企业官网建设流程全解析

简介：Cisco IOS语音网关基于SIP协议的应用与配置，是面向网络工程师、VoIP运维人员及备考思科认证的学习参考，重点解决PSTN与IP网络融合、PBX互联及SIP中继部署中的技术选型问题。内容涵盖Cisco 1700至5000系列路由器的语音通道支持、H.323/MGCP多协议互操作、Cisco Unified CallManager Express呼叫处理，以及QoS、会话边界控制器、应急故障切换等关键特性，并附有IETF RFC标准支持对照表，便于实际工程参考。资源包为单个doc格式文档，共1个文件，大小仅71KB，轻量易读，适合快速查阅。目前已有275人学习下载，说明该文档在相关技术社区具备一定参考价值。通过梳理SIP网关的部署场景、信令标准和优势，读者可快速建立企业级语音网关的选型与配置框架，节省检索资料的时间。

1. 拆一台 SIP 语音网关前，先想清楚它替你干了什么

很多网络工程师第一次碰 Cisco IOS 语音网关，都是从一台 2800 或者 3800 开始的：一边是运营商的 PSTN 中继，一边是 IP 电话或对端 SIP 服务器，中间全靠这台设备把 T1/E1 上的 ISDN、CAS 信令翻译成 SIP 的 INVITE、200 OK，再把 G.711 的 RTP 流送进 IP 网络。这就是 Cisco IOS 语音网关最常见的存在形式：PSTN 到 SIP 的中继翻译层。这篇文章直接讲清协议选型、平台接口、dial-peer 配置、QoS 兜底和五个典型翻车点，适合手里有真实网关要交付的工程师，也适合刚接手统一通信项目的集成商，照着能配完，而不是被厂商文档绕晕。

2. 协议矩阵与版本门槛：SIP、H.323、MGCP 该选哪个

拿到一台语音网关，第一步不是敲配置，而是决定让它跑哪种信令。Cisco IOS 语音网关同时支持 SIP、H.323 和 MGCP，这个“多协议支持”不是给你添乱的，它在部署切换时是后悔药。你完全可能遇到这种情况：老机房里的 CallManager 还在走 H.323，新上的 ITSP 中继只给 SIP，两边都要接，那就需要一台网关同时终结两种协议，或者在 IP 到 IP 网关里做转换。

2.1 三种信令协议在网关上的分工

SIP 是现在对接外部中继的绝对主流。它来自 IETF，以 RFC 3261 为核心，替代了老旧的 RFC 2543，特点是能把数据、语音、视频放在同一个呼叫里处理，拨号计划也能统一。对集成商来说，SIP 最大的价值是互操作性好：无论是思科呼叫座席还是第三方呼叫座席，只要都按标准实现，两边就能对上话。所以只要是“对外”的 VoIP 连接，我一般默认走 SIP。

H.323 是更老的标准，但存量市场非常庞大。老版本的 CallManager、部分旧 IP-PBX 的 VoIP 中继只认 H.323，这时候如果网关只有 SIP，就得在协议层面做转换。原文里专门提到“思科多服务 IP 到 IP 网关在需要时可在 SIP 和 H.323 之间提供协议转换”，这个能力在实际组网里价值很高，尤其是做两个不同厂家系统的对接项目。MGCP 则是另一条路线：呼叫控制集中到 CallManager，网关只负责执行命令，适合大规模的集中式部署，但灵活性不如前两者。

选型时的常见判断是这样的：对运营商、ITSP、第三方 SIP 平台，用 SIP；对接老旧的 IP-PBX 或老 CallManager，保留 H.323；如果是思科自家大集中架构，且所有话务都由 CallManager 统一控制，MGCP 才值得考虑。多协议支持最大的意义在于迁移平滑：今天跑 MGCP，明天切 SIP，不用换硬件。

2.2 RFC 支持表：版本门槛决定你的部署能不能成立

原文里给了一张很长的 IETF 特性表，每一项都标注了对应的 Cisco IOS 软件版本。这张表是选型时的硬约束，不是参考资料。部署前先核对 IOS 版本，比上线后抓包排错省太多时间。

