一种媒体信息传输方法、装置及系统与流程

本申请涉及通信技术领域，特别涉及一种媒体信息传输方法、装置及系统。

背景技术：

目前，越来越多的运营商涉足内容运营。运营商购买体育、娱乐等转播权，并通过自己的网络，将内容分发到各个用户(即终端)。在运营过程中，通常会遇到一些关注度比较大的转播内容，比如足球决赛、新片首播等，这时运营商将会有超大量的用户同时接入请求观看热点视频。由于这些用户只是临时用户，因此运营商既期望能够服务于这部分临时观众获得额外收入，又不希望因为这部分临时用户而去扩容。这种情况下，运营商对热点视频采用组播方式承载，即以单播方式从视频源服务器把热点媒体流引下来，并以组播方式分发给各个用户。这样，可以降低视频源服务器的负载，减小骨干网流量，降低城域网流量。

但是，目前观看热点视频的终端类型越来越丰富，包括手机等具有无线通信功能的手持终端，这类终端往往不支持组播形式。因此，需要在靠近这类终端时将组播转换为单播，以单播形式将视频发送给终端。组播转换单播的过程一般由靠近终端的宽带网络网关(Broadband network gateway，BNG)来执行。

如图1所示，现有技术的媒体流分发结构中，终端向域名服务器(Domain Name Server，DNS)发送携带域名的查询请求，DNS进行域名与其相对应的网际协议(Internet Protocol，IP)地址的转换，并将转换的IP地址反馈给终端。终端根据IP地址向相应的BNG发起基于传输控制协议(Transmission Control Protocol，TCP)的超文本传输协议(Hyper Text Transfer Protocol，HTTP)请求报文，请求M3U8索引和TS视频文件。BNG从策略服务器获取频道信息配置，包括频道范围、频道视频源地址、频道组播地址、频道带宽。BNG对HTTP请求报文进行解析，将HTTP请求报文中携带的频道编号映射为组播地址，向视频源服务器请求组播流。视频源服务器以组播形式发送组播流。BNG将接收到的组播流生成M3U8索引和TS视频文件，并以单播形式发送给终端。

可以看出，现有技术中的单播组播转换形式要求视频源服务器必须支持组播，然而有些视频源服务器并不一定支持组播，例如部署时间比较早的视频源服务器就不一定支持组播。

综上，现有的媒体流分发架构和单播组播转换形式，缺乏适用性，如何设计更具适用性的媒体流分发架构就成为一个问题。

技术实现要素：

本申请实施例提供一种媒体信息传输方法、装置及系统，用以提供一种新的单播组播转换形式，来提高系统的适用性。

本申请实施例提供的具体技术方案如下：

第一方面，提供一种媒体内容的传输方法，靠近终端一侧和靠近视频源服务器的一侧分别各部署一台BNG，所有组播协议交互及组播转发仅在两个BNG之间的网络上进行。视频源服务器可以采用单播形式向靠近视频源服务器的BNG发送媒体内容，这样能够避免了视频源服务器必须支持组播而带来的限制，使得媒体内容的传输系统更具有适用性。

在一个可能的设计中，靠近视频源服务器的一侧的BNG为第一BNG，靠近终端一侧的BNG为第二BNG。第一BNG接收第二BNG发送的组播加入请求，所述组播加入请求用于请求加入组播网络以接收所述组播网络发送的信息，所述第一BNG将所述组播加入请求转换为单播请求，并将所述单播请求发送给视频源服务器，所述单播请求用于向所述视频源服务器请求媒体内容，所述第一BNG接收所述视频源服务器以单播形式返回的包含所述媒体内容的第一媒体信息，并将第一媒体信息转换为包含所述媒体内容、且能够以组播形式发送的第二媒体信息，将所述第二媒体信息在所述组播网络中以组播形式发送。第一BNG可以代替视频源服务器发送组播形式的媒体信息，可以适用于支持单播形式的视频源服务器。由于组播的转发流程比较复杂会引入较大时延，而视频源服务器和终端都是强计算弱转发设备，并不擅长组播转发，采用本申请实施例提供的方法，组播转发在两个BNG上完成，而BNG是强转发设备，对组播的处理效率更高。

