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