国产a不卡片精品免费观看_最常用的18個(gè)SIP呼叫業(yè)務(wù)流程詳解完整版(一) - 文章精選

最常用的18個(gè)SIP呼叫業(yè)務(wù)流程詳解完整版（二）

　　在大部分的企業(yè)客戶(hù)的電話(huà)呼叫業(yè)務(wù)中，特別是從運營(yíng)商到企業(yè)IPPBX端的呼入業(yè)務(wù)中，有很多不同的呼叫涉及了多種SIP流程的操作，而且其流程和實(shí)際的IPPBX，代理和SIP終端存在著(zhù)非常密切的關(guān)系。排查這些技術(shù)問(wèn)題耗費相當多的時(shí)間。另外，因為越來(lái)越多的用戶(hù)開(kāi)始使用基于開(kāi)源的軟交換平臺和媒體服務(wù)器（例如，Asterisk或FreeSWITCH，Kamailio等），用戶(hù)更容易獲得技術(shù)產(chǎn)品，因此，他們更容易接觸到企業(yè)通信平臺技術(shù)，導致其入門(mén)門(mén)檻也相對比較低，技術(shù)人員可能完全不了解系統底層的流程。而且不幸的是，在實(shí)際使用過(guò)程中，很多技術(shù)人員也僅僅停留在通過(guò)系統界面配置一個(gè)呼叫業(yè)務(wù)流程，他們根本沒(méi)有了解和關(guān)注真正底層的呼叫流程和其細節，而且他們對真正的SIP消息之間的互相通信過(guò)程可能并不是非常熟悉。筆者發(fā)現，其中一個(gè)原因是他們沒(méi)有太多學(xué)習渠道獲得一些非常直觀(guān)和權威的可參考的示例。

　　大家經(jīng)常談?wù)揝IP呼叫業(yè)務(wù)，但是，究竟哪些SIP呼叫業(yè)務(wù)是企業(yè)用戶(hù)所要求的？關(guān)于SIP業(yè)務(wù)呼叫，RFC5359對18個(gè)最常用的SIP業(yè)務(wù)呼叫流程給出了完整的SIP流程圖例，這些呼叫業(yè)務(wù)為企業(yè)用戶(hù)解決方案部署提供了一個(gè)比較權威的參考。因此，筆者希望通過(guò)此文章完整列出所有18個(gè)關(guān)于SIP呼叫業(yè)務(wù)的SIP流程和其相應的圖例說(shuō)明，并且加以適當討論和說(shuō)明來(lái)解釋這些呼叫功能中可能出現的問(wèn)題或部署時(shí)應該注意到地方，以便幫助技術(shù)人員或者銷(xiāo)售工程師能夠對其產(chǎn)品或者周邊應用終端有一個(gè)完整的比較深入的理解。提醒大家，筆者的解釋和圖例介紹僅針對標準的SIP流程來(lái)加以說(shuō)明，完全以RFC5359為基礎，不會(huì )涉及其他的設備，可能有時(shí)結合開(kāi)源媒體服務(wù)器，軟交換的功能加以說(shuō)明是為了方便用戶(hù)理解和實(shí)踐。

　　在關(guān)于SIP呼叫服務(wù)的規范協(xié)議RFC5359中，對其18個(gè)SIP呼叫流程做了完整的流程示例演示。當然，RFC5359定義的這18個(gè)示例不是一個(gè)規范標準，這18個(gè)SIP呼叫業(yè)務(wù)僅表示根據RFC5359作者建議的最常用的18個(gè)呼叫業(yè)務(wù)，不是一個(gè)強制執行的要求。這18個(gè)最常用的SIP呼叫業(yè)務(wù)功能包括：

Call Hold
Consultation Hold
Music on Hold
Transfer - Unattended
Transfer - Attended
Transfer - Instant Messaging
Call Forwarding Unconditional
Call Forwarding - Busy
Call Forwarding - No Answer
3-Way Conference - Third Party Is Added
3-Way Conference - Third Party Joins
Find-Me
Call Management （Incoming Call Screening）
Call Management （Outgoing Call Screening）
Call Park
Call Pickup
Automatic Redial
Click to Dial

