對SIP協議第三方呼叫控制的研究

2019-11-03 19:24:00

字體：大中小

來源：轉載

供稿：網友

林美玉　王立言

一、引言

　　IETF提出的會話初始協議(Sip)，是在IP網上進行多媒體通信的應用層控制協議，可以用來發起、建立以及釋放會話。SIP協議靈活簡單的特性以及其靈活強大的呼叫控制的功能吸引了越來越多的廠商和運營商。SIP協議還可以與SDP協議配合使用，用來協商會話的媒體屬性，因此更易于實現第三方呼叫控制。

　　第三方呼叫控制(3pcc)指的是由第三方控制者在另外兩者之間建立一個會話，由控制者負責會話雙方的媒體協商。3pcc是一種非常靈活的控制方式，在PSTN網中，第三方呼叫控制通常用于會議、接線業務(接線員創建一個連接另外雙方的呼叫)。同樣，使用SIP協議也可以借助3pcc來完成許多業務，例如點擊撥號、通話過程中放音等等，而且實現起來非常方便。RFC3264中定義了一種提供/應答模式，使兩個實體之間可以使用SDP的提供/應答(offer/answer)模式進行會話協商。

二、第三方呼叫控制方法

　　SIP消息可以攜帶SDP消息體。SDP(會話描述協議)是用來描述與媒體流相關的參數以及與會話相關的信息，其中包括對會話的描述以及媒體類型、數據發送到的端口、傳輸協議(例如RTP)以及媒體格式(例如RTP載荷格式)的描述。3pcc的實現關鍵就在于控制者如何在會話雙方之間使用SDP消息協商即將建立的會話。根據SIP協議的機制，可以有下面四種方法實現3pcc。

　　1.流程Ⅰ

　　該流程圖中的offer和answer都是SDP消息。下面解釋消息流程。

　　控制者首先向用戶A發送一個沒有SDP的INVITE，A的電話振鈴，A應答之后，產生的200 OK響應中將包含一個ofrerl，攜帶用戶A所希望建立會話的媒體類型、媒體格式、傳輸協議以及接收媒體流的端口和IP地址?？刂普邔碜訟的offerl包含在發給B的INVITE中，B振鈴應答之后產生對rfferl的應答answerl。最后控制者向用戶A發出的ACK中包含answer1作為應答。

圖1　3pcc流程Ⅰ

　　該流程優點是非常簡單，不需要控制者產生SDP，不必考慮控制者自身對媒體類型的要求。

　　缺點是該流程存在著一個非常嚴重的超時問題。如果B不能立即響應，控制者就無法馬上給A發送ACK，有可能導致A定時重發200 OK。因為根據RFC3261，如果走時之后還沒有收到ACK，這次呼叫就失敗了。所以該流程只能用于用戶B可以立即對INVITE進行響應的情況下。

　　2.流程Ⅱ

圖2　3pcc流程Ⅱ

　　流程圖中的“黑洞”SDP指的是包含的連接地址是一個無效的連接地址，例如rtp.invalid或者0.0.0.0，也就是想建立一個空的媒體流，因為這個媒體流實際上并沒有媒體或者RTCP包從A流出。

　　該流程中，控制者首先向用戶A發送INVITE，包含SDP1，用來創建一個初始的“黑洞”媒體流，A振鈴并產生應答記為SDP2，其中包含的是一個有效的連接地址，但此時仍沒有媒體流向控制者?？刂普呦駻發出ACK。　控制者向B發送INVITE，攜帶SDP2作為對B的offer。B振鈴，應答之后產生的200 OK響應中包含一個SDP3，也就是對SDP2的應答。控制者向B發送ACK。

　　控制者向A發送re-INVITE，包含SDP3作為offer。假設用戶A不想改變原來的會話屬性，在200 OK響應中包含的應答應該仍是SDP2?？刂普甙l送ACK之后，就可以有媒體從A流向B。

　　本流程所有的最終響應都可以被立即確認，不會有因超時而導致呼叫失敗的問題。

　　缺點是控制者必須預先知道本次呼叫所要使用的媒體類型，來創建初始的“黑洞”SDP；第二，“黑洞”SDP是一種擴展的機制，并不能確定所有的UA能否支持這種機制以及如果收到這樣的地址能做何反應；第三，流程完成的前提是假設用戶A對re-INVITE的響應中仍然包含的是SDP2。如果不是SDP2的話，控制者還需要向A再發送re-INVITE，然后有可能從B得到另一個不同的SDP，然后還需要向A再發送re-INVITE，如此等等，可能形成一個無限循環的會話協商。當然，可以采用一個智能UA，要求其固定的返回SDP2，或者采用一個智能的控制者能夠分析收到的SDP確定有無必要發送re-INVITE，但是為簡單起見，應盡量避免控制者了解SDP的具體內容。所以實際上本流程根本就不可用。

　　3.流程Ⅲ

　　本流程中，控制者向A發送一個沒有SDP的INVITE。A應答的200 OK響應中包含一個offerl，控制者立即在ACK消息中產生一個“黑洞”SDP應答。

