欧美,精品,综合,亚洲,好吊妞视频免新费观看,免费观看三级吃奶,一级a片女人自慰免费看

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

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

2019-01-30 14:37:32   作者:   來源:CTI論壇   評論:0  點擊:


  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進(jìn)行掛機處理。因此,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消息來進(jìn)一步說明如何實現(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)。從字面意思,讀者也可以看明白,被呼叫方會把呼叫進(jì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)進(jì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進(jìn)行呼叫,這個INVITE消息會經(jīng)過Proxy,Proxy則會重寫請求的URL地址,然后前轉(zhuǎn)這個INVITE到Gateway地址。以上兩步是前轉(zhuǎn)最重要的部分,所以,我們僅針對這個部分進(jì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)消息進(jìn)行分析介紹。首先,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請求進(jìn)行確認(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消息示例來進(jìn)一步說明整個遇忙呼叫前轉(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需要進(jìn)行電話前轉(zhuǎn)。所以,Proxy需要對Alice發(fā)送一個180 call is Being Forwarded的消息,通知Alice,你的呼叫正在被前轉(zhuǎn)。同時,Proxy再次發(fā)起一個INVITE請求,這次,對用戶2發(fā)出INVITE請求進(jìn)行呼叫前轉(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)。
  最后,雙方進(jìn)行掛機的最終確認(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通過定時器檢測超時,進(jìn)行對第三方用戶2前轉(zhuǎn)處理。其余的處理流程基本和遇忙前轉(zhuǎn)的處理流程一致。簡單來說,Alice通過Proxy呼叫用戶1,用戶1在一定時間內(nèi)沒有應(yīng)答此呼叫,然后Proxy把這個呼叫轉(zhuǎn)接到用戶2,對用戶2進(jìn)行呼叫處理。在請求超時后(F6),Proxy對用戶1發(fā)送取消請求,然后通知Alice,同時對用戶2再次進(jìn)行INVITE請求處理,進(jìn)行呼叫請求。具體的呼叫流程如下:
  接下來,筆者配合具體的SIP消息來進(jìn)一步說明無應(yīng)答呼叫前轉(zhuǎn)的處理方式。
  首先,Alice通過Proxy對用戶1發(fā)出INVITE請求,對用戶1進(jìn)行呼叫(F1),然后Proxy對用戶1發(fā)送INVITE請求,對用戶2進(jìn)行呼叫請求處理。
  接下來,Proxy馬上對Alice發(fā)送一個100 Trying(F3忽略),表示正在對用戶1進(jìn)行呼叫,通知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)整呼叫流程,再次進(jìn)行呼叫轉(zhuǎn)接到處理。首先,Proxy先對Alice發(fā)送一個電話轉(zhuǎn)接到響應(yīng)消息(181 電話前轉(zhuǎn)),通知Alice,你的呼叫正在被前轉(zhuǎn)到其他用戶終端(F10)。緊接著Proxy對用戶2發(fā)送一個INVITE請求,對其進(jìn)行呼叫(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ù)對此流程進(jìn)行進(jìn)一步的處理,以便開始雙方的通話或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,然后雙方進(jìn)行通話。這時,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é)合具體的流程來說明第三方會議邀請是如何進(jìn)行的。
  首先,Alice對Bob發(fā)送INVITE請求,對其進(jìn)行呼叫(F1):
  Bob對Alice回復(fù)180 Ringing(F2):
  11、3-Way Conference - Third Party Joins
  3-Way Conference - Third Party Joins,我們稱之為三方會議加入。和上面的三方會議邀請不同的是,這里的第三方是自己主動希望加入到電話會議中,而不是由其他人邀請加入。因此,在處理三方會議時,其處理流程和前面的被邀請的方式完全不同。
  通過以上的處理流程我們來詳細(xì)解釋會議加入的方式是如何處理的。這里,我們假設(shè)Alice和Bob兩個人正在進(jìn)行雙方的語音通話。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消息配合具體的處理流程來進(jìn)一步對電話加入的方式做出詳細(xì)介紹。
  首先,Alice對Bob發(fā)送INVITE請求,進(jìn)行電話呼叫(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之間正在進(jìn)行電話呼叫,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”模式來支持電話會議,需要進(jìn)行媒體混音處理。
  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)備好進(jìn)行電話會議。接下來,Bob才對Carol發(fā)送200 OK,接受了其要求加入電話會議的INVITE請求,這里包括了新的Contact的會議地址。
  接下來,Carol知道Bob已經(jīng)允許自己可以加入到會議中,對Bob發(fā)送最后ACK確認(rèn)消息,表示正式加入會議中。此時,Carol加入到了會議室,三方會議正式開啟(F11),RTP流開始工作。這里的Bob構(gòu)成了一個媒體混音單元,也可能是一個會議媒體服務(wù)器功能,進(jìn)行三方混音。
  這里,筆者再進(jìn)一步介紹一下會議的標(biāo)簽isfocus tag。會議模式中的isfocus參數(shù)可以支持多種使用方式,通過SIP,它可以支持以下幾種方式:
  • 創(chuàng)建會議
  • 加入會議
  • 邀請用戶加入會議
  • 踢出會議用戶
  • 支持對會議URL判斷,可以檢查到是否是會議URL
  • 刪除會議
  會議創(chuàng)建的方式Ad-Hoc方式臨時自組的方式來創(chuàng)建一個會議,也可以通過REFER方式來創(chuàng)建一個會議室。會議邀請的方式可以通過INVITE請求,用戶可以主動呼入或者用戶被呼方式來進(jìn)入到會議室,也可以通過REFER的方式邀請用戶進(jìn)入到會議室。關(guān)于會議的管理和使用部署,RFC4579中有著非常詳細(xì)的說明,同時此規(guī)范也介紹了其他的協(xié)商流程。讀者可以閱讀此規(guī)范進(jìn)一步了解多方會議的處理流程。
  在開源媒體服務(wù)器中,Asterisk/FreePBX/FreeSWITCH也支持了強大的會議功能。用戶可以創(chuàng)建會議室,系統(tǒng)通過自動撥號的形式邀請會議用戶來加入到會議中,用戶也可以通過語音IVR的形式進(jìn)入到會議室中。會議主席也可以對會議人員實現(xiàn)靜音或者踢出等功能。如果使用Asterisk的界面管理系統(tǒng)FreePBX,用戶也可以通過界面來創(chuàng)建會議室,支持多種會議的管理功能,例如會議密碼設(shè)置,最大會議用戶人數(shù)設(shè)置,進(jìn)入會議室播放提示,音樂等待等功能。
  12、Find-Me
  Find-Me, 我們稱之為有效用戶查詢呼叫。簡單來說,Alice通過Proxy呼叫Bob,Bob可能有幾個Contact地址。Proxy會根據(jù)不同的Contact列表來逐一查詢這些地址的狀態(tài),如果有可接通的地址,則對其進(jìn)行呼叫;如果沒有,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消息和具體的流程進(jìn)行分析。
  首先,Alice通過Proxy對Bob進(jìn)行呼叫,發(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,然后再進(jìn)行下一個有效用戶的地址查詢。
  通話一段時間后,用戶4對Alice掛機,對Proxy首先發(fā)送BYE消息(F23), Proxy對Alice進(jìn)行掛機處理,對其發(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é)合每一個處理流程來進(jìn)一步說明呼叫篩選的處理過程。
  首先,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的地址進(jìn)行訪問,發(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
  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的處理流程可能存在表述錯誤。讀者需要根據(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進(jìn)行呼叫,因此,最后,Proxy對返回403 呼叫篩選失敗,最后掛機。
  現(xiàn)在,我們結(jié)合具體的SIP消息,配合每個呼叫流程做進(jìn)一步的細(xì)節(jié)介紹。
  首先,Alice對Proxy發(fā)送INVITE請求,要求對Bob進(jìn)行呼叫(F1):
  Proxy要求Alice發(fā)送安全認(rèn)證消息進(jì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進(jìn)行呼叫(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)鍵的是篩選失敗以后的處理,如何對呼叫失敗方進(jìn)行一個比較友好的處理方式,比如,對呼叫失敗方播放語音提示,轉(zhuǎn)到語音留言,抓到其他的IVR流程,或者進(jìn)行后期回呼處理。在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通過終端按鍵對其通話進(jìn)行電話駐留的設(shè)置。
  所以,Alice的電話被駐留在駐留服務(wù)器或者IPPBX/媒體服務(wù)器。Alice電話被駐留以后,媒體服務(wù)器會對Bob發(fā)送訂閱消息,說明電話駐留狀態(tài)。然后,媒體服務(wù)器對Alice發(fā)送一個INVITE請求,通知Alice,媒體服務(wù)器現(xiàn)在替換了Bob來對其會話進(jìn)行管理。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進(jìn)行通話,發(fā)送協(xié)商成功的響應(yīng)消息,然后雙方正式開始通話,駐留處理流程完成。
  在電話駐留的流程中,幾個問題需要讀者注意。首先,這里的電話駐留被重新接聽的是第三方的用戶,當(dāng)然,接聽用戶也可能是發(fā)起駐留電話自己本身。但是,這樣的駐留方式也不符合大部分場景中的電話使用習(xí)慣。因為,大部分已經(jīng)開始的通話,或者進(jìn)行電話轉(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通話進(jìn)行電話駐留處理,把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ìn)行管理,根據(jù)配置的不同,駐留空間可以支持很多個slot。還有,電話駐留的語音提示音也可以實現(xiàn)自定義功能,這樣就可以方便地支持系統(tǒng)用戶的操作。最后,電話駐留時長也可以通過配置文件來進(jìn)行調(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進(jìn)行通話(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)進(jìn)行訂閱。當(dāng)Bob處于空閑狀態(tài)后,Bob對Alice發(fā)送一個提醒消息,通知Alice現(xiàn)在Bob分機處于空閑狀態(tài),可以對Bob分機進(jìn)行呼叫。Alice收到這個提醒消息以后,結(jié)束對Bob的狀態(tài)訂閱,然后,Alice對Bob發(fā)送一個INVITE請求,對Bob進(jìn)行呼叫,雙方互相通話。
  下面,我們根據(jù)SIP消息內(nèi)容,結(jié)合每一個具體的處理流程來進(jìn)一步分析如何實現(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消息,進(jìn)行呼叫請求(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進(jìn)行狀態(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來做進(jìn)一步的學(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可以對其進(jìn)行呼叫,但是,可能當(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)化的論文可能對讀者有所幫助,大家可以參考這個方法來進(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ā)表的論文中對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進(jìn)行呼叫(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
  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)注微信公眾號:asterisk-cn,獲得有價值的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中國合作伙伴,官方qq技術(shù)分享群(3000千人):589995817

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

專題

CTI論壇會員企業(yè)