一種基于sip協(xié)議下的通過(guò)tcp傳輸rtp媒體流的方法
【專利摘要】本發(fā)明公開(kāi)了一種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體流的方法，包括媒體客戶端與媒體服務(wù)器之間的SIP信令協(xié)商和TCP協(xié)議下RTP媒體流的傳輸方法；SIP信令，用于媒體客戶端與媒體服務(wù)器之間協(xié)商RTP媒體流傳輸?shù)男畔ⅲ?dāng)媒體客戶端發(fā)起呼叫請(qǐng)求時(shí)，媒體客戶端告訴媒體服務(wù)器自己的解碼能力和媒體流接收IP端口。媒體服務(wù)器接收到請(qǐng)求后，根據(jù)媒體客戶端的能力，返回媒體流的信息，確定通過(guò)TCP傳輸RTP媒體流，并確定TCP連接方向，以及媒體服務(wù)器發(fā)送媒體流的IP端口。媒體客戶端收到媒體服務(wù)器返回的SIP消息后，向媒體服務(wù)器發(fā)送確認(rèn)消息，最終建立一個(gè)通過(guò)TCP傳輸RTP媒體流的會(huì)話。本發(fā)明能有效減少在無(wú)線網(wǎng)絡(luò)的情況下媒體流傳輸大量丟包的弊端。
【專利說(shuō)明】-種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體流的方法

【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及通訊領(lǐng)域，特別是涉及一種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體 流的方法。

【背景技術(shù)】
[0002] 流媒體應(yīng)用，如網(wǎng)絡(luò)電視對(duì)互聯(lián)網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性要求很高，目前業(yè)界的標(biāo) 準(zhǔn)是采用RTP-over-UDP協(xié)議。在傳輸層，RTP由于攜帶了大量的多媒體數(shù)據(jù)，傳輸量大，實(shí) 時(shí)性要求高，較適合采用延遲和抖動(dòng)?jì)尚〉腢DP傳輸協(xié)議。但是在無(wú)線應(yīng)用中，情況發(fā)生了 以下變化：首先，無(wú)線網(wǎng)絡(luò)系統(tǒng)服務(wù)器和客戶端之間的網(wǎng)絡(luò)通常是異構(gòu)的，其中有線網(wǎng)絡(luò)的 無(wú)線網(wǎng)絡(luò)之間的帶寬不匹配情況較嚴(yán)重，其各自的帶寬也是時(shí)刻在變動(dòng)的，沒(méi)有擁塞控制 的UDP傳輸方式在這種情況下很容易出現(xiàn)大量的擁塞丟包；其次，無(wú)線信道高誤碼率的特 點(diǎn)也令沒(méi)有丟包補(bǔ)償措施的UDP傳輸質(zhì)量難以達(dá)到流媒體的要求。雖然可以在應(yīng)用層配合 UDP協(xié)議實(shí)現(xiàn)擁塞控制和丟包補(bǔ)償措施，但是這一方面大大增加了開(kāi)發(fā)難度，導(dǎo)致了大量的 重復(fù)工作；另一方面不同的應(yīng)用層實(shí)現(xiàn)也使得系統(tǒng)之間難以兼容。而TCP協(xié)議本身?yè)碛械?擁塞控制機(jī)制和重傳機(jī)制則正好可以克服這些缺點(diǎn)，而且該協(xié)議是目前互聯(lián)網(wǎng)中應(yīng)用得最 廣泛的標(biāo)準(zhǔn)協(xié)議。另外，由于TCP能夠較好地穿透防火墻，因而可以很好地適應(yīng)無(wú)線異構(gòu)網(wǎng) 絡(luò)的各種架構(gòu)形式。


【發(fā)明內(nèi)容】

