<address id="lbt7n"></address>
      <delect id="lbt7n"><mark id="lbt7n"></mark></delect>
      <form id="lbt7n"></form>

          <big id="lbt7n"><cite id="lbt7n"><cite id="lbt7n"></cite></cite></big>
          <cite id="lbt7n"></cite>

          <p id="lbt7n"></p>
          您當前的位置是:  首頁(yè) > 新聞 > 文章精選 >
           首頁(yè) > 新聞 > 文章精選 >

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

          2019-01-29 15:42:30   作者:james.zhu   來(lái)源:CTI論壇   評論:0  點(diǎn)擊:


            在大部分的企業(yè)客戶(hù)的電話(huà)呼叫業(yè)務(wù)中,特別是從運營(yíng)商到企業(yè)IPPBX端的呼入業(yè)務(wù)中,有很多不同的呼叫涉及了多種SIP流程的操作,而且其流程和實(shí)際的IPPBX,代理和SIP終端存在著(zhù)非常密切的關(guān)系。排查這些技術(shù)問(wèn)題耗費相當多的時(shí)間。另外,因為越來(lái)越多的用戶(hù)開(kāi)始使用基于開(kāi)源的軟交換平臺和媒體服務(wù)器(例如,Asterisk或FreeSWITCH,Kamailio等),用戶(hù)更容易獲得技術(shù)產(chǎn)品,因此,他們更容易接觸到企業(yè)通信平臺技術(shù),導致其入門(mén)門(mén)檻也相對比較低,技術(shù)人員可能完全不了解系統底層的流程。而且不幸的是,在實(shí)際使用過(guò)程中,很多技術(shù)人員也僅僅停留在通過(guò)系統界面配置一個(gè)呼叫業(yè)務(wù)流程,他們根本沒(méi)有了解和關(guān)注真正底層的呼叫流程和其細節,而且他們對真正的SIP消息之間的互相通信過(guò)程可能并不是非常熟悉。筆者發(fā)現,其中一個(gè)原因是他們沒(méi)有太多學(xué)習渠道獲得一些非常直觀(guān)和權威的可參考的示例。
            大家經(jīng)常談?wù)揝IP呼叫業(yè)務(wù),但是,究竟哪些SIP呼叫業(yè)務(wù)是企業(yè)用戶(hù)所要求的? 關(guān)于SIP業(yè)務(wù)呼叫,RFC5359對18個(gè)最常用的SIP業(yè)務(wù)呼叫流程給出了完整的SIP流程圖例,這些呼叫業(yè)務(wù)為企業(yè)用戶(hù)解決方案部署提供了一個(gè)比較權威的參考。因此,筆者希望通過(guò)此文章完整列出所有18個(gè)關(guān)于SIP呼叫業(yè)務(wù)的SIP流程和其相應的圖例說(shuō)明,并且加以適當討論和說(shuō)明來(lái)解釋這些呼叫功能中可能出現的問(wèn)題或部署時(shí)應該注意到地方,以便幫助技術(shù)人員或者銷(xiāo)售工程師能夠對其產(chǎn)品或者周邊應用終端有一個(gè)完整的比較深入的理解。提醒大家,筆者的解釋和圖例介紹僅針對標準的SIP流程來(lái)加以說(shuō)明,完全以RFC5359為基礎,不會(huì )涉及其他的設備,可能有時(shí)結合開(kāi)源媒體服務(wù)器,軟交換的功能加以說(shuō)明是為了方便用戶(hù)理解和實(shí)踐。
            在關(guān)于SIP呼叫服務(wù)的規范協(xié)議RFC5359中,對其18個(gè)SIP呼叫流程做了完整的流程示例演示。當然,RFC5359定義的這18個(gè)示例不是一個(gè)規范標準,這18個(gè)SIP呼叫業(yè)務(wù)僅表示根據RFC5359作者建議的最常用的18個(gè)呼叫業(yè)務(wù),不是一個(gè)強制執行的要求。這18個(gè)最常用的SIP呼叫業(yè)務(wù)功能包括:
          1. Call Hold
          2. Consultation Hold
          3. Music on Hold
          4. Transfer - Unattended
          5. Transfer - Attended
          6. Transfer - Instant Messaging
          7. Call Forwarding Unconditional
          8. Call Forwarding - Busy
          9. Call Forwarding - No Answer
          10. 3-Way Conference - Third Party Is Added
          11. 3-Way Conference - Third Party Joins
          12. Find-Me
          13. Call Management (Incoming Call Screening)
          14. Call Management (Outgoing Call Screening)
          15. Call Park
          16. Call Pickup
          17. Automatic Redial
          18. Click to Dial
            下面,我們對這18個(gè)最常用的SIP呼叫業(yè)務(wù)分別加以解釋。另外,在所有的示例中,有幾個(gè)專(zhuān)有說(shuō)明需要提前解釋?zhuān)?/div>
            圖例中所列舉的假設用戶(hù)是Alice,Bob,Carol
            100 Trying沒(méi)有顯示
            Via和Max-Forwards頭沒(méi)有顯示
            From,To,Call-ID,Cseq,Contact,Route和 Record-Route和其他的頭依賴(lài)于實(shí)際案例
            圖例中使用假設域名來(lái)說(shuō)明用戶(hù)域名,例如,atlanta.ex.com, biloxi.ex.com和chicago.ex.com
            Tag和Call-ID替換為響應的用戶(hù)關(guān)聯(lián)的設置方式
            RFC5359中可能存在的描述錯誤,請用戶(hù)和官方核實(shí)
            SIP呼叫業(yè)務(wù)的中文名稱(chēng)是筆者自己翻譯,非任何官方翻譯定義。因此,中文名稱(chēng)的準確性有待用戶(hù)自己確認
            1、Call Hold
            Call Hold,此呼叫業(yè)務(wù)稱(chēng)之為呼叫保持。呼叫保持的流程實(shí)現需要經(jīng)過(guò)幾個(gè)步驟來(lái)完成。以下是RFC5359中的呼叫流程圖例(25個(gè)flow):
            這里假設,Alice呼叫Bob,呼叫接聽(tīng)后,Bob通過(guò)終端電話(huà)按鍵Hold鍵把呼叫設置為保持狀態(tài)。然后Bob解除呼叫保持狀態(tài),Alice掛機。注意,呼叫保持事實(shí)上是一個(gè)單向的功能。但是,執行保持的一方可以對第三方停止媒體發(fā)送,這樣可能導致雙方無(wú)媒體流交互。舊的處理方式是連接到地址0.0.0.0,F在新的處理方式是在SDP的a=中實(shí)現,a=inactive 表示無(wú)媒體發(fā)送;a=sendonly 表示仍有媒體發(fā)送。
            注意,在F10和F11中使用了渲染功能tag(rfc4235)來(lái)表示Bob終端不再渲染,例如Bob已經(jīng)設置為保持狀態(tài)。下面,我們通過(guò)完整的流程圖附帶SIP消息的說(shuō)明來(lái)具體介紹呼叫保持的流程。
            Alice對P1發(fā)出INVITE請求,然后通過(guò)P1呼叫Bob。
            Bob呼叫振鈴,Alice振鈴(F4,F5):
            Alice收到 200 OK(F6/F7)消息:
            Alice發(fā)送到ACK確認信息到P1(F8),然后P1發(fā)送到Bob(F9)的 流程。
            Bob對P1發(fā)出INVITE消息執行F10,然后,P1對Alice發(fā)出INVITE消息執行F11。這里,開(kāi)始雙方正式進(jìn)入呼叫保持狀態(tài)。讀者要注意, 結合我們開(kāi)始時(shí)說(shuō)明的,Bob使用了渲染 tag,并且o= 的version是增加的。前面在F6,F7時(shí)仍然是2890844527,這里已經(jīng)增加到了2890844528。因為是一個(gè)RE-INVITE攜帶了a=sendonly。
            Alice接受了呼叫保持請求,并且回復200 OK(F12, F13),在SDP中攜帶了a=reconly。
            Bob回復ACK消息(F14/Bob->P1,F15/P1->Alice)。
            Bob關(guān)閉呼叫保持狀態(tài),用戶(hù)通過(guò)按鍵Hold再次關(guān)閉保持功能。RE-INVITE中的SDP沒(méi)有包括a=sendonly。執行F16(Bob到P1),F17(P1到Alice)流程。
            Alice回復200 OK,發(fā)送的消息中沒(méi)有帶SDP的a=reconly。執行F18(Alice->P1),F19流程(P1->Bob)。
            Bob回復ACK,執行F20(Bob到P1),F21(P1到Alice)流程。他們之間重新創(chuàng )建RTP媒體流。
            Alice發(fā)送BYE消息到P1,P1發(fā)送BYE消息到Bob,執行流程F22和F23。
            然后各自發(fā)送最后的200 OK,執行流程F24(Bob到P1),F25(P1到Alice)。
            到此為止,整個(gè)呼叫保持流程結束。
            2、Consultation Hold
            Consultation Hold,我們稱(chēng)之為持入呼叫保持或者駐留呼叫保持。呼叫方A呼叫被呼叫方B以后,被呼叫方B將通話(huà)設置為呼叫保持狀態(tài)(通過(guò)終端的Hold鍵),然后被呼叫方B再呼叫其他第三方呼叫方C。B掛機以后,重新對被設置為呼叫保持的呼叫方A進(jìn)行操作,呼叫方A關(guān)閉呼叫保持,然后呼叫方A掛機。其流程經(jīng)過(guò)38個(gè)呼叫流程的處理。


            這里,讀者一定要注意,駐留呼叫保持和電話(huà)轉接的區別。電話(huà)轉接(transfer)從概念上我們就可以識別清楚,在呼叫流程中涉及了轉接方或者中間方。而駐留呼叫保持中的中間方完全沒(méi)有介入其他兩個(gè)被呼叫方,他們都是各自獨立的呼叫。例如,在以上的圖例中,Alice呼叫Bob,Bob呼叫Carol。Carol和Alice沒(méi)有任何直接呼叫關(guān)系。下面,我們通過(guò)完整的流程討論分別說(shuō)明這38個(gè)呼叫流程的處理方式。
            駐留呼叫保持同樣在F10的流程中使用了渲染tag來(lái)表示開(kāi)啟駐留呼叫保持狀態(tài)。事實(shí)上,從呼叫業(yè)務(wù)流程的控制來(lái)說(shuō),駐留呼叫保持相對于呼叫保持,處理流程更加簡(jiǎn)單。Alice到P1的F1,P1到Bob的F2呼叫流程,發(fā)起INVITE消息。
            雙方終端振鈴,經(jīng)過(guò)F4,F5處理流程。這里忽略了F3(Proxy到Alice的100 trying)。
            Bob對Proxy執行的F6,Proxy執行Proxy到Alice的F7呼叫流程。Bob對Proxy發(fā)送200 OK,Proxy對Alice發(fā)送200 OK。
            Alice到P的ACK消息,和P1到Bob的ACK消息,執行流程F8,F9。
            開(kāi)啟RTP媒體流,然后Bob發(fā)送INVITE到P1,P1發(fā)送INVITE到Alice,執行F10,F11流程,并且表示開(kāi)啟呼叫保持狀態(tài),使用了渲染功能表示保持狀態(tài)啟用。
            Alice對Proxy發(fā)送 200 OK(F12),帶SDPa=reconly, 接受保持狀態(tài)。Proxy發(fā)送200 OK到Bob,執行F13流程。
            Bob對Proxy發(fā)送最終ACK確認,執行F14;Proxy對Alice發(fā)送ACK確認消息,執行F15流程。至此,呼叫保持狀態(tài)開(kāi)啟(Bob/Alice之間)。
            Bob呼叫Carol。Bob對Proxy發(fā)起INVITE消息(F16),Proxy對Carol發(fā)送INVITE消息(F17)。
            這里,忽略了F18(100 trying)。Carol 對Proxy發(fā)送 180 振鈴(F19),Proxy對Bob發(fā)送180振鈴(F20)。
            執行對INVITE確認流程。Carol對Proxy發(fā)送200 ok(F21),Proxy對Bob發(fā)送 200 ok(F22)。
            雙方最后發(fā)送ACK確認信息。Bob發(fā)送ACK消息到Proxy(F23),Proxy發(fā)送ACK到Carol消息(F24)。雙方開(kāi)始媒體流互通。
            經(jīng)過(guò)雙方電話(huà)互通以后,Bob首先掛機,對Proxy發(fā)送BYE消息(F25),然后Proxy對Carol發(fā)送BYE消息掛機(F26)。
            對此次呼叫進(jìn)行最終確認掛機。Carol對Proxy發(fā)送200 OK(F27),Proxy對Bob發(fā)送200 OK(F28)。到此為止,Bob和Carol的呼叫正式結束。
            現在開(kāi)始重新開(kāi)啟對Alice的呼叫保持狀態(tài)。重新發(fā)送INVITE消息。Bob對Proxy發(fā)送INVITE消息(F29),Proxy對Alice發(fā)送INVITE消息(F30)。
            接下來(lái)對INVITE進(jìn)行確認。Alice對Proxy發(fā)送200 OK,接受INVITE。Proxy對Bob發(fā)送200 OK。
            Bob收到200 OK以后,對此次INVITE發(fā)送最終確認的ACK消息。Bob對Proxy發(fā)送ACK(F33),然后Proxy對Alice發(fā)送ACK(F34)。確認完成后,雙方開(kāi)始媒體流互通。
            雙方完成呼叫以后,Alice發(fā)送對proxyBYE消息(F35),Proxy對Bob發(fā)送BYE消息(F36)。
            最后,確認雙方的BYE消息,互相發(fā)送最后的200 OK。Bob對Proxy發(fā)送200 OK(F37),Proxy對Alice發(fā)送200 OK(F38)。到此為止,整個(gè)駐留呼叫保持的處理流程正式結束。
            3、Music on Hold
            Music on Hold(MoH),我們稱(chēng)之為呼叫音樂(lè )等待或者音樂(lè )等待。顧名思義,就是在等待過(guò)程中同時(shí)對等待方播放音樂(lè )媒體或者語(yǔ)音提示。通過(guò)音樂(lè )等待的方式會(huì )增加用戶(hù)的體驗,讓用戶(hù)不再感覺(jué)等待時(shí)間的煩躁。RFC7088 專(zhuān)門(mén)定義了語(yǔ)音等待的規范。IPPBX的功能熱鍵可啟用MoH功能。
            音樂(lè )等待具體的實(shí)現方式是,當呼叫方(Alice)呼叫被呼叫方(Bob)后,接聽(tīng)以后,被呼叫方用戶(hù)(Bob)設置此呼叫為等待狀態(tài),在等待狀態(tài)時(shí),通過(guò)媒體服務(wù)器對呼叫方播放音樂(lè ),或者其他的自定義的語(yǔ)音流。被呼叫方通過(guò)對媒體服務(wù)器或者音樂(lè )播放服務(wù)器發(fā)送一個(gè)REFER消息,攜帶呼叫方信息。然后媒體服務(wù)器對呼叫方發(fā)起INVITE,替換已經(jīng)創(chuàng )建的會(huì )話(huà)中的被呼叫方。然后,媒體服務(wù)器對被呼叫方(Alice)發(fā)送音樂(lè )媒體流服務(wù)。一定時(shí)間后,Bob重新設置等待的呼叫,對呼叫方(Alice)發(fā)送INVITE消息,然后替換會(huì )話(huà)中的媒體服務(wù)器,變成Bob和Alice之間的通話(huà)。注意,這里仍然使用了渲染功能,但是在F5流程中實(shí)現,表示其等待狀態(tài)開(kāi)啟。如果Alice拒絕對端的音樂(lè )播放,則Alice仍然會(huì )處于等待功能,但是會(huì )是靜音狀態(tài)(無(wú)聲音)。

            通過(guò)以上呼叫流程我們知道,完成音樂(lè )等待流程處理需要23個(gè)flows。其中,F5開(kāi)啟音樂(lè )等待功能,F12開(kāi)始媒體服務(wù)器替換了Bob,媒體服務(wù)器對Alice發(fā)送音樂(lè )數據流確認。在F12的流程中使用了渲染功能,增加了對automation和byeless功能標簽的支持。關(guān)于automation tag 的功能在rfc3840中定義,關(guān)于byeless tag 的支持在rfc4235中定義。rfc3840定義了媒體服務(wù)器的能力支持,rfc4235定義了自動(dòng)對話(huà)事件包管理機制。具體的細節讀者可以參考鏈接資源。以下是一個(gè)完整的音樂(lè )等待的呼叫流程,配合了SIP消息。我們根據此圖例來(lái)進(jìn)一步說(shuō)明具體的呼叫流程。
            首先是Alice對Bob發(fā)送INVITE消息(F1),表示要對Bob進(jìn)行呼叫。
            Bob對Alice發(fā)送180 振鈴消息(F2):
            緊接著(zhù),Bob對Alice發(fā)送200 OK消息(F3):
            Alice對Bob發(fā)送確認ACK(F4),開(kāi)始語(yǔ)音流傳輸通話(huà)。
            之后,Bob把Alice呼叫設置為音樂(lè )等待。Bob重新發(fā)送一個(gè)新的INVITE攜帶了SDP,并且包含了一個(gè)a=sendonly,表示等待開(kāi)啟。執行F5流程。
            然后,Alice回復Bob 200 OK消息(F6),在SDP中增加了a=reconly 表示接受等待。
            Bob回復Alice確認ACK,無(wú)RTP語(yǔ)音流。此時(shí),Bob準備開(kāi)始執行音樂(lè )媒體流服務(wù)。
            Bob對媒體服務(wù)器發(fā)送REFER消息,通知媒體服務(wù)器使用Alice替換Bob。
            媒體服務(wù)器對Bob發(fā)送202 消息,表示接受這個(gè)請求(F9)。
            然后媒體服務(wù)器發(fā)送NOTIFY消息(F10):
            Bob發(fā)送200 OK(F11):
            接下來(lái),媒體服務(wù)器對Alice發(fā)送INVITE消息,替換Bob(F12),注意這里的SIP消息中增加了渲染功能的支持,包括automation和byeless功能標簽,需要啟用事件包處理,媒體服務(wù)器能力支持等渲染功能。
            以上圖例中沒(méi)有顯示contact中的渲染功能標簽,但是在RFC5359中的音樂(lè )等待(F12)中的消息細節是:
            F12 INVITE Music Server -> Alice
            INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
            Via: SIP/2.0/TLS server.example.com:5061
            ;branch=z9hG4bK74rf
            Max-Forwards: 70
            From: ;tag=0111
            To:
            Call-ID: a5-75-34-12-76@server.example.com
            CSeq: 1 INVITE
            Referred-By:      Contact: ;automaton
            ;+sip.byeless;+sip.rendering="no"
            Require: replaces
            Replaces: 12345600@atlanta.example.com
            ;from-tag=23431;to-tag=1234567
            Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
            Supported: replaces
            Content-Type: application/sdp
            Content-Length: …
            Alice接受媒體服務(wù)器的請求,對媒體服務(wù)器發(fā)送200 OK(F13):
            媒體服務(wù)器收到200 OK以后,對Alice發(fā)送確認ACK消息(F14),然后對Alice發(fā)送音樂(lè )媒體流,Alice現在可以聽(tīng)到媒體服務(wù)器對Alice播放的音樂(lè )文件。
            因為已經(jīng)播放媒體流流程開(kāi)始,Alice對Bob發(fā)送BYE消息(F16):
            Bob接受來(lái)自于A(yíng)lice的BYE消息,對Alice發(fā)送200 OK(F16)。
            媒體服務(wù)器對Bob發(fā)送NOTIFY消息(F17),表示媒體播放成功,并且包含一個(gè)200 OK的響應消息。
            Bob對媒體服務(wù)器響應了一個(gè)200 OK(F18),表示收到此提示,同時(shí)包含了dialog的確認內容,包括了REFER需要的call-id,to tga和from tag。
            到此為止,Alice被完全駐留在媒體服務(wù)器的會(huì )話(huà)中。接下來(lái),Bob可能需要重新接聽(tīng)Alice的電話(huà),那么,Bob就會(huì )重新對Alice發(fā)送INVITE請求消息(F19),然后替換會(huì )話(huà)中的媒體服務(wù)器。
            Alice對Bob回復200 OK消息,表示接受替換,重新恢復到通話(huà)狀態(tài)(F20)。
            Bob最后對Alice回復確認ACK(F21),可以恢復正常通話(huà)狀態(tài)。
            雙方通話(huà)以后,因為媒體服務(wù)器仍然和Alice有會(huì )話(huà)的綁定關(guān)系,因此為了結束媒體播放,Alice仍然需要對媒體服務(wù)器發(fā)送一個(gè)BYE消息,表示音樂(lè )等待播放結束(F22):
            媒體服務(wù)器收到200 OK以后,對Alice發(fā)送一個(gè)最后的200 OK(F23),告知媒體服務(wù)器已經(jīng)收到Alice的響應,媒體服務(wù)器正式釋放被駐留在媒體服務(wù)器的會(huì )話(huà),解除Alice對媒體服務(wù)器的綁定關(guān)系。Bob和Alice的正常通話(huà)才算成功完成,雙方開(kāi)始正式的通話(huà)過(guò)程。
            在音樂(lè )等待的處理流程中使用了REFER的method來(lái)幫助處理音樂(lè )等待,具體的RFER規范在RFC3515中定義,讀者可以查閱學(xué)習。
            我們的討論中使用了一般的IPPBX媒體服務(wù)器來(lái)替換音樂(lè )媒體服務(wù)器,用戶(hù)也可以通過(guò)第三方的音樂(lè )服務(wù)的服務(wù)器端來(lái)處理音樂(lè )文件,用戶(hù)使用過(guò)程中可能可以獲得更多的體驗。另外,很多媒體服務(wù)器也可以對其播放文件實(shí)現自定義處理。例如,在A(yíng)sterisk/FreePBX或者FreeSWITCH開(kāi)源平臺都可以通過(guò)修改配置文件來(lái)實(shí)現自定義的MoH文件支持。
            在上面的討論中,我們僅根據呼叫流程的正常狀態(tài)說(shuō)明的整個(gè)MoH的處理過(guò)程。實(shí)際上,在MOH的實(shí)際部署過(guò)程中,讀者會(huì )遇到很多的其他的技術(shù)問(wèn)題。例如,播放文件的格式支持問(wèn)題,終端兼容性問(wèn)題,語(yǔ)音播放的帶寬消耗問(wèn)題,音樂(lè )播放的服務(wù)會(huì )話(huà)的管理問(wèn)題,回復消息失敗問(wèn)題等。所以,一般的MoH功能僅在內網(wǎng)環(huán)境下使用一般不會(huì )出現太多問(wèn)題。但是,如果通過(guò)第三方的媒體平臺提供所謂比較靈活的媒體播放業(yè)務(wù),讀者一定要注意以上問(wèn)題。
            4、Transfer - Unattended
            Transfer - Unattended或者Blind Transfer,我們稱(chēng)之為呼叫盲轉功能。呼叫盲轉簡(jiǎn)單來(lái)說(shuō),就是A呼叫B,然后B把A轉接到C,B掛機。A會(huì )對B報告一個(gè)NOTIFY消息,表示成功轉接。如果轉接C失敗,A會(huì )對B重新創(chuàng )建INVITE請求。以下是一個(gè)盲轉呼叫示例流程圖:
            另外讀者一定要注意,盡管被呼叫方發(fā)送了BYE消息(F9),但是Alice和Bob之間的Dialog仍然存在,這個(gè)dialog結束是根據REFER創(chuàng )建的訂閱來(lái)決定的。訂閱的NOTIFY中包含訂閱狀態(tài)的結果消息或者NOTIFY響應的481:
            F15 NOTIFY Bob -> Alice
            NOTIFY sips:alice@client.atlanta.example.com SIP/2.0
            Via: SIP/2.0/TLS client.biloxi.example.com:5061
            ;branch=z9hG4bKnashds67
            Max-Forwards: 70
            From: Bob ;tag=314159
            To: Alice ;tag=1234567
            Call-ID: 12345601@atlanta.example.com
            CSeq: 3 NOTIFY
            Event: refer      Subscription-State: terminated;reason=noresource
            Contact:
            Content-Type: message/sipfrag
            我們會(huì )根據以上圖例,結合具體的SIP消息和每個(gè)呼叫流程做進(jìn)一步的介紹。
            首先,Bob呼叫Alice(F1):
            然后Alice對Bob回復一個(gè)180 振鈴(F2):
            緊接著(zhù),Alice繼續對Bob發(fā)送一個(gè)200 OK(F3):
            Bob對Alice發(fā)送ACK確認消息,然后雙方執行RTP媒體流交互,開(kāi)始通話(huà)。
            通話(huà)后,Alice需要把Bob電話(huà)轉接到Carol第三方(F5):
            Bob對Alice回復202 Accepted(F6):
            然后Bob對Alice發(fā)送NOTIFY(F7),創(chuàng )建訂閱消息包:
            Alice收到NOTIFY以后,回復200 OK(F8):
            緊接著(zhù),Alice會(huì )繼續對Bob發(fā)送一個(gè)BYE消息(F9):此時(shí)RTP媒體流已經(jīng)中斷,雙方不再繼續通話(huà)。
            Bob也根據收到的BYE消息,對Alice發(fā)送一個(gè)200 OK消息(F10),到此為止,雙方語(yǔ)音完全斷開(kāi)。根據我們上面的討論,事實(shí)上,雙方仍然存在一個(gè)訂閱關(guān)系,因為電話(huà)轉接(Bob被轉接到Carol)是否成功仍然沒(méi)有進(jìn)行最后的確定。接下來(lái),Bob電話(huà)被轉接到Carol。呼叫流程開(kāi)始執行真正的電話(huà)轉接流程。
            根據以前的REFER消息,Bob對Carol發(fā)送INVITE消息,并且攜帶了“refer by” 的消息,說(shuō)明來(lái)自于A(yíng)lice的轉接(F11):
            Carol然后對Bob發(fā)送180振鈴(F12):
            緊接著(zhù),Carol對Bob發(fā)送200 OK(F13):
            Bob收到200 OK以后,發(fā)送ACK確認(F14),雙方正式開(kāi)始通話(huà)。
            現在,為了保持訂閱關(guān)系的一致性,Bob需要給Alice發(fā)送一個(gè)NOTIFY(F15),通知Alice,Bob和Carol轉接成功,可以正常通話(huà)。這里,也可能Alice忽略這些訂閱消息。
            Alice最后發(fā)送200 OK(F16),Bob和Carol進(jìn)行通話(huà)。
            通過(guò)16個(gè)流程的處理,一個(gè)完整的盲轉才可以完成。很多IPPBX或者媒體服務(wù)器(Asterisk/FreePBX/FreeSWITCH)都支持Blind transfer的功能熱鍵。用戶(hù)也可以通過(guò)SIP電話(huà)終端屏幕上的按鍵來(lái)實(shí)現轉接。
            例如,在示例的呼叫中,Bob呼叫Alice,Alice就可以通過(guò)功能熱鍵實(shí)現電話(huà)轉接功能。例如,在asterisk中定義的盲轉方式:
            [featuremap]
            blindxfer = #1 // FreeSWITCH使用*1實(shí)現盲轉。
            atxfer = *2 // FreeSWITCH使用*4實(shí)現詢(xún)轉。
            很多情況下,電話(huà)轉接失敗的概率很高,因為有可能第三方處于接聽(tīng)狀態(tài),有可能不在線(xiàn)等問(wèn)題,或者DTMF設置不當,轉接失敗。這些問(wèn)題用戶(hù)都需要通過(guò)配置IPPBX來(lái)進(jìn)行妥善處理。
            5、Transfer - Attended
            Transfer - Attended,我們稱(chēng)之為呼叫詢(xún)轉。簡(jiǎn)單來(lái)說(shuō),Alice呼叫Bob,通過(guò)通話(huà),Alice可能需要把電話(huà)轉接到Carol,然后Bob把Alice設置為等待狀態(tài)。Bob繼續呼叫Carol,同時(shí)對Carol說(shuō)明Bob需要把電話(huà)轉接給Alice。同時(shí),Bob與Carol的通話(huà)接通后,替換雙方之間的會(huì )話(huà)。Carol然后對Bob掛機。然后Alice對Bob發(fā)送一個(gè)報告,說(shuō)明Alice和Carol的電話(huà)轉接已經(jīng)成功。然后Bob對Alice掛機。
            通過(guò)上面的介紹,讀者可能已經(jīng)發(fā)現,Transfer-Unattended(Blind Transfer)和Transfer-Attended之間有所不同的。最大的不同之處在于盲轉過(guò)程中,電話(huà)轉接到終端不會(huì )詢(xún)問(wèn)第三方是否可以轉接,不關(guān)心轉接到第三方是否同意或者接受這個(gè)電話(huà)轉接(所以稱(chēng)之為“盲”)。而詢(xún)轉則有所不同,它和會(huì )轉接到第三方提前詢(xún)問(wèn),是否接受這個(gè)電話(huà)的轉接,然后再進(jìn)行電話(huà)轉接流程(所以稱(chēng)之為“詢(xún)”)。
            另外,在上面的例子中,Bob插入了Replace 頭 Refer-To URL。具體的Replace 頭的規范,讀者可以參考RFC3891。注意,Refer-To URL是一個(gè)Contact URL,它是詢(xún)轉接受方(Carol)在F10中返回的200 OK響應消息中的Contact URL。這樣可以保證正確的Carol的URL可達。在F10流程中,Contact URL中的參數gr表示Contact URL是一個(gè)GRUU,它表示是一個(gè)dialog之外的全球路由方式(RFC5627)。
            GRUU具有以下幾個(gè)特征,首先,它定義了指定的具體的用戶(hù)代理。其次,從理論上來(lái)說(shuō),可以支持全球路由方式。最后,它的存活周期很長(cháng)。我們簡(jiǎn)單查看一下關(guān)于GRUU的使用方式。如果支持了GRUU的SIP終端登錄的話(huà),其請求可能被復制出幾個(gè)不同的終端設備地址。
            但是,如果對某一臺指定的設備發(fā)送請求消息的話(huà),請求消息會(huì )根據不同的設備URL來(lái)發(fā)送,它會(huì )專(zhuān)門(mén)發(fā)送到指定的終端設備,例如,sip:user@domain;opaque=user:epid:UghFocauauCHBHoLhAAA;gruu
            發(fā)送到其他終端以后,那么,其他的設備就不會(huì )收到這個(gè)請求消息。
            在一些關(guān)于SIP的其他應用中,例如SBC的部署環(huán)境中,GRUU也支持了公開(kāi)的GRUU和臨時(shí)的GRUU,區別在于其存活周期的設定不同。具體的語(yǔ)法示例如下:
            pub-gruu=" Sip:userA@home.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
            ;temp-gruu="sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@home.net;gr";
            在詢(xún)轉過(guò)程中,如果示例中的Bob不知道Contact URL中的gruu,Bob必須自己修復這個(gè)問(wèn)題。如果觸發(fā)的INVITE失敗,Bob必須重新使用refer帶Refer-To URL來(lái)連接Carol,但是需要支持另外一個(gè)要求條件,Replace頭中必須棄用Refer-To頭。

            以上是關(guān)于電話(huà)詢(xún)轉到呼叫流程圖,處理過(guò)程需要27個(gè)具體的步驟,F在,我們配合詳細的SIP消息來(lái)進(jìn)一步解釋以上流程。
            首先是Alice對Bob發(fā)起INVITE請求,進(jìn)行呼叫(F1):
            然后,Bob對Alice發(fā)送180 振鈴(F2):
            緊接著(zhù),Bob對Alice發(fā)送 200 OK(F3):‘’
            Alice對Bob發(fā)送ACK確認消息(F4),雙方呼叫接通。
            Bob對Alice發(fā)送INVITE消息,開(kāi)啟等待狀態(tài)(F5)。
           
            Alice對Bob發(fā)送200 OK(F6):
            Bo對Alice發(fā)送ACK確認(F7):
            然后,Bob對Carol發(fā)送INVITE請求消息,要求完成Alice的電話(huà)轉接:
            參考資料:
            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,獲得有價(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中國合作伙伴,官方qq技術(shù)分享群(3000千人):589995817

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

          專(zhuān)題

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

          久久成人永久免费播放,国产精品二区在线,鲁啊鲁在线视频免费播放,精品三级内地国产在线观看

              <address id="lbt7n"></address>
              <delect id="lbt7n"><mark id="lbt7n"></mark></delect>
              <form id="lbt7n"></form>

                  <big id="lbt7n"><cite id="lbt7n"><cite id="lbt7n"></cite></cite></big>
                  <cite id="lbt7n"></cite>

                  <p id="lbt7n"></p>