Session Initiation Protocol 介紹

SIP是VoIP技術最常使用的協議，它是一種應用程式層協議，可與其他應用程式層協議配合使用，以控制Internet上的多媒體通信會話，

VoIP 技術

開始之前先對VoIP做些了解.

• VoIP是一項允許您通過Internet傳遞語音和多媒體（視頻，圖片）內容的技術，這是利用Internet的可用性隨時隨地進行通信的最便宜的方法之一，

• 其優點包括

  • 便宜

  • 可移植性

  • 靈活性

  • 視頻會議

• 對于VoIP通話，您所需要的只是一臺具有Internet連接的計算機/筆記本電腦/移動電話，下圖描述了如何進行VoIP呼叫

SIP – 總覽

以下是SIP的幾點介紹

• SIP是一種信令協議，用于創建，修改和終止多媒體會話，會話僅僅是兩個端點之間的通話，這個端點可以是智能手機，便攜式計算機或任何可以接收和發送多媒體內容的設備，

• SIP標準檔案為RFC3261.

• SIP基于客戶端-服務器架構，url類似于HTTP協議，文本編碼和頭部型別與SMTP協議類似.

• SIP使用SDP (Session Description Protocol)協議描述會話，使用RTP (Real Time Transport Protocol)協議傳輸音視頻資料.

• SIP也可以被用作單播多播會話.

• SIP其他方面的應用包括檔案傳輸，即時訊息，視頻會議，在線游戲，流媒體分發等.

SIP的網路層次

SIP是一個應用層協議. 它是一種簡單的網路信令協議，創建中斷一個或多個會話. SIP被設計為獨立于基礎的傳輸協議之上，所以它既可以基于TCP，也可以基于UDP運行.

下圖描述了SIP在通用方案中的位置:

通常，SIP協議用于兩個或多個端點之間的網路電話和多媒體分發，一如，一個人可以使用SIP向另一個人發起電話呼叫，或者某個人可以與許多參與者簡歷電話會議，

SIP協議被設計的非常簡單，僅有有限個命令集，它是基于文本的協議，因此任何會話中的參與者都可以閱讀SIP訊息.

SIP網路元素

以下幾種網路元素構成了SIP網路體系.SIP中每一種網路元素都由SIP URI (Uniform Resource Identifier) 地址所標識.

• User Agent
• Proxy Server
• Registrar Server
• Redirect Server
• Location Server

User Agent

它是端點，SIP網路中最重要的元素之一. 端點可以邀請，修改，中斷一次會話. UA是SIP中最智能的設備或網路元素. 它可以是softphone, mobile, 或者是 laptop.

UA在邏輯上被分為兩部分:

• User Agent Client (UAC) ? 發送請求接受回應的設備.

• User Agent Server (UAS) ? 接收請求做出回應的設備.

SIP基于C/S架構，呼叫著的電話充當客戶端，被呼叫的電話充當服務端.

Proxy Server

將一個UA的請求轉發給其他用戶的設備.

• 扮演了類似于路由器的角色.

• 具有一定的智能可以理解SIP請求，并借助URI提前發送.

• 位于兩個UA之間.

• UA之間最多可以有70個代理server.

有兩種典型的代理server

• 無狀態代理服務器 ? 僅僅轉發收到的訊息，不存盤任何呼叫和事務方面的資訊.

• Stateful Proxy Server ? 這種型別的代理服務器會跟蹤收到的每個請求和回應，并在將來需要時可以使用它，如果沒有及時的回應，它可以重新發送請求.

Registrar Server

注冊服務器從UA接收注冊請求. 幫助用戶進行網路驗證. 它將URI和用戶的位置存盤在資料庫中以幫助同一域中的其他SIP服務器.

下圖是SIP注冊的流程.

呼叫者想在TMC域中注冊，因此發送REGISTER請求給TMC’s服務器，服務器回傳200 OK回應授權給客戶端.

Redirect Server

重定向服務器接收到請求，然后從注冊服務商創建的資料庫中查找預期的收件人.

重定向服務器使用資料庫獲取位置資訊并以3xx回應用戶.

Location Server

本地服務器向代理服務器、重定向服務器提供有關呼叫者可能的位置資訊.

僅有代理服務器或重定向服務器可以聯系本地服務器.

下圖描繪了每個網路元素在建立會話中所扮演的角色.

SIP – 系統架構

SIP被構造為分層協議，這意味著它的行為是根據一組相當獨立的處理階段來描述的，每個階段之間只有一個松散的耦合.

• 最底層是SIP的語法和編碼. 它的編碼被指定使用增強型 Backus-Naur Form grammar (BNF).

• 第二層是傳輸層，它定義了Client/Server如何發送接收訊息. 所有的SIP元素都包含傳輸層

• 事務層. 事務是Client向Server發送的所有請求以及Server的所有回應. 任何UAC任務的完成都以事務的形式發生. 無狀態的代理沒有事務層.

• 最上層成為事務用戶. 每個SIP物體除了Stateless proxies, 都是一個事務用戶.

SIP - 基本通話流程

