CN101453349B

CN101453349B - 一种处理实时流媒体协议的方法及系统

Info

Publication number: CN101453349B
Application number: CN200810086354.7A
Authority: CN
Inventors: 祝宁
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2007-12-03
Filing date: 2008-03-26
Publication date: 2012-10-17
Anticipated expiration: 2028-03-26
Also published as: EP2211507A1; EP2211507A4; WO2009082908A1; EP2211507B1; CN101453349A

Abstract

本发明公开了一种处理实时流媒体协议的方法，包括以下步骤：媒体网关根据媒体网关控制器的指示创建上下文以及所述上下文内部的第一IP终端和第二IP终端，协商所述第一IP终端收发实时流媒体协议RTSP消息的远端地址和本端地址，以及第二IP终端收发实时流媒体协议RTSP消息的远端地址和本端地址；所述媒体网关通过所述第一IP终端从第一IP网络接收到第一RTSP消息后，通过所述第二IP终端向第二IP网络发送第二RTSP消息，所述第二RTSP消息与第一RTSP消息相关。本发明公开了一种处理实时流媒体协议的系统。本发明的实施例中，使边界网关具备转发和处理RTSP消息的能力，且使支持H.248协议的用户终端设备支持收发RTSP消息的能力。

Description

一种处理实时流媒体协议的方法及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种处理RTSP(Real Time StreamingProtocol，实时流媒体协议)的方法及系统。

背景技术

MGC(Media Gateway Controller，媒体网关控制器)和MG(MediaGateway，媒体网关)是分组网络中的两个关键构件。MGC负责呼叫控制功能，MG负责业务承载功能，实现呼叫控制平面和业务承载平面的分离，从而充分共享网络资源，简化设备升级和业务扩展，大大降低开发和维护成本。

NGN(Next Generation Network，下一代网络)中MG和MGC组网如图1所示，媒体网关控制协议是MG和MGC之间通信的主要协议，目前应用较为广泛的有H.248/MeGaCo和MGCP(Media Gateway Controller Protocol，媒体网关控制器协议)两种协议；MG与MG之间通过RTP(Real-time Transport Protocol，实时传输协议)等协议通信。

以H.248协议为例，MG上的各种资源被抽象表示为终端(Termination)，终端又分为物理(Physical)终端和临时(Ephemeral)终端，物理终端代表一些具有半永久存在性的物理实体，例如TDM(Time-Division Multiplexing，时分复用)通道等，临时终端代表一些临时申请用后释放的公共资源，例如RTP流等。另以根(Root)终端代表MG整体，终端之间的组合被抽象表示为上下文(Context)，上下文可以包含多个终端，因而以拓扑(Topology)来描述终端间的相互关系。对于还未与其它终端发生关联的终端，由一个称为空(Null)上下文的特殊上下文来表示。

基于协议的这种抽象模型，呼叫的接续实际上就是对终端和上下文的操作。这种操作通过MGC和MG之间的命令(Command)请求(Request)和响应(Reply)来完成。命令类型包括添加(Add)、修改(Modify)、删减(Subtract)、移动(Move)、审计值(AuditValue)、审计能力(AuditCapabilities)、通报(Notify)、服务改变(ServiceChange)。命令参数，也称为描述符(Descriptor)，被分类为属性(Property)、信号(Signal)、事件(Event)、统计(Statistic)。具有业务相关性的参数逻辑上聚合成为包(Package)。

传统的IP通信有两种方式：第一种是在一台源IP主机和一台目的IP主机之间进行，即单播(unicast)；第二种是在一台源IP主机和网络中所有其它的IP主机之间进行，即广播(broadcast)。如果要将信息发送给网络中的多个主机而非所有主机，则要么采用广播方式，要么由源主机分别向网络中的多台目标主机以单播方式发送IP包。采用广播方式实现时，不仅会将信息发送给不需要的主机而浪费带宽，也可能由于路由回环引起严重的广播风暴；采用单播方式实现时，由于IP包的重复发送会白白浪费掉大量带宽，也增加了服务器的负载。所以，传统的单播和广播通信方式不能有效地解决单点发送多点接收的问题。

IP组播(或者说多播)是指在IP网络中将数据包发送到网络中的某个确定节点子集，这个子集称为组播组(multicast group)。IP组播的基本思想是，源主机只发送一份数据，这份数据中的目的地址为组播组地址；组播组中的所有接收者都可接收到同样的数据拷贝，并且只有组播组内的主机(目标主机)可以接收该数据，网络中其它主机不能收到。组播组用D类IP地址(224.0.0.0～239.255.255.255)来标识。

IP组播技术有效地解决了单点发送多点接收的问题，实现了IP网络中点到多点的高效数据传送，能够大量节约网络带宽、降低网络负载。作为一种与单播和广播并列的通信方式，组播的意义不仅在于此。更重要的是，可以利用网络的组播特性方便地提供一些新的增值业务，包括在线直播、网络电视、远程教育、远程医疗、网络电台、实时视频会议等互联网的信息服务领域。

组播技术涵盖的内容相当丰富，从地址分配、组成员管理，到组播报文转发、路由建立、可靠性等诸多方面。

实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体，如音频和视频。该媒体流可以是单播或者组播媒体流。尽管连续媒体流可能与控制流交叉，RTSP本身并不发送连续媒体流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP提供了一个可扩展框架，实现实时数据(如音频与视频)的受控、按需传送。数据源包括实况数据与存储的剪辑。RTSP用于控制多个数据发送会话，提供了选择发送通道的方式，如UDP(User DatagramProtocol，用户数据报协议)、组播UDP与TCP(Transmission ControlProtocol，传输控制协议)等，并提供了选择基于RTP(Realtime TransmissionPotocol，实时传输协议)的发送机制的方法。

