專利名稱：一種在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域中的數(shù)據(jù)傳輸技術(shù)，尤其是涉及一種在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)及方法。
背景技術(shù)：
消息會話中繼協(xié)議(Message Session Relay Protocol，MSRP)，是國際互聯(lián)網(wǎng)技術(shù)標(biāo)準(zhǔn)組織(The Internet Engineering Task Force，IETF)制定的一個基于文本、面向連接的傳輸協(xié)議，可以用于交換任意的(包括二進(jìn)制)多用途互聯(lián)網(wǎng)郵件擴(kuò)展(Multipurpose Internet Mail Exchange，MIME)內(nèi)容，尤其是用于即時消息。消息會話中繼協(xié)議通過初始會話協(xié)議(Session InitiatedProtocol，SIP)和會話描述協(xié)議(Session Description Protocol，SDP)來協(xié)商建立消息會話，建立方式與通過初始會話協(xié)議建立其它會話例如音頻會話、視頻會話完全相同。
消息會話中繼協(xié)議非常適合于大消息的傳輸和基于會話的即時消息傳輸。
應(yīng)用消息會話中繼協(xié)議時，首先需要協(xié)商源端和目的端之間將要傳輸?shù)拿襟w屬性，這一協(xié)商過程由初始會話協(xié)議和會話描述協(xié)議信令承載并發(fā)送；然后根據(jù)協(xié)商之后的端口號和媒體屬性進(jìn)行媒體數(shù)據(jù)的傳送，在消息會話中繼協(xié)議中主要定義了SEND方法進(jìn)行傳輸媒體數(shù)據(jù)，消息會話中繼協(xié)議支持的媒體數(shù)據(jù)類型為MIME格式的任意數(shù)據(jù)，例如文本、音頻、視頻等等。
現(xiàn)有的國際互聯(lián)網(wǎng)技術(shù)標(biāo)準(zhǔn)組織(IETF)定義的消息會話中繼協(xié)議中，可以支持多種內(nèi)容類型的傳輸，其內(nèi)容類型通過Content-type字段進(jìn)行定義，以便在MSRP SEND消息體正文中的數(shù)據(jù)能夠被發(fā)送方和接收方正確處理，其可以支持的內(nèi)容類型有text、image、audio、video、applications、multipart、message。
在利用消息會話中繼協(xié)議(MSRP)進(jìn)行消息傳送業(yè)務(wù)的過程中，存在這樣一種必要的應(yīng)用情形某個消息自發(fā)送方客戶端(Client)被發(fā)送時，如果出現(xiàn)了接收方不在線或者服務(wù)器當(dāng)前過負(fù)荷等等的異常情況，那么該消息不能被接收方立即接收，此時服務(wù)器需要暫時存儲該消息，以便下次接收方在線時或者服務(wù)器未滿負(fù)荷或者其他異常情況被處理完畢后，服務(wù)器能夠?qū)⒋讼⑥D(zhuǎn)發(fā)到接收方，這就是“存儲轉(zhuǎn)發(fā)”的過程。
為描述方便起見，稱上述的發(fā)送到服務(wù)器之前的消息為消息1，服務(wù)器存儲后再次轉(zhuǎn)發(fā)到接收方；給接收方下發(fā)的消息為消息2。
一般地，消息1經(jīng)過服務(wù)器的存儲之后，需要被封裝在消息2中，才能被正確地下發(fā)到接收方。
如果消息1在源端是以SIP MESSAGE來承載發(fā)送的，那么服務(wù)器以MSRP SEND來封裝SIP MESSAGE的方法比較簡單，國際互聯(lián)網(wǎng)技術(shù)標(biāo)準(zhǔn)組織(IETF)的RFC(Request for Comments)標(biāo)準(zhǔn)規(guī)范中已有說明，即直接將SIP MESSAGE源消息1封裝在MSRP SEND消息體中，同時MSRP SEND的消息頭的content-type字段定義為message/sip。
如果消息1在源端是經(jīng)MSRP SEND來承載發(fā)送的，那么服務(wù)器需要以MSRP SEND方法來封裝消息1形成消息2，下發(fā)給接收方。
現(xiàn)有的一種方法是首先，服務(wù)器接收到消息1之后，去除掉其中用于傳輸?shù)拈_銷的字段消息，解析出其中的有用信息，例如消息的發(fā)送方統(tǒng)一的資源標(biāo)識符(Uniform Resource Identifier，URI)地址、接收方URI地址、消息內(nèi)容，并以一定的數(shù)據(jù)格式保存這些消息到消息存儲實(shí)體中。
然后，當(dāng)服務(wù)器需要轉(zhuǎn)發(fā)此消息到接收方客戶端時，在建立了服務(wù)器(Server)和接收方客戶端的會話之后，重新用MSRP SEND進(jìn)行消息的發(fā)送。
但是，這種方法存在很多的缺陷，其先要解析，然后又要封裝，有2次消息的處理過程，處理過程很復(fù)雜，增加服務(wù)器的負(fù)擔(dān)。