下圖是一個SIP session的通話流程圖.

解釋如下

• 一個 INVITE 請求開始一個會話.

• 代理服務器馬上發送 100 Trying 回應給Alice阻止 INVITE request的重傳.

• 代理服務器從本地服務器查詢Bob的地址，獲取地址后，它將進一步轉發 INVITE 請求.

• 此后，由Bob產生的180 Ringing (臨時回應) 回傳給 Alice.

• 200 OK 回應通常在Bob拿起電話不久后就會產生.

• Alice收到 200 OK. 回傳給Bob一個 ACK.

• 同時會話被創建，RTP資料包開始在兩端流動.

• 會話結束后，任何參與者都可以發送 BYE 請求來終止會話.

• BYE 直接從Alice到Bob，繞過代理服務器.

• 最后，Bob發送  200 OK 回應 BYE ，中斷會話.

• 以上基本通話流程，包含3個事務（1,2,3）.

完整的通話（從 INVITE 到 200 OK）被稱作 對話.

SIP 梯形

下圖顯示代理如何幫助連接兩個用戶.

圖片中顯示的拓撲結構被稱為SIP梯形

• 當呼叫方發起呼叫時，一個 INVITE 訊息被發送給代理服務器. 收到 INVITE 后，代理服務器在DNS服務器的幫助下決議被叫者的地址.

• 獲得下一跳的路由后，Proxy 1, 也被稱為 outbound 出站代理服務器轉發 INVITE 請求到 Proxy 2  inbound 入站代理服務器給被叫者.

• inbound 代理服務器聯系本地服務器獲取被叫者注冊過的地址資訊 .

• 獲得地址資訊后，轉發呼叫到目的地.

• 一旦用戶UA獲得他們的地址，他們就可以繞過呼叫，直接傳遞會話.

SIP - 訊息傳遞

SIP訊息分為兩類 請求 和 回應.

• 請求的開始行包含一個定義請求的方法，以及一個將請求發往何處的URI.

• 同樣，回應中也包含一個回應碼.

請求Method

SIP請求是用于建立通信的代碼，為了補充它們，通常有一些SIP回應指示請求是成功還是失敗，

這些方法使SIP訊息可以運行起來.

• METHODS 可以被視為SIP請求，因為它們請求由另一個用戶代理或服務器采取的特定操作.

• METHODS 被分為兩類?

  • 核心方法

  • 擴展方法

核心方法

以下6個核心方法將被討論.

INVITE

INVITE 用來啟動一次會話. 換句話說, 一個 INVITE 方法被用來在UA之間建立媒體會話.

• INVITE 可以在 訊息體 內包含呼叫者的媒體資訊.

• 會話建立的標志是: INVITE 收到了成功的回應(2xx) 或 發送出去一個 ACK.

• 一個成功的 INVITE 請求，在兩個UA之間建立了一個 dialog （對話），直到發送 BYE 中斷會話.

• 在一個建立的dialog中再次發送 INVITE 被稱作 re-INVITE.

• Re-INVITE 被用來改變會話的特征或重繪dialog狀態.

INVITE 舉例

下面的代碼顯示了INVITE的使用.

INVITE sips:[email protected] SIP/2.0 
Via: SIP/2.0/TLS client.ANC.com:5061;branch=z9hG4bK74bf9 
Max-Forwards: 70 
From: Alice<sips:[email protected]>;tag=1234567 
To: Bob<sips:[email protected]>
Call-ID: [email protected]  
CSeq: 1 INVITE 
Contact: <sips:[email protected]> 
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
Supported: replaces 
Content-Type: application/sdp 
Content-Length: ...  

v=0 
o=Alice 2890844526 2890844526 IN IP4 client.ANC.com 
s=Session SDP 
c=IN IP4 client.ANC.com 
t=3034423619 0 
m=audio 49170 RTP/AVP 0 
a=rtpmap:0 PCMU/8000  

BYE

BYE 用來中斷一個建立的會話. 這個請求可以被呼叫者或被呼叫者發送.

• 代理服務器不能發送.

• BYE 請求通常跳過代理服務器，端到端發送.

• BYE 不能發送給一個等待 INVITE 或 一個未建立的會話.

REGISTER

REGISTER 方法是UA用來發送注冊請求. 這個請求是UA發給 注冊服務器.

• REGISTER 請求可以轉發或代理知道到達指定域的權威注冊商為止.

• 它在 To 欄位中攜帶正在被注冊的用戶的 AOR (Address of Record).

• REGISTER 請求包含時間周期 (3600sec).

• 一個UA可以代表另一個UA發送 REGISTER 請求. 這就是所謂的 第三方注冊. 

CANCEL

CANCEL 被用來終止未建立的會話. UA使用這個請求取消先前發起的掛起的呼叫嘗試.

• 它可以被UA或代理服務器發送.

• CANCEL 是一個逐跳的請求，它通過UA之間的服務設備接收一個有狀態設備的回應.

ACK

ACK 是對 INVITE方法的最后回應. ACK 可能包含SDP訊息體如果它在INVITE中不可用.

