SIP register中的Contact还要承载User Agent的能力信息。
实网下抓取的UE log如上，下面就主要看下Contact header field要包含的内容及其含义。
Contact header field设置为包括 UE IP地址或FQDN的SIP URI。 如上图contact中sip:69a5de6a-a03e-46d6-ad7a-b0d974c8f083@[2409:815a:3097:c900:3c5f:52ff:fedd:e9b]:5060对应的是UE的IPV6地址。
如果UE支持GRUU，又支持多次注册且有可用的 IMEI或有可用的MEID时，UE应包括包含"+sip.instance" header field。 仅IMEI会用于生成支持 3GPP 和 3GPP2 定义的multi-mode UE 的instance ID。当UE不支持GRUU且不支持多重注册时，对UE包括基于IMEI或MEID的instance ID的要求并不意味着对网络有任何额外要求。
log中IMEI = 353407230004750 ，而+sip.instance="<urn:gsma:imei:35340723-000475-0>"
当UE支持多次注册时，就会在contace header 中包含"reg-id"。当一个UA注册多次，针对不同的流程，每次并发注册会获取唯一的reg-id值。每个 UA 都有一个唯一的instance ID，即使UA重新启动或power cycled，该UA也保持不变。 每个UA针对同一 SIP address of record (AOR)通过不同的flow 可以注册多次以实现高可靠性。 每次注册UA instance ID和每个flow都不同的 reg-id标签。 注册商可以使用instance-ID来识别这两个不同的注册是否对应同一个UA。 在reboot或network failure后，注册商可以使用reg-id标签来识别UA是否创建了新流程或刷新或替换旧流程。
当代理将消息路由到它绑定的UA时，它可以使用任意一个已经成功注册的flow。 在某个特定flow上未能成功deliver的request可以在备用流上再次尝试。 代理可以通过比较instance-id来确定哪些flow进入同一个UA。
代理可以通过查看 reg-id 来判断某个流是否替换了之前放弃的流。
UE不支持multiple registration，没有包含reg-id。
UE 应将所有支持的 ICSI 值包含在 g.3gpp.icsi-ref media feature tag中，如上图解释IMS Communication Service Identifier (ICSI)。而其他相关的streaming feature tag 罗列如上，主要在RFC 3840和 RFC 5688 中。g.3gpp.nw-init-ussi代表UE支持 the network initiated USSD over IMS。
g.3gpp.accesstype的用法解释如上。
UE log中，相关的media feature tag为 +g.3gpp.accesstype="cellular2";audio;+g.3gpp.smsip;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"。 这个UE不支持video call，因而没有带video。
如果 UE 支持 Registration for Multiple Phone Numbers in SIP(RFC 6140)并执行外部连接网络的功能，则对于批量号码联系人的注册，UE 应包括一个不带user portiom并包含"bnc"URI 参数的 contact URI。
如果UE没有特定原因(例如某些UE执行外部附着网络的功能)，则UE应该在contact address的URI中包括user part，值得注意的是user part是全球唯一，不会泄露任何私人信息；此时一般根据RFC4122生成time-based UUID(通用唯一标识符)，其是全局唯一的，不会泄露任何私人信息。
UE log没有带bnc URI，而sip:69a5de6a-a03e-46d6-ad7a-b0d974c8f083@[2409:815a:3097:c900:3c5f:52ff:fedd:e9b]:5060 对应的就是UUID。
上图是34.229-1 Protocol conformance specification中有关initial IMS registration 中contact header field default 参数的总结。