SIP中的SDP offer/answer交換初探(轉載)

1.引言

SDP的offer/answer模型本身獨立與於使用它的高層協議。SIP是使用offer/answer模型的應用之一。RFC 3264 [3]定義了offer/answer模型，但沒有規定使用那個SIP消息來攜帶一個offer或answer。這些被定義在SIP基本部分（RFC3261）及其擴展RFCs中。

理論上，任何SIP消息的正文中都可以包含會話描述部分。但是，一個SIP中的會話描述並不一定是一個offer或一個answer,只有符合在SIP標準RFCs中所描述的規則的會話描述纔會被解釋爲一個offer或一個answer。目前，這些關於如何處理offer/answer模型的規則被定義爲若干個RFCs中

offer/answer模型定義會話的更新。在SIP中，對話（dialog）用於將offer/answer交換及其要更新的會話聯繫起來。換句話說，只有在某個SIP對話中進行的offer/answer交換，才能更新該對話所管理的會話。

2、六種Offer/Answer交換模式

在SIP消息中承載offer/answer的規則定義在RFC 3261[1], RFC 3262 [2] 以及RFC 3311 [4]中。在這些RFCs中定義了六種在SIP消息中交換offer/answer的模式。

模式1和模式2是在RFC3261中定義的，用於不支持可靠臨時響應消息（1xx-rel）的SIP實體之間的會話建立。

模式1：UAC在INVITE請求中攜帶一個offer, UAS在200 INVITE響應中返回answer。這是最常用的一種模式。

模式2：UAC在INVITE請求中沒有攜帶offer。UAS在200 INVITE響應中攜帶一個offer，UAC通過ACK返回answer。這種模式通常用於3PCC中。

模式3、模式4、模式5都是在RFC3262中定義的，可用在支持100rel（可靠臨時響應）擴展的SIP實體之間。其中模式3、模式4可用於會話建立。模式5只能用於會話參數更新。它們利用1xx-rel響應消息來攜帶offer或answer來建立會話。

模式3：UAC在INVITE請求中攜帶一個offer, UAS在1xx-rel響應中返回answer。這樣，在呼叫完成之前（UAC沒有收到200 INVITE消息）會話已建立。此後，會話參數還可以被更新，具體見模式5及模式6。

模式4：UAC在INVITE請求中沒有攜帶offer。UAS在1xx-rel可靠響應中攜帶一個offer，UAC通過PRACK返回answer。同樣地，在呼叫完成之前（UAC沒有收到200 INVITE消息）會話已建立。此後，會話參數還可以被更新，具體見模式6。

模式5：當UAC與UAS採用模式3建立會話後，呼叫並未完成（見模式3）。之後，可以使用模式5對已建立的會話參數進行更新：UAC在PRACK請求中攜帶一個新的offer, UAS在200 PRACK響應中返回answer。這樣，會話參數便被更新。

模式6在RFC3311中定義，主要用於在早期對話中更新已建立的會話參數，會話可能是通過模式3，也可能是通過模式4建立的。

模式6還可以對會話進行多次更新。例如，之前已通過模式5更新過的會話還可以使用模式6更新；甚至通過模式6更新過的會話還可以再次使用模式6更新。

模式6：UAC（或UAS）發送UPDATE請求其中攜帶一個新的offer, AS（或UAC）在200UPDATE中返回一個offer。這樣，會話參數便被更新。注意，UAS或UAC在發送UPDATE進行會話更新之前，必須保證之前的會話更新過程已經完成。也就是說，發出的offer已經收到answer，或者收到的offer已經產生了answer。

3.總結

INVITE方法提供了會話建立過程。

在沒有100rel選項時，會話建立過程非常簡單，只能使用200INVITE響應消息傳送會話描述，這些會話描述可能是answer(模式1),也可能是offer（模式2）。無論使用何種模式，會話都只能呼叫完成後才能建立，在呼叫完成之前和呼叫完成之後只能有一個會話 –用於最終通話的常規會話，因而，不能建立所謂的“早期媒體會話”。

在引入100rel選項後，會話建立過程變得複雜，通過可靠的臨時消息消息也可以傳送會話描述，這些會話描述可能是answer(模式3),也可能是offer（模式4）。模式3和模式4都能夠在呼叫完成前建立會話。並且在呼叫完成之前，這些會話還可以被更新。這樣就能夠建立與常規會話不同的“早期媒體會話”，完成回鈴音的產生等功能。

PRACK方法可用於更新已建立的會話的參數（模式5）

UPDATE方法可用於多次更新已建立的會話的參數（模式6），發起更新的可以是UAC也可以是UAS。

