專利名稱：一種動態(tài)轉(zhuǎn)發(fā)媒體源的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及多媒體技術(shù)領(lǐng)域，具體涉及一種根據(jù)客戶端請求實現(xiàn)流媒體數(shù)據(jù)動態(tài)Relay(轉(zhuǎn)發(fā))的方法。
背景技術(shù)：
隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，一種新的媒體技術(shù)應(yīng)運(yùn)而生，這就是流媒體技術(shù)。流媒體是指在網(wǎng)絡(luò)中使用流式傳輸技術(shù)的連續(xù)時基媒體，如音頻、視頻或多媒體文件。流服務(wù)可以給用戶提供持續(xù)不斷的音頻、視頻流，滿足用戶在線觀看動態(tài)影音的需求，流媒體技術(shù)在媒體點播領(lǐng)域和媒體直播領(lǐng)域得到極大的應(yīng)用。此類流媒體系統(tǒng)通常采用C/S(客戶端/服務(wù)器)架構(gòu)，作為流服務(wù)的提供者，流媒體服務(wù)器是系統(tǒng)的應(yīng)用瓶頸。為緩解流媒體服務(wù)器的壓力，在流媒體系統(tǒng)引入Relay(轉(zhuǎn)發(fā))服務(wù)器來分擔(dān)流媒體服務(wù)器的負(fù)載，轉(zhuǎn)發(fā)服務(wù)器緩存流媒體服務(wù)器上的流媒體數(shù)據(jù)，這樣一部分用戶可以通過訪問轉(zhuǎn)發(fā)服務(wù)器來訪問流媒體服務(wù)器的數(shù)據(jù)。
目前轉(zhuǎn)發(fā)服務(wù)器通常采用一種靜態(tài)轉(zhuǎn)發(fā)的過程，在轉(zhuǎn)發(fā)服務(wù)之前，由轉(zhuǎn)發(fā)服務(wù)器向媒體源建立媒體流連接，并在轉(zhuǎn)發(fā)服務(wù)器保存媒體源參數(shù)文件(通常是*.SDP文件，遵循SDP(會話描述協(xié)議)協(xié)議)，流媒體客戶端通過訪問轉(zhuǎn)發(fā)服務(wù)器的參數(shù)配置文件，通過RTSP(實時流協(xié)議)/SDP/RTP(實時傳輸協(xié)議)/RTCP(實時傳輸控制協(xié)議)協(xié)議獲取媒體源的媒體數(shù)據(jù)。然而，這種轉(zhuǎn)發(fā)方法存在如下缺點當(dāng)媒體源處于私網(wǎng)時，媒體源作為流媒體服務(wù)器，轉(zhuǎn)發(fā)服務(wù)器要取得媒體數(shù)據(jù)并將其轉(zhuǎn)發(fā)到公網(wǎng)的客戶端，無法實現(xiàn)。

