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。


Offer/Answer交互" TITLE="SIP Offer/Answer交互" />

图：发送初始INVITE请求，携带SDP

当收到的1xx响应中，携带了SDP，但没有要求可靠传输，该SDP不作为answer，不作特殊处理；
当收到的1xx响应中，未携带SDP，但要求可靠传输，发送PRACK请求，该请求中不能再发送新的offer；

当收到的1xx响应中，携带了SDP，并要求可靠传输，则完成一次offer/answer交互，后续的1xx或最终响应中不能包含SDP；


Offer/Answer交互" TITLE="SIP Offer/Answer交互" />

图：发送初始INVITE请求，不携带SDP

UAC收到的1xx响应中携带了SDP，但是未要求可靠传输，该SDP不作为offer，也不处理；

UAC收到第一个要求可靠传输，并携带了SDP的临时响应（1xx）时，该SDP作为offer，UAC发送PRACK请求，并携带answer，完成一次offer/answer；

后续的临时响应1xx或最终响应2xx中不能再携带SDP，如果UAC再次收到可靠传输的临时响应或最终响应中携带SDP，将其忽略，不再作为offer；


Offer/Answer交互" TITLE="SIP Offer/Answer交互" /> 图
消息到达顺序交叉


Offer/Answer交互" TITLE="SIP Offer/Answer交互" /> 图
Offer发生同抢

消息交叉与同抢的区别在于，消息交叉从SIP信令上是能区分后续的消息先于前面的消息到达，而同抢是消息的顺序是正确的，但是双方都携带了offer。