<object id="61p7e"></object>
  • <object id="61p7e"></object>

    1. 淘豆網
      1/9
      0/100
      您的瀏覽器不支持進度條
      更多>>該用戶其他文檔
      下載所得到的文件列表
      SIP中的SDP offer-answer交換初探.doc
      文檔介紹:
      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。中。
      模式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)在200 UPDATE中返回一個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)。建立媒體會話實際上就是通過SDP offer/answer交換進行就會話的媒體參數進行協商的一個過程。在SIP中,媒體會話的建立過程通常首先伴隨著一個SIP對話(Dialog)的建立過程,一般情況下,媒體會話和SIP對話是同時建立的(通過SIP 200或ACK消息攜帶SDP answer)。這種情況下,媒體會話直到被叫用戶摘機以后才能建立起來,只能用戶傳送用戶媒體,顯然無法傳送早期媒體。
      要傳送早期媒體,必須在SIP對話尚未完全建立之時,即所謂的SIP早期對話狀態,完成媒體會話的建立。
      怎樣在早期對話狀態建立媒體會話呢?SIP中支持兩種做法。
      這兩種做法的關鍵不同在于:是否將傳送早期媒體的會話與傳送之后的通話媒體的會話明確地劃分清楚,區別開來。具體到協議上看,兩種做法都利用了 200之前的 SIP消息,比如1xx-rel、PRACK、Update等等,來傳送SDP offer/answer, 但是這些SDP offer/answer在SIP消息中的標明類型和處理指示是不同的。
      做法1沒有明確區分出用于早期媒體的會話,實際上始終只有一個會話。具體到協議上看,用于建立(或修改)這個會話的SDP offer/answer 在SIP消息中的處理指示 內容來自淘豆網www.pl383.com轉載請標明出處.
      夜生活交友