CN114553839A - Rtc数据的处理方法以及装置 - Google Patents

Abstract

本申请提供一种RTC数据的处理方法以及装置。该方法包括：用户终端向第一服务器发送RTC会话请求，该RTC会话请求携带有目标媒体数据流的拉流信息，用户终端在信令通道上，接收第一服务器发送的RTC会话响应和目标媒体数据流中的第一数据流，该RTC会话响应携带有媒体服务单元的接口信息，媒体服务单元的接口信息用于建立媒体数据通道，该媒体数据通道用于传输第二数据流，该第二数据流包括目标媒体数据流中除第一数据流之外的数据流，进一步地，用户终端播放该第一数据流。缩短了媒体数据流播放的首帧时间，进而提升了客户端的启播速度。

Description

RTC数据的处理方法以及装置

技术领域

本申请涉及网络技术领域，尤其涉及一种RTC数据的处理方法以及装置。

背景技术

在实时通信(Real-Time Communication，RTC)的音/视频数据传输场景中，客户端从服务端拉取媒体数据的拉流过程中，为了降低数据传输的时延，通常在客户端和服务端之间建立媒体数据通道。然而，由于建立媒体数据通道的过程较为复杂，导致客户端从发起拉流请求到接收到媒体数据的首个音/视频帧的时间较长，降低了媒体数据的启播速度。

发明内容

本申请实施例提供一种RTC数据的处理方法以及装置，以期缩短首帧时间，进而提升客户端的启播速度。

第一方面，本申请实施例提供一种RTC数据的处理方法，包括：用户终端向第一服务器发送RTC会话请求，该RTC会话请求携带有目标媒体数据流的拉流信息；该用户终端在信令通道上，接收该第一服务器发送的RTC会话响应和该目标媒体数据流中的第一数据流，该RTC会话响应携带有媒体服务单元的接口信息，该媒体服务单元的接口信息用于建立媒体数据通道，该媒体数据通道用于传输第二数据流，该第二数据流包括该目标媒体数据流中除该第一数据流之外的数据流；该用户终端播放该第一数据流。

第二方面，本申请实施例提供一种RTC数据传输方法，包括：第一服务器接收用户终端发送的RTC会话请求，该RTC会话请求携带有目标媒体数据流的拉流信息；该第一服务器在信令通道上，向该用户终端发送RTC会话响应和该目标媒体数据流中的第一数据流，该RTC会话响应携带有媒体服务单元的接口信息，该媒体服务单元的接口信息用于建立媒体数据通道，该媒体数据通道用于传输第二数据流，该第二数据流包括该目标媒体数据流中除该第一数据流之外的数据流。

第三方面，本申请实施例提供一种RTC数据的处理装置，包括：信令单元，用于向第一服务器发送RTC会话请求，该RTC会话请求携带有目标媒体数据流的拉流信息；该信令单元还用于在信令通道上，接收该第一服务器发送的RTC会话响应和该目标媒体数据流中的第一数据流，该RTC会话响应携带有媒体服务单元的接口信息，该媒体服务单元的接口信息用于建立媒体数据通道，该媒体数据通道用于传输第二数据流，该第二数据流包括该目标媒体数据流中除该第一数据流之外的数据流；媒体单元，用于播放该第一数据流。

第四方面，本申请实施例提供一种RTC数据的处理装置，包括：信令服务单元，用于接收用户终端发送的RTC会话请求，该RTC会话请求携带有目标媒体数据流的拉流信息；该信令服务单元还用于在信令通道上，向该用户终端发送RTC会话响应和该目标媒体数据流中的第一数据流，该RTC会话响应携带有媒体服务单元的接口信息，该媒体服务单元的接口信息用于建立媒体数据通道，该媒体数据通道用于传输第二数据流，该第二数据流包括该目标媒体数据流中除该第一数据流之外的数据流。

第五方面，本申请实施例提供一种电子设备，包括：至少一个处理器和存储器；该存储器存储计算机执行指令；该至少一个处理器执行该存储器存储的计算机执行指令，使得该至少一个处理器执行如第一方面、或第二方面提供的方法。

第六方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，当处理器执行该计算机执行指令时，实现如第一方面或第二方面提供的方法。

第七方面，本申请实施例提供一种计算机程序产品，包括计算机指令，该计算机指令被处理器执行时实现第一方面或第二方面或提供的方法。

在本申请实施例中，在用户终端从第一服务器拉流的过程中，第一服务器通过在信令通道上发送包含目标媒体数据流中的第一数据流，使得目标媒体数据流中的第一数据流提前下发至用户终端，而无需等等媒体数据通道的建立，缩短了媒体数据流播放的首帧时间，进而提升了客户端的启播速度。