• ACK不能用來修改已經在初始  INVITE 中發送的媒體描述.

• 有狀態的代理接收到ACK必須確定是否這個ACK應該被轉發另一個代理或UA.

• 對于 2xx 的回應, ACK 是端到端的，對于其他最終回應，有狀態的代理是逐跳作業的.

OPTIONS

OPTIONS 方法被用來查詢UA或代理服務器的功能. 回應列出可用的功能. 代理不會生成 OPTIONS 請求.

擴展方法

SUBSCRIBE

SUBSCRIBE 被用來建立訂閱，以獲取關于特定事件的通知i.

• 它包含一個 Expires 頭指示訂閱的持續時間.

• 時間過期后自動終止訂閱.

• 訂閱在UA之間建立會話.

• 你可以在過期之前發送另一個 SUBSCRIBE .

• 一個 200 OK 從用戶那里收到.

• 用戶和已發送另一個過期值為0的 SUBSCRIBE 取消訂閱.

NOTIFY

UA使用NOTIFY來獲取特定事件的發生. 通常，當訂閱者和通知程式之間存在訂閱時，將在觸發通知.

• 每一個 NOTIFY，當被通知人收到后，會回復 200 OK.

• NOTIFY 包含一個 Event 頭來指示事件，一個 subscriptionstate 頭指示當前狀態.

• 一個 NOTIFY 在訂閱的開始和中斷時發送.

PUBLISH

PUBLISH 被用來發送事件狀態資訊給服務器.

• PUBLISH 非常有用當有多個事件資訊源的時候.

• PUBLISH 與 NOTIFY 非常類似, 只是不再對話中發送.

• PUBLISH 必須包含 Expires 欄位和 Min-Expires 欄位.

REFER

REFER 用來被一個UA參考另一個UA來訪問對話的URI.

• REFER 必須包含 Refer-To 域. 

• REFER 的發送可以在對話期間也可以不在.

• 202 Accepted 將會觸發 REFER 請求，表明其他UA已經同意了參考.

INFO

INFO 被一個UA發送信令資訊給另一個UA與它建立媒體會話.

• 這是一個端到端的請求.

• 代理設備會始終轉發 INFO 請求.

UPDATE

UPDATE 被用來修改會話狀態當會話未建立時，用戶可以使用UPDATE 修改編碼.

如果會話已經建立，使用 re-Invite 改變或更新會話.

PRACK

PRACK 用于確認收到了可靠的臨時回復(1XX).

• 通常 當client收到一個包含RSeq的可靠序列號和支持的:100rel 報頭.

• PRACK 包含 (RSeq + CSeq) 值 rack 頭.

• PRACK 方法適用于所有的臨時回應，除了從未可靠的傳輸中收到 100 Trying 回應.

• PRACK 可以包含一個訊息體，用來 offer/answer 交換.

MESSAGE

使用SIP發送即時訊息. 一個IM通常包含的內容比較短.

• MESSAGE 的發送可以在對話期間也可以不在.

• MESSAGE 內容在訊息體中攜帶，作為一個 MIME 附件.

• 200 OK 回應收到后，表明訊息已經發送到它的目的地.

SIP - 回應碼

SIP 回應訊息通常由UAS或SIP server發出，它可以是一個正式的確認，防止UAC重傳請求.

• 回應可能包含一些UAC需要的報頭資訊.

• SIP 有六類回應.

• 1xx t到 5xx 借用于HTTTP，6xx 由 SIP 引入.

• 1xx 是臨時回復，其它的是最侄訓復.

SIP - Headers

報頭是SIP訊息的組件，傳達該訊息的資訊. 它是一組結構化的報頭序列.

SIP 報頭大部分情況下跟HTTP報頭采用相同的規則. 報頭以 NAME:VALUE的形式定義，NAME用來表明報頭欄位名，VALUE是包含資訊的令牌. 

SIP Headers - 緊湊形式

許多常見的SIP報頭欄位都有一個緊湊的形式，其中報頭欄位名稱由單個小寫字符表示. 下面給出一些例子 -

SIP Header Format

下圖顯示了典型SIP報頭的結構.

SIP - Session Description Protocol

SDP 會話描述協議. 它以一種參與者可以理解的形式來描述多媒體會話. 根據此描述，一方決定是否加入，何時加入，如何加入會議.

• 會議的所有者，通過網路，發送包含會話描述的多播訊息，例如：所有者的名稱、會話的名稱、編碼、時間等. 根據這些資訊，接收者決定是否參與會議.

• SDP 通常包含在SIP的BODY體內.

• SDP 協議檔案 RFC 2327. An SDP message is composed of a series of lines, called fields, whose names are abbreviated by a single lower-case letter, and are in a required order to simplify parsing.

SDP使用的原因

目的是在多媒體會話中傳遞有關媒體流的資訊，幫助參與者加入或收集特定會話的資訊.

• SDP 是一種簡短的結構化文本描述.

• 它傳達了會話的名稱和目的、媒體、協議、編解碼器格式、時間和傳輸資訊.

