專利名稱：用于管理客戶端的方法、相關(guān)的客戶端和服務器的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體地涉及在分組網(wǎng)絡中利用會話初始協(xié)議(SIP)進行客
戶端認證和升級。
背景技術(shù)：
SIP是由IETF于1999年提出的在互聯(lián)網(wǎng)中實現(xiàn)實時通信應用的信令控制協(xié)議。 它用于創(chuàng)建、修改和釋放一個或多個參與者的會話。這些會話例如是互聯(lián)網(wǎng)多媒體會議、IP 電話或多媒體分發(fā)。會話的參與者可以通過組播、單播或二者的組合來進行通信。SIP既不 是會話描述協(xié)議，也不提供會議控制功能。為了描述消息內(nèi)容的負載情況和特點，SIP使用 互聯(lián)網(wǎng)的會話描述協(xié)議(SDP)來描述終端設(shè)備的特點。 在利用SIP的系統(tǒng)中采用互聯(lián)網(wǎng)常用的客戶端/服務器結(jié)構(gòu)，由用戶代理和服務 器兩大部分組成。其中用戶代理又分為用戶代理客戶端(UAC :UserAgentClient)和用戶代 理服務器(UAS :UserAgent Server) 。 UAC用來發(fā)起會話請求，UAS用來接受并響應會話請 求。這二者只是邏輯上的功能，實際上網(wǎng)絡終端應同時具備這兩種功能，既能發(fā)起會話，又 能接受并響應會話。 目前，在軟件系統(tǒng)中，還未提出一種通過SIP實現(xiàn)軟件認證和升級的標準機制。不 同的軟件使用不同的專用機制來進行認證和升級。這存在以下三個缺點第一，由于沒有標 準機制，因此開發(fā)者必須設(shè)計和實現(xiàn)專用的軟件認證和升級機制，這在軟件開發(fā)過程中需 要付出額外的工作和成本；第二，難以在系統(tǒng)級對軟件認證和升級進行管理和維護；以及， 針對軟件認證和升級難以實施第三方應用和服務。

發(fā)明內(nèi)容
為了解決上述現(xiàn)有技術(shù)中的問題，根據(jù)本發(fā)明的一個方面，提出了一種用于在軟 件系統(tǒng)中通過SIP實現(xiàn)標準的客戶端認證和升級的方法，其中，在軟件客戶端中預設(shè)至少 一個服務器的地址，在所述客戶端與所述服務器之間按照會話初始協(xié)議交換信令從而實現(xiàn) 對所述客戶端的管理，所述方法包括所述客戶端當開始在終端上運行時向所述服務器發(fā) 送用于向該服務器注冊的第一消息；所述服務器向所述客戶端發(fā)送用于要求認證的第二消 息；在所述客戶端收到所述第二消息之后向所述服務器發(fā)送包含憑證的、用于向所述服務 器注冊的第三消息；以及，所述服務器向所述客戶端發(fā)送包含最新客戶端版本信息的、用于 確認的第四消息。 根據(jù)本發(fā)明的方法還包括如果所述客戶端本身的版本低于包含于所述第四消息 中的最新版本并且用戶決定進行升級，則所述客戶端向所述服務器發(fā)送包含所述最新客戶 端版本信息的、用于與所述服務器發(fā)起關(guān)于升級的會話的第五消息；以及，所述服務器向所 述客戶端傳送用于進行升級的數(shù)據(jù)。 可選地，所述服務器在收到所述第五消息后，還可以向所述客戶端發(fā)送用于要求 認證的第六消息，并且當所述客戶端收到所述第六消息之后向所述服務器發(fā)送包含憑證和所述最新客戶端版本信息的、用于與所述服務器發(fā)起關(guān)于升級的會話的第七消息。 根據(jù)本發(fā)明的另一方面，提出了一種在分組網(wǎng)絡中與至少一個服務器交換信令的
客戶端，其中，在所述客戶端中預設(shè)所述服務器的地址，在所述客戶端與所述服務器之間按
照會話初始協(xié)議交換信令從而實現(xiàn)對所述客戶端的管理。所述客戶端包括消息修改裝置，
其用于在用戶決定進行升級的情況下將最新客戶端版本信息設(shè)置在用于與所述服務器發(fā)
起關(guān)于升級的會話的消息中。 根據(jù)本發(fā)明的又一方面，提出了一種用于在利用SIP的系統(tǒng)中實現(xiàn)標準的客戶端 認證和升級的服務器，其中，在所述客戶端中預設(shè)所述服務器的地址，在所述客戶端與所述 服務器之間按照會話初始協(xié)議交換信令從而實現(xiàn)對所述客戶端的管理。所述服務器包括消 息修改裝置，其用于當成功認證客戶端之后將最新客戶端版本信息設(shè)置在用于確認的消息 中。


