在某些消息系統中，兩個消息傳遞客戶端在聊天或語音呼叫中直接發送/接收數據包。我認爲基本的機制是（例如TCP）：這些客戶端程序打開一個偵聽的TCP套接字並告訴消息/協調服務器他們的IP/PORT對。然後客戶端程序從消息/協調服務器中檢索對方的IP/PORT。其中一個（比方說A）然後用另一個（比方說B）與檢索到的IP/PORT對B啓動TCP。NAT或代理如何對傳入的TCP SYN數據包做出反應？
當被動客戶端B（等待TCP SYN分組）不在NAT或代理後面，這很好。但是如果B位於NAT或代理之後，則IP/PORT對實際上是NAT或代理的公共網絡接口。
所以我的問題是，當一個NAT或代理收到一個TCP SYN時，它的反應是什麼？他們如何將TCP SYN中繼到相應的主機/進程？
我懷疑你最初的假設是否正確。更有可能它們都打開到服務器的活動連接，服務器在它們之間路由數據。這簡單得多，你描述的問題消失了。
這個問題顯然是問很久以前，但仍...
聊天和語音/視頻通話，通常的處理方式完全不同。在聊天的情況下，您可能會使用XMPP協議，其中兩端將連接到服務器並通過它交換數據。 XMPP駐留在第4層上的TCP上，因爲可靠性優先於此情況下的延遲。由於客戶端是打開和維護連接的客戶端，因此在這種情況下您不會遇到NAT問題。
在另一方面，語音/視頻通話更加複雜了一點，所以你通常有：
信令通常通過使用SIP（會話發起協議）等一些更高層協議進行TCP。該通信將通過服務器。媒體使用RTP（實時傳輸協議）等高層協議通過UDP，這部分通信通常是點對點通信。單個UDP端口可用於傳輸和接收一個語音/視頻通道的流量。此外，您可能希望在通話就緒時獲得有關通話質量的信息，因此您可以減少使用的帶寬以避免/減少數據包丟失。爲此，您需要使用像RTCP（實時傳輸控制協議）這樣的協議。在這種情況下，NAT穿越至關重要！由於客戶都不知道他們的公共IP地址，所以你需要一個內部網絡服務器（在公共互聯網上），它可以告訴你「如何從外部看到」，即在NAT後面。在例如WebRTC這個服務器的世界知道ICE。當對方發現它在互聯網上是如何顯示的時候，它會將這些信息放入信令消息的SDP片段中，以便另一端可以通過互聯網到達它。請記住，執行NAT的路由器可能還需要一些其他設置，以保持語音/視頻UDP端口的使用情況（將NAT上的流量從互聯網NAT轉回給您）。
最後，還有其他解決方案在這些情況下使用，但這取決於您的設置。如果您正在爲最終用戶編寫軟件，則以前的解釋將適用。但是，如果您正在爲企業市場編寫軟件，那麼在企業網絡邊界處的附加服務器（稱爲EDGE）等解決方案將是一種常見方法。
我可以寫幾個小時，但這應該是足夠的開始... :)