在一个可能的设计中，所述第一BNG将所述组播加入请求转换为单播请求，通过以下方式实现：所述第一BNG对所述组播加入请求进行解析，获取第一负载字段，以及获取所述视频源服务器的第一网际协议IP地址；所述第一BNG生成所述单播请求，所述单播请求的源地址为所述第一BNG的第二IP地址、目的地址为所述第一IP地址，携带内容为所述负载字段。

在一个可能的设计中，所述第一BNG将第一媒体信息转换为包含所述媒体内容的、且能够以组播形式发送第二媒体信息，将所述第二媒体信息在所述组播网络中以组播形式发送，通过以下方式实现：所述第一BNG对所述第一媒体信息进行解析，获取第二负载字段；所述第一BNG生成第二媒体信息，所述第二媒体信息的目的地址为所述组播网络中各个接收节点的IP地址，携带内容为所述第二负载字段；将所述第二媒体信息在所述组播网络中以组播形式发送给各个接收节点；其中，所述接收节点中包括所述第二BNG。

在一个可能的设计中，所述第一BNG接收所述视频源服务器以单播形式返回的包含所述媒体内容的第一媒体信息之前，所述第一BNG与所述视频源服务器之间进行安全协商；所述第一BNG接收所述视频源服务器以单播形式返回的包含所述媒体内容的第一媒体信息之后，若所述第一媒体信息被所述视频源服务器加密，则所述第一BNG基于所述安全协商结果，对被加密的所述第一媒体信息解密，获得所述媒体内容。第一BNG可以代替终端向视频源服务器发送媒体内容请求，可以支持加密和非加密的媒体内容。

第二方面，提供一种媒体内容的传输装置，该装置具有实现上述第一方面和第一方面的任一种可能的设计中终端行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。

第三方面，提供一种媒体内容的传输装置，包括收发器、存储器和处理器，其中，所述存储器用于存储一组程序，所述处理器用于调用所述存储器存储的程序以执行如上述第一方面和第一方面的任一种可能的设计中所述的方法。

第四方面，提供了一种计算机存储介质，用于存储计算机程序，该计算机程序包括用于执行第一方面、第一方面的任一可能的实施方式中的方法的指令。

第五方面，提供一种媒体内容的传输系统，包括第一BNG和第二BNG，所述第一BNG和所述第二BNG相连，所述第一BNG用于执行第一方面、第一方面的任一可能的实施方式中的方法。这样能够避免了视频源服务器必须支持组播而带来的限制，使得媒体内容的传输系统更具有适用性。

附图说明

图1为现有技术的媒体流分发架构示意图；

图2为本申请实施例中媒体流分发架构示意图；

图3为本申请实施例中媒体内容的传输方法流程示意图之一；

图4为本申请实施例中媒体内容的传输方法流程示意图之二；

图5为本申请实施例中媒体内容的传输装置结构示意图之一；

图6为本申请实施例中媒体内容的传输装置结构示意图之二。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述。

本申请实施例中，靠近终端一侧和靠近视频源服务器的一侧分别各部署一台BNG，所有组播协议交互及组播转发仅在两个BNG之间的网络上进行。视频源服务器可以采用单播形式向靠近视频源服务器的BNG发送媒体内容，这样能够避免了视频源服务器必须支持组播而带来的限制，使得媒体内容的传输系统更具有适用性。

需要说明的是，本申请实施例提及“第一”及“第二”等序数词用于对多个对象进行区分，不用于限定多个对象的顺序。

本申请实施例中，如图2所示，媒体流分发的架构包括终端201、第一BNG202、第二BNG203和视频源服务器204。可选的，还包括DNS服务器205和策略服务器206。

其中，终端与第二BNG203相连，用于向第二BNG203发送视频请求，请求所需的媒体流；终端还与DNS服务器205相连，用于向DNS服务器205发送携带域名的查询请求，以查询媒体流的地址；DNS服务器205用于将域名转换为对应的IP地址，并反馈给终端；第二BNG203与第一BNG202相连，用于与第一BNG202之间实现组播协议的交互及组播内容的转发；第二BNG203还与策略服务器206相连，用于从策略服务器206获取频道信息配置；第一BNG102还与视频源服务器204相连，用于向视频源服务器204发送单播请求，并将接收到的媒体内容以组播形式发出去；视频源服务器204用于保存并输出媒体源，例如，可以是一种交互式网络电视的头端设备。

