[asterisk-dev] STUN support in chan_sip revisited

[Philippe Sultan]

Hi guys,

While working on implementing XMPP Jingle in Asterisk, I had to write
the basis of STUN as defined in RFC 5389.

Jingle uses ICE (and therefore STUN as per RFC 5389), which introduces
message integrity checks for STUN messages using credentials exchanged
at the signalling phase.

The changes in the STUN code are mostly an update to the STUN
attributes as defined in RFC 5389. As for other RTP based media
channels (eg. SIP), the only change is the introduction of the
following structure in the ast_rtp_instance_read interface function :

struct stun_credentials {
        char local_ufrag[AST_STUN_MAXLEN];
        char remote_ufrag[AST_STUN_MAXLEN];
        char local_password[AST_STUN_MAXLEN];
        char remote_password[AST_STUN_MAXLEN];
        unsigned long priority;
        int initiator;
};

I just resynchronized the code branch with the trunk :
http://svn.digium.com/svn/asterisk/team/phsultan/jingle-support

The corresponding bug report :
https://issues.asterisk.org/view.php?id=15634

This code works with other Jingle implementations that use the same
ICE mechanism (Empathy, PSI and Pidgin tested) in a scenario where
Asterisk runs on a public IP address and serves NAT (or not) Jingle
clients. It is limited by the fact that we let the clients choose
their best ICE candidate, as we don't make any decision on our own.

Even though it's not a complete RFC 5389 implementation, I believe
this code might help us moving forward. I'm leaving for a week of
vacations, I'll update the (old) review board request when I come back
: https://reviewboard.asterisk.org/r/401

Philippe

On Fri, Aug 6, 2010 at 5:09 PM, Simon Perreault
<simon.perreault at viagenie.ca> wrote:
> On 2010-08-06 10:54, Klaus Darilion wrote:
>> having Asterisk saying "this is a symmetric NAT, VoIP
>> will not work" is IMO a useful option to help users with NAT traversal.
>
> Even though VoIP might very well work?
>
>>> The better approach is to be agnostic to the type of NAT. Just try to
>>> traverse it using all possible ways, and see what works. Dynamically
>>> pick the best alternative.
>>
>> Pick the best alternative based on what?
>
> Based on trying them all. That's the idea behind ICE. You tell your
> peer: "I have these adddresses assigned to me, and I obtained this
> address from STUN, and I allocated this address on a TURN relay, and I
> opened these ports using UPnP/NAT-PMP, and I have this address on a VPN,
> etc. Try them all, I'll tell you when I hear from you on one of them."
>
>>> Note also that keep-alive can be done with pure SIP. This has the
>>> advantage that the peer doesn't need to support STUN. See RFC 5626
>>> section 3.5.1.
>>
>> Of course, yes. But using STUN would also detect changes of the public IP.
>
> It cannot change while it is being kept alive. Once a NAT binding is
> opened, the 5-tuple is fixed. Unless the NAT device reboots, in which
> case we're screwed anyway.
>
>> What is the standard STUN usage that works? RFC 5626? How long will it
>> take until all SIP proxies/registrars deployed will be updated to
>> support RFC 5626?
>
> Yes, SIP-outbound and ICE. The deployment time is irrelevant. When
> you're talking to a peer that supports it, you use it. Otherwise, you
> don't. You just cannot start using STUN in a broken way and expect
> everything to be rosy. It's going to help in some circumstances, but
> it's going to be really broken in others. And you'll be trying to
> outsmart the server, which is not a good thing to do.
>
>>> Working with servers that do not support SIP-outbound and/or ICE is
>>> simple: don't do anything. It is up to these servers to do their thing
>>> (i.e. latching). If they don't do any of that, then they can't
>>> reasonably expect to work with clients behind NATs.
>>
>> Is this the IETF approach? Non-RFC5626 compatible servers are
>> responsible for NAT traversal?
>
> Of course not!
>
>> That would be great - then we could drop "old style" STUN from all
>> clients immediately.
>
> I repeat, what I being described here is not "old style STUN". It is
> Asterisk-specific. Clients generally do not take the results from STUN
> and stick them in SIP headers.
>
> My point is that Asterisk should not do non-standard STUN.
>
> Simon
> --
> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
> STUN/TURN server        --> http://numb.viagenie.ca
> vCard 4.0               --> http://www.vcarddav.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
Philippe Sultan