为何最新版Chrome浏览器的WebRTC当前不支持iLBC音频编解码器？

实际测试观察到的现象 #

• 在最新正式版本Chrome中尝试将iLBC设为WebRTC音频通信的优先编解码器时，最终协商得到的可支持音频编解码器列表中，完全没有iLBC相关条目
• 通过WebRTC官方提供的创建WebRTC Offer的测试页面验证，生成的SDP协商内容中同样不存在iLBC的对应标识
• 核查WebRTC上游公开源码的内置配置文件（对应配置可在仓库内webrtc.gni配置文件的第68行位置查到相关说明）时，可见iLBC的编译配置开关默认处于启用状态，与浏览器实际运行的表现存在明显矛盾

现象背后的核心原因 #

• Chrome正式分发的安装包，在编译构建阶段对内置WebRTC模块做了定向精简：虽然源码层面保留了iLBC模块的编译开关定义，但正式发行版的构建流水线出于安装包体积优化、技术栈迭代的考量，并没有将iLBC的编解码实现打包进最终的浏览器产物中
• 源码层面的配置开关只是编译选项的定义，不代表该模块会被真正编入发行版。只要正式构建流程没有开启iLBC模块的打包逻辑，浏览器运行时就不会加载对应的编解码处理能力，自然不会在SDP协商阶段把iLBC加入可支持的编解码器列表
• 补充背景：iLBC作为已被Opus全面替代的老旧窄带音频编解码器，Chrome官方已经在近年的版本迭代中逐步移除了对该编解码器的原生内置支持，仅在部分面向特殊合规场景定制的Chrome分支中保留相关能力

实现Chrome端iLBC通信的可行路径 #

• 路径一：自行基于WebRTC公开源码编译定制版Chrome，在构建配置中显式开启iLBC编解码器的编译打包选项，关闭正式版默认的老旧编解码器裁剪逻辑，编译完成后即可在WebRTC协商流程中正常识别并使用iLBC
• 路径二：在业务链路中增加转码适配层：当浏览器原生不支持iLBC时，可通过服务端或边缘节点，将Chrome原生支持的Opus等编解码格式实时转码为iLBC格式，不需要依赖浏览器的原生编解码能力
• 注意：过往版本中可通过Chrome隐藏实验开关强行开启iLBC的操作，在近3年的Chrome版本中已经完全失效，相关实验性入口已经被官方从代码中移除

内容的提问来源于stack exchange，提问作者PhilipSong