CN105722250B - 一种数据传输与反向控制方法、设备及*** - Google Patents

Abstract

本发明公开了一种数据传输与反向控制方法、设备及***，在本案中，源设备可与车载设备进行反向音频传输能力的协商，并在确定二者均支持反向音频传输能力后，与车载设备协商反向音频传输端口并利用协商的反向音频传输端口与车载设备进行音频数据的传输，从而实现了车载设备与源设备之间的反向乃至双向音频数据的传输。另外，在本案中，源设备还可向周围各设备广播携带有用于表示自身支持车载控制设备类型的标识的反向输入能力消息，以由各车载设备在根据该反向输入能力消息确定源设备支持车载控制设备类型时，通过向源设备发送携带有相应车载反向控制信息的反向控制通用消息的方式对源设备进行反向控制，从而实现了车载设备对源设备的反向控制。

Description

一种数据传输与反向控制方法、设备及***

技术领域

本发明涉及多屏互动技术领域，尤其涉及一种数据传输与反向控制方法、设备及***。

背景技术

多屏互动技术指的是，基于DLNA(由索尼、英特尔、微软等发起成立、旨在解决个人PC、消费电器、移动设备在内的无线网络和有线网络的互联互通技术)协议、闪联协议或Miracast(又称为WI-FI Display，即无线同屏)协议等，通过WIFI(无线相容性认证)网络连接，在不同多媒体终端，如手机、PAD、TV等之间进行多媒体内容(如音频、视频或图片等)的传输、解析、展示或控制等一系列操作，以在不同平台设备上同时共享所展示的内容的技术。

简单来说，通过多屏互动技术，不同设备的屏幕之间可实现相应的连接转换，比如手机上的电影可在电视上播放，平板上的图片可在电视上分享，电脑上的内容可以投影到电视等，即，通过多屏互动技术，可实现在各相应设备间迅速地传输图片、音频或视频等，因此，多屏互动技术在各设备间的数据传输上得到了广泛的应用。

但是，目前的多屏互动技术(如Miracast技术)通常并不支持以下车载应用场景：如，通过车载设备上的控制按键(包括旋钮、按键等)操作手机等源设备上的各应用，或者，从车载设备反向传输音频数据至手机等源设备、以实现车载设备和手机等源设备之间的反向乃至双向音频数据的传输等，从而导致多屏互动技术的使用场景受到了极大的限制。

发明内容

本发明实施例提供了一种数据传输与反向控制方法、设备及***，用以解决目前存在的多屏互动技术不支持车载设备与源设备之间的反向乃至双向音频数据的传输以及不支持车载设备对源设备的反向控制等车载应用场景的问题。

本发明实施例提供了一种数据传输方法，包括：

源设备与车载设备进行反向音频传输能力的协商；

若确定自身与所述车载设备均支持反向音频传输能力，则与所述车载设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述车载设备进行音频数据的传输。

进一步地，本发明实施例还提供了另一种数据传输方法，包括：

车载设备与源设备进行反向音频传输能力的协商；

若确定自身与所述源设备均支持反向音频传输能力，则与所述源设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述源设备进行音频数据的传输。

进一步地，本发明实施例提供了一种反向控制方法，包括：

源设备若确定自身支持车载控制设备类型，则向周围各设备广播携带有用于表示所述源设备支持车载控制设备类型的标识的反向输入能力消息；

若接收到任一车载设备发送的携带有车载反向控制信息的反向控制通用消息，则根据所述反向控制通用消息中携带的所述车载反向控制信息执行相应的控制操作。

进一步地，本发明实施例还提供了另一种反向控制方法，包括：

车载设备接收源设备广播的反向输入能力消息；

若确定所述反向输入能力消息中携带有用于表示所述源设备支持车载控制设备类型的标识，且确定自身需对所述源设备进行反向控制，则向所述源设备发送携带有车载反向控制信息的反向控制通用消息，以指示所述源设备根据所述车载反向控制信息执行相应的控制操作。

进一步地，本发明实施例还提供了一种终端设备，包括：

能力协商单元，用于与车载设备进行反向音频传输能力的协商；

端口协商单元，用于若确定所述终端设备与所述车载设备均支持反向音频传输能力，则与所述车载设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述车载设备进行音频数据的传输。

进一步地，本发明实施例还提供了一种车载设备，包括：

能力协商单元，用于与源设备进行反向音频传输能力的协商；

端口协商单元，用于若确定所述车载设备与所述源设备均支持反向音频传输能力，则与所述源设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述源设备进行音频数据的传输。

进一步地，本发明实施例还提供了另一种终端设备，包括：

发送单元，用于若确定所述终端设备支持车载控制设备类型，则向周围各设备广播携带有用于表示所述终端设备支持车载控制设备类型的标识的反向输入能力消息；

接收单元，用于接收车载设备发送的携带有车载反向控制信息的反向控制通用消息；

处理单元，用于根据所述反向控制通用消息中携带的所述车载反向控制信息执行相应的控制操作。

进一步地，本发明实施例还提供了另一种车载设备，包括：

接收单元，用于接收源设备广播的反向输入能力消息；

处理单元，用于若确定所述反向输入能力消息中携带有用于表示所述源设备支持车载控制设备类型的标识且确定自身需对所述源设备进行反向控制，则触发发送单元向所述源设备发送携带有车载反向控制信息的反向控制通用消息；

发送单元，用于根据所述处理单元的触发，向所述源设备发送携带有车载反向控制信息的反向控制通用消息，以指示所述源设备根据所述车载反向控制信息执行相应的控制操作。

进一步地，本发明实施例还提供了一种数据传输***，包括包括源设备以及车载设备，其中：

所述源设备，用于与所述车载设备进行反向音频传输能力的协商，以及，若确定自身与所述车载设备均支持反向音频传输能力，则与所述车载设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述车载设备进行音频数据的传输；

所述车载设备，用于与所述源设备进行反向音频传输能力的协商，以及，若确定自身与所述源设备均支持反向音频传输能力，则与所述源设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述源设备进行音频数据的传输。

进一步地，本发明实施例还提供了一种反向控制***，包括源设备以及车载设备，其中：

所述源设备，用于若确定自身支持车载控制设备类型，则向周围各设备广播携带有用于表示所述源设备支持车载控制设备类型的标识的反向输入能力消息；以及，若接收到任一车载设备发送的携带有车载反向控制信息的反向控制通用消息，则根据所述反向控制通用消息中携带的所述车载反向控制信息执行相应的控制操作；

所述车载设备，用于接收所述源设备广播的反向输入能力消息，并若确定所述反向输入能力消息中携带有用于表示所述源设备支持车载控制设备类型的标识且确定自身需对所述源设备进行反向控制，则向所述源设备发送携带有车载反向控制信息的反向控制通用消息，以指示所述源设备根据所述车载反向控制信息执行相应的控制操作。

本发明有益效果如下：

本发明实施例提供了一种数据传输方法与反向控制方法、设备及***，在本发明实施例所述技术方案中，源设备可与车载设备进行反向音频传输能力的协商，并在确定二者均支持反向音频传输能力后，与车载设备协商用于传输音频数据的反向音频传输端口并利用协商的反向音频传输端口与车载设备进行音频数据的传输，从而实现了车载设备与源设备之间的反向乃至双向音频数据的传输，解决了现有多屏互动技术不支持车载设备与源设备之间的反向乃至双向音频数据传输的车载应用场景的问题，扩展了多屏互动技术的使用场景。

另外，在本发明实施例所述技术方案中，源设备还可在确定自身支持车载控制设备类型时，向周围各设备广播携带有用于表示自身支持车载控制设备类型的标识的反向输入能力消息，以由周围各车载设备在根据所述反向输入能力消息，确定源设备支持车载控制设备类型时，通过向源设备发送携带有相应车载反向控制信息的反向控制通用消息的方式对源设备进行反向控制，从而实现了车载设备对源设备的反向控制，解决了现有多屏互动技术不支持车载设备对源设备的反向控制的车载应用场景的问题，进一步扩展了多屏互动技术的使用场景。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1所示为本发明实施例一中所述数据传输方法的流程示意图；

图2所示为本发明实施例二中所述数据传输方法的流程示意图；

图3所示为本发明实施例三中所述数据传输方法的流程示意图；

图4所示为本发明实施例四中所述反向控制方法的流程示意图；

图5所示为本发明实施例五中所述反向控制方法的流程示意图；

图6所示为本发明实施例六中所述反向控制方法的流程示意图；

图7所示为本发明实施例七中所述终端设备的流程示意图；

图8所示为本发明实施例七中所述车载设备的流程示意图；

图9所示为本发明实施例七中所述另一种终端设备的流程示意图；

图10所示为本发明实施例七中所述另一种车载设备的流程示意图；

图11所示为本发明实施例七中所述数据传输***的结构示意图；

图12所示为本发明实施例七中所述反向控制***的结构示意图。

具体实施方式