附图说明

图1为本申请提供的一种数据传输系统的示意图；

图2为本申请实施例提供的一种RTC数据的处理方法的交互流程示意图；

图3为本申请实施例提供的一种RTC数据的处理方法的交互流程示意图；

图4为本申请实施例提供的一种RTC数据的处理装置的示意性框图；

图5为本申请实施例提供的一种RTC数据的处理装置的示意性框图；

图6为本申请示例性实施例提供的一种终端设备的结构示意图；

图7为本申请示例性实施例提供的一种服务器的结构示意图。

具体实施方式

本申请适用于任意一种RTC的音/视频数据传输场景，例如网络电话、电话会议、视频聊天、直播等等，尤其适用于低延时直播(Real-time Streaming，RTS)场景。

需要说明的是，本申请中传输的音/视频数据均可以是一种数据流(data stream)(下文中称作媒体数据流)，其可以理解为一组有序的，有起点和终点的字节的数据序列。

下面主要以低延时直播为例对本申请进行说明，但并不应理解为对本申请的任何限定。

图1为本申请提供的一种数据传输系统的示意图。如图1所示，该数据传输系统100包括播放客户端110、服务端120和主播客户端130。其中，服务端120分别与播放客户端110和主播客户端130进行通信连接。主播客户端130将录制的数据流发送至服务端120，该过程或称作推流过程，主播客户端130可以在音/视频录制的过程中持续向服务端120发送实时的数据流；播放客户端110从服务端120获取服务端120存储的媒体数据流，该过程或称作拉流过程，该媒体数据流可以是主播客户端130正在录制的数据流中已发送至服务端120的部分流数据。基于此，通过服务端120向播放客户端110传输主播客户端130中实时录制的音/视频，并在播放客户端110中进行渲染播放，以实现直播。

上述播放客户端110、服务端120和主播客户端130中均可以部署有网页即时通信(Web Real-Time Communication，WebRTC)，以支持网页浏览器进行实时音/视频数据传输，实现上述RTS。

上述播放客户端110和主播客户端130均可以实现为任意终端设备，或称作用户终端，例如普通计算机PC、手机(mobile phone)、平板电脑(pad)、智能可穿戴设备、带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端设备、增强现实(augmented reality，AR)终端设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。

上述服务端120可以实现为普通服务器、服务器集群，或者云端服务器、服务器集群。服务端120可以用于实现信令服务、媒体服务、网络地址转换(Network AddressTranslation，NAT)会话穿越应用程序(Session Traversal Utilities for NAT，STUN)服务和NAT的中继穿越(Traversal Using Relays around NAT，TURN)服务中的部分或者全部。在一些实施例中，上述各服务可以分别实现为独立的服务器，例如可以包括图1所示的信令服务器121、媒体服务器122、STUN/TURN服务器123中的部分或者全部，TURN服务器一般可以实现STUN服务和TURN服务；在另一些实施例中，上述部分或者全部服务可以以服务单元的形式集成于同一服务器中，例如下文中的第一服务器可以包括信令服务单元和媒体服务单元。

本申请实施例中，信令服务可以用于实现播放客户端110与服务端120之间的信令交互；媒体服务可以用于实现接收主播客户端130发送的媒体数据流，以及向播放客户端110提供媒体数据流；STUN服务用于检测播放客户端110周围是否存在NAT；TURN服务用于穿透播放客户端110周围的NAT，实现在播放客户端110与服务端120之间建立媒体数据通道。

在上述拉流过程中，为了降低数据传输的时延，通常在播放客户端110和服务端120之间建立媒体数据通道，例如建立WebRTC的媒体数据通道，以实现WebRTC标准接入拉流播放。然而，建立媒体数据通道的过程较为复杂。例如，建立媒体数据通道可以包括信令阶段和交互式连接建立(Interactive Connectivity Establishment，ICE)阶段，在信令阶段中，播放客户端110向服务端120发起拉流请求，播放客户端110和服务端120之间针对所需传输的媒体数据流的元数据进行协商，在ICE阶段基于STUN和/或TURN，建立媒体数据通道，进而在媒体数据通道中传输媒体数据流。此种情况下，播放客户端110从发起拉流请求，到获取媒体数据流(同下文中的目标媒体数据流)的首个音/视频帧(同下文中的首帧数据)，并对首个音/视频帧进行播放，消耗的时间较长，也即首帧时间较长，降低了播放客户端的启播速度。当然，在其他RTC的会话场景中也同样存在首帧时间长，启播速度慢的问题。

针对上述技术问题，本申请实施例考虑在上述信令阶段中对目标媒体数据中的第一数据流进行拉流，以期缩短首帧时间，进而提升客户端的启播速度。

