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

[Ezequiel Quadri]

Another possibility is that the seize ack transmited from OpenR2 is not detected by the other end and it ends the call, because whenever it fails, the release comes exactly 41ms after the seize ack has been sent in all cases. Can you think of something to change about this?

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/20180316/05a2540f/attachment-0001.html>