NGN學習筆記3——軟交換中的協議1--SIP、SIP-I\SIP-T\BICC

1.Overview：

2.SIP協議：

1）概述

SIP: Session Initiation Protocol，由IETF制定，最先由MMUSIC工做組提出，如今主要由SIP工做組負責維護和後期擴展，是一種輕量級的應用層通用信令協議，用於多媒體通訊控制，可創建、修改和終止IP網上的語音和多媒體會話。

典型的SIP梯形網絡結構：

SIP的Offer/Answer模型：

也稱爲會話協商模型，以在對等功能實體之間進行會話協商經過在SIP消息的消息體中包含SDP描述完成。、

• Offer:包括媒體類型、媒體格式、地址
• Answer:是否接收媒體類型、媒體格式、地址

在會話過程當中，任何一方能夠經過Offer/Answer模型修改會話屬性。

2）發展和應用狀況：

• 1999年，MMUSIC工做組推出SIP V1.0 (RFC2543)。
• 2003年，SIP工做組推出SIP V2.0 (RFC3261)目前已進行了許多擴展，並被3GPP/3GPP二、OMA、ETSI、ITU-T等標準化組織普遍採納。

3）相關標準：

a）SIP核心標準：

b）SIP擴展標準：

IETF針對SIP的不一樣應用需求制定了上百篇SIP擴展RFC，

SIP相關RFC：
3261-32xx, 33xx, 34xx, 35xx, 36xx, 37xx, 38xx, 39xx, 40xx,
41xx, 42xx, 43xx, 44xx, 45xx, 46xx, 47xx, 48xx, 49xx, 50xx, 
51xx, 52xx, 53xx, 54xx, before 3261

4）SIP基本功能：

• 用戶定位：肯定被叫用戶通訊所使用的終端系統的位置
• 用戶能力協商：肯定所用媒體類型和媒體參數
• 用戶可用性判斷：肯定被叫用戶是否空閒以及是否願意加入會話
• 邀請用戶加入會話（呼叫創建）：邀請和提示被叫用戶，在主被叫間傳遞控制參數是SIP的主要功能
• 呼叫處理：對呼叫進行終結和轉移等

5）SIP的特色

• 基於文本的協議：簡單靈活，便於擴展，易於用Java、Perl等面向對象的語言實現，易於調測排錯
• 獨立於底層傳輸協議：可工做在UDP、TCP、SCTP等協議之上，消息的格式及操做
• 過程與傳送協議無關：推薦首選UDP，能夠減小呼叫創建時延，便於應用採用多播機制
• 呼叫和媒體控制信息同時傳送：在傳送呼叫控制信令的同時，還能夠在消息文本中經過SDP傳送呼叫的媒體類型和格式等信息，以加快呼叫創建的速度便於增長新的應用或媒體
• 支持用戶移動性
• 支持直接路由和代理路由

6）網絡中元素：

SIP基本網絡模型：客戶-服務器協議，在語法和語義上與HTTP相似，SIP客戶發出請求，SIP服務器接收請求並進行響應

a）SIP用戶代理UA：

端系統中的SIP應用稱做SIP用戶代理(UA)，UA = UAC + UAS，UA最基本的功能是支持SIP請求和應答的正確發送和接收。

• 用戶代理客戶(UAC) - 發送SIP請求
• 用戶代理服務器(UAS)-偵聽呼叫請求，提示用戶或執行程序做出響應

B2BUA：在一次呼叫中既充當UAC又充當UAS角色，UAC根據UAS接收到的請求消息構造新的請求消息進行發送。

b）SIP代理服務器Proxy Server：

負責未來自客戶的請求轉發 到下一跳SIP代理服務器或重定向服務器或最終的UAS，也可能將請求分發到多個下一跳服務器。

主要功能：尋址、路由、轉發，能夠解釋、翻譯、改寫SIP請求。

分類：