需要说明的是，首帧数据是客户端请求拉取目标媒体数据流后接收到的目标媒体数据流的首个音/视频帧，该首帧数据可以不是目标媒体数据流的首个音/视频帧。例如目标媒体数据流是主播客户端持续录制的多个音/视频帧，而首帧数据是服务端接收到播放客户端发送的RTC会话请求后，从播放客户端已推流的目标媒体数据流中获取的处于当前时刻的预设时间段内的音/视频帧，该音/视频帧可以是目标媒体数据流中的第n个音/视频帧，n为正整数。进而将该音/视频帧作为首帧数据，持续获取首帧数据之后的数据流。

下面结合附图对本申请实施例提供的RTC数据的处理方法做详细说明。

应理解，下文仅为便于理解和说明，以用户终端和第一服务器之间的交互为例详细说明本申请实施例所提供的方法。该用户终端例如可以是图1中的播放客户端110、第一服务器例如可以是图1中的服务端120或服务端120中的一个服务器。示例性的，第一服务器可以是图1中的信令服务器121，或者部署有信令服务的服务器。

在一些实施例中，第一服务器还部署有媒体服务单元。

在另一些实施例中，媒体服务单元部署于第二服务器，例如是图1中的媒体服务器122，此种情况下，第一服务器和用户终端还分别与第二服务器存在数据交互。

在又一些实施例中，第一服务器和用户终端还与第三服务器存在数据交互，第三服务器例如可以是图1中的STUN/TURN服务器123。

图2为本申请实施例提供的一种RTC数据的处理方法的交互流程示意图。如图2所示，该方法包括：

S210，用户终端向第一服务器发送RTC会话请求，该RTC会话请求携带有目标媒体数据流的拉流信息；相应的，第一服务器接收用户终端发送的RTC会话请求。

S220，第一服务器在信令通道上，向所述用户终端发送RTC会话响应和目标媒体数据流中的第一数据流，该RTC会话响应携带有媒体服务单元的接口信息，该媒体服务单元的接口信息用于建立媒体数据通道，该媒体数据通道用于传输第二数据流，该第二数据流包括目标媒体数据流中除第一数据流之外的数据流；相应的，用户终端在信令通道上，接收第一服务器发送的RTC会话响应和目标媒体数据流中的第一数据流。

S230，用户终端播放该第一数据流。

上述RTC会话请求至少携带有用于获取目标媒体数据流的拉流信息，该拉流信息例如包括目标媒体数据流的统一资源标识符(Uniform Resource Identifier，URL)、域名、互联网协议(Internet Protocol，IP)地址中的至少之一。第一服务器基于该拉流信息可以确定用户终端所需的目标媒体数据流。

需要说明的是，目标媒体数据流为用户终端所需拉取的媒体数据流，并不特指某一类媒体数据流。

一般来说，第一服务器响应于该RTC会话请求，通过信令通道向用户终端发送RTC会话响应，该RTC会话响应携带有媒体服务单元的接口信息，使用户终端和部署媒体服务单元的服务器之间可以建立媒体数据通道，进而向用户终端发送该目标媒体数据。其中，媒体服务单元的接口信息包括但不限于媒体服务单元的IP地址和/或端口。

如前所述，媒体服务单元可以部署于第一服务器或第二服务器。当媒体服务单元部署于第一服务器时，媒体服务单元的接口信息可以是第一服务器的IP地址和/或端口；类似的，当媒体服务单元部署于第二服务器时，媒体服务单元的接口信息可以是第二服务器的IP地址和/或端口。

进一步地，本申请实施例为了能够缩短首帧时间，在上述S220中，第一服务器还通过信令通道传输目标媒体数据流中的第一数据流，使第一服务器不需要等待媒体数据通道建立完成，即向用户终端发送目标媒体数据的第一数据流。

第一服务器可以基于拉流信息获取自身存储的目标媒体数据流中的第一数据流，例如第一服务器从第一服务器中部署的媒体服务单元拉取第一数据流；或者，第一服务器可以基于拉流信息从第二服务器获取目标媒体数据流中的第一数据流，例如第一服务器向第二服务器发送拉流信息并接收第二服务器发送的第一数据流。

在一些实施例中，第一数据流在目标媒体数据流中的时序早于第二数据流在目标媒体数据流中的时序。例如，第一数据流包括目标媒体数据流中由首帧数据开始的一段数据流，第二数据流包括目标媒体数据中由第一数据流结束位置的帧数据开始的一段数据流。一般来说，第一数据流结束位置的帧数据与第二数据流开始位置的帧数据在目标媒体数据流中为相邻的帧数据，也即第一数据流和第二数据流具有连续性，当然，本申请并不排除第一数据流与第二数据流不连续或者存在重叠的情况。

