Is your TURN server correct?

[robertsdotpm]

Okay, maybe a bit of a weird issue here: but I've been developing a TURN client in Python and I've been using Peerjs's TURN server to test my channel code. What I've observed is that at some point in the protocol this TURN server will send back UDP replies from a remote port other than the listen port listed for the TURN server.

I am not an expert here: but I feel like this behavior is invalid. My reasoning is that on 'restricted port NATs' they will filter packets that originate from a source port that is different from the one originally used in outgoing packets to a destination. So while packets to and from port 3478 will cross the NAT fine -- other packets will be dropped.

I am guessing the TURN server is creating a new 'client socket' to process replies on -- but with a UDP socket you can 'multiplex' it and use the same socket to send replies to any destination which would result in preserving the source / listen port. I think this is desirable since TURN is often the last step of allowing peers to communicate when all other options have failed! So if it still doesn't work for the second most restricted NAT type - then I think this is a problem.

I could also be mistaken about all of this. But we'll see, lmaoo