RTSP会话不会绑定到传输层连接，如TCP。在RTSP会话期间，RTSP客户端可打开或关闭多个对服务器的可靠传输连接以发出RTSP请求；RTSP客户端也可选择使用无连接传输协议，如UDP。

RTSP控制的流可能用到RTP，但RTSP操作并不依赖用于传输连续媒体的传输机制。RTSP在语法和操作上与HTTP(Hypertext Transfer Protocol，超文本传输协议)/1.1类似，因此HTTP的扩展机制在多数情况下可加入RTSP。然而，在很多重要方面RTSP仍不同于HTTP，包括：RTSP引入了大量新方法并具有一个不同的协议标识符；在大多数情况下，RTSP服务器需要保持缺省状态，与HTTP的无状态相对；RTSP中客户端和服务器都可以发出请求；在多数情况下，数据由不同的协议传输；URI(Uniform ResourceIdentifier，通用资源标志符)请求总是包含绝对URI。

为了与过去的错误相互兼容，HTTP/1.1只在请求过程中传送绝对路径并将主机名置于另外的头字段。该协议支持如下操作：从媒体服务器上检索媒体，用户可通过HTTP或其它方法提交一个演示描述请求；媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录部分或全部演示；将新媒体加到现有演示中：如服务器能告诉客户端接下来可用的媒体内容，对现场直播显得尤其有用。通过RTSP协议，用户可以进行音频和视频的点播，进行快进/倒退，进行录制等。

在对现有技术的研究过程中，发明人发现现有技术存在以下缺点：

如图2所示，在两个IP网络之间的边界网关同时也是一个媒体网关，该媒体网关完成媒体数据流在不同IP网络之间的传递和相关处理，但无法转发并处理RTSP消息，媒体网关会丢弃接收到的RTSP消息。

发明内容

本发明实施例提供一种处理RTSP协议的方法及系统，以实现边界网关转发和处理RTSP消息。

本发明实施例提供了一种处理实时流媒体协议的方法，包括以下步骤：

媒体网关根据媒体网关控制器的指示创建上下文以及所述上下文内部的第一IP终端和第二IP终端，协商所述第一IP终端收发实时流媒体协议RTSP消息的远端地址和本端地址，以及第二IP终端收发实时流媒体协议RTSP消息的远端地址和本端地址；

所述媒体网关通过所述第一IP终端从第一IP网络接收到第一RTSP消息后，通过所述第二IP终端向第二IP网络发送第二RTSP消息，所述第二RTSP消息与第一RTSP消息相关。

本发明实施例还提供了另一种处理实时流媒体协议的方法，包括以下步骤：

媒体网关创建上下文以及所述上下文内部的第三IP终端；并在所述第三IP终端上设置收发实时流媒体协议RTSP消息的远端地址；所述媒体网关接收所述媒体网关控制器指示，在所述第三IP终端上分配收发实时流媒体协议RTSP消息的本端地址；

所述媒体网关通过所述第三IP终端从所述第三IP终端所在的IP网络接收到第三RTSP消息后，将所述第三RTSP消息的内容上报给媒体网关控制器。

本发明实施例进一步提供了一种处理实时流媒体协议的系统，包括：

媒体网关，用于接收媒体网关控制器指示创建上下文以及所述上下文内部的第一IP终端和第二IP终端，在所述第一IP终端和第二IP终端上设置收发实时流媒体协议RTSP消息的远端地址；在所述第一IP终端和第二IP终端上分配收发实时流媒体协议RTSP消息的本端地址；并通过所述第一IP终端从所述第一IP终端所在的IP网络接收到RTSP消息，所述RTSP消息保持不变或者进行修改后通过所述第二IP终端发送到所述第二IP终端所在的IP网络。

媒体网关，用于根据媒体网关控制器的指示创建上下文以及所述上下文内部的第三IP终端，协商其上第三IP终端收发实时流媒体协议RTSP消息的远端地址和本端地址；并通过所述第三IP终端从所述第三IP终端所在的IP网络接收到第三RTSP消息后，将所述第三RTSP消息的内容上报给媒体网关控制器。

本发明的实施例中，媒体网关通过创建上下文以及所述上下文内部的第一IP终端和第二IP终端，通过在所述第一IP终端和第二IP终端上设置收发实时流媒体协议RTSP消息的远端地址和本端地址；实现了媒体网关转发处理RTSP消息的功能；另外，可以使支持H.248协议的本身包含了住宅网关等媒体网关的用户终端设备支持收发RTSP消息的能力。

附图说明

图1是现有技术中NGN中MG和MGC组网示意图；

图2是现有技术中两个IP网络之间的边界网关互通示意图；

图3是本发明实施例一中传递RTSP消息的H.248终端上下文示意图；

图4是本发明实施例二中媒体网关控制器控制媒体网关直接应答RTSP消息的流程图；

图5是本发明实施例三中媒体网关控制器控制媒体网关继续前向发送RTSP消息的流程图；

图6是本发明实施例四中媒体网关控制器控制媒体网关收发RTSP消息流程图。

具体实施方式

媒体网关上通过IP终端处理RTSP消息过程如图3所示。本发明实施例中所涉及的RTSP消息可以为RTSP请求消息或RTSP应答消息等。其中，第一IP终端(即终端1，下文统称IP终端1)和第二IP终端(即终端2，下文统称IP终端2)分别在第一IP网络1(图中表示为IP网络1)和第二IP网络2(图中表示为IP网络2)中。IP终端是虚拟终端，是被分配在网络接口上的。终端1所在的网络接口在第一IP网络1中，终端2所在的网络接口在第二IP网络2中。终端1和终端2在收发和处理RTSP消息的同时可以用于收发和处理媒体数据流，例如RTP数据流和RTCP数据流，终端1和终端2也可以只用来收发和处理RTSP消息。IP终端上可以在不同的流描述符(streamdescriptor)中分别描述RTSP消息和媒体数据流，或者相同的流描述符中通过不同的SDP组(group)中分别描述RTSP消息和媒体数据流，因为收发以及处理媒体数据流是媒体网关已有的功能，这里不赘述。

