VoLTE注册过程

目录 一、概述 二、初始注册

三、后续注册---重注册 四、后续注册---二次注册 五、第三方注册

5.1 S-CSCF与SCC AS的第三方注册 5.2 S-CSCF与VoLTE AS的第三方注册 5.3 S-CSCF与IP-SM-GW的第三方注册 六、订阅

七、常见初始注册失败 7.1 苹果6s手机初始注册失败 7.2 三星S6手机初始注册失败

7.3 步步高VIVO X6D手机初始注册失败 7.4 金立GN9010手机初始注册失败 ? 一、概述

用户开通了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等，该过程步骤较多，此图为示意图。

从附着开始的IMS注册过程中涉及了绝大多数协议：RRC、NAS、S1AP、SGsAP、GTP-C V2、GTP-U V1协议、SIP协议、Diameter协议等，作为选项还有MAP、CAP。

由于SIP消息与VoLTE优化分析紧密结合，在此简略介绍SIP协议：

SIP协议源自于互联网产物，并非传统的通信协议，消息采用非比特位方式的文本编码，可阅读性强，具有非常强大的灵活性和扩展性，缺点就是存在大量的兼容性问题。

SIP消息有请求和响应2种类型，每个消息包含3个元素：请求行/状态行、头域、消息体（可选）。

RFC 3261中定义的SIP消息头域包括Via、From、To、Call-ID、CSeq、Contact、Content-Type、Content-Length、Max-Forwards、Proxy-Authenticate等在内共有44个，并且这些头域的数目是可扩展的。头域的介绍见本文其它相关章节，在本章节仅仅简略叙述几个头域。

Content-Type头域指示携带的消息体的媒体类型，比如application/sdp、message/sip。

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头域中相关认证授权信息为空（比如随机数为空、认证响应为空、无完整性保护），如下图：

经Gm接口，P-CSCF收到Register消息后：

删除Proxy-Require头域，将Security-Client头域保存到本地，调整Require头域为path，并在Authorization头域中添加“integrity-protected=no”标签，表示初始注册消息未受保护，增加以下头域：

增加P-Access-Network-Info头域为接入位置包含网络类型、SBC域名、UE IPV6地址和端口号共四项，。

增加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-Visited-Network-ID头域为P-CSCF的域名（也即P-CSCF的本地网络标识）。

增加P-Charging-Vector头域为P-CSCF收到注册消息后产生的ICID计费标识。

增加Feature-Caps头域包含STN-SR号码。

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消息，包含下面内容。

由于HSS不存在该用户的P-CSCF Network ID或S-CSCF名称信息，故HSS判断该用户为first register（初始注册），设置相关AVP属性值对---实验性结果代码为2001（DIAMETER_FIRST_REGISTRATION），下发S-CSCF服务器能力集（分为强制能力和可选能力），I-CSCF收到UAA消息后，根据其中的S-CSCF的能力集进行某种选择算法，选择一个合适的S-CSCF。

在拜访网络的I-CSCF选定某个归属S-CSCF后， I-CSCF转发Register消息至归属网络S-CSCF，该消息的Request-URI头域为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构成五项。

P-CSCF依然以明文形式转发register消息给I-CSCF。

值得注意的是：重注册时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名称。

经过I-CSCF与HSS的授权信息交互后，HSS判断出用户为后续注册---DIAMETER_SUBSEQUENT_REGISTRATION (2002)，并给定S-CSCF名称（而不是能力集），S-CSCF名称经DNS翻译后，I-CSCF传递register消息至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构成五项。

P-CSCF依然以明文形式转发register消息给I-CSCF。

后续注册的过程在信令平台的抓包如下：

I-CSCF发送用户授权请求UAR消息给HSS，HSS判断出用户为后续注册---DIAMETER_SUBSEQUENT_REGISTRATION (2002)，将之前记录的

S-CSCF的地址信息（注意是S-CSCF名称而不是能力集）通过UAA消息发送给I-CSCF，S-CSCF名称经DNS翻译后，I-CSCF转发Register消息至S-CSCF。

由S-CSCF比对RES响应值与XRES期望响应值，两者匹配，则该用户通过网络鉴权。接下来是为触发第三方注册而进行的流程，初始注册触发的二次注册流程中一定存在取用户数据流程，而重注册触发的二次注册流程可根据该用户数据在S-CSCF的预留情况，可选择性进行取用户数据流程，这有利于缩短时延和降低Cx接口信令负荷，取用户数据通过服务器分配请求SAR（Server Assignment Request）和SAA服务器分配回应两个过程来完成，下文假设为存在取用户数据情况：