需要说明的是，本申请实施例描述的应用场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定。

结合图2所示的网络架构，下面将结合附图对本申请实施例提供的媒体内容的传输方法及装置做进一步详细的说明。

如图3所示，本申请实施例中，媒体内容的传输方法流程如下所述。

步骤301：第二BNG向第一BNG发送组播加入请求，第一BNG接收第二BNG发送的组播加入请求。

其中，组播加入请求用于请求加入组播网络以接收组播网络发送的信息。

具体地，第二BNG在向第一BNG发送组播加入请求之前，接收终端以单播形式发送的媒体内容请求，该媒体内容请求用于请求欲播放的媒体内容。

鉴于现有技术中，终端向BNG发起媒体内容请求的请求报文是基于TCP的HTTP请求报文，如果请求报文是加密的，则BNG无法解析报文来获取频道信息。

可选的，本申请实施例中，终端向第二BNG发送的媒体内容请求的请求报文是基于用户数据包协议(User Datagram Protocol，UDP)格式的，UDP格式的请求报文无需加密，避免了第二BNG无法解析加密报文的问题。并且，减小了终端耦合。

步骤302：第一BNG将组播加入请求转换为单播请求，并将单播请求发送给视频源服务器，单播请求用于向视频源服务器请求媒体内容。

由于本申请实施例中在第二BNG与视频源服务器之间部署了第一BNG，因此，第二BNG发送的组播加入请求被第一BNG拦截，并不会发送到视频源服务器。而第一BNG接收到组播加入请求后，将组播加入请求转换为单播请求，再以单播形式发送给视频源服务器。

具体转换方式为：第一BNG对组播加入请求进行解析，获取第一负载字段，以及获取视频源服务器的IP地址，这里记为第一IP地址。第一BNG以源地址为第一BNG的IP地址(这里记为第二IP地址)、目的地址为第一IP地址，对第一负载字段进行地址封装。

视频源服务器会接收到来自第一BNG发送的单播请求，视频源服务器解析单播请求，获取频道编号，获取向第一BNG待返回的媒体内容，并对媒体内容进行地址封装，以第一IP地址为源地址、第二IP地址为目的地址进行地址封装，封装后生成第一媒体信息。

步骤303：视频源服务器向第一BNG以单播形式返回包含媒体内容的第一媒体信息，第一BNG接收视频源服务器以单播形式返回的包含媒体内容的第一媒体信息。

视频源服务器接收到来自第一BNG发送的单播请求后，视频源服务器解析单播请求，获取频道编号，获取向第一BNG待返回的媒体内容，并对媒体内容进行地址封装，以第一IP地址为源地址、第二IP地址为目的地址进行地址封装，封装后生成第一媒体信息。

基于视频源服务器可能会发送加密的媒体信息，本申请实施例中，在第一BNG接收视频源服务器以单播形式返回的包含媒体内容的第一媒体信息之前，第一BNG与视频源服务器之间进行安全协商；

第一BNG接收视频源服务器以单播形式返回的包含媒体内容的第一媒体信息之后，若第一媒体信息被视频源服务器加密，则第一BNG基于安全协商结果，对被加密的所述第一媒体信息解密，获得媒体内容。

步骤304：第一BNG将第一媒体信息转换为包含媒体内容、且能够以组播形式发送的第二媒体信息。

具体地，第一BNG需要以组播形式下发给第二BNG和组播网络中的其他接收节点，于此，第一BNG在接收到第一媒体信息后，需要将目的地址更改，以正确分发组播流。第一BNG对第一媒体信息进行解析，获取第二负载字段，第一BNG生成第二媒体信息，第二媒体信息的目的地址为组播网络中各个接收节点的IP地址，源地址仍为视频源服务器的第一IP地址，携带内容为第二负载字段。

步骤305：第一BNG将第二媒体信息在组播网络中以组播形式发送。