本发明实施例提供了一种数据传输方法与反向控制方法、设备及***，本发明实施例所述技术方案中，源设备可与车载设备进行反向音频传输能力的协商，并在确定二者均支持反向音频传输能力后，与车载设备协商用于传输音频数据的反向音频传输端口并利用协商的反向音频传输端口与车载设备进行音频数据的传输，从而实现了车载设备与源设备之间的反向乃至双向音频数据的传输，解决了现有多屏互动技术，如Miracast技术不支持车载设备与源设备之间的反向乃至双向音频数据传输的车载应用场景的问题，扩展了多屏互动技术的使用场景。

另外，在本发明实施例所述技术方案中，源设备还可在确定自身支持车载控制设备类型时，向周围各设备广播携带有用于表示自身支持车载控制设备类型的标识的反向输入能力消息，以由周围各车载设备在根据所述反向输入能力消息，确定源设备支持车载控制设备类型时，通过向源设备发送携带有相应车载反向控制信息的反向控制通用消息的方式对源设备进行反向控制，从而实现了车载设备对源设备的反向控制，解决了现有多屏互动技术，如Miracast技术不支持车载设备对源设备的反向控制的车载应用场景的问题，进一步扩展了多屏互动技术的使用场景。

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

实施例一：

为了支持车载设备与源设备之间的反向乃至双向音频数据传输，本发明实施例一提供了一种数据传输方法，如图1所示，其为本发明实施例一所述数据传输方法的流程示意图，所述方法可包括以下步骤：

步骤101：源设备与车载设备进行反向音频传输能力的协商。

具体地，以Miracast技术为例，源设备与车载设备可以在现有Miracast1.0规范定义的能力协商阶段进行反向音频传输能力的协商，并且，参照Miracast1.0规范中所涉及到的source和sink之间协商相应扩展能力的流程可知，所述反向音频传输能力的具体协商流程可包括：

源设备向所述车载设备发送携带有第一标识的第一扩展能力协商消息，所述第一标识用于表示所述源设备是否具有反向音频传输能力，以由所述车载设备根据所述第一扩展能力协商消息中携带的所述第一标识以及所述车载设备自身所具备的扩展能力，判断所述源设备与所述车载设备是否均支持反向音频传输能力；以及，若接收到所述车载设备返回的用于表示所述源设备与所述车载设备均支持反向音频传输能力的响应消息，则确定所述源设备与所述车载设备均支持反向音频传输能力，否则，则确定所述源设备与所述车载设备并非均支持反向音频传输能力；

或者，

接收所述车载设备发送的携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备支持反向音频传输能力，且根据所述源设备自身所具备的扩展能力确定自身也支持反向音频传输能力，则确定所述源设备与所述车载设备均支持反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备不支持反向音频传输能力，或，根据所述源设备自身所具备的扩展能力确定自身不支持反向音频传输能力，则确定所述源设备与所述车载设备并非均支持反向音频传输能力。

也就是说，源设备在与车载设备进行反向音频传输能力的协商时，可采用由车载设备执行判断二者是否均支持反向音频传输能力的操作的判断方式，也可采用由所述源设备执行判断二者是否均支持反向音频传输能力的操作的判断方式，本发明实施例对此不作任何限定。

另外需要说明的是，源设备在与车载设备进行反向音频传输能力的协商之前，可首先判断自身是否支持反向音频传输能力，在确定自身支持反向音频传输能力后，再执行后续的反向音频传输能力协商过程，本发明实施例对此不作赘述。

再有需要说明的是，以Miracast技术为例，源设备在与车载设备进行反向音频传输能力的协商之前，通常还可先执行相应的设备发现流程。具体地，与现有技术不同的是，在本发明实施例的设备发现阶段，源设备与终端设备(如车载设备)可在设备发现阶段的广播消息或广播帧中增加相关的信息来标识自己是否支持反向音频传输能力，以便对应的终端设备或源设备能够根据该增加的相关信息来发现周围具备相应反向音频传输能力的设备，本发明实施例对此不作赘述。

进一步地，需要说明的是，以Miracast技术为例，所述第一、第二扩展能力协商消息可为现有Miracast1.0规范中用来协商source和sink所支持的扩展能力的WFD ExtendedCapabilities消息。也就是说，为了兼容现有Miracast1.0规范，使得对其所进行的修改尽量小，在本发明所述实施例中，可在Miracast1.0规范所定义的用来协商source和sink所支持的扩展能力的WFD Extended Capabilities消息中携带相应的、用于表示相应设备是否具有反向音频传输能力的标识信息，如第一标识或第二标识。

具体地，如表1所示的WFD Extended Capabilities Bitmap(WFD ExtendedCapabilities消息所对应的比特位图)可知，WFD Extended Capabilities消息所对应的消息域中存在多个尚未使用的设定保留位(如第6-15位，即对应的位标识为6-15的保留位)，因此，可考虑对上述设定保留位中的一位(如第6位)进行扩展，以将其作为反向音频数据传输能力支持位。即，所述第一标识具体可通过所述第一扩展能力协商消息所对应的消息域中的该设定保留位的具体取值来表示；所述第二标识具体可通过所述第二扩展能力协商消息所对应的消息域中的该设定保留位的具体取值来表示，本发明实施例对此不作赘述。

表1：WFD Extended Capabilities Bitmap

进一步地，在本发明所述实施例中，所述反向音频数据传输能力支持位的定义可如如表1所示的扩展能力协商消息所对应的其他能力支持位一样，0b0可表示不支持反向音频传输能力(即Not supported)，0b1可表示支持反向音频传输能力(即supported)，本发明实施例对此不作赘述。当然需要说明的是，还可采用其它取值(如1或0等)来表示是否支持反向音频传输能力，本发明实施例对此不作任何限定。

步骤102：所述源设备若确定自身与所述车载设备均支持反向音频传输能力，则与所述车载设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述车载设备进行音频数据的传输。

具体地，以Miracast技术为例，所述源设备与所述车载设备可以在现有Miracast1.0规范所定义的能力协商阶段进行反向音频传输端口的协商，并且，参照Miracast1.0规范中所涉及到的source和sink之间协商从source向sink传输音视频数据时所使用的音视频数据端口的流程可知，所述反向音频传输端口的具体协商流程可以如步骤A1-A3所述：

步骤A1：向所述车载设备发送参数获取请求消息，所述参数获取请求消息中携带有用于协商反向音频传输端口号的反向端口号协商参数域，要求车载设备在响应该参数获取请求消息时在该反向端口号协商参数域内填写相应的反向音频传输端口号。

其中，所述参数获取请求消息可以是源设备向车载设备发送的用于询问设备的属性和支持能力的M3 request消息，该参数获取请求消息中携带的用于协商反向音频传输端口号的反向端口号协商参数域可以是在Miracast1.0规范的基础上新增加的wfd-reverse-audio-port参数域，具体地，wfd-reverse-audio-port参数域的定义可以为：

wfd-reverse-audio-port＝“wfd-reverse-audio-port:”SP profile SP rtp-port SP mode CRLF//即wfd-reverse-audio-port参数域具体可包括profile(配置)域、rtp-port(实时传输协议端口)域以及mode(模式)域等；

profile＝“RTP/AVP/UDP；unicast”//即对应的配置域信息可为通过TCP(传输控制协议)传输RTP包，或者，单播等；

rtp-port＝IPPORT；UDP port//即对应的端口域信息可为IP(网际协议)端口或UDP(用户数据报协议)端口等；

mode＝“mode＝play”//即对应的模式域信息可为play(播放)等。

步骤A2：接收所述车载设备针对所述参数获取请求消息返回的参数获取响应消息，所述参数获取响应消息中携带有添加有所述车载设备所支持的反向音频传输端口号的反向端口号协商参数域。

其中，所述参数获取响应消息可以是M3 response消息，即，所述车载设备在向所述源设备返回针对所述参数获取请求消息(即M3 request消息)的参数获取响应消息(即M3response消息)时，需在该参数获取响应消息中的wfd-reverse-audio-port参数域内添加至少一个反向音频传输端口号。

步骤A3：根据所述参数获取响应消息，向所述车载设备返回参数设置请求消息，所述参数设置请求消息中携带有添加有所述源设备所选取的反向音频传输端口号的反向端口号协商参数域，以告知所述车载设备二者所协商的反向音频传输端口号；其中，所述源设备所选取的反向音频传输端口号是所述源设备从所述车载设备所支持的反向音频传输端口号中所选取的。

具体地，所述参数设置请求消息可以是M4 request消息，本发明实施例对此不作赘述。

至此，即可实现源设备与车载设备之间的反向音频传输端口号的协商。

进一步地，需要说明的是，在协商反向音频传输端口号之后，所述源设备可通过协商的反向音频传输端口号与车载设备进行音频数据的传输，以Miracast技术为例，具体的数据传输流程可与现有Miracast 1.0规范的数据传输过程类似，本发明实施例对此不作赘述。

