CN117896369A

CN117896369A - 文件传输系统、文件传输方法、人机交互方法及机器人

Info

Publication number: CN117896369A
Application number: CN202311719682.7A
Authority: CN
Inventors: 王雄; 蒋时涛
Original assignee: Shenzhen Ubtech Technology Co ltd; Shenzhen Youbihang Technology Co ltd
Current assignee: Shenzhen Ubtech Technology Co ltd; Shenzhen Youbihang Technology Co ltd
Priority date: 2023-12-14
Filing date: 2023-12-14
Publication date: 2024-04-16

Abstract

本申请适用于数据传输技术领域，提供了文件传输系统、文件传输方法、人机交互方法及机器人，该文件传输系统包括第一服务端和目标端；所述第一服务端用于获取能够确定第一设备信息的第一方法和/或第一接口，根据获取的所述第一方法和/或所述第一接口确定所述第一设备信息；所述目标端用于获取第二设备信息；所述第一服务端用于与所述目标端建立点对点连接，并通过所述点对点连接获取所述第二设备信息；所述目标端用于通过所述点对点连接获取所述第一设备信息；所述第一服务端和所述目标端用于根据所述第一设备信息和所述第二设备信息建立所述WebRTC连接。通过上述方法，能够提高用户的良好体验。

Description

文件传输系统、文件传输方法、人机交互方法及机器人

技术领域

本申请属于数据传输技术领域，尤其涉及文件传输系统、文件传输方法、人机交互方法、机器人及计算机可读存储介质。

背景技术

网页实时通信(Web Real-Time Communications，WebRTC)是一项实时通讯技术，它允许网络应用或者站点在不借助中间媒介的情况下，建立浏览器之间点对点(Peer-to-Peer)的连接，从而实现视频流和/或音频流等数据的传输。

现有的基于WebRTC的文件传输系统由两个客户端组成，即现有的基于WebRTC的文件传输系统能够实现在两个客户端之间的数据传输，但随着通信技术的发展，应用场景的增多，现有的文件传输系统难以满足用户对不同场景的应用需求。

发明内容

本申请实施例提供了文件传输系统、文件传输方法、人机交互方法及机器人，可以解决现有的文件传输系统所能够应用的场景较少的问题。

第一方面，本申请实施例提供了一种文件传输系统，所述文件传输系统包括第一服务端和目标端；

所述第一服务端用于获取能够确定第一设备信息的第一方法和/或第一接口，根据获取的所述第一方法和/或所述第一接口确定所述第一设备信息，其中，所述第一设备信息为：所述第一服务端与所述目标端建立WebRTC连接时所需的自身的设备信息；

所述目标端用于获取第二设备信息，其中，所述第二设备信息为：所述目标端与所述第一服务端建立所述WebRTC连接时所需的自身的设备信息；

所述第一服务端用于与所述目标端建立点对点连接，并通过所述点对点连接获取所述第二设备信息；

所述目标端用于通过所述点对点连接获取所述第一设备信息；

所述第一服务端和所述目标端用于根据所述第一设备信息和所述第二设备信息建立所述WebRTC连接。

第二方面，本申请实施例提供了一种文件传输方法，应用于第一服务端，所述文件传输方法包括：

获取能够确定所述第一服务端的设备信息的第一方法和/或第一接口；

根据获取的所述第一方法和/或所述第一接口确定第一设备信息，其中，所述第一设备信息为：所述第一服务端与目标端建立WebRTC连接时所需的自身的设备信息；

与所述目标端建立点对点连接，并通过所述点对点连接获取第二设备信息，所述第二设备信息为：所述目标端与所述第一服务端建立WebRTC连接时所需的自身的设备信息；

根据所述第一设备信息和所述第二设备信息建立其自身与所述目标端的所述WebRTC连接。

第三方面，本申请实施例提供了一种文件传输方法，应用于目标端，所述目标端为第二服务端或第一客户端，所述文件传输方法包括：

获取第二设备信息，其中，所述第二设备信息为：所述目标端与第一服务端建立WebRTC连接时所需的自身的设备信息；

与所述第一服务端建立点对点连接，通过所述点对点连接获取第一设备信息，所述第一设备信息为：所述第一服务端与所述目标端建立所述WebRTC连接时所需的自身的设备信息；

根据所述第一设备信息和所述第二设备信息建立其自身与所述第一服务端的所述WebRTC连接。

