專利名稱：一種rtsp會話的驗證方法、系統(tǒng)和裝置的制作方法
技術領域：
本發(fā)明涉及通信技術領域，特別是涉及一種RTSP會話的驗證方法、系統(tǒng)
和裝置。
背景技術：
IMS是最初在3GPP R5階段增加的WCDMA網(wǎng)絡中疊加在已有分組域之 上的一個子系統(tǒng)，采用分組域為其上層控制信令和々某體傳輸?shù)某休d通道，引 入SIP協(xié)議作為業(yè)務控制協(xié)議，利用SIP簡單、易擴展、媒體組合方便的特點， 通過將業(yè)務控制與承載控制分離，提供豐富的多媒體業(yè)務，對IMS進行標準 化的國際標準組織主要有3GPP和TISPAN。 3GPP側重于從移動的角度對IMS 進行研究，而TISPAN則側重于從固定的角度對IMS提出需求，并統(tǒng)一由3GPP 完善，最終實現(xiàn)IMS對固定接入和移動接入的統(tǒng)一控制。
IMS based IPTV就是在TISPAN提出的在IMS的整體架構下提供IPTV 業(yè)務，以充分利用IMS網(wǎng)絡中已有的注冊、認證、路由、會話控制與建立、 業(yè)務觸發(fā)、計費、端到端QoS保證等機制來為用戶提供流媒體業(yè)務及融合流 媒體和實時會話業(yè)務的多媒體業(yè)務。
內容點播(COD)業(yè)務就是一種基于IMS的IPTV基本業(yè)務UE與MCF 之間首先創(chuàng)建SIP會話，通過該SIP會話完成對用戶點播權限的鑒定，并建立 起媒體通道；繼而UE使用該媒體通道發(fā)起RTSP消息直接與MCF交互實現(xiàn) 對媒體流的控制(例如播放，暫停，快進或快退等)。因此，COD業(yè)務RTSP 會話的建立之前必須保證UE的對所點播的節(jié)目具有訪問權限，而由上述流程 可發(fā)現(xiàn)，對該權限的鑒定由SIP會話來完成，即為了確保后續(xù)RTSP會話的有 效性，必須建立起RTSP會話與之前SIP會話之間的關聯(lián)關系，從而使得RTSP 會話共享之前會話的鑒權。而目前的COD業(yè)務的建立過程中卻缺乏這種會話 間的關聯(lián)紐帶，此將導致MF側無法識別后續(xù)的媒體控制請求而無法完成業(yè)務。
傳統(tǒng)IPTV也存在類似的問題，其解決方案中的相關流程為傳統(tǒng)IPTV Client端(UE)先通過HTTP在Server端(MF)完成業(yè)務請求及鑒權；后續(xù) 發(fā)起RTSP請求時，攜帶HTTP會話中所獲取的相關信息，完成后續(xù)的媒體通 道建立。
即傳統(tǒng)IPTV本質上通過用戶信息建立起了完成業(yè)務鑒權的HTTP會話與 實現(xiàn)媒體控制的RTSP會話的關聯(lián)。但是，IMS-Based IPTV中通過SIP會話 進行業(yè)務鑒權，故傳統(tǒng)IPTV的解決方案并不能為我們所采用。為保證后續(xù) RTSP媒體控制命令的有效性，需要建立RTSP會話與SIP會話之間的關聯(lián)關 系。

發(fā)明內容
本發(fā)明實施例要解決的問題是提供一種RTSP會話的驗證方法，用于明 確RTSP會話與已有SIP會話的關聯(lián)關系，使得RTSP會話中服務器(如 MF)側確認客戶端(如UE)的訪問權限，從而保證RTSP請求的有效性。
為達到上述目的，本發(fā)明實施例一方面提出一種RTSP會話的驗證方法， 包括以下步驟
接收用戶端發(fā)送的RTSP消息，所述RTSP消息包含當前RTSP會話與已 有SIP會話之間的關聯(lián)標識；
識別所述關聯(lián)標識，判斷所述當前RTSP會話與所述已有SIP會話之間是 否存在關聯(lián)；
當判斷所述當前RTSP會話與所述已有SIP會話之間存在關聯(lián)時，執(zhí)行所 述RTSP消息；或，當判斷所述當前RTSP會話與所述已有SIP會話之間不存 在關聯(lián)時，拒絕所述RTSP消息。
另一方面，本發(fā)明實施例還提出一種RTSP會話的驗證系統(tǒng)，包括終端和 服務器
所述終端，用于向所述服務器發(fā)送包含當前RTSP會話與已有SIP會話之 間的關聯(lián)標識的RTSP消息，請求驗證所述當前RTSP會話與所述已有SIP會話之間的關聯(lián)；
所述服務器，用于獲取所述當前RTSP會話與所述已有SIP會話之間的關 聯(lián)標識并對所述終端進行相應反饋，接收所述終端發(fā)送的所述包含當前RTSP 會話與已有SIP會話之間的關聯(lián)標識的RTSP消息，判斷所述當前RTSP會話 與所述已有SIP會話之間的關聯(lián)。
另一方面，本發(fā)明實施例還提出一種終端，包括 獲取模塊，用于獲取當前RTSP會話與已有SIP會話之間的關聯(lián)標識； 發(fā)送模塊，用于發(fā)送包含所述獲取模塊所獲取的關聯(lián)標識的RTSP消息， 使得服務器端通過識別所述關聯(lián)標識，判斷所述當前RTSP會話與所述已有 SIP會話之間的關聯(lián)。
另一方面，本發(fā)明實施例還提出一種服務器，包括 獲取模塊，用于獲取當前RTSP會話與已有SIP會話之間的關聯(lián)標識； 接收模塊，用于接收所述終端發(fā)送的包含當前RTSP會話與已有SIP會話 之間的關耳關標識的RTSP消息；
判斷模塊，用于根據(jù)所述接收模塊接收的包含當前RTSP會話與已有SIP 會話之間的關聯(lián)標識的RTSP消息，識別所述關聯(lián)標識，并判斷所述當前RTSP 會話與所述已有SIP會話之間的關聯(lián)。
本發(fā)明實施例的技術方案具有以下優(yōu)點，因為采用了消息中攜帶關聯(lián)標 識的方法，從而，明確了 RTSP會話與之前SIP會話的關聯(lián)關系，使得RTSP 會話中々某體服務器側可以確認用戶端的訪問權限，只有具有節(jié)目授權的用戶 才能通過RTSP會話指示々某體服務器對々某體流進行控制，達到了實現(xiàn)對用戶端 點播權限的監(jiān)控，保證RTSP請求的有效性的效果。


