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

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

VoIP技術(shù)

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

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

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

  • 低成本

  • 可移植性

  • 無額外電纜

  • 靈活性

  • 視頻會議

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

有了這個基礎(chǔ)，讓我們回到SIP。

SIP - 概述

以下是關(guān)于SIP的幾點注意事項 -

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

• SIP是由IETF(因特網(wǎng)工程任務(wù)組)標(biāo)準(zhǔn)定義的應(yīng)用層協(xié)議。 它在 RFC 3261 中定義。

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

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

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

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

SIP適合在哪里？

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

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

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

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

SIP - 網(wǎng)絡(luò)元素

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

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

用戶代理

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

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

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

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

SIP基于客戶端 - 服務(wù)器架構(gòu)，其中呼叫者的電話充當(dāng)發(fā)起呼叫的客戶端，并且被叫者的電話充當(dāng)響應(yīng)呼叫的服務(wù)器。

代理服務(wù)器

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

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

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

• 代理服務(wù)器位于兩個用戶代理之間。

• 源和目標(biāo)之間最多可以有70個代理服務(wù)器。

有兩種類型的代理服務(wù)器 -

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

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

注冊服務(wù)器

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

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

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

重定向服務(wù)器

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

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

位置服務(wù)器

位置服務(wù)器向重定向和代理服務(wù)器提供關(guān)于呼叫者可能的位置的信息。

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

下圖描述了每個網(wǎng)絡(luò)元素在建立會話時所扮演的角色。

SIP - 系統(tǒng)架構(gòu)

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

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

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

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

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

SIP - 基本呼叫流

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

下面給出了上述調(diào)用流程的逐步解釋 -

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

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

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

• 此后，由Bob產(chǎn)生的 180響鈴(臨時響應(yīng))被返回給Alice。

• Bob在接聽電話后立即生成 200 OK 響應(yīng)。

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

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

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

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

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

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

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

SIP梯形

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

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

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

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

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

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

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

SIP - 消息傳遞

SIP消息有兩種類型 - 請求和響應(yīng)。

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

• 類似地，響應(yīng)的開始行包含響應(yīng)代碼。

請求方法

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

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

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

• 方法分為兩種類型 -

  • 核心方法

  • 擴展方法

核心方法

下面討論六種核心方法。

邀請

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

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

• 如果INVITE已經(jīng)接收到成功響應(yīng)(2xx)或者已經(jīng)發(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ā)送以結(jié)束會話。

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

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

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

寄存器

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

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

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

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

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

取消

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

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

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

ACK

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

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

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

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

選項

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

擴展方法

訂閱

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

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

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

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

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

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

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

通知

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

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

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

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

發(fā)布

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

• 當(dāng)有多個事件信息來源時，PUBLISH是最有用的。

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

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

參考

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

• REFER必須包含 Refer-To 標(biāo)題。 這是REFER的必需標(biāo)題。

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

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

信息

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

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

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

更新

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

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

PRACK

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

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

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

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

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

信息

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

• MESSAGE可以在對話框內(nèi)或?qū)υ捒蛲獍l(fā)送。

• MESSAGE的內(nèi)容作為 MIME 附件在郵件正文中傳送。

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

SIP - 響應(yīng)代碼

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

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

• SIP有六個響應(yīng)。

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

• 1xx被認為是臨時響應(yīng)，其余的是最終響應(yīng)。

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

SIP - 報頭

報頭是傳達關(guān)于消息的信息的SIP消息的組件。 它被構(gòu)造為頭字段序列。

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

SIP頭 - 緊湊型

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

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

SIP頭格式

下圖顯示了典型SIP頭的結(jié)構(gòu)。

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

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

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

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

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

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

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

SDP的目的

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

• SDP是一個短結(jié)構(gòu)化文本描述。

• 它傳達會話的名稱和目的，媒體，協(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的當(dāng)前版本是0，所以有效的SDP消息將始終以v = 0開始。

起源

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

• 該字段包含 -

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

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

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

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

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

會話名稱和信息

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

URI

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

電子郵件地址和電話號碼

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

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

c =字段包含有關(guān)介質(zhì)連接的信息。

• 該字段包含 -

  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 =字段包含有關(guān)所需帶寬的信息。 它的形式 -

b = modifier:bandwidth - value

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

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

t =開始時間停止時間

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

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

媒體公告

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

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

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

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

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

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

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

屬性

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

SDP中的屬性可以是

• session level, or
• media level.

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

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

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響應(yīng)中列出它們的媒體能力。

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

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

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

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

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

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

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

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

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

例子

在以下示例中，呼叫者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應(yīng)答呼叫，為第一媒體字段選擇第二編解碼器，并且拒絕第二媒體字段，只想要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ī)則在以下部分中總結(jié)。