　　下面，我們對這18個(gè)最常用的SIP呼叫業(yè)務(wù)分別加以解釋。另外，在所有的示例中，有幾個(gè)專(zhuān)有說(shuō)明需要提前解釋?zhuān)?/div>

　　圖例中所列舉的假設用戶(hù)是Alice，Bob，Carol

　　100 Trying沒(méi)有顯示

　　Via和Max-Forwards頭沒(méi)有顯示

　　From，To，Call-ID，Cseq，Contact，Route和 Record-Route和其他的頭依賴(lài)于實(shí)際案例

　　圖例中使用假設域名來(lái)說(shuō)明用戶(hù)域名，例如，atlanta.ex.com， biloxi.ex.com和chicago.ex.com

　　Tag和Call-ID替換為響應的用戶(hù)關(guān)聯(lián)的設置方式

　　RFC5359中可能存在的描述錯誤，請用戶(hù)和官方核實(shí)

　　SIP呼叫業(yè)務(wù)的中文名稱(chēng)是筆者自己翻譯，非任何官方翻譯定義。因此，中文名稱(chēng)的準確性有待用戶(hù)自己確認

　　1、Call Hold

　　Call Hold，此呼叫業(yè)務(wù)稱(chēng)之為呼叫保持。呼叫保持的流程實(shí)現需要經(jīng)過(guò)幾個(gè)步驟來(lái)完成。以下是RFC5359中的呼叫流程圖例（25個(gè)flow）：

　　這里假設，Alice呼叫Bob，呼叫接聽(tīng)后，Bob通過(guò)終端電話(huà)按鍵Hold鍵把呼叫設置為保持狀態(tài)。然后Bob解除呼叫保持狀態(tài)，Alice掛機。注意，呼叫保持事實(shí)上是一個(gè)單向的功能。但是，執行保持的一方可以對第三方停止媒體發(fā)送，這樣可能導致雙方無(wú)媒體流交互。舊的處理方式是連接到地址0.0.0.0。現在新的處理方式是在SDP的a=中實(shí)現，a=inactive 表示無(wú)媒體發(fā)送；a=sendonly 表示仍有媒體發(fā)送。

　　注意，在F10和F11中使用了渲染功能tag（rfc4235）來(lái)表示Bob終端不再渲染，例如Bob已經(jīng)設置為保持狀態(tài)。下面，我們通過(guò)完整的流程圖附帶SIP消息的說(shuō)明來(lái)具體介紹呼叫保持的流程。

　　Alice對P1發(fā)出INVITE請求，然后通過(guò)P1呼叫Bob。

　　Bob呼叫振鈴，Alice振鈴（F4，F5）：

　　Alice收到 200 OK（F6/F7）消息：

　　Alice發(fā)送到ACK確認信息到P1（F8），然后P1發(fā)送到Bob（F9）的流程。

　　Bob對P1發(fā)出INVITE消息執行F10，然后，P1對Alice發(fā)出INVITE消息執行F11。這里，開(kāi)始雙方正式進(jìn)入呼叫保持狀態(tài)。讀者要注意，結合我們開(kāi)始時(shí)說(shuō)明的，Bob使用了渲染 tag，并且o= 的version是增加的。前面在F6，F7時(shí)仍然是2890844527，這里已經(jīng)增加到了2890844528。因為是一個(gè)RE-INVITE攜帶了a=sendonly。

　　Alice接受了呼叫保持請求，并且回復200 OK（F12, F13），在SDP中攜帶了a=reconly。

　　Bob回復ACK消息（F14/Bob->P1，F15/P1->Alice）。

　　Bob關(guān)閉呼叫保持狀態(tài)，用戶(hù)通過(guò)按鍵Hold再次關(guān)閉保持功能。RE-INVITE中的SDP沒(méi)有包括a=sendonly。執行F16（Bob到P1），F17（P1到Alice）流程。

