您當(dāng)前的位置是：  首頁(yè) > 新聞 > 文章精選 >
 首頁(yè) > 新聞 > 文章精選 >

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

2019-01-30 14:37:32   作者：   來(lái)源：CTI論壇   評(píng)論：0 　點(diǎn)擊：

　　Carol回復(fù)Bob一個(gè)180振鈴（F9）：
　　緊接著，Carol回復(fù)Bob一個(gè)200 OK（F10）。注意，這里的參數(shù)已經(jīng)增加了一個(gè)gruu。
　　Bob對(duì)Carol回復(fù)了一個(gè)ACK確認(rèn)消息（F11），開始媒體流。
　　經(jīng)過(guò)Bob和Carol通話以后，Bob告訴Carol，Alice想和Carol直接通話，Carol同樣和Alice通話。Bob將此通話設(shè)置為等待狀態(tài)，邀請(qǐng)Alice和Carol通話。
　　Carol對(duì)Bob發(fā)送200 OK（F13）：
　　Bob收到Carol的ACK消息（F14），Bob和Carol最終確定轉(zhuǎn)接。
　　然后Bob對(duì)Alice發(fā)送REFER消息，開始通知Carol的地址：
　　Alice收到202 接受消息（F16），表示接受這個(gè)轉(zhuǎn)接。
　　緊接著，Alice繼續(xù)對(duì)Bob發(fā)送NOTIFY消息（F17），通知Bob一個(gè)訂閱事件，告知Alice電話轉(zhuǎn)接的流程處理狀態(tài)。
　　Bob收到Alice 200 OK（F18）：
　　獲悉了Bob已經(jīng)知道訂閱事件以后，Alice開始對(duì)Carol發(fā)送INVITE請(qǐng)求（F19），并且替換了Bob。
　　Carol對(duì)Alice 發(fā)送200 OK（F20）：
　　然后，Alice對(duì)Carol發(fā)送ACK確認(rèn)消息（F21），開始RTP語(yǔ)音流，轉(zhuǎn)接完成。
　　因?yàn)椋珹lice和Carol已經(jīng)開始RTP流的交互，所以緊接著，Carol需要對(duì)Bob進(jìn)行掛機(jī)處理。因此，Carol對(duì)Bob發(fā)送BYE消息，雙方掛機(jī)（F22）。
　　Bob對(duì)Carol發(fā)送200 OK，執(zhí)行掛機(jī)處理（F22）：
　　到現(xiàn)在為止，Alice仍然需要告訴Bob電話轉(zhuǎn)接狀態(tài)。因此，Alice對(duì)Bob發(fā)送第二個(gè)NOTIFY事件，通知Bob電話已經(jīng)完全成功轉(zhuǎn)接（F24）：
　　Bob發(fā)送一個(gè) 200 OK消息，表示收到此事件（F25）：
　　然后Bob對(duì)Alice掛機(jī)，發(fā)送BYE消息（F26）：
　　最后，Alice對(duì)Bob發(fā)送200 OK（F27），詢轉(zhuǎn)正式流程結(jié)束。
　　6、Transfer - Instant Messaging
　　Transfer - Instant Messaging，我們稱之為即時(shí)消息轉(zhuǎn)發(fā)。其主要的工作方式是，首先用戶Alice和Bob創(chuàng)建了一個(gè)會(huì)話，然后Bob呼叫Carol，Bob發(fā)送即時(shí)消息給Carol，即時(shí)消息中包含一個(gè)Alice的URL和一個(gè)嵌入的Replace頭。如果Carol點(diǎn)擊這個(gè)URL鏈接，Carol的SIP終端會(huì)對(duì)Alice發(fā)送一個(gè)INVITE請(qǐng)求，并且替換了會(huì)話中的Bob。在這個(gè)示例中，其URL傳遞是使用的SIP MESSAGE method來(lái)實(shí)現(xiàn)（參考RFC3428），也可以使用其他IM即時(shí)協(xié)議來(lái)完成Bob和Carol之間的URL傳遞工作。具體的處理流程經(jīng)過(guò)11個(gè)步驟：
　　現(xiàn)在，我們配合SIP消息來(lái)進(jìn)一步說(shuō)明如何實(shí)現(xiàn)即時(shí)消息轉(zhuǎn)發(fā)方式。
　　首先，Alice對(duì)Bob發(fā)送INVITE消息（F1）：
　　Bob回復(fù)180（F2） ：
　　緊接著Bob對(duì)Alice發(fā)送 200 OK（F3）：
　　Alice對(duì)Bob發(fā)送Ack確認(rèn)，開始RTP流（F4）：
　　然后Bob對(duì)Carol發(fā)送一個(gè)message call（F5），在這個(gè)即時(shí)消息中攜帶了Alice的URL和Replaces頭。
　　Carol看到以后，發(fā)送一個(gè)200 OK給Bob：
　　接下來(lái)，Carol點(diǎn)擊URL，控制這個(gè)呼叫，對(duì)Alice發(fā)送一個(gè)INVITE請(qǐng)求，并且替換了Bob（F7）。
　　Alice對(duì)比dialog中消息和Replaces的頭消息，確認(rèn)以后，接受Carol的請(qǐng)求。Alice對(duì)Carol回復(fù)一個(gè)200 OK（F8）：
　　Carol對(duì)Alice回復(fù)了ACK消息（F9），并且開始RTP流。
　　Alice和Carol開始通話以后，并且因?yàn)橐呀?jīng)替換了Replaces頭，所以Alice對(duì)Bob掛機(jī)處理，Alice對(duì)Bob發(fā)送BYE消息（F10）：
　　Bob對(duì)Alice發(fā)送200 OK（F11），到此為止，即時(shí)消息轉(zhuǎn)接的流程完成。
　　7、Call Forwarding Unconditional
　　Call Forwarding Unconditional，我們稱之為無(wú)條件呼叫前轉(zhuǎn)。從字面意思，讀者也可以看明白，被呼叫方會(huì)把呼叫進(jìn)行無(wú)條件轉(zhuǎn)移。與之對(duì)應(yīng)的是忙狀態(tài)呼叫前轉(zhuǎn)和無(wú)應(yīng)答呼叫前轉(zhuǎn)。這些業(yè)務(wù)都涉及到了運(yùn)營(yíng)商接入業(yè)務(wù)（PSTN或者IMS），不是專門針對(duì)內(nèi)網(wǎng)IPPBX用戶之間的電話轉(zhuǎn)接功能。我們會(huì)在后續(xù)的章節(jié)中分別介紹這兩種呼叫的流程。這里，我們僅對(duì)無(wú)條件前轉(zhuǎn)進(jìn)行分析。
　　這里，我們假設(shè)Alice呼叫Bob（這里沒(méi)有標(biāo)識(shí)Bob的流程）。Bob會(huì)把呼叫無(wú)條件前轉(zhuǎn)到PSTN網(wǎng)絡(luò)。如果實(shí)現(xiàn)此場(chǎng)景，呼叫必須經(jīng)過(guò)Proxy和Gateway來(lái)實(shí)現(xiàn)處理。Gateway看作為另外一個(gè)Proxy的URL地址，同時(shí)支持了PSTN的接口。在以下的場(chǎng)景中，Alice對(duì)Bob進(jìn)行呼叫，這個(gè)INVITE消息會(huì)經(jīng)過(guò)Proxy，Proxy則會(huì)重寫請(qǐng)求的URL地址，然后前轉(zhuǎn)這個(gè)INVITE到Gateway地址。以上兩步是前轉(zhuǎn)最重要的部分，所以，我們僅針對(duì)這個(gè)部分進(jìn)行深入分析，對(duì)網(wǎng)關(guān)側(cè)和Bob的響應(yīng)不做分析。
　　這里，讀者需要注意，在以上示例中的F3中，Proxy是通過(guò)返回Alice 一個(gè)181 響應(yīng)消息來(lái)實(shí)現(xiàn)的呼叫前轉(zhuǎn)處理。嚴(yán)格地說(shuō)，在這個(gè)使用場(chǎng)景中，Proxy僅扮演著用戶代理的角色，它不能生成non-100的臨時(shí)響應(yīng)回復(fù)消息。另外需要說(shuō)明的是，呼叫前轉(zhuǎn)的處理也可以通過(guò)redirect的方式來(lái)實(shí)現(xiàn)，就是通常所說(shuō)302 Moved Temporarily response。以下圖例是一個(gè)完整的無(wú)條件呼叫前轉(zhuǎn)流程和具體的SIP消息操作。
　　接下來(lái)，我們針對(duì)無(wú)條件呼叫前轉(zhuǎn)的具體細(xì)節(jié)，結(jié)合請(qǐng)求響應(yīng)消息進(jìn)行分析介紹。首先，Alice對(duì)Bob發(fā)送INVITE請(qǐng)求，通過(guò)Proxy執(zhí)行呼叫（F1）：
　　然后，Proxy回復(fù)Alice 一個(gè)100 trying（F2），表示正在處理這個(gè)請(qǐng)求，忽略了流程圖。接下來(lái)，Proxy會(huì)對(duì)Alice發(fā)送一個(gè)181響應(yīng)消息（181 Call is Being forwarded），執(zhí)行F3流程；同時(shí)Proxy對(duì)Gateway發(fā)出一個(gè)INVITE請(qǐng)求（F4）。這里，Proxy對(duì)Gateway發(fā)送到INVITE請(qǐng)求中已經(jīng)重寫了請(qǐng)求URL地址。
　　讀者可以看到，Proxy和Gateway都沒(méi)有做任何其他的條件判斷，直接轉(zhuǎn)發(fā)到下一個(gè)目的地地址。在F5中，Gateway直接對(duì)Proxy回復(fù)一個(gè)180 Ringing，然后在F6中，Proxy回復(fù)Alice一個(gè)180 Ringing。
　　Gateway對(duì)Proxy發(fā)送180 Ringing以后，緊接著，Gateway對(duì)Proxy發(fā)送200 OK（F7），然后Proxy對(duì)Alice發(fā)送200 OK（F8）。
　　Alice收到200 OK以后，接下來(lái)，Alice對(duì)這個(gè)INVITE請(qǐng)求進(jìn)行確認(rèn)，發(fā)送ACK消息（F9）。Proxy收到ACK消息以后，直接對(duì)Gateway發(fā)送ACK確認(rèn)信息（F10）。雙方RTP語(yǔ)音流正式創(chuàng)建。
　　通話完成后，Alice掛機(jī)，對(duì)Proxy發(fā)送BYE消息（F11），然后Proxy對(duì)Gateway發(fā)送BYE消息（F12）。
　　最后，Gateway對(duì)Proxy發(fā)送200 OK（F13），Proxy再對(duì)Alice發(fā)送200 OK（F14），到這里，雙方的無(wú)條件呼叫前轉(zhuǎn)正式結(jié)束。
　　8、Call Forwarding - Busy
　　Call Forwarding - Busy，我們稱之為遇忙呼叫前轉(zhuǎn)。簡(jiǎn)單來(lái)說(shuō)，就是呼叫方通過(guò)Proxy呼叫被呼叫方時(shí)，被呼叫方此時(shí)處于忙狀態(tài)，然后Proxy把呼叫再次轉(zhuǎn)發(fā)到第三方用戶。例如，Alice通過(guò)Proxy呼叫用戶1，此時(shí)，如果用戶1處于忙狀態(tài)，Proxy收到用戶1的回復(fù)信息，Proxy會(huì)把此呼叫通過(guò)一個(gè)INVITE再次轉(zhuǎn)發(fā)到用戶2終端。遇忙呼叫前轉(zhuǎn)到流程圖如下：
　　下面，我們配合具體的SIP消息示例來(lái)進(jìn)一步說(shuō)明整個(gè)遇忙呼叫前轉(zhuǎn)的處理過(guò)程。
　　首先，Alice對(duì)Proxy發(fā)送一個(gè)INVITE請(qǐng)求，需要呼叫用戶1（F1），Proxy
　　接下來(lái)對(duì)用戶1發(fā)送一個(gè)INVITE請(qǐng)求，通知用戶1，Alice要呼叫對(duì)方。
　　在處理以上流程的同時(shí)，Proxy會(huì)對(duì)Alice發(fā)送一個(gè)100 Trying（F3），Proxy告訴Alice正在處理此呼叫，忽略了100 Trying圖例。經(jīng)過(guò)一定時(shí)間后，用戶1此時(shí)此刻正在處于電話的忙狀態(tài)，不能接聽(tīng)此呼叫。然后用戶1對(duì)Proxy發(fā)送了一個(gè)486 Buy響應(yīng)消息（F4）。
　　Proxy獲悉用戶1是處于忙狀態(tài)后，對(duì)用戶1發(fā)送一個(gè)ACK確認(rèn)信息，表示收到了用戶1的狀態(tài)響應(yīng)（F5）。
　　為了處理用戶1處于忙狀態(tài)不能接聽(tīng)電話的問(wèn)題，Proxy首先通知Alice，proxy需要進(jìn)行電話前轉(zhuǎn)。所以，Proxy需要對(duì)Alice發(fā)送一個(gè)180 call is Being Forwarded的消息，通知Alice，你的呼叫正在被前轉(zhuǎn)。同時(shí)，Proxy再次發(fā)起一個(gè)INVITE請(qǐng)求，這次，對(duì)用戶2發(fā)出INVITE請(qǐng)求進(jìn)行呼叫前轉(zhuǎn)。
　　接下來(lái)，用戶2對(duì)Proxy發(fā)送180 Ringing響應(yīng)消息（F8），Proxy然后對(duì)Alice發(fā)送180 Ringing響應(yīng)消息（F9），表示前轉(zhuǎn)接受。
　　發(fā)送180 Ringing以后，緊接著，用戶2對(duì)Proxy發(fā)送200 OK（F10），然后Proxy對(duì)Alice發(fā)送200 OK（F11）。
　　Alice收到Proxy發(fā)送的200 OK以后，發(fā)送確認(rèn)消息ACK（F12）。然后Proxy對(duì)用戶2發(fā)送確認(rèn)消息ACK（F13）。接下來(lái)，Alice和用戶2創(chuàng)建媒體流，雙方開始正常通話。
　　通話結(jié)束后，Alice對(duì)Proxy發(fā)送BYE消息（掛機(jī)，F(xiàn)14），然后Proxy對(duì)用戶2發(fā)送BYE消息（F15）。
　　最后，雙方進(jìn)行掛機(jī)的最終確認(rèn)，首先由用戶2發(fā)送200 OK到Proxy（F16），然后Proxy對(duì)Alice發(fā)送200 OK（F17）。
　　到此為止，遇忙呼叫前轉(zhuǎn)的處理流程正式結(jié)束。
　　9、Call Forwarding - No Answer
　　Call Forwarding-NO Answer, 我們稱之為無(wú)應(yīng)答前轉(zhuǎn)。具體的實(shí)現(xiàn)過(guò)程和前面談?wù)撁艚星稗D(zhuǎn)的處理方式基本一致，唯一不同是，用戶1是無(wú)應(yīng)答，然后Proxy通過(guò)定時(shí)器檢測(cè)超時(shí)，進(jìn)行對(duì)第三方用戶2前轉(zhuǎn)處理。其余的處理流程基本和遇忙前轉(zhuǎn)的處理流程一致。簡(jiǎn)單來(lái)說(shuō)，Alice通過(guò)Proxy呼叫用戶1，用戶1在一定時(shí)間內(nèi)沒(méi)有應(yīng)答此呼叫，然后Proxy把這個(gè)呼叫轉(zhuǎn)接到用戶2，對(duì)用戶2進(jìn)行呼叫處理。在請(qǐng)求超時(shí)后（F6），Proxy對(duì)用戶1發(fā)送取消請(qǐng)求，然后通知Alice，同時(shí)對(duì)用戶2再次進(jìn)行INVITE請(qǐng)求處理，進(jìn)行呼叫請(qǐng)求。具體的呼叫流程如下：
　　接下來(lái)，筆者配合具體的SIP消息來(lái)進(jìn)一步說(shuō)明無(wú)應(yīng)答呼叫前轉(zhuǎn)的處理方式。
　　首先，Alice通過(guò)Proxy對(duì)用戶1發(fā)出INVITE請(qǐng)求，對(duì)用戶1進(jìn)行呼叫（F1），然后Proxy對(duì)用戶1發(fā)送INVITE請(qǐng)求，對(duì)用戶2進(jìn)行呼叫請(qǐng)求處理。
　　接下來(lái)，Proxy馬上對(duì)Alice發(fā)送一個(gè)100 Trying（F3忽略），表示正在對(duì)用戶1進(jìn)行呼叫，通知Alice等待。用戶1對(duì)Proxy發(fā)送180 Ringing（F4），Proxy也對(duì)Alice發(fā)送180 Ringing（F5）。
　　這時(shí)，用戶1處于振鈴狀態(tài)，在Proxy設(shè)定的定時(shí)器超時(shí)設(shè)置范圍內(nèi)，用戶1終端無(wú)人接聽(tīng)此呼叫。因此，Proxy對(duì)用戶1發(fā)送Cancel消息，通知用戶1停止振鈴。
　　然后，用戶1對(duì)Proxy發(fā)送200 OK（F7）：
　　接下來(lái)，用戶1馬上對(duì)Proxy發(fā)送一個(gè)487 響應(yīng)消息，表示定時(shí)器超時(shí)，在一定振鈴時(shí)間內(nèi)無(wú)人應(yīng)答此呼叫。
　　Proxy收到超時(shí)消息以后，對(duì)用戶1發(fā)送ACK確認(rèn)消息，確認(rèn)超時(shí)事件（F9）：
　　這時(shí)，Proxy需要做兩件事。Proxy知道用戶1是因?yàn)檎疋彸瑫r(shí)，無(wú)人應(yīng)答這個(gè)呼叫。接下來(lái)，Proxy重新調(diào)整呼叫流程，再次進(jìn)行呼叫轉(zhuǎn)接到處理。首先，Proxy先對(duì)Alice發(fā)送一個(gè)電話轉(zhuǎn)接到響應(yīng)消息（181 電話前轉(zhuǎn)），通知Alice，你的呼叫正在被前轉(zhuǎn)到其他用戶終端（F10）。緊接著Proxy對(duì)用戶2發(fā)送一個(gè)INVITE請(qǐng)求，對(duì)其進(jìn)行呼叫（F11）：
　　然后，用戶2對(duì)Proxy發(fā)送180 Ringing（F12），Proxy又對(duì)Alice發(fā)送180 Ringing（F13）：
　　振鈴發(fā)送以后，用戶2繼續(xù)對(duì)Proxy發(fā)送200 OK（F14），Proxy又對(duì)Alice發(fā)送200 OK（F15）：
　　Alice收到200 OK以后，繼續(xù)對(duì)此流程進(jìn)行進(jìn)一步的處理，以便開始雙方的通話或RTP流。Alice馬上回復(fù)Proxy ACK確認(rèn)消息（F16），Proxy也馬上對(duì)用戶2回復(fù)ACK確認(rèn)消息（F17）：
　　經(jīng)過(guò)一定時(shí)間段通話以后，Alice首先掛機(jī)，對(duì)Proxy發(fā)送BYE消息（F18），Proxy再對(duì)用戶2發(fā)送BYE消息（F19），通知用戶2掛機(jī)：
　　最后，用戶2對(duì)Proxy發(fā)送最后200 OK消息（F20），然后Proxy對(duì)Alice發(fā)送最后的200 OK（F21）。到此為止，無(wú)應(yīng)答呼叫前轉(zhuǎn)的呼叫流程正式完成。
　　這里讀者一定要注意，我們討論的呼叫前轉(zhuǎn)方式方式可以通過(guò)IPPBX或者軟交換的配置來(lái)實(shí)現(xiàn)，proxy或者媒體服務(wù)器的設(shè)置會(huì)影響振鈴的時(shí)長(zhǎng)設(shè)置，這樣可能導(dǎo)致電話振鈴問(wèn)題，被呼叫方如果接聽(tīng)不及時(shí)的話，可能產(chǎn)生無(wú)應(yīng)答呼叫。
　　所以，在部署前轉(zhuǎn)時(shí)一定要配合IPPBX或者其他的軟交換來(lái)解決。另外，結(jié)合一些其他的應(yīng)用需求，還有一些IPPBX可以設(shè)置為無(wú)應(yīng)答或者分機(jī)隨行的方式，如果終端無(wú)應(yīng)答，可以轉(zhuǎn)接到用戶手機(jī)或者其他的終端，或者留言等方式。這些需要用戶支持其他的接入方式來(lái)實(shí)現(xiàn)。
　　10、3-Way Conference - Third Party Is Added
　　3-Way Conference - Third Party Is Added，我們稱之為三方會(huì)議邀請(qǐng)。簡(jiǎn)單來(lái)說(shuō)，此呼叫業(yè)務(wù)就是一個(gè)簡(jiǎn)單的三方電話會(huì)議。通常來(lái)說(shuō)，如果是兩方通話，我們稱之為正常呼叫業(yè)務(wù)。如果介入了第三方或者更多人的話，我們稱之為三方會(huì)議或者多方會(huì)議。
　　一般的三方會(huì)議至少需要一個(gè)混音處理單元。在以下的部署場(chǎng)景中，Alice呼叫Bob，然后雙方進(jìn)行通話。這時(shí)，Bob想把第三方Carol也邀請(qǐng)到電話會(huì)議中來(lái)一起討論問(wèn)題。當(dāng)然，Bob自己本身必須具備處理第三方媒體混音的功能。然后，Bob首先對(duì)Alice發(fā)送一個(gè)re-INVITE，在INVITE中，修改了多個(gè)Contact URLs為一個(gè)URL，這個(gè)URL表示Bob的混音單元。然后，Bob對(duì)Carol發(fā)送一個(gè)INVITE請(qǐng)求，邀請(qǐng)Carol參加會(huì)議，并且使用同樣的Contact URL。
　　這里，讀者要注意，Bob邀請(qǐng)的處理方式可能有所不同。Bob可以先等Carol應(yīng)答以后，再對(duì)Alice發(fā)送re-INVITE。Bob也可以呼叫Carol之前，先把Alice設(shè)置為等待狀態(tài)。另外，Bob邀請(qǐng)會(huì)議時(shí)，Bob包含了一個(gè)功能標(biāo)簽tag-“isfocus”，表示Bob是一個(gè)會(huì)議處理中心。"isfocus"是在規(guī)范rfc3840中定義：
　　Summary of the media feature indicated by this tag: This feature tag
　　indicates that the UA is a conference server, also known as a
　　focus, and will mix together the media for all calls to the same
　　URI [13].
　　關(guān)于會(huì)議中focus的定義和規(guī)范，讀者可以參考rfc4579的第三章節(jié)。以下是一個(gè)完整的會(huì)議第三方邀請(qǐng)?zhí)幚砹鞒獭?/div>
　　下面，我們通過(guò)SIP消息結(jié)合具體的流程來(lái)說(shuō)明第三方會(huì)議邀請(qǐng)是如何進(jìn)行的。
　　首先，Alice對(duì)Bob發(fā)送INVITE請(qǐng)求，對(duì)其進(jìn)行呼叫（F1）：
　　Bob對(duì)Alice回復(fù)180 Ringing（F2）：
　　11、3-Way Conference - Third Party Joins
　　3-Way Conference - Third Party Joins，我們稱之為三方會(huì)議加入。和上面的三方會(huì)議邀請(qǐng)不同的是，這里的第三方是自己主動(dòng)希望加入到電話會(huì)議中，而不是由其他人邀請(qǐng)加入。因此，在處理三方會(huì)議時(shí)，其處理流程和前面的被邀請(qǐng)的方式完全不同。
　　通過(guò)以上的處理流程我們來(lái)詳細(xì)解釋會(huì)議加入的方式是如何處理的。這里，我們假設(shè)Alice和Bob兩個(gè)人正在進(jìn)行雙方的語(yǔ)音通話。Carol通過(guò)其他學(xué)習(xí)方式或者對(duì)Bob的訂閱消息，例如Bob發(fā)送的其他非SIP消息或者Bob對(duì)Carol發(fā)送到NoTIFY消息，其消息中含有dialog事件包。關(guān)于dialog的事件訂閱的處理，讀者可以參考RFC4579中的第5.8章節(jié)和RFC4235的規(guī)范。
　　這時(shí)，Carol希望加入到Alice和Bob之間的電話呼叫中。這時(shí)，Carol會(huì)對(duì)Bob發(fā)送一個(gè)INVITE請(qǐng)求（F5），這個(gè)請(qǐng)求中包含一個(gè)Join頭，在這個(gè)頭中，包含Alice和Bob兩者之間的dialog，以此來(lái)保證Carol加入到是正確的dialog，而不是其他的會(huì)議呼叫。Bob然后對(duì)Alice發(fā)送一個(gè)re-INVITE修改了通話模式（F7），從雙方談話變成一個(gè)“isfocus”模式（rfc3840），開始支持三方會(huì)議的模式。然后，Bob才接受來(lái)自于Carol的INVITE請(qǐng)求，最后開始三方通話或者電話會(huì)議模式，此時(shí)，三方會(huì)議加入的處理流程徹底完成�，F(xiàn)在，我們通過(guò)完整的SIP消息配合具體的處理流程來(lái)進(jìn)一步對(duì)電話加入的方式做出詳細(xì)介紹。
　　首先，Alice對(duì)Bob發(fā)送INVITE請(qǐng)求，進(jìn)行電話呼叫（F1）：
　　然后，Bob對(duì)Alice發(fā)送180 Ringing（F2），緊接著，Bob對(duì)Alice發(fā)送200 OK（F3）：


