會話發(fā)起協(xié)議 - 簡介

會話發(fā)起協(xié)議(SIP)是在VoIP技術中使用的最常見的協(xié)議之一。 它是一種應用層協(xié)議，與其他應用層協(xié)議協(xié)同工作，以控制Internet上的多媒體通信會話。

VoIP技術

在進一步討論之前，讓我們首先了解有關VoIP的幾點。

• VOIP是一種允許您通過互聯(lián)網提供語音和多媒體(視頻，圖片)內容的技術。 它是任何時間，任何地方與互聯(lián)網的可用性最便宜的溝通方式之一。

• VOIP的一些優(yōu)勢包括 -

  • 低成本

  • 可移植性

  • 無額外電纜

  • 靈活性

  • 視頻會議

• 對于VOIP呼叫，您需要的是一臺帶有互聯(lián)網連接的電腦/筆記本電腦/手機。 下圖描述了VoIP呼叫如何發(fā)生。

有了這個基礎，讓我們回到SIP。

SIP - 概述

以下是關于SIP的幾點注意事項 -

• SIP是用于通過因特網協(xié)議創(chuàng)建，修改和終止多媒體會話的信令協(xié)議。 會話不過是兩個端點之間的簡單調用。 端點可以是智能電話，膝上型計算機或可以通過因特網接收和發(fā)送多媒體內容的任何設備。

• SIP是由IETF(因特網工程任務組)標準定義的應用層協(xié)議。 它在 RFC 3261 中定義。

• SIP體現(xiàn)了客戶端 - 服務器體系結構以及來自 HTTP 的URL和URI以及來自 SMTP 的文本編碼方案和標題樣式的使用。

• SIP利用SDP(會話描述協(xié)議)的幫助，SDP描述了用于通過IP網絡傳遞語音和視頻的會話和RTP(實時傳輸協(xié)議)。

• SIP可用于雙方(單播)或多方(多播)會話。

• 其他SIP應用包括文件傳輸，即時消息，視頻會議，在線游戲和蒸汽多媒體分發(fā)。

SIP適合在哪里？

基本上SIP是一種應用層協(xié)議。 它是用于創(chuàng)建和終止與一個或多個參與者的會話的簡單網絡信令協(xié)議。 SIP協(xié)議被設計為獨立于底層傳輸協(xié)議，因此SIP應用可以在TCP，UDP或其他低層網絡協(xié)議上運行。

下圖說明了SIP在事物的一般方案中的位置 -

通常，SIP協(xié)議用于兩個或更多個端點之間的互聯(lián)網電話和多媒體分發(fā)。 例如，一個人可以使用SIP發(fā)起到另一個人的電話呼叫，或者某人可以與許多參與者創(chuàng)建電話會議。

SIP協(xié)議被設計為非常簡單，具有有限的命令集。 它也是基于文本的，因此任何人都可以讀取在SIP會話中的端點之間傳遞的SIP消息。

SIP - 網絡元素

有一些實體幫助SIP創(chuàng)建其網絡。 在SIP中，每個網絡元件由類似地址的 SIP URI (統(tǒng)一資源標識符)標識。 以下是網絡元素 -

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

用戶代理

它是端點和SIP網絡的最重要的網絡元件之一。 端點可以啟動，修改或終止會話。 用戶代理是SIP網絡中最智能的設備或網絡元件。 它可以是軟電話，移動電話或筆記本電腦。

用戶代理在邏輯上分為兩個部分 -

• 用戶代理客戶端(UAC) - 發(fā)送請求并接收響應的實體。

• 用戶代理服務器(UAS) - 接收請求并發(fā)送響應的實體。

SIP基于客戶端 - 服務器架構，其中呼叫者的電話充當發(fā)起呼叫的客戶端，并且被叫者的電話充當響應呼叫的服務器。

代理服務器

它是從用戶代理接收請求并將其轉發(fā)給另一個用戶的網絡元素。

• 基本上代理服務器的作用就像一個路由器。

• 它具有一些智能來理解SIP請求并且在URI的幫助下向前發(fā)送它。

• 代理服務器位于兩個用戶代理之間。

• 源和目標之間最多可以有70個代理服務器。

有兩種類型的代理服務器 -

• 無狀態(tài)代理服務器 - 它僅轉發(fā)接收的消息。 這種類型的服務器不存儲呼叫或事務的任何信息。

• 狀態(tài)代理服務器 - 此類型的代理服務器會跟蹤收到的每個請求和響應，如果需要，將來可以使用它。 如果沒有來自另一方的響應，它可以重傳請求。

注冊服務器

注冊服務器接受來自用戶代理的注冊請求。 它幫助用戶在網絡中驗證自己。 它將URI和用戶的位置存儲在數(shù)據(jù)庫中，以幫助同一域中的其他SIP服務器。

請看下面的示例，顯示SIP注冊的過程。

這里呼叫者想要注冊到TMC域。 因此它向TMC的注冊服務器發(fā)送注冊請求，并且服務器在授權客戶端時返回200 OK響應。

重定向服務器

重定向服務器接收請求并在由注冊器創(chuàng)建的位置數(shù)據(jù)庫中查找請求的預期接收者。

重定向服務器使用數(shù)據(jù)庫獲取位置信息，并以3xx(重定向響應)向用戶作出響應。 我們將在本教程的后面討論響應代碼。

位置服務器

位置服務器向重定向和代理服務器提供關于呼叫者可能的位置的信息。

只有代理服務器或重定向服務器可以聯(lián)系位置服務器。

