這里，讀者要注意，卷1完全是rfc3261的中文翻譯，如果讀者有其他的版本或者更好的學習資源也可以參考其他的資源學習，筆者正在翻譯的版本可能結合一些應用場景和拓撲圖，方便讀者更好地了解SIP協議，所以和rfc3261 官方文檔的格式可能完全不一致，微信格式可能會造成一些閱讀問題，筆者會在最終以PDF或者word的格式發(fā)布RFC3261 中文版本，希望讀者耐心等待。
筆者僅發(fā)布一些最新的rfc3261的前面的章節(jié)，可能不完整，也可能和其他作者的比不是太正確，大家取長補短，也基本不妨礙對某些知識點的進一步了解。另外，rfc3261本身和其他技術協議一樣，完全是非常枯燥的閱讀體驗，沒有心靈雞湯或者其他勵志的內容匿名煽情，如果讀者想完整閱讀理解了這些協議的規(guī)范，多多少少需要一點耐心，還要耐得住寂寞。如果讀者已經有了一些經驗的話，結合協議本身再次閱讀，會有一種對SIP技術的重新認識，使得自己的技術得以大幅提升。無奈，如果你的才華支撐不了你的夢想，只能死磕。所以，還是一步步了解這些枯燥的技術概念才能逐漸掌握現在的SIP軟交換。
以下是RFC3261的部分中文學習筆記。格式和排版可能不太好看，在最終的PDF版本中會糾正。希望諒解！
1、背景介紹
很多基于網絡的應用軟件都要求可以實現會話創(chuàng)建和管理，這里的會話可以看著是關聯多個參與方交換數據的方式。實際部署這些應用軟件是非常復雜的過程：用戶可能在幾個終端之間移動切換，用戶也可能使用多個名字，用戶也可能使用不同的媒體，有時還同時使用不同的媒體介質。目前，有很多不同的協議被準許在網絡上運行，這些協議來傳輸各種形式的實時媒體會話數據，例如語音視頻，文本信息。 Session Initiation Protocol （SIP） 支持以上所說的這些功能描述和相關的協議，它可以支持開啟網絡的終端（called user agents）來發(fā)現其他的終端，準許其他終端的某些會話屬性，終端之間可以共享這些會話屬性。
為了查詢到期望的會話參與對象，和其他的功能，SIP支持了網絡主機設施設備創(chuàng)建（稱為代理服務器），用戶代理可以對會話發(fā)送注冊，邀請和其他的請求。SIP是一個敏捷，通用的工具，它用來創(chuàng)建，修改和結束會話，它可以不依賴于正在工作的傳輸協議，并且無需依賴于各種已建立的會話類型。
2、SIP功能概述
SIP 一種應用層的控制協議，它可以創(chuàng)建，修改和結束多媒體會話（會議），例如網絡電話呼叫。SIP也可以邀請參與對象加入到已存在的會話，例如多方廣播會議。它可以從當前存在的會話中再加入媒體也可以移除媒體。SIP可以透明支持名稱映射，服務重新轉發(fā)服務，這些服務功能支持個人移動能力-無論網絡位置如何，用戶可以在網絡中保持一個對外單點可視的身份。
SIP支持創(chuàng)建和結束媒體通信的五個方面的功能：
- 用戶定位： 端系統的決定來支持通信；
- 用戶有效性： 決定被呼叫方是否有意愿決定加入通信；
- 用戶能力： 決定用戶可使用的媒體和其媒體參數；
- 會話創(chuàng)建： "ringing"，在呼叫方和被呼叫方之間創(chuàng)建會話參數；
- 會話管理： 包括轉發(fā)，結束會話，修改會話參數和調用服務。
SIP 不是一個單一，垂直集成度通信系統。SIP而是一個模塊，它可以用來和其他的IETF協議集成來構建一個完整的媒體架構。典型的架構如，和實時傳輸協議（RTP）配合，實現實時數據傳輸，提供QoS反饋，使用實時媒體協議（RTSP）來控制媒體流和媒體的發(fā)送控制，媒體網關控制協議
�。∕EGACO）（RFC 3015[30]） 來控制網關對PSTN網絡的支持，和會話描述協議 （SDP） （RFC 2327[1]）來描述媒體會話。因此，SIP應該結合其他的協議一起使用對用戶提供完整的服務。但是，基本的SIP功能和操作不會依賴于其他任何協議。
SIP 本身不提供服務。但是，SIP提供基本的操作，這些操作可以支持部署不同的服務。例如，SIP可以定位一個用戶，并且對當前定位發(fā)送一個不透明的對象。如果此基本操作用來支持發(fā)送一個寫入SDP的會話描述，終端可以同意會話中的參數。如果同樣的操作用來傳遞一張呼叫方的圖片和此會話描述，那么就可以在早期部署一個“caller ID”服務。就像這個例子所展示的，一個單個基本操作往往被用來提供不同的服務。
SIP 不提供會議控制服務例如發(fā)言權控制和發(fā)言，它不能對會議發(fā)出命令控制如何管理會議。SIP可以用來發(fā)起一個會話，這個會話可以用來支持一些會議控制協議。因為，SIP創(chuàng)建的消息和會話可以傳遞到完全不同的網絡中，SIP不能也不會提供任何網絡資源預設的支持能力。
SIP所提供的服務的本質使得安全性特別重要。對于對端來說，SIP提供了一個安全服務單元，這些服務單元包括拒絕攻擊防止服務，認證（包括用戶對用戶，代理對用戶），集成保護，加密和私有服務。
SIP 可以支持IPv4和IPv6兩種網絡環(huán)境。
3、術語
在本文檔中，關鍵詞 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 通過BCP 14, RFC 2119[2] 加以解釋，并且說明了遵從SIP部署要求級別和嚴格程度。讀者需要根據關鍵詞的字面意思來區(qū)分這些規(guī)則的基本和寬泛程度，盡可能最大程度對應SIP協議的要求。很多時候，由于開發(fā)人員，特別是對英文協議了解不夠，或者對協議的理解不同，所以導致一些兼容性問題或者功能不一致等問題。
4、操作概述
此部分使用一個簡單示例介紹了SIP的基本操作。它實際上是一個學習輔導，沒有包含任何正式的說明。
第一個示例顯示了SIP的基本功能：終端定位，希望通信的意愿，創(chuàng)建會話參數的協商和創(chuàng)建會話后會話拆線。
圖表1 顯示了一個典型的介于兩個用戶之間的SIP消息交互，兩個用戶分別是Alice和 Bob。（每個消息都通過一個帶字母F的標簽來標注，文本號碼說明一個標注號碼）。在這個例子中，Alice使用了一個在PC上運行的SIP應用程序（作為一個軟電話）來呼叫Bob，Bob的電話是一個基于互聯網的SIP電話。這個圖例也同時顯示了，這里有兩個SIP 代理服務器介于Alice和BoB之間來支持會話管理工作。在圖例1中，這種典型的設置方式我們通常稱之為“SIP 拓撲圖” "SIP 框架" 。
Alice使用自己的SIP身份 “呼叫”Bob，這種SIP身份是一種URL類型，我們這里稱之為SIP URL。SIP URLs在Section 19.1中做了定義。它的格式和郵件的格式非常相似，一般都包括一個用戶名稱和主機名稱。在這個例子中，它就是 sip:bob@biloxi.com, 這里biloxi.com是一個Bob的SIP服務提供商。Alice可能也具有和Bob的URL同樣的類型，或點擊一個超鏈接后進入一個地址薄。SIP同樣也提供一個安全的URL，被稱之為SIPS URL。安全URL的示例為sips:bob@biloxi.com。通過SIPS URL發(fā)起的呼叫可以保證安全，加密的傳輸，它用來傳輸所有從呼叫方到被呼叫方域的所有SIP消息。 從這里，開始，SIP的請求消息安全地發(fā)送到被呼叫方，但是安全機制依賴于被呼叫方域的安全策略設置。
SIP 是基于一種類似于HTTP形式的請求/響應事務處理模式。每個事務處理包括一個啟動了特別method方法的請求，或者一個功能，和至少一個來自于服務器端的響應構成。在這個例子中，事務處理是以Alice的軟電話開始，軟電話發(fā)送一個INVITE請求，攜帶了Bob SIP URL地址。這里，INVITE就是一個SIP method方法，它指定了一個執(zhí)行命令，請求方（Alice）想讓服務器方（Bob）接收這個請求。這個INVITE請求中包含了幾個頭域header fields。Header fields 被命名為屬性值，這些屬性值提供了關于消息的其他額外信息。在INVITE中的某些屬性表示了呼叫的唯一身份，目的地地址，Alice的地址，和Alice和Bob之間創(chuàng)建會話所期望的會話類型的信息。INVITE （F1消息中）可能類似于這樣的流程：
Figure 1: SIP session setup example with SIP trapezoid
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
�。ˋlice的SDP 消息不顯示）
文本消息的第一行包含了一個方法名稱method（INVITE）。 緊接著的是幾行包含一個header 值域的列表。在這個示例中，它們包含了最少的要求設置。這些頭header簡單描述如下：
Via 包含了一個地址（pc33.atlanta.com），Alice希望對這個請求獲得響應的地址。它也包含了一個branch參數來確認這個事務處理。
To 包含了一個顯示名稱（Bob）和一個SIP或者SIPS URL（sip:bob@biloxi.com） 。Display names在RFC 2822[3]有介紹。
From 也包含一個顯示名稱（Alice）和一個SIP或SIPS URI （sip:alice@atlanta.com），它表示這個請求的發(fā)起方。這個header同時還有一個一個標簽tag參數，此標簽包含了一個任意字符串（1928301774），這個字符串被添加到了軟電話的URL。此標簽也是為了確認身份的目的。
Call-ID 包含一個對這個呼叫的全局唯一確認信息，它是由一個任意字符串和軟電話主機名稱或IP地址組合而成。To tag的組合，From tag的組合，和Call-ID完整定義了一個Alice和BoB兩者之間的點對點的SIP關系，這種關系可以看作一個dialog對話。
CSeq 或Command Sequence包含一個整數和一個method名稱。這個CSeq是一個增長的數值，它是支持每一個在dialog里新的請求，并且是一個普通的序列號碼。
Contact 包含一個SIP或者SIPS URI，它用來表示一個直接的路由去聯系Alice，通常情況下，它由一個用戶名稱以及它所在的全限定域名構成（FQDN）。 如果使用了全限定域名（FQDN）的話，許多終端系統沒有已注冊的域名，因此，這里IP地址是允許的。Via頭告訴其他參數往哪里發(fā)送響應消息，Contact告訴其他參數往哪里發(fā)送將來的請求消息。
Max-Forwards 最大前轉來限定一個請求到達目的地的最大跳躍（hop）數量。它是由一個整數數值構成，在經過一個跳轉時會降低一個數值。
Content-Type 包含一個信息體的描述，這里忽略。
Content-Length contains an octet （byte） count of the message body.
完整的SIP頭域集合在Section 20 中有詳細的定義。
會話的細節(jié)，例如媒體類型，編碼，采樣率等沒有在SIP中進行描述。 這些細節(jié)而是包含在了SIP消息體中，它們通過編碼以后以各種協議的格式出現。其中一種協議格式就是 會話描述協議-Session Description Protocol （SDP） （RFC 2327[1]）。這個SDP消息（沒有在這里顯示）示例是通過SIP消息來傳輸，傳輸的方式類似于電子郵件中的附件方式來傳輸，或類似于通過HTTP消息傳輸網頁頁面內容的方式。
因為軟電話不知道Bob的地址或biloxi.com域名中的SIP服務器地址，軟電話發(fā)送一個INVITE 到SIP 服務器端，這個SIP服務器支持Alice的域，atlanta.com。 atlanta.com SIP 服務器已經配置了Alice的軟電話，或者通過DHCP發(fā)現了軟電話地址信息。
這個atlanta.com SIP 服務器是一個代理服務器。代理服務器接收請求，然后作為一個請求者轉發(fā)這些請求。在這個實例中，代理服務器接收到了INVITE請求，然后發(fā)送了一個100 （Trying） 響應給Alice的軟電話。這個100 （Trying） 響應表示這個INVITE已經被收到，代理正在通過路由設置路由這個INVITE到其目的地。
在SIP中，響應消息使用一個三位數的碼和描述短語作為回復消息。這個響應消息在Via中包括同樣的To， From， Call-ID， CSeq 和 branch參數 parameter，這些參數和INVITE中的一樣，這些參數允許Alice的軟電話關聯響應消息來發(fā)送INVITE消息。這個atlanta.com代理服務器定位到這個代理服務器在biloxi.com，它可能執(zhí)行一個特別的DNS查詢來找到服務biloxi.com 域的SIP 服務器。這個部分的描述在[4]中。 因此，它獲得biloxi.com 代理服務器的IP地址，然后轉發(fā)或者在這里代理其INVITE請求。在轉發(fā)這個請求之前，這個 atlanta.com 代理服務器添加另外一個Via頭域，這個頭域包含自己的地址（這個INVITE已經在第一個Via包含了Alice的地址）。biloxi.com 代理服務器收到這個 INVITE消息后，然后回復一個帶100 （Trying） 響應消息到atlanta.com 代理服務器，表示它已經收到了這個INVITE消息，正在處理這個請求。代理服務器會查詢一個定位服務器，我們稱之為定位服務，定位服務包含當前Bob的IP地址。（我們將會在下一個部分看到如何實現數據庫查詢。）biloxi.com 代理服務器會添加另外一個Via header ，并且攜帶自己的IP地址，這個地址是對這個INVITE請求的，代理轉發(fā)這個請求到Bob的SIP軟電話。
Bob的軟電話收到這個INVITE 消息后，對 Bob 發(fā)出提示，告訴他有從Alice來的電話呼叫，Bob決定是否應答這個呼叫，這里Bob的軟電話會產生振鈴提示。Bob的軟電話提示180振鈴，這個響應消息會路由根據相反的方向回到兩個代理服務器。每個代理使用Via header 域值來決定發(fā)送響應的地址方向，并且從頂部路由記錄中刪除自己的地址。因此，盡管要求DNS和定位服務查詢 路由這個初始的INVITE請求，180（Ringing）響應返回到呼叫方時可以沒有查詢消息或沒有代理服務器中所保持的狀態(tài)。
這樣也獲得了一個合理的響應屬性，每個看到INVITE消息的代理服務器也可以看到所有對INVITE的響應消息。
當Alice的軟電話收到這個180 （Ringing）響應后，它會傳遞這個信息給Alice，傳遞過來的信息方式可以使用一個回鈴音（ringback tone）或或者在Alice終端屏幕顯示一個消息。
參考資料：
https://www.rfc-editor.org/rfc/pdfrfc/rfc3262.txt.pdf
關注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協同解決方案首選產品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術分享群（3000千人）：589995817