　　然后，Alice對(duì)200 OK回復(fù)ACK確認(rèn)信息（F4），雙方開始RTP流傳輸：
　　這時(shí)，Carol通過(guò)Bob發(fā)送到其他的非SIP消息或者NOTIFY事件了解了Alice和Bob之間正在進(jìn)行電話呼叫，Carol想加入到這個(gè)電話呼叫中。因此，Carol對(duì)Bob發(fā)送一個(gè)INVITE請(qǐng)求，在這個(gè)INVITE請(qǐng)求中（F5），包含有Join的頭，這個(gè)頭中含有加入他們之間還有的dialog消息內(nèi)容（Join中忽略了具體的內(nèi)容）：
　　Bob先對(duì)Carol發(fā)送一個(gè)180 Ringing（F6）：
　　然后，Bob再對(duì)Alice發(fā)送一個(gè)re-INVITE請(qǐng)求，Bob通知Alice，因?yàn)镃arol要加入電話會(huì)議中，我現(xiàn)在需要修改通話模式，修改為“isfocus”模式來(lái)支持電話會(huì)議，需要進(jìn)行媒體混音處理。
　　Alice收到Bob的INVITE請(qǐng)求后，對(duì)其請(qǐng)求表示同意，然后對(duì)Bob發(fā)送200 OK（F8）：
　　Bob對(duì)Alice 的200 OK發(fā)送響應(yīng)消息，獲悉Alice同意修改為會(huì)議模式（F9）：
　　現(xiàn)在，Bob完成了和Alice的協(xié)商，獲悉Alice已經(jīng)準(zhǔn)備好進(jìn)行電話會(huì)議。接下來(lái)，Bob才對(duì)Carol發(fā)送200 OK，接受了其要求加入電話會(huì)議的INVITE請(qǐng)求，這里包括了新的Contact的會(huì)議地址。
　　接下來(lái)，Carol知道Bob已經(jīng)允許自己可以加入到會(huì)議中，對(duì)Bob發(fā)送最后ACK確認(rèn)消息，表示正式加入會(huì)議中。此時(shí)，Carol加入到了會(huì)議室，三方會(huì)議正式開啟（F11），RTP流開始工作。這里的Bob構(gòu)成了一個(gè)媒體混音單元，也可能是一個(gè)會(huì)議媒體服務(wù)器功能，進(jìn)行三方混音。
　　這里，筆者再進(jìn)一步介紹一下會(huì)議的標(biāo)簽isfocus tag。會(huì)議模式中的isfocus參數(shù)可以支持多種使用方式，通過(guò)SIP，它可以支持以下幾種方式：
  • 創(chuàng)建會(huì)議
  • 加入會(huì)議
  • 邀請(qǐng)用戶加入會(huì)議
  • 踢出會(huì)議用戶
  • 支持對(duì)會(huì)議URL判斷，可以檢查到是否是會(huì)議URL
  • 刪除會(huì)議