• 有狀態代理服務器：做爲虛擬的UAC/UAS，維持事務/對話狀態機，須要記憶入請求和出請求
• 無狀態代理服務器：接收請求，進行必要的翻譯，發出請求，不須要記憶任何請求信息
• 分叉代理服務器：必須有狀態記憶能力，以便將請求和應答進行匹配
• 非分叉代理服務器：能夠無狀態記憶能力

c）SIP重定向服務器Redirect Server：

經過響應告訴請求的發起方下一跳服務器的地址，而後由請求發起方根據此地址向下一跳服務器從新發送請求 。

與Proxy Server的區別

• 重定向服務器的目的是提供可供選擇的地址列表供用戶定位SIP UA，代理服務器則是代替用戶繼續後面的定位嘗試
• 重定向服務器只提供地址解析服務，相似於DNS
• 重定向服務器不主動發送SIP請求
• 重定向服務器須要維持事務狀態

d）SIP註冊服務器Register Server

經過註冊過程接收客戶當前的位置信息，並對位置服務器進行添加、修改、查詢等操做。一般與代理服務器或重定向服務器放在一塊兒。

功能：

• 接收用戶的註冊請求
• 記錄用戶的SIP地址和IP地址的綁定關係
• 提供註冊認證功能，是實現用戶移動性的基礎

e）位置服務器

存儲並向用戶返回可能的位置信息，在SIP網絡架構中起到重要做用的Internet公共服務器。位置服務器的信息可能來自SIP註冊服務器，也可能經過其餘渠道獲取。位置服務器與SIP服務器之間經過使用LDAP協議 進行通訊，位置服務器可能返回多個位置信息，重定向服務器和代理服務器能夠採用不一樣的方式來處理這多個位置信息。

咱們看一個呼叫的過程體會一下各個功能實體的做用：

 

7）SIP協議的結構及其位置

各層功能相對獨立。層與層之間鬆散耦合，SIP獨立於網絡傳輸協議。

事務用戶層

• 負責處理請求或響應、產生請求或響應
• 負責客戶事務(CT)和服務器事務(ST)的建立和銷燬
• 經過事務層完成消息的發送和接收
• 除無狀態Proxy外，全部SIP實體都包含事務用戶層

事務層

• 接收來自事務用戶層的請求或響應，並向下傳給傳輸層進行傳送，同時完成重傳、響應與請求之間的匹配以及應用層超時處理等
• 用戶代理、有狀態Proxy都包含事務層，無狀態Proxy不包含事務層

傳輸層

• 定義了客戶如何發送請求和接收響應以及服務器如何接收請求和發送響應
• 該層從事務層接收消息，或將網絡中收到的消息傳給對應的事務
• 全部的SIP實體（包括客戶和服務器）都包含傳輸層

語法和編碼層

• 定義SIP操做的語法和編碼表示，使用BNF範式描述

8）SIP消息：

a）簡述：SIP消息用於創建或終結會話，採用純文本形式，用於Internet多媒體會議，Internet電話呼叫或多媒體信息流分配。SIP中最重要的消息是邀請「INVITE」請求消息

b) 類型：

• 請求消息：請求行=方法 +空格 +請求地址 +SIP版本號 +空行。經過一個請求行做爲起始行，請求行包括了方法名、請求的URL、協議版本號、中間用空格分開。
• 應答消息:狀態行=SIP版本+空格+狀態碼+空格+相關文本短語+空行，SIP應答消息狀態碼與功能

c）消息體通用結構：

SIP消息＝起始行（請求行/狀態行）
一個或多個消息頭域行
CRLF（空行）
[消息體]

• start-line（起始行）：在請求消息中稱爲請求行，在響應消息中稱爲狀態行，給出版本號、調用的請求操做、被邀請用戶的當前地址、響應類型等信息。
• headers 域：攜帶呼叫屬性和業務信息，用於指示客戶機/服務器如何處理消息，許多頭域來自HTTP（From, To, …）。有些是SIP特有的（Call-ID, Cseq, Via, …）。
• body 域：攜帶呼叫或會話描述，可使用SDP格式，描述會話的音頻/視頻編解碼方法、參數、地址以及會話的時間等信息。在響應消息中還多是緣由和進展指示文本。