下圖描述了每個網絡元素在建立會話時所扮演的角色。

SIP - 系統(tǒng)架構

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

• SIP的最低層是其語法和編碼。 其編碼使用擴充的背景 - 諾爾表單語法(BNF)指定。

• 第二層是傳輸層。 它定義了客戶端如何發(fā)送請求和接收響應，以及服務器如何通過網絡接收請求和發(fā)送響應。 所有SIP元素都包含傳輸層。

• 接下來是交易層。 事務是由客戶機事務(使用傳輸層)發(fā)送到服務器事務的請求，以及從服務器事務發(fā)送回客戶機的對該請求的所有響應。 用戶代理客戶端(UAC)完成的任何任務都使用一系列事務進行。 無狀態(tài)代理不包含事務層。

• 交易層上方的圖層稱為交易使用者。 除了無狀態(tài)代理，每個SIP實體都是事務用戶。

SIP - 基本呼叫流

下圖顯示了SIP會話的基本呼叫流程。

下面給出了上述調用流程的逐步解釋 -

• 發(fā)送到代理服務器的INVITE請求負責啟動會話。

• 代理服務器立即向呼叫者(Alice)發(fā)送 100 Trying 響應以停止INVITE請求的重傳。

• 代理服務器在位置服務器中搜索Bob的地址。 在獲得地址之后，它進一步轉發(fā)INVITE請求。

• 此后，由Bob產生的 180響鈴(臨時響應)被返回給Alice。

• Bob在接聽電話后立即生成 200 OK 響應。

• Bob收到 200 OK 時，Bob會收到來自Alice的 ACK 。

• 同時，會話建立并且RTP分組(對話)開始從兩端流動。

• 在對話之后，任何參與者(Alice或Bob)可以發(fā)送 BYE 請求以終止會話。

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

• 最后，Bob發(fā)送 200 OK 響應以確認BYE并且會話終止。

• 在上述基本呼叫流程中，三個事務(標記為1,2,3)可用。

完整的呼叫(從INVITE到200 OK)稱為 Dialog 。

SIP梯形

代理如何幫助將一個用戶與另一個用戶連接？ 讓我們在下面的圖的幫助下找出。

圖中所示的拓撲稱為SIP梯形。 該過程如下進行 -

• 當呼叫者發(fā)起呼叫時，向代理服務器發(fā)送INVITE消息。 在接收到INVITE時，代理服務器嘗試在DNS服務器的幫助下解析被調用者的地址。

• 在獲得下一個路由之后，呼叫者的代理服務器(代理1，也稱為出站代理服務器)將INVITE請求轉發(fā)到被叫者的代理服務器，該代理服務器充當被叫者的入站代理服務器(代理2)。

• 入站代理服務器與位置服務器聯(lián)系以獲取有關用戶注冊的被叫方地址的信息。

• 在從位置服務器獲取信息之后，它將呼叫轉發(fā)到其目的地。

• 一旦用戶代理知道他們的地址，他們可以繞過呼叫，即對話直接傳遞。

SIP - 消息傳遞

SIP消息有兩種類型 - 請求和響應。

• 請求的開始行包含定義請求的方法，以及定義請求發(fā)送位置的Request-URI。

• 類似地，響應的開始行包含響應代碼。

請求方法

SIP請求是用于建立通信的代碼。 為了補充它們，存在 SIP響應，其通常指示請求是成功還是失敗。

這些稱為方法的SIP請求使得SIP消息可行。

• 方法可以被認為是SIP請求，因為它們請求由另一個用戶代理或服務器采取的特定動作。

• 方法分為兩種類型 -

  • 核心方法

  • 擴展方法

核心方法

下面討論六種核心方法。

邀請

INVITE用于發(fā)起與用戶代理的會話。 換句話說，INVITE方法用于在用戶代理之間建立媒體會話。

• INVITE可以在消息正文中包含呼叫者的媒體信息。

• 如果INVITE已經接收到成功響應(2xx)或者已經發(fā)送了ACK，則認為會話被建立。



• 成功的INVITE請求在兩個用戶代理之間建立對話，其繼續(xù)，直到發(fā)送BYE以終止會話。

• 在已建立的對話中發(fā)送的INVITE被稱為 re-INVITE 。

• Re-INVITE用于更改會話特征或刷新對話框的狀態(tài)。

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是用于終止已建立的會話的方法。 這是一個SIP請求，可以由主叫方或被叫方發(fā)送以結束會話。

• 它不能由代理服務器發(fā)送。

• BYE請求通常繞過代理服務器端到端路由。

• BYE不能發(fā)送到掛起的INVITE或未建立的會話。

寄存器

REGISTER請求執(zhí)行用戶代理的注冊。 此請求由用戶代理發(fā)送到注冊服務器。

• REGISTER請求可以被轉發(fā)或代理，直到它到達指定域的權威注冊器。

• 它在正在注冊的用戶的 To 頭中攜帶AOR(記錄地址)。

• REGISTER請求包含時間段(3600秒)。

• 一個用戶代理可以代表另一個用戶代理發(fā)送REGISTER請求。 這稱為第三方注冊。 這里， From 標簽包含代表 To 標頭中標識的一方提交注冊的一方的URI。

取消

CANCEL用于終止未建立的會話。 用戶代理使用此請求取消之前發(fā)起的待處理呼叫嘗試。

• 它可以由用戶代理或代理服務器發(fā)送。

• CANCEL是逐跳請求，即，它通過用戶代理之間的元素并接收由下一個有狀態(tài)元素產生的響應。

