asd199086的博客

如图MO invite中的SDP所示，对于DUT来说，RTP payload =127是首选，也就是EVS codec是首选，之后按顺序看AMR-WB codec是次选，AMR codec是次次选。后续session用哪个codec，还要根据MT支持的codec情况以来确定，这个例子中，MT回复的也是EVS codec，最后session选用的就是EVS codec。一上REF，结果REF正常，进一步检查发现REF通话时用的codec是EVS，而DUT用的是AMR-WB。进一步排除了UE问题。

如果registrar支持P-Associated-URI header，那么registrar必须始终在 REGISTER request的所有 200 OK response中插入P-Associated-URI header field，无论 REGISTER 是否是initial registration、re-registration或de-registration，无论是否有零个或多个关联的URI。中的内容，相信到这里，P-Associated-URI header的含义和用法已经很清楚了。

如果body为空且存在Content-Type header field头，就表明特定类型的body长度为零，如空的音频文件。message-body长度（以字节为单位）由Content-length header field提供，因而Content-Length header field指示发送给收件人的message-body的大小。例如上图INVITE中用的是compact form，该消息中有带content-type:application/sdp，message-body就是对应的SDP信息。

temporary public user identity和private user identity格式相关，private user identity(IMPI)的格式为 "@ims.mnc.mcc.而Tel URI 格式为 tel:+而temporary public user identity(T IMPU)的格式为: sip:@ims.mnc.mcc.上述内容来自TS 23.003。

在构造的ACK request时，ACK必须包含 Call-ID、From 和 Request-URI header，这些值要等于initial INVITE request中的对应header 值。而ACK中的 To header field必须等于被确认的response中的 To header，也就是ACK的To header会包含tag。ACK 中的 CSeq header field必须包含与initial INVITE中的序列号相同，但method参数必须等于“ACK”。

当给出paylaod type number列表时，这意味着所有这些payload format都可以在session中使用，并且这些payload format按优先顺序列出，其中列出的第一个format是首选。如图MO invite中的SDP所示，对于DUT来说，RTP payload =127是首选，也就是EVS codec是首选，之后按顺序看AMR-WB codec是次选，AMR codec是次次选。后续session用哪个codec，还要根据MT支持的codec情况以及具体协商过程来确定。

这里还有一点需要注意，MO的UA可以为已确认 dialog或 early dialog发送 BYE，MT的UA只能在已确认dialog中发送BYE，但不能在early dialog中发送BYE。在接收到 INVITE的 CANCEL 请求但尚未发送final response的 UAS 将“停止响铃”，然后使用特定的error response(487)来响应 INVITE。而MT UA发送BYE也是有条件限制的，MT的UA只能在收到2xx 响应的ACK 或服务器transaction超时，才能。

UA在IMS注册失败时怎么retry，协议上也有规定，这篇就对这部分做了简单整理，主要逻辑在RFC 5626 4.5. Flow Recovery 中有解释，具体内容如下。

虽然在大多数情况下是合理的，但在某些重要情况下，INVITE就会是问题复杂化，主要就是在回答initial INVITE之前需要修改会话的的这个阶段。有时候MO或MT需要在call answer前对session进行修改，然而根据设定re-INVITE不能用于这种场景，由此定义了UPDATE method，UPDATE method 可以由 UA 在dialog(early或confirmed)内发送，在不影响dialog status时就可以实现session参数的更新。

对于2xx response，ACK则由UAC core生成。对INVITE的2xx response会建立一个session，并且还在发出INVITE 的UA和生成2xx response的UA之间创建dialog。在session进行过程中，MO和MT可能需要修改session中的地址或端口、添加媒体流、删除媒体流等，这时可以在当前建立的dialog中重新发送一个INVITE实现，这就是所说的re-INVITE(即re-INVITE消息必须与intial INVITE消息处于同一dialog中)。

对于provisional response可靠性，则采用相同的方式。如果UAC不希望一直使用可靠的provisional response，而只是在UAS需要发送response时才需要，那UAC request中的Supported header 必须包含带有option tag的100rel。如果收到初始请求的provisional response，并且该response有 Require header field 包含option tag 100rel，则代表要可靠地发送该response。

例如上图5.0c，在注册时可以将一个用户的多个ID定义在一个Implicity Registered ID set中，只要set中的某个public user ID通过单个IMS注册成功后，其他public user ID也会认为完成了注册，之后会在REGISTER的 200 OK response中的P-Associated-URI header field 带下来，这时候就不需要将每个ID都进行一遍注册。下面就是纯翻译，平时只关注UE侧，对网络侧的理解还是有所欠缺，但是感觉翻译完，也能理解。

dialog通过SIP消息建立，例如对 INVITE request的 2xx response。举例来说，dialog ID 由Call-ID 、from-tag、和to-tag确定，UAC在生成INVITE时，会生成Call-ID及From tag，在收到183 SESSION PROGRESS时就收到了UAS 的To tag，此时就可以确定dialog ID，根据这段描述，此时对应的是early dialog，而在收到final response即200 ok时，才算是final dialog。

SIP request有作为start-line的Request-Line，Request-Line包含SIP method name，a Request-URI以及用单个空格分隔的SIP协议版本。request和response都由start-line ，一个或多个header fields，指示header fields 结束的empty line以及可选的message-body。start-line，message-header line以及empty line 都必须。

上述讲2xx的ACK 作为另外 transaction的原因就是体现了INVITE的地位的重要性， 也体现了将INVITE的所有200 (OK) response传递给UAC的重要性，对 INVITE request的2xx response的ACK则是一个单独的事务，也就是2xx的ACK 对应的就是另一个transaction。如果response是2xx，则ACK 就不会被当作transaction的一部分，也就是2xx的ACK 就会当作另一个transaction。

如果UE没有特定原因(例如某些UE执行外部附着网络的功能)，则UE应该在contact address的URI中包括user part，值得注意的是user part是全球唯一，不会泄露任何私人信息；如果 UE 支持 Registration for Multiple Phone Numbers in SIP(RFC 6140)并执行外部连接网络的功能，则对于批量号码联系人的注册，UE 应包括一个不带user portiom并包含“bnc”URI 参数的 contact URI。

IP Multimedia Core Network Subsystem (IMS)商用已久，相对于CS domain的语音方案，IMS则是基于IETF定义的会话控制功能与多媒体传输功能通过IP-CAN实现的全IP完整语音解决方案。IMS能为无线和有线用户实现语音、视频、消息、数据等服务。便于运营商通过IMS向其用户提供多媒体服务，IMS也包含计费，鉴权，签约数据收发等功能。相比于企业级的语音方案，运营商级的语音网络要更过的考虑计费，移动性，Qos等等问题。IMS是业务层面实现，不关心接入网，因而。