d）SIP消息起始行：

• 請求消息：客戶機->服務器，「請求行（Method  Request-URI  SIP-Ver）」
  • INVITE：邀請一個用戶加入一電話呼叫或會議
  • ACK：證明客戶已收到對INVITE請求的最終響應，僅和INVITE方法配套使用
  • BYE：終止用戶之間的會話
  • OPTIONS：請求用戶能力信息，但不創建呼叫
  • CANCEL：終止未決的請求
  • REGISTER：將用戶的位置信息送往SIP註冊服務器

RFC3261中定義的基本方法Method：

注：SIP方法能夠進行擴展

Request-URI 請求去往的服務器的地址

SIP-VerSIP版本號目前設爲SIP/2.0

• 響應消息：服務器->客戶機，「SIP響應消息＝狀態行（Status-code Reason-phase   SIP-Ver）」
  • 中間響應：報告呼叫進展狀況，1xx，即呼叫進展響應，指示請求已被服務器接收並正在處理，但還沒有產生明確的響應，目的是防止UAC重傳請求，一 般不須要證明。100 trying、180 ringing、181 call is being forwarded、182 queued、183 call progress
  • 最終響應：報告呼叫成功或失敗，2xx，3xx，4xx, 5xx, 6xx。

  2xx，成功響應。表示請求已成功接收、徹底理解並被接受，如200 OK

  3xx，重定向響應。須要採起進一步動做來完成該請求，如30一、30二、305

  4xx，客戶出錯。請求語法出錯或沒法在此服務器完成該請求，如40一、40三、407，……

  5xx，服務器出錯。服務器不能完成合法的請求，如50三、504，……

  6xx，全局故障。任何服務器都沒法完成該請求

  注：SIP響應碼能夠進行擴展

e）SIP消息頭域：

用於攜帶呼叫屬性和業務信息，用於指示客戶或服務器如何處理消息，語法和語義相似HTTP。同一頭域名的多個頭域值能夠位於同一頭域行，頭域值之間 用逗號隔開。頭域存在多個參數時，頭域值與參數之間用逗號隔開。RFC3261定義了44個頭域，頭域的順序沒有嚴格限制，但建議將須要Proxy處理的 頭域放在前面。From、To、Call-ID、CSeq、Via和Max-Forwards這六個頭域在全部的請求消息中都必須出現。Contact頭 域在INVITE請求消息的頭域中必須出現。

通用格式：field-name: field-value *(;parameter-name=parameter-value)

• Call-ID：標識一個特定的邀請，或來自一個UAC的全部註冊請求；標識一個特定的邀請和與這個邀請相關的全部後續事務；Call-ID表明了一個或多個用戶之間共享的信令關係。
• CSeq：在同一對話中標識不一樣事務的順序，保證了同一用戶發送的不一樣請求消息間的順序，包括一個十進制的序列號和一個請求方法名；CSeq: 4711 INVITE。
• Max-Forwards：請求可被代理轉發的最大跳數（0-255），建議值70，Max-Forwards: 70。
• From：標識請求的發送方，能夠包含一個「display-name」參數和「tag」參數，From: "A. G. Bell" ;tag=a48s。
• To：指示請求的邏輯接收者，在整個對話的創建及持續過程當中不變，也不能被代理改變 。它一般包含目的方的公開地址（AOR），能夠包含一個「display-name」參數和「tag」參數，To: 「The Operator」;tag=287447。
• Contact：UAC或UAS的直接聯繫地址，可使SIP服務器在路由第一個消息後，再也不須要存在於信令通道中。Contact: "Mr. Watson" watson@worcester.bell-elephone.com >; q=0.7; expires=3600 。
• Content-Type：指示消息體的媒體類型，Content-Type: application/sdp。
• Content-Length：以十進制表示消息體的字節數，Content-Length: 349。
• Via：存儲全部處理請求的代理的地址，表示到目前爲止通過的路徑，可使響應消息沿請求消息的原路徑返回，還可用於檢測環路，由傳輸層協議、客 戶名和地址，及接收響應的端口號組成。Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
• Record-Route：由始終位於信令路徑的Proxy使用，由Proxy在請求消息中插入，以強制要求該對話中的後續請求經過該Proxy路由。
• Route：表示須要按照頭域中列出的Proxy對請求進行路由 Route: ,