[0003] 本發(fā)明所要解決的技術(shù)問(wèn)題是提供一種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體 流的方法，以減少現(xiàn)有技術(shù)中在無(wú)線網(wǎng)絡(luò)的情況下媒體流傳輸大量丟包的弊端。
[0004] 為實(shí)現(xiàn)上述發(fā)明目的，本發(fā)明提供一種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體 流的系統(tǒng)，包括媒體客戶端與媒體服務(wù)器協(xié)商傳輸協(xié)議的同時(shí)，協(xié)商媒體客戶端和媒體服 務(wù)器哪一方作為T(mén)CP服務(wù)端，哪一方作為T(mén)CP客戶端；
[0005] 所述媒體客戶端，用于：接收和發(fā)送SIP消息，并解析SIP消息以及SIP消息中的 SDP消息體。同時(shí)接收和解析從媒體服務(wù)器收到的媒體流；
[0006] 所述媒體服務(wù)器，用于：接收和發(fā)送SIP消息，并解析SIP消息以及SIP消息中的 SDP消息體，同時(shí)進(jìn)行媒體流的編碼和向媒體客戶端發(fā)送媒體流。
[0007] 本發(fā)明還提供一種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體流的方法，包括：
[0008] 媒體客戶端通過(guò)SIP消息，向媒體服務(wù)器請(qǐng)求媒體流數(shù)據(jù)，此處的SIP消息可以通 過(guò)UDP傳輸，也可以通過(guò)TCP傳輸；
[0009] 媒體服務(wù)器收到媒體客戶端發(fā)來(lái)的請(qǐng)求消息，解析SIP消息中的SDP消息體，返回 媒體流的信息，確定通過(guò)TCP傳輸RTP媒體流，并確定TCP連接方向，以及媒體服務(wù)端發(fā)送 媒體流的IP端口。媒體客戶端收到媒體服務(wù)端返回的SIP消息后，向媒體服務(wù)端發(fā)送確認(rèn) 消息，最終建立一個(gè)通過(guò)TCP傳輸RTP媒體流的會(huì)話；
[0010] 優(yōu)選的有，上述方法中，還包括：當(dāng)媒體客戶端不主動(dòng)充當(dāng)媒體流的TCP服務(wù)端 時(shí)，由媒體服務(wù)器充當(dāng)媒體流的TCP服務(wù)端，由媒體客戶端來(lái)向媒體服務(wù)器連接TCP。
[0011] 由上述方案可以看出，本發(fā)明中直接利用TCP傳輸協(xié)議進(jìn)行傳輸媒體流數(shù)據(jù)，而 該協(xié)議是目前互聯(lián)網(wǎng)中應(yīng)用得最廣泛的標(biāo)準(zhǔn)協(xié)議，而且TCP協(xié)議本身?yè)碛械膿砣刂茩C(jī)制 和重傳機(jī)制則正好可以簡(jiǎn)化系統(tǒng)的開(kāi)發(fā)工作量。另外，由于TCP能夠較好地穿透防火墻，因 而可以很好地適應(yīng)無(wú)線異構(gòu)網(wǎng)絡(luò)的各種架構(gòu)形式。

【專利附圖】

【附圖說(shuō)明】
[0012] 為了更清楚地說(shuō)明本發(fā)明實(shí)施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對(duì)實(shí)施例或現(xiàn) 有技術(shù)描述中所需要使用的附圖作簡(jiǎn)單的介紹，顯而易見(jiàn)地，下面描述中的附圖僅僅是本 發(fā)明的一些實(shí)施例，對(duì)于本領(lǐng)域普通技術(shù)人員來(lái)講，在不付出創(chuàng)造性勞動(dòng)性的前提下，還可 以根據(jù)這些附圖獲得其他的附圖。
[0013] 圖1為本發(fā)明實(shí)施例一中系統(tǒng)結(jié)構(gòu)示意圖；
[0014] 圖2為本發(fā)明實(shí)施例一中系統(tǒng)處理信息流程示意圖；
[0015] 圖3為本發(fā)明實(shí)施例一中流程示意圖；

