蓝牙车载产品的兼容性设计

　　引言

　　蓝牙技术问世10余年，得到了广泛应用，其中部分原因在于蓝牙SIG组织为各种应用以Profile的形式定义了应用协议，这样蓝牙设备之间的互操作便有章可循，但即使如此，蓝牙设备之间的互操作性又称兼容性问题仍存在于几乎所有蓝牙应用中。笔者历时两年时间为某合资汽车厂商开发了一款蓝牙车载产品，实现了免提通话、双重呼叫管理、电话本自动下载与手动下载、流媒体音乐播放及远程控制功能，期间测试了近100部手机和音乐播放器，遇到并解决了各种兼容性问题。结合产品开发过程中测试并解决兼容性问题的经验，本文对兼容性问题出现的原因进行了分析，大致有以下三个方面的原因：具体应用本身定义不严格、应用上下文差异、引入协议带来的兼容性。以下就这三个方面进行详细分析并结合具体实例，说明其解决方法。

　　应用定义不严格

　　蓝牙SIG组织定义了Profile，对各种功能的实现方式做了规范，并且定义了必选功能和可选功能，设备厂商可以对可选项有选择得实现，这样便会造成一定的差异。而且Profile并没有对应用本身做严格定义，只是定义了功能，而应用是功能的集合体，Profile并没有定义怎么由多个功能组合实现某个应用，这样蓝牙设备厂商在实现某一应用时便有了差异性。双重呼叫是车载设备免提通话应用中兼容性最多的一种应用，下面分析下该应用出现兼容性问题的原因并举例剖析其解决方法。

　　对于免提通话而言，比较重要的几个功能是呼叫建立提示CALL_SETUP、呼叫保持CALL_HELD、呼叫结果CALL、呼叫信息CLCC，手机在呼叫状态产生变化时实时向免提设备端传送这些提示消息，免提设备端便可以与手机的呼叫状态保持一致，在免提设备端控制呼叫才符合预期。其中CALL_SETUP和CALL是必选功能，但对于双重呼叫而言非常重要的CALL_HELD和CLCC却是可选功能，双重呼叫在免提剖面HFP(Hands-Free Profile)中定义为Three way calling，这也是一个可选功能。这样在支持双重呼叫时，各种手机便以自己的方式来支持或者部分支持，这样便来了双重呼叫的兼容性问题。下面以第二个呼叫为呼出为例剖析解决方法。

　　当拨打第二个电话时，手机会发送CALL_SETUP=2消息，表示正在呼出，结果有对方拒接、对方接听、未拨通这么几种情况。显然判断出呼出结果是至关重要的，我们通过对手机进行测试然后根据其表现特性进行分类，将手机分为如下几类：A-支持CALL_HELD不支持CLCC、B-支持CALL_HELD和CLCC、C-支持CLCC不支持CALL_HELD而且手机在Three way calling下不支持CALL、D-支持CLCC不支持CALL_HELD但手机在Three way calling下支持CALL、E-不支持CALL_HELD也不支持CLCC但手机在Three way calling下支持CALL、F-不支持CALL_HELD也不支持CLCC而且手机Three way calling下不支持CALL。

　　对于支持CALL_HELD消息的AB类手机而言，我们可以通过CALL_HELD来判断呼出结果，CALL_HELD=1表示对方接听，CALL_HELD=0则表示对方拒接或未拨通;对于支持CLCC的CD类手机而言，如果手机在Three way calling下支持CALL，CALL=1则表示对方接听，如果没有CALL消息说明对方拒接或未拨通，这时需要在CALL_SETUP=0时读取手机当前的呼叫信息，然后根据该呼叫信息更新免提设备端的呼叫状态;对于不支持CLCC和CALL_HELD的EF类手机而言，如果手机在Three way calling下支持CALL，CALL=1则表示对方接听，否则在CALL_SETUP=0时默认将呼叫结果处理为对方拒接，即这个时候无法判断呼出结果。

　　应用上下文差异

　　蓝牙是个对时间特性要求很严格的应用，每种蓝牙行为及其每个阶段必须在相应时间内完成，否则可能造成失败或者长时间无法响应。应用的上下文是指在某个蓝牙行为完成后，下面将要进行什么样的蓝牙行为，它是由蓝牙设备的应用决定的，同类产品在应用上的差异便会带来应用上下文上的差异，这样便可能会带来兼容性问题。比如在蓝牙车载设备与蓝牙手机互操作完成配对后，当车载设备实现配对后的自动连接时，便由于手机在配对完成后的处理有所不同而遇到了兼容性问题。车载设备实现了配对后的自动连接功能，在配对完成后车载设备读取外部设备的SDP进行服务查询以判断外部设备类型(包括免提、音频流、免提+音频流三种类型)然后自动连接其免提或音频流服务，结果造成部分手机读取SDP失败、部分手机自动连接失败、部分手机处于长时间无法响应的状态。