媒體的協(xié)商

11.5.1概述

媒体协商和对预置条件(Precondition)的处理在IMS中是两个密切相关的概念，预置条件将在11.6.4节中介绍。两者都是与SDP中会话参数的描述更为相关,然而它们对于SIP信令也具有重要的影响。

通过媒体协商，两个UE之间就本次会话中使用的媒体组合以及各类媒体使用的编解码方案达成一致。为此，使用了SDP提议/应答机制。在IMS中，该机制基本上按照以下方式工作(见图11-5)：

图11.5 IMS中的SDP提议/应答

•  主叫UE在INVITE请求中发出第一个SDP提议给被叫UE。这个SDP罗列出主叫方希望在本次会话中使用的所有媒体类型（例如音频、视频或者如白板或聊天等特定应用），以及主叫方对各类媒体所支持的各种编解码类型。

•  被叫UE返回首个SDP应答，其中它可能拒绝某些提议的媒体类型。它还会缩减编解码方案列表，去掉那些不支持的编解码，因此只剩下双方都支持的编解码。

•  在收到第一个应答之后，主叫必须最终决定使用哪种编解码方案。它给被叫用户发出第二个提议，指示在会话中每种媒体类型将惟一采用的编解码方案。

• 被叫UE接受第二个提议并返回一个回答作为确认。

SIP也允许仅一次交换提议/应答后就建立媒体连接。在IMS中，如果第一次SDP应答中对任何媒体包含了超过一种的编解码方案，那么就必须产生第二次提议/应答交换为每种媒体流选择惟一的编解码方案。这是由于双方的UE都必须准备接受所选择的任何编解码类型，因此，尽管可能实际上在整个会话中使用较低带宽的编解码方案，也需要按照较高带宽的编解码方案预留空中接口资源。

由于要进行资源预留（见11.6节），必须在收到对INVITE请求的200（OK）响应之前进行两次提议/应答的交换。因此，被叫UE需要将第一次应答放在100类响应中。在11.6节中，我们可以看到这第一个响应是183（会话进行中）响应。如果是这样，就产生了两个问题：

• 与所有的100类响应一样，183（会话进行中）响应是一个临时响应，因此它的传输并不可靠，这意味着TheresaUE并不能确信该响应究竟是否能够被主叫方收到。

• 主叫侧无法再发回第二个提议，因为在正常的INVITE会话中，除了初始的INVITE请求和会话建立过程完成时的ACK之外，主叫UE不可能向被叫UE发出任何其他的SIP请求。

[RFC3262]采用临时100类响应的可靠传送来解决了这两个问题：这就是说，当TheresaUE向TobiasUE发回一个临时响应时，它可以指示这个响应希望以一种可靠方式来发送。TobiasUE就必须对收到的临时（PR）响应返回一个确认（ACK）：PRACK请求。由于SIP中每个请求（包括ACK）都必须获得最终响应,因此TheresaUE在收到PRACK请求后，会返回一个200（OK）响应。

通过对SIP的这个补充，183（会话进行中）响应中的第一个SDP应答可以获得可靠传输，并且第二次SDP提议/应答交换可以通过PRACK请求和对它的200（0K）响应来实现。

11.5.2临时响应的可靠性

SIP的100类响应是临时的：也就是说，发送方终端不会得到对方的指示，以说明发出的响应是否被对方接收到。如前文所述，有一些情况下临时响应需要进行可靠传输：即收到该响应的终端应进行明确的确认。IMS中这样的情况之一就是该临时响应承载了一个SDP应答，必须被可靠地传递到对方。

可靠发送临时响应的机制简称为“l00rel”，与IMS连接的任何UE都必须支持该机制。

为了指示自己支持l00rel机制，TobiasUE在INVITE请求中包含一个Supported消息头，指示“l00rel”选项标签。

INVITE sip:theresa@home2.huSIP/2.0

From:HYoueBrother,,<sip:tobi@brother.com>;tag=veli

To:"MybelovedSisterH<sip:theresa@home2.hu>

Supported:1OOrel

Cseq:1112 INVITE

Call-ID:apb03a0s09dkjdfglkj49555

收到这个消息头之后，TheresaUE就可以可靠地发送临时响应了，因为它知道Tobias的终端会对这类响应进行应答。因此，TheresaUE发送183（会话进行中）响应时，它插入两个附加的消息头。

SIP/2.0183  Session in Progress

From:"YourBrother"<sip:tobi@brother.com>;tag==veli