另外，需要说明的是，除了Miracast技术之外，本发明实施例还可适用于其他多屏互动技术，如基于DLNA协议或闪联协议的多屏互动技术，本发明实施例对此不作赘述。

也就是说，在本发明实施例一所述技术方案中，源设备可与车载设备进行反向音频传输能力的协商，并在确定二者均支持反向音频传输能力后，与车载设备协商用于传输音频数据的反向音频传输端口并利用协商的反向音频传输端口与车载设备进行音频数据的传输，从而实现了车载设备与源设备之间的反向乃至双向音频数据的传输，解决了现有多屏互动技术，如Miracast技术不支持车载设备与源设备之间的反向乃至双向音频数据传输的车载应用场景的问题，扩展了多屏互动技术，如Miracast技术的使用场景。另外，本发明实施例所述技术方案可兼容现有多屏互动协议，如Miracast1.0规范，改进点小，还具有容易实现等优点。

实施例二

本发明实施例二以车载设备为动作执行方为例，对本发明实施例一中所述数据传输方法进行进一步说明，如图2所示，其为本发明实施例二所述的数据传输方法的流程示意图，所述方法可包括以下步骤：

步骤201：车载设备与源设备进行反向音频传输能力的协商。

具体地，以Miracast技术为例，所述车载设备与所述源设备可以在现有Miracast1.0规范定义的能力协商阶段进行反向音频传输能力的协商，并且，参照Miracast1.0规范中所涉及到的source和sink之间协商相应扩展能力的流程可知，所述反向音频传输能力的具体协商流程可包括：

接收所述源设备发送的携带有第一标识的第一扩展能力协商消息，所述第一标识用于表示所述车载设备是否具有反向音频传输能力；若根据所述第一扩展能力协商消息中携带的所述第一标识确定所述源设备支持反向音频传输能力，且根据所述车载设备自身所具备的扩展能力确定自身也支持反向音频传输能力，则确定所述车载设备与所述源设备均支持反向音频传输能力；若根据所述第一扩展能力协商消息中携带的所述第一标识确定所述源设备不支持反向音频传输能力，或，根据所述车载设备自身所具备的扩展能力确定自身不支持反向音频传输能力，则确定所述车载设备与所述源设备并非均支持反向音频传输能力；

或者，

向所述源设备发送携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力，以由所述源设备根据所述第二扩展能力协商消息中携带的所述第二标识以及所述源设备自身所具备的扩展能力，判断所述车载设备与所述源设备是否均支持反向音频传输能力；以及，若接收到所述源设备返回的用于表示所述车载设备与所述源设备均支持反向音频传输能力的响应消息，则确定所述车载设备与所述源设备均支持反向音频传输能力，否则，则确定所述车载设备与所述源设备并非均支持反向音频传输能力。

也就是说，车载设备在与源设备进行反向音频传输能力的协商时，可采用由车载设备执行判断二者是否均支持反向音频传输能力的操作的判断方式，也可采用由源设备执行判断二者是否均支持反向音频传输能力的操作的判断方式，本发明实施例对此不作任何限定。

另外需要说明的是，车载设备在与源设备进行反向音频传输能力的协商之前，可首先判断自身是否支持反向音频传输能力，在确定自身支持反向音频传输能力后，再执行后续的反向音频传输能力协商过程，本发明实施例对此不作赘述。

再有需要说明的是，以Miracast技术为例，车载设备在与源设备进行反向音频传输能力的协商之前，通常还可先执行相应的设备发现流程。具体地，与现有技术不同的是，在本发明实施例的设备发现阶段，车载设备与源设备可在设备发现阶段的广播消息或广播帧中增加相关的信息来标识自己是否支持反向音频传输能力，以便对应的源设备或车载设备能够根据该增加的相关信息来发现周围具备相应反向音频传输能力的设备，本发明实施例对此不作赘述。

进一步地，与本发明实施例一中的相关描述相同，以Miracast技术为例，所述第一、第二扩展能力协商消息可为现有Miracast1.0规范中用来协商source和sink所支持的扩展能力的WFD Extended Capabilities消息。也就是说，为了兼容现有Miracast1.0规范，使得对其所进行的修改尽量小，在本发明所述实施例中，可在Miracast1.0规范所定义的用来协商source和sink所支持的扩展能力的WFD Extended Capabilities消息中携带相应的、用于表示相应设备是否具有反向音频传输能力的标识信息，如第一标识或第二标识。

具体地，如实施例一中表1所示的WFD Extended Capabilities Bitmap可知，WFDExtended Capabilities消息所对应的消息域中存在多个尚未使用的设定保留位(如第6-15位)，因此，可考虑对上述设定保留位中的一位(如第6位等)进行扩展，以将其作为反向音频数据传输能力支持位。即，所述第一标识具体可通过所述第一扩展能力协商消息所对应的消息域中的该设定保留位的具体取值来表示，如当所述第一标识用于表示相应设备不支持反向音频传输能力时，该设定保留位的取值可为0b0，当所述第一标识用于表示相应设备支持反向音频传输能力时，该设定保留位的取值可为0b1；所述第二标识具体可通过所述第二扩展能力协商消息所对应的消息域中的该设定保留位的具体取值来表示，如当所述第二标识用于表示相应设备不支持反向音频传输能力时，该设定保留位的取值可为0b0，当所述第二标识用于表示相应设备支持反向音频传输能力时，该设定保留位的取值可为0b1，本发明实施例对此不作赘述。

步骤202：所述车载设备若确定自身与所述源设备均支持反向音频传输能力，则与所述源设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述源设备进行音频数据的传输。

具体地，以Miracast技术为例，车载设备与源设备可以在现有Miracast1.0规范所定义的能力协商阶段进行反向音频传输端口的协商，并且，参照Miracast1.0规范中所涉及到的source和sink之间协商从source向sink传输音视频数据时所使用的音视频数据端口的流程可知，所述反向音频传输端口的具体协商流程可以如步骤B1-B4所述：

步骤B1：接收所述源设备发送的参数获取请求消息，所述参数获取请求消息中携带有用于协商反向音频传输端口号的反向端口号协商参数域。

其中，所述参数获取请求消息可以是M3 request消息，且该参数获取请求消息中携带的反向端口号协商参数域可以是wfd-reverse-audio-port参数域，另外，所述wfd-reverse-audio-port参数域的具体定义可参见实施例一中的相关所述，重复之处不再赘述。

步骤B2：根据接收到的所述参数获取请求消息向所述源设备返回参数获取响应消息，所述参数获取响应消息中携带有添加有所述车载设备所支持的反向音频传输端口号的反向端口号协商参数域。

具体地，所述参数获取响应消息可为M3 response消息，本发明实施例对此不作赘述。

步骤B3：接收所述源设备根据所述参数获取响应消息所返回的参数设置请求消息，所述参数设置请求消息中携带有添加有所述源设备所选取的反向音频传输端口号的反向端口号协商参数域；其中，所述源设备所选取的反向音频传输端口号是所述源设备从所述车载设备所支持的反向音频传输端口号中所选取的。

具体地，所述参数设置请求消息可以是M4 request消息，本发明实施例对此不作赘述。

步骤B4：根据所述参数设置请求消息中携带的反向音频传输端口号，确定与所述源设备所协商的反向音频传输端口号。

至此，即可实现反向音频传输端口号的协商。

进一步地，需要说明的是，在协商反向音频传输端口号之后，所述车载设备可通过协商的反向音频传输端口号与对应的源设备进行音频数据的传输，以Miracast技术为例，具体的数据传输流程可与现有Miracast 1.0规范的数据传输过程类似，本发明实施例对此不作赘述。

也就是说，在本发明实施例二所述技术方案中，车载设备可与源设备进行反向音频传输能力的协商，并在确定二者均支持反向音频传输能力后，与源设备协商用于传输音频数据的反向音频传输端口并利用协商的反向音频传输端口与源设备进行音频数据的传输，从而实现了车载设备与源设备之间的反向乃至双向音频数据的传输，解决了现有多屏互动技术，如Miracast技术不支持车载设备与源设备之间的反向乃至双向音频数据传输的车载应用场景的问题，扩展了多屏互动技术，如Miracast技术的使用场景。另外，本发明实施例所述技术方案可兼容现有多屏互动协议，如Miracast1.0规范，改进点小，还具有容易实现等优点。

实施例三

本发明实施例三以源设备以及车载设备交互执行为例，对本发明实施例一或实施例二中所述数据传输方法进行进一步说明，如图3所示，其为本发明实施例三所述数据传输方法的流程示意图，所述方法可包括以下步骤：

步骤301：源设备向车载设备发送携带有第一标识的第一扩展能力协商消息，所述第一标识用于表示所述源设备是否具有反向音频传输能力。

