PRAC实现中的UAC行为

Question

如果UAS按正确的顺序发送了UAC，那么后来在UAC收到200 OK的PRACK而不是INVITE的200 OK.UAC的行为应该是什么？它会无声地丢弃数据包吗？或者它会建立对话框吗？

Answer 1

我在标准中看不到任何东西在某种程度上限制了200 OK的INVITE和200 OK for PRACK在客户端。根据

，UAC应处理对INVITE的2xx响应

RFC 3261 - 13.2.2.4 2xx响应

  

多个2xx响应可能会到达UAC以获得单个INVITE   请求由于分叉代理。每个回答的区别在于   To标头字段中的tag参数，每个都代表一个
  不同的对话框，带有不同的对话框标识符。

     

如果2xx响应中的对话标识符与对话框
匹配   现有对话框的标识符，对话框必须转换为
  ＆＃34;确认＆＃34;状态，对话框的路径设置必须为
  使用Section的过程基于2xx响应重新计算      12.2.1.2。否则，在＆＃34;确认＆＃34;中的新对话框状态必须使用第12.1.2节的程序构建。

它必须处理基于RFC 3262的PRACK响应

  

请注意，PRACK与a中的任何其他非INVITE请求类似      对话框。

需要UAS

  

UAS可能会在之前发送对初始请求的最终响应      已收到所有未确认的可靠临时的PRACK      回复，，除非最终回复是2xx 和任何      未经承认的可靠临时答复包含一个会议      描述。在这种情况下，它必须不发送最终回复直到      这些临时答复得到承认。

所以看起来UAC接收2xx响应可以决定UAS已经收到PRACK并停止重传 - 但是没有像RFC中所说的那样。因此，即使收到2xx对INVITE UAC的响应，也应该继续重传PRACK直到它被确认。