具体地，第一BNG将第二媒体信息在组播网络中以组播形式发送给各个接收节点。其中，接收节点中包括第二BNG。

采用本申请实施例提供的方法，第一BNG可以代替终端向视频源服务器发送媒体内容请求，可以支持加密和非加密的媒体内容。第一BNG可以代替视频源服务器发送组播形式的媒体信息，可以适用于支持单播形式的视频源服务器。由于组播的转发流程比较复杂会引入较大时延，而视频源服务器和终端都是强计算弱转发设备，并不擅长组播转发，采用本申请实施例提供的方法，组播转发在两个BNG上完成，而BNG是强转发设备，对组播的处理效率更高，因此，本申请实施例的方法使得端到端性能更强，转发时延更低。

下面将结合具体的应用场景对本申请实施例的媒体内容的传输方法做进一步详细说明。假设第一BNG用BNG-1表示，第二BNG用BNG-2表示，假设视频源服务器为IPTV头端。终端欲向IPTV头端请求视频流进行播放。具体流程如图4所示。

步骤401：终端以单播形式向BNG-2发送视频请求。

该视频请求的报文为UDP格式，视频请求的报文中携带视频源地址，频道编号等信息。

步骤402：BNG-2接收到终端发送的单播形式的视频请求后，将单播形式的视频请求转换为组播加入请求。

具体地，BNG-2向策略服务器获取频道信息，根据频道信息，将单播形式的视频请求中携带的频道编号映射为协议无关组播(Protocol Independent Multicast，PIM)网络中的组播目的地址。根据组播目的地址对视频请求进行重封装，将目的地址更改为组播目的地址，生成组播加入请求。组播加入请求与视频请求的封装地址不同，但是报文内容相同。

步骤403：BNG-2向BNG-1发送组播加入请求。

步骤404：BNG-1将组播加入请求转换为单播请求，并将单播请求发送给IPTV头端。

BNG-1接收到组播加入请求后，对组播加入请求的报文进行解析，获得报文中携带的视频源地址，以视频源地址为目的地址，BNG-1的IP地址为源地址，对组播加入请求的报文进行重封装，获得单播请求。该单播请求为HTTP请求。

步骤405：IPTV头端根据单播的HTTP请求，向BNG-1返回单播的HTTP视频流。

IPTV头端可以对HTTP视频流加密。

步骤406：BNG-1收到单播的HTTP视频流后，将HTTP视频流中的负载字段解析出来，并进行地址封装，其中，封装的目的地址为组播的各个接收节点的IP地址、源地址不变，生成组播的HTTP视频流。

若HTTP视频流为加密报文，则BNG-1与IPTV头端已经完成了安全协商，因此，BNG-1可以对加密报文进行解析。

步骤407：将封装后的组播的HTTP视频流以组播形式按照组播路由转发出去。

步骤408：BNG-2接收到组播的HTTP视频流，解析负载字段，并进行地址封装，其中，封装的目的地址为终端的IP地址，源地址不变，且封装后的报文为单播形式的UDP报文。

步骤409：BNG-2将单播形式的UDP报文发送给终端。

这样，终端在以单播形式发送了视频请求后，收到以单播形式返回的UDP报文。

综上，通过以上应用场景中方案的介绍，可以看出，这种形式的网络架构下，可以减少对IPTV头端的依赖，只支持单播的IPTV头端也可以应用于该网络架构中视频流的下发，避免了要求IPTV头端必须支持组播的问题。由于现网的IPTV头端，支持单播是基本功能，因此，本申请实施例中提供的方法能够应用于更多的IPTV头端，具有广泛适用性。

由于部署了BNG-1，可以由BNG-1代替终端向IPTV头端发起视频请求，如果视频内容是加密的，那么BNG-2作为接收端，已经完成和IPTV头端的安全协商，可以解析加密的内容，然后将解析后的内容，通过组播形式下发给BNG-2，BNG-2再通过单播形式下发给终端，因此，本申请实施例的方法可以支持加密和非加密视频流。

基于与图3和图4所示的媒体内容的传输方法相同的发明构思，如图5所示，本申请实施例还提供了一种媒体内容的传输装置500，包括接收单元501、处理单元502和发送单元503，其中：

