專利名稱：媒體能力重協(xié)商的方法及裝置的制作方法
技術領域：
本發(fā)明涉及通信技術領域，尤其涉及一種媒體能力重協(xié)商的方法及裝置。
技術背景由于在網際協(xié)議(IP, Internet Protocol)網絡中存在著各種各樣的媒體能 力格式，為了實現(xiàn)主叫用戶與被叫用戶之間的媒體通信，主叫用戶與4皮叫用 戶之間必須通過媒體協(xié)商，協(xié)商出主被叫都支持的媒體能力，主叫用戶與被 叫用戶之間才能進行通信。媒體重協(xié)商是指在呼叫過程中，媒體通道已經建立后，主叫和被叫方由 于各種原因需要切換媒體能力格式和媒體流收發(fā)地址時，重新進行媒體能力 協(xié)商的過程。目前所有支持媒體能力重協(xié)商的協(xié)議中，媒體重協(xié)商過程都是 由需改變的 一方主動發(fā)起的。媒體能力協(xié)商及重協(xié)商的目的，主要是協(xié)商出媒體流傳遞所使用的編解 碼能力和傳輸媒體流的IP地址及端口號。以會話初始協(xié)議(SIP, Session Initiation Protocol)為例，在協(xié)商過程有 寬帶呼叫中心(IPCC, IP Contact Center )、移動秘書臺或其他業(yè)務中心參與時， 經常會出現(xiàn)如下場景用戶A撥入IPCC后，進行一些交互式語音應答系統(tǒng) (IVR, Interactive Voice Response)交互后，IPCC將其和一個已經在通話狀 態(tài)的用戶B連接起來進行通信。此時，假若需要進行與用戶A的媒體重協(xié)商，媒體重協(xié)商的流程如圖1 所示步驟IOI、用戶A和IPCC建立呼叫，由IPCC通過IVR進行業(yè)務引導。步驟102、 IPCC和用戶B建立呼叫，由IPCC通過IVR進行業(yè)務引導。步驟103、在需要進行媒體重協(xié)商時，IPCC向用戶B發(fā)送重協(xié)商請求消 息(reINVITE)。該reINVITE消息中攜帶有用戶A支持的全部媒體能力媒體能力集C，及 用戶A用于收發(fā)媒體流的IP地址1。
步驟104、用戶B返回響應消息(200 OK)給IPCC。
該200 OK消息攜帶有用戶B支持的全部媒體能力同用戶A當前支持的 全部媒體能力媒體能力集C的交集媒體能力集C，，及用戶B用于收發(fā)媒體流 的IP地址1。
步驟105、 IPCC向用戶A發(fā)送reINVITE消息。
該reINVITE消息中攜帶有媒體能力集C，，及用戶B用于收發(fā)媒體流的 IP地址1。
步驟106、用戶A返回200 OK消息給IPCC。
該200 OK消息攜帶有媒體能力集C",用戶A媒體流IP地址2。
其中，媒體能力集C"為用戶A當前支持的全部媒體能力同媒體能力集C' 的交集。
由于在步驟1203到步驟106,用戶A有可能會進行其他的操作，導致用 戶A無法再使用媒體能力集C中的某些媒體能力，因此，此時用戶A支持的 全部媒體能力有可能不等于步驟103中IPCC發(fā)送給用戶B的媒體能力集C, 若此時用戶A支持的全部媒體能力不等于媒體能力集C，那么媒體能力集C" 也將不等于媒體能力集C，，也就是說用戶B知道的用戶A可以使用的媒體能 力集不是用戶A真實的可使用的媒體能力集，可能導致媒體能力協(xié)商失敗， 那么就需要再次進行媒體重協(xié)商。
同理，若步驟106中用戶A使用的用于收發(fā)媒體流的IP地址不同于步驟 103中提到的用戶A用于收發(fā)媒體流的IP地址1,也將需要再次進行媒體重 協(xié)商。
IPCC收到該200 OK消息后，可以通過比較媒體能力集C"與媒體能力集 C，是否相同，用戶A用于收發(fā)媒體流的IP地址1與用戶A媒體流IP地址2 是否相同，決定是否需要進行媒體重協(xié)商。
步驟107、 IPCC判斷需要進行媒體重協(xié)商。IPCC在通過比較發(fā)現(xiàn)媒體能力集C"不等于媒體能力集C，，或者用戶A 用于收發(fā)媒體流的IP地址1不等于用戶A媒—體流IP地址2時，判斷需要進 行媒體重協(xié)商。步驟108、 IPCC向用戶B發(fā)送reINVITE消息。該reINVITE消息中攜帶有媒體能力集C",及用戶A媒體流IP地址2。 步驟109、用戶B返回200 OK消息給IPCC。該200 OK消息攜帶有用戶B支持的全部媒體能力同媒體能力集C"的交 集媒體能力集C"'，及用戶B媒體流IP地址2。與在步驟106出現(xiàn)的狀況一樣，可能出現(xiàn)媒體能力集C"不等于交集媒體 能力集C'",或用戶B媒體流IP地址2不等于用戶B媒體流IP地址1的狀況， 出現(xiàn)任何一種狀況都需要繼續(xù)進行媒體重協(xié)商。步驟110、 IPCC判斷需要進行媒體重協(xié)商時，繼續(xù)進行媒體重協(xié)商，直 到協(xié)商成功。在對現(xiàn)有技術的研究和實踐過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術存在以下問題在這種需要中間協(xié)調方的媒體能力重協(xié)商過程中，由于IPCC是媒體重協(xié) 商的發(fā)起者，其必須維護用戶A和用戶B間的各種協(xié)商內容。并在不一致時 還需要調整相關參數(shù)，繼續(xù)進行第二次、第三次...媒體能力重協(xié)商過程。整 個處理機制復雜，信令交互次數(shù)繁多，非常耗費系統(tǒng)資源。其次，在步驟103中IPCC在第一次發(fā)起的媒體能力重協(xié)商時攜帶的媒體 能力集C必須是用戶A的全部能力，為了保證IPCC在發(fā)起的媒體能力重協(xié) 商時攜帶的媒體能力集C能夠是用戶A的全部能力，IPCC需要全程保留用戶 A的所有能力，同時還需保存當前協(xié)商的能力交集，處理機制相對復雜。再則，由于用戶A有可能是通過網絡中其他設備連接到IPCC的，發(fā)送 到IPCC的用戶A的媒體能力集是用戶A的全部媒體能力與中轉設備媒體能 力集的交集，用戶A的部分媒體能力已經被中轉設備過濾掉，導致IPCC最 開始收到的用戶A能力就已經不是用戶A能力的全集，此時若用戶B正好只 支持用戶A中已經被網絡中其他設備過濾掉的某種媒體能力，那么原本可以正常通信的用戶A和用戶B在這種情況下就不能通信了。 發(fā)明內容本發(fā)明實施例要解決的技術問題是提供一種媒體能力重協(xié)商的方法及裝 置，在需要中間協(xié)調方的媒體能力重協(xié)商過程中，可以避免重復進行^ 某體能 力重協(xié)商，減輕中間協(xié)調方的工作量，減少由于主叫用戶的媒體能力被網絡 中其他設備過濾掉導致的重協(xié)商失敗。為解決上述技術問題，本發(fā)明實施例一方面，提供了一種媒體能力重協(xié)商的方法，所述方法包括向須進行重協(xié)商的終端發(fā)送媒體能力重協(xié)商觸發(fā)請求，指示終端發(fā)起媒 體能力重協(xié)商請求；接收所述終端發(fā)送的媒體能力重協(xié)商請求消息，向須進行重協(xié)商的其他 終端轉發(fā)所述媒體能力重協(xié)商請求消息，實現(xiàn)媒體能力重協(xié)商。另一方面，提供了一種媒體能力重協(xié)商的方法，所述方法包括第一終端在收到中間協(xié)調方發(fā)送的媒體能力重協(xié)商觸發(fā)請求時，通過所 述中間協(xié)調方與第二終端交互媒體能力重協(xié)商消息，實現(xiàn)媒體能力重協(xié)商。另一方面，提供了一種中間協(xié)調方，所述中間協(xié)調方包括觸發(fā)單元，用于在需要進行媒體能力重協(xié)商時，向須進行重協(xié)商的終端 發(fā)送媒體能力重協(xié)商觸發(fā)請求消息；接收單元，用于接收所述須進行重協(xié)商的終端發(fā)送的媒體能力重協(xié)商消息；轉發(fā)單元，用于向須進行重協(xié)商的其他終端轉發(fā)所述媒體能力重協(xié)商消息。另一方面，提供了一種終端，所述終端包括觸發(fā)重協(xié)商單元，用于接收中間協(xié)調方發(fā)送的媒體能力重協(xié)商觸發(fā)請求；重協(xié)商單元，用于通過所述中間協(xié)調方與第二終端交互媒體能力重協(xié)商 消息，實現(xiàn)媒體能力重協(xié)商。由以上技術方案可以看出，由于作為媒體能力重協(xié)商的中間協(xié)調方，在 重協(xié)商過程中，只要做簡單的消息轉發(fā)接口，無需保存任何媒體能力和進行 相關判斷，工作量得到很大減輕。
而且整個重協(xié)商過程只要交互一次就肯定能完成，不需要重復進行媒體 能力重協(xié)商，節(jié)省了信令交互，方便媒體能力重協(xié)商的實現(xiàn)。
進一步，由于重協(xié)商中通信雙方總是會重新帶上自己支持的全部媒體能 力，避免了現(xiàn)有技術中由于主叫用戶的媒體能力被網絡中其他設備過濾掉導 致的重協(xié)商失敗。


