On Mon, Apr 28, 2008 at 4:41 PM, Tilghman Lesher <<a href="mailto:tilghman@mail.jeffandtilghman.com">tilghman@mail.jeffandtilghman.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Monday 28 April 2008 14:41, Andreas Brodmann wrote:<br>
> One thing I am not sure about - would your patch also cover the following<br>
> scenario<br>
> for international numbers with unknown length?<br>
><br>
> exten => _000!,1,Incomplete<br>
> exten => _000!,n,Dial(SIP/${EXTEN:1}@carrier,120)<br>
<br>
</div>That will never work. Calling the Incomplete application means that the<br>
dialplan will wait for more digits (and so the dialplan will restart). You<br>
need a more exact extension in the same context (or else the Incomplete app<br>
needs to go into an included context).</blockquote><div><br>May be I'm missing something basic and someone can help clarify it for me. I've dealt with this with Cisco Call Manager 6.X and Cisco 7960 phones that support KPML (KeyPad Markup Language; a dialplan language expressed in XML) that support this feature. The part that escapes me is that why do we need Asterisk dial-plan to be stateful across INVITE/484 pairs if both the SIP phone and the SIP trunk understand the 484 semantics. <br>
<br>Why can't we treat 484 received on the SIP trunk as a failed call and propagate that specific response code to the phone and eliminate that state from the Asterisk dial-plan? Remember that the phone sends the previous digits in the new INVITEs after receiving 484s so that the To: or R-URI eventually satisfies the SIP trunk provider's routing plan.<br>
<br>But like I said, I may be missing something basic. What would that be?<br><br></div></div>-- <br>Raj Jain<br><br>mailto:<a href="mailto:rj2807">rj2807</a> at gmail dot com<br>sip:rjain at iptel dot org