Sie sind auf Seite 1von 402

Information Sharing of Important

VoLTE Issues (2016-11)

Issue 01

Date 2016-12-29

HUAWEI TECHNOLOGIES CO., LTD.


Copyright © Huawei Technologies Co., Ltd. 2016. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions


and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their respective
holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.


Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China

Website: http://www.huawei.com

Email: support@huawei.com

Issue 01 (2016-12-29) Huawei Proprietary and Confidential i


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents

Contents

1 Overview.........................................................................................................................................1
2 Fault Cases......................................................................................................................................2
2.1 Fault Cases for November 2016.....................................................................................................................................2
2.1.1 In the IMS-AKA Service, Calls Cannot Be Properly Released Because the SBC Does Not Use the Expected SA. .2
2.1.2 Calls Fail Because the Registration Cache Function Is Enabled for the SE2900.......................................................4
2.1.3 Calling Party Cannot Hear the Called Party Due to Inconsistent Payload Values......................................................4
2.1.4 Customized Ring Back Tone Heard by the CS Subscriber Is Not Complete in a CS-to-VoLTE Call........................6
2.1.5 MME Disconnects Calls Because the eMSC Server Returns a Handover Success Response Upon Receiving a 404
Message Indicating a Handover Failure...............................................................................................................................7
2.1.6 Media Negotiation Fails Because the Clock Rate of the Codec Used by the Call Is Different from the RFC2833
Clock Rate............................................................................................................................................................................8
2.1.7 Two More TransCoders Are Required Due to Inconsistent maxptime Values, Causing Poor Voice Quality.............9
2.1.8 Session Timer Negotiation Fails in Non-stable State................................................................................................10
2.2 Fault Cases for October 2016.......................................................................................................................................11
2.2.1 Due to Long Period of Paging, No Tone Is Played to a Called Party After the Called Party Answers a Call...........11
2.2.2 Calls from VoLTE Subscribers to Local Fixed-Line Subscribers Fail After an eSRVCC Handover........................15
2.2.3 Triggering the MCN Service Fails When the HSS Does Not Block an IMPU in IMSI Format...............................17
2.2.4 Conference Call Fails After Adding a Participant to the Conference Fails (Occurring Only for iPhones)...............19
2.2.5 Calls to VoLTE Subscribers Fail After They Are Handed Over to a 2G Network Because of Defective PSI
Procedure on the eMSC......................................................................................................................................................20
2.2.6 After Calling Parties Are Handed Over to a 2G Network, Their New Calls to VoLTE Subscribers Are Fallen Back
............................................................................................................................................................................................22
2.2.7 CFB Service Fails to Be Triggered for a VoLTE Subscriber on a 2G Network Because the ACM Message Sent
from the VMSC Server Does Not Carry a Cause Value.....................................................................................................23
2.2.8 Incorrect Call End Time Is Recorded in ACRs After the Bearer Release Timer Expires.........................................25
2.2.9 Measurement Result of Diameter Success But Data Not Exist Sharply Increases After Some Subscribers Are
Migrated from HSS1 to HSS2............................................................................................................................................27
2.2.10 No Ring Back Tone Is Played After the ATS Triggers the CFNRY Service...........................................................29
2.2.11 Calls Addressed to VoLTE Subscribers Served by NSN HSS May Fail.................................................................30
2.2.12 eSRVCC Handover Success Rate Decreases by 5% Because ALM-10828 Is Not Cleared as Instructed..............31
2.2.13 CPU Overload Alarms Are Generated for USRSU Boards on the DRA Because Low-end VoLTE UEs Initiate a
Large Number of PDN Connection and Disconnection Requests......................................................................................34
2.3 Fault Cases for August 2016.........................................................................................................................................36

Issue 01 (2016-12-29) Huawei Proprietary and Confidential ii


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents

2.3.1 During Implementation of the IN SMS Service, the ATS9900 Does Not Support Use of the Location Information
IE of the IDP Message to Carry ECGI Information...........................................................................................................36
2.3.2 Call Forwarding Service Cannot Be Triggered When the History-Info Header Field of the INVITE Message
Received by the ATS9900 Contains the Privacy Parameter...............................................................................................37
2.3.3 After the Terminating SCC AS Triggers CS Retry, the Call Is Connected but the Calling and Called Parties Cannot
Talk with Each Other..........................................................................................................................................................38
2.3.4 Timestamps in ACR Messages Sent by the ATS9900 Are Incorrect When the Bearer Is Lost.................................39
2.3.5 Contact Header Field of the NOTIFY Message Sent by the ATS9900 Does Not Carry the Conference URI,
Causing a Failure in Inviting New Subscribers to the Conference....................................................................................40
2.3.6 After Call permitted with insufficient bandwidth Is Set to Y(Yes), the SE2900 Does Not Return a 488 Message
When Required Bandwidth Resources in the INVITE Message Sent by the Core Side Are Insufficient..........................41
2.3.7 Held Party Cannot Hear an Announcement...............................................................................................................42
2.3.8 NOTIFY and BYE Messages That Traverse the SE2900 Arrive Out of Order.........................................................42
2.3.9 During Alerting Switchover, the SCC AS Initiates an UPDATE Message to Change the Media PT Value,
Disconnecting the Voice Connection..................................................................................................................................43
2.3.10 TCP Links Fail to Be Established When Waiting for a TCP Link Establishment Response Times Out.................44
2.4 Fault Cases for July 2016.............................................................................................................................................45
2.4.1 Location Information Carried in the IMS-Visited-Network-Identifier AVP of CDRs Generated by the ATS9900 Is
Incorrect..............................................................................................................................................................................45
2.4.2 CDIV Services Cannot Be Triggered When VoLTE Subscribers Roam to a CS Network in Another Country.......46
2.4.3 Calling Party Cannot Hear the Local Ring Back Tone After the Customized Ring Back Tone Fails to Be Played. 47
2.4.4 CDIV Service Processing on the Next-hop NE Fails Because the Value of Privacy in the Diversion Header Field
of the INVITE Message Sent from the ATS9900 Is Incorrect............................................................................................48
2.4.5 Timestamp In ACR Messages Sent from the ATS9900 Is Incorrect.........................................................................49
2.4.6 ATS9900 Does Not Stopping Playing the Customized Ring Back Tone Upon Receiving a 183 Message That
Carries the P-Early-Media Header Field But Does Not Carry the SDP Information When a Call Is Routed to the CS
Network and Then the CFNRy Service Is Triggered..........................................................................................................50
2.4.7 ALM-20051 Bill Pool OverLoad Alarm Is Generated for the ATS9900...................................................................51
2.4.8 SPU Board Is Reset When There Are a Large Number of Calls in Two-System Networking..................................52
2.4.9 EXP USRINF May Fail to Run.................................................................................................................................53
2.5 Fault Cases for June 2016.............................................................................................................................................54
2.5.1 SE2900 May Fail to Connect Calls to Called Parties Due to UE Abnormalities......................................................54
2.5.2 SE2900 Returns a 404 Response After Receiving a Handover INVITE Message from the SRVCC IWF...............55
2.5.3 Second Call Fails When VoWiFi Subscribers Initiate Re-registrations in the ICS Domain After eSRVCC
Handovers...........................................................................................................................................................................56
2.5.4 eSRVCC Handover Fails for Conference Service Parties, Resulting in a Failure in Re-establishing Conference
Information.........................................................................................................................................................................57
2.5.5 S-CSCF Returns a 503 Message After Receiving an INVITE Message from the AS..............................................58
2.5.6 VoLTE Subscriber Fails to Receive a Call Immediately After Powering on the Mobile Phone...............................59
2.5.7 Terminating S-CSCF Returns a 500 Message for an Intra-VoLTE Call....................................................................60
2.5.8 eSRVCC Handover Success Rate for High-Speed Railway Dedicated Networks Is Low........................................61
2.5.9 Session Binding Service Fails When the origin-host in the CCA Message Is Inconsistent with the DMPEER host-
name Configured on the SPS..............................................................................................................................................62
2.5.10 Peer End Fails to Re-establish a Link with the SPS After the SPS Disconnects the Link with the Peer End Due to
the Failure in Receiving the DWA Message.......................................................................................................................63

Issue 01 (2016-12-29) Huawei Proprietary and Confidential iii


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents

2.5.11 When Subscription to VoLTE SRVCC Is Not Enabled on the HSS, SRVCC Handovers Fail for VoLTE UEs in
Special Scenarios................................................................................................................................................................64
2.6 Fault Cases for May 2016.............................................................................................................................................66
2.6.1 Bandwidth Values Carried in AAR Messages Sent by the SE2900 Are Incorrect During an eSRVCC Handback. .66
2.6.2 404 Message Is Returned for an eSRVCC Handover Initiated by the Calling Party................................................67
2.6.3 When a VoLTE UE Initiates a Video Call, the SE2900 Does Not Use the Bandwidth Specified in the 'b=' Line of
SDP Information Carried in the UE-Initiated Message, Wasting Wireless Network Bandwidth Resources.....................68
2.6.4 VoLTE Calling Party Cannot Hear the Called Party After Initiating an aSRVCC Handover....................................69
2.6.5 SCC AS Does Not Include the +g.3gpp.mid-call Parameter in the Feature-Caps Header Field of the 200 Message
for Handover Success.........................................................................................................................................................71
2.6.6 ATS9900 Occasionally Sends 500 Messages to Calls Initiated from a VoLTE Subscriber to Another VoLTE
Subscriber Attached to the CS Domain..............................................................................................................................72
2.6.7 SRVCC Handover of the Second Call for a Subscriber Having Two Calls Fails as the SCC AS Does Not Send the
REFER Message.................................................................................................................................................................73
2.6.8 VoLTE UE Registration Fails as the S-CSCF Returns a 500 Message.....................................................................75
2.6.9 Registered VoLTE UE Fails to Initiate a Registration Again Using Plaintext as the S-CSCF Returns a 403 Message
............................................................................................................................................................................................76
2.6.10 400 Message (Bad Request) Is Returned to the Initial Registration of an iPhone..................................................77
2.6.11 486 Message Is Returned to the Initial Registration of a Non-iOS Terminal..........................................................79
2.6.12 Registration of VoBB Terminals at a VoBB+VoLTE Site Fails If the Minimum Registration Duration Is Modified
............................................................................................................................................................................................80
2.6.13 Deregistered Subscriber Is in the Registered State on the ATS...............................................................................82
2.6.14 Third-party Deregistration Fails..............................................................................................................................83
2.6.15 Registration on the 4G Network Is Successful But Calls Fell Back to the 2G/3G Network When Huawei CSCF
Cooperates with Bell PSBC................................................................................................................................................84
2.6.16 VoLTE Subscriber Fails to be Called After Roams to the Alcatel-Lucent PSBC as the P-Associated-URI
Contained in the 200 (to REGISTER) Message Does Not Carry a tel URI.......................................................................85
2.6.17 Subscriber Cannot Make or Receive Calls After the Registration Is Updated, Which Is Restored After the
Subscriber Initiates a Registration Again...........................................................................................................................87
2.6.18 CSCF Returns 403 Messages When Different Subscribers Use the Same Call-ID to Initiate Registrations..........88
2.6.19 CSCF Connects a Call After Receiving a 405 Message from the AS.....................................................................89
2.6.20 CSCF Sends a BYE Message Immediately After the Called Party Answers the Call............................................91
2.6.21 Originating S-CSCF Returns a 500 Message for a Call Between Two IMS Subscribers After Querying the
ENUM Server.....................................................................................................................................................................93
2.6.22 Teleconference Fails After a VoLTE Video Call Falls Back to a Voice Call...........................................................95
2.7 Fault Cases for April 2016............................................................................................................................................97
2.7.1 Called UE Returns a 488 Message............................................................................................................................97
2.7.2 RTA Message Does Not Carry the Origin-Host and Origin-Realm AVP..................................................................99
2.7.3 VoLTE Subscriber Fails to Send a Short Message After a LTE-to-3G Handover...................................................100
2.7.4 No-reply Timer in the Default Call Forwarding upon No Reply Service Uses an Incorrect Value........................102
2.7.5 SCU Module Restarts When More Than Two Extended Header Fields Are Removed..........................................105
2.7.6 SCC AS Sends a 480 Message Carrying "No appropriate session for SRVCC/eSRVCC" for a bSRVCC Handover
..........................................................................................................................................................................................106
2.7.7 SCC AS Sends a 480 Message Carrying "Do not match switch condition" for a bSRVCC Handover..................107
2.7.8 ESN Cannot Be Obtained When More Than Four IP Addresses Are Configured for the ATS...............................108

Issue 01 (2016-12-29) Huawei Proprietary and Confidential iv


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents

2.7.9 Call Is Released Because the MSC Server Fails to Receive a PRACK Message Before the Timer Expires..........109
2.7.10 Encrypted SIP Signaling Hinders Fault Location..................................................................................................111
2.8 Fault Cases for March 2016........................................................................................................................................114
2.8.1 Inconsistent AMR Parameters Cause One-Way Audio...........................................................................................114
2.8.2 Inconsistent AMR Codec Attributes Cause One-Way Audio..................................................................................116
2.8.3 AGCF ua-profile Subscription Fails........................................................................................................................117
2.8.4 CSCF Incorrectly Uses Secure IP Addresses to Forward BYE Messages from Called Parties to Calling Parties..119
2.8.5 After Subscriber Migration, Alarms Indicating That Remote Addresses Are Unreachable Are Generated............121
2.8.6 404 Message May Occur in VoLTE Call Tests........................................................................................................122
2.8.7 SPG Fails to Return limitation-of-parallel-calls to the BSS....................................................................................123
2.8.8 Some Subscribers Fail to Register Due to the Incorrect qop Parameter.................................................................125
2.8.9 ATS Releases the Call Due to Unsupported Fax Codecs When a Voice Call Is Switched to a Fax Call................128
2.9 Fault Cases for February 2016...................................................................................................................................130
2.9.1 iPhones Fail to Register with IMS Networks..........................................................................................................130
2.9.2 Calls Cannot Be Made to iPhones That Are Running in the Data Mode................................................................131
2.9.3 VoLTE Subscribers Using iPhones Fail to Call CS Subscribers.............................................................................132
2.9.4 Calls Addressed to VoLTE Subscribers May Fail After IN Services Are Triggered...............................................136
2.9.5 Huawei and Bell Have Different Understandings of IMS Protocols.......................................................................137
2.10 Fault Cases for January 2016...................................................................................................................................139
2.10.1 Modifying Subscription Data on the PGW Fails Due to the Loss of KI Data......................................................139
2.10.2 Ut Service Test Can Be Performed Using the hosts File Embedded in an Android-Based Mobile Phone...........140
2.10.3 Diameter Links Between the CSCF and DRA Do Not Run Properly...................................................................141
2.10.4 SBC Cannot Receive REGISTER Messages from P-GW....................................................................................142
2.10.5 SPG Fails to Issue Service Provisioning Instructions Due to the Change in the Default Value of the INSP
Software Parameter..........................................................................................................................................................143
2.10.6 eSRVCC Handovers Fail Due to eNodeB Configuration Errors...........................................................................144
2.10.7 Calls Fail Due to Access-Side Bearer Resource Insufficiency..............................................................................146
2.10.8 Calls Fail Due to Poor Radio Network Coverage.................................................................................................148
2.10.9 eSRVCC Handovers Fail Due to Abnormal Messages Sent by the UE................................................................151
2.10.10 After the SCC AS Triggers CS Retry, the Terminating S-CSCF Returns a 500 Message...................................153
2.10.11 When Subscribers Register, the CSCF Returns a 403 Message Carrying "Administrator deregister user"........155
2.10.12 When a Call Is Addressed to a VoLTE Subscriber Who Returns to the 4G Network After an eSRVCC Handover,
CSFB Is Performed on the MT Side.................................................................................................................................158
2.10.13 End Office Takes More Than Four Seconds to Return a Response (to PSI) to the HSS.....................................160
2.11 Fault Cases for December 2015................................................................................................................................162
2.11.1 Digit Collection Fails for Calls Addressed to the Number 12580.........................................................................162
2.11.2 Subscribers Who Are Not Defined Using the China Mobile-specific Service Flow Fail to Register...................165
2.11.3 Calls Between VoBB and VoLTE Subscribers Fail...............................................................................................166
2.11.4 Subscribers Attached to SBCs of Another Vendors Cannot Make or Receive Calls After PROTOCOLPARA6
Bit1 Is Set to 1..................................................................................................................................................................168
2.11.5 eSRVCC Handover Requests May Be Forwarded to the I-CSCF When the SE2900 Releases CPU Resources Due
to an Internal Interruption.................................................................................................................................................169
2.12 Fault Cases for November 2015...............................................................................................................................171

Issue 01 (2016-12-29) Huawei Proprietary and Confidential v


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents

2.12.1 Video Calls from M823 Terminal Subscribers to CS Subscribers Cannot Fall Back to Voice Calls....................171
2.12.2 Quick Signal Attenuation Causes eSRVCC Handovers to Fail.............................................................................172
2.12.3 Incorrect Route Configuration for the Gx Interface on the P-GW Causes a Failure in Establishing Dedicated
Bearers for Calls Between VoLTE Subscribers................................................................................................................174
2.12.4 Calls Initiated by 4G Subscribers to the VoLTE Test Card Fall Back to the 2G Network as Anchoring Data Is Not
Configured for the Card....................................................................................................................................................176
2.12.5 Calls Fail When Diameter Route Data Is Not Configured for the Rx Interface of the SBC.................................178
2.12.6 There Is a Long Delay in Establishing Calls.........................................................................................................179
2.12.7 When an X2-based Handover Is Performed in a Call, the EPC Does Not Send an QCI-1 Bearer Establishment
Request, Causing an Access Failure.................................................................................................................................180
2.12.8 When a Call Is Addressed to a Subscriber Who Has Just Registered, the Network Returns a 403 Message.......182
2.12.9 eSRVCC Handovers Fail Due to Registration Errors............................................................................................183
2.12.10 Calls Fail to Be Answered After aSRVCC Handovers Are Performed for VoLTE Subscribers Who Have
Subscribed to the CRBT Service and Are Being Alerted of Incoming Calls...................................................................185
2.12.11 ZTE Terminal Users Who Have Subscribed to IN Services Encounter Call Loss..............................................186
2.12.12 eSRVCC Handovers Fail When Calls Addressed to Roaming Subscribers Are in the Alerting State................188
2.12.13 Mid-Call Handover Fails for Calls Made by Dialing the Short Number............................................................192
2.12.14 After an eSRVCC Handover Is Performed for an Alerting Call but the Calling Party Hangs Up Before the
Called Party Answers the Handed-Over Call, the Call Cannot Be Released on the Terminating Side............................194
2.12.15 Calls Are Released When the LIA Message Returned by Bell DRA Contains Error Code 5012.......................196
2.12.16 Inband Digit Collection Fails for Calls from VoLTE Subscribers to the 114 Service Platform When the P-Early-
Media Header Field Value in the 183 Message Sent by MGCF Is sendonly...................................................................198
2.12.17 Announcements Fail for Video Calls Addressed to Powered-Off Phones...........................................................200
2.12.18 404 Message Is Returned When an iPhone Registers.........................................................................................202
2.12.19 During a Mid-Call Handover, the REFER Message Cannot Be Sent.................................................................206
2.13 Fault Cases for October 2015...................................................................................................................................207
2.13.1 When a Registered UE Initiates a Subscription to the Subscriber Status, the NOTIFY Message Returned by the
S-CSCF Carries "terminated;reason=noresource"...........................................................................................................207
2.13.2 After the S-CSCF Fails to Contact an AS, It Does Not Continue to Contact Another AS....................................209
2.13.3 After an eSRVCC Handover, the MGCF Fails to Send ICS Registrations Due to "Authentication Failure".......210
2.13.4 RCS Client Receives "Unsupported media type" When Sending MESSAGE Messages.....................................211
2.13.5 During a Mid-Call eSRVCC Handover (with One Held Session and One Active Session), the BYE Message Sent
by the SCC AS Carries "channel type not implemented".................................................................................................213
2.13.6 Incorrect Access Network Information in the CDRs Generated in VoWiFi Handover Scenarios Results in a
Failure in Sorting Out VoWiFi and VoLTE CDRs............................................................................................................215
2.13.7 Media Collision Occurs in "CS CFB + Precondition" Scenarios..........................................................................217
2.13.8 Calling Parties Cannot Hear the Ring Back Tone When Calls to CRBT Subscribers Are Forwarded Upon No
Reply.................................................................................................................................................................................219
2.13.9 CRBT Service Fails When the Time Between the UPDATE Message and 200 (to UPDATE) Message Is Too
Short.................................................................................................................................................................................223
2.13.10 DNS Query Fails When the SRV Record for a Host Name on the DNS Exceeds 512 Bytes and DNS Links
Configured on the CSCF Work in UDP Mode.................................................................................................................224
2.13.11 Calling Terminal Displays the Call Failure When a Call from an iPhone Subscriber in the CS Domain to a
VoLTE Subscriber (IN Service Subscriber) Is Normally Released by the VoLTE Subscriber.........................................226

Issue 01 (2016-12-29) Huawei Proprietary and Confidential vi


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents

2.13.12 When a Subscriber in the CS Domain Calls a VoLTE Subscriber (CRBT Subscriber), the 491 Message Is
Generated..........................................................................................................................................................................228
2.13.13 One-Way Audio Occurs in Video Calls...............................................................................................................233
2.13.14 Two Announcements Play When Subscribers Attached to Ericsson VMSC Server Call VoLTE Subscribers Who
Are Busy...........................................................................................................................................................................235
2.13.15 When Huawei IMS Interworks with Bell SBC, the TAS Cannot Obtain the sbc-domain Field from the P-
Access-Network-Info Header Field..................................................................................................................................238
2.13.16 ATS Sends PUR Messages to Obtain Transparent Data from the HSS for Unregistered Subscribers................239
2.13.17 Initial Registrations from VoLTE Subscribers Fail..............................................................................................240
2.13.18 Codec Sequence Is Incorrect for SBC Calls and eSRVCC Handovers...............................................................241
2.14 Fault Cases for September 2015...............................................................................................................................243
2.14.1 When the eMSC Sends an INVITE Message to the I-CSCF, the IMS Side Returns a 403 Message, Causing the
Call to Fail........................................................................................................................................................................243
2.14.2 After the IMS Core Completes Initial Registration, the 401 Message Returned by the IMS Core Cannot Be
Routed to the UE Through the SBC Side.........................................................................................................................244
2.14.3 As the INVITE Message Sent by the UE of a Registered VoLTE Subscriber Fails to Traverse the P-GW, the Call
Fails..................................................................................................................................................................................245
2.14.4 E-CSCF Function Embedded in the SE2900 Is Required for IMS Emergency Calls...........................................248
2.14.5 During Subscriber Registration, the CSCF Returns a 500 Message After Receiving an SAA Message..............251
2.14.6 During Service Provisioning, the PUA Message Carries "diameter-error-user-data-not-recognized"..................253
2.14.7 During Third-Party Registration, the SNA Message Carries "diameter-error-user-data-cannot-be-notified"......255
2.14.8 During Third-Party Registration, Some Information in the UDA Message Returned by the HSS Is Lost...........256
2.14.9 During Third-Party Registration, the UDA Message Carries "diameter-error-user-data-not-recognized"...........257
2.14.10 SRVCCW IWF Does Not Carry the Extended Parameter UE-History-Information to the VMSC over the Sv
Interface, Causing a Handover Failure.............................................................................................................................259
2.14.11 When a 4G Subscriber Calls a 3G Subscriber, ZTE VMSC Server Does Not Respond to the UP Negotiation
Request from Huawei MGCF, Causing the Call to Be Released.....................................................................................260
2.14.12 Calls from 4G Subscribers to 3G Subscribers Are Released Due to Incompatibility of Some BICC Parameters
..........................................................................................................................................................................................262
2.14.13 When a Subscriber Roams from a 4G to 2/3G Network and Then Returns to the 4G Network for Registration, a
500 Message Is Received.................................................................................................................................................263
2.14.14 HTC Phones Fail to Call Marvell Phones...........................................................................................................265
2.14.15 In a Multi-Party Call, the Service Party Fails to Merge the Fourth Session.......................................................267
2.14.16 eSRVCC Handover Fails.....................................................................................................................................268
2.14.17 When a Call to B (CBRT Subscriber) Is Forwarded to C (not a CRBT Subscriber) Upon No Reply, C's Terminal
Itself Does Not Play an Alerting Tone..............................................................................................................................270
2.14.18 When the RAU of the Terminal Connects to the 2G Network and Then Returns to the 4G Network Through the
TAU, the VoLTE Indicator of the Terminal Is Lost..........................................................................................................272
2.14.19 Voice Calls May Fail to Be Switched to Video Calls for QualComm Terminals................................................275
2.14.20 VoLTE-to-VoLTE Calls Fail in Jinhua City in Zhejiang Province......................................................................279
2.14.21 SRVCC Handovers Fail During Comba Telecom Tests......................................................................................281
2.14.22 UE Cancels a Call Because the TFT Is Incorrectly Processed............................................................................286
2.14.23 Subsequent Call Fails If a TAU Request Is Initiated at the TA Edge Upon Call Completion.............................290
2.14.24 mid-call eSRVCC Handovers Fail When ZTE IMS Network Interworks with Huawei eMSC..........................293
2.14.25 VoLTE Video Calls Cannot Be Barred................................................................................................................294

Issue 01 (2016-12-29) Huawei Proprietary and Confidential vii


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents

2.14.26 Announcement Placed to a Call Waiting Subscriber Is Incorrect........................................................................295


2.14.27 Intra-IMS VoLTE Hotline Call Fails...................................................................................................................296
2.14.28 Called Parties on a MPTY Call Are Not Released After Hanging Up................................................................297
2.14.29 Video Call Between a VoLTE Subscriber on an LTE Network and Another VoLTE Subscriber on a 2G/3G
Network Fails...................................................................................................................................................................299
2.14.30 SRVCC IWF Does Not Send an INVITE Message to the IMS Network During an eSRVCC Handover..........299
2.14.31 Participants Are Offline During a Three-Party Call Using Huawei Mate 7........................................................300
2.15 Fault Cases for August 2015.....................................................................................................................................302
2.15.1 Video Calls Fail After SE2900 V300R001C10 Is Upgraded to V300R001C20...................................................302
2.15.2 "ALM-27011 Diameter(SCTP) link path fault" Is Generated After the SE2900's SPU Resets............................303
2.15.3 SE2900 Does Not Switch Traffic Back to the Original I/S-CSCF That Has Already Recovered After the I/S-
CSCF Switchover.............................................................................................................................................................304
2.15.4 VoLTE Users Fail to Be Called Before They Are Re-registered and After the I/S-CSCF Recovered..................305
2.15.5 CSCF Wrongly Disconnects the Existing Call After Receiving a re-REGISTER Message.................................306
2.15.6 HTC UEs Are Registered Successfully but Fail to Initiate Calls After Being Upgraded......................................307
2.15.7 sbc-domain in Access-Network-Information of the CDRs Specific to Certain Originating or Terminating UEs
Does Not Carry Any Area Code Due to the Oversized P-Access-Network-Info Header Field.......................................308
2.15.8 Registration Service Fails When the Contact Header Field Contains More Than 256 Bytes...............................309
2.15.9 VoLTE and VoBB Performance Measurement Statistics Are Not Separated........................................................310
2.15.10 VoLTE Test Result Shows that the MATE 7's Video Fallback Function May Fail.............................................312
2.15.11 Galaxy S6/MATE7/iPhone6 Fails to Call the Fixed-Line Number Served by the MA5620..............................313
2.15.12 No-audio Issue Occurs After the Call Initiated by the M821 UE to a Fixed-Line Number Served by the MA5620
Is Established....................................................................................................................................................................314
2.15.13 Call Established Between Two VoLTE UEs Falls Back to the CS Domain Because the Nokia P-GW Cannot
Report the Charging AVP.................................................................................................................................................315
2.15.14 When the VoLTE CRBT User Is Called in the CS Domain, the Calling Party Can Hear the CRBTs but Cannot
Be Informed that the Called Party Is Busy If Being Rejected..........................................................................................317
2.15.15 No CDR Header Is Present in the Empty CDR File on the VoLTE Network......................................................318
2.15.16 When a VoLTE UE Calls a CS UE, the MGCF Keeps Retransmitting the Received UPDATE Message Specific
to the Precondition to the VoLTE UE...............................................................................................................................319
2.15.17 During eSRVCC Tests on Basic Calls, the Announcement of "Sorry, the number you dialed does not exist" Is
Played...............................................................................................................................................................................320
2.15.18 UE Fails to Join the Three-Party Conference, and the ATS Returns a 481 Response.........................................322
2.15.19 Roaming VoLTE UE Fails to Call the Local VoLTE UE, and the SBC Returns a 480 Response.......................323
2.15.20 eSRVCC Handover Fails Because the STN-SR Number in the Handover INVITE Message Is Not Updated. .325
2.15.21 Call to the Roaming VoLTE UE Fails, and the CS Domain Returns a 486 Response........................................327
2.15.22 Same Announcement Is Played When the UE Is Powered Off or Unavailable..................................................329
2.15.23 After UE A That Is Already on a Call with UE B Answers the Call from UE C, the Calls Among Them Are
Disconnected....................................................................................................................................................................332
2.15.24 Call from the CS Domain to a VoLTE UE Fails, and the MGCF Returns a 488 Response................................333
2.15.25 When a Called VoLTE UE Is Unavailable, the Call Is Forwarded and Established Even If the VoLTE UE Does
Not Subscribe to the Cal Forwarding Service on the ATS of the VoLTE Network..........................................................335
2.15.26 Multiple Copies of a Short Message Are Received After the Short Message Is Sent.........................................336
2.16 Fault Cases for July 2015.........................................................................................................................................338

Issue 01 (2016-12-29) Huawei Proprietary and Confidential viii


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents

2.16.1 CFNR Service Fails...............................................................................................................................................338


2.16.2 Voice Quality Is Poor After Calls Are Forwarded to CS Subscribers Upon Non-Reply.......................................339
2.16.3 VoLTE Registration Fails.......................................................................................................................................340
2.16.4 SE2900 Receives a 404 Message After Sending a SUBSCRIBE Message..........................................................341
2.16.5 CH Service Fails....................................................................................................................................................342
2.16.6 CLIR Service Fails When Calls Are Addressed to Subscribers in the 4G Network.............................................343
2.16.7 MGCF Fails to Convert the ACM (User Busy) Message to a 486 Message.........................................................344
2.16.8 Announcements Are Still Played When Calls are Forwarded...............................................................................345
2.16.9 Domain Selection Fails..........................................................................................................................................345
2.16.10 Video Calls from Samsung S6 Encounter an Error.............................................................................................346
2.16.11 Calls Between VoLTE Subscribers in the 2G Network Occasionally Fail..........................................................347
2.16.12 Roaming VoLTE Subscribers Fail to Register.....................................................................................................348
2.16.13 Too Many SRV Records About the SCC AS Cause ENS Query to Fail.............................................................349
2.16.14 During a Conference Call, When the Conference Call Service Subscriber Initiates a SUBSCRIBE Message, the
MMTel AS Returns a 403 Message..................................................................................................................................350
2.16.15 CS-LOCATION Information Is Not Included in ACRs Generated for Calls Where the Called Party Is in the 2G
Network............................................................................................................................................................................351
2.16.16 Subscribers Cannot Be Provisioned Because Alias repository data download flag Is Set to TRUE..................352
2.16.17 Running ADD SBR on the MMTel AS Fails with the Internal Error Code 10010505.......................................353
2.16.18 Precondition Fails on a CS-to-VoLTE Call Due to Incorrect Software Parameter Setting on the MGCF..........354
2.16.19 Access-Network-Information AVP Does Not Contain the Area Code Due to Incorrect Data Configuration on the
SBC...................................................................................................................................................................................355
2.16.20 IMS Announcement Fails Because the SCC AS Does Not Carry the ICS Capability Indicator.........................356
2.16.21 CDRs Generated for VoLTE-to-VoLTE Calls Do Not Contain the TADS-Indication Due to Software Parameter
Setting on the ATS............................................................................................................................................................357
2.16.22 CFNR Calls to 2G/3G Subscribers Fail Due to Precondition Degrade Configuration on the MGCF................358
2.16.23 Call Waiting Tone Is Not Played Due to Data Configuration on the MGCF When the Service Subscriber Is on a
CS Network......................................................................................................................................................................359
2.16.24 Local Call Number Presentation Fails Because the HSS Provided by the Ericsson Does Not Support Download
of the Shared Alias Group ID Using an SAR Message....................................................................................................362
2.16.25 ATS Service Provisioning Fails Due to Inconsistent Service Rights on the HLR and ATS................................363

3 Historical Problems...................................................................................................................365
3.1 Calls Fail Because Terminals Do Not Support Dynamic Establishment of TCP Connections..................................366
3.2 ATS9900 Does Not Support Anchor IDP Messages with Variable-Length ASN.1 Coding.......................................367
3.3 Active VCU Process Occasionally Fails If the Format of the URI List for Conference Creation Does Not Comply
with the Interface Definition............................................................................................................................................368
3.4 SBC Proactively Sends a BYE Message to Release the Call Initiated by an IPSec AKA Authentication Subscriber
over TCP During Reregistration.......................................................................................................................................369
3.5 One-Way Media Occurs After an aSRVCC Handover...............................................................................................370
3.6 Call Fails to Be Retrieved After an SRVCC Handover Is Performed for a Hold Subscriber.....................................372
3.7 utran-cell-id-3gpp Cannot Be Recorded in CDRs When the P-Access-Network-Info Header Field in an INVITE
Message Exceeds 170 Bytes.............................................................................................................................................373
3.8 SCC AS Does Not Send a MESSAGE Message When the Feature-Caps Header Field in a REGISTER Message
Exceeds 512 Bytes............................................................................................................................................................375

Issue 01 (2016-12-29) Huawei Proprietary and Confidential ix


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents

3.9 MGCF Returns a 400 Message After Receiving an INVITE Message for a Video Call Initiated by a VoLTE
Subscriber to a CS Subscriber..........................................................................................................................................376
3.10 One-Way Media Occurs When a VoLTE Subscriber Calls a CS Subscriber............................................................377
3.11 SCU Modules Are Overloaded When Multiple UEs in the Same Implicit Registration Set Are Traced.................381
3.12 Call Forwarding Fails If the Precondition Function Is Enabled...............................................................................382
3.13 Extra-long CDRs Are Generated by the ATS9900...................................................................................................384
3.14 SBC Returns an Error Because the Calling Party Hangs Up After an eSRVCC Handover Occurs But Before the
Called Party Answers the Call..........................................................................................................................................385
3.15 VoLTE Call Fallback Occurs Due to USSDs Delivered by the CN Side.................................................................386
3.16 3G SRVCC Handover Fails in the Separate Deployment Scenario.........................................................................387
3.17 Internal Tracing Logs About Subscriber Message Tracing Cannot Be Displayed...................................................389

Issue 01 (2016-12-29) Huawei Proprietary and Confidential x


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) OverviewOverview

1 Overview

This document summarizes VoLTE faults that occurred at various sites, aiming at improving
the efficiency of troubleshooting similar faults. VoLTE faults vary from site to site. All faults
mentioned in this document are used for reference only.
This document is maintained by Cui Zhaorui (ID: 00184322), who will collect fault cases in
real time or at the end of each month. At the start of each month, Cui Zhaorui will update this
document to Lin Hui (ID: 00150506).
Fault cases can be collected from the following sources:
1. China Mobile General Team (Zhang Min, the coordinator)
2. RTAC (Yi PengXiao)/GTAC (Wang Yufeng)
3. Maintenance Department's coordinator (Yang Erjie, Wu Junlin, Yang Yunyi, and Huang
Jianguo. )
4. TMO (Zhang Chao)
To ensure document quality and minimize workload, each coordinator must use the excel
form provided by Zhang Min to submit complete fault cases, rather than submitting only one
sentence as a fault case. This saves Chui Zhaorui from the painstaking efforts of clarifying
fault cases.
This document is updated monthly with new contents placed in the front.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 1


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2 Fault Cases

2.1 Fault Cases for November 2016


2.2 Fault Cases for October 2016
2.3 Fault Cases for August 2016
2.4 Fault Cases for July 2016
2.5 Fault Cases for June 2016
2.6 Fault Cases for May 2016
2.7 Fault Cases for April 2016
2.8 Fault Cases for March 2016
2.9 Fault Cases for February 2016
2.10 Fault Cases for January 2016
2.11 Fault Cases for December 2015
2.12 Fault Cases for November 2015
2.13 Fault Cases for October 2015
2.14 Fault Cases for September 2015
2.15 Fault Cases for August 2015
2.16 Fault Cases for July 2015

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 2


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.1 Fault Cases for November 2016


2.1.1 In the IMS-AKA Service, Calls Cannot Be Properly Released
Because the SBC Does Not Use the Expected SA
Basic Information
Involved NE: SBC
Involved version: SE2900 V300R001C20
Applicable scope: global
Trouble ticket number:
Troubleshooting engineer: Pan Shaohua (employee ID: 00225212)

Defect Details
In the IMS-AKA service, the SBC's security association (SA) is not aged during the
registration but it is aged during the call. Consequently, the call cannot be properly released.
Probability of Occurrence
This issue will occur when the following conditions are met.
Condition
1. The SA is changed due to the reregistration.
5. The SA is aged during a call.

Root Cause
The SBC's SA is not aged during the registration but it is aged during the call. Consequently,
the call cannot be properly released.
 An IMS subscriber is registered at 12:14:26. The UE-negotiated SA1 contains port-uc
8028 and port-us 8904. The SBC's SA1 contains port-c 9952 and port-s 9900. The
negotiated aging duration is 1 hour. That is, the SA is aged at 13:14:26.
 The IMS subscriber initiates a reregistration request at 13:04:26, and the UE-negotiated
SA2 contains port-uc 8034 and port-us 8904. The SBC's SA2 contains port-c 9953 and
port-s 9900.
 The IMS subscriber receives a call at 13:13:07, and the UE uses SA1. In this case, the
SBC's SA1 is used according to configuration data.
 The call is ended at 13:16:13. The BYE message sent by the terminating SBC contains
the aged SA1. However, the UE's SA1 is aged, and it uses SA2. Therefore, messages
containing SA1 cannot be received, and the BYE message fails to be delivered.

Troubleshooting
1. Log in to the OMU client, and open the MML Command - SE2900 window.
6. Change bit 31 of BCFPARA9 to 1 to enable the SE2900 to use a new SA for service
requests if the old SA is to be aged.
MOD SFP: INSPN=BCFPARA9, MODTYPE=P1, BIT=31, BITVAL=1;

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 3


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

7. Run the following commands to configure the number of packets to be forwarded after
IPSec AKA signaling distribution resources are deleted:
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=16, BITVAL=1;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=17, BITVAL=1;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=18, BITVAL=1;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=19, BITVAL=1;

SE2900 V300R002C00 does not support the preceding software parameters.

Reference
To obtain detailed information about SE9S00AKA00 IMS-AKA/IPSec, choose Description >
Feature Guide > Optional Features > SE9S00AKA00 IMS-AKA/IPSec in the SE2900
Product Documentation.

2.1.2 Calls Fail Because the Registration Cache Function Is


Enabled for the SE2900
Basic Information
Involved NE: SBC
Involved version: all versions of SE2900
Applicable scope: global
Trouble ticket number:
Troubleshooting engineer: Pan Shaohua (employee ID: 00225212)

Defect Details
After the registration cache function is enabled, the 200 (to REGISTER) message sent from
the SE2900 to the UE does not contain the P-Associated-URI header field. The UE uses a
temporary IMPU to initiate calls, and call failure occurs.
Probability of Occurrence
This issue will occur when the following condition is met.
Condition
The registration cache function is enabled.

Root Cause
After the registration cache function is enabled, the 200 (to REGISTER) message sent from
the SE2900 to the UE does not contain the P-Associated-URI header field. The UE uses a
temporary IMPU to initiate calls, and call failure occurs.

Troubleshooting
1. Log in to the OMU client, and open the MML Command - SE2900 window.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 4


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

8. Set BCFPARA5 to 1 to enable the SE2900 to include the P-Associated-URI header field
in the 200 (to REGISTER) message to be returned to the UE.
MOD SFP: INSPN=BCFPARA5, MODTYPE=P1, BIT=12, BITVAL=1;

2.1.3 Calling Party Cannot Hear the Called Party Due to


Inconsistent Payload Values
Basic Information
Involved NE: SBC
Involved version: all versions of SE2900
Applicable scope: global
Trouble ticket number:
Troubleshooting engineer: Pan Shaohua (employee ID: 00225212)

Defect Details
Symptom
The SDP offer sent from the calling party contains the codec payload value A, and the SDP
answer returned by the called party contains the same codec but the payload value is B. After
the call is set up, the calling party cannot hear the called party due to inconsistent payload
values.
Probability of Occurrence
This issue will occur when the following condition is met.
Condition
The codecs of the calling and called parties are the same, but the payload values are different.

Cause Analysis
1. The codec carried in the INVITE message sent from the calling party is 102 AMR, but
the codec returned by the peer end is 103 AMR.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 5


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

9. After the call is set up, the calling party checks the codec payload type and discards the
103 AMR packets. Therefore, the calling party cannot hear the called party.

Troubleshooting
10. Log in to the OMU client, and open the MML Command - SE2900 window.
11. Enable the payload-type value conversion function for the SBC.
MOD BCPLC: BCPLCNAME="xxxx", ENTYPE=ABCF, PTTRANS=Y;

2.1.4 Customized Ring Back Tone Heard by the CS Subscriber Is


Not Complete in a CS-to-VoLTE Call
Basic Information
Involved NE: MSOFTX3000
Involved version: MSOFTX3000 V200R010C20SPC100
Applicable scope: global
Trouble ticket number:
Troubleshooting engineer:

Defect Details
Symptom
When a CS subscriber calls a VoLTE subscriber who has subscribed to the CRBT service, the
customized ring back tone heard by the CS subscriber is not complete.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 6


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Probability of Occurrence
This issue will occur when the following condition is met.
Condition
The CRBT center sends an UPDATE message to the MGCF.

Cause Analysis
When a CS subscriber calls a VoLTE subscriber who has subscribed to the CRBT service, the
CRBT center sends an UPDATE message to the MGCF. If the MGCF does not convert the
UPDATE message to a 18x message and sends it to the previous NE, the customized ring
back tone is not complete. An UPDATE message can carry the P-Early-Media header field as
defined in RFC5009.

Troubleshooting
Select Supporting the P-Early-Media header field in the UPDATE message for Extra
software parameter 4 of service control.
Parameter Description
Determines whether the SIP trunk group of the MGCF supports the P-Early-Media header
field in the UPDATE message. If Supporting the P-Early-Media header field in the
UPDATE message is selected, the SIP trunk group of the MGCF supports the P-Early-Media
header field in the UPDATE message. If Supporting the P-Early-Media header field in the
UPDATE message is cleared, the SIP trunk group of the MGCF does not support the P-Early-
Media header field in the UPDATE message.

Reference
RFC5009

2.1.5 MME Disconnects Calls Because the eMSC Server Returns a


Handover Success Response Upon Receiving a 404 Message
Indicating a Handover Failure
Basic Information
Involved NE: MSOFTX3000
Involved version: MSOFTX3000 V200R011C10SPC100
Applicable scope: global
Trouble ticket number:
Troubleshooting engineer:

Defect Details
The ATCF sends a 404 message to the eMSC server, indicating that the handover fails. The
eMSC server returns an SRVCC PS TO CS COMPLETE NOTIFICATION message to the
MME, indicating a handover success. The MME disconnects the call.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 7


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Cause Analysis
After the SRVCC IST flow fails, the ATCF sends a 404 message to the eMSC server,
indicating that the handover fails. The eMSC server returns an SRVCC PS TO CS
COMPLETE NOTIFICATION message to the MME, indicating a handover success. The
MME disconnects the call.

Troubleshooting
Run MOD GTPPE with SRVCC PS to CS Complete Notification contains a cause value
indicating IST failure selected for GTP peer entity capability list. This setting enables the
eMSC server to send an SRVCC PS TO CS COMPLETE NOTIFICATION message
containing a failure cause to the MME, indicating that the IST flow fails.

Summary and Reference


N/A

2.1.6 Media Negotiation Fails Because the Clock Rate of the Codec
Used by the Call Is Different from the RFC2833 Clock Rate
Basic Information
Involved NE: MSOFTX3000
Involved version: MSOFTX3000 V200R010C20SPC100
Applicable scope: global
Trouble ticket number:
Troubleshooting engineer:

Defect Details
Symptom
The clock rate of the codec used by the call is different from the RFC2833 clock rate.
Therefore, media negotiation fails.
Probability of Occurrence
The problem occurs when the following condition is met.
Condition
The clock rate of the codec used by the call is different from the RFC2833 clock rate.

Cause Analysis
The clock rate of the codec used by the call is different from the RFC2833 clock rate. The
peer device determines that RFC2833 is not supported upon receiving the SDP information.
Therefore, media negotiation fails.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 8


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Troubleshooting
Select Sending the telephone-event codec after normalization for Extra software
parameter 5 of service control, and set bit 5 of P1509 to 0.
Parameter Description
maxptime determines whether maxptime is included when AMR-WB is preferentially used as
the codec.
 If Sending the telephone-event codec after normalization is selected, the maxptime
parameter is carried over the Mc interface and Nc interface (SIP interface) when AMR-
WB is preferentially used as the codec. The value of maxptime is set to the value of
Maxptime defined by running MOD SIPTG.
 If Sending the telephone-event codec after normalization is cleared, the maxptime
parameter is not carried over the Mc interface and Nc interface (SIP interface) when
AMR-WB is preferentially used as the codec.

Summary and Reference


N/A

2.1.7 Two More TransCoders Are Required Due to Inconsistent


maxptime Values, Causing Poor Voice Quality
Basic Information
Involved NE: MSOFTX3000
Involved version: MSOFTX3000 V200R010C20SPC100
Applicable scope: global
Trouble ticket number:
Troubleshooting engineer:

Defect Details
Symptom
Two more TransCoders are detected than expected, and voice quality deteriorates.
Probability of Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 9


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

This issue will occur when the following conditions are met.
Condition
1. A 3G subscriber calls a 4G subscriber.
2. Support transmission of maxptime for AMR-WB over SIP/Mc interface is selected for
Extra software parameter 5 of service control.

Cause Analysis
When a 3G subscriber calls a 4G subscriber, the maxptime parameter values in the media
negotiation result are inconsistent. Therefore, two more TransCoders are required for the
UMG, and voice quality deteriorates.

Troubleshooting
Clear Support transmission of maxptime for AMR-WB over SIP/Mc interface for Extra
software parameter 5 of service control.
Parameter Description
Support transmission of maxptime for AMR-WB over SIP/Mc interface determines
whether maxptime is included when AMR-WB is preferentially used as the codec.
 If Support transmission of maxptime for AMR-WB over SIP/Mc interface is
selected, the maxptime parameter is carried over the Mc and Nc interfaces (SIP
interface) when AMR-WB is preferentially used as the codec.
 If Support transmission of maxptime for AMR-WB over SIP/Mc interface is cleared,
the maxptime parameter is not carried over the Mc and Nc interfaces (SIP interface)
when AMR-WB is preferentially used as the codec.

Summary and Reference


N/A

2.1.8 Session Timer Negotiation Fails in Non-stable State


Basic Information
Involved NE: MSOFTX3000
Involved version: MSOFTX3000 V200R010C20SPC100
Applicable scope: global
Trouble ticket number:
Troubleshooting engineer:

Defect Details
Symptom
VoLTE subscriber A calls VoLTE subscriber B who has subscribed to the CRBT service. An
alerting SRVCC handover occurs during announcement playback. The session timer
negotiation fails, and the session fails.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 10


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Probability of Occurrence
This issue will occur when the following condition is met.
Condition
The session timer is negotiated in non-stable state.

Cause Analysis
VoLTE subscriber A calls VoLTE subscriber B who has subscribed to the CRBT service. An
alerting SRVCC handover occurs during announcement playback. When the eMSC server
sends an INVITE message to the ATCF to establish a bearer, the ATS sends an UPDATE
message to the eMSC server through the ATCF because the INVITE message carries the
CRBT media information. The UPDATE message contains the session-timer parameter. The
negotiation fails, and the session fails.

Troubleshooting
Set bit 3 of P1523 to 0.

Summary and Reference


N/A

2.2 Fault Cases for October 2016


2.2.1 Due to Long Period of Paging, No Tone Is Played to a Called
Party After the Called Party Answers a Call
Involved NE: all
Applicable Scope: global
Troubleshooting Engineer: Liang Yongjun (ID: 00302438)
Defect Details

Symptom UE_A and UE_B are both VoLTE subscribers. UE_B resides in an area
with poor network coverage. UE_A initiates a call to UE_B, and UE_B
answers the paging after UE_A releases the call. After UE_B answers the
call, no tone is played to UE_B.
Trouble N/A
Ticket
Number
Root Cause For this call, the calling number is +853668xxxxx and the called number is
+853663xxxxx.
The details about the first call failure are as follows:
At 13:10:23, an IMS domain is selected for the call and an INVITE
message is sent to UE_B over the IMS domain.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 11


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The Call-ID in the INVITE message is


20134s22991bb1or03rs87911b9s0pr8@10.106.128.7.
At 13:10:34, the AS does not receive a 180 message from UE_B within 10
seconds. The AS triggers a CS retry and sends an INVITE message to
UE_B over a CS domain.

At 13:10:43, UE_B does not respond, and UE_A sends a CANCEL


message to release the call.
At 13:11:10, another INVITE message is sent to UE_B. Because UE_B is
engaged in the first call (waiting for an ACK message from UE_A), UE_B
returns a 180 message carrying the call waiting (CW) indicator. The 180
message carries neither an SDP body nor the P-Early-Media header field.

At 13:11:23, UE_B does not receive an ACK message before the


transaction timer expires and sends a BYE message to the SBC. The SBC
does not find the mapping session and returns a 481 message.
At 13:11:47, UE_A sends a CANCEL message to release the second call.
How do we determine that UE_B is engaged in the first call when the
second call arrives?
The traced messages show that UE_B returns a 180 message at 13:10:54
and a 200 message at 13:11:03 in the first call. Because UE_A sends a

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 12


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

CANCEL message to cancel the first call at 13:10:43, UE_A does not
return an ACK message. The Call-ID in the INVITE message for the
second call (sent at 13:11:10) is
asbc20134s22991bb1or03rs87911b9s0pr8@10.106.128.7, which is the
same as that carried in the INVITE message for the first call (sent at
13:10:23). The same Call-ID means that the INVITE message for the
second call is a retransmitted INVITE message.

Access network configuration queried by running LST SIPAN is as


follows:

When Timeout interval for initial requests is set to 0, the SBC


retransmits an INVITE message at an interval of 1, 2, 4, 4, and 4 seconds
until the retransmission times out (32 seconds) if a called UE does not
respond.
The overall call failure procedure is as follows:
1. At 13:10:23, UE_B is in the IDLE state. After an IMS domain is
selected as the terminating access domain, the SBC receives an INVITE
message and sends it to the UGW. The UGW sends a DDN message
instructing the MME to page UE_B. The MME then instructs the
eNodeB to page UE_B. However, UE_B does not answer the paging.
2. At 13:10:33, the SBC receives a CANCEL message from the CSCF
(because a CS retry is triggered). The SBC does not stop the message
retransmission. The retransmission lasts for 32 seconds. In addition, the
S-GW buffers the data for 3 to 6 seconds.
3. At 13:10:53, UE_B answers the paging. The eNodeB notifies the MME,
which then notifies the S-GW. The S-GW sends the INVITE message to

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 13


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

UE_B through the eNodeB.


4. UE_B receives the INVITE message, sends 100, 180, and 200 messages
in sequence, and waits for an ACK message.
For UE_A, user experience is as follows:
 From 13:10:23 to 13:10:43, "Calling..." is displayed on UE_A, but no
tone is played.
 From 13:11:10 to 13:11:47, "Ringing..." is displayed on UE_A. Two
cases are possible: First, UE_A plays a common ring back tone when
receiving a 180 message that does not carry an SDP body or the P-
Early-Media header field, as instructed in the SIP protocol. Second,
UE_A may play a CW tone or does not play any tone when receiving
the CW indicator. The second case is rare.
For UE_B, user experience is as follows:
 From 13:10:23 to 13:10:53, no information is displayed on UE_B.
 From 13:10:53 to 13:11:03, UE_B receives an INVITE message and is
alerted.
 From 13:11:10 to 13:11:47, UE_B receives the second call and returns a
180 message carrying the CW indicator.
 From 13:10:03 to 13:11:23, UE_B answers the call, but no tone is played.
 At 13:11:23, UE_B releases the call.
Condition  A called UE resides in an area with poor network coverage.
 An IMS network is selected. The called UE answers paging after the
SBC receives a CANCEL message from the SCC AS.
 The Precondition function is disabled.
Probability This issue may occur when the preceding conditions are met.
of
Occurrence

Involved Version
VoLTE V500R005C00
Solution
Workarounds:
Change the duration of the transaction timer on the SBC to 6 seconds.

It is recommended that the duration of the transaction timer on the SBC plus 3 seconds is less than the
duration of the CS retry timer on the SCC AS.

INITREQTM Timeout interval for initial This parameter specifies the timeout
requests(s) interval for unsolicited initial requests
(OPTIONS, MESSAGE, SUBSCRIBE,
REFER, PUBLISH, and INVITE) sent
to the access network.
Value range: 0-32
Default value: 0

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 14


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

When setting this parameter, note the


following:
 This parameter is displayed only
when Logical entity type is set to
P-CSCF(P-CSCF).
 When this parameter is set to 0, this
parameter does not take effect and
the SBC uses the timeout interval
defined in SIP.
 You are advised to set this parameter
to 6 in VoLTE scenarios to decrease
the number of retransmitted
requests.

Preventive measures:
When receiving a CANCEL message from the core network, the terminating SBC stops
sending an INVITE message to the access network. This measure is planned to be
implemented in VoLTE V500R005C10.

2.2.2 Calls from VoLTE Subscribers to Local Fixed-Line


Subscribers Fail After an eSRVCC Handover
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer:
Defect Details

Symptom UE_A (a VoLTE subscriber) initiates a call to UE_B. After the call is
connected, UE_A initiates an eSRVCC handover. Then UE_A places the
call with UE_B on hold and initiates a call to UE_C (a fixed-line
subscriber). The call to UE_C fails, and an announcement is played, stating
that the dialed number is invalid. (The call is successful if the called party
is a CSFB or VoLTE subscriber.)
Trouble N/A
Ticket
Number
Root Cause After the eSRVCC handover, UE_A is connected to the eMSC. The eMSC
sends a MAP UPDATE LOCATION REQ message to the convergent
HLR/HSS for a location update. In this case, if UE_A initiates a new call,
the call request is processed by the eMSC.
The following figure shows the location update flow triggered by the
eMSC:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 15


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

When UE_A initiates a call to UE_C by dialing UE_C's number alone, the
VMSC server has not initiated a location update and therefore does not
store UE_C's subscriber data. As a result, the VMSC server does not prefix
UE_C's number with the local area code. Instead, it transparently transmits
the call request to the eMSC.
The following figure shows the call request transparently transmitted from
the VMSC server to the eMSC:

The eMSC, which processes all calls in the entire province, does not add an
area code to UE_C's number either. The eMSC forwards the call request to
the CMN by sending an IAM message.

The CMN detects that the called number is not prefixed with an area code
and sends an REL message carrying the cause value unassigned-number to
release the call.

When a VoLTE subscriber, after being handed over to a 2G network, places


an ongoing call on hold and initiates a call to a fixed-line number (without
dialing the area code), the new call always fails. In addition, the eMSC is
responsible for generating CDRs in such a scenario. The billing center can

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 16


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

associate the ID of the eMSC server and therefore cannot identify whether
a call is a local or toll call.
Condition  An FMC network is deployed.
 An IDP message is sent to trigger an O-CSI service for a VoLTE
subscriber.
 The O-CSI and SMS services have been subscribed to for the subscriber
by running ADD MSR or MOD MSR.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C20
Solution
Workarounds:
N/A
Preventive measures:
It is update to the carrier whether a patch needs to be developed to enable the eMSC server to
add an area code to a dialed number or whether end users are required to dial an area code
before a fixed-line number.

2.2.3 Triggering the MCN Service Fails When the HSS Does Not
Block an IMPU in IMSI Format
Involved NE: HSS9860
Applicable Scope: global
Troubleshooting Engineer:
Defect Details

Symptom UE_A is a VoLTE subscriber and has subscribed to the Miss Call Notify
(MCN) service. After UE_A enables the airplane mode, UE_B initiates a
call to UE_A and receives an announcement played by the MCN service
platform. After UE_A disables the airplane mode and accesses the VoLTE
network, no short message is sent to UE_A to indicate the missed call.
Trouble N/A
Ticket
Number
Root Cause Check the messages traced on the ATS. When UE_A is called, the ATS
receives an INVITE message and then a 480 message.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 17


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The ATS sends an INVITE message to the MCN service platform.

The INVITE message carries the History-Info header field, which is set to
the original called number, an IMPU in IMSI format. The MGCF converts
the INVITE message to an IAM message and sends the IAM message to
the MCN service platform. The MCN service platform does not store the
mapping between the IMSI and MSISDN. As a result, the MCN service
platform does not know to which number it should send a short message.
Why does the ATS include an IMPU in IMSI format into the INVITE
message?
The traced messages show that the HSS does not block the IMPU in IMSI
format. In the SAA message sent over the Cx interface, the
BarringIndication field is set to 0, indicating that the blocking function is
disabled.

After the subscription data on the HSS is modified by blocking the IMPU
in IMSI format, the ATS includes the original called number in the correct
format into the INVITE message, and UE_A successfully receives a short
message indicating the missed call.
The root cause is as follows: The HSS does not block the IMPU in IMSI
format. Consequently, the ATS sends this IMPU to the MCN service
platform, and the MCN service platform cannot identify the IMPU and
does not send a short message to indicate the missed call.
Condition The HSS does not block IMPUs in IMSI format.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
HSS9860 V900R008C50

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 18


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Solution
Workarounds:
N/A
Preventive measures:
Modify the subscription data on the HSS by blocking IMPUs in IMSI format.

2.2.4 Conference Call Fails After Adding a Participant to the


Conference Fails (Occurring Only for iPhones)
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer:
Defect Details

Symptom A conference call is established for UE_A, UE_B, and UE_C, where UE_A
is the chairperson. UE_A forces UE_B to leave the conference, initiates a
new call to UE_B, and then merges the new call with the previous one. A
message is displayed, indicating that the merging fails. The call is released,
and UE_A starts to search for signals and register with the network. (This
issue occurs when UE_A uses an iPhone 6. It does not occur if UE_A uses
a Mate 8.)
Trouble N/A
Ticket
Number
Root Cause At 14:59:53, a conference call is established. Two REFER messages are
sent to invite UE_B and UE_C to the conference.

At 14:59:59, UE_A sends a REFER message to remove UE_B from the


conference.

At 15:00:19, UE_A initiates a new call to UE_B and places the conference

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 19


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

call on hold.
At 15:00:31, UE_A merges the two calls. However, an INVITE message
used to place UE_C on hold is sent, but a REFER message used to invite
UE_C to the new conference is not sent.

When the chairperson who uses an iPhone does not send a REFER message
to invite a subscriber to a conference but sends an INVITE message to
place the subscriber on hold, no 4G signals are displayed on the iPhone.
The traced messages on the SBC show that the bearer of the iPhone is
released, causing the ongoing calls to fail.
When the chairperson uses a Mate 8, a REFER message is sent to invite a
subscriber to a conference.
Condition An iPhone subscriber forces a subscriber to leave a conference, invites the
subscriber again, and merges the new call with the previous one.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
iPhone
Solution
Workarounds:
N/A
Preventive measures:
This issue occurs because the iPhone does not send a REFER message when inviting a
subscriber to a conference, which is not protocol complaint. The iPhone must be rectified to
resolve the issue.

2.2.5 Calls to VoLTE Subscribers Fail After They Are Handed


Over to a 2G Network Because of Defective PSI Procedure on the
eMSC
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 20


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Defect Details

Symptom UE_A and UE_B are on a voice call and then both are handed over to a 2G
network. UE_C initiates a call to UE_A. UE_A places the call with UE_B
on hold and answers the call from UE_C. The call is connected for about 5
seconds and is then automatically released.
Trouble N/A
Ticket
Number
Root Cause After the call with UE_B is connected, UE_A initiates an eSRVCC
handover. After UE_A is handed over to a 2G network, UE_C initiates a
call to UE_A. When UE_A answers the call, a 200 message is sent to the
BGCF through the MGCF. The MGCF does not receive an ACK message
and retransmits the 200 message for another four times (lasting for 5
seconds). The MGCF does not receive any ACK message in response to the
retransmitted 200 message and therefore sends a BYE message.

After the ATS receives the 200 message, the ATS sends a UDR message to
the HSS to query UE_A's location information (at 17:02:39). Five seconds
later (at 17:02:44), the HSS returns a UDA message.

The HSS sends a PSI message to the eMSC to obtain UE_A's location
information and the eMSC responds after 5 seconds.

Consequently, the HSS returns the information to the ATS 5 seconds after
receiving the UDR message. The call on the MGCF times out and is
therefore released.

The eMSC is defective when processing a PSI message received after a


connection is established. The internal processing error causes the eMSC to
respond to the PSI message after the timer (with the duration set to 5
seconds) expires. In addition, the PSI_ACK message carries subscriber

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 21


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

location information stored previously, rather than real-time location


information.
Condition A call is addressed to a subscriber after the subscriber is handed over to a
2G network.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C20
Solution
Workarounds:
Change the duration of the timer on the eMSC to 3 seconds.
MOD TIMER: MPID=PID223, TMRIDX=0, TMRSEQ=20, TMRVAL=3;
Preventive measures:
A patch will be released to resolve the issue.

2.2.6 After Calling Parties Are Handed Over to a 2G Network,


Their New Calls to VoLTE Subscribers Are Fallen Back
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer:
Defect Details

Symptom UE_A and UE_C are both VoLTE subscribers. When UE_A is on a call
with UE_B, an eSRVCC handover is triggered. Then UE_A initiates a call
to UE_C. UE_C is not alerted when an IMS domain is selected as the
terminating access network. After a CSFB is triggered, the call to UE_C is
connected.
Trouble N/A
Ticket
Number
Root Cause The networking is as follows: eMSC -------- STP -------- Anchor AS
After UE_A is handed over to a 2G network, UE_A initiates a location
update and its call is processed by the eMSC.
The eMSC queries the T-CSI from the HSS and sends a message to the
anchor AS through the STP to obtain an anchoring prefix. The anchor AS
returns an anchoring prefix but the eMSC fails to receive it.
This is because the STP does not forward the CONNECT message sent
from the anchor AS to the eMSC.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 22


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The following figure shows the message sent by the eMSC to obtain an
anchoring prefix:

The following figure shows that the message sent by the anchor AS carries
an anchoring prefix (the message does not reach the eMSC). This message
can be traced by creating an SCCP-layer GT tracing task on the eMSC and
anchor AS.

The following figure shows that the eMSC server does not receive the
CONNECT message at the SCCP layer:

The eMSC does not receive the anchoring prefix. After the relevant timer
expires, the eMSC triggers the procedure to obtain UE_C's CSRN. After
obtaining the CSRN, the eMSC routes the call request to the CMN and
connects the call over a CS domain. As a result, UE_C falls back to a 2G
network.
The STP does not forward the CONNECT message to the eMSC, because
the eMSC returns an error.
Condition The CAP subsystem of the eMSC is not configured.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C20
Solution
Workarounds:
N/A
Preventive measures:
Add the CAP subsystem for the eMSC.
ADD SCCPSSN: SSNNM="XXX", NI=NAT, SSN=CAP, SPC="XXX", OPC="XXX",
RELSSN1=UNDEF, RELSSN2=UNDEF, RELSSN3=UNDEF, RELSSN4=UNDEF,
RELSSN5=UNDEF, INCGT=YES, MOG="PUBLIC";

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 23


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.2.7 CFB Service Fails to Be Triggered for a VoLTE Subscriber on


a 2G Network Because the ACM Message Sent from the VMSC
Server Does Not Carry a Cause Value
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer:
Defect Details

Symptom UE_A and UE_B are both VoLTE subscribers. UE_A resides on an LTE
network, and UE_B resides on a 2G network. UE_B has subscribed to the
Call Forwarding Busy (CFB) service, with the forwarded-to party set to
UE_C.
When UE_B is engaged in another call, a call from UE_A to UE_B fails to
be forwarded. Specifically, no ring back tone is displayed. After a period of
time, the call is automatically released or an announcement is played,
stating that the called party is powered off.
Trouble N/A
Ticket
Number
Root Cause The networking is as follows: VMSC server (Huawei) --- MGCF (ZTE) ---
IMS (Huawei)
Messages from the IMS domain show that: When a CS domain is selected
as the terminating access domain for the call, the CSCF receives a 480
message from the MGCF, which then forwards the message to the ATS.
The ATS triggers the CFB service only after receiving a 486 message.
Therefore, the CFB service is not triggered when the ATS receives the 480
message.

Messages from the VMSC server show that: UE_B initiates a call to a
special service number before receiving the call from UE_A. The MGCF
converts the INVITE message from the IMS network to an IAM message
and sends the IAM message to the VMSC server. The VMSC server
responds with an ACM message.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 24


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The ACM message does not carry the BUSY indicator, because the ACM
message sent from the VMSC server to the ACM does not carry a cause
value. Therefore, the MGCF converts the ACM message to a 480 message
and sends the 480 message to the ATS.

In the office direction data queried by running LST OFC


BOFFICEPARA, ACM With Cause is not selected for Office Param.
After ACM With Cause is selected, the ACM message sent from the
VMSC server carries an abnormal announcement cause value. The MGCF
coverts this ACM message to a 486 message. When the ATS receives the
486 message, it triggers the CFB service.
The root cause is as follows:
The ACM message sent from the VMSC server does not carry a cause
value. The MGCF converts this ACM message to a 480 message and sends
the 480 message to the IMS domain. When receiving the 480 message, the
ATS determines that UE_B is not in the busy state and therefore does not
trigger the CFB service.
Condition ACM messages sent from the VMSC server to the MGCF do not carry a
cause value.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C20
Solution
Workarounds:
N/A
Preventive measures:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 25


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Run MOD OFC to select ACM With Cause for Office Param so that ACM messages sent
from the VMSC server carry a cause value.

2.2.8 Incorrect Call End Time Is Recorded in ACRs After the


Bearer Release Timer Expires
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer:
Defect Details

Symptom The call end time recorded in a final call detail record (CDR) is more than
30 seconds later than the actual call end time.
Traced messages on the SmartCare show that at 01:39:45, a BYE
message is sent to the originating ATS. At 01:39:48, the originating ATS
receives a new call (with the same calling and called parties). The
originating ATS sends a BYE message to the terminating network to
release the first call. In the final CDR generated for the first call, the call
end time is 01:40:14.
Trouble Ticket N/A
Number
Root Cause The BYE message sent at 01:39:45 carries the Reason header field, with
the cause value set to 503. The ATS determines that the BYE message is
caused by bearer release.
Reason:
SIP;cause=503;text="03077.08574.A.005.404.228.0.0.00060.00000000
Bearer Released"
Therefore, the ATS starts the bearer release timer with the duration set to
8 seconds. This timer enables the ATS to release the call and generate an
ACR [Stop] message upon the timer expiry.
The ATS receives the new call 3 seconds after it starts the timer. Because
the ATS is configured to check active calls of a subscriber when a new
call is addressed to the subscriber, the ATS releases the first call without
waiting for the timer expiry. However, the ATS does not send an ACR
[Stop] message when it releases the call.

Instead, the ATS sends an ACR [Stop] message after the transaction timer
(with the duration set to 34 seconds) expires. In this message, the call end
time is the time when the message is sent minus 8 seconds.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 26


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The timestamps for important events are listed as follows:


 200 (to INVITE): 01:39:11
 BYE (bearer release): 01:39:45 (the actual call end time)
 New INVITE: 01:39:48
 Transaction timer expiry: 01:40:22 (sending of the ACR [Stop]
message)
 Call end time in ACR [Stop]: 01:40:14 (01:40:22 minus 8 seconds)
Difference between the charged call end time and the actual call end time
= Duration from the start of the bearer release timer to the receipt of the
second INVITE message + (Duration of the transaction timer - Duration
of the bearer release timer) = x + (34 - 8) = x + 26
Because x is greater than 0 but less than 8, the difference falls within the
range between 26 and 34.
Condition  The ATS is configured to check active calls of a subscriber when a new
call is addressed to the subscriber.
 The bearer of the first call is released.
 The second call arrives within 8 seconds after the bearer release.
Probability of This issue will occur when the preceding conditions are met.
Occurrence

Involved Version
ATS9900 V100R008C20SPC100
Solution
Workarounds:
Run MOD BCCFG to deselect CHKWHENMO(Check current call during new MO call
setup) and CHKWHENMT(Check current call during new MT call setup) for Check
current call during new call setup. The configuration enables the ATS not to check active
calls of a subscriber when a new call is addressed to the subscriber.

Impact of the workaround: The ATS will send a 486 message to reject the second call.
Consequently, the call completion rate slightly decreases.
Preventive measures:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 27


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Optimize the function provided by Check current call during new call setup. In the case of
bearer release, if the ATS needs to release the first call when receiving a new call request, the
ATS sends an ACR [Stop] message immediately. This optimization ensures the correct call
end time recorded in final CDRs.
This measure will be resolved in the ATS9900 V100R008C20SPH106 patch.

2.2.9 Measurement Result of Diameter Success But Data Not Exist


Sharply Increases After Some Subscribers Are Migrated from
HSS1 to HSS2
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer: Wu Junlin (ID: 00365955) and Li Yong (ID: 00380413)
Defect Details

Symptom After some subscribers are migrated from HSS1 to HSS2, the measurement
result of the measurement entity Diameter Success But Data Not Exist in
the measurement unit ATS SH Interface Measurement sharply increases.
Trouble N/A
Ticket
Number
Root Cause The ATS is connected to the HSS through the DRA.
Obtaining location information about migrated subscribers over the Sh
interface fails. The cause is as follows:
The ATS uses MSISDNs to obtain location information. However, the DRA
is configured with routing data for these subscribers' IMSIs, but not for
their MSISDNs. Consequently, UDR messages used to obtain the location
information are sent to HSS1, causing the failure in obtaining the location
information.

Condition  The ATS is connected to the HSS through the DRA.


 The ATS is configured to use UDR messages and MSISDNs to obtain
subscriber location information. The following figure is command
output for LST HSSCFG:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 28


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

 For subscribers migrated from HSS1 to HSS2, no routing data is


configured for their MSISDNs on the DRA.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V200R011C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Configure routing data for MSISDNs on the DRA, with the destination pointed to the HSS to
which subscribers are migrated.

2.2.10 No Ring Back Tone Is Played After the ATS Triggers the
CFNRY Service
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer: Wang Linlin (ID: 00284077)
Defect Details

Symptom UE_A is a VoLTE or CS subscriber, UE_B is a VoLTE subscriber who has


subscribed to the CFNRY service, and UE_C is a VoLTE or VoBB
subscribers. When UE_A initiates a call to UE_B and UE_B does not
answer the call, the call is forwarded to UE_C. However, after the call is
forwarded, no ring back tone is played to UE_A.
Trouble N/A
Ticket
Number
Root Cause The INVITE message sent to UE_C does not carry an SDP body, and

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 29


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

UE_C returns a 180 message that carries an SDP body. The SBC adds the
P-Early-Media header field (with the value set to gated) to the 180
message and sends the message to ATS_C. ATS_C transparently transmits
the 180 message to ATS_B, and ATS_B converts the 180 message to an
UPDATE message for media renegotiation. The 180 message disappears,
and no device plays a ring back tone during this process.
Condition After media negotiation is complete, a 180 message carrying an SDP body
is returned.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
ATS9900 V100R008C10SPC100 or V100R008C20SPC100
Solution
Workarounds:
N/A
Preventive measures:
 If the 180 message does not carry the P-Early-Media header field or carries the P-Early-
Media header field with an invalid value, set P2323 to 1:
MOD SFP: SPID=2323, VAL=1;
 If the 180 message does not carry Require:precondition, set P2323 to 2:
MOD SFP: SPID=2323, VAL=2;

2.2.11 Calls Addressed to VoLTE Subscribers Served by NSN


HSS May Fail
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom After subscribers whose data is stored on NSN HSS have subscribed to
VoLTE services, some calls addressed to them fail.
Trouble N/A
Ticket
Number
Root Cause Messages traced on the SEQ show that the IMS registration status obtained
by the SCC AS from the HSS is 2, indicating that the subscriber is not
registered with the IMS domain. After the SCC AS downloads the
subscriber data, it uses the CS domain as the terminating access domain
and obtains a CSRN from the HSS.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 30


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

After the SCC AS sends a UDR message to obtain the CSRN (at 07:55:30),
the HSS does not return a UDA message. The relevant timer expires on the
SCC AS (at 07:55:38).

The message traced on the SCC AS show that the SCC AS, after the 8-
second timer expires, returns a 480 message.

The HSS obtains the CSRN from the CS network. Due to a software defect,
the HSS does not return the CSRN to the SCC AS, causing the call failure.
Condition NSN HSS does not return a CSRN to the SCC AS.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
Solution
Workarounds:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 31


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

N/A
Preventive measures:
NSN HSS must be rectified to resolve the issue.

2.2.12 eSRVCC Handover Success Rate Decreases by 5% Because


ALM-10828 Is Not Cleared as Instructed
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting Engineer: Chen Tao (ID: 00342064)
Defect Details

Symptom A fiber is disconnected, adversely affecting VoLTE services. After the fiber
is reconnected, the eSRVCC handover success rate decreases from 93% to
88%.

Trouble 6303633
Ticket
Number
Root Cause 5. SIP messages exchanged between the ATCF and eMSC are traced on
the SBC. The decrease in the eSRVCC handover success rate is as
follows: The ATCF receives an INVITE message from the eMSC for an
eSRVCC handover of a subscriber. Because the subscriber is not
registered with the ATCF, the ATCF returns a 404 message, in which the
Warning header field is set to Init Invite from EMSC Not Found
Former Call. The handover fails. In a word, the INVITE message used
for an eSRVCC handover is sent to an incorrect ATCF.
6. During the fiber disconnection, ALM-10828 High Rate of SIP Request
Retransmission is generated on two CSCFs. The alarm is manually
cleared, without following the instructions provided in the online help.
Consequently, a small proportion of subscribers is registered with two
ATSs simultaneously, causing the decrease in the eSRVCC handover
success rate.
--------------------------------------------------------------------
The alarm details are as follows:
 At 20:04:48 on June 10, ALM-10828 High Rate of SIP Request

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 32


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Retransmission was generated on the I-CSCF at the JD site. The peer of


the I-CSCF in the alarm information was the S-CSCF at the RY site.
The alarm was manually cleared at 06:54:59 in June 11.
 At 21:18:06 in May 29, ALM-10828 High Rate of SIP Request
Retransmission was generated on the I-CSCF at the RY site. The peer of
the I-CSCF in the alarm information was the S-CSCF at the JD site. The
alarm was manually cleared at 00:20:45 in May 30.

Though the alarms are cleared, the faults are not rectified. As a result,
REGISTER messages are not sent to the S-CSCF at the other site through
the I-CSCF. Consequently, some subscribers are registered with both ATSs,
causing the decrease in the eSRVCC handover success rate.

The details are as follows:


7. When receiving a REGISTER message from a subscriber at the JD site,
the ATS sends STN-SR 888888 to the HSS.
8. When receiving a REGISTER message from the subscriber at the RY
site, the I-CSCF queries the HSS and detects that the subscriber is
registered with the S-CSCF at the JD site. Therefore, the I-CSCF
attempts to send the REGISTER message to the S-CSCF at the JD site.
Because the connection between the I-CSCF and the S-CSCF at the JD
site is abnormal, the I-CSCF reselects the local S-CSCF. The ATS sends
STN-SR 888999 to the HSS.
9. When the subscriber moves back to the JD site and initiates a
registration, the ATS still uses the subscriber data stored in the previous
registration. The STN-SR is not changed. The ATS does not send STN-
SR 888888 to the HSS. Therefore, the STN-SR stored on the HSS is
888999.
10. When the subscriber initiates a call at the JD site and an eSRVCC
handover occurs during the call, the MME sends a PS to CS Request
message carrying STN-SR 888999 to the eMSC. The eMSC sends an

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 33


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

INVITE message to the SBC at the RY site for the eSRVCC handover.
However, the call to be handed over is not at the RY site. Therefore, the
SBC sends a 404 message to reject the request.
Condition  On a VoLTE network, the S-CSCF preferentially selects the local ATS.
Alternatively, the following situation occurs: After a subscriber registers
with the ATS, the IP network between the S-CSCF and ATS is faulty.
Then the subscriber registers with another ATS, and the IP network is
restored. Finally, the subscriber registers with the first ATS.
 ALM-10828 High Rate of SIP Request Retransmission is generated on
the CSCFs at both sites, and the alarm is manually cleared, rather than
by following the instructions provided in the online help.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
CSC3300 V100R011C10SPC100
Solution
Preventive measures:
Run RCV SIPPEER on the CSCFs at both sites to clear the alarm.

2.2.13 CPU Overload Alarms Are Generated for USRSU Boards on


the DRA Because Low-end VoLTE UEs Initiate a Large Number
of PDN Connection and Disconnection Requests
Involved NE: SPS, UGW9811, and USN9810
Applicable Scope: global
Troubleshooting Engineer: Chen Tao (ID: 00342064)
Defect Details

Symptom CPU overload alarms are generated for USRSU boards on two DRAs.
Trouble 6813188
Ticket
Number
Root Cause The issue is as follows:
At 00:43, subscriber data is removed on the UGW. UEs initiate a large
number of PDN connection and disconnection events within a short period
of time. The number of Gx interface messages between the P-GW and
DRA sharply increases, causing CPU overload alarms on the DRA.
The details are as follows:
11. CPU overload is caused by the burst of CCR-I and CCR-T message sent
from the P-GW.
12. PS CDRs obtained from the SEQ database show that the burst of CCR-I

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 34


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

and CCR-T messages occurs after the removal of subscriber data. The
UEs initiate a large number of PDN connection requests in a short
period of time. After the connections are established, the UEs initiate
PDN disconnection requests, causing the increase of the Gx interface
messages.
13. From 00:45 to 00:55, a single UE initiates 4500 PDN connection and
disconnection requests at most. Such a UE is a low-end smartphone.
14. No IMS registration requests are initiated during the period of PDN
connection and disconnection. No message burst occurs on the SBC,
CSCF, and HSS, and the number of initial registration requests, re-
registration requests, and deregistration requests, and the registration
success rate remain stable.
Condition  The IMS APN is deactivated on the UGW.
 Low-end VoLTE UEs are used.
Probability This issue may occur when the preceding conditions are met.
of
Occurrence

Involved Version
 SPS V300R007C10SPC200
 UGW9811 V900R010C05SPC300
 USN9810 V900R012C05SPC300
Solution
Workaround:
Enable the S1 signaling suppression on the USN (MME). To do so, perform the following
operations:
Step 1 Enable the license used for signaling suppression.
SET LICCTRL: PN="82205492", SWITCH=ON;

If this license is unavailable at your site, apply for it.

Step 2 Adjust the suppression threshold.


SET S1SMARTPARA: ATTACHTHRESH=1000, SRVREQTHRESH=1000,
PDNCONNTHRESH=1000;

Set the threshold based on site requirements.

Step 3 Add the suppression behavior for UEs.


ADD S1SMARTRULE: UETYPE=UNKNOWN_TYPE,
ATTACHCTRLRULE=SPECCAUSEREJ-1&PARKAPNACT-0&DISCARD-1,
SRVREQCTRLRULE=SPECCAUSEREJ-1&CNDETACH-0,
PDNCONNCTRLRULE=SPECCAUSEREJ-1&PARKAPNACT-0&CNDETACH-1,
PDNCONNREJCAUSE=MULTI_PDN_FOR_APN_NOT_ALLOWED,
DETACHCAUSE=PROTOCOL_ERROR_UNSPEC;

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 35


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

----End

Preventive measures:
The abnormal behavior of these low-end UEs is uncontrollable. Carriers need to work
together on resolving this issue.

2.3 Fault Cases for August 2016


2.3.1 During Implementation of the IN SMS Service, the ATS9900
Does Not Support Use of the Location Information IE of the IDP
Message to Carry ECGI Information
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom During the implementation of the IN SMS service, when the MESSAGE
message from the MO side and the P-Access-Network-Information header
field of the registration message do not contain the network-provided
parameter, the ATS9900 does not support use of the location information IE
of the IDP message to carry ECGI information.
Trouble N/A
Ticket
Number
Root Cause In the preceding scenario, the ATS9900 does not support use of the location
information IE of the IDP message to carry ECGI information.
Condition  FMC networks are deployed.
 An O-CSI IDP message is triggered by a VoLTE subscriber.
 The O-CSI and SMS services have been enabled for the subscriber by
running ADD MSR or MOD MSR.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R008C20SPC100
Solution
Workarounds
N/A

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 36


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Preventive Measures
Install the ATS9900 V100R008C20SPH102 patch. After the installation:
 The MML configuration is modified by running MOD SMSCTL:
SMSPARA=SM_SUPPORT_E-CGI, VAL=1, ECGIRM=HSS;.
 Software parameter 2080 is used. When software parameter 2080 is set to 1, the
ATS9900 obtains ECGI information from the HSS and includes it in the location
information IE of the IDP message.
 Software parameter 2081 is used. When software parameter 2081 is set to 1, the
ATS9900 does not include the ECGI IE in the message sent to the SMSC.

2.3.2 Call Forwarding Service Cannot Be Triggered When the


History-Info Header Field of the INVITE Message Received by
the ATS9900 Contains the Privacy Parameter
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom When the Privacy parameter value length of the History-Info header field
of the INVITE message received by the ATS9900 is 4 or a multiple of 4,
the ATS9900 converts the History-Info header field to a Diversion header
field. However, the Privacy parameter in the Diversion header field is
displayed as garbled characters, causing a failure in triggering the call
forwarding service.
Trouble N/A
Ticket
Number
Root Cause The ATS9900 encounters an internal defect.
Condition  FMC networks are deployed.
 A call forwarding service has been enabled for the subscriber by running
ADD MSR or MOD MSR.
 SFPARA has been set to SEND_DIVERSION-1 by running MOD
SIPCFG on the ATS9900.
 The Privacy parameter value of the History-Info header field of the
INVITE message received by the ATS9900 is none or user.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R008C20SPC100
Solution

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 37


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R008C20SPH102 patch.

2.3.3 After the Terminating SCC AS Triggers CS Retry, the Call Is


Connected but the Calling and Called Parties Cannot Talk with
Each Other
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom When the terminating SCC AS receives a 503 message (indicating bearer
loss) during resource reservation, it triggers CS Retry. However, after the
call is connected, the calling and called parties cannot talk with each other.
Trouble N/A
Ticket
Number
Root Cause When the terminating SCC AS triggers CS Retry, it receives an UPDATE
message from the originating side and returns a 200 (to UPDATE) message
in which the media port is 0. The calling UE does not support processing of
media information whose media port is 0 before the call is connected.
Consequently, after the call is connected, media information cannot be
updated and the calling and called parties cannot talk with each other.
Condition  FMC networks are deployed.
 CS Retry Switch has been set to ON(ON), CS Retry Switch After 183
has been set to YES(YES), and CS Retry Trigger Code After 183 has
been set to SIP503(SIP STATUS CODE 503 SERVICE
UNAVAILABLE) by running MOD CSRETRYCFG on the
terminating SCC AS.
 The terminating SCC AS receives a 503 message (indicating bearer loss)
during resource reservation. When it triggers CS Retry, it receives an
UPDATE message from the originating side.
 The calling UE does not support processing of media information in
which the media port is 0 before the call is connected.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the ATS9900

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 38


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Solution
Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R008C20SPH102 patch.
After the installation, software parameter 3396 is used to determine whether the ATS9900 sets
the media port to 0 or set the media direction to inactive for the 200 (to UPDATE) message
returned to the calling UE when the following conditions are met:
 The terminating SCC AS receives a 503 message (indicating bearer loss) during resource
reservation. When it triggers CS Retry, it receives an UPDATE message from the
originating side.
 The terminating MMTel AS fails to initiate a call as resource reservation is incomplete.
Then, it receives the UPDATE message from the originating side when playing an
announcement to the originating side.

2.3.4 Timestamps in ACR Messages Sent by the ATS9900 Are


Incorrect When the Bearer Is Lost
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom VoLTE subscriber A calls VoLTE subscriber B. The originating ATS9900


receives a 200 (to INVITE) message from B and a CANCEL message
carrying the cause value 503 (indicating bearer loss) from A almost at the
same time. Then, the ATS9900 sends an ACR [Start] message to the CCF
and starts a bearer loss timer (T_229_0_16_Timer for Waiting for an
SRVCC or eSRVCC Switchover After Bearer Loss). When this timer
expires, the ATS9900 sends an ACR [Stop] message to the CCF. There is a
low probability that SIP-Response-Timestamp in the ACR [Stop] message
is earlier than that in the ACR [Start] message.
Trouble N/A
Ticket
Number
Root Cause The ATS9900 encounters an internal defect.
Condition  FMC networks are deployed.
 The originating ATS9900 receives a 200 (to INVITE) message from the
called party and a CANCEL message carrying the cause value 503
(indicating bearer loss) from the calling party almost at the same time.
Probability There is a low probability that this issue will occur when the preceding
of conditions are met.
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 39


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
All versions of the ATS9900
Solution
Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R008C20SPH102 patch.

2.3.5 Contact Header Field of the NOTIFY Message Sent by the


ATS9900 Does Not Carry the Conference URI, Causing a Failure
in Inviting New Subscribers to the Conference
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom When a conference service party creates a conference, the Contact header
field of the NOTIFY message sent by the ATS9900 does not carry the
conference URI. Consequently, the conference service party cannot obtain
the conference URI to invite new subscribers to the conference.
Trouble N/A
Ticket
Number
Root Cause The ATS9900 encounters an internal defect.
Condition  FMC networks are deployed.
 The CSCF address in the Route header field of the INVITE message used
for creating a conference is in domain name format.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the ATS9900
Solution
Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R008C20SPH102 patch.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 40


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

After the installation, software parameter 2037 is used to determine whether the Contact
header field of the NOTIFY message sent by the ATS9900 carries the Conference URI and
isFocus parameters during creation of a conference.

2.3.6 After Call permitted with insufficient bandwidth Is Set to


Y(Yes), the SE2900 Does Not Return a 488 Message When
Required Bandwidth Resources in the INVITE Message Sent by
the Core Side Are Insufficient
Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom Call permitted with insufficient bandwidth has been set to Y(Yes) by
running ADD BCPLC for the called UE's SIPAN or PBX-type ISIPTG.
When required bandwidth resources in the INVITE message sent by the
core side are insufficient, the SE2900 returns a 503 message, not a 488
message returned by the SE2600.
Trouble N/A
Ticket
Number
Root Cause When required bandwidth resources in the INVITE message sent by the
core side are insufficient, the SE2900 returns a 503 message rather than
determining whether Call permitted with insufficient bandwidth is set to
Y(Yes).
Condition  Call permitted with insufficient bandwidth has been set to Y(Yes) by
running ADD BCPLC for the called UE's SIPAN or PBX-type ISIPTG.
 The CAC bandwidth restriction function has been enabled.
 Required bandwidth resources in the INVITE message sent by the core
side are insufficient.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the SE2900
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R002C00SPH216 patch.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 41


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

When required bandwidth resources in the INVITE message sent by the core side are
insufficient, the SE2900 returns a 488 message if finding that Call permitted with
insufficient bandwidth is set to Y(Yes). Otherwise, the SE2900 returns a 503 message.

2.3.7 Held Party Cannot Hear an Announcement


Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom The held party cannot hear an announcement.


Trouble N/A
Ticket
Number
Root Cause The SE2900 performs media bypass for the call between subscribers
connected to the same NAT device. When the call is held, the media bypass
status is changed. As a result, the SE2900 needs to perform media latching
again. However, as the held UE no longer sends packets, the SE2900
cannot obtain the NAT device's address to forward packets to the NAT
device.
Condition  The calling and called parties are connected to the same NAT device.
 The Media Bypass service has been configured on the SE2900. The
media bypass mode is Automatic media bypass or Intra-AN
automatic media bypass.
Probability This issue may occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the SE2900
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R002C00SPH216 patch.
After the installation, a software parameter is used to enable the SE2900 to not perform media
latching when the media bypass status is changed.

2.3.8 NOTIFY and BYE Messages That Traverse the SE2900 Arrive
Out of Order
Involved NE: SBC

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 42


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Applicable Scope: global


Troubleshooting: N/A
Defect Details

Symptom The NOTIFY and BYE messages that traverse the SE2900 arrive out of
order.
Trouble N/A
Ticket
Number
Root Cause The SE2900 first receives a NOTFIY message and then a BYE message
less than 10 ms later. As the NOTIFY message is typically outside the
dialog and the BYE message is inside the dialog, these two messages are
placed in queues of different priorities. The SE2900 preferentially
processes the BYE message and then the NOTIFY message as the BYE
message queue has a higher priority than the NOTIFY message queue.
Consequently, the upper layer first receives the BYE message and then the
NOTIFY message.
Condition  The call transfer service is being implemented.
 The interval between the time when the SE2900 receives a NOTIFY
message and the time when the SE2900 receives a BYE message is less
than 10 ms.
Probability This issue may occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the SE2900
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R002C00SPH216 patch.
After the installation, a software parameter is used to place an NOTIFY message in the in-
dialog message queue when the Event header field of the NOTIFY message contains the
Refer field.

2.3.9 During Alerting Switchover, the SCC AS Initiates an


UPDATE Message to Change the Media PT Value, Disconnecting
the Voice Connection
Involved NE: SBC
Applicable Scope: global

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 43


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Troubleshooting: N/A
Defect Details

Symptom During alerting switchover, the SCC AS initiates an UPDATE message to


change the media PT value, disconnecting the voice connection.
Trouble N/A
Ticket
Number
Root Cause During alerting switchover, the SCC AS returns a 183 message and then
initiates an UPDATE message for media renegotiation. The PT value in the
UPDATE message is different from that in the 183 message. Due to an
internal defect, the SE2900 still uses the PT value in the 183 message to
perform PT conversion, disconnecting the voice connection.
Condition During alerting switchover, the SCC AS returns a 183 message and then
initiates an UPDATE message for media renegotiation. The PT value in the
UPDATE message is different from that in the 183 message.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the SE2900
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R002C00SPH216 patch.

2.3.10 TCP Links Fail to Be Established When Waiting for a TCP


Link Establishment Response Times Out
Involved NE: CSCF
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom When the MRFC requests the MCU to establish a TCP link, the MCU
returns a response after 40 ms. Once the MRFC receives the response, it
disconnects the socket connection, resulting in a failure in establishing the
TCP link.
Trouble N/A
Ticket

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 44


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Number
Root Cause The duration for waiting for a TCP link establishment response has been set
to 40 ms. If a TCP link establishment response does not arrive within 40
ms, the MRFC determines that the TCP link is faulty and therefore
disconnects the socket connection automatically.
Condition The latency for the CSCF to establish TCP links with other NEs exceeds 40
ms.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the CSC3300
Solution
Workarounds
N/A
Preventive Measures
Install the CSC3300 V100R011C20SPH102 patch.
After the installation, the duration for waiting for a TCP link establishment response is
changed to 2s and TCP links with a latency of less than 2s can be established.

2.4 Fault Cases for July 2016


2.4.1 Location Information Carried in the IMS-Visited-Network-
Identifier AVP of CDRs Generated by the ATS9900 Is Incorrect
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom The location information carried in the IMS-Visited-Network-Identifier


AVP of CDRs generated by the ATS9900 is obtained from the P-Visited-
Network-ID header field rather than the local configuration.
Trouble N/A
Ticket
Number
Root Cause The ATS9900 cannot obtain the visited domain from the local configuration
to set the IMS-Visited-Network-Identifier AVP.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 45


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition  FMC networks are deployed.


 VCU AVP Control List is set to Visited-Network-Id-1 by running
MOD RFPARAM in the MML Command - ATS9900 window of the
OMU client.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R008C10SPC100
Solution
Workarounds
N/A
Preventive Measures
P3388 is added to determine how the ATS9900 sets the IMS-Visited-Network-Identifier AVP
in ACRs.
Install the ATS9900 V100R008C10SPH125 patch.

2.4.2 CDIV Services Cannot Be Triggered When VoLTE


Subscribers Roam to a CS Network in Another Country
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom The ATS9900 is configured not to trigger Communication Diversion


(CDIV) services for calls routed to a CS network by running SET/ADD
RMSRVPOL in the MML Command - ATS9900 window of the OMU
client. VoLTE subscriber A has subscribed to CDIV services with voice-
mail-call-completion set to true and call forwarding type set to CFD.
When subscriber A is attached to the CS domain and is roaming
internationally, CDIV services fail.
Trouble N/A
Ticket
Number
Root Cause The ATS9900 does not trigger CDIV services for subscriber A.
Condition  FMC networks are deployed.
 The ATS9900 is configured not to provide CDIV services, including the
Call Forwarding Busy (CFB), Call Forwarding No Reply (CFNR), and
Call Forwarding on User Not Reachable (CFNRc), for calls routed to a
CS network by running SET/ADD RMSRVPOL.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 46


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

 Subscriber A has subscribed to CDIV services with voice-mail-call-


completion set to true and call forwarding type set to CFD.
NOTE
The ATS9900 determines that this a CFD service request when any of the following
condition is met:
 rule id is set to any of the following values:
CFB for voice calls: id="call-forwarding-default-by-busy-by-audio";
CFNR for voice calls: id="call-forwarding-default-by-no-answer-by-audio";
CFNRc for voice calls: id="call-forwarding-default-by-not-reachable-by-audio";
CFB for video calls: id="call-forwarding-default-by-busy-by-video";
CFNR for video calls: id="call-forwarding-default-by-no-answer-by-video";
CFNRc for video calls: id="call-forwarding-default-by-not-reachable-by-video";
 ADD VMNUM has been run to add a target number.
 Subscriber A is attached to the CS domain and is roaming internationally.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R008C10SPC100
Solution
Workarounds
N/A
Preventive Measures
The ATS9900 is enhanced to trigger CDIV services, including CFB, CFNRc, and CFNR,
when the preceding conditions are met.
Install the ATS9900 V100R008C10SPH125 patch.

2.4.3 Calling Party Cannot Hear the Local Ring Back Tone After
the Customized Ring Back Tone Fails to Be Played
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom Play the ring back tone at the MT side is set to NO(NO) by running
ADD LDNSET in the MML Command - ATS9900 window of the OMU
client. VoLTE subscriber B has subscribed to the Customized Ring Back
Tone Control and Trigger (CRBT) service but has not subscribed to the ring
back tone service. When subscriber A calls subscriber B, the CRBT service
is triggered. The customized ring back tone fails to be played, and

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 47


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

subscriber A cannot hear the ring back tone.


Trouble N/A
Ticket
Number
Root Cause The ATS9900 cannot play the local ring back tone in the preceding
scenarios.
Condition  FMC networks are deployed.
 Play the ring back tone at the MT side is set to NO(NO) by running
ADD LDNSET in the MML Command - ATS9900 window of the
OMU client.
 VoLTE subscriber B has subscribed to the CRBT service but has not
subscribed to the ring back tone service.
 When subscriber A calls subscriber B, the CRBT service is triggered, but
CRBT announcement playback fails.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 of all versions
Solution
Workarounds
N/A
Preventive Measures
The ATS9900 is enhanced to play the local ring back tone when Failure processing mode is
set to Customized processing by running MOD CRBTCTL.
Install the ATS9900 V100R008C10SPH125 patch.

2.4.4 CDIV Service Processing on the Next-hop NE Fails Because


the Value of Privacy in the Diversion Header Field of the INVITE
Message Sent from the ATS9900 Is Incorrect
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom The ATS9900 converts the History-Info header field in an INVITE message
to the Diversion header field before sending the INVITE message. The
value of Privacy in the Diversion header field is incorrect. Consequently,
CDIV service processing on the next-hop NE fails.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 48


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause The ATS9900 transparently transmits the Privacy parameter when
converting the History-Info header field to the Diversion header field.
Condition  FMC networks are deployed.
 P2329 is set to 0, and SEND_DIVERSION(Send Diversion) is selected
for Software parameter of service control by running MOD SIPCFG.
 The ATS9900 converts the History-Info in an INVITE message to the
Diversion header field before sending the INVITE message to the next-
hop NE.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 of all versions
Solution
Workarounds
N/A
Preventive Measures
P3394 is added to determine whether the ATS9900 adaptively configures the Privacy
parameter complying with RFC7544 when converting the History-Info header field to the
Diversion header field.
Install the ATS9900 V100R008C10SPH125 patch.

2.4.5 Timestamp In ACR Messages Sent from the ATS9900 Is


Incorrect
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom In an original ACR [Interim] on the CCF, the time is the same between the
SIP-Request-Timestamp AVP and SIP-Response-Timestamp AVP.
However, the value of the SIP-Request-Timestamp-Fraction AVP is greater
than that of the SIP-Response-Timestamp-Fraction AVP. Consequently, an
extra long ACR is generated.
Trouble N/A
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 49


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause The ATS9900 assigns values to SIP-Request-Timestamp-Fraction and SIP-


Response-Timestamp-Fraction AVPs in an ACR sent to the CCF. Time
obtainment methods for these two AVPs are different, as a result, their AVP
values are different occasionally.
Condition  FMC networks are deployed.
 P1736 is set to 1.
Probability There is a low probability that this issue will occur when the preceding
of conditions are met.
Occurrence

Involved Version
ATS9900 of all versions
Solution
Workarounds
N/A
Preventive Measures
Rectify the internal defect that caused this issue.
Install the ATS9900 V100R008C10SPH125 patch.

2.4.6 ATS9900 Does Not Stopping Playing the Customized Ring


Back Tone Upon Receiving a 183 Message That Carries the P-
Early-Media Header Field But Does Not Carry the SDP
Information When a Call Is Routed to the CS Network and Then
the CFNRy Service Is Triggered
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom Subscriber A calls subscriber B, and the call is routed to the CS network. B
is alerted, and the CRBT service is triggered. The IMS domain plays a
customized ring back tone. During the announcement playback, B does not
answer the call, and the CFNRy service is triggered. The ATS9900 does not
stopping playing the customized ring back tone when receiving a 183
message that carries the P-Early-Media header field but does not carry the
SDP information. Subscriber A cannot hear subsequent other
announcements.
Trouble SR6234004
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 50


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause The ATS9900 is not configured to stop playing the customized ring back
tone when receiving a 183 message that carries the P-Early-Media header
field but does not carry the SDP information.
Condition  FMC networks are deployed.
 The called party has subscribed to the CRBT service by running ADD
MSR or MOD MSR.
 The call is routed to the CS network.
 The CFNRy service is triggered for the called party in the CS domain.
The ATS9900 receives a 181 message and then a 183 message that
carries the P-Early-Media header field (set to sendrecv or sendonly) but
does not carry the SDP information.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 of all versions
Solution
Workarounds
N/A
Preventive Measures
P2084 is added to determine whether the ATS9900 stops playing a customized ring back tone
when receiving a 183 message that carries the P-Early-Media header field but does not carry
the SDP information.
 Subscriber A calls subscriber B, and the call is routed to the CS network.
 The CRBT service is triggered for subscriber B. The IMS domain plays a customized
ring back tone.
 The CFNRy service is triggered for subscriber B in the CS domain. The ATS9900
receives a 183 message that carries the P-Early-Media header field (set to sendrecv or
sendonly) but does not carry the SDP information.
Install the ATS9900 V100R008C10SPH125 patch.

2.4.7 ALM-20051 Bill Pool OverLoad Alarm Is Generated for the


ATS9900
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom ALM-20051 Bill Pool OverLoad Alarm is generated for the ATS9900.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 51


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble SR6382584
Ticket
Number
Root Cause The ATS9900 receives a large number of INVITE messages for media
renegotiation. After media renegotiation is complete, the ATS9900 delivers
ACR [Interim] messages. A large number of ACR [Interim] messages are
accumulated, and ALM-20051 Bill Pool OverLoad Alarm is generated.
Condition  FMC networks are deployed.
 The ATS9900 receives a large number of INVITE messages for media
renegotiation due to a network error.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 of all versions
Solution
Workarounds
N/A
Preventive Measures
P3391 is added to determine whether the ATS9900 sends ACR [Interim] messages based on
the value of ReInvite Bill Flag configured by running MOD RFPARAM after receiving an
INVITE message for media renegotiation.
Install the ATS9900 V100R008C10SPH125 patch.

2.4.8 SPU Board Is Reset When There Are a Large Number of


Calls in Two-System Networking
Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom In two-system networking, a large number of concurrent calls may cause


SPU board resetting.
Trouble N/A
Ticket
Number
Root Cause In two-system networking, media forwarding triggers log printing. If there
are a large number of calls, frequent log printing uses many CPU resources.
This may cause SPU board resetting.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 52


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition  The dual-system hot backup networking is used.


 There are more than 7000 concurrent calls.
Probability This issue may occur when the preceding conditions are met.
of
Occurrence

Involved Version
SE2900 of all versions
Solution
Workarounds
N/A
Preventive Measures
In two-system networking, media forwarding does not trigger log printing.
Install the SE2900 V300R002C00SPH215 patch.

2.4.9 EXP USRINF May Fail to Run


Involved NE: CSCF
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom Running of EXP USRINF may fail due to timeout.


Trouble SR6302659
Ticket
Number
Root Cause After a user runs EXP USRINF, the host queries subscriber information
and sends the information to the maintenance command processing
module. The module uses a method different from the host to calculate the
message length. As a result, the module accesses the protected memory in
addition to the message package, resulting in the failure of the command.
Condition A user attempts to run EXP USRINF.
Probability There is a low probability that this issue will occur when the preceding
of condition is met.
Occurrence

Involved Version
CSC3300 of all versions
Solution

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 53


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Workarounds
N/A
Preventive Measures
The maintenance command processing module now uses the same method as the host to
calculate the message length.
Install the CSC3300 V100R011C20SPH101 patch.

2.5 Fault Cases for June 2016


2.5.1 SE2900 May Fail to Connect Calls to Called Parties Due to
UE Abnormalities
Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom At a certain site, calls to some subscribers may fail. The symptom is that
the calling party releases the call because no ring back tone is played, and
the called party is not alerted of the incoming call.
Trouble N/A
Ticket
Number
Root Cause A UE has registered with the Contact header field carrying the
transport=tcp parameter. When a call is addressed to the UE, the SE2900
uses TCP links to exchange messages with the UE. This may cause the call
to fail due to an internal defect of the SE2900. After links are aged and re-
established, the call can be restored. However, before link re-establishment,
the call fails.
Condition A call is initiated to a UE that has registered with the Contact header field
carrying the transport=tcp parameter.
Probability This issue may occur when the preceding condition is met.
of
Occurrence

Involved Version
SE2900 V300R001C30SPH100
Solution
Workarounds
1. Change the TCP client's link aging time of the SBC to 2 minutes.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 54


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=8, BITVAL=0;


MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=9, BITVAL=1;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=10, BITVAL=0;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=11, BITVAL=0;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=12, BITVAL=0;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=13, BITVAL=0;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=14, BITVAL=0;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=15, BITVAL=0;
2. Reset the active and standby SCU processes of the SBC.
This operation does not affect services. Only module alarms are generated.
Resetting method: First reset the standby SCU process and then the active SCU process after
the resetting progress of the standby SCU process reaches 100%. (To check the resetting
progress, click Module Management Pane.)x`
)
RST MODULE: MEID=xxx, MN=xxx, HAST=ACTIVE;
Preventive Measures
Install the SE2900 V300R001C30SPH102 patch.

2.5.2 SE2900 Returns a 404 Response After Receiving a Handover


INVITE Message from the SRVCC IWF
Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom In eSRVCC handover scenarios, when the SRVCC IWF sends a handover
INVITE message to the SE2900, the SE2900 returns a 404 response.
Trouble N/A
Ticket
Number
Root Cause When the Feature-caps header field of a 183 message sent by the called
party contains an SRVCC handover capability parameter that ends with a
comma (,) the SE2900 cannot recognize this parameter. Consequently, the
SE2900 cannot obtain the SRVCC handover capability carried by the called
party, resulting in a handover failure.
Condition In eSRVCC handover scenarios, the Feature-caps header field contains an
SRVCC handover capability parameter that ends with a comma (,).
Probability This issue will occur when the preceding condition is met.
of

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 55


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Occurrence

Involved Version
SE2900 V300R002C00SPH200
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R002C00SPH213 patch.

2.5.3 Second Call Fails When VoWiFi Subscribers Initiate Re-


registrations in the ICS Domain After eSRVCC Handovers
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom VoWiFi subscriber A calls subscriber B through WiFi access, and the call is
connected. During the call, A is first handed over to the LTE network.
Then, after an eSRVCC handover, A is handed over to the CS domain. A
initiates a re-registration in the ICS domain. When C calls A at this time,
the ATS9900 routes the call to the IMS domain through domain selection.
As A is unreachable in the IMS domain, the call between A and C fails.
Trouble SR6142398
Ticket
Number
Root Cause A first initiates a call in the IMS domain. Therefore, the IMPI obtained
during the re-registration is specific to the IMS domain. As A has already
registered with in the ICS domain, the IMPI has been replaced with the
IMPI specific to the ICS domain. This means that the ATS9900 cannot use
the IMS domain-specific IMPI to query the ESN, resulting in no update of
the domain selection information.
When a call is addressed to A, the ATS9900 routes the call to the IMS
domain through domain selection, causing the call to fail.
Condition This issue occurs only on FMC networks when both of the following
conditions are met:
 The number of concurrent calls allowed for A is 2.
 A first initiates a call in the IMS domain. After a handover, A re-registers
with the ICS domain and then receives a call.
Probability This issue will occur when the preceding conditions are met.
of

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 56


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Occurrence

Involved Version
All versions of the ATS9900
Solution
Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R008C10SPH123 patch.

2.5.4 eSRVCC Handover Fails for Conference Service Parties,


Resulting in a Failure in Re-establishing Conference Information
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom A calls B and C. After the calls are connected, A creates a conference and
sends SUBSCRIBE message for a subscription to the conference. Then, A
invites B and C to the conference. At this time, an eSRVCC handover
occurs for A. When this handover fails, the conference information cannot
be re-established.
Trouble N/A
Ticket
Number
Root Cause When the ATS9900 is configured to support conference information re-
establishment (this function is achieved by running MOD SRVCCCFG
with SUPMR(Support conference information reestablishment)
selected for SRVCC Extension Parameter), the Contact header field is
constructed for the 200 response to the conference handover request. The
Contact header field contains the conference URI. In version 11.1, the
conference URI is obtained from the To header field in the SUBSCRIBE
message used for a subscription to conferences.
In this failure scenario, the To header field in the SUBSCRIBE message
carries the conference factory URI and user=phone, instead of the
conference URI (on the live network, the conference URI is carried by the
Request-URI.) If the To header field carries user=phone, the URI
information in the header field is converted into the tel URI format for
storage. However, when the ATS9900 constructs the Contact header field
for a 200 (to a handover request) response, it checks the URI type. If the
URI type is not SIP URI, the ATS9900 returns a failure message rather than
constructing the Contact header field. That is, the ATS9900 cannot returns a
200 (to a handover request), resulting in a failure in re-establishing

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 57


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

conference information.
Condition This issue occurs only on FMC networks when all of the following
conditions are met:
 The ATS9900 has been configured to support conference information re-
establishment (this function is achieved by running MOD SRVCCCFG
with SUPMR(Support conference information reestablishment)
selected for SRVCC Extension Parameter).
 The To header field in the SUBSCRIBE message used for a subscription
to conferences carries the conference factory URI, instead of the
conference URI.
 The conference factory URI is a SIP URI with user=phone.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R008C10SPH100
Solution
Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R008C10SPH123 patch.

2.5.5 S-CSCF Returns a 503 Message After Receiving an INVITE


Message from the AS
Involved NE: CSCF
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom During a call, the S-CSCF receives an INVITE message from the AS and
returns a 503 message, in which the Warning header field carries "Server
Internal Error." After receiving the 503 message, the AS triggers CS Retry
and receives the same 503 message.
Trouble SR6104100
Ticket
Number
Root Cause A subscriber initiates a call and then immediately releases it. Consequently,
the S-CSCF cannot find the associated session after receiving the INVITE
message from the AS.
Condition  A subscriber initiates a call and then immediately releases it.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 58


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

 The S-CSCF takes a long time to contact the AS. Before the S-CSCF
receives an INVITE message from the AS, it receives a CANCEL
message.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the CSC3300
Solution
Workarounds
N/A
Preventive Measures
Enable the S-CSCF to returns a 481 message, not a 503 message. This prevents the AS from
accidentally triggering CS Retry.
Install the CSC3300 V100R010C10SPH219 patch.

2.5.6 VoLTE Subscriber Fails to Receive a Call Immediately After


Powering on the Mobile Phone
Involved NE: CSCF
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom A VoLTE subscriber is called immediately after powering on the mobile


phone. The SBC sends a 487 message to release the call.
Trouble SR6183366
Ticket
Number
Root Cause The S-CSCF receives a REGISTER message from the VoLTE subscriber
and an INVITE message from the calling party at the same time. As the
VoLTE subscriber has not completed the registration procedure, the S-
CSCF does not have data of the subscriber. Therefore, the S-CSCF sends
an SAR message to the HSS to download data of the subscriber.
Due to an internal system error, the S-CSCF accidentally changes the
VoLTE subscriber's registration status when processing the SAA message.
After the registration is successful, the VoLTE subscriber initiates a
subscription. The S-CSCF returns a NOTIFY message indicating that the
VoLTE subscriber has been deregistered. The SBC receives the NOTIFY
message and sends a 487 message to release the ongoing call.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 59


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition  A VoLTE subscriber initiates a registration and receives a call at the same
time.
 Before the S-CSCF receives an SAA (to SAR) message during the
registration, a call is initiated to the VOLTE subscriber. The SAA (for
the registration) message is returned before the SAA (for the call).
 The UE initiates a subscription after a successful registration.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the CSC3300
Solution
Workarounds
N/A
Preventive Measures
The internal system defect that caused this issue has been rectified.
Install the CSC3300 V100R010C10SPH219 patch.

2.5.7 Terminating S-CSCF Returns a 500 Message for an Intra-


VoLTE Call
Involved NE: CSCF
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom During an intra-VoLTE call, the terminating S-CSCF returns a 500 message
in which the Warning header field carries "Server Internal Error" when
processing the initial INVITE message. The call fails to be established.
Trouble SR6000114
Ticket
Number
Root Cause During the call establishment, the called party is handed over or initiates a
deregistration. As a result, the subscriber data on the S-CSCF is deleted.
When S-CSCF fails to obtain the subscriber data, the call fails.
Condition The called party is deregistered before the S-CSCF sends an INVITE
message to the P-CSCF.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 60


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
All versions of the CSC3300
Solution
Workarounds
N/A
Preventive Measures
The S-CSCF now returns a 480 message, not a 500 message if it fails to query subscriber data.
Based on the 480 message, the AS can trigger CS Retry to connect the call.
To provide the preceding solution, install the CSC3300 V100R010C10SPH219 patch.

2.5.8 eSRVCC Handover Success Rate for High-Speed Railway


Dedicated Networks Is Low
Involved NE: BSC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom At a certain site, the eSRVCC handover success rate for high-speed railway
dedicated networks is very low, only about 60%.
Trouble N/A
Ticket
Number
Root Cause The information collected for the site shows that the handover failure cause
is "3 Handover /Relocation Failure with Target system". Based on the
failure cause, it is found that the failure is caused by the fact the eSRVCC
handover switch is not enabled on the BSC. Two switches are used on the
BSC side to control SRVCC handovers: SRVCC handover switch and inter-
RAT incoming handover switch. SRVCC handover is allowed only when
either of the two switches is enabled. As the SRVCC handover switch is
license-controlled, the SRVCC handover switch is disabled at the site. In
addition, the inter-RAT incoming handover switch is disabled at the site.
After either of the two switches is enabled, the eSRVCC handover success
rate for high-speed railway dedicated networks increases from 60% to 98%.
Condition Neither the SRVCC handover switch nor the inter-RAT incoming handover
switch is enabled.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 61


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

All versions of the BSC


Solution
Workarounds
N/A
Preventive Measures
Enable the SRVCC handover switch, inter-RAT incoming handover switch, or both on the
BSC.

2.5.9 Session Binding Service Fails When the origin-host in the


CCA Message Is Inconsistent with the DMPEER host-name
Configured on the SPS
Involved NE: SPS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom The session binding service has been enabled on the SPS to support routing
of IP-CAN session messages sent by the same subscriber through different
GGSNs to the same PCRF. However, tests show that the session binding
service does not work. The CCR message sent by a subscriber through
GGSN1 is routed to PCRF1, but the message sent by the same subscriber
through GGSN2 is routed to PCRF2 based on flexible routing rules, not
using the session binding service.
Trouble N/A
Ticket
Number
Root Cause 1. A subscriber initiates an IP-CAN session through GGSN1. GGSN1 sends
a CCR_I message to the SPS. The SPS routes the message to PCRF1 based
on flexible routing rules. On the SPS, the host name of PCRF1 is set to
pcrf1.
2. PCRF1 returns a CCA_I message in which the origin-host is
pcrf1.aaa.com. Therefore, when the SPS saves the session binding
information of the subscriber, it saves pcrf1.aaa.com as the host-name.
3. The SPS forwards the CCA-I message to GGSN1.
4. The subscriber initiates an IP-CAN session through GGSN2. GGSN2
sends a CCR_1 message to the SPS. At this time, the SPS queries session
binding data and changes the destination-host in the message to
pcrf1.aaa.com. However, as the host-name is configured on the SPS, the
SPS cannot route the message to PCRF1 based on pcrf1.aaa.com. Instead,
the SPS routes the message to PCRF2 based on flexible routing rules.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 62


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition In VoLTE networking scenarios, no S-CSCF capabilities have been


configured for a subscriber, and the ISCAP priority configured for
subscribers at other sites is consistent with that configured for subscribers
in the local province.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
Solution
Workarounds
Preventive Measures
When PCRF1 returns a CCA message, it includes the correct origin-host (pcrf1) in the
message. Then, after session binding is performed for subsequent messages, they can be
directly routed to PCRF1 based on pcrf1.

2.5.10 Peer End Fails to Re-establish a Link with the SPS After the
SPS Disconnects the Link with the Peer End Due to the Failure in
Receiving the DWA Message
Involved NE: SPS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom The SPS serves as the server but cannot receive the device watchdog
answer (DWA) message sent by the peer. Then, the link between the SPS
and the peer is disconnected and fails to be re-established.
Trouble N/A
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 63


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause After the SPS sends a device watchdog request (DWR) message to the peer
end, it does not receive a DWA message. Then, the SPS disconnects the
link with the peer end. Due to an internal defect, the SPS accidently
releases the SCTP association. When the peer end attempts to establish a
link with the SPS, the SPS cannot process the init message from the peer
end, causing a failure in establishing the link.
Condition  The SPS is configured with Diameter links and serves as the server.
 The peer port number is not 0.
 The SPS sends a DWR message to the peer end but does not receive a
DWA message. Then, the SPS disconnects the link with the peer end
and the peer end sends a link establishment request.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All patch versions earlier than SPS V300R007C10SPH216
Solution
Workarounds
Run ACT DMLNK to activate Diameter links.
Preventive Measures
If the current version is SPS V300R007C10, upgrade it to SPS V300R007C10SPH216 or
later.

2.5.11 When Subscription to VoLTE SRVCC Is Not Enabled on


the HSS, SRVCC Handovers Fail for VoLTE UEs in Special
Scenarios
Involved NE: HSS9860
Applicable Scope: global
Troubleshooting Engineer: Chen Tao (ID: 00342064)
Defect Details

Symptom When SRVCC handovers fail for VoLTE UEs of Hutchison (Hong Kong),
the SBC returns a 404 message in which the Warning header field carries
"Random Message To ATCF Address".
Warning: 399 00000.00000.A.200.402.228.0.5.02062.00000000 "Random
Message To ATCF Address"
Trouble SR6302659
Ticket
Number
Root Cause 1. When a VoLTE UE initiates a network attach procedure, it does not

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 64


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

carry the information element (IE) MS-network-capability to support


SRVCC. Therefore, when the MME sends a ULR message to the HSS
for a location update, the UE-SRVCC-Capability in the message is set
to 0 (not supporting SRVCC).

2. After the VoLTE UE attaches to the network, it sends a REGISTER


message for an initial registration. After the initial registration, the S-
CSCF initiates a third-party registration (SRVCC/eSRVCC) to the ATS
(SCC AS). When the ATS (SCC AS) learns from the HSS that the UE-
SRVCC-Capability is set to 0 (not supporting SRVCC), it does not send
a MESSAGE message to push ATU-STI and C-MSISDN to the SBC
(ATCF).

3. The VoLTE UE initiates a network attach procedure again. The IE MS-


network-capability is carried. The value of bits 21-24 of the IE is 0xE
(1110). The value of bit 21 is 1 (supporting SRVCC).

4. As the VoLTE UE now supports SRVCC, the MME sends an NOR


message to the HSS. In the message, the UE-SRVCC-Capability is set
to 1 (supporting SRVCC).

5. At this time, as the SRVCC subscription is disabled on the HSS, the


HSS does not send a PNR message to push the SRVCC capability to the
ATS (SCC AS).
6. After the VoLTE UE attaches to the network, it sends a REGISTER
message for an initial registration. After the initial registration, the S-
CSCF initials a third-party registration (SRVCC/eSRVCC) to the ATS
(SCC AS). When the ATS (SCC AS) detects that the UE-SRVCC-
Capability is set to 0 (not supporting SRVCC), it still does not send a
MESSAGE message to push ATU-STI and C-MSISDN to the SBC
(ATCF).
7. The subscriber initiates a call. During the call, a handover occurs. The
MME sends an SRVCC PS to CS Request message to the eMSC
(SRVCC IWF). Then, the eMSC sends an INVITE message (for an

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 65


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

SRVCC handover) to the SBC (ATCF). In the INVITE message, the


Request-URI is STN-SR.
8. As the ATS (SCC AS) has not sent a MESSAGE message, the SBC
returns a 404 message in which the Warning header field carries
"Random Message To ATCF Address" when it fails to obtain the
corresponding C-MSISDN from the received INVITE message (for an
SRVCC handover).
Condition 1. When the VoLTE UE attaches to the TAU or RAU (4G-to-3G) again,
the SRVCC capability is changed.
2. Subscription to VoLTE SRVCC is not enabled on the HSS.
Probability This issue will occur when the preceding conditions are met.
of Note: In normal cases, the SRVCC capabilities of commercial UEs are not
Occurrence changed. Therefore, this issue rarely occurs.

Involved Version
HSS9860 V900R009C00SPC200
Solution
Workarounds
1. Power off the VoLTE UE or enable the offline mode for the VoLTE UE.
2. Wait for one minute (VoLTE UE deregistration takes about 32 seconds; you are advised
to wait for one minute) and power on the VoLTE UE or disable the offline mode for the
VoLTE UE to send an initial registration and obtain the SRVCC capability from the HSS
while the ATS (SCC AS) is performing a third-party registration.
Preventive Measures
On the HSS, set bit 0 of the software parameter VoLTE Enhanced Feature Switch to 1 to
enable subscription to VoLTE SRVCC.

2.6 Fault Cases for May 2016


2.6.1 Bandwidth Values Carried in AAR Messages Sent by the
SE2900 Are Incorrect During an eSRVCC Handback
Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom When a UE fails to perform an SRVCC handover, the UE sends an INVITE


message to hand back the session. The bearer bandwidth value carried in
the INVITE message is 49000 bit/s. However, the bandwidth value carried
in the AAR message sent by the SBC is 33000 bit/s.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 66


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause On the access network side, the IP address type is IPv6. However, on the
core network side, the IP address type is IPv4. As a result, bandwidth
calculation during an eSRVCC handback is incorrect.
Condition IPv6 addresses are used on the access network side, and IPv4 addresses are
used on the core network side.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
SE2900 V300R001C20SPH100
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R001C20SPH122 patch.

2.6.2 404 Message Is Returned for an eSRVCC Handover Initiated


by the Calling Party
Involved NE: SBC
Applicable Scope: China
Troubleshooting: N/A
Defect Details

Symptom When an initial call between the calling and called parties is not set up and
the calling party sends an INVITE message to perform an eSRVCC
handover, the SE2900 returns a 404 message, stating that the called party
does not exist. However, the called party does exist.
Trouble N/A
Ticket
Number
Root Cause Conflict exists in the handover and call processes. The following figure
shows the detailed processes.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 67


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The SBC returns a 404 message, indicating that the called party does not
exist. However, the called number exists.
Condition  After the SE2900 receives an INVITE message for an eSRVCC
handover, it determines that C-MSISDN/STN-SR matching fails.
 After the SE2900 receives an INVITE message for an eSRVCC
handover, it determines that the original call to be handed over does not
exist.
 After the SE2900 receives an INVITE message for an eSRVCC
handover, it determines that the 180, 183, and 200 messages of the
original call to be handed over are not received.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R001C20SPH122 patch.

2.6.3 When a VoLTE UE Initiates a Video Call, the SE2900 Does


Not Use the Bandwidth Specified in the 'b=' Line of SDP
Information Carried in the UE-Initiated Message, Wasting
Wireless Network Bandwidth Resources
Involved NE: SBC

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 68


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Applicable Scope: global


Troubleshooting: N/A
Defect Details

Symptom When a VoLTE UE initiates a video call, the SE2900 does not use the
bandwidth specified in the 'b=' line of SDP information carried in the UE-
initiated message, wasting wireless network bandwidth resources.
Trouble 5432868
Ticket
Number
Root Cause The SE2900 preferentially uses the configured service bandwidth rather
than the 'b=' line as the minimum bandwidth of the Rx interface.
Condition The configured service bandwidth is higher than the bandwidth in the 'b='
line.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R001C20SPH119 patch.

2.6.4 VoLTE Calling Party Cannot Hear the Called Party After
Initiating an aSRVCC Handover
Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom After a VoLTE subscriber, serving as the calling party, initiates an aSRVCC
handover, the calling party cannot hear the called party after the call is
connected.
Trouble 5732167
Ticket
Number
Root Cause During a call handover, PT changes on the originating and terminating

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 69


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

sides are not considered, which results in incorrect PT value delivery. (The
PT values carried in the INVITE message received by the SBC are 97 and
101. The PT values carried in the INVITE message forwarded by the SBC
are 96 and 97.)
On the media plane, the core network node will receive four PTs, including
the local voice PT, remote voice PT, local 2833 PT, and remote 2833 PT.
In handover failure scenarios, the four PT values are 97, 97, 97, and 101.
When the iMedia identifies the packet type based on the local PT = 97, the
iMedia process voice packets (whose PT is 97) based on local 2833
packets. As a result, voice packet parsing fails and are discarded, and the
calling party cannot hear the called party.

In handover success scenarios, the four PT values are 96, 97, 97, and 101.
In addition, the delivered PT conversion flag enables the HRU to change
the PT (97) of voice packets to 96. In this case, for iMedia, the voice PT is
96 and 2833 PT is 97, and the iMedia can correctly identify voice packets.

Condition The PT and mode-set values carried in the handover requests in the alerting
phase and the original call requests are inconsistent.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 70


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R001C20SPH119 patch.

2.6.5 SCC AS Does Not Include the +g.3gpp.mid-call Parameter in


the Feature-Caps Header Field of the 200 Message for Handover
Success
Involved NE: ATS
Applicable Scope: global
Troubleshooting: Huang Zhenghua (employee ID: 00248152)
Defect Details

Symptom Subscriber A has two calls. The call between subscribers A and B is placed
on hold, and the call between subscribers A and C is active. Subscriber A
initiates a handover, and the call between A and C is first handed over.
During the handover, the Contact header field in the 200 message sent by
the ATS9900 carries the +g.3gpp.mid-call parameter. However, the peer
SRVCC IWF can parse only the +g.3gpp.mid-call parameter carried in the
Feature-Caps header field. As a result, +g.3gpp.mid-call parsing fails, and
the SRVCC IWF cannot initiate the handover request for the call between A
and B.
Trouble N/A
Ticket
Number
Root Cause As stipulated in 3GPP 24.237-B40, the +g.3gpp.mid-call parameter is
carried in the Contact header field of the 200 message. Currently, the ATS
supports only 3GPP 24.237-B40.

As stipulated in the latest version 3GPP 24.237-B60, the +g.3gpp.mid-call


parameter is carried in the Feature-Caps header field of the 200 message.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 71


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition This issue occurs only on FMC networks when both of the following
conditions are met:
 Subscriber A has two calls. The call between subscribers A and B is
placed on hold, and the call between subscribers A and C is active.
 Subscriber A initiates a handover.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R006C10SPH200
Solution
Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R006C10SPH222 patch.
The software parameter P2048 is added. When the software parameter is set to 1, the
+g.3gpp.mid-call parameter is carried in the Feature-Caps header field of the 200 message
sent by the ATS9900 for handover success.

2.6.6 ATS9900 Occasionally Sends 500 Messages to Calls Initiated


from a VoLTE Subscriber to Another VoLTE Subscriber Attached
to the CS Domain
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom Subscribers A and B are VoLTE subscribers, and subscriber B is attached to


the CS domain. When subscriber A initiates calls to subscriber B, and the
ATS9900 receives 200 messages from subscriber B, the ATS9900
occasionally sends 500 messages to subscriber A. As a result, the calls fail.
Trouble N/A
Ticket
Number
Root Cause After the ATS9900 receives a call destined to subscriber B, the ATS9900
downloads service data of subscriber B from the HSS and saves it. By
default, the data can be saved for 90s. After 90s, the ATS9900 sends an
SNR message to the HSS to cancel subscription if the call is released. After
the ATS9900 receives an SNA message from the HSS, the ATS9900 deletes
service data of subscriber B. If the ATS9900 receives a new call destined to

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 72


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

subscriber B before receiving the SNA message from the HSS, the service
data are deleted during the new call processing. As a result, after the
ATS9900 receives a 200 message from the called party, service data query
fails, and the ATS9900 returns a 500 message.
Condition This issue occurs only on FMC networks when both of the following
conditions are met:
 After the service data saving timer on the ATS9900 expires, the ATS9900
sends an SNR message to the HSS to cancel subscription.
 Before the ATS9900 receives an SNA message from the HSS, the
ATS9900 receives a new call destined to the subscriber.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R006C10SPH200
Solution
Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R006C10SPH222 patch.
After the service data saving timer on the ATS9900 expires, the ATS9900 deletes service data
after it sends an SNR message to the ATS9900. After the ATS9900 receives a new call
destined to a subscriber, the ATS9900 downloads service data of the subscriber from the HSS
again.

2.6.7 SRVCC Handover of the Second Call for a Subscriber


Having Two Calls Fails as the SCC AS Does Not Send the REFER
Message
Involved NE: ATS
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom An iPhone 6s plus terminal served by the SBC provided by ZTE initiates a
mid-call SRVCC handover for two calls. One call is placed on hold and the
other is active. However, the SCC AS does not send an REFER message.
As a result, handover of the second call fails.
Trouble 5950888
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 73


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause When the iPhone 6s plus terminal served by the SBC provided by ZTE
sends an INVITE message for a mid-call SRVCC handover of two calls
(one is active and the other is placed on hold) to the SCC AS, the SCC AS
sends a BYE instead of an REFER message. As a result, handover of the
second call fails.

The following shows the corresponding printed logs:


Level(WARNING) -> [../patchsrc/VCU_V100R006C10SPH212_sc.c
FileID(3028): 225 <SC_SrvccModifyReferTo>] create To failed, Ret =
[8723297].
The SDP body carries the @ sign, and the SCC AS cannot process the sign.
As a result, the SCC AS fails to construct the Refer-To header field based
on the SDP body.
Condition This issue occurs only on FMC networks when both of the following
conditions are met:
 The terminal supports handover of multiple calls.
 Before the handover, a subscriber has two calls that meet any of the
following conditions:
− One call is active and the other is placed on hold. The INVITE
message sent to the SCC AS for handing over the held call carries
the @ sign in the SDP body.
− One call is active and the other is placed on hold. The INVITE
message sent to the SCC AS for handing over the active call carries
the @ sign in the SDP body.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R006C10SPH200
Solution
Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R006C10SPH222 patch.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 74


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The SCC AS function is enhanced to ensure that it can process the @ sign in the SDP body.

2.6.8 VoLTE UE Registration Fails as the S-CSCF Returns a 500


Message
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom A VoLTE UE fails to register with the IMS network. The message tracing
result shows that the S-CSCF returns a 500 message to the second
REGISTER message after it sends a 401 message. The Warning header
field in the 500 message carries 399
0.0.S.260.5.115.255.255.5938.0.0.xx.xxx.com "Server Internal Error."
Trouble 4890663
Ticket
Number
Root Cause According to the user message tracing result on the CSC3300, after the S-
CSCF downloads subscriber data from the HSS through the SAR/SAA
process, the S-CSCF does not return a 200 (to REGISTER) message.
Instead, the S-CSCF sends another SAR message carrying
serverAssignmentType:administrativeDeregistration (8), instructing the
HSS to clear the registration state of the subscriber.
From the printed logs, the length of the compressed Contact header field
value is 306.
CscfCompContactParam SipSerialSipHdr fail, ulRet=[72b272c]
ulRealLen=[306]
However, the CSC3300 supports the maximum length of 255 characters for
the Contact header field value. If the Contact header field value in the
REGISTER message exceeds 255 characters and cannot be compressed to
less than 255 characters, registration fails. Currently, a maximum of 1023
characters can be compressed to 255 characters.
Condition The length of the Contact header field value exceeds 255 characters and
cannot be compressed to less than 255 characters.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
CSC3300 V100R010C10 or later (excluding V500 versions)
Solution
Workarounds
N/A

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 75


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Preventive Measures
Compare the Contact header field in the REGISTER message with that in a normal
REGISTER message to check the parameters that are added. Run the following commands to
configure the data:
ADD SRVCAP: FEATURETYPE=FEATURENAMEANDVALUE,
FEATURENAME="+g.3gpp.iari-ref", FEATUREVALUE="urn%3Aurn-7%3A3gpp-
application.ims.iari.rcs", SERVICEID=ALL, COMPRESSFLAG=Y, RESERVED=0;
ADD SRVCAP: FEATURETYPE=FEATURENAMEANDVALUE,
FEATURENAME="+g.3gpp.iari-ref", FEATUREVALUE="urn%3Aurn-7%3A3gpp-
application.ims.iari.rcs.mnc000.mcc460.cloudfile", SERVICEID=ALL,
COMPRESSFLAG=Y, RESERVED=0;

2.6.9 Registered VoLTE UE Fails to Initiate a Registration Again


Using Plaintext as the S-CSCF Returns a 403 Message
Involved NE: SE2900
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom A registered VoLTE UE initiates a registration again using plaintext.


However, the S-CSCF returns a 403 message. As a result, the registration
fails. The 403 message carries 399
0.0.S.260.5.119.255.255.5144.0.0.xx.yyy.com "Administrator deregister
user."
Trouble 5671208
Ticket
Number
Root Cause 1. After a VoLTE UE successfully registers with the network using the
IMS-AKA or IPSec authentication mode, IP address and port number of
the UE at the transport layer are not changed. However, the port-s
parameter value used for IPSec negotiation is changed.
2. When the VoLTE UE initiates a registration again using plaintext (not
encrypted using IPSec), the PORT parameter in the Path header field of
the REGISTER message changes but the Contact header field does not
change when the SE2900 forwards the REGISTER message to the S-
CSCF.
3. The S-CSCF considers the registration abnormal and returns a 403
message whose Warning header field carries "Administrator deregister
user."
Condition  The SE2900 interworks with the S-CSCF and verifies the PORT
parameter in the Path header field and IP address and port number
information in the Contact header field.
 In VoLTE networking, the SE2900 functions as the P-CSCF and the port
multiplexing function is enabled.
 After a VoLTE UE successfully registers with the network using the IMS-
AKA or IPSec authentication mode, the IP address and port number at

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 76


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

the transport layer are not changed. However, the port-s parameter used
for IPSec negotiation is changed, and the UE initiates a registration
again using plaintext (not encrypted using IPSec).
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
SE2900 V300R001C20
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R001C20SPH119 patch.
Bit 10 of BCFPARA11 is added to control how the SE2900 sets the port number in the
Contact header field of the forwarded REGISTER request (involving IMS-AKA/IPSec). To
solve this problem, set bit 10 of BCFPARA11 to 1.
MOD SFP: INSPN=BCFPARA11, MODTYPE=P1, BIT=10, BITVAL=1;

Bit 10
Determines the mode that the SE2900 sets the port number in the Contact header field of the forwarded
REGISTER request (involving IMS-AKA/IPSec) when port multiplexing is enabled.
Value:
= 0: The SE2900 sets the port number in the Contact header field of the forwarded REGISTER request
based on the source transport-layer port of the UE-initiated REGISTER request.
= 1: The SE2900 sets the port number in the Contact header field of the forwarded REGISTER request
based on the port-s parameter in the Security-Client header of the UE-initiated REGISTER request.
Default value: 0

2.6.10 400 Message (Bad Request) Is Returned to the Initial


Registration of an iPhone
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom An iPhone sends a REGISTER message to initiate a registration. After


receiving a 401 message from the S-CSCF, the terminal sends another
REGISTER message. However, the S-CSCF returns a 400 (Bad Request)
message. The Warning header field in the 400 message carries
3995123.2343.S.260.5.105.7.16.4872.0.0.xx.xxxx.com

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 77


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

"Sipkeyparameterinvalid."
Trouble N/A
Ticket
Number
Root Cause The registration flow is as follows: 1. At 23:06:58:259, the REGISTER
message is sent to PSBC2. The ISBG4-I (I-CSCF/S-CSCF co-located)
returns a 401 message.

2. The terminal sends another REGISTER message. The REGISTER


message is sent to PSBC1 at 23:06:58:413. The ISBG4-S returns a 400
(Bad Request) message.

The Call-ID parameters in the first and second REGISTER messages are
the same. The CSeq is 48 in the first REGISTER message and 49 in the
second REGISTER message. The Authorization header field in the second
REGISTER message does not carry the response parameter. As a result, the
CSCF cannot complete registration and returns a 400 message.
According to 3GPP 24.229, after the S-CSCF returns a 401 message to the
first REGISTER message, it needs to start a timer to wait for the second
REGISTER message with authentication information to complete
registration.
After the terminal sends the first REGISTER message, it starts the Treg
timer. By default, the timer duration is 64s. If the terminal does not receive
a response within 64s, it registers with another PSBC.
Condition  After a terminal sends a REGISTER message, the S-CSCF returns a 401
message. Within a specified time (32 seconds by default), the S-CSCF
receives the second REGISTER message from the terminal.
 The Call-ID parameters in two REGISTER messages are the same.
However, the CSeq parameter value in the second REGISTER message
is greater than that in the first REGISTER message.
 The Authorization header field does not carry the response parameter or
the response parameter value is null.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 78


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
All CSC3300 versions
Solution
Workarounds
N/A
Preventive Measures
Install the CSC3300 V100R010C10SPH217 patch released in April to ensure that the
CSC3300 returns a 401 message to the second REGISTER message according to the latest
protocol requirements. (The solution requires cooperation from the terminal and PSBC.)

2.6.11 486 Message Is Returned to the Initial Registration of a


Non-iOS Terminal
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom A non-iOS terminal sends a REGISTER message to initiate a registration.


After receiving a 401 message from the S-CSCF, the terminal sends another
REGISTER message. However, the S-CSCF returns a 486 (Busy) message.
The Warning header field in the 486 message carries
3995123.2343.S.260.5.117.6.5.5642.0.0.xxx.com"Toomanyregisterinparall
el."
Trouble N/A
Ticket
Number
Root Cause The registration flow is as follows: 1. At 22:50:31:918, a REGISTER
message is sent to PSBC1. ISBG4-I sends the message to SBG3-S, and
ISBG3-S returns a 401 message.

2. The terminal sends another REGISTER message. At 22:50:49:669, the


message is sent to SBG4-I. SBG4-I forwards the message to ISGB3-S, and
ISBG3-S returns a 486 (Busy) message. (The SEQ tracing result is for
reference only. It is used to indicate that the interval between two
REGISTER messages is within 32 seconds.)

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 79


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Call-ID in the first REGISTER message: 3893892875@IP1


Call-ID in the second REGISTER message: 1692536583@IP1
According to 3GPP 24.229, after the S-CSCF returns a 401 message to the
first REGISTER message, it needs to start a timer to wait for the second
REGISTER message with authentication information to complete
registration. As the Call-ID parameters contained in two REGISTER
messages are different, the S-CSCF does not complete the first REGISTER
message, and therefore returns a 486 (Busy) message to the second
REGISTER message.
Condition  After the terminal receives a 401 message from the S-CSCF, the terminal
sends another REGISTER message within 32 seconds.
 In the second REGISTER message, the Call-ID parameter changes.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All CSC3300 versions
Solution
Workarounds
N/A
Preventive Measures
Install the CSC3300 patch released in April to ensure that the CSC3300 returns a 401 message
to the second REGISTER message according to the latest protocol requirements.

2.6.12 Registration of VoBB Terminals at a VoBB+VoLTE Site


Fails If the Minimum Registration Duration Is Modified
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom The minimum registration duration needs to be set to 3600s. However, at


convergent sites, after this parameter is modified, the VoBB terminal
cannot modify the expires parameter contained in the Expires or Contact

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 80


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

header field according to the received 423 message. As a result, registration


fails, and services are affected.
Trouble N/A
Ticket
Number
Root Cause After a VoBB terminal receives a 423 message, it does not set the expires
parameter in the Expires or Contact header field of the REGISTER
message to the value of the Min-Expires header field in the 423 message.
As a result, registration update fails, and the S-CSCF deregisters the
subscriber.
Description of the 423 message in RFC3261:
21.4.17 423 Interval Too Brief
The server is rejecting the request because the expiration time of the
resource refreshed by the request is too short. This response can be used by
a registrar to reject a registration whose Contact header field expiration
time was too small.
10.2.8 Error Responses
If a UA receives a 423 (Interval Too Brief) response, it MAY retry the
registration after making the expiration interval of all contact addresses in
the REGISTER request equal to or greater than the expiration interval
within the Min-Expires header field of the 423 (Interval Too Brief)
response.
Condition  The registration duration contained in the REGISTER message sent by
the VoBB terminal is less than the minimum registration duration set on
the CSCF.
 After the terminal receives a 423 message, the terminal does not change
the registration duration to the minimum registration duration specified
in the 423 message before sending a REGISTER message.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All CSC3300 versions
Solution
Workarounds
Roll back the configuration.
Preventive Measures
The VoBB terminal configuration needs to be modified. Alternatively, modify the minimum
registration duration of the VoBB terminal and then modify the minimum registration duration
of the VoLTE terminal.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 81


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.6.13 Deregistered Subscriber Is in the Registered State on the


ATS
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom After CNL URCNL is executed on the CSCF to deregister a subscriber, a


third-party REGISTER message is sent to the ATS to deregister the
subscriber. However, the subscriber is still in the registered state on the
ATS.
Trouble N/A
Ticket
Number
Root Cause 1. The third-party REGISTER message does not carry contents in the first-
party REGISTER message. The ATS checks whether the Contact
address of the first-party REGISTER message in the third-party
REGISTER message is consistent with the saved subscriber data. The
ATS deregisters the subscriber only if they are consistent.
2. After SPH211, third-party REGISTER messages for deregistration on
the CSCF carry contents of the first-party REGISTER messages.
However, the third-party registration iFC data configured on the CSCF
shows that the third-party REGISTER messages are not configured to
carry contents in the first-party REGISTER messages. To enable third-
party REGISTER messages carry contents in first-party REGISTER
messages, configure data as follows:
<SPT><ConditionNegated>0</ConditionNegated><Group>5</Group>
<DeregTriggerType>1</DeregTriggerType></SPT>
Condition The registration iFC data configuration on the CSCF is incomplete. As a
result, third-party REGISTER messages do not carry contents in first-party
REGISTER messages.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
CSC3300 V100R010C10SPC200
Solution
Workarounds
N/A
Preventive Measures

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 82


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Load V100R010C10SPH211 or later on the CSCF and modify the third-party registration iFC
data. Add the following data to trigger points:
<SPT><ConditionNegated>0</ConditionNegated><Group>5</Group><DeregTriggerType>1
</DeregTriggerType></SPT>

2.6.14 Third-party Deregistration Fails


Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom A terminal does not update the registration within a specified period of
time. After the registration times out, the terminal initiates a third-party
deregistration. However, the ATS returns a 403 message indicating that the
subscriber to be deregistered does not register.
Trouble N/A
Ticket
Number
Root Cause The CSCF determines whether subscribers' registrations time out using a
second timer. In each second, registrations of a certain number of
subscribers are checked. Therefore, registration timeout determination may
be delayed for 0 to 60s.
The ATS starts a timer for each registered subscriber. When the timer times
out, the ATS deregisters the subscriber immediately.
Therefore, after registration on the CSCF times out, and the CSCF sends a
third-party REGISTER message for deregistration to the ATS, the
subscriber status on the ATS is deregistered. As a result, the ATS returns a
403 message.
Condition The registration of a terminal times out as the terminal does not update the
registration.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
CSC3300 V100R010C10SPC200
Solution
Workarounds
N/A
Preventive Measures

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 83


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

A CSC3300 patch will be released to solve the problem. When a terminal is deregistered due
to registration timeout, the CSCF will not send a REGISTER message for deregistration to the
ATS.

2.6.15 Registration on the 4G Network Is Successful But Calls Fell


Back to the 2G/3G Network When Huawei CSCF Cooperates with
Bell PSBC
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom A VoLTE subscriber in X province (where Huawei CSCF is deployed)


roams to B province (where Bell P-SBC is deployed). The registration is
successful. However, when the VoLTE subscriber makes calls, the calls fell
back to the 2G/3G network.
Trouble N/A
Ticket
Number
Root Cause During registration of the roaming VoLTE subscriber, the REGISTER
message sent by the Bell PSBC contains two Path header fields. One
contains the ATCF address (for SRVCC handover), and the other contains
the SBC address. In the 200 (to REGISTER) message sent by Huawei S-
CSCF, the Service-Route header field contains the S-CSCF address and the
ATCF address in the Path header field of the REGISTER message sent by
Bell PSBC. The registration is successful. However, when the subscriber
makes a call, the Bell SBC sends the INVITE message to the Bell ATCF
instead of Huawei S-CSCF. As a result, the call fails.
Condition Huawei CSCF interworks with Bell PSBC, and the Path header field in the
REGISTER message contains two hop addresses.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
CSC3300 V100R010C10SPC200
Solution
Workarounds
Data configuration on Huawei S-CSCF needs to be adjusted to ensure that the S-CSCF does
not include the address contained in the Path header field of the REGISTER message from the
Bell SBC in the 200 (to REGISTER) message.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 84


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Error tolerance processing is added on the Bell SBC. When the Bell SBC receives a 200 (to
REGISTER) message in which the Service-Route header field contains a local address, the
Bell SBC ignores this address.
Preventive Measures
Set bit 16 of SCSCFPARA2 to 1.
MOD SFP: INSPN=SCSCFPARA2, MODTYPE=P1, BIT=16, BITVAL=1;

Bit 16
Determines whether the S-CSCF adds the Path header field value in a REGISTER message to the
Service-Route header field in a 200 (to REGISTER) message.
= 0: When multiple hop addresses are included in the Path header field of a REGISTER message and bit
7 of PCSCFPARA2 is 0, the S-CSCF adds both the top hop address in the Path header field value of the
REGISTER message and the S-CSCF host name to the Service-Route header field in a 200 (to
REGISTER) message.
= 1: The S-CSCF adds only the S-CSCF host name to the Service-Route header field in a 200 (to
REGISTER) message.
Default value: 0

2.6.16 VoLTE Subscriber Fails to be Called After Roams to the


Alcatel-Lucent PSBC as the P-Associated-URI Contained in the
200 (to REGISTER) Message Does Not Carry a tel URI
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom When a VoLTE subscriber roams to the Alcatel-Lucent PSBC, an error


message is displayed when the VoLTE subscriber is called.
Trouble N/A
Ticket
Number
Root Cause When the INVITE message is sent to the peer P-CSCF, the peer P-CSCF
returns a 404 message because the 200 (to REGISTER) message sent by
Huawei S-CSCF does not carry the tel URI. However, the INVITE
message carries the tel URI, and the Alcatel-Lucent PSBC regards that the
tel URI is illegal.
When some devices, for example, the terminal or P-CSCF do not support
carry the tel URI in the P-Associated-URI header field of INVITE
messages, registration data may fail to be saved. As a result, the terminal or
P-CSCF regards that the registration fails.
The following figure shows the bases for default tel URI settings.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 85


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition Huawei CSCF interworks with the Alcatel-Lucent PSBC.


Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All CSC3300 versions
Solution
Workarounds
N/A
Preventive Measures
Set bit 0 of SCSCFPARA2 to 1.
MOD SFP: INSPN=SCSCFPARA2, MODTYPE=P1, BIT=0, BITVAL=1;

Bit 0
Bit 0 is used for function control.
Determines whether the S-CSCF includes the tel URI in the P-Associated-URI header field of the 200
(to REGISTER) message.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 86


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

= 0: The S-CSCF does not include the tel URI in the P-Associated-URI header field of the 200 (to
REGISTER) message. Instead, the S-CSCF converts the tel URI to a SIP URI carrying the user=phone
parameter and includes the SIP URI in the P-Associated-URI header field of the 200 (to REGISTER)
message.
= 1: The S-CSCF includes the tel URI in the P-Associated-URI header field of the 200 (to REGISTER)
message.
Default value: 0

2.6.17 Subscriber Cannot Make or Receive Calls After the


Registration Is Updated, Which Is Restored After the Subscriber
Initiates a Registration Again
Involved NE: CSC3300 and SBC
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom At 09:06, a subscriber sends a REGISTER message carrying the


authentication information. The S-CSCF returns a 200 message directly
(without authentication). The re-registration is successful, and the call is
normal.
At 09:52, the subscriber sends a REGISTER message again (with the
terminal IP unchanged) without authentication information. The SBC
forwards the REGISTER message to the S-CSCF. The S-CSCF does not
perform authentication, and returns a 200 message directly. When the
subscriber sends an INVITE message to make a call, the SBC returns a 403
message (invalid user) directly. When the subscriber is called and sends
183 message to the SBC, the SBC does not make any response.
At 09:57, the subscriber sends a REGISTER message without
authentication information using the same IP address to the S-CSCF. The
S-CSCF returns a 401 message. The subscriber sends another REGISTER
message, and the S-CSCF returns a 200 message. The registration is
complete, and subsequent MO and MT services are normal.
Trouble N/A
Ticket
Number
Root Cause According to the signaling tracing result, after the CSCF receives a
REGISTER message, it directly returns a 200 message regardless of
whether the REGISTER message carries authentication information. No
authentication times of re-register is set to a value other than 0
(maximum value is 5) by running MOD SREG on the CSCF. If integrity-
protected=yes is carried in the Authentication header field of REGISTER
messages for re-registrations and the number of re-registrations without
authentication is within the value of No authentication times of re-
register, the CSCF directly returns a 200 message without authentication.
The subscriber cannot make or receive calls after the registration is updated
because the SE2900 (P-SBC) incorrectly determine the port number
information.
When the UE sends a REGISTER message using plaintext, the PSBC

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 87


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

determines that the REGISTER message is used for re-registration as the


PSBC saves the previous registration information of the UE. In this case,
the PSBC includes integrity-protected=yes in the REGISTER message and
forwards the REGISTER message to the S-CSCF. As a result, the S-CSCF
directly returns a 200 message instead of a 401 message. The 200 message
forwarded by the PSBC to the UE does not carry the Security-Server
header field, and the UE determines that the IPSec negotiation with the P-
CSCF fails. In this case, when the UE sends an INVITE message using
plaintext to initiate a call, the UE uses the port number used for
registration, which is inconsistent with the port number saved on the PSBC.
As a result, the PSBC returns a 403 message.
Condition When a registered UE initiates a re-registration using plaintext, No
authentication times of re-register on the CSCF is not set to 0 and the
integrity-protected parameter in the first REGISTER message originating
from the registered UE is set to no on the SE2900.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All SE2900 versions
Solution
Workarounds
N/A
Preventive Measures
MOD PCSCF: PCSCFLEN="XXXXXX", PHEADERPL=INTPRO_NO-1;
PHEADERPL: This parameter specifies the P-CSCF header field processing policy.
INTPRO_NO(Setting integrity-protected to no): The P-CSCF embedded in the SBC sets the
integrity-protected parameter in the first REGISTER message originating from a registered
UE to no.
After modification, integrity-protected is set to yes for REGISTER messages for re-
registration using ciphertext and no for REGISTER messages for re-registration using
plaintext.

2.6.18 CSCF Returns 403 Messages When Different Subscribers


Use the Same Call-ID to Initiate Registrations
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom Call-ID of the GIONEE F100 terminal is asbcQWh19pSh1o3lGM7HwSY,

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 88


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

and IMSI is 46002057443****.


The GIONEE F100 terminal sends a REGISTER message to the CSCF
through PSBC01, and the CSCF returns a 401 message. When the VOVO
X6D terminal with the same Call-ID and tag as but different IMSI
(46002707773****) from that of the GIONEE F100 terminal sends a
REGISTER message to the CSCF through PSBC02, the CSCF returns a
403 message carrying "Conflictiveuser"."
Trouble N/A
Ticket
Number
Root Cause The CSCF uses the Call-ID parameter to associate REGISTER messages
before and after the 401 message. If the two REGISTER messages have the
same IMPU, the CSCF rejects the registration and returns a 403 message.
The CSCF processing mechanism is based on the RFC3261: In a new
request created by a UAC outside of any dialog, the Call-ID header field
MUST be selected by the UAC as a globally unique identifier over space
and time unless overridden by method-specific behavior. All SIP UAs must
have a means to guarantee that the Call-ID header fields they produce will
not be inadvertently generated by any other UA.
Condition Two subscribers use the same Call-ID to initiate registrations.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
GIONEE F100 and VOVO X6D terminals
Solution
Workarounds
N/A
Preventive Measures
Call-ID of terminals must be unique.

2.6.19 CSCF Connects a Call After Receiving a 405 Message from


the AS
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom After the CSCF receives an INVITE message from a UE, the CSCF
contacts the AS based on the iFC data. The AS returns a 405 message, and
the CSCF forwards the INVITE message to the MGCF. However, the

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 89


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

CSCF is configured to connect calls after receiving a 500 message instead


of a 405 message from the AS.
Trouble N/A
Ticket
Number
Root Cause According to the SEQ tracing result, the S-CSCF does not transparently
forward the 405 message received from the SCP AS to the UE. Instead, it
continues to send the INVITE message to the MGCF.

The CSCF is not configured to continue a call when receiving a 405


message from the AS and will not continue the call according to the NE
implementation. When the problem is reproduced, we found that the 405
message returned by the SCP AS does not carry the Allow header field,
which does not comply with the RFC3261 protocol. As a result, the CSCF
converts the 405 message to a 500 message and continues the call.

21.4.6 405 Method Not Allowed


The response MUST include an Allow header field containing a list of
valid methods for the indicated address.
Condition The 405 message does not carry the Allow header field.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All CSC3300 versions
Solution
Workarounds
N/A
Preventive Measures

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 90


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

It is recommended that configuration on the AS be modified to ensure that the Allow header
field is included in 405 messages.

2.6.20 CSCF Sends a BYE Message Immediately After the Called


Party Answers the Call
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom The CSCF sends a BYE message immediately after the called party
answers the call for a subscribed-to service. The BYE message carries
Reason:SIP;text="SessionTimerCheckMessageFailedforINVITE2xx."
Trouble N/A
Ticket
Number
Root Cause 1. According the BYE message information, the refresher parameter in the
Session-Expires header field of the 200 (to INVITE) message is uac, but
the Require header field in the 200 (to INVITE) message does not carry
the timer parameter.

2. Check of protocol compliance defined by running MOD STMR is


used to check whether session timer related parameters are checked
according to the RFC4028 protocol.
3. The CSCF sends the BYE message because the 200 message sent by the
AS does not carry Require:timer.
The following describes scenarios for checking whether session timer
related parameters are processed according to the RFC4028 protocol.
RFC4028
For session timer related parameter negotiation, refresher is uac and the

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 91


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

timer parameter is carried in the Supported and Require header fields of


2XX messages.
9.UAS Behavior
If the refresher parameter in the Session-Expires header field in the 2xx
response has a value of 'uac', the UAS MUST place a Require header field
into the response with the value 'timer'. This is because the uac is
performing refreshes and the response has to be processed for the UAC to
know this.
 During session timer related parameter negotiation, the Session-Expires
value in 2XX messages must be less than the value of Min-SE in
requests. If Min-SE is not included in requests, the Session-Expires
value must be greater than or equal to 90.
 During session timer related parameter negotiation, the value of Session-
Expires in the INVITE message must be less than that in the 200
message.
If the UAS wishes to accept the request, it copies the value of the Session-
Expires header field from the request into the 2xx response. The UAS
response MAY reduce its value but MUST NOT set it to a duration lower
than the value in the Min-SE header field in the request, if it is present;
otherwise the UAS MAY reduce its value but MUST NOT set it to a
duration lower than 90 seconds. The UAS MUST NOT increase the value
of the Session-Expires header field.
 During session timer related parameter negotiation, if the Session-
Expires header field in the 2XX message does not carry the refresher
parameter, and the Supported header field does not carry the timer
parameter, the CSCF sends a BYE message to release the call. If the
timer parameter is included in the Supported header field, RFC4028 is
supported. Therefore, the refresher parameter carried in 2XX messages
must meet the following requirements:
The UAS MUST set the value of the refresher parameter in the Session-
Expires header field in the 2xx response.

 During session timer related parameter negotiation, if the refresher


parameter is not included in the Session-Expires header field of the
2XX message, the CSCF sends a BYE message to release the call in any
of the following scenarios:
 The refresher parameter is included in the Session-Expires header field of
the request.
 The values of the Session-Expires header fields in the request and
response are different.
 During session timer related parameter negotiation, if the refresher
parameter in the request is uas, and it is changed to uac in the response,
the call is not released. Otherwise, the call is released.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 92


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

 The CSCF returns a 400 message if the request meets any of the
following conditions:
− The refresher parameter is included in the Session-Expires header
field and the timer parameter is included in the Supported header
field.
− The Session-Expires value is less than 90s.
− The Session-Expires value is less than the Min-SE value.
Condition  Check of protocol compliance is set to Yes on the CSCF.
 The value of Session-Expires in the INVITE message is less than the
value of Session-Expires in the 200 message.
 The refresher parameter in the Session-Expires header field of the
INVITE message is uac. However, the 200 (to INVITE) message does
not carry the Require header field, or the Require header field does not
carry the timer parameter.
Probability This issue occurs if the preceding conditions are met.
of
Occurrence

Involved Version
All CSC3300 versions
Solution
Workarounds
N/A
Preventive Measures
Modify data configuration on NEs that do not comply with protocols.

2.6.21 Originating S-CSCF Returns a 500 Message for a Call


Between Two IMS Subscribers After Querying the ENUM Server
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details

Symptom IMS subscriber A calls IMS subscriber B. After the originating S-CSCF
queries the ENUM server, it returns a 500 message. The Warning header
field in the 500 message carries 399
37963.2172.S.261.5.105.0.27.544839.0.0.xx.xxx.com "Number Analysis
Failed."
Trouble N/A
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 93


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause The printed information shows that the S-CSCF processes the ENUM
return result incorrectly.
The following printed information shows the current configuration:
<NaConvertEnumQuryResult>] NaConvertEnumQuryResult: Call
SAdaptEnumHandleNaptrURI failed!ulRet=[9], MatchPlus=[1],
MatchFailPly=[1]
The ulRet value is not 0, which indicates that matching or replacement
fails.
The MatchPlus value is 1, which indicates that the value of bit 1 of
SCSCFPARA8 is 1.
The MatchFailPly value is 1, which indicates that the value of bit 6 of
SCSCFPARA8 is 1.
The matching expression returned by the ENUM server carries the plus
sign (+). In regular expressions, the plus sign (+) means to match the
preceding subexpression one or more times. To match the plus sign (+)
itself, add an escape character (\) before the plus sign (+).

The following figure shows the correct configuration.


For example, if the ENUM server is embedded in the CSCF, the query
result is as follows:

Condition The regular expression configuration on the ENUM server is incorrect.


Probability This issue will occur when the preceding condition is met.
of

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 94


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Occurrence

Involved Version
All CSC3300 versions
Solution
Workarounds
N/A
Preventive Measures
Modify configuration on the ENUM server to ensure that the regular expression returned by
the ENUM server has the escape character (\) added before the plus sign (+).

Bit 1 of SCSCFPARA8
Bit 1 is used for function control.
Determines whether the S-CSCF prefixes the E.164 number (converted from the subscriber number)
with the plus (+) sign to match the regular expression after querying the ENUM server is successful.
Value:
= 0: The S-CSCF does not prefix the E.164 number (converted from the subscriber number) with the
plus (+) sign to match the regular expression.
= 1: The S-CSCF prefixes the E.164 number (converted from the subscriber number) with the plus (+)
sign to match the regular expression.
Default value: 0
In other words, bit 1 determines whether the S-CSCF adds a plus sign (+) before the subscriber number
used to match the regular expression returned by the ENUM server. For example, the subscriber number
is 8675510000016, and the regular expression returned by the ENUM server is \+86755(.*).
If 8675510000016 is used to match \+86755(.*), the matching fails. If +8675510000016 is used to match
\+86755(.*), the matching is successful.
Bit 6 of SCSCFPARA8
Bit 6 is used for function control.
Determines whether the CSCF continues to route the call or rejects the call when it fails to match the
called number with the regular expression obtained by querying the ENUM/NP server based on the
called number.
Value:
= 0: The CSCF continues to route the call when the replacement expression returned by the ENUM/NP
server is a specific number. If the replacement expression returned by the ENUM/NP server is not a
specific number, the CSCF rejects the call.
= 1: The CSCF rejects the call.
Default value: 1

2.6.22 Teleconference Fails After a VoLTE Video Call Falls Back


to a Voice Call
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting: Lin Guoqiang (employee ID: 00342085)

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 95


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Defect Details

Symptom VoLTE subscriber A initiates a voice call to subscriber B, and B answers


the call.
A switches the voice call to a video call, and B answers the call.
A switches the video call back to a voice call, and B answers the call.
A invites C to the call, and B hears an announcement stating that "The
subscriber you dial is using the call hold function. Please wait."
After C answers the call, A presses the a key to merge calls. However, B
hangs up, and the call between A and C is normal.
NOTE
The preceding problem recurs when the three test terminals serve as the calling and
called parties in polling mode. If only the VoLTE voice service is used during the
third-party call, the preceding problem does not occur.

Trouble N/A
Ticket
Number
Root Cause According to tracing result of messages sent by the VoLTE AS and MRFC,
when A sends a call merging request, the MRFC sends a 488 message to
release the call.
The Warning header field carries 399
0448202576.MRFC.xx.xxx.com.250.007.102.0000002D.00000000 "Get
SDP fail."
The INVITE message sent to the MRFC carries the transport attribute
RTP/AVPF. In versions earlier than V100R010C10SPH205, the MRFC
does not support the transport attribute. In V100R010C10SPH205 or later,
bit 12 of MRCPARA8 is added to control whether the MRFC supports the
transport attribute.

Condition The AVPF is carried in the SDP body of the INVITE message.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All CSC3300 versions
Solution

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 96


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Workarounds
N/A
Preventive Measures
For CSC3300 V100R010C10SPH205 or later versions, set bit 12 of MRCPARA8 to 1.
MOD SFP: INSPN=MRCPARA8, MODTYPE=P1, BIT=12, BITVAL=1;

Bit 12 of MRCPARA8
Bit 12 is used for function control.
Determines whether the MRFC changes RTP/AVPF included in the SDP body of INVITE messages to
RTP/SAVP.
Value:
= 0: The MRFC does not change RTP/AVPF included in the SDP body of INVITE messages to
RTP/SAVP.
= 1: The MRFC changes RTP/AVPF included in the SDP body of INVITE messages to RTP/SAVP.
Default value: 0

2.7 Fault Cases for April 2016


2.7.1 Called UE Returns a 488 Message
Involved NE: SBC
Applicable Scope: global
Troubleshooting Engineer: Chen Xingwu (ID: 00145812)
Defect Details

Symptom The SBC receives hundreds of 488 messages for mobile terminated (MT)
calls every day. These failed calls are from VoBB subscribers to VoLTE
subscribers. Traced messages show that a VoLTE UE returns a 488 message
after receiving an INVITE message from the SBC.
Trouble N/A
Ticket
Number
Root Cause In the SDP body of the INVITE message sent from the SBC to the VoLTE
UE, G.711 and telephone-event codecs are carried but AMR and AMR WB
are not.
An example SDP body is as follows:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 97


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The SBC is configured to include the locally supported codecs in the SDP
body.
Further analysis shows that only a small proportion of calls from VoBB
subscribers to VoLTE subscriber fail.
In these failed calls, the SDP body in the INVITE messages sent from the
VoBB UEs carry "a=silencesupp: off - - - -", which is not carried in
successful calls from VoBB subscribers to VoLTE subscribers.
The INVITE messages sent from the S-CSCF to the SBC also carry
"a=silencesupp: off - - - -". As a result, the SBC processes the calls as faxes
and does not include AMR or AMR WB in the INVITE messages sent to
the VoLTE UEs. VoLTE UEs from Apple cannot use G.711 to establish
calls and return 488 messages.
Condition A VoBB subscriber calls a VoLTE subscriber, and the SDP body in the
INVITE message sent from the VoBB UE carries "a=silencesupp: off - - -
-".
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Versions
SE2900 V300R001C20SPC100
Solution
Workarounds:
N/A
Preventive measures:
Run MOD TCCAP on the SBC to enable the SBC not to process calls that carry
"a=silencesupp" as faxes.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 98


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.7.2 RTA Message Does Not Carry the Origin-Host and Origin-
Realm AVP
Involved NEs: CSCF and HSS
Applicable Scope: global (sites that interwork with the NSN HSS)
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom The NSN HSS sends an RTR message to deregister a UE, and the S-CSCF
responds with an RTA message that does not carry the Origin-Host and
Origin-Realm AVP. The NSN HSS determines that the RTA message does
not comply with 3GPP TS 29.229 and rejects it.
Trouble N/A
Ticket
Number
Root Cause The structure of the RTA message is defined as follows in 3GPP TS 29.229:

The Origin-Host and Origin-Realm AVPs are mandatory in the RTA


message.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 99


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition  The Huawei CSCF interworks with the NSN HSS.


 The CSCF version is earlier than CSC3300 V100R011C10SPH103.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Versions
CSC3300 V100R11C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
CSC3300 V100R011C10SPH103 has been developed to resolve this issue.

2.7.3 VoLTE Subscriber Fails to Send a Short Message After a


LTE-to-3G Handover
Involved NEs: ATS and HSS
Applicable Scope: America (sites that use the ANSI protocol)
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 100


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Symptom After a handover from an LTE network to a 3G network, a VoLTE


subscriber does not send a deregistration message to the IMS network.
Consequently, the subscriber fails to send short messages.
Trouble 5801773
Ticket
Number
Root Cause The detailed flow is as follows:
1. The IP-SM-GW fails to send a short message over the IMS network.
2. The IP-SM-GW sends an SRI message to the HLR to request the MSC
server information, but the HLR sends the message back to the IP-SM-
GW. The SRI message sent from the HSS is incorrect.
Specifically, the IP-SM-GW fills the MSC server's global title (GT)
code padded with a zero in the Called address field, because the original
MSC server's GT code contains 11 digits. The HLR detects that the
received GT code is different from any stored one and therefore does
not forward the message to the required MSC server. Instead, the HLR
sends the message back to the IP-SM-GW. An example GT code padded
with a zero is as follows:

ADD
SCCPGT:GTNM="LOCAL_00",NI=NAT,GTI=GT6,TRANSLATETY
PE="00",ADDR=K'197XXXX9441,RESULTT=LSPC2,SPC="H'023D
6E";
The following figure shows the enhanced short message routing flow
(routing preferentially to the IMS domain):

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 101


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The root cause is as follows: ANSI used at America sites does not
specify the odd/even flag in SRI messages. As a result, the HLR cannot
process the SRI messages correctly.
Condition The ANSI protocol is used for GT translation.
Probability This issue may occur when the preceding condition is met.
of
Occurrence

Involved Versions
ATS9900 V100R08C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
An HSS9860 patch will be released to enable the HLR to determine whether to perform
maximum prefix matching.

2.7.4 No-reply Timer in the Default Call Forwarding upon No


Reply Service Uses an Incorrect Value
Involved NE: ATS
Applicable Scope: global

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 102


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Troubleshooting Engineer: Yang Erjie (ID: 00191244)


Defect Details

Symptom A VoLTE subscriber has subscribed to the default call forwarding upon on
reply service. The duration of the no-reply timer applied for the subscriber
is different from the value of default no reply timer configured on the
ATS.
Trouble 5978726
Ticket
Number
Root Cause Three parameters in ADD MSR or MOD MSR are related to the CFNR
timer:
Parameter 1: no reply timer under subscriber communication diversion

Parameter 2: CFD no reply timer under actions of rule set

Parameter 3: default no reply timer under operator communication


diversion

When parameter 2 is not specified, the ATS preferentially selects the value
of parameter 1. However, the ATS should preferentially select the value of
parameter 3 if parameter 2 is not specified for the default call forwarding
upon on reply service.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 103


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

In the preceding subscriber data:


"NotReplyTime = 5" maps to parameter 1.
"NotReplyTime = 30" maps to parameter 3.
Condition The ATS version is earlier than ATS9900 V100R008C10SPH115.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Versions

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 104


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

ATS9900 V100R008C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
ATS9900 V100R008C10SPH115 has been developed to resolve this issue.

2.7.5 SCU Module Restarts When More Than Two Extended


Header Fields Are Removed
Involved NE: CSCF
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom SIP signaling filtering data is configured on the CSCF to enable the CSCF
to remove multiple extended header fields. When the CSCF removes more
than two extended header fields, the SCU module restarts.
Trouble 5968959
Ticket
Number
Root Cause When the CSCF removes the first extended header field, the extended
header field pointer configured by the CSCF is null. When the CSCF
processes the second extended header field, an exception occurs during the
memory access. Consequently, the SCU module restarts.
Condition The CSCF is configured to remove multiple extended header fields.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Versions
CSC3300 V100R11C10SPC100
Solution
Workarounds:
Delete the SIP signaling filtering data on the CSCF.
Preventive measures:
A CSC3300 patch will be released in May 2016.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 105


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.7.6 SCC AS Sends a 480 Message Carrying "No appropriate


session for SRVCC/eSRVCC" for a bSRVCC Handover
Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: Huang Jianguo (ID: 00135928)
Defect Details

Symptom A calls B. Before B is alerted, A's UE initiates a handover. The call fails to
be connected.
Trouble N/A
Ticket
Number
Root Cause The traced messages on the SEQ show that:
1. Media negotiation is complete using 183, PRACK, and 200 messages.
The SCC AS receives an UPDATE message from the calling UE and
forwards it to the called UE. Before receiving a 200 (to UPDATE)
message from the called UE, the SCC AS receives an INVITE message
from the SBC for a handover.
2. The SCC AS responds with a 480 message carrying "No appropriate
session for SRVCC/eSRVCC" to the handover request.
3. The SCC AS also sends a CANCEL message to the called UE and a
480 message carrying "No appropriate session for SRVCC/eSRVCC" to
the calling UE.

The root cause is as follows: The SCC AS always sends a 480 message to
reject a handover request if the session and media are unstable. In this
failed call, the transaction associated with the UPDATE message (mostly
the precondition flow) is not complete. Therefore, the handover is a type of
bSRVCC handover, which is supported only by ATS9900 V100R008C20
and later versions.
A Warning header field is as follows:
Warning: 399
2283028.239.ATS.sccas01b.sccas.xxxxx.ims.mnc000.mcc460.3gppnetwor
k.org.13.608 "No appropriate session for SRVCC/eSRVCC"
Condition A bSRVCC handover occurs.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Versions

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 106


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

ATS9900 V100R006C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Upgrade the ATS9900 to V100R008C20 to support bSRVCC handovers.

2.7.7 SCC AS Sends a 480 Message Carrying "Do not match switch
condition" for a bSRVCC Handover
Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: Huang Jianguo (ID: 00135928)
Defect Details

Symptom A calls B. At the moment when B is alerted, A's UE initiates a handover.


The call fails to be connected.
Trouble N/A
Ticket
Number
Root Cause The traced messages on the SEQ show that:
1. The SCC AS receives a 180 message carrying the Require header field
with the value set to 100rel. Before receiving a PRACK message from
the calling UE, the SCC AS receives an INVITE message from the SBC
for a handover.
2. The SCC AS responds with a 480 message carrying "Do not match
switch condition" to the handover request.
3. The SCC AS also sends a CANCEL message to the called UE and a 480
message carrying "Do not match switch condition" to the calling UE.

The root cause is as follows: The SCC AS always sends a 480 message to
reject a handover request if the session and media are unstable. In this
failed call, the transaction associated with the 180 message (mostly the
precondition flow) is not complete. Therefore, the handover is a type of
bSRVCC handover, which is supported only by ATS9900 V100R008C20
and later versions.
A Warning header field is as follows:
Warning: 399

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 107


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2283028.815.ATS.hzsccas01bhw.sccas.zj.ims.mnc000.mcc460.3gppnetwor
k.org.13.619 "Do not match switch condition"
Reason: Q.850;cause=66;text="channel type not implemented"
Condition A bSRVCC handover occurs.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Versions
ATS9900 V100R006C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Upgrade the ATS9900 to V100R008C20 to support bSRVCC handovers.

2.7.8 ESN Cannot Be Obtained When More Than Four IP


Addresses Are Configured for the ATS
Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: Wu Junlin (ID: 00365955)
Defect Details

Symptom A capacity expansion is performed on a VoLTE or IMS network. After the


capacity expansion, more than four IP addresses are configured for the
ATS. The ESN cannot be obtained, and a license cannot be applied for the
ATS.
Trouble N/A
Ticket
Number
Root Cause The GetEsn tool of V3.1 generates an ESN for the ATS configured with
four or less IP addresses. If more than four IP addresses are configured, the
tool cannot generate an ESN.
Condition More than four IP addresses are configured for the ATS after capacity
expansion.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 108


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Versions
All ATS9900 versions
Solution
Workarounds:
1. Use the GetEsn tool of V2.8.
2. Specify the parameters as follows:
a. Sequence the IP addresses based on the IFM module number from the smallest to
the largest.
b. If multiple IP addresses are configured for the same IFM module number, sequence
the IP addresses based on their values. For example, if 10.85.133.130 and
10.85.133.131 are configured for the same IFM module number, sequence
10.85.133.130 before 10.85.133.131.
c. Fill the IP addresses in IPv4 format in the input area of the GetEsn tool to obtain an
ESN.

Preventive measures:
Contact Huawei technical support engineers to optimize the GetEsn tool.

2.7.9 Call Is Released Because the MSC Server Fails to Receive a


PRACK Message Before the Timer Expires
Involved NE: MSC server and Samsung UE
Applicable Scope: global
Troubleshooting Engineer: Wu Junlin (ID: 00365955)
Defect Details

Symptom A VoLTE UE from Samsung calls a CS subscriber. The call is abnormally


released after being connected. A large number of records SIPAPP module
times out.timer_name =SIP_CALL_TMR_WAIT_PRACK_IN,
timer_length =32000 are displayed in CHRs generated by the MSC server.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 109


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause

The call flow is as follows:


1. A calls B, and an INVITE message is sent to the terminating MSC
server. The terminating MSC server returns a 183 message, and the
calling UE sends a PRACK message.
2. Before sending a 200 (to PRACK) message, the terminating MSC
server receives an ACM message from the called UE, converts the ACM
message to a 180 message, and sends the 180 message to the calling
UE.
3. The calling UE receives the 180 message but does not send a PRACK
message to indicate that it has received the 180 message. Even after
receiving a retransmitted 180 message, the calling UE does not respond
with a PRACK message. As a result, an internal timer of the MSC
server expires, causing the call to be released.
Condition 1. A VoLTE UE from Samsung is used, and the User-Agent header field
with the value Samsung IMS 5.0 is carried in messages sent by the UE.
2. The UE receives a 180 message prior to a 200 (to PRACK) message.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Versions
All MSOFTX3000 versions

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 110


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Solution
The UE is defective and should be improved.
Workarounds:
N/A
Preventive measures:
Ask the UE vendor to rectify the fault.

2.7.10 Encrypted SIP Signaling Hinders Fault Location


Involved NE: UGW
Applicable Scope: global
Troubleshooting Engineer: Zhang Hao (ID: 00338320)
Defect Details

Symptom The UGW is always required to locate VoLTE faults. However, packets
captured on the UGW contain a large amount of encrypted data, which
hinders fault location.
For example, if you filter SIP packets directly without performing a
decryption, only 401 and REGISTER messages can be obtained. Data after
the authentication is encrypted using ESP and cannot be parsed. Example
messages are as follows:

Trouble N/A
Ticket
Number
Root Cause In a VoLTE call, signaling plane data is protected by using IPsec to perform
integrity protection and encryption. As defined in GSMA IR.92, if IMS
AKA authentication is used between UEs and IMS networks, integrity
protection is mandatory but encryption is optional. However, encryption is
enabled for most commercial sites.
Condition The encryption function is enabled.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 111


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Versions
All UGW9811 versions
Solution
Workarounds:
N/A
Preventive measures:
Configure the Wireshark to decrypt packets that are encrypted using IPsec.
Configure the Wireshark as follows:

Obtain the parameter values as follows:


1. Obtain msip from messages traced on the UGW.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 112


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2. Obtain ealg and alg from the 401 message sent by the P-CSCF.

3. Obtain the CK and IK parameters from the 401 message sent from the S-CSCF to the P-
CSCF.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 113


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

After the configuration, the Wireshark can be used to decrypt SIP packets.

2.8 Fault Cases for March 2016


2.8.1 Inconsistent AMR Parameters Cause One-Way Audio
Involved NE: SBC
Applicable Scope: global
Troubleshooting Engineer: Wu Junlin (ID: 00365955)
Defect Details

Symptom When the call from a VoLTE subscriber to another VoLTE subscriber
roaming in the 3G network is connected, the calling party cannot hear the
called party, causing one-way audio.
Trouble N/A
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 114


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause

1. The blue arrows indicate the signaling messages when this issue occurs.
When the MGCF sends an INVITE message to the MSC server, the
INVITE message carries AMT pt=118 for the calling party. However,
the peer end returns AMR pt=108.
2. When the MGCF instructs the UMG to use pt=108 but the media
streams sent by the called party use pt=118, the UMG discards the
streams, causing one-way audio.
3. As stipulated in RFC 3264, the PT value in the Offer indicates the PT
value supported by the local end, and when the peer end uses the PT
value in the Offer to sent RTP streams, the local end should support this
action.
For recvonly RTP streams, the payload type numbers indicate the value of
the payload type field in RTP packets the offerer is expecting to receive for
that codec. For sendonly RTP streams, the payload type numbers indicate
the value of the payload type field in RTP packets the offerer is planning to
send for that codec. For sendrecv RTP streams, the payload type numbers
indicate the value of the payload type field the offerer expects to receive,
and would prefer to send. However, for sendonly and sendrecv streams,
the answer might indicate different payload type numbers for the same
codecs, in which case, the offerer MUST send with the payload type
numbers from the answer.
Condition 1. The call traverses the MGCF, and the PT value in the AMR used by the
receiving direction is different from that in the AMR used by the
sending direction.
2. The peer end uses the PT value in the Offer, instead of the PT value in
the Answer, to send media packets.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Versions
MGCF V200R010C020SPC100 and MGCF V200R010C030SPC100
Solution
Workarounds:
Solution 1:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 115


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Run MOD SIPTG on the MGCF (MSC server) with Peer does not allow a change in the
PT value selected for Extra software parameter 3 of service control. After this selection,
the MSC server negotiates about the same PT value with the peer end.
MOD SIPTG: TGN="xxx", ESFPARA3=SRV30-1;
This software parameter determines whether the peer end allows a change in the PT value. If
this value option is selected, the peer end cannot change the PT value. In this case, the codec's
PT value in an SDP response returned by the MSOFTX3000 must be the same as the PT value
in an SDP request received from the peer end. In addition, if the MSOFTX3000 needs to send
an SDP renegotiation request to the peer end, the codec's PT value in the request must be the
same as that received from the peer end during the previous negotiation. After receiving
media information from the peer end, the MSOFTX3000 does not send a renegotiation
request to the peer end, if the MSOFTX3000 has completed the media negotiation with the
peer end and the negotiation result does not change.
Solution 2:
Run MOD SIPTG on the MGCF (MSC server) with Peer uses different PT values in the
receiving and sending channels selected for Extra software parameter 3 of service
control. After this selection, the re-INVITE/200 message exchange is added to the service
flow, as indicated by the red arrows.
MOD SIPTG: TGN="xxx", ESFPARA3=SRV31-1;
This software parameter determines whether the peer end can use different PT values when
receiving and sending bearer information. If this value option is selected, the peer end can use
different PT values when receiving and sending bearer information. In this case, the preferred
codec's PT value in an SDP response returned by the MSOFTX3000 must be the same as the
PT value in an SDP request received from the peer end. If the MSOFTX3000 detects that the
preferred codec's PT value in the SDP response received from the peer is different from that in
the SDP message sent to the peer end, it must send a renegotiation request carrying the
received PT value to the peer end. If this value option is not selected, the peer end must use
the same PT value when receiving and sending bearer information.
Preventive measures:
Prefer solution 1.

2.8.2 Inconsistent AMR Codec Attributes Cause One-Way Audio


Involved NE: SBC
Applicable Scope: global
Troubleshooting Engineer: Wu Junlin (ID: 00365955)
Defect Details

Symptom When the call from a VoLTE subscriber to another VoLTE subscriber
roaming in the 3G network is connected, the calling party cannot hear the
called party, causing one-way audio.
Trouble N/A
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 116


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause

1. As shown in the preceding figure, the INVITE message sent by VoLTE


subscriber A carries 108 AMR and octet-align =1, but the 200 message
returned by the peer end carries 108 AMR and mode-set =1.
2. When the SBC detects the difference, it discards RTP packets, causing
one-way audio.
Condition 1. The call traverses the SBC, the AMR codec is used in the Offer and
Answer, but the AMR codec attribute in the Answer is different from
those in the Offer (one is octet-align =1 and the other is mode-set =1).
2. The peer end uses the AMR codec attribute in the Answer to send RTP
packets.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
SBC V100R002C00SPC200
Solution
Workarounds:
On the SBC, enable payload type switch.
MOD BCPLC: BCPLCNAME="DEFAULTABCFBCPLC", PTTRANS=Y;
Preventive measures:
On the SBC, enable payload type switch.
MOD BCPLC: BCPLCNAME="DEFAULTABCFBCPLC", PTTRANS=Y;

2.8.3 AGCF ua-profile Subscription Fails


Involved NEs: AGCF and ATS
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 117


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Symptom AGCF ua-profile subscription fails in ATS VCU scenarios.


Trouble N/A
Ticket
Number
Root Cause 1. The user message tracing result shows that the Route header field in the
SUBSCRIBE message received by the ATS from the S-CSCF contains
two values. The first value is the ATS host name, and the second value
is the S-CSCF address. This is because the S-CSCF needs to contact the
ATS through the iFC and add the S-CSCF address when it receives a
SUBSCRIBE message from the AGCF. When the ATS processes the
SUBSCRIBE message, it sends the SUBSCRIBE message to the S-
CSCF (as indicated in the following figure) based on the second Route
header field value. However, the correct behavior is that the ATS does
not forward the SUBSCRIBE message to the S-CSCF after receiving a
ua-profile subscription.

Currently, the VCU does not support explicit ua-profile subscription.


Therefore, change the ua-profile subscription mode to implicit on the
AGCF for the subscriber and change data on the ATS to enable the
subscriber to support implicit ua-profile subscription. After these
changes, this issue is resolved.
Condition  The AGCF sends an explicit ua-profile subscription message.
 The ATS uses the VCU to process services.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R06C10SPC100
Solution
Workarounds:
N/A

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 118


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Preventive measures:
Change the ua-profile subscription mode to implicit on the AGCF for the subscriber and
change data on the ATS to enable the subscriber to support implicit ua-profile subscription.

2.8.4 CSCF Incorrectly Uses Secure IP Addresses to Forward BYE


Messages from Called Parties to Calling Parties
Involved NE: CSCF
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom The CSCF incorrectly uses secure IP addresses to forward BYE messages
from called parties to calling parties.
Trouble N/A
Ticket
Number
Root Cause 1. The details are as follows:
Three IP addresses, 66, 192, and 194 have been configured on the S-
CSCF. 192 and 194 are secure IP addresses (ANIT configuration) used
to interwork only with Diameter devices.
However, at the P2 phase, the S-CSCF selects the IP address 194 to
send a BYE message from the called party to the I-SBC.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 119


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The reason is as follows:


At the P1 phase, the I-CSCF sends an INVITE message to the IP
address 194 of the S-CSCF. The S-CSCF records the IP address. At the
P2 phase, the S-CSCF preferentially selects the recorded IP address
194. However, as the IP address 194 is used for interworking only with
Diameter devices, it cannot be used to send the BYE message to the I-
SBC.
Condition Secure IP addresses have been configured on the S-CSCF, and these IP
addresses support SIP over UDP.
Probability This issue may occur when the preceding condition is met.
of
Occurrence

Involved Version
CSCF3300 V100R011C10SPC100

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 120


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Solution
Workarounds:
N/A
Preventive measures:
The customer allows use of only the IP address 194 to interwork with Diameter devices.
Therefore, disable SIP over UDP for this IP address so that this IP address is not selected to
send SIP messages.

2.8.5 After Subscriber Migration, Alarms Indicating That Remote


Addresses Are Unreachable Are Generated
Involved NEs: CSCF and HSS
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom After subscriber migration, alarms indicating that remote addresses are
unreachable are generated.
Trouble N/A
Ticket
Number
Root Cause 1. The details are as follows:
Step 1: Subscriber A has registered at site 1.
Step 2: Subscriber A at site 1 is migrated to site 2.
Step 3: Site 1 does not work any more, for example, because of
hardware removal.
After several days (subscriber A's registration at site 1 has expired),
when B calls A, an alarm is generated, indicating that the route from the
S-CSCF at site 2 to the P-CSCF at site 1 is unreachable.
The reason is as follows:
Site 1 does not work (each device at site 1 do not work). Although
subscriber A's registration at site 1 has expired, the S-CSCF at site 1
cannot send an SAR message to deregister subscriber A from the HSS.
This causes the HSS to retain subscriber A's registration information,
such as the Path header field value (P-CSCF host name at site 1).
When a call is addressed to subscriber A, the MT redundancy flow is
triggered. That is, subscriber A's data (including the P-CSCF host name
at site 1) is downloaded from the HSS. This causes the S-CSCF at site 2
to send an INVITE message to the P-CSCF at site 1. Obviously, the S-
CSCF at site 2 cannot receive any response and therefore enables
heuristic OPTIONS detection. After this detection fails several times,
the S-CSCF at site 2 generates an alarm indicating that the remote
address is unreachable and adds the P-CSCF address at site 1 to the
OPTIONS detection blacklist.
Condition  Subscribers at site 1 have been migrated but have not initiated a

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 121


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

registration to site 2.
 The S-CSCF at site 1 does not work. That is, when a subscriber's
registration expires, the S-CSCF cannot send an SAR message to
deregister the subscriber from the HSS.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
CSCF3300 V100R010C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
1. After the subscriber initiates a registration, this issue is resolved.
2. If such subscribers cannot be identified on the live network (generally, there is no
method for the identification), add the non-working P-CSCF address to the OPTIONS
whitelist to screen this alarm.

2.8.6 404 Message May Occur in VoLTE Call Tests


Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom When the customer uses a test tool to perform a call test, a 404 message
may occur, causing a call failure.
Trouble N/A
Ticket
Number
Root Cause The details are as follows:
The customer uses a test tool to perform a call test (an enormous number of
calls are simulated using this tool). A 404 message may occur.
The reason is as follows:
The message tracing result shows that the 404 message is caused by the
fact that the ATS fails to query subscriber data (including the call source).
Further analysis of the traced messages shows that the ATS involves
deleting subscriber data for a call for which the 404 message is returned.
This is because that the subscriber is an unregistered subscriber. When the
ATS receives an INVITE message and finds that it has not stored data of
the subscriber, it downloads the data from the HSS and stores it for a
specified time. The ATS has two timers (timers A and B) configured to

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 122


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

control the duration for which data of unregistered subscribers is stored.


The value of timer A is 90s, which cannot be modified. After the ATS
downloads subscriber data, the call ends within 90s. The ATS triggers only
timer A (90s). After 90s the ATS deletes subscriber data. When timer A
expires, if the subscriber is still busy on a call (regardless of whether the
call is the original or new one), the ATS starts timer B whose value is set to
32s by default. Therefore, if there is no call, the ATS deletes subscriber data
regardless of whether timer A or B expires. If the ATS receives a new call
during subscriber data deletion, it deletes and queries subscriber data
simultaneously. When the ATS detects that subscriber data has been deleted
while processing the INVITE message, it returns a 404 message for the call
due to the data query failure.
Condition  Subscribers have not registered services.
 During call setup, ATS deletes subscriber data due to the expiration of
timer A or B.
Probability This issue may occur when the preceding conditions are met.
of
Occurrence

Involved Version
ATS9900 V100R08C10SPC100
Solution
Workarounds:
ATS9900 engineers are planning to develop a patch to eliminate the root cause of this issue.
The current workaround is to increase the duration of timer B to reduce the occurrence
probability of this issue.
Preventive measures:
Wait for ATS engineers to develop a patch.

2.8.7 SPG Fails to Return limitation-of-parallel-calls to the BSS


Involved NE: ATS and SPG
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom The BSS is used to provision services for VoLTE subscribers. When LST
MSR is run with the path parameter specified to query imitation-of-
parallel-calls, the SPG does not return the query result to the BSS.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 123


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause 1. The details are as follows:
When the customer uses the path parameter to query limitation-of-
parallel-calls, the SPG does not return the query result to the BSS.
The query command received by the ATS is as follows:

The query result returned by the ATS to the SPG is as follows:

The query result received by the BSS is as follows:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 124


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The reason is as follows:


The customer uses the common service flow provided by the ATS.
When the SPG receives the query result from the ATS, it obtains
limitation-of-parallel-calls from the full directory
/m:SERVICEDATA/xcap:MMTel-extension/xcap:basic-
part/xcap:limitation-of-parallel-calls. However, as the query result
returned by the ATS to the SPG is incomplete, the SPG fails to obtain
the corresponding information.
Condition LST MSR is run with the path parameter specified to query imitation-of-
parallel-calls.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
ATS9900 V100R06C20SPC100
Solution
Workarounds:
N/A
Preventive measures:
Wait for ATS engineers to develop a patch. It is expected that a patch will be released at April
30, 2016.

2.8.8 Some Subscribers Fail to Register Due to the Incorrect qop


Parameter
Involved NE: CSCF
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom Some subscribers fail to register, and the CSCF returns a 403 message
indicating "Invalid Subsequent Register Request".

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 125


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause The details are as follows:
Some subscribers fail to register, and the CSCF returns "Invalid Subsequent
Register Request".
The reason is as follows:
The 401 message is as follows:

The REGISTER message received by the P-CSCF after the 401 message is
as follows:

The REGISTER message sent by the P-CSCF to the I-CSCF after the 401
message is as follows:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 126


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

At this time, the REGISTER message sent by the P-CSCF to the I-CSCF
does not contain the authentication header field (the protocol stack deletes
this header field). As a result, the S-CSCF determines that the REGISTER
message is abnormal, causing the registration failure.
The reason is that the S-CSCF does not include the qop parameter in the
401 message but the subsequent REGISTER message carries this
parameter.
If the UE needs to carry the qop parameter, the value of this parameter
must be set to the qop parameter value in the 401 message sent to the UE.

Condition The 401 message does not contain the qop parameter, but the REGISTER
message sent after the 401 message contains the qop parameter whose
value is left unspecified.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 127


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
ATS9900 V100R08C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Rectify the UE to be protocol-compliant.

2.8.9 ATS Releases the Call Due to Unsupported Fax Codecs


When a Voice Call Is Switched to a Fax Call
Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom When a voice call is switched to a T.38 fax call for a subscriber, the ATS
releases the call with a BYE message. This is because the subscriber' data
on the ATS indicates that the T.38 codec is not supported.
Trouble N/A
Ticket
Number
Root Cause The details are as follows:
When a voice call is switched to a T.38 fax call for a subscriber, the ATS
releases the call with a BYE message. This is because the subscriber' data
on the ATS indicates that the T.38 codec is not supported.
The reason is as follows:
The following figure shows the switchover from a voice call to a T.38 fax
call:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 128


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The following figure shows the ATS releases the call with a BYTE
message:

In ATS 10.0 or later, this issue can be resolved by modifying SIPCFG data.

In ATS 9.1 or 9.2, this issue can be resolved by changing the setting of
software parameter 3183.
Condition  Voice calls are switched to fax calls.
 Subscriber data does not indicate any support for fax calls.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 129


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
ATS9900 V100R05C02SPC100
Solution
Workarounds:
N/A
Preventive measures:
Modify the setting of software parameter 3183 or run MOD SIPCFG:
SFPARA=SIP_SEND_488_NO_MEDIA_AFTER_FILTER-1;.

2.9 Fault Cases for February 2016


2.9.1 iPhones Fail to Register with IMS Networks
Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom iPhones fail to register with IMS networks and therefore cannot use VoLTE
services.
Trouble N/A
Ticket
Number
Root Cause The following two scenarios are involved.
1. An iPhone initiates a network attach request and obtains a newly
assigned IP address. However, the iPhone still uses the original IP address
to initiate a registration, resulting in a failure for the PGW to forward the
registration to the SBC. When the maximum number of re-registrations
initiated by the iPhone is reached, the iPhone no more initiates a
registration.
2. When an iPhone uses the same IP address and a different ipsec sa port to
initiate a registration, the SBC includes the proprietary ipsec sa port in the
Via header field. Once the CSCF detects the port change, it returns a 403
message to the iPhone to deny the registration. When the iPhone receives a
403 message for two consecutive times, it no more initiates a registration.
Condition  An iPhone initiates a network attach request and obtains a newly
assigned IP address. However, the iPhone still uses the original IP
address to initiate a registration.
 The SBC includes the proprietary ipsec sa port in the Via header field.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 130


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
All versions of the SE2900
Solution
Workarounds:
N/A
Preventive measures:
For scenario 1, the Apple needs to identify and resolve the iPhone issue.
For scenario 2, a patch will be developed to resolve the SBC issue.

2.9.2 Calls Cannot Be Made to iPhones That Are Running in the


Data Mode
Involved NE: CSCF
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom When a call addressed to an iPhone running in the data mode is connected
in the IMS network, the SBC returns a 404 message.
Trouble N/A
Ticket
Number
Root Cause 1. The reason why the SBC returns a 404 message is that the iPhone has
deregistered when a call is addressed to the iPhone.
2. The time when the CSCF initiates a deregistration is three minutes later
than the SBC. When the CSCF that has not deregistered the iPhone
happens to forward a call to the SBC that has deregistered the iPhone, the
SBC returns a 404 message.
Condition  The subscriber has registered with the IMS network.
 A call is addressed to the iPhone that encounters a registration timeout.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
CSC3300 V100R010C10
Solution
Workarounds:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 131


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

N/A
Preventive measures:
Load the V100R010C10SPH213 patch on the CSCF and perform data configuration.
Data Configuration:
Set bit 12 of DBMSPARA5 to 1.
MOD SFP: INSPN=DBMSPARA5, MODTYPE=P1, BIT=12, BITVAL=1;

Bit 12 of DBMSPARA5 is used for function control.


Determines how the CSCF scans subscriber data when detecting that a subscriber has encountered a
registration timeout.
= 0: The CSCF scans subscriber relationship table data.
= 1: The CSCF scans subscriber registration control blocks.
Default value: 0
Bits 11-9 of DBMSPARA5 are used for value setting.
Determines the number of subscribers scanned by the CSCF every second when detecting that a
subscriber has encountered a registration timeout. Bits 11-9 of DBMSPARA5 are valid only when bit 12
of DBMSPARA5 is set to 1.
Value range: 0x0 to 0x7; the unit is thousand subscribers.
= 0x0: The S-CSCF scans data of 3,000 subscribers every second.
= 0x1 to 0x7: The S-CSCF scans data of a specified number of subscribers every second.
Default value: 0x0

2. In extreme situations (for example, when the SBC module restarts and subscriber data
exists on the CSCF/TAS), the SBC returns a 404 message. To ensure voice connection when
this issue occurs, add the 404 message to the CS RETRY error codes configured on the SCC
AS. The detailed configuration is as follows:
MOD CSRETRYCFG: CSRETRYSWITCH=ON, TRIGGERCODE=SIP404-1&SIP408-
1&SIP410-1&SIP503-1&SIP504-1;

2.9.3 VoLTE Subscribers Using iPhones Fail to Call CS


Subscribers
Involved NE: UE
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom After iPhone subscribers are upgraded to VoLTE subscribers, they fail to
call CS subscribers. The traced subscriber messages show that the MGCF
returns a 400 message to the previous hop immediately when receiving an
INVITE message.
Trouble N/A
Ticket
Number
Root Cause It is found that the iOS version of the iPhone is 9.0, 9.0.2, or 9.1, which is

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 132


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

earlier than 9.2.1. When the INVITE message sent by the iPhone is not
protocol-compliant, the MGCF releases the call.

The message tracing logs contain the following information:

2. Simulate SDP information. It is found that a semicolon (;) is placed


between 104 and max-red=220; and between 102 and max-red=220;,
which causes a failure in resolving SDP information. The following shows
the comparison between the successful and failed SDP resolutions:

The SEQ signaling analysis shows that the INVITE message sent by the
iPhone contains extra semicolons (;).

[Related Protocols]
As stipulated in RFC4566, there is no semicolon (;) for "<format> <format
specific parameters>".

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 133


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

According to 3GPP TS 26.103, see RFC4867 for details about how SDP
information is carried in AMR-WB.

As stipulated in RFC4867, when there are multiple <format specific


parameters>, these parameters are separated by a semicolon (;).

RFC4867 gives the following description about the IE:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 134


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition The INVITE message sent by the iPhone is not protocol-compliant.


Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the iPhone
Solution
Workarounds:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 135


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

N/A
Preventive measures:
The Apple needs to resolve this issue.

2.9.4 Calls Addressed to VoLTE Subscribers May Fail After IN


Services Are Triggered
Involved NE: SCP
Applicable Scope: China
Troubleshooting: N/A
Defect Details

Symptom Calls addressed to VoLTE subscribers may fail after Intelligent Network
(IN) services are triggered.
Trouble N/A
Ticket
Number
Root Cause 1. After the SBC sends an INVITE message to the called party, it does not
receive any response. Then, after several seconds, the originating UE
sends a REGISTER message that contains a different IP address. When
the S-CSCF receives the REGISTER message, it determines that this
request is a new initial registration or used for a deregistration and
therefore releases the previous call.

2. The SCP AS sends a message to the HSS, requesting the real-time 4G


location information. As the MSC server on the live network does not
support the real-time information acquisition, it sends a paging request
to the 2G network. The 2G network cannot determine whether this
paging request is a voice call or short message service (SMS) paging
request. After the mobile phone is handed over to the 2G network, it
cannot receive the INVITE message from the SBC. Consequently, the
mobile phone cannot respond to the INVITE message. When the mobile
phone does not receive a voice setup message before the corresponding
timer of the mobile phone expires, it is handed over to the 4G network.
At this time, the mobile phone sends a deregistration or an initial
registration, causing the previous call to be released.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 136


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition This issue occurs when the ATI message sent by the SCP AS carries the
currentlocation and LocationInformation EPS-Supported fields.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the SCP AS
Solution
Workarounds:
N/A
Preventive measures:
Rectify the SCP AS so that the ATI message sent by the SCP AS does not contain the
currentlocation or LocationInformation EPS-Supported field.

2.9.5 Huawei and Bell Have Different Understandings of IMS


Protocols
Involved NE: CSCF
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom VoLTE subscribers served by the Bell VoLTE device cannot call VoLTE
subscribers served by the Huawei VoLTE device who are in the 2/3G
network but cannot call VoLTE subscribers served by the Huawei VoLTE
device who are in the 4G network. This is because the History-Info header
field in the INVITE message sent by the Bell VoLTE device contains only
one record.
Trouble N/A
Ticket
Number
Root Cause 1. In normal call flows, the INVITE message sent by the Bell device to the
Huawei S-CSCF contains the History-Info header field. However, this
header field contains only one record, that is, B's number. After the S-
CSCF contacts the SCC AS, the SCC AS routes the call to the 2/3G
subscriber through domain selection. The Request-URI is changed to the
CSRN, that is, C's number. When the S-CSCF detects that the Request-URI
is changed and the History-Info header field is carried, it determines that a
call forwarding event has occurred. However, as stipulated in the relevant
protocol, the History-Info header field must contain two records, that is, the
original called number and forwarded-to number.
The following is an INVITE message sent by the Bell VoLTE device:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 137


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The following is an INVITE message sent by the SCC AS after the SCC
AS routes the call to the 2/3G network through domain selection:

2. Service Scenario Analysis


 Call Forwarding Service
The normal call forwarding flow applies. For example, when A calls B, B
forwards the call to C. The AS changes the Request-URI from B's number
to C's number and carries the History-Info header field that contains two
records. Then, the CSCF continues to trigger the subsequent iFCs.
 Domain Selection Service
When the AS routes the call to the 2/3G network through domain selection,
it changes the Request-URI from B's number to the CSRN and does not
carry the History-Info header field. This means that outgoing number
analysis is performed (there is no need to continue to trigger iFCs).

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 138


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition The Bell VoLTE device carries the History-Info header field in non-call
forwarding scenarios.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the CSC3300
Solution
Workarounds:
Modify software parameter settings on the S-CSCF to resolve the issue caused by the
incorrect way that the Bell device processes messages. However, the issue of continuing to
trigger iFCs after number change cannot be resolved.
MOD SFP: INSPN=SCSCFPARA27, MODTYPE=P1, BIT=3, BITVAL=0;
MOD SFP: INSPN=SCSCFPARA27, MODTYPE=P1, BIT=15, BITVAL=0;
Preventive measures:
Suggestion by Huawei:
As the INVITE message sent by the Bell VoLTE device to the S-CSCF for basic calls contains
the abnormal History-Info header field, the S-CSCF denies the calls.
The Bell VoLTE device needs to be rectified in such a way that it does not carry the History-
Info header field in non-call forwarding scenarios.

2.10 Fault Cases for January 2016


2.10.1 Modifying Subscription Data on the PGW Fails Due to the
Loss of KI Data
Involved NE: HSS
Applicable Scope: global
Troubleshooting Engineer: Wan Jun (ID: 00265982)
Defect Details

Symptom Subscribing to T-CSI data fails on the PGW. The system displays the error
message "Template not defined."
%%MOD TCSI: IMSI="51502960000xxxx", PROV=TRUE,
TPLID=102;%%
RETCODE = 3003 ERR3003:Template not defined
There is together 1 report
--- END

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 139


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause Check the template and it is found that the template has been defined.
Then, check whether the subscriber has registered. It is found that the
subscriber has registered. However, the subscriber fails to use the same
USIM card to register with the 3G network. The reason is that KI data has
been deleted. After KI data is added, subscribing to T-CSI data is
successful.
Condition KI data has been deleted.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the HSS9860
Solution
Workarounds:
N/A
Preventive measures:
Add KI data to ensure successful subscription to T-CSI data.

2.10.2 Ut Service Test Can Be Performed Using the hosts File


Embedded in an Android-Based Mobile Phone
Involved NE: UE
Applicable Scope: global
Troubleshooting Engineer: Wan Jun (ID: 00265982)
Defect Details

Symptom In VoLTE networks, Ut services use the data APN or a newly established
APN. Due to the business flow on the customer side, it takes a long time to
create UIM domain resolution data records on the DNS server. This gives
rise to a question: How to perform a Ut service test without this wait?
Trouble N/A
Ticket
Number
Root Cause If an Android-based mobile phone is rooted, use the embedded hosts file
for domain resolution and perform a Ut service test.
The details are as follows: 1. Connect the mobile phone to a computer
using a data cable. 2. Install the data cable driver. 3. Apply for CPM serial
rights. 4. Install the ADB environment.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 140


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Then, click 1_pull_hosts.bat and back up the hosts file to the current
directory.
Modify the hosts file as required, click 2_push_hosts.bat, and upload the
modified hosts file to the mobile phone.
Restart the mobile phone for the modification to take effect.
See the attachment for the ADB tool, scripts, and sample hosts file.
Attachment:
ADB.rar modify hosts.rar
Condition This issue occurs when the corresponding domain resolution data records
are not configured on the DNS server.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the UE
Solution
Workarounds:
N/A
Preventive measures:
Use the script files in the attachment to modify the UE configuration.

2.10.3 Diameter Links Between the CSCF and DRA Do Not Run
Properly
Involved NE: CSCF
Applicable Scope: global
Troubleshooting Engineer: Wan Jun (ID: 00265982)
Defect Details

Symptom Diameter links are established between the CSCF and DRA and run
properly. However, after the peer host name is changed (MOD IDRA:
DRANM="IDRA", DN="xxx.xxx.xx", HN="xxx.xxx.xxx.xx";) as required
by DRA engineers, Diameter links do not run properly.
Trouble N/A
Ticket
Number
Root Cause 1. Check whether interworking parameters are correct. If yes, perform the
following step:
2. Check the local end for Diameter link fault alarms.
3. Trace Diameter messages. It is found that the CSCF does not initiate a

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 141


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Diameter link establishment request after receiving a CEA message from


the DRA.
4. Obtain the debug logs. It is found that the following error information is
displayed:
M0032P198F00S01M 2015-01-29 16:28:08
ERR [../../../../source/COMMON/Sig/DiamRM/src/diameterlm.c
FileID(770) : 5283 <DiamDebugSend>]
Diameter Stack Debug:Error Information[DiamCmProcCEA, 4580]Server
Returned Failure CEA
5. Analyze why this error information is displayed. It is found that the peer
host name is modified without resetting the local end. When the CSCF still
uses the original peer host name for communication with the DRA,
Diameter links cannot be established.
Conclusion: When modifying the peer host name used for establishing
Diameter links, reset the local end. Alternatively, delete the original links
and create new ones.
Condition This issue occurs when the peer host name used for establishing Diameter
links is modified without resetting the local end.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
CSC3300 V100R011C10
Solution
Workarounds:
N/A
Preventive measures:
When modifying the peer host name used for establishing Diameter links, delete the original
links by running RMV IDRAL and then create new ones.

2.10.4 SBC Cannot Receive REGISTER Messages from P-GW


Involved NE: P-GW
Applicable Scope: global
Troubleshooting Engineer: Xi Dongbo (ID: 00351334)
Defect Details

Symptom The P-GW sends a REGISTER message to the access-side signaling IP


address of the SBC. However, the signaling messages traced on the SBC
show that the SBC does not receive the REGISTER message.
Networking: P-GW-----LAN switch----Firewall------Router-----SBC

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 142


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause First check whether there is a problem with 4G attach. It is found that the
signaling messages traced on the P-GW show that the P-GW sends the SBC
IP address to the UE, and it is also found that the UE obtains the IP address.
Therefore, there is no problem with 4G attach.
Then check whether the IP address is pingable. It is found that the
messages captured on the UE show the UE sends a REGISTER message.
(Before IP information is configured, pinging the P-GW IP address is
successful.) It is also found that there is no problem with the router and the
REGISTER message is not filtered out by the firewall. Perform TraceRoute
on the SBC and it is found that the LAN switch can be pingable but the UE
IP address pool on the P-GW cannot be accessed. Therefore, there must be
a problem with the P-GW. Check the newly configured data used for
interworking between the P-GW and SBC and it is found that block
information is configured for the IMS APN and outgoing data from the P-
GW to P-CSCF is disabled.
Condition This issue occurs when IMS APN data is incorrectly configured on the P-
GW.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the P-GW
Solution
Workarounds:
N/A
Preventive measures:
Correct the configuration on the P-GW as follows:
Sys
APN IMS
ims-sig-filter 2 source src-any sportop sp-any dest des-any dportop dp-any protop pro-any

2.10.5 SPG Fails to Issue Service Provisioning Instructions Due to


the Change in the Default Value of the INSP Software Parameter
Involved NE: HSS
Applicable Scope: global
Troubleshooting Engineer: Xi Dongbo (ID: 00351334)
Defect Details

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 143


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Symptom When a service provisioning command is run on the SPG, the system
displays "RETCODE = 5004HSS-ERR5004:Session ID invalid or time
out."
Trouble N/A
Ticket
Number
Root Cause Check the setting of the INSP software parameter on the USCDB.
1. In HSS9860 C10, the SOAP interface is controlled by the software
parameter obtained by running LST INSP: INSPT=PGW,
INSPN=RIGHTSWITCH.
2. In HSS9860 C20, the SOAP interface is controlled by the software
parameter obtained by running LST INSP: INSPT=FE,
INSPN=PROVRIGHTSWITCH.
The default value is 1, indicating that rights are checked.
Value:
= 0: Rights are not checked.
= 1: Rights are checked.
= 2: Rights check is enabled for MML commands, not SOAP commands.
Condition This issue occurs when the setting of the INSP software parameter is
changed.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
HSS9860 C20
Solution
Workarounds:
N/A
Preventive measures:
Run the following command on the USCDB:
MOD INSP: INSPT=FE, INSPN=PROVRIGHTSWITCH, INSPV=0, FETYPEN="USCDB";

2.10.6 eSRVCC Handovers Fail Due to eNodeB Configuration


Errors
Involved NE: eNodeB
Applicable Scope: global
Troubleshooting Engineer: Cui Zhaorui (ID: 00184322)
Defect Details

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 144


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Symptom Apple performed a VoLTE test on a certain carrier's network. At 13: 26, the
eSRVCC handover failed. That is, the UE still displayed the VoLTE
network, not the 2G/3G network.
Trouble N/A
Ticket
Number
Root Cause Trace messages on the IWF. It is found that the eSRVCC handover failure
is caused by the fact that the MME cancels the handover request. See
Figure 2-1.
Figure 2-1 Messages traced on the IWF

Check the messages traced on the MME. It is found that the MME receives
the HANDOVER REQUIRED message from the eNodeB. Then, the MME
converts the message to the SRVCC PS to CS Request message and sends
it to the IWF. One second later, the MME receives the HANDOVER
CANCEL message from the eNodeB. The HANDOVER CANCEL
message is used to cancel the handover request, causing the handover
failure. See Figure 2-2.
Figure 2-2 Messages traced on the MME

Conclusion: The time (1 second) for the eNodeB to wait for the handover
response is so short that it cancels the handover request before the core side
completes the handover.
Condition This issue occurs when the time for the eNodeB to wait for the handover
response is less than 3 seconds.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 145


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Probability This issue occasionally occurs.


of
Occurrence

Involved Version
All versions of the eNodeB
Solution
Workarounds:
N/A
Preventive measures:
Change the time for the eNodeB to wait for the handover response to a large value.

Make this change based on site requirements.

2.10.7 Calls Fail Due to Access-Side Bearer Resource Insufficiency


Involved NE: RNC
Applicable Scope: global
Troubleshooting Engineer: Cui Zhaorui (ID: 00184322)
Defect Details

Symptom Apple performed a VoLTE test on a certain carrier's network. At 14:37, the
call was dropped.
Trouble N/A
Ticket
Number
Root Cause The messages traced on the SBC show that the call was dropped before an
eSRVCC handover. The reason is "insufficient-Bearer-Resources". At
14:38:21.055, the SBC received an ASR message from the PCRF. See
Figure 2-1.
Figure 2-1 Messages traced on the SBC

At 14:38:21.040, the PCRF sent an ASR message to the SBC. At


14:38:21.039, the PCRF received a CCR-T message from the UGW. See
Figure 2-2.
Figure 2-2 Messages traced on the PCRF

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 146


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

At 14:38:21, the UGW sent a Credit Control Request message to the PCRF.
At 14:38:21, the UGW received a Release Access Bearers Request message
from the MME. See Figure 2-3.
Figure 2-3 Messages traced on the UGW

The messages traced on the MME show that the MME received a release
message from the eNodeB at 14:38:21. The reason value is radio-
connection-with-ue-lost, which causes the call to be dropped. See Figure
2-4.
Figure 2-4 Messages traced on the MME

Therefore, access-side bearer resources insufficiency is the root cause of


the call drop.
Condition This issue occurs when the access-side bearer resources are insufficient.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the RNC
Solution
Workarounds:
N/A
Preventive measures:
Optimize the radio access network.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 147


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.10.8 Calls Fail Due to Poor Radio Network Coverage


Involved NE: RNC
Applicable Scope: global
Troubleshooting Engineer: Cui Zhaorui (ID: 00184322)
Defect Details

Symptom Apple performed a VoLTE test on a certain carrier's network. At 14:01, the
call failed.
Trouble N/A
Ticket
Number
Root Cause The messages traced on the SBC show that when the iPhone initiates a call,
the SBC receives an INVITE message and forwards it to the CSCF. See
Figure 2-1.
Figure 2-1 Messages traced on the SBC

The CSCF contacts the MO ATS and forwards the message to the CS
domain. The MO CSCF receives a 500 message indicating call release. See
Figure 2-2.
Figure 2-2 Messages traced on the CSCF

When the MGCF receives an INVITE message, it converts the message an


IAM message (BICC message) and sends the IAM message to the MSC
server. See Figure 2-3.
Figure 2-3 Messages traced on the MGCF

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 148


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

When the MSC server receives an IAM message from the MGCF, it sends a
Paging message instructing the RNC to page the called party. However, as
the Ec/No value is less than -13 dbm, the RNC releases the call and sends a
call release message to the MSC server.
See Figure 2-4.
Figure 2-4 Messages traced on the RNC

When the RB is being established, the UE sends a call update to the RNC.
If the Ec/No quality is too poor, the RB establishment fails.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 149


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

When the MSC server receives a call release message from the RNC, it
changes the release cause value to No route to destination and sends the
value to the MGCF.
Figure 2-5 Messages traced on the MSC server

When the MGCF receives a call release message from the MSC server, it
converts the BICC message to a 500 message (SIP message) and sends the
500 message to the CSCF.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 150


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition This issue occurs when the radio network coverage is poor.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the RNC
Solution
Workarounds:
N/A
Preventive measures:
Optimize the radio network to improve its coverage.

2.10.9 eSRVCC Handovers Fail Due to Abnormal Messages Sent


by the UE
Involved NE: UE
Applicable Scope: global
Troubleshooting Engineer: Cui Zhaorui (ID: 00184322)
Defect Details

Symptom Apple performed a VoLTE test on a certain carrier's network. At 12:43, the
call was dropped.
Trouble N/A
Ticket
Number
Root Cause The messages traced on the SBC show that the call was dropped before an
eSRVCC handover. The reason is "bearer-Released." At 12:43:18.850, the
SBC received an ASR message from the PCRF. See Figure 2-1.
Figure 2-1 Messages traced on the SBC

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 151


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

At 12:43:18.842, the PCRF sent an ASR message to the SBC. At


12:43:18.742, the PCRF received a CCR-T message from the UGW. See
Figure 2-2.
Figure 2-2 Messages traced on the PCRF

At 12:43:19.277, the UGW sent a Credit Control Request message to the


PCRF. At 12:43:19.276, the UGW received a Delete Session Request
message from the MME. See Figure 2-3.
Figure 2-3 Messages traced on the UGW

The messages traced on the MME show that when the calling and called
parties are in the call, the MME receives an Attach Request message from
an UE, causing the call to be dropped. See Figure 2-4.
Figure 2-4 Messages traced on the MME

Condition This issue occurs when a UE sends an attach request to the MME during a
call.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 152


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
iPhone IOS 9.2
Solution
Workarounds:
N/A
Preventive measures:
Submit this issue to Apple and request Apple to resolve it.

2.10.10 After the SCC AS Triggers CS Retry, the Terminating S-


CSCF Returns a 500 Message
Involved NE: CSCF
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom During session establishment, when the called VoLTE subscriber hands
over from the 4G to 2/3G network (a deregistration is sent to the 4G
network), the S-CSCF returns a 480 message. After the SCC AS triggers
CS Retry, the MT S-CSCF returns a 500 message, causing the CS Retry
failure.
Trouble N/A
Ticket
Number
Root Cause Although the S-CSCF returns a 480 message during the handover, the SCC
AS triggers CS Retry normally. However, when the S-CSCF receives an
INVITE message related to CS Retry, it returns a 500 message to release
the call. The following figure shows the message flow:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 153


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trigger conditions:
1. During session establishment (the 1xx (other than 100), 2xx, or Oxx
message is not received when an initial INVITE message is sent to the
called VoLTE subscriber), the called VoLTE subscriber hands over from the
4G to 2G network.
2. During the handover, a deregistration is sent to the original network.
3. The route selection attribute code has been configured on the CSCF by
running ADD SRTSAC.
4. CS Retry has been enabled on the CSCF.
MOD SFP: INSPN=SCSCFPARA8, MODTYPE=P1, BIT=14, BITVAL=1;
Bit 14 of SCSCFPARA8 is used for value setting.
It determines which SIP response is used by the CSCF to release the call
when the called subscriber deregisters, changes the registration IP address,
fails to contact the AS for registration, or encounters an AS deregistration
during call establishment.
= 0: The 487 message is used by the CSCF to release the call.
= 1: The 480 message is used by the CSCF to release the call.
Default value: 0
Troubleshooting:
1. In common CS Retry scenarios, the S-CSCF downloads subscriber
information from the HSS through the SAR/SAA and stores it regardless of
whether subscribers have registered or not.
a. Registered subscribers: The S-CSCF downloads subscriber information
during registration.
b. Unregistered subscribers: The S-CSCF downloads subscriber
information when unregistered services are triggered.
2. In deregistration scenarios, the subscribe type cannot be obtained for the
CS Retry call.
MID(104) PID(261) Level(ERR) -> SCALLRouteAttributeAnaProc: Call
CallNaGetUserTypeForSRTSAC failed! ulRet=[16643]
The reason is as follows: As the route selection attribute code has been
configured on the S-CSCF by running ADD SRTSAC, a route needs to be

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 154


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

selected based on the route selection attribute code. This means the
subscriber type (that is, the called VoLTE subscriber type) needs to be
obtained during route analysis. However, as the called VoLTE subscriber
has deregistered, the corresponding registration information does not exist
any more. This causes a failure in obtaining the called VoLTE subscriber
type. Finally, CS Retry fails, and the calling party cannot establish a call to
the called VoLTE subscriber.
Condition This issue occurs when all of the following conditions are met:
 The route selection attribute code has been configured on the S-CSCF by
running ADD SRTSAC, which means that a route needs to be selected
based on the route selection attribute code.
 The VoLTE subscriber has deregistered.
 A call is addressed to the VoLTE subscriber.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
CSC10.1
Solution
Workarounds:
N/A
Preventive measures:
This issue will be resolved in the CSC10.1SPH216 patch, which is to be released by the end
of January 2016.

2.10.11 When Subscribers Register, the CSCF Returns a 403


Message Carrying "Administrator deregister user"
Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom iPhone 6 fails to register. It is found that after iPhone 6 receives a 401
message, it sends a second REGISTER message but the S-CSCF returns a
403 message whose Warning header field carries "Administrator deregister
user."
Warning: 399 0.0.S.260.5.119.255.255.5144.0.0.bj.chinamobile.com
"Administrator deregister user"
Trouble N/A
Ticket

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 155


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Number
Root Cause Within a short time, iPhone 6 (User-Agent: iOS/9.2.1 (13D15) iPhone)
initiates a reregistration and then an initial registration. The reregistration is
successful (see line 4783). For the initial registration, the S-CSCF returns a
401 message requesting an authentication. When iPhone 6 initiates a
second REGISTER message, the S-CSCF returns a 403 message whose
Warning header field carries "Administrator deregister user."

For the first and second REGTSTER messages, their Contact header fields
contain the same IP address and port number. However, their Path header
fields contain the same IP address but the different port numbers, which
means that the two registrations are initiated using the same IP address but
different port numbers.
1. Reregistration: The authentication is carried, the integrity protection flag
is set to yes, and the port number in the Path header field is 49153.
Authorization: Digest
nonce="PazhaZiaq1HMOR4bBtzy+ACeBPlsW3JMOUatpBxWma0=",
uri="XXXXXX",
response="5951937da36c748efb6297918afff1f9",algorithm=AKAv1-MD5,
nc=00000001,integrity-protected=yes
Contact: <sip:
[XXXXXXXX]:5060;transport=udp;Hpt=8e82_16;suid=AcARBiQJiACG
EADkCFze5gE9yXUBAAAA;srti=d0_1024>;+g.3gpp.icsi-ref="urn
%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;
+g.3gpp.smsip;+g.3gpp.srvcc-alerting;
+sip.instance="<urn:gsma:imei:35439406-123707-0>"
Path:
<sip:term@XXXXX:5060;transport=udp;lr;ssn;hwnos;TYPE=V6;IP=XXX
XXXXX;PORT=49153;Hpt=8e82_86;TRC=7f5-
ffffffff;suid=AcARBiQJiACGEADkCFze5gE9yXUBAAAA;srti=d0_1024
>
2. Initial registration: The authentication information is not carried, the
integrity protection flag is set to no, and the port number in the Path header
field is 58909.
Authorization: Digest
realm="ims.mnc000.mcc460.3gppnetwork.org",nonce="",

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 156


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

uri="sip:ims.mnc000.mcc460.3gppnetwork.org",response="",
algorithm=AKAv1-MD5,integrity-protected=no
Contact: <sip:
[XXXXXXX]:5060;transport=udp;Hpt=8e82_16;suid=HeYRBiQJiACGE
ADkCFze5gE9yXUBAAAA;srti=d0_1025>;+g.3gpp.icsi-ref="urn
%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;
+g.3gpp.smsip;+g.3gpp.srvcc-alerting;
+sip.instance="<urn:gsma:imei:35439406-123707-0>"
Path:
<sip:term@XXXX:5060;transport=udp;lr;ssn;hwnos;TYPE=V6;IP=2409:8
800:8610:E4:85C:DEE6:13D:C975;PORT=58909;Hpt=8e82_86;TRC=7f5-
ffffffff;suid=HeYRBiQJiACGEADkCFze5gE9yXUBAAAA;srti=d0_1025
>
For the two registrations, the Path header field is changed but the Contact
header field is kept unchanged. When storing subscriber data, the S-CSCF
considers the registration abnormal, returns a 403 message, and deletes
subscriber data.
The root cause is as follows: After the VoLTE UE has completed the IMS-
AKA/IPSec registration, the IP address is unchanged, the port number is
changed, and the changed port number is in plain text (not encrypted using
IPSec). When an initial registration is initiated again, the PORT parameter
in the Path header field of the REGISTER message forwarded by the SBC
is changed. However, as the Contact header field is not changed, the S-
CSCF considers the registration abnormal and returns a 403 message
whose Warning header field carries "Administrator deregister user."
Condition This issue occurs when both of the following conditions are met:
 After the VoLTE UE has completed the IMS-AKA/IPSec registration, the
IP address is unchanged and the port number is changed.
 The changed port number is in plain text (not encrypted using IPSec) and
used to initiate an initial registration.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
All versions of the SE2900
Solution
Workarounds:
N/A
Preventive measures:
This issue will be resolved by a SBC patch, which is to be released by February 2016.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 157


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.10.12 When a Call Is Addressed to a VoLTE Subscriber Who


Returns to the 4G Network After an eSRVCC Handover, CSFB Is
Performed on the MT Side
Involved NEs: SBC and UE
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom When two VoLTE subscribers in a call roam to areas with 2G/GSM
coverage, an eSRVCC handover is performed. After the handover, the call
continues for three minutes and then ends normally. However, after these
two VoLTE subscribers return to the 4G network and a call is initiated
between them again, circuit switched fallback (CSFB) is performed on the
MT side.
Trouble N/A
Ticket
Number
Root Cause 1. When a call is addressed to a VoLTE subscriber who returns to the 4G
network after an eSRVCC handover, the VoLTE subscriber's UE receives a
TCP SYN message (for attempting an INVITE message) from the network
side. The TCP SYN message is used to create a TCP connection. However,
as there is already a TCP connection that in the established state, the UE
discards the connection.
2. After the called UE hands over to the 2G network, the SBC sends an
RST message due to the aging of TCPs links on the MT side. However, as
the called UE is still in the 2G network, it has not received the RST
message. After the called UE returns to the 4G network and a call is
initiated to the UE, the SBC sends an SYN message for re-establishing
links. However, the UE has not received the RST message, causing TCP
link status inconsistency. Therefore, the UE does not respond to the SYN
message.
Condition This issue occurs when a TCP connection is used between the UE and
network.
Probability This issue occasionally occurs.
of
Occurrence

Involved Version
SE2900 V300R001C20
Solution
Workarounds:
1. Change the duration of the TCP aging timer on the SBC to one hour. The usage of TCP
resources on the SBC is assessed as follows:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 158


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The keepalive period for the server mode is set to one hour, and the keepalive period for the
client mode is set to 32 seconds. A single SCU module supports 50,000 subscribers as well as
80,000 TCP connections for the server mode and 40,000 connections for the client mode. As a
single SCU module supports about 8,000 concurrent calls, TCP connections are sufficient.
MOD SFP: INSPN=BCFPARA9, MODTYPE=P1, BIT=22, BITVAL=1;
Bit 22 of BCFPARA9 is used for function control.
It determines whether the aging time of TCP server links used by IPSec AKA subscribers on
the SE2900 is configurable.
= 0: The aging time is not configurable. It is fixedly set to 3 minutes.
= 1: The aging time is configurable. Use bits 7-0 of BCFPARA10 to configure the aging time.
For details, see the description of BCFPARA10.
Default value: 0
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=2, BITVAL=1;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=3, BITVAL=1;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=4, BITVAL=1;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=5, BITVAL=1;
BCFPARA10 is used for value setting. It uses bits 7-0.
It determines the aging duration of TCP server links used by IPSec AKA subscribers. Value
range: 0-60 (in minutes)
The default value is 0, indicating that the aging time is the subscriber registration duration
plus 3 minutes. The aging timer is released when a subscriber deregisters or the SA in use is
handed over.
When the value 1 is used, the link aging time is 2 minutes as the link keepalive period is also
1 minute.
When the value 60 is used, the link aging time is 60 minutes.
Recommended value: 60
Bit 23 of BCFPARA9 is valid only when bit 22 of BCFPARA9 is set to 1.
MOD SFP: INSPN=BCFPARA9, MODTYPE=P1, BIT=23, BITVAL=1;
Bit 23 of BCFPARA9 is used for function control.
It determines whether the aging time of TCP client links used by IPSec AKA subscribers on
the SE2900 is configurable.
= 0: The aging time is not configurable. Links are released 32 seconds after the call ends.
= 1: The aging time is configurable. Use bits 15-8 of BCFPARA10 to configure the aging
time. For details, see the description of BCFPARA10.
Default value: 0
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=10, BITVAL=1;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=11, BITVAL=1;
MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=12, BITVAL=1;

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 159


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

MOD SFP: INSPN=BCFPARA10, MODTYPE=P1, BIT=13, BITVAL=1;


BCFPARA10 is used for value setting. It uses bits 15-8.
It determines the aging time of TCP client links used by IPSec AKA subscribers. Value range:
1-60
The default value is 0, indicating that links are released 32 seconds after the call ends.
When the value 1 is used, the link aging time is 2 minutes as the link keepalive period is also
1 minute.
When the value 60 is used, the link aging time is 60 minutes.
Recommended value: 60
BCFPARA10 is valid only when bit 23 of BCFPARA9 is set to 1.
Preventive measures:
Optimize the TCP link establishment mechanism of the SBC as follows:
1. Optimize handover scenarios. If an eSRVCC handover is performed to the 2G network, the
RST/FIN message is not sent to the UE even if the TCP connection times out. The RST/FIN
message is sent to the UE only after it returns to the 4G network.
2. The SBC does not support link teardown using the plaintext FIN message. Currently, TCP
connection encrypted only for AKA subscribers can be torn down using the FIN message.
Plaintext TCP connections cannot be torn down using the FIN message (the port number is
5060).
3. If the UE carries transport=tcp, the BYE/PRACK message sent by the SBC cannot be
converted to a UDP message. Therefore, if the UE still cannot receive messages, the
maximum number of retransmissions times and the retransmission time of the TCP must be
modified.
This issue is considered as a service requirement that will be fulfilled in the
V300R001C20SPH117 patch.
Optimize the UE as follows:
In the client mode, after the UE hands over to the 3G network and then back to the VoLTE
network, the TCP link is still in the connected state. In this case, when the UE receives an
SYN message, it must send an ACK message rather than discarding the SYN message.

2.10.13 End Office Takes More Than Four Seconds to Return a


Response (to PSI) to the HSS
Involved NE: UE
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom When a call is addressed to a subscriber (VoLTE@CS), the TAS sends an


UDR message to query the HSS for 2/3G location information. However,
the end office takes more than four seconds to return a response to the PSI
message.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 160


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause 1. The UDR message sent by the VoLTE AS contains currentLocation.

2. The HSS has the following service requirements:


Location service requirements: The currentlocation and
currentLocationRetrieved fields can be forwarded. When the MAP ATI
message contains the currentlocation field, the HLR needs to forward
the currentLocation field to the MSC or SGs MSC through the
MAP_Provide_Subscriber_Information(PSI) message. When the SGs
MSC returns the currentLocationRetrieved field through the PSI ACK
message, the HLR does not need to report an error or filter the field out.
Instead, it needs to transparently transmit the field to the location
service platform through the ATI ACK message.
3. By default, the MSC returns subscriber information to the HSS after
receiving the PSI message.
4. After the MSC receives the PSI message, it determines whether the
message contains the Location Information or Subscriber State
information element (IE) and Whether to page when PSI in the
MAPPARA table is set to Yes. If yes, the MSC sends a paging message
to the wireless side to obtain the accurate location information and
status of the subscriber.
5. As the duration of the timer for the ATS to wait for the UDA message is
five seconds and the duration of the timer for the HSS to wait for the
response (to PSI) is four seconds, the UDA message obtained by the
TAS does not contain 2/3G location information.
Condition This issue occurs when the end office takes more than four seconds to
return a response (to PSI) to the HSS.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
iPhone IOS 9.2
Solution
Workarounds:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 161


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

N/A
Preventive measures:
This issue will be resolved in MSOFTX3000 V100R007C10SPH738 (for CPCI) and
MSOFTX3000 V200R009C02SPH138 (for ATCA).

2.11 Fault Cases for December 2015


2.11.1 Digit Collection Fails for Calls Addressed to the Number
12580
Involved NE: MGCF
Applicable Scope: global
Troubleshooting Engineer: Wang Yuanyuan (ID: 00258474)
Defect Details

Symptom When a VoLTE subscriber initiates a call to the number 12580, digit
collection fails.
Trouble N/A
Ticket
Number
Root Cause 1. Trace messages on the MGCF for the call from the VoLTE subscriber to
the number 12580. It is found that pressing keys does not work and there
are no outband DTMF messages. Simulate a scenario in which a VoLTE
subscriber initiates a call to the number 10086. Trace messages on the
MGCF for the call. It is found that pressing keys works and there are also
no outband DTMF messages.
These two calls share the same call path: UE-SBC-SCSCF-MGCF-GMSC-
service platform. The only differences are as follows: The 10086 service
platform returns both the ACM and ANM messages while playing an
announcement, but the 12580 platform returns only the ACM message
while playing an announcement.
Check data configured on the MGCF.
SIPTG data for interworking between the MGCF and S-CSCF:

BICCTG data for interworking between the MGCF and GMSC server:

2. Why are there no DTMF messages for the number 10086?


Check SIPTG data configured for interworking between the MGCF and S-
CSCF:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 162


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Change the value of Outgoing call open DTMF detect to YES (MOD
SIPTG: TGN="HKMGCF1-HKSCSF1-SIP", CALLERDTMF=YES;).
When the VoLTE subscriber initiates a call again to the number 10086, the
message tracing result shows that the MGCF, after receiving an ANM
message from the next-hop NE, returns a 200 message to the previous-hop
NE and then sends an SMMSG_DETECT_DTMF_REQ message. Finally,
the MOD_REQ message is used to instruct the IM-MGW to perform
DTMF detection.

For a SIP-to-BICC call, when the incoming SIP trunk detects an inband
DTMF signal, it converts the signal to an outband message and sends it to
the next-hop NE. In the message tracing result, it is found that APM
messages are sent when the VoLTE subscriber presses keys, and digit
collection is normal.

However, in the message tracing result for the call to the number 12580, it

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 163


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

is found that no APM messages are sent when the VoLTE subscriber
presses keys, and pressing keys still does not work.
In the message tracing result, it is also found that no MOD_REQ messages
are sent to instruct the IM-MGW to perform DTMF detection.
3. Select the following parameter value when modifying SIPTG data:

In the message tracing result, it is found that before the MGCF returns a
183 message to the previous-hop NE, it has issued DTMF detection to the
IM-MGW.

However, pressing keys still does not work, and no outband DTMF
signaling is found.
4. After comparison with messages in other provinces, it is found that the
value of the p-early-media information element (IE) in the 180 message
sent by the MGCF to the S-CSCF is sendonly in the local province and
sendrecv in other provinces.
This reason is that as the IE is incorrectly set, the terminal cannot report
inband DTMF signals.
Modify SIPTG data by deselecting the following parameter value:

Condition The p-early-media IE in the 180 message sent by the MGCF to the S-CSCF
is set to sendonly.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
MGCF V200R010C020SPC100
Solution
Workarounds:
N/A

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 164


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Preventive measures:
Modify SIPTG data by deselecting Including sendonly in P-Early-Media for Extra
software parameter 7 of service control.

2.11.2 Subscribers Who Are Not Defined Using the China Mobile-
specific Service Flow Fail to Register
Involved NE: ATS
Applicable Scope: China
Troubleshooting: N/A
Defect Details

Symptom After the MMTel AS is upgraded to V100R006C10SPH218 for China


Mobile, subscribers who are not defined using the China Mobile-specific
service flow fail to register. However, subscribers who are defined using
the service flow can register.
Trouble N/A
Ticket
Number
Root Cause It is found that some subscribers are defined by running ADD MSR but the
IMS-CAMEL-Services (IN service) flag is not selected for them. However,
in the iFC template of the MMTel AS, type in the SERVER parameter
carries the ssf field, which means that IN service-related flows will be
performed, for example, UDR messages are sent to issue IN service data.
After the V100R006C10SPH218 patch is installed, the ATS sends an SNR
message to subscribe to IN service data for parameters in the iFC template
that carry the ssf field. However, when subscribers are defined on the ATS
without selecting the MS-CAMEL-Services flag, a subscription error
occurs, affecting calls.
If the China Mobile-specific service flow is adopted, the ATS will carry the
IMS-CAMEL-Services flag for subscribers to be defined. In this case, this
issue does not occur.
Condition The V100R006C10SPH218 patch is installed.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
ATS V100R006C010SPC200
Solution
Workarounds:
N/A
Preventive measures:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 165


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

In the iFC template (CSCF and HSS) of the MMTel AS, change type=mmtel_ssf_scc to
type=mmtel_scc for the SERVER parameter, that is, remove the ssf parameter.
The following are example modifications:
MOD
SIFCINF:SIFCTPLID=100,PRIORITY=4200,SERVER="sip:aspool1.voltetas.xx.chinamobile
.com\;type=mmtel_scc";
MOD
SIFCINF:SIFCTPLID=100,PRIORITY=2100,SERVER="sip:aspool1.voltetas.xx.chinamobile
.com\;orig\;type=mmtel_scc";
MOD
SIFCINF:SIFCTPLID=100,PRIORITY=1100,SERVER="sip:aspool1.voltetas.xx.chinamobile
.com\;orig\;type=mmtel_scc";
MOD
SIFCINF:SIFCTPLID=100,PRIORITY=1000,SERVER="sip:aspool1.voltetas.xx.chinamobile
.com\;orig\;type=mmtel_scc";
MOD
SIFCINF:SIFCTPLID=100,PRIORITY=300,SERVER="sip:aspool1.voltetas.xx.chinamobile.
com\;type=mmtel_scc";
Commands before the modifications:
ADD
SIFCINF:SIFCTPLID=101,IFCNAME="VoLTE_AS_MO_INVITE",PRIORITY=2100,PART
IND=PARTIND_DEFAULT,SERVER="sip:aspool2.voltetas.sx.chinamobile.com\;orig\;type=
mmtel_ssf_scc",DEFHND=SESSION_TERMINATED,INCLUDEREGREQ=N,TRIGPT="<
TriggerPoint><ConditionTypeCNF>1</ConditionTypeCNF><SPT><ConditionNegated>0</
ConditionNegated><Group>0</Group><SessionCase>0</SessionCase></SPT><SPT><Cond
itionNegated>0</ConditionNegated><Group>0</Group><SessionCase>3</SessionCase></S
PT><SPT><ConditionNegated>0</ConditionNegated><Group>1</Group><Method>INVIT
E</Method></SPT><SPT><ConditionNegated>1</ConditionNegated><Group>2</Group><
SIPHeader><Header>P-Access-Network-
Info</Header><Content>.*3POC.*</Content></SIPHeader></SPT></TriggerPoint>";

2.11.3 Calls Between VoBB and VoLTE Subscribers Fail


Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Symptom Calls between VoLTE subscribers and IMS fixed-line subscribers fail. Two
types of symptoms occur:
Symptom 1:
 When Samsung S6, Huawei Mate 7, or iPhone 6 on the VoLTE network
initiates a call to an IMS fixed-line phone, the call fails without any
announcement. Trace signaling messages on the CSCF. It is found that a
488 message is returned.
 Calls from some of Huawei Mate 7 phones to IMS fixed-line phones fall
back to 2/3G networks and then are connected. Trace signaling

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 166


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

messages on the CSCF. It is found that a 488 message is returned.

Symptom 2
 When M821 on the VoLTE network initiates a call to a VoBB IMS fixed-
line phone, the call is connected without any audio.
 When a VoBB IMS fixed-line phone initiates a call to a VoLTE
subscriber, the call is connected with one-way audio (that is, the fixed-
line phone can hear the voice but the mobile phone cannot).
Trouble N/A
Ticket
Number
Root Cause 1. During voice call interworking between VoLTE and VoIP/VoBB
subscribers, the signaling messages sent by the IMS network to the
fixed-line subscriber contain extra SDP parameters that are irrelevant to
the fixed-line network, including LTE codecs and bandwidth. In
addition, the LTE codecs is placed in the most front, which indicates
that fixed-line subscribers preferentially use LTE codecs. However, this
signaling format causes the PON on the fixed-line network to fail in
parsing SDP information. Consequently, the call fails.
2. The following example illustrates that Huawei PON fails:
1. When a VoLTE subscriber initiates a call, the first 10 VoLTE codecs
in the SDP information of the INVITE message sent by the IMS
network is irrelevant to fixed-line devices and exceed a maximum of
eight codecs that can be processed by the MxU. As a result, the MxU
returns a 488 message, causing the call to fail.
2. Some of devices of earlier versions do not support the b=AS field.
When a VoLTE subscriber initiates a call, the IMS network sends
irrelevant bandwidth parameters (b=AS:38b=RS:0b=RR:0) to fixed-line
devices, causing one-way audio or no audio.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 167


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition  The SDP information of the INVITE message sent by the IMS network
contains more than eight codecs.
 The IMS network sends irrelevant bandwidth parameters
(b=AS:38b=RS:0b=RR:0) to fixed-line devices.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
SE2600 V200R009C30SPH111
Solution
Workarounds:
N/A
Preventive measures:
Configure the SBC on the fixed-line network side to remove the codes and SDP parameters
(including "a=" line parameters) unsupported by the fixed-line network before sending
messages to the GPON.

2.11.4 Subscribers Attached to SBCs of Another Vendors Cannot


Make or Receive Calls After PROTOCOLPARA6 Bit1 Is Set to 1
Involved NE: SBC
Applicable Scope: global
Troubleshooting: N/A
Defect Details

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 168


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Symptom PROTOCOLPARA6 bit1 is set to 1 to resolve the pre-normalization


problem with the ATS when subscribers are roaming in an area where Bell
SBC is deployed. However, after this setting, subscribers attached to ZTE
SBC cannot make or receive calls.
Trouble N/A
Ticket
Number
Root Cause The reason why subscribers attached to ZTE SBC cannot receive calls is
that in the P-Access-Network-Info header field of the PRACK message
sent by the S-CSCF, ue-ip contains an additional pair of square brackets
([]). The reason why subscribers attached to ZTE SBC cannot make calls is
that the P-Access-Network-Info header field of the 183 message sent by the
S-CSCF to the SBC is incorrect.
The following is the example information sent to the SBC:
domain=sbc.0317.he.chinamobile.com";ue-
ip=[[2409:8801:8140:1df:1:1:b272:b26f]];"ue-port=5082".
Condition The P-Access-Network-Info header field of the 183 message sent by the S-
CSCF to the SBC is incorrect.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the SE2900
Solution
Workarounds:
Run the following parameter to modify the software parameter:
MOD SFP: INSPN=PROTOCOLPARA6, MODTYPE=P1, BIT=1, BITVAL=0;
Preventive measures:
N/A

2.11.5 eSRVCC Handover Requests May Be Forwarded to the I-


CSCF When the SE2900 Releases CPU Resources Due to an
Internal Interruption
Involved NE: SBC
Applicable Scope: global
Troubleshooting Engineer: Zhao Feng (ID: 00186785)
Defect Details

Symptom An eSRVCC handover occurs when a VoLTE subscriber is in the alerting


state. There is a possibility that the eSRVCC handover fails. As a result, an

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 169


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

abnormality announcement, for example, the "number unallocated"


announcement, is played.
Trouble N/A
Ticket
Number
Root Cause The SE2900 receives a handover INVITE message and then sends it to the
I-CSCF. The I-CSCF returns a 404 message. The SE2900 forwards the 404
message to the eMSC server, causing a handover failure.

When the SE2900 updates DRT data on the SDB module, CPU resource
release is interrupted, and consequently there is a low probability that CPU
resources are preempted by other modules and DRT data is wrongly
modified. When DRT data fails to be queried later, the eSRVCC handover
fails. Note that common calls do not experience this issue.
Condition An eSRVCC handover occurs when a VoLTE subscriber is in the alerting
state.
Probability This issue occasionally occurs.
of
Occurrence

Involved Version
SE2900 V300R001C20SPC100 and SE2900 V300R001C20SPH111
Solution
Workarounds:
On the I-CSCF, add the following configurations:
ADD
IPSI:SUBDN="njsccas10bhw.sccas.js.ims.mnc000.mcc460.3gppnetwork.org",ASADDR="sip
:10.189.100.22";
ADD
IPSI:SUBDN="njsccas11bhw.sccas.js.ims.mnc000.mcc460.3gppnetwork.org",ASADDR="sip
:10.189.99.22";
Preventive measures:
Install SE2900 V300R01C20SPH117 or later.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 170


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.12 Fault Cases for November 2015


2.12.1 Video Calls from M823 Terminal Subscribers to CS
Subscribers Cannot Fall Back to Voice Calls
Involved NE: MGCF
Applicable Scope: global
Troubleshooting Engineer: Su Wei (ID: 00266878)
Defect Details

Symptom When a subscriber uses an M823 terminal to initial a video call to a CS


subscriber, the video call cannot fall back to a voice call. Consequently, the
video call is automatically released.
Trouble N/A
Ticket
Number
Root Cause Theoretically, the MGCF must perform fallback for video calls from
VoLTE subscribers to CS subscribers. That is, when the MGCF detects that
the SDP body of an INVITE message carries the video indicator, it must set
the video port to 0 and perform a voice call connection in the CS domain.
The message traced on the live network show that the MGCF releases the
call with a 400 message upon receiving an INVITE message from the
M823 terminal.

The message log analysis shows that the MGCF encounters an error when
parsing the "m=fmtp" line of the video SDP body.
SIPAPP_SDP_GetVideoFmtpH264Params():SDP H264 param Type(0)
invalid, MediaIndex = 1, AttrIndex = 1, ulParamIndex = 2. file:
sipsnc.c_12708.
The following is an example of the "m=fmtp" line that is sent by the M823

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 171


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

terminal but fails to be parsed by the MGCF:


a=fmtp:113 profile-level-id=42C01E;packetization-mode=1;sar-
understood=16;sar-supported=1;sprop-parameter-
sets=Z0KAHtoHgUaAbQoTUA==,aM4G8g==
However, the MGCF can parse the following "m=fmtp" line to perform
video fallback:
a=fmtp:120 profile-level-id=42C01E;packetization-mode=0;sprop-
parameter-sets=Z0LAHtoHgUZA,aM4G4g==
The comparison shows that the MGCF encounters an error when parsing
the following parameters in the "m=fmtp" line:
sar-understood=16;sar-supported=1;
Currently, the MGCF returns an error and releases the call when it does not
recognize SDP parameters.
Condition The MGCF receives unrecognized SDP parameters.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
MGCF V200R010C020SPC100
Solution
Workarounds:
Use the SIP-I International Adaptation feature to remove the SDP parameters of an incoming
INVITE message that cannot be recognized by the MGCF.
Preventive measures:
Load the V200R010C020SPH113 patch.
After the loading, the MGCF can continue the call regardless of unrecognized SDP
parameters.

2.12.2 Quick Signal Attenuation Causes eSRVCC Handovers to


Fail
Involved NE: eNodeB
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom eSRVCC handovers fail in elevators.


Trouble N/A
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 172


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause On the UE side:


At 14:19:07.140, the UE reported the inter-RAT measurement event A2.
At 14:19:07.174, the UE issued B1 measurement control.
At 14:19:09.940, the service area degraded to -131 after 2.8s.
Before the B1 measurement report was submitted, the call was dropped due
to network disconnection.
According to the previous test result and handover preparation time, it
takes about 8s to complete the handover. In addition, it is found that the
network coverage was -90dbm at 14:19:04.970 and an inter-frequency
handover occurred at 14:19:06.007. This quick signal attenuation causes
the handover to fail in the elevator.

Condition The signal attenuates quickly.


Probability This issue occasionally occurs.
of
Occurrence

Involved Version

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 173


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

All versions of the eNodeB


Solution
Workarounds:
N/A
Preventive measures:
N/A
To ensure the successful SRVCC handover in this scenario, the network coverage must be
changed to -90dbm for the inter-RAT measurement event A2 of the PCI138 and the inter-
frequency handover must be prevented. This is impractical.

2.12.3 Incorrect Route Configuration for the Gx Interface on the P-


GW Causes a Failure in Establishing Dedicated Bearers for Calls
Between VoLTE Subscribers
Involved NE: PGW
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom When a VoLTE subscriber calls another VoLTE subscriber, the LDRA does
not distribute AAR messages, causing a failure in establishing a bearer for
the calling party.
Trouble N/A
Ticket
Number
Root Cause When an IMS APN bearer is established, the LDRAs route Gx-interface
signaling messages of the P-GW to any of intra-province PCRFs in a pool
in load sharing mode.
When a VoLTE subscriber uses voice services, the SBCs route Rx-interface
signaling messages to any LDRA in load sharing mode. Then, the LDRA
routes the Rx-interface signaling messages to the PCRF that is responsible
for establishing an IMS APN bearer for the subscriber.
Therefore, the session binding function must be configured on the LDRA
for the Gx and RX interfaces. That is, after the LDRA routes Gx-interface
signaling messages to a certain PCRF in a pool, it records the binding
between the subscriber's IP address and the PCRF address. When the
LDRA receives Rx-interface signaling messages from the SBC, it uses the
subscriber's IP address in the messages to query the binding record locally
and forwards the messages to the corresponding PRCF.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 174


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

As the routing data configured on the P-GW is incorrect and the P-GW
directly routes subscriber registration messages to the PCRF without
traversing the LDRA, the LDRA does not store the session binding
information. When the LDRA fails to query the session binding
information, it discards AAR messages that fail to be routed. Consequently,
a bearer cannot be established for the calling party.
Condition The routing data configured on the P-GW is incorrect.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All UGW9811 versions
Solution
Workarounds:
N/A
Preventive measures:
Configure global routing data for the P-GW to directly contact the LDRA, which then
performs session binding.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 175


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.12.4 Calls Initiated by 4G Subscribers to the VoLTE Test Card


Fall Back to the 2G Network as Anchoring Data Is Not
Configured for the Card
Involved NE: HSS
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom The customer has prepared a VoLTE test card (15768144308).


When a VoLTE subscriber initiates a call to the VoLTE test card, the call is
connected successfully. However, when a 2G or 4G subscriber on the live
network initiates a call to the VoLTE test card, the call falls back to the 2G
network through circuit switched fallback (CSFB).
Trouble N/A
Ticket
Number
Root Cause Trace the messages on the IMS network for the called party. It is found that
the terminating S-CSCF and VoLTE AS do not receive any messages. This
indicates that the anchoring service is not triggered for the called party.
Instead, the call is directly routed to the MSC server for the called party.
Then, the MSC server performs combined paging to trigger the CSFB
procedure that enables call fallback to the 2G network.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 176


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The reason is that anchoring data (T-CSI, ServiceKey, and SCF Address) is
not configured on the HSS for the VoLTE test card.
Condition Anchoring data (T-CSI, ServiceKey, and SCF Address) is not configured on
the HSS for the VoLTE test card.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
N/A
Solution
Workarounds:
N/A
Preventive measures:
Configure anchoring data (T-CSI, ServiceKey, and SCF Address) on the HSS for the VoLTE
test card.

The HSS is an Ericsson device.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 177


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.12.5 Calls Fail When Diameter Route Data Is Not Configured for
the Rx Interface of the SBC
Involved NE: SBC
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom VoLTE voice calls occasionally fail.


Trace signaling messages on the originating side. It is found that the
originating SBC, after receiving an INVITE message from the calling
terminal, returns a CANCEL message to the calling terminal, indicating
that the media bearer is lost. Then, trace signaling messages on the
terminating side. It is found that the terminating SBC, after receiving a 183
message from the S-CSCF, returns a CANCEL message to the S-CSCF and
sends a 503 message ("Service Unavailable") to the called terminal,
indicating that the media bearer is lost.
Trouble N/A
Ticket
Number
Root Cause The message tracing result shows that the SBC fails to send an AAR
message to the PCRF, causing a failure in reserving resources.
Consequently, the calling party does not receive a 183 message from the
SBC before a timeout occurs and therefore the calling party sends a
CANCEL message to release the call.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 178


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Check data configuration on the SBC. It is found that Diameter routes from
the SBC to PCRF are not configured.
Condition Diameter routes from the SBC to PCRF are not configured.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All SE2900 versions
Solution
Workarounds:
N/A
Preventive measures:
On the SBC, run ADD DIAMRT to add Rx interface-specific routes from the SBC to PCRF.

2.12.6 There Is a Long Delay in Establishing Calls


Involved NE: MME
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom When a call is addressed to a 4G subscriber, there is a long delay in paging


the 4G subscriber, resulting in the calling party sending multiple INVITE
messages that carry the same CallID. After the paging is successful, the
called party receives these INVITE messages and returns multiple 100
(Trying) messages.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 179


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause To improve the LTE paging success rate of the live network in Guangzhou
City, enable accurate addressing on the MME. Accurate addressing means
addressing first from the last eNodeB and then from the track area (TA) list.
After accurate addressing is enabled, the delay in establishing some calls
will be prolonged.
Condition Accurate addressing is enabled.
Probability This issue occasionally occurs.
of
Occurrence

Involved Version
All USN9810 versions
Solution
Workarounds:
N/A
Preventive measures:
Disable accurate addressing for the VoLTE network.
After accurate addressing is disabled, the delay in establishing calls will be reduced by 300
milliseconds.

2.12.7 When an X2-based Handover Is Performed in a Call, the


EPC Does Not Send an QCI-1 Bearer Establishment Request,
Causing an Access Failure
Involved NE: SGW
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom When an X2-based handover is performed in a call, the EPC does not send
an QCI-1 bearer establishment request, causing an access failure. The
details are as follows: When a QCI-1 bearer fails to be established on the
originating side, the TQOS timer of the calling terminal will expire,
causing the calling terminal to release the call with a CANCEL message;
when a QCI-1 bearer fails to be established on the terminating side, the
TQOS timer of the called terminal will expire, causing the called terminal
to release the call with a 580 message.
Trouble N/A
Ticket

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 180


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Number
Root Cause 1. Signaling analysis on the terminal side: Trace SIP messages on the
calling terminal. It is found that the calling terminal sends a CANCEL
message eight seconds after receiving a 200 (to PRACK) message. During
this process, the calling terminal does not send an UPDATE message. This
indicates that the calling terminal does not receive a QCI-1 bearer
establishment request.
2. Signaling analysis on the eNodeB side: The eNodeB does not receive the
QCI1 establishment message from the MME on the EPC network.
Therefore, it does not issue a command to instruct the terminal to establish
a QCI1 bearer.
3. Signaling analysis on the SBC side: The SBC sends an AAR message to
the PCRF and receives the AAA message from it. This indicates that the
AAA/AAR message exchange is successful.
4. Signaling analysis on the SAEGWP-GW side: The terminal initiated a
VoLTE call at 16:40:42 and performed an X2 handover at 16:40:43. Almost
at 16:40:43, the PCRF sent an RAR message to instruct the SAEGWP-GW
to establish the dedicated QCI=-1 bearer. Almost at 16:40:43, the SAEGW
returned an RAA (cause code = 4002) to the PCRF.
It is concluded that X2-based handover conflicts with dedicated bearer
establishment. It is because the SAEGW does not send a QCI-1 bearer
establishment request that the call fails to be connected.
Condition X2-based handover conflicts with dedicated bearer establishment.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
Ericsson SAEGW
Solution
Workarounds:
N/A
Preventive measures:
The corresponding 3GPP protocol stipulates how the MME should behave when the eNodeB
is performing an X2-based handover, but not how the S-GW behave in this scenario. It is
recommended that the S-GW do the same as the MME in this scenario.
It is recommended Ericsson SAEGW continue to send a Create Bearer Request to the MME
for implementing VoLTE services because it can increase the call connection rate.
If this issue occurs, Huawei SAEGW does not consider the terminal unstable because the
handover is complete for the terminal. Therefore, Huawei SAE can continue to send a QCI-1
bearer establishment request to ensure the call connection.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 181


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.12.8 When a Call Is Addressed to a Subscriber Who Has Just


Registered, the Network Returns a 403 Message
Involved NE: UE
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom When a call is addressed to a subscriber who has just registered, the
network returns a 403 message. The call failure cause is "User is busy".
When a call is attempted to the subscriber again, the network still returns a
403 message.
Trouble N/A
Ticket
Number
Root Cause 1. Shortly after the calling party sent an INVITE message at 13:32:28.924,
an RRC connection and default bearer were established. At 13:32:30.265,
the network received a 100 (Trying) message and then a 403 (to INVITE)
message to the calling party, indicating that the called party was busy. The
calling party then sent a CANCEL message to release the call.
2. When the calling party initiated the call, the called party had just
registered with the IMS network.
3. At 13:33:21.282, the calling party sent an INVITE message again.
However, the network still returned a 403 message to the calling party,
indicating that the called party was busy.
As the first CANCEL message sent by the calling party carries SDP
information as opposed to RFC 6337/3312, IMS resources are not released
properly. When the calling party initiates a call again, the network still
returns a 403 message to deny the call.
The following are excerpts from RFC 6337/3312:
If a UAC generates an initial INVITE without an offer and receives an
offer in a 1xx or 2xx response which is not acceptable, it SHOULD
respond to this offer with a correctly formed answer and immediately send
a CANCEL or a BYE.
580 (Precondition Failure) responses and BYE and CANCEL requests,
indicating failure to meet certain preconditions, SHOULD contain an SDP
description, indicating which desired status triggered the failure. Note that
this SDP description is not an offer or an answer, since it does not lead to
the establishment of a session.
The format of such a description is based on the last SDP (an offer or an
answer) received from the remote UA.
Condition The CANCEL message sent by the calling terminal carries SDP
information.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 182


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
N/A
Solution
Workarounds:
N/A
Preventive measures:
1. Configure the SBC to delete SDP information from the CANCEL message. The final
solution is to urge terminal engineers to resolve the terminal defect.
2. Install the ATS9900 V300R001C20SPC109 patch to delete SDP information from the
CANCEL message.

2.12.9 eSRVCC Handovers Fail Due to Registration Errors


Involved NE: ATS/DNS
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom When a call is addressed to a Shenzhen subscriber roaming in Guangzhou,


an eSRVCC handover may occasionally fail with an announcement. The
details are as follows: The terminal shows that the subscriber has switched
to the GSM network. However, an announcement is immediately played
stating that the STN-SR does not exist, and then the call is automatically
released.
Trouble N/A
Ticket
Number
Root Cause Trace signaling messages on the ATCF. It is found that the ATCF does not
receive an INVITE message (for handover) from the eMSC server. Trace
signaling messages on the MME. It is found that the PS_TO_CS_Handover
message sent by the MME carries the STN-SR (8613445248). However,
the STN-SR is the number defined on the HSS but number analysis data is
not configured for the STN-SR. When the eMSC server fails to analyze the
STN-SR, it instructs the end office to play an announcement stating that the
SNR-SR does not exist.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 183


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The STN-SRs of the SBC in Guangzhou are 13445236, 13445237,


13445238, and 13445239. When a Shenzhen subscriber is roaming to
Guangzhou, the SCC AS must send a PUR message to update the STN-SR
on the HSS upon subscriber reregistration. Trace signaling messages on the
SCC AS. It is found that the SCC AS does not actually send a PUR
message to update the STN-SR upon subscriber registration. Consequently,
the HSS does not send an IDR message to instruct the MME to update the
STN-SR. During an eSRVCC handover, the MME carries the incorrect
STN-SR to the eMSC server, resulting in the handover failure
announcement.
The reason why the SCC AS does not send a PUR message is that no
MESSAGE message is sent to the SBC after subscriber registration.
The reason why no MESSAGE message is sent to the SBC is that the
ATCF domain name fails to be obtained through DNS query. Check data
configuration on the DNS in Guangzhou and it is found that gzatcf1bhw gd
ims mnc000 mcc460 3gppnetwork org is incorrect, causing the DNS query
failure.

Condition Data configuration on the DNS is incorrect.


Probability This issue will occur when the preceding condition is met.
of

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 184


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Occurrence

Involved Version
N/A
Solution
Workarounds:
N/A
Preventive measures:
On the DNS, modify SRV query data for the ATCF.

2.12.10 Calls Fail to Be Answered After aSRVCC Handovers Are


Performed for VoLTE Subscribers Who Have Subscribed to the
CRBT Service and Are Being Alerted of Incoming Calls
Involved NE: eMSC
Applicable Scope: global
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details

Symptom The call fails to be answered after an aSRVCC handover is performed for a
VoLTE subscriber (in Shenzhen) who has subscribed to the CRBT service
and is being alerted of an incoming call. The eMSC server returns a 488
message.
Trouble N/A
Ticket
Number
Root Cause After a handover is completed, the terminal answers the call by returning a
200 message. The CRBT AS needs to update SDP information. The SCC
AS sends an INVITE message to the eMSC server through the SBC,
instructing the eMSC server to update SDP information. The INVITE
message carries the codecs as shown in the following figure.
However, the eMSC server returns a 488 message carrying "Incompatible
media format".

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 185


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The reason is that the INVITE message carries AMR rate set 7 but the
eMSC server supports only AMR rate set 1.
Condition The codecs supported by the SCC AS and eMSC server are different.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Modify data configuration on the eMSC server.
That is, set the inter-office codec to UMTS-AMR2(set 7).

2.12.11 ZTE Terminal Users Who Have Subscribed to IN Services


Encounter Call Loss
Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: Su Wei (ID: 00266878)
Defect Details

Symptom A ZTE terminal user has subscribed to an Intelligent Network (IN) service.
After the ZTC terminal user initiates a call and talks with the called party
for three minutes and six seconds, the call is automatically released.
Trouble N/A
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 186


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause The call flow is as follows:

After the call is answered, the SCP AS sends an OPTIONS message to the
ZTE terminal every three minutes. The ZTE terminal (using the MKT chip)
includes SDP information in a 200 (to OPTIONS) message but the SCC AS
does not transparently transmit the message. Consequently, the MMTel AS
sends a 408 message, resulting in the SCP AS releasing the call.
Currently, when the 200 (to OPTIONS) message carries SDP information,
the SCC AS fails to match the message with the Offer/Answer model and
therefore discards it.
According to RFC 3261, the 200 (to OPTIONS) message returned by the
ZTE terminal is allowed to carry SDP information.
RFC 3261
A message body MAY be sent, the type of which is determined by the
Accept header field in the OPTIONS request (application/sdp is the default
if the Accept header field is not present). If the types include one that can
describe media capabilities, the UAS SHOULD include a body in the
response for that purpose. Details on the construction of such a body in the
case of application/sdp are described in [13].
According to RFC 3264, SDP information does not affect the offer/answer
negotiation unless the port number is 0.
An SDP constructed to indicate media capabilities is structured as follows:
It MUST be a valid SDP, except that it MAY omit both "e=" and "p=" lines.
The "t=" line MUST be equal to "0 0". For each media type supported by
the agent, there MUST be a corresponding media description of that type.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 187


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The session ID in the origin field MUST be unique for each SDP
constructed to indicate media capabilities. The port MUST be set to zero,
but the connection address is arbitrary. The usage of port zero makes sure
that an SDP formatted for capabilities does not cause media streams to be
established if it is interpreted as an offer or answer.
The preceding analysis shows that the issue is caused by the fact that the
SCC AS incorrectly processes the SDP information in the 200 (to
OPTIONS) message.
Condition ZTE terminal users has subscribed to IN services.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
ATS9900 V100R006C10SPC200
Solution
Workarounds:
N/A
Preventive measures:
Install the V100R006C10SPH218 patch.

2.12.12 eSRVCC Handovers Fail When Calls Addressed to


Roaming Subscribers Are in the Alerting State
Involved NE: AS
Applicable Scope: global
Troubleshooting Engineer: Su Wei (ID: 00266878)
Defect Details

Symptom A subscriber in Hunan Province is roaming in Jiangsu Province. When one


call addressed to the subscriber is in the alerting state, an eSRVCC
handover may fail.
Trouble N/A
Ticket
Number
Root Cause Three eSRVCC handover tests have been performed, but only one eSRVCC
handover is successful.
The details are as follows:
Messages Traced for the First Failed eSRVCC Handover
1. Messages traced on the SBC

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 188


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2. Messages traced on the eMSC server

Messages Traced for the Successful eSRVCC Handover


1. Messages traced on the SBC

2. Messages traced on the eMSC server

Message flow for the failed eSRVCC handover:

Message flow for the successful eSRVCC handover:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 189


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

According to 3GPP 24237, the SCC AS sends an INFO message only


after receiving a PRACK (to 183) message.
The following are excerpts from 3GPP 24237:
Session transfer for incoming call is in alerting phase using PS to
CS SRVCC procedure: PS to CS
In the example flow at the figure A.17.2-1, SC UE A has an incoming
session with speech media component which is anchored at SCC AS.
The session is in alerting phase. Based upon measurement reports sent
from the UE to E-UTRAN, the source E-UTRAN decides to trigger a
PS to CS SRVCC handover to CS access.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 190


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

This issue is caused by incorrect actions performed by the SCC AS


(ZTE device) that serves the roaming subscriber.
Condition The AS performs an eSRVCC handover for one call addressed to a roaming
subscriber that is in the alerting state.
Probability This issue occasionally occurs.
of
Occurrence

Involved Version
N/A

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 191


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Solution
Workarounds:
N/A
Preventive measures:
ZTE needs to rectify the SCC AS to resolve this issue.

2.12.13 Mid-Call Handover Fails for Calls Made by Dialing the


Short Number
Involved NE: eMSC
Applicable Scope: global
Troubleshooting Engineer: Su Wei (ID: 00266878)
Defect Details

Symptom A calls C by dialing the short number. After the call is answered, A places
the call on hold and calls B. The call is answered by B. A triggers an
eSRVCC handover. The call between A and B can be handed over but the
call between A and C cannot.
Trouble N/A
Ticket
Number
Root Cause The following figure shows the correct mid-call handover procedure:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 192


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Different from the correct mid-call handover procedure, the eMSC server
does not send an INVITE message as in step 28 after receiving a REFER
message and returning a 202 message.
When the eMSC server receives the REFER message pertaining to the
second call, it tries to analyze the called number in the Refer-To header
field. As number analysis data is not configured for the called number that
is a short number, analyzing the called number fails and the handover flow
is terminated. The following figure shows the incorrect handover
procedure:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 193


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

To resolve this issue, configure the eMSC server to select a route based on
the ATCF URI in the Refer-To header field rather than analyzing the called
number.
Condition A mid-call handover occurs for calls made by dialing the short number.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Install the V200R010C10SPH110 patch.

2.12.14 After an eSRVCC Handover Is Performed for an Alerting


Call but the Calling Party Hangs Up Before the Called Party
Answers the Handed-Over Call, the Call Cannot Be Released on
the Terminating Side
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer: Huang Jianguo (ID: 00135928)
Defect Details

Symptom eSRVCC handover test result: After an alerting call is handed over but the
calling party hangs up before the called party answers the handed-over call,

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 194


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

the call cannot be released on the terminating side. The message tracing
result of the SCC AS shows that the SCC AS returns a 487 message to the
originating side and a 480 (Reason: Q.850;cause=66;text="channel type not
implemented") message to the ATCF after receiving a CANCEL message
from the originating side.
The feedback from NSN engineers for the eMSC server (SRVCC IWF)
shows that the SCC AS (Huawei) must send a CANCEL or BYE message
to stop the alerting tone after the eMSC server (NSN) returns a 480
message.
Trouble 5443542
Ticket
Number
Root Cause The message tracing result shows that the SCC AS initiates a handover
request to the eMSC server (as indicated in line 151) and receives a 183
message (as indicated in line 177). At this time, the called party is being
alerted of an incoming call.

Later, the SCC AS receives a 503 message from the PSBC side. The
original call is released, and the handover is successful. After nine seconds,
the calling party sends a CANCEL message (as indicated in line 239).
Then, the SCC AS converts the CANCEL message to a 480 message (as
indicated in line 280) and sends the 480 message to instruct the eMSC
server to release the handed-over call.
The reason why the SCC AS converts the CANCEL message to a 480
message is as follows:
The SCC AS receives an INVITE message from the eMSC server and
returns a 183 message to the eMSC server. To terminate the INVITE
transaction, the SCC AS must return a final response to the eMSC server.
However, as the calling party releases the call, the final response can only
be Oxx or 480.
The CANCEL message is used to cancel the previous request. As the SCC
AS itself receives an INVITE message from the eMSC server, it cannot

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 195


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

send a CANCEL message to instruct the eMSC server to cancel the


INVITE request. The only thing that the SCC AS can do is to return an Oxx
message.
In addition, as the SCC AS has not sent a 200 (to INVITE) message to the
eMSC server, it cannot release the call with a BYE message. There is a
problem with the eMSC server when it does not stop the alerting tone for
the called party upon receiving a 480 message. Therefore, ask NSN to
resolve this problem.
Condition An eSRVCC handover is performed for an alerting call but the calling party
hangs up before the called party answers the handed-over call.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
ATS9900 V100R010C10SPH213
Solution
Workarounds:
N/A
Preventive measures:
Ask NSN to rectify the eMSC server.

2.12.15 Calls Are Released When the LIA Message Returned by


Bell DRA Contains Error Code 5012
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer: Huang Jianguo (ID: 00135928)
Defect Details

Symptom After the I-CSCF receives an INVITE message from the AS, it sends an
LIR message to Bell DRA. After eight seconds, the I-CSCF has not
received an LIA message, causing the I-CSCF to release the call with a 488
message.
Although the feedback from Bell engineers shows that Bell DRA has sent
an LIA message to the I-CSCF, Huawei finds that the I-CSCF has not
received the LIA message.
Trouble N/A
Ticket
Number
Root Cause Trace Diameter messages on the CSCF. It is found that the CSCF has
received an LIA message half a second after it sends an LIR message to

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 196


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Bell DRA.

However, the subscriber messages traced on the CSCF show that the I-
CSCF has sent an LIR message and encountered a timeout after eight
seconds.

If the LIA message can be traced through Diameter message tracing but not
through subscriber message tracing (service layer tracing), the Diameter
protocol layer may encounter an error. Enable the debug tracing on the
CSCF. The following information is displayed:
M0161P192F03S08M 2015-11-26 16:13:03
ERR [a/source/Sig/DiamRM/src/diameterlm.c FileID(770) : 5260
<DiamDebugSend>]
Diameter Stack Debug:Error Information[DiamRmValidateRsp, 3594]E-Bit
set in the answer message.ResultCodeType = 5ResultCodeValue = 5012
It is found that E-Bit (indicated in error) is set to TRUE in the case of
ResultCodetype=5012.

According to RFC 3588, E-Bit can be set to TRUE only when the error
code falls within the range 3001 to 3010. That is, E-Bit cannot be set to
TRUE when the error code is 5012.
7.1.3 Protocol Errors
Errors that fall within the Protocol Error category SHOULD be treated on a
per-hop basis, and Diameter proxies MAY attempt to correct the error, if it
is possible. Note that these and only these errors MUST only be used in

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 197


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

answer messages whose 'E' bit is set.


DIAMETER_COMMAND_UNSUPPORTED3001
The Request contained a Command-Code that the receiver did not
recognize or support. This MUST be used when a Diameter node receives
an experimental command that it does not understand.
Therefore, this issue is related to the HSS.
Condition Error code 5012 is returned when the I-CSCF sends an LIR message to the
HSS of another vendor.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
CSC3300 V100R010C10SPH210
Solution
Workarounds:
N/A
Preventive measures:
Ask the corresponding vendor to rectify the HSS.

2.12.16 Inband Digit Collection Fails for Calls from VoLTE


Subscribers to the 114 Service Platform When the P-Early-Media
Header Field Value in the 183 Message Sent by MGCF Is
sendonly
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer: Huang Jianguo (ID: 00135928)
Defect Details

Symptom When a VoLTE subscriber in Shanxi Province initiates a call to the 114
service platform, the platform returns a 183 message and plays an
announcement. However, when the subscriber follows the announcement to
press the key 1, 2, or 3, no response is returned. The messages traced on the
MGCF show that the UMG does not send a NOTIFY message to report
DTMF signals.
The subscriber can initiate a call to the 10086 service platform. The
message flow is different from that for calls made to the 114 service
platform. The details are as follows: The 10086 service platform returns a
200 message. After the subscriber presses keys, responses are returned. The
MGCF can receive the NOTFIY message and send the APM message (out-
of-band message).

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 198


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble 5346500
Ticket
Number
Root Cause The message tracing result shows that when the subscriber initiates a call to
the 114 service platform, the terminating side returns a 183 message to the
subscriber and immediately plays an announcement to instruct the
subscriber to press keys. This is inband digit collection during the session
establishment.
Trace subscriber messages on the SBC. It is found that the subscriber
presses keys on the terminals after the MGCF returns a 183 message. It is
also found that the MGCF sends media packets to the terminal but the
terminal does not send media packets to the MGCF. This indicates that the
terminal does not send the media streams related to pressed keys to the
MGCF.
Trace signaling messages on the MGCF. It is found that the SDP body of
the 183 (to INVITE) message sent by the MGCF carries a=rtpmap:102
telephone-event/8000, which indicates that DTMF digit collection is
supported. Then, check the 183 message used for playing an
announcement. It is found that the P-Early-Media header field value is
sendonly.

According to 3GPP 34.229, when the P-Early-Media header field value is


sendonly or sendrevc, another DTMF signaling messages will be generated
and the most recently received P-Early-Media header field will be used.
That is, if the P-Early-Media header field value is sendonly, the terminal
does not implement inband digit collection through DTMF.
If the UE supports the P-Early-Media header field as defined in
IETFRFC5009, and a P-Early-Media header field has been received, then
the UE shall send any available user generated media, e.g. speech or
DTMF, on media stream(s) associated with the early dialog for which the
most recent P-Early-Media header field, as described in IETFRFC5009,
contained a "sendrecv" or a "recvonly" header field value. If there is more
than one such early dialog, the UE shall use the early dialog where the P-
Early-Media header field was most recently received.
Therefore, this issue is caused by the inband 183 message sent by the
MGCF. To resolve this issue, run MOD SIPTG on the MSOFTX3000 to

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 199


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

set ESFPARA7 to FUNC15-0.


When the MSOFTX3000 includes the P-Early-Media header field in a 18x
message, this header field is set to sendrecv by default. If this header field
is set to sendonly, run the following example command on the
MSOFTX3000:
MOD SIPTG: TGN="XXX", ESFPARA7= FUNC15-0;
Condition 1. Inband digit collection occurs before session establishment.
2. FUNC15 is enabled for ESFPARA7 by running MOD SIPTG on the
MSOFTX3000.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C20SPC100
Solution
Workarounds:
N/A
Preventive measures:
Run MOD SIPTG on the MSOFTX3000 to set ESFPARA7 to FUNC15-0.
MOD SIPTG: TGN="XXX", ESFPARA7= FUNC15-0;

2.12.17 Announcements Fail for Video Calls Addressed to


Powered-Off Phones
Involved NE: MRFC
Applicable Scope: global
Troubleshooting Engineer: Huang Jianguo (ID: 00135928)
Defect Details

Symptom When a video call is made to a powered-off phone, the MRFC returns a
500 message after the MMTEL AS sends an INVITE message to request
the MRFC to play an announcement.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 200


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble 5489225
Ticket
Number
Root Cause The error information Cro response pb fail,Bc=27(1625) is typically
generated due to a license restriction. Check H.248 messages between the
MRFC and MRFP. It is found that the following information is displayed.

This indicates that there is no H.264 license. The DSP LICENSERES


command output of the MRFP does not contain the H.264 license.
However, the video call contains the H.264 codec.

Condition There is no H.264 license.


Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All MRFC versions
Solution
Workarounds:
N/A
Preventive measures:
As there are no video resources involved for the MRFP to play announcements, run MOD
MRFPRES on the MRFC to delete all video capabilities of the MRFP.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 201


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

MOD MRFPRES: MRFPNAME="MAR_MRFP", VCODEC=H261-0&H263-0&H264-


0&MPEG4-0;

Application Limitation: On the live network, the MRFC does not interwork with the convergent
conference system of the MediaX (that is, there is no VOBB&VoLTE& convergent conferencing
scenario). Therefore, the video license is not required.

2.12.18 404 Message Is Returned When an iPhone Registers


Involved NE: SBC
Applicable Scope: global
Troubleshooting Engineer: Su Wei (ID: 00266878)
Defect Details

Symptom During the iPhone access test, when the SCC AS includes the C-MSISTN
and ATU-STI in the MESSAGE message sent to the ATCF, the SBC returns
a 404 message, indicating that the corresponding subscriber data record
cannot be found.
Trouble N/A
Ticket
Number
Root Cause Trace messages on the live network. It is found that this issue occurs when
the iPhone, after completing an eSRVCC handover and releasing the
handed-over call, returns from the IMS to CS domain for registration. The
following are the message flows for the successful and failed registrations:
Message Flow for the Successful Registration

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 202


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The key descriptions are as follows:


1. The iPhone uses Address-A to initiate a call, completes an eSRVCC
handover, and then releases the call in the CS domain. (The call lasts about
10 seconds.)
2. The iPhone returns to the VoLTE domain from the CS domain and uses
Address-B to register. The IMS Core needs to remove the binding between
the iPhone subscriber and Address-A, that is, to initiate the corresponding
deregistration flow. (The blue part in the preceding figure shows the
deregistration flow.)
3. The S-CSCF receives a REGISTER message after returning a 401
message. Then, the S-CSCF sends two NOTIFY messages to the SBC, one
for the terminal to subscribe to the subscriber status, and the other for the
SBC to subscribe to the subscriber status. The SBC can quickly return a
response for its subscription to the subscriber status. However, the SBC
cannot receive a response for the subscription sent by the terminal through
Address-A. Consequently, the SBC transmits the NOTIFY message
repeatedly.
4. The S-CSCF sends a REGISTER message to the SCC AS for the
deregistration initiated using Address-A. At the same time, the S-CSCF
also sends a REGISTER message to the SCC AS for the registration
initiated using Address-B. Then, the S-CSCF sends a 200 (to REGISTER)
message to the SBC.
5. When the SCC AS first receives the REGISTER message for the
deregistration initiated using Address-A, it removes the subscriber
information.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 203


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

6. When the SCC AS then receives the REGISTER message for the
registration initiated using Address-B, it exchanges messages with the HSS
to obtain the subscriber information. This operation takes several seconds.
After this operation, the SCC AS sends a MESSAGE message to the ATCF
to update the C-MSISDN and STU-STI.
7. The SBC receives a 200 (to REGISTER) message and creates the
corresponding subscriber data record. If the received MESSAGE message
can match the created subscriber data record and the subscriber's C-
MSISDN and STU-STI can be successfully inserted, it returns a 200 (to
MESSAGE) message.
Message Flow for the Failed eSRVCC Handover

The first four steps are similar to those in the message flow for the
successful eSRVCC handover.
1. The iPhone uses Address-A to initiate a call, completes an eSRVCC
handover, and then releases the call in the CS domain. (The call lasts about
10 seconds.)
2. The iPhone returns to the VoLTE domain from the CS domain and uses
Address-B to register. The IMS Core needs to remove the binding between
the iPhone subscriber and Address-A, that is, to initiate the corresponding
deregistration flow. (The blue part in the preceding figure shows the
deregistration flow.)

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 204


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

3. The S-CSCF receives a REGISTER message after returning a 401


message. Then, the S-CSCF sends two NOTIFY messages to the SBC, one
for the terminal to subscribe to the subscriber status, and the other for the
SBC to subscribe to the subscriber status. The SBC can quickly return a
response for its subscription to the subscriber status. However, the SBC
cannot receive a response for the subscription sent by the terminal through
Address-A. Consequently, the SBC transmits the NOTIFY message
repeatedly.
4. The S-CSCF sends a REGISTER message to the SCC AS for the
deregistration initiated using Address-A. At the same time, the S-CSCF
also sends a REGISTER message to the SCC AS for the registration
initiated using Address-B. Then, the S-CSCF sends a 200 (to REGISTER)
message to the SBC.
The main differences are as follows:
When the S-CSCF performs a third-party registration, it first sends a
REGISTER message for the deregistration initiated using Address-A and
then sends a REGISTER message for the registration initiated using
Address-B. The two REGSITER messages are sent by the S-CSCF almost
at the same time.
As SIP message are UDP-based, the UDP protocol cannot ensure the
sequence in which messages are transmitted. Therefore, the SCC AS may
first receive a REGISTER message for the registration initiated using
Address-B and then receives a REGISTER message for the deregistration
using Address-A.
1. If the SCC AS first receives a REGISTER message for the registration
initiated using Address-A, it uses the subscriber's IMPU to query the
subscriber data. When the SCC AS finds the subscriber data and the
registration part contains expire=3600, the SCC AS determines that the
reregistration flow is initiated. In the reregistration flow, the SCC AS does
not need to interact with the HSS to obtain any data. Instead, it sends a
MESSAGE message that contains the C-MSISDN and ATU-STI to the
ATCF.
2. The 200 (to REGISTER) message is sent by the S-CSCF to the SBC
through the I-CSCF, but the MESSAGE message is directly sent by the
SCC AS to the SBC. Therefore, the SBC may receive the 200 (to
REGISTER) and MESSAGE messages almost at the same time or may first
receive the MESSAGE message and then the 200 (to REGISTER)
message. This causes the SBC to encounter a defect. That is, the SBC
cannot use the C-MSISDN in the MESSAGE message to query the
subscriber data, resulting in the SBC returning a 404 message.
3. When the SCC AS receives a REGISTER message for the registration
initiated using Address-B and then a REGISTER message for the
deregistration initiated using Address-A, the subscriber data on the SCC AS
is not affected. That is, when the SCC AS determines that Address-A used
for the deregistration does not match Address-B bound with the subscriber,
it does not modify the subscriber data locally.
Note that the registration flows of the iPhones and Huawei Mate 7 phones
vary as follows:
1. After an eSRVCC handover, the iPhone performs re-attachment,
modifies the local IP address, and then registers when returning from the
CS to VoLTE domain.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 205


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2. After an eSRVCC handover, Huawei Mate 7 phone still uses the original
IP address for registration when returning from the CS to VoLTE domain.
Condition The iPhone registers after an eSRVCC handover.
Probability This issue occasionally occurs.
of
Occurrence

Involved Version
SE2900 V300R001C02
Solution
Workarounds:
N/A
Preventive measures:
Install the V300R001C02SPH111 patch.

2.12.19 During a Mid-Call Handover, the REFER Message Cannot


Be Sent
Involved NE: ATS
Applicable Scope: global
Troubleshooting:
Defect Details

Symptom During a mid-call handover, as the number in the P-Asserted-Identity


header field for the call from C to A is not a global one, the REFER
message cannot be sent.
Trouble N/A
Ticket
Number
Root Cause 1. When C in a call calls A, A is alerting and an eSRVCC handover is
performed for the alerting call. The number in the P-Asserted-Identity
header field for the call from C to A is not a global one.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 206


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2. During the eSRVCC handover, the SCC AS constructs a REFER


message after receiving a 200 (to the handover INVITE message) and ACK
message. When constructing the REFER message, the SCC AS sets the
From header field to the value of the P-Asserted-Identity header field in the
initial INVITE message.
3. When the SCC AS fails to obtain the calling number prefixed with the
plus sign (+), it normalizes the calling number by querying the local DN
set. However, as the SCC AS does not store the data from the MMTel AS,
the normalization fails. Consequently, the REFER message cannot be sent,
causing the eSRVCC handover failure.
Condition During a mid-call handover, the number of the P-Asserted-Identity header
field is not a global one.
Probability This issue occurs when the preceding condition is met.
of
Occurrence

Involved Version
ATS9900 V100R006C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Install the V100R006C10SPH218 patch.

2.13 Fault Cases for October 2015


2.13.1 When a Registered UE Initiates a Subscription to the
Subscriber Status, the NOTIFY Message Returned by the S-CSCF
Carries "terminated;reason=noresource"
Involved NE: CSC3300

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 207


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Applicable Scope: global


Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom When a registered UE initiates a subscription to the subscriber status, the


NOTIFY message returned by the S-CSCF carries
"terminated;reason=noresource".
Trouble N/A
Ticket
Number
Root Cause 1. Check the traced subscriber messages. It is found that this issue is
caused by the fact that the S-CSCF fails to query subscriber data.
Theoretically, after a UE registers, the S-CSCF stores the corresponding
subscriber data (see the following figure).

2. Analyze why the S-CSCF fails to query the subscriber data. The
analysis result shows that the S-CSCF with which the UE has registered
is not the S-CSCF to which the UE has initiated a subscription to the
subscriber status. Consequently, the latter S-CSCF cannot query the
subscriber data locally.
Address of the S-CSCF with which the UE has registered:

Address of the S-CSCF to which the UE has initiated a subscription to


the subscriber status:

3. Analyze why the SBC sends the SUBSCRIBE message to the incorrect
S-CSCF. The data configuration submitted by field engineers shows that
the SBC uses an embedded DNS for managing mappings between

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 208


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

domain names and IP addresses. Due to the data configuration on the


DNS, the SBC sends the SUBSCRIBE message to the incorrect S-
CSCF.

4. Correct the data configuration on the SBC. It is found that this issue is
resolved.
Condition  A registered UE sends a subscription to the subscriber status.
 The DNS data configuration for the P-CSCF is inconsistent with that for
the I-CSCF.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
CSC3300 V100R011C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Correct the DNS data on the SBC to enable the SBC to map S-CSCF host names to the
corresponding S-CSCF IP addresses.

2.13.2 After the S-CSCF Fails to Contact an AS, It Does Not


Continue to Contact Another AS
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom When the S-CSCF contacts an AS, the AS returns a 598 message. Then, the
S-CSCF does not continue to contact another AS.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 209


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause STASFPLCY data on the S-CSCF determines whether the S-CSCF denies
the call or continues to process the call based on iFC data when it fails to
contact an AS. If STASFPLCY data is not configured, the S-CSCF by
default denies the call when it fails to contact an AS.

This issue is caused by lack of STASFPLCY data.


In addition, note the following:
In STASFPLCY data, Policy must be set to CHKDFHAND(Check
default handling). The value of Default handling in the iFC data is also
used to determine whether the S-CSCF continues the call.
As the protocol stack does not forward some special failures (for example,
481) to the service layer, the S-CSCF directly releases the corresponding
calls. Therefore, STASFPLCY data does not take effect for such special
failures.
By default, STASFPLCY data takes effect for the following failures: 408,
500, 501, 502, 504, 505, 513, 533, and 580.
Condition STASFPLCY data is not configured on the S-CSCF.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
CSC3300 V100R011C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Configure the corresponding STASFPLCY data on the S-CSCF.

2.13.3 After an eSRVCC Handover, the MGCF Fails to Send ICS


Registrations Due to "Authentication Failure"
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 210


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Defect Details

Symptom After an UE hands over from the LTE to CS network, the MGCF fails to
proxy ICS registrations for the UE due to an authentication failure.
Trouble N/A
Ticket
Number
Root Cause It is found that the REGISTER message sent by the MGCF has carried
integrity-projected="auth-done" and TDMI data on the S-CSCF shows
that the S-CSCF allows registration in auth-done mode.
Theoretically, when the S-CSCF receives the REGISTER message from the
MGCF, it determines that CS authentication has been performed and IMS
authentication is not required. However, the message tracing result shows
that the S-CSCF still sends an MAR message. This is because the S-CSCF
does not trust auth-done carried in the REGISTER message sent by the
MGCF.
The analysis of TDMI data submitted by field engineers shows that the
following two TDMI data records conflict:
ADD TDMI: ADDRT=IPADDRESS, IPSEG="10.145.34.120",
MASK="255.255.0.0", ALLOWAUTHDONE=N;
ADD TDMI: ADDRT=IPADDRESS, IPSEG="10.145.34.62",
MASK="255.255.0.0", ALLOWAUTHDONE=Y;
After the S-CSCF matches the first TDMI data record, it does not trust
auth-done carried in the REGISTER message sent by the MGCF and
therefore sends an MAR message to request authentication. This causes an
authentication failure.
Condition TMDI data on the S-CSCF is incorrect.
Probability This issue always occurs.
of
Occurrence

Involved Version
CSC3300 V100R011C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Correct TDMI data on the S-CSCF.
MOD TDMI: ADDRT=IPADDRESS, IPSEG="10.145.34.120", MASK="255.255.0.0",
ALLOWAUTHDONE=Y;

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 211


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.13.4 RCS Client Receives "Unsupported media type" When


Sending MESSAGE Messages
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom When an RCS client sends a MESSAGE message, the CSCF returns a 415
message carrying "Unsupported media type".
Trouble N/A
Ticket
Number
Root Cause 1. When an RCS client sends a MESSAGE message, the CSCF returns a
415 message carrying "Unsupported media type" (see the following figure).
This is because that the CSCF does not support the content in the
MESSAGE message sent by the RCS client.

2. However, due to privacy protection, the content cannot be viewed in the


subscriber message tracing result. Therefore, contact field engineers to
trace IP messages.
3. The IP message tracing result (CGP IP messages can be converted to
CAP messages) shows that the MESSAGE message carries the following
media types:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 212


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

4. It is found that SMSG data has been modified on the customer side
(SMSG data before modification can support all media types). This issue
can be resolved after SMSG data is corrected.
Condition SMSG data on the S-CSCF is incorrect.
Probability This issue always occurs.
of
Occurrence

Involved Version
CSC3300 V100R011C10SPC100
Solution
Workarounds:
N/A
Preventive measures:
Configure SMSG data.
ADD SMSG: MEDT=APPLICATION, MEDST=ALL, MSGLEN=1500;

2.13.5 During a Mid-Call eSRVCC Handover (with One Held


Session and One Active Session), the BYE Message Sent by the
SCC AS Carries "channel type not implemented"
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom During a mid-call eSRVCC handover, the SCC AS sends a BYE message to
release the call.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 213


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause 1. In the normal handover flow, after the SCC AS returns a 200 (to
INVITE) message, it needs to send a REFER message instructing the
eMSC server to perform media negotiation for the second call.

2. The Refer-To header field in the REFER message needs to contain


session information (call-id, from-tag, and to-tag) and SDP information.
However, as SDP information exceeds 1024 bytes, the SCC AS fails to
construct a REFER message.
Condition The SDP information carried for the held session exceeds 1024 bytes.
Probability This issue always occurs.
of
Occurrence

Involved Version
ATS9900 V100R006C10SPC210
Solution
Workarounds:
N/A
Preventive measures:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 214


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

ATS9900 V100R006C10SPH212 has been developed to resolve this issue.

2.13.6 Incorrect Access Network Information in the CDRs


Generated in VoWiFi Handover Scenarios Results in a Failure in
Sorting Out VoWiFi and VoLTE CDRs
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom Incorrect access network information in the CDRs generated in VoWiFi


handover scenarios results in a failure in sorting out VoWiFi and VoLTE
CDRs.
Trouble 4956699
Ticket
Number
Root Cause 1. After the UE hands over from the VoLTE to VoWiFi network and
releases the call, Access-Network-Information in the VoWiFi CDRs is
still set to 3GPP-E-UTRAN-FDD;utran-cell.
2. When the CCF consolidates ACRs, it obtains pAccessNetworkinfo from
the first ACR message and fills the information in the pAccessNetworkinfo
field. If the CCF receives such an ACR message during a handover between
VoLTE and VoWiFi networks, the CCF starts ACR consolidation.
3. The ATS is configured to first send an ACR [Start] message and then an
ACR [Interim]message at an interval of three minutes. The access network
information in the ACR [Start] message is the same as that in the ACR
[Interim] message. This may cause the CCF to fill incorrect access network
information during ACR consolidation. Due to the incorrect access network
information, the billing center cannot sort out VoLTE and VoWiFi CDRs.
4. The detailed analysis is as follows:
4.1 The calling party (A) registers with IMS over LTE.
4.2 A calls B. After the call is connected, the ATS sends an ACR [Start]
message to the CCF.

4.3 Media renegotiation is performed, and an ACR [Interim] message is


sent to the CCF.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 215


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

4.4 A handover to VoWiFi is performed, and an ACR [Interim] message is


sent to the CCF.

1. After three minutes, another ACR [Interim] message is sent to the CCF.

1. After the call ends, an ACR [Stop] message is sent to the CCF.

In this way, the ACR consolidation for steps 4.1 and 4.2 is correct but the
access network information in the ACR consolidation for steps 4.3 and 4.4

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 216


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

is incorrect.
Condition A handover is performed between the VoWiFi and VoLTE networks.
Probability This issue always occurs.
of
Occurrence

Involved Version
ATS9900 V100R008C10 TR5
Solution
Workarounds:
N/A
Preventive measures:
This issue has been resolved in ATS9900 V100R008C10 TR6.

2.13.7 Media Collision Occurs in "CS CFB + Precondition"


Scenarios
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details

Symptom Media collision occurs in "CS CFB + precondition" scenarios.


Trouble 4884748
Ticket
Number
Root Cause The test scenario is as follows:
1. VoLTE subscribers A, B, C, and D belong to the same home network. A
and B are attached to the 2/3G network.
2. B has subscribed to the CFB service with C as the forwarded-to party. A
and C are idle. A call is established between B and D.
3. A calls B.
4. The call from A is forwarded to C.
The message flow is as follows:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 217


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition The preceding test scenario occurs.


Probability This issue occasionally occurs.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C20
Solution
Workarounds:
N/A
Preventive measures:
Set bit 8 of P1510 to 0.
The following figure shows the description of bit 8 of P1510:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 218


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.13.8 Calling Parties Cannot Hear the Ring Back Tone When
Calls to CRBT Subscribers Are Forwarded Upon No Reply
Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: Wu Dai (ID: 00146329)
Defect Details

Symptom A, B, and C are VoLTE subscribers. B has subscribed to the Customized


Ring Back Tone Control and Trigger (CRBT) service and Call Forwarding
No Reply (CFNR) service. C is under VoLTE coverage. When a call from A
to B is forwarded to C upon no reply, A cannot hear the ring back tone from
C. However, if C is in the CS domain, A can hear the ring back tone from
C.
Trouble N/A
Ticket
Number
Root Cause The call scenario is as follows:
B has subscribed to the CRBT service. The following figure shows the
networking diagram where B is alerted:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 219


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

As shown in the figure, A hears the CBRT announcement through inband


signaling. This is because the PEM indicator in the 180 message sent by the
CRBT platform is set to sendrecv.

The following figure shows the networking diagram where a 180 message
is returned when the forwarded-to subscriber is under VoLTE coverage:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 220


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The 180 message does not carry any PEM indicator. According to the
relevant protocol, the calling mobile phone takes the PEM indicator
received last time. However, as the inband signaling for the CRBT
announcement has been released, the CRBT announcement cannot be
played.
The following figure shows the networking diagram where C is in the CS
domain:

The MGCF converts the ACM message to a 180 message whose PEM
indicator is inactive. When the mobile phone receives this indicator, it
switches to the local mode for playing the ring back tone.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 221


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The following are excerpts from relevant protocols:


3GPP TS 24.628:
The UE shall not generate the locally generated communication progress
information if an early dialog exists where the last received P-Early-Media
header field as described in IETF RFC 5009 [12] contains "sendrecv" or
"sendonly".
RFC 5009:
After an early media authorization request has been received within a
dialogue, and a subsequent message is received without the P-Early-Media
header field, the previous early media authorization remains unchanged.
3GPP TS 24.229:
NOTE 7: If the UE supports the P-Early-Media header field and if the most
recently received P-Early-Media header field within the dialog includes a
parameter applicable to media stream with value "inactive", then based on
local configuration, the UE will provide an indication that the invited user
is being alerted and stop presenting received early media to the user if
requested by any previous receipt of P-Early-Media header field within the
dialog.
To sum up, this issue is caused by the fact that the MMTel AS processes the
180 message incorrectly.
Condition The "call forwarding + CRBT" scenario occurs.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
ATS9900 V100R006C10SPC200
Solution
Workarounds:
N/A
Preventive measures:
ATS SPH215 has been developed to resolve this issue. Specifically, P3302 is used to resolve
this issue.
Subsequent patches will be developed to resolve all the issues related to the "call forwarding
+ CRBT" scenario.
To resolve the issue that occurs when B is in the CS domain, use P2311 and P3302.
To resolve the issue that occurs when B is in the IMS domain, use P2311.
The following is the description of P2311:
P2311 is used for function control.
P2311 is used to determine whether the ATS includes the P-Early-Media header field whose
PEM indicator is inactive in an outgoing 180 message in the following scenarios:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 222


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

 The called terminal is in the LTE network, and the 180 message sent by the called
terminal does not carry any SDP information or the P-Early-Media header field.
 In non-forking scenarios, the ATS that serves the One Number or Virtual PBX subscriber
sends a 180 message to the calling party.
P2311 applies only in FMC networks.
Default value: 0
= 0: The ATS does not include the P-Early-Media header field whose PEM indicator is
inactive in an outgoing 180 message.
= 1: The ATS includes the P-Early-Media header field whose PEM indicator is inactive in an
outgoing 180 message.

2.13.9 CRBT Service Fails When the Time Between the UPDATE
Message and 200 (to UPDATE) Message Is Too Short
Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: Huang Jianguo (ID: 00135928)
Defect Details

Symptom The CRBT service fails when the time between the UPDATE message and
200 (to UPDATE) message is too short.
Trouble N/A
Ticket
Number
Root Cause 1. First trace messages on the MMTel AS for the forwarding party.
2. Check whether an UPDATE message has been retransmitted many
times.

3. Find the time when the UPDATE message was first received and check
whether a 200 message has been received in the same direction at the
same time. It is found that a 200 message has been received in the same
direction at the same time and the 200 message has been transparently
transmitted but the UPDATE has not.
This is because a large number of UPDATE messages are generated in the
precondition flow when the CRBT service platform is involved.
Condition The "call forwarding + CRBT" scenario occurs.
Probability This issue occasionally occurs.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 223


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
ATS9900 V100R006C10SPC200
Solution
Workarounds:
N/A
Preventive measures:
A patch will be developed by the end of November 2015 to resolve this issue.

2.13.10 DNS Query Fails When the SRV Record for a Host Name
on the DNS Exceeds 512 Bytes and DNS Links Configured on the
CSCF Work in UDP Mode
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting Engineer: Huang Jianguo (ID: 00135928)
Defect Details

Symptom When mobile subscribers in City Chongqing are roaming in City Ningxia,
DNS query fails. Specifically, after the SRV returns a query result, the
ENUM returns NULL.

Trouble 5296561
Ticket
Number
Root Cause Check external messages. It is found that there are SRV records but these
records carry the TC parameter.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 224


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

When the bit for the TC parameter in the response to a query request is set
to 1, only the first 512 bytes are returned if the response exceeds 512 bytes.
When the CSCF receives the TC parameter, it finds that the returned result
is incomplete. Then, the CSCFR uses the TCP mode to perform DNS
query. However, it finds that there are no TCP links because the transport
protocol type configured on the SDNSL is UDP. For details, see the
following debug logs:
ERR [a/source/Sig/ENUM/src/enumproc.c FileID(707) : 3216
<EnumStackLogprint>] RM: [eENUM_LOG_ERROR][Module 112]
[EnumQm_HandleResponseMsg:3512]:
EnumCm_TrTcpSelect()/EnumCm_TcpLinkPriSelect()failed when
received truncated response, return 0x10A04327! M0112P191F01S03M
2015-10-26 17:44:50 ERR [a/source/Sig/ENUM/src/enumproc.c
Therefore, you can infer that this issue is caused by the fact that the SRV
record for a host name on the DNS exceeds 512 bytes and DNS links
configured on the CSCF work in UDP mode. That is, the DNS query result
that exceeds 512 bytes is not supported.
Condition  The DNS query result exceeds 512 bytes.
 DNS links configured on the CSCF work in UDP mode.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Involved Version
CSCF V100R010C10SPC200
Solution

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 225


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Workarounds: N/A
Preventive measures:
Method 1: Change the link transmission mode configured on the SDNSL from UDP to TCP.
Method 2: Compress the SRV record for a host name.

2.13.11 Calling Terminal Displays the Call Failure When a Call


from an iPhone Subscriber in the CS Domain to a VoLTE
Subscriber (IN Service Subscriber) Is Normally Released by the
VoLTE Subscriber
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer: Su Wei (ID: 00266878
Defect Details

Symptom The calling terminal displays the call failure when a call from an iPhone
subscriber in the CS domain to a VoLTE subscriber (IN service subscriber)
is normally released by the VoLTE subscriber. The following is a snapshot
of the call failure displayed on the calling terminal:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 226


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Trouble N/A
Ticket
Number
Root Cause Analyze the traced messages.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 227


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The analysis is as follows:


1. When the called terminal releases the call, it sends a BYE message that
does not carry the Reason header field.
2. When the SCP AS receives the BYE message, it includes the Reason
header field in the BYTE message. The Reason header field carries the SIP
cause value 487 and Q.850 cause value 16.
3. When the MGCF receives the BYE message that carries the Reason
header field, it preferentially converts the topmost SIP cause value 487 to
the corresponding BICC cause value 127 (Interworking, unspecified).
4. When the UE receives the cause value 127, it determines that the call
release is an abnormal one (16 normal clear) and therefore displays the
call failure.
Condition The iPhone subscriber in the CS domain calls a VoLTE subscriber (IN
service subscriber).
Probability The problem occurs when the preceding condition is met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C20
Solution
Workarounds:
Configure data on the MGCF to convert the SIP cause value 487 to the cause value 159
(normal unspecified).
ADD CVTSIPCAU: ON="officename", SRCCAU=SC487, DESCAU=CV159;
Preventive measures:
A patch will be developed to resolve this issue.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 228


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.13.12 When a Subscriber in the CS Domain Calls a VoLTE


Subscriber (CRBT Subscriber), the 491 Message Is Generated
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer: Su Wei (ID: 00266878
Defect Details

Symptom B is a VoLTE subscriber who has subscribed to the CRBT service. When A
in the CS domain calls B, the 491 message is generated in the signaling
message flow. However, the call can be connected.
Trouble N/A
Ticket
Number
Root Cause The 491 message is described in the relevant protocol as follows:
21.4.27 491 Request Pending
The request was received by a UAS that had a pending request within
the same dialog.
The 491 message occurs in the following scenarios:
Scenario 1:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 229


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

When the MGCF receives an UPDATE message from the CRBT platform,
it returns a 200 message. At the same time, the MGCF sends an UPDATE
message.
The MGCF sends the 200 and UPDATE messages at the same time. That
is, the MGCF sends the UPDATE message immediately after sending the
200 message.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 230


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

As SIP over UDP is used, the message sequence is as follows:


1. 200
2. UPDATE
Due to the transmission path, the sequence of the messages that reach the
S-CSCF may be as follows:
1. UPDATE
2. 200
When the S-CSCF that is waiting for the 200 message receives the
UPDATE message, it sends a 491 message notifying the peer end that
message collision occurs.
Scenario 2:

An error occurs on the CAT AS.


Specifically, the UPDATE message highlighted in blue is not required in

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 231


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

the CRBT service scenario. The reason why the UPDATE message is sent
is as follows:
A in the CS network calls B in the VoLTE network and the call is
forwarded to C for some reason (for example, when B does not reply or is
busy). If there is no UPDATE message for connecting the call to C, the
precondition flow for C cannot be implemented, causing a failure in
connecting the call.
The corresponding message flow is as follows:

Condition A subscriber in the CS domain calls a VoLTE subscriber who has


subscribed to the CRBT service.
Probability This issue may occur.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 232


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
MSOFTX3000 V200R010C20
Solution
Workarounds:
Configure the CRBT platform in such a way that the UPDATE message sent by it does not
carry a=conf.
Preventive measures:
N/A

2.13.13 One-Way Audio Occurs in Video Calls


Involved NE: SBC
Applicable Scope: global
Troubleshooting Engineer: Su Wei (ID: 00266878
Defect Details

Symptom In City Suzhou, China, when A initiates a video call to B, A can neither
view the video of B nor hear the voice of B but B can do both.
Trouble N/A
Ticket
Number
Root Cause The analysis of signaling messages shows that the call can be connected;
the analysis of media packets generated after the call is answered shows
that SBC-2 on the originating side can receive media packets from the
calling terminal and send them to SBC-1 on the terminating side. However,
SBC-2 does not receive media packets from SBC-1.
The analysis of messages traced on SBC-1 shows that SBC-1 can receive
packets from SBC-2 and send them to the called terminal. SBC-1 can also
receive media packets from the called terminal and send them to SBC-2.
The message flow on the media plane is as follows:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 233


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Ping the peer IP address from SBC-1. It is found that the bearer channel
fails.
+++SE2900/*MEID:5*/2015-10-14 19:26:48+08:00
O&M#162
%%PING: SRN=0, SN=1, IPTYPE=IPV4, DIPV4="10.189.109.150",
SIPV4="10.189.103.137", VRFFLAG=Y,
VRFNAME="ChinaMobile_IMS_Media", DATATYPE=DYNAMICLEN;
%%
RETCODE = 0 Operation succeeded
The result is as follows
------------
Sent packets = 5
Received packets = 0
Packet loss ratio(%) = 100
Maximum round time(ms) = NULL
Minimum round time(ms) = NULL
Average round time(ms) = NULL
(Number of results = 1)
---END
It is found that the bearer plane IP address configuration on SBC-1 is
incorrect. That is, the peer IP address is incorrectly set to a signaling plane
IP address, resulting in the IP interworking failure. This issue is resolved
after the bearer plane IP address configuration is corrected.
Condition The bearer plane IP address configuration the SBC is incorrect.
Probability This issue may occur.
of
Occurrence

Involved Version

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 234


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

All versions of the SE2900


Solution
Workarounds:
N/A
Preventive measures:
Correct the bearer plane IP address configuration on the SBC.

2.13.14 Two Announcements Play When Subscribers Attached to


Ericsson VMSC Server Call VoLTE Subscribers Who Are Busy
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer: Su Wei (ID: 00266878
Defect Details

Symptom When a CS subscriber attached to Ericsson VMSC server calls a VoLTE


subscriber who is busy, the busy tone plays. However, after the busy tone
finishes playing, the CS subscriber hears an announcement stating that the
subscriber you have dialed cannot be connected for the moment.
Trouble N/A
Ticket
Number
Root Cause Perform the message flow analysis.
1. In the normal message flow, when the IMS returns the SIP cause value
487, the MGCF converts the cause value to 31 and then sends an REL
message carrying the cause value 31.

2. In the abnormal message flow, when the IMS returns the SIP cause value
487, the MGCF converts the cause value to 127 and then sends an REL
message carrying the cause value 127.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 235


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

You can doubt that the VMSC server plays an announcement for the cause
value 127. Perform a test on Ericsson VMSC server Huawei VMSC server.
Compare the test results and it is found that this doubt can be confirmed.
Then comes the next question: What is the cause value conversion
mechanism of the MGCF? The cause value conversion mechanism of the
MGCF is as follows:
First, the MGCF parses the Reason header filed in the SIP message.
The Reason header field can contain multiple cause values, which are
classified into SIP and Q.850 causes values. SIP and Q.850 cause values
are separated by coma (,).
The MGCF preferentially obtains the first cause value.
If the first cause value is a Q.850 value greater than 127, the MGCF
discards it and obtains the next one.
If the first cause value is a SIP cause value, the MGCF converts the cause
value to another value using the configured mapping between SIP status
codes and cause values. Alternatively, when the SIPSL sends an REL
message to the CCB, it queries the data configured by running ADD
CVTSIPCAU to perform this conversion.
In the normal message flow, the Reason header field is as follows:
Reason: Q.850;cause=31;text="normal",SIP;cause=487
In the abnormal message flow, the Reason header field is as follows:
Reason: SIP;cause=487,Q.850;cause=31

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 236


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

According to the Reason header field value selection mechanism, the


MGCF selects 31 in the normal message flow and 487 in the abnormal
message flow.
Perform further analysis for the abnormal message flow. It is found that the
called party is an IN service subscriber and an MT IN service is triggered.
When the MT IN service is triggered, the ATS generates a 487 message but
the SCP AS modifies the Reason header field of the message.
This issue is caused by this modification. The following figure shows that
the 487 message sent to the SCP AS carries the correct the Reason header
field:

However, the SCP AS changes the Reason header field in the 487 message.

This issue is caused by the fact that the SCP AS changes the sequence of
cause values in the Reason header field. This issue will be resolved in

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 237


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

subsequent versions.
Condition A subscriber attached to Ericsson VMSC server calls a VoLTE subscriber
who is busy.
Probability The problem occurs when the preceding condition is met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C20
Solution
Workarounds:
Configure data on the MGCF to convert the SIP cause value 487 to the cause value 159
(normal unspecified).
ADD CVTSIPCAU: ON="officename", SRCCAU=SC487, DESCAU=CV159;
Preventive measures:
A patch will be developed to resolve this issue.

2.13.15 When Huawei IMS Interworks with Bell SBC, the TAS
Cannot Obtain the sbc-domain Field from the P-Access-Network-
Info Header Field
Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: zhang Minchao (ID: 00290970)
Defect Details

Symptom An interoperability test is performed between Huawei IMS and Bell SBC.
The details are as follows: A is a VoLTE subscriber whose area code is
0772. When A is roaming in the 4G network in another location (with the
area code 0771) in the same province and initiates a call to a PSTN number
in the home location without dialing the area code, the system plays an
announcement stating that the number you have dialed is invalid.
Trouble N/A
Ticket
Number
Root Cause The traced messages show that the TAS incorrectly performs number
normalization. That is, it normalizes the PSTN number to a global number
prefixed with 86772. The internal logs show that the TAS fails to obtain the
sbc-domain field from the P-Access-Network-Info header field. This is
because the ATS cannot recognize the sub-domain sent by Bell SBC that is
not enclosed with quotation marks.
The sbc-domain, ue-ip, and ue-port in the P-Access-Network-Info header

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 238


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

field sent by Bell SBC are not enclosed with quotation marks.
A software parameter is used to determine whether the sbc-domain, ue-ip,
and ue-port in the P-Access-Network-Info header field sent by the SE2900
are enclosed with quotation marks.

The ATS supports only the following P-Access-Network-Info header field:


P-Access-Network-Info:3GPP-E-UTRAN-FDD;utran-cell-id-
3gpp=4600800154601;"sbc-
domain=sbc1.010.bj.chinamobile.com";network-provided
That is, the ATS can process only "sbc-
domain=sbc1.010.bj.chinamobile.com".
Condition The sub-domain is not enclosed with quotation marks.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
All versions of the ATS
Solution
Workarounds:
N/A
Preventive measures:
A patch will be developed to resolve this issue.

2.13.16 ATS Sends PUR Messages to Obtain Transparent Data


from the HSS for Unregistered Subscribers
Involved NE: ATS
Applicable Scope: global
Troubleshooting Engineer: Wu Dai (ID: 00146329)
Defect Details

Symptom When the ATS sends a PUR message to obtain transparent data from the

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 239


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

HSS for the unregistered subscriber during a call, the call fails.
Trouble N/A
Ticket
Number
Root Cause When the CSCF routes a call from a VoLTE subscriber to the TAS, the TAS
returns "query adb failed". When you run LST MSR, the system displays
that the VoLTE subscriber does not exist (subscriber data sent through the
UDA message is incomplete). When you run ADD MSR, the system
displays that the VoLTE subscriber exists (The HSS returns the error code
5105 to the PUR message).
1. When the subscriber initiates a registration before being defined on the
ATS, the MMTel AS cannot obtain subscriber data, causing the registration
to fail. However, as the SCC AS does not need to obtain subscriber data,
the registration is successful.
2. When the subscriber is defined on the TAS, the MMTel AS sends a PUR
message to push TAS-UPDATE-DATA with SequenceNumber set to 0.
However, as the SCC AS has pushed TAS-UPDATE-DATA during the
subscriber registration, SequenceNumber must be set to 1.
Condition A subscriber has registered with the ATS before being defined on the ATS.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
ATS9900 V100R006C10
Solution
Workarounds:
Delete transparent data from the HSS.
Preventive measures:
ATS SPH218 has been developed to resolve this issue.

2.13.17 Initial Registrations from VoLTE Subscribers Fail


Involved NE: CSCF
Applicable Scope: global
Troubleshooting Engineer: Wu Dai (ID: 00146329)
Defect Details

Symptom On the live VoBB network, nationwide VoLTE capabilities have been added
on the I-CSCF. Consequently, when a VoBB subscriber from a province
registers, the S-CSCF for another province is selected.
Trouble N/A

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 240


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Ticket
Number
Root Cause When a VoBB subscriber is defined at a site, the I-CSCF randomly selects
one of S-CSCFs with the same priority based on ISCAP data if it has not
been configured with nationwide S-CSCF capabilities. However, if
nationwide VoLTE capabilities have been configured with the same priority
as the S-CSCF for the subscriber's province, the I-CSCF will select one S-
CSCF outside the subscriber's province when the subscriber sends an initial
registration. Consequently, the initial registration fails.
Condition Nationwide VoLTE capabilities have been configured on the I-CSCF.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
CSC3300 V100R010C10
Solution
Workarounds:
N/A
Preventive measures:
1. On the HSS Management page of the SPG2800 web portal, run LST HMOCAP to check
whether national VoLTE capabilities have been configured for some sample VoBB
subscribers.
2. If national VoLTE capabilities have not been configured for VoBB subscribers, do not
configure national VoLTE capabilities on the I-CSCF on the VoBB network or lower the
priorities of newly added S-CSCF capabilities.
3. Add VoLTE capabilities after VoBB sites are enhanced to support S-CSCF capability-based
subscriber definition.

2.13.18 Codec Sequence Is Incorrect for SBC Calls and eSRVCC


Handovers
Involved NE: SBC
Applicable Scope: global
Troubleshooting Engineers: Liang Chenjie (ID: 00138148)
Defect Details

Symptom The codec sequence is incorrect for SBC calls and eSRVCC handovers.
Trouble N/A
Ticket
Number

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 241


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Root Cause When a VoLTE subscriber calls a VoBB subscriber, the call path is IMS-
UGC-UMG-PRA. The codecs carried by an incoming SIP message do not
overlap with the codecs (including G.729, G.711, and AMR2) configured
by running ADD MGW. The UGC obtains the first eight codecs from the
received codecs. The common call failure scenario is as follows: The SBC
carries more than eight codecs to the MGCF, and the first eight codecs do
not contain G.711 or AMR2. As the UGC and MGCF support a maximum
of eight codecs and AMR2 and G.711 are generally configured on them, the
codecs carried by the UGC or MGCF do not overlap with those carried by
the SBC.
Condition The SBC carries more than eight codecs to the MGCF, and the first eight
codecs do not contain G.711 and AMR2.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
SE2900 V300R001C20
Solution
Workarounds:
N/A
Preventive measures:
The SBC uses the TC function to adjust the sequence of the codecs carried by it. That is, the
SBC places G711 and AMR2 12.2K in the front.
1. Delete the duplicate AMR WB and NB codecs.
2. When the VoLTE subscriber resides in the EMSC server after a handover, the SBC sends
AMR2 to the EMSC server as the first codec.
a. Run the following command to add a bearer control policy data record:
ADD
BCPLC:BCPLCNAME="AMR_SORT",QOSSAMPLERATE=50,SINGLEWAYCHK=N,EN
TYPE=ABCF,LPCHECKP1=CHECKMEDIATYPE-0&CHECKBANDWIDTH-
0&CHECKCODE-0&CODESORT-0&AMRSORT-0,
LPCHECKP2=CHECKMEDIATYPE-0&CHECKBANDWIDTH-0&CHECKCODE-
0&CODESORT-0&AMRSORT-0,LPCHECKP3=CHECKMEDIATYPE-
0&CHECKBANDWIDTH-0&CHECKCODE-0&CODESORT-1&AMRSORT-0,
LPCHECKP4=CHECKMEDIATYPE-0&CHECKBANDWIDTH-0&CHECKCODE-
0&CODESORT-0&AMRSORT-0,FBDMT=AUDIO-0&VIDEO-0&APPLICATION-
0&DATA-0&CONTROL-0&IMAGE-0&MESSAGE-0&TEXT-0&OTHER-0,
MCFPL=REJECT_WITH_488RSP,MEDIADETECT=Y,TMLINE=Y,NBWCTL=N,VIDEOB
WREDRATE=0,MODIFYPATH=Y,SYNTCPLINK=N,RFC2198ENABLE=N,MBM=DISAB
LE,PORTOBTAINMODE=M_line,PTTRANS=N,MEDIASMOOTH=N,

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 242


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

HOLDRTCPMODE=Y,ANS=OTHER,RR=2000,RS=600,CHKCNPPORT=N,CONVIDEO=
N;
b. Add the codec sequencing function to place AMR in the first position.
Note: After an eSRVCC handover, AMR2 must be located before all the other codecs sent by
the SBC to the eMSC server. The SBC originally placed AMRWB in the first position, and the
eMSC server supports only AMR2 12.5k. Therefore, to resolve this issue, the SBC needs to
place ARM2 in the first position.
ADD
CODECINF:CINAME="AMR",ENTYPE=ABCF,BCPLCNAME="AMR_SORT",DMT=BO
TH,MEDT=AUDIO,CODN="AMR",CLOCR=8000,CN=ANY,ALLOW=Y,PRIO=0;
c. Modify the SIP AN data record for the ATCF. That is, change the value of BCPLCNAME
to the newly added BCPLC.
MOD SIPAN: ANNAME="ATCF_SIPAN", LETYPE=ATCF,
BCPLCNAME="AMR_SORT";

2.14 Fault Cases for September 2015


2.14.1 When the eMSC Sends an INVITE Message to the I-CSCF,
the IMS Side Returns a 403 Message, Causing the Call to Fail
Involved NE: MSOFTX3000
Applicable Scope: global
Troubleshooting Engineer: Zhang Zhao (ID: 00302145)
Defect Details

Symptom During a call from a CS subscriber on the CS network to a VoLTE


subscriber on the VoLTE network, after the eMSC receives the IMRN
anchoring prefix from the ATS, it fails to send an INVITE message to the I-
CSCF. Consequently, the call fails.
Trouble N/A
Ticket
Number
Root Cause According to the VoLTE signaling manual, the V/GMSC server sends an
initial detection point (IDP) message to the anchor AS to trigger the T-CSI
services for obtaining the IMRN. The anchor AS sends a Connect message
that carries the IMRN to the V/GMSC Server. The V/GMSC server
analyzes the IMRN to obtain the MGCF address and routes the call request
to the MGCF. The MGCF analyzes the IMRN to obtain the I-CSCF address
and routes the call request to the I-CSCF. When the eMSC (incorporating
the functions of the VMSC, MGCF, and eSRVCC-IWF) receives the IMRN
prefix 123 from the ATS and sends an INVITE message to the I-CSCF, the
I-CSCF returns a 403 (server internal error) message to the eMSC. The
message tracing result shows that the value formats of some header fields
in the INVITE message sent by the MGCF are incorrect. That is, before the
MGCF sends an INVITE message, it must remove the MT anchoring prefix

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 243


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

to restore the called number and then normalize the called number to a
global number. Only in this way can the I-CSCF recognize the called
number and anchor the call to the IMS domain.

Condition A CS subscriber on the CS network calls a VoLTE subscriber on the VoLTE


network.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
MSOFTX3000 V200R010C20SPC100
Solution
Workarounds:
N/A
Preventive measures:
Run the following command to add an outgoing number processing data record to delete the
IMRN prefix:
ADD OUTNUMPREPRO: CSCNAME="all", TGN="SIP-TO-I-CSCF", P=0, PFX=K'123,
CIDN="INVALID", ODIDN="INVALID", CLRFT=UNKNOW, CDN="DEFAULT",
CLDFT=UNKNOW, DDN="DELETE_123", ORICLDFT=UPFXIN, RDFT=UNKNOW,
RDDN="DEFAULT", GENFT=UNKNOW, GENNCN="DEFAULT", FCCLI=NO;

2.14.2 After the IMS Core Completes Initial Registration, the 401
Message Returned by the IMS Core Cannot Be Routed to the UE
Through the SBC Side
Involved NE: SE2900
Applicable Scope: global
Troubleshooting Engineer: Zhang Chao (ID: 00302145)
Defect Details

Symptom After the IMS Core completes initial registration, it returns a 401

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 244


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

(unauthorized) message but the message cannot be routed by the SBC side
to the UE. Consequently, the UE fails to register.
Trouble 4748325
Ticket
Number
Root Cause As the REGISTER messages sent before and after a 401 message are the
same, you can infer that the UE has not received the 401 message. The
REGISTER message sent by the UE after the IMS Core returns a 401
message does not contain the RES that is calculated based on the shared
secret key and RAND.
Typically, the time from when the SBC sends a 401 message to the UE
until the UE sends a REGISTER message again should be in milliseconds.
In this example, the UE sends a REGISTER message again after 16
seconds. This obviously shows that the UE has not received a 401 message
from the SBC.

Therefore, check test messages on the EPC side to see whether a 401
message has been sent to the UE. In addition, check the messages traced on
the LAN switch on the SBC side to see whether the SBC has sent a 401
message.
Condition Route data on the LAN switch is incorrect.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
SE2900 V300R001C20
Solution
Workarounds:
N/A
Preventive measures:
On the LAN switch and backbone network, configure route data about backhaul IP addresses
for the UE address pool.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 245


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

2.14.3 As the INVITE Message Sent by the UE of a Registered


VoLTE Subscriber Fails to Traverse the P-GW, the Call Fails
Involved NE: UGW
Applicable Scope: global
Troubleshooting Engineer: Zhang Chao (ID: 00302145)
Defect Details

Symptom After the INVITE message sent by the UE of a registered VoLTE


subscriber fails to traverse the P-GW, the call fails.
Trouble N/A
Ticket
Number
Root Cause First check whether the UE fails to send a call request. Connect the UE to a
PC and simulate the UE to initiate multiple calls. Check the messages
traced on the UE. It is found that the INVITE message sent by the UE is
correct.
Then check whether the INVITE message sent by the UE is possibly lost
when traversing the P-GW. Analyze this possibility by checking the
messages traced on the P-GW. Lines 140-144 in the UGW message tracing
result show that the UGW has not forwarded messages to the P-CSCF on
the core side. In addition, this error is not logged on the EMS.

Perform mirroring on the access-side IP address port of the SBC and trace
messages on the SBC. It is found that the SBC has not received INVITE
message. Therefore, you can infer that the INVITE message is lost when
traversing the P-GW.
It is found from other failure cases that when the UGW IP message that
exceeds the 1500 bytes is lost, check whether the FPIC supports message
fragmentation. It is found that the UGW does not support message
fragmentation.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 246


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

The following information shows that message fragmentation is supported:

Further analyze the traced messages. It is found that some unfragmented


messages have been forwarded and some fragmented messages have not
been forwarded. In addition, fragmented messages from other carriers have
been forwarded. Therefore, check data on the live network and it is found
that the following configuration applies:
apn ims
apn-softpara-byte 3 1
The software parameter APN_BYTE3 is described as follows:
APN_BYTE3 is used to enable or disable forwarding-plane functions for a
specific APN instance.
Bit 1:
This bit is used to determine whether the UGW9811 performs IP
fragmentation and reassembly for a specific APN instance.
 = 0: The UGW9811 performs IP fragmentation and reassembly for a
specific APN instance.
 = 1: The UGW9811 does not perform IP fragmentation and reassembly
for a specific APN instance.
After APN_BYTE3 bit 1 is set to 0, perform the same test again. It is found
that the SBC side can receive the INVITE message, the VoLTE call is
successful, and the traced signaling and media messages are correct.
Condition An alarm about IP fragmentation resource insufficiency is generated.
Probability This issue may occur.
of
Occurrence

Involved Version
UGW V900R011C00
Solution

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 247


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Workarounds:
Use the software parameter apn-softpara-byte to disable IP fragmentation and reassembly for
some APNs.
Preventive measures:
N/A

2.14.4 E-CSCF Function Embedded in the SE2900 Is Required for


IMS Emergency Calls
Involved NE: SE2900
Applicable Scope: global
Troubleshooting Engineer: Zhang Zhao (ID: 00302145)
Defect Details

Symptom In the current VoLTE solution, CSFB-based emergency calls are preferred.
However, after the VoWiFi introduction, the network side needs to support
IMS emergency calls made by iPhones in flight mode. The VoLTE/VoWiFi
prefers the E-CSCF/EATF function embedded in the SE2900. The
ECSCF/EATF function is license-controlled.
Note:
1. The way Samsung S6 phones accessing IMS over Wi-Fi initiate
emergency calls is different from the way iPhones initiate such calls. That
is, when Samsung S6 phones initiate such calls, the flight mode is
automatically disabled and the calls fall back to the CS network for being
connected.
2. Carriers can assign an emergency call APN or reuse the IMS APN.
3. The SBC can be configured to return a 380 message after identifying
emergency call numbers. The 380 message is used to instruct the mobile
phone to fall back to the CS network for connecting emergency calls.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 248


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Notes: If mobile phones in flight mode access IMS over Wi-Fi to initiate
emergency calls, the IMS emergency call solution is used. In other cases,
the CSFB solution is used regardless of the emergency call handover flow.
The PSAP is located in the CS domain. The E-CSCF first routes the
emergency call number to the MGCF and then the MGCF contacts the
PSAP. CDRs are generated for emergency calls when the E-CSCF
interworks with the CCF.
Trouble N/A
Ticket
Number
Root Cause Emergency call data is incomplete.
Condition  The call is an emergency call.
 Emergency call data is incomplete.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 249


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Involved Version
All versions of the SE2900
Solution
Workarounds:
N/A
Preventive measures:
Perform the following operations on the SBC:
1. Configure general emergency call data to enable the SBC to identify emergency calls.
ADD GEMC: ENTYPE=ABCF, ANN="ALL", ADDRT=URNSERVICE,
URN="urn:service:sos", QOSPRI=QP7;
ADD GEMC: ENTYPE=ABCF, ANN="ALL", ADDRT=TELNUM, EMCNUM="112",
QOSPRI=QP7;
Note: The URN varies depending on the corresponding value carried by the mobile phone.
Emergency call numbers also vary from country to country.
2. Configure PSAP data.
ADD EEMCC: ADDRT=URNSERVICE, URN="urn:service:sos", LIF=INVALID,
EMCCAT=TELNUM, EMCCNUM="tel:##0112";
Note: The preceding data is about routing the emergency call numbers to the MGCF. The data
must be negotiated with the MGCF.
3. Add the local E-CSCF entity.
ADD ECSCF: ECSCFLEN="ECSCFTWA1H", LRFR=Y, PTYPE=DIAMETER;
4. Configure data for the P-CSCF to contact the E-CSCF.
Configure data about the embedded DNS:
ADD DNSSRV: DOMAINNAME="_sip._udp.ecscf.ims.mncxxx.mccxxx.3gppnetwork.org",
PORT=5060, TARGET="ecscf.ims.mncxxx.mccxxx.3gppnetwork.org ";
ADD DNSRESA: NAME="ecscf.ims.mncxxx.mccxxx.3gppnetwork.org", IPTYPE=IPV4,
ADDR="xxx.xxx.xxx.xxx";
Configure dynamic route data for the P-CSCF to contact the E-CSCF:
ADD ART: RTNAME="PCSCF_ECSCF_ART", SOPLY=AUTO, SBPLY=MANUAL,
RTTYPE=DYNAMIC, DOMAIN="ecscf.ims.mncxxx.mccxxx.3gppnetwork.org ",
ISMPORT=N, LINKINFO=UDP, ADDRGN="CORE_SIG_ACNADDRG",
MEDDN="CORE_MEDIA_MEDDN", CHB=CTHB,
CHBLADDRNAME="TO_CORE_SIG", CHBLPORT=5060;
Configure an emergency call route for the P-CSCF SIP AN:
MOD SIPAN: ANNAME="xxx", LETYPE=P-CSCF, ERTNAME="PCSCF_ECSCF_ART";
5. Configure data for the E-CSCF to contact the MGCF.
Configure the SIP TG, OFC, and ART:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 250


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

ADD ASIPTG: TGNAME="ECSCF-MGCF", LINKINFO=UDP, IPTYPE=IPV4,


PIPV4="xxx", VRFFLAG=N, CHB=CTHB, CHBLADDRNAME="ECSCF_Core",
BCPLCNAME="DEFAULTABCFBCPLC";
ADD AOFC: OFCNAME=" ECSCF-MGCF", TG1NAME=" ECSCF-MGCF ";
ADD ART: RTNAME="ECSCF_MGCF_ART", RTTYPE=STATIC, ISMPORT=N,
ADDRGN="ECSCF_ACNADDRG", MEDDN="CORE_MEDIA_MEDDN",
OFC1NAME=" ECSCF-MGCF";
Configure E-CSCF SIP AN data:
ADD SIPAN: ANNAME="access_ecscf_mgcf", LETYPE=E-CSCF,
ADDRNAME="ECSCF_Access", IPTYPE=IPV4, UEIP="xxx", UEMASK="xxx",
LAPT=5060, LCPT=5060, RTNAME="ECSCF_MGCF_ART", ECSCFLEN="ECSCF",
CMDENABLE=Y;
Note: Set UEIP to the P-CSCF core-side address segment.
6. If the E-CSCF needs to generate emergency call CDRs, configure data for the SBC to
interwork with the CCF.
MOD RFPLC: ENTITYPE=ECSCF, NFUN=ECSCF, ECCH=Y, CANCH=N,
EMCCOFCH=N, EMCCFCH=N, RUCH=N, START=Y;

2.14.5 During Subscriber Registration, the CSCF Returns a 500


Message After Receiving an SAA Message
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting Engineer: Xu Junqi (ID: 00302795)
Defect Details

Symptom The CSCF returns a 500 message carrying the cause value "Query data
error" after receiving an SAA message.

The networking is as follows:


UE (Huawei Ascend P1) -> PCSCF (HW) -> I/SCSCF (HW) -> IMS HSS
(HP)
Trouble N/A
Ticket
Number
Root Cause The charging address AVP in the SAA message returned by the HP HSS is
incorrect. The value of the AVP must be aaa//ccf.huawei.com. As shown in
the following figure, the CSCF returns a 500 message because
dummycharging1 is carried:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 251


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

[Protocol Reference]
The following descriptions in the 3GPP TS 29.229 are for your reference:
1.3.20 Primary-Event-Charging-Function-Name AVP
The Primary-Event-Charging-Function-Name AVP is of type DiameterURI.
This AVP contains the address of the Primary Online Charging Function.
The receiving network element shall extract the FQDN of the DiameterURI
in this AVP and may use it as content of the Destination-Host AVP for the
Diameter accounting requests. The parent domain of the FQDN in the
DiameterURI shall be used as Destination-Realm. The number of labels
used for the Destination-Realm shall be determined before the Charging
Information is provisioned and may be a configuration option.

In RFC3588, the DiameterURI format requirements are as follows:


DiameterURI The DiameterURI MUST follow the Uniform Resource
Identifiers (URI)syntax [URI] rules specified below:"aaa://" FQDN [ port ]
[ transport ] [ protocol ]; No transport security"aaas://" FQDN [ port ]
[ transport ] [ protocol ]; Transport security used FQDN = Fully Qualified
Host Name port = ":" 1*DIGIT; One of the ports used to listen for;
incoming connections.; If absent,; the default Diameter port (3868) is;
assumed.transport = ";transport=" transport-protocol; One of the transports
used to listen; for incoming connections. If absent,; the default SCTP
[SCTP] protocol is; assumed. UDP MUST NOT be used when; the aaa-
protocol field is set to; diameter.transport-protocol = ( "tcp" / "sctp" / "udp"
)protocol = ";protocol=" aaa-protocol; If absent, the default AAA protocol;
is diameter.aaa-protocol = ( "diameter" / "radius" / "tacacs+" )The
following are examples of valid Diameter host
identities:aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radius

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 252


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

Condition The charging address AVP does not comply with the protocol.
Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
CSCF V100R010C00SPC100
Solution
Workarounds:
N/A
Preventive measures:
Ask HP engineers to correct the charging address in the SAA message returned by the IMS
HSS.

2.14.6 During Service Provisioning, the PUA Message Carries


"diameter-error-user-data-not-recognized"
Involved NE: ATS9900
Applicable Scope: global
Troubleshooting Engineer: Yang Jianqun (ID: 00267249)
Defect Details

Symptom The PUA message carries "diameter-error-user-data-not-recognized".

Trouble N/A
Ticket
Number
Root Cause As stipulated in the protocol of the new version, dataReference in AVP
703 of the PUR message must be set to 0. However, Huawei ATS is
compatible with the old version where dataReference is set to the default
value 20 (as shown in the following figure). There is no error reported for
interworking with Huawei HSS. To interwork with the HSS of another
vendor, adaptation needs to be made based on the compatibilities of the
peer end.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 253


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

[Protocol Reference]
Relevant contents in 3GPP TS 29.328 C30 are as follows:

Condition The compatibilities of the HSS are insufficient.


Probability This issue will occur when the preceding condition is met.
of
Occurrence

Involved Version
ATS9900 V100R006C00SPC100
Solution
Workarounds:
N/A
Preventive measures:

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 254


Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Fault CasesFault Cases

In the MML Command - ATS window of the OMU client, run the MOD SPCFG:
ALREPDATA=FALSE; command.
After this configuration, the value of dataReference in the PUR message is changed from 20
to 0.
Alias repository data download flag determines whether the Data-Reference AVP in a
request message can be set to 20(AliasesRepositoryData) when repository data needs to be
downloaded for subscribers in an alias set. 20(AliasesRepositoryData) indicates that alias
repository data needs to be downloaded from the HSS.
Value:
FALSE: The Data-Reference AVP is set to 0(RepositoryData).
TRUE: The Data-Reference AVP is set to 20(AliasesRepositoryData).

2.14.7 During Third-Party Registration, the SNA Message Carries


"diameter-error-user-data-cannot-be-notified"
Involved NE: CSC3300
Applicable Scope: global
Troubleshooting Engineer: Yue Peng (ID: 00148445)
Defect Details

Symptom After HP HSS receives an SNR message, it returns an SNA message that
carries "Diameter-error-user-data-cannot-be-notified".

Trouble N/A
Ticket
Number
Root Cause HP HSS returns the incorrect SNA message because it does not support the
SNR message.
Condition The HSS does not support the SNR message.
Probability This issue will occur when the preceding condition is met.