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

　　Carol回復(fù)Bob一個180振鈴（F9）：

　　緊接著，Carol回復(fù)Bob一個200 OK（F10）。注意，這里的參數(shù)已經(jīng)增加了一個gruu。

　　Bob對Carol回復(fù)了一個ACK確認(rèn)消息（F11），開始媒體流。

　　經(jīng)過Bob和Carol通話以后，Bob告訴Carol，Alice想和Carol直接通話，Carol同樣和Alice通話。Bob將此通話設(shè)置為等待狀態(tài)，邀請Alice和Carol通話。

　　Carol對Bob發(fā)送200 OK（F13）：

　　Bob收到Carol的ACK消息（F14），Bob和Carol最終確定轉(zhuǎn)接。

　　然后Bob對Alice發(fā)送REFER消息，開始通知Carol的地址：

　　Alice收到202 接受消息（F16），表示接受這個轉(zhuǎn)接。

　　緊接著，Alice繼續(xù)對Bob發(fā)送NOTIFY消息（F17），通知Bob一個訂閱事件，告知Alice電話轉(zhuǎn)接的流程處理狀態(tài)。

　　Bob收到Alice 200 OK（F18）：

　　獲悉了Bob已經(jīng)知道訂閱事件以后，Alice開始對Carol發(fā)送INVITE請求（F19），并且替換了Bob。

　　Carol對Alice 發(fā)送200 OK（F20）：

　　然后，Alice對Carol發(fā)送ACK確認(rèn)消息（F21），開始RTP語音流，轉(zhuǎn)接完成。

　　因為，Alice和Carol已經(jīng)開始RTP流的交互，所以緊接著，Carol需要對Bob進行掛機處理。因此，Carol對Bob發(fā)送BYE消息，雙方掛機（F22）。

　　Bob對Carol發(fā)送200 OK，執(zhí)行掛機處理（F22）：

　　到現(xiàn)在為止，Alice仍然需要告訴Bob電話轉(zhuǎn)接狀態(tài)。因此，Alice對Bob發(fā)送第二個NOTIFY事件，通知Bob電話已經(jīng)完全成功轉(zhuǎn)接（F24）：

　　Bob發(fā)送一個 200 OK消息，表示收到此事件（F25）：

　　然后Bob對Alice掛機，發(fā)送BYE消息（F26）：

　　最后，Alice對Bob發(fā)送200 OK（F27），詢轉(zhuǎn)正式流程結(jié)束。

　　6、Transfer - Instant Messaging

　　Transfer - Instant Messaging，我們稱之為即時消息轉(zhuǎn)發(fā)。其主要的工作方式是，首先用戶Alice和Bob創(chuàng)建了一個會話，然后Bob呼叫Carol，Bob發(fā)送即時消息給Carol，即時消息中包含一個Alice的URL和一個嵌入的Replace頭。如果Carol點擊這個URL鏈接，Carol的SIP終端會對Alice發(fā)送一個INVITE請求，并且替換了會話中的Bob。在這個示例中，其URL傳遞是使用的SIP MESSAGE method來實現(xiàn)（參考RFC3428），也可以使用其他IM即時協(xié)議來完成Bob和Carol之間的URL傳遞工作。具體的處理流程經(jīng)過11個步驟：

　　現(xiàn)在，我們配合SIP消息來進一步說明如何實現(xiàn)即時消息轉(zhuǎn)發(fā)方式。

　　首先，Alice對Bob發(fā)送INVITE消息（F1）：

　　Bob回復(fù)180（F2）：

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

　　Alice對Bob發(fā)送Ack確認(rèn)，開始RTP流（F4）：

　　然后Bob對Carol發(fā)送一個message call（F5），在這個即時消息中攜帶了Alice的URL和Replaces頭。

　　Carol看到以后，發(fā)送一個200 OK給Bob：

　　接下來，Carol點擊URL，控制這個呼叫，對Alice發(fā)送一個INVITE請求，并且替換了Bob（F7）。

　　Alice對比dialog中消息和Replaces的頭消息，確認(rèn)以后，接受Carol的請求。Alice對Carol回復(fù)一個200 OK（F8）：

　　Carol對Alice回復(fù)了ACK消息（F9），并且開始RTP流。

　　Alice和Carol開始通話以后，并且因為已經(jīng)替換了Replaces頭，所以Alice對Bob掛機處理，Alice對Bob發(fā)送BYE消息（F10）：

　　Bob對Alice發(fā)送200 OK（F11），到此為止，即時消息轉(zhuǎn)接的流程完成。

　　7、Call Forwarding Unconditional

　　Call Forwarding Unconditional，我們稱之為無條件呼叫前轉(zhuǎn)。從字面意思，讀者也可以看明白，被呼叫方會把呼叫進行無條件轉(zhuǎn)移。與之對應(yīng)的是忙狀態(tài)呼叫前轉(zhuǎn)和無應(yīng)答呼叫前轉(zhuǎn)。這些業(yè)務(wù)都涉及到了運營商接入業(yè)務(wù)（PSTN或者IMS），不是專門針對內(nèi)網(wǎng)IPPBX用戶之間的電話轉(zhuǎn)接功能。我們會在后續(xù)的章節(jié)中分別介紹這兩種呼叫的流程。這里，我們僅對無條件前轉(zhuǎn)進行分析。

　　這里，我們假設(shè)Alice呼叫Bob（這里沒有標(biāo)識Bob的流程）。Bob會把呼叫無條件前轉(zhuǎn)到PSTN網(wǎng)絡(luò)。如果實現(xiàn)此場景，呼叫必須經(jīng)過Proxy和Gateway來實現(xiàn)處理。Gateway看作為另外一個Proxy的URL地址，同時支持了PSTN的接口。在以下的場景中，Alice對Bob進行呼叫，這個INVITE消息會經(jīng)過Proxy，Proxy則會重寫請求的URL地址，然后前轉(zhuǎn)這個INVITE到Gateway地址。以上兩步是前轉(zhuǎn)最重要的部分，所以，我們僅針對這個部分進行深入分析，對網(wǎng)關(guān)側(cè)和Bob的響應(yīng)不做分析。

　　這里，讀者需要注意，在以上示例中的F3中，Proxy是通過返回Alice 一個181 響應(yīng)消息來實現(xiàn)的呼叫前轉(zhuǎn)處理。嚴(yán)格地說，在這個使用場景中，Proxy僅扮演著用戶代理的角色，它不能生成non-100的臨時響應(yīng)回復(fù)消息。另外需要說明的是，呼叫前轉(zhuǎn)的處理也可以通過redirect的方式來實現(xiàn)，就是通常所說302 Moved Temporarily response。以下圖例是一個完整的無條件呼叫前轉(zhuǎn)流程和具體的SIP消息操作。

　　接下來，我們針對無條件呼叫前轉(zhuǎn)的具體細(xì)節(jié)，結(jié)合請求響應(yīng)消息進行分析介紹。首先，Alice對Bob發(fā)送INVITE請求，通過Proxy執(zhí)行呼叫（F1）：

　　然后，Proxy回復(fù)Alice 一個100 trying（F2），表示正在處理這個請求，忽略了流程圖。接下來，Proxy會對Alice發(fā)送一個181響應(yīng)消息（181 Call is Being forwarded），執(zhí)行F3流程；同時Proxy對Gateway發(fā)出一個INVITE請求（F4）。這里，Proxy對Gateway發(fā)送到INVITE請求中已經(jīng)重寫了請求URL地址。