　　Alice回復200 OK，發(fā)送的消息中沒(méi)有帶SDP的a=reconly。執行F18（Alice->P1），F19流程（P1->Bob）。

　　Bob回復ACK，執行F20（Bob到P1），F21（P1到Alice）流程。他們之間重新創(chuàng )建RTP媒體流。

　　Alice發(fā)送BYE消息到P1，P1發(fā)送BYE消息到Bob，執行流程F22和F23。

　　然后各自發(fā)送最后的200 OK，執行流程F24（Bob到P1），F25（P1到Alice）。

　　到此為止，整個(gè)呼叫保持流程結束。

　　2、Consultation Hold

　　Consultation Hold，我們稱(chēng)之為持入呼叫保持或者駐留呼叫保持。呼叫方A呼叫被呼叫方B以后，被呼叫方B將通話(huà)設置為呼叫保持狀態(tài)（通過(guò)終端的Hold鍵），然后被呼叫方B再呼叫其他第三方呼叫方C。B掛機以后，重新對被設置為呼叫保持的呼叫方A進(jìn)行操作，呼叫方A關(guān)閉呼叫保持，然后呼叫方A掛機。其流程經(jīng)過(guò)38個(gè)呼叫流程的處理。

　　這里，讀者一定要注意，駐留呼叫保持和電話(huà)轉接的區別。電話(huà)轉接（transfer）從概念上我們就可以識別清楚，在呼叫流程中涉及了轉接方或者中間方。而駐留呼叫保持中的中間方完全沒(méi)有介入其他兩個(gè)被呼叫方，他們都是各自獨立的呼叫。例如，在以上的圖例中，Alice呼叫Bob，Bob呼叫Carol。Carol和Alice沒(méi)有任何直接呼叫關(guān)系。下面，我們通過(guò)完整的流程討論分別說(shuō)明這38個(gè)呼叫流程的處理方式。

　　駐留呼叫保持同樣在F10的流程中使用了渲染tag來(lái)表示開(kāi)啟駐留呼叫保持狀態(tài)。事實(shí)上，從呼叫業(yè)務(wù)流程的控制來(lái)說(shuō)，駐留呼叫保持相對于呼叫保持，處理流程更加簡(jiǎn)單。Alice到P1的F1，P1到Bob的F2呼叫流程，發(fā)起INVITE消息。

　　雙方終端振鈴，經(jīng)過(guò)F4，F5處理流程。這里忽略了F3（Proxy到Alice的100 trying）。

　　Bob對Proxy執行的F6，Proxy執行Proxy到Alice的F7呼叫流程。Bob對Proxy發(fā)送200 OK，Proxy對Alice發(fā)送200 OK。

　　Alice到P的ACK消息，和P1到Bob的ACK消息，執行流程F8，F9。

　　開(kāi)啟RTP媒體流，然后Bob發(fā)送INVITE到P1，P1發(fā)送INVITE到Alice，執行F10，F11流程，并且表示開(kāi)啟呼叫保持狀態(tài)，使用了渲染功能表示保持狀態(tài)啟用。

　　Alice對Proxy發(fā)送 200 OK（F12），帶SDPa=reconly, 接受保持狀態(tài)。Proxy發(fā)送200 OK到Bob，執行F13流程。

　　Bob對Proxy發(fā)送最終ACK確認，執行F14；Proxy對Alice發(fā)送ACK確認消息，執行F15流程。至此，呼叫保持狀態(tài)開(kāi)啟（Bob/Alice之間）。

　　Bob呼叫Carol。Bob對Proxy發(fā)起INVITE消息（F16），Proxy對Carol發(fā)送INVITE消息（F17）。

　　這里，忽略了F18（100 trying）。Carol 對Proxy發(fā)送 180 振鈴（F19），Proxy對Bob發(fā)送180振鈴（F20）。

　　執行對INVITE確認流程。Carol對Proxy發(fā)送200 ok（F21），Proxy對Bob發(fā)送 200 ok（F22）。