媒体网关控制器控制媒体网关协商IP终端收发RTSP消息的本端(local)和远端(remote)地址，协商过程和协商媒体数据流的本端和远端地址类似。其中，分配本端地址，一般来说是接收媒体流或RTSP消息的目的地址，但是通常情况下也用该本端地址作为发送媒体流的源地址。同一个上下文中的IP终端1和IP终端2之间被设置拓扑连接关系。H.248协议支持的拓扑连接关系包括双向不导通，双向导通和单向导通。地址协商完成后，IP终端1从第一IP网络1接收到RTSP消息，通过上下文内部的终端之间的拓扑连接(此时拓扑允许从IP终端1到IP终端2导通)，将RTSP消息通过IP终端2发送到第二IP网络2；同理，IP终端2从第二IP网络2接收到的RTSP消息也可以通过上下文内部的终端之间的拓扑连接(此时拓扑允许从IP终端2到IP终端1导通)，将RTSP消息通过IP终端1发送到第一IP网络1。

上述在IP终端进行能力协商(包括收发地址协商和RTSP编解码协商)的过程可以通过SDP携带收发RTSP消息的IP地址和端口号来实现。例如，媒体网关控制器向媒体网关发送创建IP终端或者修改IP终端的命令，其中，

本地(或者说本端)SDP中包含如下部分：

v＝0

c＝IN IP4 $

m＝message $ udp RTSP

远端SDP包含如下部分：

v＝0

c＝IN IP4 192.168.200.10

m＝message 10000 udp RTSP

本地SDP中，”v＝0”表示SDP版本为0；”c＝IN IP4$”用来描述连接属性，”INIP4”表示使用internet协议的IPv4协议，”$”表示要求媒体网关为该终端分配地址；”m＝message $ udp RTSP”用来描述媒体属性，”UDP”表示使用UDP协议，”$”表示需要媒体网关分配一个UDP端口，”message”表示媒体类型为message，”RTSP”表示格式为RTSP。

远端SDP中，”v＝0”表示SDP版本为0；”c＝IN IP4 192.168.200.10”表示使用internet协议的IPv4协议，远端地址为192.168.200.10；”m＝message 10000 udpRTSP”表示远端使用UDP端口为10000，媒体类型为message，格式为RTSP。

虽然上述举例是通过UDP协议传输RTSP消息，但实际中也可以使用其它协议进行传输。如果使用其它的传输层协议，则SDP的m＝行也要作对应的改动。例如，如果该IP终端通过TCP协议传递RTSP协议，则本端的m＝行的格式为类似m＝application 9 tcp iptv rtsp的格式。

媒体类型和格式在协商过程中可以忽略，例如本端m＝行也可以为m＝-$udp-。

媒体网关向媒体网关控制器的应答消息中的本地SDP包含如下部分

v＝0

c＝IN IP4 192.168.200.100

m＝message 20000 udp RTSP

以上SDP表示媒体网关为该IP终端分配了地址192.168.100.100的20000端口用于传递UDP数据流，RTSP消息可以通过该地址进行收发。

RTSP描述部分和媒体流描述部分也可以在不同的流描述符中分别描述。也可以在一个流描述符中并存。例如：

v＝0

c＝IN IP4 $

m＝message $ udp RTSP

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 8

本发明实施例一中，媒体网关控制器通过创建或者修改终端向媒体网关通知远端SDP的信息，以及从媒体网关应答的消息中获得媒体网关为接收和/或发送RTSP消息分配的IP地址和端口。本发明不排除通过不同的地址分别接收和发送RTSP消息，但是，实际应用中通常使用相同的地址收发RTSP消息。另外，IP终端可以用于收发RTSP消息，也可以用来只接收或者只发送RTSP消息，例如只处理单向的RTSP消息的情况。实际应用中，还可能会分成多个H.248消息交互才能完成。例如，增加终端的时候媒体网关控制器不提供远端SDP信息，之后再通过修改终端的消息进行通知。通过设置终端1和终端2之间的拓扑关系，可以将终端1和终端2中的一个终端接收到的RTSP消息通过另外一个终端发送出去。

另外，如果转发RTSP消息的媒体网关支持路由模式下，媒体网关上创建接口级别的终端，这些终端上不使用前面描述的SDP方式来协商发送收发RTSP消息的IP地址和端口，但是仍然可以收发RTSP消息。

媒体网关收到RTSP消息后，还可以通过H.248事件上报给媒体网关控制器，媒体网关控制器进行决策后可以指示媒体网关发送应答的RTSP消息，也可以指示媒体网关的IP终端继续向前转发该RTSP消息，该RTSP消息在被转发前可以被媒体网关控制器指示更新。

还有一种方式是媒体网关进行自治。媒体网关的终端1侧接收到RTSP消息后，不上报给媒体网关控制器，而是自行通过终端2进行转发，转发前还可能自发地对RTSP消息进行修改。一些RTSP消息中带有媒体流信息，例如带有RTSP设备A接收的媒体流的IP地址AA1和端口P1，而该地址对于媒体流对端是不可见的，因此媒体网关自发在终端2侧的网络接口上分配IP地址BB2和端口P2用于接收该媒体流，而在转发RTSP消息时将RTSP消息中的AA1和P1替换成BB2和P2。对于反向的RTSP消息也要做类似处理，在媒体网关上自行分配媒体资源和替换RTSP消息中的相关内容。这里不再赘述。