【具體實(shí)施方式】
[0016] 為使本發(fā)明的上述目的、特征和優(yōu)點(diǎn)能夠更加明顯易懂，下面結(jié)合附圖和具體實(shí) 施方式對(duì)本發(fā)明作進(jìn)一步詳細(xì)的說(shuō)明。顯然，所描述的實(shí)施例僅是本發(fā)明一部分實(shí)施例，而 不是全部的實(shí)施例。基于本發(fā)明中的實(shí)施例，本領(lǐng)域普通技術(shù)人員在沒(méi)有做出創(chuàng)造性勞動(dòng) 前提下所獲得的所有其他實(shí)施例，都屬于本發(fā)明保護(hù)的范圍。
[0017] 實(shí)施例一，參見(jiàn)圖1，圖2。
[0018] 本發(fā)明提供一種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體流的方法，所述系統(tǒng)包 括SIP控制信令和基于TCP協(xié)議傳輸?shù)腞TP媒體流，所述SIP控制信令中包含SDP消息體， 所述基于TCP協(xié)議傳輸?shù)腞TP媒體流，其中 ：
[0019] 由于RTP媒體流數(shù)據(jù)包是獨(dú)立分包的，在TCP協(xié)議傳輸中，是按塊連續(xù)地傳輸，因 此需要在每個(gè)RTP包頭之前增加分包的包頭，讓接收方能區(qū)分每一個(gè)RTP數(shù)據(jù)包；
[0020] 參考RFC2326中第10. 12章的內(nèi)容，在發(fā)送RTP包之前增加分隔符"$+通道ID+ 包長(zhǎng)度"。
[0021] 例：
[0022] S-> C :$\000{2byte length}{" length" bytes data，w/RTP header}
[0023] S_ > C :$\000{2byte length} {" length" bytes data，w/RTP header}
[0024] 上述系統(tǒng)的工作過(guò)程參見(jiàn)圖3,具體包括以下步驟：
[0025] 步驟S301，媒體客戶端向媒體服務(wù)器發(fā)起視頻請(qǐng)求；
[0026] 步驟S302,媒體服務(wù)器判斷媒體客戶端發(fā)來(lái)的請(qǐng)求中，媒體客戶端是否作為T(mén)CP 服務(wù)端，若是則執(zhí)行S303 ;否則，執(zhí)行S304 ;
[0027] 步驟S303,媒體服務(wù)器創(chuàng)建TCP客戶端，準(zhǔn)備向媒體客戶端連接；
[0028] 步驟S304,媒體服務(wù)器創(chuàng)建TCP服務(wù)端，等待媒體客戶端的連接；
[0029] 步驟S305,媒體服務(wù)器根據(jù)媒體客戶端所支持的媒體格式，啟動(dòng)對(duì)應(yīng)的媒體流模 塊，準(zhǔn)備發(fā)送媒體流數(shù)據(jù)；
[0030] 步驟S306,媒體服務(wù)器向媒體客戶端返回2000K消息，附帶媒體流的信息，如媒體 流傳輸?shù)腎P和端口等；
[0031] 步驟S307,媒體客戶端根據(jù)媒體服務(wù)器返回的2000K消息中SDP對(duì)媒體流的描述 信息，創(chuàng)建對(duì)應(yīng)的媒體流模塊接收和解析媒體流數(shù)據(jù)；
[0032] 步驟S308,媒體客戶端向媒體服務(wù)器返回ACK，并根據(jù)步驟S307中SDP對(duì)媒體流 的描述信息，建立RTP媒體流的TCP連接；
[0033] 步驟S309,媒體服務(wù)器收到ACK消息后，開(kāi)始向媒體客戶端發(fā)送RTP媒體流數(shù)據(jù)；
[0034] 步驟S310,媒體客戶端向媒體服務(wù)器發(fā)送BYE消息，請(qǐng)求斷開(kāi)RTPoverTCP的連 接；
[0035] 步驟S311，媒體服務(wù)器收到BYE消息后，斷開(kāi)RTPoverTCP的連接，并返回2000K給 媒體客戶端；
[0036] 步驟S312,媒體客戶端收到2000K消息后，斷開(kāi)RTPoverTCP的連接。
[0037] 本發(fā)明所述系統(tǒng)常用于無(wú)線網(wǎng)絡(luò)視頻傳輸，則引用手機(jī)觀看網(wǎng)絡(luò)電視為實(shí)施例進(jìn) 行說(shuō)明。
[0038] 此過(guò)程可視為手機(jī)通過(guò)無(wú)線網(wǎng)絡(luò)向視頻服務(wù)器請(qǐng)求媒體流數(shù)據(jù)。
[0039] 用戶在手機(jī)上觀看一部電影，手機(jī)通過(guò)無(wú)線網(wǎng)絡(luò)向視頻服務(wù)器發(fā)送SIP請(qǐng)求，告 訴視頻服務(wù)器用戶要點(diǎn)播的視頻、自己能支持的媒體流格式，以及接收媒體流數(shù)據(jù)的IP端 口等信息。
[0040] 視頻服務(wù)器接收到該視頻請(qǐng)求后判定該視頻請(qǐng)求的客戶端是作為T(mén)CP服務(wù)端還 是TCP客戶端，同時(shí)啟動(dòng)對(duì)應(yīng)的媒體流模塊，并將媒體流的信息通過(guò)2000K消息返回給手機(jī) 客戶端。
[0041] 手機(jī)接收到視頻服務(wù)器返回的2000K消息后，根據(jù)此消息中的SDP媒體流信息描 述，創(chuàng)建對(duì)應(yīng)的媒體流模塊，與視頻服務(wù)器建立TCP連接，并返回ACK消息給視頻服務(wù)器。
[0042] 視頻服務(wù)器接收到ACK消息后，開(kāi)始向手機(jī)客戶端發(fā)送媒體流數(shù)據(jù)，此時(shí)用戶就 能在手機(jī)上看到電影。
[0043] 本發(fā)明中利用現(xiàn)有已經(jīng)很成熟的SIP協(xié)議來(lái)控制視頻請(qǐng)求會(huì)話，利用SDP協(xié)議描 述媒體流的信息，設(shè)計(jì)簡(jiǎn)單，通用性高。直接利用TCP傳輸協(xié)議進(jìn)行傳輸媒體流數(shù)據(jù)，而該 協(xié)議是目前互聯(lián)網(wǎng)中應(yīng)用得最廣泛的標(biāo)準(zhǔn)協(xié)議，而且TCP協(xié)議本身?yè)碛械膿砣刂茩C(jī)制和 重傳機(jī)制則正好可以簡(jiǎn)化系統(tǒng)的開(kāi)發(fā)工作量。另外，由于TCP能夠較好地穿透防火墻，因而 可以很好地適應(yīng)無(wú)線異構(gòu)網(wǎng)絡(luò)的各種架構(gòu)形式。
[0044] 由上可見(jiàn)，本發(fā)明提供的一種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體流的系統(tǒng) 和方法，有以下優(yōu)點(diǎn)。
[0045] (1)便于開(kāi)發(fā)，降低成本
[0046] 本發(fā)明只需在業(yè)界已有的技術(shù)基礎(chǔ)上進(jìn)行擴(kuò)展，即可實(shí)現(xiàn)通過(guò)TCP傳輸RTP媒體 流，減少了開(kāi)發(fā)的工作量；同時(shí)，通過(guò)利用現(xiàn)有成熟且應(yīng)用廣泛的SIP協(xié)議進(jìn)行請(qǐng)求會(huì)話控 制，免去重復(fù)的消息通訊開(kāi)發(fā)，這大大降低了使用成本。
[0047] (2)應(yīng)用范圍廣
[0048] SIP協(xié)議、SDP協(xié)議、TCP協(xié)議和RTP協(xié)議都是全世界廣泛使用的國(guó)標(biāo)標(biāo)準(zhǔn)協(xié)議，無(wú) 需其他軟件的協(xié)作，即可實(shí)現(xiàn)RTP媒體流的傳輸，應(yīng)用時(shí)方便易行，推廣度高。
[0049] (3)提供穩(wěn)定清晰的媒體服務(wù)
[0050] TCP協(xié)議本身?yè)碛械膿砣刂茩C(jī)制和重傳機(jī)制則正好可以簡(jiǎn)化系統(tǒng)的開(kāi)發(fā)工作 量。另外，由于TCP能夠較好地穿透防火墻，因而可以很好地適應(yīng)無(wú)線異構(gòu)網(wǎng)絡(luò)的各種架構(gòu) 形式，很好地解決了在公網(wǎng)傳輸過(guò)程中公網(wǎng)端口映射、防火墻穿透和運(yùn)營(yíng)商封殺等問(wèn)題，提 供穩(wěn)定清晰的媒體服務(wù)。
[0051] 通過(guò)以上的方法實(shí)施例的描述，所屬領(lǐng)域的技術(shù)人員可以清楚地了解到本發(fā)明可 借助軟件加必需的通用硬件平臺(tái)的方式來(lái)實(shí)現(xiàn)。基于這樣的理解，本發(fā)明的技術(shù)方案本質(zhì) 上或者說(shuō)對(duì)現(xiàn)有技術(shù)做出貢獻(xiàn)的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來(lái)，該計(jì)算機(jī)軟件產(chǎn)品 存儲(chǔ)在一個(gè)存儲(chǔ)介質(zhì)中，包括若干指令用以使得一臺(tái)計(jì)算機(jī)設(shè)備（可以是個(gè)人計(jì)算機(jī)，月艮 務(wù)器，或者網(wǎng)絡(luò)設(shè)備等）執(zhí)行本發(fā)明各個(gè)實(shí)施例所述方法的全部或部分步驟。而前述的存 儲(chǔ)介質(zhì)包括：只讀存儲(chǔ)器（ROM)、隨機(jī)存取存儲(chǔ)器（RAM)、磁碟或者光盤(pán)等各種可以存儲(chǔ)程 序代碼的介質(zhì)。
[0052] 對(duì)于系統(tǒng)實(shí)施例而言，由于其基本相應(yīng)于方法實(shí)施例，所以相關(guān)之處參見(jiàn)方法實(shí) 施例的部分說(shuō)明即可。以上所描述的裝置或系統(tǒng)實(shí)施例僅僅是示意性的，其中所述作為分 離部件說(shuō)明的單元可以是或者也可以不是物理上分開(kāi)的，作為單元顯示的部件可以是或者 也可以不是物理單元，即可以位于一個(gè)地方，或者也可以分布到多個(gè)網(wǎng)絡(luò)單元上。可以根據(jù) 實(shí)際的需要選擇其中的部分或者全部模塊來(lái)實(shí)現(xiàn)本實(shí)施例方案的目的。本領(lǐng)域普通技術(shù)人 員在不付出創(chuàng)造性勞動(dòng)的情況下，即可以理解并實(shí)施。
[0053] 在本申請(qǐng)所提供的實(shí)施例中，應(yīng)該理解到，所揭露的系統(tǒng)和方法，在沒(méi)有超過(guò)本申 請(qǐng)的精神和范圍內(nèi)，可以通過(guò)其他的方式實(shí)現(xiàn)。當(dāng)前的實(shí)施例只是一種示范性的例子，不應(yīng) 該作為限制，所給出的具體內(nèi)容不應(yīng)該限制本申請(qǐng)的目的。例如，所述單元或子單元的劃 分，僅僅為一種邏輯功能劃分，實(shí)際實(shí)現(xiàn)時(shí)可以有另外的劃分方式，例如多個(gè)單元或多個(gè)子 單元結(jié)合一起。另外，多個(gè)單元可以或組件可以結(jié)合或者可以集成到另一個(gè)系統(tǒng)，或一些特 征可以忽略，或不執(zhí)行。
[0054] 另外，所描述系統(tǒng)和方法以及不同實(shí)施例的示意圖，在不超出本申請(qǐng)的范圍內(nèi)，可 以與其它系統(tǒng)，模塊，技術(shù)或方法結(jié)合或集成。另一點(diǎn)，所顯示或討論的相互之間的耦合或 直接耦合或通信連接可以是通過(guò)一些接口，裝置或單元的間接耦合或通信連接，可以是電 性，機(jī)械或其它的形式。
[0055] 以上所述僅是本發(fā)明的【具體實(shí)施方式】，應(yīng)當(dāng)指出，對(duì)于本【技術(shù)領(lǐng)域】的普通技術(shù)人 員來(lái)說(shuō)，在不脫離本發(fā)明原理的前提下，還可以做出若干改進(jìn)和潤(rùn)飾，這些改進(jìn)和潤(rùn)飾也應(yīng) 視為本發(fā)明的保護(hù)范圍。
【權(quán)利要求】
1. 一種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體流的方法，其特征在于，通過(guò)SIP信令 在媒體客戶端和媒體服務(wù)器之間通信，利用SDP消息體商定媒體流發(fā)送的信息； 所述SIP信令，用于：媒體客戶端與媒體服務(wù)器之間進(jìn)行通信，交互對(duì)端信息并建立會(huì) 話連接； 所述SDP消息體，用于：描述媒體客戶端的解碼能力以及接收媒體流的IP端口等信息， 描述媒體服務(wù)器提供的碼流的編碼格式、傳輸協(xié)議已經(jīng)傳輸IP端口等信息； 所述RTP媒體流，用于：承載音視頻數(shù)據(jù)，提供時(shí)間信息和實(shí)現(xiàn)流同步。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括：媒體客戶端與媒體服務(wù)器協(xié)商傳 輸協(xié)議的同時(shí)，協(xié)商媒體客戶端和媒體服務(wù)器哪一方作為T(mén)CP服務(wù)端，哪一方作為T(mén)CP客戶 端。
3. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括：媒體客戶端通過(guò)SDP消息體與媒 體服務(wù)器協(xié)商媒體流編碼格式，以及媒體流發(fā)送端口等信息。
4. 一種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體流的系統(tǒng)，其特征在于，包括： 媒體客戶端SIP信令模塊，用于接收和發(fā)送SIP消息，并解析SIP消息以及SIP消息中 的SDP消息體； 媒體客戶端媒體流模塊，用于接收和解析從媒體服務(wù)器收到的媒體流。
5. -種基于SIP協(xié)議下的通過(guò)TCP傳輸RTP媒體流的系統(tǒng)，其特征在于，包括： 媒體服務(wù)器SIP信令模塊，用于接收和發(fā)送SIP消息，并解析SIP消息以及SIP消息中 的SDP消息體； 媒體服務(wù)器媒體流模塊，用于媒體流的編碼和向媒體客戶端發(fā)送媒體流。
【文檔編號(hào)】H04N21/643GK104159165SQ201410366529
【公開(kāi)日】2014年11月19日 申請(qǐng)日期:2014年7月26日 優(yōu)先權(quán)日:2014年7月26日
【發(fā)明者】劉斌, 張進(jìn)飛, 黃星光 申請(qǐng)人:佳都新太科技股份有限公司