S-CSCF发送消息SAR（类型为注册）至HSS，由于相关用户签约和第三方认证数据等是空的，HSS响应S-CSCF的SAA消息，该消息包含了用户签约数据、

两套iFC（初始过滤准则，用于触发AS进行第三方注册以及后续业务AS逻辑顺序）、计费信息域名等。

S-CSCF原路返回或内部传递SIP---INVITE 200 OK消息至I-CSCF，传递至P-CSCF，最终到达UE，确认注册成功，包含头域叙述如下：

P-Associated-URI头域中包含了两个IMS公用身份标识(IMPU)，分别采用Tel URI和SIP URI格式，其中SIP URI格式包含该用户归属省份信息，比如下述号码为浙江移动号码：

Tel URI用于后续的语音呼叫，而SIP URI用于IMS网络路由。

Contact头域为注册成功用户的IMSI、IPV6地址和端口号、重注册时长、终端支持业务类型等，截图如下：

Service-Route头域包含有该用户归属的S-CSCF名称，由S-CSCF向I-CSCF发送，继而由I-CSCF传递给向P-CSCF，如下图所示注册成功消息中所示：

由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进行下一步逻辑处理。

Path头域包含S-CSCF已登记的IPV4的P-CSCF地址，经P-CSCF实体变换为IPV6的P-CSCF地址传递给UE，作为Gm接口的端地址。

Accept-Resource-Priority头域包含用户签约的优先级，比如wps.4。

可选项---Authentication-Info头域，携带下一次重注册的随机项nonce。

下表为注册前、中、后三个状态的各相关网元必须要记录的地址、域名、安全数据或用户数据：

五、第三方注册

在基本注册成功之后，归属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的第三方注册消息构造有如下特征：

Request-Line内容为具体第三方应用服务器的名称，比如SCC AS、VoLTE AS、IP-SM-GW；

From头域除了标签不一样其余相同，其中主要内容为S-CSCF名称，代替了用户的公有标识IMPU，这是第三方注册的由来；

Via头域除了分支不一样其余相同；

Call-ID头域都是相互独立的标识，也与之前的基本注册Call-ID不相关；

To、Contact、P-Charging-Vector、P-Access-Network-Info、P-Visited-Network-ID头域内容均相同，To头域为用户的SIP格式的公有标识IMPU；

消息体（Message Body）内容完全是一样的，均为二次注册内容，该消息体是由I-CSCF传递到S-CSCF的，包含内容有Request-Line、Message Header、I-CSCF IP地址的Via头域、基本注册Call-ID头域、From/To头域、成功认证向量的Authorization头域、Contact头域、Path头域、P-Visited-Network-ID头域、P-Access-Network-Info头域、P-Charging-Vector头域、ATCF/STN-SR内容的Feature-Caps头域等。

手机发起初始注册或重注册，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内部事件记录。

7.3 步步高VIVO X6D手机初始注册失败

在对步步高VIVO X6D（TAC=86989502批次）的手机进行注册失败分析时，发现代码为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所识别。

7.4 金立GN9010手机初始注册失败

在对金立GN9010（TAC=86861202批次）的手机进行注册失败分析时，发现原因值为486和500的占比较高。

其中失败响应码486的产生过程和三星S6手机的一样：也是手机发起初始注册，S-CSCF回送401挑战消息，但手机UE未响应401挑战，之后进行PDN连接性请求，重新分配得到IPV6地址，而后进行新的初始注册，两次注册的Call-ID不同，但前后两次时间差在S-CSCF的注册保护定时器作用的时长内，S-CSCF回送失败响应码486，具体原因为“Too Many Register in Parallel”。

而500失败响应码的产生与步步高VIVO X6D的一样：也是由P-CSCF实体产生，注册失败为服务器内部错误，原因值为“AKA IP+Port conflict”，这是因为之前PGW分配的IPV6地址以及发布的两个P-CSCF地址所产生的手机端口号被某个P-CSCF拒绝所导致，更换另一个P-CSCF则通过。

本文来源：https://www.bwwdw.com/article/g5jv.html