CN102118359B - 基于sip协议的媒体消息传输方法 - Google Patents

Abstract

本发明公开了一种基于SIP协议的媒体消息传输方法。该媒体消息传输方法中，呼叫发起端和呼叫接收端在会话建立过程中，对SIP协议进行扩展，将RTP消息封装在基于SIP协议的媒体消息中进行传送，所述呼叫接收端在收到所述媒体消息后，直接进行媒体处理，不进行回应。本发明提高了VoIP应用对NAT服务器与防火墙网络的适应性以及服务器的安全性。同时，本发明具有后向兼容性，降低了服务器的处理负担，提高安全性。

Description

基于SIP协议的媒体消息传输方法

技术领域

本发明涉及一种基于SIP协议的媒体消息传输方法，属于互联网电话(Voice over IP，简称为VoIP)技术领域。

背景技术

互联网电话技术是一种在传统电路交换网络和IP网络之间传输语音，或直接在IP网络上传输语音的技术。其工作过程分为以下几个步骤：语音的数字化，数据压缩，数据打包，解包及解压缩，语音恢复。其技术结构由信令技术、语音编解码技术、实时传输技术、服务质量(QoS)保障技术和网络传输技术等组成。

会话初始化协议(Session Initiation Protocol，SIP)与H.323协议是目前在互联网电话中应用最广的两大信令协议标准。SIP被描述为用来生成、修改和终结一个或多个参与者之间的会话。对于使用者来说，由于SIP与互联网结合紧密，并且对多媒体接入支持、移动通讯的支持都有着明显的优势，因此更符合未来通讯的要求。

SIP同HTTP相似，SIP报文是人类可读的，并且也是采取请求-应答的流程。SIP用于初始、管理和终止分组网络中的语音和视频会话。SIP协议设计目的只是在用户代理(UA)之间建立会话并控制会话，因此SIP协议仅仅涉及会话的信令部分(control message)，所以SIP需要与许多其它的协议协同工作完成整个会话过程。SIP报文传送会话描述协议(SDP)。SDP协议描述了会话所使用的流媒体的细节。SIP利用实时传输协议(RTP)作为语音或视频等媒体的载体进行流媒体传输。SIP利用实时传输控制协议(RTCP)进行流媒体传输控制。SIP与上述协议构建了当今VoIP技术的主体框架。

由SIP协议发展而来的SIMPLE协议族规定了SIP在呈现与即时消息技术领域的应用方法，这些扩展使SIP在“会话初始”之外的领域也得到广泛应用。

目前，SIP的媒体传送方式主要存在以下一些缺点与隐患：

(1)一次会话的信令部分与媒体部分使用不同的协议端口，增加了NAT穿越的难度。

(2)由于RTP协议使用动态端口分配机制，一路会话所采用的端口号是随机生成的，对于进行媒体代理的服务器来说需要同时打开大量的端口，增加了服务器的处理负担，也带来一定的安全隐患。

(3)RTCP协议规定默认使用与其对应的RTP端口加一作为其传输端口，因此RTCP的NAT穿越更加复杂，也造成了现有VoIP产品难以利用RTCP进行实时传输的网络质量监控。

(4)会话的信令与媒体部分在互联网上分开传输，加大了VoIP通话行为的行政监管难度。

发明内容

本发明所要解决的技术问题在于提供一种基于SIP协议的媒体消息传输方法。

为实现上述的发明目的，本发明采用下述的技术方案：

一种基于SIP协议的媒体消息传输方法，用于在呼叫发起端和呼叫接收端进行媒体传输，其特征在于：

所述呼叫发起端和所述呼叫接收端在会话建立过程中，使INVITE消息中的Allow头域包含media值，Supported头域包含media-resp值，使200OK消息中的Allow头域包含media值，Supported头域包含media-resp值；

在会话建立以后，所述呼叫发起端将RTP消息封装在基于SIP协议的媒体消息中进行传送，使媒体消息中的Content-Type头域的取值为media/rtp，Content-Length头域的取值为二进制形式RTP消息长度的总字节数；所述呼叫接收端在收到所述媒体消息后，直接进行媒体处理，不进行回应。

其中，所述呼叫接收端使用RTCP协议格式向所述呼叫发送端的指定的地址和端口发送媒体控制包，

