SIP (Session Initiation Protocol) 協議

撒歡發表於2021-04-04
SessionProtocol協議

Session Initiation Protocol 介紹

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

VoIP 技術

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

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

  • 其優點包括

    • 便宜

    • 可移植性

    • 靈活性

    • 視訊會議

  • 對於VoIP通話，您所需要的只是一臺具有Internet連線的計算機/膝上型電腦/行動電話。下圖描述瞭如何進行VoIP呼叫

　　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 Layers

通常，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註冊的流程.

SIP Registration Example

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

Redirect Server

重定向伺服器接收到請求，然後從註冊服務商建立的資料庫中查詢預期的收件人.

重定向伺服器使用資料庫獲取位置資訊並以3xx響應使用者.

Location Server

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

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

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

Location Server

SIP – 系統架構

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

System Architecture

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

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

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

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

SIP - 基本通話流程

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

SIP Call Flow

解釋如下

  • 一個 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 Trapezoid

圖片中顯示的拓撲結構被稱為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

  • 一個成功的 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 方法是UA用來傳送註冊請求. 這個請求是UA發給 註冊伺服器.

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

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

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

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

CANCEL

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

  • 它可以被UA或代理伺服器傳送.

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

Hop By Hop

ACK

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

SDP Ack

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

SDP Acknowledgement

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

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

OPTIONS

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

擴充套件方法

SUBSCRIBE

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

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

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

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

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

  • 一個 200 OK 從使用者那裡收到.

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

Example Subscribe

NOTIFY

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

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

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

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

PUBLISH

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 修改編碼.

Update

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

PRACK

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

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

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

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

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

MESSAGE

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

Message

  • 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報頭欄位都有一個緊湊的形式，其中報頭欄位名稱由單個小寫字元表示. 下面給出一些例子 -

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

SIP Header Format

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

SIP Header Format

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

編解碼器型別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 使通話變得活躍起來.

Call Hold

SIP - 移動性

Personal mobility，個人移動性是在多個裝置之間擁有恆定識別符號的能力. SIP支援使用REGISTER 方法，實現基本的個人移動性，這種方法允許移動裝置更改其IP地址和網際網路連線點，但仍然能夠接收來電.

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

SIP 交接時的移動性

裝置通過簡單的sip註冊將其聯絡的URI與記錄的地址繫結。根據裝置的IP地址，註冊授權此資訊在sip網路中自動更新.

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

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

  • 第一次註冊是在新的服務運營商那裡進行的，該運營商將裝置的聯絡人URI與新的服務提供商的AOR URI繫結.

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

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

SIP Mobility

對於第一次註冊，包含裝置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可以從兩個網路接收媒體流，中斷可以忽略不計. 如果不是這樣，一些媒體包可能會丟失，導致通話輕微中斷.

Mobility During Call

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的會話，傳輸所有資源到新建立的對話.

Mobility In Midcall

  • 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.

Parallel Forking

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

順序Forking

在這個場景中，代理伺服器將會fork INVITE 到一個裝置，如果這個裝置此時不可達或繁忙，然後代理將會fork它到另一個裝置.

Sequential Forking

分支- 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空間在兩個方向上是獨立的. 在單個方向中，在每個事務上序列號是遞增的.

Call Leg Id

語音信箱

對企業使用者來說語音郵件變得非常普遍. 它是一個電話應用. 當被叫不可用或無法接電話時，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 Voicemail

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.

SIP to 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).

 

相關文章