SIP中的早期媒體early media與回鈴音

1、早期媒體

無論是在PSTN還是在VoIP網絡中，一個呼叫的最終目的讓兩個用戶進行交談（conversation）。這裏我們將由用戶之間的交談所產生的媒體稱爲常規媒體（“regular media”）。

早期媒體（“early media”）是與常規媒體相比而言的。

通常，主叫用戶發起呼叫後用戶交談並不會立即開始（甚至可能最終沒有開始），等待時間一般是幾秒到幾十秒，這完全取決於被叫用戶的何時應答。在被叫應答之前，主叫用戶與網絡之間也可以有媒體流產生，與常規媒體相區別，這種媒體被稱爲早期媒體。

最典型的早期媒體就是回鈴音。其他形式的早期媒體還有排隊提示等等。早期媒體通常都是單向的（網絡>主叫），在SIP中也可能會有雙向的早期媒體。

 

2、早期媒體的傳送

要傳送媒體首先要建立一個媒體會話（Session）。建立媒體會話實際上就是通過SDPoffer/answer交換進行就會話的媒體參數進行協商的一個過程。在SIP中，媒體會話的建立過程通常首先伴隨着一個SIP對話（Dialog）的建立過程，一般情況下，媒體會話和SIP對話是同時建立的（通過SIP 200或ACK消息攜帶SDPanswer）。這種情況下，媒體會話直到被叫用戶摘機以後才能建立起來，只能用戶傳送用戶媒體，顯然無法傳送早期媒體。

要傳送早期媒體，必須在SIP對話尚未完全建立之時，即所謂的SIP早期對話狀態，完成媒體會話的建立。

怎樣在早期對話狀態建立媒體會話呢？SIP中支持兩種做法。

這兩種做法的關鍵不同在於：是否將傳送早期媒體的會話與傳送之後的通話媒體的會話明確地劃分清楚，區別開來。具體到協議上看，兩種做法都利用了200之前的 SIP消息，比如1xx-rel、PRACK、Update等等，來傳送SDP offer/answer， 但是這些SDPoffer/answer在SIP消息中的標明類型和處理指示是不同的。

做法1沒有明確區分出用於早期媒體的會話，實際上始終只有一個會話。具體到協議上看，用於建立（或修改）這個會話的SDP offer/answer 在SIP消息中的處理指示都是“Session”。

做法2專門建立一個用於傳送早期媒體的會話，並稱之爲早期會話（“early-session”）。具體到協議上看，用於建立（或修改）早期會話的SDP offer/answer SIP消息中的處理指示是“early-session”。並且，在一個SIP消息中可以同時攜帶處理指示分別爲“Session”和“early-session”的兩個SDP消息，各自獨立地用於早期會話的協商和正常會話的協商。

在做法1中，用同一個會話（在不同的時間段裏）來傳送早期媒體和通話媒體。在被叫摘機之前，這個會話可用於傳送早期媒體，在被叫摘機之後，這個會話又用於傳送通話媒體。倘若早期媒體和通話媒體的參數不同的話，需要重新進行媒體傳輸參數的協商，這需要一定的時間，可能會帶來媒體刪剪（mediaclipping）的問題。在做法2中，同時會存在兩個會話，分別用於傳送早期媒體和通話媒體，在被叫摘機之後，終端可以迅速從早期會話切換到正常會話，不會帶來媒體刪剪的問題。

 

根據它們的適用場景的不同，這兩種做法分別被稱爲網關模式和應用服務器模式。

3、回鈴音的產生

一個呼叫被髮起之後，當被叫終端振鈴時，主叫也會聽到某種聲音，提示正在等待被叫應答，這就是所謂回鈴音。回鈴音通常是某種標準的音頻信號，也可能是被叫用戶指定的某種特殊的聲音文件，例如音樂等等。在PSTN中，回鈴音通常是被叫的本地交換機產生，然後通過已建立的單向話路傳送給主叫話機，由主叫話機播放給主叫。

在SIP網絡中，被叫側可以早期媒體的形式向主叫提供回鈴音（如果被叫側不提供回鈴音，則主叫SIP終端會在本地產生回鈴音）。究竟使用前面所述的兩種做法的那一種來傳送早期媒體，下面分別討論。

3.1．網關模式

網關模式適用於被叫（即UAS）爲一個SIP網關的情形。具體的可能的情況通常如下圖所示：一個用戶在SIP終端上呼叫一個PSTN用戶，這個呼叫通過了一個SIP網關。就SIP呼叫而言，網關是被叫。

 