發(fā)明內(nèi)容
本發(fā)明的目的在于克服上述缺陷而提供的一種在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)及方法，其實(shí)現(xiàn)了MSRP SEND封裝MSRP消息并傳輸給接收方客戶端的方法，減輕了服務(wù)器的負(fù)載。
為實(shí)現(xiàn)本發(fā)明的目的而提供的一種在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)，包括服務(wù)器，至少一個發(fā)送方客戶端和至少一個接收方客戶端；發(fā)送方客戶端發(fā)送MSRP源消息，經(jīng)服務(wù)器下發(fā)給接收方客戶端。
所述服務(wù)器包括解析封裝消息模塊，用于將服務(wù)器收到的MSRP源消息進(jìn)行解析，得到接收方客戶端地址，并根據(jù)接收方客戶端的地址及源消息封裝新的MSRP SEND消息。
所述接收方客戶端還包括解析模塊，用于當(dāng)接收方客戶端接收到所述MSRP SEND消息時，對所述消息進(jìn)行解析，并獲取消息的信息。
所述的服務(wù)器還可以包括存儲模塊，用于存儲發(fā)送方客戶端與服務(wù)器交互的以消息會話中繼協(xié)議承載的消息。
所述MSRP源消息可以是包括SIP INVITE消息，MSRP SEND消息。
所述MSRP源消息還可以包括SIP 200 OK消息和SIP BYE消息。
所述MSRP SEND消息可以包括消息頭和消息體，所述消息體包括SIPINVITE消息部分和MSRP SEND消息部分。
所述MSRP SEND消息也可以包括消息頭和消息體，所述消息體包括SIPINVITE消息部分、MSRP SEND消息部分、SIP 200 OK消息部分和SIP BYE消息部分。
為實(shí)現(xiàn)本發(fā)明目的而提供的一種在消息會話中繼協(xié)議中封裝消息的服務(wù)器，包括解析封裝消息模塊，用于將服務(wù)器收到的MSRP源消息進(jìn)行解析，得到接收方客戶端地址，并根據(jù)接收方客戶端的地址及源消息封裝新的MSRP SEND消息。
所述MSRP源消息可以包括SIP INVITE消息，MSRP SEND消息。
所述MSRP源消息還可以包括SIP 200 OK消息和SIP BYE消息。
所述MSRP SEND消息可以包括消息頭和消息體，所述消息體包括SIPINVITE消息部分和MSRP SEND消息部分。
所述MSRP SEND消息也可以包括消息頭和消息體，所述消息體包括SIPINVITE消息部分、MSRP SEND消息部分、SIP 200 OK消息部分和SIP BYE消息部分。
為實(shí)現(xiàn)本發(fā)明目的而提供的一種在消息會話中繼協(xié)議中消息的封裝方法，包括下列步驟
步驟A)服務(wù)器讀取MSRP源消息；步驟B)解析所述的MSRP源消息，得到接收方客戶端地址，并利用所述地址和所述源消息封裝新的MSRP SEND消息。
所述步驟B)可以包括下列步驟步驟B1)服務(wù)器解析的MSRP源消息的SIP INVITE消息，獲取該源消息的接收方客戶端的URI地址，然后構(gòu)造新的MSRP SEND消息的消息頭；步驟B2)服務(wù)器以所述MSRP源消息中的SIP INVITE消息封裝新的MSRP SEND消息的SIP INVITE消息部分；步驟B3)服務(wù)器以所述MSRP源消息中的MSRP SEND消息封裝新的NSRP SEND消息中的MSRP SEND消息部分。
所述步驟B)還可以包括下列步驟服務(wù)器以所述MSRP源消息中的SIP 200 OK消息封裝新的MSRP SEND消息中的SIP 200 OK消息部分；服務(wù)器以所述MSRP源消息中的SIP BYE消息封裝新的MSRP SEND消息中的SIP BYE消息部分。
所述消息頭包括接收方地址字段，服務(wù)器地址字段，消息體類型字段和分界標(biāo)志符。
所述消息頭的消息體類型字段為復(fù)合體消息體。
所述封裝的SIP INVITE消息部分的消息體類型為message/sip；所述封裝的MSRP SEND消息部分中消息體類型為message/msrp；所述封裝的SIP 200 OK消息部分中消息體類型為message/sip；所述封裝的SIP BYE消息部分中消息體類型為message/sip。
本發(fā)明的在消息會話中繼協(xié)議中消息的封裝方法，還可以包括下列步驟步驟Y)服務(wù)器還讀取服務(wù)器接收到所述MSRP源消息的接收時間；并將所述接收時間封裝到新的MSRP SEND消息的各個消息部分中。
所述步驟Y)可以包括下列步驟將所述接收時間封裝到新的MSRP SEND消息的SIP INVITE消息部分，MSRP SEND消息部分，SIP 200 OK消息部分和SIP BYE消息部分。
為實(shí)現(xiàn)本發(fā)明目的而提供的一種在消息會話中繼協(xié)議中消息的封裝傳輸方法，包括下列步驟步驟A′)服務(wù)器和接收方客戶端建立起MSRP連接；步驟B′)服務(wù)器將利用MSRP源消息解析并得到接收方客戶端地址，根據(jù)接收方客戶端地址和源消息封裝新的MSRP SEND消息；步驟C′)服務(wù)器將所述MSRP SEND消息下發(fā)給接收方客戶端；步驟D′)接收方客戶端解析收到的MSRP SEND消息，將消息的內(nèi)容解析出來。
所述步驟D′)還可以包括下列步驟步驟D1′)接收方客戶端確認(rèn)收到下發(fā)消息，發(fā)送確認(rèn)消息。
所述步驟D′)也可以包括下列步驟步驟D21′)接收方客戶端收到MSRP消息，判斷出其消息內(nèi)容類型是復(fù)合消息體；步驟D22′)接收方客戶端依次讀取MSRP SEND消息中的各個部分，根據(jù)MSRP SEND消息的消息體中各個部分所示的消息體類型進(jìn)行解析，得到消息內(nèi)容。
所述消息內(nèi)容包括發(fā)送方客戶端的URI地址，接收方客戶端的URI地址信息，發(fā)送內(nèi)容以及消息的發(fā)送時間戳。
所述步驟D22′)可以包括下列步驟步驟D221′)接收方客戶端解析SIP INVITE消息部分，獲取發(fā)送方客戶端的URI地址和接收方客戶端的URI地址；步驟D222′)接收方客戶端解析MSRP SEND消息部分，獲取消息內(nèi)容以及消息的發(fā)送時間戳。
所述步驟D22′)還可以包括下列步驟步驟D233′)接收方客戶端還解析MSRP SEND消息的消息體中的SIP200OK消息部分和SIP BYE消息部分。
本發(fā)明的在消息會話中繼協(xié)議中消息的封裝傳輸方法，還包括下列步驟步驟M1′)發(fā)送方客戶端和服務(wù)器協(xié)商建立MSRP會話；步驟M2′)發(fā)送方客戶端將發(fā)送MSRP SEND消息；步驟M3′)服務(wù)器接收到所述MSRP SEND消息。
本發(fā)明的在消息會話中繼協(xié)議中消息的封裝傳輸方法，還可以包括下列步驟發(fā)送方客戶端斷開和服務(wù)器的MSRP連接。
本發(fā)明的有益效果是本發(fā)明在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)及方法，其使得服務(wù)器處理簡單，無需解析直接存儲，只需要一次封裝，從而減輕了服務(wù)器的負(fù)載。而對于客戶端來說，在滿足了能夠支持MSRP協(xié)議的基礎(chǔ)條件下，解析了一個具有普通消息體的MSRP SEND消息和解析具有復(fù)合消息體的MSRP SEND消息(即消息體中嵌套MSRP消息)的時間復(fù)雜度是基本相同的，都是解析一次。因此，這種封裝消息的方法使整個會話過程簡單而實(shí)用，減輕服務(wù)器的負(fù)擔(dān)。


