CN101309203A - 一种网络媒体服务方法 - Google Patents

Abstract

本发明公开了一种网络媒体服务方法，将作为媒体流提供端的媒体源作为客户端，作为媒体流请求端的流服务器作为服务端；流服务器在监听端口等待媒体源的连接请求，媒体源主动连接流服务器，发送媒体流的媒体描述信息到流服务器，流服务器建立起服务会话并维护媒体描述信息；媒体源和流服务器协商媒体流的传输方式，当媒体源的媒体流传输准备就绪时通知流服务器，流服务器接收到终端播放器的流服务请求时，通知媒体源开始发送媒体流，接收媒体源的媒体流，缓冲并转发给终端播放器。采用本发明所述方法，不影响现有网关设备，不占用公网IP资源，是一种公私网通用的网络媒体服务方法，特别适合在网络地址转换后大规模部署媒体源的应用场合。

Description

一种网络媒体服务方法

技术领域

本发明涉及网络多媒体技术领域，具体涉及一种解决NAT(Net AddressTranslation，网络地址转换)穿越问题的网络媒体服务方法。

背景技术

目前，随着互联网的普及和多媒体技术在互联网上的广泛应用，迫切需要能解决实时传送音频、视频和计算机动画等媒体文件的技术，流式传输技术及流媒体便是在这种背景下应运而生的。

通俗的讲，在互联网上的音频服务器和视频服务器将声频、图像或动画等媒体文件从服务器向客户端实时连续传输时，用户不必等待全部媒体文件下载完毕，而只需延迟几秒或十几秒，就可以在用户的计算机上播放，而文件的其余部分则由用户的计算机在后台继续接收，直至播放完毕或用户中止操作，这种技术使用户在播放音频、视频或动画等媒体的等待时间成百倍的减少，而且不需要太多的缓存。

在一个完整的流媒体服务系统中，按照媒体数据的流动方向，可以将网络节点划分为媒体源、流服务器、终端播放器三大部分。媒体源负责媒体流的编码和网络发送，一般由编码器实现，流服务器负责媒体流的存储或转发控制，终端播放器负责媒体流的解码和呈现，三部分由适合多媒体实时传输协议的网络进行连接。

流媒体服务中一般的控制协议采用客户端/服务器体系结构，请求媒体码流的一方为客户端，提供媒体码流的一方为服务端。服务端等待客户端媒体请求，接收到客户端的请求后，解析请求取得客户端的IP地址和端口号，然后将请求的媒体数据发送到客户端。因此，在整个媒体流服务提供过程中，流服务器一方面作为终端播放器的服务端，另一方面则作为媒体源的客户端。

随着Internet(互联网)网络的普及，很多Intranet(内联网)的视频需要在Internet网络上点播，此时媒体源位于网关设备之后，现有网关设备通常运行NAT功能，所以媒体源是位于私网的，例如电信级视频监控系统广泛分布的监控前端就是部署在运营商私网之内的。根据上述接收和发送机制，媒体源位于私网造成的问题是流服务器无法访问媒体源，也不能将媒体码流转发给终端播放器。

对上述这种NAT穿越问题，目前业界常用的解决方案是ALG(ApplicationLayer Gateway，应用层网关)和Proxy Server(代理服务器)。ALG是最简单的方法，但是大量现网网关设备并不支持特定业务，升级是不现实的，而使用ProxyServer显著增加设备投资，并且占用公网IP，因此也不能为运营商所接受。

发明内容

为了克服现有技术中存在的问题，本发明提供一种网络媒体服务方法，即，针对流服务器位于公网总能访问的特点，在媒体流提供服务过程中变换服务端和客户端角色，从而将运营商私网媒体源的媒体流顺利传送到播放器终端，实现对位于运营商私网的媒体源的音频码流和视频码流的接收、转发或存储，而且不影响现网网关设备，也不增加额外的硬件设备投资和公网IP资源消耗。

本发明具体是这样实现的：

一种网络媒体服务方法，进行如下处理：

将作为媒体流提供端的媒体源作为客户端，作为媒体流请求端的流服务器作为服务端；

流服务器在监听端口等待媒体源的连接请求，媒体源主动连接流服务器，发送媒体流的媒体描述信息到流服务器，流服务器建立起服务会话并维护媒体描述信息；

