SIP (Session Initiation Protocol) 協議

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:[e-mail] SIP/2.0 
Via: SIP/2.0/TLS client.ANC.com:5061;branch=z9hG4bK74bf9 
Max-Forwards: 70 
From: Alice<sips:[e-mail]>;tag=1234567 
To: Bob<sips:[e-mail]>
Call-ID: 12345601@192.168.2.1  
CSeq: 1 INVITE 
Contact: <sips:[e-mail]> 
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 是臨時回復，其它的是最終回復.

響應碼	Function & Description
1xx	Provisional/Informational Responses 信息響應用來顯示呼叫的進度. 通常響應是端到端的(除了 100 Trying).
2xx	Success Responses 這類響應表明請求已經被收到.
3xx	Redirect Responses 通常這類響應由重定向服務器發送，來響應INVITE. 它們也被稱為重定向類響應.
4xx	Request Failure Responses 由於客戶端的錯誤，服務器響應表明請求不能被滿足.
5xx	Server Failure Response 這類響應表明Server端遇到錯誤無法完成請求的內容.
6xx	Global Failure Response 這類響應表明請求在任何地方都無法得到回應，都會失敗.

SIP - Headers

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

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

SIP Headers - 緊湊形式

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

Header	Compact Form
To	T
Via	V
Call-ID	I
Contact	M
From	F
Subject	S
Content-Length	I

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
e=[e-mail](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:[e-mail]> 
From: Tom <sip:[e-mail]>;tag = 72d65a24 
Call-ID: 4e719d1c1fc9000803630373300@172.22.1.102 
CSeq: 1 REGISTER 
Contact: <sip:Tom@172.22.1.102: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:[e-mail]> 
From: Tom <sip:[e-mail]>;tag = 45375 
Call-ID:87nr43i@172.22.1.102 
CSeq: 6421 REGISTER 
Contact: <sip:[e-mail]> 
Content-Length: 0

第一個 INVITE 將被發送到 sip:registrar2.in； 第二個 INVITE 將被發送到 sip: sip:[e-mail]， 將被轉發到 sip:Tom@172.22.1.102. 它到達Tom並允許建立會話. 兩個注冊都需要定期刷新.

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

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

• Tom發現一個新的網絡,

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

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

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

re-INVITE如下：

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

To: <sip:[e-mail]> 

From: sip:[e-mail];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:[e-mail] 有一個語音信箱系統使用 sip:voicemail.tutorialspoint.com 提供語音信箱，INVITE的Request-URI 當它轉發到語音信箱服務器時顯示為−

sip:voicemail.tutorialspoint.com;target = sip:[e-mail];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:[e-mail]) 是SIP電話，Jerry使用一個全球電話號碼 [phone].

SIP 到 PSTN 通過網關

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

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

• 首先，(Tom) SIP電話撥打全球號碼 [phone]到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).