根据RFC3261-13.2.1所述，SIP使用的Offer/Answer模型是建立在对话环境下的。RFC中还特意对Offer/Answer交互有限制：

1. 初始Offer必须在INVITE消息或者第一个可靠的非失败型响应中。注：当时RFC3261中可靠效应只有2**，接下来将讲到1**（除100外）也可为可靠性效应。

2. 如果初始Offer在INVITE消息中，Answer必须出现在一个可靠的非失败型响应中。可能在1**中就带有Answer（但该Answer必须与之后的2**中的一致），UAC将忽略同一事务之后出现的回应中的Answer。

3. 如果初始Offer出现在第一个可靠的非失败型响应中，Answer必须出现在对该响应的确认消息中（ACK）。

4. 如果已经发送或接受对于第一个Offer的Answer，UAC可以继续发送新的Offer；相反的，如果没有确认对前一个Offer的Answer，不能发送新的Offer。

5. 如果已经发送或接受对于初始Offer的Answer，UAS禁止在之后同一个事务的响应消息中带上新的Offer。

根据RFC3262-5所述，对于Offer/Anwer模型引入了新的扩展。

1. 如果INVITE消息带有Offer，UAS必须在一个可靠的非失败型的响应中提供Answer。这将在呼叫完成之前建立好会话。同样，Answer可以出现在1**中，因为RFC3262提供了PRACK方法来保证1**消息为可靠消息。

2. 如果UAC接收到1**中的Offer，必须在PRACK方法中带有Answer。但是如果UAC收到1**中的Answer，则可能在PRACK带上新的Offer。如果UAS接收到PRACK中的Offer，则必须在2**中带上Answer。

3. 如果Offer/Answer交互成功的话，在INVITE事务没有完成之前也能建立好会话。

4. 如果在1**中带有Offer的话，UAS在没有收到对1**的确认之前不能发送2**。

根据RFC3264所述，Offer建立媒体选择项（高层如SIP提供），而Answer端可以接受或拒绝，取决于高层。UA可以通过新的Offer/Answer交互来进行会话更新，但旧的Offer/Answer交互未结束之前不可发起新的Offer。

1. 发起初始Offer：虽然SDP(RFC4566)允许在一个SDP消息中支持多个会话，但具有Offer/Answer模型的SDP消息只能包含一个对话描述。

2. Offer可以包含0个或更多的媒体流（每个媒体流使用一个“m=”行和相关的属性来描述的）。0个媒体流代表只是连接，之后可以通过新的Offer来更新会话。

3. 构建单点传播媒体Offer：1）媒体流方向，包含recvonly、sendrecv（默认）、sendonly及inactive。但需要注意的是在RTP协议中，RTCP不会受该方向影响，即任何设置情况下均处于工作状态。

4. 对于recvonly和sendrecv方向的媒体流来说，Offer中的端口号码和地址指示了提供方接受媒体流的地方。对于sendonly方向的媒体 流来说，Offer中的端口号码和地址间接指示了提供方接受RTCP的地方（除非特殊说明，RTCP的端口比对应RTP端口高一位）。如果端口是0，则只 提供、拒绝或终止媒体流。

5. 对于sendonly和sendrecv流来说，Answer可能对于同一编码指示不同的负载类型编号（Payload Type Number），在这种情况下，Offer必须采取Answer中的编号值。

6. 对于RTP流，媒体描述需要使用"a=rtpmap"来映射RTP媒体负载类型编号，如果没有对应的"a=rtpmap"行，则使用当前默认的配置（RFC 1890）。

7. “m=”行中所列的编码必须采取优先顺序排列。

8. 对于Offer中的每个“m=”行，Answer中必须有对应的“m=”行。Answer中的“t=”行必须与Offer行的一致。

9. 拒绝某个Offer的流，该流的端口值必须设置为0.

10. Offer如果是sendonly，则Answer必须为recvonly或者inactive；Offer如果是recvonly，则Answer必须 为sendonly或者inactive；Offer如果是sendrecv，则Answer必须为sendrecv、recvonly、 sendonly或者inactive；Offer如果是inactive，则Answer必须为inactive。

11. 即使Offer是senonly型，Answer的地址和端口也必须存在，因为需要传送RTCP。

12. 如果是RTP，Offer使用特定负载编号来与某编码相对应，Answer应该保持这种对应关系。

13. Answer中的“m=”行编码应具有优先顺序，以便Offer能采用最高优先级的选项。但即便如此，建议Answer采取与Offer相同的优先顺序。

14. ptime指示接受的打包间隔，但并不要求双方的ptime值一致。但发送媒体流时应该按照ptime指示的打包间隔来发送。

15. 如果是RTP流，Answer应该采用Offer提供的负载编码编号。

16. 当Offer收到Answer后，必须采用Answer中的媒体类型中的一个，最后应该采用排列的第一个。

按照上述，

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模型已经完成交互，并不是SDP为空，此时SDP内媒体选项已经确定，所以不会再改变。