　　讀者可以看到，Proxy和Gateway都沒有做任何其他的條件判斷，直接轉(zhuǎn)發(fā)到下一個目的地地址。在F5中，Gateway直接對Proxy回復(fù)一個180 Ringing，然后在F6中，Proxy回復(fù)Alice一個180 Ringing。

　　Gateway對Proxy發(fā)送180 Ringing以后，緊接著，Gateway對Proxy發(fā)送200 OK（F7），然后Proxy對Alice發(fā)送200 OK（F8）。

　　Alice收到200 OK以后，接下來，Alice對這個INVITE請求進行確認(rèn)，發(fā)送ACK消息（F9）。Proxy收到ACK消息以后，直接對Gateway發(fā)送ACK確認(rèn)信息（F10）。雙方RTP語音流正式創(chuàng)建。

　　通話完成后，Alice掛機，對Proxy發(fā)送BYE消息（F11），然后Proxy對Gateway發(fā)送BYE消息（F12）。

　　最后，Gateway對Proxy發(fā)送200 OK（F13），Proxy再對Alice發(fā)送200 OK（F14），到這里，雙方的無條件呼叫前轉(zhuǎn)正式結(jié)束。

　　8、Call Forwarding - Busy

　　Call Forwarding - Busy，我們稱之為遇忙呼叫前轉(zhuǎn)。簡單來說，就是呼叫方通過Proxy呼叫被呼叫方時，被呼叫方此時處于忙狀態(tài)，然后Proxy把呼叫再次轉(zhuǎn)發(fā)到第三方用戶。例如，Alice通過Proxy呼叫用戶1，此時，如果用戶1處于忙狀態(tài)，Proxy收到用戶1的回復(fù)信息，Proxy會把此呼叫通過一個INVITE再次轉(zhuǎn)發(fā)到用戶2終端。遇忙呼叫前轉(zhuǎn)到流程圖如下：

　　下面，我們配合具體的SIP消息示例來進一步說明整個遇忙呼叫前轉(zhuǎn)的處理過程。

　　首先，Alice對Proxy發(fā)送一個INVITE請求，需要呼叫用戶1（F1），Proxy

　　接下來對用戶1發(fā)送一個INVITE請求，通知用戶1，Alice要呼叫對方。

　　在處理以上流程的同時，Proxy會對Alice發(fā)送一個100 Trying（F3），Proxy告訴Alice正在處理此呼叫，忽略了100 Trying圖例。經(jīng)過一定時間后，用戶1此時此刻正在處于電話的忙狀態(tài)，不能接聽此呼叫。然后用戶1對Proxy發(fā)送了一個486 Buy響應(yīng)消息（F4）。

　　Proxy獲悉用戶1是處于忙狀態(tài)后，對用戶1發(fā)送一個ACK確認(rèn)信息，表示收到了用戶1的狀態(tài)響應(yīng)（F5）。

　　為了處理用戶1處于忙狀態(tài)不能接聽電話的問題，Proxy首先通知Alice，proxy需要進行電話前轉(zhuǎn)。所以，Proxy需要對Alice發(fā)送一個180 call is Being Forwarded的消息，通知Alice，你的呼叫正在被前轉(zhuǎn)。同時，Proxy再次發(fā)起一個INVITE請求，這次，對用戶2發(fā)出INVITE請求進行呼叫前轉(zhuǎn)。

　　接下來，用戶2對Proxy發(fā)送180 Ringing響應(yīng)消息（F8），Proxy然后對Alice發(fā)送180 Ringing響應(yīng)消息（F9），表示前轉(zhuǎn)接受。

　　發(fā)送180 Ringing以后，緊接著，用戶2對Proxy發(fā)送200 OK（F10），然后Proxy對Alice發(fā)送200 OK（F11）。

　　Alice收到Proxy發(fā)送的200 OK以后，發(fā)送確認(rèn)消息ACK（F12）。然后Proxy對用戶2發(fā)送確認(rèn)消息ACK（F13）。接下來，Alice和用戶2創(chuàng)建媒體流，雙方開始正常通話。

　　通話結(jié)束后，Alice對Proxy發(fā)送BYE消息（掛機，F(xiàn)14），然后Proxy對用戶2發(fā)送BYE消息（F15）。

　　最后，雙方進行掛機的最終確認(rèn)，首先由用戶2發(fā)送200 OK到Proxy（F16），然后Proxy對Alice發(fā)送200 OK（F17）。

　　到此為止，遇忙呼叫前轉(zhuǎn)的處理流程正式結(jié)束。

　　9、Call Forwarding - No Answer

　　Call Forwarding-NO Answer, 我們稱之為無應(yīng)答前轉(zhuǎn)。具體的實現(xiàn)過程和前面談?wù)撁艚星稗D(zhuǎn)的處理方式基本一致，唯一不同是，用戶1是無應(yīng)答，然后Proxy通過定時器檢測超時，進行對第三方用戶2前轉(zhuǎn)處理。其余的處理流程基本和遇忙前轉(zhuǎn)的處理流程一致。簡單來說，Alice通過Proxy呼叫用戶1，用戶1在一定時間內(nèi)沒有應(yīng)答此呼叫，然后Proxy把這個呼叫轉(zhuǎn)接到用戶2，對用戶2進行呼叫處理。在請求超時后（F6），Proxy對用戶1發(fā)送取消請求，然后通知Alice，同時對用戶2再次進行INVITE請求處理，進行呼叫請求。具體的呼叫流程如下：

　　接下來，筆者配合具體的SIP消息來進一步說明無應(yīng)答呼叫前轉(zhuǎn)的處理方式。

　　首先，Alice通過Proxy對用戶1發(fā)出INVITE請求，對用戶1進行呼叫（F1），然后Proxy對用戶1發(fā)送INVITE請求，對用戶2進行呼叫請求處理。

　　接下來，Proxy馬上對Alice發(fā)送一個100 Trying（F3忽略），表示正在對用戶1進行呼叫，通知Alice等待。用戶1對Proxy發(fā)送180 Ringing（F4），Proxy也對Alice發(fā)送180 Ringing（F5）。

　　這時，用戶1處于振鈴狀態(tài)，在Proxy設(shè)定的定時器超時設(shè)置范圍內(nèi)，用戶1終端無人接聽此呼叫。因此，Proxy對用戶1發(fā)送Cancel消息，通知用戶1停止振鈴。

　　然后，用戶1對Proxy發(fā)送200 OK（F7）：

　　接下來，用戶1馬上對Proxy發(fā)送一個487 響應(yīng)消息，表示定時器超時，在一定振鈴時間內(nèi)無人應(yīng)答此呼叫。

　　Proxy收到超時消息以后，對用戶1發(fā)送ACK確認(rèn)消息，確認(rèn)超時事件（F9）：

　　這時，Proxy需要做兩件事。Proxy知道用戶1是因為振鈴超時，無人應(yīng)答這個呼叫。接下來，Proxy重新調(diào)整呼叫流程，再次進行呼叫轉(zhuǎn)接到處理。首先，Proxy先對Alice發(fā)送一個電話轉(zhuǎn)接到響應(yīng)消息（181 電話前轉(zhuǎn)），通知Alice，你的呼叫正在被前轉(zhuǎn)到其他用戶終端（F10）。緊接著Proxy對用戶2發(fā)送一個INVITE請求，對其進行呼叫（F11）：

　　然后，用戶2對Proxy發(fā)送180 Ringing（F12），Proxy又對Alice發(fā)送180 Ringing（F13）：

　　振鈴發(fā)送以后，用戶2繼續(xù)對Proxy發(fā)送200 OK（F14），Proxy又對Alice發(fā)送200 OK（F15）：

