<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/1416/">https://reviewboard.asterisk.org/r/1416/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On September 6th, 2011, 12:42 p.m., <b>Olle E Johansson</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;">Please confirm that the "allowoverlap=yes|no" setting still works as expected. Thanks.</pre>
</blockquote>
<p>On September 6th, 2011, 1:01 p.m., <b>mjordan</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;">This change doesn't really affect the allowoverlap setting. This change affects those situations where a match is made in the Asterisk dialplan to a valid extension, and either (a) the dialplan itself marks the extension as being Incomplete, or (b) the device dialed from the extension is SIP and returns a 484. The allowoverlap setting only applies when an extension cannot be matched exactly in the Asterisk dialplan, but a potential match could be made. If a potential match could be made, then if allowoverlap is true, a 484 response is returned; otherwise a 404 response is returned.
This does mean however that you could set allowoverlap to false, dial an Asterisk dialplan extension that matches exactly, which calls the Dial application to an external SIP device with an incomplete extension, and have that external device return SIP 484. This would forward back to the originating device a SIP 484 - but that actually isn't much different then what would happen previously (where we would sit idle for several seconds, and eventually tell them they had a protocol error). If that's a problem, we can discuss whether or not Asterisk should manipulate the return code in that situation.
</pre>
</blockquote>
<p>On September 6th, 2011, 1:09 p.m., <b>Olle E Johansson</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 personally don't think we should ever respond with 484 if the incoming device as allowoverlap=no.</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;">I discussed this with some others and they tend to agree. This is a weird edge case (where you'd disallow overlapped dialing, but then put Incomplete into your dialplan), but I'll put in a check for the allowoverlap flag where we would otherwise send back a 484 and, if set to false, will send 404 instead.</pre>
<br />
<p>- mjordan</p>
<br />
<p>On September 6th, 2011, 12:32 p.m., mjordan 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, David Vossel and rmudgett.</div>
<div>By mjordan.</div>
<p style="color: grey;"><i>Updated Sept. 6, 2011, 12:32 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;">ASTERISK-17288 was filed against chan_sip. When a response code of "484 Address Incomplete" was received by the dialplan, the channel was being hung up with a hangup cause of 111, as opposed to the RFC recommended 28. Upon resolving this, the previously implemented logic for Incomplete extension dialing was triggered (implemented under ASTERISK-11768). For SIP phones, this had a somewhat unexpected result: upon receiving the 484 response back from the dialed device, the dialplan would send no information back to the device that dialed the numbers, and, after a period of time, would timeout (transferring to either the 't' or 'i' extension, depending on the dialplan).
While this was the intended effect of the pbx Incomplete logic, it was not desired by the issue reporter. What's more, for SIP phones, since no information was being forwarded back to the dialing device that the number that they dialed was incomplete, the device did not know to dial more numbers.
After discussion on asterisk-dev with Kevin and the issue reporter, the following decisions were made:
1. app_dial by default should not attempt to place a call into Incomplete - functionality should be triggered by explicit dialplan usage
2. Incomplete application should notify channels that they are in Incomplete status using a control frame. That allows channel tech to automatically hangup if no more digits are possible.
A new control frame AST_CONTROL_INCOMPLETE was added and is sent to the channel in the Incomplete application. Otherwise, the Incomplete application logic was left unchanged.
Handling the control frame differs on the channel technology. With respect to SIP, an Incomplete implies immediately sending the 484 Address Incomplete response to the dialing device and performing a soft hangup, as a new INVITE sequence is required. If the device wants to retry, then the device will resend the URI with whatever appended digits it determines is needed to try for the next extension.
For other channel technologies, it depends on their implementation and their support for overlapped dialing. DAHDI (and sig_pri) and mISDN have support for overlapped dialing - for those cases, receiving an AST_CONTROL_INCOMPLETE means either doing nothing if overlapped dialing is supported (and if the channel is in a state that it can receive additional digits), or hanging up if overlapped dialing is not supported. In the case of a hangup, the approach was taken to emulate AST_CONTROL_CONGESTION.
For channels that do not support overlapped dialing, they treat a control frame of AST_CONTROL_INCOMPLETE as if it were AST_CONTROL_CONGESTION.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </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;">Two new Asterisk test suites were written to test the behavior for SIP (review on https://reviewboard.asterisk.org/r/1417/ ). These two tests check that Asterisk handles the SIP 484 Address Incomplete both when the response is returned and the Incomplete application is not used, and when the Incomplete application is used.
Additional testing will be needed for other channel types. DAHDI will be tested in conjunction with this review; other channels whose support are extended will require testing by the Asterisk community.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-17288">ASTERISK-17288</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/team/mjordan/AST_17288/1.8/apps/app_dial.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_alsa.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_console.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_dahdi.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_h323.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_mgcp.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_misdn.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_oss.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_sip.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_skinny.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_unistim.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/chan_usbradio.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/sig_pri.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/channels/sig_ss7.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/funcs/func_frame_trace.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/include/asterisk/frame.h <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/main/channel.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/main/dial.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/main/features.c <span style="color: grey">(334565)</span></li>
<li>/team/mjordan/AST_17288/1.8/main/pbx.c <span style="color: grey">(334565)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1416/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>