本申请实施例对第一数据流的时长不做限定。作为一种示例，第一数据流可以包括由首帧数据开始的预设时长的数据流，该预设时长可以与建立媒体数据通道的时长正相关；作为另一种示例，第一数据流包括目标媒体数据流中由首帧数据开始至媒体数据通道建立完成时，已在信令通道发送的数据流，此种情况下，上述S220具体可以实现为，第一服务器在信令通道上，持续向用户终端发送目标媒体数据流中由首帧数据开始的数据流，直至媒体数据通道建立完成。上述第二种示例相对于第一种示例来说，通过信令通道传输的第一数据流和切换至媒体数据通道传输的目标媒体数据流中的其他数据流能够更好的衔接，减少播放卡顿的现象。

可选的，第一数据流可以包括目标媒体数据流中的全部数据流。例如，第一服务器可以在目标媒体数据流的总时长(或者说数据大小)小于预设值时，在信令通道中发送该目标媒体数据流。

可以理解的是，信令通道和媒体数据通道均为逻辑传输通道，其与传输的阶段以及传输的内容相关。信令通道用于表征用户终端和第一服务器在信令阶段进行信令交互的通道；媒体数据通道用于表征用户终端和第一服务器(或第二服务器)在拉流阶段传输媒体数据的通道，例如基于WebRTC的媒体数据通道。

可选的，用户终端可以通过信令通道向第一服务器发送RTC会话请求。

在上述S210中的RTC会话请求和S220中的会话响应均可以是信令。应理解，信令用于协调通信，例如通过信令交互可以使WebRTC应用程序能够建立一个会话。

例如，RTC会话请求可以实现为会话描述协议(Session Description Protocol，SDP)请求(offer)，RTC会话响应可以实现为SDP响应(answer)。SDP offer和SDP answer可以用于两个会话实体(如用户终端和第一服务器)之间的媒体协商。

基于此，为了实现信令阶段的协调通信，RTC会话请求还用于请求第一服务器和用户终端协商媒体数据通道上传输的媒体数据的元数据。应理解，元数据被定义为：描述数据的数据，对数据及信息资源的描述性信息，媒体数据的元数据为描述媒体数据的数据。该元数据例如包括媒体数据的编/解码器设置、媒体格式、传输带宽等中的至少之一。在如下图3中将对协商过程进行说明。

在上述S230中，若第一数据流是视频数据流，用户终端将接收到的第一数据流进行渲染，并先用户终端的显示界面中显示渲染得到的画面；若第一数据流是音频数据流，用户终端播放该第一数据流，可选的，用户终端在播放第一数据流时显示音频播放控制界面。

本申请实施例中，在用户终端从第一服务器拉流的过程中，第一服务器通过在信令通道上发送包含目标媒体数据流中的第一数据流，使得目标媒体数据流中的第一数据流提前下发至用户终端，而无需等等媒体数据通道的建立，缩短了媒体数据流播放的首帧时间，进而提升了客户端的启播速度。

一般来说，媒体数据通道有利于提供媒体数据的传输质量，以及媒体数据流传输的实时性。当媒体数据通道建立完成后，可以将模板媒体数据切换至媒体数据通道进行传输，以进一步提高数据传输的质量和实时性。基于此，该方法还包括如图2所示的S240至S260中的部分或者全部过程：

S240，用户终端在播放第一数据流时，根据媒体服务单元的接口信息和STUN，建立用户终端与媒体服务单元之间的媒体数据通道。

S250，第一服务器通过媒体服务单元在媒体数据通道上，向用户终端发送第二数据流；相应的，用户终端在媒体数据通道上，接收媒体服务单元发送的第二数据流。

S260，用户终端播放第二数据流。

为了加快媒体数据通道建立的速度，用户终端可以在播放第一数据流的过程中，例如在对第一数据流进行渲染的过程中，启动建立媒体数据通道的过程。换言之，上述S240和上述S230可以同步执行。

上述S240中，用户终端可以将媒体服务单元的接口信息作为候选地址，并通过STUN服务单元(可以实现为STUN/TURN服务器)进行NAT检测。在检测通过时与媒体服务单元建立媒体数据通道；在NAT检测失败时，基于TURN服务单元(可以实现为TURN服务器)与媒体服务单元建立媒体数据通道，换言之，通过TURN提供的中继服务，建立用户终端与媒体服务单元之间的媒体数据通道。下面图3所述实施例中将作进一步说明。

