[asterisk-dev] [Code Review]: Add a SIP nat=auto setting

Kevin Fleming reviewboard at asterisk.org
Fri Jan 27 11:31:25 CST 2012 


> On Jan. 27, 2012, 9:53 a.m., Kevin Fleming wrote:
> > I don't think that this patch as written is adequate; it turns on *both* force_rport and comedia when NAT is detected, and there could definitely be situations where that results in broken calls. If we're going to provide an 'auto' mode, we should also provide 'force_rport_auto' and 'comedia_auto', so that those can be individually automatically enabled in cases where the UA (or mid-path network element) in use doesn't work with both of them enabled.
> > 
> > However, I think there is a potentially larger problem here: whether 'force_rport' and/or 'comedia' will work properly for any given path that the remote UA is using is dependent on *both* the UA's behavior and the behavior of the network elements (NATs, SBCs, proxies, etc.) in between that UA and Asterisk. To go back to the reporter's statements in JIRA... what if the 3G operator's edge device (presumably an SBC) doesn't hide itself (so Asterisk detects that NAT is in use) but still doesn't support symmetric RTP (comedia)? The risk here is that users will just expect 'auto' mode to make everything work smoothly all the time, and that won't always be the case. To some extent, the current situation of requiring the Asterisk admin to take some sort of action (learning what is required for that configuration) is potentially better, because the admin will have to learn how to deal with these network complexities. Having an 'automatic' mode leads to users believing that they don't need to understand or care about these topics, and then we have to help them later when their calls "don't work".
> 
> Terry Wilson wrote:
>     > it turns on *both* force_rport and comedia when NAT is detected, and there could definitely be situations where that results in broken calls.
>     
>     Yes. This is a feature for nat=auto, so whether to set nat=yes or nat=no automatically--it isn't a way to magically figure out what crazy set of circumstances might possibly be in play between the endpoint and Asterisk (something that is pretty much impossible to determine without some more help from the client). In my opinion, this is a documentation issue. It should be thoroughly documented that this will just pick between those two options.
>     
>     The nat settings aren't bitfields/combinable, so we would end up with auto_force_rport, auto_comedia, and auto_everystuff for, what I would imagine to be a vanishingly small percentage of users who would use them. Searching with google, I get the impression that the vast majority of people use nat=yes and the greatest minority uses nat=no. If the idea is to create a type that just "tries to do the right thing" for clients that move between many different networks, I don't see how adding the more specialized options help. You still aren't going to be able to support networks that look natted and require comedia and ones that look natted and don't support comedia at the same time. The only way I can think of it being used is if a client moves *only* between some very specific networks (always stays at the same hotel?), with very specific requirements for each.
>     
>     We've made it a decade without anyone submitting this patch. I bet that if we accepted it, it would be another decade before anyone said "What I really need is the ability to move between only these two very specific networks."
>     
>     As far as users being confused that automatic doesn't work, well, users are confused when the default (whatever it may be) doesn't work. This patch makes things work for situations that wouldn't have worked without it. If it doesn't work for a situation, users still have to learn how things work just like they do now--this is no change from how things currently are. But, things also might "just work" for a larger number of cases. And that is a win for everybody, IMHO.

Well, I didn't express my point clearly. The need for 'nat=auto' was probably driven mostly by the fact that the default setting for 'nat' *used to be* 'no'. Now that the default in all widely-deployed and supported branches is no longer 'no', the percentage of systems that will 'just work' out of the box will increase, because for the overwhelming majority of endpoints, having 'nat' mode enabled is not harmful, even when it is not necessary.

Unless I am misunderstanding what this patch does, here is the gist of it: if we receive an out-of-dialog (or dialog-forming) request with an address/port in the top-most Via header (an address, not a domain name... as the Cisco docs that Simon linked to say, you can't do 'auto' mode if the Via header doesn't have an IP address) that does not match the address/port we received the request from, then we turn on force_rport and comedia. If the request included 'rport', then enabling force_rport has no effect. If the device would have worked with force_rport enabled in the first place, then enabling it later has no effect. If the device (and the network elements in the path) will work with comedia mode on, then enabling it later has no effect. If the device (or the network elements in the path) won't work with force_rport or comedia enabled (or both), then enabling either of them will break the communication.

So, what this patch does is allow Asterisk to support a group of endpoints that would not work with force_rport enabled when they are not behind a NAT but will work with it enabled when they are behind a NAT. In addition, these devices must also support comedia mode when located behind a NAT. To date, the only devices that we know of that do not work with force_rport enabled *also* don't benefit from it being enabled when they are behind a NAT (because the only NAT that they work behind has a SIP ALG that accommodates their unusual requirements), and they don't benefit from comedia mode being enabled either when they are behind a NAT (because said NAT handles that via its SIP ALG as well).

If there is *any* risk of regression, confusion or other problems caused by this patch being merged, then I'm unsure we should proceed with doing so. I just can't see that there is really any substantial demonstrated advantage to having it in place, that we haven't already achieved by making 'force_rport' the default. It's probably time to take this thread directly to asterisk-dev to get some additional feedback.


- Kevin


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


On Jan. 26, 2012, 8:28 p.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1698/
> -----------------------------------------------------------
> 
> (Updated Jan. 26, 2012, 8:28 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> First, this patch as originally posted is from JIRA user pedro-garcia. It has been in JIRA for a long while, and has finally come up to be considered. There were some changes that I wanted to made to the original patch, so I tried contacting the author to get them to put the patch on reviewboard, but after a week I got no response. So, I'm putting the original patch up, then will immediately add a review with my changes. Many thanks to pedro-garcia for his contribution.
> 
> From the JIRA issue:
> 
> I have some devices in the following scenario:
> 
> Asterisk server with public IP address
> Mobile devices (clients):
> 
> When in internal network, no NAT between the client and the server
> When in "roaming" (i.e. a Hotel with WiFi), the client is behing a NAT
> When in 3G, operator transparent sip proxy so it looks as no NAT, but does not support symmetric RTP.
> Sometime, the device gets a public IP with no NAT at all.
> No NAT setting available in asterisk works for all these scenarios at the same time, and I can not request the user to activate different accounts depending on its location.
> 
> I have added a new NAT setting (nat=auto) to the current ones. When set, chan_sip auto detects from the Via header, the recv sockaddr, and the rport setting if the client is behind a NAT.
> 
> It also adds to cli interface results (sip show peer/s) info on this (so now you could see "N" for NAT and nothing for no NAT as before, "a" for auto detect no NAT, and "A" for autodetect NAT.
> 
> 
> This addresses bug ASTERISK-17860.
>     https://issues.asterisk.org/jira/browse/ASTERISK-17860
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 352610 
>   /trunk/channels/sip/include/sip.h 352610 
>   /trunk/configs/sip.conf.sample 352610 
> 
> Diff: https://reviewboard.asterisk.org/r/1698/diff
> 
> 
> Testing
> -------
> 
> Lots of reloads with changing values, and registry natted and un-natted phones. I also set the nat_supertest in testsuite to run with nat=auto to make sure that it responded the same with existing and non-existing peers.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120127/1531e052/attachment-0001.htm>

More information about the asterisk-dev mailing list