• 一個試探性參與者檢查這些資訊，決定是否加入會話，如何以及什么時候加入會話.

• 該格式以<type> = <value>形式展示, <type> 定義了一個唯一的會話引數，<value> 為引數提供了一個特定的值.

• SDP訊息的通用格式為: x = parameter1 parameter2 ... parameterN

• 每行以一個小寫字母開始，例如， x.  字母和=之間沒有空格，每個引數之間只有一個空格. 每個欄位有一定數量的引數.

Session Description Parameters

會話描述(* 表示可選)

• v=(協議版本)
• o=(所有者/創建者會話識別符號)
• s=(會話名)
• i=*(會話資訊)
• u=*(URI)
• e=*(email地址)
• p=*(電話號碼)
• c=*(連接資訊 - 如果包含在所有的媒體中則不需要)
• b=*(帶寬資訊)
• z=*(時區調整)
• k=*(加密秘鑰)
• a=*(零或多個會話屬性行)

Protocol Version

v= 欄位包含SDP版本號. 由于當前SDP版本是0，一個有效的SDP訊息總是以v=0開始.

Origin

o= 欄位包含會話參與者和會話識別符號資訊. 次欄位用于唯一表示會話.

• 次欄位包含 ?

  o=<用戶名><會話id><版本><網路型別><地址型別>

• <用戶名>包含發起者的登錄名或主機名.

• <會話id>Network Time Protocol (NTP) 時間戳或一個隨機確保唯一性.

• <版本>每次會話的更改這個數字欄位都會增加，建議使用NTP時間戳.

• <網路型別>總是 IN . <地址型別> IP4 或 IP6 對應 IPv4 或 IPv6 地址，既可以是點分十進制或全限定的主機名.

Session Name and Information

s= 欄位包含了會話的名稱. 它可以包含任何大于零個數量的字符. i= 欄位包含會話的資訊. 可以包含任意數量字符.

URI

u= 欄位包含一個唯一資源定位符 (URI) 提供更多會話的資訊.

E-Mail Address 和 Phone Number

e= 包含一個e-mail 會話主機的地址. p= 包含一個電話號碼.

Connection Data

c= 包含媒體連接資訊.

• c =<network-type><address-type><connection-address>.

• <connection-address>發送媒體資料包的IP地址或主機， 可以是單播或多播.

• 如果是多播， <connection-address>=多播地址/ttl/地址數量

ttl 生存時長的值， 從多播基地址開始包含多少連續的多播地址.

Bandwidth

b= 包含需要的帶寬資訊. 格式為 b=modifier:bandwidth ? value

Time, Repeat Times, and Time Zones

t= 欄位包含會話開始和結束時間. t=start-time stop-time

r= 重復時間資訊， 包含 NTP 或 天(d)， 時(h)， 分(m).

z= 時區調整，時區偏移量的資訊. 

Media Announcements

m= 包含媒體會話資訊 m= media port transport format-list

• media 可以是 audio, video, text, application, message, image, or control.

• port 引數表示埠號.

• transport 引數表示傳輸協議 RTP 等.

• format-list 包含更多媒體的資訊. 通常包含媒體載荷型別 RTP audio/video .

Example:
m = audio 49430 RTP/AVP 0 6 8 99

Attributes

a= 包含媒體會話屬性. 它被用來擴展SDP 以提供更多媒體資訊，如果SDP user不能完全理解，可以被忽略. 列出的每一個媒體型別可以包含一個或多個次欄位.

Attributes 可以是:

• 會話級別
• 媒體級別

會話級別，它被列在SDP媒體行的第一列. 該屬性應用于下面的所有媒體行.

媒體級別，它被列在媒體行之后. 該屬性僅應用于次特定的媒體流.

SDP 可以同時包含會話級別和每一級別屬性. 如果相同的屬性同時出現， 對特定的流媒體級別屬性會覆寫會話級別的屬性. 連接資料欄位可以是媒體級別或會話級別.

SDP 示例

摘自 RFC 2327 ?