这张表里最容易被忽略的一个坑是 RFC 3263：IOS 对 NAPTR 记录的支持是缺失的。你在 session target 里写了一个域名，如果对端依赖 NAPTR 做解析，那在这类网关上必然失败。我一般直接写 IP，或者确保对端存在可用的 A 记录与 SRV 记录。另外 RFC 2246 的 TLS 支持要到 12.4(6)T 才出现，低于这个版本，任何“信令加密”的部署方案都走不通。

2.3 误用提醒：不是所有语音网关都自带会话边界控制器

“会话边界控制器”这个词经常被误解。原文里说得很清楚：Cisco IOS 语音网关上的“思科多服务 IP 到 IP 网关”才提供 SBC 功能集，包括 SIP 和 H.323 之间的信号互操作、带地址和端口转换的拓扑隐藏、计费和 CDR 规范化、QoS 和带宽管理、基于 TCL 和 VXML 的丰富信令、DTMF 和编解码器转换、防火墙和 DoS 保护。

也就是说，普通语音网关做的是“线路侧终结”，SBC 功能是“IP 到 IP 中继侧”的能力。两者不在一个层面上。如果你要做的是两个 IP 语音域之间的安全互联，需要确认目标平台是否启用了多服务 IP 到 IP 网关能力，而不是默认所有 ISR 都能当 SBC 用。这个误判在组网初期很难发现，到了联调阶段才会爆出来，属于能提前避开的高成本坑。

3. 硬件平台与语音接口：从 2 到 2688 个通道怎么选

Cisco IOS 语音网关不是一个单一型号，而是一个从分支到运营商级的完整产品线。原文给出了一系列可配置的网关平台：1700、2600、2800、3700、3800、5000 系列，支持 2 到 2688 个语音通道。选型逻辑先看你要多少通道，再看你要什么接口，最后才轮到功能特性。

3.1 从 1700 到 5000：型号、通道数与部署位置

这里有一个很容易被忽略的选型点：2800 和 3800 系列上内嵌的 Cisco Unified CallManager Express。原文专门讲了一句：它在单一路由器平台中提供了成本低廉、高度可靠、特性丰富的电话解决方案。如果你面对的是一个没有独立 CallManager 的中小机构，CUE 模式就能让一台 ISR 同时承担呼叫处理和中继网关两个角色。很多集成商在第一个项目里就把这一步省了，结果客户还得再买一台服务器跑呼叫控制，预算翻倍。

3.2 接口选型表：PRI、CAS、R2、QSIG 各管哪一段

语音接口决定了你能接什么样的线路，这是网关选型里最不能拍脑袋的部分。原文列出支持的信号方式包括 T1/E1 PRI、T1 CAS、E1-R2、T1/E1 QSIG、T1 特性组 D、BRI、FXO、E&M 和 FXS。用一句话概括：接口类型本质上是在说“对端线路长什么样”。

国内现网最常遇到的是 E1 PRI、FXO、FXS 这三类。E1 PRI 用来接管运营商数字中继线，FXO 用于只有模拟外线的营业网点，FXS 则用来接传真机或模拟话机。QSIG 看着用得少，但在跨国企业组网、不同品牌 PBX 做专网互联时是刚需。R2 信令在国内 E1 时代很常见，现在大部分已经退网，见到基本是在旧存量设备升级项目里，需要摸清楚对端是否还支持 R2 转 SIP。

3.3 PRI 落地配置：从 controller 到 pots dial-peer

接口类型定了之后，配置就按“物理层到逻辑层”的顺序走。以常见的 T1 线路为例，第一段配置是 controller：

controller T1 1/0 framing esf linecode b8zs clock source line primary pri-group timeslots 1-24 service voice

这段配置做的事情很直接：framing 指定帧格式为 ESF（扩展超帧），linecode 用 B8ZS 编码，这是北美 T1 的标准组合。clock source 必须说明白，PRI 链路的时钟以运营商线路为主，用 line primary，否则可能出现滑码。最后一行把 1 到 24 个时隙全部划给 voice。

如果是 E1 线路，对应配置改为：

