On Sat, 3 Jan 2009, Iñaki Baz Castillo wrote:
2009/1/3 Aymeric Moizard jack@atosc.org:
This specification draft-ietf-sip-outbound-16 ios only about SIP: http://tools.ietf.org/html/draft-ietf-sip-outbound-16
True, I didn't read it. Thanks.
You're welcome.
So for 100% of UA, STUN is usable for keeping alive and detecting IP changes on the SIP connection.
Don't you want kamailio to be standard?
Why do you thing so? Of course I want it. I was just asking a question, no more. ;)
It though you were aware of the draft! This draft looks important to me as a first step, because it's important, for compliance that the contact header is not changed in INVITEs by proxies... This is a first step towards message integrity... (Second step is about ICE discussion below!)
For RTP? Even if you put a STUN server on another port, that would not be of any help at all... because only part of the 100% can use the STUN discovered address in their RTP and such solution would not work 100%.
Which is the reason for it? do you mean those routers that "sometimes" behave as symmetric NAT router and other times not? Or perhaps you mean that even in a normal and correct router (not symmetric NAT) STUN would not work on 100% of cases?
Yes. Quoting the new rfc5389 that deprecated old STUN rfc3489:
"STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution."
So, what I meant is that STUN is not a global solution for RTP: as you know, if you open a hole in your NAT using STUN, you cannot be sure you can receive RTP through this hole. Also, the above new rfc, clearly states that it's impossible to predict a NAT behavior even if you have made some test and determined that it was a symmetric NAT for example.
However, the STUN *usage* (wording of ietf rfc5389) described in "draft-ietf-sip-outbound-16" is a global solution for SIP connection to "outbound" proxy.
Instead for RTP, ICE and TURN are required. That's just a different server that has to be installed: NOT THE SAME as the one running on the SIP server which is ONLY doing STUN binding request.
Well, AFAIK ICE is very far from being interoperable, isn't it?
You are right, but I do not think the draft is guilty there: the specification is very interoperable and there is no reason which should prevent application developper to implement it correctly.
I'm using an ICE version of draft-13 in my products and I'm not interoperable with anyone (never tested any in fact...) but the solution does work properly in closed environment. No doubt to me.
And TURN requires RTP through a media proxy, that is not a very scalable solution :(
ICE is a scalable solutions:
* SRV records do the balancing over several TURN server. * TURN is used ONLY when 2 peers cannot connect together, this means that it's much better than always offering RTP relay which is the solution today. * ICE allow to certify that you are sending the RTP data to your correspondant (ther is an ICE password in SDP) * ICE will allow 100% of direct connection and will never use TURN in a BEHAVE compliant environment: rfc4787. (no symmetric NAT any more...)
In the future, ICE is supposed to never use TURN at all because all direct connection will be possible. 0% relay is PLANNED by ietf and ICE ;)
Isn't it great news for the future? and peer to peer UDP exchange using a SIP network?
Thanks for your reply and thanks for your work :)
I thank you all for yours and wish the best for the next "sip router project"...
I also want to inform people that are not aware that a nice turnserver is available there:
http://turnserver.sourceforge.net/
That will surely help people to become compliant to ICE! I'm currently working with it for testing purpose and I will try to connect it to my kamailio sql database...
tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/