在自治的方式下，当自行分配的媒体资源使用完毕后，媒体网关将其释放。

本发明实施例二是媒体网关控制器控制媒体网关继续前向发送RTSP消息的流程，请一同参阅图3与图5，包括以下步骤：

步骤s501，RTSP设备A向媒体网关发送第一RTSP请求消息。

步骤s502，媒体网关的终端1接收到该第一RTSP请求消息，通过H.248事件将该第一RTSP请求消息的内容上报给媒体网关控制器。终端1已经通过实施例1所述的方法确定了该终端接收RTSP请求消息的IP地址和端口，和/或，发送RTSP请求消息的目的IP地址和端口。

步骤s503，媒体网关控制器向媒体网关应答该Notify消息。

步骤s504，媒体网关控制器通过Modify消息指示媒体网关通过终端2发送第二RTSP请求消息。可以是第一RTSP请求消息本身，也可以是对该第一RTSP内容的描述，媒体网关可以根据这些信息以及自身保存的信息构造终端2要发送的第二RTSP请求消息。

终端2已经通过实施例1所述的方法确定了该终端2接收RTSP消息的IP地址和端口，和/或，发送RTSP请求消息的目的IP地址和端口。

在该步骤中，媒体网关控制器可以对终端1接收的RTSP请求消息中的内容进行替换，包括对媒体流收发地址进行替换。例如，假设在同一个IP终端上既处理媒体数据流又处理RTSP请求消息，图3中的第一IP网络1中的RTSP设备A在发出的RTSP消息M1中提供接收媒体流S1的IP地址A1和端口P1。该媒体流由第二IP网络2中的RTSP对端设备B提供。由于媒体网关的阻隔，该RTSP设备A对于第二IP网络2中的RTSP对端设备B来说不可直接路由到达，所以该RTSP请求消息被发送给媒体网关上的IP终端1，IP终端1的功能包括转发媒体流S1以及在IP网络中收发RTSP消息。第二IP网络2中的IP终端2的功能包括接收媒体流S1，以及在第二IP网络2中收发RTSP消息。媒体网关通过IP终端2在向RTSP远端设备B转发RTSP请求消息M1前，需要将其中的IP地址A1和端口P1替换成IP终端T2为接收媒体流S1分配的IP地址和端口。媒体流S1到达IP终端2后通过IP终端1发送到达第一IP网络1，最终被转发到第一IP网络1中的RTSP设备A。

同理，如果媒体流的接收端IP终端1需要获得媒体流的源IP地址和端口，则需要媒体网关在转发RTSP消息时对相应的头域或者SDP等作替换。其原理和前面描述的替换媒体流的目的地址相同。这是因为媒体流通过媒体网关转发后源地址被替换成媒体网关上发送该媒体流的IP地址和端口，所以RTSP消息中携带的发送媒体流的IP地址和端口也需要被替换成媒体网关上转发该媒体流时为其分配的用于发送该媒体流的IP地址和端口。

本实施例中，同一个终端，例如IP终端2，处理RTSP消息和媒体流时，该终端可以为RTSP消息和/或媒体流分配相同的或者不同的IP地址和端口。媒体网关还可以为RTSP消息和媒体流分别创建终端，但是多数情况下没有必要。在某些情况下，例如，对于同一个会话，媒体流和RTSP消息通过不同的路径传递(一种可能的情况是通过两个不同的媒体网关进行传递)，该媒体网关只负责收发RTSP消息而不收发涉及的媒体流。无论RTSP消息和媒体流是否通过同一个终端处理，其处理流程相同。

前面提到媒体网关上要分配IP地址和端口等资源用于收发媒体流。所以，在本步骤前隐含了一个可选步骤，即：媒体网关控制器通过H.248的ADD命令或者MODIDY命令指示媒体网关在新的终端或者已有终端上分配这些用于收发媒体流的资源。媒体网关在应答消息中将被分配的资源的IP地址和端口等信息通过SDP返回给媒体网关控制器。媒体网关控制器可以利用这些信息构造第二RTSP请求消息。

步骤s505，媒体网关根据指示通过终端2向RTSP对端设备发送第二RTSP请求消息。该第二RTSP请求消息的内容可能和步骤s501中的第一RTSP消息相同，也可能在媒体网关控制器的指示下对步骤s501中的第一RTSP消息做了更改。媒体网关可以通过设置终端1到终端2之间的拓扑关系(例如修改成isolate)避免终端2既发送媒体网关控制器指示发送的RTSP消息，又转发终端1接收到的RTSP消息。

步骤s506，媒体网关向媒体网关控制器发送Modify消息的应答消息。

步骤s506和步骤s505的次序可以颠倒。

步骤s507，媒体网关在终端2上接收到前述第二RTSP请求消息的应答消息。

步骤s508，媒体网关通过终端1向RTSP客户转发RTSP应答消息。

步骤s507和步骤s508之间，媒体网关可以向媒体网关控制器上报接收到的RTSP应答消息，并且接收媒体网关控制器的指示以确定向RTSP设备发送的RTSP应答消息的内容。其原理和步骤s502、步骤s503、步骤s504、步骤s506相同，这里不赘述。

媒体网关处理RTSP请求消息和处理RTSP应答消息可以是两个独立的过程，例如某个媒体网关只处理RTSP请求消息，而RTSP应答消息不通过该媒体网关传递(通过别的传输路径)，或者本媒体网关上的其它IP终端传递。将这两个过程放在图5的同一个流程中是为了完整说明一整个RTSP的请求加应答的流程，但是并不妨碍本发明只用在针对RTSP请求消息或者只针对RTSP应答消息。