controller E1 1/0 framing crc4 pri-group timeslots 1-31 service voice

E1 的时隙 0 用于同步，所以可用时隙是 1 到 31。帧格式用 CRC4 更常见，国内对接运营商 PRI 时也多以 CRC4 为准。接着配置 D 信道对应的串口，T1 的 D 信道在第 24 时隙：

interface Serial1/0:23 isdn switch-type primary-ni isdn incoming-voice voice no cdp enable

isdn switch-type 指定了交换类型，North America 是 primary-ni，欧洲和中国常见的是 primary-net5。incoming-voice voice 决定了入向呼叫按语音方式处理。最后一步，把这条 PRI 绑定到 pot 类型的 dial-peer：

dial-peer voice 100 pots description PSTN outbound to CO destination-pattern ^9[2-9]......$ direct-inward-dial port 1/0:23 forward-digits all

pots dial-peer 负责把 IP 侧的呼叫送到 PSTN。destination-pattern 用正则写法收敛拨号规则，这里的意思是：拨 9 后跟一个非 1、非 0 的局号再加 7 位号码。port 绑定到物理端口，forward-digits all 避免运营商号码被截断。dial-peer 匹配是整个网关呼叫路由的核心，数字写错一个，呼叫就会走到错误的 peer 上，这是后续排错时首先要怀疑的地方。

4. 把 PSTN 接进 SIP 中继：dial-peer 与 QoS 配置实战

物理接口配通之后，真正决定网关会不会“打电话”的是两张拨号计划：一张把 PSTN 呼叫送进 IP 网络，另一张把 IP 侧呼叫转回线路侧。这一章直接落到 SIP 中继配置上，所有参数照着抄基本能通，但每个参数的意思必须明白，不然出了问题不知道从哪下手。

4.1 配置结构：controller、voice-port、dial-peer 三层各管什么

整个语音网关可以拆成三层：controller 管物理线路的成帧与时钟；voice-port 管语音通道的行为参数，比如呼叫超时、忙音检测；dial-peer 管呼叫路由。很多新手配置时跳过 voice-port，直接在 controller 上绑 dial-peer，结果遇到线路侧掛不断、呼叫超时等奇怪问题就懵了。

以 PRI 线路为例，voice-port 是这样配置的：

voice-port 1/0:23 timeouts call-disconnect 0 station-id name PSTN-LINK-01

timeouts call-disconnect 0 表示呼叫断开后立即释放通道，不保留额外时间，这对高并发中继线是有意义的。station-id name 是一个标识，方便在 show voice port summary 里识别这条线路。如果你只有模拟线路，voice-port 的可调项更多：FXS 口的信号类型、振铃频率、二四线转换模式，这些参数直接影响传真和语音的质量。

4.2 SIP 侧 dial-peer 与 sip-ua：参数逐个拆

SIP 中继的侧重点在 dial-peer 和 sip-ua 两块。一个标准的 ITSP 对接配置如下：

dial-peer voice 200 voip description SIP trunk to ITSP destination-pattern ^9......$ session protocol sipv2 session target ipv4:203.0.113.10 dtmf-relay rtp-nte codec g711ulaw no vad

逐行分析：session protocol sipv2 指定这个 peer 走 SIP，这是与 H.323 peer 的本质区别。session target 填写对端 SIP 服务器地址，建议直接用 IP，绕开 DNS 解析的不确定性。dtmf-relay rtp-nte 对应 RFC 2833，把 DTMF 按键封装成 RTP 事件包传输，这是目前最可靠的按键传输方式。codec g711ulaw 是北美和日本的标准语音编码，国内 PSTN 侧通常对接 G.711A 律，需要按运营商要求改成 g711alaw。no vad 关闭语音活动检测，VAD 在带宽紧张时有价值，但在传真和低音量场景下经常把语音切没，中继线上一律关掉。

sip-ua 部分配置对端认证信息与重试策略：

sip-ua authentication username 6881234 password 0 Cisco@123 retry invite 2 timers connect 500

