專利名稱：同步源標識符分配方法
技術領域：
本發(fā)明涉及通信和互聯(lián)網(wǎng)領域，尤其涉及一種同步源標識符(synchronization source identifier，簡稱為SSRC)分配方法。
背景技術：
IP多媒體子系統(tǒng)(IP multimedia subsystem，簡稱為IMS)最先在第三代合作伙伴計劃(3rd generation partnership project，簡稱為3GPP)的R5版本中被提出，其目的在于定義一套基于互聯(lián)網(wǎng)工程工作小組(internet engineering task force，簡稱為IETF)會話控制能力、與接入網(wǎng)絡無關、能夠與多媒體承載一起使用分組交換域(packet switch，簡稱為PS域)、且支持互聯(lián)網(wǎng)協(xié)議(Internetprotocol，簡稱為IP)多媒體應用的完全解決方案。
IMS域是特別為實時和非實時的用戶端到端的多媒體業(yè)務所設計的。IMS通過諸如會話協(xié)商和管理、服務質量(quality of service，簡稱為QoS)和移動性管理等的一系列關鍵機制為用戶提供實時的端到端的多媒體業(yè)務(例如，增量的語音和視頻電話)，還可以提供非實時的用戶端到端的多媒體業(yè)務(例如，聊天和即時消息)、多用戶業(yè)務(例如，多媒體會議和聊天室)、用戶端到服務器端業(yè)務(例如，強推廣告業(yè)務(PUSH業(yè)務)和一鍵通(push-to-talk overcellular，簡稱為PoC)業(yè)務)。
會話初始協(xié)議(Session Initiation Protocol，簡稱為SIP)是用于建立更改和終止多媒體會話或呼叫的應用層協(xié)議。SIP協(xié)議可以用于發(fā)起會話，也可以用于邀請成員加入已經(jīng)用其它方式建立的會話。
實時傳輸協(xié)議(Real-time Transport Protocol，簡稱為RTP)是用于互聯(lián)網(wǎng)上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。它是一種提供端對端傳輸服務的實時傳輸協(xié)議，用來支持在單目標廣播和多目標廣播網(wǎng)絡服務中傳輸實時數(shù)據(jù)，而實時數(shù)據(jù)的傳輸則由實時傳輸控制協(xié)議(Real-time Transport Control Protocol，簡稱為RTCP)來監(jiān)視和控制。同時，RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間和實現(xiàn)流同步，通常使用用戶數(shù)據(jù)報協(xié)議(userdatagram protocol，簡稱為UDP)來傳送數(shù)據(jù)，但也可以在傳輸控制協(xié)議(transmission control protocol，簡稱為TCP)或異步傳輸模式(asynchronous transfer mode，簡稱為ATM)等其它協(xié)議之上工作。
當應用程序開始一個RTP會話時將使用兩個端口一個給RTP，另一個給RTCP。RTP本身并不能為按順序傳送的數(shù)據(jù)包提供可靠的傳送機制，并且也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。在RTP會話期間，各參與者周期性地發(fā)送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，服務器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能夠以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。
RTP的消息格式如圖1所示。其中，SSRC標識符是RTP消息的原始發(fā)送端的32位標識符，用于決定消息中序列號和時間戳的值。SSRC標識符是隨機產(chǎn)生的，并且在某個特定的RTP會話中具有全局唯一性。由于這個標識符是隨機產(chǎn)生的，所以有可能幾個發(fā)送端會選擇相同的SSRC標識符，如果多個發(fā)送端同時開始發(fā)送數(shù)據(jù)，則這種沖突產(chǎn)生的幾率會非常高。RTP會話中根據(jù)群組規(guī)模來動態(tài)地計算RTCP數(shù)據(jù)包的發(fā)送間隔，否則會造成網(wǎng)絡擁塞。為了估算群組規(guī)模，每個發(fā)送端都要偵聽組播分組來計算加入成員的數(shù)目，這就需要保證每個成員SSRC的唯一性。
因此，目前還沒有一種能夠避免在RTP中出現(xiàn)SSRC標識符沖突，即，能夠保證SSRC標識符的唯一性的方案。

