On Sat, 3 Jan 2009, Iñaki Baz Castillo wrote:
2009/1/3 Aymeric Moizard <[email protected]>:
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/
--
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Users mailing list
[email protected]
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