ACK

ACK用于確認對INVITE方法的最終響應。 ACK總是向著INVITE的方向。如果在INVITE中不可用，ACK可以包含SDP主體(媒體特性)。

• ACK可以不被用于修改已經在初始INVITE中發(fā)送的媒體描述。

• 接收ACK的狀態(tài)代理必須確定ACK是否應當向下游轉發(fā)到另一個代理或用戶代理。

• 對于2xx響應，ACK是端到端的，但是對于所有其他最終響應，當涉及狀態(tài)代理時，其工作在逐跳基礎上。

選項

OPTIONS方法用于向用戶代理或代理服務器查詢其功能，并發(fā)現(xiàn)其當前可用性。 對請求的響應列出了用戶代理或服務器的功能。 代理永遠不會生成OPTIONS請求。

擴展方法

訂閱

用戶代理使用SUBSCRIBE來建立訂閱，以獲得關于特定事件的通知。

• 它包含一個 Expires 頭字段，用于指示訂閱的持續(xù)時間。

• 在該時間段過去之后，訂閱將自動終止。

• 訂閱在用戶代理之間建立對話。

• 您可以在到期時間之前在對話框中發(fā)送另一個SUBSCRIBE再次重新訂閱。

• 將收到來自用戶的訂閱的200 OK。

• 用戶可以通過發(fā)送另一個SUBSCRIBE方法取消訂閱，Expires值為0(零)。

通知

NOTIFY用于由用戶代理獲取特定事件的發(fā)生。 通常，當訂閱者和通知者之間存在訂閱時，NOTIFY將在對話框中觸發(fā)。

• 每個NOTIFY將得到200 OK響應，如果它被通知器接收。

• NOTIFY包含指示事件的 Event 頭字段和指示訂閱當前狀態(tài)的 subscriptionstate 頭字段。

• NOTIFY總是在訂閱的開始和終止時發(fā)送。

發(fā)布

PUBLISH由用戶代理用于向服務器發(fā)送事件狀態(tài)信息。

• 當有多個事件信息來源時，PUBLISH是最有用的。

• PUBLISH請求類似于NOTIFY，除了它不是在對話框中發(fā)送。

• PUBLISH請求必須包含 Expires 頭字段和 Min-Expires 頭字段。

參考

REFER由用戶代理使用來引用另一個用戶代理來訪問對話框的URI。

• REFER必須包含 Refer-To 標題。 這是REFER的必需標題。

• REFER可以在對話框內部或外部發(fā)送。

• A 202 Accepted 將觸發(fā)REFER請求，指示其他用戶代理已接受引用。

信息

INFO由用戶代理用來向與其建立媒體會話的另一用戶代理發(fā)送呼叫信令信息。

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

• 代理將始終轉發(fā)INFO請求。

更新

如果會話未建立，UPDATE用于修改會話的狀態(tài)。 用戶可以使用UPDATE更改編解碼器。

如果建立了會話，則使用重新邀請來改變/更新會話。

PRACK

PRACK用于確認接收到臨時響應(1XX)的可靠傳輸。

• 通常，當客戶端接收到包含 RSeq 可靠序列號和支持的:100rel 頭部的臨時響應時，PRACK就會生成。

• PRACK在 rack 標題中包含(RSeq＆amp; plus; CSeq)值。

• PRACK方法適用于所有臨時響應，除了100 Trying響應，其從未可靠地傳送。

• PRACK可以包含消息體; 它可以用于提供/應答交換。

信息

它用于使用SIP發(fā)送即時消息。 IM通常包括從事文本會話的參與者實時交換的短消息。

• MESSAGE可以在對話框內或對話框外發(fā)送。

• MESSAGE的內容作為 MIME 附件在郵件正文中傳送。

• 通常接收到 200 OK 響應以指示消息已在其目的地傳送。

SIP - 響應代碼

SIP響應是由用戶代理服務器(UAS)或SIP服務器生成的用于回復由客戶端生成的請求的消息。 它可以是防止UAC重傳請求的正式確認。

• 響應可以包含UAC所需的信息的一些附加報頭字段。

• SIP有六個響應。

• 1xx到5xx已從HTTP借用，6xx已在SIP中引入。

• 1xx被認為是臨時響應，其余的是最終響應。

S.No。	功能＆amp; 描述
1	1xx: Provisional/Informational Responses 信息響應用于指示呼叫進度。 通常響應是端到端的(除了100 Trying)。
2	2xx: Success Responses 這類響應用于指示請求已被接受。
3	3xx: Redirect Responses 通常這些類響應由重定向服務器響應INVITE發(fā)送。 它們也稱為重定向類響應。
4	4xx: Client Failure Responses 客戶端錯誤響應指示無法滿足請求，因為從UAC側識別出一些錯誤。
5	5xx: Server Failure Response 此類響應用于指示由于服務器錯誤而無法處理請求。
6	6xx: Global Failure Response 此響應類指示服務器知道請求在嘗試的任何地方都將失敗。 因此，請求不應發(fā)送到其他位置。

SIP - 報頭

報頭是傳達關于消息的信息的SIP消息的組件。 它被構造為頭字段序列。