圖1為本發(fā)明MSRP消息傳輸過程流程圖；圖2為本發(fā)明MSRP消息封裝過程流程圖。
具體實(shí)施例方式
下面結(jié)合附圖1和附圖2進(jìn)一步詳細(xì)說明本發(fā)明的一種在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)及方法。
本實(shí)施例以消息從發(fā)送方客戶端被發(fā)送時，接收方客戶端不在線，或者服務(wù)器當(dāng)前過負(fù)荷等異常情況，消息不能被接收方立即接收，此時服務(wù)器需要暫時存儲該消息，即延遲發(fā)送消息為例，說明MSRP消息封裝傳輸系統(tǒng)及方法，但本發(fā)明并不以此為限，只要應(yīng)用到了本發(fā)明的MSRP協(xié)議封裝技術(shù)，均應(yīng)在本發(fā)明的保護(hù)范圍之內(nèi)。
如圖1所示，在實(shí)施例中，各實(shí)體的含義如下ClientA表示消息的發(fā)送方客戶端；ClientB表示消息的接收方客戶端；Server表示MSRP服務(wù)器，其可以是延遲消息發(fā)送服務(wù)器，并具有其它的功能，如MSRP用于SIP/SIMPLE即時消息業(yè)務(wù)領(lǐng)域時該服務(wù)器就是即時消息服務(wù)器(IM Server)；Message1表示從發(fā)送方客戶端ClientA發(fā)送的MSRP SEND消息，其中包含要發(fā)送的消息內(nèi)容；
Message2表示服務(wù)器封裝的新的MSRP SEND消息，其中包含源消息的內(nèi)容。
在本發(fā)明的實(shí)施例中，傳輸消息需要經(jīng)過公知的SIP/IP Core核心網(wǎng)，本發(fā)明不再詳述。
(一)下面詳細(xì)描述本發(fā)明的一種在消息會話中繼協(xié)議中消息封裝傳輸系統(tǒng)。
本發(fā)明的在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)包括服務(wù)器，至少一個發(fā)送方客戶端和一個接收方客戶端，其中發(fā)送方客戶端發(fā)送并經(jīng)服務(wù)器下發(fā)給接收方客戶端MSRP消息。
在服務(wù)器中，包括存儲模塊和解析封裝消息模塊。
存儲模塊，用于存儲發(fā)送方客戶端與服務(wù)器交互的以消息會話中繼協(xié)議承載的消息。
解析封裝消息模塊，用于將服務(wù)器收到的MSRP源消息進(jìn)行解析，得到接收方客戶端地址，并根據(jù)接收方客戶端的地址及MSRP源消息封裝新的MSRP消息。
在接收方客戶端，包括解析模塊。
解析模塊，用于當(dāng)接收到所述MSRP消息時，對所述消息進(jìn)行解析，并獲取所述MSRP源消息的信息。
發(fā)送方客戶端ClientA和服務(wù)器Server協(xié)商以公知的方式，使用SIP消息及其攜帶的會話描述協(xié)議(SDP)offer/answer機(jī)制來協(xié)商建立MSRP會話，發(fā)送方客戶端ClientA構(gòu)造MSRP SEND消息message1，發(fā)送到接收方客戶端ClientB，服務(wù)器Server接收到MSRP SEND消息message1，并且出現(xiàn)接收方客戶端ClientB不在線、服務(wù)器Server過負(fù)荷或者其他異常情況，則服務(wù)器Server存儲源消息，包括MSRP SEND消息message1和SIP INVITEI消息，還可以包括SIP 200 OK消息以及SIP BYE消息到存儲模塊。
當(dāng)接收方客戶端ClientB和服務(wù)器Server協(xié)商以公知的方式建立MSRP連接，接收方客戶端ClientB再次上線或者服務(wù)器Server未滿負(fù)荷或者其他異常情況不存在時，服務(wù)器Server中的解析封裝模塊將源消息從存儲模塊中讀取出來，進(jìn)行解析，得到接收方客戶端ClientB的地址，然后封裝新的MSRPSEND消息中，服務(wù)器Server下發(fā)新的MSRP SEND消息message2。
接收方客戶端ClientB確認(rèn)收到下發(fā)的MSRP SEND消息message2，其解析模塊解析收到的MSRP SEND消息，得到消息內(nèi)容。
(二)如圖1所示，下面詳細(xì)描述本發(fā)明的消息會話中繼協(xié)議中消息傳輸方法過程。
步驟1發(fā)送方客戶端ClientA和服務(wù)器Server協(xié)商建立MSRP會話；在發(fā)送方客戶端和接收方客戶端之間，發(fā)送SIP INVITE消息，發(fā)送方客戶端ClientA和服務(wù)器Server協(xié)商以公知的方式建立MSRP會話，其可以是發(fā)送方客戶端ClientA發(fā)起建立，也可以是服務(wù)器Server發(fā)起建立。會話建立后，回應(yīng)SIP 200 OK消息。
步驟3-4發(fā)送方客戶端ClientA將MSRP SEND消息message1發(fā)送，其中消息體中包括發(fā)送方真正需要發(fā)送的內(nèi)容；步驟5-6發(fā)送方客戶端ClientA斷開和服務(wù)器Server的MSRP連接。
發(fā)送方客戶端ClientA斷開和服務(wù)器Server的MSRP連接，發(fā)送SIP BYE消息；步驟7服務(wù)器Server接收到源消息，出現(xiàn)異常情況，則服務(wù)器Server存儲源消息。
服務(wù)器Server接收到源消息，接收方客戶端ClientB不在線、服務(wù)器Server過負(fù)荷或者出現(xiàn)其他異常情況，則服務(wù)器Server存儲源消息到存儲模塊。
較佳地，服務(wù)器Server存儲模塊在存儲源消息的同時，還需要記錄并存儲服務(wù)器Server接收到此源消息的時間，也即給該消息加上時間戳Date。這樣以便后面轉(zhuǎn)發(fā)到接收端時接收端能夠得知該消息的發(fā)送時間。對于延遲消息來說，時間戳也是一個重要的消息屬性。
例1，發(fā)送方客戶端ClientA向接收方客戶端ClientB發(fā)送消息內(nèi)容“Hi,Alice!I’m Bob!”，則存儲源消息如下INVITE sip:imserver.com SIP/2.0 //SIP INVITE消息To:<sip:user2@imserver.com> //目的端URI地址From:<sip:user1@imserver.com>;tag=123 //源端URI地址Call-ID:3413an89KU
Content-Type:application/sdp //消息體類型c=IN IP4 user1.imserver.com //IP地址m=message 7654 TCP/MSRP*//端口號、傳輸協(xié)議類型a=accept-types:text/plain //可接受的MIME類型a=path:msrp://user1.imserver.com:7654/jshA7we;tcp //MSRP URI，標(biāo)識一個MSRP會話SIP/2.0 200 OK //SIP 200 OK消息To:<sip:user2@imserver.com>;tag=012abFrom:<sip:user1@imserver.com>;tag=123Call-ID:3413an89KUContent-Type:application/sdpc=IN IP4 imserver.comm=message 12345 TCP/MSRP*a=accept-types:text/plaina=path:msrp://imserver.com:12345/kjhd37s2s2;tcpMSRP dkei38sd SEND //MSRP SEND消息To-Path:msrp://imserver.com:12345/kjhd37s2s2;tcp //接收方URI地址From-Path:msrp://user1.imserver.com:7654/jshA7we;tcp //服務(wù)器URI地址Message-ID:123Content-Type:text/plainHi,Alice!I′m Bob! //發(fā)送內(nèi)容(消息體)-------dkei38sd$ //傳輸IDBYE sip:user1@i imserver.com SIP/2.0//SIP BYE子消息上述步驟5-6和7不存在必然的時序先后關(guān)系，也可以是7在前，5-6在后，但并不影響本發(fā)明。
步驟8服務(wù)器Server和接收方客戶端ClientB建立起MSRP連接。
接收方客戶端ClientB和服務(wù)器Server協(xié)商以公知的方式建立MSRP連接，其可以是接收方客戶端ClientB發(fā)起建立，也可以是服務(wù)器Server發(fā)起建立。
服務(wù)器和接收方客戶端通過SIP INVITE、SIP 200OK建立起MSRP會話，根據(jù)消息獲取的方式不同(或者是接收方客戶端ClientB主動獲取，或者是服務(wù)器Server主動push推送到接收方客戶端ClientB)，SIP INVITE可以是接收方客戶端ClientB方主動發(fā)起，也可以是服務(wù)器Server端主動發(fā)起。當(dāng)是接收方客戶端ClientB主動發(fā)起時，SIP INVITE的源地址和接收方地址分別是接收方客戶端ClientB的URI地址和服務(wù)器地址；當(dāng)是服務(wù)器Server主動發(fā)起時，SIP INVITE的源地址和接收方地址分別是服務(wù)器地址和接收方clientB的URI地址。這里的SIP INVITE和SIP 200 OK消息的構(gòu)造方式和現(xiàn)有技術(shù)完全類似，和本發(fā)明的消息封裝傳輸技術(shù)本身無關(guān)，因此本領(lǐng)域的技術(shù)人員可以根據(jù)例子中的源消息的內(nèi)容，構(gòu)造出新的SIP INVITE和SIP 200 OK消息，因此本發(fā)明不再詳述。
步驟9當(dāng)異常情況不再存在時，服務(wù)器Server將已存儲的源消息進(jìn)行消息封裝，封裝到新的MSRP SEND消息中。
當(dāng)接收方客戶端ClientB再次上線或者服務(wù)器Server未滿負(fù)荷或者其他異常情況不存在時，服務(wù)器Server解析封裝模塊將源消息從存儲模塊中讀取出來，進(jìn)行解析，并封裝到新的MSRP SEND消息message2中。
步驟10服務(wù)器Server將所述的MSRP SEND消息message2下發(fā)給接收方客戶端ClientB；服務(wù)器Server將封裝后的新的MSRP SEND消息message2下發(fā)到接收方客戶端ClientB。
這里的轉(zhuǎn)發(fā)方式可以是接收方客戶端ClientB主動請求獲取，也可以是服務(wù)器Server主動下發(fā)，無論哪種方式都不影響本發(fā)明的保護(hù)范圍。
步驟11接收方客戶端ClientB確認(rèn)收到下發(fā)的MSRP SEND消息message2，發(fā)送SIP 200 OK消息。
步驟12接收方客戶端ClientB解析收到的MSRP SEND消息，將源消息內(nèi)容解析出來。
封裝后的新的MSRP SEND消息被發(fā)送之后，服務(wù)器和接收方客戶端還需要通過SIP BYE來結(jié)束本次MSRP會話。SIP BYE消息的構(gòu)造方式和現(xiàn)有技術(shù)完全類似，和消息封裝傳輸技術(shù)本身無關(guān)，因此本領(lǐng)域的技術(shù)人員可以根據(jù)例子中的源消息的內(nèi)容，構(gòu)造出新的SIP BYE消息，因此本發(fā)明不再詳述。
(三)如圖2所示，下面詳細(xì)描述步驟9中在消息會話中繼協(xié)議中封裝消息的方法過程步驟91)服務(wù)器Server讀取已存儲的需要發(fā)送給接收方客戶端ClientB的源消息；服務(wù)器Server讀取已存儲的需要發(fā)送到接收方客戶端ClientB的源消息。在優(yōu)選方式下，服務(wù)器Server還需要讀取該消息在服務(wù)器上的接收時間，以便接收方能夠知道該消息是什么時間被發(fā)送出來的，由于消息從發(fā)送端發(fā)出到被服務(wù)器接收之間的時間間隔很短，可以認(rèn)為消息在服務(wù)器上的接收時間就是該消息的發(fā)送時間，因此服務(wù)器Server讀取該時間作為該消息的時間戳。
步驟92)解析服務(wù)器Server所存儲的需要發(fā)送到接收方客戶端ClientB的消息，得到接收方客戶端的URI地址，并利用所述地址和所述消息封裝新的MSRP SEND消息。
步驟921)首先服務(wù)器Server解析已經(jīng)存儲的MSRP會話過程中的源消息的SIP INVITE消息，以獲取該源消息的接收方URI地址，然后構(gòu)造新的MSRP SEND消息的消息頭。
其中新的MSRP SEND的消息頭中的To-path字段為接收方URI地址、From-path字段為Server的URI地址；字段Content-Type頭域的值為multipart/mixed，表示消息體類型是復(fù)合消息體；定義字段boundary的值，表示各個子消息體之間的分界標(biāo)志，例如boundary42；如所述例1的消息，則服務(wù)器Server解析SIP INVITE消息，獲取該源消息的接收方URI地址user2@imserver.com；然后，構(gòu)造新的MSRP SEND消息的消息頭中的To-path字段為接收方URI地址user2@imserver.com，F(xiàn)rom-path字段為服務(wù)器Server的URI地址imserver.com。
如所述例1的消息，則新MSRP SEND的消息頭為MSRP abcd12sk SEND //封裝后的MSRP SEND消息頭To-Path:msrp://user2.imserver.com:7777/iau39;tcp //目的URI地址From-Path:msrp://imserver.com:8888/9di4ea;tcp//源URI地址Message-ID:456Content-Type:multipart/mixed;//消息體類型boundary="boundary42"http://分界標(biāo)志而新的MSRP SEND消息message2消息的消息體根據(jù)源消息構(gòu)造，包括源消息中的SIP INVITE消息、SIP 200 OK消息、MSRP SEND消息和SIP BYE消息。
922)服務(wù)器Server以被發(fā)送時的MSRP源消息中的SIP INVITE消息，封裝新的MSRP SEND消息message2的SIP INVITE消息部分，其中包含了源消息的發(fā)送方URI地址，這部分的Content-type頭域的值為message/sip；服務(wù)器Server封裝的新的MSRP SEND消息message2的SIP INVITE消息部分還可以在原有的SIP INVITE消息中增加Date字段，其值為步驟91)所述的時間戳；如所述例1的消息，封裝后的SIP INVITE消息部分如下--boundary42Content-Type:message/sipINVITE sip:imserver.com SIP/2.0To:<sip:user2@imserver.com>
From:<sip:user1@imserver.com>;tag=123Call-ID:3413an89KUDate:Mon,03Jan 2005 08:01:02 GMTContent-Type:application/sdpc=IN IP4 user1.imserver.comm=message 7654TCP/MSRP*a=accept-types:text/plaina=path:msrp://user1.imserver.com:7654/jshA7we;tcp923)服務(wù)器Server以被發(fā)送時MSRP源消息中的SIP 200 OK消息，封裝新的MSRP SEND消息message2的SIP 200 OK消息部分，這部分的Content-type頭域的值為message/sip；服務(wù)器Server封裝新的MSRP SEND消息message2的SIP 200 OK消息部分還可以在原有的SIP 200 OK消息中增加Date字段，其值為步驟91)所述的時間戳；如所述例1的消息，封裝后的SIP 200 OK消息部分如下--boundary42Content-Type:message/sipSIP/2.0 200 OKTo:<sip:user2@imserver.com>;tag=012abFrom:<sip:user1@imserver.com>;tag=123Call-ID:3413an89KUDate:Mon,03 Jan 2005 08:01:02 GMTContent-Type:application/sdpc=IN IP4 imserver.comm=message 12345 TCP/MSRP*
a=accept-types:text/plaina=path:msrp://imserver.com:12345/kjhd37s2s2;tcp924)服務(wù)器Server以被發(fā)送時MSRP源消息中的MSRP SEND消息，封裝新MSRP SEND消息message2的MSRP SEND消息部分；這部分的Content-type頭域的值需要對現(xiàn)有技術(shù)(IETF規(guī)范)進(jìn)行擴(kuò)充，例如定義Content-type為“message/msrp”；進(jìn)一步地，服務(wù)器Server封裝新的MSRP SEND消息message2的MSRPSEND消息部分還可以在原有的MSRP SEND消息中增加Date字段，其值為步驟91)所述的時間戳；如所述例1的消息，封裝后的MSRP SEND消息部分如下--boundary42Content-Type:message/msrpMSRP dkei38sd SENDTo-Path:msrp://imserver.com:12345/kjhd37s2s2;tcpFrom-Path:msrp://user1.imserver.com:7654/jshA7we;tcpMessage-ID:123Date:Mon,03 Jan 2005 08:01:02 GMTContent-Type:text/plainHi,Alice!I′m Bob!-------dkei38sd$925)服務(wù)器Server以被發(fā)送時MSRP源消息中的SIP BYE消息，封裝新的MSRP SEND消息的SIP BYE消息部分，這部分的Content-type頭域的值為message/sip；進(jìn)一步地，服務(wù)器Server封裝新的MSRP SEND消息的MSRP SEND消息部分還可以在原有的SIP BYE消息中增加Date字段，其值為步驟91所述的時間戳；如所述例1的消息，封裝后的SIP BYE消息部分如下--boundary42Content-Type:message/sipBYE sip:user1@i imserver.com SIP/2.0Date:Mon,03 Jan 2005 08:01:02 GMT--boundary42-該消息被封裝后發(fā)送時，封裝后新的MSRP SEND消息message2如下MSRP abcd12sk SEND //封裝后的MSRP SEND消息頭To-Path:msrp://user2.imserver.com:7777/iau39;tcp //目的URI地址From-Path:msrp://imserver.com:8888/9di4ea;tcp //源URI地址Message-ID:456Content-Type:multipart/mixed; //消息體類型boundary="boundary42" //分界標(biāo)志--boundary42 //封裝后的MSRP SEND消息體Content-Type:message/sipINVITE sip:imserver.com SIP/2.0To:<sip:user2@imserver.com>
From:<sip:user1@imserver.com>;tag=123Call-ID:3413an89KUDate:Mon,03 Jan 2005 08:01:02 GMTContent-Type:application/sdpc=IN IP4 user1.imserver.comm=message 7654 TCP/MSRP*a=accept-types:text/plaina=path:msrp://user1.imserver.com:7654/jshA7we;tcp--boundary42Content-Type:message/sipSIP/2.0 200 OKTo:<sip:user2@imserver.com>;tag=012abFrom:<sip:user1@imserver.com>;tag=123Call-ID:3413an89KUDate:Mon,03 Jan 2005 08:01:02 GMTContent-Type:application/sdpc=IN IP4 imserver.comm=message 12345 TCP/MSRP*a=accept-types:text/plaina=path:msrp://imserver.com:12345/kjhd37s2s2;tcp--boundary42Content-Type:message/msrpMSRP dkei38sd SENDTo-Path:msrp://imserver.com:12345/kjhd37s2s2;tcpFrom-Path:msrp://user1.imserver.com:7654/jshA7we;tcpMessage-ID:123Date:Mon,03 Jan 2005 08:01:02 GMTContent-Type:text/plainHi,Alice!I′m Bob!
-------dkei38sd$--boundary42Content-Type:message/sipBYE sip:user1@i imserver.com SIP/2.0Date:Mon,03Jan 2005 08:01:02 GMT--boundary42-封裝后新的MSRP SEND消息message2下發(fā)給接收方客戶端ClientB。
(四)下面詳細(xì)描述步驟12中接收方客戶端ClientB解析被封裝后的MSRP SEND消息的方法接收方客戶端ClientB根據(jù)所述封裝過程反向解析MSRP SEND消息message2即可。
步驟121)接收方客戶端ClientB收到MSRP SEND消息message2后，發(fā)現(xiàn)其內(nèi)容類型是multipart/mixed，需要解析消息體內(nèi)容。
步驟122)接收方客戶端ClientB依次讀取MSRP SEND消息體中的各個部分，根據(jù)消息體中各個部分所示的content-type進(jìn)行解析，如果是message/sip，則知道是SIP消息；如果是message/msrp，在知道是MSRP消息。
步驟1221)接收方客戶端ClientB首先解析SIP INVITE消息體，獲取發(fā)送方客戶端ClientA的URI地址和接收方客戶端ClientB的URI地址；步驟1222)接收方客戶端ClientB解析MSRP SEND消息體，獲取消息內(nèi)容以及消息的發(fā)送時間戳；步驟1223)進(jìn)一步地，接收方客戶端ClientB還解析MSRP SEND消息中的SIP 200 OK消息體和SIP BYE消息體；步驟123)接收方客戶端ClientB將發(fā)送方客戶端ClientA的URI地址、接收方客戶端ClientB的URI地址信息、發(fā)送內(nèi)容以及消息的發(fā)送時間戳以公知的技術(shù)組合到用戶界面中，呈現(xiàn)給用戶。
具體的公知的用戶界面組合技術(shù)和本發(fā)明無關(guān)，其不影響本發(fā)明的保護(hù)范圍。
本發(fā)明的MSRP消息封裝系統(tǒng)及傳輸方法，通過擴(kuò)充現(xiàn)有的技術(shù)(IETF標(biāo)準(zhǔn)協(xié)議)，使得MSRP協(xié)議更加完善，為延遲消息的存儲轉(zhuǎn)發(fā)等業(yè)務(wù)應(yīng)用提供了傳輸層的必要技術(shù)支撐。
和現(xiàn)有技術(shù)相比，本發(fā)明的封裝技術(shù)使得服務(wù)器處理簡單，無需解析直接存儲，只需要一次解析封裝。而對于客戶端來說，在滿足了能夠支持MSRP協(xié)議的基礎(chǔ)條件下，解析一個具有普通消息體的MSRP SEND消息和解析具有復(fù)合消息體的MSRP SEND消息的時間復(fù)雜度是相同的，都是解析一次。因此，從總體上說，本發(fā)明的消息封裝及傳輸方法更加簡單，減輕了服務(wù)器的負(fù)擔(dān)。
本實(shí)施例是使本領(lǐng)域普通技術(shù)人員理解本發(fā)明，而對本發(fā)明所進(jìn)行的詳細(xì)描述，但可以想到，在不脫離本發(fā)明的權(quán)利要求所涵蓋的范圍內(nèi)還可以做出其它的變化和修改，這些變化和修改均在本發(fā)明的保護(hù)范圍內(nèi)。
權(quán)利要求
1.一種在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)，包括服務(wù)器，至少一個發(fā)送方客戶端和至少一個接收方客戶端；發(fā)送方客戶端發(fā)送MSRP源消息，經(jīng)服務(wù)器下發(fā)給接收方客戶端，其特征在于所述服務(wù)器包括解析封裝消息模塊，用于將服務(wù)器收到的MSRP源消息進(jìn)行解析，得到接收方客戶端地址，并根據(jù)接收方客戶端的地址及源消息封裝新的MSRP SEND消息；所述接收方客戶端還包括解析模塊，用于當(dāng)接收方客戶端接收到所述MSRP SEND消息時，對所述消息進(jìn)行解析，并獲取消息的信息。
2.根據(jù)權(quán)利要求1所述的在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)，其特征在于，所述的服務(wù)器還包括存儲模塊，用于存儲發(fā)送方客戶端與服務(wù)器交互的以消息會話中繼協(xié)議承載的消息。
3.根據(jù)權(quán)利要求1或2所述的在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)，其特征在于，所述MSRP源消息包括SIP INVITE消息，MSRP SEND消息。
4.根據(jù)權(quán)利要求3所述的在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)，其特征在于，所述MSRP源消息還包括SIP 200 OK消息和SIP BYE消息。
5.根據(jù)權(quán)利要求3所述的在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)，其特征在于，所述MSRP SEND消息包括消息頭和消息體，所述消息體包括SIP INVITE消息部分和MSRP SEND消息部分。
6.根據(jù)權(quán)利要求4所述的在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)，其特征在于，所述MSRP SEND消息包括消息頭和消息體，所述消息體包括SIP INVITE消息部分、MSRP SEND消息部分、SIP 200 OK消息部分和SIPBYE消息部分。
7.一種在消息會話中繼協(xié)議中封裝消息的服務(wù)器，其特征在于，包括解析封裝消息模塊，用于將服務(wù)器收到的MSRP源消息進(jìn)行解析，得到接收方客戶端地址，并根據(jù)接收方客戶端的地址及源消息封裝新的MSRP SEND消息。
8.根據(jù)權(quán)利要求7所述的在消息會話中繼協(xié)議中封裝消息的服務(wù)器，其特征在于，所述MSRP源消息包括SIP INVITE消息，MSRP SEND消息。
9.根據(jù)權(quán)利要求8所述的在消息會話中繼協(xié)議中封裝消息的服務(wù)器，其特征在于，所述MSRP源消息還包括SIP 200 OK消息和SIP BYE消息。
10.根據(jù)權(quán)利要求8所述的在消息會話中繼協(xié)議中封裝消息的服務(wù)器，其特征在于，所述MSRP SEND消息包括消息頭和消息體，所述消息體包括SIP INVITE消息部分和MSRP SEND消息部分。
11.根據(jù)權(quán)利要求9所述的在消息會話中繼協(xié)議中封裝消息的服務(wù)器，其特征在于，所述MSRP SEND消息包括消息頭和消息體，所述消息體包括SIP INVITE消息部分、MSRP SEND消息部分、SIP 200 OK消息部分和SIPBYE消息部分。
12.一種在消息會話中繼協(xié)議中消息的封裝方法，其特征在于，包括下列步驟步驟A)服務(wù)器讀取MSRP源消息；步驟B)解析所述的MSRP源消息，得到接收方客戶端地址，并利用所述地址和所述源消息封裝新的MSRP SEND消息。
13.根據(jù)權(quán)利要求12所述的在消息會話中繼協(xié)議中消息的封裝方法，其特征在于，所述步驟B)包括下列步驟步驟B1)服務(wù)器解析的MSRP源消息的SIP INVITE消息，獲取該源消息的接收方客戶端的URI地址，然后構(gòu)造新的MSRP SEND消息的消息頭；步驟B2)服務(wù)器以所述MSRP源消息中的SIP INVITE消息封裝新的MSRP SEND消息的SIP INVITE消息部分；步驟B3)服務(wù)器以所述MSRP源消息中的MSRP SEND消息封裝新的NSRP SEND消息中的MSRP SEND消息部分。
14.根據(jù)權(quán)利要求13所述的在消息會話中繼協(xié)議中消息的封裝方法，其特征在于，所述步驟B)還包括下列步驟服務(wù)器以所述MSRP源消息中的SIP 200 OK消息封裝新的MSRP SEND消息中的SIP 200 OK消息部分；服務(wù)器以所述MSRP源消息中的SIP BYE消息封裝新的MSRP SEND消息中的SIP BYE消息部分。
15.根據(jù)權(quán)利要求13所述的在消息會話中繼協(xié)議中消息的封裝方法，其特征在于，所述消息頭包括接收方地址字段，服務(wù)器地址字段，消息體類型字段和分界標(biāo)志符。
16.根據(jù)權(quán)利要求15所述的在消息會話中繼協(xié)議中消息的封裝方法，其特征在于，所述消息頭的消息體類型字段為復(fù)合體消息體。
17.根據(jù)權(quán)利要求13所述的在消息會話中繼協(xié)議中消息的封裝方法，其特征在于，所述封裝的MSRP SEND消息部分中消息體類型為message/msrp。
18.根據(jù)權(quán)利要求14所述的在消息會話中繼協(xié)議中消息的封裝方法，其特征在于所述封裝的SIP INVITE消息部分的消息體類型為message/sip；所述封裝的MSRP SEND消息部分中消息體類型為message/msrp；所述封裝的SIP 200 OK消息部分中消息體類型為message/sip；所述封裝的SIPBYE消息部分中消息體類型為message/sip。
19.根據(jù)權(quán)利要求12至18任一項(xiàng)所述的在消息會話中繼協(xié)議中消息的封裝方法，其特征在于，還包括下列步驟步驟Y)服務(wù)器還讀取服務(wù)器接收到所述MSRP源消息的接收時間；并將所述接收時間封裝到新的MSRP SEND消息的各個消息部分中。
20.根據(jù)權(quán)利要求12所述的在消息會話中繼協(xié)議中消息的封裝方法，其特征在于，所述步驟Y)包括下列步驟將所述接收時間封裝到新的MSRP SEND消息的SIP INVITE消息部分，MSRP SEND消息部分，SIP 200 OK消息部分和SIP BYE消息部分。
21.一種在消息會話中繼協(xié)議中消息的封裝傳輸方法，其特征在于，包括下列步驟步驟A′)服務(wù)器和接收方客戶端建立起MSRP連接；步驟B′)服務(wù)器將利用MSRP源消息解析并得到接收方客戶端地址，根據(jù)接收方客戶端地址和源消息封裝新的MSRP SEND消息；步驟C′)服務(wù)器將所述MSRP SEND消息下發(fā)給接收方客戶端；步驟D′)接收方客戶端解析收到的MSRP SEND消息，將消息的內(nèi)容解析出來。
22.根據(jù)權(quán)利要求21所述的在消息會話中繼協(xié)議中消息的封裝傳輸方法，其特征在于，所述步驟D′)還包括下列步驟步驟D1′)接收方客戶端確認(rèn)收到下發(fā)消息，發(fā)送確認(rèn)消息。
23.根據(jù)權(quán)利要求22所述的在消息會話中繼協(xié)議中消息的封裝傳輸方法，其特征在于，所述步驟D′)包括下列步驟步驟D21′)接收方客戶端收到MSRP消息，判斷出其消息內(nèi)容類型是復(fù)合消息體；步驟D22′)接收方客戶端依次讀取MSRP SEND消息中的各個部分，根據(jù)MSRP SEND消息的消息體中各個部分所示的消息體類型進(jìn)行解析，得到消息內(nèi)容。
24.根據(jù)權(quán)利要求23所述的在消息會話中繼協(xié)議中消息的封裝傳輸方法，其特征在于，所述消息內(nèi)容包括發(fā)送方客戶端的URI地址，接收方客戶端的URI地址信息，發(fā)送內(nèi)容以及消息的發(fā)送時間戳。
25.根據(jù)權(quán)利要求23所述的在消息會話中繼協(xié)議中消息的封裝傳輸方法，其特征在于，所述步驟D22′)包括下列步驟步驟D221′)接收方客戶端解析SIP INVITE消息部分，獲取發(fā)送方客戶端的URI地址和接收方客戶端的URI地址；步驟D222′)接收方客戶端解析MSRP SEND消息部分，獲取消息內(nèi)容以及消息的發(fā)送時間戳。
26.根據(jù)權(quán)利要求25所述的在消息會話中繼協(xié)議中消息的封裝傳輸方法，其特征在于，所述步驟D22′)還包括下列步驟步驟D233′)接收方客戶端還解析MSRP SEND消息的消息體中的SIP200 OK消息部分和SIP BYE消息部分。
27.根據(jù)權(quán)利要求21至26任一項(xiàng)所述的在消息會話中繼協(xié)議中消息的封裝傳輸方法，其特征在于，還包括下列步驟步驟M1′)發(fā)送方客戶端和服務(wù)器協(xié)商建立MSRP會話；步驟M2′)發(fā)送方客戶端將發(fā)送MSRP SEND消息；步驟M3′)服務(wù)器接收到所述MSRP SEND消息。
28.根據(jù)權(quán)利要求27所述的在消息會話中繼協(xié)議中消息的封裝傳輸方法，其特征在于，還包括下列步驟發(fā)送方客戶端斷開和服務(wù)器的MSRP連接。
全文摘要
本發(fā)明公開了一種在消息會話中繼協(xié)議中消息的封裝傳輸系統(tǒng)及方法，其系統(tǒng)包括服務(wù)器，至少一個發(fā)送方客戶端和至少一個接收方客戶端；發(fā)送方客戶端發(fā)送MSRP源消息，經(jīng)服務(wù)器下發(fā)給接收方客戶端。服務(wù)器包括解析封裝消息模塊和存儲模塊；接收方客戶端還包括解析模塊。其封裝方法包括下列步驟步驟A)服務(wù)器讀取MSRP源消息；步驟B)解析服務(wù)器所述的源消息，得到接收方客戶端的URI地址，并利用所述地址和所述源消息封裝新的MSRP消息。本發(fā)明還公開一種MSRP消息的封裝傳輸方法。其實(shí)現(xiàn)了MSRP SEND封裝MSRP消息并傳輸給接收方客戶端的方法，減輕了服務(wù)器的負(fù)載。
文檔編號H04L29/06GK1863176SQ200610058398
公開日2006年11月15日 申請日期2006年3月3日 優(yōu)先權(quán)日2006年3月3日
發(fā)明者牟倫建, 王玨 申請人:華為技術(shù)有限公司