做外呼业务或者对接运营商线路的兄弟十有八九碰到过这种尴尬FreeSWITCH外呼出去主叫侧音乐响起来了你以为是运营商下发的彩铃其实设备只是在本地播放了一段默认回铃音等被叫真的接听了你这边还在傻乎乎地播等待音对方喂了好几声你都没接上话。这类问题的根源就是没有把回铃音和彩铃当作两件完全不同的事也没有在SIP信令之外建立一套媒体层面的兜底检测机制。这篇文章我会从SIP信令里的180和183聊起讲清楚回铃音和彩铃在信令层、媒体层的本质差异然后再往下拆FreeSWITCH里与早期媒体相关的配置参数包括最常见的p-early-media-support。最后重点聊一聊媒体检测方向也就是标题里提到的mod_da2检测模块它是怎么帮助我们解决被叫到底接没接听这个老大难问题的。适用对象很明确正在做FreeSWITCH外呼、呼叫中心、IVR、线路对接的朋友。内容不是那种填鸭式给你一份万能配置就完事的写法而是把原理和场景掰开揉碎你拿回任何项目里都能复用。1. 先搞清楚概念回铃音与彩铃到底差在哪里1.1 回铃音本地生成的嘟嘟声在国内打一个普通电话听到的嘟——嘟——回铃音大多数人会默认为是手机那头传来的。实际上并非如此传统PSTN网络里回铃音是由交换机在本地生成的它不需要被叫终端参与也不需要在整个网络里传输音频码流。你可以把它理解成一个本地提示被叫电话已经振铃了请主叫耐心等待。就好比你在银行柜台取号后柜台窗口的提示屏亮起这只是现场的一个本地信号并没有从你的卡号账户那边远程传一段声音过来。到了VoIP和SIP环境下这个逻辑发生了变化但本质仍然保留。IP话机或者软终端收到SIP 180 Ringing响应后可以在本地自行播放一段回铃音。这一段声音可能是话机上固化的也可以是话机管理平台下发的但不管怎样它都不占用媒体协商资源也没有码流在对端和本端之间来回跑。换句话说这种场景下你听到的声音是本地产物和SIP信令消息里的180状态信息并不是同一个东西。因此判断是不是回铃音一个非常硬的标准就是这段声音是不是本地生成的和你通话的目标设备有没有建立实时媒体关系。如果没有媒体流在跑那就是传统回铃音信令只需要一个180就足够了。反过来说如果这段等待音是网络上某个服务器实时推送过来的那它就不再是回铃音而是彩铃或者早期媒体。1.2 彩铃从网络传来的媒体流彩铃则完全是另一套逻辑。被叫用户开通彩铃之后当主叫发起呼叫、被叫终端进入振铃状态运营商彩铃平台或IMS网络会在正式接通之前先把一段媒体流推送给主叫。这段媒体流可能是音乐、广告、自定义语音它需要一个真实的RTP媒体会话承载。也就是说彩铃本质上是内容推送不是本地提示。为了让这段媒体流能顺利到达主叫侧SIP信令上必须有一个媒体协商过程。通常由彩铃平台发送183 Session Progress响应并且在响应中携带SDP告诉主叫我要用什么编码、向哪个IP和端口发RTP包。主叫侧收到183带SDP后开始建立媒体通路播放彩铃。等到被叫真正接听200 OK到来彩铃停止媒体切换到正常通话。整个过程里RTP包一直在网络上跑谁也不能把它当成一句简单的信令状态。简单说彩铃不是提示声它是内容推送。内容要从远端推送过来必须走媒体通道。这也就是为什么彩铃场景里会频繁出现早期媒体Early Media这个概念——早于正式通话建立但已经存在的媒体流。理解这一点之后你会发现后面所有配置和排查都是围绕着这段媒体流是否被正确处理展开的。1.3 一张表看懂核心差异对比维度回铃音180 Ringing彩铃183 Session Progress / Early Media触发信令180 Ringing183 Session Progress通常带SDP是否需要SDP不一定必须带SDP才能协商媒体媒体来源主叫本地生成远端/平台通过早期媒体实时传送控制方主叫终端本地播放被叫侧或运营商彩铃平台控制内容典型内容嘟...嘟...音乐、语音广告、自定义铃声对FreeSWITCH的要求只需等200 OK需要处理早期媒体与应答检测媒体流是否跨网络否是需要补充一个很容易被忽略的细节不是所有183都代表彩铃。183只是一个SIP临时响应它本身不包含媒体内容。有些终端在振铃时发送183但带的是空SDP有些只是透传状态具体要看SDP是否完整、RTP是否实际推送。这个细节至关重要很多人在抓包时看到183就以为已经有媒体流了其实可能什么都没有。2. SIP信令里的关键判断180、183与Early Media2.1 180 Ringing并不等于你听到的声音先纠正一个误区收到180 Ringing不代表主叫侧听得到嘟嘟声。180只是SIP协议栈里的一个临时响应语义是被叫地址已经定位系统正在振铃。它没有任何义务附带音频。至于主叫终端听到什么完全取决于终端自己的实现。有的终端收到180会播放本地回铃音有的终端如果开启了静默振铃或者DND免打扰模式可能一声都不响还有的终端可以结合配置自行决定播放什么铃声。所以在排查为什么没有回铃音的时候不要一股脑扎进信令抓包里只数180有几条。你还要看话机本地配置、回铃音文件是否存在、话机是否真的把呼叫状态切换到了振铃中。很多时候问题不在FreeSWITCH而在话机侧或者语音网关的本地配置里。在FreeSWITCH发起外呼时它作为主叫也会收到对端比如运营商网关发来的180。FreeSWITCH的处理策略通常是在dialplan中通过ringback变量决定是否给本侧播放提示音。如果对端要送彩铃它通常发的是183而不是180。这是区分两种模式的最直接依据看到183优先考虑早期媒体看到180默认走本地回铃音。但这个默认规则并不是铁律某些网关也会在180里携带SDP来表示早期媒体只是不多见。2.2 183 Session Progress为什么普遍伴随SDP183 Session Progress在SIP里也是个临时响应但它携带的信息量更多服务器或被叫方想告诉主叫会话已经进入某种有进展的状态更重要的是通常会携带SDP来完成媒体协商。RFC 3960定义了Early Media的推荐处理方式。当一个UA收到183带SDP后它就获得了对端的媒体地址、编码格式等参数理论上可以开始发送和接收RTP包。彩铃就是在这种状态下被送过来的。这也解释了为什么彩铃场景里SDP几乎是标配没有SDP就没有协商没有协商RTP流往哪里发都不知道。为什么我强调通常因为实际网络里各种特殊情况多得是。有的网关会发一个不带SDP的183或者183里的SDP缺少codec参数甚至存在183里带了一个根本不通的媒体端口。这些问题都会导致早期媒体异常。因此在FreeSWITCH里有一个专门参数ignore_183_no_sdp就是为了处理这类半吊子183的场景。注意183可以带SDP也可以不带。带SDP的183才是早期媒体的正式入场券不带SDP的183只相当于一个状态通知不要指望后面马上有RTP流。抓包的时候看到183第一件事就是展开SDP字段确认里面有没有maudio、artpmap这些关键字段。如果SDP缺失或者媒体端口为0那就说明对端并没有真正建立早期媒体的意思你后面的彩铃期望可以提前打消了。2.3 FreeSWITCH作为B2BUA如何处置这两类信令FreeSWITCH的SIP实现基于mod_sofia本质上是一个B2BUABack-to-Back User Agent。它把一条呼叫拆成两段A腿主叫侧和B腿被叫侧。在A腿和B腿各自进行SIP信令交互FreeSWITCH在中间做桥接和媒体流转发。理解这个中间人角色是排查一切媒体问题的前提。当你用FreeSWITCH对外呼出时B腿收到运营商网关的180FreeSWITCH知道对端在振铃并把180转发给A腿B腿收到183带SDPFreeSWITCH进入早期媒体状态。如果配置允许媒体引擎开始接收并转发对端的RTP流A腿的主叫可能收到FreeSWITCH发出的183或者180并决定是播放本地回铃音还是接收来自FreeSWITCH的早期媒体当你用FreeSWITCH接听呼入时主叫网关向FreeSWITCH发INVITEFreeSWITCH的dialplan决定是否发送180或183响应如果dialplan里用了pre_answer并开始播放语音你其实就是在向主叫提供彩铃/等待音了等到你真正执行answer时200 OK才被发送呼叫正式建立很多刚上手的朋友经常把自己搞晕抓包看到对端明明发了183软终端还是听不到彩铃。原因往往就出在中间这一层——FreeSWITCH没有把183透传也没有把媒体转发过去。B2BUA不是透明的SIP代理它完全可以决定哪些信令和媒体放行哪些在内部消化掉。3. 让彩铃真正被听到FreeSWITCH早期媒体配置实操3.1 开关一p-early-media-supportp-early-media-support位于sip_profiles配置文件的profile节点下它是FreeSWITCH媒体引擎对待早期媒体态度的总开关。配置位置通常在conf/sip_profiles/external.xml或internal.xml。profile nameexternal param namep-early-media-support valuetrue/ param nameignore_183_no_sdp valuefalse/ /profile设为true时FreeSWITCH在收到带SDP的183或180后会积极进行媒体协商使媒体引擎具备处理早期媒体的能力。设为false时即便对端发来183SDPFreeSWITCH也不会建立媒体通路主叫侧只能靠本地回铃音。这个参数基本是哪个profile对外走运营商就开哪个。比如你用external网关呼出那就修改external.xml如果用internal作为用户侧接入也需要评估是否需要支持早期媒体因为内部软电话如果要听到彩铃同样离不开这个开关。常见错误是只开了p-early-media-support早期媒体依然不工作。原因是这个参数只是允许协商真正控制要不要把媒体透传给对端的还有一个开关。很多项目只配了一半结果卡在媒体透传上。3.2 开关二early-media-passthru这个开关就是上面说的另一半early-media-passthru。param nameearly-media-passthru valuetrue/early-media-passthru决定FreeSWITCH是否把已经协商好的早期媒体透传给对端。把它打开配合p-early-media-supporttrue彩铃才能完整地从运营商网关经过FreeSWITCH到达最终用户。如果只开前者不开后者FreeSWITCH自己能收到媒体却不会转给用户表现就是我这边抓包有RTP但软电话就是没声音。我见过太多项目在external.xml里开了p-early-media-support但在internal.xml对应的那个用户侧profile里没有开early-media-passthru结果用户听不到彩铃。这种跨profile的配置特别容易漏因为从单看一个profile很难发现问题必须把整条链路上的A腿和B腿配置都拉出来对比一遍。如果两个开关都开了彩铃还是透传不过去请立刻去抓包。重点看三个地方B腿183里的SDP媒体IP和端口是否路由可达FreeSWITCH转发给A腿的媒体参数是否正确主叫终端是否真的在往协商好的地址发送RTCP或者接收RTP3.3 用pre_answer做自定义彩铃的正确姿势除了被动接收外部彩铃FreeSWITCH经常要扮演彩铃提供方。比如企业总机想让来电者听到欢迎致电XX公司请稍候而不是运营商的默认嘟嘟声。这个场景用pre_answer配合playback就能实现。典型dialplanextension namecompany_ringback condition fielddestination_number expression^(200[0-9])$ action applicationpre_answer/ action applicationplayback data/var/audio/welcome_on_hold.wav/ action applicationanswer/ action applicationbridge datauser/1001${domain}/ /condition /extension这里面的执行顺序非常关键先pre_answerFreeSWITCH向主叫发送183不是200 OK主叫进入早期媒体状态然后playback向主叫播放公司自定义等待音频等到被叫接听再执行answer和bridge进入正式通话提醒pre_answer之后不要过早执行answer否则它会向主叫发送200 OK主叫以为被叫已经接听但实际桥接还没建立会造成一段不短的空窗期。这类提前应答在对接IVR、录音等场景中也很常见处理不好会出现接听延迟或者媒体断流。如果你想让主叫听自己定义的彩铃同时又不希望在正式桥接前让主叫误以为通话已建立pre_answer是唯一正确的选择。4. 信令不可靠时的终极方案mod_da2检测模块4.1 什么场景下你会被信令坑标准SIP里被叫接听这个事件由200 OK表达。但在真实电信网里200 OK并不是一个完全值得信赖的信号。第一种坑是运营商网关的预应答pre-answer机制。有些平台为了尽早建立媒体通路会在被叫真正接听前就向FreeSWITCH返回200 OK。如果你把200 OK当作被叫已接听来处理就会提前给被叫放音用户会听到你从中间开始说话前面的内容被吞掉。第二种坑是被叫已经接听了但200 OK迟迟不到或者直接丢失。NAT会话老化、防火墙SIP ALG篡改、信令网异常都可能导致200 OK延迟甚至丢包。这种情况下FreeSWITCH一直在等待信令而被叫已经在喂喂喂了系统却毫无反应。第三种坑是对端喜欢用183SDP做准应答但一直不发200 OK或者发来之后又立刻BYE状态切换极其奇怪。尤其在对接一些省级运营商线路时这类不规范行为并不罕见。在这些场景下我们需要的不是信令等待而是媒体检测。因为无论信令如何飘忽只要被叫真正接听了媒体流的特征一定会发生变化——可能从彩铃/回铃音的连续音变成静音之后的说话声或者从单方RTP变成双向RTP。检测这种变化就能辅助判断接听的准确时刻。4.2 mod_da2检测模块的工作原理mod_da2就是FreeSWITCH生态里为这类需求设计的媒体检测模块。它的核心逻辑相对简洁对通话中的媒体流做实时分析检测音频的能量、静音、活跃状态以及特定信号特征的变化输出对应的事件业务层收到事件后再做后续动作。放在彩铃和早期媒体场景里它就像一个听声识物的守门员媒体流中有彩铃或语音内容模块认为此时是振铃或提示阶段当一段连续语音出现且伴随双向媒体时模块认为被叫可能已经接听当检测到持续静音或信号切换时模块认为呼叫正在发生转移或进入等待状态FreeSWITCH本身是一个事件驱动的系统支持通过Event Socket或ESL把模块检测到的事件推送给外部业务逻辑。你可以在这里实现立即停止本侧回铃音更新呼叫状态、启动通话计费触发语音机器人开始播放开场白通知CRM系统呼叫已经接通我个人的经验是mod_da2在呼叫中心外呼场景里的价值最大。尤其当你对接了大量不同省份、不同运营商的线路时每条线路对200 OK的处理习惯都不一样。如果业务代码只依赖信令你永远在跟被叫都开始说话了系统却还在等待的问题搏斗。加入媒体检测作为兜底手段能显著降低这种不确定性。4.3 mod_da2接入流程与实战配置不同FreeSWITCH版本对mod_da2的API和事件名可能有差异但接入的整体思路是一致的加载模块、在呼叫流程中启用检测、订阅事件做业务响应。这里给出一个通用的框架你拿到实际环境时以版本自带的文档为准。第一步加载模块。来到conf/autoload_configs/modules.conf.xml找到modules区域添加load modulemod_da2/保存后重启FreeSWITCH或者通过fs_cli执行load mod_da2加载成功后可以用show modules确认模块是否已经就绪。第二步在呼叫流程中启用检测。针对你要做应答检测的外呼呼叫在bridge前设置检测开关extension nameoutbound_call_with_detect condition fielddestination_number expression^(1[3-9]\d{9})$ action applicationset datada2_detecttrue/ action applicationbridge datasofia/gateway/carrier/$1/ /condition /extension第三步通过ESL或事件监听接收检测结果。mod_da2在检测到媒体特征变化时会触发事件事件中包含呼叫唯一标识、检测到的媒体类型、时间点等信息。外部业务程序订阅这些事件一旦收到检测到语音或等价事件就认为被叫已接听开始执行后续动作。提示不同FreeSWITCH版本的mod_da2在实际命令和事件名上很可能不一样。部署前一定要在测试环境里跑一遍完整流程用一条测试线路确认模块加载、检测触发、事件上报都能通再上生产。这里我还想泼一盆清醒水不要在业务上100%依赖媒体检测。mod_da2是信令之外的补充手段最佳实践是信令优先媒体检测兜底。也就是说如果200 OK正常到达以200 OK为准如果200 OK迟迟不来或明显异常才用媒体检测的结果作为接听依据。两者结合准确率才能拉满。5. 常见问题与排查技巧实录5.1 彩铃透传失败的排查清单如果你已经配置了p-early-media-supporttrue和early-media-passthrutrue主叫还是听不到彩铃请按这个顺序排查抓包确认对端是否真的发送183且携带完整SDP。有些所谓彩铃其实只是对端本地播放并没有真实媒体流。检查FreeSWITCH是否把183转发给A腿以及A腿的SDP媒体地址是否有效。用sofia status profile external查看注册和媒体状态确认媒体端口没有被占用或冲突。检查防火墙和NAT。企业防火墙如果开启了SIP ALG它可能会重写SDP或插入代理导致媒体流指向错误地址。这种情况下优先关闭SIP ALG改用FreeSWITCH自身的NAT穿透参数。确认主叫终端是否支持早期媒体。某些老式话机对183的处理有bug不会接收RTP流只能等200 OK。把这五步走完95%的彩铃透传问题都能定位到具体环节。5.2 被叫接听判断迟滞或错乱的三种解法被叫已经接听但FreeSWITCH没感知最直接的三个解法启用媒体检测就是前面讲的mod_da2方案适合信令不可靠的线路和运营商。用桥接变量规避状态错乱在bridge时合理设置早期媒体相关参数和超时时间让FreeSWITCH不要因为收不到200 OK而一直干等。业务层面做双确认在话术设计上留一个缓冲比如机器人开场白设计成您好然后等待一个短反馈或静音周期再继续主流程。即使系统没有及时知道被叫接听机器人也不会把话说尬。这三种方案可以组合使用效果叠加。我自己在项目里通常是一、三组合信令可靠时跟随信令信令飘忽时靠媒体检测兜底同时话术上始终保留容错。5.3 SIP ALG与NAT对早期媒体的干扰SIP ALG是很多企业防火墙默认开启的功能它的初衷是帮SIP流量做NAT穿透。但在SIP加早期媒体的场景下SIP ALG常常好心办坏事它会修改SDP里的IP地址把本应到达FreeSWITCH的RTP包重定向到别的地址或者在SIP消息里插入额外的Via和Record-Route导致信令路径混乱。我的建议是在FreeSWITCH对外服务的网络边界上关闭防火墙的SIP ALG功能把NAT穿透交给FreeSWITCH自己处理。相关配置一般包括sip_profile里的ext-rtp-ip、ext-sip-ip、apply-nat-acl、aggressive-nat等参数。注意关闭SIP ALG前先在测试环境验证路由和基本呼叫都正常。尤其要确认能不能收到对方的媒体流以及本机能不能把RTP包正确发出去。5.4 排查工具与抓包要点问题发生的时候最快的定位方式是抓包。我常用的组合是SIP信令抓包用Wireshark抓取网卡上的5060端口流量。RTP媒体验证在Wireshark里对SIP RTP做综合过滤直接看SIP对话和RTP流的时序关系。fs_cli在FreeSWITCH上查看呼叫状态和媒体协商信息常用命令包括show channels、sofia status、uuid_dump uuid。抓包时最值得关注的时间线是INVITE发出。183到达是否带SDP、SDP内容是否合法。RTP是否从对端流向本机。是否出现200 OK。ACK是否发出。媒体是否从单向变为双向。很多奇怪的问题只要把这条时间线拉出来答案自己就浮出来了。如果你看到183带了SDP但没有后续RTP那多半是NAT或路由问题如果RTP一直在跑但FreeSWITCH没有转发那问题出在透传配置如果200 OK已经到了但媒体没有切换那问题出在A腿的媒体协商上。最后聊点我自己的体会。早期媒体这个坑几乎每个做FreeSWITCH业务的人都会踩而且踩的方式各不相同。我刚做外呼那阵遇到被叫明明已经接听了、人都在说话了系统还在播放等待音折腾了两天才发现是信令和媒体两个层面的问题交织在一起。后来我把回铃音是本地提示、彩铃是媒体推送这句话刻在脑子里再看信令流程就通透多了。配置层面的p-early-media-support和early-media-passthru是两个最常用的开关但真正治本的思路还是要建立信令为主、媒体检测兜底的双保险。如果你正准备上外呼业务建议提前把mod_da2这类检测机制加进去不要等到被用户投诉了再补。我踩过这个坑所以希望你不用再踩一遍。
做外呼业务或者对接运营商线路的兄弟十有八九碰到过这种尴尬FreeSWITCH外呼出去主叫侧音乐响起来了你以为是运营商下发的彩铃其实设备只是在本地播放了一段默认回铃音等被叫真的接听了你这边还在傻乎乎地播等待音对方喂了好几声你都没接上话。这类问题的根源就是没有把回铃音和彩铃当作两件完全不同的事也没有在SIP信令之外建立一套媒体层面的兜底检测机制。这篇文章我会从SIP信令里的180和183聊起讲清楚回铃音和彩铃在信令层、媒体层的本质差异然后再往下拆FreeSWITCH里与早期媒体相关的配置参数包括最常见的p-early-media-support。最后重点聊一聊媒体检测方向也就是标题里提到的mod_da2检测模块它是怎么帮助我们解决被叫到底接没接听这个老大难问题的。适用对象很明确正在做FreeSWITCH外呼、呼叫中心、IVR、线路对接的朋友。内容不是那种填鸭式给你一份万能配置就完事的写法而是把原理和场景掰开揉碎你拿回任何项目里都能复用。1. 先搞清楚概念回铃音与彩铃到底差在哪里1.1 回铃音本地生成的嘟嘟声在国内打一个普通电话听到的嘟——嘟——回铃音大多数人会默认为是手机那头传来的。实际上并非如此传统PSTN网络里回铃音是由交换机在本地生成的它不需要被叫终端参与也不需要在整个网络里传输音频码流。你可以把它理解成一个本地提示被叫电话已经振铃了请主叫耐心等待。就好比你在银行柜台取号后柜台窗口的提示屏亮起这只是现场的一个本地信号并没有从你的卡号账户那边远程传一段声音过来。到了VoIP和SIP环境下这个逻辑发生了变化但本质仍然保留。IP话机或者软终端收到SIP 180 Ringing响应后可以在本地自行播放一段回铃音。这一段声音可能是话机上固化的也可以是话机管理平台下发的但不管怎样它都不占用媒体协商资源也没有码流在对端和本端之间来回跑。换句话说这种场景下你听到的声音是本地产物和SIP信令消息里的180状态信息并不是同一个东西。因此判断是不是回铃音一个非常硬的标准就是这段声音是不是本地生成的和你通话的目标设备有没有建立实时媒体关系。如果没有媒体流在跑那就是传统回铃音信令只需要一个180就足够了。反过来说如果这段等待音是网络上某个服务器实时推送过来的那它就不再是回铃音而是彩铃或者早期媒体。1.2 彩铃从网络传来的媒体流彩铃则完全是另一套逻辑。被叫用户开通彩铃之后当主叫发起呼叫、被叫终端进入振铃状态运营商彩铃平台或IMS网络会在正式接通之前先把一段媒体流推送给主叫。这段媒体流可能是音乐、广告、自定义语音它需要一个真实的RTP媒体会话承载。也就是说彩铃本质上是内容推送不是本地提示。为了让这段媒体流能顺利到达主叫侧SIP信令上必须有一个媒体协商过程。通常由彩铃平台发送183 Session Progress响应并且在响应中携带SDP告诉主叫我要用什么编码、向哪个IP和端口发RTP包。主叫侧收到183带SDP后开始建立媒体通路播放彩铃。等到被叫真正接听200 OK到来彩铃停止媒体切换到正常通话。整个过程里RTP包一直在网络上跑谁也不能把它当成一句简单的信令状态。简单说彩铃不是提示声它是内容推送。内容要从远端推送过来必须走媒体通道。这也就是为什么彩铃场景里会频繁出现早期媒体Early Media这个概念——早于正式通话建立但已经存在的媒体流。理解这一点之后你会发现后面所有配置和排查都是围绕着这段媒体流是否被正确处理展开的。1.3 一张表看懂核心差异对比维度回铃音180 Ringing彩铃183 Session Progress / Early Media触发信令180 Ringing183 Session Progress通常带SDP是否需要SDP不一定必须带SDP才能协商媒体媒体来源主叫本地生成远端/平台通过早期媒体实时传送控制方主叫终端本地播放被叫侧或运营商彩铃平台控制内容典型内容嘟...嘟...音乐、语音广告、自定义铃声对FreeSWITCH的要求只需等200 OK需要处理早期媒体与应答检测媒体流是否跨网络否是需要补充一个很容易被忽略的细节不是所有183都代表彩铃。183只是一个SIP临时响应它本身不包含媒体内容。有些终端在振铃时发送183但带的是空SDP有些只是透传状态具体要看SDP是否完整、RTP是否实际推送。这个细节至关重要很多人在抓包时看到183就以为已经有媒体流了其实可能什么都没有。2. SIP信令里的关键判断180、183与Early Media2.1 180 Ringing并不等于你听到的声音先纠正一个误区收到180 Ringing不代表主叫侧听得到嘟嘟声。180只是SIP协议栈里的一个临时响应语义是被叫地址已经定位系统正在振铃。它没有任何义务附带音频。至于主叫终端听到什么完全取决于终端自己的实现。有的终端收到180会播放本地回铃音有的终端如果开启了静默振铃或者DND免打扰模式可能一声都不响还有的终端可以结合配置自行决定播放什么铃声。所以在排查为什么没有回铃音的时候不要一股脑扎进信令抓包里只数180有几条。你还要看话机本地配置、回铃音文件是否存在、话机是否真的把呼叫状态切换到了振铃中。很多时候问题不在FreeSWITCH而在话机侧或者语音网关的本地配置里。在FreeSWITCH发起外呼时它作为主叫也会收到对端比如运营商网关发来的180。FreeSWITCH的处理策略通常是在dialplan中通过ringback变量决定是否给本侧播放提示音。如果对端要送彩铃它通常发的是183而不是180。这是区分两种模式的最直接依据看到183优先考虑早期媒体看到180默认走本地回铃音。但这个默认规则并不是铁律某些网关也会在180里携带SDP来表示早期媒体只是不多见。2.2 183 Session Progress为什么普遍伴随SDP183 Session Progress在SIP里也是个临时响应但它携带的信息量更多服务器或被叫方想告诉主叫会话已经进入某种有进展的状态更重要的是通常会携带SDP来完成媒体协商。RFC 3960定义了Early Media的推荐处理方式。当一个UA收到183带SDP后它就获得了对端的媒体地址、编码格式等参数理论上可以开始发送和接收RTP包。彩铃就是在这种状态下被送过来的。这也解释了为什么彩铃场景里SDP几乎是标配没有SDP就没有协商没有协商RTP流往哪里发都不知道。为什么我强调通常因为实际网络里各种特殊情况多得是。有的网关会发一个不带SDP的183或者183里的SDP缺少codec参数甚至存在183里带了一个根本不通的媒体端口。这些问题都会导致早期媒体异常。因此在FreeSWITCH里有一个专门参数ignore_183_no_sdp就是为了处理这类半吊子183的场景。注意183可以带SDP也可以不带。带SDP的183才是早期媒体的正式入场券不带SDP的183只相当于一个状态通知不要指望后面马上有RTP流。抓包的时候看到183第一件事就是展开SDP字段确认里面有没有maudio、artpmap这些关键字段。如果SDP缺失或者媒体端口为0那就说明对端并没有真正建立早期媒体的意思你后面的彩铃期望可以提前打消了。2.3 FreeSWITCH作为B2BUA如何处置这两类信令FreeSWITCH的SIP实现基于mod_sofia本质上是一个B2BUABack-to-Back User Agent。它把一条呼叫拆成两段A腿主叫侧和B腿被叫侧。在A腿和B腿各自进行SIP信令交互FreeSWITCH在中间做桥接和媒体流转发。理解这个中间人角色是排查一切媒体问题的前提。当你用FreeSWITCH对外呼出时B腿收到运营商网关的180FreeSWITCH知道对端在振铃并把180转发给A腿B腿收到183带SDPFreeSWITCH进入早期媒体状态。如果配置允许媒体引擎开始接收并转发对端的RTP流A腿的主叫可能收到FreeSWITCH发出的183或者180并决定是播放本地回铃音还是接收来自FreeSWITCH的早期媒体当你用FreeSWITCH接听呼入时主叫网关向FreeSWITCH发INVITEFreeSWITCH的dialplan决定是否发送180或183响应如果dialplan里用了pre_answer并开始播放语音你其实就是在向主叫提供彩铃/等待音了等到你真正执行answer时200 OK才被发送呼叫正式建立很多刚上手的朋友经常把自己搞晕抓包看到对端明明发了183软终端还是听不到彩铃。原因往往就出在中间这一层——FreeSWITCH没有把183透传也没有把媒体转发过去。B2BUA不是透明的SIP代理它完全可以决定哪些信令和媒体放行哪些在内部消化掉。3. 让彩铃真正被听到FreeSWITCH早期媒体配置实操3.1 开关一p-early-media-supportp-early-media-support位于sip_profiles配置文件的profile节点下它是FreeSWITCH媒体引擎对待早期媒体态度的总开关。配置位置通常在conf/sip_profiles/external.xml或internal.xml。profile nameexternal param namep-early-media-support valuetrue/ param nameignore_183_no_sdp valuefalse/ /profile设为true时FreeSWITCH在收到带SDP的183或180后会积极进行媒体协商使媒体引擎具备处理早期媒体的能力。设为false时即便对端发来183SDPFreeSWITCH也不会建立媒体通路主叫侧只能靠本地回铃音。这个参数基本是哪个profile对外走运营商就开哪个。比如你用external网关呼出那就修改external.xml如果用internal作为用户侧接入也需要评估是否需要支持早期媒体因为内部软电话如果要听到彩铃同样离不开这个开关。常见错误是只开了p-early-media-support早期媒体依然不工作。原因是这个参数只是允许协商真正控制要不要把媒体透传给对端的还有一个开关。很多项目只配了一半结果卡在媒体透传上。3.2 开关二early-media-passthru这个开关就是上面说的另一半early-media-passthru。param nameearly-media-passthru valuetrue/early-media-passthru决定FreeSWITCH是否把已经协商好的早期媒体透传给对端。把它打开配合p-early-media-supporttrue彩铃才能完整地从运营商网关经过FreeSWITCH到达最终用户。如果只开前者不开后者FreeSWITCH自己能收到媒体却不会转给用户表现就是我这边抓包有RTP但软电话就是没声音。我见过太多项目在external.xml里开了p-early-media-support但在internal.xml对应的那个用户侧profile里没有开early-media-passthru结果用户听不到彩铃。这种跨profile的配置特别容易漏因为从单看一个profile很难发现问题必须把整条链路上的A腿和B腿配置都拉出来对比一遍。如果两个开关都开了彩铃还是透传不过去请立刻去抓包。重点看三个地方B腿183里的SDP媒体IP和端口是否路由可达FreeSWITCH转发给A腿的媒体参数是否正确主叫终端是否真的在往协商好的地址发送RTCP或者接收RTP3.3 用pre_answer做自定义彩铃的正确姿势除了被动接收外部彩铃FreeSWITCH经常要扮演彩铃提供方。比如企业总机想让来电者听到欢迎致电XX公司请稍候而不是运营商的默认嘟嘟声。这个场景用pre_answer配合playback就能实现。典型dialplanextension namecompany_ringback condition fielddestination_number expression^(200[0-9])$ action applicationpre_answer/ action applicationplayback data/var/audio/welcome_on_hold.wav/ action applicationanswer/ action applicationbridge datauser/1001${domain}/ /condition /extension这里面的执行顺序非常关键先pre_answerFreeSWITCH向主叫发送183不是200 OK主叫进入早期媒体状态然后playback向主叫播放公司自定义等待音频等到被叫接听再执行answer和bridge进入正式通话提醒pre_answer之后不要过早执行answer否则它会向主叫发送200 OK主叫以为被叫已经接听但实际桥接还没建立会造成一段不短的空窗期。这类提前应答在对接IVR、录音等场景中也很常见处理不好会出现接听延迟或者媒体断流。如果你想让主叫听自己定义的彩铃同时又不希望在正式桥接前让主叫误以为通话已建立pre_answer是唯一正确的选择。4. 信令不可靠时的终极方案mod_da2检测模块4.1 什么场景下你会被信令坑标准SIP里被叫接听这个事件由200 OK表达。但在真实电信网里200 OK并不是一个完全值得信赖的信号。第一种坑是运营商网关的预应答pre-answer机制。有些平台为了尽早建立媒体通路会在被叫真正接听前就向FreeSWITCH返回200 OK。如果你把200 OK当作被叫已接听来处理就会提前给被叫放音用户会听到你从中间开始说话前面的内容被吞掉。第二种坑是被叫已经接听了但200 OK迟迟不到或者直接丢失。NAT会话老化、防火墙SIP ALG篡改、信令网异常都可能导致200 OK延迟甚至丢包。这种情况下FreeSWITCH一直在等待信令而被叫已经在喂喂喂了系统却毫无反应。第三种坑是对端喜欢用183SDP做准应答但一直不发200 OK或者发来之后又立刻BYE状态切换极其奇怪。尤其在对接一些省级运营商线路时这类不规范行为并不罕见。在这些场景下我们需要的不是信令等待而是媒体检测。因为无论信令如何飘忽只要被叫真正接听了媒体流的特征一定会发生变化——可能从彩铃/回铃音的连续音变成静音之后的说话声或者从单方RTP变成双向RTP。检测这种变化就能辅助判断接听的准确时刻。4.2 mod_da2检测模块的工作原理mod_da2就是FreeSWITCH生态里为这类需求设计的媒体检测模块。它的核心逻辑相对简洁对通话中的媒体流做实时分析检测音频的能量、静音、活跃状态以及特定信号特征的变化输出对应的事件业务层收到事件后再做后续动作。放在彩铃和早期媒体场景里它就像一个听声识物的守门员媒体流中有彩铃或语音内容模块认为此时是振铃或提示阶段当一段连续语音出现且伴随双向媒体时模块认为被叫可能已经接听当检测到持续静音或信号切换时模块认为呼叫正在发生转移或进入等待状态FreeSWITCH本身是一个事件驱动的系统支持通过Event Socket或ESL把模块检测到的事件推送给外部业务逻辑。你可以在这里实现立即停止本侧回铃音更新呼叫状态、启动通话计费触发语音机器人开始播放开场白通知CRM系统呼叫已经接通我个人的经验是mod_da2在呼叫中心外呼场景里的价值最大。尤其当你对接了大量不同省份、不同运营商的线路时每条线路对200 OK的处理习惯都不一样。如果业务代码只依赖信令你永远在跟被叫都开始说话了系统却还在等待的问题搏斗。加入媒体检测作为兜底手段能显著降低这种不确定性。4.3 mod_da2接入流程与实战配置不同FreeSWITCH版本对mod_da2的API和事件名可能有差异但接入的整体思路是一致的加载模块、在呼叫流程中启用检测、订阅事件做业务响应。这里给出一个通用的框架你拿到实际环境时以版本自带的文档为准。第一步加载模块。来到conf/autoload_configs/modules.conf.xml找到modules区域添加load modulemod_da2/保存后重启FreeSWITCH或者通过fs_cli执行load mod_da2加载成功后可以用show modules确认模块是否已经就绪。第二步在呼叫流程中启用检测。针对你要做应答检测的外呼呼叫在bridge前设置检测开关extension nameoutbound_call_with_detect condition fielddestination_number expression^(1[3-9]\d{9})$ action applicationset datada2_detecttrue/ action applicationbridge datasofia/gateway/carrier/$1/ /condition /extension第三步通过ESL或事件监听接收检测结果。mod_da2在检测到媒体特征变化时会触发事件事件中包含呼叫唯一标识、检测到的媒体类型、时间点等信息。外部业务程序订阅这些事件一旦收到检测到语音或等价事件就认为被叫已接听开始执行后续动作。提示不同FreeSWITCH版本的mod_da2在实际命令和事件名上很可能不一样。部署前一定要在测试环境里跑一遍完整流程用一条测试线路确认模块加载、检测触发、事件上报都能通再上生产。这里我还想泼一盆清醒水不要在业务上100%依赖媒体检测。mod_da2是信令之外的补充手段最佳实践是信令优先媒体检测兜底。也就是说如果200 OK正常到达以200 OK为准如果200 OK迟迟不来或明显异常才用媒体检测的结果作为接听依据。两者结合准确率才能拉满。5. 常见问题与排查技巧实录5.1 彩铃透传失败的排查清单如果你已经配置了p-early-media-supporttrue和early-media-passthrutrue主叫还是听不到彩铃请按这个顺序排查抓包确认对端是否真的发送183且携带完整SDP。有些所谓彩铃其实只是对端本地播放并没有真实媒体流。检查FreeSWITCH是否把183转发给A腿以及A腿的SDP媒体地址是否有效。用sofia status profile external查看注册和媒体状态确认媒体端口没有被占用或冲突。检查防火墙和NAT。企业防火墙如果开启了SIP ALG它可能会重写SDP或插入代理导致媒体流指向错误地址。这种情况下优先关闭SIP ALG改用FreeSWITCH自身的NAT穿透参数。确认主叫终端是否支持早期媒体。某些老式话机对183的处理有bug不会接收RTP流只能等200 OK。把这五步走完95%的彩铃透传问题都能定位到具体环节。5.2 被叫接听判断迟滞或错乱的三种解法被叫已经接听但FreeSWITCH没感知最直接的三个解法启用媒体检测就是前面讲的mod_da2方案适合信令不可靠的线路和运营商。用桥接变量规避状态错乱在bridge时合理设置早期媒体相关参数和超时时间让FreeSWITCH不要因为收不到200 OK而一直干等。业务层面做双确认在话术设计上留一个缓冲比如机器人开场白设计成您好然后等待一个短反馈或静音周期再继续主流程。即使系统没有及时知道被叫接听机器人也不会把话说尬。这三种方案可以组合使用效果叠加。我自己在项目里通常是一、三组合信令可靠时跟随信令信令飘忽时靠媒体检测兜底同时话术上始终保留容错。5.3 SIP ALG与NAT对早期媒体的干扰SIP ALG是很多企业防火墙默认开启的功能它的初衷是帮SIP流量做NAT穿透。但在SIP加早期媒体的场景下SIP ALG常常好心办坏事它会修改SDP里的IP地址把本应到达FreeSWITCH的RTP包重定向到别的地址或者在SIP消息里插入额外的Via和Record-Route导致信令路径混乱。我的建议是在FreeSWITCH对外服务的网络边界上关闭防火墙的SIP ALG功能把NAT穿透交给FreeSWITCH自己处理。相关配置一般包括sip_profile里的ext-rtp-ip、ext-sip-ip、apply-nat-acl、aggressive-nat等参数。注意关闭SIP ALG前先在测试环境验证路由和基本呼叫都正常。尤其要确认能不能收到对方的媒体流以及本机能不能把RTP包正确发出去。5.4 排查工具与抓包要点问题发生的时候最快的定位方式是抓包。我常用的组合是SIP信令抓包用Wireshark抓取网卡上的5060端口流量。RTP媒体验证在Wireshark里对SIP RTP做综合过滤直接看SIP对话和RTP流的时序关系。fs_cli在FreeSWITCH上查看呼叫状态和媒体协商信息常用命令包括show channels、sofia status、uuid_dump uuid。抓包时最值得关注的时间线是INVITE发出。183到达是否带SDP、SDP内容是否合法。RTP是否从对端流向本机。是否出现200 OK。ACK是否发出。媒体是否从单向变为双向。很多奇怪的问题只要把这条时间线拉出来答案自己就浮出来了。如果你看到183带了SDP但没有后续RTP那多半是NAT或路由问题如果RTP一直在跑但FreeSWITCH没有转发那问题出在透传配置如果200 OK已经到了但媒体没有切换那问题出在A腿的媒体协商上。最后聊点我自己的体会。早期媒体这个坑几乎每个做FreeSWITCH业务的人都会踩而且踩的方式各不相同。我刚做外呼那阵遇到被叫明明已经接听了、人都在说话了系统还在播放等待音折腾了两天才发现是信令和媒体两个层面的问题交织在一起。后来我把回铃音是本地提示、彩铃是媒体推送这句话刻在脑子里再看信令流程就通透多了。配置层面的p-early-media-support和early-media-passthru是两个最常用的开关但真正治本的思路还是要建立信令为主、媒体检测兜底的双保险。如果你正准备上外呼业务建议提前把mod_da2这类检测机制加进去不要等到被用户投诉了再补。我踩过这个坑所以希望你不用再踩一遍。
