SIP中的SDP offer/answer交换初探

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），发起更新的可以是UAC也可以是UAS。

SIP中的早期媒体early media与回铃音

1、早期媒体

无论是在PSTN还是在VoIP网络中，一个呼叫的最终目的让两个用户进行交谈（conversation）。这里我们将由用户之间的交谈所产生的媒体称为常规媒体（“regular media”）。

早期媒体（“early media”）是与常规媒体相比而言的。

通常，主叫用户发起呼叫后用户交谈并不会立即开始（甚至可能最终没有开始），等待时间一般是几秒到几十秒，这完全取决于被叫用户的何时应答。在被叫应答之前，主叫用户与网络之间也可以有媒体流产生，与常规媒体相区别，这种媒体被称为早期媒体。

最典型的早期媒体就是回铃音。其他形式的早期媒体还有排队提示等等。早期媒体通常都是单向的（网络>主叫），在SIP中也可能会有双向的早期媒体。

 

2、早期媒体的传送

要传送媒体首先要建立一个媒体会话（Session）。建立媒体会话实际上就是通过SDP offer/answer交换进行就会话的媒体参数进行协商的一个过程。在SIP中，媒体会话的建立过程通常首先伴随着一个SIP对话（Dialog）的建立过程，一般情况下，媒体会话和SIP对话是同时建立的（通过SIP 200或ACK消息携带SDP answer）。这种情况下，媒体会话直到被叫用户摘机以后才能建立起来，只能用户传送用户媒体，显然无法传送早期媒体。

要传送早期媒体，必须在SIP对话尚未完全建立之时，即所谓的SIP早期对话状态，完成媒体会话的建立。

怎样在早期对话状态建立媒体会话呢？SIP中支持两种做法。

这两种做法的关键不同在于：是否将传送早期媒体的会话与传送之后的通话媒体的会话明确地划分清楚，区别开来。具体到协议上看，两种做法都利用了 200之前的 SIP消息，比如1xx-rel、PRACK、Update等等，来传送SDP offer/answer， 但是这些SDP offer/answer在SIP消息中的标明类型和处理指示是不同的。

做法1没有明确区分出用于早期媒体的会话，实际上始终只有一个会话。具体到协议上看，用于建立（或修改）这个会话的SDP offer/answer 在SIP消息中的处理指示都是“Session”。

做法2专门建立一个用于传送早期媒体的会话，并称之为早期会话（“early-session”）。具体到协议上看，用于建立（或修改）早期会话的 SDP offer/answer SIP 消息中的处理指示是“early-session”。并且，在一个SIP消息中可以同时携带处理指示分别为“Session”和“early- session”的两个SDP消息，各自独立地用于早期会话的协商和正常会话的协商。

在做法1中，用同一个会话（在不同的时间段里）来传送早期媒体和通话媒体。在被叫摘机之前，这个会话可用于传送早期媒体，在被叫摘机之后，这个会话又用于传送通话媒体。倘若早期媒体和通话媒体的参数不同的话，需要重新进行媒体传输参数的协商，这需要一定的时间，可能会带来媒体删剪（media clipping）的问题。在做法2中，同时会存在两个会话，分别用于传送早期媒体和通话媒体，在被叫摘机之后，终端可以迅速从早期会话切换到正常会话，不会带来媒体删剪的问题。

 

根据它们的适用场景的不同，这两种做法分别被称为网关模式和应用服务器模式。

3、回铃音的产生

一个呼叫被发起之后，当被叫终端振铃时，主叫也会听到某种声音，提示正在等待被叫应答，这就是所谓回铃音。回铃音通常是某种标准的音频信号，也可能是被叫用户指定的某种特殊的声音文件，例如音乐等等。在PSTN中，回铃音通常是被叫的本地交换机产生，然后通过已建立的单向话路传送给主叫话机，由主叫话机播放给主叫。

在SIP网络中，被叫侧可以早期媒体的形式向主叫提供回铃音（如果被叫侧不提供回铃音，则主叫SIP终端会在本地产生回铃音）。究竟使用前面所述的两种做法的那一种来传送早期媒体，下面分别讨论。