媒体源和流服务器协商媒体流的传输方式，当媒体源的媒体流传输准备就绪时通知流服务器，流服务器接收到终端播放器的流服务请求时，通知媒体源开始发送媒体流，接收媒体源的媒体流，缓冲并转发给终端播放器。

在流服务器等候终端播放器的流服务请求时，为了维护其与流服务器两者之间的媒体通道，媒体源每隔一定时间向流服务器的服务程序发送握手消息。

流服务器在规定的时间内没有收到媒体源发送的握手消息，则认为媒体源已经宕掉，关闭服务会话，删除媒体描述信息。

在一定的时间内，流服务器没有收到终端播放器的流服务请求，则流服务器通知媒体源停止发送媒体流，继续保持流服务器与媒体源间的媒体连接，等候后续的终端播放器的流服务请求，直至媒体源主动断开媒体连接。

所述的媒体源主动断开媒体连接，是指：

基于系统静态配置或负载均衡的考虑，媒体源主动向流服务器发出关闭媒体连接请求，流服务器收到该请求后，关闭服务会话，删除媒体描述信息。

所述流服务器收到终端播放器的流服务请求时，进行如下处理：

流服务器查询与请求所对应的媒体源的连接状况，如果连接没有建立，则流服务器拒绝终端播放器的流服务请求；如果连接建立，则向媒体源发送媒体流数据请求消息，媒体源开始向流服务器发送媒体流数据。

在多媒体网络中，媒体源位于网关或NAT之后，本发明提出的网络媒体服务方法，将流服务器与媒体源建立媒体连接，顺利将媒体数据转发至终端播放器或保存于网络存储设备，从而实现网络媒体服务的方法，本发明有效的解决了媒体源在NAT后常规流服务方法的媒体控制信令无法穿越NAT的问题，并且不影响现有网关设备，不占用公网IP资源，是一种公私网通用的网络媒体服务方法，特别适合在NAT后大规模部署媒体源的应用场合，如电信级视频监控系统等。

附图说明

图1是本发明应用场景示意图；

图2是本发明实施例应用实例基本流程示意图。

具体实施方式

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

如图1所示，网络流媒体服务系统包括一个或多个流服务器以及通过网络与流服务器相连的一个或多个编码器，编码器作为媒体源与流服务器一般是一对一的关系。

其中，编码器可以是编码硬件设备或编码软件程序，采集各种数字或模拟音频数据和视频数据，实时压缩编码成符合ISO和ITU等标准的音频和视频，并以流媒体的方式进行Intranet和Internet传播等功能，编码器可以分布于固定或移动的公众场合、行业内部等，最终接入运营商网络。

运营商网络节点部署流服务器和存储等设备，流服务器具有外网IP地址，能够被外网或者内网访问，流服务器能够根据终端播放器的流服务请求，把编码器的实时码流传送给终端播放器。

对于流服务器而言，对处于内网的编码器所在设备的IP地址和端口是不可知的，因此流服务器不能按照常规处理向编码器发送媒体请求从而接收编码器的媒体码流并转发给终端播放器。但是流服务器通常位于外网，编码器的信令和码流可以穿透NAT正确发送给流服务器。

因此，对编码器和流服务器的客户端/服务器角色加以转换，由流服务器监听编码器的媒体连接请求，编码器主动连接流服务器，告诉流服务器相关的媒体描述信息，流服务器维护媒体描述信息并建立起服务会话，然后编码器和流服务器协商媒体流的传输方式，当编码器的媒体码流(例如，音频流和视频流)传输准备就绪时通知流服务器，流服务器接收到终端播放器的流服务请求时，通知编码器开始发送媒体码流，接收编码器的媒体码流，缓冲并转发给终端播放器。

如果一段时间内没有任何终端播放器需要流服务，流服务器通知编码器停止发送媒体码流，从而节省系统开销和带宽，但是流服务器与编码器间的媒体连接还是继续保持，等候后续的终端播放器的流服务请求，直至编码器基于一定的策略主动断开媒体连接，服务器将删除媒体描述信息并撤销服务会话，这个过程对处于外网的编码器也同样适用。

本发明上述方法的具体工作步骤如下：

步骤1，流服务器在监听端口等待编码器的连接请求。