如果媒体网关上配置了对该RTSP消息的处理规则，则步骤s502、步骤s503、步骤s504、步骤s506为可选。即媒体网关可以自己完成对该RTSP请求消息的前向转发，在被转发前该消息可以被媒体网关更新。该配置可以由媒体网关控制器设置或者更新。该配置可能包括媒体流收发IP地址和端口的替换逻辑以及RTSP消息中一些字段和头域等的替换逻辑等，该配置功能在后面有详细描述。

实施例二中的RTSP设备和RTSP对端设备分别是RTSP客户端和RTSP服务器，或者分别是RTSP服务器和RTSP客户端。如果协议允许RTSP客户端之间或者RTSP服务器之间进行RTSP协议交互，则RTSP设备和RTSP对端设备也可能同为RTSP客户端或者RTSP服务器。

根据本发明实施例，媒体网关控制器控制媒体网关协商IP终端收发RTSP消息的本端(local)和远端(remote)地址后，在某些场景下，单个的IP终端也能够实现对RTSP消息的处理。为与实施例二进行区别，将单独处理RTSP消息的IP终端称为第三IP终端，该第三终端处理的RTSP消息为第三RTSP消息。该第三IP终端可以为图3中的终端1、终端2或者是专门创建的终端。下面通过具体的应用场景进行说明。

本发明实施例三是媒体网关控制器控制媒体网关直接应答RTSP消息的流程，如图4所示，所述的第三终端具体为终端1，包括以下步骤：

步骤s401，RTSP设备向媒体网关发送第三RTSP消息，如RTSP请求消息。

步骤s402，媒体网关的终端1接收到该RTSP请求消息，通过H.248事件将该RTSP请求消息的内容上报给媒体网关控制器。终端1已经通过实施例1所述的方法指定了接收RTSP消息的IP地址和端口。

步骤s403，媒体网关控制器向媒体网关应答该Notift消息。

步骤s404，媒体网关控制器通过Modift消息指示媒体网关通过终端1发送RTSP应答消息。该消息中携带RTSP应答消息的内容，可以是RTSP消息本身，也可以是对该RTSP内容的描述。例如，如果RTSP请求中要求的带宽无法满足，则媒体网关控制器指示媒体网关应答错误码。

步骤s405，媒体网关根据指示通过终端1发送RTSP应答消息。

步骤s406，媒体网关向媒体网关控制器发送Modify消息的应答消息。

步骤s406和步骤s405的次序可以颠倒。如果媒体网关上配置或者由媒体网关控制器设置了对该RTSP消息的处理逻辑，则步骤s402、步骤s403、步骤s404和步骤s406为可选，即媒体网关可以自己完成对该RTSP请求消息的应答，不需要与媒体网关交互控制信息。其中，RTSP设备是RTSP客户端(client)或者RTSP服务器(server)。

本发明实施例四中，如果H.248终端设备(例如UE中的RG设备)需要支持RTSP协议功能，则需要媒体网关控制器控制媒体网关收发RTSP消息，如图6所示，包括以下步骤：

步骤s601，媒体网关控制器通过Modify消息指示媒体网关通过第三IP终端(终端3)发送第三RTSP消息，如RTSP请求消息。该消息中携带RTSP消息的内容。终端3已经通过实施例1所述的方法确定了该终端接收RTSP请求消息的IP地址和端口，和/或，发送RTSP请求消息的目的IP地址和端口。

步骤s602，媒体网关根据指示通过终端3发送媒体网关控制器要求发送的RTSP请求消息。

步骤s603，媒体网关向媒体网关控制器发送Modift消息的应答消息。

步骤s603和步骤s604的次序可以颠倒。

步骤s604，媒体网关在终端3上接收到RTSP应答消息。

步骤s605，媒体网关通过H.248事件将接收到的RTSP应答消息的内容上报给媒体网关控制器。

步骤s606，媒体网关控制器向媒体网关应答该Notify消息。

媒体网关上涉及到分配资源进行媒体流收发时，媒体网关控制器通过在媒体网关上创建或者修改终端的方式分配资源。媒体网关在应答消息中返回的IP地址和端口等资源信息被用于RTSP消息中描述媒体信息。

本发明实施例五中，媒体网关可以作为媒体流的缓存(cache)。媒体网关上缓存媒体数据，如图3所示，媒体网关接收到RTSP设备A发送的请求获得媒体流的请求后，可以向RTSP设备B请求媒体流，也可以将自身已经缓存的媒体数据提供给RTSP设备A。在这种情况下，媒体网关可以终结RTSP消息，给RTSP设备A发送应答消息，进而将自身缓存的媒体流数据提供给RTSP设备A。RTSP设备A请求的媒体流还可以部分由媒体网关中的缓存提供，部分由媒体网关向其它RTSP设备(例如图3中的RTSP设备B)请求获得后转发给RTSP设备A。在该实施例的情况下，媒体网关可以自行对RTSP设备A的RTSP请求消息进行应答，也可以将RTSP设备A发来的RTSP请求消息的内容上报给媒体网关控制器，还可以进而由媒体网关控制器指示向RTSP设备A发送应答消息。媒体网关在RTSP设备B这一侧也同理，媒体网关可以自己收发RTSP消息，也可以在媒体网关控制器的指示下上报接收到的RTSP消息的内容和/或发送RTSP消息。