其中，以Miracast技术为例，所述第一扩展能力协商消息可为现有Miracast1.0规范中用来协商source和sink所支持的扩展能力的WFD Extended Capabilities消息。并且，为了兼容现有Miracast1.0规范，使得对其所进行的修改尽量小，在本发明所述实施例中，所述第一标识具体可通过所述第一扩展能力协商消息所对应的消息域中的设定保留位的具体取值来表示，如当所述第一标识用于表示相应设备不支持反向音频传输能力时，该设定保留位的取值可为0b0，当所述第一标识用于表示相应设备支持反向音频传输能力时，该设定保留位的取值可为0b1，本发明实施例对此不作赘述。

步骤302：车载设备接收所述第一扩展能力协商消息，并根据所述第一扩展能力协商消息中携带的第一标识以及自身所具有的扩展能力确定源设备与车载设备二者是否均支持反向音频传输能力，若是，则执行步骤303，若否，则可向源设备返回用于表示所述源设备与所述车载设备并非均支持反向音频传输能力的响应消息，以使得所述源设备根据该响应消息，结束本次反向音频传输能力协商流程。

步骤303：车载设备向源设备返回用于表示所述源设备与所述车载设备均支持反向音频传输能力的响应消息。

至此，即可实现车载设备与源设备之间的反向音频传输能力的协商。

进一步地，若确定源设备与车载设备均支持反向音频传输能力，则继续执行以下步骤以进行反向音频传输端口的协商：

步骤304：源设备向车载设备发送参数获取请求消息，所述参数获取请求消息中携带有用于协商反向音频传输端口号的反向端口号协商参数域。

步骤305：车载设备接收所述参数获取请求消息，并根据所述参数获取请求消息向所述源设备返回参数获取响应消息，所述参数获取响应消息中携带有添加有所述车载设备所支持的反向音频传输端口号的反向端口号协商参数域。

步骤306：源设备根据所述参数获取响应消息，向所述车载设备返回参数设置请求消息，所述参数设置请求消息中携带有添加有所述源设备所选取的反向音频传输端口号的反向端口号协商参数域；其中，所述源设备所选取的反向音频传输端口号是所述源设备从所述车载设备所支持的反向音频传输端口号中所选取的。

步骤307：车载设备接收所述参数设置请求消息，并根据所述参数设置请求消息中携带的反向音频传输端口号，确定与所述源设备所协商的反向音频传输端口号。

至此，即可实现反向音频传输端口号的协商。

进一步地，需要说明的是，在协商反向音频传输端口号之后，所述源设备与所述车载设备可通过协商的反向音频传输端口号进行音频数据的传输，以Miracast技术为例，具体的数据传输流程可与现有Miracast 1.0规范的数据传输过程类似，本发明实施例对此不作赘述。

另外，需要说明的是，源设备在与车载设备进行反向音频传输能力的协商时，除了可采用上述步骤301～步骤304所述的由车载设备执行判断二者是否均支持反向音频传输能力的操作的判断方式之外，也可采用由所述源设备执行判断二者是否均支持反向音频传输能力的操作的判断方式，此时，所对应的反向音频传输能力的协商流程可包括以下步骤：

步骤S1：源设备接收车载设备发送的携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力。

其中，以Miracast技术为例，所述第二扩展能力协商消息可为现有Miracast1.0规范中用来协商source和sink所支持的扩展能力的WFD Extended Capabilities消息。并且，为了兼容现有Miracast1.0规范，使得对其所进行的修改尽量小，在本发明所述实施例中，所述第二标识具体可通过所述第二扩展能力协商消息所对应的消息域中的设定保留位的具体取值来表示，如当所述第二标识用于表示相应设备不支持反向音频传输能力时，该设定保留位的取值可为0b0，当所述第二标识用于表示相应设备支持反向音频传输能力时，该设定保留位的取值可为0b1，本发明实施例对此不作赘述。

步骤S2：源设备根据所述第二扩展能力协商消息中携带的第二标识以及自身所具有的扩展能力确定二者是否均支持反向音频传输能力，若是，则执行步骤S3，若否，则可向车载设备返回用于表示所述源设备与所述车载设备并非均支持反向音频传输能力的响应消息，并结束本次反向音频传输能力协商流程。

步骤S3：源设备向车载设备返回用于表示所述车载设备与所述源设备均支持反向音频传输能力的响应消息，以完成本次反向音频传输能力的协商。

也就是说，在本发明实施例三所述技术方案中，源设备可与车载设备进行反向音频传输能力的协商，并在确定二者均支持反向音频传输能力后，与车载设备协商用于传输音频数据的反向音频传输端口并利用协商的反向音频传输端口与车载设备进行音频数据的传输，从而实现了车载设备与源设备之间的反向乃至双向音频数据的传输，解决了现有多屏互动技术，如Miracast技术不支持车载设备与源设备之间的反向乃至双向音频数据传输的车载应用场景的问题，扩展了多屏互动技术，如Miracast技术的使用场景。另外，本发明实施例所述技术方案可兼容现有多屏互动协议，如Miracast1.0规范，改进点小，还具有容易实现等优点。

实施例四

为了支持车载设备对源设备的反向控制，本发明实施例四提供了一种反向控制方法，如图4所示，其为本发明实施例四所述反向控制方法的流程示意图，所述方法可包括以下步骤：

步骤401：源设备若确定自身支持车载控制设备类型，则向周围各设备广播携带有用于表示所述源设备支持车载控制设备类型的标识的反向输入能力消息。

其中，所述用于表示所述源设备支持车载控制设备类型的标识可位于所述反向输入能力消息的类型域内。具体地，以Miracast技术为例，所述反向输入能力消息可以是Miracast1.0规范中所定义的wfd-uibc-capability消息、其类型域可以是inp-type。

也就是说，以Miracast技术为例，为了兼容现有Miracast1.0规范，使得对其所进行的修改尽量小，在本发明所述实施例中，可通过修改wfd-uibc-capability消息的方式，来在其所对应的类型域内增加相应的车载控制设备类型，以使得sink可根据所述wfd-uibc-capability消息中是否携带有用于表示所述源设备支持车载反向控制设备类型的标识，来确定源设备是否支持车载控制设备类型。

具体地，wfd-uibc-capability消息的原有inp-type域内已添加有可支持的反向控制设备类型，如“Keyboard”、“Mouse”、“SingleTouch”、“MultiTouch”、“Joystick”、“Camera”、“Gesture”或“RemoteControl”等，在此基础上可在inp-type域内新添加“Carkit”或其他与车载控制设备类型相关的标识来标识源设备支持车载控制设备类型，本发明实施例对此不作赘述。

步骤402：若接收到任一车载设备发送的携带有车载反向控制信息的反向控制通用消息，则根据所述反向控制通用消息中携带的所述车载反向控制信息执行相应的控制操作。

其中，以Miracast技术为例，所述反向控制通用消息可以是现有Miracast1.0规范中定义的Generic input消息，即为了兼容现有Miracast1.0规范，使得对其所进行的修改尽量小，在本发明所述实施例中，可通过对Generic input消息进行修改，来使其能够携带相应的车载反向控制信息。

具体地，依据表2所示的现有Miracast1.0规范中Generic input消息的消息体所具备的格式可知，所述Generic input消息中所携带的各输入设备所对应的控制信息通常可以包括所述控制信息所对应的通用输入类型标识以及所述控制信息的具体信息描述等，因此，相应地，修改后的Generic input消息中所携带的所述车载反向控制信息通常也可以包括所述车载反向控制信息所对应的通用输入类型标识以及所述车载反向控制信息的具体信息描述等，本发明实施例对此不作赘述。

表2：Generic input消息的消息体所具备的格式

表3：现有Miracast1.0规范中定义的各可能的通用数据类型

进一步地，为了兼容现有Miracast1.0规范，使得对其所进行的修改尽量小，在本发明所述实施例中，所述车载反向控制信息所对应的通用输入类型标识可位于所述反向控制通用消息的通用输入类型标识域(即Generic Input Type ID域)内，所述车载反向控制信息的具体信息描述可位于所述反向控制通用消息的描述域(即Describe域)内。并且，进一步地，所述车载反向控制信息所对应的通用输入类型标识具体可通过所述反向控制通用消息的通用输入类型标识域的设定保留位所对应的位标识来表示。如，可对所述反向控制通用消息的通用输入类型标识域的第9设定保留位(即对应的位标识为9的保留位)进行扩展，来使其所对应的位标识用以表示车载反向控制信息所对应的通用输入类型。具体地，在对所述第9设定保留位(即对应的位标识为9的保留位)进行扩展时，可将所述第9设定保留位的相关解释(即Notes)设置为Carkit，本发明实施例对此不作赘述。

进一步地，所述车载反向控制信息的具体信息描述可包括以下信息中的一种或多种：

用于表示所述车载反向控制信息的控制按键类型为按键或旋钮(knob)的控制按键类型信息，即，Keytype信息；具体地，当所述Keytype的取值为1时，可表示控制按键类型为按键，当所述Keytype的取值为2时，可表示控制按键类型为旋钮；