v=0
o=mhandley2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
[email protected](Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416udp wb
a=orient:portrait

SIP - Offer/Answer 模式

RFC 3264 提供了SIP使用SDP offer/answer. SIP默認的訊息體型別為application/sdp.

• 主叫方在SDP中列出他們可接受的媒體，通常在一個INVITE or ACK訊息中.

• 被叫方在 INVITE 的200 OK回應中，列出了他們實作的媒體型別.

一個典型的SIP 使用的SDP包含了一下欄位：version, origin, subject, time, connection, 和一個或多個 media 和 attribute.

• SIP不使用 subject 和 time 欄位，但是為了兼容還是加進去了.

• 在SDP標準中，subject欄位是必須項，必須包含至少一個字符，如果沒有內容，建議使用 s=-.

• time 欄位通常被設定為 t = 00. SIP 使用 connection, media, 和 attribute 欄位在UAs之間建立會話.

• origin 欄位對于SIP來時使用有限.

• session-id 貫穿整個SIP會話中保持不變.

• SDP每次改變時，version 都會增加. 如果SDP發送的與前一次的相同，版本保持不變.

• 由于要使用的媒體會話型別和編解碼器是連接協商的一部分，所以SIP可以使用SDP來指定多種備選媒體型別，并有選擇地接受或拒絕這些媒體型別.

offer/answer 規范，RFC 3264建議一個 attribute 包含一個 a=rtpmap: 被每一個media使用. SDP回應中，將對應媒體欄位的埠號設定為0，來拒絕媒體流的回應.

Example

下面的例子里，主叫Tesla 想要建立一個音頻和視頻的通話包含兩個可用的音頻編碼和一個視頻編碼

v=0 
o=John 0844526 2890844526 IN IP4 172.22.1.102  
s=- 
c=IN IP4 172.22.1.102 
t=0 0 
m=audio 6000 RTP/AVP 97 98 
a=rtpmap:97 AMR/16000/1 
a=rtpmap:98 AMR-WB/8000/1 
m=video 49172 RTP/AVP 32 
a=rtpmap:32 MPV/90000 

編解碼器型別97、98，為RTP/AVP 所規定

 被叫 Marry ，為第一個media選擇了第二種編解碼 ，拒絕了第二種媒體形式，僅僅希望AMR會話.

v=0 
o=Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s=- 
c=IN IP4 200.201.202.203 
t=0 0 
m=audio 60000 RTP/AVP 8 
a=rtpmap:97 AMR/16000 
m=video 0 RTP/AVP 32 

如果不接受只有音頻的通話，會在發送完ACK后發送BYE取消通話.否則，音頻通話將會建立，隨后通過RTP報文進行資料互動.

如本例所示，除非保持媒體域的順序不變，否則主叫方無法確定哪個媒體會話被接受，哪個取消.

下面總結了 offer/answer 的規則.

Offer規定

一個SDP offer 必須包含所需要的SDP欄位(包括 v=, o=, s=, c=, t=). 這些是必填項.

通常還包括 media 欄位 (m=) 但不是必須的. 媒體行按照優先順序列出了所有的編解碼型別. 唯一的例外是，如果端點支持大量的編解碼型別，則應該列出最可能被接受或最首選的編解碼型別. 不同的媒體型別，包括音頻，視頻，文本，MSRP，BFCP等等.

Answer規定

SDP 回應一個 offer 必須按照以下規則來構造

• answer 必須與有相同數量和順序的編號行 m= .

• 通過設定埠號為0來拒絕單個媒體流.

• 發送一個非0埠號，流就會被接受.

• 列出的每一種媒體型別的載荷，必須是在 offer 中已經列出了得.

• 對于動態型別載荷，相同的動態型別載荷號碼不需要被用在每個方向，通常僅選擇一種型別.

修改會話的規定

任何一方都可以發起另一個 offer/answer 交換來修改會話

• origin (o=) 行版本號，必須和上一次發送的相同，這表明這個SDP和前一個是相同的，或者被增加一個，表明新的SDP必須被決議.

• offer 必須包含所有存在的媒體行，它們必須以相同的順序發送.

• 增加的媒體流，可以加載m= 行串列末尾.

• 一個已經存在的媒體流，可以通過設定埠號為0，來洗掉. 這條媒體行必須保留在SDP和所有以后進行的 offer/anser交換會話中.

呼叫保持

通話中一方可以暫時保持另一方. 這需要發送一個INVITE，與原來 INVITE 相同的SDP， 且帶有 a=sendonly 屬性.

通過發送另一個帶有 a=sendrecv 的INVITE 使通話變得活躍起來.

SIP - 移動性

Personal mobility，個人移動性是在多個設備之間擁有恒定識別符號的能力. SIP支持使用REGISTER 方法，實作基本的個人移動性，這種方法允許移動設備更改其IP地址和互聯網連接點，但仍然能夠接收來電.

SIP 也支持服務移動性 - 當移動時保持相同服務的能力

SIP 交接時的移動性

設備通過簡單的sip注冊將其聯系的URI與記錄的地址系結，根據設備的IP地址，注冊授權此資訊在sip網路中自動更新.

在切換期間，用戶代理在不同的運營商之間路由，它必須再次注冊一個聯系人作為AOR與另一個服務提供商.

例如，UA臨時接收了一個帶有新的服務提供商新的SIP URI，UA執行兩次注冊

• 第一次注冊是在新的服務運營商那里進行的，該運營商將設備的聯系人URI與新的服務提供商的AOR URI系結.

• 第二次 REGISTER 請求被路由回原來的服務提供商，并提供新服務提供商的AOR作為聯系URI.

當請求進入原始服務提供商的網路時，INVITE被重定向到新的服務提供商，然后該服務提供商將通話路由到用戶.

對于第一次注冊，包含設備URI

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 72d65a24 
Call-ID: [email protected] 
CSeq: 1 REGISTER 
Contact: <sip:[email protected]:5060> 
Expires: 600000 
Content-Length: 0

第二個帶有漫游URI的注冊訊息

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 45375 
Call-ID:[email protected] 
CSeq: 6421 REGISTER 
Contact: <sip:[email protected]> 
Content-Length: 0

第一個 INVITE 將被發送到 sip:registrar2.in； 第二個 INVITE 將被發送到 sip: sip:[email protected]， 將被轉發到 sip:[email protected]. 它到達Tom并允許建立會話. 兩個注冊都需要定期重繪.

通話時的移動性(re-Invite)

用戶代理可以在會話期間改變它的IP地址，因為它從一個網路交換到另一個網路.  基本SIP支持此場景，一個對話期間re-INVITE可以用于更新聯系人URI和更改SDP中的媒體資訊.

• Tom發現一個新的網路,

• 使用DHCP請求一個新的IP地址

• 執行re-INVITE，讓信令和媒體流使用新的IP地址.

如果UA可以從兩個網路接收媒體流，中斷可以忽略不計. 如果不是這樣，一些媒體包可能會丟失，導致通話輕微中斷.

re-INVITE如下：

INVITE sip:[email protected] SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:[email protected]> 

From: sip:[email protected];tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v=0
o=PPT 40467 40468 IN IP4 192.168.2.1 
s=- 
c=IN IP4 192.168.2.1 
b=AS:49 
t=0 0 
b=RR:0 
b=RS:0 
a=rtpmap:97 AMR/8000/1 
m=audio 6000 RTP/AVP 96 
a=fmtp:102 0-15 
a=ptime:20 
a=maxptime:240

中間呼叫的移動性(With replace Header)

在中途移動中，真實的路由集合(SIP訊息必經過的SIP代理集合)必須改變. 這時我們不能使用re-INVITE.

例如，如果一個NAT需要一個代理，然后Contact URI必須被修改 — 一個新的對話必須被創建. 因此，必須發送一個新的INVITE使用Replaces header標識現有會話.

Note ? 假設A和B通話，如果A獲得另一個INVITE(來自C的)帶有Replaceheader(應該匹配現有對話)，那么A必須接受INVITE，同時中斷和B的會話，傳輸所有資源到新建立的對話.

• Tom和Jerry的通話包括了老的VisitedProxy服務器.

• 新的通話使用了新的代理服務器的無線網路.

• Tom發送一個Replaces INVITE請求，創建一個新的通話使用新的VisitedProxyServer而不是舊的.

• 當Jerry接受了INVITE，BYE自動被發送中斷路由到老的代理服務器的通話，使其不再參與會話.

• 生成的媒體會話使用Tom發送的INVITE中SDP的新IP地址建立.

服務遷移

SIP服務可以被任何代理或UAs提供. 跟隨個人移動性提供服務移動性是個挑戰，除非用戶的設備提供了相同的服務.

SIP基于internet可以很容易支持服務移動.當連接到互聯網，一個UA 配置使用印度的的代理服務器時，在歐洲漫游時任然可以使用這些代理. 它對媒體會話的質量沒有任何影響，因為媒體總是在兩個UAs之間流動而不經過代理服務器. 只有當終端連接到互聯網上時，終端駐留服務才可使用. 如果終端暫時失去了它的Internet連接，那么終端服務(如在終端中實作的呼叫前轉服務)將失敗. 因此一些服務在網路中使用SIP代理服務器實作.

SIP - Forking

有時一個代理服務器將一個SIP呼叫轉移到多個SIP終端，這個程序被稱為forking. 這是一個呼叫可以同時ring多個終端.

通過SIP forking，可以使你的固話、軟體電話或手機上的SIP電話同時響鈴，允許你很容易的從任何設備接聽電話.

通常，在辦公室，老板不能接電話或離開，SIP forking允許秘書接聽他的分機.

一個有狀態代理使Forking變得可能，當它需要執行和回應它收到的多個呼叫.

有兩種型別的forking ?

• 平行Forking
• 順序Forking

平行Forking

在這個場景中，代理服務器將會同時fork INVITE 到兩個設備(UA2，UA3). 兩個設備將同時產生180Ringing，任何接到電話的人將會產生200 OK. 先到達發起者的回應，將會和這個設備建立會話，另一個回應將會觸發CANCLE.

如果發起者同時接收到兩個回應，根據q-value轉發回應.

順序Forking

在這個場景中，代理服務器將會fork INVITE 到一個設備，如果這個設備此時不可達或繁忙，然后代理將會fork它到另一個設備.

分支- ID and Tag

分支IDs幫助代理匹配回應到forked請求. 沒有分支IDs，一個代理服務器就不能理解forked回應. 分支-id  在Via頭部中提供.

UAC Tags被用于區分多個不同的UAS最終回應. 一個UAS不能決議是否請求已經被forked，因此需要加一個tag.

代理也可以增加tags，如果它生成一個最終的回應，他們從不插入一個tags到他們轉發的請求或回應中.

單個請求也可以被多個代理服務器forked. fork的代理應該增加它自己的唯一IDs到它創建的分支.

Call leg 和 Call ID

call leg指的是兩個UA之間一對一的信令關系. call ID是SIP訊息里攜帶的唯一指代這次通話的標識. 一次通話是call legs的集合.

一個UAC以發送INVITE開始. 由于forking，它可能收到多個200 OK從不同的UAs. 在同一通話中每個對應一個不同的call-leg.

一次通話是一組call legs. 一個call leg指的是UAs之間端到端的連接.

call leg的CSeq空間在兩個方向上是獨立的. 在單個方向中，在每個事務上序列號是遞增的.

語音信箱

對企業用戶來說語音郵件變得非常普遍. 它是一個電話應用. 當被叫不可用或無法接電話時，PBX將會發出語音訊息通知給被叫.

如果被叫號碼不可達，UA會得到一個3xx的回應或重定向到語音信箱服務器. 然而，需要某種SIP擴展來指示語音信箱系統哪個郵箱被使用--即哪個歡迎語被播放，語音訊息被記錄到哪里.

有兩種方式可以達成此目的 -

• 使用SIP頭欄位擴展

• 使用Request-URI通知這個資訊

假設 sip:[email protected] 有一個語音信箱系統使用 sip:voicemail.tutorialspoint.com 提供語音信箱，INVITE的Request-URI 當它轉發到語音信箱服務器時顯示為?

sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486

下圖展示了Request-URI如何攜帶郵箱識別符號和原因(這里是486)：

SIP - 代理和路由

我們知道，代理服務器可以是無狀態的，也可以是有狀態的，在本章中，我們將更多地討論代理服務器和SIP路由.

無狀態代理服務器

無狀態代理服務器只是轉發它接收到的訊息，這種服務器不存盤通話或事務的任何資訊.

• 無狀態代理在SIP請求被轉發后就會忘記它.
• 通過無狀態代理，事務將變得很快.

有狀態代理服務器

有狀態代理服務器跟蹤它接收到的每個請求和響. 如果需要，它可以在將來使用存盤的資訊. 如果沒有收到對方的回應，它可以重新發送請求.

• 有狀態代理在請求被轉發后會記住請求，因此它們可以將其用于提前路由. 有狀態代理維護事務狀態，事務意味著事務狀態，而不是通話狀態.

• 使用有狀態代理的事務不如無狀態代理快.

• 有狀態的代理如果需要可以fork和重傳.(例如：呼叫轉發忙碌).

Via 和 Record-route

Record-Route

Record-Route頭部通過代理插入到請求中，這些代理希望進入針對相同call-id的后續請求的路徑中. 然后，用戶代理使用它來路由后續請求.

Via

Via 頭由服務器插入到請求中以檢測回圈和幫助回應找到回傳客戶端的路徑. 這只對回應到達它們的目的地有幫助.

• UA發送請求時，在Via頭中生成和添加它自己的地址.

• 代理轉發請求時添加自己的地址到Via header地址串列頂部.

• 代理或UA對一個請求生成一個回應，從請求里拷貝所有Via header欄位按順序放入回應中，然后發送回應到Via header指定的地址.

• 代理收到回應，檢查Via header欄位然后匹配自己的地址. 如果匹配失敗，回應會被丟棄.

• 最上面的Via header 會被移除，回應轉發到下一個Via header指定的地址.

Via header包含協議名稱，版本號，傳輸層協議 (SIP/2.0/UDP, SIP/2.0/TCP, etc.)，埠號和引數，例如：received，rport，branch.

• 如果一個UA或代理從不同地址收到一個請求，收到的tag將被加到Via header.

• UAs和代理將分支引數添加到Via header中，它將作為 Request-URI, To, From, Call-ID, CSeq number的hash函式計算.

SIP 到 PSTN

SIP (Softphone) 和 PSTN (Old telephone)是兩種不同的網路說著不同的語言. 因此我們需要一個翻譯器（網關）在這兩個網路之間交流.

讓我們舉個例子來說明SIP電話如何通過PSTN網關將電話呼叫到PSTN的.

在這個例子中，Tom (sip:[email protected]) 是SIP電話，Jerry使用一個全球電話號碼 +91401234567.

SIP 到 PSTN 通過網關

下圖顯示了從SIP通過網關到PSTN.

下面是一步一步的解釋說明.

• 首先，(Tom) SIP電話撥打全球號碼 +91401234567到Jerry. SIP UA將它決議做一個全球號碼同時轉換它到request-uri 使用的DNS中并觸發請求.

• SIP電話發送INVITE直接到網關.

• 網關通過選擇SS7 ISUP中繼向PSTN側下一個電話交換機發起呼叫.

• 從INVITE中撥出的數字映射到ISUP IAM中，由PSTN回傳ISUP address complete message (ACM)，表示中繼已經創建完成.

• 電話產生鈴聲，鈴聲傳到電話開關，網關將ACM映射到183會話進度回應，該回應包含一個SDP協議，該協議表示網關將使用該協議從PSTN橋接音頻.

• 接收到183后，呼叫者的UAC開始接收從網關發送的RTP包，并向呼叫者呈現音頻，這樣他們知道被呼叫者在PSTN中通話進度.

• 被叫應答后，通話結束，電話交換機向網關發送應答訊息(ANM)，.

• 然后網關在兩個方向切斷PSTN音頻連接，并向呼叫者發送一個200 OK回應，由于RTP媒體路徑已經建立，網關183中回復SDP，但對RTP連接沒有改變.

• TUAC發送一個ACK來完成SIP信令交換，由于在ISUP中沒有等價的訊息，網關接收ACK.

• 呼叫者發送BYE到網關終止，網關將BYE映射到ISUP發布訊息(REL)中.

• 網關向BYE發送200OK，然后從PSTN接收RLC.

SIP - 編解碼器

codec，是coder-decoder的縮寫，執行兩種基本的操作 ?

• 首先，它將模擬語音信號轉換成等效的數字形式，以便于方便地傳輸.

• 此后，它將壓縮后的數字信號轉換回其原始模擬形式，以便能夠重新播放.

市場上有許多編解碼器——一些是免費的，而另一些則需要許可，編解碼器的音質不同，帶寬也相應不同.

電話和網關等硬體設備支持幾種不同的編解碼器. 在相互交談時，他們會協商使用哪種編解碼器.

在本章中，我們將討論一些廣泛使用的流行SIP音頻編解碼器.

G.711

G.711是國際電聯于1972年推出的一種用于數字電話的編解碼器，編解碼器有兩個變種:A-Law在歐洲和國際電話線路中使用，u-Law在美國和日本使用，

• G.711使用對數壓縮，將每個16位的樣本壓縮為8位，壓縮比為1:2.

• 一個方向的位元率是64kbit /s，因此通話消耗128kbit /s.

• G.711是PSTN網路使用的相同的編解碼器，因此它提供了最好的語音質. 然而，它比其他編解碼器消耗更多的帶寬.

• 它在有大量可用帶寬的局域網路中作業得最好.

G.729

G.729是一種低帶寬要求的編解碼器，它提供了良好的音頻質量.

• 編解碼器以10毫秒長的幀對音頻進行編碼，給定8 kHz的采樣頻率，10毫秒幀包含80個音頻樣本.

• 編解碼器演算法將每幀編碼為10個位元組，因此在一個方向上得到的位元率為8kbit /s.

• G.729是一個經過許可的編解碼器. 想要使用這種編解碼器的終端用戶應該購買實作它的硬體(可以是VoIP電話或網關).

• G.729的一個常用變體是G.729a. 它與原始的編解碼器是線兼容的，但有較低的CPU要求.

G.723.1

G.723.1是國際電聯宣布的一項競賽的結果，競賽的目的是設計一種可允許在28.8和33kbit /s調制解調器鏈路上通話的編解碼器.

• 我們有G.723.1的兩種變體，它們都是在30毫秒(即240個樣本)的音頻幀上運行，但演算法不同.

• 第一個變體的位元率是6.4 kbit/s，而第二個變體是5.3 kbit/s.

• 這兩種變體的編碼幀分別為24和20位元組.

GSM 06.10

GSM 06.10是為GSM移動網路設計的一種編解碼器. 它也被稱為GSM全速率.

• 這種變體的GSM編解碼器可以免費使用，因此您經常可以在開源VoIP應用程式中找到它.

• 編解碼器對20毫秒長的音頻幀(即160個樣本)進行操作，并將每個幀壓縮為33位元組，因此得到的位元率為13 kbit/s.

SIP - B2BUA

一種背靠背的UA (B2BUA) 是SIP應用程式中的邏輯網路元素. 它是一種SIP UA，它接收SIP請求，然后重新制定請求，并將其作為新請求發送出去.

與代理服務器不同，它維護通話狀態，并且必須參與在它建立的通話上發送的所有請求，B2BUA打破了SIP的端到端本質.

B2BUA – 如何作業?

一個B2BUA代理操作在兩個電話終端，并將兩個通信通道分成兩個call legs. B2BUA 是一個UAC和UAS之間的連接. 它參與了它已經建立的呼叫兩端之間的所有SIP信令. 由于對話的B2BUA可用，服務提供者可能

實作一些增值特性. 在原始的call leg中，B2BUA充當用戶代理服務器(UAS)，并作為用戶代理客戶端(UAC)處理到目的地端的請求，處理端點之間背靠背的信令.

B2BUA維護它掌握的通話完整狀態. B2BUA的每一側作為RFC 3261中指定的標準SIP網路單元操作.

B2BUA方法

B2BUA 提供了以下方法 ?

• Call management (billing, automatic call disconnection, call transfer, etc.)

• Network interworking (perhaps with protocol adaptation)

• Hiding of network internals (private addresses, network topology, etc.)

通常，B2BUAs也在媒體網關中實作，橋接媒體流，以完全控制會話.

B2BUA舉例

許多私有分支交換機(PBX)企業電話系統采用了B2BUA邏輯.

一些防火墻內置了ALG(應用層網關)功能，它允許防火墻授權SIP和媒體流量，同時仍然保持高水平的安全性.

B2BUA的另一種常見型別是會話邊界控制器(SBC).

標籤：其他

上一篇：兩位管理者的對話，或許這個團隊并不適合你

下一篇：資料結構與演算法（四）鏈表（上）