　　Alice收到200 OK以后，繼續(xù)對此流程進行進一步的處理，以便開始雙方的通話或RTP流。Alice馬上回復(fù)Proxy ACK確認(rèn)消息（F16），Proxy也馬上對用戶2回復(fù)ACK確認(rèn)消息（F17）：

　　經(jīng)過一定時間段通話以后，Alice首先掛機，對Proxy發(fā)送BYE消息（F18），Proxy再對用戶2發(fā)送BYE消息（F19），通知用戶2掛機：

　　最后，用戶2對Proxy發(fā)送最后200 OK消息（F20），然后Proxy對Alice發(fā)送最后的200 OK（F21）。到此為止，無應(yīng)答呼叫前轉(zhuǎn)的呼叫流程正式完成。

　　這里讀者一定要注意，我們討論的呼叫前轉(zhuǎn)方式方式可以通過IPPBX或者軟交換的配置來實現(xiàn)，proxy或者媒體服務(wù)器的設(shè)置會影響振鈴的時長設(shè)置，這樣可能導(dǎo)致電話振鈴問題，被呼叫方如果接聽不及時的話，可能產(chǎn)生無應(yīng)答呼叫。

　　所以，在部署前轉(zhuǎn)時一定要配合IPPBX或者其他的軟交換來解決。另外，結(jié)合一些其他的應(yīng)用需求，還有一些IPPBX可以設(shè)置為無應(yīng)答或者分機隨行的方式，如果終端無應(yīng)答，可以轉(zhuǎn)接到用戶手機或者其他的終端，或者留言等方式。這些需要用戶支持其他的接入方式來實現(xiàn)。

　　10、3-Way Conference - Third Party Is Added

　　3-Way Conference - Third Party Is Added，我們稱之為三方會議邀請。簡單來說，此呼叫業(yè)務(wù)就是一個簡單的三方電話會議。通常來說，如果是兩方通話，我們稱之為正常呼叫業(yè)務(wù)。如果介入了第三方或者更多人的話，我們稱之為三方會議或者多方會議。

　　一般的三方會議至少需要一個混音處理單元。在以下的部署場景中，Alice呼叫Bob，然后雙方進行通話。這時，Bob想把第三方Carol也邀請到電話會議中來一起討論問題。當(dāng)然，Bob自己本身必須具備處理第三方媒體混音的功能。然后，Bob首先對Alice發(fā)送一個re-INVITE，在INVITE中，修改了多個Contact URLs為一個URL，這個URL表示Bob的混音單元。然后，Bob對Carol發(fā)送一個INVITE請求，邀請Carol參加會議，并且使用同樣的Contact URL。

　　這里，讀者要注意，Bob邀請的處理方式可能有所不同。Bob可以先等Carol應(yīng)答以后，再對Alice發(fā)送re-INVITE。Bob也可以呼叫Carol之前，先把Alice設(shè)置為等待狀態(tài)。另外，Bob邀請會議時，Bob包含了一個功能標(biāo)簽tag-“isfocus”，表示Bob是一個會議處理中心。"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)于會議中focus的定義和規(guī)范，讀者可以參考rfc4579的第三章節(jié)。以下是一個完整的會議第三方邀請?zhí)幚砹鞒獭?/div>

　　下面，我們通過SIP消息結(jié)合具體的流程來說明第三方會議邀請是如何進行的。

　　首先，Alice對Bob發(fā)送INVITE請求，對其進行呼叫（F1）：

　　Bob對Alice回復(fù)180 Ringing（F2）：

　　11、3-Way Conference - Third Party Joins

　　3-Way Conference - Third Party Joins，我們稱之為三方會議加入。和上面的三方會議邀請不同的是，這里的第三方是自己主動希望加入到電話會議中，而不是由其他人邀請加入。因此，在處理三方會議時，其處理流程和前面的被邀請的方式完全不同。

　　通過以上的處理流程我們來詳細(xì)解釋會議加入的方式是如何處理的。這里，我們假設(shè)Alice和Bob兩個人正在進行雙方的語音通話。Carol通過其他學(xué)習(xí)方式或者對Bob的訂閱消息，例如Bob發(fā)送的其他非SIP消息或者Bob對Carol發(fā)送到NoTIFY消息，其消息中含有dialog事件包。關(guān)于dialog的事件訂閱的處理，讀者可以參考RFC4579中的第5.8章節(jié)和RFC4235的規(guī)范。

　　這時，Carol希望加入到Alice和Bob之間的電話呼叫中。這時，Carol會對Bob發(fā)送一個INVITE請求（F5），這個請求中包含一個Join頭，在這個頭中，包含Alice和Bob兩者之間的dialog，以此來保證Carol加入到是正確的dialog，而不是其他的會議呼叫。Bob然后對Alice發(fā)送一個re-INVITE修改了通話模式（F7），從雙方談話變成一個“isfocus”模式（rfc3840），開始支持三方會議的模式。然后，Bob才接受來自于Carol的INVITE請求，最后開始三方通話或者電話會議模式，此時，三方會議加入的處理流程徹底完成�，F(xiàn)在，我們通過完整的SIP消息配合具體的處理流程來進一步對電話加入的方式做出詳細(xì)介紹。

　　首先，Alice對Bob發(fā)送INVITE請求，進行電話呼叫（F1）：

　　然后，Bob對Alice發(fā)送180 Ringing（F2），緊接著，Bob對Alice發(fā)送200 OK（F3）：

　　然后，Alice對200 OK回復(fù)ACK確認(rèn)信息（F4），雙方開始RTP流傳輸：

　　這時，Carol通過Bob發(fā)送到其他的非SIP消息或者NOTIFY事件了解了Alice和Bob之間正在進行電話呼叫，Carol想加入到這個電話呼叫中。因此，Carol對Bob發(fā)送一個INVITE請求，在這個INVITE請求中（F5），包含有Join的頭，這個頭中含有加入他們之間還有的dialog消息內(nèi)容（Join中忽略了具體的內(nèi)容）：

　　Bob先對Carol發(fā)送一個180 Ringing（F6）：

　　然后，Bob再對Alice發(fā)送一個re-INVITE請求，Bob通知Alice，因為Carol要加入電話會議中，我現(xiàn)在需要修改通話模式，修改為“isfocus”模式來支持電話會議，需要進行媒體混音處理。

　　Alice收到Bob的INVITE請求后，對其請求表示同意，然后對Bob發(fā)送200 OK（F8）：

　　Bob對Alice 的200 OK發(fā)送響應(yīng)消息，獲悉Alice同意修改為會議模式（F9）：

　　現(xiàn)在，Bob完成了和Alice的協(xié)商，獲悉Alice已經(jīng)準(zhǔn)備好進行電話會議。接下來，Bob才對Carol發(fā)送200 OK，接受了其要求加入電話會議的INVITE請求，這里包括了新的Contact的會議地址。

　　接下來，Carol知道Bob已經(jīng)允許自己可以加入到會議中，對Bob發(fā)送最后ACK確認(rèn)消息，表示正式加入會議中。此時，Carol加入到了會議室，三方會議正式開啟（F11），RTP流開始工作。這里的Bob構(gòu)成了一個媒體混音單元，也可能是一個會議媒體服務(wù)器功能，進行三方混音。

　　這里，筆者再進一步介紹一下會議的標(biāo)簽isfocus tag。會議模式中的isfocus參數(shù)可以支持多種使用方式，通過SIP，它可以支持以下幾種方式：

創(chuàng)建會議
加入會議
邀請用戶加入會議
踢出會議用戶
支持對會議URL判斷，可以檢查到是否是會議URL
刪除會議