第四方面，本申请实施例提供了一种人机交互方法，应用于机器人，所述机器人包括第二客户端和第三服务端，所述人机交互方法包括：

所述第二客户端获取输入的数据，所述输入的数据包括：语音数据和/或文本数据；在判断出本次的输入已结束且需要唤醒摄像头的情况下，唤醒所述机器人的摄像头进行数据的采集并获取所述摄像头采集的音视频数据；获取第三设备信息，所述第三设备信息为：所述第二客户端与所述第三服务端建立WebRTC连接时所需的设备信息；与所述第三服务端建立WebSocket连接，通过所述WebSocket连接向所述第三服务端发送所述第三设备信息；

所述第三服务端获取能够确定所述第三服务端的设备信息的第三方法和/或第三接口；根据所述第三方法和/或所述第三接口确定第四设备信息，其中，所述第四设备信息为：所述第三服务端与所述第二客户端建立所述WebRTC连接时所需的设备信息；与所述第二客户端建立所述WebSocket连接，通过所述WebSocket连接向所述第二客户端发送所述第四设备信息；

所述第二客户端和所述第三服务端根据所述第三设备信息和所述第四设备信息建立所述WebRTC连接；

所述第二客户端通过所述WebRTC连接，将获取的所述音视频数据通过所述WebRTC连接向所述第三服务端发送；

所述第三服务端对所述音视频数据进行处理并响应处理后的结果。

第五方面，本申请实施例提供了一种机器人，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第二方面或第三方面或第四方面所述的方法。

第六方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如第二方面或第三方面或第四方面所述的方法。

第七方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在机器人上运行时，使得机器人执行上述第二方面或第三方面或第四方面所述的方法。

本申请实施例与现有技术相比存在的有益效果是：

在本申请实施例中，由于提供的文件传输系统包括第一服务端，即该文件传输系统包括至少一个服务端，而服务端具有业务逻辑处理的能力，因此，当采用本申请实施例提供的文件传输系统进行数据传输时，不仅能够实现数据的实时传输，还能够实现对数据的业务逻辑处理。即，由于本申请实施例的文件传输系统所具有的功能更强大，因此，其能够满足用户在更多场景类型下的应用需求，从而能够提高用户的良好体验。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1是本申请一实施例提供的一种文件传输系统的结构示意图；

图2是本申请一实施例提供的一种第一服务端与目标端的交互示意图；

图3是本申请一实施例提供的一种文件传输方法的流程示意图；

图4是本申请一实施例提供的另一种文件传输方法的流程示意图；

图5是本申请另一实施例提供的一种机器人的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。

在实际生活中，不同用户之间可能存在数据传输的需求，例如，存在视频数据传输的需求，存在语音数据传输的需求等。

为了满足用户的数据传输需求，通常在两个客户端之间建立WebRTC连接，通过建立的WebRTC连接，可在两个客户端之间实现双向实时传播。例如，通过建立的WebRTC连接，能够满足两个用户在会话场景或视频场景对数据传输的需求。

但随着通信技术的发展，用户会产生新的需求。例如，当用户处于人机交互场景时，用户可能希望得到机器人对流媒体文件的业务逻辑处理后的结果，此时，在客户端之间建立的WebRTC连接将不能满足用户的需求，因为在客户端之间建立的WebRTC连接只能实现双向实时传播，并不具有业务逻辑处理的能力。

为了具备业务逻辑处理的能力，本申请实施例提供了一种新的文件传输系统。在该文件传输系统所包括的两端中，至少有一端为服务端，即在至少包括一个服务端的两端之间建立WebRTC连接。由于服务端具有业务逻辑处理的能力，因此，本申请实施例所提供的文件传输系统具备业务逻辑处理的能力。

下面结合附图对本申请实施例提供的文件传输系统进行描述。

图1示出了本申请实施例提供的一种文件传输系统的结构示意图，该文件传输系统1包括第一服务端11和目标端12，其中：

本申请实施例提供的第一服务端11用于获取能够确定第一设备信息的第一方法和/或第一接口，根据获取的上述第一方法和/或上述第一接口确定上述第一设备信息，其中，上述第一设备信息为：上述第一服务端11与上述目标端12建立WebRTC连接时所需的自身的设备信息。

