Solve crimes near you

Start the path





=============================================================================================================================== 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 < simo ... @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 -- _____________________________________________________________________ -- 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