　　會(huì)議創(chuàng)建的方式Ad-Hoc方式臨時(shí)自組的方式來(lái)創(chuàng)建一個(gè)會(huì)議，也可以通過(guò)REFER方式來(lái)創(chuàng)建一個(gè)會(huì)議室。會(huì)議邀請(qǐng)的方式可以通過(guò)INVITE請(qǐng)求，用戶可以主動(dòng)呼入或者用戶被呼方式來(lái)進(jìn)入到會(huì)議室，也可以通過(guò)REFER的方式邀請(qǐng)用戶進(jìn)入到會(huì)議室。關(guān)于會(huì)議的管理和使用部署，RFC4579中有著非常詳細(xì)的說(shuō)明，同時(shí)此規(guī)范也介紹了其他的協(xié)商流程。讀者可以閱讀此規(guī)范進(jìn)一步了解多方會(huì)議的處理流程。
　　在開源媒體服務(wù)器中，Asterisk/FreePBX/FreeSWITCH也支持了強(qiáng)大的會(huì)議功能。用戶可以創(chuàng)建會(huì)議室，系統(tǒng)通過(guò)自動(dòng)撥號(hào)的形式邀請(qǐng)會(huì)議用戶來(lái)加入到會(huì)議中，用戶也可以通過(guò)語(yǔ)音IVR的形式進(jìn)入到會(huì)議室中。會(huì)議主席也可以對(duì)會(huì)議人員實(shí)現(xiàn)靜音或者踢出等功能。如果使用Asterisk的界面管理系統(tǒng)FreePBX，用戶也可以通過(guò)界面來(lái)創(chuàng)建會(huì)議室，支持多種會(huì)議的管理功能，例如會(huì)議密碼設(shè)置，最大會(huì)議用戶人數(shù)設(shè)置，進(jìn)入會(huì)議室播放提示，音樂(lè)等待等功能。
　　12、Find-Me
　　Find-Me, 我們稱之為有效用戶查詢呼叫。簡(jiǎn)單來(lái)說(shuō)，Alice通過(guò)Proxy呼叫Bob，Bob可能有幾個(gè)Contact地址。Proxy會(huì)根據(jù)不同的Contact列表來(lái)逐一查詢這些地址的狀態(tài)，如果有可接通的地址，則對(duì)其進(jìn)行呼叫；如果沒(méi)有，Proxy會(huì)繼續(xù)查詢其他的地址，直到找到可接聽(tīng)呼叫的地址。一旦找到可接聽(tīng)通話的地址，則不再繼續(xù)查詢其他的地址。
　　這里筆者提醒讀者，在對(duì)用戶狀態(tài)的查詢中，系統(tǒng)也可以使用并列查詢的方式。我們剛才使用的是按序查詢的方式，系統(tǒng)也可以使用并列查詢的方式。并列查詢狀態(tài)下，Proxy會(huì)同時(shí)對(duì)所有Contact 列表中的地址發(fā)送查詢可接聽(tīng)的地址，然后創(chuàng)建RTP語(yǔ)音流。以下圖例中說(shuō)明了兩種重新的處理不同。并列查詢的處理方式：
　　按序查詢的處理方式：
　　在本章節(jié)的有效用戶查詢呼叫中，我們使用的方式是按序查詢的方式。Proxy會(huì)通過(guò)Bob的Contact列表逐一查詢地址狀態(tài)，如果有效，則創(chuàng)建呼叫。
　　下面，我們結(jié)合SIP消息和具體的流程進(jìn)行分析。
　　首先，Alice通過(guò)Proxy對(duì)Bob進(jìn)行呼叫，發(fā)送INVITE請(qǐng)求給Proxy（F1），Proxy對(duì)Bob發(fā)送INVITE請(qǐng)求（F2）：
　　接下來(lái)，Proxy馬上回Alice 一個(gè)100 Trying（這里忽略，F(xiàn)3），表示呼叫正在處理中。用戶1對(duì)Proxy回一個(gè)180 Ringing（F4）。緊接著，Proxy對(duì)Alice回復(fù)一個(gè)180 Ringing，表示用戶1已經(jīng)振鈴（F5）。
 