SIP頭字段在大多數(shù)情況下遵循與HTTP頭字段相同的規(guī)則。 標題字段定義為 Header:字段，其中Header用于表示標題字段名稱，字段是包含信息的標記集合。 每個字段包含一個字段名稱，后跟冒號(“:")和字段值(即字段名稱:字段值)。

SIP頭 - 緊湊型

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

標題	緊湊型
To	T
Via	V
Call-ID	I
Contact	M
From	F
Subject	S
Content-Length	I

SIP頭格式

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

根據(jù)其在SIP中的用法，標題被分類如下:

• Request and Response
• Request Only
• Response Only
• Message Body

SIP - 會話描述協(xié)議

SDP代表會話描述協(xié)議。 它用于描述參與者通過網絡理解的格式的多媒體會話。 根據(jù)該描述，一方決定是否加入會議或者何時或如何加入會議。

• 會議的所有者通過發(fā)送包含會話描述的多播消息在網絡上廣告它。 所有者的名稱，會話的名稱，編碼，時間等。根據(jù)這些信息，廣告的接收者做出關于參與會話的決定。

• SDP通常包含在通常稱為SIP的會話發(fā)起協(xié)議的主體部分中。

• SDP在RFC 2327中定義。SDP消息由一系列稱為字段的行組成，其名稱由單個小寫字母縮寫，并且以所需順序來簡化解析。

SDP的目的

SDP的目的是在多媒體會話中傳達關于媒體流的信息，以幫助參與者加入或收集特定會話的信息。

• SDP是一個短結構化文本描述。

• 它傳達會話的名稱和目的，媒體，協(xié)議，編解碼格式，定時和傳輸信息。

• 臨時參與者檢查這些信息并決定是否加入會話，以及如果它決定如何以及何時加入會話。

• 格式具有< type>形式的條目。 =< value>，其中< type> 定義唯一會話參數(shù)，并且< value> 提供該參數(shù)的特定值。

• SDP消息的一般形式是 -

  SDP消息的一般形式是 - ...

• 行以單個小寫字母開頭，例如x。 字母和=之間從不存在任何空格，每個參數(shù)之間只有一個空格。 每個字段都有一定數(shù)量的參數(shù)。

會話描述參數(shù)

會話描述(*表示可選)

• v = (protocol version)
• o = (owner/creator and session identifier)
• s = (session name)
• i =* (session information)
• u =* (URI of description)
• e =* (email address)
• p =* (phone number)
• c =* (connection information - not required if included in all media)
• b =* (bandwidth information)
• z =* (time zone adjustments)
• k =* (encryption key)
• a =* (zero or more session attribute lines)

協(xié)議版本

v =字段包含SDP版本號。 因為SDP的當前版本是0，所以有效的SDP消息將始終以v = 0開始。

起源

o =字段包含有關會話發(fā)起者和會話標識符的信息。 此字段用于唯一標識會話。

• 該字段包含 -

  o =< username>< session-id>< version>< network-type>< address-type>

• 用戶名參數(shù)包含發(fā)起方的登錄名或主機。

• session-id 參數(shù)是用于確保唯一性的網絡時間協(xié)議(NTP)時間戳或隨機數(shù)。

• 版本是一個數(shù)字字段，對于會話的每個更改都會增加，也建議為NTP時間戳。

• 對于Internet，網絡類型始終為IN。 address-type參數(shù)為IPv4或IPv6地址的IP4或IP6(點分十進制形式或完全限定的主機名)。

會話名稱和信息

s =字段包含會話的名稱。 它可以包含任何非零數(shù)字的字符。 可選的i =字段包含有關會話的信息。 它可以包含任意數(shù)量的字符。

URI

可選的u =字段包含具有關于會話的更多信息的統(tǒng)一資源指示符(URI)

電子郵件地址和電話號碼

可選的e =字段包含會話主機的電子郵件地址。 可選的p =字段包含電話號碼。

連接數(shù)據(jù)

c =字段包含有關介質連接的信息。

• 該字段包含 -

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

• 對于Internet， network-type 參數(shù)定義為IN。

• 地址類型定義為IPv4地址的IP4和IPv6地址的IP6。

• connection-address 是將發(fā)送媒體數(shù)據(jù)包的IP地址或主機，可以是多播或單播。

• 如果組播，則connection-address字段包含 -

  connection-address = base-multicast-address / ttl / number-of-addresses

其中 ttl 是生存時間值，并且地址數(shù)量指示從基本多播地址開始包括多少個連續(xù)的多播地址。

帶寬

可選b =字段包含有關所需帶寬的信息。 它的形式 -

b = modifier:bandwidth - value

時間，重復次數(shù)和時區(qū)

t =字段包含會話的開始時間和停止時間。

t =開始時間停止時間

可選的r =字段包含有關可以在NTP或天( d 小>)，小時( h 小>)或分鐘( > m )。

可選的 z =字段包含有關時區(qū)偏移的信息。 如果發(fā)生的會話跨越從夏令時到標準時間的更改，則使用此字段，反之亦然。

媒體公告

可選的 m =字段包含有關媒體會話類型的信息。 該字段包含 -

m =媒體端口傳輸格式列表

• 媒體參數(shù)是音頻，視頻，文本，應用程序，消息，圖像或控件。 port參數(shù)包含端口號。

• 傳輸參數(shù)包含使用的傳輸協(xié)議或RTP配置文件。

• 格式列表包含有關介質的更多信息。 通常，它包含在RTP音頻視頻簡檔中定義的媒體有效載荷類型。

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

這三個編解碼器之一可以用于音頻媒體會話。 如果意圖是建立三個音頻通道，則將使用三個單獨的媒體字段。

屬性

可選的a =字段包含前面的媒體會話的屬性。 此字段可用于擴展SDP以提供有關介質的更多信息。 如果SDP用戶沒有完全理解，則可以忽略屬性字段。 媒體字段中列出的每個媒體有效內容類型可以有一個或多個屬性字段。

SDP中的屬性可以是

• session level, or
• media level.

會話級別意味著該屬性在SDP中的第一個媒體行之前列出。 如果是這種情況，該屬性將應用于其下的所有媒體行。

媒體級別表示它在媒體行之后列出。 在這種情況下，屬性僅適用于該特定媒體流。

SDP可以包括會話級和媒體級屬性。 如果相同的屬性同時出現(xiàn)，則媒體級屬性將覆蓋該特定媒體流的會話級屬性。 請注意，連接數(shù)據(jù)字段也可以是會話級或媒體級。

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 - 提供/回答模型

SDP與SIP的使用在SDP提議回答RFC 3264中給出。SIP中的默認消息體類型是 application / sdp 。

• 主叫方列出他們愿意在SDP中接收的媒體能力，通常在INVITE或ACK中。

• 被叫方在對INVITE的200 OK響應中列出它們的媒體能力。

SDP的典型SIP使用包括以下字段:版本，起源，主題，時間，連接以及一個或多個媒體和屬性。

• 主題和時間字段不由SIP使用，但包括為了兼容性。

• 主題和時間字段不由SIP使用，但包括為了兼容性。

• 時間字段通常設置為t = 00.SIP使用連接，媒體和屬性字段在UA之間建立會話。

• 原始字段對SIP的使用有限。

• session-id通常在整個SIP會話中保持不變。

• 每次更改SDP時，版本都會增加。 如果發(fā)送的SDP與之前發(fā)送的SDP沒有變化，則版本保持不變。

• 由于要使用的媒體會話和編解碼器的類型是連接協(xié)商的一部分，SIP可以使用SDP來指定多個替代媒體類型并且選擇性地接受或拒絕那些媒體類型。

offer / answer規(guī)范RFC 3264建議對每個媒體字段使用包含a = rtpmap:的屬性。 通過將SDP響應中相應的媒體字段的端口號設置為零來拒絕媒體流。

例子

在以下示例中，呼叫者Tesla想要使用兩個可能的音頻編解碼器和在初始INVITE中攜帶的SDP中的視頻編解碼器來建立音頻和視頻呼叫 -

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 

編解碼器由RTP / AVP配置文件編號97,98引用。

被叫方Marry應答呼叫，為第一媒體字段選擇第二編解碼器，并且拒絕第二媒體字段，只想要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 

如果此僅音頻呼叫不可接受，則Tom將發(fā)送ACK，然后發(fā)送BYE以取消呼叫。 否則，將建立音頻會話并交換RTP分組。

如該示例所示，除非保持媒體字段的數(shù)量和順序，否則呼叫方將不知道被叫方正在接受和拒絕哪些媒體會話。

提供/回答規(guī)則在以下部分中總結。

生成要約的規(guī)則

SDP報價必須包括所有必需的SDP字段(這包括v =，o =，s =，c =和t =)。 這些是SDP中的必填字段。

它通常包括一個媒體字段( m = )，但它不必。 媒體行包含按優(yōu)先順序列出的所有編解碼器。 唯一的例外是，如果端點支持大量的編解碼器，最可能被接受或最優(yōu)選應該被列出。 不同的媒體類型包括音頻，視頻，文本，MSRP，BFCP等。

生成答案的規(guī)則

SDP對報價的回答必須根據(jù)以下規(guī)則構建:

• 答案必須具有與答案相同順序的相同數(shù)量的 m = 行。

• 可以通過將端口號設置為0來拒絕單個媒體流。

• 通過發(fā)送非零端口號接受流。

• 每個媒體類型的列出的有效載荷必須是報價中列出的有效載荷的子集。

• 對于動態(tài)有效載荷，不需要在每個方向上使用相同的動態(tài)有效載荷數(shù)。 通常，只選擇單個有效載荷。

修改會話的規(guī)則

任一方可以發(fā)起另一個提議/應答交換以修改會話。 修改會話時，必須遵循以下規(guī)則:

• 原始( o = )線路版本號必須與發(fā)送的最后一個版本號相同，這表示此SDP與前一個交換相同，或者可以遞增一，表示新 必須解析的SDP。

• 優(yōu)惠必須包含所有現(xiàn)有媒體行，并且必須按相同的順序發(fā)送。

• 附加的媒體流可以添加到 m = 行列表的末尾。

• 可以通過將端口號設置為0來刪除現(xiàn)有媒體流。此媒體行必須保留在SDP中以及此會話的所有將來的提供/應答交換。

呼叫保持

呼叫中的一方可以暫時將另一方暫停。 這通過發(fā)送具有與原始INVITE的SDP相同的SDP但具有 a = sendonly 屬性的INVITE來完成。

通過發(fā)送具有 a = sendrecv 屬性的另一個INVITE，該調用再次激活。 下圖顯示了呼叫保持的呼叫流程。

SIP - 移動性

個人移動性是在多個設備上擁有常量標識符的功能。 SIP使用REGISTER方法支持基本的個人移動性，其允許移動設備改變其到因特網的IP地址和連接點，并且仍然能夠接收呼入呼叫。

SIP還可以支持服務移動性 - 移動時用戶保持相同服務的能力

切換期間的SIP移動性(呼叫前)

設備通過簡單的SIP注冊將其聯(lián)系URI與記錄的地址綁定。 根據(jù)設備IP地址，注冊授權此信息在SIP網絡中自動更新。

在切換期間，用戶代理在不同運營商之間路由，其中它必須再次向作為AOR的聯(lián)系人注冊另一服務提供商。

例如，讓我們以下面的調用流程為例。 UA已經臨時接收到具有新服務提供商的新SIP URI。 UA然后執(zhí)行雙重注冊 -

• 第一次注冊是使用新的服務運營商，它將設備的Contact URI與新的服務提供商的AOR URI綁定。

• 第二個REGISTER請求被路由回原始服務提供者，并提供新的服務提供者的AOR作為聯(lián)系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將被發(fā)送到sip:registrar2.in; 第二INVITE將被發(fā)送到sip:sip:Tom@registrar2.in，其將被轉發(fā)到 sip:Tom@172.22.1.102 。 它到達Tom并允許建立會話。 定期兩個注冊都需要刷新。

通話期間的移動(重新邀請)

用戶代理可以在會話期間更改其IP地址，因為它從一個網絡交換到另一個網絡。 基本SIP支持此場景，因為對話框中的re-INVITE可用于更新聯(lián)系URI并更改SDP中的媒體信息。

看看下面圖中提到的呼叫流程。

• 這里，Tom檢測到一個新的網絡，

• 使用DHCP獲取新的IP地址，和

• 執(zhí)行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

re-INVITE在Via和Contact報頭字段和SDP媒體信息中包含Bowditch的新IP地址。

移動性在Midcall(與替換標題)

在中間移動性中，實際路由集(SIP消息必須穿越的SIP代理集)必須改變。 我們不能在midcall移動中使用re-INVITE

例如，如果NAT穿越需要代理，則必須更改聯(lián)系URI - 必須創(chuàng)建一個新對話框。 因此，它必須發(fā)送一個帶有Replaces標頭的新INVITE，它標識現(xiàn)有會話。

注意 - 假設A＆amp; B都在一個調用中，如果A得到另一個INVITE(我們說從C)替換頭(應該匹配現(xiàn)有的對話框)，則A必須接受INVITE并終止與B的會話，并將所有資源轉移到新形成的對話框。

呼叫流程如下圖所示。 它類似于使用re-INVITE的先前呼叫流程，除了當接受具有Replaces的INVITE時自動生成BYE以終止現(xiàn)有對話。

下面是在這種情況下要注意的要點 -

• Tom和Jerry之間的現(xiàn)有對話包括舊的訪問代理服務器。

• 使用新無線網絡的新對話框需要包括新的訪問代理服務器。

• 結果，由Tom發(fā)送具有Replaces的INVITE，其創(chuàng)建包括新訪問的代理服務器但不包括舊的訪問的代理服務器的新對話。

• 當Jerry接受INVITE時，會自動發(fā)送一個BYE，以終止通過現(xiàn)在不再包含在會話中的舊訪問代理服務器路由的舊對話。

• 使用來自INVITE中的SDP的Tom的新IP地址來建立所得到的媒體會話。

服務移動性

SIP中的服務可以在代理中或在UA中提供。 除非用戶的設備被相同地配置有相同的服務，否則提供服務移動性以及個人移動性可能是有挑戰(zhàn)性的。

SIP可以輕松地支持Internet上的服務移動性。 當連接到Internet時，配置為在印度使用一組代理的UA仍然可以在歐洲漫游時使用這些代理。 它對媒體會話的質量沒有任何影響，因為媒體總是直接在兩個UA之間流動，并且不穿過SIP代理服務器。

端點駐留服務僅在端點連接到Internet時可用。 如果端點已臨時丟失其Internet連接，則端點中實現(xiàn)的端點服務(例如呼叫轉發(fā)服務)將失敗。 因此，使用SIP代理服務器在網絡中實現(xiàn)一些服務。

SIP - 分岔

有時，代理服務器將單個SIP呼叫轉發(fā)到多個SIP端點。 這個過程被稱為分叉。 這里單個呼叫可以同時響鈴多個端點。

使用SIP分叉，您可以讓您的桌面電話與手機上的軟件電話或SIP電話同時響鈴，從而可以輕松地從任一設備接聽電話。

一般來說，在辦公室里，假設老板無法接聽電話或離開，SIP分機允許秘書接聽電話他的分機。

如果有一個有狀態(tài)的代理可用，因為它需要執(zhí)行和響應從它收到的許多，分叉將是可能的。

我們有兩種類型的分叉 -

• Parallel Forking
• Sequential Forking

平行分叉

在這種情況下，代理服務器將把INVITE分叉到例如兩個設備(UA2，UA3)。 兩個設備將產生180響鈴，并且接收呼叫的任何人將產生200 OK。 首先到達發(fā)起者的響應(假設UA2)將與UA2建立會話。 對于其他響應，將觸發(fā)CANCEL。

如果發(fā)起者同時接收到這兩個響應，則基于q值，它將轉發(fā)響應。

順序分岔

在這種情況下，代理服務器將INVITE分叉到一個設備(UA2)。 如果UA2在那時不可用或忙，則代理將它分配到另一個設備(UA3)。

分支 - ID和標簽

分支標識幫助代理匹配對分叉請求的響應。 沒有分支ID，代理服務器將無法了解分叉響應。 分支標識將在Via標頭中可用。

標簽由UAC使用以區(qū)分來自不同UAS的多個最終響應。 UAS無法解析請求是否已分叉。 因此，它需要添加一個標簽。

代理還可以添加標簽，如果它生成最終響應，他們從來不插入標簽到請求或響應他們轉發(fā)。

也有可能單個請求也可以由多個代理服務器分叉。 因此，fork的代理將向它創(chuàng)建的分支添加自己的唯一ID。

呼叫支路和呼叫ID

呼叫支路是指兩個用戶代理之間的一對一信令關系。 呼叫ID是參考呼叫的SIP消息中攜帶的唯一標識符。 呼叫是呼叫線路的集合。

UAC通過發(fā)送INVITE開始。 由于分叉，它可以從不同的UA接收多個200OK。 每個對應于相同呼叫中的不同呼叫支路。

UAC通過發(fā)送INVITE開始。 由于分叉，它可以從不同的UA接收多個200OK。 每個對應于相同呼叫中的不同呼叫支路。...

呼叫支路的兩個方向上的CSeq空間是獨立的。 在單個方向上，序列號對于每個事務遞增。

語音郵件

對于企業(yè)用戶來說，語音郵件是非常普遍的。 這是一個電話應用程序。 談到圖片，當被叫方不可用或無法接收呼叫時，PBX將通知主叫方留下語音消息。

如果被叫方的號碼不可達，用戶代理將獲得3xx響應或重定向到語音郵件服務器。 然而，需要某種SIP分機來向語音郵件系統(tǒng)指示要使用哪個郵箱 - 即，播放哪個問候語以及在哪里存儲所記錄的消息。 有兩種方法來實現(xiàn)這一點 -

• 通過使用SIP頭字段擴展

• 通過使用Request-URI來發(fā)信號通知這個信息

假設用戶 sip:Tom@tutorialspoint.com 在sip:voicemail.tutorialspoint.com處具有語音郵件系統(tǒng)，其提供語音郵件，INVITE的Request-URI，當它被轉發(fā)到語音郵件服務器時 可能看起來像 -

sip:voicemail.tutorialspoint.com;target = sip:Tom@tutorialspoint.com;cause = 486

下圖顯示了Request-URI如何攜帶郵箱標識符和原因(這里為486)。

SIP - 代理和路由

我們知道，代理服務器可以是無狀態(tài)的或有狀態(tài)的。 在這里，在本章中，我們將討論更多關于代理服務器和SIP路由。

無狀態(tài)代理服務器

無狀態(tài)代理服務器簡單地轉發(fā)它接收的消息。 這種服務器不存儲任何呼叫或交易的信息。

• Stateless proxies forget about the SIP request once it has been forwarded.
• Transaction will be fast via stateless proxies.

狀態(tài)代理服務器

狀態(tài)代理服務器跟蹤它接收的每個請求和響應。 如果需要，它可以使用未來存儲的信息。 如果它沒有從另一方接收到響應，它可以重傳請求。

• 狀態(tài)代理在轉發(fā)請求之后記住請求，因此它們可以使用它來提前路由。 狀態(tài)代理維護事務狀態(tài)。 交易意味著交易狀態(tài)，不是呼叫狀態(tài)。

• 事務不像無狀態(tài)的狀態(tài)代理那么快。

• 如果需要，狀態(tài)代理可以分叉和重傳(例如，例如呼叫前轉忙)。

通過和記錄路由

記錄路由

記錄 - 路由報頭被想要在相同呼叫id的后續(xù)請求的路徑中的代理插入到請求中。 然后由用戶代理使用它來路由后續(xù)請求。

通過

通過頭由服務器插入請求以檢測循環(huán)并幫助響應找到他們的方式回到客戶端。 這有助于只有響應到達其目的地。

• UA自己在發(fā)送請求時在Via報頭字段中生成并添加其自己的地址。

• 轉發(fā)請求的代理將Via頭字段包含其自己的地址添加到Via頭字段列表的頂部。

• 生成對請求的響應的代理或UA將請求中的所有Via報頭字段按順序復制到響應中，然后將響應發(fā)送到在頂部Via報頭字段中指定的地址。

• 接收響應的代理檢查頂部Via頭字段并匹配其自身的地址。 如果不匹配，則響應已被丟棄。

• 然后刪除頂部Via頭字段，并將響應轉發(fā)到在下一個Via頭字段中指定的地址。

Via頭字段包含協(xié)議名，版本號和傳輸(SIP / 2.0 / UDP，SIP / 2.0 / TCP等)，并包含端口號和參數(shù)，如received，rport，branch。

• 如果UA或代理從與在頂部Via頭字段中指定的地址不同的地址接收到請求，則將所接收的標簽添加到Via報頭字段。

• 分支參數(shù)通過UA和代理被添加到Via報頭字段，其被計算為Request-URI的哈希函數(shù)，以及To，F(xiàn)rom，Call-ID和CSeq數(shù)。

SIP到PSTN

SIP(軟電話)和PSTN(舊電話)都是不同的網絡，并使用不同的語言。 因此，我們需要一個翻譯器(網關在這里)在這兩個網絡之間通信。

讓我們舉一個例子來說明SIP電話如何通過PSTN網關向PSTN發(fā)出電話呼叫。

在此示例中，Tom (sip:tom@tutorialspoint.com)是sip電話，Jerry使用全球電話號碼+91401234567。

SIP到PSTN通過網關

下圖顯示了通過網關從SIP到PSTN的呼叫流。

下面給出了從SIP電話到PSTN的呼叫時所進行的所有過程的逐步解釋。

• 首先，(Tom)SIP電話撥打全球號碼+91401234567到達Jerry。 SIP用戶代理將其理解為全局編號，并使用DNS將其轉換為請求uri并觸發(fā)請求。

• SIP電話直接向網關發(fā)送INVITE。

• 網關通過選擇SS7 ISUP中繼線到PSTN中的下一個電話交換機來發(fā)起進入PSTN的呼叫。

• 來自INVITE的撥號數(shù)字被映射到ISUP IAM。 ISUP地址完成消息(ACM)由PSTN發(fā)回以指示中繼已經創(chuàng)建。

• 電話產生鈴聲，并進入電話交換機。 網關將ACM映射到183會話進度響應，其包含指示網關將用于橋接來自PSTN的音頻的RTP端口的SDP。

• 在接收到183時，呼叫者的UAC開始接收從網關發(fā)送的RTP分組，并將該音頻呈現(xiàn)給呼叫者，使得他們知道被叫者在PSTN中前進。

• 當被叫方應答電話時，呼叫完成，這使得電話交換機向網關發(fā)送應答消息(ANM)。

• 網關然后在兩個方向上切斷PSTN音頻連接，并向呼叫者發(fā)送200 OK響應。 由于RTP媒體路徑已經建立，網關在183中回復SDP，但是不會改變RTP連接。

• UAC發(fā)送ACK以完成SIP信令交換。 由于在ISUP中沒有等效消息，網關吸收ACK。

• 呼叫者發(fā)送BYE到網關終止。 網關將BYE映射到ISUP釋放消息(REL)。

• 網關向BYE發(fā)送200OK，并從PSTN接收RLC。

SIP - 編解碼器

編解碼器，編碼器 - 解碼器的簡稱，做兩個基本操作 -

• 首先，它將模擬語音信號轉換為其等效數(shù)字形式，以便可以容易地發(fā)送。

• 此后，它將壓縮的數(shù)字信號轉換回其原始模擬形式，以便可以重放。

市場上有許多編解碼器 - 有些是免費的，有些則需要許可。 編解碼器在聲音質量上不同，并且?guī)捪鄳刈兓?/span>

