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

[Ezequiel Quadri]

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/01a96a22/attachment.html>