專利名稱：一種會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種基于IP網(wǎng)絡(luò)和以會(huì)話發(fā)起協(xié)議 (Session Initiation Protocol, SIP)作為控制信令的語音通信系統(tǒng)中的SIP終端編 解碼算法動(dòng)態(tài)協(xié)商的方法及系統(tǒng)。
背景技術(shù)：
在基于IP網(wǎng)絡(luò)和以SIP作為控制信令的語音通信系統(tǒng)中，以往的流程往往 是會(huì)話雙方(SIP終端之間，或者SIP終端與媒體網(wǎng)關(guān)(MediaGateway, MGW) 之間)在開始通話，即建立媒體通道進(jìn)行媒體交換之前，預(yù)先進(jìn)行媒體協(xié)商。協(xié) 商的方式是在SIP消息中攜帶會(huì)話描述協(xié)議(Session Description Protocol, SDP) 消息體，用以描述SIP終端的媒體能力信息，包括語音或視頻使用的編解碼算法、 IP地址和媒體流使用的端口等等；并利用SDP協(xié)議的提供/應(yīng)答 (OFFER/ANSWER)機(jī)制，實(shí)現(xiàn)與對(duì)端之間的媒體協(xié)商。協(xié)商完成之后開始通話 并進(jìn)行媒體交互，在這之后進(jìn)行交互的語音編解碼算法都是采用協(xié)商確定的算 法。
基于IP的語音通信，媒體流都是在分組交換網(wǎng)上傳送，每一路通話都占用 一定的網(wǎng)絡(luò)帶寬資源。在話務(wù)量不高或者網(wǎng)絡(luò)帶寬資源足夠豐富的情況下，能夠 保證媒體流的實(shí)時(shí)和無損傳輸；當(dāng)網(wǎng)絡(luò)上一個(gè)端點(diǎn)到另一端點(diǎn)的話路媒體流過多 時(shí)，該網(wǎng)絡(luò)就會(huì)出現(xiàn)擁塞。擁塞后的網(wǎng)絡(luò)在其上傳送的所有媒體流就會(huì)出現(xiàn)丟包 過多，時(shí)延過大，導(dǎo)致在該網(wǎng)絡(luò)上承載的正常語音通話語音質(zhì)量下降，嚴(yán)重時(shí)甚 至?xí)?dǎo)致通話無法正常進(jìn)行。解決該問題的理想辦法是建設(shè)足夠大帶寬的分組交 換網(wǎng)，使其不會(huì)產(chǎn)生擁塞，但這樣做一方面成本過高，另一方面巨大帶寬的分組 網(wǎng)大多時(shí)間話務(wù)量不高時(shí)其上面只傳送很少的媒體流，產(chǎn)生巨大的浪費(fèi)。
在網(wǎng)絡(luò)上傳輸?shù)恼Z音數(shù)據(jù)是在終端采集后按照一定的編碼算法進(jìn)行壓縮，然 后通過實(shí)時(shí)傳輸協(xié)議(Realtime Transport Protocol, RTP)發(fā)送到對(duì)端；再由對(duì)端 用相應(yīng)的解碼算法進(jìn)行解碼還原。由于語音編解碼技術(shù)的不斷進(jìn)步，現(xiàn)在能夠選 擇的編解碼算法非常之多，如G711A、 G711u、 (1729、 G723.1、 (1726、 G728、 AMR、 iLBC、 Speex等等。終端支持的可用于媒體協(xié)商的編解碼算法也有很多
5種。不同的編碼算法，數(shù)據(jù)壓縮比例有高有低，同樣的語音數(shù)據(jù)，得到的壓縮后 數(shù)據(jù)有大有小。例如，G711、 G729和G723.1三種編解碼算法，壓縮后的純語 音數(shù)據(jù)量(不考慮RTP和IP包頭)在網(wǎng)絡(luò)上傳輸?shù)乃俾史謩e為64Kbps (bitper second,位每秒)、8Kbps和5.3Kbps。明顯地，同樣帶寬情況下，低速率的編解 碼格式能傳送更多的話路。然而低速率傳送的語音在話音質(zhì)量會(huì)有一些的下降， 例如對(duì)于G711、 G729和G723.1三種算法，反映語音編碼質(zhì)量的平均意見值 (Mean Opinion Score, MOS)分別為4.1、 3.92和3.8。
傳統(tǒng)的動(dòng)態(tài)語音編解碼切換方法， 一般是在網(wǎng)絡(luò)側(cè)進(jìn)行，由媒體網(wǎng)關(guān)監(jiān)視是 否發(fā)生擁塞，當(dāng)檢測到出現(xiàn)擁塞時(shí)，向軟交換上報(bào)網(wǎng)絡(luò)擁塞事件，軟交換對(duì)該網(wǎng) 關(guān)上以后新建立的呼叫切換為低速率的編解碼格式，擁塞嚴(yán)重時(shí)會(huì)對(duì)新呼叫建立 進(jìn)行限制。再有對(duì)己建立的呼叫向媒體網(wǎng)關(guān)下命令向低速率強(qiáng)行切換。這種方法 如果有一側(cè)網(wǎng)關(guān)不支持低速率的編解碼格式，媒體流就會(huì)中斷。因此迫切需要一 種方法，當(dāng)話路不多時(shí)，以高速率的編解碼格式傳送媒體流，提供給用戶清晰、 高質(zhì)量的語音業(yè)務(wù)；而當(dāng)網(wǎng)絡(luò)出現(xiàn)擁塞時(shí)，動(dòng)態(tài)調(diào)整媒體流的編解碼格式到低速 率的格式，降低網(wǎng)絡(luò)上的媒體流量，避免出現(xiàn)網(wǎng)絡(luò)擁塞而影響業(yè)務(wù)；同時(shí)保證被 調(diào)整的媒體流降低到低速率的格式后，雖然清晰度稍有下降，但仍能保持繼續(xù)進(jìn) 行而不中斷。
另外，傳統(tǒng)的語音編解碼切換方法，往往只考慮交換側(cè)的網(wǎng)絡(luò)資源狀況，而 在呼叫通道上，從端到端的所有傳輸環(huán)節(jié)都可能造成媒體包的丟失。媒體協(xié)商的 主體是終端與終端之間，或者終端與媒體網(wǎng)關(guān)之間，對(duì)于終端支持的語音編解碼 算法信息在終端側(cè)最完整。因此若能由終端檢測和統(tǒng)計(jì)對(duì)端發(fā)過來的媒體流，就 能夠反映和預(yù)測未來整個(gè)呼叫通道上的網(wǎng)絡(luò)資源狀況；還可根據(jù)本端支持的編解 碼算法信息，進(jìn)行調(diào)整后發(fā)起新的媒體協(xié)商，以動(dòng)態(tài)地適應(yīng)網(wǎng)絡(luò)資源狀況。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題是，提供一種SIP終端編解碼算法動(dòng)態(tài)協(xié)商的方 法，并在此基礎(chǔ)上提供一種SIP終端編解碼算法動(dòng)態(tài)協(xié)商的系統(tǒng)，以解決現(xiàn)有切 換語音編解碼技術(shù)中存在的不能從終端發(fā)起、未對(duì)端到端的RTP流實(shí)時(shí)檢測和 統(tǒng)計(jì)的問題。
本發(fā)明所述一種SIP終端編解碼算法動(dòng)態(tài)協(xié)商的方法，包括以下步驟 步驟A: SIP終端對(duì)收到的媒體流進(jìn)行實(shí)時(shí)檢測，并周期性統(tǒng)計(jì)媒體流的丟
6包數(shù)量，計(jì)算一定周期內(nèi)的網(wǎng)絡(luò)丟包率；
步驟B: SIP終端基于歷史時(shí)段的網(wǎng)絡(luò)丟包率對(duì)本端支持的語音編解碼算法 進(jìn)行排序；
步驟C:判斷編解碼算法列表是否發(fā)生變化，若是，則SIP終端發(fā)出包含有 新的編解碼算法列表的請求消息，與通話對(duì)端進(jìn)行媒體協(xié)商；協(xié)商成功后，雙方 以新的編解碼格式進(jìn)行通訊；否則，執(zhí)行步驟A。
所述SIP終端是指SIP電話、PC客戶端或者其它支持SIP協(xié)議的終端。
所述通話對(duì)端是指通話對(duì)方的SIP終端或者媒體網(wǎng)關(guān)MGW。
所述步驟A進(jìn)一步包括
步驟Al:通話開始時(shí)，SIP終端設(shè)置收包計(jì)數(shù)器和丟包計(jì)數(shù)器；并設(shè)置檢 測步長以及預(yù)測周期
步驟A2:通話進(jìn)行過程中，SIP終端在步長范圍對(duì)接收到的語音RTP包進(jìn) 行檢測，記錄一個(gè)步長內(nèi)相同負(fù)荷值的所有RTP包頭部的序列號(hào)(Sequence Number)字段；每收到一個(gè)RTP包，收包計(jì)數(shù)器加1，并計(jì)算前后兩個(gè)RTP包序 列號(hào)的差值，若差值不為l，則丟包計(jì)數(shù)器增加該差值減l;
步驟A3:計(jì)算一個(gè)步長內(nèi)的丟包率，記錄該值將收包計(jì)數(shù)器和丟包計(jì)數(shù) 器清零；并判斷步長累計(jì)時(shí)間是否到達(dá)預(yù)測周期，若是，則提交丟包率統(tǒng)計(jì)數(shù)據(jù) 記錄；否則，執(zhí)行步驟A2。
步驟A3中所述丟包率的值為丟包計(jì)數(shù)器的值除以收包計(jì)數(shù)器的值和丟包計(jì) 數(shù)器的值的和。
步驟A2中所述相同負(fù)荷值的所有RTP包是指同一類型的所有RTP包。 所述步驟B進(jìn)一步包括
步驟B1:根據(jù)丟包率計(jì)算一個(gè)檢測周期內(nèi)的丟包率均值和丟包率方差其 中，丟包率均值代表一定周期內(nèi)網(wǎng)絡(luò)資源狀況平均水平，丟包率方差代表網(wǎng)絡(luò)資 源的穩(wěn)定性；以此對(duì)未來時(shí)段的網(wǎng)絡(luò)資源狀況進(jìn)行預(yù)測；
步驟B2:判斷丟包率均值的大小，若丟包率均值大于設(shè)定的丟包率閾值上 限，則按照占用帶寬的高低調(diào)整本地的語音編解碼算法列表，其中占用帶寬低的 算法設(shè)置為高優(yōu)先級(jí)；若丟包率均值小于設(shè)定的丟包率閾值下限，且丟包率方差 小于設(shè)定的方差閾值，則按照占用帶寬的高低調(diào)整本地的語音編解碼算法列表， 其中占用帶寬高的算法設(shè)置為高優(yōu)先級(jí)；否則，本地的語音編解碼算法列表不變；
步驟B3:判斷本地的語音編解碼算法列表是否發(fā)生變化，若是，則存儲(chǔ)變化后的算法優(yōu)先級(jí)列表。
步驟B2中所述丟包率閾值上限的值在運(yùn)行過程中可根據(jù)實(shí)際的網(wǎng)絡(luò)狀況， 以及SIP終端支持的編解碼算法占用帶寬的情況進(jìn)行修正。
步驟B2中所述丟包率閾值下限的值在運(yùn)行過程中可根據(jù)實(shí)際的網(wǎng)絡(luò)狀況， 以及SIP終端支持的編解碼算法占用帶寬的情況進(jìn)行修正。
步驟B2中所述方差閾值在運(yùn)行過程中可根據(jù)實(shí)際的網(wǎng)絡(luò)狀況，以及SIP終 端支持的編解碼算法占用帶寬的情況進(jìn)行修正。
所述步驟C進(jìn)一步包括
步驟C1:若本地的語音編解碼算法列表發(fā)生變化，則通過SIP協(xié)議的請求 消息與通話對(duì)端重新發(fā)起媒體協(xié)商，該消息攜帶的SDP消息體中包含了重新調(diào) 整優(yōu)先級(jí)后的編解碼算法列表；
步驟C2:通話對(duì)端收到該消息后，按照收到消息中的算法優(yōu)先級(jí)順序及本 地支持的編解碼算法確定最終的編解碼算法；然后返回200OK消息，其中包含 攜帶該算法信息的SDP消息體；
步驟C3:請求消息發(fā)起端收到200OK并確認(rèn)后，雙方后續(xù)的語音媒體交互 以新的編解碼格式進(jìn)行。
步驟C2中所述最終的編解碼算法是通話對(duì)端通過提取SDP消息中的編解碼 算法信息，與本地支持的編解碼算法取交集，然后按照收到消息中的算法優(yōu)先級(jí) 順序選擇交集中優(yōu)先級(jí)高的編解碼算法確定的。
本發(fā)明所述SIP終端編解碼算法動(dòng)態(tài)協(xié)商的系統(tǒng)，包括
檢測單元，用于通話過程中檢測接收到的RTP包，記錄包頭的序列號(hào)字段；
統(tǒng)計(jì)單元，用于獲取并統(tǒng)計(jì)來自檢測單元的數(shù)據(jù)，在一個(gè)步長內(nèi)計(jì)算網(wǎng)絡(luò)丟
包率；并計(jì)算預(yù)測周期內(nèi)丟包率的均值和方差；
預(yù)測單元，用于根據(jù)統(tǒng)計(jì)單元得到的數(shù)據(jù)，預(yù)測未來時(shí)段的網(wǎng)絡(luò)資源狀況，
包括判斷丟包率均值是否在設(shè)定的丟包率閾值范圍內(nèi)；參考丟包率方差和閾值的 值，進(jìn)行決策是否調(diào)整編解碼算法的優(yōu)先級(jí)列表；
存儲(chǔ)單元，用于在編解碼算法的優(yōu)先級(jí)發(fā)生變化時(shí)，存儲(chǔ)變化后的優(yōu)先級(jí)列
表；
執(zhí)行單元，用于在預(yù)測單元發(fā)出指令后，攜帶變化后存儲(chǔ)單元中的編解碼算 法優(yōu)先級(jí)列表作為SDP消息體，發(fā)起新的媒體協(xié)商，并負(fù)責(zé)隨后的信令交互。 本發(fā)明所述的方法和系統(tǒng)，即可用于下一代網(wǎng)絡(luò)(Next Generation NetworkNGN)環(huán)境，此時(shí)與所述SIP終端進(jìn)行信令交互的網(wǎng)絡(luò)側(cè)設(shè)備是軟交換(Soft Switch, SS);另外也可用于IP多媒體子系統(tǒng)(IP Multimedia Subsystem, IMS)環(huán) 境，此時(shí)與所述SIP終端進(jìn)行信令交互的網(wǎng)絡(luò)側(cè)設(shè)備是服務(wù)-呼叫會(huì)話控制功能 (Serving-Call Session Control Function, S-CSCF)。
采用本發(fā)明所述方法和系統(tǒng)，與現(xiàn)有技術(shù)相比，能夠在呼叫終端側(cè)實(shí)時(shí)地對(duì) RTP流進(jìn)行檢測和統(tǒng)計(jì)，動(dòng)態(tài)調(diào)整會(huì)話采用的編解碼算法以適應(yīng)網(wǎng)絡(luò)資源狀況， 使用戶得到最佳的語音質(zhì)量體驗(yàn)。


圖1是實(shí)現(xiàn)本發(fā)明所述方法的系統(tǒng)結(jié)構(gòu)圖2是實(shí)現(xiàn)本發(fā)明所述方法，對(duì)端是SIP終端時(shí)的進(jìn)行信令交互的示意圖； 圖3是實(shí)現(xiàn)本發(fā)明所述方法，對(duì)端是媒體網(wǎng)關(guān)時(shí)的進(jìn)行信令交互的示意圖。
具體實(shí)施例方式
下面將通過附圖對(duì)本發(fā)明做進(jìn)一步詳細(xì)說明。
如圖1所示，為實(shí)現(xiàn)本發(fā)明所述的方法，SIP終端(SIP User Equipment, SIP
UE)需要增加本發(fā)明所述的系統(tǒng)，圖中
11檢測單元，用于通話過程中檢測接收到的RTP包，記錄包頭的序列號(hào)字
段；
12統(tǒng)計(jì)單元，用于獲取檢測單元提供的數(shù)據(jù)進(jìn)行統(tǒng)計(jì)，并在一個(gè)步長內(nèi)計(jì) 算網(wǎng)絡(luò)丟包率；在經(jīng)過多個(gè)步長達(dá)到預(yù)測周期以后，計(jì)算該周期內(nèi)丟包率的均值
和方差；
13預(yù)測單元，用于根據(jù)統(tǒng)計(jì)單元得到的數(shù)據(jù)，預(yù)測未來時(shí)段的網(wǎng)絡(luò)資源狀 況；判斷丟包率均值是否在設(shè)定的丟包率閾值范圍之外，并參考丟包率方差和閾 值的值，進(jìn)行決策是否調(diào)整編解碼算法的優(yōu)先級(jí)列表；
14執(zhí)行單元，用于在預(yù)測單元發(fā)出指令后，攜帶變化后存儲(chǔ)單元中的編解 碼算法優(yōu)先級(jí)列表作為SDP消息體，發(fā)起新的媒體協(xié)商，并負(fù)責(zé)隨后的信令交 互。
15存儲(chǔ)單元，用于當(dāng)編解碼算法的優(yōu)先級(jí)列表發(fā)生變化時(shí)，存儲(chǔ)變化后的 優(yōu)先級(jí)列表。
如圖2所示，是本發(fā)明的一個(gè)經(jīng)簡化的應(yīng)用環(huán)境。在網(wǎng)絡(luò)側(cè)只列出了與本實(shí)施例緊密相關(guān)的網(wǎng)元，它們與SIP終端一起進(jìn)行信令交互實(shí)現(xiàn)本發(fā)明。在NGN 環(huán)境下進(jìn)行呼叫控制的是SS，在IMS環(huán)境下進(jìn)行呼叫控制的是S-CSCF，以下 說明以NGN環(huán)境為例。
圖2所示是兩個(gè)SIP UE——21-UE1和23-UE2之間通話，其中媒體流不經(jīng) 過MGW直接到達(dá)對(duì)端。UE之間的信令交互經(jīng)過22-SS。圖中，假設(shè)UE1支持 的語音編解碼算法包括5種格式，它們構(gòu)成UE1當(dāng)前的編解碼格式列表 CodecList—old{Codec_l, Codec—2， Codec—3， Codec_4, Codec_5}。UEl與UE2建立 呼叫進(jìn)行媒體協(xié)商的時(shí)候假設(shè)協(xié)商的結(jié)果是Codec—1;通話開始之后UE1與UE2 以Codec—1作為編解碼方式互相發(fā)送媒體流。
在通話開始時(shí)候，UE1設(shè)置收包計(jì)數(shù)器PacketCounter和丟包計(jì)數(shù)器 LoseCounter;同時(shí)設(shè)置丟包率的閾值下限RateHold一down和閾值上限 RateHold—up,以及丟包率方差的閾值VarHold;還需要設(shè)置對(duì)RTP包的統(tǒng)計(jì)步 長Delta,預(yù)測周期Period;其中，Period為若干個(gè)Delta: Period = n*Delta。
步驟201 ，通話過程中UE1與UE2以Codec—1作為編解碼格式互相發(fā)送RTP包。
步驟202，為本發(fā)明的核心部分，細(xì)分為以下子步驟
a) 對(duì)收到的RTP進(jìn)行實(shí)時(shí)檢測，每收到一個(gè)RTP包，PacketCounter增1; 判斷相鄰RTP包的包頭Sequence Number字段的值，如果相差不為1，則 LoseCounter增加該差值減1;
b) 時(shí)間達(dá)到檢測步長 Delta 后，計(jì)算丟包率 ri=LoseCounter/(PacketCounterfLoseCounter),其中i-l,2，…，n;然后將計(jì)數(shù)器 PacketCounter和LoseCounter清零，返回步驟a)繼續(xù)進(jìn)行；
c) 判斷時(shí)間是否達(dá)到預(yù)測周期Delta,若是，則執(zhí)行步驟d);否則，執(zhí)行 步驟a);
d) 計(jì)算該周期內(nèi)的丟包率均值A(chǔ)vr和方差Var;其中，Avr代表一定周期內(nèi) 網(wǎng)絡(luò)資源狀況平均水平，Var代表網(wǎng)絡(luò)資源的穩(wěn)定性；以此對(duì)未來時(shí)段的網(wǎng)絡(luò)資 源狀況進(jìn)行預(yù)測；
e) 判斷Avr與RateHold_down和RateHold_up的關(guān)系若Avr大于 RateHold_up,則按照占用帶寬的高低調(diào)整本地的語音編解碼算法的優(yōu)先級(jí)，其 中占用帶寬低的算法設(shè)置為高優(yōu)先級(jí)；若Avr小于RateHold—down并且Var小于 VarHold,則調(diào)整語音編解碼算法的優(yōu)先級(jí)，其中占用帶寬高的算法設(shè)置為高優(yōu)先級(jí)
f)判斷UE1的編解碼算法列表CodecList是否發(fā)生改變；若沒有改變，返回步驟a)重新開始執(zhí)行；否則執(zhí)行步驟203，發(fā)起新的媒體協(xié)商。
步驟203， UE1以新的編解碼算法列表CodecList—new作為SDP消息體通過re-INVITE發(fā)起新的媒體協(xié)商；
步驟204， SS收到以后轉(zhuǎn)發(fā)到UE2;
步驟205， UE2根據(jù)收到的新的編解碼算法優(yōu)先列表，結(jié)合本端支持的編解碼算法，確定后續(xù)交互的媒體格式，放在200OK的SDP消息體中返回給SS;步驟206， SS轉(zhuǎn)發(fā)給UE1;步驟207-208, UE1發(fā)出ACK確認(rèn)；
步驟209， UE1與UE2之間以新的編解碼算法交互媒體流。
例如，經(jīng)過步驟202后，UE1得到新的媒體優(yōu)先級(jí)列表CodecList_new{Codec_3, Codec—4, Codec—1， Codec—2, Codec—5} ; UE2收到re-INVITE以后根據(jù)本端支持的編解碼格式確定以Codec—3作為最終的媒體格式，在這之后的通話中雙方將以Codec—3格式的媒體進(jìn)行交互。
以上步驟中使用的幾個(gè)閾值RateHold一down、 RateHold—up和VarHold,即可以由用戶在初始化的時(shí)候進(jìn)行設(shè)置；也可以根據(jù)實(shí)際的網(wǎng)絡(luò)狀況以及本端支持的編解碼算法占用帶寬情況，在運(yùn)行過程中進(jìn)行修正，以得到最適合的值，使得在一定帶寬下能夠得到最優(yōu)的語音質(zhì)量。
圖3所示的情況與圖2不同之處是UE進(jìn)行媒體交互的直接對(duì)象是MGW，通過MGW與通話對(duì)方進(jìn)行媒體交互。這種情況下SS與MGW的信令交互(步驟304)是通過媒體網(wǎng)關(guān)控制協(xié)議(Media Gateway Control Protocol, MGCP)進(jìn)行的，其它的步驟與圖2所示情況基本相似，在此不再贅述。
以上描述的實(shí)施例是說明性的而不是限制性的，本發(fā)明還可有其他多種實(shí)施例，在不脫離本發(fā)明的精神和范圍的情況下，熟悉本領(lǐng)域的技術(shù)人員當(dāng)可根據(jù)本發(fā)明作出各種相應(yīng)的改變和變形，但這些相應(yīng)的改變和變形都應(yīng)屬于本發(fā)明所附的權(quán)利要求的保護(hù)范圍。
權(quán)利要求
1、一種會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，其特征在于，包括以下步驟步驟A會(huì)話發(fā)起協(xié)議終端對(duì)收到的媒體流進(jìn)行實(shí)時(shí)檢測，并周期性統(tǒng)計(jì)媒體流的丟包數(shù)量，計(jì)算一定周期內(nèi)的網(wǎng)絡(luò)丟包率；步驟B會(huì)話發(fā)起協(xié)議終端基于歷史時(shí)段的網(wǎng)絡(luò)丟包率對(duì)本端支持的語音編解碼算法進(jìn)行排序；步驟C判斷編解碼算法列表是否發(fā)生變化，若是，則會(huì)話發(fā)起協(xié)議終端發(fā)出包含有新的編解碼算法列表的請求消息，與通話對(duì)端進(jìn)行媒體協(xié)商；協(xié)商成功后，雙方以新的編解碼格式進(jìn)行通訊；否則，執(zhí)行步驟A。
2、 如權(quán)利要求1所述的會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，其 特征在于，所述通話對(duì)端是指通話對(duì)方的會(huì)話發(fā)起協(xié)議終端或者媒體網(wǎng)關(guān)。
3、 如權(quán)利要求1所述的會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，其 特征在于，所述步驟A進(jìn)一步包括步驟Al:通話開始時(shí)，會(huì)話發(fā)起協(xié)議終端設(shè)置收包計(jì)數(shù)器和丟包計(jì)數(shù)器； 并設(shè)置檢測步長以及預(yù)測周期；步驟A2:通話進(jìn)行過程中，會(huì)話發(fā)起協(xié)議終端在步長范圍對(duì)接收到的語音 實(shí)時(shí)傳輸協(xié)議包進(jìn)行檢測，記錄一個(gè)步長內(nèi)相同負(fù)荷值的所有實(shí)時(shí)傳輸協(xié)議包頭 部的序列號(hào)字段；每收到一個(gè)實(shí)時(shí)傳輸協(xié)議包，收包計(jì)數(shù)器加l，并計(jì)算前后兩 個(gè)實(shí)時(shí)傳輸協(xié)議包序列號(hào)的差值，若差值不為1，則丟包計(jì)數(shù)器增加該差值減1;步驟A3:計(jì)算一個(gè)步長內(nèi)的丟包率，記錄該值，將收包計(jì)數(shù)器和丟包計(jì)數(shù) 器清零；并判斷步長累計(jì)時(shí)間是否到達(dá)預(yù)測周期，若是，則提交丟包率統(tǒng)計(jì)數(shù)據(jù) 記錄；否則，執(zhí)行步驟A2。
4、 如權(quán)利要求1所述的會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，其 特征在于，所述步驟B進(jìn)一步包括步驟B1:根據(jù)丟包率計(jì)算一個(gè)檢測周期內(nèi)的丟包率均值和丟包率方差； 步驟B2:判斷丟包率均值的大小，若丟包率均值大于設(shè)定的丟包率閾值上限，則按照占用帶寬的高低調(diào)整本地的語音編解碼算法列表，其中占用帶寬低的算法設(shè)置為高優(yōu)先級(jí)；若丟包率均值小于設(shè)定的丟包率閾值下限，且丟包率方差 小于設(shè)定的方差閾值，則按照占用帶寬的高低調(diào)整本地的語音編解碼算法列表， 其中占用帶寬高的算法設(shè)置為高優(yōu)先級(jí)；否則，本地的語音編解碼算法列表不變;步驟B3:判斷本地的語音編解碼算法列表是否發(fā)生變化，若是，則存儲(chǔ)變 化后的算法優(yōu)先級(jí)列表。
5、 如權(quán)利要求1所述的會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，其 特征在于，所述步驟C進(jìn)一步包括-步驟Cl:若本地的語音編解碼算法列表發(fā)生變化，則通過會(huì)話發(fā)起協(xié)議協(xié) 議的請求消息與通話對(duì)端重新發(fā)起媒體協(xié)商，該消息攜帶的會(huì)話描述協(xié)議消息體 中包含了重新調(diào)整優(yōu)先級(jí)后的編解碼算法列表；步驟C2:通話對(duì)端收到該消息后，按照收到消息中的算法優(yōu)先級(jí)順序及本 地支持的編解碼算法確定最終的編解碼算法；然后返回200OK消息，其中包含 攜帶該算法信息的會(huì)話描述協(xié)議消息體；步驟C3:請求消息發(fā)起端收到200OK并確認(rèn)后，雙方后續(xù)的語音媒體交互 以新的編解碼格式進(jìn)行。
6、 如權(quán)利要求3所述的會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，其 特征在于，步驟A3中所述丟包率的值為丟包計(jì)數(shù)器的值除以收包計(jì)數(shù)器的值和 丟包計(jì)數(shù)器的值的和。
7、 如權(quán)利要求4所述的會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，其 特征在于，步驟B2中所述丟包率閾值上、下限的值在運(yùn)行過程中可根據(jù)實(shí)際的 網(wǎng)絡(luò)狀況，以及SIP終端支持的編解碼算法占用帶寬的情況進(jìn)行修正。
8、 如權(quán)利要求4所述的會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，其 特征在于，步驟B2中所述方差閾值在運(yùn)行過程中可根據(jù)實(shí)際的網(wǎng)絡(luò)狀況，以及 SIP終端支持的編解碼算法占用帶寬的情況進(jìn)行修正。
9、 如權(quán)利要求5所述的會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，其 特征在于，步驟C2所述最終的編解碼算法是通話對(duì)端通過提取會(huì)話描述協(xié)議消息中的編解碼算法信息，與本地支持的編解碼算法取交集，然后按照收到消息中 的算法優(yōu)先級(jí)順序選擇交集中優(yōu)先級(jí)高的編解碼算法確定的。
10、 一種會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的系統(tǒng)，其特征在于，包括檢測單元，用于通話過程中檢測接收到的實(shí)時(shí)傳輸協(xié)議包，記錄包頭的序列 號(hào)字段；統(tǒng)計(jì)單元，用于獲取并統(tǒng)計(jì)來自檢測單元的數(shù)據(jù)，在一個(gè)步長內(nèi)計(jì)算網(wǎng)絡(luò)丟包率；并計(jì)算預(yù)測周期內(nèi)丟包率的均值和方差；預(yù)測單元，用于根據(jù)統(tǒng)計(jì)單元得到的數(shù)據(jù)，預(yù)測未來時(shí)段的網(wǎng)絡(luò)資源狀況， 包括判斷丟包率均值是否在設(shè)定的丟包率閾值范圍內(nèi)；參考丟包率方差和閾值的 值，進(jìn)行決策是否調(diào)整編解碼算法的優(yōu)先級(jí)列表；存儲(chǔ)單元，用于在編解碼算法的優(yōu)先級(jí)發(fā)生變化時(shí)，存儲(chǔ)變化后的優(yōu)先級(jí)列表；執(zhí)行單元，用于在預(yù)測單元發(fā)出指令后，攜帶變化后存儲(chǔ)單元中的編解碼算 法優(yōu)先級(jí)列表作為會(huì)話描述協(xié)議消息體，發(fā)起新的媒體協(xié)商，并負(fù)責(zé)隨后的信令 交互。
全文摘要
本發(fā)明涉及一種會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的方法，該方法通過會(huì)話發(fā)起協(xié)議終端在呼叫過程中對(duì)收到的媒體流進(jìn)行實(shí)時(shí)檢測，周期性統(tǒng)計(jì)媒體流的丟包率；并基于歷史時(shí)段的網(wǎng)絡(luò)丟包率對(duì)語音編解碼算法進(jìn)行排序，然后主動(dòng)發(fā)起與通話對(duì)端或者媒體網(wǎng)關(guān)的媒體協(xié)商，成功后雙方以新的編解碼格式進(jìn)行通訊；本發(fā)明還在上述方法的基礎(chǔ)上提供一種會(huì)話發(fā)起協(xié)議終端編解碼算法動(dòng)態(tài)協(xié)商的系統(tǒng)，該系統(tǒng)包括檢測單元，統(tǒng)計(jì)單元，預(yù)測單元，存儲(chǔ)單元以及執(zhí)行單元。本發(fā)明能夠在呼叫終端側(cè)實(shí)時(shí)地對(duì)實(shí)時(shí)傳輸協(xié)議流進(jìn)行檢測和統(tǒng)計(jì)，動(dòng)態(tài)調(diào)整會(huì)話采用的編解碼算法以適應(yīng)網(wǎng)絡(luò)資源狀況，使用戶得到最佳的語音質(zhì)量體驗(yàn)。
文檔編號(hào)H04L1/00GK101483494SQ200810065149
公開日2009年7月15日 申請日期2008年1月7日 優(yōu)先權(quán)日2008年1月7日
發(fā)明者張繼棟, 昊 董, 鄧加瓊 申請人:中興通訊股份有限公司