给同事打电话听筒里传来“嘟——嘟——”的等待音你下意识觉得对方手机正在响铃甚至在心里默数响了几声。前阵子我遇到一件挺有意思的事给一位老同事打电话响了六声没人接挂断后微信问他他说手机一直平放在桌上充电屏幕压根没亮过。当时我就在想那个“嘟”到底是谁发出来的这个问题看着简单但真要把它讲清楚得把电话网的信令、语音通道、彩铃平台、VoIP 的早期媒体机制全部串一遍。这一路讲下来你会发现一个反直觉但完全成立的结论你在听筒里听到的“嘟嘟”声绝大多数情况下跟对方手机的扬声器、振动马达没有任何物理关系。这篇文章我打算从这一声“嘟”出发把呼叫建立过程中信令与语音分离的核心逻辑拆开顺带聊聊彩铃为什么能“替换”掉那个声音、为什么打国外电话节奏会变、为什么有时候对方说没响但你确实听到了回铃音。适合对通信原理感兴趣的朋友也适合做网络运维、客服质检、呼叫中心系统开发的同行参考。1. 先搞清楚那声“嘟”到底是谁制造的1.1 一个被误解了很多年的日常现象先把结论摆在最前面传统电话网里你听到的回铃音是由主叫侧的交换机或者移动网络里的主叫端局设备本地产生的跟被叫手机没有直接关系。被叫手机在振铃的时候它只是向网络回了一个“我已经开始振铃了”的信令消息网络收到这个信令后转身在主叫这一侧放一段音频给你听。这个过程有点像你去餐厅点菜服务员跟你说“您的菜已经下单了”这句话是前台说的不是厨房在喊厨房只是回了一个“单子收到了”。这个设计不是偷懒而是被传输成本逼出来的。在早期的模拟电话网和数字程控交换网里通话信道是非常宝贵的资源。一个电话从北京打到广州中间要经过若干个汇接局和长途传输设备如果回铃音要靠被叫侧沿着这条完整链路传到主叫耳朵里那这条话路在对方还没接电话的时候就必须全程打通并占用。长途线路按分钟计费的成本大家都懂为了让你听几声“嘟”而占着一条跨省中继这在工程上是完全不能接受的。所以业界采用的做法是信令走信令网语音走话路网回铃音这种“状态提示音”由主叫端局自己在本地生成只消耗主叫侧的一点点资源。反过来说你听到“嘟”这个事实能证明的事情非常有限。它只能说明主叫到被叫之间的信令链路走通了被叫侧回了一个“地址收全、开始振铃”的信号。至于被叫手机是真在响、是响铃被静音了、还是压根就没响只是网络模拟出来的从这个声音里完全判断不出来。1.2 回铃音、彩铃、忙音、语音提示的区别很多人把这几种声音混在一起其实它们背后的来源和触发条件完全不同我整理了一张对照表方便快速区分。声音类型听感特征产生位置触发条件拨号音连续的“嗡——”主叫端局摘机后、号码未拨完回铃音1秒响、4秒停主叫端局本地生成收到被叫侧地址收全信令彩铃音乐、歌曲、广告语被叫侧彩铃平台被叫用户订购了彩铃业务忙音0.35秒响、0.35秒停主叫端局被叫正在通话中拥塞音0.7秒响、0.7秒停主叫端局或汇接局中继资源不足语音提示“您拨打的电话已关机”语音平台或智能网设备关机、停机、空号等情况看这张表就能明白一件事回铃音和彩铃虽然听起来都是在“等对方接电话”但它们的产生位置正好相反。回铃音是主叫侧的设备在放彩铃是被叫侧的服务器在放两者背后是两套完全不同的业务逻辑。这个差别在下文讲彩铃实现原理的时候会展开这里先记住一点——彩铃能播出来说明被叫侧的语音通道在对方接通之前就已经打通了这恰恰是后来网络带宽变便宜之后才能做到的事情。提示判断一个电话是不是彩铃其实有个很简单的办法。普通回铃音永远严格遵循“响1秒停4秒”的节奏节奏极其规整彩铃是完整音频流节奏由音乐本身决定。如果你听到的声音节奏不规则那基本可以确定是被叫侧的彩铃平台在给你放东西。2. 一通电话从按下拨号键到对方振铃中间经历了什么2.1 信令网和话路网是两条完全独立的路要理解回铃音先得理解电话网的“两层结构”。这是整个通信体系里最容易被忽略、但又是最关键的设计。想象一下铁路系统信令网相当于调度电话系统话路网相当于真正的铁轨和列车。调度系统负责告诉各个车站“有趟车要从A站发往B站请准备好站台”但它本身不运送乘客。在传统电话网里这个“调度系统”就是七号信令网SS7它是一张独立于话路的、专门传送控制消息的分组网络。你拨完号码按下拨号键主叫端局做的第一件事不是接通话路而是往信令网里丢一条消息这条消息叫IAM初始地址消息Initial Address Message里面装着被叫号码、主叫号码、需要的电路编号等信息。IAM 消息会沿着信令链路一跳一跳地传到被叫端局中间可能经过汇接局、长途局。被叫端局收到 IAM 之后会做几件事检查这个号码是否合法、查这个用户当前的状态、给被叫用户的电话机送振铃电流。做完这些之后它回一条ACM地址收全消息Address Complete Message给主叫端局。注意ACM 这条消息的意思不是“对方接电话了”而是“地址收全了我开始让被叫振铃了”。主叫端局收到 ACM才决定给你放那段“嘟——嘟——”的声音。这三条消息的顺序非常重要我把它们并列出来IAM主叫端局发起请求建立呼叫携带被叫号码。ACM被叫端局回应表示号码已收全被叫正在振铃。ANM应答消息Answer Message被叫用户摘机此时计费启动话路正式接通。从 IAM 到 ACM 之间的时间可能很短也可能很长取决于网络寻址的复杂程度、被叫是否漫游、是否跨运营商。这就是为什么有时候你拨完号要等一两秒才听到第一声“嘟”。这段等待时间里网络正在下发和传递 IAM 消息。2.2 为什么回铃音非要由主叫侧来放这里有个很多人会问的问题既然被叫端局知道被叫正在振铃为什么不干脆让被叫端局放一段声音沿着话路传过来答案就是前面提到的——成本。在 ACM 消息里有一个字段叫“带内信息指示”它用来告诉主叫侧“我这边可以提供带内音频你要不要”如果这个字段被置位主叫侧就会把话路接通让被叫侧的声音通常是本地交换机产生的回铃音沿着话路传过来。如果不置位主叫侧就自己本地生成回铃音。早期长途呼叫、国际呼叫基本都会选择后者因为跨长途、跨国的话路资源太贵了。这个设计还带来一个副作用主叫和被叫听到的声音状态是不对称的。在主叫听到“嘟”的时候被叫那边其实已经响铃了两边的时间差主要来自信令传递时延。一般来说这个时延在几十到几百毫秒之间跨运营商、跨地域会更大一些。所以“我听到第二声对方就接了”这种说法在时间上并不精确因为你的第二声和对方的振铃次数并不是一一对应的。还有一点值得说不同国家的回铃音频率和节奏是不一样的这跟各国的电话网标准有关。我把几个主要地区的参数放在下面。国家/地区回铃音频率节奏中国450 Hz响 1 秒、停 4 秒美国440 Hz 480 Hz 双频响 2 秒、停 4 秒英国400 Hz 450 Hz 双频响 0.4 秒、停 0.2 秒、响 0.4 秒、停 2 秒日本400 Hz响 1 秒、停 2 秒这就是为什么你打国际长途的时候会觉得“嘟嘟”的节奏怪怪的不是设备坏了是对方国家的标准本来就不一样。2.3 被叫侧的状态其实是从信令里读出来的被叫手机没接、关机、正在通话这些状态在主叫侧是怎么体现的答案还是在信令里。被叫端局在收到 IAM 之后会去查询被叫用户的状态如果被叫正在通话被叫端局不会回 ACM而是回一条释放消息附带一个“用户忙”的原因值主叫端局收到后就给你放忙音。如果被叫关机或者不在服务区被叫端局同样回释放消息主叫端局就转接语音平台给你播“您拨打的电话已关机”。如果一切正常就回 ACM你听到回铃音。这里有个细节主叫侧是根据信令里的“原因值”来决定放什么音的而不是根据实际听到了什么。这句话的意思是即使用户真的在响铃只要信令里返回的原因值不对主叫侧也可能放错音。反过来也一样网络可以“假装”对方在响铃只要它愿意回一条 ACM 消息。这不是什么黑科技就是协议设计本身的灵活性。3. 手机时代之后这套机制发生了什么变化3.1 移动网络里的呼叫路径更长从固话到了移动网呼叫流程多了好几步。主叫手机发起呼叫后信号先到基站再到主叫侧的移动交换中心MSC。主叫 MSC 要先去查询被叫用户的归属位置寄存器HLR问“这个号码现在在哪个 MSC 下面”。HLR 查到被叫当前登记的拜访位置寄存器VLR和 MSC把路由信息返回来主叫 MSC 才能把呼叫接过去。被叫侧 MSC 收到呼叫请求后要寻呼被叫手机给手机分配无线信道然后向手机下发振铃指令手机才开始响铃或者振动。整个过程涉及无线侧、核心网侧、信令网侧的多级配合链路比固话长得多。这就是为什么手机通话从拨号到听到“嘟”的延迟通常比固话要明显一些尤其在信号不好的地方。而且移动网络里还有个特殊情况被叫手机的响铃状态和网络认为的响铃状态不一定同步。手机可能在收到振铃指令后因为系统卡顿、省电策略、通知权限设置等原因延迟响铃甚至不响铃但网络那边已经按“已振铃”处理了。你听到的“嘟”就是基于网络状态生成的跟手机本地的实际表现无关。3.2 彩铃是怎么做到“替对方响”的彩铃个性化回铃音这套业务的实现思路恰好把前面讲的机制反过来用了。彩铃业务的核心是在被叫侧拦截回铃音用一段音频替换掉它。具体流程大致是这样的被叫用户订购了彩铃业务订购信息记录在归属网络的智能网平台或者彩铃平台上。当有呼叫到达被叫侧时被叫端局或者 MSC 在准备回 ACM 之前先查询这个用户是否订购了彩铃。如果订购了就把这次呼叫的话路接到彩铃平台由彩铃平台向主叫侧播放指定的音频。这里有个关键点彩铃必须走带内音频通道也就是前面提到的那种“让被叫侧放音”的模式。因为彩铃是一段完整的音频流不可能用主叫侧本地生成的方式来播放——主叫侧也不知道该放哪首歌。所以彩铃业务的普及某种程度上依赖于现代网络带宽成本的下降让带内音频传输在经济上变得可行了。这也解释了一个现象有时候彩铃会播到一半突然断掉然后听到正常的回铃音或者直接接通。这种情况通常是彩铃平台和交换机之间的交互出了点小问题比如媒体协商没谈拢或者被叫用户提前接听了。彩铃播到一半被切断在技术上是有可能发生的不是玄学。3.3 智能手机和 VoLTE 带来的新变化到了 4G/5G 时代语音走 VoLTE基于 LTE 的语音之后底层协议从七号信令换成了 SIP会话初始协议。这一变化对回铃音的影响很直接现在很多回铃音是真的从网络侧以音频流的形式送到你手机上的而不是手机本地生成的。在 VoLTE 里主叫手机发起 INVITE 请求被叫侧如果开始振铃会回一个180 Ringing响应。如果这个响应里不带媒体描述SDP主叫侧的设备就会本地生成回铃音如果带媒体描述就会提前建立媒体通道让真实的回铃音或者彩铃以 RTP 流的形式传过来。这就是所谓的“早期媒体”机制。所以现在的回铃音来源其实比以前更复杂了可能是主叫侧设备本地生成的可能是被叫侧彩铃平台推过来的也可能是被叫侧普通交换机生成的。你很难从听感上判断是哪一种除非去抓信令包。4. 为什么你听到的“嘟”不代表对方手机真的在响4.1 呼叫建立和振铃是两件独立的事回到最初的问题。你现在应该能理解这句话的含义了“呼叫建立”和“被叫振铃”是两个由信令协调的独立事件而“回铃音”只是主叫侧对“被叫振铃”这个信令状态的一种音频表示。主叫侧收到 ACM或者 SIP 里的 180就认为“被叫正在振铃”然后放回铃音。至于被叫手机有没有真的响不一定。响了几声不知道。是不是静音了不知道。是不是被系统拦了不知道。这个信息差是协议设计层面的不是某个运营商的“套路”。当然现实中确实存在一些情况会放大这个信息差下面几种我实际遇到过。4.2 几种“听得到嘟声但对方没感觉”的真实场景场景一对方手机处于静音或者勿扰模式。这是最常见的。手机收到振铃指令后系统按用户的设置静音处理了屏幕可能亮一下也可能不亮但网络侧已经正常回了 ACM你这边就会一直“嘟”下去直到呼叫超时或者被转接。场景二对方开启了呼叫转移。如果被叫设置了无条件呼转网络会把呼叫转到另一个号码你听到的回铃音其实是转接后的那个号码引发的。如果设置了遇忙转移或者无应答转移流程会更复杂一些中间可能还会听到一段彩铃或者提示音。场景三对方手机在信号边缘或者刚开机。手机在弱信号区域时网络寻呼可能失败但被叫侧 MSC 在寻呼超时前可能已经回了 ACM。这种情况持续时间不长通常几秒后就会返回失败原因然后你听到语音提示。场景四企业总机或者呼叫中心。这类系统的回铃音经常是平台自己生成的跟被叫座席的实际状态没关系。你听到“嘟”的时候可能系统还在排队座席那边压根没被呼到。场景五主叫侧设备本地放音。前面讲过如果 ACM 里没有带内信息指示回铃音完全由主叫侧生成。这种情况下即使被叫侧在振铃过程中发生了异常只要 ACM 已经发出来了主叫侧还是会正常放回铃音。注意如果你做客服质检或者呼叫中心系统千万不要把“听到回铃音”当作“被叫已被呼叫”的依据。可靠的做法是从信令层面判断或者依赖平台自己记录的呼叫状态事件。4.3 反过来也有对方手机响了但你没听到嘟声这种情况相对少见但确实存在。比如对方接听特别快在你听到第一声“嘟”之前就接通了你就会觉得“一拨就通”。还有一种是彩铃播放的起始时间被延后你在最初几秒听到的是普通回铃音之后才切换成彩铃。VoLTE 网络里如果媒体通道建立得慢也可能出现短暂无声或者听到一段杂音的情况。5. 从 VoIP 到网络通话早期媒体是怎么处理的5.1 SIP 里的 180 和 183前面提到 SIP 协议这里稍微展开一点因为做 VoIP 开发或者呼叫中心系统的同行经常会碰到这两个响应码的区别。主叫方发出INVITE请求后可能收到这么几种响应100 Trying表示请求已收到正在处理这是一个临时响应通常不会触发任何提示音。180 Ringing表示被叫正在振铃。这个响应通常不带 SDP媒体描述主叫侧收到后本地生成回铃音。183 Session Progress表示会话正在进行中可以携带 SDP用来提前建立媒体通道。彩铃、自定义回铃音、语音提示就是靠这个响应传过来的。200 OK被叫接听会话正式建立之后双方开始传输 RTP 媒体流。这个区分非常实用。如果你在抓包时看到 183 且带 SDP说明对方很可能配置了彩铃或者自定义回铃音如果只看到 180那基本就是主叫侧本地放音。下面这段是一个典型的 183 响应示例展示早期媒体的协商过程。SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 10.0.0.1:5060;branchz9hG4bK... From: sip:callerexample.com;tagabc123 To: sip:calleeexample.com;tagxyz789 Call-ID: 123456789010.0.0.1 CSeq: 1 INVITE Content-Type: application/sdp Content-Length: 218 v0 o- 12345 12345 IN IP4 10.0.0.2 sCRBT Session cIN IP4 10.0.0.2 t0 0 maudio 20000 RTP/AVP 0 8 artpmap:0 PCMU/8000 artpmap:8 PCMA/8000看到sCRBT Session这样的会话名基本就能确定这是彩铃平台在推音频流了。这类字段对排查“为什么回铃音不对”特别有用比听录音靠谱得多。5.2 网络通话的“嘟”为什么感觉不太一样用微信语音、企业会议系统这类应用打电话时你听到的等待提示音往往是应用自己生成的本地音频压根没经过运营商网络。这类提示音的特点是响应快、节奏由应用自己定跟运营商的“响1秒停4秒”完全不是一回事。做产品的时候很多团队会选择自己录一段更好听的等待音替换掉系统默认的这在技术上没什么难度只是产品体验层面的取舍。提示如果要在自己的应用里实现“等待音”注意区分两种情况——本地播放的提示音可以在拨号后立刻开始不需要等任何网络响应网络侧推送的早期媒体则必须等 SDP 协商完成中间会有一小段静默期。忽略这个差异用户体验上会显得“卡了一下”。6. 排查这类问题的思路和常见坑6.1 常见现象与排查方向对照实际工作中遇到“回铃音异常”的问题可以用下面这张表快速定位方向。现象可能原因排查方向一直响铃无人接听被叫静音、勿扰、未察觉联系被叫确认手机设置响一声就提示关机被叫侧直接返回失败原因查被叫用户状态、是否欠费停机回铃音节奏异常跨网呼叫、国际呼叫确认被叫归属网络和路由彩铃播放中断媒体协商失败或提前接听抓 183 响应和 RTP 流听不到回铃音直接接通被叫秒接或媒体通道建立慢看呼叫建立时间戳回铃音持续但被叫无感知主叫侧本地生成、被叫静音结合信令日志判断6.2 几个容易踩的坑第一个坑是把回铃音当成接通依据。做外呼系统的时候有些团队会通过检测回铃音来判断“呼叫已到达被叫”然后开始计费或者记录状态。这个做法在技术上是不严谨的因为回铃音只代表收到了 ACM不代表被叫真的被呼到了。正确的方式是解析信令消息拿到 180 或者 ACM 之后再结合被叫侧的确认信息。第二个坑是忽略运营商之间的实现差异。同样是“被叫振铃”不同运营商、不同网络制式下的具体行为可能不同。比如某些网络在被叫未接时可能播放一段语音提示另一些网络则直接返回释放消息。做跨运营商业务的时候一定要用真实号码做全量测试不能只看文档。第三个坑是在 VoLTE 环境下依赖本地放音。有些老系统还保持着“主叫侧本地生成回铃音”的逻辑但在 VoLTE 环境下如果被叫侧推送了早期媒体就会出现两段声音重叠的情况。处理方式是在 SDP 协商成功后判断是否需要关闭本地放音。第四个坑是对彩铃平台的时延预期过高。彩铃需要先查询用户订购信息再建立媒体通道再开始播放这中间会有几百毫秒的延迟。如果你在开发中设了很短的超时阈值可能会误判成呼叫失败。6.3 一个实用的小工具思路如果你想自己验证回铃音到底是谁放出来的最直接的办法是在手机侧录音然后用音频分析软件看频谱。中国标准回铃音是纯粹的 450 Hz 单频信号波形非常干净频谱上就是一根竖线彩铃是音乐频谱是连续分布的。这个区别一目了然比听感判断靠谱得多。手机上装一个能显示频谱的录音 App 就够了成本几乎为零。再进阶一点如果是做 VoIP 系统直接用 Wireshark 抓 SIP 包看到底是 180 还是 183有没有带 SDP一看便知。这套方法我在排查“为什么彩铃不生效”的问题时用过很多次比翻文档快得多。我个人在实际操作中的体会是回铃音这个问题之所以容易引起误解本质上是因为音频反馈和系统状态之间没有强绑定关系。电话网的设计哲学是“用最低的成本传递最必要的信息”回铃音承担的是“提示用户等待”的功能而不是“准确反映被叫状态”的功能。理解了这个设计初衷很多看起来奇怪的现象就都能解释了。后续如果你在做呼叫相关的系统建议把音频提示和信令状态这两条线彻底分开对待音频只负责体验状态判断一律走信令这样系统会稳很多。
电话里的“嘟嘟”声是谁发出的？详解回铃音与信令机制
给同事打电话听筒里传来“嘟——嘟——”的等待音你下意识觉得对方手机正在响铃甚至在心里默数响了几声。前阵子我遇到一件挺有意思的事给一位老同事打电话响了六声没人接挂断后微信问他他说手机一直平放在桌上充电屏幕压根没亮过。当时我就在想那个“嘟”到底是谁发出来的这个问题看着简单但真要把它讲清楚得把电话网的信令、语音通道、彩铃平台、VoIP 的早期媒体机制全部串一遍。这一路讲下来你会发现一个反直觉但完全成立的结论你在听筒里听到的“嘟嘟”声绝大多数情况下跟对方手机的扬声器、振动马达没有任何物理关系。这篇文章我打算从这一声“嘟”出发把呼叫建立过程中信令与语音分离的核心逻辑拆开顺带聊聊彩铃为什么能“替换”掉那个声音、为什么打国外电话节奏会变、为什么有时候对方说没响但你确实听到了回铃音。适合对通信原理感兴趣的朋友也适合做网络运维、客服质检、呼叫中心系统开发的同行参考。1. 先搞清楚那声“嘟”到底是谁制造的1.1 一个被误解了很多年的日常现象先把结论摆在最前面传统电话网里你听到的回铃音是由主叫侧的交换机或者移动网络里的主叫端局设备本地产生的跟被叫手机没有直接关系。被叫手机在振铃的时候它只是向网络回了一个“我已经开始振铃了”的信令消息网络收到这个信令后转身在主叫这一侧放一段音频给你听。这个过程有点像你去餐厅点菜服务员跟你说“您的菜已经下单了”这句话是前台说的不是厨房在喊厨房只是回了一个“单子收到了”。这个设计不是偷懒而是被传输成本逼出来的。在早期的模拟电话网和数字程控交换网里通话信道是非常宝贵的资源。一个电话从北京打到广州中间要经过若干个汇接局和长途传输设备如果回铃音要靠被叫侧沿着这条完整链路传到主叫耳朵里那这条话路在对方还没接电话的时候就必须全程打通并占用。长途线路按分钟计费的成本大家都懂为了让你听几声“嘟”而占着一条跨省中继这在工程上是完全不能接受的。所以业界采用的做法是信令走信令网语音走话路网回铃音这种“状态提示音”由主叫端局自己在本地生成只消耗主叫侧的一点点资源。反过来说你听到“嘟”这个事实能证明的事情非常有限。它只能说明主叫到被叫之间的信令链路走通了被叫侧回了一个“地址收全、开始振铃”的信号。至于被叫手机是真在响、是响铃被静音了、还是压根就没响只是网络模拟出来的从这个声音里完全判断不出来。1.2 回铃音、彩铃、忙音、语音提示的区别很多人把这几种声音混在一起其实它们背后的来源和触发条件完全不同我整理了一张对照表方便快速区分。声音类型听感特征产生位置触发条件拨号音连续的“嗡——”主叫端局摘机后、号码未拨完回铃音1秒响、4秒停主叫端局本地生成收到被叫侧地址收全信令彩铃音乐、歌曲、广告语被叫侧彩铃平台被叫用户订购了彩铃业务忙音0.35秒响、0.35秒停主叫端局被叫正在通话中拥塞音0.7秒响、0.7秒停主叫端局或汇接局中继资源不足语音提示“您拨打的电话已关机”语音平台或智能网设备关机、停机、空号等情况看这张表就能明白一件事回铃音和彩铃虽然听起来都是在“等对方接电话”但它们的产生位置正好相反。回铃音是主叫侧的设备在放彩铃是被叫侧的服务器在放两者背后是两套完全不同的业务逻辑。这个差别在下文讲彩铃实现原理的时候会展开这里先记住一点——彩铃能播出来说明被叫侧的语音通道在对方接通之前就已经打通了这恰恰是后来网络带宽变便宜之后才能做到的事情。提示判断一个电话是不是彩铃其实有个很简单的办法。普通回铃音永远严格遵循“响1秒停4秒”的节奏节奏极其规整彩铃是完整音频流节奏由音乐本身决定。如果你听到的声音节奏不规则那基本可以确定是被叫侧的彩铃平台在给你放东西。2. 一通电话从按下拨号键到对方振铃中间经历了什么2.1 信令网和话路网是两条完全独立的路要理解回铃音先得理解电话网的“两层结构”。这是整个通信体系里最容易被忽略、但又是最关键的设计。想象一下铁路系统信令网相当于调度电话系统话路网相当于真正的铁轨和列车。调度系统负责告诉各个车站“有趟车要从A站发往B站请准备好站台”但它本身不运送乘客。在传统电话网里这个“调度系统”就是七号信令网SS7它是一张独立于话路的、专门传送控制消息的分组网络。你拨完号码按下拨号键主叫端局做的第一件事不是接通话路而是往信令网里丢一条消息这条消息叫IAM初始地址消息Initial Address Message里面装着被叫号码、主叫号码、需要的电路编号等信息。IAM 消息会沿着信令链路一跳一跳地传到被叫端局中间可能经过汇接局、长途局。被叫端局收到 IAM 之后会做几件事检查这个号码是否合法、查这个用户当前的状态、给被叫用户的电话机送振铃电流。做完这些之后它回一条ACM地址收全消息Address Complete Message给主叫端局。注意ACM 这条消息的意思不是“对方接电话了”而是“地址收全了我开始让被叫振铃了”。主叫端局收到 ACM才决定给你放那段“嘟——嘟——”的声音。这三条消息的顺序非常重要我把它们并列出来IAM主叫端局发起请求建立呼叫携带被叫号码。ACM被叫端局回应表示号码已收全被叫正在振铃。ANM应答消息Answer Message被叫用户摘机此时计费启动话路正式接通。从 IAM 到 ACM 之间的时间可能很短也可能很长取决于网络寻址的复杂程度、被叫是否漫游、是否跨运营商。这就是为什么有时候你拨完号要等一两秒才听到第一声“嘟”。这段等待时间里网络正在下发和传递 IAM 消息。2.2 为什么回铃音非要由主叫侧来放这里有个很多人会问的问题既然被叫端局知道被叫正在振铃为什么不干脆让被叫端局放一段声音沿着话路传过来答案就是前面提到的——成本。在 ACM 消息里有一个字段叫“带内信息指示”它用来告诉主叫侧“我这边可以提供带内音频你要不要”如果这个字段被置位主叫侧就会把话路接通让被叫侧的声音通常是本地交换机产生的回铃音沿着话路传过来。如果不置位主叫侧就自己本地生成回铃音。早期长途呼叫、国际呼叫基本都会选择后者因为跨长途、跨国的话路资源太贵了。这个设计还带来一个副作用主叫和被叫听到的声音状态是不对称的。在主叫听到“嘟”的时候被叫那边其实已经响铃了两边的时间差主要来自信令传递时延。一般来说这个时延在几十到几百毫秒之间跨运营商、跨地域会更大一些。所以“我听到第二声对方就接了”这种说法在时间上并不精确因为你的第二声和对方的振铃次数并不是一一对应的。还有一点值得说不同国家的回铃音频率和节奏是不一样的这跟各国的电话网标准有关。我把几个主要地区的参数放在下面。国家/地区回铃音频率节奏中国450 Hz响 1 秒、停 4 秒美国440 Hz 480 Hz 双频响 2 秒、停 4 秒英国400 Hz 450 Hz 双频响 0.4 秒、停 0.2 秒、响 0.4 秒、停 2 秒日本400 Hz响 1 秒、停 2 秒这就是为什么你打国际长途的时候会觉得“嘟嘟”的节奏怪怪的不是设备坏了是对方国家的标准本来就不一样。2.3 被叫侧的状态其实是从信令里读出来的被叫手机没接、关机、正在通话这些状态在主叫侧是怎么体现的答案还是在信令里。被叫端局在收到 IAM 之后会去查询被叫用户的状态如果被叫正在通话被叫端局不会回 ACM而是回一条释放消息附带一个“用户忙”的原因值主叫端局收到后就给你放忙音。如果被叫关机或者不在服务区被叫端局同样回释放消息主叫端局就转接语音平台给你播“您拨打的电话已关机”。如果一切正常就回 ACM你听到回铃音。这里有个细节主叫侧是根据信令里的“原因值”来决定放什么音的而不是根据实际听到了什么。这句话的意思是即使用户真的在响铃只要信令里返回的原因值不对主叫侧也可能放错音。反过来也一样网络可以“假装”对方在响铃只要它愿意回一条 ACM 消息。这不是什么黑科技就是协议设计本身的灵活性。3. 手机时代之后这套机制发生了什么变化3.1 移动网络里的呼叫路径更长从固话到了移动网呼叫流程多了好几步。主叫手机发起呼叫后信号先到基站再到主叫侧的移动交换中心MSC。主叫 MSC 要先去查询被叫用户的归属位置寄存器HLR问“这个号码现在在哪个 MSC 下面”。HLR 查到被叫当前登记的拜访位置寄存器VLR和 MSC把路由信息返回来主叫 MSC 才能把呼叫接过去。被叫侧 MSC 收到呼叫请求后要寻呼被叫手机给手机分配无线信道然后向手机下发振铃指令手机才开始响铃或者振动。整个过程涉及无线侧、核心网侧、信令网侧的多级配合链路比固话长得多。这就是为什么手机通话从拨号到听到“嘟”的延迟通常比固话要明显一些尤其在信号不好的地方。而且移动网络里还有个特殊情况被叫手机的响铃状态和网络认为的响铃状态不一定同步。手机可能在收到振铃指令后因为系统卡顿、省电策略、通知权限设置等原因延迟响铃甚至不响铃但网络那边已经按“已振铃”处理了。你听到的“嘟”就是基于网络状态生成的跟手机本地的实际表现无关。3.2 彩铃是怎么做到“替对方响”的彩铃个性化回铃音这套业务的实现思路恰好把前面讲的机制反过来用了。彩铃业务的核心是在被叫侧拦截回铃音用一段音频替换掉它。具体流程大致是这样的被叫用户订购了彩铃业务订购信息记录在归属网络的智能网平台或者彩铃平台上。当有呼叫到达被叫侧时被叫端局或者 MSC 在准备回 ACM 之前先查询这个用户是否订购了彩铃。如果订购了就把这次呼叫的话路接到彩铃平台由彩铃平台向主叫侧播放指定的音频。这里有个关键点彩铃必须走带内音频通道也就是前面提到的那种“让被叫侧放音”的模式。因为彩铃是一段完整的音频流不可能用主叫侧本地生成的方式来播放——主叫侧也不知道该放哪首歌。所以彩铃业务的普及某种程度上依赖于现代网络带宽成本的下降让带内音频传输在经济上变得可行了。这也解释了一个现象有时候彩铃会播到一半突然断掉然后听到正常的回铃音或者直接接通。这种情况通常是彩铃平台和交换机之间的交互出了点小问题比如媒体协商没谈拢或者被叫用户提前接听了。彩铃播到一半被切断在技术上是有可能发生的不是玄学。3.3 智能手机和 VoLTE 带来的新变化到了 4G/5G 时代语音走 VoLTE基于 LTE 的语音之后底层协议从七号信令换成了 SIP会话初始协议。这一变化对回铃音的影响很直接现在很多回铃音是真的从网络侧以音频流的形式送到你手机上的而不是手机本地生成的。在 VoLTE 里主叫手机发起 INVITE 请求被叫侧如果开始振铃会回一个180 Ringing响应。如果这个响应里不带媒体描述SDP主叫侧的设备就会本地生成回铃音如果带媒体描述就会提前建立媒体通道让真实的回铃音或者彩铃以 RTP 流的形式传过来。这就是所谓的“早期媒体”机制。所以现在的回铃音来源其实比以前更复杂了可能是主叫侧设备本地生成的可能是被叫侧彩铃平台推过来的也可能是被叫侧普通交换机生成的。你很难从听感上判断是哪一种除非去抓信令包。4. 为什么你听到的“嘟”不代表对方手机真的在响4.1 呼叫建立和振铃是两件独立的事回到最初的问题。你现在应该能理解这句话的含义了“呼叫建立”和“被叫振铃”是两个由信令协调的独立事件而“回铃音”只是主叫侧对“被叫振铃”这个信令状态的一种音频表示。主叫侧收到 ACM或者 SIP 里的 180就认为“被叫正在振铃”然后放回铃音。至于被叫手机有没有真的响不一定。响了几声不知道。是不是静音了不知道。是不是被系统拦了不知道。这个信息差是协议设计层面的不是某个运营商的“套路”。当然现实中确实存在一些情况会放大这个信息差下面几种我实际遇到过。4.2 几种“听得到嘟声但对方没感觉”的真实场景场景一对方手机处于静音或者勿扰模式。这是最常见的。手机收到振铃指令后系统按用户的设置静音处理了屏幕可能亮一下也可能不亮但网络侧已经正常回了 ACM你这边就会一直“嘟”下去直到呼叫超时或者被转接。场景二对方开启了呼叫转移。如果被叫设置了无条件呼转网络会把呼叫转到另一个号码你听到的回铃音其实是转接后的那个号码引发的。如果设置了遇忙转移或者无应答转移流程会更复杂一些中间可能还会听到一段彩铃或者提示音。场景三对方手机在信号边缘或者刚开机。手机在弱信号区域时网络寻呼可能失败但被叫侧 MSC 在寻呼超时前可能已经回了 ACM。这种情况持续时间不长通常几秒后就会返回失败原因然后你听到语音提示。场景四企业总机或者呼叫中心。这类系统的回铃音经常是平台自己生成的跟被叫座席的实际状态没关系。你听到“嘟”的时候可能系统还在排队座席那边压根没被呼到。场景五主叫侧设备本地放音。前面讲过如果 ACM 里没有带内信息指示回铃音完全由主叫侧生成。这种情况下即使被叫侧在振铃过程中发生了异常只要 ACM 已经发出来了主叫侧还是会正常放回铃音。注意如果你做客服质检或者呼叫中心系统千万不要把“听到回铃音”当作“被叫已被呼叫”的依据。可靠的做法是从信令层面判断或者依赖平台自己记录的呼叫状态事件。4.3 反过来也有对方手机响了但你没听到嘟声这种情况相对少见但确实存在。比如对方接听特别快在你听到第一声“嘟”之前就接通了你就会觉得“一拨就通”。还有一种是彩铃播放的起始时间被延后你在最初几秒听到的是普通回铃音之后才切换成彩铃。VoLTE 网络里如果媒体通道建立得慢也可能出现短暂无声或者听到一段杂音的情况。5. 从 VoIP 到网络通话早期媒体是怎么处理的5.1 SIP 里的 180 和 183前面提到 SIP 协议这里稍微展开一点因为做 VoIP 开发或者呼叫中心系统的同行经常会碰到这两个响应码的区别。主叫方发出INVITE请求后可能收到这么几种响应100 Trying表示请求已收到正在处理这是一个临时响应通常不会触发任何提示音。180 Ringing表示被叫正在振铃。这个响应通常不带 SDP媒体描述主叫侧收到后本地生成回铃音。183 Session Progress表示会话正在进行中可以携带 SDP用来提前建立媒体通道。彩铃、自定义回铃音、语音提示就是靠这个响应传过来的。200 OK被叫接听会话正式建立之后双方开始传输 RTP 媒体流。这个区分非常实用。如果你在抓包时看到 183 且带 SDP说明对方很可能配置了彩铃或者自定义回铃音如果只看到 180那基本就是主叫侧本地放音。下面这段是一个典型的 183 响应示例展示早期媒体的协商过程。SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 10.0.0.1:5060;branchz9hG4bK... From: sip:callerexample.com;tagabc123 To: sip:calleeexample.com;tagxyz789 Call-ID: 123456789010.0.0.1 CSeq: 1 INVITE Content-Type: application/sdp Content-Length: 218 v0 o- 12345 12345 IN IP4 10.0.0.2 sCRBT Session cIN IP4 10.0.0.2 t0 0 maudio 20000 RTP/AVP 0 8 artpmap:0 PCMU/8000 artpmap:8 PCMA/8000看到sCRBT Session这样的会话名基本就能确定这是彩铃平台在推音频流了。这类字段对排查“为什么回铃音不对”特别有用比听录音靠谱得多。5.2 网络通话的“嘟”为什么感觉不太一样用微信语音、企业会议系统这类应用打电话时你听到的等待提示音往往是应用自己生成的本地音频压根没经过运营商网络。这类提示音的特点是响应快、节奏由应用自己定跟运营商的“响1秒停4秒”完全不是一回事。做产品的时候很多团队会选择自己录一段更好听的等待音替换掉系统默认的这在技术上没什么难度只是产品体验层面的取舍。提示如果要在自己的应用里实现“等待音”注意区分两种情况——本地播放的提示音可以在拨号后立刻开始不需要等任何网络响应网络侧推送的早期媒体则必须等 SDP 协商完成中间会有一小段静默期。忽略这个差异用户体验上会显得“卡了一下”。6. 排查这类问题的思路和常见坑6.1 常见现象与排查方向对照实际工作中遇到“回铃音异常”的问题可以用下面这张表快速定位方向。现象可能原因排查方向一直响铃无人接听被叫静音、勿扰、未察觉联系被叫确认手机设置响一声就提示关机被叫侧直接返回失败原因查被叫用户状态、是否欠费停机回铃音节奏异常跨网呼叫、国际呼叫确认被叫归属网络和路由彩铃播放中断媒体协商失败或提前接听抓 183 响应和 RTP 流听不到回铃音直接接通被叫秒接或媒体通道建立慢看呼叫建立时间戳回铃音持续但被叫无感知主叫侧本地生成、被叫静音结合信令日志判断6.2 几个容易踩的坑第一个坑是把回铃音当成接通依据。做外呼系统的时候有些团队会通过检测回铃音来判断“呼叫已到达被叫”然后开始计费或者记录状态。这个做法在技术上是不严谨的因为回铃音只代表收到了 ACM不代表被叫真的被呼到了。正确的方式是解析信令消息拿到 180 或者 ACM 之后再结合被叫侧的确认信息。第二个坑是忽略运营商之间的实现差异。同样是“被叫振铃”不同运营商、不同网络制式下的具体行为可能不同。比如某些网络在被叫未接时可能播放一段语音提示另一些网络则直接返回释放消息。做跨运营商业务的时候一定要用真实号码做全量测试不能只看文档。第三个坑是在 VoLTE 环境下依赖本地放音。有些老系统还保持着“主叫侧本地生成回铃音”的逻辑但在 VoLTE 环境下如果被叫侧推送了早期媒体就会出现两段声音重叠的情况。处理方式是在 SDP 协商成功后判断是否需要关闭本地放音。第四个坑是对彩铃平台的时延预期过高。彩铃需要先查询用户订购信息再建立媒体通道再开始播放这中间会有几百毫秒的延迟。如果你在开发中设了很短的超时阈值可能会误判成呼叫失败。6.3 一个实用的小工具思路如果你想自己验证回铃音到底是谁放出来的最直接的办法是在手机侧录音然后用音频分析软件看频谱。中国标准回铃音是纯粹的 450 Hz 单频信号波形非常干净频谱上就是一根竖线彩铃是音乐频谱是连续分布的。这个区别一目了然比听感判断靠谱得多。手机上装一个能显示频谱的录音 App 就够了成本几乎为零。再进阶一点如果是做 VoIP 系统直接用 Wireshark 抓 SIP 包看到底是 180 还是 183有没有带 SDP一看便知。这套方法我在排查“为什么彩铃不生效”的问题时用过很多次比翻文档快得多。我个人在实际操作中的体会是回铃音这个问题之所以容易引起误解本质上是因为音频反馈和系统状态之间没有强绑定关系。电话网的设计哲学是“用最低的成本传递最必要的信息”回铃音承担的是“提示用户等待”的功能而不是“准确反映被叫状态”的功能。理解了这个设计初衷很多看起来奇怪的现象就都能解释了。后续如果你在做呼叫相关的系统建议把音频提示和信令状态这两条线彻底分开对待音频只负责体验状态判断一律走信令这样系统会稳很多。
