媒体数据流的流转方法、系统、设备及计算机可读介质与流程

1.本技术涉及媒体数据流的流转，尤其涉及多个基于rtos内核的多媒体终端之间的数据流的实时安全流转的方法、系统、装置及计算机可读介质。


背景技术：

2.aiot是人工智能技术(ai)与物联网(iot)在实际应用中的落地融合。ai、iot“一体化”之后，“人工智能”逐渐向“应用智能”发展。在万物智联的场景中，设备与设备间将互联互通，形成数据交互、共享的崭新生态。例如，aiot设备可包括嵌入或附接到日常事物(诸如建筑物、交通工具、包裹、娱乐设施等)的低功率设备，以提供对这些事物的附加水平的人工感官知觉。随着技术的发展，基于无线网络的多个低功耗aiot设备之间的数据互传功能在物联网领域得到广泛的应用。
3.在现有技术中，低功耗aiot设备之间的数据互传功能一般通过可信pin码来实现。然而，采用可信pin码传输仍然存在着诸如以下的问题：1)无法保证数据传输的安全性；以及2)容易通过抓包进行信息破解，无法完全保证目标设备的可信性；等等。换言之，现有技术中采取pin码传输的策略不可避免地带来隐患，因为采取pin码传输的策略可能危及所传输的信息的安全性，并且也无法确保目标设备是可信的。
4.由此，当基于无线网络的多个低功耗aiot设备之间的数据互传功能用在音频播放设备之间的数据跨屏流转中，如何保证数据传输的安全性成为关键。
5.因此，需要一种高效且安全的数据互传方案来用于低功耗aiot设备(诸如，带屏的音频播放设备等)之间的数据跨设备流转。


技术实现要素：