　　雙方最后發(fā)送ACK確認信息。Bob發(fā)送ACK消息到Proxy（F23），Proxy發(fā)送ACK到Carol消息（F24）。雙方開(kāi)始媒體流互通。

　　經(jīng)過(guò)雙方電話(huà)互通以后，Bob首先掛機，對Proxy發(fā)送BYE消息（F25），然后Proxy對Carol發(fā)送BYE消息掛機（F26）。

　　對此次呼叫進(jìn)行最終確認掛機。Carol對Proxy發(fā)送200 OK（F27），Proxy對Bob發(fā)送200 OK（F28）。到此為止，Bob和Carol的呼叫正式結束。

　　現在開(kāi)始重新開(kāi)啟對Alice的呼叫保持狀態(tài)。重新發(fā)送INVITE消息。Bob對Proxy發(fā)送INVITE消息（F29），Proxy對Alice發(fā)送INVITE消息（F30）。

　　接下來(lái)對INVITE進(jìn)行確認。Alice對Proxy發(fā)送200 OK，接受INVITE。Proxy對Bob發(fā)送200 OK。

　　Bob收到200 OK以后，對此次INVITE發(fā)送最終確認的ACK消息。Bob對Proxy發(fā)送ACK（F33），然后Proxy對Alice發(fā)送ACK（F34）。確認完成后，雙方開(kāi)始媒體流互通。

　　雙方完成呼叫以后，Alice發(fā)送對proxyBYE消息（F35），Proxy對Bob發(fā)送BYE消息（F36）。

　　最后，確認雙方的BYE消息，互相發(fā)送最后的200 OK。Bob對Proxy發(fā)送200 OK（F37），Proxy對Alice發(fā)送200 OK（F38）。到此為止，整個(gè)駐留呼叫保持的處理流程正式結束。

　　3、Music on Hold

　　Music on Hold（MoH），我們稱(chēng)之為呼叫音樂(lè )等待或者音樂(lè )等待。顧名思義，就是在等待過(guò)程中同時(shí)對等待方播放音樂(lè )媒體或者語(yǔ)音提示。通過(guò)音樂(lè )等待的方式會(huì )增加用戶(hù)的體驗，讓用戶(hù)不再感覺(jué)等待時(shí)間的煩躁。RFC7088 專(zhuān)門(mén)定義了語(yǔ)音等待的規范。IPPBX的功能熱鍵可啟用MoH功能。

　　音樂(lè )等待具體的實(shí)現方式是，當呼叫方（Alice）呼叫被呼叫方（Bob）后，接聽(tīng)以后，被呼叫方用戶(hù)（Bob）設置此呼叫為等待狀態(tài)，在等待狀態(tài)時(shí)，通過(guò)媒體服務(wù)器對呼叫方播放音樂(lè )，或者其他的自定義的語(yǔ)音流。被呼叫方通過(guò)對媒體服務(wù)器或者音樂(lè )播放服務(wù)器發(fā)送一個(gè)REFER消息，攜帶呼叫方信息。然后媒體服務(wù)器對呼叫方發(fā)起INVITE，替換已經(jīng)創(chuàng )建的會(huì )話(huà)中的被呼叫方。然后，媒體服務(wù)器對被呼叫方（Alice）發(fā)送音樂(lè )媒體流服務(wù)。一定時(shí)間后，Bob重新設置等待的呼叫，對呼叫方（Alice）發(fā)送INVITE消息，然后替換會(huì )話(huà)中的媒體服務(wù)器，變成Bob和Alice之間的通話(huà)。注意，這里仍然使用了渲染功能，但是在F5流程中實(shí)現，表示其等待狀態(tài)開(kāi)啟。如果Alice拒絕對端的音樂(lè )播放，則Alice仍然會(huì )處于等待功能，但是會(huì )是靜音狀態(tài)（無(wú)聲音）。

