|
三、后续注册---重注册
四、后续注册---二次注册
7.1 苹果6s手机初始注册失败
7.2 三星S6手机初始注册失败
用户开通了VoLTE签约，并在VoLTE终端上打开“VoLTE”、“ims服务”或“HD高清语音”开关，在开机附着成功后，UE单独发起APN=ims的PDN连接性请求，并成功建立QCI=5的ims信令默认承载，接着UE发起注册请求。
注册流程拆分成初始注册/后续注册（重注册）、后续注册（二次注册）、第三方注册、订阅共四个阶段，其中后续注册和初始注册的区别在于注册消息中增加了用户认证数据和接入网络位置信息。成功的初始注册必须经过初始注册、二次注册、第三方注册、订阅阶段，而成功的重注册必须经过重注册、二次注册、第三方注册阶段。
初始注册、重注册和二次注册过程称为基本注册，基本注册由用户终端发起，基本注册成功后，用户就拥有了基本呼叫权限。第三方注册由S-CSCF代替用户终端发起，第三方注册成功后，用户就拥有了AS提供的相关业务权限。基本注册、第三方注册示意图如下：
▲本图中1~4为初始注册，5为二次注册，6为第三方注册
更加详细的流程见下图（融合HSS组网）：
1~12步骤为初始注册，其中8~9步骤可以选择性进行（视S-CSCF本地剩余IMS认证数据情况）；
13~24步骤为二次注册，20~21步骤可以选择性进行（视S-CSCF本地有无用户数据及iFC集合数据）；
25~26为S-CSCF向AS（应用服务器）请求的第三方注册，根据iFC准则，涉及的应用服务器为SCC AS、VoLTE AS、IP-SM-GW等，该过程步骤较多，此图为示意图。
由于SIP消息与VoLTE优化分析紧密结合，在此简略介绍SIP协议：
SIP协议源自于互联网产物，并非传统的通信协议，消息采用非比特位方式的文本编码，可阅读性强，具有非常强大的灵活性和扩展性，缺点就是存在大量的兼容性问题。
SIP消息有请求和响应2种类型，每个消息包含3个元素：请求行/状态行、头域、消息体（可选）。
Content-Length头域用十进制方式表示出消息体的字节数，比如450。
由于本文为注册专题，那么UE发出的首条SIP消息为Register，若该注册消息中包含Contact头域内容，则为基本注册；若缺失Contact头域，则为UE查询注册状态，根据P-CSCF的配置情况来进行处理。
存在多种类型的消息体，比如文本格式的SDP消息体，或二进制格式的ISUP消息体等。
关于不同SIP消息代码见其它相关文档介绍，除了正常响应代码，更要了解失败响应代码。
作为VoLTE优化工程师，一定要了解上述知识点，然后在工作中进行验证性测试。日常工作中常用的方式就是采用测试手机和测试软件相结合的方式进行，比如采用HTC M8t手机和CDS测试软件，在Uu接口上的信令消息截图如下：
▲看不清请点击放大了看
初始注册事件发生的场景：
开机附着于LTE网络，并完成建立IMS默认承载之后；
从23G网络重选上（或返回）LTE网络，并完成TAU之后；
IMS注销之后，再次启用IMS功能；
在重注册失败之后再次发起的注册；
手机认为必须经过初始注册流程（不兼容401认证挑战消息或终端BUG问题导致）
作为注册消息的发起方---用户终端，UE根据USIM信息，推导得出注册用的私有身份标识IMPI和临时IMS公用身份标识IMPU（即T-IMPU，为SIP格式，仅作注册之用，不能用作呼叫）：
其中私有身份标识是归属网络运营商提供的用户唯一全球标识，类似IMSI，用于对IMS用户进行鉴权认证，该标识对用户不可见，简明初始注册示意图如下：
初始注册的过程在信令平台的抓包如下：
空口中的register消息通过逻辑上的Gm口直到P-CSCF，该过程是通过该消息中Route头域的P-CSCF地址来实现的，该地址被用来作为Request消息的路由。
关于Route头域含义如下：当一个Proxy Server收到一个Request消息时，会检查Route字段的第一个地址是否等于自己，如果是，它可以从Route字段中删去自己的地址信息，然后叠加下一段地址，并将消息转发到Route字段中指定的下个地址；如果Route字段为空，则转发到Request
URI指定的地址。如果没有就根据Contact头域发送，如果连Contact都没有，就根据From头域发送。
关于Via头域含义如下：当发起一个SIP
Request消息时，消息经过的每一跳（包含发起方）都会在SIP消息中增加一个Via字段，内容为自己的地址信息，表示通过此地址发往下一跳，为什么要增加Via字段来记录Request消息经过的地址呢？用以保存请求历经的路径，实际上这个地址信息将被作为Request消息的Response消息的路由，Response消息逐段设置Via头域地址，实现逐级返回，直到回到Request的发起方，因此Via头域是一种给响应消息返回留路径的方式，是响应消息的本路由段的目的地址。
另外Record-Route头域为某一段路由的目的地、源头传递信息（构建路由集），从而发送消息时可构建Route头域。Path头域为注册时才特有的，用于S-CSCF设置用户的P-CSCF，作为反向请求直通路由至P-CSCF网元。Contact头域为UE的IPV6地址和端口号。
UE发起初始注册时，Register消息中Authorization头域中相关认证授权信息为空（比如随机数为空、认证响应为空、无完整性保护），如下图：
增加Path头域为本P-CSCF地址（也即P-CSCF的主机名），而在I-CSCF转发Register请求给S-CSCF时同样要插入P-CSCF地址的path头域，S-CSCF通过Path字段保存一个UE所使用的P-CSCF地址，这样当S-CSCF需要主动向UE发送消息时（例如网络端发起的De-register），S-CSCF就知道实际应该发往的P-CSCF地址了，这是一种直达路由消息。
P-CSCF向I-CSCF进行进一步转发Register消息，为了获得入口I-CSCF网元IP地址，P-CSCF根据请求行中的Request-URI域名向DNS服务器发起查询，由于目前UE基本注册时的Request-URI字段统一设置为只有运营商信息而不带省份信息的域名sip:ims.mnc000.mcc460.3gppnetwork.org，鉴于P-CSCF只有DNS查询而没有被叫号码分析功能，故查询结果不能定位出是哪个省的用户，也就不能路由到归属网络的I-CSCF，结果只能为拜访网络的I-CSCF功能实体的IP地址（而在呼叫流程中，由于S-CSCF和MGCF具备被叫号码分析功能和查询ENUM/DNS功能，可得知IMS被叫用户的归属网络入口I-CSCF地址）。
作为拜访网络的I-CSCF为了判断该用户是否具备漫游的权限，根据From头域中的T-IMPU标识和拜访网络标识P-Visited-Network-ID头域，通过Cx接口向归属HSS发起USER-AUTHORIZATION-REQUEST查询消息（该消息用于注册流程，与呼叫流程中LIR不同），Diameter协议类型为注册，根据信令网架构，中间必须经过LDRA或HDRA网元，DRA基于IMSI/主机名路由至归属HSS。HSS将该UAR相关头域内容与用户开户数据中漫游模板内容进行比对，若匹配，则回复给I-CSCF网元UAA消息，包含下面内容。
register（初始注册），设置相关AVP属性值对---实验性结果代码为2001（DIAMETER_FIRST_REGISTRATION），下发S-CSCF服务器能力集（分为强制能力和可选能力），I-CSCF收到UAA消息后，根据其中的S-CSCF的能力集进行某种选择算法，选择一个合适的S-CSCF。
S-CSCF收到无认证数据的初始注册消息后，通过Cx接口发送MULTIMEDIA-AUTH-REQUEST消息给HSS，请求认证向量集，同时也指示HSS实体：本S-CSCF即为该用户归属服务器，MAR和MAA字面上为多媒体认证请求和多媒体认证回应，实为提供IMS认证向量消息，认证算法指定为Digest-AKAv1-MD5（消息摘要算法5），认证过程与EPC认证流程相类似，也是双向认证，但认证过程采用了五元组：XRES/RAND/AUTH/IK/CK，而非四元组，涉及S-CSCF、P-CSCF、UE三个实体。
在HSS的成功响应消息中属性值对---SIP-Auth-Data-Item，包含5套完整的认证数据（S-CSCF对用户认证时任选一套即可，有点类似于EPS附着时MME对用户认证，总的来说不同类型的原始认证数据均出自于HSS，而根据具体认证内容不同，涉及不同实体，关于附着认证见EPS认证和NAS解码方面文档）。
S-CSCF截留某一套的XRES后，将这套剩余认证数据包括Digest认证方式算法、随机数RAND/认证令牌AUTH（RAND/AUTH合成“nonce”）、完整性保护密钥IK、加密密钥CK打包在register401消息（即鉴权认证挑战）里并传递至I-CSCF，继而I-CSCF将401消息传递给P-CSCF：
P-CSCF截留CK/IK后，将剩余的鉴权认证元素RAND/AUTH（”Nonce”）、认证算法通过401消息传递给UE，以上IMS认证的五元组传递如下图：
关于认证过程描述见本文的二次注册章节。
三、后续注册---重注册
初始注册成功后，用户的签约网络会登记用户的注册时长T1。当用户的已注册时长接近T1时，一般为50分钟，UE需要向网络侧发起新的注册请求，即重注册。
重注册的流程与初始注册过程相似，对于UE手机和S-CSCF这两个实体来说判断重注册与初始注册的依据在于是否携带上次成功IMS认证的数据: AUTH/RAND/RES/IK/CK等，以及携带接入网络位置信息。
P-CSCF通过完整性验证和解密后，在转发注册消息之前，和初始注册时的头域处理相类似，但有所改变，其中：Authorization头域内容调整“integrity-protected=yes”标签，表示注册消息受保护；P-Access-Network-Info头域内容新增小区ID构成五项。
值得注意的是：重注册时Call-ID必须维持不变（IPV6地址也不变），之后由于现网S-CSCF设置为每次重注册都认证（重注册时，S-CSCF对用户进行鉴权认证是可选流程），那么同样会生成401认证挑战，与初始注册一样也要经历IMS认证过程。
而对于HSS实体来说，则依据数据库是否存在该用户的P-CSCF Network ID或S-CSCF名称来判断初始注册或后续注册，若不存在任一条件，则判断为初始注册，回复给I-CSCF则为S-CSCF能力集；若存在P-CSCF Network
ID则判断为后续注册，回复给I-CSCF为S-CSCF能力集；若存在S-CSCF名称则判断为后续注册，且回复给I-CSCF为S-CSCF名称。
S-CSCF依据Register消息中授权认证头域的信息为该用户的上次成功认证信息，判断本次注册为重注册。重注册若设置为需要认证时，可根据IMS认证数据（初始注册时下载了5套五元组）在S-CSCF的剩余情况来决定是否需要MAR和MAA的流程，否则可直接取用本地保存的未曾使用过的认证数据。因此对于S-CSCF和HSS来说这是一个选择性认证过程，有利于缩短时延及降低S-CSCF与HSS之间的信令负荷，最终S-CSCF发送401鉴权认证挑战消息给I-CSCF，由I-CSCF传递给P-CSCF，之后通过Gm接口下发至UE。
四、后续注册---二次注册
后续注册中的二次注册指的是UE收到S-CSCF的401鉴权认证挑战消息之后，手机发起的第二次注册过程，手机首先对网络进行认证：根据算法、随机数和USIM卡中的共享密钥，对AUTH进行验证以判断网络是否合法。
在验证通过后（XMAC与MAC一致，SQN在合理范围内），再基于共享密钥、RAND和算法计算出RES/CK/IK，并通过Gm口将digest摘要认证数据发送给P-CSCF网元：
简明二次注册示意图如下：
9-12步骤是认证成功所必须的，13步骤是为了进一步触发第三方注册。
UE发起二次注册，其中Call-ID头域标识保持不变，而From头域tag标识可变、Cseq头域可变，并将生成的RES响应值以及原始的RAND/AUTH通过加密通道发给P-CSCF，另外还携带接入网络位置信息。
P-CSCF通过完整性验证和解密后，在转发注册消息之前，和初始注册时的头域处理相类似，但有所改变，其中：Authorization头域内容调整“integrity-protected=yes”标签，表示注册消息受保护；P-Access-Network-Info头域内容新增小区ID构成五项。
后续注册的过程在信令平台的抓包如下：
由S-CSCF比对RES响应值与XRES期望响应值，两者匹配，则该用户通过网络鉴权。接下来是为触发第三方注册而进行的流程，初始注册触发的二次注册流程中一定存在取用户数据流程，而重注册触发的二次注册流程可根据该用户数据在S-CSCF的预留情况，可选择性进行取用户数据流程，这有利于缩短时延和降低Cx接口信令负荷，取用户数据通过服务器分配请求SAR（Server
Assignment Request）和SAA服务器分配回应两个过程来完成，下文假设为存在取用户数据情况：
S-CSCF发送消息SAR（类型为注册）至HSS，由于相关用户签约和第三方认证数据等是空的，HSS响应S-CSCF的SAA消息，该消息包含了用户签约数据、两套iFC（初始过滤准则，用于触发AS进行第三方注册以及后续业务AS逻辑顺序）、计费信息域名等。
P-Associated-URI头域中包含了两个IMS公用身份标识(IMPU)，分别采用Tel URI和SIP URI格式，其中SIP URI格式包含该用户归属省份信息，比如下述号码为浙江移动号码：
Tel URI用于后续的语音呼叫，而SIP URI用于IMS网络路由。
Contact头域为注册成功用户的IMSI、IPV6地址和端口号、重注册时长、终端支持业务类型等，截图如下：
由P-CSCF保存Service-Route头域内容：归属S-CSCF名称，这样UE成功注册之后的其它SIP消息（非注册类，例如呼叫INVITE）抵达P-CSCF后，在转往下一跳时，直接在Route字段放置该用户的S-CSCF名称，经DNS翻译后，可实现SIP消息无需再经过I-CSCF实体就可直达该用户的归属S-CSCF。也就是说在用户IMS注册成功后，用户的非注册类的SIP消息，即可经Gm接口、Mw接口至归属网络的S-CSCF，由S-CSCF进行下一步逻辑处理。
下表为注册前、中、后三个状态的各相关网元必须要记录的地址、域名、安全数据或用户数据：
在基本注册成功之后，归属S-CSCF代替用户发起第三方注册，第三方注册过程仅在IMS核心网出现，Uu口无此信息，REGISTER消息中的Contact头域包含该用户归属S-CSCF的地址，以保证应用服务器AS不会直接路由到用户终端UE，而是总会先与S-CSCF联络。
S-CSCF网元检查所下载的该用户的初始过滤准则iFC，并触发去往为该用户服务的相关网元的路由，通告相关网元该用户已经注册且可到达，同时更新必要的网元数据，主要涉及S-CSCF与HSS/SCC-AS/VoLTE-AS/IP-SM-GW交互，涉及SIP协议的ISC接口、Diameter协议的Sh接口。
不同AS的第三方注册消息构造有如下特征：
From头域除了标签不一样其余相同，其中主要内容为S-CSCF名称，代替了用户的公有标识IMPU，这是第三方注册的由来；
Via头域除了分支不一样其余相同；
Call-ID头域都是相互独立的标识，也与之前的基本注册Call-ID不相关；
鉴于第三方注册可由初始注册触发，也可由重注册触发，主要环节是相同的。但由于初始注册情况下，AS和IP短信网关并没有该用户的注册信息，相关网元必须从HSS获取该用户的数据，相应过程和时间会稍长；而重注册情况下的第三方注册相对来说简洁明了且时间较短，下文假定为初始注册情况下的第三方注册。
REGISTER消息经S-CSCF发送给AS后，AS发现并不存在该用户的数据，因此判断为初始注册情况下的第三方注册，发送UDR消息给融合HLR/HSS，请求获取用户数据（包括用户身份数据、业务签约数据等），HSS返回UDA响应，携带用户数据。AS根据收到的用户数据对用户进行鉴权认证，通过之后，AS将用户数据保存到本地数据库，并继续下一步流程，最后向S-CSCF返回第三方注册的200OK的成功响应。根据涉及的第三方注册网元不同，分为三步：
这个步骤的第三方注册目的是为了后续被叫接入域选和eSRVCC作准备。
流程分为：用户数据查询UDR/UDA、订阅通知SNR/SNA（向HSS订阅用户数据变化通知，若终端通过Ut/CS或业务发放系统引起补充业务有变化时HSS则通知AS）、SCC AS与ATCF的MESSAGE过程、档案数据更新PUR、用户数据插入ISD。
涉及STN-SR描述如下：
STN-SR是ATCF的地址，UE在IMS网络注册时，ATCF根据终端能力和会话需要，为其分配STN-SR号码，将ATCF置于信令路由中，以便该终端的注册和呼叫相关消息都经ATCF。在基本注册时由SBC带给S-CSCF，之后由S-CSCF带给SCC AS，SCC AS同时从HSS处获得HSS登记的STN-SR号码，SCC
AS通过MESSAGE消息传给ATCF，总体作用是ATCF将eSRVCC切换上来的用户（INVITE消息中From头域为用户标识，to头域为ATCF地址）进行关联计费，而实现eSRVCC切换产生话单。
几个关键参数的分配及传递如下表：
在S-CSCF与SCC-AS注册完成后，会接着进行VoLTE-AS注册，VoLTE是处理呼叫业务的核心网元，包含基本业务、补充业务等，因此数据量较大。
第三方注册过程中会有多次UDR/UDA消息交互，此外还有档案数据更新PUR/PUA、请求订阅用户数据SNR/SNA（向HSS订阅用户数据变化通知，若终端通过Ut/CS或业务发放系统引起补充业务有变化时HSS则通知AS）、用户数据插入ISD过程。
完成S-CSCF与VoLTE AS的第三方注册之后，根据iFC准则，最后就是S-CSCF与IP-SM-GW的第三方注册，目的是为了之后VoLTE用户的收发短信都经过该网元，实现IMS域与CS域间短消息互通的功能（涉及SIP协议与MAP协议转换）。
由于IP短信网关地址并不在HSS签约数据中，因此该节点与HSS之间需要数据更新过程，通过PUR/PUA过程来实现，用户数据更新完成后，HSS才能为接受短信提供路由信息，也即IP-SM-GW的IP地址。
至此初始注册情况下的第三方注册成功完成，时长为400ms以内，也即完成了整个IMS注册，接下来是订阅过程。
顺便阐述一下重注册情况下的第三方注册，现网截图如下：
由于SCC AS和VoLTE AS、IP-SM-GW存在该用户数据，因此重注册情况下的第三方注册并不需要与HSS进行交互，流程相对简洁，时长在100ms以内。
该过程由UE发起，并终止于UE，在Uu可观察到相关消息。
SUBSCRIBE方法用于发起订阅请求，NOTIFY方法用于通告当前资源状态，当那些被订阅的资源的状态发生改变时，负责这一资源的网络实体将向订阅者发送通告，通报当前资源状态的变化情况，这是事件通告机制，以上都为单向行为，涉及以下几个概念：
订阅者向通告者发送SUBSCRIBE消息以请求创建一次订阅关系。订阅者负责接收NOTIFY消息，这些NOTIFY消息中包含订阅者所订阅的资源信息。
通告者接收SUBSCRIBE消息，判断P-Asserted-Identify头域携带的用户标识已在S-CSCF上注册，返回200(OK)响应，指示订阅成功。通告者负责产生NOTIFY消息，向订阅者回馈当前资源的状态。
UE是订阅者，订阅由UE发起，涉及SBC、S-CSCF及HSS网元；而S-CSCF是通告者，通告是由HSS触发、S-CSCF发起的。
通告者在成功创建订阅关系后，必须立即发送NOTIFY消息，向订阅者通告当前订阅资源的状态。通告内容也即消息体以xml格式予以表达，NOTIFY消息中必须包含扩展的 Subscription-State头域，指示创建的订阅的状态及剩余注册时间。共有3种订阅状态，分别是：
(2)pending：SUBSCRIBE请求已收到，但还没有足够的信息决定接受或拒绝此次订阅。
对应active状态或pending状态，该头部还带有expires参数指示此次订阅的有效时长。对应terminated状态，该头部应包含reason参数指示订阅被终止的原因，或者包含Retry-After参数，指示订阅者过一段时间后重新发起订阅请求。
对于订阅已被接受且授权成功的notify截图如下：
由于平台原因，上述抓包中涉及HSS的几个Diameter消息，予以补充如下：
注意：订阅和通告是同一个Call-ID，并且通告行为可延伸到23G网络，也即通告消息可通过S-CSCF、SBC、GGSN传至SGSN，之后通过Gb接口或IU-PS接口到达用户手机，这种现象发生在当UE重定向、盲重定向至23G网络且在RAU完成之后，用户发出register注销消息SIP数据包（Expires:
IMS注册失败与手机终端、IMS核心网设备是息息相关的，找出影响注册成功率的终端型号和核心网元，并进一步推动解决问题。本章节仅以注册成功率较低且请求数较高的几款型号终端来进行论述，不尽悉数。
7.1 苹果6s手机初始注册失败
在对苹果6s（A1700）的手机进行注册失败分析时，发现响应码为400的占比较高：
截取一个典型的苹果6s手机（A1700）的注册失败信令图：
在不考虑注册消息在Gm重复发送的因素以外，针对苹果终端失败响应码为400的情况，这类初始注册失败有个特征：
先发起初始注册，收到网络下发的401挑战，但手机不予理会，过几秒钟时间后，手机发起PDN连接性请求（APN=IMS），再次建立起IMS信令的默认承载，并分配得到新的IPV6地址。
再次发起初始注册，本次Call-ID与上次的相同，但不携带IMS认证响应RES结果（其Nonce和response均为空），Gm接口的P-CSCF地址改变（出于安全和负荷角度考虑，轮流使用两个不同地址的代理服务器）。
当S-CSCF收到本次的同一个Call-ID注册信息，认为是上次注册的延续，但同时根据未携带IMS认证信息也判断出并非接在401认证挑战消息后的二次注册，于是回应失败响应码400，具体原因值为“SIP Key Parameter Invalid”或“Invalid Message”。
建议终端厂家出补丁来解决401认证挑战消息的兼容性问题。
建议核查S-CSCF下发的401认证挑战消息的兼容性问题。
7.2 三星S6手机初始注册失败
在对三星S6（TAC=批次）的手机进行注册失败分析时，发现原因值为486和500的占比较高：
手机发起初始注册或重注册，S-CSCF回送401挑战消息，但手机UE未响应401挑战消息，稍后UE再次发起初始注册（可发生APN=IMS的PDN重新连接，重新分配IPV6地址），两次注册的Call-ID不同，但由于S-CSCF注册消息处理周期定时器（30s）还在工作，认为同一个IMSI用户的第一次注册尚未完成，因此直接回应486 Busy
Here消息，原因值为'Too many register in parallel'，拒绝了注册操作流程。由此产生了两次初始注册失败，截图如下：
建议终端厂家出补丁来解决401认证挑战消息的兼容性问题。
建议核查S-CSCF下发的401认证挑战消息的兼容性问题。
建议S-CSCF缩短注册保护定时器时长或修改流程以信任新的注册消息。
500失败响应码为服务器内部错误，由S-CSCF实体产生，建议检查S-CSCF内部事件记录。
在对步步高VIVO X6D（TAC=批次）的手机进行注册失败分析时，发现代码为486和500的占比较高：
代码486的产生类似三星S6手机过程：也是因为手机不响应401认证挑战消息，直至超时，而后手机再次发起初始注册，但被S-CSCF拒绝，产生486 BUSY HERE代码。
同时这款手机还有个问题：每隔一段时间发起一次初始注册（无规律），而不是重注册，那么S-CSCF会判断为该用户存在故障，于是一方面予以注册成功，另一方面又是第三方注销，存在逻辑上的混乱，之后是手机注销。而后手机再次发起初始注册，但对401认证挑战消息无响应，如此循环。
500响应码的注册失败为服务器内部错误，由P-CSCF实体产生，原因值为“AKA IP+Port conflict”，这是因为之前PGW分配的IPV6地址以及发布的两个P-CSCF地址所产生的手机端口号被某个P-CSCF拒绝所导致，更换另一个P-CSCF则通过。
建议终端厂家出补丁来解决401认证挑战消息的兼容性问题。
建议核查S-CSCF下发的401认证挑战消息的兼容性问题。
建议终端厂家出补丁来解决多次初始注册和注销的BUG问题。
建议终端厂家出补丁来解决UE源端口号算法问题，以便让P-CSCF所识别。
在对金立GN9010（TAC=批次）的手机进行注册失败分析时，发现原因值为486和500的占比较高。
其中失败响应码486的产生过程和三星S6手机的一样：也是手机发起初始注册，S-CSCF回送401挑战消息，但手机UE未响应401挑战，之后进行PDN连接性请求，重新分配得到IPV6地址，而后进行新的初始注册，两次注册的Call-ID不同，但前后两次时间差在S-CSCF的注册保护定时器作用的时长内，S-CSCF回送失败响应码486，具体原因为“Too
而500失败响应码的产生与步步高VIVO X6D的一样：也是由P-CSCF实体产生，注册失败为服务器内部错误，原因值为“AKA IP+Port conflict”，这是因为之前PGW分配的IPV6地址以及发布的两个P-CSCF地址所产生的手机端口号被某个P-CSCF拒绝所导致，更换另一个P-CSCF则通过。
建议终端厂家出补丁来解决401认证挑战消息的兼容性问题。
建议核查S-CSCF下发的401认证挑战消息的兼容性问题。
建议S-CSCF缩短注册保护定时器时长或修改流程以信任新的注册消息。
建议终端厂家出补丁来解决UE源端口号算法问题，以便让P-CSCF所识别。
由于写文档是非常辛苦的过程，希望得到大家的鼓励和动力,见下面“赞赏”按钮，愿大家能获得更多的知识点，对工作有强大的促进。
作者介绍：周国有，从事核心网工作后转至无线网优，熟悉3GPP协议，熟悉信令流程，擅长234G互操作融合优化，目前在杭州华星公司。
|
点击联系发帖人
