[asterisk-dev] [Code Review]: Lightweight NAT Support

Kevin Fleming reviewboard at asterisk.org
Tue Feb 21 10:14:31 CST 2012



> On Feb. 21, 2012, 8:35 a.m., Simon Perreault wrote:
> > I have two questions...
> > 
> > 
> > 1. CRLF keep-alives are supported only for connection-oriented transports. Not UDP. Excerpt from RFC 5626:
> > 
> > 4.4.1. Keep-Alive with CRLF
> > 
> >    This approach MUST only be used with connection oriented transports
> >    such as TCP or SCTP; it MUST NOT be used with connection-less
> >    transports such as UDP.
> > 
> > This is because of RFC 3261 section 7.5. Excerpt:
> > 
> >    Implementations processing SIP messages over stream-oriented
> >    transports MUST ignore any CRLF appearing before the start-line
> >    [H4.1].
> > 
> > A CRLF transported over UDP is just plain wrong. It is not valid SIP.
> > 
> > So, question: did I miss something? Did I not understand what you're sending over UDP?
> > 
> > 
> > 2. If Asterisk is talking over TCP or TLS to a UA that supports RFC 5626, that UA would echo the CRLF back to Asterisk. Is Asterisk prepared to handle that?
> 
> Joshua Colp wrote:
>     1. I was under the impression that this was also for UDP, at least that is what the discussion I was in on led to. Unfortunately I wasn't at the Asterisk dev cons so I don't know what was discussed there about it. I can say though that other clients do use CRLFs for this purpose, even on UDP transports.
>     
>     2. Yes. We will accept CRLF over any transport, that was done long long ago.
>
> 
> Simon Perreault wrote:
>     RFC 5626 defines lightweight keep-alives for UDP using STUN multiplexed on the SIP port. The problem is that this can only be used with UAs implementing RFC 5626.
>     
>     There is also RFC 6223 which somehow decouples the keep-alive mechanism from the rest of RFC 5626. Basically it looks like you could signal support for STUN keep-alives and start using that with UAs that also advertise support for RFC 6223. It looks very easy to implement: a new Via header flag for the signaling, and STUN Binding requests for the keep-alives.

While it's certainly true that the mechanism being implemented here is not necessarily RFC compliant, it is being implemented here for Asterisk because it already exists in many UAs that are widely deployed, and there's very little cost to implementing it (and certainly very low risk of regression or interoperability issues).


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1756/#review5565
-----------------------------------------------------------


On Feb. 21, 2012, 7:26 a.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1756/
> -----------------------------------------------------------
> 
> (Updated Feb. 21, 2012, 7:26 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch implements extremely lightweight NAT support, specifically sending a CRLF at a defined interval to keep the NAT mapping open. It does not use this mechanism to determine if the remote server is available or not, that is the trade off.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 355996 
>   /trunk/channels/sip/include/sip.h 355996 
>   /trunk/configs/sip.conf.sample 355996 
> 
> Diff: https://reviewboard.asterisk.org/r/1756/diff
> 
> 
> Testing
> -------
> 
> Confirmed packet is sent at default interval as well as configured interval. Also wrote testsuite test which will be in another review.
> 
> 
> Thanks,
> 
> Joshua
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120221/45f81213/attachment.htm>


More information about the asterisk-dev mailing list