圖1為現(xiàn)有技術需要中間協(xié)調方的媒體能力重協(xié)商過程流程圖； 圖2為本發(fā)明實施例提供的媒體能力重協(xié)商的方法實施例流程圖； 圖3為本發(fā)明實施例提供的中間協(xié)調方結構示意圖； 圖4為本發(fā)明實施例提供的終端結構示意圖。
具體實施例方式
本發(fā)明實施例提供了 一種媒體能力重協(xié)商的方法及裝置，在需要中間協(xié) 調方的媒體能力重協(xié)商過程中，可以避免重復進行媒體能力重協(xié)商，減輕中 間協(xié)調方的工作量，減少由于主叫用戶的媒體能力被網絡中其他設備過濾掉 導致的重協(xié)商失敗。
本發(fā)明實施例提供的媒體能力重協(xié)商的方法實施例中，作為中間協(xié)調方 的業(yè)務中心在需要發(fā)起媒體能力重協(xié)商時，向會話中的一方發(fā)出要求發(fā)起媒 體能力重協(xié)商過程的媒體能力重協(xié)商觸發(fā)請求消息，要求其主動發(fā)起媒體能 力重協(xié)商過程；終端在收到^^某體能力重協(xié)商觸發(fā)請求消息后按照正常的重協(xié) 商流程發(fā)出請求進行重協(xié)商的消息到中間協(xié)調方，由中間協(xié)調方將請求進行 重協(xié)商的消息轉發(fā)到須進行重協(xié)商的其他終端，以完成兩個終端之間的重協(xié) 商。重協(xié)商過程中終端發(fā)出的各種消息都可以被稱為^f某體能力重協(xié)商消息。
常見的業(yè)務中心有IPCC、移動秘書臺等等，以用戶A通過IPCC與用戶 B建立呼叫，IPCC在需要進行重協(xié)商時向用戶B發(fā)送媒體能力重協(xié)商觸發(fā)請求消息為例，本發(fā)明實施例提供的媒體能力重協(xié)商的方法實施例流程如圖2所示步驟201、用戶A和IPCC建立呼叫，由IPCC通過IVR進行業(yè)務引導。步驟202、 IPCC和用戶B建立呼叫，由IPCC通過IVR進行業(yè)務引導。步驟203、 IPCC發(fā)送媒體能力重協(xié)商觸發(fā)請求消息給用戶B，要求用戶 B主動發(fā)起媒體重協(xié)商流程。媒體能力重協(xié)商觸發(fā)請求消息可以為一個按照SIP協(xié)議規(guī)定的擴展的SIP 消息(SIP INFO )，以下為SIP INFO消息格式的一種實施方式INFO sip:2143302100@172.17.2.33 SIP/2.0Via: SIP/2.0/UDP 172.80.2.100:5060From: <sip:9724401003@172.80.2.100>;tag=43To: <sip: *02800800800@172.17.2.33>;tag=9753.0207Call-ID: 984072_15401962@172.80.2.100CSeq: 25634 INFOContent-Length: 19 Content-Type: application/reNegotiationReq reNegotiationReq =...步驟204、用戶B向IPCC發(fā)送reINYITE消息。用戶B收到媒體能力重協(xié)商觸發(fā)請求消息后，按照普通媒體重協(xié)商流程 向IPCC發(fā)送reINVITE消息，該reINVITE消息中，攜帶了用戶B當前支持 的所有媒體能力C,同時攜帶了用戶B用于收發(fā)媒體流的IP地址和端口。步驟205、 IPCC將用戶B發(fā)來的reINVITE消息直接轉發(fā)給用戶A。IPCC收到用戶B的媒體重協(xié)商的reINVITE消息后，不做任何處理，直 接轉發(fā)給用戶A。步驟206、用戶A回應200 OK給IPCC。用戶A收到該reINVITE消息后，回應200 OK給IPCC，該200 OK消息 中攜帶了用戶B支持的所有媒體能力C同用戶A支持的所有媒體能力的交集 C，，同時將決定在此次媒體通信使用的媒體能力放在能力集中的首位。此外， 該200 OK消息還攜帶了 A用于收發(fā)媒體流的IP地址和端口 。
步驟207、 IPCC將用戶A發(fā)送的200 OK消息直接轉發(fā)給用戶B。
IPCC收到用戶A的200 OK消息后，不做任何處理，直接轉發(fā)給用戶B。
此時，媒體重協(xié)商完成，通過此次媒體重協(xié)商，用戶A和用戶B都知道 對方此后使用的媒體能力和傳輸媒體流的IP地址和端口 ，可以在此基礎上進 行媒體通信。
IPCC也可以向用戶A發(fā)出媒體能力重協(xié)商觸發(fā)請求消息，要求用戶A 主動發(fā)起媒體重協(xié)商流程，在這種情況下，與圖2中處理方式基本相同，在 此不再重復描述。
使用本發(fā)明實施例提供的媒體能力重協(xié)商的方法實施例后，作為媒體能 力重協(xié)商的中間協(xié)調方，在重協(xié)商過程中，IPCC只要做簡單的消息轉發(fā)接口， 無需保存任何^^某體能力和進行相關判斷。
而且整個重協(xié)商過程只要交互一次就肯定能完成，避免了現(xiàn)有技術中的 可能需要重復進行媒體能力重協(xié)商的狀況。
進一步，由于重協(xié)商中用戶A或用戶B總是會重新帶上自己支持的全部 媒體能力，避免了現(xiàn)有技術中由于由于主叫用戶的媒體能力被網絡中其他設 備過濾掉導致的重協(xié)商失敗。
本發(fā)明實施例提供的中間協(xié)調方實施例的結構如圖3所示，中間協(xié)調方 300包括
觸發(fā)單元301,用于在需要進行媒體能力重協(xié)商時，向須進行重協(xié)商的終 端發(fā)送媒體能力重協(xié)商觸發(fā)請求消息；
接收單元302,用于接收所述須進行重協(xié)商的終端發(fā)送的媒體能力重協(xié)商 消息；
轉發(fā)單元303,用于向須進行重協(xié)商的其他終端轉發(fā)所述媒體能力重協(xié)商消息。本發(fā)明實施例提供的中間協(xié)調方實施例可以由IPCC擔任，所述媒體能力 重協(xié)商消息可能為攜帶用戶媒體能力集及用戶媒體流網際協(xié)議地址和端口的請求進行重協(xié)商的消息；也可能為攜帶用戶媒體能力集及用戶媒體流網際協(xié) "i義地址和端口的響應消息。本發(fā)明實施例提供的終端實施例結構如圖4所示，包括觸發(fā)重協(xié)商單元410,用于接收中間協(xié)調方發(fā)送的媒體能力重協(xié)商觸發(fā)請求；重協(xié)商單元420,用于通過所述中間協(xié)調方與第二終端交互媒體能力重協(xié) 商消息，實現(xiàn)媒體能力重協(xié)商。添加單元430,用于在所述重協(xié)商請求消息中添加所述終端^某體流網際協(xié) i義;l也址和端口 。其中重協(xié)商單元420包括發(fā)送單元421,用于通過所述中間協(xié)調方將攜帶所述第一用戶媒體能力集 的請求進行重協(xié)商的消息轉發(fā)至第二終端；處理單元422,用于接收所述第二終端通過所述中間協(xié)調方返回的所述第 二用戶媒體能力集與所述第一用戶媒體能力集的交集，實現(xiàn)媒體能力重協(xié)商。本發(fā)明實施例提供的中間協(xié)調方實施例、及終端實施例的運行方式，與 本發(fā)明實施例提供的媒體能力重協(xié)商的方法實施例基本類似，在此不再重復 描述。使用本發(fā)明實施例提供的中間協(xié)調方實施例、終端實施例，作為媒體能 力重協(xié)商的中間協(xié)調方，在重協(xié)商過程中，IPCC只要做簡單的消息轉發(fā)接口， 無需保存任何媒體能力和進行相關判斷。而且整個重協(xié)商過程只要交互一次就肯定能完成，避免了現(xiàn)有技術中的 可能需要重復進行^^某體能力重協(xié)商的狀況。進一步，由于重協(xié)商中用戶A或用戶B會攜帶自己支持的全部媒體能力， 避免了現(xiàn)有技術中由于主叫用戶的媒體能力被網絡中其他設備過濾掉導致的重協(xié)商失敗。
本領域普通技術人員可以理解實現(xiàn)上述實施例方法中的全部或部分步驟 是可以通過程序來指令相關的硬件完成，所述的程序可以存儲于一種計算積^ 可讀存儲介質中，該程序在執(zhí)行時，包括如下步驟
一種媒體能力重協(xié)商的方法，所述方法包括
向須進行重協(xié)商的終端發(fā)送媒體能力重協(xié)商觸發(fā)請求，指示終端發(fā)起々某
體能力重協(xié)商請求；
接收所述終端發(fā)送的媒體能力重協(xié)商請求消息，向須進行重協(xié)商的其他 終端轉發(fā)所述媒體能力重協(xié)商請求消息，實現(xiàn)媒體能力重協(xié)商。 或， 一種媒體能力重協(xié)商的方法，所述方法包括
第一終端在收到中間協(xié)調方發(fā)送的媒體能力重協(xié)商觸發(fā)請求時，通過所 述中間協(xié)調方與第二終端交互媒體能力重協(xié)商消息，實現(xiàn)媒體能力重協(xié)商。
上述提到的存儲介質可以是只讀存儲器，磁盤或光盤等。
以上對本發(fā)明所提供的一種媒體能力重協(xié)商的方法及裝置進行了詳細介 紹，本文中應用了具體個例對本發(fā)明的原理及實施方式進行了闡述，以上實
域的一般技術人員，依據(jù)本發(fā)明的思想，在具體實施方式
及應用范圍上均會 有改變之處，綜上所述，本說明書內容不應理解為對本發(fā)明的限制。
權利要求
1、一種媒體能力重協(xié)商的方法，其特征在于，所述方法包括向須進行重協(xié)商的終端發(fā)送媒體能力重協(xié)商觸發(fā)請求，指示終端發(fā)起媒體能力重協(xié)商請求；接收所述終端發(fā)送的媒體能力重協(xié)商請求消息，向須進行重協(xié)商的其他終端轉發(fā)所述媒體能力重協(xié)商請求消息，實現(xiàn)媒體能力重協(xié)商。
2、 如權利要求1所述的媒體能力重協(xié)商的方法，其特征在于，所述媒體 能力重協(xié)商消息包括攜帶用戶媒體能力集及用戶媒體流網際協(xié)議地址和端口的請求進行重協(xié) 商的消息；或，攜帶用戶媒體能力集及用戶媒體流網際協(xié)議地址和端口的響應消息。
3、 如權利要求1或2所述的媒體能力重協(xié)商的方法，其特征在于，所述 ^^某體能力重協(xié)商觸發(fā)請求為會話初始協(xié)議消息。
4、 如權利要求1或2所述的i某體能力重協(xié)商的方法，其特征在于，所述 中間協(xié)調方為業(yè)務中心。
5、 一種媒體能力重協(xié)商的方法，其特征在于，所述方法包括第一終端在收到中間協(xié)調方發(fā)送的媒體能力重協(xié)商觸發(fā)請求時，通過所 述中間協(xié)調方與第二終端交互媒體能力重協(xié)商消息，實現(xiàn)媒體能力重協(xié)商。
6、 如權利要求5所述的媒體能力重協(xié)商的方法，其特征在于，所述通過 所述中間協(xié)調方與第二終端交互4某體能力重協(xié)商消息包括通過所述中間協(xié)調方將攜帶所述第一用戶媒體能力集的請求進行重協(xié)商的消息轉發(fā)至第二終端，接收所述第二終端通過所述中間協(xié)調方返回的所述 第二用戶媒體能力集與所述第一用戶媒體能力集的交集。
7、 如權利要求5或6所述的纟某體能力重協(xié)商的方法，其特征在于，所述方法還包括，在所述重協(xié)商請求消息中攜帶所述第一用戶媒體流網際協(xié)議地 址和端口 。
8、 如權利要求5或6所述的媒體能力重協(xié)商的方法，其特征在于，所述 媒體能力重協(xié)商觸發(fā)請求消息為會話初始協(xié)議消息。
9、 如權利要求5或6所述的媒體能力重協(xié)商的方法，其特征在于，所述 中間協(xié)調方為寬帶呼叫中心。
10、 一種中間協(xié)調方，其特征在于，所述中間協(xié)調方包括觸發(fā)單元，用于在需要進行媒體能力重協(xié)商時，向須進行重協(xié)商的終端 發(fā)送^ 某體能力重協(xié)商觸發(fā)請求消息；接收單元，用于接收所述須進行重協(xié)商的終端發(fā)送的媒體能力重協(xié)商消息；轉發(fā)單元，用于向須進行重協(xié)商的其他終端轉發(fā)所述媒體能力重協(xié)商消臺
11、 如權利要求9所述的中間協(xié)調方，其特征在于，所述媒體能力重協(xié) 商消息包括攜帶用戶媒體能力集及用戶媒體流網際協(xié)議地址和端口的請求進行重協(xié) 商的消息；或，攜帶用戶媒體能力集及用戶媒體流網際協(xié)議地址和端口的響應消息。
12、 一種終端，其特征在于，所述終端包括觸發(fā)重協(xié)商單元，用于接收中間協(xié)調方發(fā)送的媒體能力重協(xié)商觸發(fā)請求；重協(xié)商單元，用于通過所述中間協(xié)調方與第二終端交互媒體能力重協(xié)商 消息，實現(xiàn)媒體能力重協(xié)商。
13、 如權利要求12所述的終端，其特征在于，所述重協(xié)商單元包括發(fā)送單元，用于通過所述中間協(xié)調方將攜帶所述第一用戶媒體能力集的 請求進行重協(xié)商的消息轉發(fā)至第二終端；處理單元，用于接收所述第二終端通過所述中間協(xié)調方返回的所述第二 用戶i某體能力集與所述第一用戶^!某體能力集的交集，實現(xiàn)媒體能力重協(xié)商。
14、 如權利要求12或13所述的終端，其特征在于，所述終端還包括添加單元，用于在所述重協(xié)商請求消息中添加所述終端媒體流網際協(xié)議 地址和端口 。
全文摘要
本發(fā)明公開了一種媒體能力重協(xié)商的方法，包括向須進行重協(xié)商的終端發(fā)送媒體能力重協(xié)商觸發(fā)請求，指示終端發(fā)起媒體能力重協(xié)商請求；接收所述終端發(fā)送的媒體能力重協(xié)商請求消息，向須進行重協(xié)商的其他終端轉發(fā)所述媒體能力重協(xié)商請求消息，實現(xiàn)媒體能力重協(xié)商。本發(fā)明還公開了一種媒體能力重協(xié)商的方法，包括第一終端在收到中間協(xié)調方發(fā)送的媒體能力重協(xié)商觸發(fā)請求時，通過所述中間協(xié)調方與第二終端交互媒體能力重協(xié)商消息，實現(xiàn)媒體能力重協(xié)商。本發(fā)明還公開了相應的中間協(xié)調方及終端。本發(fā)明減輕了中間協(xié)調方的工作量，避免了重復進行媒體能力重協(xié)商。
文檔編號H04L29/06GK101222502SQ20081000702
公開日2008年7月16日 申請日期2008年1月25日 優(yōu)先權日2008年1月25日
發(fā)明者濤 宋, 霖 林, 輝 禹 申請人:華為技術有限公司