1. 从一通打不通的外线电话说起如果你正在看这篇内容，大概率你手里正握着一台Yeastar的PSTN网关，或者正准备把它和FreePBX对接起来。我先说结论：这套组合能跑通，而且跑通之后非常稳定，但中间有几个坑，几乎每一个第一次做对接的人都会踩一遍。我自己前前后后配过不下十套这种组合，从最早的模拟外线网关到后来的数字中继网关，每一次都能遇到点新花样。先把场景说清楚。所谓PSTN网关，本质上是把传统的电话线路（模拟线、E1数字中继等）转换成SIP协议，让IPPBX能够识别和调度。Yeastar在这个领域做了很多年，产品线覆盖了从几路模拟口到整机数字中继的各种型号。而FreePBX是基于Asterisk的一套开源IPPBX管理系统，图形化界面友好，社区资源丰富，很多中小企业在自建电话系统时都会选它。把这两者对接起来，就是让FreePBX通过SIP中继把呼叫送到Yeastar网关上，再由网关落到实际的电话线路上。听起来很简单对吧？注册一个SIP中继，填几个参数，打个电话测试一下，完事。但实际操作中，从SIP注册状态、编解码协商、DTMF传输方式、呼叫路由规则到拨号计划匹配，每一个环节都可能出问题。而且这些问题往往不是那种一眼就能看出来的报错，而是"注册显示成功但打不出去""能打出去但对方听不到按键""能打通但单向语音"这类让人抓狂的现象。这篇内容我会把整个对接过程中最常见的坑一个一个拆开讲，包括每个坑背后的原理、排查思路、以及我实际验证过的解决方案。不管你是刚接触VOIP的新手，还是已经配过几套系统的老手，应该都能从中找到有用的东西。另外，我也会在最后聊聊国内VOIP这些年的一些变化，算是一个从业者的个人感受。2. 对接前的底层逻辑：SIP中继到底在做什么2.1 信令和媒体是两条独立的通道很多人配SIP中继时容易犯一个根本性的认知错误：把信令和媒体当成一回事。实际上在SIP协议里，信令（SIP消息）和媒体（RTP语音流）是分开走的。信令负责建立、修改和拆除会话，走的是SIP端口，默认5060；媒体负责实际传输语音数据，走的是RTP端口，通常是一段UDP端口范围。这个区分为什么重要？因为你在排查问题时，需要先判断是信令层面出了问题还是媒体层面出了问题。比如"注册失败"是信令问题，"能接通但没声音"大概率是媒体问题。两者的排查方向完全不同。在Yeastar网关和FreePBX对接的场景中，信令通常走IP可达的SIP中继（也有走注册模式的），媒体则通过SDP协商确定双方的IP和端口。如果中间有NAT设备，媒体流的可达性就会变成一个关键问题。2.2 中继模式的选择：注册中继 vs 对等中继Yeastar网关和FreePBX之间建立SIP中继，有两种基本模式：注册模式（Register Trunk）：FreePBX作为客户端向Yeastar网关发起注册，网关作为服务端验证身份。这种模式适合网关在固定公网IP上，或者两端在同一内网的情况。配置相对简单，网关侧创建一个SIP账号，FreePBX侧填上对应的注册信息就行。对等模式（Peer Trunk / IP Authentication）：双方通过IP地址互信，不需要注册。这种模式适合两端都有固定IP的场景，省去了注册维护的开销，但安全性依赖IP白名单。我个人的经验是，如果是内网对接，两种模式都行，注册模式更直观一些；如果涉及跨网络对接，对等模式配合IP白名单更稳定，因为注册模式在NAT环境下容易出各种幺蛾子。2.3 编解码协商：不是你想用什么就能用什么SIP在建立会话时，双方会通过SDP交换各自支持的编解码列表，然后选择一个双方都支持的。Yeastar网关通常支持G.711（PCMA/PCMU）、G.722、G.729等，FreePBX默认也支持这些。看起来没问题，但坑在于优先级和实际选择。如果FreePBX的SIP中继配置里把G.729排在前面，而Yeastar网关没有G.729的授权（G.729是需要额外license的），协商就会失败或者回落到其他编解码。更隐蔽的情况是，双方都"支持"某个编解码，但实际实现有差异，导致语音质量差或者单通。我的建议是：内网对接直接用G.711（PCMA或PCMU），带宽足够，音质最好，兼容性最强。如果带宽紧张需要压缩，优先考虑G.722而不是G.729，因为G.722是宽带编解码，音质明显好于G.729，而且通常不需要额外授权。3. 第一个大坑：SIP注册显示成功但呼叫失败3.1 现象描述与初步排查这个坑我遇到过至少三次，每次的表现都略有不同，但核心症状是一样的：FreePBX的SIP中继状态显示"Registered"，但拨打外线时要么直接失败，要么听到忙音，要么呼叫被立即挂断。第一次遇到这个问题时，我花了整整一个下午才找到原因。当时的排查过程是这样的：先看FreePBX的CDR（呼叫详单），发现呼叫确实发起了，但状态是"FAILED"；然后看Asterisk的CLI日志，发现SIP INVITE发出去了，但对方回了"403 Forbidden"；再去看Yeastar网关的日志，发现网关收到了INVITE，但因为没有匹配的路由规则，直接拒绝了。问题的根源在于：Yeastar网关上的呼入路由和呼出路由没有正确配置。SIP注册成功只代表信令通道通了，不代表呼叫路由通了。网关需要知道"从FreePBX来的呼叫应该送到哪条PSTN线路上"，这个信息是通过呼出路由（Outbound Route）来定义的。3.2 Yeastar网关侧的路由配置要点在Yeastar网关的管理界面上，呼出路由的配置通常包含以下几个关键字段：路由名称：随便起，但要能看懂，比如"to-PSTN-port1"呼叫来源：指定哪些SIP账号或IP的呼叫可以走这条路由被叫号码模式：用正则或通配符匹配被叫号码，比如"9."表示以9开头的号码优先级：多条路由时的匹配顺序目标端口：指定从哪个PSTN端口出局这里最容易出错的是"被叫号码模式"和"呼叫来源"的匹配。如果FreePBX发过来的被叫号码带了前缀（比如拨9出局），而网关的路由规则没有去掉这个9，那么送到PSTN线路上的号码就会多一位，导致呼叫失败。我的做法是在FreePBX的出局路由里配置好去前缀规则，确保送到网关的号码是干净的。比如用户拨"9-010-12345678"，FreePBX在送出前把9去掉，网关收到的是"01012345678"，直接匹配路由规则送到PSTN端口。3.3 FreePBX侧的中继配置细节FreePBX的SIP中继配置里，有几个参数直接影响呼叫能否成功：Outbound Proxy：如果Yeastar网关不在同一网段，或者需要经过SIP代理，这里要填网关的IP和端口。很多人忽略这个字段，导致INVITE发到了错误的地址。From Domain / From User：这两个字段决定了SIP消息头里的From字段内容。有些网关会校验From字段是否匹配已注册的账号，如果填错了，网关会拒绝呼叫。Contact User：这个字段影响网关回送响应时的目标地址。如果填错，可能出现"呼叫能发出但收不到响应"的情况。我通常会在配置完成后，用sip show peer <peer-name>命令在Asterisk CLI里查看中继的详细状态，确认注册状态、延迟、编解码协商结果等信息。如果注册状态是"OK"但呼叫失败，就重点检查路由和号码处理规则。4. 第二个大坑：DTMF按键不生效的各种姿势4.1 DTMF的三种传输方式DTMF（双音多频）就是电话按键音，在IVR（交互式语音应答）场景中至关重要。SIP环境下，DTMF有三种传输方式：RFC 2833 / RFC 4733：把按键事件作为RTP载荷传输，不依赖语音编解码，最可靠SIP INFO：通过SIP信令消息传输按键信息，兼容性好但依赖信令通道Inband：按键音混在语音流里传输，依赖编解码保真度，最不可靠Yeastar网关和FreePBX都支持这三种方式，但默认配置可能不一致。如果一端用RFC 2833，另一端用SIP INFO，按键就可能丢失。4.2 实际排查过程有一次客户反馈说，打外线进IVR后按分机号没反应。我先在FreePBX的SIP中继配置里把DTMF模式改成RFC 2833，测试后问题依旧。然后去Yeastar网关侧检查，发现网关的DTMF模式是"Auto"，理论上应该能自动协商，但实际抓包发现网关发出的RTP流里没有DTMF事件包。后来我把网关的DTMF模式强制设为RFC 2833，同时在FreePBX侧也强制设为RFC 2833，问题解决。这个案例告诉我，不要依赖"Auto"模式，两端都明确指定同一种DTMF传输方式最稳妥。4.3 抓包验证DTMF是否正常传输如果你不确定DTMF有没有正确传输，最直接的方法是在FreePBX服务器上抓包：tcpdump -i eth0 -w dtmf.pcap udp portrange 10000-20000然后在通话中按几个按键，停止抓包后用Wireshark打开，过滤rtp，查看是否有Telephone-event类型的载荷。如果有，说明DTMF事件包正常发送了；如果没有，就需要检查发送端的DTMF配置。5. 第三个大坑：单向语音和NAT穿透5.1 单向语音的典型表现单向语音是指通话建立后，一方能听到另一方，但反过来听不到。这个问题在跨网络对接时特别常见，根源通常是SDP里声明的媒体地址不可达。具体来说，FreePBX在SDP里声明的媒体地址可能是它的内网IP（比如192.168.1.100），但Yeastar网关在另一个网段，无法直接访问这个内网IP。结果就是网关把RTP流发到了192.168.1.100，但那个地址对它来说不可达，语音自然就断了。5.2 解决方案：正确配置NAT相关参数FreePBX的SIP中继配置里有几个NAT相关的参数：NAT：设为"Yes (force_rport, comedia)"，让Asterisk忽略SDP里的地址，直接回复到实际发送RTP的地址Local Networks：在Asterisk的SIP设置里配置本地网段，让Asterisk知道哪些地址是内网External Address：如果FreePBX在NAT后面，这里填公网IPYeastar网关侧也有类似的NAT配置。如果网关在NAT后面，需要在网络设置里开启NAT模式，并填写外部IP。我的经验是，内网对接时把NAT设为"No"，跨网络对接时设为"Yes (force_rport, comedia)"，并且在两端都正确配置本地网段。这样大多数单向语音问题都能解决。5.3 用SDP信息定位媒体地址问题在Asterisk CLI里，可以用sip set debug on命令开启SIP调试，然后发起一次呼叫，观察SDP里的c=字段（连接地址）和m=字段（媒体端口）。如果c=字段里的地址明显不对（比如是内网IP但实际需要公网IP），那就说明NAT配置有问题。6. 第四个大坑：拨号计划与号码处理的细节6.1 出局前缀的添加与去除国内打电话习惯拨前缀出局，比如拨"9"走外线。这个前缀在FreePBX的出局路由里添加，然后在送到Yeastar网关之前去掉。如果忘记去掉，网关收到的号码就会多一位，导致呼叫失败。FreePBX的出局路由配置里有一个"Dial Patterns"区域，可以配置前缀去除规则。比如：9|. // 匹配以9开头的号码 9|0[1-9]. // 匹配9开头的国内长途这里的9|表示匹配前缀9，后面的.表示任意后续号码。在"Trunk Sequence"里选择对应的SIP中继，然后在"Prepend"和"Prefix"字段里配置号码处理规则。6.2 号码规范化的常见问题国内电话号码的格式比较多样，有带区号的固话、有不带区号的固话、有手机号、有400/800号码等。如果号码规范化没做好，可能出现"能打通但对方看不到正确主叫号码"或者"呼叫被运营商拒绝"的情况。我的做法是在FreePBX里配置一个统一的出局号码处理规则：固话补全区号，手机号直接透传，国际长途加拨特定前缀。然后在Yeastar网关侧再检查一遍号码格式，确保送到PSTN线路上的号码符合运营商要求。6.3 呼入路由的匹配逻辑呼入方向同样重要。PSTN线路收到来电后，Yeastar网关需要根据被叫号码（DID）把呼叫路由到FreePBX的对应分机或IVR。如果网关的呼入路由配置不正确，来电可能被直接挂断或者送到错误的目的地。Yeastar网关的呼入路由通常支持按DID号码匹配、按端口匹配、按时间条件匹配等。我一般会配置一条默认路由，把所有未匹配的来电送到FreePBX的总机或IVR，然后再根据具体DID配置精确路由。7. 第五个大坑：语音质量与编解码选择7.1 为什么G.711是内网对接的首选G.711是PSTN网络的标准编解码，采样率8kHz，比特率64kbps。它的优点是音质好、兼容性强、几乎不需要额外处理。缺点是带宽占用相对较高，但对于内网环境来说，这点带宽根本不是问题。相比之下，G.729的比特率只有8kbps，节省带宽，但音质明显下降，而且需要license。G.722是宽带编解码，采样率16kHz，音质比G.711还好，但需要两端都支持。我的建议很直接：内网对接用G.711，不要折腾其他编解码。如果带宽实在紧张，优先考虑G.722而不是G.729。7.2 编解码协商失败的排查如果呼叫建立后没有语音，或者语音质量极差，首先要检查编解码协商结果。在Asterisk CLI里用core show channels查看活动通道，或者用sip show peer <peer>查看协商的编解码。如果发现协商的编解码不是预期的，检查两端的编解码配置顺序。FreePBX的SIP中继配置里有一个"Codecs"区域，可以调整编解码的优先级。Yeastar网关侧也有类似的配置。7.3 网络抖动和丢包的影响即使编解码协商正确，网络质量差也会导致语音问题。VOIP对网络抖动和丢包非常敏感，一般要求抖动小于30ms，丢包率小于1%。如果怀疑是网络问题，可以在两端之间做持续的ping测试和MTR测试，观察延迟和丢包情况。如果网络质量确实差，可以考虑启用Asterisk的jitter buffer功能，或者调整Yeastar网关的QoS设置。8. 国内VOIP这些年的变化与个人感受8.1 从模拟线到全IP的迁移我入行的时候，大部分企业还在用传统的程控交换机，模拟外线一条一条地接。后来IPPBX逐渐普及，SIP中继开始替代模拟线，部署和维护的成本大幅下降。Yeastar这类网关产品的出现，让传统电话线路和IP系统之间的过渡变得平滑了很多。现在新建的办公场景，基本上直接上SIP话机或者软电话，连物理线路都省了。但在一些传统行业和特定场景里，PSTN线路仍然有不可替代的价值，比如传真、报警系统、POS机等。这也是为什么PSTN网关这个品类至今仍然有市场。8.2 对接调试从"玄学"到"工程化"早些年配VOIP，很多时候靠经验靠猜，出了问题就重启设备、换端口、改参数，试到通为止。现在随着工具链的完善，抓包分析、日志追踪、SIP调试都变得更容易了，排查问题越来越像一门工程学科，而不是玄学。但即便如此，SIP协议的灵活性和各厂商实现的差异性，仍然让对接工作充满挑战。同一个问题，不同型号的网关可能有不同的表现；同一个配置，不同版本的固件可能有不同的行为。这也是为什么我每次对接新设备时，都会预留足够的调试时间，不会假设"上次这样配能通，这次也一定能通"。8.3 给后来者的几点建议如果你刚开始接触Yeastar网关和FreePBX的对接，我有几个建议：第一，先把网络层打通。确保两端IP可达，SIP端口和RTP端口没有被防火墙拦截。这是所有后续工作的基础。第二，从最简单的配置开始。先用G.711编解码，RFC 2833 DTMF，注册模式中继，把基本呼叫跑通，再逐步添加复杂功能。第三，善用日志和抓包工具。Asterisk的CLI日志、Yeastar网关的系统日志、tcpdump抓包，这三个工具能解决90%以上的问题。第四，不要怕试错。VOIP对接本身就是一个不断调试的过程，每一次踩坑都是一次学习。我到现在配新设备时仍然会遇到没见过的问题，但只要掌握了排查方法，总能找到解决方案。最后说一句，技术这东西，文档看十遍不如自己动手配一遍。找个空闲时间，搭个测试环境，把各种配置都试一遍，踩过的坑才会真正变成你自己的经验。
1. 从一通打不通的外线电话说起如果你正在看这篇内容，大概率你手里正握着一台Yeastar的PSTN网关，或者正准备把它和FreePBX对接起来。我先说结论：这套组合能跑通，而且跑通之后非常稳定，但中间有几个坑，几乎每一个第一次做对接的人都会踩一遍。我自己前前后后配过不下十套这种组合，从最早的模拟外线网关到后来的数字中继网关，每一次都能遇到点新花样。先把场景说清楚。所谓PSTN网关，本质上是把传统的电话线路（模拟线、E1数字中继等）转换成SIP协议，让IPPBX能够识别和调度。Yeastar在这个领域做了很多年，产品线覆盖了从几路模拟口到整机数字中继的各种型号。而FreePBX是基于Asterisk的一套开源IPPBX管理系统，图形化界面友好，社区资源丰富，很多中小企业在自建电话系统时都会选它。把这两者对接起来，就是让FreePBX通过SIP中继把呼叫送到Yeastar网关上，再由网关落到实际的电话线路上。听起来很简单对吧？注册一个SIP中继，填几个参数，打个电话测试一下，完事。但实际操作中，从SIP注册状态、编解码协商、DTMF传输方式、呼叫路由规则到拨号计划匹配，每一个环节都可能出问题。而且这些问题往往不是那种一眼就能看出来的报错，而是"注册显示成功但打不出去""能打出去但对方听不到按键""能打通但单向语音"这类让人抓狂的现象。这篇内容我会把整个对接过程中最常见的坑一个一个拆开讲，包括每个坑背后的原理、排查思路、以及我实际验证过的解决方案。不管你是刚接触VOIP的新手，还是已经配过几套系统的老手，应该都能从中找到有用的东西。另外，我也会在最后聊聊国内VOIP这些年的一些变化，算是一个从业者的个人感受。2. 对接前的底层逻辑：SIP中继到底在做什么2.1 信令和媒体是两条独立的通道很多人配SIP中继时容易犯一个根本性的认知错误：把信令和媒体当成一回事。实际上在SIP协议里，信令（SIP消息）和媒体（RTP语音流）是分开走的。信令负责建立、修改和拆除会话，走的是SIP端口，默认5060；媒体负责实际传输语音数据，走的是RTP端口，通常是一段UDP端口范围。这个区分为什么重要？因为你在排查问题时，需要先判断是信令层面出了问题还是媒体层面出了问题。比如"注册失败"是信令问题，"能接通但没声音"大概率是媒体问题。两者的排查方向完全不同。在Yeastar网关和FreePBX对接的场景中，信令通常走IP可达的SIP中继（也有走注册模式的），媒体则通过SDP协商确定双方的IP和端口。如果中间有NAT设备，媒体流的可达性就会变成一个关键问题。2.2 中继模式的选择：注册中继 vs 对等中继Yeastar网关和FreePBX之间建立SIP中继，有两种基本模式：注册模式（Register Trunk）：FreePBX作为客户端向Yeastar网关发起注册，网关作为服务端验证身份。这种模式适合网关在固定公网IP上，或者两端在同一内网的情况。配置相对简单，网关侧创建一个SIP账号，FreePBX侧填上对应的注册信息就行。对等模式（Peer Trunk / IP Authentication）：双方通过IP地址互信，不需要注册。这种模式适合两端都有固定IP的场景，省去了注册维护的开销，但安全性依赖IP白名单。我个人的经验是，如果是内网对接，两种模式都行，注册模式更直观一些；如果涉及跨网络对接，对等模式配合IP白名单更稳定，因为注册模式在NAT环境下容易出各种幺蛾子。2.3 编解码协商：不是你想用什么就能用什么SIP在建立会话时，双方会通过SDP交换各自支持的编解码列表，然后选择一个双方都支持的。Yeastar网关通常支持G.711（PCMA/PCMU）、G.722、G.729等，FreePBX默认也支持这些。看起来没问题，但坑在于优先级和实际选择。如果FreePBX的SIP中继配置里把G.729排在前面，而Yeastar网关没有G.729的授权（G.729是需要额外license的），协商就会失败或者回落到其他编解码。更隐蔽的情况是，双方都"支持"某个编解码，但实际实现有差异，导致语音质量差或者单通。我的建议是：内网对接直接用G.711（PCMA或PCMU），带宽足够，音质最好，兼容性最强。如果带宽紧张需要压缩，优先考虑G.722而不是G.729，因为G.722是宽带编解码，音质明显好于G.729，而且通常不需要额外授权。3. 第一个大坑：SIP注册显示成功但呼叫失败3.1 现象描述与初步排查这个坑我遇到过至少三次，每次的表现都略有不同，但核心症状是一样的：FreePBX的SIP中继状态显示"Registered"，但拨打外线时要么直接失败，要么听到忙音，要么呼叫被立即挂断。第一次遇到这个问题时，我花了整整一个下午才找到原因。当时的排查过程是这样的：先看FreePBX的CDR（呼叫详单），发现呼叫确实发起了，但状态是"FAILED"；然后看Asterisk的CLI日志，发现SIP INVITE发出去了，但对方回了"403 Forbidden"；再去看Yeastar网关的日志，发现网关收到了INVITE，但因为没有匹配的路由规则，直接拒绝了。问题的根源在于：Yeastar网关上的呼入路由和呼出路由没有正确配置。SIP注册成功只代表信令通道通了，不代表呼叫路由通了。网关需要知道"从FreePBX来的呼叫应该送到哪条PSTN线路上"，这个信息是通过呼出路由（Outbound Route）来定义的。3.2 Yeastar网关侧的路由配置要点在Yeastar网关的管理界面上，呼出路由的配置通常包含以下几个关键字段：路由名称：随便起，但要能看懂，比如"to-PSTN-port1"呼叫来源：指定哪些SIP账号或IP的呼叫可以走这条路由被叫号码模式：用正则或通配符匹配被叫号码，比如"9."表示以9开头的号码优先级：多条路由时的匹配顺序目标端口：指定从哪个PSTN端口出局这里最容易出错的是"被叫号码模式"和"呼叫来源"的匹配。如果FreePBX发过来的被叫号码带了前缀（比如拨9出局），而网关的路由规则没有去掉这个9，那么送到PSTN线路上的号码就会多一位，导致呼叫失败。我的做法是在FreePBX的出局路由里配置好去前缀规则，确保送到网关的号码是干净的。比如用户拨"9-010-12345678"，FreePBX在送出前把9去掉，网关收到的是"01012345678"，直接匹配路由规则送到PSTN端口。3.3 FreePBX侧的中继配置细节FreePBX的SIP中继配置里，有几个参数直接影响呼叫能否成功：Outbound Proxy：如果Yeastar网关不在同一网段，或者需要经过SIP代理，这里要填网关的IP和端口。很多人忽略这个字段，导致INVITE发到了错误的地址。From Domain / From User：这两个字段决定了SIP消息头里的From字段内容。有些网关会校验From字段是否匹配已注册的账号，如果填错了，网关会拒绝呼叫。Contact User：这个字段影响网关回送响应时的目标地址。如果填错，可能出现"呼叫能发出但收不到响应"的情况。我通常会在配置完成后，用sip show peer <peer-name>命令在Asterisk CLI里查看中继的详细状态，确认注册状态、延迟、编解码协商结果等信息。如果注册状态是"OK"但呼叫失败，就重点检查路由和号码处理规则。4. 第二个大坑：DTMF按键不生效的各种姿势4.1 DTMF的三种传输方式DTMF（双音多频）就是电话按键音，在IVR（交互式语音应答）场景中至关重要。SIP环境下，DTMF有三种传输方式：RFC 2833 / RFC 4733：把按键事件作为RTP载荷传输，不依赖语音编解码，最可靠SIP INFO：通过SIP信令消息传输按键信息，兼容性好但依赖信令通道Inband：按键音混在语音流里传输，依赖编解码保真度，最不可靠Yeastar网关和FreePBX都支持这三种方式，但默认配置可能不一致。如果一端用RFC 2833，另一端用SIP INFO，按键就可能丢失。4.2 实际排查过程有一次客户反馈说，打外线进IVR后按分机号没反应。我先在FreePBX的SIP中继配置里把DTMF模式改成RFC 2833，测试后问题依旧。然后去Yeastar网关侧检查，发现网关的DTMF模式是"Auto"，理论上应该能自动协商，但实际抓包发现网关发出的RTP流里没有DTMF事件包。后来我把网关的DTMF模式强制设为RFC 2833，同时在FreePBX侧也强制设为RFC 2833，问题解决。这个案例告诉我，不要依赖"Auto"模式，两端都明确指定同一种DTMF传输方式最稳妥。4.3 抓包验证DTMF是否正常传输如果你不确定DTMF有没有正确传输，最直接的方法是在FreePBX服务器上抓包：tcpdump -i eth0 -w dtmf.pcap udp portrange 10000-20000然后在通话中按几个按键，停止抓包后用Wireshark打开，过滤rtp，查看是否有Telephone-event类型的载荷。如果有，说明DTMF事件包正常发送了；如果没有，就需要检查发送端的DTMF配置。5. 第三个大坑：单向语音和NAT穿透5.1 单向语音的典型表现单向语音是指通话建立后，一方能听到另一方，但反过来听不到。这个问题在跨网络对接时特别常见，根源通常是SDP里声明的媒体地址不可达。具体来说，FreePBX在SDP里声明的媒体地址可能是它的内网IP（比如192.168.1.100），但Yeastar网关在另一个网段，无法直接访问这个内网IP。结果就是网关把RTP流发到了192.168.1.100，但那个地址对它来说不可达，语音自然就断了。5.2 解决方案：正确配置NAT相关参数FreePBX的SIP中继配置里有几个NAT相关的参数：NAT：设为"Yes (force_rport, comedia)"，让Asterisk忽略SDP里的地址，直接回复到实际发送RTP的地址Local Networks：在Asterisk的SIP设置里配置本地网段，让Asterisk知道哪些地址是内网External Address：如果FreePBX在NAT后面，这里填公网IPYeastar网关侧也有类似的NAT配置。如果网关在NAT后面，需要在网络设置里开启NAT模式，并填写外部IP。我的经验是，内网对接时把NAT设为"No"，跨网络对接时设为"Yes (force_rport, comedia)"，并且在两端都正确配置本地网段。这样大多数单向语音问题都能解决。5.3 用SDP信息定位媒体地址问题在Asterisk CLI里，可以用sip set debug on命令开启SIP调试，然后发起一次呼叫，观察SDP里的c=字段（连接地址）和m=字段（媒体端口）。如果c=字段里的地址明显不对（比如是内网IP但实际需要公网IP），那就说明NAT配置有问题。6. 第四个大坑：拨号计划与号码处理的细节6.1 出局前缀的添加与去除国内打电话习惯拨前缀出局，比如拨"9"走外线。这个前缀在FreePBX的出局路由里添加，然后在送到Yeastar网关之前去掉。如果忘记去掉，网关收到的号码就会多一位，导致呼叫失败。FreePBX的出局路由配置里有一个"Dial Patterns"区域，可以配置前缀去除规则。比如：9|. // 匹配以9开头的号码 9|0[1-9]. // 匹配9开头的国内长途这里的9|表示匹配前缀9，后面的.表示任意后续号码。在"Trunk Sequence"里选择对应的SIP中继，然后在"Prepend"和"Prefix"字段里配置号码处理规则。6.2 号码规范化的常见问题国内电话号码的格式比较多样，有带区号的固话、有不带区号的固话、有手机号、有400/800号码等。如果号码规范化没做好，可能出现"能打通但对方看不到正确主叫号码"或者"呼叫被运营商拒绝"的情况。我的做法是在FreePBX里配置一个统一的出局号码处理规则：固话补全区号，手机号直接透传，国际长途加拨特定前缀。然后在Yeastar网关侧再检查一遍号码格式，确保送到PSTN线路上的号码符合运营商要求。6.3 呼入路由的匹配逻辑呼入方向同样重要。PSTN线路收到来电后，Yeastar网关需要根据被叫号码（DID）把呼叫路由到FreePBX的对应分机或IVR。如果网关的呼入路由配置不正确，来电可能被直接挂断或者送到错误的目的地。Yeastar网关的呼入路由通常支持按DID号码匹配、按端口匹配、按时间条件匹配等。我一般会配置一条默认路由，把所有未匹配的来电送到FreePBX的总机或IVR，然后再根据具体DID配置精确路由。7. 第五个大坑：语音质量与编解码选择7.1 为什么G.711是内网对接的首选G.711是PSTN网络的标准编解码，采样率8kHz，比特率64kbps。它的优点是音质好、兼容性强、几乎不需要额外处理。缺点是带宽占用相对较高，但对于内网环境来说，这点带宽根本不是问题。相比之下，G.729的比特率只有8kbps，节省带宽，但音质明显下降，而且需要license。G.722是宽带编解码，采样率16kHz，音质比G.711还好，但需要两端都支持。我的建议很直接：内网对接用G.711，不要折腾其他编解码。如果带宽实在紧张，优先考虑G.722而不是G.729。7.2 编解码协商失败的排查如果呼叫建立后没有语音，或者语音质量极差，首先要检查编解码协商结果。在Asterisk CLI里用core show channels查看活动通道，或者用sip show peer <peer>查看协商的编解码。如果发现协商的编解码不是预期的，检查两端的编解码配置顺序。FreePBX的SIP中继配置里有一个"Codecs"区域，可以调整编解码的优先级。Yeastar网关侧也有类似的配置。7.3 网络抖动和丢包的影响即使编解码协商正确，网络质量差也会导致语音问题。VOIP对网络抖动和丢包非常敏感，一般要求抖动小于30ms，丢包率小于1%。如果怀疑是网络问题，可以在两端之间做持续的ping测试和MTR测试，观察延迟和丢包情况。如果网络质量确实差，可以考虑启用Asterisk的jitter buffer功能，或者调整Yeastar网关的QoS设置。8. 国内VOIP这些年的变化与个人感受8.1 从模拟线到全IP的迁移我入行的时候，大部分企业还在用传统的程控交换机，模拟外线一条一条地接。后来IPPBX逐渐普及，SIP中继开始替代模拟线，部署和维护的成本大幅下降。Yeastar这类网关产品的出现，让传统电话线路和IP系统之间的过渡变得平滑了很多。现在新建的办公场景，基本上直接上SIP话机或者软电话，连物理线路都省了。但在一些传统行业和特定场景里，PSTN线路仍然有不可替代的价值，比如传真、报警系统、POS机等。这也是为什么PSTN网关这个品类至今仍然有市场。8.2 对接调试从"玄学"到"工程化"早些年配VOIP，很多时候靠经验靠猜，出了问题就重启设备、换端口、改参数，试到通为止。现在随着工具链的完善，抓包分析、日志追踪、SIP调试都变得更容易了，排查问题越来越像一门工程学科，而不是玄学。但即便如此，SIP协议的灵活性和各厂商实现的差异性，仍然让对接工作充满挑战。同一个问题，不同型号的网关可能有不同的表现；同一个配置，不同版本的固件可能有不同的行为。这也是为什么我每次对接新设备时，都会预留足够的调试时间，不会假设"上次这样配能通，这次也一定能通"。8.3 给后来者的几点建议如果你刚开始接触Yeastar网关和FreePBX的对接，我有几个建议：第一，先把网络层打通。确保两端IP可达，SIP端口和RTP端口没有被防火墙拦截。这是所有后续工作的基础。第二，从最简单的配置开始。先用G.711编解码，RFC 2833 DTMF，注册模式中继，把基本呼叫跑通，再逐步添加复杂功能。第三，善用日志和抓包工具。Asterisk的CLI日志、Yeastar网关的系统日志、tcpdump抓包，这三个工具能解决90%以上的问题。第四，不要怕试错。VOIP对接本身就是一个不断调试的过程，每一次踩坑都是一次学习。我到现在配新设备时仍然会遇到没见过的问题，但只要掌握了排查方法，总能找到解决方案。最后说一句，技术这东西，文档看十遍不如自己动手配一遍。找个空闲时间，搭个测试环境，把各种配置都试一遍，踩过的坑才会真正变成你自己的经验。