[asterisk-r2] Fwd: Delay - Outgoing calls

[Aleks Honma]

More info on this.

 Yesterday I managed to configure the SPANs separately on the use o
"mfcr2_advanced_protocol_file" with a tip given on another forum, so my
above information is incorrect.

 The only thing is that you have to state again the
"mfcr2_advanced_protocol_file" parameter and specify a different config
file as if you do not it will load the first file for all channels.

...
mfcr2_advanced_protocol_file=/etc/asterisk/span1_r2proto.conf
channel => 1-15,17-31

...
mfcr2_advanced_protocol_file=/etc/asterisk/span2_r2proto.conf
channel =>32-46,48-62

On Wed, Jun 1, 2016 at 3:27 PM, Aleks Honma <aleks.honma at gmail.com> wrote:

> Just to add one info to this case trying to funnel down the problem.
>
> Althought reluctant, today I got a telco's technician to come over to
> update Cisco 2900 IOS. After that they connect their testing equipment
> direct to the router's E1 interface and they made a test call from it. The
> result is that their test call was as fast as having our Legacy PBX
> connected to it. So I guess with that we rule out a possible router
> firmware version problem for MFCR2.
>
>
> On Sat, May 28, 2016 at 4:18 PM, Aleks Honma <aleks.honma at gmail.com>
> wrote:
>
>> Sure, how do I run the trace in openr2?
>>
>> I am sending attached
>> - extract from Asterisk "full" log file
>> - call file
>> - and Asterisk CLI output
>>
>> Here is an extract for the "full" log file showing an 8 second delay.
>>
>> [2016-05-28 15:50:18] DEBUG[6547][C-00000000] chan_dahdi.c: Chan 1 -
>> Sending category National Subscriber
>> [2016-05-28 15:50:23] DEBUG[6559] manager.c: Running action 'Login'
>> [2016-05-28 15:50:23] DEBUG[6559] manager.c: Running action 'Command'
>> [2016-05-28 15:50:23] DEBUG[6559] manager.c: Running action 'Command'
>> [2016-05-28 15:50:23] DEBUG[6559] manager.c: Running action 'Command'
>> [2016-05-28 15:50:24] DEBUG[5740] chan_sip.c: Auto destroying SIP dialog
>> '_q_cRCFvo58BQH0taqD0xw..'
>> [2016-05-28 15:50:24] DEBUG[5740] chan_sip.c: Destroying SIP dialog
>> _q_cRCFvo58BQH0taqD0xw..
>> [2016-05-28 15:50:26] DEBUG[6547][C-00000000] chan_dahdi.c: Enabled echo
>> cancellation on channel 1
>> [2016-05-28 15:50:26] VERBOSE[6547][C-00000000] chan_dahdi.c: MFC/R2 call
>> has been accepted on forward channel 1
>>
>> I thought that enabling the mf_g1_tones.no_more_dnis_available=F would
>> affect just group 0, channels 1-15,17-31 (from SPAN1, my E1 - Telco), but
>> it seems to be a global config to all channels affecting also group 1,
>> channels 32-46,48-62 (from SPAN2, legacy pbx).  The option worked great
>> when calling my SIP phone, but "killed" my legacy PBX returning "ERROR[914]
>> chan_dahdi.c: MFC/R2 protocol error on chan 56: Multi Frequency Cycle
>> Timeout". So I had to disable it. :-(
>>
>> On Fri, May 27, 2016 at 1:16 PM, Moises Silva <moises.silva at gmail.com>
>> wrote:
>>
>>> On Thu, May 26, 2016 at 1:39 PM, Aleks Honma <aleks.honma at gmail.com>
>>> wrote:
>>>
>>>> Moises you probably already know that, but man you rock!
>>>>
>>>> Timer is gone and I get connected 3s earlier, so from 8s in my test we
>>>> have gone done to 5s.
>>>>
>>>
>>> Good :)
>>>
>>>
>>>> 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.
>>>>
>>>> Is there any option to tweak this ?
>>>>
>>>
>>> It may be a similar issue. Can I see the Asterisk debug log for this? or
>>> the openr2 protocol trace?
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-r2 mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20160613/a07d700f/attachment.html>