一号多终端业务被叫失败原因分析与优化

武红然，史鹏利，邓 娜（中国联通河北分公司，河北石家庄 050000）

1 研究背景

一号多终端业务是指手机和射频功能的手表（或PAD）可单独通话和上网，但对外只体现一个手机号码，共用一个计费套餐。由于业务的便利性，越来越多的用户选择开通一号多终端业务。一号多终端和普通VoLTE 业务相同点是都基于IMS 架构的业务平台（AS）完成业务控制，不同点是一号多终端存在主副卡绑定关系来实现同振，该功能集成在现网VoLTE AS设备，由AS实现相关业务。

在VoLTE 业务以及一号多终端业务中普遍应用了资源预留技术。资源预留是指在呼叫流程中使用INVITE/183 进行SDP 协商，以UPDATE 消息携带SDP指示本端的资源预留完成，在200 OK（UPDATE）消息中携带对端的资源预留完成。如果协商结果为支持Precondition，则在用户振铃前就会将承载面资源预留完成，这样用户振铃时资源已经准备就绪，能够提高呼叫接通率。

一号多终端业务相对VoLTE 业务来说，需要AS集成同振管理来实现相应功能，该AS和呼叫会话控制功能（SCSCF）、协商会话控制功能（ICSCF）、边界会话控制器（SBC）等IMS 网元和手机终端互相配合，正确处理资源预留等信令消息，保障用户业务正常使用。随着一号多终端业务的迅速开展，一些异常现象也浮出水面，近期发生一些中兴AS一号多终端用户在中兴SBC 区域使用正常，到华为SBC 区域漫游时被叫失败的情况。由于中兴和华为IMS 设备在现网中广泛使用，伴随手机用户的移动性和终端的多样性，类似情况时有发生，深入分析原因，从根本上解决问题迫在眉睫，下面从一个具体案例展开详细分析。

2 现象描述与原因分析

河南一号多终端主卡在河南使用正常，漫游到河北之后，被叫振铃4 s 之后听到关机的录音通知，不能正常使用。为了解决这个问题，首先要了解跨省VoLTE 呼叫流程。以河南VoLTE 用户做主叫为例，拨打漫游在河北的河南VoLTE 用户的正常的信令流程如图1所示。

通过对比用户在河北漫游时被叫4 s 提示关机的消息，发现用户终端收到河北SBC 下发的UPDATE 消息后，并没有返回200 OK（UPDATE），而是在向河北SBC 返回180 振铃消息后，4 s 就再次返回580 PRECONDITION FAILURE，随即主叫侧听到关机的录音通知。该失败流程如图2所示。

为什么手机终端会返回580的失败码呢？是所有的河南的一号多终端用户漫游到河北都是同样的现象吗？为了回答这个问题，我们对河南的一号多终端测试卡，使用华为MATE 10、小米note 手机和荣耀手机进行测试，均能正常被叫。而用户使用的是小米某款手机，被叫时就产生了4 s 后提示关机的现象，证实这个问题和手机终端有关。由于用户的终端在河南使用正常，因此推断小米某款手机终端与河北IMS 网络和在河南IMS 网络的交互信息有差异，导致手机不能正确处理。

根据VoLTE 业务流程，漫游场景下使用漫游地SBC，归属地的SCSCF 和AS，对应到本案例用户在河北使用的是河北的华为SBC，在河南使用的是河南的中兴SBC，因此推断河北和河南的SBC 下发的UPDATE 消息内容差异导致问题产生，需要进一步证实。为此从如下3个场景分析UPDATE消息内容。

图1 拨打漫游在河北的河南VoLTE用户的正常的信令流程

图2 失败流程

2.1 河北一号多终端用户在河北使用场景

河北本地的一号多终端主卡做被叫测试，发现河北华为AS 下发的UPDATE 消息携带的P-Early-Media字段值为“gated”，华为SBC 下发给用户终端的P-Early-Media字段值也为“gated”，未做改变。

2.2 河南一号多终端用户在河南使用场景

河南一号多终端用户在河南做被叫测试，发现河南中兴AS下发的P-Early-Media 字段值为“sendonly”，河南的中兴SBC 下发给用户终端的UPDATE 消息PEarly-Media也为“sendonly”，未做改变。

2.3 河南一号多终端用户在河北漫游场景

河南一号多终端用户在河北做被叫测试，发现河南中兴AS下发的P-Early-Media 字段值为“sendonly”，河北的华为SBC 收到该消息后增加“gated”字段下发给手机终端，导致手机终端收到的P-Early-Media 字段值为“sendonly，gated”2项内容。