　　控制者再向B發送一個沒有SDP的INVITE。B應答的200 0K響應中包含一個提供offer2，控制者應該基于offer2向A發送一個re-INVITE，注意。offer2可能需要稍作修改來滿足媒體要求。例如如果offer1包含一個音頻和一個視頻行，而offer2只有一個音頻行，控制者就需要在offer2中增加一個視頻行(端口設為O)來構成offer2’。由于這是一個re-INVITE，所以通常應該能立即收到響應。A的200 0K響應中包含的answer2’，可能也需要稍作修改作為offer2的應答answer2?？刂普呦駻發送ACK之后，媒體就可以流通。

圖3　3pcc流程Ⅲ

　　本流程沒有消息重發或者超時的問題(但是如果UA不能對re-INVITE立即進行響應，還是會出現這種問題)，而且不需要控制者預知用戶本次呼叫所使用的媒體類型。

　　缺點：首先是控制者需要對SDP進行操作，按照接收到的offer1構建一個具有相同媒體組成的“黑洞”answer1,還要對offer2進行重排列或者修改，構建一個適合用戶A的offer2’。來自B的offer2可能跟來自A的offerl沒有相同的編解碼或者媒體流，控制者需要識別這一情況并能及時的結束呼叫。第四，需要使用擴展的invalid機制，UA有可能不支持。第五，該流程復雜的多，除了信令的交互相對流程I較多外，主要表現在對控制者要求較高，增加了控制者的復雜性。

　　4.流程Ⅳ

　　本流程實際上是流程Ⅲ的簡化版，消息流程完全相同，只有SDP的組成不同。初始的INVITE中的SDP沒有m行，這表明本次會話所用的媒體需要在隨后的re-INVITE中建立。后面流程跟流程Ⅲ完全相同，但是將offer2轉變成offer2’還有answer2’轉變成answer2比流程Ⅲ簡單多了，因為根本不需要再對媒體行進行任何操作了。

　　缺點：首先是要得到answerl，就需要用戶A在沒有任何媒體的情況下就被振鈴，用戶A將不能根據媒體類型來決定是否拒絕該請求。第二點，如果A、B之間經過協商發現并沒有共同的媒體類型，而在得知這一情況之前，A、B都已經響應了呼叫請求(發出了200 OK)，所以除了擾民之外還將引發收費混亂的問題。

圖4　3pcc流程Ⅳ

　　綜上所述，流程I是最簡單且有效的流程。如果控制者預先知道B是自動應答的能夠立即響應，例如B是媒體服務器、會議服務器等等情況下，使用本流程是最好不過了。

　　如果控制者無法預知被叫的類型，就可以使用流程Ⅳ或者流Ⅲ來實現3pcc，但是一般不會使用流程Ⅱ。使用IV、Ⅲ時對控制者的智能性要求比較高。

三、3pcc應用

　　SIP協議的突出優點就在于靈活的多媒體會話的控制功能，配合使用3pcc就可以比傳統電話網更加靈活方便的實現各種補充業務和新業務。

　　3pcc的應用非常廣泛，例如可以方便對信令的控制，易于實現點擊撥號、早期媒體放音(early media)、通話過程中播放語音通知的業務等等。

　　點擊撥號業務是最典型的3pcc的應用實例。用戶瀏覽網站時，可以直接點擊網頁上的鏈接地址，使用HTTP啟動控制者對客服代表和SIP用戶之間的第三方呼叫控制。然后控制者就可以使用上述四種方法在兩者之間建立起媒體會話。

　　通話過程中播放語音通知，可以使用控制者將媒體服務器跟正在通話的用戶之間連接起來，播放通知。

　　下面以播放早期放音媒體為例，選用最簡單的流程I來介紹3pcc的應用。實際應用中，應該根據具體的情況考慮使用其它流程對下圖進行修改。

　　Early media指的是呼叫建立之前已經建立的會話，通常用來傳遞關于呼叫進程的語音通知。圖5便是用戶B在應答呼叫之前已經建立了Early media媒體通道進行放音(圖中(1)處)。用戶B對呼叫進行應答之前用戶A和控制者之間，B和控制者之間都分別已經進行過一輪媒體的交互了。當B接受呼叫之后，由于會話狀態并沒有改變，因此并不需要重新與用戶A進行SDP信令交互。

圖5　用戶B播放早期放音媒體

四、總結語

　　3pcc在多方通信中(例如會議)的應用也很廣泛，SIP協議的3pcc功能應用靈活，使用一個控制者可以將多個用戶聯系起來進行通信，方便管理。但是目前3pcc實現上還有一些標準無法統一的問題，例如如何創建一個無效連接地址的SDP，亟待解決。目前我國正在積極的開展關于SIP協議對呼叫控制方面標準的制定，第三方呼叫控制作為呼叫控制的一個重要方面，也將成為一個不可或缺的研究重點。

摘自　泰爾網

上一篇：網絡處理器平臺之設計與應用

下一篇：兩大業務主線支撐多元數據網