用于表示所述车载反向控制信息的控制按键动作的控制按键动作信息，即Keyvalue1信息；其中，当所述车载反向控制信息的控制按键类型为按键时，所述控制按键动作信息可用于表示所述车载反向控制信息的控制按键动作为按下或抬起，此时，其具体取值可为1、2等，其中，取值为1时，可表示按下，取值为2时可表示抬起；当所述车载反向控制信息的控制按键类型为旋钮时，所述控制按键动作信息可用于表示所述车载反向控制信息的控制按键动作为顺时针旋转或逆时针旋转，此时，其取值可表示旋钮旋转的角度的整数部分，并且，当其取值为正值时可表示逆时针旋转，当其取值为负值时可表示顺时针旋转，也就是说，此时，Keyvalue1的具体取值可根据旋扭的实际旋转情况而定，并且，此时，Keyvalue1除了可表示是否顺时针旋转之外，还可表示旋转的整数角度，本发明实施例对此不作任何限定；

当所述车载反向控制信息的控制按键类型为按键时，用于表示所述车载反向控制信息所对应的具体按键的按键信息，即Keycode信息；具体地，Keycode的取值可根据实际按键的取值而定，本发明实施例对此不作赘述，如当Keycode的取值为1时，表示按键1，当其取值为2时，表示按键2等；或者，

当所述车载反向控制信息的控制按键类型为旋钮时，用于表示所述车载反向控制信息所对应的具体旋转角度(通常为旋转角度的小数部分)的旋转角度信息，即Keyvalue2；具体地，Keyvalue2的具体取值可根据旋扭的实际旋转情况而定，本发明实施例对此不作任何限定。

进一步地，根据上述描述可知，在本发明所述实施例中，所述车载反向控制信息的具体信息描述在Describe域内的消息结构具体可如以下表4所示：

表4：车载反向控制信息的具体信息描述的消息结构

相应地，若接收到任一车载设备发送的携带有车载反向控制信息的反向控制通用消息，则根据所述反向控制通用消息中携带的所述车载反向控制信息执行相应的控制操作，可以包括：

根据所述车载反向控制信息所对应的通用输入类型标识，确定本次反向控制的输入设备类型为车载设备，并根据所述车载反向控制信息的具体信息描述，执行相应的控制操作，如发送或停止发送音频数据给相应的车载设备，或者升高或降低发送给相应车载设备的音频数据的声音大小等。

也就是说，在本发明实施例四所述技术方案中，源设备可在确定自身支持车载控制设备类型时，向周围各设备广播携带有用于表示自身支持车载控制设备类型的标识的反向输入能力消息，以由周围各车载设备在根据所述反向输入能力消息，确定源设备支持车载控制设备类型时，通过向源设备发送携带有相应车载反向控制信息的反向控制通用消息的方式对源设备进行反向控制，从而实现了车载设备对源设备的反向控制，解决了现有多屏互动技术，如Miracast技术不支持车载设备对源设备的反向控制的车载应用场景的问题，进一步扩展了多屏互动技术，如Miracast技术的使用场景。另外，本发明实施例所述技术方案可兼容现有多屏互动协议，如Miracast1.0规范，改进点小，还具有容易实现等优点。

实施例五

本发明实施例五以车载设备为动作执行方为例，对本发明实施例四中所述反向控制方法进行进一步说明，如图5所示，其为本发明实施例五所述反向控制方法的流程示意图，所述方法可包括以下步骤：

步骤501：车载设备接收源设备广播的反向输入能力消息。

其中，当所述源设备支持车载控制设备类型时，所述反向输入能力消息，如wfd-uibc-capability消息中可携带有用于表示所述源设备支持车载控制设备类型的标识，如Carkit等。具体地，所述用于表示所述源设备支持车载控制设备类型的标识通常可位于所述反向输入能力消息的类型域(即int-type域)内。

步骤502：若确定所述反向输入能力消息中携带有用于表示所述源设备支持车载控制设备类型的标识且确定自身需对源设备进行反向控制，则向所述源设备发送携带有车载反向控制信息的反向控制通用消息，以指示所述源设备根据所述车载反向控制信息执行相应的控制操作。

其中，所述反向控制通用消息可以是Generic input消息，且所述Generic input消息中所携带的所述车载反向控制信息通常可以包括所述车载反向控制信息所对应的通用输入类型标识以及所述车载反向控制信息的具体信息描述等，本发明实施例对此不作赘述。

具体地，所述车载反向控制信息所对应的通用输入类型标识可位于所述反向控制通用消息的通用输入类型标识域(即Generic Input Type ID域)内，所述车载反向控制信息的具体信息描述可位于所述反向控制通用消息的描述域(即Describe域)内。并且，进一步地，所述车载反向控制信息所对应的通用输入类型标识具体可通过所述反向控制通用消息的通用输入类型标识域的设定保留位(如第9保留位)所对应的位标识来表示，本发明实施例对此不作赘述。

进一步地，所述车载反向控制信息的具体信息描述可包括以下信息中的一种或多种：

用于表示所述车载反向控制信息的控制按键类型为按键或旋钮(knob)的控制按键类型信息；

用于表示所述车载反向控制信息的控制按键动作的控制按键动作信息；其中，当所述车载反向控制信息的控制按键类型为按键时，所述控制按键动作信息可用于表示所述车载反向控制信息的控制按键动作为按下或抬起；当所述车载反向控制信息的控制按键类型为旋钮时，所述控制按键动作信息可用于表示所述车载反向控制信息的控制按键动作为顺时针旋转或逆时针旋转；

当所述车载反向控制信息的控制按键类型为按键时，用于表示所述车载反向控制信息所对应的具体按键的按键信息；或者，

当所述车载反向控制信息的控制按键类型为旋钮时，用于表示所述车载反向控制信息所对应的具体旋转角度(通常为旋转角度的小数部分)的旋转角度信息。

再有，所述车载反向控制信息的具体信息描述在Describe域内的消息结构具体可如实施例四中的表4所示，本发明实施例对此不作赘述。

在本发明实施例五所述技术方案中，车载设备可在确定源设备广播的反向输入能力消息中携带有用于表示所述源设备支持车载控制设备类型的标识且确定自身需对源设备进行反向控制时，向所述源设备发送携带有车载反向控制信息的反向控制通用消息，以指示所述源设备根据所述车载反向控制信息执行相应的控制操作，从而实现了车载设备对源设备的反向控制，解决了现有多屏互动技术，如Miracast技术不支持车载设备对源设备的反向控制的车载应用场景的问题，进一步扩展了多屏互动技术，如Miracast技术的使用场景。另外，本发明实施例所述技术方案可兼容现有多屏互动协议，如Miracast1.0规范，改进点小，还具有容易实现等优点。

实施例六

本发明实施例六以源设备以及车载设备交互执行为例，对本发明实施例四或实施例五中所述反向控制方法进行进一步说明，如图6所示，其为本发明实施例六所述反向控制方法的流程示意图，所述方法可包括以下步骤：

步骤601：源设备若确定自身支持车载控制设备类型，则向周围各设备广播携带有用于表示自身支持车载控制设备类型的标识的反向输入能力消息。

其中，所述用于表示所述源设备支持车载控制设备类型的标识可位于所述反向输入能力消息的类型域内。

步骤602：车载设备接收所述源设备广播的反向控制能力消息，并根据所述反向控制能力消息中携带的用于表示所述源设备支持车载控制设备类型的标识，确定所述源设备支持车载反向控制设备类型。

步骤603：车载设备若确定自身需对所述源设备进行反向控制(即存在进行反向控制的需求)，则向所述源设备发送携带有相应的车载反向控制信息的反向控制通用消息。

其中，所述车载反向控制信息可包括所述车载反向控制信息所对应的通用输入类型标识以及所述车载反向控制信息的具体信息描述。且，所述车载反向控制信息所对应的通用输入类型标识可位于所述反向控制通用消息的通用输入类型标识域内，所述车载反向控制信息的具体信息描述可位于所述反向控制通用消息的描述域内。

再有，根据实施例四或实施例五的相关描述克制，所述车载反向控制信息的具体信息描述可包括以下信息中的一种或多种：

用于表示所述车载反向控制信息的控制按键类型为按键或旋钮的控制按键类型信息；

用于表示所述车载反向控制信息的控制按键动作的控制按键动作信息；其中，当所述车载反向控制信息的控制按键类型为按键时，所述控制按键动作信息用于表示所述车载反向控制信息的控制按键动作为按下或抬起；当所述车载反向控制信息的控制按键类型为旋钮时，所述控制按键动作信息用于表示所述车载反向控制信息的控制按键动作为顺时针旋转或逆时针旋转；

当所述车载反向控制信息的控制按键类型为按键时，用于表示所述车载反向控制信息所对应的具体按键的按键信息；或，

当所述车载反向控制信息的控制按键类型为旋钮时，用于表示所述车载反向控制信息所对应的具体旋转角度的旋转角度信息。

