[asterisk-r2] FW: Incoming calls hangs randomly prior R2 exchange

Tue Apr 17 06:51:28 CDT 2018

Hi Ezequiel.
It looks very strange, how about to check other components as hardware issues, irq, process, system latency, and whatever, or OS.
Best regards.

Mc GRATH Ricardo

________________________________
From: asterisk-r2-bounces at lists.digium.com [asterisk-r2-bounces at lists.digium.com] On Behalf Of Ezequiel Quadri [ezequiel_quadri at hotmail.com]
Sent: 12 April 2018 17:17
To: asterisk-r2 at lists.digium.com
Subject: Re: [asterisk-r2] Incoming calls hangs randomly prior R2 exchange

Hi Ricardo , thanks for your answer,

This happens randomly but very often, about 6 calls of 10 fail, and the server is only for tests so it has no load. We have already tested with the persistence timer and it did not have any effect since it has nothing to do with the problem, remember that asterisk is the receiver of calls in this case.

Here is the trace of PA41 where a delay of 933ms is seen in the shipment of the SEIZE ACK from asterisk:

Regards, Ezequiel
________________________________
De: asterisk-r2-bounces at lists.digium.com <asterisk-r2-bounces at lists.digium.com> en nombre de Mc GRATH Ricardo <mcgrathr at mail2web.com>
Enviado: jueves, 12 de abril de 2018 01:42 p.m.
Para: asterisk-r2 at lists.digium.com
Asunto: Re: [asterisk-r2] Incoming calls hangs randomly prior R2 exchange

Hi Ezequiel.
Thanks, strange wide delayed timing, it happens all time?? how about Asterisk traffic information, as core show calls or channels? by the way do you have trace log of PA-41??
How about to set persistent timer?, I think  S-Ack it will send to PSTN always in a unique timing, according to parameter value (according to Telco spec. expecting to 200 ms).
Best regards.

Mc GRATH Ricardo

________________________________
From: asterisk-r2-bounces at lists.digium.com [asterisk-r2-bounces at lists.digium.com] On Behalf Of Ezequiel Quadri [ezequiel_quadri at hotmail.com]
Sent: 12 April 2018 12:05
To: asterisk-r2 at lists.digium.com
Subject: Re: [asterisk-r2] Incoming calls hangs randomly prior R2 exchange

Hi Moises, group,

Last night we were able to make some captures with the analyzer W & G PA-41 and we discovered the cause of the problem. The issue is that our asterisk sends the SEIZE ACK with a delay that varies between 30ms and 900ms, and the PBX waits for it before 200ms, therefore when it is sent before 200ms the call is established, and when it is late the PBX sends CLEAR FWD and releases the call. The question is why openr2 can erratically delay sending of the SEIZE ACK.

Thanks in advance..

Regards, Ezequiel

________________________________
De: Ezequiel Quadri <ezequiel_quadri at hotmail.com>
Enviado: viernes, 16 de marzo de 2018 04:19 p.m.
Para: asterisk-r2 at lists.digium.com
Asunto: Re: [asterisk-r2] Incoming calls hangs randomly prior R2 exchange

Hi Moises, thanks for your answer,

The issue is that with another PBX the calls have no problem, all are handled correctly, therefore the provider argues that a problem is the new PBX.
However, I have already tried with the persistence check, and the release signal really persists for about 160ms.

Regards, Ezequiel

________________________________
De: asterisk-r2-bounces at lists.digium.com <asterisk-r2-bounces at lists.digium.com> en nombre de Moises Silva <moises.silva at gmail.com>
Enviado: viernes, 16 de marzo de 2018 10:56 a.m.
Para: asterisk-r2 at lists.digium.com
Asunto: Re: [asterisk-r2] Incoming calls hangs randomly prior R2 exchange

On Thu, Mar 15, 2018 at 3:40 PM, Ezequiel Quadri <ezequiel_quadri at hotmail.com<mailto:ezequiel_quadri at hotmail.com>> wrote:

OpenR2 call files:

[12:22:03:236] [Thread: 140405976749824] [Chan 4] - Call started at Tue Mar 13 12:22:03 2018 on chan 4 [openr2 version 1.3.3, revision (release)]
[12:22:03:236] [Thread: 140405976749824] [Chan 4] - Initialized R2 MF detector
[12:22:03:236] [Thread: 140405976749824] [Chan 4] - CAS Tx >> [SEIZE ACK] 0x0C
[12:22:03:236] [Thread: 140405976749824] [Chan 4] - CAS Raw Tx >> 0x0D
[12:22:03:277] [Thread: 140405976749824] [Chan 4] - Bits changed from 0x00 to 0x08
[12:22:03:277] [Thread: 140405976749824] [Chan 4] - CAS Rx << [CLEAR FORWARD] 0x08
[12:22:03:277] [Thread: 140405976749824] [Chan 4] - Far end disconnected. Reason: Normal Clearing
[12:22:03:277] [Thread: 140405976749824] [Chan 4] - Call ended
[12:22:03:277] [Thread: 140405976749824] [Chan 4] - Attempting to cancel timer timer 0
[12:22:03:277] [Thread: 140405976749824] [Chan 4] - Cannot cancel timer 0

[12:22:03:236] [Thread: 140405976241920] [Chan 5] - Call started at Tue Mar 13 12:22:03 2018 on chan 5 [openr2 version 1.3.3, revision (release)]
[12:22:03:236] [Thread: 140405976241920] [Chan 5] - Initialized R2 MF detector
[12:22:03:236] [Thread: 140405976241920] [Chan 5] - CAS Tx >> [SEIZE ACK] 0x0C
[12:22:03:236] [Thread: 140405976241920] [Chan 5] - CAS Raw Tx >> 0x0D
[12:22:03:277] [Thread: 140405976241920] [Chan 5] - Bits changed from 0x00 to 0x08
[12:22:03:277] [Thread: 140405976241920] [Chan 5] - CAS Rx << [CLEAR FORWARD] 0x08
[12:22:03:277] [Thread: 140405976241920] [Chan 5] - Far end disconnected. Reason: Normal Clearing
[12:22:03:277] [Thread: 140405976241920] [Chan 5] - Call ended
[12:22:03:277] [Thread: 140405976241920] [Chan 5] - Attempting to cancel timer timer 0
[12:22:03:277] [Thread: 140405976241920] [Chan 5] - Cannot cancel timer 0

I think you should try contacting your telco as this seems like an issue upstream. Having said that, you may try to fix it by using 'timers.cas_persistence_check=100' in the advanced protocol file (r2proto.conf). This helps clearing 'false positives' with CAS signals that are short-lived (e.g less than 100ms).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20180417/ec5ea61b/attachment.html>