硬件設備如電話和網關支持幾種不同的編解碼器。 當彼此交談時，他們談判使用哪個編解碼器。

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

G.711

G.711是國際電聯(lián)在1972年引入的用于數(shù)字電話的編解碼器。 編解碼器有兩種變體: A-Law 正在歐洲和國際電話鏈接中使用， uLaw 用于美國和日本。

• G.711使用對數(shù)壓縮。 它將每個16位樣本壓縮為8位，從而實現(xiàn)1:2的壓縮比。

• 一個方向的比特率為64 kbit / s，因此一個呼叫消耗128 kbit / s。

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

• 它在我們有很多帶寬的局域網中工作的最好。

G.729

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

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

• 編解碼算法將每個幀編碼為10個字節(jié)，因此在一個方向上產生的比特率為8 kbit / s。

• G.729是許可編解碼器。 想要使用此編解碼器的最終用戶應購買實現(xiàn)它的硬件(無論是VoIP電話還是網關)。

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

G.723.1

G.723.1是國際電聯(lián)宣布的競爭的結果，目的是設計一個編解碼器，允許呼叫超過28.8和33 kbit / s調制解調器鏈路。

• 我們有兩個G.723.1的變體。 它們都在30ms的音頻幀(即240個采樣)上操作，但算法不同。

