前几篇把 ACL 链路的建立、加密、探测、角色切换一路讲完，链路这条高速公路已经车水马龙。但蓝牙还有一个杀手级应用始终没登场——通话。语音数据有个坏脾气：晚到的数据等于没到。一个字延迟 100 毫秒再播出来，用户听到的就是回声和卡顿。所以经典蓝牙为语音单独修了一条按固定节拍流动的专线：同步连接（SCO/eSCO）。
目录
一、语音为什么不能挤 ACL 的车道
二、建链第一式：Central 发起 eSCO
三、建链第二式：Peripheral 发起，请求要走三趟
四、SCO 的建链路径：四世同堂的兼容艺术
4.1 Central 发起，对端是新设备
4.2 对端是 legacy 设备
4.3 仅支持 SCO 的设备发起
五、增强命令组：3-slot 包与重传策略
5.1 Central 发起
5.2 Peripheral 发起
5.3 混搭场景
六、重协商：不拆链，改参数
七、拆链：好聚好散
八、实测log：规范的每一根箭头都有影子
8.1 主机侧：一次通话的完整生命周期
8.2 空口：三趟请求的教科书复现
8.3 两份日志的互补关系
九、给工程的一段参数表
十、把 15 张图拧成一根时间轴
十一、测验
规范用15 张消息序列图，把这条专线的生老病死画得明明白白：谁能发起、怎么协商参数、中途怎么换参数不拆链、最后怎么好聚好散。这一篇就把 15 张图全部拆开，再用一份主机侧 HCI 日志和一份空口日志逐条分析——你会发现规范里画的每一根箭头，都能在真实空口上找到自己的影子。
一、语音为什么不能挤ACL的车道
先回答一个根本问题：ACL链路带宽不低，为什么语音非要单独建链？
ACL 是异步传输，本质是尽力而为：冲突了重传、拥塞了排队、带宽按需分配。数据业务对此毫不在乎——晚 50ms 收到一张图片，无感。但 PCM 语音流是恒定码率的实时流，每 7.5ms 产生一帧数据，这一帧如果不能准时上空口，接收端就会出现断音。挤在 ACL 里，语音帧要跟网页、音乐、控制信令抢队列，时延完全不可控。
同步连接的解法很直接：在已有链路上划出专用时隙，按固定间隔发送，谁也不许抢。核心参数就三个：</