　　但是，在一定的振鈴時(shí)間內(nèi)，用戶1沒(méi)有人接聽(tīng)電話呼叫，Proxy的定時(shí)器出現(xiàn)超時(shí)。然后，Proxy對(duì)用戶1發(fā)送Cancel消息（F6）。
　　用戶1對(duì)Proxy回復(fù)一個(gè)200 OK（F7）：
　　然后，用戶1對(duì)Proxy發(fā)送一個(gè)487 超時(shí)消息（F8）：
　　Proxy對(duì)487 回復(fù)一個(gè)ACK確認(rèn)消息（F9）：
　　在獲悉用戶1呼叫超時(shí)以后，Proxy繼續(xù)對(duì)Contact 列表中的用戶2地址發(fā)送INVITE請(qǐng)求（F10）：
　　但是，用戶2根本沒(méi)有登錄注冊(cè)，所以，用戶2回復(fù)480 消息（F11）
　　Proxy對(duì)用戶2回復(fù)ACK確認(rèn)（F12）：
　　然后，Proxy繼續(xù)對(duì)Bob的Contact 列表中的用戶3地址發(fā)送INVITE請(qǐng)求消息（F13）：
　　但對(duì)用戶3發(fā)送INVITE請(qǐng)求后，發(fā)現(xiàn)用戶3處于忙狀態(tài)，不能接聽(tīng)這個(gè)呼叫。用戶3回復(fù)486 Busy Here（F14）:
　　緊接著，Proxy對(duì)用戶3回復(fù)ACK確認(rèn)消息（F15）：
　　接下來(lái)，Proxy繼續(xù)對(duì)Bob的Contact列表中的用戶4地址發(fā)送INVITE請(qǐng)求（F16）：
　　然后，用戶4回復(fù)Proxy 180 Ringing（F17），Proxy再回復(fù)Alice一個(gè)180 Ringing（F18）：
　　緊接著，用戶4對(duì)Proxy發(fā)送一個(gè)200 OK（F19），然后，Proxy又對(duì)Alice發(fā)送一個(gè)200 OK（F20）：
　　然后，Alice對(duì)Proxy發(fā)送一個(gè)ACK確認(rèn)消息（F21），Proxy對(duì)用戶4發(fā)送一個(gè)ACK確認(rèn)消息（F22）。到此為止，整個(gè)有效用戶查詢呼叫的流程完成，雙方開始語(yǔ)音流的互通。
　　結(jié)合以上多種用戶終端出現(xiàn)的情況，Proxy經(jīng)過(guò)了Bob的4個(gè)Contact列表地址查詢，第一個(gè)呼叫超時(shí)，第二個(gè)地址沒(méi)有登錄，第三個(gè)用戶忙，到最后一個(gè)用戶地址，才真正和Alice創(chuàng)建了RTP語(yǔ)音流的傳輸。在每一個(gè)異常狀態(tài)下，終端都返回相應(yīng)的響應(yīng)消息，然后Proxy會(huì)對(duì)每一個(gè)響應(yīng)發(fā)送ACK，然后再進(jìn)行下一個(gè)有效用戶的地址查詢。
　　通話一段時(shí)間后，用戶4對(duì)Alice掛機(jī)，對(duì)Proxy首先發(fā)送BYE消息（F23）， Proxy對(duì)Alice進(jìn)行掛機(jī)處理，對(duì)其發(fā)送BYE消息（F24）：
　　然后，Alice對(duì)Proxy發(fā)送200 OK（F25），Proxy再對(duì)用戶4發(fā)送200 OK（F26）：
　　Alice和用戶4的通話正式結(jié)束。
　　13、Call Management （Incoming Call Screening）
　　Call Management （Incoming Call Screening），我們這里稱之為呼叫篩選或呼叫過(guò)濾。在企業(yè)通信環(huán)境中，為了節(jié)省員工的時(shí)間，提高工作效率，用戶可以設(shè)置一個(gè)電話篩選機(jī)制來(lái)保證不被一些不相關(guān)的電話騷擾。簡(jiǎn)單來(lái)說(shuō)，如果有外部呼叫呼入到IPPBX的終端時(shí)，終端可以顯示呼叫方號(hào)碼，或者名稱，或者通過(guò)第三方媒體發(fā)送到語(yǔ)音提示。此時(shí)，終端用戶可以根據(jù)終端所設(shè)置的號(hào)碼地址薄選擇繼續(xù)接聽(tīng)電話，拒絕，轉(zhuǎn)語(yǔ)音郵箱，或者對(duì)呼叫方播放一個(gè)自定義的語(yǔ)音媒體。以上這些功能都可以通過(guò)Proxy加媒體播放服務(wù)器來(lái)實(shí)現(xiàn)，或者使用企業(yè)IPPBX本身的配置功能來(lái)實(shí)現(xiàn)。為了更加專業(yè)地表達(dá)此功能名稱，我們稱之為呼叫篩選或呼叫過(guò)濾，黑白名單過(guò)濾比較通俗易懂。其實(shí)，呼叫篩選和黑白名單過(guò)濾的功能要求基本類似，從功能設(shè)置的角度來(lái)說(shuō)它們的功能基本相同。
　　在日常生活中，我們簡(jiǎn)單稱之為黑白名單過(guò)濾。因?yàn)榇罅康尿}擾電話的問(wèn)題，我們現(xiàn)在已經(jīng)對(duì)呼叫篩選不陌生了。我們手機(jī)app所設(shè)置的騷擾電話設(shè)置或者黑名單過(guò)濾等都可以視為呼叫篩選的功能。但是，這些基于個(gè)人終端的業(yè)務(wù)支持，不是我們這里討論的內(nèi)容。
　　呼叫篩選的具體流程經(jīng)過(guò)了幾個(gè)步驟。假設(shè)，Alice呼叫用戶Bob，Bob的終端聯(lián)系方式中可能已經(jīng)對(duì)Alice設(shè)置為拒絕接聽(tīng)的地址，因此Bob拒絕接聽(tīng)此呼叫。拒絕接聽(tīng)后，Bob對(duì)Alice返回了一個(gè)消息，通知你呼叫必須通過(guò)Proxy的安全認(rèn)證機(jī)制，Bob僅接受經(jīng)過(guò)Proxy確認(rèn)的呼叫。因此，Alice再次對(duì)Proxy發(fā)送請(qǐng)求，但是因?yàn)榘踩O(shè)置的問(wèn)題，Alice沒(méi)有通過(guò)Proxy的安全認(rèn)證，Proxy在錯(cuò)誤消息返回時(shí)插入了一個(gè)新的Error-info的URL地址，Alice播放這個(gè)來(lái)自于媒體服務(wù)器或者第三方聲明提示等服務(wù)器的語(yǔ)音提示。
　　這里注意，安全認(rèn)證不能使用From 頭來(lái)判斷，必須通過(guò)Proxy的安全機(jī)制來(lái)處理。以下是一個(gè)呼叫篩選的流程圖，在圖例中，一般企業(yè)用戶使用IPPBX本身自帶的媒體播放功能對(duì)Alice實(shí)現(xiàn)媒體語(yǔ)音提示。
　　接下來(lái)，我們根據(jù)SIP消息細(xì)節(jié)結(jié)合每一個(gè)處理流程來(lái)進(jìn)一步說(shuō)明呼叫篩選的處理過(guò)程。
　　首先，Bob看到來(lái)自于Alice的呼叫，表示Alice需要和Bob通話（F1）。
　　Bob拒絕了Alice的呼叫請(qǐng)求，要求必須通過(guò)Proxy認(rèn)證才能通話。Bob對(duì)Alice發(fā)送305消息（F2）：
　　Alice獲悉這個(gè)錯(cuò)誤以后，對(duì)Bob發(fā)送ACK確認(rèn)消息（F3）：
　　然后，Alice對(duì)Proxy發(fā)送INVITE請(qǐng)求（F4）：
　　然后，Proxy對(duì)Alice發(fā)送認(rèn)證響應(yīng)消息407（F5）:
　　Alice對(duì)Proxy返回確認(rèn)ACK消息（F6）：
　　然后，Alice對(duì)Proxy發(fā)送安全認(rèn)證消息（F7），攜帶自己的認(rèn)證信息：
　　Proxy經(jīng)過(guò)安全認(rèn)證檢查以后，發(fā)現(xiàn)Alice沒(méi)有權(quán)限直接呼叫Bob，呼叫篩選不能通過(guò)，因此對(duì)Alice返回一個(gè)失敗消息（F8），并且插入了一個(gè)Error-info，帶了一個(gè)URL地址。這個(gè)地址播放語(yǔ)音提示。
　　Alice收到403 響應(yīng)錯(cuò)誤消息以后，對(duì)Proxy發(fā)送一個(gè)ACK確認(rèn)消息（F9）：
　　為了知道Proxy對(duì)Alice發(fā)送的是什么提示，Alice會(huì)繼續(xù)對(duì)這個(gè)Error-info的地址進(jìn)行訪問(wèn)，發(fā)送一個(gè)INVITE請(qǐng)求（F10）這時(shí)一個(gè)媒體播放的服務(wù)器地址，其服務(wù)器會(huì)對(duì)Alice播放剛才呼叫失敗的提示音：
　　然后，媒體播放服務(wù)器對(duì)Alice發(fā)送200 OK消息（F11），表示可以對(duì)Alice播放語(yǔ)音提示。
　　另外，在F11的200 OK中，媒體播放服務(wù)器對(duì)Alice增加了一個(gè)渲染功能標(biāo)簽，表示此服務(wù)器僅能支持自動(dòng)媒體功能automaton和rendering：
　　F11 200 OK Announcement Server -> Alice
　　SIP/2.0 200 OK
　　Via: SIP/2.0/TLS client.atlanta.example.com:5061
　　;branch=z9hG4bK74bfj
　　;received=192.0.2.103
　　From: Alice ;tag=1234567
　　To: Bob ;tag=234934
　　Call-ID: 12345600@atlanta.example.com
　　CSeq: 4 INVITE
　　Contact:
　　;automaton;+sip.rendering="no"
　　Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
　　Content-Type: application/sdp
　　Content-Length: …
　　v=0
　　o=annc 2890844543 2890844543 IN IP4 announce.biloxi.example.com
　　s=
　　c=IN IP4 announce.biloxi.example.com
　　t=0 0
　　m=audio 49174 RTP/AVP 0
　　a=rtpmap:0 PCMU/8000
　　注意，在RFC5359規(guī)范的2.13章節(jié)中，F(xiàn)11的處理流程可能存在表述錯(cuò)誤。讀者需要根據(jù)實(shí)際的場(chǎng)景來(lái)做出正確的判斷。按照流程圖的示意，F(xiàn)11應(yīng)該是從媒體服務(wù)器到Alice的返回消息：
　　但是，按照正常的處理規(guī)范來(lái)說(shuō)，應(yīng)該是媒體服務(wù)器對(duì)Alice的返回消息（200 OK）。另外一個(gè)矛盾的地方是，在具體的流程中（F11），規(guī)范又描述為媒體到Proxy 1的處理流程：
　　以上討論是筆者僅根據(jù)官方規(guī)范做的疑點(diǎn)做出的自己的判斷，讀者可以通過(guò)其他渠道和規(guī)范發(fā)布者確認(rèn)最終結(jié)果。
　　現(xiàn)在我們回到合理的處理流程中。接下來(lái)，Alice收到200 OK以后，對(duì)媒體服務(wù)器發(fā)送ACK確認(rèn)消息，然后媒體播放服務(wù)器對(duì)Alice播放語(yǔ)音提示（F12）：
　　語(yǔ)音提示播放完成以后，媒體服務(wù)器對(duì)Alice發(fā)送BYE消息，表示媒體播放結(jié)束，斷開連接（F13）。
　　最后，Alice收到了媒體播放器發(fā)送到最后提示，表示斷開連接，Alice發(fā)送確認(rèn)消息（F14）：
　　14、Call Management （Outgoing Call Screening）
　　Call Management （Outgoing Call Screening），我們稱之為呼出呼叫篩選。此呼叫業(yè)務(wù)和上面的呼入呼叫篩選基本類似，但是處理流程更加簡(jiǎn)單。簡(jiǎn)單舉例，呼叫方Alice通過(guò)Proxy呼叫Bob，但是Bob在Alice的呼叫篩選名單中，Proxy對(duì)Alice要求安全認(rèn)證的驗(yàn)證，Alice對(duì)Proxy發(fā)送安全認(rèn)證的消息，但是因?yàn)锽ob在Alice的Call Screening的篩選名單中，不能對(duì)Bob進(jìn)行呼叫，因此，最后，Proxy對(duì)返回403 呼叫篩選失敗，最后掛機(jī)。
　　現(xiàn)在，我們結(jié)合具體的SIP消息，配合每個(gè)呼叫流程做進(jìn)一步的細(xì)節(jié)介紹。
　　首先，Alice對(duì)Proxy發(fā)送INVITE請(qǐng)求，要求對(duì)Bob進(jìn)行呼叫（F1）：
　　Proxy要求Alice發(fā)送安全認(rèn)證消息進(jìn)行驗(yàn)證（F2），返回407響應(yīng)消息：
　　Alice獲悉以后，繼續(xù)對(duì)Proxy發(fā)送ACK確認(rèn)消息（F3）：
　　然后再次對(duì)Proxy發(fā)送INVITE消息，包含了安全認(rèn)證的信息（F4）：
　　Proxy經(jīng)過(guò)檢查，Alice沒(méi)有權(quán)限呼叫Bob，因此對(duì)Alice返回403 Screening Failure （Originating）的消息，表示不能對(duì)Bob進(jìn)行呼叫（F5）。另外，在返回的消息中插入了一個(gè)Error-info 頭，包含了一個(gè)媒體播放的鏈接，用戶可以聽(tīng)到失敗提示音。
　　Alice收到403以后，獲悉自己不能呼叫Bob，發(fā)送ACK給Proxy。此時(shí)，外呼篩選流程結(jié)束（F6）。
　　關(guān)于呼叫篩選的功能，很多IPPBX支持了多種配置方式和功能。比較常見(jiàn)的處理方式包括：不在呼叫權(quán)限組，呼叫前綴不對(duì)，用戶不接受其他部門呼叫，一定時(shí)間內(nèi)不接受其他無(wú)關(guān)聯(lián)用戶呼叫，或者其他IP地址的呼叫，出差期間不接受呼叫等篩選方式。
　　這里比較關(guān)鍵的是篩選失敗以后的處理，如何對(duì)呼叫失敗方進(jìn)行一個(gè)比較友好的處理方式，比如，對(duì)呼叫失敗方播放語(yǔ)音提示，轉(zhuǎn)到語(yǔ)音留言，抓到其他的IVR流程，或者進(jìn)行后期回呼處理。在Asterisk或者FreeSWITCH平臺(tái)中，這些處理策略都可以通過(guò)IPPBX的撥號(hào)規(guī)則加一定的腳本來(lái)實(shí)現(xiàn)篩選的路由控制。具體的實(shí)現(xiàn)方式用戶參考網(wǎng)上的學(xué)習(xí)資料。
　　15、Call Park
　　Call Park，我們稱之為呼叫駐留/�？�。簡(jiǎn)單來(lái)說(shuō)，呼叫駐留就是呼叫方呼叫被呼叫方時(shí)，電話被駐留在駐留服務(wù)器（一般是媒體服務(wù)器或者IPPBX）。經(jīng)過(guò)一段時(shí)間后，呼叫方電話被其他第三方用戶再次接聽(tīng)。具體的實(shí)現(xiàn)過(guò)程是這樣的，假設(shè)Alice呼叫Bob，Bob和Alice開始通話，通話后，可能Alice想轉(zhuǎn)接第三方或者Bob可能有其他事情，暫時(shí)不能繼續(xù)和Alice通話，Bob通過(guò)終端按鍵對(duì)其通話進(jìn)行電話?cǎi)v留的設(shè)置。
　　所以，Alice的電話被駐留在駐留服務(wù)器或者IPPBX/媒體服務(wù)器。Alice電話被駐留以后，媒體服務(wù)器會(huì)對(duì)Bob發(fā)送訂閱消息，說(shuō)明電話?cǎi)v留狀態(tài)。然后，媒體服務(wù)器對(duì)Alice發(fā)送一個(gè)INVITE請(qǐng)求，通知Alice，媒體服務(wù)器現(xiàn)在替換了Bob來(lái)對(duì)其會(huì)話進(jìn)行管理。Alice獲悉駐留狀態(tài)后，接受此處理流程，然后，媒體服務(wù)器或者IPPBX對(duì)其播放音樂(lè)媒體提示音。接下來(lái)，Alice對(duì)Bob發(fā)送BYE消息，媒體服務(wù)器對(duì)Bob發(fā)送Bob消息，表示現(xiàn)在媒體服務(wù)器已經(jīng)駐留了Alice的通話，Bob脫離和Alice之間的關(guān)系。第三方Carol想接聽(tīng)這個(gè)被駐留在媒體服務(wù)器的呼叫，因此，首先需要對(duì)媒體服務(wù)器發(fā)送訂閱消息，媒體服務(wù)器接受訂閱以后，獲悉Carol想接聽(tīng)這個(gè)被駐留的呼叫，接下來(lái)Carol對(duì)Alice發(fā)送INVITE請(qǐng)求，并且要求替換會(huì)話中的媒體服務(wù)器。Alice收到此請(qǐng)求后，同意和Carol進(jìn)行通話，發(fā)送協(xié)商成功的響應(yīng)消息，然后雙方正式開始通話，駐留處理流程完成。
　　在電話?cǎi)v留的流程中，幾個(gè)問(wèn)題需要讀者注意。首先，這里的電話?cǎi)v留被重新接聽(tīng)的是第三方的用戶，當(dāng)然，接聽(tīng)用戶也可能是發(fā)起駐留電話自己本身。但是，這樣的駐留方式也不符合大部分場(chǎng)景中的電話使用習(xí)慣。因?yàn)�，大部分已�?jīng)開始的通話，或者進(jìn)行電話轉(zhuǎn)接，或者一定時(shí)間后雙方掛機(jī)，或者掛機(jī)后，雙方稍晚時(shí)間后重新呼叫對(duì)方。因此，電話?cǎi)v留其實(shí)也是電話轉(zhuǎn)接的一種特殊方式或特殊使用場(chǎng)景。其次，電話?cǎi)v留的方式其實(shí)也是音樂(lè)等待的一種處理方式。只是，在電話?cǎi)v留服務(wù)器或者媒體服務(wù)器中，駐留處理可以分割為多個(gè)駐留空間或者slot，電話?cǎi)v留基本的處理流程或原理事實(shí)上和語(yǔ)音等待類似。最后，電話?cǎi)v留服務(wù)器開啟駐留處理時(shí)也對(duì)駐留方發(fā)送了automaton,，rendering和 byeless tag標(biāo)簽，表示其服務(wù)器的支持能力。以下是電話?cǎi)v留的處理流程：


