简介：这份PDF文档是Avaya Aura™ Communication Manager 5.2版官方新增功能说明，面向统一通信管理员、SIP运维工程师及Avaya系统实施人员，用于快速了解5.2版本在呼叫排队自动回叫、安装向导增强、呼叫记录增强、SIP路由优化、改址通知及Extension to Cellular等方面的技术更新。整个下载包仅含1个PDF文件，体积399KB，内容来自Avaya支持网站的正式文档，目录涵盖Communication Manager、SIP Enablement Services、Avaya Servers与Media Gateways等模块，结构清晰便于定位查阅。目前已有559人浏览学习，可作为实施与排障场景下的轻量参考手册。读者可从中掌握被叫方排队自动回叫、记录转送呼叫、链路呼叫转送、编辑拨号、增强型呼叫代答警报、SIP增强型改变路由指示等关键功能的具体含义与实际使用场景，帮助理解系统升级后带来的行为变化，并为日常运维配置和故障排查提供官方依据。
1. Avaya_SIP_设置说明.pdf：这份文档到底在解决什么
拿到《Avaya_SIP_设置说明.pdf》的工程师，多半卡在同一道坎上：SIP 不像以前的 TDM 中继那样插上 E1 就能通，它把信令、认证、端口、编解码全部揉在一起，任何一个参数没对齐，电话就是不响。这份设置说明的核心价值不是教你 SIP 协议本身，而是告诉你 Avaya 这一侧哪些参数必须改、哪些保持默认就行。
目标读者很明确：给 Avaya Communication Manager 或者 IP Office 开局、要接运营商 SIP trunk，或者要接 SIP 软电话的运维和网络工程师。照着这份说明，你可以把信令组、中继组、路由、软电话注册一次性配出来，而不是在 Web 管理面里来回试。
下面我把这类设置说明里最常见、也最容易被忽略的步骤拆开，并把容易翻车的地方单独拎出来，做成可以直接复现的操作路径。
2. 动手之前先理清信令与媒体流：Avaya 的 SIP 不是简单换个端口
很多第一次接触 Avaya SIP 的工程师，第一反应是把原来模拟中继、数字中继的配置思路平移过来——哪个槽位插了什么板卡、哪个 trunk 组对应哪个物理端口。结果在 SIP 配置界面里找了半天也没找到“端口”这个概念，因为 SIP 链路本来就是逻辑的。
在 Avaya Communication Manager（CM）里，SIP trunk 由三样东西组合出来：signaling group 负责信令通道，trunk group 负责话路资源，route pattern 负责把拨号计划送进 trunk。它们不是物理实体，但你必须按顺序建好，缺一个，后面那个表单里就选不到对应项。
2.1 三条链路：信令流、媒体流、管理流不要混在一张网里
Avaya SIP 开局最忌讳的就是把三股流量全塞进同一段网络却不在参数上做区分。这里说的三条链路分别是：
信令流走 SIP 协议。CM 侧默认监听 UDP/TCP 5060，signaling group 里可以单独指定 near-end listen port 和 far-end listen port。对端可能是运营商 SBC，也可能是另一个 Avaya 系统，信令口必须双向可达。
媒体流走 RTP。Avaya 实际用的媒体端口范围由 network region 里的 IP Codec Set 和媒体端口范围决定，常见做法是限制在 10000~20000 或者 20000~30000，方便防火墙放行和抓包过滤。如果信令通了但媒体端口被挡，就会出现“能响铃但拿起电话听不见声音”的诡异现场。
管理流走 SSH、HTTP(S)、服务端口。这部分千万别和信令端口混在一起做 NAT 或端口映射，否则经常会出现一种很玄学的故障：信令看着正常，但 Avaya 的 License 或者 feature 激活就是起不来。
| 流向 | 协议/端口 | 在 Avaya 侧主要配置位置 | 常见误区 |
|---|---|---|---|
| 信令流 | SIP over UDP/TCP 5060 | signaling group | 只开 UDP 不放 TCP |
| 媒体流 | RTP，建议限定一个范围 | ip-network-region 的 codec set | 用出厂默认 2048~65534 |
| 管理流 | SSH 22 / HTTP 80 / HTTPS 443 | 系统管理面 | 和信令共用公网映射 |
我一般会建议在开局之前先画一张简单的拓扑图，标清楚对端 IP、本端 IP、信令端口、媒体端口范围、管理口 IP，然后把这个图贴在配置记录里。等后面真出了故障，这张图能省下至少半天排查时间。
值得提醒的是，媒体端口范围不要只放 UDP，有些对端和软电话实现会协商 TCP 的 RTP 封装。端口范围收得越窄，越要确认两边都支持同样的传输方式。否则你防火墙开得再漂亮，RTP 流照样被对端丢弃。
2.2 SIP trunk 与 SIP endpoint：两种不同的配置逻辑
Avaya 里 SIP 分两类，很多人设置说明读到一半开始迷糊：一类是 SIP trunk，用来连接运营商、SBC 或者另一套 PBX；另一类是 SIP endpoint，也就是常说的 SIP 软电话（比如安卓上的 SIP 软电话应用）或者 Avaya 自家的 SIP 话机。
SIP trunk 的核心是“中继资源”。在 CM 上，你要先建 signaling group，再建 trunk group，然后把 route pattern 指过去。运营商把你看成一个“客户”，你在它那边注册一个 trunk 账号，呼叫由 PBX 选择走哪条 trunk。
SIP endpoint 的核心是“用户”。每个软电话对应一个扩展号，Avaya 侧要有一个 SIP user 或者叫 station，并且把该用户和实际的 SIP 终端绑定。认证信息不在 trunk 里，而是在这个 SIP user 上。如果拿 trunk 的认证信息去配软电话，结果必然是注册失败，因为 Avaya 两边用的 digest 用户名和密码不是同一套。
如果你是给 IP Office 做配置，对应关系也类似：SIP Line 相当于 trunk，SIP Extension 相当于 endpoint。设置说明里最容易翻车的点，就是没分清自己当前在配置哪一个。用同一个思路去套两种对象，最后只能得到一堆互相矛盾的参数。
2.3 开局前参数表：这是最容易变成黑匣子的环节
设置说明的 PDF 正文里给了一堆参数，真正动手前你要做的第一件事，是先填一张“开局参数表”。我就按这类说明最常见的顺序列在这里：
| 参数 | 建议值/填写内容 | 不填会有什么后果 |
|---|---|---|
| 本端 IP/节点名 | 与 ip node-names 一致 | signaling group 里选不到节点 |
| 对端 IP/域名 | 运营商 SBC 的公网地址或内网地址 | 信令根本发不出去 |
| 信令端口 | 大多 5060，个别大客户用 5061 | 端口不一致直接无响应 |
| Transport | UDP/TCP/TLS 三选一 | 写死 UDP，对端改 TCP 就翻车 |
| Realm/Domain | 运营商给出的认证域 | REGISTER 被 403 拒绝 |
| 认证用户名/密码 | 运营商或 Avaya 侧创建的用户 | 407 和 401 轮着来 |
| 编解码 | G.711A/U、G.729、G.722 | 双方只剩一个交集，通话效果差 |
| DTMF | 推荐 RTP-NTE（RFC2833/4733） | 拨号音传不过去，IVR 失灵 |
| 媒体端口范围 | 比如 10000~20000 | 防火墙不好开，抓包也不好抓 |
这张表不是文档里现成印好的，是实际开局过程里从各种邮件、工单、截图里抠出来的。填好之后，配置就不是“看着说明一条条敲”，而是“对着参数表填进对应表单”。哪个参数找不到位置，就先查，不要跳过去。后面百分之八十的故障，本质上都是这张表里某一行没填对。
3. 照设置说明配置 Avaya SIP trunk：从 signaling group 到 route pattern 的完整命令
这一章按最常见的 Avaya Communication Manager 环境写，如果你用的是 IP Office，表单名称会有点差别，但思路是一模一样的。关键是不要跳步，signaling group、trunk group、route pattern 这三层必须按顺序落。
3.1 建 signaling group：SIP trunk 的“第一块骨头”
进入 CM 的 SAT 终端，首先确认节点名已经存在：
change node-names ip在这个界面里，你要有本端节点名（比如avaya-cm）和对端节点名（比如sbc-carrier），分别对应各自的管理 IP。如果没有，先add node-names补上。然后创建 signaling group：
add signaling-group 12进去之后主要改这几个字段：
- Group Type：选 near-end。near-end 意思是本端主动向外发起信令，对大多数运营商 trunk 都适用。
- Near-end Node Name：选刚才建好的本端节点。
- Far-end Node Name：选对端节点，如果对端不是 Avaya，可以选一个近似的名字然后在 IP 地址上改。
- Far-end Network Region：填对端电话资源所在的 network region。如果两端媒体要互通，这个区域必须和本端区域有 codec 交集。
- Transport Method：和运营商确认是 UDP 还是 TCP。不要默认，很多运营商只开放 TCP/TLS。
- DTMF over IP：选 rtp-payload，等于走 RFC2833，这是和 IVR 对接的关键。
这些字段填错任何一个，signaling group 建完也只是“存在”，并不代表能用。我见过不止一次 far-end node name 选错，结果信令包是从本端某个完全无关的 VLAN 发出，对端抓包永远看不到。所以在建完之后，第一时间status signaling-group 12，确认状态不是 idle，这是一个很低成本的自检动作。
3.2 建 trunk group 和 route pattern：把拨号计划接到 SIP 上
signaling group 建好后，建 trunk group：
add trunk-group 12Trunk Group Number 保持和 signaling group 一致是可读性更好的习惯；Group Type 选 sip；然后往下找 Signaling Group 这一项，填 12。其他字段按运营商要求填：
- COR：呼叫权限等级，确认已经允许拨打外线。
- Trunk Access Code (TAC)：这个是后续 route pattern 要引用的号码，比如 812。
- Number of trunks：SIP 中继不是按物理路数算的，是按同时呼叫数。按并发量填，通常 30~120 之间。
- Direction：two-way。
- Caller ID 相关内容：有的运营商要求匿名，有的要求透传，按实际填。
trunk group 建完还没有拨号能力，必须挂一个 route pattern：
change route-pattern 1Route Pattern Number 编号随意，关键是 Pattern Name 写清楚用途，比如CARRIER-SIP-IMS。Grp No 填 12，然后设置 FRL（Facility Restriction Level）和 Prefix 字段。很多人忘了：在这个 pattern 里有 FRL 和 COR 两套权限体系，如果 pattern 的 COR 比 trunk group 的 COR 更严格，呼叫会直接被拒绝，连拨号音都听不到。
之后把路由指向路由模式，在 ARS 表里完成：
change ars analysis 9这里把前缀 9 或者具体号段指向刚才的 route pattern 1，拨号计划才算真正和 SIP trunk 接通。改完先别急着拨号，回到 SAT 里list trace，在 trace 界面下拨一个测试号码，确认呼叫确实进了 trunk 12，这一步能帮你把配置错误和运营商问题尽快切开。
3.3 在路由器上做 IMS/运营商对接：dial-peer 与 set sip voice trunk 的对应写法
很多运营商送过来的对接文档里，Avaya 对端是路由器或者 SBC，而不是另一台 Avaya。这时候我们要在路由器或边界网关上配置 SIP trunk 来对接 IMS。对应的思路和上面一样，但落点是路由器的 dial-peer。
以下是一份常见的思科风格配置，对接运营商 IMS 中继：
voice service voip sip session transport udp early-media bypass no sip-serverdial-peer voice 100 voip description IMS-SIP-Trunk-to-Carrier session protocol sipv2 session target ipv4:10.20.30.40:5060 destination-pattern ^9011...... codec g711ulaw dtmf-relay rtp-nte no vad配置里有两段逻辑需要说明。第一段voice service voip下的sip进到 SIP 子模式，session transport udp告诉路由器用 UDP 往对端发信令；early-media bypass允许在没有完成被叫侧应答时就先送媒体，这对某些 IMS 网络很重要，不关掉会导致环路摘机音。
第二段dial-peer voice 100 voip是真正的拨号出口。session target指定 IMS SBC 的 IP 和端口；destination-pattern决定了哪些号码会走到这条中继，上例用^9011......表示匹配 9 开头然后 011 加 6 位号码的形式；dtmf-relay rtp-nte让 DTMF 以 RTP 带内事件发送，而不是走带外交互。
如果你在路由器操作手册上看到set sip voice trunk ims on router这类描述，它指的就是这一整套逻辑：先在全局把 SIP 语音服务打开，再针对 IMS 网络定义特定的 destination-pattern、codec、dtmf-relay 策略。Avaya 侧只需要把 signaling group 指向这台路由器，剩下的让路由器的 dial-peer 去对接运营商。
注意：不要在 Avaya 和路由器两侧重复做 NAT 或端口映射。很多设置说明里没写这句话，但实际排查时发现，两边同时做了代理，SIP 消息里的 SDP 地址就对不上，媒体流必然单通。遇到这种环境，我的处理原则是只在一侧做地址改写，另一侧全部用真实 IP，避免 SDP 里的 c= 和 o= 字段被改得没法看。
4. 避坑：Avaya SIP 设置里最容易翻车的 5 个现场
这一章写的都是真实开局里反复出现的故障，不一定都写在官方设置说明里，但不处理它们，配置再标准也跑不通。
4.1 REGISTER 发出去没有回应
现象：Avaya 侧看到 REGISTER 已经发出，但运营商 SBC 或者对端设备毫无反应，抓包也看不到任何回包。这个时候不是协商问题，是信令根本没到达对端。
原因：最常见的是 transport 不匹配。Avaya signaling group 里写 UDP，对端 SBC 只监听 TCP；或者对端监听端口是 5061，本端还在发 5060。另一个常见原因是中间防火墙把大于 1024 的源端口过滤了，SIP 的源端口经常是随机高端口，而不是 5060。
解决：先在 Avaya 侧用ping和telnet确认到对端 IP 的网络可达性，再从对端侧抓包确认是否收到 UDP 或 TCP 报文。如果包到了但没响应，基本可以断定 transport 或端口写错。改完 signaling group 的 Transport Method 后，记得release并重新add，有些参数在运行中改不生效。
4.2 能注册但一打电话就单通
现象：REGISTER 正常，呼叫也能建立，但通话只有一路有声音，或者两边都听不见，媒体指示灯在抓包里能看到 RTP 流发送，但方向不对。
原因：RTP 流没有走对网段。最常见的是 network region 配置不对，Avaya 不知道应该用哪个 IP 地址去和对方通信；或者本端配置的媒体端口范围与防火墙放行范围不一致。另一个容易被忽视的原因是编解码协商不完整，比如 Avaya 只协商出 G.729，但对端设备不支持。
解决：先确认 network region 的 IP 地址映射，change ip-network-map里把本端 IP 段对应到正确的 region。然后status trunk 12查看媒体端口是否落在设定的范围内，再抓包看 RTP 的源地址到底是哪个接口发出的。编解码问题就直接查list trace里的 codec 字段，看双方最终选中的编码是什么。这个坑几乎每个项目都会踩一次，属于 Avaya SIP 的血泪经验。
4.3 安卓 SIP 软电话一直 407/403：认证信息放错了位置
现象：安卓上的 SIP 软电话（比如 Zoiper、Linphone 或者运营商定制的软电话）注册 Avaya 时一直报 407 Proxy Authentication Required 或者 403 Forbidden，换了密码也没用。
原因：软电话是 SIP endpoint，不是 trunk。你在 Avaya 侧创建了一个 SIP user，但软电话里填的认证用户名是 trunk 的 digest 用户名，或者反过来。Avaya 用的认证域和运营商 SBC 的认证域不同，软电话把 407 响应里的 realm 一股脑收下，再按错的 realm 重新计算 digest，结果永远是认证失败。
解决：确认这个软电话对应的是 extension 而不是 trunk。登录 Avaya 系统管理面，找到该用户的 Digest Authentication 用户名和密码，软电话里要填的认证名就是这个 digest 用户名，不是分机号，也不是 SIP 注册的全地址。然后确认软电话设置的 domain 和 Avaya 侧 user 的 domain 一致。配完后先抓包看 INVITE 还是 REGISTER 失败，REGISTER 失败优先查 digest，INVITE 失败查号码权限。
4.4 呼叫一接通就被挂断，抓包看到 488 Not Acceptable Here
现象：呼叫能建立，但刚接通或者刚响铃就被释放，抓包看到对端回 488 Not Acceptable Here。这种情况在 IMS 对接场景尤其常见。
原因：488 的核心是 SDP offer 里没有对端可接受的媒体。可能是 codec 交集为空，也可能是 Avaya 只送了带 SRTP 的加密媒体，而对端只支持明文 RTP。还有一类隐蔽情况：Avaya 默认在信令里带 100rel（PRACK），对端不支持，虽然没有直接报 488，但会卡在 Early Media 阶段。
解决：在 signaling group 里把 100rel 设为 disabled 或者按对端要求设置，然后检查 codec set。change ip-codec-set 1里确认 G.711 和 G.729 都启用，并把对端首选编解码放在列表靠前位置。如果运营商要求明文 RTP，把 Media Encryption 相关的 H.235 参数关掉。这里建议每次只改一个因素，不要同时改 100rel、codec 和加密，否则你根本不知道是哪一项生效的。
4.5 list trace 显示 far-end disconnect，但对端说没问题
现象：Avaya 侧 list trace 里看到far-end disconnect，通话被释放，但运营商侧查看 SBC 日志显示一切正常，两边对不到账。
原因：这个问题常常和 session timer 有关。SIP 会话定时器（RFC 4028）如果两边配置不对称，某一侧的 refresh 消息没有及时收到，就会先挂断。另一个常见原因是过于敏感的 NAT keepalive 超时，Avaya 与路由器之间的地址映射在空闲几秒后被拆除，对端再发 INVITE 就找不到了。
解决：在 signaling group 里开启或关闭 Session Refresh Timer，并确认对端配置一致。如果走的是路由器 NAT，把 NAT keepalive interval 缩短到 30 秒以内，并确保 SIP 的 NAT 映射用同一个外部地址。排查这类问题，最好在 Avaya 侧和对端 SBC 同时抓包，对比挂断前最后几条消息。单侧抓包很容易把问题归结到对方，但实际两边都没做错什么，只是超时参数没对齐。
5. 验证与排查：用 list trace 和抓包确认 SIP 真的通了
配置做完，真正的工作才刚开始。SIP 这东西不像模拟中继，摘机听个拨号音就知道通不通。它需要验证注册、呼叫保持、RTP 双向流、DTMF 透传、挂机释放完整闭环。
5.1 用 list trace 看每通呼叫的信令轨迹
Avaya 自带的 trace 工具比抓包更直观，因为它能直接告诉你 Avaya 侧对每通呼叫的判断。进入 SAT 终端，敲：
list trace进去后建议打开trace状态，然后让同事拨一个测试号码。trace 输出里会显示每通呼叫经过的 trunk group、被叫号码、主叫号码、放音信息。再配合下面的命令看 trunk 和 signaling group 的运行状态：
status signaling-group 12 status trunk 12看 signaling group 时重点看状态是不是 active，以及当前有没有存量呼叫。看 trunk 时重点看 usage 和 codec 两列。如果 usage 一直为零，route pattern 大概率没挂好；如果 codec 显示为空，说明媒体协商还没有完成，这个问题比号码没通更隐蔽，因为有些计费系统已经会显示呼叫成功。
5.2 用 tcpdump 和 sngrep 把黑匣子打开
Avaya 侧不方便装抓包工具的话，可以在接入交换机上做端口镜像，或者直接在边缘接一台 Linux 主机做串接抓包。我常用的抓包命令是：
tcpdump -i eth0 -s 0 -w avaya_sip.pcap "port 5060 or portrange 10000-20000"这个命令把信令端口和媒体端口一起抓到文件里。端口范围要和你设置的 media port range 对应，否则 RTP 流不在包里。抓完之后用 sngrep 打开，可以按通话维度过滤 SIP 消息，比 Wireshark 里一条条翻效率高很多：
sngrep -I avaya_sip.pcapsngrep 里按呼叫流程看四件事：INVITE 的 SDP 里 codec 列表、183/180 里对端选的媒体地址和端口、ACK 和 BYE 的发起方、任何非 200 的响应码。很多时候单通问题，用 sngrep 看 SDP 就能定位，不需要再猜。
5.3 用软电话做端到端呼叫验证
配置全做完，建议用一台安卓上的 SIP 软电话做最终验证，而不是直接拿话机打。原因很简单，软电话的 SIP 配置全暴露在界面上，出了问题可以看到注册状态、域名、端口和认证信息，比 Avaya 话机好排查。
验证流程我一般按这个顺序走一遍：
- 软电话注册到 Avaya 扩展号，确认注册状态 active。
- 软电话拨打本系统另一部分机，确认内线通话双向语音正常。
- 分机呼叫软电话，确认来电显示和振铃路径正常。
- 通话中按软电话 DTMF 键，确认对方能识别（尤其要打运营商 IVR 验证）。
- 执行一次呼叫保持和恢复，然后做一次盲转。
这几步跑完，SIP 配置基本就算闭环了。很多项目只看注册成功就宣布上线，结果第一天就被用户打爆—能注册不代表能通话，能通话不代表 DTMF 和转接没问题。软电话测试就是一个低成本后悔药，花十分钟，省掉上线后一整天的投诉。
6. 把设置说明变成自己的配置基线：一条值得长期坚持的习惯
很多人拿到《Avaya_SIP_设置说明.pdf》之后的做法是照着配一遍，配通就算完。我的做法是把这份 PDF 当成一份“配置基线”的骨架，每次开局前先把 2.3 节里的参数表填好，然后把所有改动过的字段记录在案，形成一份单独的变更记录，而不是直接改动 PDF 或者系统默认配置。
具体操作是：每配置完一个环节，用list configuration导出一次对照文件，标明改动时间和改动人。等整条链路调通后，把 signaling group、trunk group、route pattern 这三段配置导出，连同开局参数表放进同一个目录，用日期命名归档。下次项目直接复制这份基线来改，而不是把官方的设置说明重新读一遍。
这里有一个我长期坚持的习惯：每次上线后，都会保留一份status signaling-group和list trace的成功输出截图。不是给领导看，是给三个月后的自己看，因为那会儿你已经忘了当时的 codec 是什么、support 100rel 是开还是关。等出了问题，拿当前状态和基线一对比，差异项就是问题候选，就不用从零开始抓包了。
真正让我养成这个习惯的事故是一次半夜割接：Avaya SIP trunk 在凌晨突然批量释放通话，当时没有任何基线可对比，只能一边抓包一边翻历史配置，浪费了将近两个小时。后来发现只是一个同事在测试时把 network region 改错了，但因为没有任何基线，连这个改动都差点没查到。
从那以后，所有 Avaya SIP 相关项目我都强制保留配置基线，并且每次变更前先备份、变更后立刻导出一份新基线。做 SIP 这个领域，最大的敌人不是复杂协议，而是没有记录的随意改动。希望帮到你。
本文还有配套的精品资源，点击获取