f）SIP消息體：

SIP消息頭只涉及會話創建、終結和修改，並不涉及媒體控制。SIP會話的媒體類型、編碼格式、收發地址等信息由SIP的消息體（SDP）來描述。SIP請求和響應消息均可以包含消息體
SIP消息體一般在UA之間進行端到端的傳送，對中間代理透明。SDP是用於描述多媒體會話信息的協議，目的爲告知某會話的存在給出參與會話所必需的信息，包括會話的地址、時
間、媒體類型等信息。SDP定義了會話描述的統一格式，但不定義SDP消息的傳送，也不支持媒體編碼方案的協商。SDP描述的信息封裝在傳送協議中傳送。 典型的會話傳送協議包括：SAP、SIP、RTSP、HTTP、使用MIME的E-mail。採用SAP、SIP或RTSP傳送SDP信息的數據報格式。

SDP會話描述做爲消息體放在SIP消息中，只有請求消息和2xx響應消息包含SDP消息體，其它響應消息包含的消息體爲文本描述，給出呼叫進展信息和異常緣由的說明。

SIP消息體頭部中用於說明消息體類型和大小的部分：

• 內容類型(content-type)：指明消息體的類型。共有兩種類型。application/sdp表示是SDP會話描述；text/html表示是普通文本或html格式描述
• 內容編碼(content-encoding)：補充說明消息體類型，使用戶能夠採用壓縮編碼編輯消息體
• 內容長度(content-length)：給出消息體的字節數

SDP內容：

• 會話名和目的
• 會話激活的時間區段
• 構成會話的媒體
• 媒體類型（如音頻、視頻、數據）
  • 傳送協議（如UDP、H.320）
  • 媒體格式（如H.261視頻）
  • 媒體地址和端口
• 接收媒體所需的信息（地址、端口、格式等）
• 會話所用的帶寬信息（任選）
• 會話負責人的聯繫方式（任選）

SDP格式：

SDP描述由多個文本行構成 =，純文本描述——具備可攜帶性，緊湊型編碼——各字段有嚴格的順序和格式。

SDP描述包括兩部分

• 會話級描述：給出適用於整個會話和全部媒體流的描述信息，以「v=」文本行開始，一個會話描述可能包含一個（SAP中）或多個會話級描述（SIP、RTSP等）。
• 媒體級描述：給出只適用於該媒體流的信息，以「m=」文本行開始，一個會話描述能夠包含零個或多個媒體級描述。

g）SIP舉例：

SIP請求消息舉例——INVITE

SIP響應消息舉例——200 OK

h）SIP尋址和路由

尋址：在SIP中，用戶經過SIP/SIPS URI進行尋址，SIP URI有如下幾種形式。

• sip:user@domain--sip:wei.wang@alcatel.com
• sip:user@host--sip:manu5@bellsip.alcatel.be
• sip:user@IP_address--sip:manu@198.137.241.30
• sip:phone_number@gateway--sip:+86-1-62409735@beijing.net2phone.com

路由：

UAC的路由機制--

相關頭域：

• Request-URI：位於請求行，通常與To頭域的值一致
• Route：可選頭域，只出如今預設路由的狀況

路由策略：

• 存在Route頭域時，按照Route頭域的第一個URI路由請求消息。
• 不存在Route頭域時，按照Request-URI對應的IP地址發送請求消息

UAS的路由機制--應答消息根據Via頭域的值與沿着請求消息相反的路徑返回，在不要求代理轉發請求時，應答消息直接發送給請求消息的Contact頭域指示的UAC。