在同样场景下，更换多种手机终端进行被叫测试，发现不同的手机终端对P-Early-Media 字段值为“sendonly，gated”处理机制不同，华为MATE 10、小米note 和荣耀手机可以正常进行被叫流程，而小米某款手机和VIVO 某款手机返回580错误码。

通过对上述3 个场景的UPDATE 消息内容对比分析，得出如下结论：华为和中兴SBC 对P-Early-Media字段内容的处理机制不同，在中兴AS和华为SBC组合的场景下，会产生P-Early-Media 字段值为“sendonly，gated”的UPDATE 消息。这种特殊的UPDATE 消息在部分手机终端（如小米某款手机和VIVO 某款手机）无法被识别处理，导致被叫失败。

3 解决方案可行性分析

为了解决上述场景下一号多终端被叫失败的问题，可以从手机终端、中兴AS 和华为SBC 等3 个方面考虑解决方案，下面分别对这3 种方案的可行性进行分析。

方案1：手机终端侧解决。终端厂商升级，支持PEarly-Media 字段值为“sendonly，gated”。虽然现网大部分手机终端可以正确处理这种特殊的UPDATE 消息，但是根据各运营商现网实践表明，终端只需要处理sendonly，sendrecv参数，不需要根据gated 参数作任何处理。本案例中的用户终端是小米某款手机，现网中还发现还有VIVO 某款手机、ZTE 某款手机等终端也有被叫失败的问题，由于终端的多样性，不排除还会有其他型号的终端会有问题，因此方案1不可行。

方案2：中兴AS 侧解决。中兴AS 调整配置，修改UPDATE消息不下发P-Early-Media字段内容为“sendonly”。由于中兴VoLTE AS（含一号多终端功能）经常使用18x 播放网络提示音，不仅限于一号多终端业务，基本业务中也存在用18x 放网络提示音的情况。各种情况下播放提示音均采用P-Early-Media 值为sendonly，符合中国联通标准及3GPP 标准要求，因此方案2不可行。

方案3：华为SBC侧解决。华为SBC修改UPDATE消息不增加P-Early-Media 字段内容“gated”。在3GPP TS 24.628 Common Basic Communication procedures using IP Multimedia（IM）Core Network（CN）subsystem 中提到了网络放音采用sendonly 参数，全文未提及gated 参数。在RFC 5009 Private Header（PHeader）Extension to the Session Initiation Protocol（SIP）for Authorization of Early Media 中，对P-Early-Media 头域中gated 参数的描述是，表明SIP 消息经过的网络实体已经对到UAS 的早媒体进行了门控（gate），即这路媒体可以允许通过或关闭。通过对业务场景的分析，确定修改华为SBC早期媒体门控策略，实现对P-Early-Media 字段的处理方式为不增加“gated”。经过测试验证该方案可以解决被叫失败问题，同时不会影响现网业务，因此方案3可行。

修改方式为在华为SBC“早期媒体门控策略”中执行指令取消“早期媒体打开策略”，该参数修改完成后，经过测试验证，华为SBC不再给收到的UPDATE消息中P-Early-Media 字段增加“gated”，联系用户进行业务复测，中兴AS的一号多终端用户漫游到华为SBC使用小米某款等特定手机终端被叫业务恢复正常。

4 分析总结

本次案例中，由于IMS 设备厂商与手机终端厂商对资源预留消息UPDATE 中的P-Early-Media 字段处理机制不同，导致在中兴AS、华为SBC 和特定型号手机终端组合的场景下，发生被叫失败的现象。通过对信令消息深入研究分析，定位问题原因并提出3 种解决方案。通过对3种解决方案的分析得知本次被叫异常现象的发生，并非手机终端或设备厂商违规或不符合规范，而是网络设备商和手机终端商对协议理解不同，在协议未明确规定的范畴内未达成一致理解，导致组合场景下存在配合失败的现象。经过对3种方案的可行性分析，最终采取华为SBC 优化“承载控制策略”配置的方案，既解决了用户的被叫失败问题，同时也提高了设备兼容性。

由于现网IMS 网络的AS 和SBC 设备多个厂商共存，手机终端厂商存在更大的多样性，在漫游场景下涉及到不同IMS厂商和手机终端的组合场景更加不计其数，用户使用异常的现象也随之出现了更多可能性。遇到异常情况时，要具体问题具体分析，通过跟踪信令，分析信令消息的差异，找到问题原因，选择最优解决方案，力争通过一起案例解决一类问题，提升客户感知。