接收单元501，用于接收其他装置发送的组播加入请求，组播加入请求用于请求加入组播网络以接收组播网络发送的信息；

处理单元502，用于将接收单元501接收到的组播加入请求转换为单播请求，并将单播请求发送给视频源服务器，单播请求用于向视频源服务器请求媒体内容；

接收单元501，还用于接收视频源服务器以单播形式返回的包含媒体内容的第一媒体信息；

处理单元502，还用于将接收单元501接收到的第一媒体信息转换为包含媒体内容的第二媒体信息；

发送单元503，用于将处理单元502转换的第二媒体信息在组播网络中以组播形式发送。

可选的，处理单元502用于：

对组播加入请求进行解析，获取第一负载字段，以及获取视频源服务器的第一网际协议IP地址；

以源地址为装置的第二IP地址、和目的地址为第一IP地址，对第一负载字段进行地址封装。

可选的，处理单元502用于：

将第一媒体信息的目的地址分别更换为组播网络中各个接收节点的IP地址，生成第二媒体信息；

发送单元503用于：将第二媒体信息在组播网络中以组播形式发送给各个接收节点；

其中，接收节点中包括第二BNG。

可选的，处理单元502还用于：

在接收视频源服务器以单播形式返回的包含媒体内容的第一媒体信息之前，与视频源服务器之间进行安全协商；以及，

在接收视频源服务器以单播形式返回的包含媒体内容的第一媒体信息之后，若第一媒体信息为加密报文，则第一BNG基于安全协商结果，对加密报文进行解析，获得媒体内容。

基于与图3和图4所示的媒体内容的传输方法相同的发明构思，如图6所示，本申请实施例还提供了一种媒体内容的传输装置600，包括收发器601、处理器602、存储器603和总线604，收发器601、处理器602、存储器603均与总线604连接，其中，存储器603中存储一组程序，处理器602用于调用存储器603中存储的程序，当程序被执行时，使得处理器602执行以下操作：

通过收发器601接收其他装置发送的组播加入请求，组播加入请求用于请求加入组播网络以接收组播网络发送的信息；

将接收到的组播加入请求转换为单播请求，并将单播请求发送给视频源服务器，单播请求用于向视频源服务器请求媒体内容；

通过收发器601接收视频源服务器以单播形式返回的包含媒体内容的第一媒体信息；

将接收到的第一媒体信息转换为包含媒体内容的第二媒体信息；

将转换的第二媒体信息在组播网络中以组播形式发送。

可选的，处理器602用于：

对组播加入请求进行解析，获取第一负载字段，以及获取视频源服务器的第一网际协议IP地址；

以源地址为装置的第二IP地址、和目的地址为第一IP地址，对第一负载字段进行地址封装。

可选的，处理器602用于：

将第一媒体信息的目的地址分别更换为组播网络中各个接收节点的IP地址，生成第二媒体信息；

通过收发器601将第二媒体信息在组播网络中以组播形式发送给各个接收节点；

其中，接收节点中包括第二BNG。

可选的，处理器602还用于：

在接收视频源服务器以单播形式返回的包含媒体内容的第一媒体信息之前，与视频源服务器之间进行安全协商；以及，

在接收视频源服务器以单播形式返回的包含媒体内容的第一媒体信息之后，若第一媒体信息为加密报文，则第一BNG基于安全协商结果，对加密报文进行解析，获得媒体内容。

处理器602可以是中央处理器(central processing unit，CPU)，网络处理器(network processor，NP)或者CPU和NP的组合。

处理器602还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(generic array logic,GAL)或其任意组合。

存储器603可以包括易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器603也可以包括非易失性存储器(non-volatile memory)，例如快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；存储器603还可以包括上述种类的存储器的组合。

需要说明的是，图5提供的装置，可用于实现图3和图4所示的方法。一个具体的实现方式中，图5中的处理单元502可以用图6中的处理器602实现，接收单元501、发送单元603均可以由图6中的收发器601实现。

本申请还提供了一种媒体内容的传输系统，包括第一BNG和第二BNG，，第一BNG可以是图5、图6对应的实施例所提供的装置。所述媒体内容的传输系统用于执行图3和图4对应的实施例的方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。