1、VoLTE 网上问题案例集文档版本 V1.0发布日期 2015-01-28华 为 技 术 有 限 公 司修订记录Date日期Revision Version修订版本CR ID CR 号Section Number修改章节Change Description修改描述Author作者2015-01-22 V1.0 初稿完成 曾佳00130333VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 3 共 95 页目 录1 导读 42 语音呼叫类问题 52.1 呼叫失败 .52.2 单通 .313 语音质量类问题
2、583.1 语音质量差 .584 语音增强特性类问题 594.1 RoHC.594.2 TTI_Bundling664.3 SPS 70VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 4 共 95 页1导读本文根据以往网上问题整理 VoLTE 相关问题的相关案例，在处理网上语音问题时，可以先翻阅本文相关案例，以拓展思路并缩小问题范围，最终提升问题定位效率。本文所包含案例包括从各产品收集到的历史案例，以及 GTAC VoLTE 专题组启动后处理的问题提取出来的案例，在案例格式上有些差异，后续逐步统一。本文
3、档会逐步完善，新需求或建议，请联系曾佳 00130333。VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 5 共 95 页2语音呼叫类问题 2.1 呼叫失败案例 1：英国 VDF，VoLTE 用户呼叫失败问题分析【问题描述】英国 VDF 在 11 月 15 号下午反馈同一终端同一套核心网，在爱立信/诺西基站下成功打通 VoLTE call，在华为基站下必然失败；问题表现为：VoLTE 终端开机后，QCI5 、默认承载均可建立但无法建立 QCI1导致不能通话；【问题分析】1.组网环境信息分析1.1VoLT
4、E 业务原理分析正常 VoLTE 业务流程分为以下几个过程：a) VoLTE终端完成TAU Attach流程建立QCI5 承载；b) VoLTE终端发起IMS注册流程 , 注册使用的SIP信令使用QCI5 承载；c) VoLTE终端发起语音呼叫，建立QCI1 专有承载，语音媒体使用QCI1 承载；d) VoLTE终端发起视频呼叫，建立QCI2专有承载，视频媒体使用 QCI2承载；VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 6 共 95 页图 1：正常 VoLTE 用户注册流程VoLTE 网上问题案例
5、集文档版本 Error! Unknown document property name.(2019-06-18)第 7 共 95 页图 2：正常 VoLTE 用户语音呼叫流程图 3：VoLTE 业务所使用的承载方式1.2 网络拓扑分析VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 8 共 95 页11.18 日下午，一线实验室复测抓取了 S-PGW-P-CSCF 上的抓包。分析华为和爱立信基站下主要有如下两个差异点1) 华为基站下注册的终端是诺基亚，爱立信基站下注册的终端型号未知。2）注册到华为的 re
6、gister 消息是通过 TCP 承载，且在 TCP 层有分包，对端 SBC回 503 service unavailable，而注册到爱立信的 register 消息是 UDP 承载，无分包，对端 SBC 正常回复 401。通过多次抓包和定点分析最终确定网络拓扑图如下：图 4：英国 VDF 实验室组网图 B2. 分段隔离分析针对现场所有华为站点分析，现场总共有 6 个华为站点PTH100/101/102/104/110/112，而发现在华为 PTH102 站点( 未配置 IPSEC)进行测试，VoLTE 业务有大概率 60%左右成功率(剩余 40%失败主要和核心网相关)，当时已经怀疑和 IP
7、 SEC 隧道(SeGW 节点) 强相关。进一步锁定在 PTH112 站点(配置 IPSEC)分析，通过修改 S1 接口上链路，尝试旁路 CPN 和 SeGW，并且修改 IPSec 加密算法为空加密等方案后，发现VoLTE 业务均能建立成功，最终问题隔离到和 IPSEC 相关。2.1 IPSec 旁路方案一图 5：IPSec 旁路方案一安全网关 SeGW 旁路之后，基站配置不变，基站的下一跳地址配置到跟SGE 比较靠近的路由器上，基站直接拉线到该路由器；VoLTE 业务测试结果为OK。VoLTE 网上问题案例集文档版本 Error! Unknown document property name
8、.(2019-06-18)第 9 共 95 页此旁路方案同 PTH102 站点，102 站点没有配置 IPSec，从 102 站点的 S1 用户面地址 ping SpGW 地址，8000 字节的报文都可以 ping 通，整条链路没有报文大小限制。2.2 IPSec 旁路方案二图 6：IPSec 旁路方案二相对于方案一，方案二直接把在连接安全网关 SeGW 两端的路由器互联，基站配置不变；VoLTE 业务测试结果为 OK。2.3 IPSec 旁路方案三图 7：IPSec 旁路方案三方案三实际上没有改变组网，而是将基站和安全网关的 IPSECPROPOSAL的加密算法设置为 NULL，验证算法不改
9、；VoLTE 业务测试结果为失败。同时抓取路由器和安全网关两端报文，确认 SIP_401 消息已经从安全网关发送到基站；此时排查重点转移到基站，需要确认 eNodeB 是否成功转发 401 消息；3.eNodeB 版本和配置以及话统分析检查 eNodeB 版本：BTS3900 V100R009C00SPC160；检查 EUTRAN 支持 VoIP 能力开关：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；检查小区信号质量：正常；检查数传业务成功率：正常；检查所有基站配置和 VoLTE 业务：总共 6 个基站PTH100/101/102/104/110/1
10、12，VoLTE 均失败；VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 10 共 95 页检查话统话统来确认 QCI 5 是否丢包：话统正常无丢包；Cell DT 和 IFTS 跟踪：确认 eNodeB 的 PDCP 和 MAC 层无丢包且调度正常；eNodeB 跟踪 CELL DT 和终端侧 QXDM 数据分析从 Cell dt 132 跟踪看，有些时候 VoLTE 建立的时候 QCI5 的下行有数据包，有些时候又没有下行数据包。从 CELL DT34 看，下行都是 ACK，说明空口发送 QCI5
11、数据时没有误码。终端侧 QXDM 看到，QCI5 的 RB ID 为 2，该 RB 下行也收到了数据包，但有时这些数据包能到 PDCP 层，有些到不了 PDCP 层，但是 SIP 层都收不到，不确定这些数据包是否就是 401 消息。VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 11 共 95 页4.异常问题流程分析由于前期从英国 VDF 一线和罗马尼亚 GTAC 二线得到信息是终端收不到SIP_401 消息，前后方重点都放在下行 SIP_401 丢失问题上，但是前面分析SeGW 证实已经下发；而 eN
12、odeB eRAN7.0 使用 Cell DT、IFTS、话统等都无法准确判断 401 是否从 S1 和 UU 接口转发，现场的终端 Nokia 和 Sony 也都不具备 QXDM 抓包条件；问题分析未能取得突破进展。为了统一思路前后方重新整理问题和思路寻求新的突破口，正对不同终端在同一个华为站点 PTH112 下面验证总共得到以下 3 种失败场景如下：Case1:VoLTE 注册过程中网络下发 401 鉴权挑战消息，终端未收到；图 9：Case1 网络下发鉴权挑战 401 终端未收到Case2: Sony 终端基于 UDP 的 Register 消息异常；VoLTE 网上问题案例集文档版本
13、Error! Unknown document property name.(2019-06-18)第 12 共 95 页图 10：Case2 Sony 终端基于 UDP 的注册失败Case3: Nokia 终端基于 TCP 的 Register 消息异常；图 11：Case3 Nokia 终端基于 TCP 的注册失败根据以上 3 种失败场景，根据不同终端和网元节点跟踪定位分析确定如下失败模型；至此很明显最初得到的 Case1 所描述的失败类型是一个错误的判断，是因为 Nokia 和 Sony 终端不同的失败表现产生混淆导致：5.友商成功数据分析针对相同终端在 IMS 侧抓包，分别从 E/站点
14、和华为站点比较分析，发现E/站点和华为站点的 Register 和 401 Unauthorized 消息没有明显差异；VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 13 共 95 页E/，从 IMS CORE 到 SBCWWW-Authenticate: Digest nonce=“6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y=“,realm=“ims.vodafone.co.uk“,algorithm=AKAv1-MD5,qop=“auth“,ck=“67
15、3C3B94B35314C9FE03432A239BA836“,ik=“FFD4EB7997DCB64E714184274286A155“Authentication Scheme: DigestNonce Value: “6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y=“Realm: “ims.vodafone.co.uk“Algorithm: AKAv1-MD5QOP: “auth“Cyphering Key: “673C3B94B35314C9FE03432A239BA836“Integrity Key: “FFD4EB7997DCB64E7141
16、84274286A155“E/，从 SBC 到 UESecurity-Server: ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3407;spi-s=3408;port-c=6000;port-s=7000Security-mechanism: ipsec-3gppq=0.1alg: hmac-sha-1-96ealg: aes-cbcprot: espmod=transspi-c: 3407 (0x00000d4f)spi-s: 3408 (0x00000d50)port-c: 6000p
17、ort-s: 7000Huawei 从 IMS CORE 到 SBCWWW-Authenticate: Digest nonce=“+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ=“,realm=“ims.vodafone.co.uk“,algorithm=AKAv1-MD5,qop=“auth“,ck=“31ED1CC2BAE29058057070437894DBC0“,ik=“71CF825E807149738C7EF51A794D7FEF“Authentication Scheme: DigestNonce Value: “+cF5iJzFh0c1
18、ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ=“Realm: “ims.vodafone.co.uk“Algorithm: AKAv1-MD5QOP: “auth“VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 14 共 95 页Cyphering Key: “31ED1CC2BAE29058057070437894DBC0“Integrity Key: “71CF825E807149738C7EF51A794D7FEF“HUAWEI，从 SBC 到 UESecurity-Server
19、: ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3437;spi-s=3438;port-c=6000;port-s=7000Security-mechanism: ipsec-3gppq=0.1alg: hmac-sha-1-96ealg: aes-cbcprot: espmod=transspi-c: 3437 (0x00000d6d)spi-s: 3438 (0x00000d6e)port-c: 6000port-s: 7000至此，通过以上分析判断排除终端和核心网异常；而从 P1 点抓
20、包来看也能够确认 eNodeB 成功转发了 Register 和 401 Unauthorized 消息。6.诸点抓包分析通过华为站点和 E/站点对比分析，已经明确问题出现在 S1 接口所连接设备上面，但是由于 eRAN7.0 版本( 内部确认 eRAN8.0 以上版本可以)不具备 SIP信令跟踪和足够的证据，来证明 eNodeB 成功转发 SIP 消息；即便我们能够证明PDCP 和 MAC 无丢包且调度正常。根据现场组网信息启动网络逐点抓包隔离异常网元，开始尝试 Ping 不同大小报文并且抓包分析结果如下：VoLTE 网上问题案例集文档版本 Error! Unknown document p
21、roperty name.(2019-06-18)第 15 共 95 页对 Nokia 和 Sony 两款终端异常场景抓包分析发现 P3 段会丢弃大于 1500Bytes 的报文，统计数据结果如下：VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 16 共 95 页同时对 Nokia 和 Sony 两款终端在友商 E/抓包分析发现报文在 P3 段传输固定为1420Bytes 的报文，统计数据结果如下：VoLTE 网上问题案例集文档版本 Error! Unknown document property na
22、me.(2019-06-18)第 17 共 95 页至此，发现丢包问题最终锁定在 P3(SeGWCPN)抓包段，并且此段只会丢弃大于 1490Bytes 的报文；而对比友商 E/网络传送的 1420Bytes 报文能够成功传输；最终问题锁定在 SeGW 和 CPN 网元节点。7.UE 侧问题分析7.1 华为 P7现场使用的 P7 不支持 VoLTE，临时升级到研发内部版本但是仍然测试失败;通过测试发现 P7 使用的 SIP 基于 UDP 承载，并且 Register 消息总共才1172Bytes，MTU 值可通过 root 权限配置但是设置未生效；待进一步验证。P7 升级到测试成功，但在 E/
23、的基站下，接入失败。IMS 直接回 494 消息，CN侧抓包如下：如下是 P7 失败和 sony 成功（E/基站）的对比，差异如红圈出，但 P7 发送的也符合协议 RFC3329.VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 18 共 95 页对比协议，P7 发送的 register 消息，是符合协议的，需联合 IMS 确认，其发送494 的原因。RFC3329 定义的 SIP 协商安全传输机制：2. Solution2.1 Overview of OperationThe message flow
24、below illustrates how the mechanism defined in thisdocument works:1. Client -client list- Server2. Client Server5. Client ;tag=aprqngfrt-0fqlel2000020From: ;tag=Z3dcbqtCall-ID: Y2dcbqtET10.60.9.16CSeq: 1 REGISTERVia: SIP/2.0/UDP 10.60.9.16:5060;received=10.60.9.16;branch=z9hG4bKW4dcbqtETatET9aaaqJg;
25、rport综上所述发现 P7 终端 VoLTE 业务失败原因为 SIP 协商安全传输机制失败，由于 P7 使用测试版本有可能不支持 IPSec 加密算法” ealg=null;”原因，导致友商E/的 IMS Core 直接拒绝；而 P7 终端在研发内部测试 VoLTE 业务成功，使用的是华为 CN 兼容性更高。VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 20 共 95 页7.2Nokia Lumia 830现场使用的 Nokia 终端，Windows Phone 操作系统 Lumia 系列手机；通过
26、测试发现 Nokia 终端使用的 SIP 基于 TCP 承载，并且第一条 Register 消息的大分片报文为 1360Bytes，第二条 Register 消息的大分片报文为 1480Bytes；Nokia 的 MTU 值通过信令判断为 1480，具体配置待继续研究；7.3 Sony Xperia Z2现场使用的 Sony 终端，安卓操作系统；通过测试发现 Sony 终端使用的 SIP 基于 UDP 承载，并且第一条 Register 消息的大分片报文为 1500Bytes，第二条 Register 消息的大分片报文为 1500Bytes；Nokia 的 MTU 值通过信令判断为 1500，
27、具体配置待继续研究；VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 21 共 95 页8. eNodeB 侧问题分析8.1 华为 eNodeB版本为 BTS3900 V100R009C00SPC160，此系列版本无 SIP 信令跟踪，并且不能基于 Cell DT 和 IFTS 跟踪判断 SIP 消息；即 eRAN7.0 版本无有效定位 SIP 信令的手段。/已经确认 eRAN8.0 以上版本可跟踪 SIP 消息。通过对比华为和 E/报文分析，发现 MTU 实现差异如下，华为 eNodeB 经过加密后在
28、IPSEC 以下 IP 层进行 MTU(1500)分包；SeGW 收到后会进行组包再解密，解密后如果报文大于 SeGW 的 MTU 设置会再次进行分片处理；8.2 E/ eNodeB通过对比华为和 E/报文分析，发现 MTU 实现差异如下，友商 E/可以实现在IPSEC 以上 IP 层进行 MTU(1420)分包，即先将业务报文分片再进行独立加密传输；SeGW 收到后对报文解密而不需要组包，这样避免了传输过程中再次组包和分片的操作；其 IPSEC 是通过独立单板实现；8.3 NSN eNodeBNSN eNodeB 暂时未抓取报文，但是相同组网其站点下业务能够成功说明其实现也有类似业务分片机制
29、；NSN 具体实现方式待后续验证9. 传输问题分析根据现场网络拓扑和组网进行分段 Ping 包，能够快速进行分段隔离异常网元；通过现场测试不同大小报文的 Ping 结果，发现异常点主要集中在 P3 抓包点，而 P3 抓包点为 SeGWCPN 互联方向；P3 点报文大于 1490Bytes 都被丢弃，而 SeGW 组包后解密再分片的小包能够正常传输，最初问题锁定在T5(SeGW)和 T6(CPN)两个端点；VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 22 共 95 页通过多次修改 SeGW 和 CPN
30、 端口的 MTU 值尝试 Ping 包测试，并且结合现场 CPN 抓包镜像端口 M，实际抓包端口 M 也是 CPN 物理端口，此端口 M 通过镜像 T2/T3/T6/T7 实现 Wireshark 抓包的，丢包点再次确认为 T6(CPN)和T7(CPN)两个端点；即 T6 实际收到报文且出现异常丢弃导致没有发送给镜像端口 M。再次检查整条链路中各节点 MTU 配置，统一修改 eNodeB(T1)、T2、T3、T4 、 T5、T6 、T7 MTU 为 1700Bytes，再次检查 SeGW 的 Path MTU为 1700；最终 Ping 报文 1601Bytes 能够成功，验证 VoLTE 业
31、务成功。Ping 结果如下：【问题根因】问题结论简述：现象为 VoLTE 用户注册失败，上行传输网络有大包限制和丢弃问题；处理问题过程中发现 eRAN7.0 BTS3900 V100R009C00SPC160 版本存在两点不足：1） 、eRAN7.0 以前版本不支持 SIP 信令跟踪，缺乏有效手段定位 SIP 消息转发情况；2） 、华为 eNodeB 对不支持按照业务报文分片处理，虽然符合协议但是与友商灵活实现机制相比；华为 eNodeB 实现方式优势：可以减少传输网络负荷，提高传输效率；VoLTE 网上问题案例集文档版本 Error! Unknown document property na
32、me.(2019-06-18)第 23 共 95 页华为 eNodeB 实现方式缺点：安全网关 SeGW 需要组包，增加对组网传输网路 MTU 限制的要求；RFC: 791【解决方案】解决英国 VDF 的 VoLTE 问题，根据现场诉求提供两种方案：方案 1） 、建议现场检查全网设备节点的 MTU 设置，通过 Ping 报文确认 S1 口(eNodeBSpGW)能够 ping 通至少 1600Bytes 报文；研发根据现场组网提供推荐配置和现场实际成功配置如下：方案 2） 、华为 eNodeB 根据现场诉求实现按照业务报文分片处理功能，待最终讨论确认正式版本；VoLTE 网上问题案例集文档版本
33、 Error! Unknown document property name.(2019-06-18)第 24 共 95 页案例 2：iphone6 做主叫 VoLTE 呼叫失败问题分析【问题描述】西研实验室进行 iphone6 VoLTE 测试，iphone6 VoLTE SIP Registration 成功，但 iphone6 作为主叫呼叫 P7，呼叫失败；而 P7 呼叫 iphone6 是正常的。【问题分析】1、根据问题现象， 属于 VoLTE 呼叫建立失败问题，这类问题，从语音核心网IMS 侧入手分析 VoLTE 呼叫控制面 SIP 信令效率较高。eNodeB/S-GW/P-GW 主
34、要负责将 SIP 信令（承载在 QCI5 EPS bearer 上）在 UE 和 P-CSCF 间正确转发，如下为 LTE 终端与 LTE 终端呼叫示意图，其中，黑色虚线为 VoLTE 呼叫建立所涉及到的网元：流程简述：1 LTE 用户发起呼叫。2 MMTel AS 执行主叫业务处理。3 完成主叫业务处理后，MMTel AS 将呼叫路由回 S-CSCF；S-CSCF 查询 ENUM，并将呼叫路由到被叫。4 在被叫侧，呼叫被路由到向被叫用户提供业务的 I-CSCF，I-CSCF 发送呼叫请求到 S-CSCF。5 MMTel AS 执行被叫业务处理后，MMTel AS 将呼叫路由回 S-CSCF；
35、S-CSCF 触发 SCC AS 进行域选（即选择被叫落地的域） ，选择 LTE 网络接入被叫用户。6 S-CSCF 将呼叫请求通过 P-CSCF 接续到被叫用户。7 承载建立。2、如下为测试同事在 SBC 侧镜像抓包采集的 log：VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 25 共 95 页从上面可以看出，当 Iphone6 发起 VoLTE 呼叫时，Iphone6 先触发建立 TCP connection，但 SBC 却没有响应，经确认，我司 SBC SE2600 在作为 A-SBC 时，缺省
36、情况下，仅支持 SIP over UDP，SIP over TCP 为可选特性，需要相关 license和相关配置才能支持，如下内容摘自 SE2600 产品手册：注：SE2600 部署在 IP 网络的边缘或汇聚层，是会话信令和媒体流的聚合点 。SE2600 作为信令代理和媒体代理设备。通过对信令和媒体的处理，SE2600 实现拓扑隐藏、NAT（Network Address Translation）/防火墙穿越等功能。A-SBC SIP 代理功能包括信令代理和媒体代理。信令代理：对 SIP 信令报文的解析、处理和转发。媒体代理：对音频、视频等媒体流的代理。3、测试同事在 SBC 上补充 SIP
37、 over TCP 相关配置后，再进行测试，发现仍是无法呼叫， log 如下：VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 26 共 95 页经测试同事咨询 SE2600 同事，该问题确认为： Iphone6 在 SIP Registration 过程中采用的是 UDP 传输协议，而在发起 VoLTE 呼叫时，采用的是 TCP 传输协议，我司 SE2600 不支持这种场景，仅支持对于同一个 UA，所有 SIP 消息都采用UDP 协议或 TCP 协议。所以，导致 iphone6 终端作为主叫时，VoLT
38、E 呼叫无法建立。问题分析到这里，我们会有个疑问，那到底 SE2600 的问题，还是 Iphone6 的问题呢？翻查了一下 RFC 3261 SIP 协议（18 Transport 章节） ，18.1.1 Sending RequestsIf a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 43 congestion controlled
39、 transport protocol, such as TCP. 18.2.1 Receiving RequestsFor any port and interface that a server listens on for UDP, it MUST listen on that same port and interface for TCP. This is because a message may need to be sent using TCP, rather than UDP, if it is too large. As a result, the converse is n
40、ot true. A server need not listen for UDP on a particular address and port just because it is listening on that same address and port for TCP. There may, of course, be other reasons why a server needs to listen for UDP on a particular address and port.大致理解如下：SIP 协议是基于 transaction 的协议，每个 transaction
41、应该都可以根据 SIP 消息需求场景决定所要采用的传输协议。而且，SIP 协议也要求大于 1300 字节的 SIP Request 消息使用支持拥塞控制的传输层协议（如：TCP） 。所以，该问题应该是 SE2600 的兼容性不够导致的问题，Iphone6 的实现没有错。【问题根因】Iphone6 终端在 VoLTE SIP Registration 过程中采用了 SIP over UDP，发起VoLTE 呼叫时，采用了 SIP over TCP，而我司 SE2600 不支持场景， SE2600 只支持对于同一个 UA，所有 SIP 消息都采用 UDP 协议或 TCP 协议。所以，出现了 Iph
42、one6 注册成功，但做主叫时，呼叫无法建立的问题。该问题根因是 SE2600 产品兼容性问题 ，我司 SBC 下一代产品 SE2900 会支持上述场景。【解决方案】1）目前，西研实验室下，由 Iphone6 临时加载补丁，使得 Iphone6 在 SIP Registration 和 VoLTE 呼叫过程中都采用 UDP 传输协议来规避。2）也可以考虑部署 SE2900 设备来解决 （SE2900 的 SIP over TCP 是产品基础特性，不再受 license 限制） 。VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2
43、019-06-18)第 27 共 95 页案例:3：UE 未发送 INVITE 消息导致电话呼叫失败的问题分析【问题描述】一线反馈 VoLTE 电话呼叫失败【问题分析】1、终端拨打电话时，基站侧的 Uu 口和 S1 口没有建立 QCI1 的承载2、QCI1 的建立条件：只有在 MME 在收到 SIP 消息后才会触发 QCI1 的承载建立。由于在基站侧看到没有建 QCI1，所以怀疑 MME 没有收到 SIP 消息。 3、通过 UE 侧的 QXDM 抓包，确认 UE 没有在拨打电话时没有发送 INVITE 消息，所以呼叫失败。4、复位手机后，问题现象消失，QXDM 抓包如下【问题根因】UE 没有在
44、拨打电话时没有发送 INVITE 消息【解决方案】需要终端分析不发送 invite 消息的原因。本案例中复位手机可以解决该问题。案例 4：Analysis report for VOLTE setup failure under HL475201_Sangambank300 site【问题描述】The VOLTE service always fails under Micro site HL475201_Sangambank300VoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 28 共 95 页【问题
45、分析】1.ENODEB alarm and faulty analysisThere is no any related active alarm and faulty from ENODEB side.2. ENODEB trace analysisAs demonstrated in the below figure, there is no RRC setup and ERAB setup failure, no call drop. And the QCI5 which is used to carry the VOIP setup signal (SIP) is setup succ
46、essfully. Figure1. S1 and UU interface signal flowSo the VOLTE setup failure should be from SIP signal part.3. Wireshark trace analysisIn this version, there is no way to capture the SIP signal from ENODEB side. So the only method to trace the SIP signal is to capture all the data transmission betwe
47、en ENODEB and SGW.Below figure shows where the wireshark data was captured.Figure2. Data capture locationFrom the wireshark trace, the VOLTE call failure is due to register fail, and the reason is the CN does not receives the second register message from UE after sending “401 unauthorized” message t
48、o UE. Figure3. The SIP signal trace between ENODEB and SGWVoLTE 网上问题案例集文档版本 Error! Unknown document property name.(2019-06-18)第 29 共 95 页Figure4. The normal register SIP signal flowThe possible reasons of CN not receive the second “register” message are:a.UE doesnt receive the “401 unauthorized” mes
49、sage.b.UE doesnt send the second register.c.ENODEB doesnt send the second register to CN.1).UE doesnt receive the “401 unauthorized” messageBy comparing with the ENODEB trace, the time difference between the CN data and ENODEB trace is 1 hour, ENODEB time is 1 hour later than CN.So the 4 times failures happened from 3:53:06 to 3:53:21 according to ENODEB time.There are logs to record the data packets at each point demonstrated in the below figure:Figure5. The ENODEB packet statistic pointVoLTE 网上问题案例集文档版本 Error! Unknown document prop
