亚洲欧美日韩国产精品第不页,亚洲日韩va中文字幕,国产精品一区二区高清在线

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

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

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

　　在關(guān)于SIP呼叫服務(wù)的規(guī)范協(xié)議RFC5359中，對(duì)其18個(gè)SIP呼叫流程做了完整的流程示例演示。當(dāng)然，RFC5359定義的這18個(gè)示例不是一個(gè)規(guī)范標(biāo)準(zhǔn)，這18個(gè)SIP呼叫業(yè)務(wù)僅表示根據(jù)RFC5359作者建議的最常用的18個(gè)呼叫業(yè)務(wù)，不是一個(gè)強(qiáng)制執(zhí)行的要求。這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

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

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

　　100 Trying沒有顯示

　　Via和Max-Forwards頭沒有顯示

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

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

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

　　RFC5359中可能存在的描述錯(cuò)誤，請(qǐng)用戶和官方核實(shí)

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

　　1、Call Hold

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

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

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

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

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

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

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

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

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

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

　　Bob回復(fù)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）。

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

　　2、Consultation Hold

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

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

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

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

　　Bob對(duì)Proxy執(zhí)行的F6，Proxy執(zhí)行Proxy到Alice的F7呼叫流程。Bob對(duì)Proxy發(fā)送200 OK，Proxy對(duì)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對(duì)Proxy發(fā)送 200 OK（F12），帶SDPa=reconly, 接受保持狀態(tài)。Proxy發(fā)送200 OK到Bob，執(zhí)行F13流程。

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

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

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

　　執(zhí)行對(duì)INVITE確認(rèn)流程。Carol對(duì)Proxy發(fā)送200 ok（F21），Proxy對(duì)Bob發(fā)送 200 ok（F22）。

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

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

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

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

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

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

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

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

　　3、Music on Hold

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

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

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

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

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

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

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

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

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

　　Bob回復(fù)Alice確認(rèn)ACK，無RTP語音流。此時(shí)，Bob準(zhǔn)備開始執(zhí)行音樂媒體流服務(wù)。

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

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

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

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

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

　　以上圖例中沒有顯示contact中的渲染功能標(biāo)簽，但是在RFC5359中的音樂等待（F12）中的消息細(xì)節(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接受媒體服務(wù)器的請(qǐng)求，對(duì)媒體服務(wù)器發(fā)送200 OK（F13）：

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

　　因?yàn)橐呀?jīng)播放媒體流流程開始，Alice對(duì)Bob發(fā)送BYE消息（F16）：

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

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

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

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

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

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

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

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

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

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

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

　　4、Transfer - Unattended

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

　　另外讀者一定要注意，盡管被呼叫方發(fā)送了BYE消息（F9），但是Alice和Bob之間的Dialog仍然存在，這個(gè)dialog結(jié)束是根據(jù)REFER創(chuàng)建的訂閱來決定的。訂閱的NOTIFY中包含訂閱狀態(tài)的結(jié)果消息或者NOTIFY響應(yīng)的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ì)根據(jù)以上圖例，結(jié)合具體的SIP消息和每個(gè)呼叫流程做進(jìn)一步的介紹。

　　首先，Bob呼叫Alice（F1）：

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

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

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

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

　　Bob對(duì)Alice回復(fù)202 Accepted（F6）：

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

　　Alice收到NOTIFY以后，回復(fù)200 OK（F8）：

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

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

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

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

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

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

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

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

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

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

　　[featuremap]

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

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

　　很多情況下，電話轉(zhuǎn)接失敗的概率很高，因?yàn)橛锌赡艿谌教幱诮勇牋顟B(tài)，有可能不在線等問題，或者DTMF設(shè)置不當(dāng)，轉(zhuǎn)接失敗。這些問題用戶都需要通過配置IPPBX來進(jìn)行妥善處理。

　　5、Transfer - Attended

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

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

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

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

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

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

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

　　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ù)這個(gè)問題。如果觸發(fā)的INVITE失敗，Bob必須重新使用refer帶Refer-To URL來連接Carol，但是需要支持另外一個(gè)要求條件，Replace頭中必須棄用Refer-To頭。