场景： 1. UAC使用头中的sip uri和头中的tel uri将INVITE发送到B2B UA。 2. B2B UA以与INVITE相同的uri方案以1xx（可靠）消息回复给哪个B2B UA（即，从标头中吸入uri，在标头中输入tel）。 3. UAC在两个标头（即“从”和“到”）中使用tel uri发送1xx的PRACK。 4.之后，所有1xx-PRACK和最后的200 OK-ACK事务都使用tel uri在From和To标头中。 5.最终ACK之后，B2B UA在发件人和发件人头中都使用tel uri将Reinvite发送到UAC。
所以，我的问题是第5点提到的Reinvite是正确的，还是我们应该使用第1点提到的初始邀请所使用的URI方案？
答案 0 :(得分：0)
在发送PRACK时，RFC3262在第4章（UAC行为）中指出：
[...] UAC必须使用方法PRACK创建一个新请求。此请求在与临时响应[...]
关联的对话框中发送
RFC 3261在对话框中创建请求的状态：
请求的“收件人”字段中的URI必须设置为远程URI 从对话框状态。 [...]的From URI 请求必须从对话框状态设置为本地URI。
因此，步骤3中的PRACK应该包含与步骤1中的INVITE请求相同的To-URI和From-URI。
从这一点开始，双方都将tel URI用于From和To报头，这似乎很好用。可以通过以下事实来解释这一点：对话是通过组合的call-id / from-tag / to-tag来标识的。 From-URI和To-URI在其中不起作用。它们可以被视为对话框的属性。
回答您的问题：
在这种情况下，您在ReInvite中使用哪种方案似乎无关紧要：双方仅将To-URI和From-URI作为对话框的属性，并在它们更改时对其进行更新。
当然，如果此特定的UAC与较宽松的UAS（要求To-URI和From-URI在对话的生存期内保持不变）相连接，则此行为可能导致连接问题。