圖1為本發(fā)明實施例中一種RTSP會話的驗證方法的流程示意圖； 圖2為本發(fā)明實施例一中一種RTSP會話的驗證方法的流程示意圖； 圖3為本發(fā)明實施例二中一種RTSP會話的驗證方法的流程示意圖； 圖4為本發(fā)明實施例三中一種RTSP會話的驗證方法的流程示意圖；圖5為本發(fā)明實施例四中一種RTSP會話的^r證方法的流程示意圖； 圖6為本發(fā)明實施例五中一種RTSP會話的驗證方法的流程示意圖； 圖7為本發(fā)明實施例六中 一種RTSP會話的驗證系統(tǒng)的結構示意圖。
具體實施例方式
本發(fā)明實施例提供了一種RTSP會話的驗證方法，使用戶端與媒體服務 器在SIP階段獲取關聯(lián)標識，并且終端在后續(xù)的RTSP請求中繼續(xù)攜帶該標識， 從而表明其對前面SIP會話的"繼承"關系，實現(xiàn)兩個會話之間的關聯(lián)。
通過本發(fā)明實施例所提供的技術方案，明確了 RTSP會話與之前SIP會話 的關聯(lián)關系，使得RTSP會話中媒體服務器側確認用戶端的訪問權限，從而保 證RTSP請求的有效性。
如圖l所示，為本發(fā)明實施例一， 一種RTSP會話的驗證方法的流程示意 圖，包括以下步驟
步驟S101、服務器端接收用戶端發(fā)送的RTSP消息。
其中，RTSP消息包含當前RTSP會話與已有SIP會話之間的關聯(lián)標識， 該RTSP會話的關if關標識，具體包括以下兩種情況 (1 )從SIP消息中獲取的參數(shù)信息，具體包括
SIP會話標識、用戶身份信息和節(jié)目標識中的一項或多項。
其中，SIP會話標識可以但不限于Call-ID;
用戶身份信息可以但不限于用戶的IMPU或是終端的IP地址；
節(jié)目標識可以但不限于COD ContentID或是所點播節(jié)目的RTSP URL。
并且，UE發(fā)送SIP消息至媒體服務器側，媒體服務器也將保存上述的參 數(shù)信息用作關聯(lián)標識。
(2)服務器端生成的標識信息。
該標識信息由服務器端通過返回消息發(fā)送給用戶端，具體的發(fā)送方式包 括以下幾種
擴展新的SIP頭域攜帶；或，
由SDP描述中攜帶，以屬性行(a行)攜帶為例，格式可以為a=fintp:rtsph-uri=<request-uri >;其中，request-uri可直接攜帶RTSP URL或是RTSP URL/ SIP-id-關聯(lián)標識；或，
由SDP描述中擴展的參數(shù)攜帶，以a行中新擴展參數(shù)攜帶為例，格式可 以為a-fmtp:SIP-id-〈關聯(lián)標識〉。
需要進一步說明的是，上述的描述格式僅為本發(fā)明的優(yōu)選實施例，在實 際應用過程中可以作出相應的格式調整或參數(shù)名的變化，這樣的變化同樣屬 于本發(fā)明的保護范圍。
用戶端發(fā)送包含關聯(lián)標識的RTSP消息，使得服務器端通過識別關聯(lián)標 識，判斷當前RTSP會話與已有SIP會話之間的關聯(lián)，明確用戶端的訪問權限。
本步驟中的用戶端發(fā)送包含關聯(lián)標識的RTSP消息，具體的，該關聯(lián)標識 通過以下方式進行攜帶
方式一 在RTSP請求的Request URI中攜帶該關聯(lián)標識。
方式二通過RTSP的頭域攜帶該關聯(lián)標識，其中，RTSP的頭域具體包 括RTSP已有的頭域；或，擴展的新的RTSP頭域。
步驟S102、媒體服務器端識別關聯(lián)標識，判斷當前RTSP會話與所述已 有SIP會話之間是否存在關聯(lián)。
具體的，判斷當前RTSP會話與已有SIP會話之間的關聯(lián)，明確用戶端的 訪問^l限的具體過程包括
服務器端識別關聯(lián)標識，判斷關聯(lián)標識與服務器端保存的已有SIP會話 的關聯(lián)標識是否相同，即服務器從用戶端發(fā)送的RTSP消息中解析出其中攜帶 的關聯(lián)標識，并將該標識與服務器端在步驟SIOI中獲取并保存的關聯(lián)標識相 比較，從而判斷用戶端當前請求的RTSP會話與先前的SIP會話之間是否存在 關耳關關系。
當判斷結果為相同時，轉入步驟S103;
當判斷結果為不相同時，轉入步驟S104。
進一步的，對應上述的兩種標識攜帶方式，服務器端通過識別關聯(lián)標識 同樣包括以下兩種情況
即用戶端通過在RTSP請求的Request URI中攜帶關聯(lián)標識時，服務器端解析Request URI,獲取關聯(lián)標識；而用戶端通過RTSP的頭域攜帶關聯(lián)標識 時，服務器端解析RTSP請求消息的頭域，獲取關聯(lián)標識。
步驟S103、判斷所述當前RTSP會話與所述已有SIP會話之間存在關聯(lián)， 4丸行所述RTSP請求。
步驟S104、判斷所述當前RTSP會話與所述已有SIP會話之間不存在關 聯(lián)，拒絕所述RTSP請求。
下面結合附圖和實施例，對本發(fā)明的具體實施方式
作進一步詳細描述 如圖2所示，為本發(fā)明實施例一， 一種RTSP會話的驗證方法的流程示意圖。
在本實施例中，媒體服務器端通過獲取SIP消息中的相關參數(shù)作為關 聯(lián)標識，該標識在RTSP會話中通過Request URI進行攜帶。
本實施例中，為方便描述，媒體服務器端以MF (在實際應用場景中， MF可以為MCF或MDF )為例進行說明。
具體的，該方法包括以下步驟
步驟S201 、 UE發(fā)起SIP INVITE請求會話建立J 某體控制通道。 步驟S202、 MF從SIP會話中獲取Call-ID頭域，保存作為該SIP會話 的標識信息。
需要進一步指出的是，本步驟中獲取的關聯(lián)標識可以為Call-ID頭域、 用戶的身份及節(jié)目標識中的任意一個，或是三者的任意組合。 步驟S203 、 MF對該SIP INVITE請求回復SIP 200 OK。 步驟S204、 UE接收SIP 200 OK。
步驟S205、 UE發(fā)起RTSP DESCRIBE請求網(wǎng)絡側相關參數(shù)，并于 R叫uest URI中攜帶獲取的會話標識信息。 具體的攜帶格式示例如下
DESCRIBE rtsp:〃media. .com:554/twister/audiotrack/&sip—ID= "dcd98b7102dd2，， RTSP/1.0 Accept: application/sdpCseq: 1
需要進一步指出的是，上述的攜帶格式僅是本發(fā)明的一種優(yōu)選實施例， 其中的參數(shù)值或參數(shù)名稱等在實際應用中均可以發(fā)生變化，這樣的變化也 可以達到通過R叫uest URI進行攜帶關聯(lián)標識的效果，這樣的變化同樣屬 于本發(fā)明的保護范圍。
步驟S206、 MF從Request URI解析出UE攜帶的會話標識信息，判 斷該會話標識信息與步驟S202中所保存的SIP會話的標識信息是否相同。
如果相同，則執(zhí)行步驟S207;
如果不相同或沒有攜帶，則MF拒絕請求，返回對應的4** Response,
RTSP DESCRIBE請求所對應的會話終止。
步驟S207、 MF返回RTSP 200 OK及網(wǎng)絡參數(shù)。
步驟S208、 UE根據(jù)接收的網(wǎng)絡參數(shù)與MF建立媒體交付通道。
步驟S209、 UE發(fā)起RTSP SETUP請求，并Request URI中攜帶會話
標識信息。
具體的攜帶格式示例如下
SETUP rtsp:〃media.example.com:554/twister/audiotrack/&sip—ID=
"dcd98b7102dd2" RTSP/1.0
Transport: RTP/AVP;unicast;client_port=4588-4589 Cseq: 2
需要進一步指出的是，上述的攜帶格式僅是本發(fā)明的一種優(yōu)選實施例， 其中的參數(shù)值或參數(shù)名稱等在實際應用中均可以發(fā)生變化，這樣的變化也 可以達到通過Request URI進行攜帶關聯(lián)標識的效果，這樣的變化同樣屬
于本發(fā)明的保護范圍。
步驟S210、 MF從Request URI解析出UE攜帶的標識，判斷該會話 標識信息與步驟S202中所保存的SIP會話的標識信息是否相同。
如果相同，則執(zhí)行步驟S211;
如果不相同或沒有攜帶，則MF拒絕請求，返回對應的4** Response, RTSP DESCRIBE請求所對應的會話終止。步驟S2U、 MF返回RTSP 200 OK及所分配的SessionID。
步驟S212、 UE攜帶SessionID發(fā)起RTSP PLAY,控制節(jié)目進行播放。
步驟S213、 MF返回RTSP 200 OK。
如圖3所示，為本發(fā)明實施例二， 一種RTSP會話的-驗證方法的流程示 意圖。
在本實施例中，媒體服務器端生成SIP會話標識，該標識在RTSP會
話中通過Request URI攜帶。
本實施例中，為方便說明，媒體服務器端以MF為例進行說明。 步驟S301、 UE發(fā)起SIP INVITE請求建立媒體控制通道，SIP路由至
MF處。
步驟S302、 MF4妻收SIP請求后生成該SIP會話的標識信息。
步驟S303、 MF在SIP消息的200 OK回復中采用a行同時攜帶生成 的會話標識與RTSP URL (或僅RTSP URL，由RTSP URL同時充當關聯(lián) 標識)。
具體格式示例如下
v=0
o=- 1357924 1357924 IN IP6 5555::6:7:8:9 s=-
c=IN IP6 5555::6:7:8:9 t,7165275 0
m=application 554 tcp iptv—rtsp a=setup:passive 3=comisction:n6W a=ftmp: iptv一rtsp
h-uri=rtsp:〃media.example.com:554/twister/audiotrack/&sip—ID="dcd98b710 2dd2f0e8blld0f600bfb0c093"
(或
13a=ftmp:iptv—rtsp h-uri=rtsp:〃media.example.com: 5 54/twister/audiotrack) 需要進一步指出的是，上述的攜帶格式僅是本發(fā)明的一種優(yōu)選實施例，
樣的變化也可以達到通過SDP進行攜帶關聯(lián)標識的效果，這樣的變化同樣 屬于本發(fā)明的保護范圍。
步驟S304、 UE接收到SIP 200 OK，獲取其中a行攜帶的SIP會話標 識信息。
步驟S305、 UE發(fā)起RTSP DESCRIBE請求網(wǎng)絡側相關參數(shù)，并于 R叫uestURI中攜帶步驟S304中獲耳又的會話標識信息。 具體格式示例如下
DESCRIBE rtsp:〃media.example.com:554/twister/audiotrack/&sip—ID= "dcd98b7102dd2f0e8b 11 d0f600bfb0c093" RTSP/1.0
(或
DESCRIBE rtsp:〃media.example.com:554/twister/audiotrack RTSP/1.0 ) Accept: application/sdp Cseq: 1
需要進一步指出的是，上述的攜帶格式僅是本發(fā)明的一種優(yōu)選實施例， 其中的參數(shù)值或參數(shù)名稱等在實際應用中均可以發(fā)生變化，這樣的變化也 可以達到通過Request URI進行攜帶關聯(lián)標識的效果，這樣的變化同樣屬 于本發(fā)明的保護范圍。
步驟S306、 MF從Request URI解析出UE攜帶的會話標識信息，判 斷該會話標識信息與步驟S302中所保存的SIP會話的標識信息是否相同。
如果相同，則執(zhí)行步驟S307;
如果不相同或沒有攜帶，則MF拒絕請求，返回對應的4** Response, RTSP DESCRIBE請求所對應的會話終止。
步驟S307、 MF返回RTSP200 OK及網(wǎng)絡參數(shù)。
步驟S308、 UE根據(jù)接收的網(wǎng)絡參數(shù)與MF建立媒體交付通道。
步驟S309、 UE發(fā)起RTSP SETUP請求，并于Request URI中攜帶所獲取的會話標識信息。
具體的攜帶格式示例如下
SE TUP rtsp :〃medi a. example. com: 554/twister/audiotrack/& sip—ID= "dcd98b7102dd2f0e8bl 1 d0f600bfb0c093" RTSP/1.0
(或
SETUP rtsp:〃media.example.com:554/twister/audiotrack RTSP/1.0 ) Transport: RTP/AVP;unicast;client_port=4588-4589 Cseq: 2
需要進一步指出的是，上述的攜帶格式僅是本發(fā)明的一種優(yōu)選實施例， 其中的參數(shù)值或參數(shù)名稱等在實際應用中均可以發(fā)生變化，這樣的變化也 可以達到通過Request URI進行攜帶關聯(lián)標識的效果，這樣的變化同樣屬 于本發(fā)明的保護范圍。
步驟S310、 MF從Request URI解析出UE攜帶的標識，判斷該會話 標識信息與步驟S302中所保存的SIP會話的標識信息是否相同。
如果相同，則執(zhí)行步驟S311;
如果不相同或沒有攜帶，則MF拒絕請求，返回對應的4** Response, RTSP DESCRIBE請求所對應的會話終止。
步驟S311、返回RTSP 200 OK及所分配的SessionID。
步驟S312、 UE攜帶SessionID發(fā)起RTSP PLAY,控制節(jié)目進行播放。
步驟S313、 MF返回RTSP 200 OK。
如圖4所示，為本發(fā)明實施例三， 一種RTSP會話的-驗證方法的流程示 意圖。
在本實施例中，媒體服務器端獲取SIP消息中的相關參數(shù)用作SIP與 RTSP會話的關聯(lián)標識，該標識在RTSP會話中采用專門頭域攜帶，為方便 描述，本實施例以Nonce—ID為例進行說明。
本實施例中，為方便說明，服務器端以MF為例進行說明。 步驟S401 、 UE發(fā)起SIP INVITE請求會話建立々某體控制通道。步驟S402、 MF從SIP會話中獲取Call-ID頭域，保存作為會話的關聯(lián) 標識信息。
需要進一步指出的是，本步驟中獲取的關聯(lián)標識可以為Call-ID頭域、 用戶的身份及節(jié)目標識中的任意一個，或是三者的任意組合。 步驟S403、 MF對該SIP Invite請求回復SIP 200 OK。 步驟S404、 UE接收SIP 200 OK。
步驟S405、UE發(fā)起RTSP DESCRIBE請求網(wǎng)絡側相關參數(shù)，并于RTSP
請求所擴展的頭域(例如以下示例中的Nonce—ID)中攜帶荻取的參數(shù)標識。 具體攜帶格式示例如下
DESCRIBE rtsp:〃media.example.com:554/twister/audiotrack RTSP/1.0 Accept: application/sdp NonceID: "dcd98b7102dd2" Cseq: 1
需要進一步指出的是，上述的攜帶格式僅是本發(fā)明的一種優(yōu)選實施例， 其中的參數(shù)值或參數(shù)名稱等在實際應用中均可以發(fā)生變化，這樣的變化也 可以達到通過頭域攜帶關聯(lián)標識的效果，這樣的變化同樣屬于本發(fā)明的保 護范圍。
步驟S406、 MF解析所接收的RTSP請求，判斷該會話標識信息與步 驟S402中所保存的SIP會話的標識信息是否相同。 如果相同，則執(zhí)行步驟S407;
如果不相同或沒有攜帶，則MF拒絕請求，返回對應的4** Response,
RTSP DESCRIBE請求所對應的會話終止。
步驟S407、 MF返回RTSP 200 OK及網(wǎng)絡參數(shù)。
步驟S408、 UE根據(jù)接收的網(wǎng)絡參數(shù)與MF建立媒體交付通道。
步驟S409、 UE發(fā)起RTSP SETUP請求SessionID，并于RTSP請求中
Nonce—ID頭域攜帶獲取的參數(shù)標識。 具體攜帶格式示例如下
SETUP rtsp:〃media.example.com:554/twister/audiotrack RTSP/1.0Transport: RTP/AVP;unicast;client_port=4588-4589 NonceID: "dcd98b7102dd2" Cseq: 2
需要進一步指出的是，上述的攜帶格式僅是本發(fā)明的一種優(yōu)選實施例， 其中的參數(shù)值或參數(shù)名稱等在實際應用中均可以發(fā)生變化，這樣的變化也 可以達到通過頭域攜帶關聯(lián)標識的效果，這樣的變化同樣屬于本發(fā)明的保 護范圍。
步驟S410、 MF解析所接收的RTSP請求，判斷該會話標識信息與步 驟S402中所保存的SIP會話的標識信息是否相同。 如果相同，則執(zhí)行步驟S411;
如果不相同或沒有攜帶，則MF拒絕請求，返回對應的4** Response, RTSP DESCRIBE請求所對應的會話終止。
步驟S411 、 MF返回RTSP 200 OK及所分配的SessionID。
步驟S412、 UE攜帶SessionID發(fā)起RTSP PLAY,控制節(jié)目進行播放。
步驟S413、 MF返回RTSP 200 OK。
如圖5所示，為本發(fā)明實施例四， 一種RTSP會話的驗證方法的流程示 意圖。
在本實施例中，服務器端生成SIP會話標識，該標識在RTSP會話中 采用專門頭域攜帶，為方便描述，本實施例以Nonce一ID為例進行說明。 本實施例中，為方侵z說明，服務器端以MF為例進行i兌明。 步驟S501、 UE發(fā)起SIP INVITE請求建立媒體控制通道，SIP路由至 MF處。
步驟S502、 MF接收SIP請求后生成對該SIP會話的標識符。 步驟S503、 MF在SIP消息的200 OK回復中采用a行同時攜帶生成 的會話標識與RTSPURL。 具體攜帶格式示例如下
v=0
17o=- 1357924 1357924 IN IP6 5555::6:7:8:9 s=-
c=IN IP6 5555::6:7:8:9 t=907165275 0
m=application 554 tcp iptv—rtsp
a=setup:passive
3=comi6Ction:n6w
a=ftmp:iptv—rtsp h-uri= twister/audiotrack/&sip—ID= "dcd98b7102dd2f0e8b 11 d0f600bfb0c093 "
需要進一步指出的是，該步驟中也可以通過擴展SDP描述中的a行的 參數(shù)來攜帶，例如
a=ftmp:SIP—id =dcd98b7102dd2f0e8b 11 d0f600bfb0c093; 或是通過擴展SIP消息頭來攜帶該標識，例如 SIP-id: dcd98b7102dd2fOe8b 11 d0f600bfb0c093 。
需要進一 步指出的是，以上的給出的攜帶格式僅是本發(fā)明的 一種優(yōu)選 實施例，其中的參數(shù)值或參數(shù)名稱等在實際應用中均可以發(fā)生變化，這樣 的變化也可以達到SDP攜帶關聯(lián)標識的效果，這樣的變化同樣屬于本發(fā)明 的保護范圍。
步驟S504、 UE接收到SIP 200 OK,獲取其中a行攜帶的SIP會話標 識符。
步驟S505 、 UE發(fā)起RTSP DESCRIBE請求網(wǎng)絡側相關參數(shù)，于RTSP 請求的NonceID頭域中攜帶步驟S504中獲取的標識。 具體攜帶格式示例如下
DESCRIBE rtsp:〃media.example.com:554/twister/audiotrack RTSP/1.0 Accept: application/sdp
Nonce—ID: "dcd98b7102dd2f0e8blld0f600bfb0c093" Cseq: 1
步驟S506、 MF解析所接收的RTSP請求，判斷該會話標識信息與步驟S502中所保存的SIP會話的標識信息是否相同。 如果相同，則執(zhí)行步驟S507;
如果不相同或沒有攜帶，則MF拒絕請求，返回對應的4** Response,
RTSP DESCRIBE請求所對應的會話終止。
步驟S507、 MF返回RTSP200 OK及網(wǎng)絡參數(shù)。
步驟S508、 UE根據(jù)接收的網(wǎng)絡參數(shù)與MF建立媒體交付通道。
步驟S509、 UE發(fā)起RTSP SETUP請求，于Nonce—ID頭域中攜帶步
驟S504中獲耳又的標識。
具體攜帶格式示例如下
SETUP rtsp:〃media.example.com:554/twister/audiotrack RTSP/1.0 Transport: RTP/AVP;unicast;client_port=4588-4589 Nonce—ID: "dcd98b7102dd2f0e8b 11 d0f600bfb0c093" Cseq:之
需要進一步指出的是，上述的攜帶格式僅是本發(fā)明的一種優(yōu)選實施例， 其中的參數(shù)值或參數(shù)名稱等在實際應用中均可以發(fā)生變化，這樣的變化也 可以達到通過頭域攜帶關聯(lián)標識的效果，這樣的變化同樣屬于本發(fā)明的保 護范圍。
步驟S510、 MF解析所接收的RTSP請求，判斷該會話標識信息與步 驟S502中所保存的SIP會話的標識信息是否相同。 如果相同，則執(zhí)行步驟S511;
如果不相同或沒有攜帶，則MF拒絕i貪求，返回對應的4** Response, RTSP DESCRIBE請求所對應的會話終止。
步驟S511、 MF返回RTSP 200 OK及所分配的SessionID。
步驟S512、 UE攜帶SessionID發(fā)起RTSP PLAY,控制節(jié)目進行播放。
步驟S513、 MF返回RTSP 200 OK。
如圖6所示，為本發(fā)明實施例五， 一種RTSP會話的-險證方法的流程示 意圖。在本實施例中，服務器端獲取SIP會話的相關參數(shù)作為關聯(lián)標識，該 標識在RTSP的現(xiàn)有頭域中攜帶，為方便描述，本實施例以Autheticate頭 域攜帶為例進行說明。
本實施例中，為方便說明，服務器端以MF為例進行說明。 步驟S601 、 UE通過SIP INVITE請求建立纟某體控制通道。 步驟S602、 UE發(fā)起RTSP DESCRIBE請求網(wǎng)絡參數(shù)。 步驟S603、MF檢查請求中是否攜帶Autheticate消息頭，無則返回401 Unauthorized Response,攜帶WWW-Authenticated消息頭對UE挑戰(zhàn)。
步驟S604、 UE重新生成DESCRIBE請求，并攜帶挑戰(zhàn)響應信息，該 -挑戰(zhàn)響應信息具體為Authorization頭域，在該頭域中包括用作為會話關聯(lián) 標識的UE的地址及點播節(jié)目ID(或是本發(fā)明實施例一種所提及的其他SIP 會話中用作關聯(lián)標識的參數(shù)的組合)。 具體攜帶格式示例如下
DESCRIBE rtsp-url RTSP/1.0 CSeq: 1
Authorization: Digest username="Mufasa",
realm="testrealm@host.com"，
nonce="dcd98b7102dd2f0e8blld0f600bfb0c093"，
uri=7dir/index.html"，
response=" 1:2:3:4:5555 :contentID",
opaque="5ccc069c403ebaf9f0171 e9517f40e41" Accept: application/sdp
需要進一步指出的是，步驟S603也可以為UE發(fā)起RTSP DESCRIBE 請求，其中通過諸如User-Agent等其他頭域攜帶會話標識，此種情況下， 則可能跳過步驟S604。
步驟S605、 MF解析接收的信息，判斷該信息與SIP階段獲取的信息 是否相同。
如果相同，則返回RTSP200 OK，同時攜帶UE側所需的相關網(wǎng)絡參
20數(shù)信息；
如果不相同或沒有攜帶，則MF拒絕請求，返回對應的4** Response, RTSP DESCRIBE i青求所對應的會話終止。 步驟S606、建立媒體交付通道。
步驟S607、 UE發(fā)起RTSP SETUP請求SessionID，其中可以繼續(xù)攜帶 前次的Authorization頭域，或通過User-agent頭域攜帶關聯(lián)標識。 具體攜帶格式示例如下 SETUP rtsp-url RTSP/1.0 CSeq: 2
Authorization: Digest username="Mufasa"，
realm="testrealm@host.com",
nonce="dcd98b7102dd2f0e8b 11 d0f600bfb0c093",
uri="/dir/index.html"，
response=" 1:2:3:4:5555 :contentID",
opaque="5ccc069c403ebaf9f0171 e9517f40e41" Transport: RTP/AVP;unicast;client_port=4588-4589 步驟S608 步驟S610、 MF解析接收的消息，并決定是否重新發(fā)起挑戰(zhàn)。
若需要重新挑戰(zhàn)，則執(zhí)行步驟S608,步驟S609,然后核對步驟S610 中接收的響應信息，返回200 OK及SessionID或相應的錯誤應答；
否則，則直接執(zhí)行步驟S610,即判斷所接收消息中的響應信息是否能 通過鑒權，并返回相應的回復消息。
步驟S611、 UE攜帶接收的SessionID發(fā)起RTSP PLAY,控制節(jié)目播放。
步驟S612、 MF返回RTSP200 OK。
需要進一步指出的是，上述的攜帶格式示例僅是本發(fā)明的一種優(yōu)選實 施例，其中的參數(shù)值或參數(shù)名稱等在實際應用中均可以發(fā)生變化，以此， 基于本發(fā)明技術思想所做出的變化同樣屬于本發(fā)明的保護范圍。如圖7所示，為本發(fā)明實施例六， 一種RTSP會話的驗證系統(tǒng)的結構示 意圖，包括終端1和服務器2:
終端1 ，用于向服務器2發(fā)送包含當前RTSP會話與已有SIP會話之間的 關聯(lián)標識的RTSP消息，請求驗證當前RTSP會話與已有SIP會話之間的關聯(lián)， 包括
獲取模塊11,用于獲取當前RTSP會話與已有SIP會話之間的關聯(lián)標識； 發(fā)送模塊12,用于發(fā)送包含獲取模塊11所獲取的關聯(lián)標識的RTSP消息，
使得服務器2通過識別關聯(lián)標識，判斷當前RTSP會話與已有SIP會話之間的
關聯(lián)；
接收模塊13,用于接收服務器2發(fā)送的包含當前RTSP會話與已有SIP 會話之間的關聯(lián)標識的消息。
需要進一步指出的是，根據(jù)實際應用的變化，接收模塊13并非為終端1 的必選模塊，即，如果關聯(lián)標識為服務器2所生成時，需要服務器2將關聯(lián) 標識發(fā)送給終端1，則終端1需要設置接收模塊13,以接收該關聯(lián)標識，而 如果關聯(lián)標識為從SIP消息中獲取的參數(shù)時，則終端1中已保存有該關聯(lián)標 識，則無需服務器2進行發(fā)送，此時，終端1中不包含接收模塊13,綜上所 述，終端1中的接收模塊13為可選模塊，是否含有該模塊并不影響本發(fā)明的 保護范圍。
服務器2,用于生成當前RTSP會話與已有SIP會話之間的關聯(lián)標識并發(fā) 送給終端1 ，接收終端1發(fā)送的包含當前RTSP會話與已有SIP會話之間的關 聯(lián)標識的RTSP消息，判斷當前RTSP會話與已有SIP會話之間的關聯(lián)，包括
獲取模塊21,用于生成當前RTSP會話與已有SIP會話之間的關聯(lián)標識， 具體包括
信息獲取子模塊211,用于通過SIP消息獲取的已有SIP會話的參數(shù)信息， 作為當前RTSP會話與已有SIP會話之間的關聯(lián)標識。
信息生成子模塊212，用于生成的已有SIP會話的參數(shù)信息，作為當前 RTSP會話與已有SIP會話之間的關聯(lián)標識。
22發(fā)送子模塊213,用于通過消息，將信息生成子模塊212生成的關聯(lián)標識 發(fā)送給終端；
信息保存子模塊214，用于保存信息獲取子模塊211或信息生成子模塊 212生成的關4關標識。
需要進一步指出的是，上述的信息獲取子模塊211和信息生成子模塊212, 發(fā)送子模塊213在實際應用中，獲取模塊21可以包含其中的一個或多個，這 主要由具體的關聯(lián)標識生成方式?jīng)Q定，這樣的變化并不影響本發(fā)明的保護范 圍。
另外，根據(jù)實際應用的變化，發(fā)送子模塊213并非為服務器2的必選模 塊，而是與信息生成子模塊212匹配出現(xiàn)，即，如果關聯(lián)標識為服務器2所 生成時，需要服務器2將關聯(lián)標識發(fā)送給終端1,則服務器2需要設置發(fā)送子 模塊213，以發(fā)送該關聯(lián)標識，而如果關聯(lián)標識為從SIP消息中獲取的參數(shù)時， 則終端1中已保存有該關聯(lián)標識，則無需服務器2進行發(fā)送，此時，服務器2 中不包含發(fā)送子模塊213，綜上所述，服務器2中的發(fā)送子模塊213為可選模 塊，是否含有該模塊并不影響本發(fā)明的保護范圍
接收模塊22，用于接收終端1發(fā)送的包含當前RTSP會話與已有SIP會 話之間的關聯(lián)標識的RTSP消息；
判斷模塊23,用于根據(jù)接收模塊22接收的包含當前RTSP會話與已有SIP 會話之間的關聯(lián)標識的RTSP消息，識別關聯(lián)標識，并判斷當前RTSP會話與 已有SIP會話之間的關聯(lián)，具體包括
識別子模塊231,用于根據(jù)接收模塊22接收的包含當前RTSP會話與已 有SIP會話之間的關聯(lián)標識的RTSP消息，識別關聯(lián)標識；
匹配子模塊232,用于將識別子模塊231所識別的關聯(lián)標識與保存的已有 SIP會話的關聯(lián)標識進行匹配，判斷當前RTSP會話與已有SIP會話之間的關 聯(lián)。
反饋子模塊233,用于根據(jù)匹配子模塊232的匹配結果，對終端進行反饋。 本發(fā)明實施例的技術方案具有以下優(yōu)點，因為采用了消息中攜帶關聯(lián)標 識的方法，從而，明確了 RTSP會話與之前SIP會話的關聯(lián)關系，使得RTSP會話中媒體服務器側可以確認用戶的訪問權限，從而保證只有具有節(jié)目授權
的用戶才能通過RTSP會話指示MF對i某體流進行控制，達到了實現(xiàn)對用戶側 點播權限的監(jiān)控，保證RTSP請求的有效性的效果。
通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到本 發(fā)明可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當然也可以通過硬 件，但很多情況下前者是更佳的實施方式?；谶@樣的理解，本發(fā)明的技 術方案本質上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產品的形式體
現(xiàn)出來，該計算機軟件產品存儲在一個存儲介質中，包括若干指令用以使 得一臺終端設備(可以是手機，個人計算機，服務器，或者網(wǎng)絡設備等) 執(zhí)行本發(fā)明各個實施例所述的方法。
以上所述僅是本發(fā)明的優(yōu)選實施方式，應當指出，對于本技術領域的 普通技術人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進 和潤飾，這些改進和潤飾也應視為本發(fā)明的保護范圍。
權利要求
1、一種實時流協(xié)議RTSP會話的驗證方法，其特征在于，包括以下步驟接收用戶端發(fā)送的RTSP消息，所述RTSP消息包含當前RTSP會話與已有SIP會話之間的關聯(lián)標識；識別所述關聯(lián)標識，判斷所述當前RTSP會話與所述已有SIP會話之間是否存在關聯(lián)；當判斷所述當前RTSP會話與所述已有SIP會話之間存在關聯(lián)時，執(zhí)行所述RTSP消息；或，當判斷所述當前RTSP會話與所述已有SIP會話之間不存在關聯(lián)時，拒絕所述RTSP消息。
2、 如權利要求1所述RTSP會話的驗證方法，其特征在于，所述接收用 戶端發(fā)送的RTSP消息之前，還包括獲取與已有SIP會話之間的關聯(lián)標識，具 體為通過SIP消息獲取所述已有SIP會話的參數(shù)信息作為所述關聯(lián)標識；或， 生成所述已有SIP會話的標識信息作為所述關聯(lián)標識。
3、 如權利要求2所述RTSP會話的驗證方法，其特征在于，所述通過SIP 消息獲取所述已有SIP會話的參數(shù)信息，具體包括SIP會話標識、用戶身f分信息和內容標識中的 一項或多項。
4、 如權利要求2所述RTSP會話的驗證方法，其特征在于，當所述生成 已有SIP會話的標識信息作為所述關聯(lián)標識時，通過以下方式中的一種將所 述關聯(lián)標識發(fā)送給所述用戶端，具體包括由SIP頭域攜帶；或， 由會話描述協(xié)議SDP中攜帶。
5、 如權利要求1所述RTSP會話的驗證方法，其特征在于，所述接收用 戶端發(fā)送的RTSP消息中的所述關聯(lián)標識具體通過以下方式進行攜帶在RTSP請求的Request URI中攜帶所述關耳關標識；或， 通過RTSP的頭域攜帶所述關聯(lián)標識。
6、 如權利要求5所述RTSP會話的-3h正方法，其特征在于，所述服務器 端識別所述關聯(lián)標識，具體為所述服務器端解析所述Request URI，或RTSP請求消息的頭域，獲取所 述關聯(lián)標識；判斷所述關聯(lián)標識與保存的已有SIP會話的關聯(lián)標識是否相同； 當所述判斷結果為相同時，判斷所述當前RTSP會話與所述已有SIP會話之間存在關聯(lián)，當所述判斷結果為不相同時，判斷所述當前RTSP會話與所述已有SIP會話之間不存在關聯(lián)。
7、 一種RTSP會話的驗證系統(tǒng)，其特征在于，包括終端和服務器 所述終端，用于向所述服務器發(fā)送包含當前RTSP會話與已有SIP會話之間的關聯(lián)標識的RTSP消息，請求驗證所述當前RTSP會話與所述已有SIP會 話之間的關聯(lián)；所述服務器，用于獲取所述當前RTSP會話與所述已有SIP會話之間的關 聯(lián)標識并對所述終端進行相應反饋，接收所述終端發(fā)送的所述包含當前RTSP 會話與已有SIP會話之間的關聯(lián)標識的RTSP消息，判斷所述當前RTSP會話 與所述已有SIP會話之間的關聯(lián)。
8、 如權利要求7所述RTSP會話的驗證系統(tǒng)，其特征在于，所述終端， 包括獲取模塊，用于獲取當前RTSP會話與已有SIP會話之間的關聯(lián)標識； 發(fā)送模塊，用于發(fā)送包含所述獲取模塊所獲取的關聯(lián)標識的RTSP消息，使得服務器端通過識別所述關聯(lián)標識，判斷所述當前RTSP會話與所述已有SIP會話之間的關聯(lián)。
9、 如權利要求7所述RTSP會話的驗證系統(tǒng)，其特征在于，所述服務器， 包括獲取模塊，用于獲取當前RTSP會話與已有SIP會話之間的關聯(lián)標識； 接收模塊，用于接收所述終端發(fā)送的包含當前RTSP會話與已有SIP會話之間的關聯(lián)標識的RTSP消息；判斷模塊，用于根據(jù)所述接收模塊接收的包含當前RTSP會話與已有SIP會話之間的關聯(lián)標識的RTSP消息，識別所述關聯(lián)標識，并判斷所述當前RTSP會話與所述已有SIP會話之間的關聯(lián)。
10、 一種終端，其特征在于，包括獲取#莫塊，用于獲取當前RTSP會話與已有SIP會話之間的關聯(lián)標識； 發(fā)送模塊，用于發(fā)送包含所述獲取模塊所獲取的關聯(lián)標識的RTSP消息，使得服務器端通過識別所述關聯(lián)標識，判斷所述當前RTSP會話與所述已有SIP會話之間的關聯(lián)。
11、 如權利要求10所述終端，其特征在于，還包括接收模塊，用于接收所述服務器端發(fā)送的包含當前RTSP會話與已有SIP 會話之間的關聯(lián)標識的消息。
12、 一種服務器，其特征在于，包括獲取模塊，用于獲取當前RTSP會話與已有SIP會話之間的關聯(lián)標識； 接收模塊，用于接收所述終端發(fā)送的包含當前RTSP會話與已有SIP會話之間的關聯(lián)標識的RTSP消息；判斷模塊，用于根據(jù)所述接收模塊接收的包含當前RTSP會話與已有SIP會話之間的關聯(lián)標識的RTSP消息，識別所述關聯(lián)標識，并判斷所述當前RTSP會話與所述已有SIP會話之間的關聯(lián)。
13、 如權利要求12所述服務器，其特征在于，所述獲^Mt塊，具體包括 信息獲取子模塊，用于通過SIP消息獲取的所述已有SIP會話的參數(shù)信息，作為所述當前RTSP會話與已有SIP會話之間的關聯(lián)標識。
14、 如權利要求12所述服務器，其特征在于，所述獲^^莫塊，具體包括 信息生成子模塊，用于生成的所述已有SIP會話的參數(shù)信息，作為所述當前RTSP會話與已有SIP會話之間的關聯(lián)標識；發(fā)送子模塊，用于通過消息，將所述信息生成子模塊生成的關聯(lián)標識發(fā) 送給終端。
15、 如權利要求13或14所述服務器，其特征在于，所述獲取模塊，還 包括信息保存子模塊，用于保存所述信息獲取子模塊或信息生成子模塊生成 的所述關聯(lián)標識。
16、如權利要求12所述服務器，其特征在于，所述判斷模塊，具體包括 識別子模塊，用于根據(jù)所述接收模塊接收的包含當前RTSP會話與已有SIP會話之間的關聯(lián)標識的RTSP消息，識別所述關聯(lián)標識；匹配子模塊，用于將所述識別子模塊所識別的關聯(lián)標識與保存的已有SIP會話的關聯(lián)標識進行匹配，判斷所述當前RTSP會話與所述已有SIP會話之間的關聯(lián)；反饋子模塊，用于根據(jù)所述匹配子模塊的匹配結果，對所述終端進行反饋。
全文摘要
本發(fā)明實施例公開了一種RTSP會話的驗證方法、系統(tǒng)和裝置。所述方法包括接收用戶端發(fā)送的RTSP消息，所述RTSP消息包含當前RTSP會話與已有SIP會話之間的關聯(lián)標識；識別所述關聯(lián)標識，判斷所述當前RTSP會話與所述已有SIP會話之間是否存在關聯(lián)；當判斷所述當前RTSP會話與所述已有SIP會話之間存在關聯(lián)時，執(zhí)行所述RTSP消息；或，當判斷所述當前RTSP會話與所述已有SIP會話之間不存在關聯(lián)時，拒絕所述RTSP消息。從而，明確了RTSP會話與之前SIP會話的關聯(lián)關系，使RTSP會話中媒體服務器(如MF)側可以確認用戶端的訪問權限，實現(xiàn)了對用戶側點播權限的監(jiān)控，保證了RTSP請求的有效性。
文檔編號H04L29/06GK101605124SQ200810111150
公開日2009年12月16日 申請日期2008年6月10日 優(yōu)先權日2008年6月10日
發(fā)明者和曉艷, 豐 王, 黃靈芝 申請人:華為技術有限公司