發(fā)明內(nèi)容
本發(fā)明所要解決的問題是提供一種根據(jù)客戶端請求動態(tài)轉(zhuǎn)發(fā)媒體源的方法，以實現(xiàn)轉(zhuǎn)發(fā)服務(wù)器對媒體源數(shù)據(jù)的取得及動態(tài)轉(zhuǎn)發(fā)，并節(jié)約網(wǎng)絡(luò)帶寬。
本發(fā)明具體是這樣實現(xiàn)的一種動態(tài)轉(zhuǎn)發(fā)媒體源的方法，進(jìn)行如下處理將轉(zhuǎn)發(fā)服務(wù)器作為媒體流請求端，將媒體源作為媒體流提供端；所述媒體源主動連接轉(zhuǎn)發(fā)服務(wù)器，發(fā)送媒體流的媒體源參數(shù)文件到轉(zhuǎn)發(fā)服務(wù)器，并與轉(zhuǎn)發(fā)服務(wù)器協(xié)商媒體流的傳輸方式；所述轉(zhuǎn)發(fā)服務(wù)器維護(hù)媒體源參數(shù)文件并與媒體源建立流服務(wù)會話；轉(zhuǎn)發(fā)服務(wù)器接收到客戶端的流服務(wù)請求時，通知媒體源開始發(fā)送媒體流，接收媒體源的媒體流，緩沖并轉(zhuǎn)發(fā)給客戶端。
優(yōu)選地，所述轉(zhuǎn)發(fā)服務(wù)器維護(hù)媒體源參數(shù)文件并與媒體源建立流媒體會話，包括如下步驟轉(zhuǎn)發(fā)服務(wù)器保存媒體源發(fā)送的媒體源參數(shù)文件并反饋應(yīng)答響應(yīng)至媒體源；媒體源接受轉(zhuǎn)發(fā)服務(wù)器返回的應(yīng)答響應(yīng)后，與轉(zhuǎn)發(fā)服務(wù)器建立流媒體會話，并保持該會話且不推送媒體流。
優(yōu)選地，所述轉(zhuǎn)發(fā)服務(wù)器保存媒體源參數(shù)文件時，進(jìn)行如下處理將媒體源參數(shù)文件保存在轉(zhuǎn)發(fā)服務(wù)器本地文件中；或替換地，進(jìn)行如下處理將媒體源參數(shù)文件保存在轉(zhuǎn)發(fā)服務(wù)器內(nèi)存中。
優(yōu)選地，所述轉(zhuǎn)發(fā)服務(wù)器與媒體源建立流媒體會話后，為了維護(hù)其與轉(zhuǎn)發(fā)服務(wù)器兩者之間的媒體通道，媒體源定時向轉(zhuǎn)發(fā)服務(wù)器發(fā)送握手消息。
優(yōu)選地，所述轉(zhuǎn)發(fā)服務(wù)器在收到客戶端的流服務(wù)請求后，進(jìn)行如下處理轉(zhuǎn)發(fā)服務(wù)器查詢與請求所對應(yīng)的媒體源的連接狀況，如果連接沒有建立，則轉(zhuǎn)發(fā)服務(wù)器拒絕客戶端的流服務(wù)請求；如果連接建立，則將轉(zhuǎn)發(fā)服務(wù)器與媒體源會話的媒體源參數(shù)文件發(fā)送給客戶端；客戶端接受媒體源參數(shù)文件，并與轉(zhuǎn)發(fā)服務(wù)器之間建立流媒體會話。
優(yōu)選地，在客戶端與轉(zhuǎn)發(fā)服務(wù)器之間建立流媒體會話后，轉(zhuǎn)發(fā)服務(wù)器緩沖媒體源的媒體流并轉(zhuǎn)發(fā)給客戶端前，包括轉(zhuǎn)發(fā)服務(wù)器確認(rèn)媒體源是否已經(jīng)發(fā)送媒體流的步驟。
在多媒體網(wǎng)絡(luò)中，本發(fā)明提出的一種動態(tài)轉(zhuǎn)發(fā)媒體源的方法，一方面，采用媒體源主動向轉(zhuǎn)發(fā)服務(wù)器建立連接，保證了位于公私網(wǎng)內(nèi)的媒體源能夠?qū)崿F(xiàn)轉(zhuǎn)發(fā)；另一方面，轉(zhuǎn)發(fā)服務(wù)器和媒體源之間的服務(wù)會話建立后并不立即緩存數(shù)據(jù)，而是等到客戶端開始發(fā)送請求后，才通知媒體源開始發(fā)送媒體流，轉(zhuǎn)發(fā)到客戶端，從而實現(xiàn)動態(tài)轉(zhuǎn)發(fā)，節(jié)省網(wǎng)絡(luò)帶寬。


圖1是本發(fā)明中媒體源動態(tài)轉(zhuǎn)發(fā)的應(yīng)用環(huán)境部署圖；圖2是本發(fā)明中動態(tài)轉(zhuǎn)發(fā)媒體源的流程圖。
本發(fā)明中涉及的英文術(shù)語及縮寫對應(yīng)的中文如下