其中，第一服务端11为一种服务端，本申请实施例中，为了便于与后续出现的服务端进行区分，故将此处的服务端命名为第一服务端。

其中，WebRTC能够提供音视频传输、编解码、降噪等服务，实现这些服务的应用程序编程接口(Application Programming Interface，API)是基于C++语言编写的。由于WebRTC提供的对外API是基于C++语言编写的，因此，其他服务模块若需要使用WebRTC的相关服务，则需要基于该WebRTC提供的API进行服务调用。

当第一服务端11采用C++语言编写时，该第一服务端11能够直接基于WebRTC提供的API进行相关服务的调用，此时，上述的第一方法(或第一接口)为能够识别C++语言的方法(或接口)，这样，通过第一方法(或第一接口)能够识别第一服务端11的服务调用需求，并根据识别结果调用与服务调用需求对应的WebRTC的服务，进而获取第一设备信息，即实现同一语言的服务调用；而当第一服务端11不是采用C++语言编写时，该第一服务端11不能够直接基于WebRTC提供的API进行相关服务的调用，此时，上述的第一方法(或第一接口)为能够识别C++语言和该第一服务端11本身的编写语言的方法或接口，这样，通过第一方法(或第一接口)对第一服务端11的服务调用需求对应的语言进行识别，以及，对WebRTC提供的API的语言进行识别，能够准确调用第一服务端11所需要调用的WebRTC的服务，进而获取第一设备信息，即能够实现跨语言的服务调用。

其中，第一设备信息为第一服务端11与目标端12建立WebRTC连接时所需的第一服务端11的设备信息，其包括会话描述协议(Session Description Protocal，SDP)，该SDP主要用于两个会话开始之前的媒体协商，用于建立会话，该第一设备信息还可以包括交互式连接创建(Interactive Connectivity Establishment，ICE)，该ICE为用于进行透传时所需的信息。

本申请实施例提供的目标端12用于获取第二设备信息，其中，上述第二设备信息为：上述目标端12与上述第一服务端11建立上述WebRTC连接时所需的自身的设备信息。

其中，该目标端12可以为客户端也可以为服务端，但无论是客户端还是服务端，均需要获取建立WebRTC连接时所需的自身的设备信息，即获取第二设备信息。

在第一服务端11和目标端12均获取到相关的设备信息之后，该第一服务端11与该目标端12将建立点对点连接，并通过该点对点连接获取该第二设备信息，而该目标端12则通过该点对点连接获取该第一设备信息。

具体地，第一服务端11和目标端12分别作为一个本地点(即本地peer)，该两个本地点通过同一个协议实现其自身的设备信息的交换，即通过点对点连接的方式实现其自身的设备信息的交换。

当第一服务端11和目标端12分别获取到对方的设备信息之后，该第一服务端11和该目标端12可根据该第一设备信息和该第二设备信息建立WebRTC连接。

由于第一设备信息是第一服务端11与目标端12建立WebRTC连接所需的设备信息，而第二设备信息是目标端12与第一服务端11建立WebRTC连接所需的设备信息，因此，当第一服务端11和目标端12均获取到第一设备信息和第二设备信息之后，将能够在该第一服务端11和目标端12之间建立WebRTC连接。

在本申请实施例中，由于提供的文件传输系统包括第一服务端11，即该文件传输系统包括至少一个服务端，而服务端具有业务逻辑处理的能力，因此，当采用本申请实施例提供的文件传输系统进行数据传输时，不仅能够实现数据的实时传输，还能够实现对数据的业务逻辑处理。即，由于本申请实施例的文件传输系统所具有的功能更强大，因此，其能够满足用户在更多场景类型下的应用需求，从而能够提高用户的良好体验。

在一些实施例中，本申请实施例提供的目标端12可以为客户端(即下述的第一客户端)也可以为服务端(即下述的第二服务端)，而客户端和服务端在获取设备信息时其方法是不同的，即：上述目标端12用于获取第二设备信息，包括：

在上述目标端12为第二服务端的情况下，上述第二服务端用于获取能够确定第二设备信息的第二方法和/或第二接口，根据获取的上述第二方法和/或上述第一接口获取上述第二设备信息。

在上述目标端12为第一客户端的情况下，上述第一客户端用于获取上述第二设备信息。

其中，第二服务端为与第一服务端不同的服务端(即第二服务端不是客户端)，故当目标端12为第二服务端时，该目标端12在获取第二设备信息时也采用与第一服务端获取第一设备信息类似的方法，此处不再赘述。

