<div dir="ltr">Moises you probably already know that, but man you rock!<div><br><div>Timer is gone and I get connected 3s earlier, so from 8s in my test we have gone done to 5s. </div><div><br></div><div>Now the issue seems that it is taking way too much time between sending out digits for ANI and DNIS. On my test above I was dialing just 5 digits (10315) that that is why it was taking 8s. For regular phone number where I dial 021ZZ XXXX-XXXX it takes about 15 seconds or more.</div><div><br></div><div>Is there any option to tweak this ?</div></div><div><br></div><div>Thanks again in advance for your time,</div><div>Aleks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 26, 2016 at 11:23 AM, Moises Silva <span dir="ltr"><<a href="mailto:moises.silva@gmail.com" target="_blank">moises.silva@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You can try setting this parameter in the advanced protocol file:<div><br></div><div>mf_g1_tones.no_more_dnis_available=F<br></div><div><br></div><div>This will force openr2 to send an F when there are no more DNIS available. The Brazilian variant by default is using the timeout mechanism, but your telco may accept the F. </div><div><br></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><p style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span>-</span></p><p style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span>Moy</span></p></div></div></div>
<br><div class="gmail_quote"><div><div class="h5">On Wed, May 25, 2016 at 7:34 AM, Aleks Honma <span dir="ltr"><<a href="mailto:aleks.honma@gmail.com" target="_blank">aleks.honma@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hello R2 Specialists,<div><br></div><div> I have been struggling for some time trying to find the source for the delay in initiating an OUTBOUND call.</div><div><br></div><div> The first question is what is a reasonable (normal) wait time between the last digit dialed and the first ring in Asterisk with an E1 setup for an outbound call?</div><div><br></div><div> My call takes beyond 8 seconds to connect. Just for ref. same link with old legacy Siemens PBX was almost instant.</div><div> </div><div><div>My setup:</div><div>- Country: Brazil</div><div>- Telco: Embratel</div><div>- Link type: E1 R2 (CAS)</div><div>- Freepbx 13, Asterisk 13.8.2</div><div><br></div><div>Implementation scenario:</div><div>Embratel E1 <-> Freepbx (Digium TE235 -2 span E1)</div></div><div><br></div><div> I "see" time counting at this stage below, here alone we have about 5 seconds of wait time.</div><div><br></div><div><div>[2016-05-20 13:06:01] DEBUG[22751][C-0000005b]: chan_dahdi.c:3892 dahdi_r2_write_log: Chan 23 - Sending DNIS digit 5</div><div>[2016-05-20 13:06:01] DEBUG[22751][C-0000005b]: chan_dahdi.c:3892 dahdi_r2_write_log: Chan 23 - Group A DNIS request handled</div><div>[2016-05-20 13:06:01] DEBUG[22751][C-0000005b]: chan_dahdi.c:3892 dahdi_r2_write_log: Chan 23 - No more DNIS. Doing nothing, waiting for timeout.</div><div>[2016-05-20 13:06:01] DEBUG[22751][C-0000005b]: chan_dahdi.c:3892 dahdi_r2_write_log: Chan 23 - Group A DNIS request handled</div><div>[2016-05-20 13:06:04] DEBUG[22751][C-0000005b]: chan_dahdi.c:3892 dahdi_r2_write_log: Chan 23 - Sending category National Subscriber</div><div>[2016-05-20 13:06:05] DEBUG[22751][C-0000005b]: chan_dahdi.c:4648 dahdi_ec_enable: Enabled echo cancellation on channel 23</div><div>MFC/R2 call has been accepted on forward channel 23</div><div>    -- DAHDI/23-1 is ringing</div><div>[2016-05-20 13:06:05] DEBUG[1968]: devicestate.c:474 do_state_change: Changing state for DAHDI/23 - state 6 (Ringing)</div><div>[2016-05-20 13:06:05] DEBUG[1968]: devicestate.c:474 do_state_change: Changing state for PJSIP/820 - state 2 (In use)</div></div><div><br></div><div> I understand that people usually have delays with broken dialplans, but in this case it seems that we have gone by all that pretty fast and the trouble as above is from the trunk forward.</div><div><br></div><div> Any one could share a tip for me to follow?</div><div><br></div><div>Many thanks in advance,</div><div>Aleks Honma</div></div>
</div><br></div>
<br></div></div><span class="HOEnZb"><font color="#888888">--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-r2 mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-r2" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br></font></span></blockquote></div><br></div></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-r2 mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-r2" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br></blockquote></div><br></div>