具體實施方式
下面結(jié)合附圖對本發(fā)明的具體實施方式
進(jìn)行詳細(xì)說明。
如圖1所示的具體實施環(huán)境中，一個或多個轉(zhuǎn)發(fā)服務(wù)器通過移動網(wǎng)絡(luò)或固定網(wǎng)絡(luò)與編碼器相連，一個或多個轉(zhuǎn)發(fā)服務(wù)的客戶端，例如移動終端或固定終端，通過移動網(wǎng)絡(luò)或固定網(wǎng)絡(luò)與轉(zhuǎn)發(fā)服務(wù)器相連。
所述編碼器可以是編碼硬件設(shè)備或編碼軟件程序，采集各種數(shù)字或模擬音頻數(shù)據(jù)和視頻數(shù)據(jù)，實時壓縮編碼成符合ISO和ITU等標(biāo)準(zhǔn)的音頻和視頻，并以流媒體的方式進(jìn)行Intranet和Internet傳播等功能，部署在私網(wǎng)或公網(wǎng)中，由RGM(注冊服務(wù)器模塊)統(tǒng)一管理。在本發(fā)明中，此編碼器即視為媒體流提供端的媒體源。所述轉(zhuǎn)發(fā)服務(wù)器能夠被外網(wǎng)或者內(nèi)網(wǎng)訪問，轉(zhuǎn)發(fā)服務(wù)器能夠根據(jù)客戶端(比如圖1中所示固定或移動監(jiān)控終端)的流服務(wù)請求，把編碼器的媒體流傳送給客戶端。
位于私網(wǎng)內(nèi)的媒體源，在作為流媒體服務(wù)器的被動模式下，轉(zhuǎn)發(fā)服務(wù)器無法取得媒體數(shù)據(jù)并將其轉(zhuǎn)發(fā)到公網(wǎng)的客戶端。
因此，為實現(xiàn)對私網(wǎng)的穿越，本發(fā)明一種動態(tài)轉(zhuǎn)發(fā)媒體源的方法中，由作為媒體流提供端的媒體源主動連接作為媒體流請求端的轉(zhuǎn)發(fā)服務(wù)器，發(fā)送媒體流的媒體源參數(shù)文件到轉(zhuǎn)發(fā)服務(wù)器，并和轉(zhuǎn)發(fā)服務(wù)器協(xié)商媒體流的傳輸方式，然后轉(zhuǎn)發(fā)服務(wù)器維護(hù)媒體源參數(shù)文件并與媒體源建立流媒體會話，當(dāng)轉(zhuǎn)發(fā)服務(wù)器接收到客戶端的流服務(wù)請求時，通知媒體源開始發(fā)送媒體流，接收媒體源的媒體流，緩沖并轉(zhuǎn)發(fā)給客戶端。當(dāng)然，在媒體源處于公網(wǎng)時，本發(fā)明動態(tài)轉(zhuǎn)發(fā)媒體源的方法亦能很好適用。
在轉(zhuǎn)發(fā)服務(wù)器維護(hù)媒體源參數(shù)文件并與媒體源建立流媒體會話后，媒體源并不直接將媒體流緩存至轉(zhuǎn)發(fā)服務(wù)器，而是待客戶端發(fā)送流服務(wù)請求至轉(zhuǎn)發(fā)服務(wù)器時，才開始緩存媒體流，從而實現(xiàn)動態(tài)轉(zhuǎn)發(fā)，節(jié)省網(wǎng)絡(luò)帶寬。
在本發(fā)明一優(yōu)選實施例中，固定終端可通過轉(zhuǎn)發(fā)服務(wù)器請求移動網(wǎng)絡(luò)側(cè)，私網(wǎng)內(nèi)的媒體源，且與轉(zhuǎn)發(fā)服務(wù)器之間的媒體流通過UDP傳輸(普通的RTSP流)，在移動網(wǎng)絡(luò)側(cè)的編碼器與轉(zhuǎn)發(fā)服務(wù)器之間的媒體流通過TCP傳輸(遵循RTSP協(xié)議，即RTP/RTCP over TCP方式)。當(dāng)然，優(yōu)選實施例中的UDP或TCP傳輸方式，僅為利于后續(xù)描述，在不背離本發(fā)明精神及其實質(zhì)的情況下，其他傳輸方式亦可采用，以實現(xiàn)媒體源與轉(zhuǎn)發(fā)服務(wù)器、轉(zhuǎn)發(fā)服務(wù)器與客戶端之間的媒體流傳輸。
如圖2所示，是本發(fā)明所述方法的具體實施例的一個應(yīng)用實例——監(jiān)控業(yè)務(wù)中基于RTSP協(xié)議的實時碼流服務(wù)，其具體步驟如下步驟201，編碼器首先與轉(zhuǎn)發(fā)服務(wù)器協(xié)商建立TCP連接。建立的方法是編碼器通過RTSP Announce(實時流協(xié)議應(yīng)答)方法向轉(zhuǎn)發(fā)服務(wù)器發(fā)起請求，請求的內(nèi)容為對應(yīng)流的SDP內(nèi)容(具體可參見RTSP協(xié)議RFC2326，在此不再贅言)，即編碼器對應(yīng)媒體流的媒體描述信息。本實施中流請求為ANNOUNCErtsp://<RelaySvr ip>/<codec guid>.sdp；Method＝TCP；<Codec IP>；<rtsp port>；Resolution＝CIF；...其中<RelaySvr ip>為轉(zhuǎn)發(fā)服務(wù)器的IP地址，<codec guid>為編碼器的唯一性標(biāo)記，Method＝TCP指定轉(zhuǎn)發(fā)服務(wù)器與媒體源(編碼器)間通過RTP/RTCP over TCP方式傳輸數(shù)據(jù)，<Code IP>為編碼器的IP地址，<rtspport>為編碼器提供的rtsp服務(wù)端口，Resolution＝CIF指定請求流為CIF流。
步驟202，轉(zhuǎn)發(fā)服務(wù)器維護(hù)與編碼器交互的SDP信息，同時返回給編碼器一個應(yīng)答響應(yīng)，編碼器收到轉(zhuǎn)發(fā)服務(wù)器返回的ANNOUNCE成功應(yīng)答后，遵循RTSP標(biāo)準(zhǔn)協(xié)議要求，相繼通過RTSP Setup、RTSP Record方法與Relay服務(wù)器建立RTSP/RTP/RTCP流媒體會話，保持該會話但是編碼器不推送數(shù)據(jù)。
步驟203，流媒體會話建立完成后，編碼器定時通過RTSP OPTIONS方法向轉(zhuǎn)發(fā)服務(wù)器發(fā)送握手信息，通過判斷轉(zhuǎn)發(fā)服務(wù)器的返回值來保持TCP連接的暢通。
步驟204，監(jiān)控終端(即客戶端)通過RTSP協(xié)議向轉(zhuǎn)發(fā)服務(wù)器請求轉(zhuǎn)發(fā)編碼器的媒體流。根據(jù)RTSP標(biāo)準(zhǔn)協(xié)議，轉(zhuǎn)發(fā)服務(wù)器首先收到RTSP Describe請求，Describe請求中包含客戶端的請求信息，轉(zhuǎn)發(fā)服務(wù)器分析請求信息，解析出客戶端所要求的轉(zhuǎn)發(fā)媒體源信息，根據(jù)媒體源信息中包含的編碼器的GUID信息，判斷其對應(yīng)編碼器和轉(zhuǎn)發(fā)服務(wù)器是否已經(jīng)完成連接，如果沒有連接，則返回失敗，如果存在連接，則轉(zhuǎn)發(fā)服務(wù)器將保存的先前與媒體源交互的SDP信息，作為客戶端RTSP Describe請求響應(yīng)的標(biāo)準(zhǔn)參數(shù)發(fā)送給客戶端。
步驟205，監(jiān)控終端收到RTSP Describe請求響應(yīng)的標(biāo)準(zhǔn)參數(shù)，即SDP信息后，通過RTSP SETUP，RTSP PLAY與轉(zhuǎn)發(fā)服務(wù)器建立基于RTP/RTCP overTCP的流媒體會話。
步驟206，轉(zhuǎn)發(fā)服務(wù)器接收到監(jiān)控終端的RTSP PLAY請求后，檢查編碼器是否已經(jīng)開始發(fā)送媒體流，如果已經(jīng)在發(fā)送，就跳轉(zhuǎn)到步驟207。如果沒有，則使用RTSP SET_PARAMETER方法向編碼器發(fā)送請求，通知編碼器開始發(fā)送媒體流。
步驟207，轉(zhuǎn)發(fā)服務(wù)器緩存編碼器推送的媒體流并轉(zhuǎn)發(fā)給監(jiān)控終端，這樣監(jiān)控終端就能就能訪問公、私網(wǎng)內(nèi)的媒體流。
其中，在步驟202中，轉(zhuǎn)發(fā)服務(wù)器維護(hù)SDP信息的方法有兩種一是將該信息保存在本地文件中，一旦系統(tǒng)重啟，還可以通過讀取本地文件獲取信息；另一種是直接將該SDP信息保存在內(nèi)存中，這種方式在系統(tǒng)重啟后不再獲取。
其中，在步驟206中，轉(zhuǎn)發(fā)服務(wù)器和編碼器一直保持會話，只有轉(zhuǎn)發(fā)服務(wù)器通過Set Parameter方法發(fā)起推送請求之后，編碼器才推送數(shù)據(jù)，這樣既可以避免多次穿越網(wǎng)絡(luò)的代價，又可以避免推送數(shù)據(jù)時浪費(fèi)帶寬。
當(dāng)然，本發(fā)明不僅僅適用于RTSP/RTP/RTCP傳輸流的方法，通過簡單變形，轉(zhuǎn)發(fā)服務(wù)器也可以動態(tài)轉(zhuǎn)發(fā)使用FTP(文件傳輸協(xié)議)/HTTP(超文本傳輸協(xié)議)等其他網(wǎng)絡(luò)傳輸協(xié)議傳送的數(shù)據(jù)。
與現(xiàn)有技術(shù)相比，本發(fā)明一方面采用媒體源主動向轉(zhuǎn)發(fā)服務(wù)器建立連接，保證了位于公私網(wǎng)內(nèi)的媒體源能夠?qū)崿F(xiàn)轉(zhuǎn)發(fā)；另一方面，轉(zhuǎn)發(fā)服務(wù)器和媒體源之間的流媒體會話建立后并不立即緩存數(shù)據(jù)，而是等到客戶端開始發(fā)送請求后，才通知媒體源開始發(fā)送媒體流，轉(zhuǎn)發(fā)到客戶端，從而實現(xiàn)動態(tài)轉(zhuǎn)發(fā)，節(jié)省網(wǎng)絡(luò)帶寬。
當(dāng)然，本發(fā)明還可有其他多種實施例，在不背離本發(fā)明精神及其實質(zhì)的情況下，熟悉本領(lǐng)域的技術(shù)人員可根據(jù)本發(fā)明作出各種相應(yīng)的改變和變形，但這些相應(yīng)的改變和變形都應(yīng)屬于本發(fā)明所附的權(quán)利要求的保護(hù)范圍。
權(quán)利要求
1.一種動態(tài)轉(zhuǎn)發(fā)媒體源的方法，其特征在于將轉(zhuǎn)發(fā)服務(wù)器作為媒體流請求端，將媒體源作為媒體流提供端；所述媒體源主動連接轉(zhuǎn)發(fā)服務(wù)器，發(fā)送媒體流的媒體源參數(shù)文件到轉(zhuǎn)發(fā)服務(wù)器，并與轉(zhuǎn)發(fā)服務(wù)器協(xié)商媒體流的傳輸方式；所述轉(zhuǎn)發(fā)服務(wù)器維護(hù)媒體源參數(shù)文件并與媒體源建立流媒體會話；轉(zhuǎn)發(fā)服務(wù)器接收到客戶端的流服務(wù)請求時，通知媒體源開始發(fā)送媒體流，接收媒體源的媒體流，緩沖并轉(zhuǎn)發(fā)給客戶端。
2.如權(quán)利要求1所述的動態(tài)轉(zhuǎn)發(fā)媒體源的方法，其特征在于，所述轉(zhuǎn)發(fā)服務(wù)器維護(hù)媒體源參數(shù)文件并與媒體源建立流媒體會話，包括如下步驟轉(zhuǎn)發(fā)服務(wù)器保存媒體源發(fā)送的媒體源參數(shù)文件并反饋應(yīng)答響應(yīng)至媒體源；媒體源接受轉(zhuǎn)發(fā)服務(wù)器返回的應(yīng)答響應(yīng)后，與轉(zhuǎn)發(fā)服務(wù)器建立流媒體會話，并保持該會話且不推送媒體流。
3.如權(quán)利要求2所述的動態(tài)轉(zhuǎn)發(fā)媒體源的方法，其特征在于，所述轉(zhuǎn)發(fā)服務(wù)器保存媒體源參數(shù)文件時，進(jìn)行如下處理將媒體源參數(shù)文件保存在轉(zhuǎn)發(fā)服務(wù)器的本地文件中。
4.如權(quán)利要求2所述的動態(tài)轉(zhuǎn)發(fā)媒體源的方法，其特征在于，所述轉(zhuǎn)發(fā)服務(wù)器保存媒體源參數(shù)文件時，進(jìn)行如下處理將媒體源參數(shù)文件保存在轉(zhuǎn)發(fā)服務(wù)器內(nèi)存中。
5.如權(quán)利要求3或4所述的動態(tài)轉(zhuǎn)發(fā)媒體源的方法，其特征在于，所述轉(zhuǎn)發(fā)服務(wù)器與媒體源建立流媒體會話后，為了維護(hù)其與轉(zhuǎn)發(fā)服務(wù)器兩者之間的媒體通道，媒體源定時向轉(zhuǎn)發(fā)服務(wù)器發(fā)送握手消息。
6.如權(quán)利要求5所述的動態(tài)轉(zhuǎn)發(fā)媒體源的方法，其特征在于，所述轉(zhuǎn)發(fā)服務(wù)器在收到客戶端的流服務(wù)請求后，進(jìn)行如下處理轉(zhuǎn)發(fā)服務(wù)器查詢與請求所對應(yīng)的媒體源的連接狀況，如果連接沒有建立，則轉(zhuǎn)發(fā)服務(wù)器拒絕客戶端的流服務(wù)請求；如果連接建立，則將轉(zhuǎn)發(fā)服務(wù)器保存的媒體源參數(shù)文件發(fā)送給客戶端；客戶端接受媒體源參數(shù)文件，并與轉(zhuǎn)發(fā)服務(wù)器之間建立流媒體會話。
7.如權(quán)利要求6所述的動態(tài)轉(zhuǎn)發(fā)媒體源的方法，其特征在于，在客戶端與轉(zhuǎn)發(fā)服務(wù)器之間建立流媒體會話后，轉(zhuǎn)發(fā)服務(wù)器緩沖媒體源的媒體流并轉(zhuǎn)發(fā)給客戶端前，包括轉(zhuǎn)發(fā)服務(wù)器確認(rèn)媒體源是否已經(jīng)發(fā)送媒體流的步驟。
全文摘要
本發(fā)明公開了一種動態(tài)轉(zhuǎn)發(fā)媒體源的方法，包括步驟如下作為媒體流提供端的媒體源主動連接作為媒體流請求端的轉(zhuǎn)發(fā)服務(wù)器，發(fā)送媒體流的媒體源參數(shù)文件到轉(zhuǎn)發(fā)服務(wù)器，并與轉(zhuǎn)發(fā)服務(wù)器協(xié)商媒體流的傳輸方式；所述轉(zhuǎn)發(fā)服務(wù)器維護(hù)媒體源參數(shù)文件并與媒體源建立流媒體會話；轉(zhuǎn)發(fā)服務(wù)器接收到客戶端的流服務(wù)請求時，通知媒體源開始發(fā)送媒體流，接收媒體源的媒體流，緩沖并轉(zhuǎn)發(fā)給客戶端。
文檔編號H04L29/06GK101083628SQ20071013727
公開日2007年12月5日 申請日期2007年7月20日 優(yōu)先權(quán)日2007年7月20日
發(fā)明者代丹, 夏正勛, 陳潔 申請人:中興通訊股份有限公司