3.1．网关模式

网关模式适用于被叫（即UAS）为一个SIP网关的情形。具体的可能的情况通常如下图所示：一个用户在SIP终端上呼叫一个PSTN用户，这个呼叫通过了一个SIP网关。就SIP呼叫而言，网关是被叫。

 

在这里，回铃音是由PSTN网产生的。但是在SIP域，SIP网关需要以早期媒体的形式将从PSTN网络收到的回铃音媒体传送给主叫SIP终端。

这种情况下，从SIP域来看，回铃音媒体流和之后的被叫媒体流的产生是同源的，都在SIP网关上。当被叫用户摘机时，回铃音媒体流自然地变成了用户媒体流，因此可以使用网关模式，而不会带来媒体删剪的问题。

信令流程如下图：

 

其中消息简单说明如下：

1) INVITE请求中含有SDP offer，其处置类型为“Session”。
网关收到INVITE后向PSTN发送IAM消息，然后在PCM话路上收到回铃音，同时在信令上收到ACM消息。

2) 183响应中含有SDP answer，其处置类型为“Session”。
此时，UAC与网关之间媒体会话建立，同时将回铃音在这个会话上传送给UAC。

3) UAC发送PRACK

4) 网关返回针对PRACK的200响应。

5) 被叫用户应答，网关收到ANM后向SIP UAC返回200 INVITE响应。同时到SIP UAC上的会话上的回铃音自动变成了从PSTN上收到的用户话音。主被叫用户开始双向通话

6) SIP UAC发送ACK。

3.2．应用服务器模式

 

应用服务器模式适用于被叫（即UAS）是一个应用服务器的情形。具体的可能的情况通常如上图所示：一个SIP用户希望由运营商网络（而非终端）来产生回铃音。运营商通常使用网络上的一个MRF资源提供回铃音，并且需要一个应用服务器其来控制回铃音的产生。

这种情况下，回铃音媒体流与之后的被叫媒体流分别在MRF与被叫SIP终端上产生，显然是不同的源。如果使用网关模式的话，将回铃音媒体切换为被叫媒体流必须在会话上进行媒体更改，媒体更改不能立即完成，这将会带来媒体删剪的问题。

使用应用服务器模式，则是同时建立了两个会话，将回铃音媒体切换为被叫媒体流可以通过将当前会话从早期会话切换到正常会话上即可，能够立即完成。

信令流程如下图：

简单说明如下：

1) INVITE请求中携带一个SDP作为常规会话的offer
其Supported头域中包含一个选项标签“early-session”，表示主叫终端支持早期会话。

2) INVITE请求中携带之前收到的offer

3) 183响应中携带一个SDP作为常规会话的answer。

4) 183中含有两个SDP：

a) 一个是之前从被叫那里收到的，作为常规会话的answer；
此时常规会话被建立，但并没有媒体被传送。

b) 另一个作为要建立的早期会话的的offer.

5) PRACK中携带一个SDP，作为早期会话的answer
此时早期会话被建立，且有被早期媒体（回铃音）传送。

6) AS向被叫发送PRACK

7) 被叫向AS返回200 PRACK

8) AS向主叫返回200 PRACK

9) 被叫摘机，向AS发送200响应

10) AS向主叫发送200响应
此时常规会话上将会有媒体传送，主叫UA播放常规会话上的媒体。

4、关于目前多媒体彩铃的实现的简单说明

目前中国网通及中国移动的多媒体体彩铃业务的实现都主要采用了网关模式的实现方案（详细流程参见相关技术规范），原因是很多SIP终端都不支持“early-session”选项标签，无法使用应用服务器模式。

实际上，采用网关模式实现彩铃会导致媒体删剪等一些问题，最终应该会逐步过渡到理想的方案 – 应用服务器模式。

SIP Using SDP with Offer/Answer Model

http://blog.sina.com.cn/s/blog_4b839a1b010092tl.html

       根据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内媒体选项已经确定，所以不会再改变。