authentication 用于对接 ITSP 的注册鉴权，对应 RFC 2617 的摘要认证。密码默认明文显示，生产环境建议用 password 6 加密存储。retry invite 2 限制 INVITE 重试次数，避免对端无响应时网关无休止重发。timers connect 500 设置了连接超时时间，这个值按对端响应速度调整，一般不需要轻易动。

4.3 让语音好听：DSCP、LLQ、CAC 的配合

SIP 中继配通了，不代表语音质量能过关。原文明确定义了 QoS 能力：DSCP 分组标记、IP 优先级、低延迟队列、基于类别的加权公平队列、资源可用性检查和 RSVP。实际部署时最有效的组合是 DSCP 标记加 LLQ。

class-map match-any VOICE-RTP match ip dscp ef class-map match-any VOICE-SIGNAL match ip dscp cs3 policy-map WAN-EDGE class VOICE-RTP priority percent 80 class VOICE-SIGNAL bandwidth percent 5 queue-limit 20 class class-default fair-queue

语音 RTP 流量打 DSCP EF，放在 LLQ 的 priority 队列里，这是“无论带宽多紧张，语音包永远最先出去”的兜底手段。信令流量打 CS3，给固定带宽，避免拥塞时 INVITE 消息丢失。剩下的流量用 fair-queue 公平调度。这个策略贴在 WAN 出口接口上：

interface GigabitEthernet0/1 service-policy output WAN-EDGE

CAC 是另一个容易漏掉的部分。带宽再宽，也扛不住呼叫数量无限上涨。最朴素的呼叫准入控制是限制并发呼叫数，常见做法是在语音网关里设置最大通话路数，超出后拒绝新呼叫，保证已有通话质量。RSVP 做端到端带宽预留是更彻底的方式，但需要全网设备配合，在中小型部署里用得不多。

5. 部署避坑：五个真实翻车现场

这一章写的每一条都是调试时留下的血泪经验。语音网关这个问题，现象看起来千奇百怪，但根因往往集中在信令解析、拨号计划、媒体协商、切换逻辑这几个固定区域里。照着这些检查，能省掉大半抓包时间。

5.1 现象一：SRV 解析失败导致呼叫超时

拨号后听到一串忙音，或者呼叫直接超时。查 session target 写了域名，网关解析失败。

原因是 RFC 3263 的支持只到 A 记录和 SRV 记录，NAPTR 不受支持。对端 SIP 服务器如果只发布了 NAPTR 记录，这版 IOS 根本不会去查。解决方法是把 session target 改成 ipv4: 加具体 IP。如果必须用域名，先确认对端有 A 记录。这个坑在 12.4M 之前的版本上更隐蔽，因为老版本连 SRV 都支持得不完整，遇到域名解析异常时优先怀疑版本门槛。

5.2 现象二：接通后单通，前几个字被切掉

电话能接通，但声音只有一边听得见，或者说话的前一两个字被切掉。

单通先查 RTP 方向：ACL 是否放行了 UDP 语音端口范围、NAT 是否做了 UDP 转换。前几个字被切掉，最常见的根因是 VAD 没关。语音活动检测在通话建立初期会把前半包当作静音丢弃，中继线上一律 no vad。另一个隐蔽原因是编码不匹配，PSTN 侧用 a 律，SIP 侧用 u 律，两边都以为自己协商成功，实际媒体听不懂。解决方法是统一 codec，并抓包确认 SDP 里协商出来的编码和实际发送的 RTP 负载一致。

5.3 现象三：DTMF 按键无响应，语音通了但不听话

电话通了，说话正常，但 IVR 里按的按键没反应。

这是 DTMF 传输方式的问题。语音通了只说明媒体流建立，按键事件没有可靠传递。最常见的原因是 dial-peer 里没有 dtmf-relay rtp-nte，按键被当作带内音频传出去，经过压缩编码后变了形。解决方法是补上 dtmf-relay rtp-nte。如果对端是老式设备只支持 SIP INFO，再增加对 RFC 2976 的支持。国内现网还有一种情况：对端 ITSP 要求 RFC 2833 的 payload 类型固定为某个值，而 IOS 默认协商成了别的值，需要手动在 voice-class sip 里指定。