为了实现实施例二到实施例五中的各个流程，需要对H.248协议做扩展，扩展要完成的基本功能如下：媒体网关通过扩展的事件上报检测到的RTSP消息，上报事件中携带RTSP消息的内容；媒体网关控制器通过扩展的信号指示媒体网关发送RTSP消息，信号中通过参数携带要发送的RTSP消息的内容；媒体网关控制器通过扩展的属性向媒体网关设置处理RTSP消息的规则，例如更改RTSP消息头域的规则，根据这些规则，媒体网关可以自主完成对RTSP消息的更新和转发，减少和媒体网关控制器之间的消息交互。

以下是该扩展的一个具体方案：扩展H.248包RTSPfunc，在RTSPfunc包中扩展事件RTSPe，该事件的参数包括：

1、方法(method)过滤参数mf，通过该参数，媒体网关控制器指示媒体网关需要上报的RTSP方法列表。例如只要求检测上报setup方法和teardown方法。该参数的数据类型为枚举列表，枚举值为RTSP协议支持的各方法。

2、承载层转发开关参数tt，通过该参数，媒体网关控制器指示媒体网关是否在承载层前向转发已经被上报的RTSP消息，例如图三中终端1接收到RTSP消息后是否在承载层通过终端2前向转发。媒体网关控制器接收到该事件后可能会对RTSP消息进行更新后指示媒体网关通过终端2进行转发，但是，媒体网关内部也可以通过拓扑关系(此时拓扑允许从终端1到终端2导通)对该RTSP消息进行转发，这样会有双份RTSP消息发往目的地址。所以如果媒体网关控制器准备自己控制转发上报的RTSP消息，可以通过该参数指示媒体网关是否在承载层向前转发已经上报的RTSP消息。该参数的数据类型为开关变量。取值为on/off，默认值为on。on表示媒体网关自行前向转发。Off表示媒体网关不前向转发。

还可以定义参数要求媒体网关上报涉及QoS指标的RTSP消息。例如，定义如下参数：

3、带宽上报参数br，该参数为开关变量，取值为on/off，默认值为off；如果该开关值为on，如果终端接收到的RTSP消息中涉及到传输带宽，则需要上报。

4、速度改变参数sc，该参数为开关变量，取值为on/off，默认值为off；如果该开关值为on，如果终端接收到的RTSP消息中speed头域值发生变化，则需要上报。

还可以定义其它一些参数，当RTSP消息中携带其它涉及到QoS指标的信息时，触发媒体网关的事件上报。

5、媒体流携带参数sap，该参数为开关变量，取值为on/off，默认值为on；如果该开关值为on，如果终端接收到的RTSP消息中携带了媒体流描述信息，则需要上报。

6、指定报告内容参数rc，该参数描述媒体网关控制器需要媒体网关上报的信息形式.例如可以用该参数指定要求媒体网关上报整个RTSP消息体，也可以通过该参数指定只要求上报RTSP消息中被指定的部分的内容，举例说明如下：指定要求媒体网关上报指定内容(例如Speed头域等)，指定要求媒体网关上报指定头域中指定具体选项的内容(例如Transport头域的dest_addr和src_addr字段等)。通过该参数，媒体网关控制器可以从媒体网关获得所需要的内容。

该事件上报的参数(ObservedEventsDescriptor参数)包括：

1、RTSP消息内容。可以定义通过该参数直接将整个RTSP消息作为该参数的内容上报给媒体网关控制器。该情况下该参数的数据类型是字串。

媒体网关可能被要求将RTSP消息的内容分解后上报指定的内容，例如上报RTSP消息的Transport头域中的源地址和目的地址等.还可以定义相应的参数一一实现上报RTSP消息分解后的各个媒体网关控制器要求上报的单项信息.参数的定义方法不唯一，这里不赘述。

定义信号RTSPs，该信号的参数包括：RTSP消息内容，可以定义将整个RTSP消息作为该参数的内容下发给媒体网关，该参数的数据类型是字符串。媒体网关接收到该信号后，将参数中携带的RTSP消息发送到remote描述符指定的地址。其它的可行办法是将RTSP消息的内容分解成各项信息分别在多个参数中下发，媒体网关根据该这些参数中携带的信息构造RTSP消息并发送.具体细节这里不一一赘述。

定义媒体网关控制器向媒体网关设置处理RTSP消息的规则可以通过如下属性：

1、定义属性requrl，该属性用于媒体网关控制器向媒体网关设置处理RTSP消息中的”Request-URI”部分的规则。该属性的数据类型为字符串。该参数默认为空，表示不对“Request-URI“进行转换。如果requrl参数的值为”RTSP://example.com/fizzle/foo”，媒体网关在设置了该参数的终端上收到如下消息：

C->S:TEARDOWN RTSP://bigserver.com/fizzle/foo RTSP/1.0

CSeq:892

Session:12345678

则媒体网关在前向转发该消息时会将发出的消息修改成

C->S:TEARDOWN RTSP://example.com/fizzle/foo RTSP/1.0

CSeq:892

Session:12345678

2、定义属性srcaddrexp，该属性的数据类型为字符串.代表需要将收到的RTSP消息中的Transport头域的src_addr字段的内容替换成的值.例如，该属性值为″10.11.1.100:9000″/″10.11.1.100:9001″代表将接收到的Transport头域的src_addr字段的内容替换成″10.11.1.100:9000″/″10.11.1.100:9001″。

还可以定义类似属性用来替换RTSP消息中SDP中涉及的媒体流源地址和/或目的地址。

媒体网关收发RTSP消息的IP终端和收发媒体流的IP终端可以是相同的IP终端，也可以不同的IP终端。单播媒体流通过媒体网关后，媒体流源地址会变成媒体网关上发送该媒体流的源地址；单播媒体流到达媒体网关时，媒体流目的地址是媒体网关的地址，在媒体网关将其在另外一侧的IP网络中转发出去时，目的地址也需要被更新成目的地的地址。被媒体网关转发的RTSP消息中可能携带RTSP设备自身收发媒体流的IP地址和端口，而一般来说媒体网关一侧的IP网络中的设备地址对另外一侧的IP网络中的设备来说是不可以直接到达的，所以媒体网关需要将被自己转发处理的RTSP消息中携带的媒体流的源地址和目的地址中受影响的部分替换成媒体网关的IP终端上分配的地址。

