中国美女视频黄的全免费,唯美美女视频

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

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

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

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

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個最常用的SIP呼叫業(yè)務分別加以解釋。另外，在所有的示例中，有幾個專有說明需要提前解釋：

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

　　100 Trying沒有顯示

　　Via和Max-Forwards頭沒有顯示

　　From，To，Call-ID，Cseq，Contact，Route和 Record-Route和其他的頭依賴于實際案例

　　圖例中使用假設域名來說明用戶域名，例如，atlanta.ex.com， biloxi.ex.com和chicago.ex.com

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

　　RFC5359中可能存在的描述錯誤，請用戶和官方核實

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

　　1、Call Hold

　　Call Hold，此呼叫業(yè)務稱之為呼叫保持。呼叫保持的流程實現(xiàn)需要經(jīng)過幾個步驟來完成。以下是RFC5359中的呼叫流程圖例（25個flow）：

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

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

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

　　Bob呼叫振鈴，Alice振鈴（F4，F(xiàn)5）：

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

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

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

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

　　Bob回復ACK消息（F14/Bob->P1，F(xiàn)15/P1->Alice）。

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

　　Alice回復200 OK，發(fā)送的消息中沒有帶SDP的a=reconly。執(zhí)行F18（Alice->P1），F(xiàn)19流程（P1->Bob）。

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

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

　　然后各自發(fā)送最后的200 OK，執(zhí)行流程F24（Bob到P1），F(xiàn)25（P1到Alice）。

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

　　2、Consultation Hold

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

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

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

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

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

　　Alice到P的ACK消息，和P1到Bob的ACK消息，執(zhí)行流程F8，F(xiàn)9。

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

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

　　Bob對Proxy發(fā)送最終ACK確認，執(zhí)行F14；Proxy對Alice發(fā)送ACK確認消息，執(zhí)行F15流程。至此，呼叫保持狀態(tà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）。

　　執(zhí)行對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）。雙方開始媒體流互通。

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

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

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

　　接下來對INVITE進行確認。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）。確認完成后，雙方開始媒體流互通。

　　雙方完成呼叫以后，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）。到此為止，整個駐留呼叫保持的處理流程正式結(jié)束。

　　3、Music on Hold

　　Music on Hold（MoH），我們稱之為呼叫音樂等待或者音樂等待。顧名思義，就是在等待過程中同時對等待方播放音樂媒體或者語音提示。通過音樂等待的方式會增加用戶的體驗，讓用戶不再感覺等待時間的煩躁。RFC7088 專門定義了語音等待的規(guī)范。IPPBX的功能熱鍵可啟用MoH功能。

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

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

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

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

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

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

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

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

　　Bob回復Alice確認ACK，無RTP語音流。此時，Bob準備開始執(zhí)行音樂媒體流服務。

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

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

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

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

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

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

　　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接受媒體服務器的請求，對媒體服務器發(fā)送200 OK（F13）：

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

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

　　Bob接受來自于Alice的BYE消息，對Alice發(fā)送200 OK（F16）。

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

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

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

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

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

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

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

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

　　我們的討論中使用了一般的IPPBX媒體服務器來替換音樂媒體服務器，用戶也可以通過第三方的音樂服務的服務器端來處理音樂文件，用戶使用過程中可能可以獲得更多的體驗。另外，很多媒體服務器也可以對其播放文件實現(xiàn)自定義處理。例如，在Asterisk/FreePBX或者FreeSWITCH開源平臺都可以通過修改配置文件來實現(xiàn)自定義的MoH文件支持。

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

　　4、Transfer - Unattended

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

　　另外讀者一定要注意，盡管被呼叫方發(fā)送了BYE消息（F9），但是Alice和Bob之間的Dialog仍然存在，這個dialog結(jié)束是根據(jù)REFER創(chuàng)建的訂閱來決定的。訂閱的NOTIFY中包含訂閱狀態(tài)的結(jié)果消息或者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

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

　　首先，Bob呼叫Alice（F1）：

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

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

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

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

　　Bob對Alice回復202 Accepted（F6）：

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

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

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

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

　　根據(jù)以前的REFER消息，Bob對Carol發(fā)送INVITE消息，并且攜帶了“refer by” 的消息，說明來自于Alice的轉(zhuǎn)接（F11）：

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

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

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

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

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

　　通過16個流程的處理，一個完整的盲轉(zhuǎn)才可以完成。很多IPPBX或者媒體服務器（Asterisk/FreePBX/FreeSWITCH）都支持Blind transfer的功能熱鍵。用戶也可以通過SIP電話終端屏幕上的按鍵來實現(xiàn)轉(zhuǎn)接。

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

　　[featuremap]

　　blindxfer = #1 // FreeSWITCH使用*1實現(xiàn)盲轉(zhuǎn)。

　　atxfer = *2 // FreeSWITCH使用*4實現(xiàn)詢轉(zhuǎn)。

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

　　5、Transfer - Attended

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

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

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

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

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

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

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

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

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

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