CN116708391A - 信令协商方法、信息传输方法及内容分发系统 - Google Patents

Abstract

本说明书实施例提供信令协商方法、信息传输方法及内容分发系统，其中所述信令协商方法包括：生成媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记；通过回源路径，传输所述媒体预回源请求；接收回源服务器返回的媒体描述信息，所述回源服务器是所述回源路径上的任一服务器，所述媒体描述信息是所述回源服务器在确定命中了所述媒体流标识对应的媒体流的情况下，根据所述媒体查询标记，利用所述媒体流查询出的媒体描述信息；利用所述媒体描述信息进行所述信令协商。

Description

信令协商方法、信息传输方法及内容分发系统

技术领域

本说明书实施例涉及计算机技术领域，特别涉及信令协商方法和信息传输方法。

背景技术

内容分发网络，是构建在现有网络基础之上的虚拟网络，依靠部署在各地的边缘服务器，通过中心服务器的负载均衡、内容分发、调度等功能，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。

基于内容分发网络，能够实现便捷接入、高清流畅、高并发的音视频播放服务。为了向用户提供音视频播放服务，音视频客户端先要与边缘服务器进行信令协商。信令协商，是指客户端与边缘服务器相互协商媒体描述信息，通过协商决定双方使用何种媒体描述信息通信的阶段。但是，目前边缘服务器查询媒体描述信息的效率不高且存在安全风险。因此，目前亟需一种更加高效安全的信令协商方案。

发明内容

有鉴于此，本说明书实施例提供了一种信令协商方法。本说明书一个或者多个实施例同时涉及一种信息传输方法，一种内容分发系统，一种计算设备，一种计算机可读存储介质以及一种计算机程序，以解决现有技术中存在的技术缺陷。

根据本说明书实施例的第一方面，提供了一种信令协商方法，应用于边缘服务器，包括：生成媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记；通过回源路径，传输所述媒体预回源请求；接收回源服务器返回的媒体描述信息，所述回源服务器是所述回源路径上的任一服务器，所述媒体描述信息是所述回源服务器在确定命中了所述媒体流标识对应的媒体流的情况下，根据所述媒体查询标记，利用所述媒体流查询出的媒体描述信息；利用所述媒体描述信息进行所述信令协商。

根据本说明书实施例的第二方面，提供了一种信息传输方法，应用于回源服务器，包括：接收边缘服务器通过回源路径传输的媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记，所述回源服务器是所述回源路径上的任一服务器；判断所述回源服务器是否命中了所述媒体流标识对应的媒体流；如果是，根据所述媒体描述查询标记，利用所述媒体流查询出对应的媒体描述信息；向所述边缘服务器发送所述媒体描述信息。

根据本说明书实施例的第三方面，提供了一种内容分发系统，包括：应用了如本说明书任意实施例所述信令协商方法的边缘服务器和应用了如本说明书任意实施例所述信息传输方法的回源服务器。

根据本说明书实施例的第四方面，提供了一种计算设备，包括：存储器和处理器；所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，该计算机可执行指令被处理器执行时实现上述信令协商方法或信息传输方法的步骤。

根据本说明书实施例的第五方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现上述信令协商方法或信息传输方法的步骤。

根据本说明书实施例的第六方面，提供了一种计算机程序，其中，当所述计算机程序在计算机中执行时，令计算机执行上述信令协商方法或信息传输方法的步骤。

本说明书一个实施例实现了信令协商方法，该信令协商方法应用于边缘服务器，由于该方法在边缘服务器进行信令协商时，生成媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记,通过回源路径，传输所述媒体预回源请求,相当于边缘服务器在信令协商阶段提前触发媒体流的回源，当回源路径上的回源服务器在确定命中了所述媒体流标识对应的媒体流的情况下，根据所述媒体查询标记，利用所述媒体流查询出的媒体描述信息，边缘服务器能够接收到回源服务器返回的媒体描述信息，从而边缘服务器利用所述媒体描述信息完成信令协商。

本说明书另一个实施例实现了信息传输方法，该信息传输方法应用于回源服务器，由于该方法接收边缘服务器通过回源路径传输的媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记，判断所述回源服务器是否命中了所述媒体流标识对应的媒体流，如果是，根据所述媒体描述查询标记，利用所述媒体流查询出对应的媒体描述信息，向所述边缘服务器发送所述媒体描述信息，从而边缘服务器利用所述媒体描述信息完成信令协商。

可见，上述方法利用媒体流的回源路径查询并传输媒体描述信息，不依赖其他组件，避免通过其他组件查询媒体描述信息而出现查询繁琐、查询链路过长、存在安全风险等问题，实现了更加高效安全的信令协商方案。