所述呼叫发送端将RTCP消息封装在基于SIP协议的媒体消息中进行传送，使所述媒体消息中的Content-Type头域的取值为me dia/rtcp，Content-Length头域的取值为表示二进制RTCP消息长度的总字节数，

所述呼叫接收端在收到所述媒体消息后，直接进行媒体控制处理，不进行回应。

所述呼叫发送端或者所述呼叫接收端在会话过程中，直接将RTP或RTCP消息封装在SIP消息中进行媒体发送，或直接以RTP或RTCP消息进行媒体发送。

所述呼叫发送端根据需要，通过re-INVITE消息来改变会话属性，使re-INVITE消息的Require头域中包含media-resp值。

所述呼叫接收端在收到所述re-INVITE消息后，对随后收到的每一个所述媒体消息进行回应。

本发明所提供的基于SIP协议的媒体消息传输方法，可以解决NAT服务器穿越问题，并能够方便地使用RTCP格式的消息进行媒体传输控制，也提高了安全性，降低了服务器的负担。

附图说明

下面结合附图和具体实施方式对本发明作进一步的详细说明。

图1为无需应答事务的呼叫发起端(UAC)的行为；

图2为无需应答事务的呼叫接收端(UAS)的行为；

图3为使用媒体方法进行媒体传输的会话过程示意图；

图4为在NAT服务器环境中使用媒体方法进行媒体传输的示意图。

具体实施方式

本发明对SIP协议进行扩展，添加一种新的SIP事务(transaction)-无需应答事务(no-response transaction)。由于会话媒体传输中对丢包与乱序的容错性较好，故采用无需消息确认的一种新机制来传输媒体信息，同时在要求较高传输质量时可以随时要求对端使用SIP非邀请事务状态机，以保证在发送图片或文本信息时对端能够正确的收到每一帧消息。

图1表示呼叫发起端(UAC)对无需应答事务的处理状态机。UAC的事务(transaction)层接收到事务用户(TU)要求发送的消息后，在将消息发送完成之后，无论对端是否应答或传输错误，均直接跳转到结束状态，结束此次事务处理。因为一个无需应答事务不会收到对端的回应，所以UAC并没有用于接收到对端无需应答事务回应的处理状态机。

图2表示呼叫接收端(UAS)对无需应答事务的处理状态机。UAS的事务层接收到对端发送的消息后，将消息转发给TU并直接进入结束状态，结束此次事务处理。因为对端TU不会对无需应答事务进行回应，所以UAS并没有用于实际接收到TU对无需应答事务回应的处理状态机。

在本发明中，增加媒体传输(MEDIA)这种新的SIP封装方法。该方法拥有rfc3261中对通用方法定义的所有属性，唯一的不同是在SIP协议事务层将此方法按照无需应答事务处理。SIP协议TU层在收到一个MEDIA方法消息之后，无需对其进行回应。若发现SIP包携带媒体错误，服务器无法解析，SIP包出现乱序等现象，则直接将此包进行丢弃处理。

根据SIP协议要求，如果UAC支持服务端响应请求的SIP扩展，UAC应该在请求的时候包含一个Supported头域来说明options tags描述的那些S IP扩展。如果UAC要求UAS能够支持扩展，以便UAS能够处理UAC的特定请求，那么它必须在请求头中增加一个Require头域来说明处理本特定请求需要什么样的扩展option tags。因此，通过对Require头域与Supported的取值进行扩展，可以实现要求UAS对每一个收到的媒体包进行应答的机制，可以保证在要求高质量网络传输时的媒体传输的可靠性。

具体的扩展方法是，在SIP协议的Allow头域的取值范围，增加media值，表示此UA支持媒体传输方法(MEIDA)，可以使用SIP协议对媒体进行封装发送处理。扩展SIP协议的Supported头域、Require头域、Proxy-Require头域与Unsupported头域的取值范围，增加media-resp值和media-resp值来表示需要对收到的每一个MEDIA方法消息进行回应。此时UAC与UAS的事务层应将MEDIA方法的消息作为一次非邀请事务(non-invite transaction)进行处理。TU层应对此消息进行回应，如果消息正确，则返回200OK，如果消息体内出现错误或服务器无法处理此消息，则将其按照普通SIP Response规定对此消息进行回应。

