企业官网建设流程全解析

给同事打电话，听筒里传来“嘟——嘟——”的等待音，你下意识觉得对方手机正在响铃，甚至在心里默数响了几声。前阵子我遇到一件挺有意思的事：给一位老同事打电话，响了六声没人接，挂断后微信问他，他说手机一直平放在桌上充电，屏幕压根没亮过。当时我就在想，那个“嘟”到底是谁发出来的？这个问题看着简单，但真要把它讲清楚，得把电话网的信令、语音通道、彩铃平台、VoIP 的早期媒体机制全部串一遍。这一路讲下来，你会发现一个反直觉但完全成立的结论：你在听筒里听到的“嘟嘟”声，绝大多数情况下跟对方手机的扬声器、振动马达没有任何物理关系。这篇文章我打算从这一声“嘟”出发，把呼叫建立过程中信令与语音分离的核心逻辑拆开，顺带聊聊彩铃为什么能“替换”掉那个声音、为什么打国外电话节奏会变、为什么有时候对方说没响但你确实听到了回铃音。适合对通信原理感兴趣的朋友，也适合做网络运维、客服质检、呼叫中心系统开发的同行参考。

1. 先搞清楚那声“嘟”到底是谁制造的

1.1 一个被误解了很多年的日常现象

先把结论摆在最前面：传统电话网里，你听到的回铃音是由主叫侧的交换机（或者移动网络里的主叫端局设备）本地产生的，跟被叫手机没有直接关系。被叫手机在振铃的时候，它只是向网络回了一个“我已经开始振铃了”的信令消息，网络收到这个信令后，转身在主叫这一侧放一段音频给你听。这个过程有点像你去餐厅点菜，服务员跟你说“您的菜已经下单了”，这句话是前台说的，不是厨房在喊，厨房只是回了一个“单子收到了”。

这个设计不是偷懒，而是被传输成本逼出来的。在早期的模拟电话网和数字程控交换网里，通话信道是非常宝贵的资源。一个电话从北京打到广州，中间要经过若干个汇接局和长途传输设备，如果回铃音要靠被叫侧沿着这条完整链路传到主叫耳朵里，那这条话路在对方还没接电话的时候就必须全程打通并占用。长途线路按分钟计费的成本大家都懂，为了让你听几声“嘟”而占着一条跨省中继，这在工程上是完全不能接受的。所以业界采用的做法是：信令走信令网，语音走话路网，回铃音这种“状态提示音”由主叫端局自己在本地生成，只消耗主叫侧的一点点资源。

反过来说，你听到“嘟”这个事实，能证明的事情非常有限。它只能说明主叫到被叫之间的信令链路走通了，被叫侧回了一个“地址收全、开始振铃”的信号。至于被叫手机是真在响、是响铃被静音了、还是压根就没响只是网络模拟出来的，从这个声音里完全判断不出来。

1.2 回铃音、彩铃、忙音、语音提示的区别

很多人把这几种声音混在一起，其实它们背后的来源和触发条件完全不同，我整理了一张对照表，方便快速区分。

看这张表就能明白一件事：回铃音和彩铃虽然听起来都是在“等对方接电话”，但它们的产生位置正好相反。回铃音是主叫侧的设备在放，彩铃是被叫侧的服务器在放，两者背后是两套完全不同的业务逻辑。这个差别在下文讲彩铃实现原理的时候会展开，这里先记住一点——彩铃能播出来，说明被叫侧的语音通道在对方接通之前就已经打通了，这恰恰是后来网络带宽变便宜之后才能做到的事情。

提示：判断一个电话是不是彩铃，其实有个很简单的办法。普通回铃音永远严格遵循“响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 消息里有一个字段叫“带内信息指示”，它用来告诉主叫侧：“我这边可以提供带内音频，你要不要？”如果这个字段被置位，主叫侧就会把话路接通，让被叫侧的声音（通常是本地交换机产生的回铃音）沿着话路传过来。如果不置位，主叫侧就自己本地生成回铃音。早期长途呼叫、国际呼叫基本都会选择后者，因为跨长途、跨国的话路资源太贵了。

这个设计还带来一个副作用：主叫和被叫听到的声音状态是不对称的。在主叫听到“嘟”的时候，被叫那边其实已经响铃了，两边的时间差主要来自信令传递时延。一般来说这个时延在几十到几百毫秒之间，跨运营商、跨地域会更大一些。所以“我听到第二声对方就接了”这种说法，在时间上并不精确，因为你的第二声和对方的振铃次数并不是一一对应的。

