接前面的章节。

　　12.2 Requests within a Dialog

　　-旦介于两个UA之间的dialog创建以后，如有必要，其中之一UA可以在dialog中发起新的事务。发送请求的UA将会在事务中充当UAC的角色。接收请求的UA将会在事务中充当UAS的角色。注意，在UA执行事务期间，这些事务创建了不同的dialog ,它们的角色可能是不同的。

　　在dialog中，请求可以包含Record-Route和Contact头值。尽官这些请求可能修改远端目的地URL,但是，这些请求不能导致dialog中路由组修改。

　　具体来说-些请求中，不刷新目的地请求的这些请求不修改dialog的远端目的地URL ,刷新目的地请求的可以修改。在使用一个INVITE创建的dialog中，只有re-INVITE是一个被定义的目的地刷新请求。参考（ Section 14 ）获得更多讨论。其他拓展可以通过不同的方式在dialog中定义其他的目的地刷新请求。

　　注意，一个ACK不是一个目的地刷新请求。

　　目的地刷新请求仅更新dialog的远端目的地URL ,不更新从Record- Route构建的路由组。更新后者将会引起与RFC 2543向后兼容的问题。

　　Dialog中的请求是通过此状态多种组件构成，此状态被存为dialog的一个部分。

　　请求中To头域的URL必须设置为远端URL（从dialog状态中获得）。在请求中To头域中的标签tag必须设置为dialog ID的远端标签tag。请求的From URL必须设置为dialog状态中设置的本地URL地址。请求中From头中的tag标签必须设置为dialog ID的本地tag标签。如果远端或者本地标签tags值为空，标签参数必须从各自的To或者From头中忽略。

　　初始请求中的To头和From头使用URL方式以及在此后续请求中的URL使用方式是通过RFC2543的向后兼容性来完成的，RFC2543中使用URL来支持dialog的身份确认。在本规范中，仅使用tags标签来确认dialog的身份。预计，在mid-dialog中的初始To和From头URL强制映射处理方式将会在此规范的后续重审中被废弃。

　　此请求的Call-ID必须设置为dialog的Call-ID。在每个方向上（当然，除了ACK和CANCEL以外，这些请求中的号码等于此请求被确认或者取消的号码），一个dialog请求必须包含一个严格单调增加和持续的CSeq序列号（每次递增一个数值）。因此，如果本地序列号不是空值，本地序列号必须递增一，并且此值必须存储在CSeq头中。如果本地序列号为空，必须选择一个初始的值，根据Section 8.1.1.5中的指导来选择。CSeq头中的method必须匹配请求中method。

　　CSeq使用32 bits长度的数字串，在一个单呼叫中，一个客户端能够生成一个请求，一秒内可能大概需要136年才需要涵盖这样的数字。选择了序列号的初始值以便在同样呼叫中的后续请求将不会在包含此序列号数字。非零的值允许客户使用一个基于时间的初始序列号。例如，客户端可以选择最有效率的31 bits长度作为初始序列号（32bits秒级为标准）。

　　UAC使用此远端目的地和路由组来创建请求中的Request-URI和Route头域。

　　如果路由组设置为空，UAC必须把远端目的地URL置于Request-URI中。UAC一定不能给请求添加Route头值。

　　如果路由组不为空，在路由组的第一个URL中包含了lr参数（Section 19.1.1）的话，UAC必须把远端目的地URL置入到Request-URI，并且必须包含一个Route头，此Route按续包含路由组值和所有参数。

　　如果路由组不为空，并且它的第一个不包含lr参数，此UAC必须把从路由组中的第一个URL置入到Request-URI，去除任何Request-URI不支持的参数。此UAC必须添加一个Route头，此头值按续包含剩余的路由组值。然后，作为最后的值，此UAC必须把远端目的地URL置入到Route头值中。

　　例如，如果远端目的地是sip:user@remoteua，并且路由组route set包含：

　　<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>

　　此请求的构成需要以下Request-URI和Route头域值：

　　METHOD sip:proxy1

　　Route:  <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>

　　如果路由组中的第一个URL不包含lr参数值，此proxy表示不能理解此规范中的路由机制，使用RFC 2543的规范来执行，使用第一个Route头替换这个Request-URI，第一个Route头是当进行消息转发时收到的路由头。处理消息过程中，通过（严格路由）strict router时，把路由头中结尾的Request-URI保存到那个Request-URI中。

　　（当此请求抵达一个松散-路由时（loose-router），它将被返回到此Request-URI中）。

　　在一个dialog中，UAC应该在任何目的地刷新请求中包含一个Contact头，而且，除非处理过程中有一个需求需要修改它，URL应该和此dialog中前面请求所使用的URL相同。如果"secure" flag为true的话，那个URL必须是一个SIPS URI格式。就像在Section 12.2.2讨论的一样，在目的地刷新请求中的Contact头将会更新远端目的地URL。这样就会支持UA提供一个新的contact地址，在此dialog生命周期内，它的地址也会发生改变。

　　但是，请求不是目的地刷新请求的话，此请求不会影响此dialog中的远端目的地URL地址。

　　其他请求构成方式在Section 8.1.1中有更多介绍。

　　一旦请求构建完成后，服务器的地址会被处理，使用同样的外部dialog请求处理方式发生此请求（Section 8.1.2）。

　　在Section 8.1.2中规定的处理流程中，如果没有Route头的话，此流程将会导致请求被发送到一个地址，这个地址标识在topmost Route头中或者Request-URI中。受限于某些限制，它们允许此请求被发送到其他可选目的地地址（例如，默认的outbound proxy没有出现在路由组中）。

　　继续更新中。