本帖最后由 siyzhang 于 2015-7-16 16:32 编辑
RFC3261、RFC3264的中文概要，关于SIP offer/answer 模型的介绍。看完后对SIP协议会有更好的了解。
{:3_49:}
想要更深入地了解，可以看看英文原版，完整的RFC3261、RFC3264请点击下面的链接进入
https://www.ietf.org/rfc/rfc3261.txt
https://www.ietf.org/rfc/rfc3264.txt
RFC3261、RFC3264的中文概要，关于SIP offer/answer 模型的介绍。看完后对SIP协议会有更好的了解。
{:3_49:}
想要更深入地了解，可以看看英文原版，完整的RFC3261、RFC3264请点击下面的链接进入
https://www.ietf.org/rfc/rfc3261.txt
https://www.ietf.org/rfc/rfc3264.txt
IP Using SDP with Offer/Answer Model
根据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内媒体选项已经确定，所以不会再改变。