　　會議創(chuàng)建的方式Ad-Hoc方式臨時自組的方式來創(chuàng)建一個會議，也可以通過REFER方式來創(chuàng)建一個會議室。會議邀請的方式可以通過INVITE請求，用戶可以主動呼入或者用戶被呼方式來進入到會議室，也可以通過REFER的方式邀請用戶進入到會議室。關(guān)于會議的管理和使用部署，RFC4579中有著非常詳細(xì)的說明，同時此規(guī)范也介紹了其他的協(xié)商流程。讀者可以閱讀此規(guī)范進一步了解多方會議的處理流程。

　　在開源媒體服務(wù)器中，Asterisk/FreePBX/FreeSWITCH也支持了強大的會議功能。用戶可以創(chuàng)建會議室，系統(tǒng)通過自動撥號的形式邀請會議用戶來加入到會議中，用戶也可以通過語音IVR的形式進入到會議室中。會議主席也可以對會議人員實現(xiàn)靜音或者踢出等功能。如果使用Asterisk的界面管理系統(tǒng)FreePBX，用戶也可以通過界面來創(chuàng)建會議室，支持多種會議的管理功能，例如會議密碼設(shè)置，最大會議用戶人數(shù)設(shè)置，進入會議室播放提示，音樂等待等功能。

　　12、Find-Me

　　Find-Me, 我們稱之為有效用戶查詢呼叫。簡單來說，Alice通過Proxy呼叫Bob，Bob可能有幾個Contact地址。Proxy會根據(jù)不同的Contact列表來逐一查詢這些地址的狀態(tài)，如果有可接通的地址，則對其進行呼叫；如果沒有，Proxy會繼續(xù)查詢其他的地址，直到找到可接聽呼叫的地址。一旦找到可接聽通話的地址，則不再繼續(xù)查詢其他的地址。

　　這里筆者提醒讀者，在對用戶狀態(tài)的查詢中，系統(tǒng)也可以使用并列查詢的方式。我們剛才使用的是按序查詢的方式，系統(tǒng)也可以使用并列查詢的方式。并列查詢狀態(tài)下，Proxy會同時對所有Contact 列表中的地址發(fā)送查詢可接聽的地址，然后創(chuàng)建RTP語音流。以下圖例中說明了兩種重新的處理不同。并列查詢的處理方式：

　　按序查詢的處理方式：

　　在本章節(jié)的有效用戶查詢呼叫中，我們使用的方式是按序查詢的方式。Proxy會通過Bob的Contact列表逐一查詢地址狀態(tài)，如果有效，則創(chuàng)建呼叫。

　　下面，我們結(jié)合SIP消息和具體的流程進行分析。

　　首先，Alice通過Proxy對Bob進行呼叫，發(fā)送INVITE請求給Proxy（F1），Proxy對Bob發(fā)送INVITE請求（F2）：

　　接下來，Proxy馬上回Alice 一個100 Trying（這里忽略，F(xiàn)3），表示呼叫正在處理中。用戶1對Proxy回一個180 Ringing（F4）。緊接著，Proxy對Alice回復(fù)一個180 Ringing，表示用戶1已經(jīng)振鈴（F5）。

　　但是，在一定的振鈴時間內(nèi)，用戶1沒有人接聽電話呼叫，Proxy的定時器出現(xiàn)超時。然后，Proxy對用戶1發(fā)送Cancel消息（F6）。

　　用戶1對Proxy回復(fù)一個200 OK（F7）：

　　然后，用戶1對Proxy發(fā)送一個487 超時消息（F8）：

　　Proxy對487 回復(fù)一個ACK確認(rèn)消息（F9）：

　　在獲悉用戶1呼叫超時以后，Proxy繼續(xù)對Contact 列表中的用戶2地址發(fā)送INVITE請求（F10）：

　　但是，用戶2根本沒有登錄注冊，所以，用戶2回復(fù)480 消息（F11）

　　Proxy對用戶2回復(fù)ACK確認(rèn)（F12）：

　　然后，Proxy繼續(xù)對Bob的Contact 列表中的用戶3地址發(fā)送INVITE請求消息（F13）：

　　但對用戶3發(fā)送INVITE請求后，發(fā)現(xiàn)用戶3處于忙狀態(tài)，不能接聽這個呼叫。用戶3回復(fù)486 Busy Here（F14）:

　　緊接著，Proxy對用戶3回復(fù)ACK確認(rèn)消息（F15）：

　　接下來，Proxy繼續(xù)對Bob的Contact列表中的用戶4地址發(fā)送INVITE請求（F16）：

　　然后，用戶4回復(fù)Proxy 180 Ringing（F17），Proxy再回復(fù)Alice一個180 Ringing（F18）：

　　緊接著，用戶4對Proxy發(fā)送一個200 OK（F19），然后，Proxy又對Alice發(fā)送一個200 OK（F20）：

　　然后，Alice對Proxy發(fā)送一個ACK確認(rèn)消息（F21），Proxy對用戶4發(fā)送一個ACK確認(rèn)消息（F22）。到此為止，整個有效用戶查詢呼叫的流程完成，雙方開始語音流的互通。

　　結(jié)合以上多種用戶終端出現(xiàn)的情況，Proxy經(jīng)過了Bob的4個Contact列表地址查詢，第一個呼叫超時，第二個地址沒有登錄，第三個用戶忙，到最后一個用戶地址，才真正和Alice創(chuàng)建了RTP語音流的傳輸。在每一個異常狀態(tài)下，終端都返回相應(yīng)的響應(yīng)消息，然后Proxy會對每一個響應(yīng)發(fā)送ACK，然后再進行下一個有效用戶的地址查詢。

　　通話一段時間后，用戶4對Alice掛機，對Proxy首先發(fā)送BYE消息（F23）， Proxy對Alice進行掛機處理，對其發(fā)送BYE消息（F24）：

　　然后，Alice對Proxy發(fā)送200 OK（F25），Proxy再對用戶4發(fā)送200 OK（F26）：

　　Alice和用戶4的通話正式結(jié)束。

　　13、Call Management （Incoming Call Screening）

　　Call Management （Incoming Call Screening），我們這里稱之為呼叫篩選或呼叫過濾。在企業(yè)通信環(huán)境中，為了節(jié)省員工的時間，提高工作效率，用戶可以設(shè)置一個電話篩選機制來保證不被一些不相關(guān)的電話騷擾。簡單來說，如果有外部呼叫呼入到IPPBX的終端時，終端可以顯示呼叫方號碼，或者名稱，或者通過第三方媒體發(fā)送到語音提示。此時，終端用戶可以根據(jù)終端所設(shè)置的號碼地址薄選擇繼續(xù)接聽電話，拒絕，轉(zhuǎn)語音郵箱，或者對呼叫方播放一個自定義的語音媒體。以上這些功能都可以通過Proxy加媒體播放服務(wù)器來實現(xiàn)，或者使用企業(yè)IPPBX本身的配置功能來實現(xiàn)。為了更加專業(yè)地表達(dá)此功能名稱，我們稱之為呼叫篩選或呼叫過濾，黑白名單過濾比較通俗易懂。其實，呼叫篩選和黑白名單過濾的功能要求基本類似，從功能設(shè)置的角度來說它們的功能基本相同。

　　在日常生活中，我們簡單稱之為黑白名單過濾。因為大量的騷擾電話的問題，我們現(xiàn)在已經(jīng)對呼叫篩選不陌生了。我們手機app所設(shè)置的騷擾電話設(shè)置或者黑名單過濾等都可以視為呼叫篩選的功能。但是，這些基于個人終端的業(yè)務(wù)支持，不是我們這里討論的內(nèi)容。

