Hi, I want to share my experience with verto client and nat. I’m facing a delay issue with verto clients behind some types of nat (symmetric and port restricted cone nat), the port in the SDP is not the same for media and that introduces 3 seconds delay at the begging of the call. It only occurs in the direction Client -> Freeswitch. From the capture I notice that this delay is cause in the dlls negotiation, the Client Hello is sent to a port that is closed at the client side, after 3seconds FS detects that the rtp traffic is arriving in a natted port and it now send the Client Hello to that port. FS —> Client (pkt flow): 1s. Client Hello ——> :49897 <— (port unreached) 2s. Client Hello ——> :49897 <— (port unreached) 3s. Client Hello ——> :1025 <— Server Hello Certificate —> :1025 (Normal audio) Currently I solve it using turn server in the client and forcing to present only relay candidate to FS, DTLS is negotiated immediately, the only issue I see is that FS is not using the relay server (my configuration), it communicates directly to the client so it detects the change of address during media rtp: 1s. Client Hello ——> relay:49897 ——> client:49897 <— Server Hello:49897 FS RTP —> Relay: 49897 ——> client:49897 FS <— RTP from client address: 49897 (FS detects address change, stop send it to relay address and with to client address) FS RTP —> client:49897 The address change detection is perfect in this situation, we only load the relay server for dtls negotiation, then the media flows directly between FS and Client. What do you think of this approach? Do you have a better solution for this problem? -- Saludos / Regards / Cumprimentos António Silva