在這裏，回鈴音是由PSTN網產生的。但是在SIP域，SIP網關需要以早期媒體的形式將從PSTN網絡收到的回鈴音媒體傳送給主叫SIP終端。

這種情況下，從SIP域來看，回鈴音媒體流和之後的被叫媒體流的產生是同源的，都在SIP網關上。當被叫用戶摘機時，回鈴音媒體流自然地變成了用戶媒體流，因此可以使用網關模式，而不會帶來媒體刪剪的問題。

信令流程如下圖：

 

其中消息簡單說明如下：

1) INVITE請求中含有SDP offer，其處置類型爲“Session”。
網關收到INVITE後向PSTN發送IAM消息，然後在PCM話路上收到回鈴音，同時在信令上收到ACM消息。

2) 183響應中含有SDP answer，其處置類型爲“Session”。
此時，UAC與網關之間媒體會話建立，同時將回鈴音在這個會話上傳送給UAC。

3) UAC發送PRACK

4) 網關返回針對PRACK的200響應。

5) 被叫用戶應答，網關收到ANM後向SIP UAC返回200 INVITE響應。同時到SIP UAC上的會話上的回鈴音自動變成了從PSTN上收到的用戶話音。主被叫用戶開始雙向通話

6) SIP UAC發送ACK。

3.2．應用服務器模式

 

應用服務器模式適用於被叫（即UAS）是一個應用服務器的情形。具體的可能的情況通常如上圖所示：一個SIP用戶希望由運營商網絡（而非終端）來產生回鈴音。運營商通常使用網絡上的一個MRF資源提供回鈴音，並且需要一個應用服務器其來控制回鈴音的產生。

這種情況下，回鈴音媒體流與之後的被叫媒體流分別在MRF與被叫SIP終端上產生，顯然是不同的源。如果使用網關模式的話，將回鈴音媒體切換爲被叫媒體流必須在會話上進行媒體更改，媒體更改不能立即完成，這將會帶來媒體刪剪的問題。

使用應用服務器模式，則是同時建立了兩個會話，將回鈴音媒體切換爲被叫媒體流可以通過將當前會話從早期會話切換到正常會話上即可，能夠立即完成。

信令流程如下圖：

簡單說明如下：

1) INVITE請求中攜帶一個SDP作爲常規會話的offer
其Supported頭域中包含一個選項標籤“early-session”，表示主叫終端支持早期會話。

2) INVITE請求中攜帶之前收到的offer

3) 183響應中攜帶一個SDP作爲常規會話的answer。

4) 183中含有兩個SDP：

a) 一個是之前從被叫那裏收到的，作爲常規會話的answer；
此時常規會話被建立，但並沒有媒體被傳送。

b) 另一個作爲要建立的早期會話的的offer.

5) PRACK中攜帶一個SDP，作爲早期會話的answer
此時早期會話被建立，且有被早期媒體（回鈴音）傳送。

6) AS向被叫發送PRACK

7) 被叫向AS返回200 PRACK

8) AS向主叫返回200 PRACK

9) 被叫摘機，向AS發送200響應

10) AS向主叫發送200響應
此時常規會話上將會有媒體傳送，主叫UA播放常規會話上的媒體。

4、關於目前多媒體彩鈴的實現的簡單說明

目前中國網通及中國移動的多媒體體彩鈴業務的實現都主要採用了網關模式的實現方案（詳細流程參見相關技術規範），原因是很多SIP終端都不支持“early-session”選項標籤，無法使用應用服務器模式。

實際上，採用網關模式實現彩鈴會導致媒體刪剪等一些問題，最終應該會逐步過渡到理想的方案 – 應用服務器模式。

SIP Using SDP with Offer/Answer Model

http://blog.sina.com.cn/s/blog_4b839a1b010092tl.html

      根據RFC3261-13.2.1所述，SIP使用的Offer/Answer模型是建立在對話環境下的。RFC中還特意對Offer/Answer交互有限制：

1.        初始Offer必須在INVITE消息或者第一個可靠的非失敗型響應中。注：當時RFC3261中可靠效應只有2**，接下來將講到1**（除100外）也可爲可靠性效應。

2.        如果初始Offer在INVITE消息中，Answer必須出現在一個可靠的非失敗型響應中。可能在1**中就帶有Answer（但該Answer必須與之後的2**中的一致），UAC將忽略同一事務之後出現的迴應中的Answer。

3.        如果初始Offer出現在第一個可靠的非失敗型響應中，Answer必須出現在對該響應的確認消息中（ACK）。

4.        如果已經發送或接受對於第一個Offer的Answer，UAC可以繼續發送新的Offer；相反的，如果沒有確認對前一個Offer的Answer，不能發送新的Offer。

