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

[Mc GRATH Ricardo]

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/20180412/3c13e4ac/attachment-0001.html>