步骤604：源设备根据车载设备发送的携带有车载反向控制信息的反向控制通用消息，执行相应的控制操作，如发送或停止发送音频数据给相应的车载设备，或者升高或降低发送给相应车载设备的音频数据的声音大小等。

具体地，所述源设备可根据所述车载反向控制信息所对应的通用输入类型标识，确定本次反向控制的输入设备类型为车载设备，并根据所述车载反向控制信息的具体信息描述，执行相应的控制操作。

也就是说，在本发明实施例六所述技术方案中，源设备可在确定自身支持车载控制设备类型时，向周围各设备广播携带有用于表示自身支持车载控制设备类型的标识的反向输入能力消息，以由周围各车载设备在根据所述反向输入能力消息，确定源设备支持车载控制设备类型时，通过向源设备发送携带有相应车载反向控制信息的反向控制通用消息的方式对源设备进行反向控制，从而实现了车载设备对源设备的反向控制，解决了现有多屏互动技术，如Miracast技术不支持车载设备对源设备的反向控制的车载应用场景的问题，进一步扩展了多屏互动技术，如Miracast技术的使用场景。另外，本发明实施例所述技术方案可兼容现有多屏互动协议，如Miracast1.0规范，改进点小，还具有容易实现等优点。

实施例七：

基于与本发明实施例一相同的发明构思，本发明实施例七提供了一种终端设备，所述终端设备可为手机或平板电脑等终端设备，且该终端设备的具体实施可参见上述方法实施例一中的相关描述，重复之处不再赘述。具体地，如图7所示，其为所述终端设备的结构示意图，所述终端设备具体可包括：

能力协商单元71，可用于与车载设备进行反向音频传输能力的协商；

端口协商单元72，可用于若确定所述终端设备与所述车载设备均支持反向音频传输能力，则与所述车载设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述车载设备进行音频数据的传输。

可选地，所述能力协商单元71具体可用于向所述车载设备发送携带有第一标识的第一扩展能力协商消息(如WFD Extended Capabilities消息)，所述第一标识用于表示所述终端设备是否具有反向音频传输能力，以由所述车载设备根据所述第一扩展能力协商消息中携带的所述第一标识以及所述车载设备自身所具备的扩展能力，判断所述终端设备与所述车载设备是否均支持反向音频传输能力；以及，若接收到所述车载设备返回的用于表示所述终端设备与所述车载设备均支持反向音频传输能力的响应消息，则确定所述终端设备与所述车载设备均支持反向音频传输能力，否则，则确定所述终端设备与所述车载设备并非均支持反向音频传输能力；或者，

具体可用于接收所述车载设备发送的携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备支持反向音频传输能力，且根据所述源设备自身所具备的扩展能力确定自身也支持反向音频传输能力，则确定所述源设备与所述车载设备均支持反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备不支持反向音频传输能力，或，根据所述源设备自身所具备的扩展能力确定自身不支持反向音频传输能力，则确定所述源设备与所述车载设备并非均支持反向音频传输能力。

其中，所述第一标识可通过所述第一扩展能力协商消息的消息域中的设定保留位的取值来表示；所述第二标识可通过所述第二扩展能力协商消息的消息域中的设定保留位的取值来表示。

进一步地，所述端口协商单元72具体可用于向所述车载设备发送参数获取请求消息，所述参数获取请求消息中携带有用于协商反向音频传输端口号的反向端口号协商参数域(如新定义的wfd-reverse-audio-port参数域)；并接收所述车载设备针对所述参数获取请求消息返回的参数获取响应消息，所述参数获取响应消息中携带有添加有所述车载设备所支持的反向音频传输端口号的反向端口号协商参数域；以及，根据所述参数获取响应消息，向所述车载设备返回参数设置请求消息，所述参数设置请求消息中携带有添加有所述终端设备所选取的反向音频传输端口号的反向端口号协商参数域，以告知所述车载设备二者所协商的反向音频传输端口号；其中，所述终端设备所选取的反向音频传输端口号是所述终端设备从所述车载设备所支持的反向音频传输端口号中所选取的。

进一步地，基于与本发明实施例二相同的发明构思，本发明实施例七还提供了一种车载设备，所述车载设备可为车载蓝牙或车载导航等设备，且该车载设备的具体实施可参见上述方法实施例二中的相关描述，重复之处不再赘述。具体地，如图8所示，其为所述车载设备的结构示意图，所述车载设备具体可包括：

能力协商单元81，可用于与源设备进行反向音频传输能力的协商；

端口协商单元82，可用于若确定所述车载设备与所述源设备均支持反向音频传输能力，则与所述源设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述源设备进行音频数据的传输。

可选地，所述能力协商单元81具体可用于接收所述源设备发送的携带有第一标识的第一扩展能力协商消息，所述第一标识用于表示所述车载设备是否具有反向音频传输能力；若根据所述第一扩展能力协商消息中携带的所述第一标识确定所述源设备支持反向音频传输能力，且根据所述车载设备自身所具备的扩展能力确定自身也支持反向音频传输能力，则确定所述车载设备与所述源设备均支持反向音频传输能力；若根据所述第一扩展能力协商消息中携带的所述第一标识确定所述源设备不支持反向音频传输能力，或，根据所述车载设备自身所具备的扩展能力确定自身不支持反向音频传输能力，则确定所述车载设备与所述源设备并非均支持反向音频传输能力；或者，

具体可用于向所述源设备发送携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力，以由所述源设备根据所述第二扩展能力协商消息中携带的所述第二标识以及所述源设备自身所具备的扩展能力，判断所述车载设备与所述源设备是否均支持反向音频传输能力；以及，若接收到所述源设备返回的用于表示所述车载设备与所述源设备均支持反向音频传输能力的响应消息，则确定所述车载设备与所述源设备均支持反向音频传输能力，否则，则确定所述车载设备与所述源设备并非均支持反向音频传输能力。

其中，所述第一标识可通过所述第一扩展能力协商消息的消息域中的设定保留位的取值来表示；所述第二标识可通过所述第二扩展能力协商消息的消息域中的设定保留位的取值来表示。

进一步地，所述端口协商单元82具体可用于接收所述源设备发送的参数获取请求消息，所述参数获取请求消息中携带有用于协商反向音频传输端口号的反向端口号协商参数域；并根据接收到的所述参数获取请求消息向所述源设备返回参数获取响应消息，所述参数获取响应消息中携带有添加有所述车载设备所支持的反向音频传输端口号的反向端口号协商参数域；以及，接收所述源设备根据所述参数获取响应消息所返回的参数设置请求消息，所述参数设置请求消息中携带有添加有所述源设备所选取的反向音频传输端口号的反向端口号协商参数域；其中，所述源设备所选取的反向音频传输端口号是所述源设备从所述车载设备所支持的反向音频传输端口号中所选取的；并根据所述参数设置请求消息中携带的反向音频传输端口号，确定与所述源设备所协商的反向音频传输端口号。

进一步地，基于与本发明实施例四相同的发明构思，本发明实施例七还提供了另一种终端设备，所述另一种终端设备可为手机或平板电脑等终端设备，且该另一种终端设备的具体实施可参见上述方法实施例四中的相关描述，重复之处不再赘述。具体地，如图9所示，其为所述另一种终端设备的结构示意图，所述另一种终端设备具体可包括：

发送单元91，可用于若确定所述终端设备支持车载控制设备类型，则向周围各设备广播携带有用于表示所述终端设备支持车载控制设备类型的标识的反向输入能力消息；其中，所述用于表示所述终端设备支持车载反向控制设备类型的标识可位于所述反向输入能力消息的类型域内；

接收单元92，可用于接收车载设备发送的携带有车载反向控制信息的反向控制通用消息；其中，所述车载反向控制信息可包括所述车载反向控制信息所对应的通用输入类型标识以及所述车载反向控制信息的具体信息描述，且所述车载反向控制信息所对应的通用输入类型标识位于所述反向控制通用消息的通用输入类型标识域内，所述车载反向控制信息的具体信息描述位于所述反向控制通用消息的描述域内；

处理单元93，可用于根据所述反向控制通用消息中携带的所述车载反向控制信息执行相应的控制操作。

另外需要说明的是，所述车载反向控制信息的具体信息描述可包括以下信息中的一种或多种：

用于表示所述车载反向控制信息的控制按键类型为按键或旋钮的控制按键类型信息；

用于表示所述车载反向控制信息的控制按键动作的控制按键动作信息；其中，当所述车载反向控制信息的控制按键类型为按键时，所述控制按键动作信息用于表示所述车载反向控制信息的控制按键动作为按下或抬起；当所述车载反向控制信息的控制按键类型为旋钮时，所述控制按键动作信息用于表示所述车载反向控制信息的控制按键动作为顺时针旋转或逆时针旋转；

当所述车载反向控制信息的控制按键类型为按键时，用于表示所述车载反向控制信息所对应的具体按键的按键信息；或，