To:”MybelovedSister”

<sip:theresa@home2.hu>;tag=schwester

Require:lOOrel

Rseq:1971

Cseq:1112INVITE

Call-ID:apb03a0s09dkjdfglkj49555

Require消息头指示接收这个临时响应的终端必须对它返回一个PRACK请求。为了在多个临时响应间进行识别，还增加了一个RSeq消息头。

TobiasUE需要按照要求返回一个PRACK请求，以确认183（会话进行中）临时响应。

PRACK<sip:[5555::5:6:7:8]:1006SIP/2.0

From:"YourBrothern<sip:tobi@brother.com>;tag=veli

To:"MybelovedSister"

<sip:theresa@home2.hu>;tag=schwester

RAck:1971 1112 INVITE

CSeq:1113 PRACK

Call-ID:apb03a0s09dkjdfglkj49555

该请求被发往Theresa终端的IP地址，该地址在183（会话进行中）响应中的Contact头中得到。此外CSeq数值加1,因为PRACK是对话中由INVITE/183（会话进行中）交换所创建的后续请求。

RAck消息头标识了明文确认的临时响应，RAck消息头包含了已收到响应中的RSeq和CSeq消息头的值。RAck头中同时包含了RSeq和CSeq的值是为了惟一标志该183（会话进行中）响应。

由于PRACK是一个正常的SIP请求，因此Theresa的终端需要对它返回一个最终响应。

SIP/2.0 200 OK

From:"YourBrother"<sip:tobi@brother.com>;tag=veli

To:"MybelovedSister"

<sip:theresa@home2.hu>;tag=schwester

Cseq:1113PRACK

CalHD:apb03a0s09dkjdfglkj49555

200（OK）响应中的CSeq头指示这是对PRACK请求（CSeq<4113PRACK”）的最终响应，而不是对INVITE请求（CSeq值“1112INVITE”）的响应。Tobias的终端仍然在等候对INVITE请求的最后响应，在我们现在的这个IMS例子中，这还要等待一段时间。

11.5.3IMS中的SDP提议/应答

SDP的提议/应答机制使两个用户能够为一个特定会话协商确定所希望使用的媒体类型和编解码方案。

我们假设Tobias希望在与姐姐的多媒体会话中使用以下媒体类型：

•  一个音频流——用于相互交谈；

•  第一个视频流由TobiasUE内置摄像头拍摄，这样Theresa就可以看到他；如果Theresa也有类似的摄像头，Tobias也可以看到她；

•  第二个视频流——由连接到UE的外置摄像头拍摄，现在产生的是芬兰奥鲁一个木屋的图像。

这样，在INVITE请求中会包含SDP内容，如下所示（注意这里并没有给出全部SDP参数）：

v=0

o=-29879336152987933615INIP65555::1:2:3:4

s=・

c=INIP65555::1:2:3:4

t=907165275 0

m=audio3458RTP/AVP 0 96 97 98

a=rtpmap:0 PCMU

a=rtpmap:96 G726-32/8000

a=rtpmap:97 AMR-WB

a=rtpmap:98 telephone-event

m=video3400 RTP/AVP 98 99

a=rtpmap:98MPVa=rtpmap:99H.261

m=video3456RTP/AVP 98 99

a=sendonly

a=rtpmap:98H.261

a=rtpmap:99MPV

11.5.3.1通用的SDP参数

让我们进一步分析一下这些SDP信息。首先，最前面的五行构成开头。

v=0

o=-29879336152987933615INIP65555::1:2:3:4

s=-

c=INIP65555::l:2:3:4

t=9071652750

v行中指示协议版本，总是设置为0。

o行中包含与会话所有者有关的参数，本例中会话所有者即Tobias：

• 第一个参数是Tobias希望告诉SDP接收者的他自己的名字。但是由于在INVITE请求的SIPFrom消息头已经做了标识，因此这里可以不填写。

• 第二个参数是Tobias的会话标识符,TobiasUE使用这个数字来关联会话描述和他所希望建立的媒体。

• 第三个参数是Tobias所发送的会话信息的版本——本例中初始值为与会话标识符相同的值，但它也可以设置为其他值。

•  接下来的参数表示TobiasUE使用Internet（IN）和IPv6地址，并且他现在正在使用一个特定地址的终端。

s行可以包含一个本次会话的标题，但是这也已经由SIP完成了。

