<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1698/">https://reviewboard.asterisk.org/r/1698/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On January 27th, 2012, 9:53 a.m., <b>Kevin Fleming</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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".</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> 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.</pre>
<br />
<p>- Terry</p>
<br />
<p>On January 26th, 2012, 8:28 p.m., Terry Wilson wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By Terry Wilson.</div>
<p style="color: grey;"><i>Updated Jan. 26, 2012, 8:28 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.