上述S250中，第一服务器将目标媒体数据中未通过信令通道发送的数据流切换至媒体数据通道上发送，该切换过程可以理解为，第一服务器按照媒体数据通道的传输协议发送数据流，例如将目标媒体数据中未通过信令通道发送的数据流按照实时传输协议(Real-time Transport Protocol，RTP)进行数据封装后发送。当然，在需要TURN服务器提供中继服务的情况下，第一服务器将目标媒体数据中未通过信令通道发送的数据流发送至TURN服务器，再由TURN服务器转发至用户终端。

可选的，第二数据包括目标媒体数据流中除第一数据流之外的其他数据流中的部分或者全部；或者第二数据还可以包括目标媒体数据流之外的数据流，例如第一数据流包括目标媒体数据流中的全部数据流，则不需要在媒体数据通道中传输目标媒体数据流，此种情况下，第二数据中不包括目标媒体数据流中的数据流。

上述S260中，用户终端播放第二数据流，其实现方式与播放第一数据流类似，此处不再赘述。

下面结合图3所示，以用户终端包括媒体单元和信令单元、第一服务器包括信令服务单元和媒体服务单元、第三服务器包括STUN/TURN服务单元为例，进行示例性的说明。但不应理解为对本申请的限定，例如用户终端中可以不区分媒体单元和信令单元，又例如媒体服务单元可以部署于第二服务器。

图3为本申请实施例提供的一种RTC数据的处理方法的交互流程示意图。如图3所示，该方法包括如下S301至S311中的部分或者全部过程：

S301，信令单元向信令服务单元发送RTC会话请求，该RTC会话请求携带有目标媒体数据流的拉流信息；

S302，信令服务单元向媒体服务单元发送拉流信息；

S303，信令服务单元进行信令协商；

S304，媒体服务单元向信令服务单元发送第一数据流；

S305，信令服务单元在信令通道上，发送RTC会话响应和第一数据流；

S306，信令单元向媒体单元发送第一数据流；

S307，媒体单元播放第一数据流；

S308，信令单元向STUN/TURN服务单元发送STUN绑定(binfing)offer；

S309，STUN/TURN服务单元向信令单元发送STUN binding response；

S310，媒体服务单元在媒体数据通道上，向媒体单元发送第二数据流；

S311，媒体单元播放第二数据流。

上述部分步骤，与图2中对应的步骤类似，具有相同或者相似的实现方式，区别在于图3中的执行主体体现为用户终端或第一服务器中的单元，例如，S301、S305、S307、S310和S311。因此，不再对其实现方式进行赘述。

在上述S302和S304中，信令服务单元向媒体服务单元发送拉流信息以获取媒体服务单元发送的第一数据流；在S303中基于RTC会话请求进行信令协商；进而信令服务单元根据协商的结果生成RTC会话响应，并将RTC会话响应与获取到的第一数据流一起通过信令通道传输给信令单元。

其中，S303的信令协商主要包括对媒体数据的元数据的协商。如前所述，媒体数据的元数据可以包括媒体数据的编/解码器设置、媒体格式、传输带宽等中的至少之一。为了实现媒体数据的元数据的协商，RTC会话请求中应携带有用户终端支持的媒体数据的元数据，第一服务器(例如信令服务单元)可以针对用户终端支持的媒体数据的元数据，确定媒体数据通道上传输的媒体数据的元数据。第一服务器确定的媒体数据通道上传输的媒体数据的元数据，一方面应为用户终端所支持的媒体数据的元数据，另一方面应为媒体服务单元提供的媒体数据所能满足的元数据。

举例而言，若RTC会话请求指示的用户终端支持的媒体格式包括AVI、MPEG、MOV，第一服务器确定RTC会话请求所请求的目标媒体数据流的格式为AVI，则可以通过RTC会话响应指示协商后的媒体数据的媒体格式为AVI。若RTC会话请求指示的用户终端支持的媒体格式包括AVI、MPEG，第一服务器确定RTC会话请求所请求的目标媒体数据流的格式为MOV；则第一服务器通过RTC会话响应指示无法基于该用户终端所支持的媒体数据的元数据进行媒体数据的传输，或者，第一服务器具备将MOV转换为AVI的能力，则第一服务器通过通过RTC会话响应指示协商后的媒体数据的媒体格式为AVI。

若信令服务单元和媒体服务单元均部署于第一服务器，则上述S302和S304为第一服务器内部的实现过程，若信令服务单元部署于第一服务器、媒体服务单元部署于第二服务器，则上述S302和S304为第一服务器与第二服务器之间的交互过程。

