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