發(fā)明內(nèi)容
考慮到相關技術中存在的上述問題而做出本發(fā)明，為此，本發(fā)明的主要目的在于提供一種同步源標識符分配方法。
該方法包括步驟S202，第一用戶向其從屬服務器發(fā)送會話初始協(xié)議邀請請求，以請求加入已建立的會話；步驟S204，在第一用戶的從屬服務器不是會話的主控服務器的情況下，從屬服務器將會話初始協(xié)議邀請請求發(fā)送給會話的主控服務器；步驟S206，在需要擴展會話初始協(xié)議的情況下，主控服務器為第一用戶分配同步源標識符；步驟S208，主控服務器將為第一用戶分配的同步源標識符與會話中的其它發(fā)送端的同步源標識符相比較，以判斷同步源標識符是否是唯一的；在判斷結果為是的情況下，主控服務器向第一用戶發(fā)送攜帶有所述同步源標識符的響應消息；以及在判斷結果為否的情況下，主控服務器重新執(zhí)行步驟S208。
其中，在步驟S202和步驟S204之間，進一步包括以下處理判斷從屬服務器是否是會話的主控服務器。
具體地，在會話是由第一用戶建立的會話的情況下，從屬服務器是會話的主控服務器，并且處理進行到步驟S206；在會話不是由第一用戶建立的會話的情況下，從屬服務器不是會話的主控服務器，并且處理進行到步驟S204，其中，在這種情況下，建立會話的用戶的從屬服務器為主控服務器。
此外，在步驟S206中，主控服務器根據(jù)會話初始協(xié)議邀請請求中的消息體中會話描述協(xié)議中的特定字段中的特定值來判斷是否需要擴展會話初始協(xié)議，其中，在特定值為RTP/AVP的情況下，判斷需要擴展會話初始協(xié)議。
此外，在步驟S208之后，該方法進一步包括以下處理第一用戶對響應消息進行解析，獲取同步源標識符；以及第一用戶構造RTP數(shù)據(jù)包，將同步源標識符填入RTP數(shù)據(jù)包頭部的相應字段并發(fā)送，開始多媒體數(shù)據(jù)傳輸。
通過本發(fā)明的技術方案，避免了RTP會話中SSRC標識符的沖突問題，降低了產(chǎn)生回路的概率，從而增加了群組規(guī)模估算的精確度。


