★ FEATURED ARTICLE 简介一份深入解析5G国际漫游及语音呼叫实现的专业技术文档适合通信工程师、核心网运维人员及5G协议学习者。文档根据3GPP定义的5GS与EPS互通漫游架构展开先厘清了漫游协议及运营商直连/国际枢纽连接方式再重点解释访问网络VPLMN与归属网络HPLMN之间的互联机制UE入网注册时AMF通过NRF寻址AUSF与UDMSEPP保障跨网信令安全PDU会话建立涉及V-SMF/H-SMF协作。针对语音业务分别介绍了EPS Fallback与VoNRN9HR两种方案在呼叫建立时延和网络兼容性上的差异建议漫游时优先选择VoNR同时归属网络兼顾两种方案以最大化兼容性紧急呼叫可通过5GS本地提供或回退到EPS的完整流程也作了专门说明。资源为单个docx文档体积291KB结构完整包含拓扑与信令流程讲解便于离线研读。已有220人学习浏览尤其适合需要快速理解5G漫游信令、语音连续性及紧急服务机制的工程技术人员参考。1. 5G时代的国际长途难点不在5G而在“长途”这题目乍看像是一则客服问答但真正在运营商或企业通信里摸过的人都知道这是核心网里最难啃的一块。5G网络下的国际长途指的是从5G用户发起到境外固网或移动网落地的一段完整呼叫链路涉及VoNR、IMS、国际信令网、对端运营商路由策略和计费对账。难点不在无线电而在信令互通与路由决策——你要让一个基于SIP-I的呼叫在跨国IP链路上找到对端还得保证媒体面质量、号码显示、DTMF和录音通知都正常任何一段掉链子用户感知就是“拨不通”或“听不清”。这篇文章写给正在做国际语音业务的工程师、虚拟运营商的技术负责人以及想把5G语音能力对接到海外落地网的读者我会把从架构选型到路由参数再到排障手段的完整路径讲干净。2. 5G国际长途的架构基础从电路域到VoNR呼叫必须走的几条链路2.1 5G语音的两条路EPS Fallback与VoNR国际呼叫为何默认走IMS在5G初期运营商普遍采用EPS Fallback方案5G用户拨打国际长途时终端先重选或切换到4G再由VoLTE的IMS网络承接呼叫。后来VoNR成熟了呼叫直接从5G NR接入IMS。不管哪条路真正决定国际长途能不能打通的是IMS核心网与境外网络的互通节点——国际关口局IGW和信令转换设备。5G网络里没有传统的TDM交换机所有语音都是IP包。国际长途呼叫从用户侧发起后会经过P-CSCF代理呼叫会话控制功能接入IMS域然后由S-CSCF服务呼叫会话控制功能根据用户的签约和触发规则将呼叫路由到出口网元。如果被叫是境外传统PSTN网络的号码呼叫还得经过MGCF或SIP-I中继网关把SIP信令转换成ISUP信令送入对端运营商网络。这里有一个关键认知所谓“在5G网络打通国际长途”本质上是在5G核心网与境外网络之间建立一条合规、可计费、媒体可穿透的SIP-I中继链路。5G只是接入方式真正的工程量在链路建立和协议协商。2.2 一张图看懂5G国际呼叫的网元角色与信令路径我习惯先把网络模型画清楚再动手下面是一个典型的5G国际长途呼叫链路的网元角色对照表网元角色在5G国际长途中的职责UE用户终端发起VoNR呼叫携带被叫E.164号码P-CSCF代理呼叫会话控制功能负责UE接入IMS分配媒体资源处理早期媒体S-CSCF服务呼叫会话控制功能触发iFC规则判断是否出网选择出口路由IBCF/TrGW网络互通边界控制功能/中继网关跨运营商网络边界做SIP头域过滤和媒体面NATMGCF媒体网关控制功能将SIP信令转换为ISUPBICC衔接PSTN网络IGW国际关口局汇聚国际话务做号码分析和路由选择境外对端网络被叫所在运营商接受来话向被叫终端寻呼常见做法是用IBCF做运营商间信令隔离用TrGW做媒体面的地址转换和端口映射用MGCF做PSTN互通。如果对端是另一个VoLTE运营商且双方签了IP互联协议则可以省略MGCF直接用SIP-I对等互联。2.3 国际长途的最小可用配置从5G核心网到国际关口局要做一个最小的可测试环境你至少需要四个部分一张5G签约卡支持VoNR或EPS Fallback、一套IMS核心网含P-CSCF/S-CSCF、一对IBCF/TrGW、一个指向对端运营商的SIP-I中继。我在实验室里通常用Open5GS做5G核心网用Kamailio做IBCF/S-CSCF的轻量替代再用FreeSWITCH模拟MGCF和境外被叫侧。这样做的好处是每一跳都能抓包、能定位。以下是一个用Kamailio做S-CSCF出网路由的最小路由配置示例# kamailio.cfg 中关于出网呼叫的路由片段 route[OUTBOUND_TO_IGW] { # 只有被叫号码以 00 开头时才走国际出口 if (uri ~ ^sip:00[0-9]) { # 改写Request-URI指向国际关口局 rewritehostport(192.0.2.10:5060); # 添加Route头强制经过IBCF append_branch(); route(RELAY); exit; } # 其他呼叫进入本地域内路由 route(LOCAL_ROUTE); }这段配置的逻辑很直白先判断被叫URI是否以“00”国际字冠开头若是则把信令转发到国际关口局的IP地址和端口若不是则走本地路由。关键参数是rewritehostport它决定了呼叫的下一跳网元地址。实际运营商环境里这里会是一张复杂的号码分析表但实验室里这一条就够了。如果你在配置里加了IBCF还需要在它对外的SIP消息里做头域透传控制尤其是P-Asserted-Identity主叫号码标识和Privacy主叫号码隐藏标志。这两个头域在跨国呼叫里经常被对端运营商严格校验透传错了轻则号码显示异常重则呼叫被直接拒绝。3. 打通国际长途的核心路由设计、号码分析与出局策略3.1 号码分析为什么是国际长途的“第一道关卡”国际呼叫的号码规则比国内呼叫复杂得多。被叫号码可能是标准的国际E.164格式如00862112345678也可能带国家码但不带国际接入码如862112345678还有可能携带运营商前缀某些国家的移动号码需要加拨运营商选择码。在5G核心网的MGCF或IGW里都必须先做号码归一化和字冠分析再决定路由去向。我一般会在IGW的路由表里维护一张前缀匹配表格式是“字冠 对端运营商 中继组 费率”。例如0086对应中国内地00886对应中国台湾00852对应中国香港。这里有个容易踩坑的地方国际字冠在某些国家是00在北美是011在澳大利亚是0011。5G核心网如果收的是带00的号码但国际关口局的对端中继用的还是011那必须在出口前做号码改写。3.2 用一张表讲清国际路由策略直连、转接与LCR选路路由策略适用场景优点常见问题直连对端话务量大、双方签有对等互联时延低、质量可控对端要求严格接入门槛高经转接商中小话务量、覆盖不足快速开通、免对接每转一手多一跳质量不可控LCR动态选路多转接商并存、价格波动成本最优可自动切换需实时监控路由质量否则容易翻车选择直连还是转接主要看话务量和对端合作意愿。多数虚拟运营商和中小电信运营商会从转接开始跑累积话务后再跟重点方向的运营商签直连。LCR最经济路由是话务量上来后的必选项但LCR的前提是每条路由的质量数据可统计、可回溯否则你会发现最便宜的那条路恰恰是接通率最低的。3.3 在5G核心网里配置出局路由从S-CSCF到IBCF的实战配置出局路由的配置位置通常在S-CSCF的iFC初始过滤规则里它决定了用户的来话是否触发到出网应用服务器。实际项目中S-CSCF会把国际呼叫转发给一个专门的应用服务器AS这个AS再根据号码分析结果将呼叫送到对应的IBCF或MGCF。这里写一个简化的LCR选路脚本用Python模拟国际路由决策适合你理解选路逻辑也能直接改写到大网的数据配置里# lcr_route.py - 模拟国际路由选择 # 路由表: 国家码 - [(中继组, 优先级, 成本权重)] route_table { 86: [(TRUNK-UNICOM, 1, 0.8), (TRUNK-TRANSIT-A, 2, 0.5)], 886: [(TRUNK-TRANSIT-B, 1, 0.6), (TRUNK-TRANSIT-C, 2, 0.9)], 81: [(TRUNK-KDDI, 1, 0.7), (TRUNK-TRANSIT-D, 2, 0.4)], } def select_route(called_number): # 提取国家码规则为00 国家码 cc called_number[2:5] # 在路由表里做最长前缀匹配 best_cc None for i in range(len(cc), 0, -1): if cc[:i] in route_table: best_cc cc[:i] break if not best_cc: return None candidates route_table[best_cc] # 选择优先级最高且成本权重最低的路由 candidates.sort(keylambda x: (x[1], x[2])) return candidates[0]这段脚本的核心是“最长前缀匹配”和“优先级成本权重”双因子选路。注意国家码的匹配顺序如果被叫是00886你会先用“886”匹配到中国台湾的专用路由而不是误用“86”匹配到中国内地。宁可在数据库里多建几条字冠也不要靠模糊匹配猜。3.4 对端互联参数SIP-I中继、编解码与媒体面协商的初始配置一旦路由选定呼叫就会以SIP会话的形式送入对端。运营商之间的互联协议一般是SIP-ISIP with ISUP encapsulation它比普通SIP多了一层ISUP消息封装目的是保留PSTN侧的电路参数和信令信息。配置SIP-I中继时有三个参数必须提前与对端书面确认第一是编解码列表建议只协商G.711PCMA/PCMU和AMR-WB跨国场景下不要轻易启用EVS因为对端不一定支持第二是DTMF传输方式统一用RFC 2833RTP中的电话事件避免用SIP INFO因为SIP INFO在穿越多段网络时容易被丢弃第三是T.38传真支持如果业务里有传真需求要在SIP/SDP协商阶段提前声明。媒体面NAT穿越是另一个隐藏坑。如果IBCF/TrGW部署在内网对端媒体的源IP是私网地址呼叫建立后媒体流会一直被对端丢弃。常见做法是在TrGW上开启媒体面的IP和端口改写把私网地址映射成公网地址后再发出SDP。4. 5G国际长途的协议协商细节编解码、DTMF、超时和呼叫保持4.1 编解码协商为什么G.729在国际长途里是“玄学”编解码协商发生在SDP会话描述协议交换阶段。主叫UE在Invite请求里携带自己支持的编解码列表被叫侧应答时只会选择双方都支持的编码。国际长途场景里由于网络跳数多、路由器缓存深高压缩比编码如G.729容易出现“听得到字但断断续续”的情况因为它对丢包极其敏感。而G.711虽然带宽大但抗丢包能力好得多。我的一线经验是国际中继上只允许PCMA/PCMU且要求对端关闭静音抑制。如果对端坚持用AMR-WB也是可以的但必须在TrGW上把媒体面抖动缓冲区调大到100ms以上。这里给一个FreeSWITCH上设置国际中继编解码的示例实际用的是运营商SBC时参数逻辑是相通的。!-- FreeSWITCH中继的编解码配置示例 -- bridge param nameinbound-codec-prefs valuePCMU,PCMA/ param nameoutbound-codec-prefs valuePCMU,PCMA/ param namedisable-silence-detection valuetrue/ param namejitterbuffer-size value100/ /bridge4.2 DTMF传输RFC2833、SIP INFO与带内音的选择DTMF在跨国呼叫里是典型的“黑匣子”——你无法直接控制对端怎么处理按键音。国内呼叫经常用SIP INFO传DTMF但跨国链路中中间每一跳都可能把SIP INFO当成普通OPTIONS消息处理导致按键丢失。最保险的方案是启用RFC 2833也叫telephone-event它把按键音编码成RTP包随媒体流传输天然能和NAT穿透兼容。但要注意有些老旧的转接商不支持RFC 2833你会在接听时听到对方IVR的提示音按键却毫无反应。遇到这种情况只能退回带内DTMF也就是把音频里的DTMF音和语音一并传输让对端自己识别。4.3 呼叫超时与重定向国际长途的“后悔药”参数国际呼叫的寻呼时延远高于国内呼叫常见设置是被叫振铃超时在90到120秒之间。如果设短了国际漫游用户还没响应就被释放了如果设长了用户体验是“拨了号半天没声音”。另外重定向策略也要考虑当首选LCR路由无应答时是否自动溢出到次选路由。我会在IGW上配置两轮路由尝试首轮选择质量最高的直连路由第二轮溢出到成本和接通率更均衡的转接路由。前提是IGW必须能区分“网络不可达”“用户忙”“无应答”几种不同的释放原因否则会把一个被叫主动拒接的呼叫错误地浪费到第二路由上。4.4 早期媒体与183响应的关键作用跨国呼叫的“哆——哆——”回铃音来源有两种一种是被叫侧返回183 Session Progress并带早期媒体另一种是本侧MGCF生成的本地回铃音。在国际长途场景我强烈建议开启早期媒体透传因为对端运营商的回铃音往往包含了品牌提示音、彩铃或法律提示语本地生成回铃音会绕开这些业务。但开启早期媒体透传的前提是TrGW/SBC必须允许183消息通过并且对早期媒体的IP和端口做地址改写。这里的参数一般叫“early-media-bypass”或“allow-early-media”在运营商级SBC上默认是关闭的遇到国际呼叫没有回铃音的问题优先检查这一个点。5. 5G国际长途的常见问题与排查从“拨不通”到“听不清”的战场5.1 现象呼叫建立后主叫听不到任何回铃音原因大多是P-CSCF或IBCF没有放行183早期媒体响应或者TrGW没有对早期媒体的SDP做NAT改写。解决在SBC/IBCF上开启early-media透传策略并在TrGW上启用early-media地址改写。如果对端使用的是私网IP发布SDP还必须人工比对抓包中SDP里的IP与后续RTP实际来源IP是否一致。5.2 现象呼叫可以接通但通话30秒左右被强制中断原因多数不是信号问题而是媒体面NAT映射老化。TrGW维护的地址映射表有会话超时时间默认可能在30到60秒一旦超出且没有keepalive后续RTP包的源IP或端口变了对端防火墙就把媒体连接切断了。解决把TrGW的媒体会话空闲超时提高到300秒以上并在SBC上配置RTP keepalive比如每15秒发一个带舒适噪声的RTP包。5.3 现象主叫号码显示为“匿名”或被对端直接拦截原因国际信令里的P-Asserted-Identity头域携带的主叫号码可能因为隐私设置或格式不合法比如没带国家码、含非数字字符被对端拒绝。许多国家对接入的国际呼叫要求必须携带合法的主叫号码否则按骚扰电话处理。解决在出局网关做号码归一化确保PAI头域格式为“CountryCodeNationalNumber”并检查Privacy头域的值。若业务上允许显示主叫号码Privacy必须设为“none”如果业务要求隐藏在发送给对端时还要同时把PAI清空。5.4 现象拨打特定国家的号码一直“网络忙”其他方向正常原因大概率是国际信令路由在某一跳上出了环路。我曾经遇到一个案例A运营商的IGW把呼叫转给B转接商B的运营数据里又把呼叫转回了A结果信令在A和B之间来回跳直到Max-Forwards耗尽被丢弃。解决查呼叫的Via头域和Path头域看是否出现了两个AS的地址交替出现。配置上要确保国际中继的呼出方向不会指向本网的回程路由并在SBC上设置Max-Forwards上限为15防止无限循环。5.5 现象接通后语音单通主叫听到被叫被叫听不到主叫原因媒体面地址协商错误最常见的是SDP应答里携带的是TrGW的内网地址或者TrGW的媒体端口没放通。还有一种情况是双端都启用了对称RTPNAT穿透策略不一致。解决抓RTP包确认主叫→被叫方向的媒体流是否有实际包到达对端。在TrGW上关闭对称RTP并启用端口固定确保同一会话的RTP收发使用相同四元组源IP/源端口/目的IP/目的端口。这通常要运营商配合调试物理防火墙不止改软件参数。5.6 现象呼叫接通率在夜间暴跌白天正常原因最现实的原因是白天的国际话务走高对端运营商的AS应用服务器或中继容量拥塞导致从路由到寻呼的各环节时延变大、触发超时释放。也有另一种更隐蔽的情况部分转接商在夜间把到某些方向的媒体转给了备用链路而备用链路的码型变换设备故障只通信令不通媒体。解决在IGW上做分时段路由策略比如22点到次日8点把特定方向话务切到备用直连中继同时监控每小时的接通率与平均呼叫建立时延阈值超过30秒就告警人工介入调整路由权重。6. 验证国际长途是否“打通”拨测矩阵、信令追踪与媒体质量评分国际呼叫的验证工作分三层信令层、媒体层、业务层。信令层主要看Invite到ACK的完整交互媒体层要看RTP包是否连续、抖动和丢包指标是否在可接受区间业务层要看回铃音、DTMF、通话保持与放音是否正常。我一般会建一个拨测矩阵覆盖“主叫所属网络5G/4G/固网×被叫方向直连国家/转接国家/漫游国家×业务类型语音/传真/呼叫保持”每个组合拨测5次记录接通率、平均建立时延、丢包率和MOS值。拨测时优先使用自动拨测工具但跨国场景里自动拨测工具的服务器位置会影响结果建议用SIPP或自研拨测脚本双轨验证。分享一个信令追踪的实用命令在SBC或MGCF的抓包服务器上直接用SIPp发起测试呼叫并记录trace# 使用SIPp发起一个国际呼叫场景 sipp -sf uac_offer_answer.xml 192.0.2.10:5060 -m 5 -i 192.0.2.20 -p 5060 -trace_screen -trace_err -trace_msg # 抓包分析SIP消息里的关键头域 tshark -r output.pcap -Y sip.MethodINVITE -T fields -e sip.From -e sip.To -e sip.P-Asserted-Identity这里SIPp的脚本文件(uac_offer_answer.xml)定义了呼叫的SDP和信令流程执行后会生成消息trace和错误日志。抓包的目标IP端口要对准IGW监听的IP和端口tshark过滤器提取了呼叫里的关键号码标识便于核对主被叫号码改写是否正确。媒体质量的验证我习惯用PESQ或POLQA算法打分。没有专业仪器时可以抓取RTP流后计算抖动和丢包再按经验映射成MOS参考值。一条好的国际中继端到端平均丢包率应低于1%抖动应低于30ms往返时延在直连场景下低于250ms经转接场景下低于500ms。最后说一个我自己的教训配置国际中继时永远不要急着把对端提供的参数照单全收。对端运营商的配置文档往往只描述了理想网络环境下的行为真实链路里的NAT、防火墙策略、编解码优先级冲突都要靠拨测去验证。尤其是早期媒体和DTMF这两个点项目上线前必须逐方向模拟测通否则上线后接到的第一个投诉电话就会让你在夜里翻工。建立一个“合规优先、小流量试运行、逐步放量”的节奏能让你少走很多弯路。希望这些路径和参数能帮到你剩下的实战细节就是用抓包文件和拨测记录去和电路争议死磕的过程了。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