　　通過(guò)以上呼叫流程我們知道，完成音樂(lè )等待流程處理需要23個(gè)flows。其中，F5開(kāi)啟音樂(lè )等待功能，F12開(kāi)始媒體服務(wù)器替換了Bob，媒體服務(wù)器對Alice發(fā)送音樂(lè )數據流確認。在F12的流程中使用了渲染功能，增加了對automation和byeless功能標簽的支持。關(guān)于automation tag 的功能在rfc3840中定義，關(guān)于byeless tag 的支持在rfc4235中定義。rfc3840定義了媒體服務(wù)器的能力支持，rfc4235定義了自動(dòng)對話(huà)事件包管理機制。具體的細節讀者可以參考鏈接資源。以下是一個(gè)完整的音樂(lè )等待的呼叫流程，配合了SIP消息。我們根據此圖例來(lái)進(jìn)一步說(shuō)明具體的呼叫流程。

　　首先是Alice對Bob發(fā)送INVITE消息（F1），表示要對Bob進(jìn)行呼叫。

　　Bob對Alice發(fā)送180 振鈴消息（F2）：

　　緊接著(zhù)，Bob對Alice發(fā)送200 OK消息（F3）：

　　Alice對Bob發(fā)送確認ACK（F4），開(kāi)始語(yǔ)音流傳輸通話(huà)。

　　之后，Bob把Alice呼叫設置為音樂(lè )等待。Bob重新發(fā)送一個(gè)新的INVITE攜帶了SDP，并且包含了一個(gè)a=sendonly，表示等待開(kāi)啟。執行F5流程。

　　然后，Alice回復Bob 200 OK消息（F6），在SDP中增加了a=reconly 表示接受等待。

　　Bob回復Alice確認ACK，無(wú)RTP語(yǔ)音流。此時(shí)，Bob準備開(kāi)始執行音樂(lè )媒體流服務(wù)。

　　Bob對媒體服務(wù)器發(fā)送REFER消息，通知媒體服務(wù)器使用Alice替換Bob。

　　媒體服務(wù)器對Bob發(fā)送202 消息，表示接受這個(gè)請求（F9）。

　　然后媒體服務(wù)器發(fā)送NOTIFY消息（F10）：

　　Bob發(fā)送200 OK（F11）：

　　接下來(lái)，媒體服務(wù)器對Alice發(fā)送INVITE消息，替換Bob（F12），注意這里的SIP消息中增加了渲染功能的支持，包括automation和byeless功能標簽，需要啟用事件包處理，媒體服務(wù)器能力支持等渲染功能。

　　以上圖例中沒(méi)有顯示contact中的渲染功能標簽，但是在RFC5359中的音樂(lè )等待（F12）中的消息細節是：

　　F12 INVITE Music Server -> Alice

　　INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0

　　Via: SIP/2.0/TLS server.example.com:5061

　　;branch=z9hG4bK74rf

　　Max-Forwards: 70

　　From: ;tag=0111

　　To:

　　Call-ID: a5-75-34-12-76@server.example.com

　　CSeq: 1 INVITE

　　Referred-By: Contact: ;automaton

　　;+sip.byeless;+sip.rendering="no"

　　Require: replaces

　　Replaces: 12345600@atlanta.example.com

　　;from-tag=23431;to-tag=1234567

　　Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

　　Supported: replaces

　　Content-Type: application/sdp

　　Content-Length: …

　　Alice接受媒體服務(wù)器的請求，對媒體服務(wù)器發(fā)送200 OK（F13）：

　　媒體服務(wù)器收到200 OK以后，對Alice發(fā)送確認ACK消息（F14），然后對Alice發(fā)送音樂(lè )媒體流，Alice現在可以聽(tīng)到媒體服務(wù)器對Alice播放的音樂(lè )文件。

　　因為已經(jīng)播放媒體流流程開(kāi)始，Alice對Bob發(fā)送BYE消息（F16）：

　　Bob接受來(lái)自于A(yíng)lice的BYE消息，對Alice發(fā)送200 OK（F16）。

　　媒體服務(wù)器對Bob發(fā)送NOTIFY消息（F17），表示媒體播放成功，并且包含一個(gè)200 OK的響應消息。