当所述车载反向控制信息的控制按键类型为旋钮时，用于表示所述车载反向控制信息所对应的具体旋转角度的旋转角度信息。

进一步地，基于与本发明实施例五相同的发明构思，本发明实施例七还提供了另一种车载设备，所述另一种车载设备可为车载蓝牙或车载导航等设备，且该另一种车载设备的具体实施可参见上述方法实施例五中的相关描述，重复之处不再赘述。具体地，如图10所示，其为所述另一种车载设备的结构示意图，所述另一种车载设备具体可包括：

接收单元101，可用于接收源设备广播的反向输入能力消息；

处理单元102，用于若确定所述反向输入能力消息中携带有用于表示所述源设备支持车载控制设备类型的标识且确定自身需对所述源设备进行反向控制，则触发发送单元103向所述源设备发送携带有车载反向控制信息的反向控制通用消息；

发送单元103，可用于根据所述处理单元102的触发，向所述源设备发送携带有车载反向控制信息的反向控制通用消息，以指示所述源设备根据所述车载反向控制信息执行相应的控制操作。

其中，所述车载反向控制信息可包括所述车载反向控制信息所对应的通用输入类型标识以及所述车载反向控制信息的具体信息描述。

且，所述用于表示所述源设备支持车载控制设备类型的标识可位于所述反向输入能力消息的类型域内；所述车载反向控制信息所对应的通用输入类型标识可位于所述反向控制通用消息的通用输入类型标识域内，所述车载反向控制信息的具体信息描述可位于所述反向控制通用消息的描述域内。

另外需要说明的是，所述车载反向控制信息的具体信息描述可包括以下信息中的一种或多种：

用于表示所述车载反向控制信息的控制按键类型为按键或旋钮的控制按键类型信息；

用于表示所述车载反向控制信息的控制按键动作的控制按键动作信息；其中，当所述车载反向控制信息的控制按键类型为按键时，所述控制按键动作信息用于表示所述车载反向控制信息的控制按键动作为按下或抬起；当所述车载反向控制信息的控制按键类型为旋钮时，所述控制按键动作信息用于表示所述车载反向控制信息的控制按键动作为顺时针旋转或逆时针旋转；

当所述车载反向控制信息的控制按键类型为按键时，用于表示所述车载反向控制信息所对应的具体按键的按键信息；或，

当所述车载反向控制信息的控制按键类型为旋钮时，用于表示所述车载反向控制信息所对应的具体旋转角度的旋转角度信息。

进一步地，基于与本发明实施例一～三相同的发明构思，本发明实施例七还提供了一种数据传输***，该数据传输***的具体实施可参见上述方法实施例一～三中的相关描述，重复之处不再赘述。具体地，如图11所示，其为所述数据传输***的结构示意图，所述数据传输***具体可包括源设备111以及车载设备112，其中：

所述源设备111，可用于与所述车载设备112进行反向音频传输能力的协商，以及，若确定自身与所述车载设备112均支持反向音频传输能力，则与所述车载设备112协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述车载设备112进行音频数据的传输；

所述车载设备112，可用于与所述源设备111进行反向音频传输能力的协商，以及，若确定自身与所述源设备111均支持反向音频传输能力，则与所述源设备111协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述源设备111进行音频数据的传输。

进一步地，基于与本发明实施例四～六相同的发明构思，本发明实施例七还提供了一种反向控制***，所述反向控制***的具体实施可参见上述方法实施例四～六中的相关描述，重复之处不再赘述。具体地，如图12所示，其为所述反向控制***的结构示意图，所述反向控制***具体可包括源设备121以及车载设备122，其中：

所述源设备121，可用于若确定自身支持车载控制设备类型，则向周围各设备广播携带有用于表示所述源设备121支持车载控制设备类型的标识的反向输入能力消息；以及，若接收到任一车载设备122发送的携带有车载反向控制信息的反向控制通用消息，则根据所述反向控制通用消息中携带的所述车载反向控制信息执行相应的控制操作；

所述车载设备122，用于接收所述源设备121广播的反向输入能力消息，并若确定所述反向输入能力消息中携带有用于表示所述源设备121支持车载控制设备类型的标识且确定自身需对所述源设备121进行反向控制，则向所述源设备121发送携带有车载反向控制信息的反向控制通用消息，以指示所述源设备121根据所述车载反向控制信息执行相应的控制操作。

本发明实施例七提供了一种数据传输与反向控制相关设备及***，在本发明实施例七所述技术方案中，源设备可与车载设备进行反向音频传输能力的协商，并在确定二者均支持反向音频传输能力后，与车载设备协商用于传输音频数据的反向音频传输端口并利用协商的反向音频传输端口与车载设备进行音频数据的传输，从而实现了车载设备与源设备之间的反向乃至双向音频数据的传输，解决了现有多屏互动技术，如Miracast技术不支持车载设备与源设备之间的反向乃至双向音频数据传输的车载应用场景的问题，扩展了多屏互动技术，如Miracast技术的使用场景。

另外，在本发明实施例七所述技术方案中，源设备还可在确定自身支持车载控制设备类型时，向周围各设备广播携带有用于表示自身支持车载控制设备类型的标识的反向输入能力消息，以由周围各车载设备在根据所述反向输入能力消息，确定源设备支持车载控制设备类型时，通过向源设备发送携带有相应车载反向控制信息的反向控制通用消息的方式对源设备进行反向控制，从而实现了车载设备对源设备的反向控制，解决了现有多屏互动技术，如Miracast技术不支持车载设备对源设备的反向控制的车载应用场景的问题，进一步扩展了多屏互动技术，如Miracast技术的使用场景。

再有，由于本发明实施例七所述技术方案可兼容现有多屏互动协议，如Miracast1.0规范，改进点小，因而还具有容易实现等优点。

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

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

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

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

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

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

Claims (13)

1.一种数据传输方法，其特征在于，包括：

源设备与车载设备进行反向音频传输能力的协商；

若确定自身与所述车载设备均支持反向音频传输能力，则与所述车载设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述车载设备进行音频数据的传输；

源设备与车载设备进行反向音频传输能力的协商，包括：

向所述车载设备发送携带有第一标识的第一扩展能力协商消息，所述第一标识用于表示所述源设备是否具有反向音频传输能力，以由所述车载设备根据所述第一扩展能力协商消息中携带的所述第一标识以及所述车载设备自身所具备的扩展能力，判断所述源设备与所述车载设备是否均支持反向音频传输能力；以及，若接收到所述车载设备返回的用于表示所述源设备与所述车载设备均支持反向音频传输能力的响应消息，则确定所述源设备与所述车载设备均支持反向音频传输能力，否则，则确定所述源设备与所述车载设备并非均支持反向音频传输能力；

或者，

接收所述车载设备发送的携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备支持反向音频传输能力，且根据所述源设备自身所具备的扩展能力确定自身也支持反向音频传输能力，则确定所述源设备与所述车载设备均支持反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备不支持反向音频传输能力，或，根据所述源设备自身所具备的扩展能力确定自身不支持反向音频传输能力，则确定所述源设备与所述车载设备并非均支持反向音频传输能力。

2.如权利要求1所述的方法，其特征在于，

所述第一标识通过所述第一扩展能力协商消息的消息域中的设定保留位的取值来表示；

所述第二标识通过所述第二扩展能力协商消息的消息域中的设定保留位的取值来表示。

3.如权利要求1或2所述的方法，其特征在于，所述与所述车载设备协商用于传输音频数据的反向音频传输端口，包括：

向所述车载设备发送参数获取请求消息，所述参数获取请求消息中携带有用于协商反向音频传输端口号的反向端口号协商参数域；

接收所述车载设备针对所述参数获取请求消息返回的参数获取响应消息，所述参数获取响应消息中携带有添加有所述车载设备所支持的反向音频传输端口号的反向端口号协商参数域；

根据所述参数获取响应消息，向所述车载设备返回参数设置请求消息，所述参数设置请求消息中携带有添加有所述源设备所选取的反向音频传输端口号的反向端口号协商参数域，以告知所述车载设备二者所协商的反向音频传输端口号；其中，所述源设备所选取的反向音频传输端口号是所述源设备从所述车载设备所支持的反向音频传输端口号中所选取的。

4.一种数据传输方法，其特征在于，包括：

车载设备与源设备进行反向音频传输能力的协商；

若确定自身与所述源设备均支持反向音频传输能力，则与所述源设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述源设备进行音频数据的传输；

车载设备与源设备进行反向音频传输能力的协商，包括：

接收所述源设备发送的携带有第一标识的第一扩展能力协商消息，所述第一标识用于表示所述车载设备是否具有反向音频传输能力；若根据所述第一扩展能力协商消息中携带的所述第一标识确定所述源设备支持反向音频传输能力，且根据所述车载设备自身所具备的扩展能力确定自身也支持反向音频传输能力，则确定所述车载设备与所述源设备均支持反向音频传输能力；若根据所述第一扩展能力协商消息中携带的所述第一标识确定所述源设备不支持反向音频传输能力，或，根据所述车载设备自身所具备的扩展能力确定自身不支持反向音频传输能力，则确定所述车载设备与所述源设备并非均支持反向音频传输能力；