附图说明

图1是本说明书一个实施例提供的一种信令协商方法的应用场景示意图；

图2是本说明书一个实施例提供的一种信令协商方法的流程图；

图3是本说明书一个实施例提供的一种信令协商方法的处理过程流程图；

图4是本说明书一个实施例提供的一种信令协商装置的结构示意图；

图5是本说明书一个实施例提供的一种信息传输方法的流程图；

图6是本说明书一个实施例提供的一种信息传输装置的结构示意图；

图7是本说明书一个实施例提供的一种内容分发系统的结构示意图；

图8是本说明书一个实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

此外，需要说明的是，本说明书一个或多个实施例所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

首先，对本说明书一个或多个实施例涉及的名词术语进行解释。

WebRTC(Web Real-Time Communication，网页实时通信)，是一种实时通信技术，通过在web浏览器里面引入实时通信,包括音视频实时通信等，实现视频流、音频流或者其他任意数据的传输。

信令，也称为通信控制指令，是一种建立通信双方通信协议、通信通道的机制。

媒体描述信息，是对媒体流中音视频的属性的描述信息。例如，所述媒体描述信息可以包括编码标准及其定义的参数等媒体编码信息，如媒体编码格式等。

为了向用户提供音视频播放服务，在正式播放音视频之前，音视频客户端先要与边缘服务器进行信令协商。在信令协商阶段中，协商的一项信息就是媒体描述信息。目前，边缘服务器通过中心组件来旁路查询出媒体描述信息，导致信令协商过程对中心组件有依赖，效率不高且存在安全风险。因此，目前亟需一种更加高效安全的信令协商方案。

有鉴于此，本说明书实施例提供了一种信令协商方案，该方案在边缘服务器进行信令协商时，生成媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记,通过回源路径，传输所述媒体预回源请求,相当于边缘服务器在信令协商阶段提前触发媒体流的回源，当回源路径上的回源服务器确定命中了所述媒体流标识对应的媒体流的情况下，根据所述媒体查询标记，利用所述媒体流查询出的媒体描述信息，边缘服务器能够接收到回源服务器返回的媒体描述信息，从而边缘服务器利用所述媒体描述信息完成信令协商，利用媒体流的回源路径查询并传输媒体描述信息，不依赖其他组件，避免通过其他组件查询媒体描述信息而出现查询繁琐、查询链路过长、存在安全风险等问题，实现了更加高效安全的信令协商方案。

具体地，在本说明书中，提供了一种信令协商方法，一种信息传输方法，本说明书同时涉及一种信令协商装置，一种信息传输装置，一种内容分发系统，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

参见图1，图1示出了根据本说明书一个实施例提供的一种信令协商方法的应用场景示意图。如图1所示，本说明书实施例提供的信令协商方法的一个示例性应用场景是基于WebRTC的音视频直播场景。

WebRTC(Web Real-Time Communication，网页实时通信)，是一种实时通信技术，通过在Web(网页)浏览器里面引入实时通信,包括音视频实时通信等，实现视频流、音频流或者其他任意数据的传输。WebRTC适用于直播、点播、视频会议、在线课堂、在线聊天室、游戏互动等场景，实现纯音频数据、视频数据等的实时传输。因此，在一些音视频直播服务中，支持以WebRTC客户端接入的方式播放媒体流。在WebRTC客户端接入过程中，需要与服务端进行信令协商。信令协商是建立通信能力重要的起始阶段。例如，在WebRTC技术中，可以使用会话描述协议在信令协商阶段携带媒体描述信息，从而为WebRTC客户端提供多种初始化信息。例如，在信令协商阶段，客户端与服务端双方交互媒体编码信息，不仅完成了信令协商，便于后续通信，而且可以使WebRTC客户端在真正获取媒体数据之前，利用媒体编码信息初始化好解码器，提高解码效率。由此，在基于WebRTC实现的直播、点播、视频会议、在线课堂、在线聊天室、游戏互动等通信场景中，与WebRTC客户端通信的边缘服务器，可以根据本说明书实施例提供的信令协商方法，与WebRTC客户端完成音视频正式播放前的信令协商。

如图1，该应用场景中可以包括服务端100以及多个客户端200。多个客户端200之间通过服务端100可以建立通信连接，在WebRTC场景中，服务端100用来在多个客户端200之间提供通信服务，多个客户端200可以分别作为发送端或接收端，通过服务端100实现实时通信。