　　呼叫篩選的具體流程經(jīng)過了幾個步驟。假設(shè)，Alice呼叫用戶Bob，Bob的終端聯(lián)系方式中可能已經(jīng)對Alice設(shè)置為拒絕接聽的地址，因此Bob拒絕接聽此呼叫。拒絕接聽后，Bob對Alice返回了一個消息，通知你呼叫必須通過Proxy的安全認(rèn)證機制，Bob僅接受經(jīng)過Proxy確認(rèn)的呼叫。因此，Alice再次對Proxy發(fā)送請求，但是因為安全設(shè)置的問題，Alice沒有通過Proxy的安全認(rèn)證，Proxy在錯誤消息返回時插入了一個新的Error-info的URL地址，Alice播放這個來自于媒體服務(wù)器或者第三方聲明提示等服務(wù)器的語音提示。

　　這里注意，安全認(rèn)證不能使用From 頭來判斷，必須通過Proxy的安全機制來處理。以下是一個呼叫篩選的流程圖，在圖例中，一般企業(yè)用戶使用IPPBX本身自帶的媒體播放功能對Alice實現(xiàn)媒體語音提示。
　　接下來，我們根據(jù)SIP消息細(xì)節(jié)結(jié)合每一個處理流程來進一步說明呼叫篩選的處理過程。

　　首先，Bob看到來自于Alice的呼叫，表示Alice需要和Bob通話（F1）。

　　Bob拒絕了Alice的呼叫請求，要求必須通過Proxy認(rèn)證才能通話。Bob對Alice發(fā)送305消息（F2）：

　　Alice獲悉這個錯誤以后，對Bob發(fā)送ACK確認(rèn)消息（F3）：

　　然后，Alice對Proxy發(fā)送INVITE請求（F4）：

　　然后，Proxy對Alice發(fā)送認(rèn)證響應(yīng)消息407（F5）:

　　Alice對Proxy返回確認(rèn)ACK消息（F6）：

　　然后，Alice對Proxy發(fā)送安全認(rèn)證消息（F7），攜帶自己的認(rèn)證信息：

　　Proxy經(jīng)過安全認(rèn)證檢查以后，發(fā)現(xiàn)Alice沒有權(quán)限直接呼叫Bob，呼叫篩選不能通過，因此對Alice返回一個失敗消息（F8），并且插入了一個Error-info，帶了一個URL地址。這個地址播放語音提示。

　　Alice收到403 響應(yīng)錯誤消息以后，對Proxy發(fā)送一個ACK確認(rèn)消息（F9）：

　　為了知道Proxy對Alice發(fā)送的是什么提示，Alice會繼續(xù)對這個Error-info的地址進行訪問，發(fā)送一個INVITE請求（F10）這時一個媒體播放的服務(wù)器地址，其服務(wù)器會對Alice播放剛才呼叫失敗的提示音：

　　然后，媒體播放服務(wù)器對Alice發(fā)送200 OK消息（F11），表示可以對Alice播放語音提示。

　　另外，在F11的200 OK中，媒體播放服務(wù)器對Alice增加了一個渲染功能標(biāo)簽，表示此服務(wù)器僅能支持自動媒體功能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

　　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的處理流程可能存在表述錯誤。讀者需要根據(jù)實際的場景來做出正確的判斷。按照流程圖的示意，F(xiàn)11應(yīng)該是從媒體服務(wù)器到Alice的返回消息：

　　但是，按照正常的處理規(guī)范來說，應(yīng)該是媒體服務(wù)器對Alice的返回消息（200 OK）。另外一個矛盾的地方是，在具體的流程中（F11），規(guī)范又描述為媒體到Proxy 1的處理流程：

　　以上討論是筆者僅根據(jù)官方規(guī)范做的疑點做出的自己的判斷，讀者可以通過其他渠道和規(guī)范發(fā)布者確認(rèn)最終結(jié)果。

　　現(xiàn)在我們回到合理的處理流程中。接下來，Alice收到200 OK以后，對媒體服務(wù)器發(fā)送ACK確認(rèn)消息，然后媒體播放服務(wù)器對Alice播放語音提示（F12）：

　　語音提示播放完成以后，媒體服務(wù)器對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ù)和上面的呼入呼叫篩選基本類似，但是處理流程更加簡單。簡單舉例，呼叫方Alice通過Proxy呼叫Bob，但是Bob在Alice的呼叫篩選名單中，Proxy對Alice要求安全認(rèn)證的驗證，Alice對Proxy發(fā)送安全認(rèn)證的消息，但是因為Bob在Alice的Call Screening的篩選名單中，不能對Bob進行呼叫，因此，最后，Proxy對返回403 呼叫篩選失敗，最后掛機。

　　現(xiàn)在，我們結(jié)合具體的SIP消息，配合每個呼叫流程做進一步的細(xì)節(jié)介紹。

　　首先，Alice對Proxy發(fā)送INVITE請求，要求對Bob進行呼叫（F1）：

　　Proxy要求Alice發(fā)送安全認(rèn)證消息進行驗證（F2），返回407響應(yīng)消息：

　　Alice獲悉以后，繼續(xù)對Proxy發(fā)送ACK確認(rèn)消息（F3）：

　　然后再次對Proxy發(fā)送INVITE消息，包含了安全認(rèn)證的信息（F4）：

　　Proxy經(jīng)過檢查，Alice沒有權(quán)限呼叫Bob，因此對Alice返回403 Screening Failure （Originating）的消息，表示不能對Bob進行呼叫（F5）。另外，在返回的消息中插入了一個Error-info 頭，包含了一個媒體播放的鏈接，用戶可以聽到失敗提示音。

　　Alice收到403以后，獲悉自己不能呼叫Bob，發(fā)送ACK給Proxy。此時，外呼篩選流程結(jié)束（F6）。

　　關(guān)于呼叫篩選的功能，很多IPPBX支持了多種配置方式和功能。比較常見的處理方式包括：不在呼叫權(quán)限組，呼叫前綴不對，用戶不接受其他部門呼叫，一定時間內(nèi)不接受其他無關(guān)聯(lián)用戶呼叫，或者其他IP地址的呼叫，出差期間不接受呼叫等篩選方式。

　　這里比較關(guān)鍵的是篩選失敗以后的處理，如何對呼叫失敗方進行一個比較友好的處理方式，比如，對呼叫失敗方播放語音提示，轉(zhuǎn)到語音留言，抓到其他的IVR流程，或者進行后期回呼處理。在Asterisk或者FreeSWITCH平臺中，這些處理策略都可以通過IPPBX的撥號規(guī)則加一定的腳本來實現(xiàn)篩選的路由控制。具體的實現(xiàn)方式用戶參考網(wǎng)上的學(xué)習(xí)資料。

　　15、Call Park

　　Call Park，我們稱之為呼叫駐留/停靠。簡單來說，呼叫駐留就是呼叫方呼叫被呼叫方時，電話被駐留在駐留服務(wù)器（一般是媒體服務(wù)器或者IPPBX）。經(jīng)過一段時間后，呼叫方電話被其他第三方用戶再次接聽。具體的實現(xiàn)過程是這樣的，假設(shè)Alice呼叫Bob，Bob和Alice開始通話，通話后，可能Alice想轉(zhuǎn)接第三方或者Bob可能有其他事情，暫時不能繼續(xù)和Alice通話，Bob通過終端按鍵對其通話進行電話駐留的設(shè)置。

