SIP Offer/Answer交互

IETF的"draft-ietf-sipping-sip-offeranswer-01.txt"

 

              Offer                Answer             RFC    Ini Est Early 

-----------------------------------------------------------------

       1. INVITE Req.          2xx INVITE Resp.     RFC 3261  O   O    X 

       2. 2xx INVITE Resp.     ACK Req.             RFC 3261  O   O    X 

       3. INVITE Req.          1xx-rel INVITE Resp. RFC 3262  O   O    X 

       4. 1xx-rel INVITE Resp. PRACK Req.           RFC 3262  O   O    X 

       5. PRACK Req.           200 PRACK Resp.      RFC 3262  X   O    O 

       6. UPDATE Req.          2xx UPDATE Resp.     RFC 3311  X   O    O

'Ini':表示模式能否用於在創建會話的情況下進行offer/answer的交互。'O'表示這種模式可以用於初始offer/answer交互，'X'表示這種模式不能用於初始offer/answer交互。只有初始INVITE請求能用於創建多媒體會話的offer/answer交互。

 

'Est':表示模式能否用於能否更新已建立會話。

 

'Early':表示模式能否在已創建的早期對話中更新會話。

 

使用SIP進行Offer/Answer交互的基本原則；

(1)    同一請求消息的所有可靠響應消息中只能有一個可靠響應消息帶 有SDP。

(2)    如果INVITE請求消息帶有SDP，那麼必須通過可靠的18X、200攜帶SDP Answer，之後不能通過任何可靠響應消息攜帶SDP。

(3)    如果INVITE請求消息不帶SDP，那麼只能必須通過第一個可靠的18X、200消息攜帶SDP Offer，而且必須通過對攜帶SDP Offer的響應消息的確認消息攜帶SDP Answer。如下：

18X消息攜帶SDP Offer，對該18X的PRACK消息攜帶SDP Answer。

200消息攜帶SDP Offer，ACK消息攜帶SDP Answer。

    

                圖：發送初始INVITE請求，攜帶SDP

當收到的1xx響應中，攜帶了SDP，但沒有要求可靠傳輸，該SDP不作爲answer，不作特殊處理；

當收到的1xx響應中，未攜帶SDP，但要求可靠傳輸，發送PRACK請求，該請求中不能再發送新的offer；

當收到的1xx響應中，攜帶了SDP，並要求可靠傳輸，則完成一次offer/answer交互，後續的1xx或最終響應中不能包含SDP；

            圖：發送初始INVITE請求，不攜帶SDP

UAC收到的1xx響應中攜帶了SDP，但是未要求可靠傳輸，該SDP不作爲offer，也不處理；

UAC收到第一個要求可靠傳輸，並攜帶了SDP的臨時響應（1xx）時，該SDP作爲offer，UAC發送PRACK請求，並攜帶answer，完成一次offer/answer；

後續的臨時響應1xx或最終響應2xx中不能再攜帶SDP，如果UAC再次收到可靠傳輸的臨時響應或最終響應中攜帶SDP，將其忽略，不再作爲offer；

 圖 消息到達順序交叉

 圖 Offer發生同搶

消息交叉與同搶的區別在於，消息交叉從SIP信令上是能區分後續的消息先於前面的消息到達，而同搶是消息的順序是正確的，但是雙方都攜帶了offer。