當STUN服務器從不同的STUN代理接收到具有相同事務ID的請求時，STUN服務器如何工作？

Question

當一個STUN服務器收到來自兩個具有相同事務ID的不同STUN代理的請求時，它應該如何表現？

Answer 1

來自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 2

我不認爲你應該準備你的軟件來處理這種奇怪的情況。事務ID是由客戶端生成的隨機值，您很可能在昏迷客戶端看到這樣的錯誤。

交易ID是一個96位的標識符，用於唯一標識 STUN交易。對於請求/響應事務，由STUN客戶端爲請求選擇 事務ID，並在響應中由服務器響應 。

如果不是隨機的，那麼最有可能的是將一個單一的虛假客戶端軟件造成的，最終你剛剛結束了發送壞的答案是客戶端，直到它的開發者發現這一點，並解決他們的軟件。

Answer 3

這不應該發生，但如果服務器應該檢查5元組（客戶端IP地址和端口，服務器IP地址和端口以及傳輸協議（目前是UDP，TCP或TLS之一）的組合）） 。如果五元組不匹配，那麼服務器應該繼續考慮作爲一個有效的事務，否則它應該按照RFC-5766進行操作。