6.根据本发明的一方面，描述了一种媒体数据流的流转方法，包括：由源设备向目标设备发送媒体的数据流的流转请求；由源设备对从目标设备接收到的数字证书和数字签名进行解析以对目标设备进行认证；在认证成功的情况下，由源设备使用第一加密算法生成第一密钥；由源设备将经第二加密算法加密的第一密钥发送到目标设备；目标设备从源设备接收经第二加密算法加密的第一密钥，使用第二加密算法对第一密钥进行解析，并根据解析结果向源设备返回密钥协商结果；以及在密钥协商结果是协商成功的情况下，在源设备与目标设备之间使用第一密钥进行通信。
7.在一实施例中，由源设备对从目标设备接收到的数字证书和数字签名进行解析以对目标设备进行认证进一步包括：目标设备在接收到流转请求之后，向源设备发送数字证书和数字签名；以及由源设备对接收到的数字证书和数字签名进行解析，以对目标设备进行认证。
8.在一实施例中，源设备对接收到的数字证书和数字签名进行解析进一步包括：对数字签名进行解析，并利用hash函数计算摘要；将计算出的摘要与先前存储的服务器的摘要进行比较；以及如果计算出的摘要与先前存储的服务器的摘要匹配，则认证成功。
9.在一实施例中，第一加密算法是对称加密算法，而第一密钥是对称密钥。
10.在一实施例中，第二加密算法是非对称加密算法，源设备使用目标设备的公钥对第一密钥进行加密，目标设备使用自己的私钥对第一密钥进行解析。
11.在一实施例中，方法进一步包括：在接收到来自源设备的经第二加密算法加密的第一密钥之后，目标设备对经第二加密算法加密的第一密钥进行解析；以及如果解析成功，则目标设备向源设备返回解析成功的协商结果。
12.在该实施例中，方法进一步包括：在发送与媒体相关的流转数据包之前，由源设备向目标设备发送使用第一密钥加密的目标设备相关信息请求帧；以及响应于目标设备相关信息请求帧，由目标设备向源设备发送使用第一密钥加密的目标设备相关信息响应帧。
13.在一实施例中，方法进一步包括：基于对接收到的目标设备相关信息响应帧的解析，由源设备确定目标设备是否满足数据流的流转的条件；以及如果满足数据流的流转的条件，则由源设备向目标设备发送流转数据包。
14.在一实施例中，确定目标设备是否满足数据流的流转的条件包括确定以下各项中的一项或多项：目标设备是否具有播放媒体的能力；目标设备是否已安装用于播放媒体的应用；以及目标设备是否利用hash函数进行完整性检测。
15.在一实施例中，流转数据包是用第一密钥加密的。
16.在一实施例中，目标设备相关信息请求帧和目标设备相关信息响应帧中的任一者包括以下各项中的一项或多项：版本号；消息类型；加密指示符；完整性检测指示符；压缩指示符；扬声器指示符；屏幕存在性指示符；剩余flash指示符；剩余内存指示符；电量信息；格式支持列表；应用包安装指示符；保留位；填充位；超时指示符；以及时间戳。
17.在一实施例中，流转数据包包括以下各项中的一项或多项：版本号；消息类型；加密指示符；完整性检测指示符；压缩指示符；应用包安装指示符；保留位；填充位；超时指示符；以及时间戳。
18.在一实施例中，方法进一步包括：目标设备对接收到的流转数据包进行解析，并基于经解析的流转数据包来进行播放器重建，播放器重建包括安装用于播放媒体的应用；如果重建成功，则目标设备进行媒体的播放并向源设备返回重建成功指示；以及如果重建失败，则目标设备关闭流转操作链路。
19.在一实施例中，方法进一步包括：如果接收到来自目标设备的重建成功指示，则源设备暂停对媒体的播放；以及如果未接收到来自目标设备的重建成功指示，则源设备结束流转操作。
20.在一实施例中，源设备和目标设备是aiot智能设备。
21.根据本发明的另一方面，描述了一种媒体数据流的流转系统，包括：源设备，源设备被配置成：向目标设备发送流转请求；从所述目标设备接收数字证书和数字签名以对目标设备进行认证；在认证成功的情况下，使用第一加密算法生成第一密钥；以及将经第二加密算法加密的第一密钥发送到目标设备；以及目标设备，目标设备被配置成：从源设备接收流转请求；向源设备发送数字证书和数字签名以供源设备进行认证；从源设备接收经第二加密算法加密的第一密钥，使用第二加密算法对第一密钥进行解析，并根据解析结果向源设备返回密钥协商结果，其中在密钥协商结果是协商成功的情况下，源设备与目标设备之间的通信通过使用第一密钥来进行。
22.在一实施例中，第一加密算法是对称加密算法，而第一密钥是对称密钥。
23.在一实施例中，第二加密算法是非对称加密算法，源设备使用目标设备的公钥对第一密钥进行加密，目标设备使用自己的私钥对第一密钥进行解析。
24.根据本发明的又一方面，描述了一种用于媒体的数据流的流转的设备，包括用于执行如上所述的方法的装置。
25.根据本发明的再一方面，描述了一种其上存储有指令的计算机可读介质，所述指令当由计算机处理器执行时使所述处理器执行如上所述的方法。
26.根据本发明的再又一方面，描述了一种发起媒体数据流的流转的方法，包括：向目标设备发送流转请求；从目标设备接收数字证书和数字签名以对目标设备进行认证；在认证成功的情况下，使用第一加密算法生成第一密钥；将经第二加密算法加密的第一密钥发送到目标设备；以及在目标设备返回协商成功的密钥协商结果的情况下，使用第一密钥来与目标设备进行通信。
27.根据本发明的另一方面，描述了一种接受媒体数据流的流转的方法，包括：从源设备接收流转请求；向源设备发送数字证书和数字签名以供源设备进行认证；从源设备接收经第二加密算法加密的第一密钥，使用第二加密算法对第一密钥进行解析，并根据解析结果向源设备返回密钥协商结果；以及在密钥协商结果是协商成功的情况下，使用第一密钥来与源设备进行通信。
28.根据本发明的再一方面，描述了一种发起媒体数据流的流转的设备，包括：用于向目标设备发送流转请求的装置；用于从目标设备接收数字证书和数字签名以对目标设备进行认证的装置；用于在认证成功的情况下，使用第一加密算法生成第一密钥的装置；用于将经第二加密算法加密的第一密钥发送到目标设备的装置；以及用于在另一设备返回协商成功的密钥协商结果的情况下，使用第一密钥来与目标设备进行通信的装置。
29.根据本发明的再又一方面，描述了一种接受媒体数据流的流转的设备，包括：用于从源设备接收流转请求的装置；用于向源设备发送数字证书和数字签名以供源设备进行认证的装置；用于从源设备接收经第二加密算法加密的第一密钥，使用第二加密算法对第一密钥进行解析，并根据解析结果向源设备返回密钥协商结果的装置；以及用于在密钥协商结果是协商成功的情况下，使用第一密钥来与源设备进行通信的装置。
30.利用本发明的技术方案，在多个低功耗aiot设备之间发起数据互传以实现媒体数据流的无缝流转时，应用了组合式密钥加密技术。这能够有效阻止传送的密钥被窃取，从而实现数据安全性的提升。
附图说明
31.在附图中(这些附图不一定是按比例绘制的)，同样的数字可描述不同视图中的类似组件。具有不同的字母后缀的相同的数字可表示类似组件的不同实例。在所附附图的图中通过示例的方式而非限制性地图示出一些实施例，其中：
32.图1例示了涉及可信pin码传输的媒体的数据流的流转的现有技术方案
33.图2例示了根据本发明实施例的媒体数据流的流转方法
34.图3例示了根据本发明另一实施例的媒体数据流的流转方法。
35.图4例示了根据本发明实施例的目标设备相关信息请求帧的结构。
36.图5例示了根据本发明实施例的目标设备相关信息响应帧的结构。
37.图6例示了根据本发明实施例的流送数据包的结构。
具体实施例
38.本发明实施例涉及通过结合对称加密技术和非对称加密技术来实现高效且安全的数据互传。具体而言，在本技术方案中，当在多个低功耗aiot设备之间发起数据互传以实现媒体数据流的无缝流转时，通过利用组合式密钥加密技术(例如，对称加密技术和非对称加密技术的组合)来实现数据安全性的提升。
39.本发明实施例中涉及的“对称加密技术/算法”是指加密和解密使用相同密钥的加密技术。具体而言，在使用对称加密技术的情景中，发送方和接收方使用相同的密钥，其中发送方在发送信息时使用一密钥进行加密，而接收方在接收到经加密信息之后使用相同的密钥进行解密。并且，在对称加密技术中，发送方和接收方共享的密钥被称为对称密钥。
40.本发明实施例中涉及的“非对称加密技术/算法”是指加密和解密使用不同密钥的加密技术，其中这一对不同的密钥(分别称为公钥和私钥)可称为密钥对。具体而言，在使用非对称加密算法的情景中，发送方在发送信息时使用密钥对中的一个密钥进行加密，而接收方在接收到经加密信息之后使用密钥对中的另一密钥进行解密。并且，在非对称加密技术中，密钥对中的一者被称为公钥，而密钥对的另一者被称为私钥。在一些实施例中，发送方可使用私钥进行加密，而接收方可使用公钥进行解密。在另一些实施例中，发送方可使用公钥进行加密，而接收方可使用私钥进行解密。
41.在一些实施例中，本发明实施例涉及数字证书和数字签名。数字证书是由权威机构ca证书授权中心发行且能被用来在因特网上进行身份验证的一种权威性电子文档。而数字签名是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术实现，其被用来鉴别数字信息。
42.在密码技术领域中，数字签名是由发送方使用hash函数来生成的。具体而言，通过对所发送的内容进行hash计算，从而得到所发送内容的摘要(digest)。然后，可通过专用的私钥对所生成的摘要进行加密，从而产生“数字签名”。发送方可将要发送的内容连同数字签名一起发送给接收方。
43.接收方在接收到来自发送方的数字签名之后，可采用公钥对该数字签名进行解密，从而获得发送方发送的摘要。接收方可采用与发送方相同的hash函数来对接收自发送方的内容进行摘要计算，并将计算出的摘要与经解密获得的摘要进行比较，来确保接收到的内容未被篡改。替代地，在一些实施例中，接收方也可通过将计算出的摘要与预先存储的服务器的摘要进行比较，来确保接收到的内容未被篡改。
44.在密码技术领域中，为了进一步确保通信的安全性，可由权威机构ca证书授权中心对将由接收方使用的公钥进行公证。具体而言，ca证书授权中心可用自己的私钥将由接收方使用的公钥进行加密，以生成“数字证书”。
45.如此，一旦接收方接收到来自发送方的数字证书，就可利用ca证书授权中心发行的公钥来对该数字证书进行解密，以获得在后续步骤用来对数字签名进行解密的公钥。
46.虽然以下结合对称加密技术和非对称加密技术对本发明实施例进行了描述，但是应当理解，本发明实施例也可结合任何其他合适的加密技术来实现。
47.本技术方案旨在实现多个例如低功耗aiot设备之间的数据互传功能。例如，在室内多aiot设备的场景中，用户可能需要将媒体播放从第一aiot设备切换到第二aiot设备。经由无线通信技术(诸如，wifi、以太网、局域网等)，通过利用本技术方案，用户可实现从第一aiot设备到第二aiot设备的媒体(诸如，音频、视频等等)播放的无缝流转。具体而言，正在播放媒体的第一aiot设备通过无线通信技术将对媒体的播放流转到第二aiot设备，并且在第二aiot设备成功接替第一aiot设备播放原本由其播放的媒体之后，该第一aiot设备播放终止对媒体的播放。
48.在一些实施例中，低功耗aiot设备可以是具有显示屏的设备，其中显示屏可以包括但不限于：led显示屏、crt显示屏、lcd显示屏、3d显示屏、电子墨水屏等等。替代地，在一些实施例中，低功耗aiot设备可以是不具备显示屏的设备。
49.本发明实施例可以基于rtos(real-time operating system：实时操作系统)内核。但是，应当理解，本发明实施例并不限于rtos内核，而是可以基于任何合适的内核。
50.在本发明实施例中，源设备可以是发起媒体播放器数据流转的设备，而目标设备可以是接收媒体播放器数据的设备。并且，在本发明实施例中，媒体可包括但不限于：音频、视频、文字、图形、动画、图像、等等。
51.在以下描述中，出于解释的目的，阐述了许多特定的细节以提供对一些示例实施例的透彻理解。然而，对本领域技术人员将显而易见的是，在没有这些特定细节的情况下也可实施本公开。
52.图1例示了涉及可信pin码传输的媒体数据流的流转的现有技术方案。
53.如图1所例示，在采用可信pin码的带屏设备的场景中，源设备(诸如，源带屏设备)是正在工作的音乐播放器，其在步骤101对目标设备发出流转请求。目标设备收到源设备的流转请求后，在步骤102对其进行流转合法性判断。合法性判断可以是关于源设备的身份的认证或者任何其他出于安全性目的的认证。
54.若满足流转条件，则目标设备在步骤103向源设备返回同意接收音乐播放器的流转请求，并同时返回本设备的一个pin码。若不满足流转条件，则目标设备向源设备返回拒绝信息。
55.在步骤104，源设备在收到目标设备的同意应答以及目标设备的pin码之后，判断目标设备是否可信。若可信，则在步骤105源设备将音乐播放器上下文信息数据包发送给目标设备。若不可信，则源设备终止流转，意味着流转请求失败。
56.在步骤106，目标设备在接收到源设备发送的完整的数据包之后，向源设备回复确认消息，并根据数据包的内容重建播放器并开始继续播放。源设备在同步接收到目标设备的确认消息之后，暂停音乐播放。由此，实现从源设备到目标设备的数据流转。
57.在图1中例示了用于媒体的数据流的流转的现有技术方案。然而，采用可信pin码传输仍然存在着诸如缺点，诸如例如1)无法保证数据传输的安全性；以及2)容易通过抓包进行信息破解，无法完全保证目标设备的可信性；等等。因此，现有技术方案在数据传输的安全性上显然是令人担忧的。
58.图2例示了根据本技术实施例的用于媒体的数据流的无缝流转的方法。如图2所例示的，在步骤201，由源设备向目标设备发送媒体的数据流的流转请求。一旦接收到来自源设备的流转请求，在步骤202，由源设备对目标设备进行认证。
59.在步骤203，如果认证成功，则由源设备使用第一加密算法生成第一密钥，并且接着，在步骤204，由源设备将经第二加密算法加密的第一密钥发送到目标设备。在一些实施例中，第一加密算法可以是对称加密算法，而第一密钥可以是对称密钥。然而，应当理解，本文中的第一加密算法并不限于对称加密算法，而是可以是任何合适的加密算法。同样地，本文中的第一密钥并不限于对称密钥，而是可以是任何合适的密钥。另外，在一些实施例中，第二加密算法可以是非对称加密算法。然而，类似地，应当理解，本文中的第二加密算法并不限于非对称加密算法，而是可以是任何合适的加密算法。
60.接着，在步骤205，目标设备从源设备接收经第二加密算法加密的第一密钥，使用第二加密算法对第一密钥进行解析，并根据解析结果向源设备返回密钥协商结果。然后，在步骤206，在密钥协商结果是协商成功的情况下，在源设备与目标设备之间使用第一密钥进行通信。
61.图3例示了根据本技术另一实施例的用于媒体的数据流的无缝流转的方法。具体而言，图3中所例示的方法可以是图2中所例示的方法在特定情境下的更加具体的实施方式。
62.如图3所示，在步骤301，源设备在使用音乐播放器的过程中，向目标设备发出音乐播放器流转请求。在步骤302，目标设备在接收到来自源设备的流转请求之后，向源设备发送其预置的数字证书和数字签名，以进行身份认证。
63.在步骤303，源设备可对接收自目标设备的数字签名和数字证书进行解析。一旦获得经解析的数字签名和数字证书，源设备就可使用预置的公钥来解密数字签名。在一些实施例中，预置的公钥是由ca机构发行的，其中ca机构是指权威机构ca证书授权中心(certificate authority，简称ca)。
64.在一些实施例中，源设备通过可预置的公钥(即，ca机构发行的公钥)来解密数字签名。然后，源设备可通过采用与目标设备所使用相同的hash函数来计算摘要。
65.在步骤304，源设备可将计算出的摘要和服务器的摘要(例如，先前存储的摘要)进行比较，以确定目标设备是否可信，并向目标设备发送可信性认证结果。若比较结果相同，则认证成功，认为目标设备可信，跳转至步骤305；否则，认证失败，则跳转至步骤323。
66.接下来，在步骤305，源设备生成对称密钥，并在步骤306使用目标设备的公钥对该对称密钥进行加密。在一些实施例中，该对称密钥将被用来对后续通信的内容进行解密，以实现安全性提升。在步骤307，源设备将加密后的对称密钥发送给目标设备。在一些实施例中，对称密钥是通过非对称加密算法来加密的。但是，应当理解，在本发明实施例中，对称密钥也可通过其他加密算法来加密，而不限于非对称加密算法。
67.一旦接收到来自源设备的经非对称密钥算法加密的对称密钥，在步骤308，目标设备就使用自己的私钥对其进行解析。进一步地，在步骤309，目标设备根据解析结果向源设备返回密钥协商结果。
68.在步骤310，源设备判断协商是否成功。如果目标设备向源设备返回的密钥协商结果指示协商成功，则流程行进至步骤311，否则，流程跳转至步骤323。
69.在步骤311，源设备可向目标设备发送对目标设备信息的请求。在一些实施例中，对目标设备信息的请求可以是按信息帧的形式(即，“目标设备相关信息请求帧”，在下文中也简称为“请求帧”)来发送的。在一些实施例中，请求帧可包括以下各项信息中的一个或多
个：版本号；消息类型；加密指示符(加密或不加密)；完整性检测指示符；压缩指示符；扬声器指示符；屏幕存在性指示符；剩余flash指示符；剩余内存指示符；电量信息；格式支持列表；保留位；填充位指示符；超时指示符；以及时间戳。在一些实施例中，源设备可用先前已发送给目标设备的对称密钥来对要发送的请求帧进行加密。
70.在一些实施例中，在步骤312，目标设备可用先前接收自源设备的对称密钥来对要发送的响应帧进行加密。在一些实施例中，响应帧可包括以下各项信息中的一个或多个：版本号；消息类型；加密指示符；完整性检测指示符；压缩指示符；扬声器指示符；屏幕存在性指示符；剩余flash指示符；剩余内存指示符；电量信息；格式支持列表；应用包安装指示符；保留位；填充位指示符；超时指示符；以及时间戳。
71.响应于来自源设备的请求帧，在步骤313，目标设备可向源设备发送包含与所请求的目标设备信息相对应的信息的响应帧(即，“目标设备相关信息响应帧”，在下文中也简称为“响应帧”)。在请求帧是通过对称密钥加密的情形中，目标设备用先前接收自源设备的对称密钥对经加密的请求帧进行解密。
72.一旦接收到来自目标设备的响应帧，在步骤314，源设备可对响应帧进行解析。基于对所接收的响应帧的解析，在步骤315，源设备确定目标设备是否满足数据流的流转的条件。如果满足数据流的流转的条件，则流程行进至步骤316，否则，流程转至步骤323。
73.在一些实施例中，确定目标设备是否满足数据流的流转的条件包括确定诸如以下各项中的一项或多项：目标设备是否具有播放所述媒体的能力；目标设备是否已安装用于播放所述媒体的应用；以及目标设备是否利用hash函数进行完整性检测，等等。
74.在步骤316，源设备可构建要发送给目标设备的流转数据包。在一些实施例中，要发送的流转数据包可由源设备通过利用对称密钥来进行加密。在一些实施例中，流转数据包可以是信息帧的格式。在本文中，流转数据包也可称为“数据帧”。在一些实施例中，数据帧可包括以下各项信息中的一个或多个：版本号；消息类型；加密指示符；完整性检测指示符；压缩指示符；应用包安装指示符；保留位；填充位指示符；超时指示符；以及时间戳
75.在一些实施例中，数据帧可包括正在播放的音频源连接、播放进度、缓冲数据。在一些实施例中，源设备可通过确定来自目标设备的响应帧中的应用包安装指示符来确定是否在数据帧中打包应用。例如，如果接收自目标设备的响应帧中的应用包安装指示符指示目标设备处尚未安装应用，则源设备可在数据帧中打包应用。
76.在一些实施例中，数据帧中的完整性检测指示符可被置位，从而向目标设备指示在接收到数据帧之后利用hash函数进行摘要计算，以确保数据帧的完整性。
77.在步骤317，源设备可将数据帧发送到目标设备。在一些实施例中，在完整性检测指示符可被置位的情形中，数据帧包括利用hash函数计算的摘要。在一些实施例中，源设备可使用对称密钥来对要发送的数据帧进行加密，并在随后将经加密的数据帧作为流转数据包发送到目标设备。
78.在接收到经加密的流转数据包之后，在步骤318，目标设备可利用对称密钥来对所接收的流转数据包进行解析。
79.在步骤319，目标设备基于经解析的流转数据包来进行播放器重建。如果重建成功，则目标设备在步骤330继续进行媒体的播放并在步骤220向源设备返回重建成功指示，否则流程跳转至步骤321，在那里，目标设备关闭流转操作链路。
80.在一些实施例中，播放器重建包括安装用于播放媒体的应用。
81.在一些实施例中，媒体可包括但不限于：音频；视频；以及音频和视频的组合等等。在媒体包括视频的情形中，目标设备对媒体的播放包括在显示屏上显示视频画面。
82.在步骤322，如果接收到来自目标设备的重建成功指示，则源设备暂停对所述媒体的播放。如果未接收到来自目标设备的所述重建成功指示，则在步骤323，源设备结束流转操作。
83.在本发明实施例中，在传递对称密钥时，用到不对称加密技术。换言之，在本发明实施例中，在多个低功耗aiot设备之间发起数据互传以实现媒体数据流的无缝流转时，应用了组合式密钥加密技术(例如，对称加密技术和非对称加密技术的组合)，这能够有效阻止传送的密钥被窃取，从而实现数据安全性的提升。
84.图4例示了根据本技术实施例的目标设备相关信息请求帧的结构。如图4所示，请求帧可以包括协议头部以及应用id字段和应用版本字段。应当理解，请求帧的协议头部并不限于64位，而是可根据需要被配置成包含任何合适位的尺寸，诸如128位、256位、512位等等。
85.在一些实施例中，请求帧的协议头部中的[0:1]位(bit[0:1]:v)表示版本号。例如，v＝1指示版本为1。在一些实施例中，请求帧的协议头部中的[2:5]位(bit[2:5]:mt)表示消息类型。在一些实施例中，请求帧的协议头部中的[6]位(bit[6]:s)表示加密指示符(加密或不加密)。在一些实施例中，bit[6]＝0指示加密，而bit[6]＝1指示不加密，或者反之亦然。
[0086]
在一些实施例中，请求帧的协议头部中的[7]位(bit[7]:h)表示完整性检测指示符，其指示是否需要使用hash函数进行完整性检测。在一些实施例中，请求帧中的[8]位(bit[8]:c)表示压缩指示符。在一些实施例中，bit[8]＝0指示压缩，而bit[8]＝1指示不压缩，或者反之亦然。在一些实施例中，请求帧的协议头部中的[9]位(bit[9]:s)表示扬声器指示符，其指示是否具备扬声器。一些实施例中，请求帧的协议头部中的[10]位(bit[10]:gui)表示屏幕存在性指示符，其指示是否带有界面、屏或屏幕等等。
[0087]
在一些实施例中，请求帧的协议头部中的[11]位(bit[11]:f)表示剩余flash指示符，其指示是否剩余足够的flash，以供实现媒体播放的流转。在一些实施例中，请求帧的协议头部中的[12]位(bit[12]:m)表示剩余内存指示符，其指示是否剩余足够的内存，以供实现媒体播放的流转。
[0088]
在一些实施例中，请求帧的协议头部中的[13]位(bit[13]:p)表示电量信息。在一些实施例中，请求帧的协议头部中的[14]位(bit[14]:a)表示格式支持列表，其指示设备所支持的格式的列表。在一些实施例中，格式可包括mp3、wav、midi、cda、wma、mp4、avi、3gp、rm、flv、蓝光(blu-ray)、以及mkv等等。
[0089]
在一些实施例中，请求帧的协议头部中的[15:22]位(bit[15:22])表示保留位。在一些实施例中，请求帧的协议头部中的[23:27]位(bit[23:27]:p)表示填充位指示符。
[0090]
在一些实施例中，请求帧的协议头部中的[28:31]位(bit[28:31]:tmo)表示超时指示符(例如，范围从0至7秒)。在一些实施例中，请求帧的协议头部中的[32:63]位(bit[28:31]:timestamp)表示时间戳(以秒为单位)。
[0091]
在一些实施例中，请求帧的协议头部中的一些信息元素用于向目标设备指示源设
备希望从该目标设备处接收到的信息，诸如扬声器指示符、屏幕存在性指示符、电量信息、格式支持列表等等。
[0092]
在一些实施例中，请求帧的协议头部中的一些信息元素指示时间相关信息，诸如超时指示符、时间戳等等。
[0093]
需要指出的是，上文例示的请求帧中的各个信息元素所包含的bit数目仅是示例性，而不是限制性的。换言之，上述例示的各个信息元素可包含任何合适的bit数目。
[0094]
图5例示了根据本技术实施例的目标设备相关信息响应帧的结构。如图5所示，响应帧包括协议头部以及任选的hash字节字段和填充字段(pad)。
[0095]
应当理解，响应帧的协议头部的尺寸并不限于64位，而是可根据需要被配置成包含任何合适位的尺寸，诸如128位、256位、512位等等。
[0096]
在一些实施例中，响应帧的协议头部中包含的信息元素与请求帧的协议头部中包含的信息元素是大致相对应的。
[0097]
例如，在一些实施例中，响应帧的协议头部可包括但不限于以下各种信息元素：版本号(bit[0:1]:v)；消息类型(bit[2:5]:mt)；加密指示符(bit[6]:s)；完整性检测指示符(bit[7]:h)；压缩指示符(bit[8]:c)；扬声器指示符(bit[9]:s)；屏幕存在性指示符(bit[10]:gui)；剩余flash指示符(bit[11]:f)；剩余内存指示符(bit[12]:m)；电量信息(bit[13]:p)；格式支持列表(bit[14]:a)；应用包安装指示符(bit[15]:u)；保留位(bit[16:23])；填充位指示符(bit[24:28]:p)；超时指示符(bit[29:31]:tmo)；以及时间戳(bit[32:63]:timestamp)。
[0098]
由于响应帧是目标设备针对源设备发送的请求帧而发送的，因此，响应帧中那些类似于请求帧中的信息元素指示类似的含义。因此，为了简洁起见，对响应帧中的类似信息元素不再赘述。
[0099]
如图5所示，除了协议头部之外，响应帧还可包括任选的hash字节字段和任选的填充(pad)字段。
[0100]
在一些实施例中，任选的hash字节字段和任选的填充(pad)字段被用来检测完整性。具体而言，在需要使用hash函数进行完整性检测的情形中，响应帧的协议头部中的填充位指示符指示响应帧末尾的填充(pad)字段的长度。由于响应帧的总长度、hash字节字段的长度以及协议头部的长度是固定且已知的，因此，在源设备处，通过将响应帧的长度减去协议头部的长度，再减去hash字节的长度和填充位指示符所指示的填充(pad)字段的长度，就能得到要进行hash计算的部分。
[0101]
在一些实施例中，源设备可对flash(闪存)字段、mem(存储器)字段、功率字段、解码器列表字段进行hash计算，并将计算所得的结果与响应帧中包含的hash字节字段进行比较，以检测完整性。
[0102]
需要指出的是，上文例示的响应帧中的各个信息元素所包含的bit数目仅是示例性，而不是限制性的。换言之，上述例示的各个信息元素可包含任何合适的bit数目。
[0103]
图6例示了根据本技术实施例的流转数据包的结构。在本文中，流转数据包也可称为数据帧。
[0104]
如图6所示，数据帧可分为控制平面和数据平面两个部分，其中控制平面对应于协议头部(诸如，版本号、消息类型、加密指示符、完整性检测指示符、压缩指示符等等)，而数
据平面对应于数据信息(诸如，音频源链接长度、音频源链接、应用包等等)。
[0105]
如图6所例示的，数据帧的协议头部包含64位的信息。然而，应当理解，数据帧的协议头部的尺寸并不限于64位，而是可根据需要被配置成包含任何合适位的尺寸，诸如128位、256位、512位等等。
[0106]
如图6所例示的，数据帧的协议头部中包含的一些信息元素类似于请求帧和响应帧的协议头部中包含的信息元素。例如，在一些实施例中，数据帧的协议头部可包括但不限于以下各种信息元素：版本号(bit[0:1]:v)；消息类型(bit[2:5]:mt)；加密指示符(bit[6]:s)；完整性检测指示符(bit[7]:h)；压缩指示符(bit[8]:c)；应用包安装指示符(bit[9]:u)；保留位(bit[10:22])；填充位(bit[23:27]：p)；超时指示符(bit[28:31]:tmo)；以及时间戳(bit[32:63]:timestamp)。
[0107]
除了协议头部中的信息元素之外，如图6所例示，数据帧的数据平面还可包括不限于以下各项信息元素中的一项或多项：音频/视频源链接长度、音频/视频源链接、播放进度(指示已经播放到所附音频/视频源链接的媒体数据流的第几帧)、所缓存音频长度、音频缓存、应用长度(指示应用包的大小)、应用包(诸如，播放器应用)、hash字节字段(任选)以及填充(pad)字段(任选)。
[0108]
需要指出的是，上文例示的数据帧中的各个信息元素所包含的bit数目仅是示例性，而不是限制性的。换言之，上述例示的各个信息元素可包含任何合适的bit数目。
[0109]
在一些实施例中，在目标设备处尚未安装播放应用的情况下，数据帧可包括上述应用包(诸如，播放器应用)，以供目标设备安装应用来播放媒体。
[0110]
在一些实施例中，在完整性检测指示符指示是否需要使用hash函数进行完整性检测的情况下，对数据帧中从音频源链接长度至应用包的部分进行hash计算，以便检测完整性。
[0111]
类似于响应帧，在数据帧中，在需要使用hash函数进行完整性检测的情形中，数据帧的协议头部中的填充位指示符指示数据帧末尾的填充字段的长度。由于数据帧的总长度以及协议头部的长度是固定且已知的，因此，在目标设备出，通过将数据帧帧的长度减去协议头部的长度，再减去填充位指示符所指示的填充字段的长度，就能得到要进行hash计算的部分(对应于数据帧中从音频源链接长度至应用包的部分)。
[0112]
在一些实施例中，目标设备对以下信息元素部分进行hash计算：音频源链接长度、音频源链接、播放进度、解码列表、所缓存音频长度、音频缓存、应用长度、应用包。
[0113]
随后，目标设备可通过将计算所得的结果与数据帧中包含的hash字节字段进行比较来检测完整性。
[0114]
示例实现方式
[0115]
本文中所讨论的当前所描述的方法、设备、系统和计算机可读存储介质的附加示例包括以下非限制性实现方式。下列非限制性示例中的每一个示例可以独立存在，或可以与以下所提供的或遍及本公开的其他示例中的任何一个或多个示例按照任何排列或组合进行结合。
[0116]
示例1包括一种媒体数据流的流转方法，包括：由源设备向目标设备发送媒体的数据流的流转请求；由源设备从目标设备接收到的数字证书和数字签名进行解析以对对目标设备进行认证；在认证成功的情况下，由源设备使用第一加密算法生成第一密钥；由源设备
将经第二加密算法加密的第一密钥发送到目标设备；目标设备从源设备接收经第二加密算法加密的第一密钥，使用第二加密算法对第一密钥进行解析，并根据解析结果向源设备返回密钥协商结果；以及在密钥协商结果是协商成功的情况下，在源设备与目标设备之间使用第一密钥进行通信。
[0117]
示例2包括示例1或本文的某个其他示例的方法，其中由源设备对从目标设备接收到的数字证书和数字签名进行解析以对目标设备进行认证进一步包括：目标设备在接收到流转请求之后，向源设备发送数字证书和数字签名；以及由源设备对接收到的数字证书和数字签名进行解析，以对目标设备进行认证。
[0118]
示例3包括示例1-2中的任一项或本文中的某个其他示例的方法，其中源设备对接收到的数字证书和数字签名进行解析进一步包括：对数字签名进行解析，并利用hash函数计算摘要；将计算出的摘要与先前存储的服务器的摘要进行比较；以及如果计算出的摘要与先前存储的服务器的摘要匹配，则认证成功。
[0119]
示例4包括示例1-3中的任一项或本文中的某个其他示例的方法，其中第一加密算法是对称加密算法，而第一密钥是对称密钥。
[0120]
示例5包括示例1-4中的任一项或本文中的某个其他示例的方法，其中第二加密算法是非对称加密算法，源设备使用目标设备的公钥对第一密钥进行加密，目标设备使用自己的私钥对第一密钥进行解析。
[0121]
示例6包括示例1-5中的任一项或本文中的某个其他示例的方法，进一步包括：在接收到来自源设备的经第二加密算法加密的第一密钥之后，目标设备对经第二加密算法加密的第一密钥进行解析；以及如果解析成功，则目标设备向源设备返回解析成功的协商结果。
[0122]
示例7包括示例1-6中的任一项或本文中的某个其他示例的方法，进一步包括：在发送与媒体相关的流转数据包之前，由源设备向目标设备发送使用第一密钥加密的目标设备相关信息请求帧；以及响应于目标设备相关信息请求帧，由目标设备向源设备发送使用第一密钥加密的目标设备相关信息响应帧。
[0123]
示例8包括示例1-7中的任一项或本文中的某个其他示例的方法，进一步包括：基于对接收到的目标设备相关信息响应帧的解析，由源设备确定目标设备是否满足数据流的流转的条件；以及如果满足数据流的流转的条件，则由源设备向目标设备发送流转数据包。
[0124]
示例9包括示例1-8中的任一项或本文中的某个其他示例的方法，其中确定目标设备是否满足数据流的流转的条件包括确定以下各项中的一项或多项：目标设备是否具有播放媒体的能力；目标设备是否已安装用于播放媒体的应用；以及目标设备是否利用hash函数进行完整性检测。
[0125]
示例10包括示例1-9中的任一项或本文中的某个其他示例的方法，其中流转数据包是用第一密钥加密的。
[0126]
示例11包括示例1-10中的任一项或本文中的某个其他示例的方法，其中目标设备相关信息请求帧和目标设备相关信息响应帧中的任一者包括以下各项中的一项或多项：版本号；消息类型；加密指示符；完整性检测指示符；压缩指示符；扬声器指示符；屏幕存在性指示符；剩余flash指示符；剩余内存指示符；电量信息；格式支持列表；应用包安装指示符；保留位；填充位；超时指示符；以及时间戳。
[0127]
示例12包括示例1-11中的任一项或本文中的某个其他示例的方法，其中流转数据包包括以下各项中的一项或多项：版本号；消息类型；加密指示符；完整性检测指示符；压缩指示符；应用包安装指示符；保留位；填充位；超时指示符；以及时间戳。
[0128]
示例13包括示例1-12中的任一项或本文中的某个其他示例的方法，进一步包括：目标设备对接收到的流转数据包进行解析，并基于经解析的流转数据包来进行播放器重建，播放器重建包括安装用于播放媒体的应用；如果重建成功，则目标设备进行媒体的播放并向源设备返回重建成功指示；以及如果重建失败，则目标设备关闭流转操作链路。
[0129]
示例14包括示例1-13中的任一项或本文中的某个其他示例的方法，进一步包括：如果接收到来自目标设备的重建成功指示，则源设备暂停对媒体的播放；以及如果未接收到来自目标设备的重建成功指示，则源设备结束流转操作。
[0130]
示例15包括示例1-14中的任一项或本文中的某个其他示例的方法，其中源设备和目标设备是aiot智能设备。
[0131]
示例16包括一种媒体数据流的流转系统，包括：源设备，源设备被配置成：向目标设备发送流转请求；对目标设备进行认证；使用第一加密算法生成第一密钥；以及将经第二加密算法加密的第一密钥发送到目标设备；以及目标设备，目标设备被配置成：从源设备接收流转请求；向源设备发送数字证书和数字签名以供源设备进行认证；从源设备接收经第二加密算法加密的第一密钥，使用第二加密算法对第一密钥进行解析，并根据解析结果向源设备返回密钥协商结果，其中在密钥协商结果是协商成功的情况下，源设备与目标设备之间的通信通过使用第一密钥来进行。
[0132]
示例17包括示例16或本文中的某个其他示例的系统，其中第一加密算法是对称加密算法，而第一密钥是对称密钥。
[0133]
示例18包括示例16-17中的任一项或本文中的某个其他示例的系统，其中第二加密算法是非对称加密算法，源设备使用目标设备的公钥对第一密钥进行加密，目标设备使用自己的私钥对第一密钥进行解析。
[0134]
示例19包括一种用于媒体的数据流的流转的设备，包括用于执行如上所述的方法的装置。
[0135]
示例20包括一种其上存储有指令的计算机可读介质，所述指令当由计算机处理器执行时使所述处理器执行如上所述的方法。
[0136]
示例21包括一种发起媒体数据流的流转的方法，包括：向目标设备发送流转请求；从目标设备接收数字证书和数字签名以对目标设备进行认证；在认证成功的情况下，使用第一加密算法生成第一密钥；将经第二加密算法加密的第一密钥发送到目标设备；以及在目标设备返回协商成功的密钥协商结果的情况下，使用第一密钥来与目标设备进行通信。
[0137]
示例22包括一种接受媒体数据流的流转的方法，包括：从源设备接收流转请求；向源设备发送数字证书和数字签名以供源设备进行认证；从源设备接收经第二加密算法加密的第一密钥，使用第二加密算法对第一密钥进行解析，并根据解析结果向源设备返回密钥协商结果；以及在密钥协商结果是协商成功的情况下，使用第一密钥来与源设备进行通信。
[0138]
示例23包括一种发起媒体数据流的流转的设备，包括：用于向目标设备发送流转请求的装置；用于从所述目标设备接收数字证书和数字签名以对目标设备进行认证的装置；用于在认证成功的情况下，使用第一加密算法生成第一密钥的装置；用于将经第二加密
算法加密的第一密钥发送到目标设备的装置；以及用于在另一设备返回协商成功的密钥协商结果的情况下，使用第一密钥来与目标设备进行通信的装置。
[0139]
示例24包括一种接受媒体数据流的流转的设备，包括：用于从源设备接收流转请求的装置；用于向源设备发送数字证书和数字签名以供源设备进行认证的装置；用于从源设备接收经第二加密算法加密的第一密钥，使用第二加密算法对第一密钥进行解析，并根据解析结果向源设备返回密钥协商结果的装置；以及用于在密钥协商结果是协商成功的情况下，使用第一密钥来与源设备进行通信的装置。
[0140]
本文中的“媒体”或“媒体流”可以是指表示针对用户的内容的任何数据。内容的示例可包括例如来自音频、视频、语音对话、视频会议、电子邮件(“email”)消息、语音邮件消息、字母数字符号、图形、图像、视频、文本等的数据。来自语音对话的数据可以是例如，话语信息、静默时段、背景噪声、舒适噪声、音调等。
[0141]
文本中的“无线通信技术”可以包括任何一种或多种通信技术(例如，有线或无线通信)和相关联的协议，例如，蜂窝联网协议(诸如3gpp 4g或5g标准)、无线局域网协议(诸如ieee 802.11/)、无线广域网协议，以太网、蓝牙低能量、iot协议(诸如ieee 802.15.4或)、低功率广域网(lpwan)或低功率广域网(lpwa)协议等。
[0142]
文本中的“aiot设备”可以是智能电话、媒体娱乐设备、播放器、智能电视、智能手表、耳机、手持式计算机、掌上计算机、个人数字助理(pda)、蓝牙耳机、头戴式耳机、膝上型设备、机顶盒、平板设备、pc、组合式蜂窝电话/pda、蜂窝电话、电视机、智能平板计算机、移动互联网设备(mid)、发消息设备、数据通信设备或其他任何合适的智能设备。进一步地，iot设备可以是虚拟设备，诸如智能电话或其他计算设备上的应用。
[0143]
此外，aiot设备的网络也可包括商用和家用自动化设备，诸如给水系统、配电系统、流水线控制系统、工厂控制系统、灯开关、恒温器、锁、相机、警报、运动传感器，等等。aiot设备可以是通过远程计算机、服务器和其他系统可访问的，从而例如控制系统或访问数据。
[0144]
至少一个实施例的一个或多个方面可以由存储在机器可读介质上的表征性指令来实现，该指令表示处理器中的各种逻辑，该指令在被机器读取时使得该机器制作用于执行本文所述的技术的逻辑。
[0145]
例如，可使用机器可读介质或者制品来实现一些实施例，这些介质或者制品可存储指令或者指令集，这些指令或指令集在由机器执行时可使该机器根据实施例来执行方法和/或操作。这样的机器可以包括，例如，任何合适的处理平台、计算平台、计算设备、处理设备、计算系统、处理系统、计算机、处理器等等，并可以使用硬件和/或软件的任何合适的组合来实现。机器可读取的介质或制品可以包括，例如，任何合适类型的存储器单元、存储器设备、存储器制品、存储器介质、存储设备、存储器制品、存储器介质和/或存储器单元，例如，存储器、可移动或不可移动介质、可擦除的或非可擦除的介质，可写入的或重写的介质、数字或模拟介质、硬盘、软盘、只读光盘存储器(cd-rom)、可记录光盘(cd-r)、可重写光盘(cd-rw)、光盘、磁性介质、磁光介质、可移动存储器卡或盘、各种类型的数字多功能盘(dvd)、磁带、磁带盒等等。指令可包括任何合适类型的代码，如源代码、已编译的代码、已解释的代码、可执行代码、静态代码、动态代码、加密代码等等，使用任何合适的高级别的、低级别的、面向对象的、可视的、已编译的和/或解释性编程语言来实现。
[0146]
在此文档中，如在专利文档中常见的那样，使用术语“一”以包括一个或多于一个，这独立于“至少一个”或“一个或多个”的任何其他实例或用法。在此文档中，使用术语“或”来指非排他性的“或”，使得“a或b”包括“a但非b”、“b但非a”以及“a和b”，除非另外指示。此外，在所附权利要求书中，术语“包括”和“包含”是开放式的，也就是说，在权利要求中除此类术语之后列举的那些元件之外的元件的系统、设备、制品或过程仍被视为落在那项权利要求的范围内。此外，在所附权利要求书中，术语“第一”、“第二”和“第三”等仅被用作标记，并且不旨在表明对它们的对象的数字顺序。
[0147]
以上描述旨在是说明性的，而非限制性的。例如，可结合其他实施例来使用以上描述的示例(或者其一个或多个方面)。诸如，本领域普通技术人员中的一个可通过回顾以上描述来使用其他实施例。
[0148]
在此已经阐明了许多具体的细节，以便对这些实施例有透彻的理解。然而，本领域技术人员将会理解，可在没有这些具体细节的情况下实施这些实施例。在其它实例中，未对公知操作、组件和电路进行详细描述，以免使这些实施例难以理解。可以认识到，在此公开的、特定的结构细节和功能细节可以是代表性的，不一定限制这些实施例的范围。
[0149]
应当注意，本文所描述的方法不必以所述顺序或任何特定顺序来执行。此外，参考本文标识的方法而描述的各种活动可以按串行或并行方式执行。
[0150]
尽管在本文中已经图示并描述了各特定实施例，但应当认识到，被预计能够实现相同目的的任何安排可以替换所示的特定实施例。本文公开内容旨在覆盖各种实施例的任何和全部适应或变形。应当理解，以上描述是以说明性的方式而非限制性的方式进行的。
[0151]
对于本领域技术人员而言，在阅读了以上描述之后，上述实施例的组合以及未在本文中具体描述的其它实施例是显而易见的。因此，各种实施例的范围包括了使用以上各组分、结构和方法的任何其它应用。