<br><br><div class="gmail_quote">On Fri, Jul 10, 2009 at 11:40 AM, Dave Fullerton <span dir="ltr"><<a href="mailto:dfullertasterisk@shorelinecontainer.com">dfullertasterisk@shorelinecontainer.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">Steve Totaro wrote:<br>
> On Fri, Jul 10, 2009 at 10:45 AM, Dave Fullerton <<br>
> <a href="mailto:dfullertasterisk@shorelinecontainer.com">dfullertasterisk@shorelinecontainer.com</a>> wrote:<br>
><br>
>> Tzafrir Cohen wrote:<br>
>>> On Thu, Jul 09, 2009 at 05:31:18PM -0400, Steve Totaro wrote:<br>
>>><br>
>>> You have a small typo:<br>
>>><br>
>>>> exten => _.,1,Dial(Zap,g1,${EXTEN})<br>
>>>> exten => _.,2,Dial(SIP,Provider,${EXTEN})<br>
>>> exten => _.,1,Dial(Zap/g1/${EXTEN})<br>
>>> exten => _.,2,Dial(SIP/Provider/${EXTEN})<br>
>>><br>
>>> ('/' instead of ',')<br>
>>><br>
>> While this will work, be aware that there are circumstances where you<br>
>> may end up calling the number twice, once through each provider. One<br>
>> example is if the number you dial is busy, that progress will be passed<br>
>> via the PRI to asterisk and the dialplan will continue to the next<br>
>> priority. In this case, dialing the number again through the SIP<br>
>> provider. To avoid this you will need to use some dialplan logic and<br>
>> check the result of the DIALSTATUS variable. See this page for examples:<br>
>><br>
>> <a href="http://www.voip-info.org/wiki/view/Asterisk+variable+DIALSTATUS" target="_blank">http://www.voip-info.org/wiki/view/Asterisk+variable+DIALSTATUS</a><br>
>><br>
>> -Dave<br>
>><br>
>><br>
> Good point.<br>
><br>
> I was unaware that "busy" back from a TDM circuit would progress in the<br>
> dialplan rather than going to the h exten.<br>
><br>
> What other cases are there like that?<br>
<br>
</div></div>It is my understanding (through trial and error, reading, etc) that any<br>
Dial command that does not result in an answered state will continue in<br>
the dialplan after a timeout (if specified) or some sort of progress is<br>
received. If the called channel results in an answer then dialplan<br>
processing stops as soon as one party hangs up (unless the g option is<br>
specified).<br>
<br>
This works on any channels that can pass progress (SIP/IAX and Zap/DAHDI<br>
PRI and BRI). Zap/DAHDI Analog channels are considered answered as soon<br>
as the dial is complete so you won't be able to use this trick under<br>
normal circumstances.<br>
<div><div></div><div class="h5"><br>
-Dave<br>
<br>
</div></div></blockquote></div><br>True I guess except that if the call fails as the OP posted, because the PRI is down, it should work then right?<br><br>Another thing. For outbound calls, I do not have a timeout. So the user hangs up when they are ready, or when the other side hangs up or gets congestion, which amounts to the h exten, or am I not correct.<br>
<br>Why have a timeout on outbound dialing (unless you are a dialer app?) It is not like voicemail where you want it to ring for so many seconds and then roll to VM.<br clear="all"><br>-- <br>Thanks,<br>Steve Totaro <br>
+18887771888 (Toll Free)<br>+12409381212 (Cell)<br>+12024369784 (Skype)<br>