[Kamailio-Users] stun/outbound draft...

[Aymeric Moizard]

On Sat, 3 Jan 2009, Iñaki Baz Castillo wrote:

>> 2009/1/3 Aymeric Moizard <jack at 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/




-- 
Iñaki Baz Castillo
<ibc at aliax.net>
_______________________________________________
Users mailing list
Users at lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users