5.        如果已經發送或接受對於初始Offer的Answer，UAS禁止在之後同一個事務的響應消息中帶上新的Offer。

 

 

   根據RFC3262-5所述，對於Offer/Anwer模型引入了新的擴展。

1.        如果INVITE消息帶有Offer，UAS必須在一個可靠的非失敗型的響應中提供Answer。這將在呼叫完成之前建立好會話。同樣，Answer可以出現在1**中，因爲RFC3262提供了PRACK方法來保證1**消息爲可靠消息。

2.        如果UAC接收到1**中的Offer，必須在PRACK方法中帶有Answer。但是如果UAC收到1**中的Answer，則可能在PRACK帶上新的Offer。如果UAS接收到PRACK中的Offer，則必須在2**中帶上Answer。

3.        如果Offer/Answer交互成功的話，在INVITE事務沒有完成之前也能建立好會話。

4.        如果在1**中帶有Offer的話，UAS在沒有收到對1**的確認之前不能發送2**。

 

 

根據RFC3264所述，Offer建立媒體選擇項（高層如SIP提供），而Answer端可以接受或拒絕，取決於高層。UA可以通過新的Offer/Answer交互來進行會話更新，但舊的Offer/Answer交互未結束之前不可發起新的Offer。

1.        發起初始Offer：雖然SDP(RFC4566)允許在一個SDP消息中支持多個會話，但具有Offer/Answer模型的SDP消息只能包含一個對話描述。

2.        Offer可以包含0個或更多的媒體流（每個媒體流使用一個“m=”行和相關的屬性來描述的）。0個媒體流代表只是連接，之後可以通過新的Offer來更新會話。

3.        構建單點傳播媒體Offer：1）媒體流方向，包含recvonly、sendrecv（默認）、sendonly及inactive。但需要注意的是在RTP協議中，RTCP不會受該方向影響，即任何設置情況下均處於工作狀態。

4.        對於recvonly和sendrecv方向的媒體流來說，Offer中的端口號碼和地址指示了提供方接受媒體流的地方。對於sendonly方向的媒體流來說，Offer中的端口號碼和地址間接指示了提供方接受RTCP的地方（除非特殊說明，RTCP的端口比對應RTP端口高一位）。如果端口是0，則只提供、拒絕或終止媒體流。

5.        對於sendonly和sendrecv流來說，Answer可能對於同一編碼指示不同的負載類型編號（PayloadType Number），在這種情況下，Offer必須採取Answer中的編號值。

6.        對於RTP流，媒體描述需要使用"a=rtpmap"來映射RTP媒體負載類型編號，如果沒有對應的"a=rtpmap"行，則使用當前默認的配置（RFC1890）。

7.        “m=”行中所列的編碼必須採取優先順序排列。

8.        對於Offer中的每個“m=”行，Answer中必須有對應的“m=”行。Answer中的“t=”行必須與Offer行的一致。

9.        拒絕某個Offer的流，該流的端口值必須設置爲0.

10.    Offer如果是sendonly，則Answer必須爲recvonly或者inactive；Offer如果是recvonly，則Answer必須爲sendonly或者inactive；Offer如果是sendrecv，則Answer必須爲sendrecv、recvonly、sendonly或者inactive；Offer如果是inactive，則Answer必須爲inactive。

11.    即使Offer是senonly型，Answer的地址和端口也必須存在，因爲需要傳送RTCP。

12.    如果是RTP，Offer使用特定負載編號來與某編碼相對應，Answer應該保持這種對應關係。

13.    Answer中的“m=”行編碼應具有優先順序，以便Offer能採用最高優先級的選項。但即便如此，建議Answer採取與Offer相同的優先順序。

14.    ptime指示接受的打包間隔，但並不要求雙方的ptime值一致。但發送媒體流時應該按照ptime指示的打包間隔來發送。

15.    如果是RTP流，Answer應該採用Offer提供的負載編碼編號。

16.    當Offer收到Answer後，必須採用Answer中的媒體類型中的一個，最後應該採用排列的第一個。

按照上述，

Offer/Answer模型的交互情況將如下：

圖1 Offer/Answer模型交互圖

SIP使用Offer/Answer模型的交互情況如下：

圖2 SIP利用Offer/Answer模型交互1圖

圖3 SIP利用Offer/Answer模型交互2圖

圖4 SIP利用Offer/Answer模型交互3圖

圖5 SIP利用Offer/Answer模型交互4圖

注：圖中NULL代表Offer/Answer模型已經完成交互，並不是SDP爲空，此時SDP內媒體選項已經確定，所以不會再改變。