通過閱讀下面結(jié)合附圖對本發(fā)明具體實施例的說明，本發(fā)明的上述及其他特征和 優(yōu)點將變得更加明顯。其中 圖1概略地說明了如何利用SIP來實現(xiàn)和標準化客戶端認證；
圖2概略地說明了如何利用SIP來實現(xiàn)和標準化客戶端升級；
圖3是根據(jù)本發(fā)明一個實施例的客戶端認證和升級方法的流程圖；
圖4是根據(jù)本發(fā)明另一個實施例的客戶端認證和升級方法的流程圖；
圖5是根據(jù)本發(fā)明一個實施例的客戶端的框圖；禾口
圖6是根據(jù)本發(fā)明一個實施例的服務器的框圖。
具體實施例方式
本發(fā)明提出了一種用于在利用SIP的系統(tǒng)中實現(xiàn)和標準化軟件管理的方法，所述 管理包括例如認證和升級。本發(fā)明的基本思想是利用SIP注冊來實現(xiàn)和標準化軟件認證； 以及利用SIP會話發(fā)起來實現(xiàn)和標準化軟件升級。軟件與軟件服務器之間的信令流可以例 如嚴格遵循RFC 3261 。應當指出，為了經(jīng)由網(wǎng)絡而實現(xiàn)軟件認證和升級，軟件必須知道至少 一個軟件服務器的地址，并且軟件用作SIP用戶代理客戶端(UAC)而其服務器用作SIP注 冊服務器和用戶代理服務器(UAS)。圖1和圖2概略地說明了本發(fā)明的基本思想。
注意，下文將提到的軟件認證服務器與軟件升級服務器從邏輯上來說是兩個不同 的模塊，但是在實際應用中，可以物理上共存于同一服務器內(nèi)。 圖1說明了如何利用SIP來實現(xiàn)和標準化軟件認證。如圖所示，當軟件開始運行 時，它首先向軟件認證服務器發(fā)送REGISTER消息(Fl)。在SIP中，用戶代理可以通過向軟件 認證服務器發(fā)送REGISTER請求消息來完成注冊、注銷、刷新、地址映射獲取等操作。然后， 如果軟件認證服務器想要認證該軟件，則可以通過返回帶"WWW-Auth enticate"的401消 息(F2)來要求軟件提供憑證。軟件收到該401消息后根據(jù)該消息中的認證碼計算出授權(quán)碼 并重新發(fā)出具有授權(quán)碼的REGISTER消息(F3)(只有授權(quán)的軟件才能正確計算出授權(quán)碼)。 接著，當軟件認證服務器成功處理完具有正確憑證的REGISTER消息后，它將返回2000K消 息(F4)。應當指出，在由軟件認證服務器返回的這個2000K消息中引入了新的SIP報頭
5"Software-Release",軟件認證服務器通過這個新報頭告知軟件當前可獲得的最新升級版 本。該新報頭包含軟件名稱和版本。其形式例如可以是"Software-Release :software_ name 16. 6. 556. 9"，其中software_name是軟件名稱，而16. 6. 556. 9是版本號。
認證成功之后，軟件即獲知可用的最新升級版本。如果該軟件自身的版本低于最 新的升級版本，則例如可以向用戶彈出一個對話框以詢問用戶是否進行升級。如果用戶決 定進行升級，則該軟件可以使用SIP來發(fā)起升級會話。 圖2說明了如何利用SIP來實現(xiàn)和標準化軟件升級。如果用戶決定升級，則軟件 首先向軟件升級服務器發(fā)送INVITE消息(Fl)來發(fā)起升級會話。該INVITE消息中引入了 新的報頭"Software-Release",該報頭用于告知服務器該軟件想要升級至哪個軟件版本。 該INVITE消息例如可以如下 INVITE sip :updatesvr. xxx. com SIP/2. 0
Software-Release :software—name 16.6.556.9
… 其中，新的報頭Software-Release用來描述軟件名稱和版本號，即"software— name"是軟件的名稱，而"16. 6. 556. 9"是軟件的版本號。服務器可以根據(jù)這個信息來選擇 軟件升級包。F1消息所攜帶的SDP1包含客戶端升級會話的參數(shù)。所述參數(shù)包括軟件接收 升級數(shù)據(jù)所使用的網(wǎng)絡地址、軟件接收數(shù)據(jù)要使用的傳輸協(xié)議，等等。 此時，軟件升級服務器例如可以要求軟件提供憑證(F3)，如針對圖1中的 REGISTER消息那樣。在這種情況下，該軟件需要重新發(fā)出具有正確憑證的INVITE消息 (F5)。軟件升級服務器完成認證之后可以返回具有SDP2的2000K消息(F7)。在得到軟件 的確認消息ACK(F8)之后就可以向軟件發(fā)送升級數(shù)據(jù)了。當所有的升級數(shù)據(jù)被軟件接收完 畢之后，軟件升級服務器就發(fā)送BYE(F9)至軟件以釋放該會話。最后，軟件用所收到的升級 數(shù)據(jù)來進行升級。 通過以上描述可知，采用根據(jù)本發(fā)明的軟件認證和升級方法具有以下優(yōu)點
-不同的軟件可以使用相同的軟件認證和升級機制；-新軟件的開發(fā)成本和工作可以減少，因為開發(fā)者不必設(shè)計和實現(xiàn)專業(yè)的軟件認 證和升級機制； _可以在不同的軟件之間重復使用軟件認證和升級的代碼；
-可以在系統(tǒng)級實現(xiàn)對軟件認證和升級的管理和維護；以及
-可以在軟件認證和升級上實現(xiàn)第三方服務或應用。 圖3是根據(jù)本發(fā)明一個實施例的客戶端認證和升級方法的流程圖。下面結(jié)合圖1 和圖2來說明圖3的方法。 在步驟301中，所述客戶端當開始在終端上運行時向所述服務器發(fā)送用于向該服 務器注冊的第一消息。具體地，以圖l所示的信令流程圖為例，運行于終端上的客戶端向服
務器發(fā)送REGISTER消息。在這里，所述終端可以例如是個人計算機、個人數(shù)字助理(PDA)等。 接著，在步驟302中，所述服務器向所述客戶端發(fā)送用于要求認證的第二消息。在 這里，所述第二消息例如是具有WWW-Authenticate的401消息。在步驟303中，在所述客 戶端收到所述第二消息之后向所述服務器發(fā)送包含憑證的、用于向所述服務器注冊的第三
6消息。在這里，所述第三消息例如是包含憑證的REGISTER消息。在步驟304中，所述服務 器向所述客戶端發(fā)送包含最新客戶端版本信息的、用于確認的第四消息。在這里，所述第四 消息例如是2000K消息，該2000K消息具有如上文所述的新報頭"Software-Release"。
然后，在步驟305中，如果所述客戶端本身的版本低于包含于所述第四消息中的 最新版本并且用戶決定進行升級，則所述客戶端向所述服務器發(fā)送包含所述最新客戶端版 本信息的、用于與所述服務器發(fā)起關(guān)于升級的會話的第五消息。具體地，以圖2所示的信 令流程圖為例，在客戶端將收到的版本與自身版本比較后發(fā)現(xiàn)自身版本較低時，例如可以 向用戶彈出對話框來詢問用戶是否進行升級。如果用戶決定升級，則向服務器發(fā)送INVITE 消息，該INVITE消息中包含如上文所述的新報頭"Software-Release"用以告知服務器想 要升級到哪個版本。最后，在步驟306中，所述服務器向所述客戶端傳送用于進行升級的數(shù) 據(jù)。在升級數(shù)據(jù)傳送完畢之后，服務器例如可以向客戶端發(fā)送BYE消息以釋放該對話。
圖4示出了根據(jù)本發(fā)明另一個實施例的客戶端認證和升級方法的流程圖。該圖中 的步驟401至405與圖3中的步驟301至305是相同的。在下面的描述中對于相同的部分 將適當?shù)厥÷哉f明以避免重復。 在實際的應用當中，服務器在接收到來自客戶端的包含版本信息的、用于發(fā)起升 級會話的INVITE消息后，可能會要求客戶端提供憑證。本實施例就是針對這種情況。因 此，在步驟406中，所述服務器向所述客戶端發(fā)送用于要求認證的第六消息。在這里，所述 第六消息可以例如是如上文的401消息。接著，在步驟407中，當所述客戶端收到所述第六 消息之后向所述服務器發(fā)送包含憑證和所述最新客戶端版本信息的、用于與所述服務器發(fā) 起關(guān)于升級的會話的第七消息。具體地，以圖2所示的流程為例，當客戶端收到來自服務器 的401消息之后，向該服務器重新發(fā)出包含憑證以及所述新報頭"Software-Release"的 INVITE消息。最后，在步驟408中，當所述服務器認證完畢之后，向所述客戶端傳送用于進 行升級的數(shù)據(jù)。同樣，在升級數(shù)據(jù)傳送完畢之后，服務器例如可以向客戶端發(fā)送BYE消息以 釋放該對話。 這樣，通過根據(jù)本發(fā)明的方法，可以在利用SIP的系統(tǒng)中實現(xiàn)用于軟件認證和升 級的統(tǒng)一機制，從而達到如前文所述的那些優(yōu)點。 在同一發(fā)明構(gòu)思下，根據(jù)本發(fā)明的另一個方面，提供了一種用于實現(xiàn)根據(jù)本發(fā)明
的軟件認證和升級的統(tǒng)一機制的客戶端。下面就結(jié)合附圖對其進行說明。 圖5示出了根據(jù)本發(fā)明一個實施例的客戶端500。該客戶端500包括消息修改裝置
501。消息修改裝置501用于在用戶決定進行升級的情況下將最新客戶端版本信息設(shè)置在
用于與所述服務器發(fā)起關(guān)于升級的會話的消息中。例如，在用戶決定升級的情況下，消息修
改裝置501將如上文所述的新報頭"Software-Release"添加至待發(fā)送給服務器的INVITE
消息中，從而告知服務器它要升級到哪個版本。 在實施上，本實施例的客戶端500以及其包含的消息修改裝置501可以以軟件、硬 件或軟件和硬件組合的方式來實現(xiàn)。例如，本領(lǐng)域技術(shù)人員熟悉多種可用來實現(xiàn)這些部件 的設(shè)備，諸如微處理器、微控制器、專用集成電路(ASIC)、可編程邏輯設(shè)備(PLD)和/或現(xiàn)場 可編程門陣列(FPGA)等。本實施例的消息處理裝置501可以和客戶端500集成在一起實 現(xiàn)，也可以各自獨立實現(xiàn)。 在操作上，上述結(jié)合圖5說明的實施例的客戶端，可以實現(xiàn)前面描述的客戶端認證和升級方法。通過使用該客戶端，可以在利用SIP的系統(tǒng)中實現(xiàn)認證和升級客戶端的標 準機制。 在同一發(fā)明構(gòu)思下，根據(jù)本發(fā)明的另一個方面，提供了一種用于在利用SIP的系 統(tǒng)中認證和升級客戶端的服務器。下面就結(jié)合附圖對其進行說明。 圖6示出了根據(jù)本發(fā)明一個實施例的服務器600。服務器600包括消息修改裝置 601。消息修改裝置601用于當成功認證客戶端之后將最新客戶端版本信息設(shè)置在用于確 認的消息中。例如，在收到來自客戶端的包含憑證的REGISTER消息之后，消息修改裝置601 將如上所述的新報頭"Software-Release"添加至待返回給客戶端的2000K消息中，該新報 頭向客戶端指示了可用的最新升級版本。 在實施上，本實施例的服務器600以及其包含的消息修改裝置601可以以軟件、硬 件或軟件和硬件組合的方式來實現(xiàn)。例如，本領(lǐng)域技術(shù)人員熟悉多種可用來實現(xiàn)這些部件 的設(shè)備，諸如微處理器、微控制器、專用集成電路(ASIC)、可編程邏輯設(shè)備(PLD)和/或現(xiàn)場 可編程門陣列(FPGA)等。本實施例的消息處理裝置601可以和服務器600集成在一起實 現(xiàn)，也可以各自獨立實現(xiàn)。 在操作上，上述結(jié)合圖6說明的實施例的服務器，可以實現(xiàn)前面描述的客戶端認 證和升級方法。通過使用該服務器，可以在利用SIP的系統(tǒng)中實現(xiàn)認證和升級客戶端的標 準機制。 以上雖然通過一些示例性的實施例對本發(fā)明的用于在利用SIP的系統(tǒng)中實現(xiàn)標 準的客戶端認證和升級的方法、相應的客戶端以及服務器進行了詳細的描述，但是以上這 些實施例并不是窮舉的，本領(lǐng)域技術(shù)人員可以在本發(fā)明的精神和范圍內(nèi)實現(xiàn)各種變化和修 改。因此，本發(fā)明并不限于這些實施例，本發(fā)明的范圍僅由所附權(quán)利要求為準。
8
權(quán)利要求
一種用于在分組網(wǎng)絡中進行客戶端管理的方法，其中，在客戶端中預設(shè)至少一個服務器的地址，在所述客戶端與所述服務器之間按照會話初始協(xié)議交換信令從而實現(xiàn)對所述客戶端的管理，其特征在于，所述方法包括所述客戶端當開始在終端上運行時向所述服務器發(fā)送用于向該服務器注冊的第一消息；所述服務器向所述客戶端發(fā)送用于要求認證的第二消息；在所述客戶端收到所述第二消息之后向所述服務器發(fā)送包含憑證的、用于向所述服務器注冊的第三消息；以及所述服務器向所述客戶端發(fā)送包含最新客戶端版本信息的、用于確認的第四消息。
2. 根據(jù)權(quán)利要求l所述的方法，還包括下列步驟如果所述客戶端本身的版本低于包含于所述第四消息中的最新版本并且用戶決定進 行升級，則所述客戶端向所述服務器發(fā)送包含所述最新客戶端版本信息的、用于與所述服 務器發(fā)起關(guān)于升級的會話的第五消息；以及所述服務器向所述客戶端傳送用于進行升級的數(shù)據(jù)。
3. 根據(jù)權(quán)利要求2所述的方法，其中，所述服務器在收到所述第五消息后，向所述客戶 端發(fā)送用于要求認證的第六消息，并且當所述客戶端收到所述第六消息之后向所述服務器 發(fā)送包含憑證和所述最新客戶端版本信息的、用于與所述服務器發(fā)起關(guān)于升級的會話的第 七消息。
4. 根據(jù)權(quán)利要求1-3中任一項所述的方法，其中，所述最新客戶端版本信息被設(shè)置在 所述第四消息、所述第五消息和所述第七消息的報頭中，并且包括相應的客戶端名稱和版 本號。
5. 根據(jù)權(quán)利要求1-4中任一項所述的方法，其中，所述第一消息和第三消息是按照會 話初始協(xié)議的REGISTER消息。
6. 根據(jù)權(quán)利要求1-5中任一項所述的方法，其中，所述第二消息和所述第六消息是按 照會話初始協(xié)議的401消息。
7. 根據(jù)權(quán)利要求1-6中任一項所述的方法，其中，所述第四消息是按照會話初始協(xié)議 的2000K消息。
8. 根據(jù)權(quán)利要求1-7中任一項所述的方法，其中，所述第五消息和所述第七消息是按 照會話初始協(xié)議的INVITE消息。
9. 一種在分組網(wǎng)絡中與至少一個服務器交換信令的客戶端，其中，在所述客戶端中預 設(shè)所述服務器的地址，在所述客戶端與所述服務器之間按照會話初始協(xié)議交換信令從而實 現(xiàn)對所述客戶端的管理，其特征在于，所述客戶端包括消息修改裝置，用于在用戶決定進行升級的情況下將最新客戶端版本信息設(shè)置在用于 與所述服務器發(fā)起關(guān)于升級的會話的消息中。
10. 根據(jù)權(quán)利要求9所述的客戶端，其中，所述用于與所述服務器發(fā)起關(guān)于升級的會話 的消息是按照會話初始協(xié)議的INVITE消息。
11. 根據(jù)權(quán)利要求9或10所述的客戶端，其中，所述最新客戶端版本信息被設(shè)置在所述 用于與所述服務器發(fā)起關(guān)于升級的會話的消息的報頭中，并且包括相應的客戶端名稱和版 本號。
12. —種用于在分組網(wǎng)絡中管理客戶端的服務器，其中，在所述客戶端中預設(shè)所述服務 器的地址，在所述客戶端與所述服務器之間按照會話初始協(xié)議交換信令從而實現(xiàn)對所述客 戶端的管理，其特征在于，所述服務器包括消息修改裝置，用于當成功認證客戶端之后將最新客戶端版本信息設(shè)置在用于確認的 消息中。
13. 根據(jù)權(quán)利要求12所述的服務器，其中，所述用于確認的消息是按照會話起始協(xié)議 的2000K消息。
14. 根據(jù)權(quán)利要求12或13所述的服務器，其中，所述最新客戶端版本信息被設(shè)置在所 述用于確認的消息的報頭中，并且包括相應的客戶端名稱和版本號。
全文摘要
本發(fā)明提出了一種在利用SIP的系統(tǒng)中實現(xiàn)標準化軟件認證和升級的方法、相關(guān)的客戶端和服務器，其中，在客戶端中預設(shè)至少一個服務器的地址，在客戶端與服務器之間按照SIP交換信令，該方法包括客戶端當開始在終端上運行時向服務器發(fā)送向服務器注冊的第一消息；服務器向客戶端發(fā)送要求認證的第二消息；在客戶端收到第二消息之后向服務器發(fā)送包含憑證的、向服務器注冊的第三消息；服務器向客戶端發(fā)送包含最新客戶端版本信息的第四確認消息；如果客戶端本身的版本低于包含于第四消息中的版本并且用戶決定升級，則客戶端向服務器發(fā)送包含最新客戶端版本信息的、與服務器發(fā)起關(guān)于升級的會話的第五消息；以及，服務器向客戶端傳送升級數(shù)據(jù)。
文檔編號H04L12/24GK101783783SQ20091000325
公開日2010年7月21日 申請日期2009年1月21日 優(yōu)先權(quán)日2009年1月21日
發(fā)明者卜文飛 申請人:阿爾卡特朗訊公司