　　所以，Alice的電話被駐留在駐留服務(wù)器或者IPPBX/媒體服務(wù)器。Alice電話被駐留以后，媒體服務(wù)器會對Bob發(fā)送訂閱消息，說明電話駐留狀態(tài)。然后，媒體服務(wù)器對Alice發(fā)送一個INVITE請求，通知Alice，媒體服務(wù)器現(xiàn)在替換了Bob來對其會話進行管理。Alice獲悉駐留狀態(tài)后，接受此處理流程，然后，媒體服務(wù)器或者IPPBX對其播放音樂媒體提示音。接下來，Alice對Bob發(fā)送BYE消息，媒體服務(wù)器對Bob發(fā)送Bob消息，表示現(xiàn)在媒體服務(wù)器已經(jīng)駐留了Alice的通話，Bob脫離和Alice之間的關(guān)系。第三方Carol想接聽這個被駐留在媒體服務(wù)器的呼叫，因此，首先需要對媒體服務(wù)器發(fā)送訂閱消息，媒體服務(wù)器接受訂閱以后，獲悉Carol想接聽這個被駐留的呼叫，接下來Carol對Alice發(fā)送INVITE請求，并且要求替換會話中的媒體服務(wù)器。Alice收到此請求后，同意和Carol進行通話，發(fā)送協(xié)商成功的響應(yīng)消息，然后雙方正式開始通話，駐留處理流程完成。

　　在電話駐留的流程中，幾個問題需要讀者注意。首先，這里的電話駐留被重新接聽的是第三方的用戶，當(dāng)然，接聽用戶也可能是發(fā)起駐留電話自己本身。但是，這樣的駐留方式也不符合大部分場景中的電話使用習(xí)慣。因為，大部分已經(jīng)開始的通話，或者進行電話轉(zhuǎn)接，或者一定時間后雙方掛機，或者掛機后，雙方稍晚時間后重新呼叫對方。因此，電話駐留其實也是電話轉(zhuǎn)接的一種特殊方式或特殊使用場景。其次，電話駐留的方式其實也是音樂等待的一種處理方式。只是，在電話駐留服務(wù)器或者媒體服務(wù)器中，駐留處理可以分割為多個駐留空間或者slot，電話駐留基本的處理流程或原理事實上和語音等待類似。最后，電話駐留服務(wù)器開啟駐留處理時也對駐留方發(fā)送了automaton,，rendering和 byeless tag標(biāo)簽，表示其服務(wù)器的支持能力。以下是電話駐留的處理流程：

　　現(xiàn)在，我們結(jié)合具體的SIP消息和每一個處理的具體細(xì)節(jié)來一步步介紹整個電話駐留的處理：

　　首先，Alice對Bob發(fā)送INVITE呼叫請求（F1）：

　　然后Bob對Alice響應(yīng)180 Ringing（F2）：

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

　　Alice收到200 OK以后，對Bob發(fā)送ACK確認(rèn)消息（F4），雙方開始通話。

　　通話后獲悉，Alice可能需要被駐留，然后第三方Carol來接聽。因此，Bob首先需要對Alice通話進行電話駐留處理，把Alice的呼叫�？吭隈v留服務(wù)器或者媒體服務(wù)器上，Bob對服務(wù)器發(fā)送REFER消息（F5），并且通知媒體服務(wù)器在會話中使用Bob替換Alice。這里的Refer-To是Alice，Refer-By是Bob自己。注意，這里不存在Bob和媒體服務(wù)器之間的直接的會話。

　　駐留服務(wù)器收到Bob的REFER以后，對Bob發(fā)送一個202 Accepted，表示接受此REFER消息（F6）：

　　然后，駐留服務(wù)器對Bob發(fā)送NOTIFY消息，創(chuàng)建一個對事件的訂閱，同時提示Bob正在處理電話駐留（F7），100 Trying：

　　Bob回復(fù)200表示收到訂閱事件（F8）：

　　接下來，駐留媒體服務(wù)器對Alice發(fā)送INVITE請求，同時替換Bob（F9），增加了渲染功能的標(biāo)簽，表示媒體服務(wù)器的處理能力（在Contact中插入了媒體服務(wù)器的渲染功能標(biāo)簽：

　　Contact:;automaton ;+sip.byeless;+sip.rendering="no"

　　注意：以下圖例中忽略了渲染功能標(biāo)簽

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

　　媒體服務(wù)器對Alice發(fā)送ACK確認(rèn)消息，開始媒體流處理（這里開始播放語音提示，F(xiàn)11）：

　　提示音播放開始以后，Alice對Bob發(fā)送BYE消息（F12），表示Alice已經(jīng)和媒體服務(wù)器創(chuàng)建了新的會話關(guān)系：

　　Bob獲悉Alice的電話被成功駐留以后，對Alice發(fā)送一個最終的200 OK（F13）：

　　這時，媒體服務(wù)器再次對Bob發(fā)送NOTIFY消息，并且攜帶了返回的200 OK消息，表示媒體服務(wù)器成功處理了Alice的駐留（F14）。

　　Bob對媒體服務(wù)器返回200 OK消息，并且確認(rèn)了dialog的ID（F15），到此為止，Alice已經(jīng)完全駐留在媒體服務(wù)器中。

　　接下來，如果Carol想接聽這個被駐留在服務(wù)器的Alice的電話時，Carol首先需要對媒體服務(wù)器發(fā)送訂閱消息，否則，Carol不知道Alice電話的事件。因此，Carol對服務(wù)器發(fā)送訂閱消息（F16）：

　　媒體服務(wù)器對Carol回復(fù)一個200 OK，獲悉媒體服務(wù)器的支持能力等渲染標(biāo)簽（F17）：

　　有了新的事件以后，媒體服務(wù)器對Carol發(fā)送NOTIFY消息，通知Carol的事件具體消息內(nèi)容（F18）：

　　Carol獲悉被駐留方的地址信息后，對媒體服務(wù)器發(fā)送200 OK（F19）：

　　Bob通過媒體服務(wù)器發(fā)送到NOTIFY已經(jīng)獲得被駐留電話的地址信息，然后，為了接聽Alice的駐留電話，Bob對Alice發(fā)送INVITE請求，并且要求替換媒體服務(wù)器的地址（Replaces，F(xiàn)20）。

　　Alice接受了Carol的請求，對Carol返回200 OK（F21）：

　　然后，Carol對Alice繼續(xù)發(fā)送一個ACK確認(rèn)消息（F22），創(chuàng)建RTP流，雙方開始正式通話，Carol接聽被駐留的電話。

　　然后，Alice必須對駐留服務(wù)器發(fā)送最后的通知消息（BYE，F(xiàn)23），表示Alice已經(jīng)開始和Carol通話，駐留服務(wù)器和Alice的駐留關(guān)系釋放。

　　駐留服務(wù)器最后對Alice返回200 OK（F24），表示確認(rèn)駐留關(guān)系釋放：

　　呼叫駐留到這一步，媒體服務(wù)器釋放了和Alice的駐留關(guān)系，Alice通知了Bob，Carol接聽了駐留電話。呼叫駐留的流程才真正完成。

　　企業(yè)IPPBX基本上都支持了呼叫駐留/�？康臉I(yè)務(wù)需求。IPPBX支持了多種駐留熱鍵功能，用戶可以通過熱鍵功能來駐留呼叫或者重新被激活駐留的呼叫。在開源平臺Asterisk（#72）或者FreeSWITCH（*5900）都有相應(yīng)的設(shè)置，用戶可以根據(jù)配置文件來實現(xiàn)電話駐留或重接被駐留的呼叫，另外，IPPBX用戶也可以對駐留的空間進行管理，根據(jù)配置的不同，駐留空間可以支持很多個slot。還有，電話駐留的語音提示音也可以實現(xiàn)自定義功能，這樣就可以方便地支持系統(tǒng)用戶的操作。最后，電話駐留時長也可以通過配置文件來進行調(diào)整。FreePBX支持了電話駐留的界面配置，也支持了多種配置選項，用戶可以參考其功能配置：