用户通过客户端200可与服务端100进行交互以接收其它客户端200发送的数据，或将数据发送至其它客户端200等。在WebRTC场景中，可以是用户通过客户端200向服务端100发布数据流，服务端200将该媒体流推送至订阅该媒体流的客户端中。媒体流例如可以包括音频流、视频流等媒体数据。如在直播场景中，主播用户通过客户端可以实时采集媒体数据，并发送至服务端，不同主播用户的媒体数据通过直播间进行区分，服务端可以将该主播用户的媒体数据推送至进入该主播用户对应直播间的观看用户。又如在会议场景中，参会用户通过客户端可以实时采集媒体数据并发送至服务端，服务端可以将每个客户端发送的媒体数据推送至其它参会用户的客户端等。

例如，服务端100可以包括边缘服务器(如图1所示的L1-A、L1-B和L1-C是边缘服务器)、中间服务器(如图1所示的L2-A和L2-B是中间服务器)、源站和中心服务器。中间服务器、中心服务器和源站中的任一服务器均可视为回源服务器。中心服务器，用于实现负载均衡、内容分发、调度等功能。源站，用于存储海量用户的数据，如推流者推送的媒体数据等。中间服务器，用于保存用户请求的数据，如果本地未保存用户请求的数据，需要返回源站去获取数据并保存，供后续用户访问。边缘服务器，用于就近与用户的客户端200通信，使用户就近获取或发送数据。

由此，客户端200在播放音视频之前先要与边缘服务器进行信令协商，以便根据协商的信令获取或发布媒体流。

其中，客户端200与服务端100之间通过网络建立连接。网络为客户端与服务端之间提供了通信链路的介质。网络可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

其中，客户端200可以为浏览器、APP(Application，应用程序)、或网页应用如H5(HyperText Markup Language5，超文本标记语言第5版)应用、或轻应用(也被称为小程序，一种轻量级应用程序)或云应用等，客户端200可以基于服务端提供的相应服务的SDK(Software Development Kit，软件开发工具包)，如基于WebRTC开发获得等。客户端200可以部署在电子设备中，需要依赖设备运行或者设备中的某些应用而运行等。电子设备例如可以具有显示屏并支持信息浏览等，如可以是个人移动终端如手机、平板电脑、个人计算机等。在电子设备中通常还可以配置各种其它类应用，例如人机对话类应用、模型训练类应用、文本处理类应用、网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

服务端100可以包括提供各种服务的服务器，例如为多个客户端提供通信服务的服务器，又如为客户端上使用的模型提供支持的用于后台训练的服务器，又如对客户端发送的数据进行处理的服务器等。

服务端100可以实现成多个服务器组成的分布式服务器集群。服务器可以为分布式系统的服务器，或者是结合了区块链的服务器。服务器也可以是云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器，或者是带人工智能技术的智能云计算服务器或智能云主机。

可以理解的是，上述应用场景仅用于对本说明书实施例提供的方法进行示例性说明，并不构成对本说明书实施例提供的方法的限制。本说明书实施例提供的方法可以应用于各种基于内容分发网络的信令协商。

参见图2，图2示出了根据本说明书一个实施例提供的一种信令协商方法的流程图。该信令协商方法应用于边缘服务器，具体包括以下步骤。

步骤202：生成媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记。

媒体预回源请求，是指在信令协商阶段，正式媒体播放请求之前，提前生成的媒体回源请求。因此，所述媒体预回源请求，也可以理解为一个假的媒体播放请求。

所述媒体流标识，是用于区分媒体流的符号。基于媒体流标识，可以全局唯一确定一条媒体流。所述媒体描述查询标记，是用于指示回源服务器对媒体流标识的媒体流进行媒体描述信息查询的指示信息。所述媒体流标识和所述媒体描述查询标记，可以使用字母、数字、特殊符号等任意字符串来表示。

步骤204：通过回源路径，传输所述媒体预回源请求。

所述回源路径，是指从所述边缘服务器出发、经由一个或多个中间服务器到达源站的路径。所述媒体预回源请求按照所述回源路径，逐层向源站发送，当所述回源路径上的任一服务器命中所述媒体预回源请求携带的媒体流标识对应的媒体流时，则可以停止继续传输所述媒体预回源请求。其中，命中，可以是指该服务器具有媒体流标识对应的媒体流的数据。

步骤206：接收回源服务器返回的媒体描述信息，所述回源服务器是所述回源路径上的任一服务器，所述媒体描述信息是所述回源服务器在确定命中了所述媒体流标识对应的媒体流的情况下，根据所述媒体查询标记，利用所述媒体流查询出的媒体描述信息。