上述S308和S309可以实现媒体数据通道的建立。示例性的，ICE建立可以包括NAT检测阶段和打洞阶段，上述S308和S309可用于实现NAT检测阶段的NAT检测，例如，STUNbinding offer中携带有用户终端的IP地址和端口，STUN/TURN服务单元接收到STUNbinding offer后，获取发送方的IP地址和端口，将发送方的IP地址和端口与STUN bindingoffer中携带IP地址和端口进行比较，如果一致，表明用户终端前不存在NAT设备，如果不一致，表明用户终端前存在NAT设备。在用户终端前存在NAT设备的情况下，可以通过TURN服务单元提供中继服务，以建立媒体单元和媒体服务单元之间的媒体数据通道。

在媒体数据通道建立完成后，媒体服务单元将目标媒体数据由信令通道切换至媒体数据通道上继续发送，该过程已在图2所示实施例中说明，此处不再赘述。

需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的数据、设备等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图4为本申请实施例提供的一种RTC数据的处理装置的示意性框图。如图4所示，该RTC数据的处理装置400可以包括信令单元410和媒体单元420。

可选的，该RTC数据的处理装置400可对应于上文方法实施例中的用户终端，例如可以为前述播放客户端的一种实现，或者配置于播放客户端中的部件(如芯片或芯片系统等)。

其中，信令单元410可以用于向第一服务器发送RTC会话请求，该RTC会话请求携带有目标媒体数据流的拉流信息；该收发单元410还用于在信令通道上，接收该第一服务器发送的RTC会话响应和该目标媒体数据流中的第一数据流，该RTC会话响应携带有媒体服务单元的接口信息，该媒体服务单元的接口信息用于建立媒体数据通道，该媒体数据通道用于传输第二数据流；媒体单元420可以用于播放该第一数据流。

在一些实施例中，第一数据流在目标媒体数据流中的时序早于第二数据流在目标媒体数据流中的时序。

在一些实施例中，信令单元410还用于在播放该第一数据流时，根据该媒体服务单元的接口信息和网络地址转换会话穿越应用程序STUN，建立该用户终端与该媒体服务单元之间的媒体数据通道；媒体单元420还用于在该媒体数据通道上，接收该媒体服务单元发送的第二数据流；媒体单元420还用于播放该第二数据流。

在一些实施例中，该第一数据流包括该目标媒体数据流中由该首帧数据开始的预设时长的数据流。

在一些实施例中，该第一数据流包括该目标媒体数据流中由该首帧数据开始至该媒体数据通道建立完成时，已在该信令通道发送的数据流；信令单元410具体用于在该信令通道上，持续接收该第一服务器发送该目标媒体数据流中由该首帧数据开始的数据流，直至该媒体数据通道建立完成。

在一些实施例中，信令单元410具体用于向该第一服务器的信令服务单元发送该RTC会话请求。

在一些实施例中，该媒体服务单元包括于该第一服务器或第二服务器，该第一服务器与该第二服务器相互独立。

应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。

图5为本申请实施例提供的一种RTC数据的处理装置的示意性框图。如图5所示，该RTC数据的处理装置500可以包括信令服务单元510和媒体服务单元520。

可选的，该RTC数据的处理装置500可对应于上文方法实施例中的第一服务器，例如可以为第一服务器，或者配置于第一服务器中的部件(如芯片或芯片系统等)。

其中，信令服务单元510可以用于接收用户终端发送的RTC会话请求，该RTC会话请求携带有目标媒体数据流的拉流信息；该信令服务单元510还用于在信令通道上，向该用户终端发送RTC会话响应和该目标媒体数据流中的第一数据流，该RTC会话响应携带有媒体服务单元的接口信息，该媒体服务单元的接口信息用于建立媒体数据通道，该媒体数据通道用于传输第二数据流。

在一些实施例中，该第一数据流在目标媒体数据流中的时序早于第二数据流在目标媒体数据流中的时序。

在一些实施例中，该媒体服务单元520在该媒体数据通道上，向该用户终端发送第二数据流。

在一些实施例中，该第一数据流包括该目标媒体数据流中由该首帧数据开始的预设时长的数据流。

在一些实施例中，该第一数据流包括该目标媒体数据流中由该首帧数据开始至该媒体数据通道建立完成时，已在该信令通道发送的数据流；媒体服务单元510具体用于在该信令通道上，持续向该用户终端发送该目标媒体数据流中由该首帧数据开始的数据流，直至该媒体数据通道建立完成。

在一些实施例中，信令服务单元510具体用于接收该用户终端发送的该RTC会话请求；该信令服务单元510还用于根据该拉流信息，从媒体服务单元520获取该第一数据流。

应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。

图6为本申请示例性实施例提供的一种终端设备的结构示意图。该终端设备可以实现为上文方法实施例中的用户终端。如图6所示，该终端设备600包括：处理器610和收发器620。可选地，该终端设备600还包括存储器630。其中，处理器610、收发器620和存储器630之间可以通过内部连接通路互相通信，传递控制和/或数据信号，该存储器630用于存储计算机程序，该处理器610用于从该存储器630中调用并运行该计算机程序，以控制该收发器620收发信号。可选地，终端设备600还可以包括天线640，用于将收发器620输出的上行数据或上行控制信令通过无线信号发送出去。