　　Bob對媒體服務(wù)器響應了一個(gè)200 OK（F18），表示收到此提示，同時(shí)包含了dialog的確認內容，包括了REFER需要的call-id，to tga和from tag。

　　到此為止，Alice被完全駐留在媒體服務(wù)器的會(huì )話(huà)中。接下來(lái)，Bob可能需要重新接聽(tīng)Alice的電話(huà)，那么，Bob就會(huì )重新對Alice發(fā)送INVITE請求消息（F19），然后替換會(huì )話(huà)中的媒體服務(wù)器。

　　Alice對Bob回復200 OK消息，表示接受替換，重新恢復到通話(huà)狀態(tài)（F20）。

　　Bob最后對Alice回復確認ACK（F21），可以恢復正常通話(huà)狀態(tài)。

　　雙方通話(huà)以后，因為媒體服務(wù)器仍然和Alice有會(huì )話(huà)的綁定關(guān)系，因此為了結束媒體播放，Alice仍然需要對媒體服務(wù)器發(fā)送一個(gè)BYE消息，表示音樂(lè )等待播放結束（F22）：

　　媒體服務(wù)器收到200 OK以后，對Alice發(fā)送一個(gè)最后的200 OK（F23），告知媒體服務(wù)器已經(jīng)收到Alice的響應，媒體服務(wù)器正式釋放被駐留在媒體服務(wù)器的會(huì )話(huà)，解除Alice對媒體服務(wù)器的綁定關(guān)系。Bob和Alice的正常通話(huà)才算成功完成，雙方開(kāi)始正式的通話(huà)過(guò)程。

　　在音樂(lè )等待的處理流程中使用了REFER的method來(lái)幫助處理音樂(lè )等待，具體的RFER規范在RFC3515中定義，讀者可以查閱學(xué)習。

　　我們的討論中使用了一般的IPPBX媒體服務(wù)器來(lái)替換音樂(lè )媒體服務(wù)器，用戶(hù)也可以通過(guò)第三方的音樂(lè )服務(wù)的服務(wù)器端來(lái)處理音樂(lè )文件，用戶(hù)使用過(guò)程中可能可以獲得更多的體驗。另外，很多媒體服務(wù)器也可以對其播放文件實(shí)現自定義處理。例如，在A(yíng)sterisk/FreePBX或者FreeSWITCH開(kāi)源平臺都可以通過(guò)修改配置文件來(lái)實(shí)現自定義的MoH文件支持。

　　在上面的討論中，我們僅根據呼叫流程的正常狀態(tài)說(shuō)明的整個(gè)MoH的處理過(guò)程。實(shí)際上，在MOH的實(shí)際部署過(guò)程中，讀者會(huì )遇到很多的其他的技術(shù)問(wèn)題。例如，播放文件的格式支持問(wèn)題，終端兼容性問(wèn)題，語(yǔ)音播放的帶寬消耗問(wèn)題，音樂(lè )播放的服務(wù)會(huì )話(huà)的管理問(wèn)題，回復消息失敗問(wèn)題等。所以，一般的MoH功能僅在內網(wǎng)環(huán)境下使用一般不會(huì )出現太多問(wèn)題。但是，如果通過(guò)第三方的媒體平臺提供所謂比較靈活的媒體播放業(yè)務(wù)，讀者一定要注意以上問(wèn)題。

　　4、Transfer - Unattended

　　Transfer - Unattended或者Blind Transfer，我們稱(chēng)之為呼叫盲轉功能。呼叫盲轉簡(jiǎn)單來(lái)說(shuō)，就是A呼叫B，然后B把A轉接到C，B掛機。A會(huì )對B報告一個(gè)NOTIFY消息，表示成功轉接。如果轉接C失敗，A會(huì )對B重新創(chuàng )建INVITE請求。以下是一個(gè)盲轉呼叫示例流程圖：

　　另外讀者一定要注意，盡管被呼叫方發(fā)送了BYE消息（F9），但是Alice和Bob之間的Dialog仍然存在，這個(gè)dialog結束是根據REFER創(chuàng )建的訂閱來(lái)決定的。訂閱的NOTIFY中包含訂閱狀態(tài)的結果消息或者NOTIFY響應的481：