所述媒体描述信息，包括媒体流中音视频的编码标准及其定义的参数等信息。例如，所述媒体描述信息可以是媒体编码信息。当回源路径上的任一服务器接收到所述媒体预回源请求时，由于该请求中携带了媒体描述查询标记，因此，该服务器能够确定该请求的目的是查询媒体描述信息，因此，根据媒体流标识判断是否命中所述媒体流标识对应的媒体流，如果是，则可以利用该媒体流，从中解析出对应的媒体描述信息，将媒体描述信息返回给边缘服务器。

步骤208：利用所述媒体描述信息进行所述信令协商。

边缘服务器利用所述媒体描述信息进行所述信令协商的具体方式，可以参照一般的信令协商方式完成，本说明书对此并不进行限制。例如，客户端与边缘服务器相互交换媒体编码格式，进而确定二者均支持的媒体编码格式，完成信令协商。

可见，根据本说明书实施例提供的信令协商方法，边缘服务器进行信令协商时，会生成媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记,边缘服务器通过回源路径，传输所述媒体预回源请求,相当于边缘服务器在信令协商阶段提前触发媒体流的回源，当回源路径上的回源服务器根据所述媒体流标识和媒体描述查询标记查询到的媒体描述信息情况下，边缘服务器能够接收到回源服务器返回的媒体描述信息，从而边缘服务器利用所述媒体描述信息完成信令协商，利用媒体流的回源路径查询并传输媒体描述信息，不依赖其他组件，避免通过其他组件查询媒体描述信息而出现查询繁琐、查询链路过长、存在安全风险等问题，实现了更加高效安全的信令协商方案。

本说明书一个或多个实施例中，在接收回源服务器返回的媒体描述信息时，还包括：

接收所述回源服务器根据所述媒体流标识下发的媒体流。

例如，回源服务器在根据媒体流标识确定命中所述媒体流标识对应的媒体流时，进一步该媒体流发送给边缘服务器，以便媒体流被推送到边缘服务器，达到媒体流预热的效果。根据该实施例，不仅媒体描述信息这个轻量级数据经过媒体回源链路下发到边缘服务器，提高了信令协商效率，而且，媒体数据也提前下发到边缘服务器，从而当正式播放时，可以达到降低时延的效果。

本说明书另一个或多个实施例中，为了减少回源路径上传输的数据量，在回源服务器查询到媒体描述信息的情况下，可以只下发媒体描述信息这一轻量级数据，而不下发媒体流。

本说明书一个或多个实施例中，所述生成媒体预回源请求，包括：

接收客户端发送的信令协商请求；

根据所述信令协商请求，生成媒体预回源请求。

所述信令协商请求，是客户端与边缘服务器协商媒体信息的请求，请求中可以携带客户端支持的会话描述信息、媒体描述信息等协商信息。例如，基于WebRTC技术的客户端，向边缘服务器发送的信令协商请求包含SDP offer(Session Description Protocol，会话描述协议)。SDP是一种会话描述协议，在WebRTC技术中，客户端与边缘服务器之间利用该会话描述协议来描述具体的媒体描述信息，基于offer(请求)/answer(应答)的交互模式来进行媒体描述信息的协商。以所述媒体描述信息为音视频格式为例，客户端会先向服务端发送带有SDP offer的信令请求。SDP offer中包含了客户端支持的音视频格式(客户端支持的音视频格式可以是一个或多个)，服务端查询出本方支持的音视频格式后，返回带有SDP answer的应答，SDP answer中包含服务端最终选定支持的音视频格式，服务端最终选定支持的音视频格式通常是客户端请求的媒体流本身真实的音视频格式或者媒体流经过服务端转码得到的转码流的音视频格式。

根据该实施例，由于边缘服务器利用所述媒体描述信息完成信令协商，利用媒体流的回源路径查询并传输媒体描述信息，实现了更加高效安全的信令协商方案。

由此，在边缘服务器查询到媒体描述信息之后，可以确定二者均支持的媒体描述信息(如媒体编码信息)，以便完成信令协商，后续使用该媒体描述信息进行通信。相应地，边缘服务器还可以将查询到的媒体描述信息返回给客户端，从而使客户端同样完成该信令协商阶段，本说明书一个或多个实施例中，所述方法还包括：

向所述客户端返回信令协商应答，所述信令协商应答携带所述媒体描述信息。

例如，可以向基于WebRTC技术的客户端返回SDP answer，SDP answer中携带了音视频格式信息，不仅提高了信令协商效率，而且还能帮助客户端获取初始化需要的参数，如音视频编码的各种参数(如视频的高宽信息)等，以加速客户端的初始化。