c行包含为多媒体会话而建立的连接的信息:也就是说它指出了真正的媒体流要使用的地址，而不是信令所使用的地址。本例中Tobias UE指出它希望使用IP地址来接收本会话中的所有媒体，该IP地址也用于SIP信令：即，该地址在PDP上下文激活时（见10.2节）分配。TobiasUE将使用相同的IP地址和相同的接入点为媒体建立全部的次PDP上下文。

最后，还有一个t行，指示本会话建立的时间和将要持续的时长。在SDP中，不需要为会话设置时长限制，因为SIP用户可通过手动发送一个BYE请求来结束会话。因此，t行的第二个参数可以放心地设置为0。

会话开始的时间值按照网络时间协议（NTP）中定义的格式，使用64bit、无符号定点数，代表自从1900年1月1日00:00以来所经过的秒数。

11.5.3.2媒体行

各个媒体行，或称m行，代表Tobias希望发送的三个不同的媒体流。

m=audio 3458 RTP/AVP0 96 97 98

m=video 3400 RTP/AVP 98 99

m=video 3456 RTP/AVP 98 99

第一行表示Tobias希望在本次会话中使用音频，并且他的UE将在本地端口3458上发送音频流。音频媒体使用的传输协议是RTP/AVP（音频视频配置），并且终端支持四种音频编解码格式，因为m行中给出了四种不同的格式（0、96、97和98）。稍后我们会看到实际上只支持三种格式，最后一个（98）是DTMF（双音多频）。

后面的两个m行代表两个不同的视频流，二者将会并行发送：一个是Tobias的视频，另一个是木屋。一个通过Tobias终端的本地端口3400发送，另一个通过端口3456。二者都使用RTP/AVP传输。终端对二者分别都支持两种格式。

11.5.3.3音频和视频格式

SDP的m行中包含一种或多种格式，指示媒体流所使用的编解码方案。［RFC3551］包含了多达35种格式或编解码方案，都已经固定分配了RTP/AVP净荷类型号码（0到35）。在分配这些号码之后，又定义了多种编解码方案，也可以通过RTP/AVP来传输。这些新编解码方案可以动态分配一个从96-127之间的净荷类型号码。

在我们的例子中，第一个媒体行包含了四种RTP/AVP净荷类型，并在接下来的几行SDP信息中得到进一步解释。两个SDP媒体行之间的行构成一个块，用于更详细的描述其前面的m行中的媒体。

m=audio 3458 RTP/AVP0 96 97 98

a=rtpmap:O PCMU

a=rtpmap:96G726-32/8000

a=rtpmap:97 AMR-WB

a=rtpmap:98 telephone-event

m行中所列出的四种音频格式号码现在被映射成各种单独的净荷类型或编解码方案。