　　16、Call Pickup

　　Call Pickup, 我們稱之為組內(nèi)代答或者呼叫代答功能。一般情況下，如果是企業(yè)客戶用戶的話，每個部門的員工都有各自的分機。如果有人呼叫分機1，分機1如果沒有應(yīng)答的話，分機2看到分機1用戶分機沒有人應(yīng)答，分機2用戶可以通過熱鍵來替正在振鈴的分機1代接此呼叫。一般情況下，如果系統(tǒng)用戶想替其他分機代接的話，這些分機必須在一個工作組或者根據(jù)業(yè)務(wù)類型分配的部門，同一組內(nèi)用戶可以互相代接其他用戶的呼叫。

　　組內(nèi)代接的具體處理流程需要經(jīng)過大概以上幾個步驟。假設(shè)，Alice呼叫Bob，Bob沒有應(yīng)答此呼叫。和Bob同組的Bill想為Bob代接此呼叫。為了代接此呼叫，Bill首先需要對Bob發(fā)送訂閱消息，通過訂閱消息獲取到Dialog消息內(nèi)容。然后，根據(jù)獲取的dialog消息內(nèi)容，對Alice發(fā)送INVITE請求消息，替換Bob。Alice收到INVITE請求以后，然后對Bob分機發(fā)送一個CANCEL取消的消息，通知Bob分機停止振鈴。這里讀者要注意，對于F11和F12相關(guān)的順序和200 OK（F10）它們之間是不確定的。

　　在以上圖例中的F7流程中，Replaces頭中使用了一個新的參數(shù)“early-only”，這個參數(shù)可以防止接受一個Bob可能已經(jīng)接受的INVITE請求。如果Bill已經(jīng)準(zhǔn)備從Bob那里代接此呼叫，無論Bill是否應(yīng)答呼叫，參數(shù)“early-only”就將不會出現(xiàn)在F7的流程中。另外，讀者需要注意一下Bob和Bill之間的訂閱會話創(chuàng)建的時間問題。實際上，這個訂閱會話可能已經(jīng)存在于Alice呼叫Bob之前。這里的圖例是為了表達(dá)方便，而顯示在F3，Alice呼叫之后發(fā)生，實際上，Bob和Bill的訂閱可能已經(jīng)發(fā)生在Alice呼叫之前。

　　另外提醒讀者，根據(jù)RFC5359的描述，這里可能是拼寫錯誤，把Bill說成了Carol。以上流程圖中沒有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消息，配合每一個處理流程來一步步說明組內(nèi)代接：

　　首先，Alice對Bob發(fā)送INVITE請求，要求和Bob進行通話（F1）：

　　接下來，Bob對Alice發(fā)送180 Ringing，Bob分機振鈴（F2）。

　　這時，因為Bob分機振鈴，無人接聽電話，Bill打算為Bob代接呼叫，Bill對Bob發(fā)送訂閱消息來獲取呼叫的dialog身份確認(rèn)消息（F3）：

　　Bob收到Bill訂閱消息，然后回復(fù)200 OK（F4）：

　　緊接著，Bob對Bill發(fā)送NOTIFY消息，包括了訂閱消息的內(nèi)容和Alice的相關(guān)消息信息（F5）：

　　Bill回復(fù)Bob收到了訂閱的dialog消息內(nèi)容（F6），準(zhǔn)備對Alice發(fā)送INVITE請求。

　　Bill對Alice發(fā)送INVITE請求，替換Bob，使用了early-only（F7）：

　　Replaces: 12345600@atlanta.example.com

　　;from-tag=314578;to-tag=1234567;early-only

　　Alice收到Bill的INVITE請求，檢查匹配Replaces頭中的dialog，確認(rèn)以后，接受了這個來自于Bill的INVITE，然后對Bill發(fā)送200 OK（F8）：

　　Alice接受了Bill的INVITE以后，Alice還要對正在振鈴的Bob的分機發(fā)送一個CANCEL取消的回復(fù)，通知Bob分機停止振鈴（F9）：

　　Bob收到CANCEL以后，停止振鈴，然后對Alice回復(fù)200 OK（F10）：

　　然后Bob最后對Alice發(fā)送487 響應(yīng)消息，表示對Bob的請求正式結(jié)束（F11）：

　　Alice對Bob發(fā)送最后確認(rèn)消息ACK（F12），他們兩個人之間的會話關(guān)系正式結(jié)束。

　　Bill回復(fù)Alice發(fā)送的200 OK（F8）的ACK確認(rèn)消息（F13），雙方開始RTP語音流的傳輸，組內(nèi)代接成功。

　　經(jīng)過一段時間通話后，Alice先掛機，對Bill發(fā)送BYE消息（F14）：

　　然后，Bill對Alice發(fā)送最后的200 OK（F15），雙方通話結(jié)束。

　　大部分的企業(yè)IPPBX都支持了組內(nèi)代接功能。顧名思義，如果需要實現(xiàn)組內(nèi)代接功能的話，用戶首先需要創(chuàng)建一個呼叫組，組內(nèi)成員則可以通過IPPBX的系統(tǒng)熱鍵來代接電話。在asterisk或FreePBX平臺上，用戶可以按熱鍵*8來實現(xiàn)代接功能。當(dāng)然，其他平臺也可以通過熱鍵設(shè)置來接聽代接電話。另外，用戶可以通過比較靈活和人性化的設(shè)計可以支持代接成功或者失敗的的語音提示，這樣可以讓用戶獲得更好的用戶體驗。

　　17、Automatic Redial

　　Automatic Redial，我們稱之為自動呼叫重?fù)芄δ�。簡單來說，如果呼叫方呼叫被呼叫方時，對端如果處于忙狀態(tài)或者其他狀態(tài)，在一定時間后，呼叫方再次呼叫被呼叫方。具體的實現(xiàn)過程相對比較簡單（查看以下圖例）。

　　假設(shè)，Alice呼叫Bob，這時Bob處于忙狀態(tài)可能正在接聽其他電話呼叫，Bob正在通話中。Alice呼叫后，對Bob發(fā)送一個訂閱消息，對Bob分機狀態(tài)進行訂閱。當(dāng)Bob處于空閑狀態(tài)后，Bob對Alice發(fā)送一個提醒消息，通知Alice現(xiàn)在Bob分機處于空閑狀態(tài)，可以對Bob分機進行呼叫。Alice收到這個提醒消息以后，結(jié)束對Bob的狀態(tài)訂閱，然后，Alice對Bob發(fā)送一個INVITE請求，對Bob進行呼叫，雙方互相通話。

　　下面，我們根據(jù)SIP消息內(nèi)容，結(jié)合每一個具體的處理流程來進一步分析如何實現(xiàn)呼叫重?fù)芄δ堋?/div>

　　首先，Alice呼叫Bob，對Bob發(fā)送INVITE請求（F1）：

　　因為Bob此時正處于忙狀態(tài)，所以，Bob回復(fù)Alice 一個486 響應(yīng)消息（F2）：

　　Alice回復(fù)一個ACK確認(rèn)消息（F3）：

　　為了獲悉Bob分機的狀態(tài)，Alice對Bob發(fā)送了一個訂閱（F4），獲取dialog消息內(nèi)容：

　　Bob回復(fù)Alice的訂閱，回復(fù)200 OK（F5）：

　　Bob對Alice發(fā)送NOTIFY消息（F6）：

　　Alice回復(fù)200 OK（F7）：