为了便于说明，本发明中媒体流源地址表示媒体流的源IP地址和端口，目的地址表示目的IP地址和端口。

下面用一个示例描述前述地址转换过程，结合图2，具体过程包括：

1、终端1接收到RTSP设备A如下RTSP消息：

C->S:SETUP RTSP://example.com/foo/bar/baz.rm RTSP/2.0

CSeq:302

Transport:RTP/AVP；unicast；dest_addr＝″:4588″/″:4589″，

RTP/AVP/TCP；unicast；interleaved＝0-1

媒体流的目的端口是4588和4589，而媒体网关在第二IP网络2侧为该媒体流分配的端口是8000和8001。

2、终端2向RTSP消息的目的设备B转发该RTSP消息时发出的是：

C->S:SETUP RTSP://example.com/foo/bar/baz.rm RTSP/2.0

CSeq:302

Transport:RTP/AVP；unicast；dest_addr＝″:8000″/″:8001″，

RTP/AVP/TCP；unicast；interleaved＝0-1

3、终端2接收到如下应答消息：

S->C:RTSP/2.0200OK

CSeq:302

Date:23 Jan 1997 15:35:06 GMT

Server:PhonyServer 1.1

Session:47112344；timeout＝60

Transport:RTP/AVP；unicast；dest_addr＝″:8000″/″:8001″；

src_addr＝″192.0.2.241:6256″/″192.0.2.241:6257″；

ssrc＝2A3F93ED

Accept-Ranges:NPT

192.0.2.241:6256″和″192.0.2.241:6257″是该媒体流的源IP地址和端口，而媒体网关为该媒体流在第一IP网络1侧分配的IP地址和端口是10.11.1.100:9000和10.11.1.100:9001。

4、终端1向RTSP设备A转发该RTSP消息时发出的是：

Session:47112344；timeout＝60

Transport:RTP/AVP；unicast；dest_addr＝″:4588″/″:4589″；

src_addr＝″10.11.1.100:9000″/″10.11.1.100:9001″；

ssrc＝2A3F93ED

Accept-Ranges:NPT

通过对媒体流收发地址的替换，实现了媒体网关两侧的RTSP设备都和媒体网关上的IP终端交互媒体流，而媒体网关在其中对RTSP消息起到了变换和传递功能。对RTSP消息的变换和传递功能有如下两个方法：

一种是媒体网关上报接收到的RTSP消息给媒体网关控制器，由媒体网关控制器将要发送的RTSP消息的信息发给媒体网关，该信息中携带了转换后的IP地址和端口。图5的流程中的步骤502到步骤506使用了该方法。

另一种是提前将转换规则下发给媒体网关，媒体网关按照规则替换RTSP消息中的相关的部分，例如媒体流IP地址和端口，指定的头域，字段等。

本发明实施例还提供了一种处理实时流媒体协议的系统，包括：媒体网关，用于接收媒体网关控制器指示创建上下文以及所述上下文内部的第一IP终端和第二IP终端，在所述第一IP终端和第二IP终端上设置收发实时流媒体协议RTSP消息的远端地址；在所述第一IP终端和第二IP终端上分配收发实时流媒体协议RTSP消息的本端地址；并通过所述第一IP终端从所述第一IP终端所在的IP网络接收到RTSP消息，所述RTSP消息保持不变或者进行修改后通过所述第二IP终端发送到所述第二IP终端所在的IP网络。媒体网关控制器，用于指示所述媒体网关创建上下文以及所述上下文内部的第一IP终端和第二IP终端，在所述第一IP终端和第二IP终端上设置收发实时流媒体协议RTSP消息的本端地址和远端地址。

所述媒体网关具体包括：拓扑连接设置单元，用于接收媒体网关控制器指示创建上下文以及所述上下文内部的第一IP终端和第二IP终端，在所述第一IP终端和第二IP终端上设置收发实时流媒体协议RTSP消息的远端地址；在所述第一IP终端和第二IP终端上分配收发实时流媒体协议RTSP消息的本端地址；RTSP消息收发单元，用于通过所述第一IP终端从所述第一IP终端所在的IP网络接收到RTSP消息，所述RTSP消息保持不变或者进行修改后通过所述第二IP终端发送到所述第二IP终端所在的IP网络。

所述拓扑连接设置单元具体包括：拓扑连接存储子单元，用于预先存储由媒体网关控制器预先设定的IP终端收发RTSP消息的本端和远端地址；获取由媒体网关控制器设置IP终端发送RTSP消息的本端和远端地址。

所述媒体网关还包括：事件上报单元，用于第一IP终端从所述第一IP终端所在的IP网络检测媒体网关控制器要求检测的第一RTSP消息，通过事件将所述第一RTSP消息的内容上报给媒体网关控制器；命令接收单元，用于根据所述媒体网关控制器下发的命令，从所述接收IP终端发送应答的RTSP消息，或通过其他IP终端转发所述RTSP消息。

所述媒体网关还包括：消息更新单元，用于根据媒体网关控制器下发的扩展信号指示确定要发送的RTSP消息的内容。

本发明实施例还提供了一种处理实时流媒体协议的系统，包括：媒体网关，用于根据媒体网关控制器的指示创建上下文以及所述上下文内部的第三IP终端，协商其上第三IP终端收发实时流媒体协议RTSP消息的远端地址和本端地址；并通过所述第三IP终端从所述第三IP终端所在的IP网络接收到第三RTSP消息后，将所述第三RTSP消息的内容上报给媒体网关控制器。