需要指出的是，当该目标端12为客户端(如浏览器或网页)时，由于WebRTC的开发者预先基于脚本语言(JavaScript，JS)对WebRTC的API进行了封装，而该JS语言为前端的语言，因此，作为前端的客户端(即第一客户端)能够直接基于JS语言的方法和/或接口实现对WebRTC的服务的调用，进而获取该第一客户端的用于建立WebRTC连接的设备信息。

本申请实施例中，由于客户端和服务端在获取其自身的设备信息时所采取的策略是不同的，因此，根据目标端12是客户端还是服务端选择不同的策略获取其自身的设备信息，能够准确获取到对应的设备信息。

在一些实施例中，考虑到Java语言更擅长于实现业务逻辑处理，而服务端通常需要实现较多的业务逻辑处理，因此，服务端通常采用Java语言实现。当第一服务端11采用Java语言开发时，上述第一服务端11用于获取能够确定第一设备信息的第一方法和/或第一接口，包括：

在上述第一服务端所采用的语言为Java语言的情况下，第一服务端用于通过JNI或JNA的方式获取能够确定第一设备信息的第一方法和/或第一接口。

其中，JNI(Java Native Interface)是Java提供的一个功能强大的框架，其允许Java应用程序调用底层的C或C++代码。

其中，JNA(Java Native Access)提供一组Java工具类用于在运行期间动态访问系统本地库(native library：如Window的dll)而不需要编写任何Native或JNI代码。

本申请实施例，考虑到通过JNI或JNA能够获取到不仅能够识别C++语言还能够识别Java语言的方法和/或接口，而第一服务端11采用Java语言开发，且WebRTC采用C++语言开发，因此，通过上述方式，能够保证获取到的第一方法和/或第一接口是可以获取到第一设备信息的方法和/或接口，即能够保证获取的第一方法和/或第一接口的准确度。

在一些实施例中，第一服务端11也可能采用其他语言进行开发，此时，只需要获取能够同时识别该第一服务端11的开发语言以及WebRTC的开发语言(即C++语言)的方法和/或接口即可。如在第一服务端11采用Python语言开发时，可通过ctypes或者extension的方式获取上述的第一方法和/或第一接口，再采用获取的第一方法和/或第一接口获取第一设备信息。其中，ctypes是Python的外部函数库，它提供了与C语言兼容的数据类型，并允许调用DLL或共享库中的函数；而Python的extension是一种方法，是可以在Python中使用其他语言编写的代码模块。即在Python语言开发时，无论是ctypes还是extension，都能够获取到同时识别该第一服务端11的开发语言(即Python语言)以及WebRTC的开发语言(即C++语言)。当然，在实际情况中，若第一服务端11的开发语言既不是Java语言也不是Python语言，则该第一服务端11也是先获取能够同时识别该第一服务端11的开发语言以及WebRTC的开发语言(即C++语言)的方法和/或接口，再根据获取的方法和/或接口获取第一设备信息即可，此处不再赘述。

在一些实施例中，在第一服务端11和目标端12建立WebRTC连接之后，该第一服务端11和目标端12基于该WebRTC连接进行文本文件和/或非文本文件的传输。

其中，这里的非文本文件包括音频文件和/或视频文件。

由于WebRTC本身能够提供音视频等数据的传输服务，因此，在第一服务端11与目标端12建立WebRTC连接之后，可利用该WebRTC连接在第一服务端11和目标端12之间进行各种类型文件的传输，从而在包括至少一个服务端的文件传输系统内实现了数据的实时传输。例如，考虑到WebRTC连接中的onDataChannel通道只限定了单次传输的数据量，但并不限定可传输的文件类型，因此，可通过onDataChannel通道进行各种类型的文件的传输。

需要指出的是，由于onDataChannel通道限定了单次传输的数据量，而视频文件所包含的数据通常较多，因此，在待传输的视频文件所包含的数据的数据量大于onDataChannel通道单次所能够传输的最大的数据量的情况下，将待传输的视频文件所包含的数据截断为多个数据段，并保证每个数据段对应的数据量小于或等于onDataChannel通道单次所能够传输的最大的数据量，再采用该onDataChannel通道分别传输各个数据段。

