- SIP/2.0200 OK
- Via: SIP/2.0/UDPserver10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3
- Via: SIP/2.0/UDPbigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
- Via: SIP/2.0/UDPpc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1
- To:Bob <sip:bob@biloxi.com>;tag=a6c85cf
- From:Alice <sip:alice@atlanta.com>;tag=1928301774
- Call-ID:a84b4c76e66710@pc33.atlanta.com
- CSeq:314159 INVITE
- Contact:<sip:bob@192.0.2.4>
- Content-Type:application/sdp
- Content-Length:131
- （Bob'sSDP not shown）
響應消息的第一行包含了響應碼（200）和響應原因短語(yǔ)習語(yǔ)（OK）。其余其他行消息包含 header值域消息。Via，To， From，Call-ID，和 CSeq header 值域都是從 INVITE請求中拷貝過(guò)來(lái)的。（注意，這里有三個(gè)Via 頭值–一個(gè)是Alice軟電話(huà)添加的，另外一個(gè)是atlanta.com代理服務(wù)器添加到，還有一個(gè)是biloxi.com代理添加的）。Bob的軟電話(huà)已經(jīng)在header中添加了一個(gè)taq標簽參數To。這個(gè)標簽將會(huì )在兩個(gè)終端的dialog中使用，也將會(huì )在此呼叫將來(lái)的請求和響應使用。
Contact頭包含了一個(gè)URL地址，這個(gè)URL就是Bob可以直接訪(fǎng)問(wèn)的軟電話(huà)地址。 Content-Type 和 Content-Length參考消息體（這里沒(méi)有列出），這個(gè)消息包含了BobSDP 媒體的信息。
另外，在這個(gè)示例中，DNS和定位查詢(xún)顯示代理服務(wù)器可以做一個(gè)靈活的路由決定，它可以決定往哪里發(fā)送請求。例如，如果Bob軟電話(huà)返回一個(gè)486 （Busy，忙狀態(tài)）響應的話(huà)，biloxi.com 代理服務(wù)器可以代理這個(gè)INVITE到Bob的語(yǔ)音郵箱服務(wù)器。代理服務(wù)器也可以同時(shí)發(fā)送一個(gè)INVITE到多個(gè)地址。這種類(lèi)型的并行查詢(xún)方式稱(chēng)之為forking（分支）處理方式。
在這個(gè)示例中，200 （OK） 消息通過(guò)兩個(gè)代理服務(wù)器返回到Alice，Alice軟電話(huà)收到響應消息，軟電話(huà)停止回鈴音，表示呼叫已應答。最后，Alice軟電話(huà)發(fā)送一個(gè)確認消息ACK，這個(gè)消息發(fā)送到Bob軟電話(huà)來(lái)確認最終響應 （200 （OK））已收到。在這個(gè)示例中，這個(gè)ACK是通過(guò)Alice軟電話(huà)直接被發(fā)送到了Bob軟電話(huà)，發(fā)送過(guò)程繞開(kāi)了兩個(gè)代理服務(wù)器。這樣處理的原因就是因為兩個(gè)終端已經(jīng)通過(guò)互相學(xué)習知道對方的地址，雙方地址是通過(guò)INVITE/200（OK）交互時(shí)的Contact頭獲得，當然這個(gè)地址在初始時(shí)的INVITE是雙方都不知道的。兩個(gè)代理服務(wù)器的查詢(xún)服務(wù)也不需要。因此，代理服務(wù)器則會(huì )退出這個(gè)呼叫流程。這個(gè)處理過(guò)程成功實(shí)現了 INVITE/200/ACK 三方握手，并且創(chuàng )建了SIP會(huì )話(huà)。完整的關(guān)于SIP會(huì )話(huà)創(chuàng )建的細節，請參考Section 13。
注意，為了幫助讀者非常清晰地理解rfc3261，在本章節和未來(lái)的章節中筆者會(huì )適當增加一些第三方的資料和流程圖，這樣比完全介紹rfc3261協(xié)議本身更加清晰，以便幫助讀者更好理解SIP協(xié)議。但是，為了保證rfc3261的權威性和完整性，如果是第三方的資料，筆者會(huì )盡量注明是非rfc3261協(xié)議資料。
非rfc3261協(xié)議資料
Alice和Bob之間的媒體會(huì )話(huà)啟動(dòng)，他們之間的軟電話(huà)開(kāi)始發(fā)送媒體數據包，媒體數據包的格式是他們之間的SDP交互互相同意支持的格式。一般來(lái)說(shuō)，端對端的媒體數據通過(guò)不同的路徑發(fā)送，而不是使用SIP信令消息的路徑。
在這個(gè)會(huì )話(huà)過(guò)程中，Alice或Bob任何一方都可以有權決定修改媒體會(huì )話(huà)的屬性。修改會(huì )話(huà)屬性是通過(guò)發(fā)送一個(gè)re-INVITE消息，在此消息中包含一個(gè)新的媒體描述來(lái)實(shí)現。這個(gè)re-INVITE涉及到了已存在的dialog,因此其他的參與方知道這個(gè)消息是修改了現在的會(huì )話(huà)，而不是重新建立的新會(huì )話(huà)。其他方發(fā)送一個(gè)200（ok）接受這個(gè)修改。請求方對200（ok）發(fā)送一個(gè)ACK。如果其他方不能接受這個(gè)修改的話(huà)，它會(huì )發(fā)生一個(gè)錯誤響應，例如488 （Not Acceptable Here），同樣也接收一個(gè)ACK確認消息。但是，這個(gè)re-INVITE失敗不會(huì )導致目前的呼叫失敗-這個(gè)會(huì )話(huà)仍然會(huì )繼續使用以前協(xié)商的屬性。完整的話(huà)會(huì )修改細節，請閱讀Section14。
在呼叫結束后，Bob首先掛機（hangs up），并且生成一個(gè)BYE消息。這個(gè)BYE會(huì )直接路由返回到Alice的軟電話(huà)，這里仍然繞過(guò)了代理。Alice確認了BYE接收，發(fā)送一個(gè)200（ok），結束這個(gè)會(huì )話(huà)和BYE消息事務(wù)。這里沒(méi)有ACK發(fā)送-ACK發(fā)送僅發(fā)生在對INVITE請求的響應中。對于對INVITE特別處理的原因會(huì )在后續的章節中討論，這里涉及了SIP中的可靠性機制問(wèn)題，振鈴應答的時(shí)間程度和分叉處理等因素。因為這個(gè)原因，SIP中的請求處理經(jīng)常被劃分為INVITE或者non-INVITE兩個(gè)層面，除了INVITE method以外，還涉及其他的所有methods 。完整的關(guān)于會(huì )話(huà)結束的詳情將在Section 15進(jìn)行討論。
Section 24.2 描述了在 Figure 1的完整的消息構成。
在某些案例中，對于代理來(lái)說(shuō)可能非常有用，在整個(gè)會(huì )話(huà)期間可以看到兩個(gè)終端之間在SIP信令路徑上的所有消息。例如，如果 biloxi.com 代理服務(wù)器希望保持除了初始INVITE以外的SIP消息，它對INVITE添加一個(gè)要求的路由header值，這個(gè)值我們稱(chēng)之為Record-Route，用來(lái)解析主機或者代理的IP地址。因為Bob軟電話(huà)（這個(gè)消息會(huì )通過(guò)200（ok）傳送會(huì )Bob）和Alice軟電話(huà)將會(huì )收到這個(gè)消息，在整個(gè)dialog過(guò)程中保存這個(gè)消息。biloxi.com 代理服務(wù)器將收到和對BYE代理轉發(fā)這個(gè)ACK，BYE和200（OK）。每個(gè)代理可以獨立決定收到的后續的消息，消息將被通過(guò)所有選擇接收的代理發(fā)送，這些代理來(lái)接收這個(gè)消息。這個(gè)能力經(jīng)常被代理使用，代理通過(guò)這個(gè)能力可以提供mid-call 功能或者呼叫期間的控制功能。
注冊是另外一個(gè)SIP常用的操作。注冊是一種方法，它可以使得biloxi.com服務(wù)器獲知當前Bob的位置。Bob軟電話(huà)基于初始化處理，在一定周期內Bob軟電話(huà)對在biloxi.com的服務(wù)器發(fā)送REGISTER消息，我們稱(chēng)之為SIP registrar或者SIP注冊。REGISTER 消息關(guān)聯(lián)Bob的SIP軟電話(huà)或者SIPS URI （sip:bob@biloxi.com），這個(gè)機器是當前Bob寫(xiě)入記錄的地址（它在Contact頭中傳輸SIP或者SIPURL）。這個(gè)注冊會(huì )寫(xiě)入此關(guān)聯(lián)，也被稱(chēng)之為在數據庫中的綁定或者定位服務(wù)，此定位服務(wù)可以使用在biloxi.com 域的代理中。經(jīng)常，對于一個(gè)域的注冊服務(wù)器需要和這個(gè)域的代理協(xié)同工作。這里一定要注意，區分不同類(lèi)型的SIP服務(wù)器功能概念是非常重要的，它們區別是在于邏輯處理的不同，而不是物理上，形體上的不同。
Bob不僅僅局限于從一臺設備注冊。例如，Bob的兩個(gè)終端設備，一臺在家里面，另外一臺在辦公室都發(fā)送注冊消息。兩臺設備的消息都保存在定位服務(wù)中，允許代理執行各種對Bob 終端的定位查詢(xún)。
同樣的道理，同一時(shí)間，多個(gè)用戶(hù)可以注冊到一臺單個(gè)設備上。
定位服務(wù)僅是一個(gè)抽象概念。通常情況下，它包括一些必要的信息，它支持代理輸入一個(gè)URL，并且接收零個(gè)或多個(gè)URL，這些URL告訴代理往什么地址發(fā)送請求。注冊是一種方式來(lái)創(chuàng )建這些信息，但也不僅僅是這一種方式。任意映射功能可以通過(guò)管理員自行決定。
最后，一定要注意，在SIP中注冊是用來(lái)路由入局的SIP請求的，它不能充當出局的授權請求的角色。在SIP中，簽權和身份認證的處理可以基于逐一請求的方式，使用 challenge/response 機制的方式來(lái)處理，或使用更低一層的方案來(lái)處理，這種方案的討論在Section26有所描述。
完整的關(guān)于SIP注冊的消息細節示例在Section 24.1討論。
其他的SIP操作，例如查詢(xún)SIP服務(wù)器的能力或終端使用OPTIONS，或使用CANCEL取消正在進(jìn)行的請求等流程將會(huì )在后續之間進(jìn)行討論。
5 SIP 協(xié)議結構
SIP 是按照一定的層級結構創(chuàng )建的協(xié)議，這表示它的行為是根據一系列各自相對獨立的處理流程來(lái)實(shí)現，每個(gè)處理階段之間是松耦合關(guān)系。協(xié)議行為描述為多個(gè)層級，這樣是為了支持呈現的目的，支持標準的函數描述，這些描述涉及了單一環(huán)境的多個(gè)要素。它不能通過(guò)任何方式來(lái)決定部署。當我們說(shuō)一個(gè)要素“包含”一個(gè)層級時(shí)，我們的意思是它符合一系列在這個(gè)層級所定義的規范規則。
不是每個(gè)通過(guò)協(xié)議設定的要素都包含在每個(gè)層級。進(jìn)一步說(shuō)，在SIP協(xié)議中設定的要素是邏輯要素，不是物理形態(tài)的要素。一種物理實(shí)現可以選擇不同的邏輯要素來(lái)執行，也許可以基于依次事務(wù)對事務(wù)的處理方式進(jìn)行。
非rfc3261協(xié)議資料
SIP結構的最低層是語(yǔ)法和解碼層。解碼是通過(guò)增強的Backus-Naur Form grammar （BNF）語(yǔ)法來(lái)實(shí)現的。完整的BNF在Section 25有介紹。整個(gè)SIP消息結構的總覽在Section 7介紹。
第二層是傳輸層。它定義了用戶(hù)如何發(fā)送請求，如何接收響應和服務(wù)器如何通過(guò)網(wǎng)絡(luò )接收請求和發(fā)送響應。所有SIP要素都包含一個(gè)傳輸層。傳輸層是在Section 18進(jìn)行描述。
參考資料：
https://www.rfc-editor.org/rfc/pdfrfc/rfc3262.txt.pdf
關(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