• 第一變體的比特率是6.4kbit / s，而對于第二變體，它是5.3kbit / s。

• 兩個變體的編碼幀分別為24和20字節(jié)長。

GSM 06.10

GSM 06.10是為GSM移動網絡設計的編解碼器。 它也稱為GSM全速率。

• 這種GSM編解碼器的變體可以自由使用，所以你經常會在開源VoIP應用中找到它。

• 編解碼器對20ms長(即160個樣本)的音頻幀進行操作，并且將每個幀壓縮為33字節(jié)，因此所得的比特率為13kbit /。

SIP - B2BUA

背靠背用戶代理(B2BUA)是SIP應用程序中的邏輯網絡元素。 它是一種SIP UA，它接收SIP請求，然后重新格式化請求，并將其作為新請求發(fā)送出去。

與代理服務器不同，它維護對話狀態(tài)，并且必須參與在其建立的對話框上發(fā)送的所有請求。 B2BUA打破了SIP的端到端性質。

B2BUA - 如何工作？

B2BUA代理在電話呼叫的兩個端點之間操作，并且將通信信道劃分為兩個呼叫分支。 B2BUA是UAC和UAS的串聯(lián)。 它參與呼叫兩端之間的所有SIP信令，它已經建立。 由于對話服務提供商中可用的B2BUA可以實現(xiàn)一些增值特征。

在始發(fā)呼叫段中，B2BUA充當用戶代理服務器(UAS)，并將該請求作為用戶代理客戶端(UAC)處理到目的地端，處理 端點之間的信令。

B2BUA維護其處理的調用的完整狀態(tài)。 B2BUA的每一側作為RFC 3261中規(guī)定的標準SIP網絡元件操作。

B2BUA的功能

B2BUA提供以下功能 -

• 呼叫管理(計費，自動呼叫斷開，呼叫轉移等)

• 網絡互通(可能與協(xié)議適配)

• 隱藏網絡內部(私有地址，網絡拓撲等)

通常，B2BUA也在媒體網關中實現(xiàn)以橋接媒體流以完全控制會話。

B2BUA的示例

許多專用交換機(PBX)企業(yè)電話系統(tǒng)包含B2BUA邏輯。

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

另一種常見類型的B2BUA稱為會話邊界控制器(SBC)。

---