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。