可以理解的是，本说明书实施例提供的信令协商方法，可以用于客户端与边缘服务器之间的信令协商，也可以用于其他服务器与边缘服务器之间的信令协商，本说明书对此并不进行限制。

下述结合附图3，以本说明书提供的信令协商方法在基于WebRTC技术的音视频直播服务中应用为例，对所述信令协商方法进行进一步说明。其中，图3示出了本说明书一个实施例提供的一种信令协商方法的处理过程流程图，具体包括以下步骤。

步骤302：WebRTC客户端就近向边缘服务器(图3所示L1节点)发送信令协商请求。

在基于WebRTC技术的音视频直播服务中，由于两个基于WebRTC的客户端需要通过Web服务端进行SDP交换,以在客户端之间建立传输媒体流的通道，因此，WebRTC客户端在信令协商阶段，需要向Web服务端中的边缘服务器发送信令协商请求。

步骤304：边缘服务器响应于接收到信令协商请求，生成媒体预回源请求。

其中，所述边缘服务器中可以包括专门用于信令协商的信令处理器，由该信令处理器完成信令协商阶段的处理。

如图3所示的L1节点提前生成媒体预回源请求。其中，所述媒体预回源请求可以基于任意流媒体协议生成。例如，所述媒体预回源请求可以是基于RTMP(Real TimeMessaging Protocol，实时消息传输协议)的媒体预回源请求。所述媒体预回源请求会携带媒体流标识和媒体描述查询标记，以表示该请求用于在信令协商阶段查询媒体描述信息。

步骤306：通过回源路径，传输所述媒体预回源请求。

在该步骤中，所述媒体预回源请求，会按照回源路径逐层向上回源。可以理解的是，在基于内容分发网络的Web服务端内部，针对边缘服务器的回源请求，可以有一条或多条回源路径，具体根据场景需要设置，本说明书对此并不进行限制。

步骤308：回源路径上的任一回源服务器(例如，如图3所示的L2、proxy或source中任一服务器)命中所述媒体预回源请求对应的媒体流，则回源服务器向下游下发对应的媒体描述信息(例如，媒体编码信息)。

例如，如图3所示的一条回源路径中，从边缘服务器L1出发，经由中间服务器L2到达源站source。

回源服务器会根据所述媒体流标识判断是否本地已具有对应媒体流，如果是，根据所述媒体描述查询标记查询出对应的媒体描述信息。具体地，在查询时，回源服务器会先判断客户端需求的媒体格式是否与本地具有的媒体流的媒体格式一致，如果一致，则直接解析媒体流，获得其中的媒体描述信息，如果不一致，则触发转码服务器对所述媒体流标识对应的媒体流进行转码处理，从而接收转码服务器针对所述转码处理返回的转码流，并对所述转码流进行解析，获得所述转码流中的媒体描述信息。

其中，转码服务器，可以是如图3所示的转码集群中的任一转码服务器。转码服务器，通常用于将媒体数据转码成适合在各种客户端上播放的格式，能够满足音视频网站、在线教育、在线会议等多种场景下媒体数据格式不同的要求。在本说明书实施例提供的方法中，转码服务器还可以用于在信令协商阶段，对媒体流进行转码处理，以获取客户端支持的媒体格式的转码流。比如回源服务器具有的源流的媒体流标识是A，分辨率是1080P。但是客户端支持的媒体流A的分辨率是720P，因此，回源服务器会根据客户端需要的媒体格式(720P)，触发转码服务器，将媒体流A转码为一条720P的转码流，推到该回源服务器，此时该回源服务器才能够解析出720P的转码流的编码信息以及分辨率信息等媒体描述信息。通过转码处理，转码服务器能够将媒体流转换为客户端支持的媒体格式。客户端与服务端支持同一媒体格式，能够保证客户端与服务端双方后续可以基于同一媒体格式的媒体流的媒体描述信息进行通信。因此，转码服务器在进行转码处理后，将转码流发送给回源服务器，能够使回源服务器从转码流中解析出具体的媒体描述信息，使回源服务器获得相应的媒体描述信息，并将该媒体描述信息下发到边缘服务器，使边缘服务器完成信令协商。例如，回源服务器可以将该媒体描述信息回推给正在等待该媒体描述信息的会话，该会话是指媒体预回源请求对应的会话。

步骤310：边缘服务器获得逐层下发的媒体描述信息。

其中，逐层下发的媒体描述信息采用的消息格式不限，例如，可以采用RTMP AMF消息格式。

