SIP (Session Initiation Protocol) 協議

時間 2021-04-05

標籤 html 算法數據庫安全服務器網絡 session 架構 app less 欄目網站開發简体版

原文原文鏈接

Session Initiation Protocol 介紹

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

VoIP 技術

開始以前先對VoIP作些瞭解.算法

VoIP是一項容許您經過Internet傳遞語音和多媒體（視頻，圖片）內容的技術。這是利用Internet的可用性隨時隨地進行通訊的最便宜的方法之一。數據庫
其優勢包括安全
- 便宜服務器
- 可移植性網絡
- 靈活性session
- 視頻會議架構
對於VoIP通話，您所須要的只是一臺具備Internet鏈接的計算機/筆記本電腦/移動電話。下圖描述瞭如何進行VoIP呼叫app

SIP – 總覽

如下是SIP的幾點介紹less

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:Bob@TMC.com SIP/2.0 
Via: SIP/2.0/TLS client.ANC.com:5061;branch=z9hG4bK74bf9 
Max-Forwards: 70 
From: Alice<sips:Alice@TTP.com>;tag=1234567 
To: Bob<sips:Bob@TMC.com>
Call-ID: 12345601@192.168.2.1  
CSeq: 1 INVITE 
Contact: <sips:Alice@client.ANC.com> 
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 請求能夠轉發或代理知道到達指定域的權威註冊商爲止.
它在 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 被用來創建訂閱，以獲取關於特定事件的通知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=mjh@isi.edu(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

編解碼器類型9七、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:UA1@registrar1.in> 
From: Tom <sip:UA1@registrar1.in>;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:UA1@registrar2.in> 
From: Tom <sip:UA1@registrar2.in>;tag = 45375 
Call-ID:87nr43i@172.22.1.102 
CSeq: 6421 REGISTER 
Contact: <sip:UA1@registrar2.in> 
Content-Length: 0

第一個 INVITE 將被髮送到 sip:registrar2.in；第二個 INVITE 將被髮送到 sip: sip:Tom@registrar2.in，將被轉發到 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:Jerry@TTP.com SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:Harry@TTP.com> 

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

sip:voicemail.tutorialspoint.com;target = sip:Tom@tutorialspoint.com;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:tom@tutorialspoint.com) 是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.