在维护SIP防爆电话时，REGISTER事务返回200 OK，只能确认终端已经与注册服务器成功建立经过认证的地址绑定关系。它并不能保证INVITE能够被正确路由，也不能保证SDP可以协商出兼容的编解码器，更不能保证RTP媒体能够在防爆电话与对端之间双向通过。换句话说，“已注册”只描述了SIP控制平面可达性的一部分，并不代表端到端通话能力已经完整可用。
因此，防爆电话即使显示注册正常，仍可能出现不振铃、接通后无声音、单向语音，或者接听后立即断开的情况。很多时候，真正的故障并不在注册服务器，而是在注册之后的信令路径、媒体路径或本地音频链路。按照信令、媒体、终端音频三个层次排查，可以把“已经注册但打不了电话”这种模糊现象拆成一系列可独立验证的步骤，也能避免反复重启设备却始终查错方向。
为什么“已注册”不等于电话一定可以正常呼叫？
首先要看清注册到底完成了什么。终端发送的REGISTER请求通常包含几个重要字段：Request-URI用于标识注册域；To表示正在注册的账号，也就是Address-of-Record（AOR）；Contact表示终端当前可到达的地址，通常是IP地址和端口；Expires则定义注册绑定的有效时间。
注册并不是一次性操作。平台会在位置服务中保存一条关系，表示某个AOR当前可以通过某个Contact到达。这个绑定关系有过期时间，常见配置约为1小时。终端必须在到期前刷新注册，否则平台最终可能把该分机判断为离线。
认证通常需要两次交互。终端先发送不带凭据的REGISTER，服务器返回401 Unauthorized，并携带realm、nonce等挑战参数。终端使用账号凭据计算认证摘要，再发送一个带Authorization头的REGISTER，随后通常才会收到200 OK。因此从信令角度看，“注册成功”只是说明终端与服务器刚刚完成了一次经过认证的REGISTER事务。
真正的电话呼叫还需要更多环节。用户拨号后，终端必须生成INVITE；PBX、SIP服务器或调度平台必须根据号码规则和权限把被叫号码正确路由；双方还要通过SDP协商编解码器、媒体地址和RTP端口，之后语音才可能真正传输。
信令和媒体还可能走不同的路径。SIP信令通常使用UDP/TCP 5060或TLS 5061，而RTP一般使用另一段动态UDP端口范围。如果防火墙放行了5060，却阻断了RTP端口范围，就会出现注册完全正常、通话却没有声音的情况。
REGISTER成功
→ SIP账号显示在线
→ INVITE仍可能被拒绝
→ 即使返回200 OK
→ RTP仍可能被防火墙、NAT或错误的媒体地址阻断
→ 即使RTP已经到达终端
→ 本地麦克风或扬声器仍可能发生故障
核心结论很简单：注册状态只是某个时间点一次事务成功的快照，并不能证明端到端语音一定可用。它甚至不能证明此刻网络仍然可达，因为注册会周期性刷新，界面上显示的“已注册”状态可能只是上一次刷新成功留下的结果。
先判断故障发生在呼叫建立还是语音媒体
当有人反馈电话“已经注册但打不了”，第一步不应该直接修改编解码或网络参数，而是先明确“打不了”到底是什么现象。在使用任何工具之前，只需问几个问题，通常就能确定排障方向。
一个完整的SIP通话可以分成两个主要阶段。第一个阶段是呼叫建立，从INVITE开始，一直到被叫返回200 OK、主叫发送ACK。第二个阶段是语音媒体，此时SDP协商已经完成，双向RTP应该开始实际传输。最简单的分界线，就是界面是否已经显示通话接通。
如果一拨号就报错、没有振铃，或者对端完全看不到来电，问题更可能出在SIP信令或呼叫路由。如果双方都显示已接通、通话计时已经开始，但没有声音或只有单向声音，就应把排查重点转到SDP与RTP媒体路径。
| 现象 | 可能阶段 | 优先检查 |
|---|---|---|
| 拨号立即报错 / 不振铃 / 对端完全收不到 | 呼叫建立 | 号码路由、权限、SIP响应码、信令可达性 |
| 显示已接通但没有声音 | 语音媒体 | SDP媒体地址、RTP端口、防火墙、NAT、编解码 |
| 通话接通但只有单向声音 | 语音媒体 | 按方向对比SDP、RTP、NAT映射和抓取到的媒体流 |
| 接通几秒后断开 | 呼叫建立 + 媒体 | ACK、Session Timer、NAT超时、平台释放策略 |
| 声音断续或间歇性异常 | 媒体传输质量 | 丢包、抖动、时延、带宽和RTP端口变化 |
还有两种模式也很有参考价值。如果电话能呼出却无法接听，原因往往与入呼号码路由、Contact地址、NAT或平台路由有关；如果能接听却无法呼出，则应把检查重点转向拨号计划、外呼权限、号码格式或SIP中继配置。
如果普通SIP分机之间可以互拨，但拨打调度台、广播系统或PSTN失败，故障范围就已经明显缩小，更可能与某一条特定路由或系统接口有关。
一份有价值的现场故障反馈，至少应该回答四个问题：
故障发生在呼出还是呼入？
呼叫是否振铃？
界面是否显示已经接通？
是完全无声音、单向声音，还是接通几秒后断开？
这四个答案远比一句“电话坏了”更有排障价值。
呼叫建立失败时，应先查号码、权限还是SIP响应？
如果故障发生在呼叫建立阶段，在怀疑防爆电话硬件之前，应沿SIP信令路径排查。一个实用顺序是：号码 → 权限 → 响应码 → 信令可达性。
先检查号码和拨号计划。终端发出的Request-URI是否符合平台预期？分机是否需要加前缀？跨系统呼叫是否需要区号、接入码或号码转换？很多“注册正常但无法呼出”的问题，最终都是因为电话发送的号码格式与PBX中的路由规则不一致。
例如，电话可能发送8001，而PBX要求8#8001，或者要求完整的E.164格式号码。抓包查看INVITE中的Request-URI，就能立即确认这一点。
接着检查账号权限。有些分机只允许内部呼叫，没有PSTN权限；另一些可以拨打普通SIP分机，却不能访问紧急热线、调度组或广播分区。这类服务等级配置在工业项目中尤其容易被忽略，因为注册过程并不会验证这些业务权限。REGISTER回答的是“这个账号是否在线？”，真正的呼叫尝试回答的是“这个账号是否允许呼叫这个目的地？”
然后可以利用SIP响应码进一步缩小范围：
| 类别 | 常见响应 | 典型排查方向 |
|---|---|---|
| 1xx 信息响应 | 100 Trying、180 Ringing、183 Session Progress | 呼叫建立正在继续；问题可能位于后续路由或媒体阶段 |
| 2xx 成功 | 200 OK | 呼叫建立成功；转入媒体排查 |
| 4xx 客户端失败 | 401/407认证、403权限、404未找到、408超时、480不可用、486忙、488编解码不匹配 | 通常与终端配置、路由或业务策略有关 |
| 5xx 服务器失败 | 500、503 Service Unavailable | PBX、SBC或调度平台侧 |
| 6xx 全局失败 | 603 Decline | 目的端明确拒绝呼叫 |
排障中有几个响应尤其常见。401/407通常指向认证挑战处理问题，例如凭据、算法或账号绑定异常；403应把排查方向转向权限规则、账号策略或平台拒绝请求的原因；404可能表示号码不存在，或者没有任何路由匹配；408和480通常与超时或用户不可用有关；488常见于媒体能力不兼容或编解码协商失败。
如果SIP配置看起来正常，但INVITE始终到不了目的系统，就要回到网络路径排查。检查VLAN、网关、防火墙、ACL规则，以及电话实际使用的目的地址。最快的方法是在服务器侧抓包：如果INVITE已经到达但没有继续转发，就排查PBX或调度平台路由；如果INVITE根本没有到达，就把重点放在终端或终端到服务器之间的网络路径。
通话已接通却无声音或只有单向声音，应检查什么？
“双方都显示已接通，但没有声音”是最常见的SIP故障之一。此时呼叫信令通常已经成功完成，问题更可能出在SDP协商或RTP传输。排障重点应该从信令平面转到媒体平面。
先看SDP中携带的媒体信息。其中几行特别重要：c=标识连接地址，m=定义媒体和端口，a=rtpmap把Payload Type映射到编解码器，a=sendrecv/sendonly/recvonly定义媒体方向。
终端在INVITE或200 OK的SDP中公布的音频地址，必须能被对端到达。如果终端在SDP中填写了192.168.x.x这类不可路由的私网地址，而对端位于另一个网络，SIP呼叫仍然可能正常建立，但RTP永远到不了目的地。这就是非常典型的“已接通但没声音”。
NAT环境尤其容易出现这类问题，具体处理方式取决于网络架构。SIP信令可能顺利穿过NAT，而媒体路径却完全失败。常见NAT类型包括全锥型NAT、受限锥型NAT、端口受限锥型NAT和对称型NAT，穿透难度逐步增加。
工业网络中常用SBC作为媒体中继，把RTP锚定到一个已知节点。其他环境可能使用STUN发现公网地址映射，更复杂的部署也可能使用TURN或ICE。应采用哪种机制取决于真实网络拓扑。REGISTER成功并不能证明RTP可以穿越NAT。
防火墙也是常见原因。有些项目只放行5060或5061，因为这些是最显眼的SIP端口，而语音却使用完全独立的RTP端口范围。很多设备会从10000–20000等范围动态分配RTP端口。如果SIP被允许、RTP却被ACL阻断，用户看到的现象正是“电话接通了，但没有声音”。
单向声音应该按方向排查。如果控制室能听到现场电话，但现场人员听不到控制室，至少说明一个方向的RTP或一条本地音频路径已经正常工作。不要再从头检查整个网络，而应对比双方的SDP地址、RTP端口、NAT映射和抓到的媒体流。方向性差异常常能直接指向某一侧的NAT映射、防火墙规则或错误SDP地址。
网络确认正常后，再检查编解码和本地音频链路
能看到RTP数据包，并不代表一定能听到清晰语音。下一步要确认双方是否真正协商出了兼容的编解码器。
编解码协商遵循SDP offer/answer模型。主叫终端在INVITE SDP中列出自己支持的编解码器，通常按优先级排列；被叫从中选择一个自己也支持的编解码器，并在200 OK中返回。如果双方能力列表没有共同编解码，媒体协商就会失败。
工业防爆电话中常见的编解码包括G.711（PCMU/PCMA，64 kbps，与PSTN环境兼容性广）、适用于较低带宽链路的G.729、用于宽带语音的G.722，以及部分新设备支持的Opus。如果电话只启用了某一组编解码，而PBX、录音系统或调度平台只支持另一组，可能返回488 Not Acceptable Here；在某些实现中，也可能出现呼叫已经接通但媒体异常的现象。
正确的排障方法，是直接比较双方SDP消息中的Payload Type和编解码列表，而不是只看管理页面上某个编解码是否显示“已启用”。
在确认编解码协商和RTP传输正常后，再检查终端的物理音频链路。防爆电话常年工作在高噪声、潮湿、多尘或腐蚀性环境中。即使SIP协议栈完全正常，麦克风、手柄、扬声器、功放模块、连接器或现场线缆仍可能损坏。
一个实用方法，是把RTP统计与现场实际听感对照。如果抓包显示双向RTP持续存在，包数量和时间间隔都正常，但某一侧仍没有声音，就检查静音状态、音量设置以及物理麦克风或扬声器。如果RTP确实正在发送，但其中的音频内容实际上接近静音，还要检查麦克风拾音或音频采集链路。
在可以进行定量媒体分析时，三个指标尤其有用：丢包、抖动和单向时延。随着丢包增加，语音质量会逐渐恶化；抖动过大可能需要更大的抖动缓冲；单向时延过高会让自然对话变得困难。如果丢包集中在某一段网络跳点，还要考虑链路拥塞或无线传输问题。
对带扩音输出的防爆广播话站，还要区分电话内置扬声器通路与外接号角或功放输出通路，两者不一定完全共用同一条音频链路。普通手柄或免提通话正常，并不能证明外部广播音频也正常，反过来也一样。调试和排障时，应逐条验证项目实际需要的音频路径，而不是把所有“广播没声音”都当成SIP故障。
抓包如何快速缩小故障范围？
对复杂SIP故障来说，反复修改参数通常不如完整抓取一次失败呼叫有效。可以按照时间顺序，从REGISTER一路跟到BYE。多数场景使用Wireshark就足够。常用抓包点包括电话侧、交换机镜像端口，以及SBC或PBX侧。
抓包位置决定了你能证明什么。终端侧抓包能看到电话实际发出和收到的内容，有助于判断故障是否起于本地；SBC或PBX侧抓包能确认平台是否正确收到并转发信令。对于跨VLAN、跨站点或经过SBC的部署，最好在多个点同时抓包，因为一个抓包点只能证明消息经过了这里，不能证明下一段网络也正常。
获得抓包后，可以按以下顺序跟踪呼叫：
1. REGISTER是否成功？
→ 2. INVITE是否真的发出了？
→ 3. PBX是否收到并正确路由？
→ 4. 对端是否返回18x / 200 OK？
→ 5. SDP是否协商出共同编解码？
→ 6. 是否真正存在双向RTP？
→ 7. RTP目的IP和端口是否正确？
→ 8. 现场麦克风和扬声器是否真的在传递音频？
Wireshark提供了很多实用工具。SIP消息可以使用sip或sip.CSeq等表达式过滤。在Telephony → VoIP Calls中，可以连同信令时序和相关RTP流一起查看某个通话；RTP分析还能帮助观察丢包、抖动等媒体质量指标。
排障顺序应始终保持先信令，后媒体。如果信令失败，问题就在呼叫建立阶段；如果信令已经完成但没有媒体，就应继续查媒体路径。
对“能呼出、不能呼入”的情况，要确认入呼INVITE是否真正到达防爆电话。如果呼叫总是在几秒或几十秒后固定断开，应检查ACK、Session Timer、NAT映射，以及平台是否因为没有收到预期消息而释放会话。
还有一种不太容易察觉的情况，是通话过程中发生媒体重新协商。re-INVITE可能改变RTP地址或端口。如果在这次重新协商时NAT映射失败，就可能表现为“刚开始通话正常，几秒后突然没声音”。
目标不是背下所有SIP响应码，而是始终追问一个问题：这个呼叫最后成功通过了哪一层，第一个异常行为又出现在哪里？一旦找到第一个失败点，大部分排障工作其实已经完成。
常见问题
SIP电话显示已注册，至少能证明网络正常吗？
不能。“已注册”只说明终端在某个时间点成功与Registrar完成了一次SIP注册事务。它不能证明呼叫路由、目的端可达性、RTP媒体、NAT、防火墙规则或终端音频硬件都正常，也不能证明实际通话时网络不会出现丢包或高时延。由于注册是周期性的，界面上的“已注册”状态可能只是上一次刷新成功的结果。
双方都显示已接通但没有声音，第一步应该查什么？
先检查SDP中的媒体IP地址、RTP端口和编解码协商结果，再确认防火墙、NAT设备或SBC是否允许双向RTP。如果已经明确双向RTP都能到达两端，再检查麦克风、扬声器、静音状态和本地音频输出设置。实用顺序是先媒体路径，再本地硬件。
为什么同一台防爆电话内部呼叫正常，拨打PSTN却失败？
内部分机呼叫和PSTN呼叫通常走不同的路由。外部呼叫还涉及外呼权限、号码转换、SIP中继配置、运营商路由和主叫号码显示规则。分机之间互拨成功，只能证明部分SIP和媒体路径正常；PSTN呼叫仍要经过中继和运营商网络，因此会增加额外的路由与策略要求。
注册正常，但声音断续或通话中途断开，可能是什么原因？
问题往往在媒体传输质量：丢包、抖动过大、带宽不足或NAT映射过期，都可能在通话过程中中断RTP。先检查RTP丢包和抖动，再根据场景检查链路容量和无线覆盖。如果呼叫总是在可预测的时间间隔后断开，还要检查re-INVITE媒体重新协商和Session Timer行为。
为什么换一台电话就正常，而原来的设备仍然失败？
这通常更指向原电话的配置、固件或本地硬件，而不是网络。可能原因包括固件问题、注册过期时间、NAT处理或RTP端口范围等SIP参数配置错误，也可能是DSP或音频模块故障。应把两台设备逐项对比，尤其是编解码列表、SIP端口和NAT设置，不要立即把差异归因于网络不稳定。
重启SIP防爆电话能算正规的排障方法吗？
重启有时可以暂时恢复注册、刷新NAT映射或清除卡住的进程，但不能代替故障隔离。如果根因是拨号计划配置、SIP权限、防火墙规则、编解码协商或媒体路由，重启最多只是短暂掩盖问题，甚至完全无效。更合理的维护方式是记录故障现象，保留信令抓包和日志，再判断第一个故障点究竟在终端、网络还是通信平台。
贝克通信可根据终端、IP PBX、SIP中继、网络交换、SBC及调度系统的实际架构协助开展故障排查。贝克通信同时提供防爆电话、防爆广播话站、SIP网关、IP广播及融合调度设备，适用于石化、能源、矿山、隧道等工业通信环境。