扩展SIP协议的Content-Type头域的取值范围，增加media/rtp与media/rtcp值。其中，media/rtp值表示此SIP消息封装的消息体为采用RTP协议表示的媒体信息；media/rtcp值表示此SIP消息封装的消息体为采用RTCP协议表示的媒体控制信息。

扩展SIP协议的Contect-Language头域的取值范围，增加none值，表示此消息并未使用任何语言，而是直接传输二进制消息。

扩展SIP协议的Content-Disposition头域的取值范围，增加media值。表示此消息体内容为媒体信息。

扩展SIP协议的Content-Length头域的定义，在Content-Type头域的取值为media/rtp或media/rtcp时，Content-Length头域的取值为消息体内二进制格式的RTP或RTCP消息内容长度取值，单位为字节。

利用rfc3320、rfc3321、rfc3485、rfc4896与rfc5049等一系列SigComp扩展协议相关规定对SIP信令进行压缩处理，可以提高网络带宽利用率。

本发明增强了SIP协议的能力范围，扩充SIP协议不仅仅能够建立与控制会话，而且在可以参与会话的整个媒体处理流程，同时，增强了SIP协议对NAT型网络与防火墙的协调使用能力，也增强了VoIP应用服务器的安全性与服务质量，主要表现在：

(1)使用SIP协议对RTP协议进行封装，使得会话建立过程与媒体传输过程变得一致，一次会话自始至终使用相同端口，简化了会话建立行为在含有NAT服务器与防火墙的网络环境下的处理过程。

(2)RTP协议与RTCP协议无需使用动态端口，而是封装在SIP协议内进行传输，因此使媒体代理VoIP服务器的端口开放数量得以减少，增强了此类VoIP服务器的安全性与处理性能。

(3)现有RTCP协议在现有NAT网络环境中使用成本过高，将RTCP协议封装在SIP协议中进行传输之后可以很方便地使用RTCP协议进行网络服务质量监控，增强VoIP应用的服务质量。

(4)会话控制与媒体在完全相同的路径上传输，便于进行VoIP应用监管。

图3显示使用MEDIA方法进行媒体传输的一次完整的会话过程。在会话期间UA可以自由选择是否使用MEDIA方法进行媒体传输并能够在两种传输模式中自由切换。下面以图3所示的一次完整的会话流程为实施例，详细描述本发明的具体实施方式。

(1)首先，UAC发出INVITE消息，请求建立会话。INVITE消息中的Allow头域包含media值，表示此UAC支持MEDIA方法，并且Supported头域包含media-resp值，表示此UAC支持对MEDIA方法进行回应。

UAS处理收到INVITE消息后，接连返回100Trying消息与180Ringing消息。100Trying用于提示UAC正在对INVITE消息进行处理，180Ringing用于提示UAC被叫已经开始振铃。

(2)UAS返回200OK消息，完成会话建立过程，200OK消息中的Allow头域包含media值，表示此UAS支持MEDIA方法，同时Supported头域包含media-resp值，表示此UAS支持对MEDIA方法进行回应。

(3)会话建立以后，UAS使用普通的RTP协议格式向UAC指定的地址与端口发送媒体，而UAC使用上述MEDIA方法将RTP消息封装在SIP消息中进行传送，此消息中Content-Type头域取值media/rtp，表示携带内容为RTP格式的媒体消息，Content-Length头域的取值为表示二进制形式RTP消息长度的总字节数。UAS收到MEDIA消息后，直接进行媒体处理，无需进行任何回应。

(4)UAS使用普通的RTCP协议格式向UAC指定的地址和端口发送媒体控制包，向对端反馈媒体传输质量。UAC使用上述MEDIA方法将RTCP消息封装在SIP消息中进行传送，此消息中Content-Type头域取值media/rtcp，表示携带内容为RTCP格式的媒体控制消息，Content-Length头域表示二进制形式RTCP消息长度的总字节数。UAS收到MEDIA消息后，直接进行媒体控制处理，无需进行任何回应。

UAS在会话进行当中，可以随时改变自己的媒体发送方式，不需要向UAC发出请求，直接使用MEDIA方法，将RTP或RTCP消息封装在SIP消息中进行媒体发送。此时UAC能够通过解析接收到的SIP消息，判断出媒体所属会话并进行正确处理。同样，UAC也能够随时改用MEDIA方法，而不需向UAC发出请求。