　　F15 NOTIFY Bob -> Alice

　　NOTIFY sips:alice@client.atlanta.example.com SIP/2.0

　　Via: SIP/2.0/TLS client.biloxi.example.com:5061

　　;branch=z9hG4bKnashds67

　　Max-Forwards: 70

　　From: Bob ;tag=314159

　　To: Alice ;tag=1234567

　　Call-ID: 12345601@atlanta.example.com

　　CSeq: 3 NOTIFY

　　Event: refer Subscription-State: terminated;reason=noresource

　　Contact:

　　Content-Type: message/sipfrag

　　我們會(huì )根據以上圖例，結合具體的SIP消息和每個(gè)呼叫流程做進(jìn)一步的介紹。

　　首先，Bob呼叫Alice（F1）：

　　然后Alice對Bob回復一個(gè)180 振鈴（F2）：

　　緊接著(zhù)，Alice繼續對Bob發(fā)送一個(gè)200 OK（F3）：

　　Bob對Alice發(fā)送ACK確認消息，然后雙方執行RTP媒體流交互，開(kāi)始通話(huà)。

　　通話(huà)后，Alice需要把Bob電話(huà)轉接到Carol第三方（F5）：

　　Bob對Alice回復202 Accepted（F6）：

　　然后Bob對Alice發(fā)送NOTIFY（F7），創(chuàng )建訂閱消息包：

　　Alice收到NOTIFY以后，回復200 OK（F8）：

　　緊接著(zhù)，Alice會(huì )繼續對Bob發(fā)送一個(gè)BYE消息（F9）：此時(shí)RTP媒體流已經(jīng)中斷，雙方不再繼續通話(huà)。

　　Bob也根據收到的BYE消息，對Alice發(fā)送一個(gè)200 OK消息（F10），到此為止，雙方語(yǔ)音完全斷開(kāi)。根據我們上面的討論，事實(shí)上，雙方仍然存在一個(gè)訂閱關(guān)系，因為電話(huà)轉接（Bob被轉接到Carol）是否成功仍然沒(méi)有進(jìn)行最后的確定。接下來(lái)，Bob電話(huà)被轉接到Carol。呼叫流程開(kāi)始執行真正的電話(huà)轉接流程。

　　根據以前的REFER消息，Bob對Carol發(fā)送INVITE消息，并且攜帶了“refer by” 的消息，說(shuō)明來(lái)自于A(yíng)lice的轉接（F11）：

　　Carol然后對Bob發(fā)送180振鈴（F12）：

　　緊接著(zhù)，Carol對Bob發(fā)送200 OK（F13）：

　　Bob收到200 OK以后，發(fā)送ACK確認（F14），雙方正式開(kāi)始通話(huà)。

　　現在，為了保持訂閱關(guān)系的一致性，Bob需要給Alice發(fā)送一個(gè)NOTIFY（F15），通知Alice，Bob和Carol轉接成功，可以正常通話(huà)。這里，也可能Alice忽略這些訂閱消息。

　　Alice最后發(fā)送200 OK（F16），Bob和Carol進(jìn)行通話(huà)。

　　通過(guò)16個(gè)流程的處理，一個(gè)完整的盲轉才可以完成。很多IPPBX或者媒體服務(wù)器（Asterisk/FreePBX/FreeSWITCH）都支持Blind transfer的功能熱鍵。用戶(hù)也可以通過(guò)SIP電話(huà)終端屏幕上的按鍵來(lái)實(shí)現轉接。

　　例如，在示例的呼叫中，Bob呼叫Alice，Alice就可以通過(guò)功能熱鍵實(shí)現電話(huà)轉接功能。例如，在asterisk中定義的盲轉方式：

　　[featuremap]

　　blindxfer = #1 // FreeSWITCH使用*1實(shí)現盲轉。

　　atxfer = *2 // FreeSWITCH使用*4實(shí)現詢(xún)轉。