步骤2，编码器向流服务器IP地址和监听端口发送音频流描述请求消息和视频流描述请求消息，消息包含了编码器音频流和视频流的媒体描述信息，流服务器接收到请求后建立服务会话，并维护媒体描述信息。

步骤3，编码器与流服务器进行媒体流传输方式协商。

步骤4，编码器向流服务器发送音频流和视频流就绪通知消息，告知流服务器音频流和视频流已经准备就绪，正在等待流服务器的后续命令以开始音频流和视频流的网络传输。

步骤5，编码器向流服务器发送握手消息，用于维护两者间的媒体通道，等候后续的终端流服务请求，编码器每隔一定时间(例如，20秒)向流服务器的服务程序发送该消息，服务器在一定时间内(例如，20秒或者40秒)没有收到该消息的时候，就认为编码器已经宕掉，关闭服务会话，删除媒体描述信息。

步骤6，流服务器收到终端播放器的流服务请求，查询与请求所对应的编码器的连接状况，如果连接没有建立，流服务器拒绝终端播放器的流服务请求，实现上可以通过业务逻辑避免这种情况的发生，如果流服务器查询到连接后，向编码器发送音频数据请求消息和视频数据请求消息，编码器开始向流服务器发送音频数据和视频数据。

步骤7，流服务器接收并向终端播放器转发实时媒体数据，服务过程中流服务器可以控制音频数据和视频数据的停止和发送。

由流服务器控制的停止音频数据和视频数据传输的情况是，流服务器检测到一定时段内(例如，30秒或者60秒)没有终端播放器请求媒体流，则向编码器发送停止发送音频数据请求消息和视频数据请求消息，编码器停止向流服务器发送音频数据和视频数据。

步骤8，编码器向流服务器发出关闭媒体连接请求，流服务器收到该请求后，关闭服务会话，删除媒体描述信息。编码器主动关闭媒体连接可以是基于系统静态配置或负载均衡动态策略等不限。

步骤1至步骤8的实现可以选择全新实现或者基于现有媒体控制协议做扩展，如RTSP(Real-time Streaming Protocol，实时流协议)和扩展、SIP和扩展，对协议种类和扩展形式不限。

如图2所示，是本发明所述方法的具体实施例的一个应用实例——电信级视频监控业务中基于RTSP协议的实时码流服务：在电信级视频监控系统中，监控前端是集成了摄像头、麦克风、告警检测、编码器、网卡等功能的设备，监控前端数量繁多，广泛分布于内网，最终通过NAT接入运营商网络，运营商网络的流服务器具有外网地址，用于接收和转发监控前端的实时码流，监控客户端负责将码流解码呈现给用户。

监控前端提供MPEG-4的视频，视频传输遵循RFC3016(用于MPEG-4视听流的RTP负载格式)，音频传输遵循ISMA协议规范，监控前端和流服务器的媒体交互消息采用RTSP协议及其扩展实现。

根据本发明所述方法，电信级监控业务中基于RTSP协议的实时码流服务，具体是这样实现的：

步骤1，运营商网络流服务器打开RTSP监听端口，等待监控前端的连接请求；

步骤2，内网的监控前端上电，读取配置信息，得到流服务器IP地址和RTSP监听端口号，向流服务器发送RTSP ANNOUNCE(实时流协议应答)消息，包含监控前端的SDP(Session Description Protocol，会话描述协议)信息，RTSP消息格式参见标准RTSP协议，此处不再赘述；

步骤3，流服务器收到RTSP ANNOUNCE消息后，保存SDP，创建RTSP服务会话；

步骤4，监控前端向流服务器发送RTSP SETUP(实时流协议建立)消息，根据监控前端的SDP，步骤4可重复进行多次，选择RTP(Real-time TransportProtocol，实时传输协议)/TCP/IP或RTP/UDP/IP传输方式。

步骤5，流服务器收到SETUP消息后，响应服务器的传输端口等信息；

步骤6，监控前端主动向流服务器发送UDP包以打通到流服务器的RTP和RTCP传输通道，码流发送准备就绪后，向流服务器发送RTSP RECORD命令和“x-WAITPLAY：yes”x-WAITPLAY扩展，流服务器的响应中也需要带上x-WAITPLAY扩展。

扩展消息格式如下：