步骤312:边缘服务器利用所述媒体描述信息完成信令协商，向WebRTC客户端发送信令协商应答。

该实施例在基于WebRTC技术的音视频直播服务的信令协商阶段，边缘服务器提前触发媒体回源，也可以理解为边缘服务器触发了一个假的媒体播放请求，随着媒体链路的回源，基于媒体流命中特性，当某个节点命中媒体流时，即可获得具体的媒体描述信息，从而使该媒体描述信息这个轻量级数据随着媒体链路逐层下发给下游节点直到边缘服务器，可见，根据该实施例，在WebRTC的信令协商阶段，服务端能够利用媒体回源链路传递媒体描述信息来完成信令协商，不依赖其他组件，更加高效安全。

与上述方法实施例相对应，本说明书还提供了信令协商装置实施例，图4示出了本说明书一个实施例提供的一种信令协商装置的结构示意图。如图4所示，该装置包括：

预回源触发模块402，被配置为生成媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记。

请求传输模块404，被配置为通过回源路径，传输所述媒体预回源请求。

信息获取模块406，被配置为接收回源服务器返回的媒体描述信息，所述回源服务器是所述回源路径上的任一服务器，所述媒体描述信息是所述回源服务器在确定命中了所述媒体流标识对应的媒体流的情况下，根据所述媒体查询标记，利用所述媒体流查询出的媒体描述信息。

协商执行模块408，被配置为利用所述媒体描述信息进行所述信令协商。

本说明书一个或多个实施例中，所述装置还包括：

媒体流接收模块，被配置为在信息获取模块接收回源服务器返回的媒体描述信息时，接收所述回源服务器根据所述媒体流标识下发的媒体流。

本说明书一个或多个实施例中，所述预回源触发模块，包括：

协商请求接收子模块，被配置为接收客户端发送的信令协商请求；

回源触发子模块，被配置为根据所述信令协商请求，生成媒体预回源请求。

本说明书一个或多个实施例中，所述装置还包括：

应答模块，被配置为向所述客户端返回信令协商应答，所述信令协商应答携带所述媒体描述信息。

上述为本实施例的一种信令协商装置的示意性方案。需要说明的是，该信令协商装置的技术方案与上述的信令协商方法的技术方案属于同一构思，信令协商装置的技术方案未详细描述的细节内容，均可以参见上述信令协商方法的技术方案的描述。

与上述信令协商方法相对应，本说明书还提供了一种应用于回源服务器的信息传输方法。图5示出了本说明书一个实施例提供的一种信息传输方法的流程图。如图5所示，该方法具体包括以下步骤。

步骤502：接收边缘服务器通过回源路径传输的媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记。

所述回源服务器是所述回源路径上的任一服务器。例如，所述回源服务器可以是边缘服务器到源站之间的中间服务器，或者，可以是源站。

步骤504：判断所述回源服务器是否命中了所述媒体流标识对应的媒体流。

例如，回源服务器，可以将所述媒体流标识与回源服务器缓存的媒体流的媒体流标识进行比对，判断回源服务器是否已具有对应媒体流。

步骤506：如果是，根据所述媒体描述查询标记，利用所述媒体流查询出对应的媒体描述信息。

需要说明的是，回源服务器本身具有媒体流解析能力，能够从媒体流中解析出媒体描述信息。在一些实施例中，为了满足不同媒体格式的需求，内容分发网络中设置了专门用于解码的解码服务器，在该实施例中，回源服务器可以触发转码服务器对媒体流进行转码处理，使媒体流转码为客户端支持的媒体格式，得到转码流，回源服务器通过解析转码流来获得其中的媒体描述信息。

步骤508：向所述边缘服务器发送所述媒体描述信息。

例如，回源服务器可以根据所述回源路径，逐层下发媒体描述信息给边缘服务器。

可见，根据本说明书实施例提供的信息传输方法，边缘服务器进行信令协商时，边缘服务器通过回源路径传输媒体预回源请求,从而回源路径上的回源服务器根据所述媒体流标识和媒体描述查询标记查询到的媒体描述信息情况下，能够向边缘服务器返回媒体描述信息，从而使边缘服务器利用所述媒体描述信息完成信令协商，由于利用媒体流的回源路径查询并传输媒体描述信息，不依赖其他组件，避免通过其他组件查询媒体描述信息而出现查询繁琐、查询链路过长、存在安全风险等问题，实现了更加高效安全的信令协商方案。

本说明书一个或多个实施例中，在回源服务器下发所述媒体描述信息的同时，还可以下发对应的媒体流，从而正式播放时，边缘服务器可以尽快将媒体流发送给客户端，降低客户端的播放时延。具体地，所述方法还可以包括：