净荷类型0在［RFC3551］中已经固定分配给PCMU(μ率脉冲编码调制；ITU-TG.711）编解码方案。第一个a行（属性行）再次重申了这种对应关系。

接下来两个属性行将媒体行中指出的后面两个动态RTP/AVP格式值（96和97）映射为特定的编解码方案，本例中为：

• 净荷类型96对应为G.726编码；

• 净荷类型97对应为自适应多速率宽带（AMR-WB）编码。

最后一个净荷类型对应为DTMF音调的电话事件表示，这在［RFC2833］中介绍。这意味着任何时候当用户按一个键时本终端将产生标准化音调。这些音调在常规（电路交换，或称CS）电话中普遍使用，例如一个自动语音应答单元提出问题，然后用户通过按特定键来回答（例如“收听英文信息，请按1;收听德语信息,请按2”）。电话事件定义了一种基于文本的表示法，以表示DTMF音调或其他可以通过RTP来传送的与电话有关的音调。

前面三种净荷类型（PCMU、G.726、AMR-WB）可以彼此替代——它们每一个都可以用来对上面m行中指示的媒体进行编码。电话事件净荷类型不能被替代:任何时候当需要生成一个音调时，UE必须能够发送该信息。

现在，可以很容易解释SDP描述中后面两个媒体块的含义。

m=video3400RTP/AVP

a=rtpmap:98MPV

a=rtpmap:99H.261

m=video3456RTP/AVP9899

a=sendonly

a=rtpmap:98H.261

a=rtpmap:99MPV

终端可以使用MPV（动态分配给RTP/AVP的净荷类型98）或H.261（动态分配的净荷类型99）两种编码中的任何一种对两个视频流进行编码。第一个视频流从拍摄Tobias的摄像头产生并发送。由于没有对该视频流作进一步解释，因此它默认为一个收发双向流，这意味着Theresa也可以通过相同的流向Tobias发送视频信息。通过第二个视频流可以看到木屋的图像，由于假设Theresa不会发回任何图像，因此该视频流设置为“sendonly”。

11.5.3.4第一次SDP提议与应答交换

上面介绍的SDP信息是第一次提议,TobiasUE在INVITE请求的正文中将其发往Theresao基于INVITE请求的SIP路由机制，SDP提议到达Theresa UE,然后Theresa UE对收到的提议生成SDP应答，如下所示：

v=0

o=-13579241357924INIP65555::5:6:7:8

s=-

c=INIP65555=5:6:7:8

t=9071652750

m=audio 4011RTP/AVP 96 97 98

a=rtpmap:96G726-32/8000

a=srtpmap:97ARM-WR

a==rtpmap:98telephone-event

m=video4012RTP/AVP99

a=rtpmap:99H.261

m=video0RTP/AVP98

现在这个SDP头中包含TheresaUE信息，具体来说就是：o行包含它的地址、UE会话标识以及SDP信息的版本，c行也包含UE的IP地址。

从m行中，我们可以看到该终端可以处理音频流（在端口4011上）和第一个视频流（在端口4012上）,但不能把第二个视频流传递给用户。因此，第三个m行中端口号被设置为0,并简单地去掉了所有相关的a行。

SDP应答必须重复SDP提议中的所有m行。因此，终端还不能把这里的最后一个m行删除：用于标识无法处理这个视频的惟一方式就是把端口号设置为0。

此外，该UE也不支持MPV的视频编解码方案。这个RTP/AVP净荷类型值被从第一个视频的m行中去掉，在应答中相关的a行也被忽略掉。

对于音频，UE不支持PCMU净荷类型，但是G.726和AMR-WB都可以被支持。这里UE并不做选择，它仅仅把所支持的两个编解码方案返回给主叫。

另外，终端将DTMF信号表示为电话事件。

11.5.3.5第二次SDP提议与应答交换

收到第一个SDP应答后，TobiasUE必须对媒体流及其使用的编解码方案作出最终决定。如前所述，SIP和SDP不强制用户或终端为每个媒体流仅选择一种编解码方案。由于空中接口资源通常是稀缺的，因此强烈建议在通过无线链路附着到IMS时最好作出这个选择。

这样，第二个SDP提议就通过PRACK请求发往Theresa的终端。

v=0

o=-13579241357925INIP65555::1:2:3:4

s=-

c=INIP65555::1:2:3:4

t=9071652750

m=audio3458RTP/AVP9798

a=rtpmap:97ARM-WR

a=rtpmap:98telephone-event

m=video3440RTP/AVP99

a=rtpmap:99H.261

m=video0RTP/AVP98

对于音频媒体，终端选择了AMR-WB作为期望的编解码方案。同时，DTMF信号也可以作为电话事件来发送。Theresa的终端所接受的第一个视频流将使用H.261格式发送，同时，由于对端不支持第二个视频流，Tobias的终端也将其端口设为0。

由于第二个提议包含了所有的媒体有关信息，因此应答不再包含任何新的信息。也就是说，它仅包含Theresa终端所使用的端口号和地址信息。

v=0

o=13579241357924INIP65555::5:6:7:8

s=-

c=INIP65555::5:6:7:8

t=9071652750

m=audio4011RTP/AVP969798

a=rtpmap:97ARM-WR

a=rtpmap:98telephone-event

m=video4012RTP/AVP99

a=rtpmap:99H.261

m=video0RTP/AVP98

11.5.4相关标准

与11.5节有关的规范有:

•RFC1305    NetworkTimeProtocol(Version3)Specification,ImplementationandAnalysis.

•RFC3550    RTP:ATransportProticolforReal-timeApplications.

•RFC3551    RTPProfilefbrAudioandViedoConferenceswithMinimalControl.

•RFC2327    SDP:SessionDescriptionProtocol.

•Draft-ietf-mmusic-sdp-new     SDP:SessionDescriptionProtocol.

•RFC2833    RTPPayloadfbrDTMFDigits,TelephonyTonesandTelephonySignals.

•RFC3262    ReliabilityofPtovisionalResponsesintheSessionInitiationPtotocol(SIP).

•RFC3264     AnOflfer/AnswerModelWithSDP.