此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構成對本發(fā)明的不當限定。在附圖中圖1是示出根據(jù)相關技術的RTP消息格式的示意圖；圖2是示出根據(jù)本發(fā)明實施例的同步源標識符分配方法的流程圖；以及圖3是示出根據(jù)本發(fā)明實施例的同步源標識符分配方法實例的信令流程圖；
圖4是示出根據(jù)本發(fā)明實施例的同步源標識符分配方法實例的詳細處理流程圖。
具體實施例方式
首先需要說明的是，根據(jù)RFC3550中的相關描述，關于同步源標識符(SSRC)的分配都是由每個發(fā)送端采用消息摘要算法5(message-digest algorithm version 5，簡稱為MD5)產(chǎn)生的。在以下提供的本發(fā)明的技術方案中，仍采用MD5算法產(chǎn)生SSRC標識符，但是并不是由每個終端產(chǎn)生而是由一特定服務器通過擴展SIP協(xié)議在整個實時傳輸協(xié)議(RTP)會話過程中進行全局分配。
下面將參照附圖詳細描述本發(fā)明的實施例。
在本發(fā)明實施例中，提供了一種同步源標識符分配的方法；圖2是示出該方法的流程圖。
參照圖2，該方法包括步驟S202，第一用戶(例如，用戶A)向其從屬服務器(例如，從屬服務器A)發(fā)送會話初始協(xié)議邀請(SIP INVITE)請求，以請求加入已建立的會話；步驟S204，在第一用戶的從屬服務器不是會話的主控服務器的情況下，從屬服務器將會話初始協(xié)議邀請請求發(fā)送給會話的主控服務器；步驟S206，在需要擴展會話初始協(xié)議的情況下，主控服務器為第一用戶分配同步源標識符(SSRC)；
步驟S208，主控服務器將為第一用戶分配的同步源標識符與會話中的其它發(fā)送端的同步源標識符相比較，以判斷同步源標識符是否是唯一的；具體而言，在判斷結果為是的情況下，主控服務器向第一用戶發(fā)送攜帶有所述同步源標識符的響應消息(步驟S210)；以及在判斷結果為否的情況下，主控服務器重新執(zhí)行步驟S208。
其中，在步驟S202和步驟S204之間，進一步包括以下處理判斷從屬服務器是否是會話的主控服務器。
具體地，在會話是由第一用戶建立的會話的情況下，從屬服務器是會話的主控服務器，并且處理進行到步驟S206；在會話不是由第一用戶建立的會話的情況下，從屬服務器不是會話的主控服務器，并且處理進行到步驟S204，其中，建立會話的用戶的從屬服務器為主控服務器。
此外，在步驟S206中，主控服務器根據(jù)會話初始協(xié)議邀請請求中的消息體中會話描述協(xié)議中的特定字段中的特定值(例如，字段m中的<transport>的值)來判斷是否需要擴展會話初始協(xié)議，其中，在特定值為RTP/AVP的情況下，判斷需要擴展會話初始協(xié)議。
此外，該方法進一步包括以下處理第一用戶對響應消息進行解析，獲取同步源標識符；以及第一用戶構造RTP數(shù)據(jù)包，將同步源標識符填入RTP數(shù)據(jù)包頭部的相應字段并發(fā)送，開始多媒體數(shù)據(jù)傳輸。
以下將以PoC中聊天組會話的應用為例來描述根據(jù)本發(fā)明實施例的同步源標識符分配的方法，但是本發(fā)明不限于此。其中，圖3示出了該實例的處理的信令流程，圖4示出了該實例的詳細處理流程。
具體而言，圖3中示出了一個用戶加入到聊天組中所進行的處理實例的信令流程圖。如圖3所示，其具體過程如下UE A將SIP INVITE請求發(fā)送給輔助PoC A，聊天組PoC服務器對用戶進行認證，如果用戶通過認證，則將該用戶加入到聊天組中，并將表示加入成功的消息SIP 200 OK返回給UE A；接下來，UE A收到200 OK后，對媒體設備進行初始化，并將SIP ACK請求發(fā)送至輔助PoC，輔助PoC將該請求轉發(fā)給具有聊天組的主控PoC，之后便可以執(zhí)行媒體數(shù)據(jù)包(RTP報文)的傳輸，用戶的加入結束。
在PoC應用中，根據(jù)RTP會話過程中(從會話的建立到終止的整個過程中)服務器所完成的邏輯功能來判斷服務器擔當?shù)氖侵骺胤掌鬟€是輔助服務器。具體地，在組會話的情況下，發(fā)起對用戶邀請的服務器擔當主控服務器的功能，而在聊天組和預定義組會話的情況下，保存有組定義標識的服務器擔當主控服務器。
首先，用戶B建立一個PoC聊天組會話，此時，用戶B的從屬服務服務器B可以是主服務器；然后，用戶A(即，第一用戶)發(fā)送SIP INVITE請求給從屬服務器A，由用戶B的從屬服務器B負責將該SIP INVITE請求轉發(fā)給該會話的主控服務器(或者，從屬服務器B即為主控服務器)。
上述過程可以參照圖4中的步驟S402至S410來理解。
其中，用戶A發(fā)送的SIP INVITE請求為INVITE sipA@ims.zhongxing.chinamobile.com SIP/2.0Via.............
From<sipA@ims.zhongxing.chinamobile.com>；tag＝789To<sipgroupB@ims.zhongxing.chinamobile.com>
Call-ID....
......
m＝audio...RTP/AVP主控服務器根據(jù)SIP INVITE請求中的消息體中的會話描述協(xié)議(session description protocol，簡稱為SDP)中字段m中的<transport>的值來判斷是否需要擴展SIP協(xié)議，如果該值為RTP/AVP，則需要擴展SIP協(xié)議；反之，則不需要進行擴展。(對應于圖4中步驟S412)如果需要擴展SIP協(xié)議，則由主控服務器為用戶A分配一個SSRC，并將其與該會話中其它發(fā)送端的SSRC標識符相比較，判斷是否存在沖突。如果存在沖突，則重新分配一個SSRC，直至SSRC在整個會話中具有全局唯一性。(對應于圖4中的步驟S414)主控服務器將產(chǎn)生的SSRC標識符保存，并與用戶的唯一標識(例如，SIP URL)相關聯(lián)，以便為其它用戶SSRC標識符唯一性的判斷提供依據(jù)。(對應于圖4中的步驟S416)主控服務器對用戶A從屬服務器的SIP INVITE請求發(fā)送200OK的響應，并將為用戶A產(chǎn)生的SSRC標識符附加在200OK的響應消息體中的擴展字段SSRC，并由用戶A的從屬服務器將200OK轉發(fā)給用戶A。(對應于圖4中的步驟S418和S420)其中，200OK響應如下SIP/2.0 200OK
Via.............
From<sipA@ims.zhongxing.chinamobile.com>；tag＝789To<sipgroupB@ims.zhongxing.chinamobile.com>；tag＝123；Contact......
Call-ID......
SSRC......(32位的隨機字符串)然后，用戶A對200OK進行解析，取出SSRC標識符，構造RTP數(shù)據(jù)包，將獲取的SSRC標識符填入RTP數(shù)據(jù)包的頭部相應字段并發(fā)送，開始進行多媒體數(shù)據(jù)傳輸。
在PoC中通過由主控服務器產(chǎn)生SSRC標識符的方式，相比較在發(fā)送端產(chǎn)生該標識符，可以在整個會話過程中對SSRC的產(chǎn)生進行全局的控制，可以有效的避免RTP中存在的沖突和回路問題。(對應于圖4中的步驟S422)綜上所述，通過本發(fā)明的技術方案，避免了RTP會話中SSRC標識的沖突問題，降低了產(chǎn)生回路的概率，從而增加了群組規(guī)模估算的精確度。
以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。
權利要求
1.一種同步源標識符分配方法，其特征在于，包括步驟S202，第一用戶向其從屬服務器發(fā)送會話初始協(xié)議邀請請求，以請求加入已建立的會話；步驟S204，在所述第一用戶的從屬服務器不是所述會話的主控服務器的情況下，所述從屬服務器將所述會話初始協(xié)議邀請請求發(fā)送給所述會話的主控服務器；步驟S206，在需要擴展會話初始協(xié)議的情況下，所述主控服務器為所述第一用戶分配同步源標識符；步驟S208，所述主控服務器將為所述第一用戶分配的同步源標識符與所述會話中的其它發(fā)送端的同步源標識符相比較，以判斷所述同步源標識符是否是唯一的；在判斷結果為是的情況下，所述主控服務器向所述第一用戶發(fā)送攜帶有所述同步源標識符的響應消息；在判斷結果為否的情況下，所述主控服務器重新執(zhí)行所述步驟S208。
2.根據(jù)權利要求1所述的同步源標識符分配方法，其特征在于，在所述步驟S202和所述步驟S204之間，進一步包括以下處理判斷所述從屬服務器是否是所述會話的主控服務器。
3.根據(jù)權利要求2所述的同步源標識符分配方法，其特征在于，在所述會話是由所述第一用戶建立的會話的情況下，所述從屬服務器是所述會話的主控服務器，并且處理進行到步驟S206。
4.根據(jù)權利要求2所述的同步源標識符分配方法，其特征在于，在所述會話不是由所述第一用戶建立的會話的情況下，所述從屬服務器不是所述會話的主控服務器，并且處理進行到所述步驟S204。
5.根據(jù)權利要求4所述的同步源標識符分配方法，其特征在于，建立所述會話的用戶的從屬服務器為所述主控服務器。
6.根據(jù)權利要求1所述的同步源標識符分配方法，其特征在于，在所述步驟S206中，所述主控服務器根據(jù)所述會話初始協(xié)議邀請請求中的消息體中會話描述協(xié)議中的特定字段中的特定值來判斷是否需要擴展所述會話初始協(xié)議。
7.根據(jù)權利要求6所述的同步源標識符分配方法，其特征在于，在所述特定值為RTP/AVP的情況下，判斷需要擴展所述會話初始協(xié)議。
8.根據(jù)權利要求1所述的同步源標識符分配方法，其特征在于，在所述步驟S208之后，進一步包括以下處理所述第一用戶對所述響應消息進行解析，獲取所述同步源標識符；以及所述第一用戶構造實時傳輸協(xié)議數(shù)據(jù)包，將所述同步源標識符填入所述實時傳輸協(xié)議數(shù)據(jù)包頭部的相應字段并發(fā)送，開始多媒體數(shù)據(jù)傳輸。
全文摘要
本發(fā)明提供了一種同步源標識符分配的方法，該方法包括步驟S202，第一用戶向其從屬服務器發(fā)送會話初始協(xié)議邀請請求，以請求加入已建立的會話；步驟S204，在第一用戶的從屬服務器不是會話的主控服務器的情況下，從屬服務器將會話初始協(xié)議邀請請求發(fā)送給會話的主控服務器；步驟S206，在需要擴展會話初始協(xié)議的情況下，主控服務器為第一用戶分配同步源標識符；步驟S208，主控服務器將為第一用戶分配的同步源標識符與會話中的其它發(fā)送端的同步源標識符相比較，以判斷同步源標識符是否是唯一的；在判斷結果為是的情況下，主控服務器向第一用戶發(fā)送攜帶有所述同步源標識符的響應消息；以及在判斷結果為否的情況下，主控服務器重新執(zhí)行步驟S208。
文檔編號H04L12/24GK101052045SQ20071010305
公開日2007年10月10日 申請日期2007年5月16日 優(yōu)先權日2007年5月16日
發(fā)明者張桂蘭 申請人:中興通訊股份有限公司