(5)如果在通话过程中需要插入重要内容或者要求较高的传输质量情况，这时，UAC可以通过re-INVITE方法改变会话属性。在re-INVITE消息的Require头域中包含media-resp值。UAS将会对随后收到的每一个MEDIA消息进行回应。通过使用SIP协议定义的消息检测与重发机制，可以有效解决RTP传输中的乱序与丢包问题，从而保证传输质量。

(6)UAC向UAS发送BYE消息，请求结束一次会话，UAS返回200OK消息，通话正式结束。

图3中，“切换事物传输方式”表示UAC与UAS双发在会话建立后可以任意切换是否使用MEDIA方法进行RTP传输，无需任何信令交互。当其中一方需要高传输质量时，可以通过发送Require头域中包含media-resp值的re-INVITE信令进行“切换事物交互方式”操作，对方在收到次信令并返回200OK后，需要对之后收到的每一个MEDIA信令做出响应，使媒体传输不会出现乱序或丢包现象。

图4表示在NAT服务器环境中使用MEDIA方法进行媒体传输。由图4可以看出，MEDIA方法很容易解决除对称型NAT服务器外的NAT服务器穿越问题，并能够方便地使用RTCP格式的消息进行媒体传输控制。图4中UAC在会话建立阶段打开一个防火墙端口之后，随后UAS仍然使用此防火墙端口向UAC发送RTP与RTCP媒体消息，保证媒体流能够成功穿越防火墙。而传统媒体传输方法中UAS向UAC发送的媒体消息由于没有打开防火墙端口而被防火墙拒绝。

本发明利用基于SIP协议的媒体传输方法，提高了VoIP应用对NAT服务器与防火墙网络的适应性以及服务器的安全性。同时，本发明具有后向兼容性，可以对不支持本发明的UA进行兼容，有广泛的应用性。由于本发明使用约定的端口，降低了服务器的处理负担，提高安全性。

以上对本发明所提供的基于SIP协议的媒体消息传输方法进行了详细的说明。对本领域的技术人员而言，在不背离本发明实质精神的前提下对它所做的任何显而易见的改动，都将构成对本发明专利权的侵犯，将承担相应的法律责任。

Claims (5)

1.—种基于SIP协议的媒体消息传输方法，用于在呼叫发起端和呼叫接收端进行媒体传输，其特征在于： 

所述呼叫发起端和所述呼叫接收端在会话建立过程中，使INVITE消息中的Allow头域包含media值，Supported头域包含media-resp值，使200 OK消息中的Allow头域包含media值，Supported头域包含media-resp值； 

在会话建立以后，所述呼叫发起端将RTP消息封装在基于SIP协议的媒体消息中进行传送，使媒体消息中的Content-Type头域的取值为media/rtp，Content-Length头域的取值为二进制形式RTP消息长度的总字节数；所述呼叫接收端在收到所述媒体消息后，直接进行媒体处理，不进行回应。 

2.如权利要求1所述的媒体消息传输方法，其特征在于： 

所述呼叫接收端使用RTCP协议格式向所述呼叫发起端的指定的地址和端口发送媒体控制包， 

所述呼叫发起端将RTCP消息封装在基于SIP协议的媒体消息中进行传送，使所述媒体消息中的Content-Type头域的取值为media/rtcp，Content-Lengh头域的取值为表示二进制RTCP消息长度的总字节数， 

所述呼叫接收端在收到所述媒体消息后，直接进行媒体控制处理，不进行回应。 

3.如权利要求1所述的媒体消息传输方法，其特征在于： 

所述呼叫发起端或者所述呼叫接收端在会话过程中，直接将RTP或RTCP消息封装在SIP消息中进行媒体发送，或直接以RTP或RTCP消息进行媒体发送。 

4.如权利要求1所述的媒体消息传输方法，其特征在于： 

所述呼叫发起端根据需要，通过re-INVITE消息来改变会话属性，使re-INVITE消息的Require头域中包含media-resp值。 

5.如权利要求4所述的媒体消息传输方法，其特征在于： 

所述呼叫接收端在收到所述re-INVITE消息后，对随后收到的每一个所述媒体消息进行回应。 

Images