一、引言 IETF提出的會話初始協(xié)議(SIP)，是在IP網(wǎng)上進行多媒體
通信的應用層控制協(xié)議，可以用來發(fā)起、建立以及釋放會話。SIP協(xié)議靈活簡單的特性以及其靈活強大的呼叫控制的功能吸引了越來越多的廠商和運營商。SIP協(xié)議還可以與SDP協(xié)議配合使用，用來協(xié)商會話的媒體屬性，因此更易于實現(xiàn)第三方呼叫控制。
第三方呼叫控制(3pcc)指的是由第三方控制者在另外兩者之間建立一個會話，由控制者負責會話雙方的媒體協(xié)商。3pcc是一種非常靈活的控制方式，在PSTN網(wǎng)中，第三方呼叫控制通常用于會議、接線業(yè)務(接線員創(chuàng)建一個連接另外雙方的呼叫)。同樣，使用SIP協(xié)議也可以借助3pcc來完成許多業(yè)務，例如點擊撥號、通話過程中放音等等，而且實現(xiàn)起來非常方便。RFC3264中定義了一種提供/應答模式，使兩個實體之間可以使用SDP的提供/應答(offer/answer)模式進行會話協(xié)商。
二、第三方呼叫控制方法 SIP消息可以攜帶SDP消息體。SDP(會話描述協(xié)議)是用來描述與媒體流相關(guān)的參數(shù)以及與會話相關(guān)的信息，其中包括對會話的描述以及媒體類型、數(shù)據(jù)發(fā)送到的端口、傳輸協(xié)議(例如RTP)以及媒體格式(例如RTP載荷格式)的描述。3pcc的實現(xiàn)關(guān)鍵就在于控制者如何在會話雙方之間使用SDP消息協(xié)商即將建立的會話。根據(jù)SIP協(xié)議的機制，可以有下面四種方法實現(xiàn)3pcc。
1.流程Ⅰ
該流程圖中的offer和answer都是SDP消息。下面解釋消息流程。
控制者首先向用戶A發(fā)送一個沒有SDP的INVITE，A的電話振鈴，A應答之后，產(chǎn)生的
200 OK響應中將包含一個ofrerl，攜帶用戶A所希望建立會話的媒體類型、媒體格式、傳輸協(xié)議以及接收媒體流的端口和IP地址?？刂普邔碜訟的offerl包含在發(fā)給B的INVITE中，B振鈴應答之后產(chǎn)生對rfferl的應答answerl。最后控制者向用戶A發(fā)出的ACK中包含answer1作為應答。
圖1 3pcc流程Ⅰ 該流程優(yōu)點是非常簡單，不需要控制者產(chǎn)生SDP，不必考慮控制者自身對媒體類型的要求。
缺點是該流程存在著一個非常嚴重的超時問題。如果B不能立即響應，控制者就無法馬上給A發(fā)送ACK，有可能導致A定時重發(fā)200 OK。因為根據(jù)RFC3261，如果走時之后還沒有收到ACK，這次呼叫就失敗了。所以該流程只能用于用戶B可以立即對INVITE進行響應的情況下。
2.流程Ⅱ
圖2 3pcc流程Ⅱ 流程圖中的“黑洞”SDP指的是包含的連接地址是一個無效的連接地址，例如rtp.invalid或者0.0.0.0，也就是想建立一個空的媒體流，因為這個媒體流實際上并沒有媒體或者RTCP包從A流出。
該流程中，控制者首先向用戶A發(fā)送INVITE，包含SDP1，用來創(chuàng)建一個初始的“黑洞”媒體流，A振鈴并產(chǎn)生應答記為SDP2，其中包含的是一個有效的連接地址，但此時仍沒有媒體流向控制者?？刂普呦駻發(fā)出ACK。 控制者向B發(fā)送INVITE，攜帶SDP2作為對B的offer。B振鈴，應答之后產(chǎn)生的200 OK響應中包含一個SDP3，也就是對SDP2的應答?？刂普呦駼發(fā)送ACK。
控制者向A發(fā)送re-INVITE，包含SDP3作為offer。假設用戶A不想改變原來的會話屬性，在200 OK響應中包含的應答應該仍是SDP2?？刂普甙l(fā)送ACK之后，就可以有媒體從A流向B。
本流程所有的最終響應都可以被立即確認，不會有因超時而導致呼叫失敗的問題。
缺點是控制者必須預先知道本次呼叫所要使用的媒體類型，來創(chuàng)建初始的“黑洞”SDP；第二，“黑洞”SDP是一種擴展的機制，并不能確定所有的UA能否支持這種機制以及如果收到這樣的地址能做何反應；第三，流程完成的前提是假設用戶A對re-INVITE的響應中仍然包含的是SDP2。如果不是SDP2的話，控制者還需要向A再發(fā)送re-INVITE，然后有可能從B得到另一個不同的SDP，然后還需要向A再發(fā)送re-INVITE，如此等等，可能形成一個無限循環(huán)的會話協(xié)商。當然，可以采用一個智能UA，要求其固定的返回SDP2，或者采用一個智能的控制者能夠分析收到的SDP確定有無必要發(fā)送re-INVITE，但是為簡單起見，應盡量避免控制者了解SDP的具體內(nèi)容。所以實際上本流程根本就不可用。
3.流程Ⅲ
本流程中，控制者向A發(fā)送一個沒有SDP的INVITE。A應答的200 OK響應中包含一個offerl，控制者立即在ACK消息中產(chǎn)生一個“黑洞”SDP應答。
控制者再向B發(fā)送一個沒有SDP的INVITE。B應答的200 0K響應中包含一個提供offer2，控制者應該基于offer2向A發(fā)送一個re-INVITE，注意。offer2可能需要稍作修改來滿足媒體要求。例如如果offer1包含一個音頻和一個
視頻行，而offer2只有一個音頻行，控制者就需要在offer2中增加一個視頻行(端口設為O)來構(gòu)成offer2’。由于這是一個re-INVITE，所以通常應該能立即收到響應。A的200 0K響應中包含的answer2’，可能也需要稍作修改作為offer2的應答answer2?？刂普呦駻發(fā)送ACK之后，媒體就可以流通。
圖2 3pcc流程Ⅱ 流程圖中的“黑洞”SDP指的是包含的連接地址是一個無效的連接地址，例如rtp.invalid或者0.0.0.0，也就是想建立一個空的媒體流，因為這個媒體流實際上并沒有媒體或者RTCP包從A流出。
該流程中，控制者首先向用戶A發(fā)送INVITE，包含SDP1，用來創(chuàng)建一個初始的“黑洞”媒體流，A振鈴并產(chǎn)生應答記為SDP2，其中包含的是一個有效的連接地址，但此時仍沒有媒體流向控制者?？刂普呦駻發(fā)出ACK。 控制者向B發(fā)送INVITE，攜帶SDP2作為對B的offer。B振鈴，應答之后產(chǎn)生的200 OK響應中包含一個SDP3，也就是對SDP2的應答?？刂普呦駼發(fā)送ACK。
控制者向A發(fā)送re-INVITE，包含SDP3作為offer。假設用戶A不想改變原來的會話屬性，在200 OK響應中包含的應答應該仍是SDP2?？刂普甙l(fā)送ACK之后，就可以有媒體從A流向B。
本流程所有的最終響應都可以被立即確認，不會有因超時而導致呼叫失敗的問題。
缺點是控制者必須預先知道本次呼叫所要使用的媒體類型，來創(chuàng)建初始的“黑洞”SDP；第二，“黑洞”SDP是一種擴展的機制，并不能確定所有的UA能否支持這種機制以及如果收到這樣的地址能做何反應；第三，流程完成的前提是假設用戶A對re-INVITE的響應中仍然包含的是SDP2。如果不是SDP2的話，控制者還需要向A再發(fā)送re-INVITE，然后有可能從B得到另一個不同的SDP，然后還需要向A再發(fā)送re-INVITE，如此等等，可能形成一個無限循環(huán)的會話協(xié)商。當然，可以采用一個智能UA，要求其固定的返回SDP2，或者采用一個智能的控制者能夠分析收到的SDP確定有無必要發(fā)送re-INVITE，但是為簡單起見，應盡量避免控制者了解SDP的具體內(nèi)容。所以實際上本流程根本就不可用。
3.流程Ⅲ
本流程中，控制者向A發(fā)送一個沒有SDP的INVITE。A應答的200 OK響應中包含一個offerl，控制者立即在ACK消息中產(chǎn)生一個“黑洞”SDP應答。
控制者再向B發(fā)送一個沒有SDP的INVITE。B應答的200 0K響應中包含一個提供offer2，控制者應該基于offer2向A發(fā)送一個re-INVITE，注意。offer2可能需要稍作修改來滿足媒體要求。例如如果offer1包含一個音頻和一個視頻行，而offer2只有一個音頻行，控制者就需要在offer2中增加一個視頻行(端口設為O)來構(gòu)成offer2’。由于這是一個re-INVITE，所以通常應該能立即收到響應。A的200 0K響應中包含的answer2’，可能也需要稍作修改作為offer2的應答answer2?？刂普呦駻發(fā)送ACK之后，媒體就可以流通。
圖4 3pcc流程Ⅳ 綜上所述，流程I是最簡單且有效的流程。如果控制者預先知道B是自動應答的能夠立即響應，例如B是媒體
服務器、會議
服務器等等情況下，使用本流程是最好不過了。
如果控制者無法預知被叫的類型，就可以使用流程Ⅳ或者流Ⅲ來實現(xiàn)3pcc，但是一般不會使用流程Ⅱ。使用IV、Ⅲ時對控制者的智能性要求比較高。
三、3pcc應用 SIP協(xié)議的突出優(yōu)點就在于靈活的多媒體會話的控制功能，配合使用3pcc就可以比傳統(tǒng)電話網(wǎng)更加靈活方便的實現(xiàn)各種補充業(yè)務和新業(yè)務。
3pcc的應用非常廣泛，例如可以方便對信令的控制，易于實現(xiàn)點擊撥號、早期媒體放音(early media)、通話過程中播放語音通知的業(yè)務等等。
點擊撥號業(yè)務是最典型的3pcc的應用實例。用戶瀏覽網(wǎng)站時，可以直接點擊網(wǎng)頁上的鏈接地址，使用HTTP啟動控制者對客服代表和SIP用戶之間的第三方呼叫控制。然后控制者就可以使用上述四種方法在兩者之間建立起媒體會話。
通話過程中播放語音通知，可以使用控制者將媒體服務器跟正在通話的用戶之間連接起來，播放通知。
下面以播放早期放音媒體為例，選用最簡單的流程I來介紹3pcc的應用。實際應用中，應該根據(jù)具體的情況考慮使用其它流程對下圖進行修改。
Early media指的是呼叫建立之前已經(jīng)建立的會話，通常用來傳遞關(guān)于呼叫進程的語音通知。圖5便是用戶B在應答呼叫之前已經(jīng)建立了Early media媒體通道進行放音(圖中(1)處)。用戶B對呼叫進行應答之前用戶A和控制者之間，B和控制者之間都分別已經(jīng)進行過一輪媒體的交互了。當B接受呼叫之后，由于會話狀態(tài)并沒有改變，因此并不需要重新與用戶A進行SDP信令交互。
圖5 用戶B播放早期放音媒體
四、總結(jié)語
3pcc在多方通信中(例如會議)的應用也很廣泛
文章轉(zhuǎn)載地址：http://cisco.chinaitlab.com/TCP/22072.html