在一些实施例中，考虑到WebRTC提供了多个用于传输数据的通路，因此，为了提高通路的利用率以及提高数据传输的速率，第一服务端11和目标端12可根据待传输文件的类型选择对应的通路进行传输。即：

上述第一服务端11还用于：通过建立的上述WebRTC连接的通道中的目标轨道将视频文件向上述目标端12发送，和/或，通过建立的上述WebRTC连接的通道中的目标通道将除了上述视频文件之外的文件向上述目标端12发送，其中，上述目标轨道为用于传输视频文件的轨道，上述目标通道为能够传输任何类型文件的通道；

和/或，

上述目标端12还用于：通过建立的上述WebRTC连接的通道中的目标轨道将视频文件向上述第一服务端11发送，和/或，通过建立的上述WebRTC连接的通道中的目标通道将除了上述视频文件之外的文件向上述第一服务端11发送。

其中，上述的目标轨道是指：在WebRTC连接中只能用于传输视频文件的轨道。例如，由于onTrack规定了其能够传输的数据的格式为视频文件的格式，且数据经过该onTrack传输时，还会对传输的数据进行识别编解码的处理，因此，可采用onTrack进行视频文件的传输。具体地，在通过onTrack进行视频文件的传输时，将接收到的每帧yuv格式的数据通过移位等操作转为字节数组(即byte数组)，待会话结束后再通过动态图像专家组(Fast Forward Moving Picture Experts Group，FFmpeg)算法或rgb算法或bgr算法，对各个byte数组中的yuv格式的数据进行识别，以将各个byte数组中的数据转为所需格式的视频文件。其中，选择何种算法转为视频文件与接收端所需的视频文件的图像格式有关，例如，若接收端(如第一服务端11或目标端12)所需的视频文件的图像格式为“rgb”格式，则选择rgb算法将各个byte数组中的yuv格式的数据转为该rgb格式的视频文件。

其中，目标通道可以为WebRTC连接中的onDataChannel通道。具体地，当采用onDataChannel通道传输音频文件时，可通过该onDataChannel通道中预设的方法，将该音频文件对应的数据流转为对应的buffer数组，再将该buffer数组中的数据转为所需格式的文件，以便后续进一步的处理。例如，假设待传输的音频文件为脉冲编码调制(PulseCodeModulation，PCM)格式的音频文件，接收端所需的格式为动态影像专家压缩标准音频层面3(Moving Picture Experts Group Audio Layer III，MP3)格式的音频文件，则采用onDataChannel通道传输时将会把PCM格式的音频文件转为MP3格式的音频文件。

本申请实施例中，由于根据待传输文件的类型选择不同的通路进行传输，即根据待传输文件的类型进行传输分流，因此，有利于提高待传输文件的传输效率。

在一些实施例中，本申请实施例提供的点对点连接可以为以下的任一种连接：

WebSocket连接、中继穿透NAT:STUN的扩展(Traversal Using Relays aroundNAT:Relay Extensions to Session Traversal Utilities for NAT，TURN)连接和NAT会话穿越应用程序(Session Traversal Utilities for NAT，STUN)连接。

其中，WebSocket是HTML5下的一种新的协议，它实现了浏览器与服务器全双工通信，能更好地节省服务器资源和带宽并达到实时通讯的目的。

当然，在实际情况中，还可以通过其他方式建立第一服务端11和目标端12之间的点对点的连接，此处不再赘述。

在一些实施例中，为了进一步对待传输的数据进行传输分流，在上述点对点连接为上述WebSocket连接的情况下，第一服务端11和目标端12可通过该WebSocket连接进行文本文件的传输，即：

上述第一服务端11还用于：通过上述WebSocket连接将文本文件向上述目标端12发送。

和/或，

上述目标端12还用于：通过上述WebSocket连接将文本文件向上述第一服务端11发送。

具体地，可通过WebSocket连接进行文本文件(即纯文本的文件)的传输，而通过onDataChannel通道进行非文本文件的传输；或者，通过WebSocket连接进行文本文件(即纯文本的文件)的传输，通过onDataChannel通道进行音频文件的传输，通过onTrack进行视频文件的传输。