生成要約的規(guī)則

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

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

生成答案的規(guī)則

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

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

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

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

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

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

修改會話的規(guī)則

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

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

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

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

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

呼叫保持

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

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

SIP - 移動性

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

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

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

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

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

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

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

• 第二個REGISTER請求被路由回原始服務(wù)提供者，并提供新的服務(wù)提供者的AOR作為聯(lián)系URI。

如稍后在呼叫流程中所示，當(dāng)請求進入原始服務(wù)提供商的網(wǎng)絡(luò)時，INVITE被重定向到新的服務(wù)提供商，然后新的服務(wù)提供商將呼叫路由到用戶。

對于第一次注冊，包含設(shè)備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，其將被轉(zhuǎn)發(fā)到 sip:Tom@172.22.1.102 。 它到達Tom并允許建立會話。 定期兩個注冊都需要刷新。

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

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

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

• 這里，Tom檢測到一個新的網(wǎng)絡(luò)，

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

• 執(zhí)行re-INVITE以允許信令和媒體流到新的IP地址。

如果UA可以從兩個網(wǎng)絡(luò)接收媒體，則中斷可以忽略。 如果不是這種情況，則幾個媒體分組可能丟失，導(dǎo)致呼叫的輕微中斷。

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(與替換標(biāo)題)

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

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

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

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

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

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

• 使用新無線網(wǎng)絡(luò)的新對話框需要包括新的訪問代理服務(wù)器。

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

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

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

服務(wù)移動性

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

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

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

SIP - 分岔

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

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

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

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

我們有兩種類型的分叉 -

• Parallel Forking
• Sequential Forking

平行分叉

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

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

順序分岔

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

分支 - ID和標(biāo)簽

分支標(biāo)識幫助代理匹配對分叉請求的響應(yīng)。 沒有分支ID，代理服務(wù)器將無法了解分叉響應(yīng)。 分支標(biāo)識將在Via標(biāo)頭中可用。

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

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

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

呼叫支路和呼叫ID

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

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

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

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

語音郵件

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

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

• 通過使用SIP頭字段擴展

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

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

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

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

SIP - 代理和路由

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

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

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

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

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

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

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

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

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

通過和記錄路由

記錄路由

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

通過

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

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

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

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

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

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

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

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

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

SIP到PSTN

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

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

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

SIP到PSTN通過網(wǎng)關(guān)

下圖顯示了通過網(wǎng)關(guān)從SIP到PSTN的呼叫流。

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

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

• SIP電話直接向網(wǎng)關(guān)發(fā)送INVITE。

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

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

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

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

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

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

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

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

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

SIP - 編解碼器

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

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

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

市場上有許多編解碼器 - 有些是免費的，有些則需要許可。 編解碼器在聲音質(zhì)量上不同，并且?guī)捪鄳?yīng)地變化。

硬件設(shè)備如電話和網(wǎng)關(guān)支持幾種不同的編解碼器。 當(dāng)彼此交談時，他們談判使用哪個編解碼器。

在這里，在本章中，我們將討論一些流行的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網(wǎng)絡(luò)使用的相同的編解碼器，因此它提供最好的語音質(zhì)量。 然而，它消耗比其他編解碼器更多的帶寬。

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

G.729

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

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

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

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

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

G.723.1

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

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

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

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

GSM 06.10

GSM 06.10是為GSM移動網(wǎng)絡(luò)設(shè)計的編解碼器。 它也稱為GSM全速率。

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

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

SIP - B2BUA

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

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

B2BUA - 如何工作？

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

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

B2BUA維護其處理的調(diào)用的完整狀態(tài)。 B2BUA的每一側(cè)作為RFC 3261中規(guī)定的標(biāo)準(zhǔn)SIP網(wǎng)絡(luò)元件操作。

B2BUA的功能

B2BUA提供以下功能 -

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

• 網(wǎng)絡(luò)互通(可能與協(xié)議適配)

• 隱藏網(wǎng)絡(luò)內(nèi)部(私有地址，網(wǎng)絡(luò)拓撲等)

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

B2BUA的示例

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

一些防火墻內(nèi)置了ALG(應(yīng)用層網(wǎng)關(guān))功能，允許防火墻授權(quán)SIP和媒體流量，同時仍然保持高水平的安全性。

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

---