如果命中了所述媒体流标识对应的媒体流，向所述边缘服务器发送所述媒体流。

本说明书一个或多个实施例中，

所述根据所述媒体描述查询标记，利用所述媒体流查询出对应的媒体描述信息，包括：

触发转码服务器对所述媒体流标识对应的媒体流，按照客户端需求的媒体格式进行转码，获得转码流；

对所述转码流进行解析，获得所述转码流中的媒体描述信息。

在该实施例中，通过转码服务器进行转码处理，获得客户端支持的媒体格式的转码流，进而能够从中解析出媒体描述信息并下发给边缘服务器，提高信令协商效率。

本说明书一个或多个实施例中，所述向所述边缘服务器发送所述媒体描述信息，包括：

利用所述媒体预回源请求在所述回源路径上对应的会话，将所述媒体描述信息相对于所述媒体流独立地返回给所述边缘服务器。

在该实施例中，利用所述媒体预回源请求在所述回源路径上对应的会话，将所述媒体描述信息相对于所述媒体流独立地返回，避免大规模数据流的下发，而是基于已建立的会话，通过轻量级的消息格式下发媒体描述信息，能够提高媒体描述信息的传输效率。

上述为本实施例的一种信息传输方法的示意性方案。需要说明的是，该信息传输方法的技术方案与上述的信令协商方法的技术方案属于同一构思，信息传输方法的技术方案未详细描述的细节内容，均可以参见上述信令协商方法的技术方案的描述。

与上述方法实施例相对应，本说明书还提供了信息传输装置实施例，图6示出了本说明书一个实施例提供的一种信息传输装置的结构示意图。如图6所示，该装置包括：

回源请求接收模块602，被配置为接收边缘服务器通过回源路径传输的媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记，所述回源服务器是所述回源路径上的任一服务器。

命中判断模块604，被配置为判断所述回源服务器是否命中了所述媒体流标识对应的媒体流。

信息查询模块606，被配置为如果命中判断模块604判定为是，根据所述媒体描述查询标记，利用所述媒体流查询出对应的媒体描述信息。

描述信息下发模块608，被配置为向所述边缘服务器发送所述媒体描述信息。

本说明书一个或多个实施例中，所述装置还包括：

媒体流下发模块，被配置为如果命中了所述媒体流标识对应的媒体流，向所述边缘服务器发送所述媒体流

本说明书一个或多个实施例中，所述信息查询模块，被配置为触发转码服务器对所述媒体流标识对应的媒体流，按照客户端需求的媒体格式进行转码，获得转码流，对所述转码流进行解析，获得所述转码流中的媒体描述信息。

本说明书一个或多个实施例中，所述描述信息下发模块，被配置为利用所述媒体预回源请求在所述回源路径上对应的会话，将所述媒体描述信息相对于所述媒体流独立地返回给所述边缘服务器。

上述为本实施例的一种信息传输装置的示意性方案。需要说明的是，该信息传输装置的技术方案与上述的信息传输方法的技术方案属于同一构思，信息传输装置的技术方案未详细描述的细节内容，均可以参见上述信息传输方法的技术方案的描述。

与上述信令协商方法和信息传输方法实施例相对应，本说明书还提供了内容分发系统的实施例，图7示出了本说明书一个实施例提供的一种内容分发系统的结构示意图。如图7所示，该系统包括：

应用了如本说明书任意实施例所述信令协商方法的边缘服务器和应用了如本说明书任意实施例所述信息传输方法的回源服务器。

图7中，以边缘服务器L1-A、L1-B和L1-C来示意内容分发系统中的各个边缘服务器，以回源服务器L2-A、L2-B和L3-A来示意内容分发系统中的各个回源服务器。需要说明的是，图7仅用于对本说明书实施例提供的内容分发系统进行示例性说明，并不构成对本说明书实施例提供的内容分发系统的限制。

上述为本实施例的一种内容分发系统的示意性方案。需要说明的是，该内容分发系统的技术方案与上述的信令协商方法和信息传输方法的技术方案属于同一构思，内容分发系统的技术方案未详细描述的细节内容，均可以参见上述信令协商方法和信息传输方法的技术方案的描述。

图8示出了根据本说明书一个实施例提供的一种计算设备800的结构框图。该计算设备800的部件包括但不限于存储器810和处理器820。处理器820与存储器810通过总线830相连接，数据库850用于保存数据。

