SIP中的SDP offeranswer交换初探.docVIP

1.引言 SDP的offer/answer模型本身独立 与于使用它的高层协议。SIP是使用offer/answer模型的应用之一。RFC 3264 [3] 定义了offer/answer模型，但没有规定使用那个SIP消息来携带一个offer或answer。这些被定义在SIP基本部分（RFC3261） 及其扩展RFCs中。 理论上，任何SIP消息的正文中都可以包含会话描述部分。但是，一个SIP中的会话描述并不一定是一个offer 或一个answer,只有符合在SIP标准RFCs中所描述的规则的会话描述才会被解释为一个offer或一个answer。目前，这些关于如何处理 offer/answer模型的规则被定义为若干个RFCs中 offer/answer模型定义会话的更新。在SIP中，对话（dialog）用于将offer/answer交换及其要更新的会话联系起来。换句话 说，只有在某个SIP对话中进行的offer/answer交换，才能更新该对话所管理的会话。 2、 六种Offer/Answer交换模式 在SIP消息中承载offer/answer的规则定义在RFC 3261[1], RFC 3262 [2] 以及RFC 3311 [4]中。在这些RFCs中定义了六种在SIP消息中交换offer/answer的模式。 模式1和模式2是在RFC3261中定义 的，用于不支持可靠临时响应消息（1xx-rel）的SIP实体之间的会话建立。 模式1：UAC在INVITE请求中携带一个 offer, UAS在200 INVITE响应中返回answer。这是最常用的一种模式。 模式2：UAC在INVITE请求中没有携带 offer。UAS在200 INVITE响应中携带一个offer，UAC通过ACK返回answer。这种模式通常用于3PCC中。 模式3、模式4、模式5都是在RFC3262中 定义的，可用在支持100rel（可靠临时响应）扩展的SIP实体之间。其中模式3、模式4可用于会话建立。模式5只能用于会话参数更新。它们利用 1xx-rel响应消息来携带offer或answer来建立会话。 模式3：UAC在INVITE请求中携带一个offer, UAS在1xx-rel响应中返回answer。这样，在呼叫完成之前（UAC没有收到200 INVITE消息）会话已建立。此后，会话参数还可以被更新，具体见模式5及模式6。 模 式4： UAC在INVITE请求中没有携带offer。UAS在1xx-rel可靠响应中携带一个offer，UAC通过PRACK返回answer。同样地， 在呼叫完成之前（UAC没有收到200 INVITE消息）会话已建立。此后，会话参数还可以被更新，具体见模式6。 模式5：当UAC与UAS采用模式3建立会话 后，呼叫并未完成（见模式3）。之后，可以使用模式5对已建立的会话参数进行更新：UAC在PRACK请求中携带一个新的offer, UAS在200 PRACK响应中返回answer。这样，会话参数便被更新。 模式6在RFC3311中定义，主要用于在早期 对话中更新已建立的会话参数，会话可能是通过模式3，也可能是通过模式4建立的。 模式6还可以对会话进行多次更新。例如，之前已通过模 式5更新过的会话还可以使用模式6更新；甚至通过模式6更新过的会话还可以再次使用模式6更新。 模 式6：UAC（或UAS）发送UPDATE请求其中携带一个新的offer, AS（或UAC）在200 UPDATE中返回一个offer。这样，会话参数便被更新。注意，UAS或UAC在发送UPDATE进行会话更新之前，必须保证之前的会话更新过程已经 完成。也就是说，发出的offer已经收到answer，或者收到的offer已经产生了answer。 3.总 结 INVITE方法提供了会话建立过程。 在 没有100rel选项时，会话建立过程非常简单，只能使用200INVITE响应消息传送会话描述，这些会话描述可能是answer(模式1),也可能是 offer（模式2）。无论使用何种模式，会话都只能呼叫完成后才能建立，在呼叫完成之前和呼叫完成之后只能有一个会话 – 用于最终通话的常规会话，因而，不能建立所谓的“早期媒体会话”。 在引入100rel选项后，会话建立过程变得复杂，通过可靠的临时消 息消息也可以传送会话描述，这些会话描述可能是answer(模式3),也可能是offer（模式4）。模式3和模式4都能够在呼叫完成前建立会话。并且 在呼叫完成之前，这些会话还可以被更新。这样就能够建立与常规会话不同的“早期媒体会话”，完成回铃音的产生等功能。 PRACK方法可 用于更新已建立的会话的参数（模式5） UPDATE方法可用于多次更新已建立的会话的参数（模式6），发起