上述处理器610可以和存储器630可以合成一个处理装置，处理器610用于执行存储器630中存储的程序代码来实现上述功能。具体实现时，该存储器630也可以集成在处理器610中，或者独立于处理器610。

上述收发器620可以包括接收器(或称接收机、接收电路)和发射器(或称发射机、发射电路)。其中，接收器用于接收信号，发射器用于发射信号。

可选地，上述终端设备600还可以包括电源650，用于给终端设备600中的各种器件或电路提供电源。

除此之外，为了使得该终端设备的功能更加完善，该终端设备600还可以包括输入单元660、显示单元670、音频电路680、摄像头690和传感器700等中的一个或多个，所述音频电路还可以包括扬声器680a、麦克风680b等。

应理解，图6所示的终端设备600能够实现上文方法实施例中涉及第一终端或第二终端的各个过程。终端设备600中的各个模块的操作和/或功能，分别为了实现上述方法实施例中的相应流程。具体可参见上述方法实施例中的描述，为避免重复，此处适当省略详细描述。

图7为本申请示例性实施例提供的一种服务器的结构示意图。该服务器800可以为上文方法实施例中第一服务器的一种实现。如图7所示，该云服务器800包括：存储器810和处理器820。

存储器810，用于存储计算机程序，并可被配置为存储其它各种数据以支持在云服务器上的操作。该存储器810可以是对象存储(Object Storage Service，OSS)。

处理器820，与存储器810耦合，用于执行存储器810中的计算机程序，以用于实现上文方法实施例中由第一服务器实现的方法。

进一步，如图7所示，该服务器实现为云服务器时还包括：防火墙830、负载均衡器840、通信组件850、电源组件860等其它组件。图7中仅示意性给出部分组件，并不意味着服务器只包括图7所示组件。

应理解，图7所示的服务器800能够实现上文方法实施例中涉及第一服务器的各个过程。服务器800中的各个模块的操作和/或功能，分别为了实现上述方法实施例中的相应流程。具体可参见上述方法实施例中的描述，为避免重复，此处适当省略详细描述。

图6所示的终端设备和图7所示的服务器均可以是一种电子设备。

本申请还提供了一种处理装置，包括至少一个处理器，所述至少一个处理器用于执行存储器中存储的计算机程序，以使得所述处理装置执行上述方法实施例中用户终端或第一服务器执行的方法。

本申请实施例还提供了一种处理装置，包括处理器和输入输出接口。所述输入输出接口与所述处理器耦合。所述输入输出接口用于输入和/或输出信息。所述信息包括指令和数据中的至少一项。所述处理器用于执行计算机程序，以使得所述处理装置执行上述方法实施例中用户终端或第一服务器执行的方法。

本申请实施例还提供了一种处理装置，包括处理器和存储器。所述存储器用于存储计算机程序，所述处理器用于从所述存储器调用并运行所述计算机程序，以使得所述处理装置执行上述方法实施例中用户终端或第一服务器执行的方法。

应理解，上述处理装置可以是一个或多个芯片。例如，该处理装置可以是现场可编程门阵列(field programmable gate array，FPGA)，可以是专用集成芯片(applicationspecific integrated circuit，ASIC)，还可以是系统芯片(system on chip，SoC)，还可以是中央处理器(central processor unit，CPU)，还可以是网络处理器(networkprocessor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logicdevice，PLD)或其他集成芯片。

在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

