当STUN服务器从不同的STUN代理接收具有相同事务ID的请求时，它如何表现？

Question

当STUN服务器收到来自具有相同交易ID的两个不同STUN代理的请求时，它应该如何表现？

Answer 1

这不应该发生，但是如果那时服务器应该检查5元组（客户端IP地址和端口，服务器IP地址和端口以及传输协议（当前是UDP，TCP或TLS之一）的组合）。如果5元组不匹配，则服务器应该继续将其视为有效事务，否则它应该按照RFC-5766行事。

Answer 2

STUN绑定请求中的事务ID简单地在STUN绑定响应中回显。除了记录之外，服务器不会尝试将此值解释为其他任何内容。它也不会尝试管理或处理重复请求或重复事务ID。如果两个不同的客户端发送具有相同事务ID的绑定请求，则两者将在其相应的响应中获得相同的事务ID。

交易ID仅供客户使用。如果客户端收到来自服务器的响应，其响应ID与请求中使用的响应不同，则应该忽略它。因为该数据包可能是从之前的STUN会话延迟到来的。

关于唯一可以存在重复转换ID的时间是客户端超时等待响应并再次重新发送绑定请求。 RFC 5389在section 6：Resends of the same request reuse the same transaction ID中提到了这一点。

Answer 3

我认为你不应该准备你的软件来处理这种奇怪的情况。事务id是客户端生成的随机值，您不太可能在stun客户端中看到此类错误。

  

事务ID是96位标识符，用于唯一标识      STUN交易。对于请求/响应事务，      STUN客户端为请求选择事务ID      在响应中由服务器回应。

当不是随机的时候，很可能是由一个虚假的客户端软件造成的，最终你最终会向该客户端发送错误的答案，直到它的开发人员发现并修复他们的软件。