监控前端-＞流服务器RECORD URL RTSP/1.0CSeq：<seq number>x-WAITPLAY：yes
	流服务器-＞监控前端RTSP/1.0200OKCseq：<seq number>x-WAITPLAY：yes
[注]关键域为x-WAITPLAY，取值为yes，表示等待后续命令才开始媒体码流的传输。

步骤7，流服务器收到监控客户端的实时监控请求，找到对应的监控前端连接会话，向监控前端发送RTSP SET_PARAMETER消息和“PLAY：START”x-PLAYCTRL扩展，监控前端开始向流服务器发送媒体码流，流服务器接收到码流后转发给监控客户端。

扩展消息格式如下：

S-＞CSET_PARAMETER URL RTSP/1.0CSeq：<seq number>x-PLAYCTRL：“Method：Value”
	C-＞SRTSP/1.0200OKCseq：<seq number>
[注]关键域为x-PLAYCTRL，“Method：Value”对暂时定义值为“PLAY：START|Stop”，表示开始(PLAY：START)或者暂停(PLAY：START)音频流和视频流的传输，START和Stop不能同时存在。

步骤8，流服务器检测到连续30秒没有收到监控客户端的服务请求时，向监控前端发送RTSP SET_PARAMETER消息和“PLAY：STOP”x-PLAYCTRL扩展，监控前端停止媒体码流的发送。

步骤9，监控前端向流服务器发送RTSP OPTION消息保持媒体连接，如果流服务器超过20秒收不到OPTION消息，主动断开连接，回收资源。

步骤10，监控前端向流服务器发送RTSP TEARDOWN消息断开媒体连接，流服务器回收资源。

本发明提出的网络媒体服务方法，转变一般流媒体服务过程中媒体源作为服务器而流服务器作为客户端的常规模式，对运营商私网的媒体源的音频码流和视频码流进行接收、转发或存储，不影响现网网关设备，不增加额外的硬件设备投资和运营商IP资源消耗，是一种公私网通用的网络媒体服务方法，特别适合在NAT后大规模部署媒体源的应用场合。

这里需要指出的是，本发明中的具体实施例只是列举了本发明的个别实例，使用本发明的设计思想及其任何等效变换实现的监控告警录像，均应属于本发明的保护范围。

Claims (6)

1.一种网络媒体服务方法，其特征在于：

将作为媒体流提供端的媒体源作为客户端，作为媒体流请求端的流服务器作为服务端；

流服务器在监听端口等待媒体源的连接请求，媒体源主动连接流服务器，发送媒体流的媒体描述信息到流服务器，流服务器建立起服务会话并维护媒体描述信息；

媒体源和流服务器协商媒体流的传输方式，当媒体源的媒体流传输准备就绪时通知流服务器，流服务器接收到终端播放器的流服务请求时，通知媒体源开始发送媒体流，接收媒体源的媒体流，缓冲并转发给终端播放器。

2.如权利要求1所述的网络媒体服务方法，其特征在于：

在流服务器等候终端播放器的流服务请求时，为了维护与流服务器两者之间的媒体通道，媒体源每隔一定时间向流服务器的服务程序发送握手消息。

3.如权利要求2所述的网络媒体服务方法，其特征在于：

流服务器在规定的时间内没有收到媒体源发送的握手消息，则认为媒体源已经宕掉，关闭服务会话，删除媒体描述信息。

4.如权利要求1或2所述的网络媒体服务方法，其特征在于：

在一定的时间内，流服务器没有收到终端播放器的流服务请求，则流服务器通知媒体源停止发送媒体流，继续保持流服务器与媒体源间的媒体连接，等候后续的终端播放器的流服务请求，直至媒体源主动断开媒体连接。

5.如权利要求4所述的网络媒体服务方法，其特征在于，所述的媒体源主动断开媒体连接，是指：

基于系统静态配置或负载均衡的考虑，媒体源主动向流服务器发出关闭媒体连接请求，流服务器收到该请求后，关闭服务会话，删除媒体描述信息。

6.如权利要求1所述的网络媒体服务方法，其特征在于，所述流服务器收到终端播放器的流服务请求时，进行如下处理：

流服务器查询与请求所对应的媒体源的连接状况，如果连接没有建立，则流服务器拒绝终端播放器的流服务请求；如果连接建立，则向媒体源发送媒体流数据请求消息，媒体源开始向流服务器发送媒体流数据。

Images