或者，

向所述源设备发送携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力，以由所述源设备根据所述第二扩展能力协商消息中携带的所述第二标识以及所述源设备自身所具备的扩展能力，判断所述车载设备与所述源设备是否均支持反向音频传输能力；以及，若接收到所述源设备返回的用于表示所述车载设备与所述源设备均支持反向音频传输能力的响应消息，则确定所述车载设备与所述源设备均支持反向音频传输能力，否则，则确定所述车载设备与所述源设备并非均支持反向音频传输能力。

5.如权利要求4所述的方法，其特征在于，

所述第一标识通过所述第一扩展能力协商消息的消息域中的设定保留位的取值来表示；

所述第二标识通过所述第二扩展能力协商消息的消息域中的设定保留位的取值来表示。

6.如权利要求4或5所述的方法，其特征在于，所述与所述源设备协商用于传输音频数据的反向音频传输端口，包括：

接收所述源设备发送的参数获取请求消息，所述参数获取请求消息中携带有用于协商反向音频传输端口号的反向端口号协商参数域；

根据接收到的所述参数获取请求消息向所述源设备返回参数获取响应消息，所述参数获取响应消息中携带有添加有所述车载设备所支持的反向音频传输端口号的反向端口号协商参数域；

接收所述源设备根据所述参数获取响应消息所返回的参数设置请求消息，所述参数设置请求消息中携带有添加有所述源设备所选取的反向音频传输端口号的反向端口号协商参数域；其中，所述源设备所选取的反向音频传输端口号是所述源设备从所述车载设备所支持的反向音频传输端口号中所选取的；

根据所述参数设置请求消息中携带的反向音频传输端口号，确定与所述源设备所协商的反向音频传输端口号。

7.一种终端设备，其特征在于，包括：

能力协商单元，用于与车载设备进行反向音频传输能力的协商；

端口协商单元，用于若确定所述终端设备与所述车载设备均支持反向音频传输能力，则与所述车载设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述车载设备进行音频数据的传输；

所述能力协商单元，具体用于向所述车载设备发送携带有第一标识的第一扩展能力协商消息，所述第一标识用于表示所述终端设备是否具有反向音频传输能力，以由所述车载设备根据所述第一扩展能力协商消息中携带的所述第一标识以及所述车载设备自身所具备的扩展能力，判断所述终端设备与所述车载设备是否均支持反向音频传输能力；以及，若接收到所述车载设备返回的用于表示所述终端设备与所述车载设备均支持反向音频传输能力的响应消息，则确定所述终端设备与所述车载设备均支持反向音频传输能力，否则，则确定所述终端设备与所述车载设备并非均支持反向音频传输能力；

或者，

具体用于接收所述车载设备发送的携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备支持反向音频传输能力，且根据所述终端设备自身所具备的扩展能力确定自身也支持反向音频传输能力，则确定所述终端设备与所述车载设备均支持反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备不支持反向音频传输能力，或，根据所述终端设备自身所具备的扩展能力确定自身不支持反向音频传输能力，则确定所述终端设备与所述车载设备并非均支持反向音频传输能力。

8.如权利要求7所述的终端设备，其特征在于，

所述第一标识通过所述第一扩展能力协商消息的消息域中的设定保留位的取值来表示；

所述第二标识通过所述第二扩展能力协商消息的消息域中的设定保留位的取值来表示。

9.如权利要求7或8所述的终端设备，其特征在于，

所述端口协商单元，具体用于向所述车载设备发送参数获取请求消息，所述参数获取请求消息中携带有用于协商反向音频传输端口号的反向端口号协商参数域；并

接收所述车载设备针对所述参数获取请求消息返回的参数获取响应消息，所述参数获取响应消息中携带有添加有所述车载设备所支持的反向音频传输端口号的反向端口号协商参数域；以及，

根据所述参数获取响应消息，向所述车载设备返回参数设置请求消息，所述参数设置请求消息中携带有添加有所述终端设备所选取的反向音频传输端口号的反向端口号协商参数域，以告知所述车载设备二者所协商的反向音频传输端口号；其中，所述终端设备所选取的反向音频传输端口号是所述终端设备从所述车载设备所支持的反向音频传输端口号中所选取的。

10.一种车载设备，其特征在于，包括：

能力协商单元，用于与源设备进行反向音频传输能力的协商；

端口协商单元，用于若确定所述车载设备与所述源设备均支持反向音频传输能力，则与所述源设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述源设备进行音频数据的传输；

所述能力协商单元，具体用于接收所述源设备发送的携带有第一标识的第一扩展能力协商消息，所述第一标识用于表示所述车载设备是否具有反向音频传输能力；若根据所述第一扩展能力协商消息中携带的所述第一标识确定所述源设备支持反向音频传输能力，且根据所述车载设备自身所具备的扩展能力确定自身也支持反向音频传输能力，则确定所述车载设备与所述源设备均支持反向音频传输能力；若根据所述第一扩展能力协商消息中携带的所述第一标识确定所述源设备不支持反向音频传输能力，或，根据所述车载设备自身所具备的扩展能力确定自身不支持反向音频传输能力，则确定所述车载设备与所述源设备并非均支持反向音频传输能力；

或者，

具体用于向所述源设备发送携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力，以由所述源设备根据所述第二扩展能力协商消息中携带的所述第二标识以及所述源设备自身所具备的扩展能力，判断所述车载设备与所述源设备是否均支持反向音频传输能力；以及，若接收到所述源设备返回的用于表示所述车载设备与所述源设备均支持反向音频传输能力的响应消息，则确定所述车载设备与所述源设备均支持反向音频传输能力，否则，则确定所述车载设备与所述源设备并非均支持反向音频传输能力。

11.如权利要求10所述的车载设备，其特征在于，

所述第一标识通过所述第一扩展能力协商消息的消息域中的设定保留位的取值来表示；

所述第二标识通过所述第二扩展能力协商消息的消息域中的设定保留位的取值来表示。

12.如权利要求10或11所述的车载设备，其特征在于，

所述端口协商单元，具体用于接收所述源设备发送的参数获取请求消息，所述参数获取请求消息中携带有用于协商反向音频传输端口号的反向端口号协商参数域；并

根据接收到的所述参数获取请求消息向所述源设备返回参数获取响应消息，所述参数获取响应消息中携带有添加有所述车载设备所支持的反向音频传输端口号的反向端口号协商参数域；以及，

接收所述源设备根据所述参数获取响应消息所返回的参数设置请求消息，所述参数设置请求消息中携带有添加有所述源设备所选取的反向音频传输端口号的反向端口号协商参数域；其中，所述源设备所选取的反向音频传输端口号是所述源设备从所述车载设备所支持的反向音频传输端口号中所选取的；并根据所述参数设置请求消息中携带的反向音频传输端口号，确定与所述源设备所协商的反向音频传输端口号。

13.一种数据传输***，其特征在于，所述***包括源设备以及车载设备，其中：

所述源设备，用于与所述车载设备进行反向音频传输能力的协商，以及，若确定自身与所述车载设备均支持反向音频传输能力，则与所述车载设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述车载设备进行音频数据的传输；

所述车载设备，用于与所述源设备进行反向音频传输能力的协商，以及，若确定自身与所述源设备均支持反向音频传输能力，则与所述源设备协商用于传输音频数据的反向音频传输端口，并利用协商的反向音频传输端口与所述源设备进行音频数据的传输；

源设备与车载设备进行反向音频传输能力的协商，包括：

向所述车载设备发送携带有第一标识的第一扩展能力协商消息，所述第一标识用于表示所述源设备是否具有反向音频传输能力，以由所述车载设备根据所述第一扩展能力协商消息中携带的所述第一标识以及所述车载设备自身所具备的扩展能力，判断所述源设备与所述车载设备是否均支持反向音频传输能力；以及，若接收到所述车载设备返回的用于表示所述源设备与所述车载设备均支持反向音频传输能力的响应消息，则确定所述源设备与所述车载设备均支持反向音频传输能力，否则，则确定所述源设备与所述车载设备并非均支持反向音频传输能力；

或者，

接收所述车载设备发送的携带有第二标识的第二扩展能力协商消息，所述第二标识用于表示所述车载设备是否具有反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备支持反向音频传输能力，且根据所述源设备自身所具备的扩展能力确定自身也支持反向音频传输能力，则确定所述源设备与所述车载设备均支持反向音频传输能力；若根据所述第二扩展能力协商消息中携带的所述第二标识确定所述车载设备不支持反向音频传输能力，或，根据所述源设备自身所具备的扩展能力确定自身不支持反向音频传输能力，则确定所述源设备与所述车载设备并非均支持反向音频传输能力。