Hello everyone, I'm testing various NAT traversal mechanisms with the PJSUA sample application on Mac OS X Lion. Overall things are going extremely well. I've currently configured one TLS account with STUN and ICE always enabled. Behind NAT to various other PJSUA ICE/STUN enabled endpoints on various networks this has worked perfectly. Even when testing with non PJSIP endpoints two-way audio is established without any media relaying. Very awesome. Whether you're using STUN+TURN+ICE or just STUN+ICE enabled endpoints the connection address in the initial SDP offer doesn't really matter - ICE enabled endpoints will test the various candidates and generally "do the right thing". When the nomination is successful and ICE ends PJSIP sends an UPDATE with an updated connection address in the SDP and everything is great. When you have STUN+ICE this initial connection address (and port) is the STUN discovered external address. When you enabled STUN+ICE+TURN, however, this initial connection address is always assigned from the TURN server (relay address). Of course the ICE candidates still look great and the local addresses, STUN discovered external addresses, and TURN relay candidates are in the right order and as I've said the remote ICE endpoint will just figure them out. Ideally you'd never use TURN. Proxying RTP is almost always bad when you don't absolutely need to do it for two way audio/video. Outside of the lab, in the real world, I'm certain there are cases where I will need TURN relaying (unfortunately). However, as of now enabling TURN on the account essentially requires TURN for my non-ICE enabled endpoints. Ideally there would be a way to change this behavior at the time of call setup, like so: App knows it's calling a non-ICE capable endpoint and doesn't need TURN: - Use STUN discovered external address/port in initial INVITE SDP offer - Disable ICE - Disable TURN allocation App knows it's calling an ICE capable endpoint and we have a TURN server available: - Do what you do now -or- - Provide option to just include TURN relay as potential candidate and leave STUN discovered external address/port in initial INVITE SDP offer Is some mechanism like this currently available? I need to mention that regardless of which options I use I have a robust NAT traversal solution here - I can't seem to get PJSIP to produce one-way audio, which is incredible. I would just like to optimize my media path in cases where I think I should be able to make a decent guess at the capabilities of the remote endpoint before I initiate the call. The other solution, of course, is to ICE enable all of my endpoints. Unfortunately that just can't happen :(. Some traces and logs: STUN+TURN+ICE: http://pastebin.com/Ysk1bT9W STUN+ICE: http://pastebin.com/30QMP9W8 Thanks! -- Kristian Kielhofner