　　很多情況下，電話(huà)轉接失敗的概率很高，因為有可能第三方處于接聽(tīng)狀態(tài)，有可能不在線(xiàn)等問(wèn)題，或者DTMF設置不當，轉接失敗。這些問(wèn)題用戶(hù)都需要通過(guò)配置IPPBX來(lái)進(jìn)行妥善處理。

　　5、Transfer - Attended

　　Transfer - Attended，我們稱(chēng)之為呼叫詢(xún)轉。簡(jiǎn)單來(lái)說(shuō)，Alice呼叫Bob，通過(guò)通話(huà)，Alice可能需要把電話(huà)轉接到Carol，然后Bob把Alice設置為等待狀態(tài)。Bob繼續呼叫Carol，同時(shí)對Carol說(shuō)明Bob需要把電話(huà)轉接給Alice。同時(shí)，Bob與Carol的通話(huà)接通后，替換雙方之間的會(huì )話(huà)。Carol然后對Bob掛機。然后Alice對Bob發(fā)送一個(gè)報告，說(shuō)明Alice和Carol的電話(huà)轉接已經(jīng)成功。然后Bob對Alice掛機。

　　通過(guò)上面的介紹，讀者可能已經(jīng)發(fā)現，Transfer-Unattended（Blind Transfer）和Transfer-Attended之間有所不同的。最大的不同之處在于盲轉過(guò)程中，電話(huà)轉接到終端不會(huì )詢(xún)問(wèn)第三方是否可以轉接，不關(guān)心轉接到第三方是否同意或者接受這個(gè)電話(huà)轉接（所以稱(chēng)之為“盲”）。而詢(xún)轉則有所不同，它和會(huì )轉接到第三方提前詢(xún)問(wèn)，是否接受這個(gè)電話(huà)的轉接，然后再進(jìn)行電話(huà)轉接流程（所以稱(chēng)之為“詢(xún)”）。

　　另外，在上面的例子中，Bob插入了Replace 頭 Refer-To URL。具體的Replace 頭的規范，讀者可以參考RFC3891。注意，Refer-To URL是一個(gè)Contact URL，它是詢(xún)轉接受方（Carol）在F10中返回的200 OK響應消息中的Contact URL。這樣可以保證正確的Carol的URL可達。在F10流程中，Contact URL中的參數gr表示Contact URL是一個(gè)GRUU，它表示是一個(gè)dialog之外的全球路由方式（RFC5627）。

　　GRUU具有以下幾個(gè)特征，首先，它定義了指定的具體的用戶(hù)代理。其次，從理論上來(lái)說(shuō)，可以支持全球路由方式。最后，它的存活周期很長(cháng)。我們簡(jiǎn)單查看一下關(guān)于GRUU的使用方式。如果支持了GRUU的SIP終端登錄的話(huà)，其請求可能被復制出幾個(gè)不同的終端設備地址。

　　但是，如果對某一臺指定的設備發(fā)送請求消息的話(huà)，請求消息會(huì )根據不同的設備URL來(lái)發(fā)送，它會(huì )專(zhuān)門(mén)發(fā)送到指定的終端設備，例如，sip:user@domain;opaque=user:epid:UghFocauauCHBHoLhAAA;gruu

　　發(fā)送到其他終端以后，那么，其他的設備就不會(huì )收到這個(gè)請求消息。

　　在一些關(guān)于SIP的其他應用中，例如SBC的部署環(huán)境中，GRUU也支持了公開(kāi)的GRUU和臨時(shí)的GRUU，區別在于其存活周期的設定不同。具體的語(yǔ)法示例如下：

　　pub-gruu=" Sip:userA@home.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

　　;temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@home.net;gr";

　　在詢(xún)轉過(guò)程中，如果示例中的Bob不知道Contact URL中的gruu，Bob必須自己修復這個(gè)問(wèn)題。如果觸發(fā)的INVITE失敗，Bob必須重新使用refer帶Refer-To URL來(lái)連接Carol，但是需要支持另外一個(gè)要求條件，Replace頭中必須棄用Refer-To頭。