一號多終端業務被叫失敗原因分析與優化

武紅然，史鵬利，鄧 娜（中國聯通河北分公司，河北石家莊 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廠商和手機終端的組合場景更加不計其數，用戶使用異常的現象也隨之出現了更多可能性。遇到異常情況時，要具體問題具體分析，通過跟蹤信令，分析信令消息的差異，找到問題原因，選擇最優解決方案，力爭通過一起案例解決一類問題，提升客戶感知。