　　Bob分機處于空閑狀態(tài)，再次對Alice發(fā)送NOTIFY消息，提醒Alice現(xiàn)在Bob是處于空閑狀態(tài)（F8）。

　　Bob收到來自于Alice的提醒消息，Bob現(xiàn)在處于空閑狀態(tài)，回復(fù)200 OK（F9）：

　　然后，Alice馬上對Bob發(fā)送INVITE消息，進行呼叫請求（F10）：

　　因為Bob已經(jīng)是空閑狀態(tài)，所以接聽了來自Alice的呼叫。對Alice返回180 振鈴消息（F11）：

　　Alice然后返回200 OK（F12）：

　　緊接著，Alice對Bob發(fā)送一個ACK確認(rèn)消息（F13），重?fù)芎艚薪油�。雙方開始語音流傳輸（F13）。

　　Bob再次對Alice發(fā)送NOTIFY消息（F14）：

　　Alice返回200 OK（F15）：

　　經(jīng)過以上互相發(fā)送NOTIFY和確認(rèn)消息，Alice已獲悉對方狀態(tài)，不再對Bob進行狀態(tài)訂閱，結(jié)束訂閱，所以Alice對Bob再次發(fā)送訂閱通知，結(jié)束對Bob的訂閱（F16），重置Expire：0。

　　Bob回復(fù)Alice 200 OK（F17）:

　　Bob對Alice發(fā)送NOTIFY消息（F18），訂閱結(jié)束。

　　最后，Alice對Bob返回200 OK響應(yīng)消息（F19），訂閱結(jié)束確認(rèn)。

　　在以上的訂閱消息結(jié)束處理中，根據(jù)RFC6665的規(guī)范（4.1.2.3），取消訂閱可以通過重設(shè)Expire頭，設(shè)置expire:0 來通知取消訂閱。根據(jù)規(guī)范的說明，成功取消訂閱會再次觸發(fā)一個最終NOTIFY消息（F18）。因此，讀者不用對此產(chǎn)生誤解。另外，我們這里沒有涉及更多訂閱的定時器刷新等問題，更多關(guān)于訂閱的處理，讀者可以查閱rfc6665來做進一步的學(xué)習(xí)。

　　關(guān)于訂閱功能使用方面，筆者建議讀者在部署IPPBX和使用SIP終端時要慎用此功能。因為，一旦開啟了訂閱信息，IPPBX分機之間的訂閱消息會生成大量的無效的數(shù)據(jù)，這樣可能影響IPPBX本身的性能和企業(yè)內(nèi)網(wǎng)的網(wǎng)絡(luò)的穩(wěn)定性，還有用戶消息傳送的時延，這樣可能導(dǎo)致其他處理流程的錯誤。比如，如果Bob的終端對Alice發(fā)送了NOTIFY消息，通知Alice現(xiàn)在Bob處于空閑狀態(tài)，Alice可以對其進行呼叫，但是，可能當(dāng)前的Alice也正在處于其他的狀態(tài)，可能沒有可能再次及時對Bob發(fā)起呼叫，因此這個流程就會出現(xiàn)其他的問題。

　　一些技術(shù)論文對消息導(dǎo)致的系統(tǒng)性能問題和網(wǎng)絡(luò)優(yōu)化做了討論。Ahmadreza Montazerolghaem發(fā)表的論文關(guān)于重傳機制優(yōu)化的論文可能對讀者有所幫助，大家可以參考這個方法來進一步優(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ā)表的論文中對SIP即時消息互發(fā)對網(wǎng)絡(luò)影響數(shù)據(jù)流量的影響可以給我們提供一些參考建議，用戶可以查閱研究。

　　另外，Maria Isabel Pous在論文-SIP-based Applications in UMTS: A Performance Analysis也對SIP消息產(chǎn)生的影響做了深入的分析，讀者可以查閱其論文作為參考資料。

　　18、Click to Dial

　　Click to Dial，我們稱之為點擊呼叫或頁面點擊呼叫。瀏覽器用戶以插件的形式或者頁面的形式通過瀏覽器訪問點擊界面。用戶通過點擊頁面的一個SIP URL鏈接，頁面點擊呼叫消息傳遞給電腦SIP終端，終端配置了呼叫方的SIP URL地址，通過REFER發(fā)送SIP終端，然后SIP終端和被呼叫方創(chuàng)建一個會話連接，實現(xiàn)雙方呼叫。

　　這里的呼叫場景適合于簡單的點對點的SIP呼叫場景。如果用戶通過媒體服務(wù)器實現(xiàn)呼叫的話，處理流程和我們現(xiàn)在討論的有所不同。具體的呼叫流程如下：

　　現(xiàn)在，我們配合具體的SIP消息內(nèi)容和每一個流程來簡單說明點擊呼叫的處理過程。

　　首先，Bob的PC端SIP對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）：

　　接下來，Bob對Carol發(fā)送INVITE請求消息，表示需要對Carol進行呼叫（F3）：

　　接下來，Carol對Bob SIP 電話回復(fù)180 振鈴（F4）：

　　然后，Alice對Bob SIP電話回復(fù)200 OK（F5）：

　　接下來，Bob的SIP 電話回復(fù)ACK確認(rèn)消息（F6），然后實現(xiàn)雙方語音流傳輸。

　　到此為止，整個點擊呼叫的流程結(jié)束，雙方開始電話互通。

　　事實上，現(xiàn)在點擊呼叫業(yè)務(wù)功能可以通過很多種方式實現(xiàn)，可以通過瀏覽器插件的形式實現(xiàn)，也可以通過HTML加腳本語言的形式實現(xiàn)，WebRTC或者郵件終端插件工具來實現(xiàn)。

　　特別是基于開源軟交換的平臺，例如Asterisk/FreePBX或者FreeSWITCH都可以通過接口語言來開發(fā)更加靈活的點擊呼叫功能。例如，通過腳本語言加Asterisk AMI接口實現(xiàn)的頁面點擊呼叫功能。用戶可以下載以下代碼來實現(xiàn)點擊呼叫功能。以下是一個PHP的頁面點擊呼叫實例地址，讀者可以參考：

　　https://github.com/spbx/Simple-Click2Call-for-Asterisk-PBX/blob/master/click2dial.php

　　基于Asterisk的點擊呼叫的插件，用戶可以參考TBDialOut來實現(xiàn)，開源項目地址：

　　http://www.oak-wood.co.uk/tbdialout/

　　19、總結(jié)討論

　　筆者根據(jù)RFC5359，結(jié)合一些具體的圖例非常系統(tǒng)地討論了最常用的18個SIP呼叫流程的具體細(xì)節(jié)。在每一個細(xì)節(jié)中，筆者增加了一些相關(guān)的討論，幫助讀者能夠更加全面地了解部署使用時的問題和風(fēng)險。筆者再次強調(diào)，這18個SIP呼叫業(yè)務(wù)是一個規(guī)范流程，不一定是強制執(zhí)行的標(biāo)準(zhǔn)，特別是涉及到Proxy的內(nèi)容，讀者一定要注意。不同的Proxy或者媒體服務(wù)器可能對流程的處理有所不同，讀者需要根據(jù)自己的部署平臺來對照檢查。整體而言，通過這18個完整的SIP呼叫業(yè)務(wù)細(xì)節(jié)討論，筆者為提供SIP呼叫業(yè)務(wù)的技術(shù)人員提供了相對比較完整的學(xué)習(xí)資料和比較權(quán)威的參考，希望對大家有所幫助。

　　另外，因為筆者水平和資源有限，肯定有很多錯誤之處，敬請諒解。

　　參考資料：

　　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