　　現(xiàn)在，我們結(jié)合具體的SIP消息和每一個(gè)處理的具體細(xì)節(jié)來(lái)一步步介紹整個(gè)電話?cǎi)v留的處理：


　　首先，Alice對(duì)Bob發(fā)送INVITE呼叫請(qǐng)求（F1）：
　　然后Bob對(duì)Alice響應(yīng)180 Ringing（F2）：
　　緊接著，Bob對(duì)Alice發(fā)送200 OK（F3）：
　　Alice收到200 OK以后，對(duì)Bob發(fā)送ACK確認(rèn)消息（F4），雙方開始通話。
　　通話后獲悉，Alice可能需要被駐留，然后第三方Carol來(lái)接聽(tīng)。因此，Bob首先需要對(duì)Alice通話進(jìn)行電話?cǎi)v留處理，把Alice的呼叫�？吭隈v留服務(wù)器或者媒體服務(wù)器上，Bob對(duì)服務(wù)器發(fā)送REFER消息（F5），并且通知媒體服務(wù)器在會(huì)話中使用Bob替換Alice。這里的Refer-To是Alice，Refer-By是Bob自己。注意，這里不存在Bob和媒體服務(wù)器之間的直接的會(huì)話。
　　駐留服務(wù)器收到Bob的REFER以后，對(duì)Bob發(fā)送一個(gè)202 Accepted，表示接受此REFER消息（F6）：
　　然后，駐留服務(wù)器對(duì)Bob發(fā)送NOTIFY消息，創(chuàng)建一個(gè)對(duì)事件的訂閱，同時(shí)提示Bob正在處理電話?cǎi)v留（F7），100 Trying：
　　Bob回復(fù)200表示收到訂閱事件（F8）：
　　接下來(lái)，駐留媒體服務(wù)器對(duì)Alice發(fā)送INVITE請(qǐng)求，同時(shí)替換Bob（F9），增加了渲染功能的標(biāo)簽，表示媒體服務(wù)器的處理能力（在Contact中插入了媒體服務(wù)器的渲染功能標(biāo)簽：
　　Contact:;automaton ;+sip.byeless;+sip.rendering="no"
　　注意：以下圖例中忽略了渲染功能標(biāo)簽
　　Alice接受了媒體服務(wù)器的請(qǐng)求，發(fā)送200 OK（F10）：
　　媒體服務(wù)器對(duì)Alice發(fā)送ACK確認(rèn)消息，開始媒體流處理（這里開始播放語(yǔ)音提示，F(xiàn)11）：
　　提示音播放開始以后，Alice對(duì)Bob發(fā)送BYE消息（F12），表示Alice已經(jīng)和媒體服務(wù)器創(chuàng)建了新的會(huì)話關(guān)系：
　　Bob獲悉Alice的電話被成功駐留以后，對(duì)Alice發(fā)送一個(gè)最終的200 OK（F13）：
　　這時(shí)，媒體服務(wù)器再次對(duì)Bob發(fā)送NOTIFY消息，并且攜帶了返回的200 OK消息，表示媒體服務(wù)器成功處理了Alice的駐留（F14）。
　　Bob對(duì)媒體服務(wù)器返回200 OK消息，并且確認(rèn)了dialog的ID（F15），到此為止，Alice已經(jīng)完全駐留在媒體服務(wù)器中。
　　接下來(lái)，如果Carol想接聽(tīng)這個(gè)被駐留在服務(wù)器的Alice的電話時(shí)，Carol首先需要對(duì)媒體服務(wù)器發(fā)送訂閱消息，否則，Carol不知道Alice電話的事件。因此，Carol對(duì)服務(wù)器發(fā)送訂閱消息（F16）：
　　媒體服務(wù)器對(duì)Carol回復(fù)一個(gè)200 OK，獲悉媒體服務(wù)器的支持能力等渲染標(biāo)簽（F17）：
　　有了新的事件以后，媒體服務(wù)器對(duì)Carol發(fā)送NOTIFY消息，通知Carol的事件具體消息內(nèi)容（F18）：
　　Carol獲悉被駐留方的地址信息后，對(duì)媒體服務(wù)器發(fā)送200 OK（F19）：
　　Bob通過(guò)媒體服務(wù)器發(fā)送到NOTIFY已經(jīng)獲得被駐留電話的地址信息，然后，為了接聽(tīng)Alice的駐留電話，Bob對(duì)Alice發(fā)送INVITE請(qǐng)求，并且要求替換媒體服務(wù)器的地址（Replaces，F(xiàn)20）。
　　Alice接受了Carol的請(qǐng)求，對(duì)Carol返回200 OK（F21）：
　　然后，Carol對(duì)Alice繼續(xù)發(fā)送一個(gè)ACK確認(rèn)消息（F22），創(chuàng)建RTP流，雙方開始正式通話，Carol接聽(tīng)被駐留的電話。
　　然后，Alice必須對(duì)駐留服務(wù)器發(fā)送最后的通知消息（BYE，F(xiàn)23），表示Alice已經(jīng)開始和Carol通話，駐留服務(wù)器和Alice的駐留關(guān)系釋放。
　　駐留服務(wù)器最后對(duì)Alice返回200 OK（F24），表示確認(rèn)駐留關(guān)系釋放：
　　呼叫駐留到這一步，媒體服務(wù)器釋放了和Alice的駐留關(guān)系，Alice通知了Bob，Carol接聽(tīng)了駐留電話。呼叫駐留的流程才真正完成。
　　企業(yè)IPPBX基本上都支持了呼叫駐留/�？康臉I(yè)務(wù)需求。IPPBX支持了多種駐留熱鍵功能，用戶可以通過(guò)熱鍵功能來(lái)駐留呼叫或者重新被激活駐留的呼叫。在開源平臺(tái)Asterisk（#72）或者FreeSWITCH（*5900）都有相應(yīng)的設(shè)置，用戶可以根據(jù)配置文件來(lái)實(shí)現(xiàn)電話?cǎi)v留或重接被駐留的呼叫，另外，IPPBX用戶也可以對(duì)駐留的空間進(jìn)行管理，根據(jù)配置的不同，駐留空間可以支持很多個(gè)slot。還有，電話?cǎi)v留的語(yǔ)音提示音也可以實(shí)現(xiàn)自定義功能，這樣就可以方便地支持系統(tǒng)用戶的操作。最后，電話?cǎi)v留時(shí)長(zhǎng)也可以通過(guò)配置文件來(lái)進(jìn)行調(diào)整。FreePBX支持了電話?cǎi)v留的界面配置，也支持了多種配置選項(xiàng)，用戶可以參考其功能配置：
　　16、Call Pickup
　　Call Pickup, 我們稱之為組內(nèi)代答或者呼叫代答功能。一般情況下，如果是企業(yè)客戶用戶的話，每個(gè)部門的員工都有各自的分機(jī)。如果有人呼叫分機(jī)1，分機(jī)1如果沒(méi)有應(yīng)答的話，分機(jī)2看到分機(jī)1用戶分機(jī)沒(méi)有人應(yīng)答，分機(jī)2用戶可以通過(guò)熱鍵來(lái)替正在振鈴的分機(jī)1代接此呼叫。一般情況下，如果系統(tǒng)用戶想替其他分機(jī)代接的話，這些分機(jī)必須在一個(gè)工作組或者根據(jù)業(yè)務(wù)類型分配的部門，同一組內(nèi)用戶可以互相代接其他用戶的呼叫。
　　組內(nèi)代接的具體處理流程需要經(jīng)過(guò)大概以上幾個(gè)步驟。假設(shè)，Alice呼叫Bob，Bob沒(méi)有應(yīng)答此呼叫。和Bob同組的Bill想為Bob代接此呼叫。為了代接此呼叫，Bill首先需要對(duì)Bob發(fā)送訂閱消息，通過(guò)訂閱消息獲取到Dialog消息內(nèi)容。然后，根據(jù)獲取的dialog消息內(nèi)容，對(duì)Alice發(fā)送INVITE請(qǐng)求消息，替換Bob。Alice收到INVITE請(qǐng)求以后，然后對(duì)Bob分機(jī)發(fā)送一個(gè)CANCEL取消的消息，通知Bob分機(jī)停止振鈴。這里讀者要注意，對(duì)于F11和F12相關(guān)的順序和200 OK（F10）它們之間是不確定的。
　　在以上圖例中的F7流程中，Replaces頭中使用了一個(gè)新的參數(shù)“early-only”，這個(gè)參數(shù)可以防止接受一個(gè)Bob可能已經(jīng)接受的INVITE請(qǐng)求。如果Bill已經(jīng)準(zhǔn)備從Bob那里代接此呼叫，無(wú)論Bill是否應(yīng)答呼叫，參數(shù)“early-only”就將不會(huì)出現(xiàn)在F7的流程中。另外，讀者需要注意一下Bob和Bill之間的訂閱會(huì)話創(chuàng)建的時(shí)間問(wèn)題。實(shí)際上，這個(gè)訂閱會(huì)話可能已經(jīng)存在于Alice呼叫Bob之前。這里的圖例是為了表達(dá)方便，而顯示在F3，Alice呼叫之后發(fā)生，實(shí)際上，Bob和Bill的訂閱可能已經(jīng)發(fā)生在Alice呼叫之前。
　　另外提醒讀者，根據(jù)RFC5359的描述，這里可能是拼寫錯(cuò)誤，把Bill說(shuō)成了Carol。以上流程圖中沒(méi)有Carol。
　　Also note that the subscription between Bob and Carol could have been
　　established prior to Alice's call.
　　關(guān)于"early-only”的規(guī)范定義，用戶可以參考RFC3891，此規(guī)范完整介紹了Replaces和其參數(shù)的使用方式，以及如何檢查INVITE重用�，F(xiàn)在，我們結(jié)合具體的SIP消息，配合每一個(gè)處理流程來(lái)一步步說(shuō)明組內(nèi)代接：
　　首先，Alice對(duì)Bob發(fā)送INVITE請(qǐng)求，要求和Bob進(jìn)行通話（F1）：
　　接下來(lái)，Bob對(duì)Alice發(fā)送180 Ringing，Bob分機(jī)振鈴（F2）。
　　這時(shí)，因?yàn)锽ob分機(jī)振鈴，無(wú)人接聽(tīng)電話，Bill打算為Bob代接呼叫，Bill對(duì)Bob發(fā)送訂閱消息來(lái)獲取呼叫的dialog身份確認(rèn)消息（F3）：
　　Bob收到Bill訂閱消息，然后回復(fù)200 OK（F4）：
　　緊接著，Bob對(duì)Bill發(fā)送NOTIFY消息，包括了訂閱消息的內(nèi)容和Alice的相關(guān)消息信息（F5）：
　　Bill回復(fù)Bob收到了訂閱的dialog消息內(nèi)容（F6），準(zhǔn)備對(duì)Alice發(fā)送INVITE請(qǐng)求。
　　Bill對(duì)Alice發(fā)送INVITE請(qǐng)求，替換Bob，使用了early-only（F7）：
　　Replaces: 12345600@atlanta.example.com
　　;from-tag=314578;to-tag=1234567;early-only
　　Alice收到Bill的INVITE請(qǐng)求，檢查匹配Replaces頭中的dialog，確認(rèn)以后，接受了這個(gè)來(lái)自于Bill的INVITE，然后對(duì)Bill發(fā)送200 OK（F8）：
　　Alice接受了Bill的INVITE以后，Alice還要對(duì)正在振鈴的Bob的分機(jī)發(fā)送一個(gè)CANCEL取消的回復(fù)，通知Bob分機(jī)停止振鈴（F9）：
　　Bob收到CANCEL以后，停止振鈴，然后對(duì)Alice回復(fù)200 OK（F10）：
　　然后Bob最后對(duì)Alice發(fā)送487 響應(yīng)消息，表示對(duì)Bob的請(qǐng)求正式結(jié)束（F11）：
　　Alice對(duì)Bob發(fā)送最后確認(rèn)消息ACK（F12），他們兩個(gè)人之間的會(huì)話關(guān)系正式結(jié)束。
　　Bill回復(fù)Alice發(fā)送的200 OK（F8）的ACK確認(rèn)消息（F13），雙方開始RTP語(yǔ)音流的傳輸，組內(nèi)代接成功。
　　經(jīng)過(guò)一段時(shí)間通話后，Alice先掛機(jī)，對(duì)Bill發(fā)送BYE消息（F14）：
　　然后，Bill對(duì)Alice發(fā)送最后的200 OK（F15），雙方通話結(jié)束。
　　大部分的企業(yè)IPPBX都支持了組內(nèi)代接功能。顧名思義，如果需要實(shí)現(xiàn)組內(nèi)代接功能的話，用戶首先需要?jiǎng)?chuàng)建一個(gè)呼叫組，組內(nèi)成員則可以通過(guò)IPPBX的系統(tǒng)熱鍵來(lái)代接電話。在asterisk或FreePBX平臺(tái)上，用戶可以按熱鍵*8來(lái)實(shí)現(xiàn)代接功能。當(dāng)然，其他平臺(tái)也可以通過(guò)熱鍵設(shè)置來(lái)接聽(tīng)代接電話。另外，用戶可以通過(guò)比較靈活和人性化的設(shè)計(jì)可以支持代接成功或者失敗的的語(yǔ)音提示，這樣可以讓用戶獲得更好的用戶體驗(yàn)。
　　17、Automatic Redial
　　Automatic Redial，我們稱之為自動(dòng)呼叫重?fù)芄δ�。�?jiǎn)單來(lái)說(shuō)，如果呼叫方呼叫被呼叫方時(shí)，對(duì)端如果處于忙狀態(tài)或者其他狀態(tài)，在一定時(shí)間后，呼叫方再次呼叫被呼叫方。具體的實(shí)現(xiàn)過(guò)程相對(duì)比較簡(jiǎn)單（查看以下圖例）。
　　假設(shè)，Alice呼叫Bob，這時(shí)Bob處于忙狀態(tài)可能正在接聽(tīng)其他電話呼叫，Bob正在通話中。Alice呼叫后，對(duì)Bob發(fā)送一個(gè)訂閱消息，對(duì)Bob分機(jī)狀態(tài)進(jìn)行訂閱。當(dāng)Bob處于空閑狀態(tài)后，Bob對(duì)Alice發(fā)送一個(gè)提醒消息，通知Alice現(xiàn)在Bob分機(jī)處于空閑狀態(tài)，可以對(duì)Bob分機(jī)進(jìn)行呼叫。Alice收到這個(gè)提醒消息以后，結(jié)束對(duì)Bob的狀態(tài)訂閱，然后，Alice對(duì)Bob發(fā)送一個(gè)INVITE請(qǐng)求，對(duì)Bob進(jìn)行呼叫，雙方互相通話。
　　下面，我們根據(jù)SIP消息內(nèi)容，結(jié)合每一個(gè)具體的處理流程來(lái)進(jìn)一步分析如何實(shí)現(xiàn)呼叫重?fù)芄δ堋?/div>
　　首先，Alice呼叫Bob，對(duì)Bob發(fā)送INVITE請(qǐng)求（F1）：
　　因?yàn)锽ob此時(shí)正處于忙狀態(tài)，所以，Bob回復(fù)Alice 一個(gè)486 響應(yīng)消息（F2）：
　　Alice回復(fù)一個(gè)ACK確認(rèn)消息（F3）：
　　為了獲悉Bob分機(jī)的狀態(tài)，Alice對(duì)Bob發(fā)送了一個(gè)訂閱（F4），獲取dialog消息內(nèi)容：
　　Bob回復(fù)Alice的訂閱，回復(fù)200 OK（F5）：
　　Bob對(duì)Alice發(fā)送NOTIFY消息（F6）：
　　Alice回復(fù)200 OK（F7）：
　　Bob分機(jī)處于空閑狀態(tài)，再次對(duì)Alice發(fā)送NOTIFY消息，提醒Alice現(xiàn)在Bob是處于空閑狀態(tài)（F8）。
　　Bob收到來(lái)自于Alice的提醒消息，Bob現(xiàn)在處于空閑狀態(tài)，回復(fù)200 OK（F9）：
　　然后，Alice馬上對(duì)Bob發(fā)送INVITE消息，進(jìn)行呼叫請(qǐng)求（F10）：
　　因?yàn)锽ob已經(jīng)是空閑狀態(tài)，所以接聽(tīng)了來(lái)自Alice的呼叫。對(duì)Alice返回180 振鈴消息（F11）：
　　Alice然后返回200 OK（F12）：
　　緊接著，Alice對(duì)Bob發(fā)送一個(gè)ACK確認(rèn)消息（F13），重?fù)芎艚薪油�。雙方開始語(yǔ)音流傳輸（F13）。
　　Bob再次對(duì)Alice發(fā)送NOTIFY消息（F14）：
　　Alice返回200 OK（F15）：
　　經(jīng)過(guò)以上互相發(fā)送NOTIFY和確認(rèn)消息，Alice已獲悉對(duì)方狀態(tài)，不再對(duì)Bob進(jìn)行狀態(tài)訂閱，結(jié)束訂閱，所以Alice對(duì)Bob再次發(fā)送訂閱通知，結(jié)束對(duì)Bob的訂閱（F16），重置Expire：0。
　　Bob回復(fù)Alice 200 OK（F17）:
　　Bob對(duì)Alice發(fā)送NOTIFY消息（F18），訂閱結(jié)束。
　　最后，Alice對(duì)Bob返回200 OK響應(yīng)消息（F19），訂閱結(jié)束確認(rèn)。
　　在以上的訂閱消息結(jié)束處理中，根據(jù)RFC6665的規(guī)范（4.1.2.3），取消訂閱可以通過(guò)重設(shè)Expire頭，設(shè)置expire:0 來(lái)通知取消訂閱。根據(jù)規(guī)范的說(shuō)明，成功取消訂閱會(huì)再次觸發(fā)一個(gè)最終NOTIFY消息（F18）。因此，讀者不用對(duì)此產(chǎn)生誤解。另外，我們這里沒(méi)有涉及更多訂閱的定時(shí)器刷新等問(wèn)題，更多關(guān)于訂閱的處理，讀者可以查閱rfc6665來(lái)做進(jìn)一步的學(xué)習(xí)。
　　關(guān)于訂閱功能使用方面，筆者建議讀者在部署IPPBX和使用SIP終端時(shí)要慎用此功能。因?yàn)�，一旦開啟了訂閱信息，IPPBX分機(jī)之間的訂閱消息會(huì)生成大量的無(wú)效的數(shù)據(jù)，這樣可能影響IPPBX本身的性能和企業(yè)內(nèi)網(wǎng)的網(wǎng)絡(luò)的穩(wěn)定性，還有用戶消息傳送的時(shí)延，這樣可能導(dǎo)致其他處理流程的錯(cuò)誤。比如，如果Bob的終端對(duì)Alice發(fā)送了NOTIFY消息，通知Alice現(xiàn)在Bob處于空閑狀態(tài)，Alice可以對(duì)其進(jìn)行呼叫，但是，可能當(dāng)前的Alice也正在處于其他的狀態(tài)，可能沒(méi)有可能再次及時(shí)對(duì)Bob發(fā)起呼叫，因此這個(gè)流程就會(huì)出現(xiàn)其他的問(wèn)題。
　　一些技術(shù)論文對(duì)消息導(dǎo)致的系統(tǒng)性能問(wèn)題和網(wǎng)絡(luò)優(yōu)化做了討論。Ahmadreza Montazerolghaem發(fā)表的論文關(guān)于重傳機(jī)制優(yōu)化的論文可能對(duì)讀者有所幫助，大家可以參考這個(gè)方法來(lái)進(jìn)一步優(yōu)化自己的網(wǎng)絡(luò)環(huán)境。
　　The Overload Reduction in SIP Servers through Exact Regulation of the Retransmission Timer of the Invite Message
　　Finnian McKeon 發(fā)表的論文中對(duì)SIP即時(shí)消息互發(fā)對(duì)網(wǎng)絡(luò)影響數(shù)據(jù)流量的影響可以給我們提供一些參考建議，用戶可以查閱研究。
　　另外，Maria Isabel Pous在論文-SIP-based Applications in UMTS: A Performance Analysis也對(duì)SIP消息產(chǎn)生的影響做了深入的分析，讀者可以查閱其論文作為參考資料。
　　18、Click to Dial
　　Click to Dial，我們稱之為點(diǎn)擊呼叫或頁(yè)面點(diǎn)擊呼叫。瀏覽器用戶以插件的形式或者頁(yè)面的形式通過(guò)瀏覽器訪問(wèn)點(diǎn)擊界面。用戶通過(guò)點(diǎn)擊頁(yè)面的一個(gè)SIP URL鏈接，頁(yè)面點(diǎn)擊呼叫消息傳遞給電腦SIP終端，終端配置了呼叫方的SIP URL地址，通過(guò)REFER發(fā)送SIP終端，然后SIP終端和被呼叫方創(chuàng)建一個(gè)會(huì)話連接，實(shí)現(xiàn)雙方呼叫。
　　這里的呼叫場(chǎng)景適合于簡(jiǎn)單的點(diǎn)對(duì)點(diǎn)的SIP呼叫場(chǎng)景。如果用戶通過(guò)媒體服務(wù)器實(shí)現(xiàn)呼叫的話，處理流程和我們現(xiàn)在討論的有所不同。具體的呼叫流程如下：
　　現(xiàn)在，我們配合具體的SIP消息內(nèi)容和每一個(gè)流程來(lái)簡(jiǎn)單說(shuō)明點(diǎn)擊呼叫的處理過(guò)程。
　　首先，Bob的PC端SIP對(duì)BobSIP電話發(fā)送REFER消息（F1），這里的頭域中設(shè)置了Refer-Sub：false，這表示PC端要求不生成REFER的dialog，僅支持2XX響應(yīng)消息。關(guān)于Refer-Sub的使用方法和參數(shù)設(shè)置，讀者可以查閱RFC4488。
　　然后，BobSIP電話終端回復(fù)202 接受（F2）：
　　接下來(lái)，Bob對(duì)Carol發(fā)送INVITE請(qǐng)求消息，表示需要對(duì)Carol進(jìn)行呼叫（F3）：
　　接下來(lái)，Carol對(duì)Bob SIP 電話回復(fù)180 振鈴（F4）：
　　然后，Alice對(duì)Bob SIP電話回復(fù)200 OK（F5）：
　　接下來(lái)，Bob的SIP 電話回復(fù)ACK確認(rèn)消息（F6），然后實(shí)現(xiàn)雙方語(yǔ)音流傳輸。
　　到此為止，整個(gè)點(diǎn)擊呼叫的流程結(jié)束，雙方開始電話互通。
　　事實(shí)上，現(xiàn)在點(diǎn)擊呼叫業(yè)務(wù)功能可以通過(guò)很多種方式實(shí)現(xiàn)，可以通過(guò)瀏覽器插件的形式實(shí)現(xiàn)，也可以通過(guò)HTML加腳本語(yǔ)言的形式實(shí)現(xiàn)，WebRTC或者郵件終端插件工具來(lái)實(shí)現(xiàn)。
　　特別是基于開源軟交換的平臺(tái)，例如Asterisk/FreePBX或者FreeSWITCH都可以通過(guò)接口語(yǔ)言來(lái)開發(fā)更加靈活的點(diǎn)擊呼叫功能。例如，通過(guò)腳本語(yǔ)言加Asterisk AMI接口實(shí)現(xiàn)的頁(yè)面點(diǎn)擊呼叫功能。用戶可以下載以下代碼來(lái)實(shí)現(xiàn)點(diǎn)擊呼叫功能。以下是一個(gè)PHP的頁(yè)面點(diǎn)擊呼叫實(shí)例地址，讀者可以參考：
　　https://github.com/spbx/Simple-Click2Call-for-Asterisk-PBX/blob/master/click2dial.php
　　基于Asterisk的點(diǎn)擊呼叫的插件，用戶可以參考TBDialOut來(lái)實(shí)現(xiàn)，開源項(xiàng)目地址：
　　http://www.oak-wood.co.uk/tbdialout/
　　19、總結(jié)討論
　　筆者根據(jù)RFC5359，結(jié)合一些具體的圖例非常系統(tǒng)地討論了最常用的18個(gè)SIP呼叫流程的具體細(xì)節(jié)。在每一個(gè)細(xì)節(jié)中，筆者增加了一些相關(guān)的討論，幫助讀者能夠更加全面地了解部署使用時(shí)的問(wèn)題和風(fēng)險(xiǎn)。筆者再次強(qiáng)調(diào)，這18個(gè)SIP呼叫業(yè)務(wù)是一個(gè)規(guī)范流程，不一定是強(qiáng)制執(zhí)行的標(biāo)準(zhǔn)，特別是涉及到Proxy的內(nèi)容，讀者一定要注意。不同的Proxy或者媒體服務(wù)器可能對(duì)流程的處理有所不同，讀者需要根據(jù)自己的部署平臺(tái)來(lái)對(duì)照檢查。整體而言，通過(guò)這18個(gè)完整的SIP呼叫業(yè)務(wù)細(xì)節(jié)討論，筆者為提供SIP呼叫業(yè)務(wù)的技術(shù)人員提供了相對(duì)比較完整的學(xué)習(xí)資料和比較權(quán)威的參考，希望對(duì)大家有所幫助。
　　另外，因?yàn)楣P者水平和資源有限，肯定有很多錯(cuò)誤之處，敬請(qǐng)諒解。
　　參考資料：
　　https://tools.ietf.org/html/rfc4579
　　https://www.rfc-editor.org/rfc/rfc5359.txt
　　https://tools.ietf.org/html/rfc7088
　　https://www.rfc-editor.org/rfc/rfc3515.txt
　　https://tools.ietf.org/html/rfc3840
　　https://tools.ietf.org/html/rfc3891
　　https://www.rfc-editor.org/rfc/rfc6665.txt
　　http://file.scirp.org/Html/1-1730003_32286.htm
　　https://arrow.dit.ie/cgi/viewcontent.cgi?
　　referer=https://www.google.com/&httpsredir=1&article=1005&context=ittscicon
　　http://www.cs.columbia.edu/~nahum/papers/sip-multicore-journal.pdf
　　https://support.sonus.net/display/SBXDOC51/GRUU+Support
　　https://www.tech-invite.com/fo-sip/tinv-fo-sip-service-99.html
　　www.freepbx.org.cn
　　https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/recon/MOHParkServer/doc/MOHParkServer_User_Documentation.pdf?revision=8937&view=co
　　http://ijsetr.com/uploads/463152IJSETR13872-273.pdf
　　https://tools.ietf.org/html/rfc3665
　　https://tools.ietf.org/html/rfc3265
　　https://tools.ietf.org/html/rfc3515
　　https://tools.ietf.org/html/rfc4317


　　關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
　　Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
　　Asterisk freepbx技術(shù)文檔： www.freepbx.org.cn
　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
　　Asterisk/FreePBX中國(guó)合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817

【免責(zé)聲明】本文僅代表作者本人觀點(diǎn)，與CTI論壇無(wú)關(guān)。CTI論壇對(duì)文中陳述、觀點(diǎn)判斷保持中立，不對(duì)所包含內(nèi)容的準(zhǔn)確性、可靠性或完整性提供任何明示或暗示的保證。請(qǐng)讀者僅作參考，并請(qǐng)自行承擔(dān)全部責(zé)任。

專題

CTI論壇會(huì)員企業(yè)