本申请实施例中，由于WebSocket连接更适合于进行文本、信令等类型的数据的传输，因此，第一服务端11和目标端12通过WebSocket连接传输文本文件，有利于提高接收端(如第一服务端11或目标端12)得到准确的文本文件的概率。此外，由于onDataChannel通道和onTrack均为与WebSocket连接不同的通路，因此，当还采用onDataChannel通道和/或onTrack进行非文本文件的传输而采用WebSocket连接进行文本文件的传输，即采用不同的通路传输文本文件和非文本文件时，能够极大提高文件的传输效率。

在一些实施例中，为了进一步提高第一服务端11和目标端12通信的安全性，则该第一服务端11和该目标端12需要将其自身的设备信息(即第一设备信息和第二设备信息均存入第三方，之后再允许该第一服务端11和该目标端12建立WebRTC连接。

例如，当点对点连接为WebSocket连接的情况下，第一服务端11将第一设备信息向TURN或STUN发送，而目标端12也将第二设备信息向TURN或STUN发送。由于TURN或STUN均接收到第一服务端11和目标端12发送的设备信息，因此，将判定该第一服务端11和该目标端12均为可信的，从而保证后续建立的WebRTC连接的可靠性。

为了更清楚地描述本申请提供的文件传输系统，下面结合图2进行描述。在图2中，客户端相当于上述的目标端12，服务端相当于上述的第一服务端11，且该服务端的开发语言为Java语言。假设客户端和服务端建立的点对点连接为WebSocket连接，且该服务端从JNI获取第一方法和/或第一接口，则：

1、服务端在与客户端建立WebSocket之前，通过JNI方式获取用于确定第一设备信息的第一方法和/或第一接口，并根据该第一方法和/或第一接口获取其自身的设备信息，即获取上述的第一设备信息。

2、服务端将获取的第一设备信息向WebSocket发送，若此时该WebSocket已接收到客户端发送的第二设备信息，则将该第二设备信息发送给该服务端，否则，等待接收到客户端发送的第二设备信息之后，再将该第二设备信息发送给该服务端。

3、客户端通过JS语言获取其自身的设备信息(即第二设备信息)，并将该第二设备信息向WebSocket发送，若此时该WebSocket已接收到服务端发送的第一设备信息，则将该第一设备信息发送给该客户端，否则，等待接收到服务端发送的第一设备信息之后，再将该第一设备信息发送给该客户端。需要指出的是，该步骤3可以在上述的步骤1和/或2之前执行，也可以在步骤1和/或2之后执行，此处不作限定。

4、服务端向STUN或TURN发送第一设备信息，若此时该STUN或TURN已接收到客户端发送的第二设备信息，则将该第二设备信息发送给该服务端，否则，等待接收到客户端发送的第二设备信息之后，再将该第二设备信息发送给该服务端。

5、客户端将第二设备信息向STUN或TURN发送，若此时该STUN或TURN已接收到服务端发送的第一设备信息，则将该第一设备信息发送给该客户端，否则，等待接收到服务端发送的第一设备信息之后，再将该第一设备信息发送给该客户端。需要指出的是，该步骤5可以在上述的步骤4之前执行，也可以在步骤4之后执行，此处不作限定。

6、当客户端和服务端均获取到对方的设备信息且均将自身的设备信息存入STUN或TURN之后，该客户端和服务端可建立WebRTC连接，并可基于该WebRTC连接进行数据传输。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对应于上述实施例所描述的文件传输系统，图3示出了本申请实施例提供的一种文件传输方法的流程示意图，该文件传输方法应用于第一服务端，详述如下：

S31，获取能够确定上述第一服务端的设备信息的第一方法和/或第一接口。

S32，根据获取的上述第一方法和/或上述第一接口确定第一设备信息，其中，上述第一设备信息为：上述第一服务端与目标端建立WebRTC连接时所需的自身的设备信息。

S33，与上述目标端建立点对点连接，并通过上述点对点连接获取第二设备信息，上述第二设备信息为：上述目标端与上述第一服务端建立WebRTC连接时所需的自身的设备信息。

S34，根据上述第一设备信息和上述第二设备信息建立其自身与上述目标端的上述WebRTC连接。

由于该第一服务端即为上述文件传输系统中的第一服务端，因此，第一服务端在执行上述各个步骤时的相关描述可参看文件传输系统所对应的实施例，此处不再赘述。

对应于上述实施例所描述的文件传输系统，图4示出了本申请实施例提供的另一种文件传输方法的流程示意图，该文件传输方法应用于目标端，该目标端为第二服务端或第一客户端，详述如下：

S41，获取第二设备信息，其中，上述第二设备信息为：上述目标端与第一服务端建立WebRTC连接时所需的自身的设备信息。

S42，与上述第一服务端建立点对点连接，通过上述点对点连接获取第一设备信息，上述第一设备信息为：上述第一服务端与上述目标端建立上述WebRTC连接时所需的自身的设备信息。

S43，根据上述第一设备信息和上述第二设备信息建立其自身与上述第一服务端的上述WebRTC连接。

由于该目标端即为上述文件传输系统中的目标端，因此，该目标端在执行上述各个步骤时的相关描述可参看文件传输系统所对应的实施例，此处不再赘述。

在一些实施例中，考虑到人机交互场景中可采用本申请实施例提供的文件传输系统进行相关数据的传输，该人机交互方法应用于机器人，该机器人包括第二客户端和第三服务端，上述人机交互方法包括：

上述第二客户端获取输入的数据，上述输入的数据包括：语音数据和/或文本数据；在判断出本次的输入已结束且需要唤醒摄像头的情况下，唤醒上述机器人的摄像头进行数据的采集并获取上述摄像头采集的音视频数据；获取第三设备信息，上述第三设备信息为：上述第二客户端与上述第三服务端建立WebRTC连接时所需的设备信息；与上述第三服务端建立WebSocket连接，通过上述WebSocket连接向上述第三服务端发送上述第三设备信息。

上述第三服务端获取能够确定上述第三服务端的设备信息的第三方法和/或第三接口；根据上述第三方法和/或上述第三接口确定第四设备信息，其中，上述第四设备信息为：上述第三服务端与上述第二客户端建立上述WebRTC连接时所需的设备信息；与上述第二客户端建立上述WebSocket连接，通过上述WebSocket连接向上述第二客户端发送上述第四设备信息。

上述第二客户端和上述第三服务端根据上述第三设备信息和上述第四设备信息建立上述WebRTC连接。

上述第二客户端通过上述WebRTC连接，将获取的上述音视频数据通过上述WebRTC连接向上述第三服务端发送。

上述第三服务端对上述音视频数据进行处理并响应处理后的结果。

其中，这里的第二客户端可为机器人上的应用或浏览器，第三服务端可为用于处理涉及该机器人的数据的服务器。

其中，上述语音数据和文本数据可为用户输入到机器人上的数据，例如，用户向机器人喊“请启动摄像头”，则该第二客户端将获取到“请启动摄像头”对应的语音数据。当然，在实际情况中，上述语音数据和文本数据也可为其他设备发送到机器人上的数据。

本申请实施例中，第二客户端在获取到输入的数据后，若判断出该数据为语音数据，则可获取该语音数据对应的音素序列；若判断出该数据为文本数据，则可根据文本到语音(Text To Speech，TTS)技术将该文本数据转换为对应的音素序列，再根据自然语言处理(Natural Language Processing，NLP)算法对得到的音素序列进行分析，以判断本次的输入是否已结束。由于不同语句之间通常存在一定的时间间隔，因此，NLP可根据该特性判断本次的输入是否已结束。

在本申请实施例中，在判断本次的输入是否结束时，还对本次输入的数据进行语义分析，以判断用户的需求。若判断出用户需要启动该机器人的摄像头，则该第二客户端将唤醒该摄像头，以便该摄像头进行音视频数据的采集。在该摄像头采集了音视频数据之后，将其采集的音视频数据发送给该第二客户端。

在第二客户端将其获取的音视频数据向第三服务端发送之前，该第二客户端还需要与第三服务端建立WebSocket连接以及WebRTC连接。在建立WebSocket连接后，依赖于该WebSocket连接，该第二客户端能够获取第三服务端的第四设备信息，而该第三服务端则能够获取第二客户端的第三设备信息。在第二客户端和第三服务端均获取到对方的设备信息之后，该第二客户端和该第三服务端能够建立WebRTC连接。

在建立WebRTC连接之后，第二客户端将会话开始标识和会话结束标识分别通过WebSocket连接向第三服务端发送，该第三服务端根据会话开始标识开始接收第二客户端通过WebRTC连接发送的音视频数据，以及，根据会话结束标识停止接收第二客户端通过WebRTC连接发送的音视频数据。

该第三服务端对接收的音视频数据进行处理，若判断出用户还需要知悉处理结果，则该第三服务端将处理结果发送给第二客户端。需要指出的是，若该处理结果为文本信息，则该第三服务端可通过WebSocket连接向第二客户端发送，若该处理结果为非文本信息，则该第三服务端WebRTC连接向第二客户端发送。

在本申请实施例中，由于第二客户端和第三服务端建立WebRTC连接后，第二客户端和第三服务端能够进行实时的多种类型的文件的传输，同时，由于第三服务端具备业务逻辑处理能力，因此，第二客户端能够获取到第三服务端对其发送到第三服务端的数据的处理结果，从而能够扩大该第二客户端和第三服务端所能够应用的场景，进而能够极大提高用户的良好体验。

图5为本申请一实施例提供的一种机器人的结构示意图。如图5所示，该实施例的机器人5包括：至少一个处理器50(图5中仅示出一个处理器)、存储器51以及存储在所述存储器51中并可在所述至少一个处理器50上运行的计算机程序52，所述处理器50执行所述计算机程序52时实现上述任意各个方法实施例中的步骤。

所述机器人5可以是人型机器人或机械臂等可移动的设备。该机器人可包括但不仅限于，处理器50、存储器51。本领域技术人员可以理解，图5仅仅是机器人5的举例，并不构成对机器人5的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。

所称处理器50可以是中央处理单元(Central Processing Unit，CPU)，该处理器50还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器51在一些实施例中可以是所述机器人5的内部存储单元，例如机器人5的硬盘或内存。所述存储器51在另一些实施例中也可以是所述机器人5的外部存储设备，例如所述机器人5上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器51还可以既包括所述机器人5的内部存储单元也包括外部存储设备。所述存储器51用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器51还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在机器人上运行时，使得机器人执行时可实现上述各个方法实施例中的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/机器人的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

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

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/网络设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/网络设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims

1.一种文件传输系统，其特征在于，所述文件传输系统包括第一服务端和目标端；

2.如权利要求1所述的文件传输系统，其特征在于，所述目标端用于获取第二设备信息，包括：

在所述目标端为第二服务端的情况下，所述第二服务端用于获取能够确定第二设备信息的第二方法和/或第二接口，根据获取的所述第二方法和/或所述第一接口获取所述第二设备信息；

在所述目标端为第一客户端的情况下，所述第一客户端用于获取所述第二设备信息。

3.如权利要求1所述的文件传输系统，其特征在于，所述第一服务端用于获取能够确定第一设备信息的第一方法和/或第一接口，包括：

在所述第一服务端所采用的语言为Java语言的情况下，第一服务端用于通过JNI或JNA的方式获取能够确定第一设备信息的第一方法和/或第一接口。

4.如权利要求1所述的文件传输系统，其特征在于，

所述第一服务端还用于：通过建立的所述WebRTC连接的通道中的目标轨道将视频文件向所述目标端发送，和/或，通过建立的所述WebRTC连接的通道中的目标通道将除了所述视频文件之外的文件向所述目标端发送，其中，所述目标轨道为用于传输视频文件的轨道，所述目标通道为能够传输任何类型文件的通道；

和/或，

所述目标端还用于：通过建立的所述WebRTC连接的通道中的目标轨道将视频文件向所述第一服务端发送，和/或，通过建立的所述WebRTC连接的通道中的目标通道将除了所述视频文件之外的文件向所述第一服务端发送。

5.如权利要求1至4任一项所述的文件传输系统，其特征在于，所述点对点连接为WebSocket连接或TURN连接或STUN连接。

6.如权利要求5所述的文件传输系统，其特征在于，在所述点对点连接为所述WebSocket连接的情况下，

所述第一服务端还用于：通过所述WebSocket连接将文本文件向所述目标端发送；

和/或，

所述目标端还用于：通过所述WebSocket连接将文本文件向所述第一服务端发送。

7.一种文件传输方法，其特征在于，应用于第一服务端，所述文件传输方法包括：

8.一种文件传输方法，其特征在于，应用于目标端，所述目标端为第二服务端或第一客户端，所述文件传输方法包括：

9.一种人机交互方法，其特征在于，应用于机器人，所述机器人包括第二客户端和第三服务端，所述人机交互方法包括：

10.一种机器人，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求7至9任一项所述的方法。

11.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求7至9任一项所述的方法。