1.引言
SDP的offer/answer模型本身獨立與于使用它的高層協(xié)議。SIP是使用offer/answer模型的應用之一。RFC 3264 [3] 定義了offer/answer模型，但沒有規(guī)定使用那個SIP消息來攜帶一個offer或answer。這些被定義在SIP基本部分（RFC3261）及其擴展RFCs中。
理論上，任何SIP消息的正文中都可以包含會話描述部分。但是，一個SIP中的會話描述并不一定是一個offer 或一個answer,只有符合在SIP標準RFCs中所描述的規(guī)則的會話描述才會被解釋為一個offer或一個answer。目前，這些關(guān)于如何處理 offer/answer模型的規(guī)則被定義為若干個RFCs中
offer/answer模型定義會話的更新。在SIP中，對話（dialog）用于將offer/answer交換及其要更新的會話聯(lián)系起來。換句話說，只有在某個SIP對話中進行的offer/answer交換，才能更新該對話所管理的會話。2、六種Offer/Answer交換模式
在SIP消息中承載offer/answer的規(guī)則定義在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只能用于會話參數(shù)更新。它們利用1xx-rel響應消息來攜帶offer或answer來建立會話。
模式3：UAC在INVITE請求中攜帶一個offer, UAS在1xx-rel響應中返回answer。這樣，在呼叫完成之前（UAC沒有收到200 INVITE消息）會話已建立。此后，會話參數(shù)還可以被更新，具體見模式5及模式6。
模式4： UAC在INVITE請求中沒有攜帶offer。UAS在1xx-rel可靠響應中攜帶一個offer，UAC通過PRACK返回answer。同樣地，在呼叫完成之前（UAC沒有收到200 INVITE消息）會話已建立。此后，會話參數(shù)還可以被更新，具體見模式6。
模式5：當UAC與UAS采用模式3建立會話后，呼叫并未完成（見模式3）。之后，可以使用模式5對已建立的會話參數(shù)進行更新：UAC在PRACK請求中攜帶一個新的offer, UAS在200 PRACK響應中返回answer。這樣，會話參數(shù)便被更新。
模式6在RFC3311中定義，主要用于在早期對話中更新已建立的會話參數(shù)，會話可能是通過模式3，也可能是通過模式4建立的。
模式6還可以對會話進行多次更新。例如，之前已通過模式5更新過的會話還可以使用模式6更新；甚至通過模式6更新過的會話還可以再次使用模式6更新。
模式6：UAC（或UAS）發(fā)送UPDATE請求其中攜帶一個新的offer, AS（或UAC）在200 UPDATE中返回一個offer。這樣，會話參數(shù)便被更新。注意，UAS或UAC在發(fā)送UPDATE進行會話更新之前，必須保證之前的會話更新過程已經(jīng)完成。也就是說，發(fā)出的offer已經(jīng)收到answer，或者收到的offer已經(jīng)產(chǎn)生了answer。
3.總結(jié)
INVITE方法提供了會話建立過程。
在沒有100rel選項時，會話建立過程非常簡單，只能使用200INVITE響應消息傳送會話描述，這些會話描述可能是answer(模式1),也可能是 offer（模式2）。無論使用何種模式，會話都只能呼叫完成后才能建立，在呼叫完成之前和呼叫完成之后只能有一個會話 – 用于最終通話的常規(guī)會話，因而，不能建立所謂的“早期媒體會話”。
在引入100rel選項后，會話建立過程變得復雜，通過可靠的臨時消息消息也可以傳送會話描述，這些會話描述可能是answer(模式3),也可能是offer（模式4）。模式3和模式4都能夠在呼叫完成前建立會話。并且在呼叫完成之前，這些會話還可以被更新。這樣就能夠建立與常規(guī)會話不同的“早期媒體會話”，完成回鈴音的產(chǎn)生等功能。
PRACK方法可用于更新已建立的會話的參數(shù)（模式5）
UPDATE方法可用于多次更新已建立的會話的參數(shù)（模式6），發(fā)起更新的可以是UAC也可以是UAS。
SIP中的早期媒體early media與回鈴音
1、早期媒體
無論是在PSTN還是在VoIP網(wǎng)絡(luò)中，一個呼叫的最終目的讓兩個用戶進行交談（conversation）。這里我們將由用戶之間的交談所產(chǎn)生的媒體稱為常規(guī)媒體（“regular media”）。
早期媒體（“early media”）是與常規(guī)媒體相比而言的。
通常，主叫用戶發(fā)起呼叫后用戶交談并不會立即開始（甚至可能最終沒有開始），等待時間一般是幾秒到幾十秒，這完全取決于被叫用戶的何時應答。在被叫應答之前，主叫用戶與網(wǎng)絡(luò)之間也可以有媒體流產(chǎn)生，與常規(guī)媒體相區(qū)別，這種媒體被稱為早期媒體。
最典型的早期媒體就是回鈴音。其他形式的早期媒體還有排隊提示等等。早期媒體通常都是單向的（網(wǎng)絡(luò)>主叫），在SIP中也可能會有雙向的早期媒體。
2、早期媒體的傳送
要傳送媒體首先要建立一個媒體會話（Session）。建立媒體會話實際上就是通過SDP offer/answer交換進行就會話的媒體參數(shù)進行協(xié)商的一個過程。在SIP中，媒體會話的建立過程通常首先伴隨著一個SIP對話（Dialog）的建立過程，一般情況下，媒體會話和SIP對話是同時建立的（通過SIP 200或ACK消息攜帶SDP answer）。這種情況下，媒體會話直到被叫用戶摘機以后才能建立起來，只能用戶傳送用戶媒體，顯然無法傳送早期媒體。
要傳送早期媒體，必須在SIP對話尚未完全建立之時，即所謂的SIP早期對話狀態(tài)，完成媒體會話的建立。
怎樣在早期對話狀態(tài)建立媒體會話呢？SIP中支持兩種做法。
這兩種做法的關(guān)鍵不同在于：是否將傳送早期媒體的會話與傳送之后的通話媒體的會話明確地劃分清楚，區(qū)別開來。具體到協(xié)議上看，兩種做法都利用了 200之前的 SIP消息，比如1xx-rel、PRACK、Update等等，來傳送SDP offer/answer， 但是這些SDP offer/answer在SIP消息中的標明類型和處理指示是不同的。
做法1沒有明確區(qū)分出用于早期媒體的會話，實際上始終只有一個會話。具體到協(xié)議上看，用于建立（或修改）這個會話的SDP offer/answer 在SIP消息中的處理指示都是“Session”。
做法2專門建立一個用于傳送早期媒體的會話，并稱之為早期會話（“early-session”）。具體到協(xié)議上看，用于建立（或修改）早期會話的 SDP offer/answer SIP 消息中的處理指示是“early-session”。并且，在一個SIP消息中可以同時攜帶處理指示分別為“Session”和“early- session”的兩個SDP消息，各自獨立地用于早期會話的協(xié)商和正常會話的協(xié)商。
在做法1中，用同一個會話（在不同的時間段里）來傳送早期媒體和通話媒體。在被叫摘機之前，這個會話可用于傳送早期媒體，在被叫摘機之后，這個會話又用于傳送通話媒體。倘若早期媒體和通話媒體的參數(shù)不同的話，需要重新進行媒體傳輸參數(shù)的協(xié)商，這需要一定的時間，可能會帶來媒體刪剪（media clipping）的問題。在做法2中，同時會存在兩個會話，分別用于傳送早期媒體和通話媒體，在被叫摘機之后，終端可以迅速從早期會話切換到正常會話，不會帶來媒體刪剪的問題。
根據(jù)它們的適用場景的不同，這兩種做法分別被稱為網(wǎng)關(guān)模式和應用服務器模式。
3、回鈴音的產(chǎn)生
一個呼叫被發(fā)起之后，當被叫終端振鈴時，主叫也會聽到某種聲音，提示正在等待被叫應答，這就是所謂回鈴音?；剽徱敉ǔＪ悄撤N標準的音頻信號，也可能是被叫用戶指定的某種特殊的聲音文件，例如音樂等等。在PSTN中，回鈴音通常是被叫的本地交換機產(chǎn)生，然后通過已建立的單向話路傳送給主叫話機，由主叫話機播放給主叫。
在SIP網(wǎng)絡(luò)中，被叫側(cè)可以早期媒體的形式向主叫提供回鈴音（如果被叫側(cè)不提供回鈴音，則主叫SIP終端會在本地產(chǎn)生回鈴音）。究竟使用前面所述的兩種做法的那一種來傳送早期媒體，下面分別討論。
3.1．網(wǎng)關(guān)模式
網(wǎng)關(guān)模式適用于被叫（即UAS）為一個SIP網(wǎng)關(guān)的情形。具體的可能的情況通常如下圖所示：一個用戶在SIP終端上呼叫一個PSTN用戶，這個呼叫通過了一個SIP網(wǎng)關(guān)。就SIP呼叫而言，網(wǎng)關(guān)是被叫。
在這里，回鈴音是由PSTN網(wǎng)產(chǎn)生的。但是在SIP域，SIP網(wǎng)關(guān)需要以早期媒體的形式將從PSTN網(wǎng)絡(luò)收到的回鈴音媒體傳送給主叫SIP終端。
這種情況下，從SIP域來看，回鈴音媒體流和之后的被叫媒體流的產(chǎn)生是同源的，都在SIP網(wǎng)關(guān)上。當被叫用戶摘機時，回鈴音媒體流自然地變成了用戶媒體流，因此可以使用網(wǎng)關(guān)模式，而不會帶來媒體刪剪的問題。
信令流程如下圖：
其中消息簡單說明如下：
1) INVITE請求中含有SDP offer，其處置類型為“Session”。
網(wǎng)關(guān)收到INVITE后向PSTN發(fā)送IAM消息，然后在PCM話路上收到回鈴音，同時在信令上收到ACM消息。
2) 183響應中含有SDP answer，其處置類型為“Session”。
此時，UAC與網(wǎng)關(guān)之間媒體會話建立，同時將回鈴音在這個會話上傳送給UAC。
3) UAC發(fā)送PRACK
4) 網(wǎng)關(guān)返回針對PRACK的200響應。
5) 被叫用戶應答，網(wǎng)關(guān)收到ANM后向SIP UAC返回200 INVITE響應。同時到SIP UAC上的會話上的回鈴音自動變成了從PSTN上收到的用戶話音。主被叫用戶開始雙向通話
6) SIP UAC發(fā)送ACK。
3.2．應用服務器模式
應用服務器模式適用于被叫（即UAS）是一個應用服務器的情形。具體的可能的情況通常如上圖所示：一個SIP用戶希望由運營商網(wǎng)絡(luò)（而非終端）來產(chǎn)生回鈴音。運營商通常使用網(wǎng)絡(luò)上的一個MRF資源提供回鈴音，并且需要一個應用服務器其來控制回鈴音的產(chǎn)生。
這種情況下，回鈴音媒體流與之后的被叫媒體流分別在MRF與被叫SIP終端上產(chǎn)生，顯然是不同的源。如果使用網(wǎng)關(guān)模式的話，將回鈴音媒體切換為被叫媒體流必須在會話上進行媒體更改，媒體更改不能立即完成，這將會帶來媒體刪剪的問題。
使用應用服務器模式，則是同時建立了兩個會話，將回鈴音媒體切換為被叫媒體流可以通過將當前會話從早期會話切換到正常會話上即可，能夠立即完成。
信令流程如下圖：
簡單說明如下：
1) INVITE請求中攜帶一個SDP作為常規(guī)會話的offer
其Supported頭域中包含一個選項標簽“early-session”，表示主叫終端支持早期會話。
2) INVITE請求中攜帶之前收到的offer
3) 183響應中攜帶一個SDP作為常規(guī)會話的answer。
4) 183中含有兩個SDP：
a) 一個是之前從被叫那里收到的，作為常規(guī)會話的answer；
此時常規(guī)會話被建立，但并沒有媒體被傳送。
b) 另一個作為要建立的早期會話的的offer.
5) PRACK中攜帶一個SDP，作為早期會話的answer
此時早期會話被建立，且有被早期媒體（回鈴音）傳送。
6) AS向被叫發(fā)送PRACK
7) 被叫向AS返回200 PRACK
8) AS向主叫返回200 PRACK
9) 被叫摘機，向AS發(fā)送200響應
10) AS向主叫發(fā)送200響應
此時常規(guī)會話上將會有媒體傳送，主叫UA播放常規(guī)會話上的媒體。
4、關(guān)于目前多媒體彩鈴的實現(xiàn)的簡單說明
目前中國網(wǎng)通及中國移動的多媒體體彩鈴業(yè)務的實現(xiàn)都主要采用了網(wǎng)關(guān)模式的實現(xiàn)方案（詳細流程參見相關(guān)技術(shù)規(guī)范），原因是很多SIP終端都不支持“early-session”選項標簽，無法使用應用服務器模式。
實際上，采用網(wǎng)關(guān)模式實現(xiàn)彩鈴會導致媒體刪剪等一些問題，最終應該會逐步過渡到理想的方案 – 應用服務器模式。
SIP Using SDP with Offer/Answer Model
http://blog.sina.com.cn/s/blog_4b839a1b010092tl.html
1.
2.
3.
4.
5.
1.
2.
3.
4.
根據(jù)RFC3264所述，Offer建立媒體選擇項（高層如SIP提供），而Answer端可以接受或拒絕，取決于高層。UA可以通過新的Offer/Answer交互來進行會話更新，但舊的Offer/Answer交互未結(jié)束之前不可發(fā)起新的Offer。
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
按照上述，
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模型已經(jīng)完成交互，并不是SDP為空，此時SDP內(nèi)媒體選項已經(jīng)確定，所以不會再改變。