本发明的实施例中，使边界网关具备转发和处理RTSP消息的能力；使支持H.248协议的用户终端设备支持收发tsp消息的能力。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims

1.一种处理实时流媒体协议消息的方法，其特征在于，包括以下步骤：

所述媒体网关通过所述第一IP终端从第一IP网络接收到第一RTSP消息后，所述媒体网关将所述第一RTSP消息的内容上报给媒体网关控制器；

所述媒体网关接收媒体网关控制器指示，通过所述第二IP终端发送第二RTSP消息，所述第二RTSP消息由媒体网关控制器指定，其内容和所述第一RTSP消息相同，或者其内容为所述媒体网关控制器对所述第一RTSP消息进行了修改后的内容。

2.如权利要求1所述的方法，其特征在于，所述媒体网关在所述第一IP终端和/或第二IP终端上进一步设置承载RTSP消息的传输层协议类型，通过设置的传输层协议进行RTSP消息的传输。

3.如权利要求1所述的方法，其特征在于，

所述收发RTSP消息的本端地址包括：收发RTSP消息的本端IP地址和端口号；

所述收发RTSP消息的远端地址包括：收发RTSP消息的远端IP地址和端口号。

4.如权利要求1所述的方法，其特征在于，将所述第一RTSP消息进行修改，修改的内容包括第一RTSP消息中包含的媒体流源地址和/或目的地址，则所述第二RTSP消息中包含修改后的媒体流源地址和/或目的地址。

5.如权利要求1所述的方法，其特征在于，所述协商所述第一IP终端收发实时流媒体协议RTSP消息的远端地址和本端地址，以及第二IP终端收发实时流媒体协议RTSP消息的远端地址和本端地址的步骤包括：媒体网关接收媒体网关控制器下发的扩展的信息，根据所述扩展的信息为所述第一IP终端和所述第二IP终端分配相应的地址。

6.一种处理实时流媒体协议消息的方法，其特征在于，包括以下步骤：

媒体网关根据媒体网关控制器的指示创建上下文以及所述上下文内部的第三IP终端，协商所述第三IP终端收发实时流媒体协议RTSP消息的远端地址和本端地址；

7.如权利要求6所述的方法，其特征在于，所述第三RTSP消息为RTSP请求消息，所述方法进一步包括：

所述媒体网关根据所述媒体网关控制器的指示通过所述第三IP终端发送RTSP应答消息。

8.如权利要求6所述的方法，其特征在于，所述第三RTSP消息为RTSP应答消息，所述媒体网关通过所述第三IP终端从所述第三IP终端所在的IP网络接收到第三RTSP消息之前还包括：

所述媒体网关根据媒体网关控制器指示通过所述第三IP终端发送RTSP请求消息。

9.如权利要求6所述的方法，其特征在于，还包括：媒体网关缓存媒体流数据，通过所述第三IP终端接收到媒体流请求后，将自身缓存的媒体流数据提供给所述媒体流请求的发起设备。

10.一种处理实时流媒体协议消息的系统，其特征在于，包括媒体网关控制器以及媒体网关，其中：

所述媒体网关控制器，用于指示所述媒体网关创建上下文以及所述上下文内部的第一IP终端和第二IP终端，在所述第一IP终端和第二IP终端上设置收发实时流媒体协议RTSP消息的本端地址和远端地址；

所述媒体网关，用于根据所述媒体网关控制器的指示创建上下文以及所述上下文内部的第一IP终端和第二IP终端，在所述第一IP终端和第二IP终端上设置收发实时流媒体协议RTSP消息的远端地址；在所述第一IP终端和第二IP终端上分配收发实时流媒体协议RTSP消息的本端地址；并通过所述第一IP终端从所述第一IP终端所在的IP网络接收到RTSP消息，所述RTSP消息保持不变或者进行修改后通过所述第二IP终端发送到所述第二IP终端所在的IP网络。

11.如权利要求10所述的系统，其特征在于，所述媒体网关具体包括：

拓扑连接设置单元，用于接收媒体网关控制器指示创建上下文以及所述上下文内部的第一IP终端和第二IP终端，在所述第一IP终端和第二IP终端上设置收发实时流媒体协议RTSP消息的远端地址；在所述第一IP终端和第二IP终端上分配收发实时流媒体协议RTSP消息的本端地址；

RTSP消息收发单元，用于通过所述第一IP终端从所述第一IP终端所在的IP网络接收到RTSP消息，所述RTSP消息保持不变或者进行修改后通过所述第二IP终端发送到所述第二IP终端所在的IP网络。

12.如权利要求11所述的系统，其特征在于，所述拓扑连接设置单元具体包括：

拓扑连接存储子单元，用于预先存储由媒体网关控制器预先设定的IP终端收发RTSP消息的本端和远端地址；获取由媒体网关控制器设置IP终端发送RTSP消息的本端和远端地址。

13.如权利要求11所述的系统，其特征在于，所述媒体网关还包括：

事件上报单元，用于第一IP终端从所述第一IP终端所在的IP网络检测媒体网关控制器要求检测的第一RTSP消息，通过事件将所述第一RTSP消息的内容上报给媒体网关控制器；

命令接收单元，用于根据所述媒体网关控制器下发的命令，从所述第一IP终端发送应答的RTSP消息，或通过其他IP终端转发所述RTSP消息。

14.如权利要求11所述的系统，其特征在于，所述媒体网关还包括：

消息更新单元，用于根据媒体网关控制器下发的扩展信号指示确定要发送的RTSP消息的内容。