5.4 现象四：PSTN 故障切换后分支电话彻底哑了

主 SIP 代理故障后，分支路由器的电话没有像预期那样落到 PSTN 备用链路上。

原文里明确说：如果无法连接到主 SIP 代理或背靠背用户代理，故障恢复功能可在此期间为分支机构路由器的 PSTN 电话接口提供支持，这一功能可与 Cisco Unified Survivable Remote Site Telephony 相结合。问题是很多项目里只配了主用呼叫服务器，没在网关里配 call-manager-fallback。常见做法是配置 SRST：

call-manager-fallback ip source-address 10.10.10.1 port 2000 max-ephones 24 max-dn 48 dialplan-pattern 8888.... keepalive 30

这段配置让网关在主用呼叫服务器失联后，自己临时承担呼叫处理，分支电话继续能拨号。keepalive 30 表示每 30 秒检测一次主用服务器状态。还有一个细节：原文提到“当 Cisco Unified CallManager 故障切换到第三个服务器时，Cisco IOS 语音网关将使用下一个可用服务器”，这说明网关侧的故障切换是级联的，排查时要按“主用、备用、网关兜底”三层去检查，而不是只看一层。

5.5 现象五：TLS 信令加密一直握手失败

配置了 SIP TLS，信令始终握手失败，查看日志发现是协议版本或套件不兼容。

先核对版本。原文指出 TLS 支持对应 RFC 2246，最低 IOS 版本是 12.4(6)T。如果设备还在跑 12.3 或更老的版本，任何 TLS 配置都不会生效，这是硬门槛。版本满足后，再看 cipher suite 是否匹配。思科设备默认套件和对端服务器的偏好经常不一致，需要对端提供支持的标准套件列表，在 sips-ua 里显式指定。实际交付中我见过不少因为 TLS 版本不匹配导致整个中继不可用的案例，排到最后都是版本清单没对齐。

6. 上线前的验证清单：show 与 debug 够用但要用对

最后一章不讲新功能，讲验证。我每次上线语音网关，都强制自己按固定顺序跑一遍检查，顺序错了容易漏掉线索。

先做状态检查，确认物理层和链路层是活的。show isdn status 看 PRI 的层一和层二状态，层一激活、层二 MULTIPLE_FRAME_ESTABLISHED 才说明线路没问题。show voice port summary 看所有语音端口的挂机状态，如果有端口一直 off-hook，先处理再谈下一步。show dial-peer voice summary 检查拨号计划的匹配情况，重点看 calls 计数是否在增长，这能判断呼叫是否真的走到了预期 peer。

再确认 SIP 层面的注册与会话状态，show sip-ua status 看注册是否成功，show sip-ua calls 看当前活动的 SIP 呼叫。上线初期我习惯开 debug ccsip messages 抓信令，但注意这是高负载命令，必须在业务低峰期用，而且只在单条测试呼叫时开启。拨号计划匹配问题用 debug voip dialpeer inout，能直接看到每个呼叫匹配到了哪个 dial-peer，比对着配置猜快很多。

抓包验证要抓两个层面的东西：SIP 信令和 RTP 媒体。信令层面重点看 INVITE 的 SDP 里 codec 和 dtmf-relay 是否协商正确。媒体层面重点看 RTP 流是否真的有双向包，以及 payload 类型是否稳定。单通问题在抓包上会非常直观，一边持续发 RTP，另一边完全没有，方向定位立刻就出来了。

故障切换测试不能省。断开主 SIP 代理的网络连通，观察分支电话是否在预期时间内完成 SRST 接管，恢复主用后是否自动切回。这个测试在中小型项目里经常被跳过，等真出故障时才发现切换逻辑是坏的。

从那以后，我每次改语音网关配置都强制走一遍完整流程：先确认没有活动呼叫，再改配置，然后按 show isdn status、show dial-peer voice summary、show sip-ua status 的顺序验证，最后抓包对比信令与媒体。这套流程看着繁琐，但它把“看起来能通”和“真出故障时扛得住”之间的距离拉平了。希望帮到你。

本文还有配套的精品资源，点击获取