计算设备800还包括接入设备840，接入设备840使得计算设备800能够经由一个或多个网络860通信。这些网络的示例包括公用交换电话网(PSTN，Public SwitchedTelephone Network)、局域网(LAN，Local Area Network)、广域网(WAN，Wide AreaNetwork)、个域网(PAN，Personal Area Network)或诸如因特网的通信网络的组合。接入设备840可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC，networkinterface controller))中的一个或多个，诸如IEEE802.11无线局域网(WLAN，WirelessLocal Area Network)无线接口、全球微波互联接入(Wi-MAX，WorldwideInteroperability for Microwave Access)接口、以太网接口、通用串行总线(USB，Universal Serial Bus)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC，Near FieldCommunication)。

在本说明书的一个实施例中，计算设备800的上述部件以及图8中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图8所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备800可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或个人计算机(PC，Personal Computer)的静止计算设备。计算设备800还可以是移动式或静止式的服务器。

其中，处理器820用于执行如下计算机可执行指令，该计算机可执行指令被处理器执行时实现上述信令协商方法或上述信息传输方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的信令协商方法或上述信息传输方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述信令协商方法或上述信息传输方法的技术方案的描述。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现上述信令协商方法或上述信息传输方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的信令协商方法或上述信息传输方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述信令协商方法或上述信息传输方法的技术方案的描述。

本说明书一实施例还提供一种计算机程序，其中，当所述计算机程序在计算机中执行时，令计算机执行上述信令协商方法或上述信息传输方法的步骤。

上述为本实施例的一种计算机程序的示意性方案。需要说明的是，该计算机程序的技术方案与上述的信令协商方法或上述信息传输方法的技术方案属于同一构思，计算机程序的技术方案未详细描述的细节内容，均可以参见上述信令协商方法或上述信息传输方法的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据专利实践的要求进行适当的增减，例如在某些地区，根据专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书实施例并不受所描述的动作顺序的限制，因为依据本说明书实施例，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书实施例所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书实施例的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书实施例的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。

Claims (11)

1.一种信令协商方法，应用于边缘服务器，包括：

生成媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记；

通过回源路径，传输所述媒体预回源请求；

接收回源服务器返回的媒体描述信息，所述回源服务器是所述回源路径上的任一服务器，所述媒体描述信息是所述回源服务器在确定命中了所述媒体流标识对应的媒体流的情况下，根据所述媒体查询标记，利用所述媒体流查询出的媒体描述信息；

利用所述媒体描述信息进行所述信令协商。

2.根据权利要求1所述的方法，在接收回源服务器返回的媒体描述信息时，还包括：

接收所述回源服务器根据所述媒体流标识下发的媒体流。

3.根据权利要求1所述的方法，所述生成媒体预回源请求，包括：

接收客户端发送的信令协商请求；

根据所述信令协商请求，生成媒体预回源请求。

4.根据权利要求3所述的方法，还包括：

向所述客户端返回信令协商应答，所述信令协商应答携带所述媒体描述信息。

5.一种信息传输方法，应用于回源服务器，包括：

接收边缘服务器通过回源路径传输的媒体预回源请求，所述媒体预回源请求携带媒体流标识和媒体描述查询标记，所述回源服务器是所述回源路径上的任一服务器；

判断所述回源服务器是否命中了所述媒体流标识对应的媒体流；

如果是，根据所述媒体描述查询标记，利用所述媒体流查询出对应的媒体描述信息；

向所述边缘服务器发送所述媒体描述信息。

6.根据权利要求5所述的方法，还包括：

如果命中了所述媒体流标识对应的媒体流，向所述边缘服务器发送所述媒体流。

7.根据权利要求5所述的方法，所述根据所述媒体描述查询标记，利用所述媒体流查询出对应的媒体描述信息，包括：

触发转码服务器对所述媒体流标识对应的媒体流，按照客户端需求的媒体格式进行转码，获得转码流；

对所述转码流进行解析，获得所述转码流中的媒体描述信息。

8.根据权利要求5所述的方法，所述向所述边缘服务器发送所述媒体描述信息，包括：

利用所述媒体预回源请求在所述回源路径上对应的会话，将所述媒体描述信息相对于所述媒体流独立地返回给所述边缘服务器。

9.一种内容分发系统，包括：应用了如权利要求1-4任一项所述方法的边缘服务器和应用了如权利要求5-8任一项所述方法的回源服务器。

10.一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1-4任一项所述信令协商方法的步骤，或者，实现权利要求5-8任一项所述信息传输方法的步骤。

11.一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1-4任一项所述信令协商方法的步骤，或者，实现权利要求5-8任一项所述信息传输方法的步骤。