应注意，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rateSDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(directrambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行上述方法实施例中的第一终端、第二终端设备或云服务端执行的方法。

根据本申请实施例提供的方法，本申请还提供一种计算机可读存储介质，该计算机可读存储介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行上述方法实施例中的第一终端、第二终端设备或云服务端执行的方法。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种实时通信RTC数据的处理方法，其特征在于，包括：

用户终端向第一服务器发送RTC会话请求，所述RTC会话请求携带有目标媒体数据流的拉流信息；

所述用户终端在信令通道上，接收所述第一服务器发送的RTC会话响应和所述目标媒体数据流中的第一数据流，所述RTC会话响应携带有媒体服务单元的接口信息，所述媒体服务单元的接口信息用于建立媒体数据通道，所述媒体数据通道用于传输第二数据流，所述第二数据流包括所述目标媒体数据流中除所述第一数据流之外的数据流；

所述用户终端播放所述第一数据流。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述用户终端在播放所述第一数据流时，根据所述媒体服务单元的接口信息和网络地址转换会话穿越应用程序STUN，建立所述用户终端与所述媒体服务单元之间的媒体数据通道；

所述用户终端在所述媒体数据通道上，接收所述媒体服务单元发送的所述第二数据流；

所述用户终端播放所述第二数据流。

3.根据权利要求1或2所述的方法，其特征在于，所述第一数据流包括所述目标媒体数据流中由首帧数据开始的预设时长的数据流。

4.根据权利要求1或2所述的方法，其特征在于，所述第一数据流包括所述目标媒体数据流中由首帧数据开始至所述媒体数据通道建立完成时，已在所述信令通道发送的数据流；

所述用户终端在信令通道上，接收所述第一服务器发送的所述目标媒体数据流中的第一数据流，包括：

所述用户终端在所述信令通道上，持续接收所述第一服务器发送所述目标媒体数据流中由所述首帧数据开始的数据流，直至所述媒体数据通道建立完成。

5.根据权利要求1或2所述的方法，其特征在于，所述第一数据流在所述目标媒体数据流中的时序早于所述第二数据流在所述目标媒体数据流中的时序。

6.根据权利要求1或2所述的方法，其特征在于，所述用户终端向第一服务器发送RTC会话请求，包括：

所述用户终端向所述第一服务器的信令服务单元发送所述RTC会话请求。

7.根据权利要求1或2所述的方法，其特征在于，所述媒体服务单元包括于所述第一服务器或第二服务器，所述第一服务器与所述第二服务器相互独立。

8.一种RTC数据的处理方法，其特征在于，包括：

第一服务器接收用户终端发送的RTC会话请求，所述RTC会话请求携带有目标媒体数据流的拉流信息；

所述第一服务器在信令通道上，向所述用户终端发送RTC会话响应和所述目标媒体数据流中的第一数据流，所述RTC会话响应携带有媒体服务单元的接口信息，所述媒体服务单元的接口信息用于建立媒体数据通道，所述媒体数据通道用于传输第二数据流，所述第二数据流包括所述目标媒体数据流中除所述第一数据流之外的数据流。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括：

所述第一服务器通过所述媒体服务单元在所述媒体数据通道上，向所述用户终端发送所述第二数据流。

10.根据权利要求8或9所述的方法，其特征在于，所述第一数据流包括所述目标媒体数据流中由首帧数据开始的预设时长的数据流。

11.根据权利要求8或9所述的方法，其特征在于，所述第一数据流包括所述目标媒体数据流中由首帧数据开始至所述媒体数据通道建立完成时，已在所述信令通道发送的数据流；

所述第一服务器在信令通道上，向所述用户终端发送所述目标媒体数据流中的第一数据流，包括：

所述第一服务器在所述信令通道上，持续向所述用户终端发送所述目标媒体数据流中由所述首帧数据开始的数据流，直至所述媒体数据通道建立完成。

12.根据权利要求8或9所述的方法，其特征在于，所述第一服务器接收用户终端发送的RTC会话请求，包括：

所述第一服务器通过信令服务单元接收所述用户终端发送的所述RTC会话请求；

所述方法还包括：

所述第一服务器通过所述信令服务单元根据所述拉流信息，从媒体服务单元获取所述第一数据流。

13.一种RTC数据的处理装置，其特征在于，包括：

信令单元，用于向第一服务器发送RTC会话请求，所述RTC会话请求携带有目标媒体数据流的拉流信息；

所述信令单元还用于在信令通道上，接收所述第一服务器发送的RTC会话响应和所述目标媒体数据流中的第一数据流，所述RTC会话响应携带有媒体服务单元的接口信息，所述媒体服务单元的接口信息用于建立媒体数据通道，所述媒体数据通道用于传输第二数据流，所述第二数据流包括所述目标媒体数据流中除所述第一数据流之外的数据流，所述第一数据流在所述目标媒体数据流中的时序早于所述第二数据流在所述目标媒体数据流中的时序；

媒体单元，用于播放所述第一数据流。

14.一种RTC数据的处理装置，其特征在于，包括：

信令服务单元，用于接收用户终端发送的RTC会话请求，所述RTC会话请求携带有目标媒体数据流的拉流信息；

所述信令服务单元还用于在信令通道上，向所述用户终端发送RTC会话响应和所述目标媒体数据流中的第一数据流，所述RTC会话响应携带有媒体服务单元的接口信息，所述媒体服务单元的接口信息用于建立媒体数据通道，所述媒体数据通道用于传输第二数据流，所述第二数据流包括所述目标媒体数据流中除所述第一数据流之外的数据流，所述第一数据流在所述目标媒体数据流中的时序早于所示第二数据流在所述目标媒体数据流中的时序。

Images