还有一点值得说：不同国家的回铃音频率和节奏是不一样的，这跟各国的电话网标准有关。我把几个主要地区的参数放在下面。

这就是为什么你打国际长途的时候，会觉得“嘟嘟”的节奏怪怪的，不是设备坏了，是对方国家的标准本来就不一样。

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;branch=z9hG4bK... From: <sip:caller@example.com>;tag=abc123 To: <sip:callee@example.com>;tag=xyz789 Call-ID: 1234567890@10.0.0.1 CSeq: 1 INVITE Content-Type: application/sdp Content-Length: 218 v=0 o=- 12345 12345 IN IP4 10.0.0.2 s=CRBT Session c=IN IP4 10.0.0.2 t=0 0 m=audio 20000 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000

看到s=CRBT Session这样的会话名，基本就能确定这是彩铃平台在推音频流了。这类字段对排查“为什么回铃音不对”特别有用，比听录音靠谱得多。

5.2 网络通话的“嘟”为什么感觉不太一样

用微信语音、企业会议系统这类应用打电话时，你听到的等待提示音往往是应用自己生成的本地音频，压根没经过运营商网络。这类提示音的特点是响应快、节奏由应用自己定，跟运营商的“响1秒停4秒”完全不是一回事。做产品的时候，很多团队会选择自己录一段更好听的等待音替换掉系统默认的，这在技术上没什么难度，只是产品体验层面的取舍。

提示：如果要在自己的应用里实现“等待音”，注意区分两种情况——本地播放的提示音可以在拨号后立刻开始，不需要等任何网络响应；网络侧推送的早期媒体则必须等 SDP 协商完成，中间会有一小段静默期。忽略这个差异，用户体验上会显得“卡了一下”。

6. 排查这类问题的思路和常见坑

6.1 常见现象与排查方向对照

实际工作中遇到“回铃音异常”的问题，可以用下面这张表快速定位方向。

6.2 几个容易踩的坑

第一个坑是把回铃音当成接通依据。做外呼系统的时候，有些团队会通过检测回铃音来判断“呼叫已到达被叫”，然后开始计费或者记录状态。这个做法在技术上是不严谨的，因为回铃音只代表收到了 ACM，不代表被叫真的被呼到了。正确的方式是解析信令消息，拿到 180 或者 ACM 之后，再结合被叫侧的确认信息。

第二个坑是忽略运营商之间的实现差异。同样是“被叫振铃”，不同运营商、不同网络制式下的具体行为可能不同。比如某些网络在被叫未接时可能播放一段语音提示，另一些网络则直接返回释放消息。做跨运营商业务的时候，一定要用真实号码做全量测试，不能只看文档。

第三个坑是在 VoLTE 环境下依赖本地放音。有些老系统还保持着“主叫侧本地生成回铃音”的逻辑，但在 VoLTE 环境下如果被叫侧推送了早期媒体，就会出现两段声音重叠的情况。处理方式是在 SDP 协商成功后，判断是否需要关闭本地放音。

第四个坑是对彩铃平台的时延预期过高。彩铃需要先查询用户订购信息，再建立媒体通道，再开始播放，这中间会有几百毫秒的延迟。如果你在开发中设了很短的超时阈值，可能会误判成呼叫失败。

6.3 一个实用的小工具思路

如果你想自己验证回铃音到底是谁放出来的，最直接的办法是在手机侧录音，然后用音频分析软件看频谱。中国标准回铃音是纯粹的 450 Hz 单频信号，波形非常干净，频谱上就是一根竖线；彩铃是音乐，频谱是连续分布的。这个区别一目了然，比听感判断靠谱得多。手机上装一个能显示频谱的录音 App 就够了，成本几乎为零。

再进阶一点，如果是做 VoIP 系统，直接用 Wireshark 抓 SIP 包，看到底是 180 还是 183，有没有带 SDP，一看便知。这套方法我在排查“为什么彩铃不生效”的问题时用过很多次，比翻文档快得多。

我个人在实际操作中的体会是，回铃音这个问题之所以容易引起误解，本质上是因为音频反馈和系统状态之间没有强绑定关系。电话网的设计哲学是“用最低的成本传递最必要的信息”，回铃音承担的是“提示用户等待”的功能，而不是“准确反映被叫状态”的功能。理解了这个设计初衷，很多看起来奇怪的现象就都能解释了。后续如果你在做呼叫相关的系统，建议把音频提示和信令状态这两条线彻底分开对待，音频只负责体验，状态判断一律走信令，这样系统会稳很多。