Proxy的路由機制--對請求消息的路由策略，根據Request-URI頭域的值進行路由，根據Route頭域的值進行路由；對應答消息的路由策略，根據Via頭域的內容進行轉發。

i）SIP的呼叫/對話/會話/事務：

Call——呼叫：在對等SIP UA之間創建的聯繫，由Call-ID惟一標識

Dialog——對話：在兩個UA之間保持必定時間的對等SIP關係，由SIP消息（如對INVITE的2xx響應）創建，由Call-ID（呼叫標識）、local tag（本地標籤）和 remote tag（遠端標籤）共同標識。

Session——會話：在對等參與者之間創建的媒體流鏈接。在使用SDP進行會話描述時，會話由SDP用戶名、session id、網絡類型、地址類型以及源域的地址元素共同定義。

SIP Transaction——SIP事務：發生在一個客戶和一個服務器之間，包括從客戶發出一個請求到服務器回送終結響應之間的全部消息。

事務是一個垂直的概念，描述了SIP實體在事務層應完成的功能（對話則描述了對等UA之間的交互關係，一個對話每每須要經過多個事務來完成）事務只存在於UA和有狀態的Proxy中。事務經過維護有限狀態機來提供相應的功能，SIP定義了四個事務狀態機。

• INVITE CT
• Non-INVITE CT
• INVITE ST
• Non-INVITE-ST

每一個事務狀態機有自身的定時器、重傳規則、過濾規則和終止規則。

g）SIP典型流程

用戶註冊流程：

 
直接呼叫控制流程：

代理呼叫控制流程：

 

重定向呼叫控制流程：

第三方呼叫控制模型：

k）SIP在軟交換網絡中的應用

l）SIP的擴展

SIP方法擴展
INFO
UPDATE、MESSAGE
SUBSCRIBE/NOTIFY
REFER
PRACK
PUBLISH
……
SIP消息頭域和參數擴展
refered-by
Refer-to
……
SIP消息體擴展
XML消息體
Multipart消息體
ISUP消息體

3.SIP-T/SIP-I/BICC協議

1）簡介：

SIP-T--Session Initiation Protocol for Telephones，SIP協議針對電信業務的擴展，RFC337二、RFC3398。

SIP-I--SIP with Encapsulated ISUP，由ITU-T制定，是SS7 ISUP與SIP的互通協議，Q.1912。

2）目的：

使基於SIP的軟交換網絡可以與傳統電信網絡互通，使SIP網絡橋接PSTN網絡時可以透明傳遞ISUP消息。

3）內容：

制定了詳細的SIP消息與ISUP消息的映射，保證ISUP信令的透明傳遞，經過 「封裝」 的方法實現。

4）兩者區別：

SIP-T協議：制定了基本的SIP-ISUP映射規則與映射方法，描述簡單，易於理解，但可實現性差，不易操做。

SIP-I協議：繼承了SIP-T協議的規則與方法，進一步嚴格規範了消息與參數的映射，描述複雜，可操做性好，可實現性強，擴展了對補充業務的描述已經考慮了3GPP的相關內容。

5）SIP 網絡與PSTN網絡互通：

SIP-T/SIP-I協議用於指導軟交換完成SIP-ISUP的映射。

參考點A：ISUP over SIGTRAN
參考點B：Megaco/H.248
參考點D：SIP-T/SIP-T

SIP-T/SIP-I用於指導軟交換之間的交互，以透明傳遞ISUP消息。

6）BICC協議

BICC協議由ITU-T SG11定義提供承載無關的呼叫控制功能，與IETF的SIP協議相對應。

BICC協議基於ISUP標準（Q.761-765），並對其進行了加強，以支持分組網承載信息的傳送。承載信息採用BICC的APM機制

BICC CS1支持基於ATM承載上的窄帶業務的提供。BICC CS2進行了進一步的加強，能夠支持基於IP的承載信息的傳送。

BICC呼叫控制流程舉例：