[asterisk-r2] Failed calls CANTV updated again
Gerardo Barajas
gerardo.barajas at gmail.com
Mon Feb 25 00:48:29 CST 2013
Una vez resolví algo similar configurando canal por canal en Elastix y
chan_dahdi.
En lugar de agruparlas todas asi:
channel => 1-15
fue así
channel =>1
channel =>2
channel =>3
etc
Y en el dialplan (en este caso en las rutas de salida de Elastix y en las
troncales) puse una por una.
Es una solución poco elegante, pero así dejo de sucederme lo que a ti te
pasa.
Saludos/Regards
--
Ing. Gerardo Barajas Puente
On Mon, Feb 25, 2013 at 12:03 AM, Rafael Angulo
<rafael.angulo at tarma.com.ve>wrote:
> Saludos a todos los amigos de la lista, he seguido trabajando sobre el
> problema aleatorio que ocurre en los canales salientes del E1 de cantv,
> abajo en el correo esta el planteamiento original del problema, pero en
> resumen, de forma aleatoria en canales aleatorios, el log de llamadas
> muestra esto (extracto):
>
> Bits changed from 0x0C to 0x08
> [Chan 17] - CAS Rx << [0x08] 0x08
> [Chan 17] - Protocol error. Reason = Invalid CAS, R2 State = Seize ACK
> Received, MF state = MF Engine Off, MF Group = Forward DTMF init, CAS DNIS
> = 4092442, ANI = 2748100, MF = 0x20
> Posterior a esto le indica al llamante que todas las lineas están ocupadas
> sin intentar con otro canal. Por lo que el llamante debe colgar e intentar
> de nuevo
> Por un tiempo el log estaba lleno de estos errores solo cuando el numero
> discado era Movistar (otra operadora Venezolana el patron es 0414XXXXXXX o
> 0424XXXXXXX), pero han ido apareciendo otros números. El técnico de CANTV
> coloco un analizador de protocolos y su conclusión es que aleatoriamente la
> central no esta enviando los tonos DTMF (la señalización saliente es DTMF)
> con los números discados (efectivamente no se oyen en el analizador de
> protocolos). A nivel de señalización esto es lo que aparentemente ocurre:
>
> IPBX CANTV
> 1001 ------------------------------------ 1001 (Idle)
> 0001 ------------------------------------ 1001
> 0001 ------------------------------------ 1101 (Inicio de llamada
> y envío de tono de invitación a marcar por parte de CANTV) (Seize) y (Seize
> ACK)
> cierto tiempo
> 0001 ------------------------------------ 1001
> 0001 ------------------------------------ 1101
> y nada mas pasa, sigue en este ciclo, a veces el canal se bloquea a veces
> vuelve a IDLE.
>
> La tarjeta es una Sangoma A102D y ya le actualice el firmware a la ultima
> versión. Alguien tendrá alguna pista de que puede estar pasando? Alguien
> sabrá como puedo evitar que Asterisk indique que todas las
> lineas están ocupadas e intente por otro canal hasta que tenga éxito?
>
> Mil gracias de antemano,
>
> Rafa
>
>
>
>
> On Mon, Feb 4, 2013 at 12:10 PM, Rafael Angulo <rafael.angulo at tarma.com.ve
> > wrote:
>
>> Hola a todos!,
>>
>> Abajo en el correo esta el planteamiento original del problema. Logre
>> determinar que el problema no esta relacionado con ocupación de las lineas,
>> ocurre aun cuando hay lineas disponibles. Y lo problemático es que Asterisk
>> no trata con el siguiente canal disponible después del error sino
>> que envía el mensaje de "todas las lineas están ocupadas" de vuelta al
>> llamante. El problema ocurre aleatorio y por cualquier canal .Por favor si
>> alguien tiene alguna pista sobre la solución, sugerencias de que probar,
>> donde investigar o que leer, mucho lo sabría agradecer. adjunto el archivo
>> de debug de openr2 para una llamada fallida y la configuración del
>> chan-dahdi.conf.
>>
>> [Chan 17] - Call started at Mon Dec 10 08:54:38 2012 on chan 17 [openr2
>> version 1.3.1, revision exported]
>> [Chan 17] - Outgoing call proceeding: ANI=2748100, DNIS=4092442,
>> Category=National Subscriber
>> [Chan 17] - CAS Tx >> [SEIZE] 0x00
>> [Chan 17] - CAS Raw Tx >> 0x01
>> [Chan 17] - scheduled timer id 2 (r2_seize)
>> [Chan 17] - Bits changed from 0x08 to 0x0C
>> [Chan 17] - CAS Rx << [SEIZE ACK] 0x0C
>> [Chan 17] - Attempting to cancel timer timer 2
>> [Chan 17] - timer id 2 found, cancelling it now
>> [Chan 17] - DTMF/R2 call acknowledge!
>> [Chan 17] - scheduled timer id 3 (start_dialing_dtmf)
>> [Chan 17] - scheduled timer id 4 (r2_answer)
>> [Chan 17] - Attempting to cancel timer timer 3
>> [Chan 17] - timer id 3 found, cancelling it now
>> [Chan 17] - calling timer 3 (start_dialing_dtmf) callback
>> [Chan 17] - Dialing 4092442 with DTMF/R2 (tone on = 50, tone off = 100)
>> [Chan 17] - Done with DTMF generation
>> [Chan 17] - Attempting to cancel timer timer 0
>> [Chan 17] - Cannot cancel timer 0
>> [Chan 17] - DTMF R2 call is done generating DTMF, forcing accept signal
>> [Chan 17] - Bits changed from 0x0C to 0x08
>> [Chan 17] - CAS Rx << [0x08] 0x08
>> [Chan 17] - Protocol error. Reason = Invalid CAS, R2 State = Seize ACK
>> Received, MF state = MF Engine Off, MF Group = Forward DTMF init, CAS DNIS
>> = 4092442, ANI = 2748100, MF = 0x20
>> [Chan 17] - Attempting to cancel timer timer 0
>> [Chan 17] - Cannot cancel timer 0
>>
>> chan_dahdi.conf
>>
>> [channels]
>> context=default
>> usecallerid=yes
>> hidecallerid=no
>> callwaiting=yes
>> usecallingpres=yes
>> callwaitingcallerid=yes
>> threewaycalling=yes
>> transfer=yes
>> canpark=yes
>> cancallforward=yes
>> callreturn=yes
>> echocancel=yes
>> echocancelwhenbridged=yes
>> relaxdtmf=yes
>> rxgain=0.0
>> txgain=0.0
>> ;group=1
>> callgroup=1
>> pickupgroup=1
>> immediate=no
>>
>> group=1
>> context=from-trunk
>> signalling=mfcr2
>> mfcr2_variant=ve
>> mfcr2_get_ani_first=yes
>> mfcr2_max_ani=10
>> mfcr2_max_dnis=4
>> mfcr2_immediate_accept=no
>> mfcr2_category=national_subscriber
>> mfcr2_call_files=yes
>> mfcr2_logdir=cantv
>> mfcr2_logging=all
>> mfcr2_mfback_timeout=-1
>> ;channel => 1-15,32-46
>> channel => 1-15
>>
>> group=2
>> context=from-internal
>> signalling=mfcr2
>> mfcr2_variant=ve
>> mfcr2_get_ani_first=yes
>> mfcr2_immediate_accept=yes
>> mfcr2_dtmf_detection=1
>> mfcr2_dtmf_dialing=1
>> mfcr2_max_ani=10
>> mfcr2_max_dnis=4
>> mfcr2_category=national_subscriber
>> mfcr2_logdir=cantv
>> mfcr2_logging=all
>> mfcr2_mfback_timeout=-1
>> channel => 17-31
>>
>> group=3
>> channel => 22-31
>>
>>
>> On Sat, Feb 2, 2013 at 1:30 PM, <asterisk-r2-request at lists.digium.com>wrote:
>>
>>> Send asterisk-r2 mailing list submissions to
>>> asterisk-r2 at lists.digium.com
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>> or, via email, send a message with subject or body 'help' to
>>> asterisk-r2-request at lists.digium.com
>>>
>>> You can reach the person managing the list at
>>> asterisk-r2-owner at lists.digium.com
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of asterisk-r2 digest..."
>>>
>>> Today's Topics:
>>>
>>> 1. Failed calls E1 CANTV (Rafael Angulo)
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Rafael Angulo <rafael.angulo at tarma.com.ve>
>>> To: asterisk-r2 at lists.digium.com
>>> Cc:
>>> Date: Fri, 1 Feb 2013 16:29:02 -0430
>>> Subject: [asterisk-r2] Failed calls E1 CANTV
>>> Hello everybody,
>>>
>>> I have an E1 (CANTV VENEZUELA) configured against an elastix appliance.
>>> Elastix version is 2.3 asterisk version is 1.8.17.0 and dahdi version
>>> is 2.4.1.2. Some calls are failing to go out, writing the "busy/congested"
>>> message into the log and sending the appropriate message back to the
>>> caller. I'm not sure why the calling is failing, I think all the outgoing
>>> channels in the E1 are getting busy, but when I check the logs, there are
>>> some errors and I'm not sure if is the regular way asterisk log when all
>>> channels in a E1 are busy or there is actually an error in the progress of
>>> the call.
>>>
>>> Any help will be appreciated, right now I'm saving the output of the
>>> command mfcr2 show channels executed every two seconds to monitor if all
>>> the channels get busy together at any time during the day. Attached to this
>>> email is the log with the failing calls, this same behavior happens
>>> randomly with many other channels.
>>>
>>> [Feb 1 09:50:20] DEBUG[12104] chan_dahdi.c: Chan 22 - Requested to make
>>> call (ANI=2748100, DNIS=04149898199, category=National Subscriber)
>>> [Feb 1 09:50:20] DEBUG[12104] chan_dahdi.c: Chan 22 - Call started at
>>> Fri Feb 1 09:50:20 2013 on chan 22 [openr2 version 1.3.1, revision
>>> exported]
>>> [Feb 1 09:50:20] DEBUG[12104] chan_dahdi.c: Chan 22 - Outgoing call
>>> proceeding: ANI=2748100, DNIS=04149898199, Category=National Subscriber
>>> [Feb 1 09:50:20] DEBUG[12104] chan_dahdi.c: Chan 22 - CAS Tx >> [SEIZE]
>>> 0x00
>>> [Feb 1 09:50:20] DEBUG[12104] chan_dahdi.c: Chan 22 - CAS Raw Tx >> 0x01
>>> [Feb 1 09:50:20] VERBOSE[12104] app_dial.c: -- Called
>>> DAHDI/g3/04149898199
>>> [Feb 1 09:50:20] DEBUG[12104] chan_dahdi.c: bits changed in chan 22
>>> [Feb 1 09:50:20] DEBUG[12104] chan_dahdi.c: Chan 22 - Bits changed from
>>> 0x08 to 0x0C
>>> [Feb 1 09:50:20] DEBUG[12104] chan_dahdi.c: Chan 22 - CAS Rx << [SEIZE
>>> ACK] 0x0C
>>> [Feb 1 09:50:20] DEBUG[12104] chan_dahdi.c: Chan 22 - DTMF/R2 call
>>> acknowledge!
>>> [Feb 1 09:50:21] DEBUG[12104] chan_dahdi.c: Chan 22 - calling timer 3
>>> (start_dialing_dtmf) callback
>>> [Feb 1 09:50:21] VERBOSE[12104] chan_dahdi.c: Chan 22 - Dialing
>>> 04149898199 with DTMF/R2 (tone on = 50, tone off = 100)
>>> [Feb 1 09:50:22] DEBUG[12104] chan_dahdi.c: Chan 22 - Done with DTMF
>>> generation
>>> [Feb 1 09:50:22] DEBUG[12104] chan_dahdi.c: Chan 22 - DTMF R2 call is
>>> done generating DTMF, forcing accept signal
>>> [Feb 1 09:50:22] VERBOSE[12104] chan_dahdi.c: MFC/R2 call has been
>>> accepted on forward channel 22
>>> [Feb 1 09:50:22] VERBOSE[12104] app_dial.c: -- DAHDI/22-1 is ringing
>>> [Feb 1 09:50:22] DEBUG[12104] chan_dahdi.c: Enqueuing progress frame
>>> after R2 accept in chan 22
>>> [Feb 1 09:50:22] VERBOSE[12104] app_dial.c: -- DAHDI/22-1 is making
>>> progress passing it to SIP/116-000089f0
>>> [Feb 1 09:50:23] DEBUG[12104] chan_dahdi.c: bits changed in chan 22
>>> [Feb 1 09:50:23] DEBUG[12104] chan_dahdi.c: Chan 22 - Bits changed from
>>> 0x0C to 0x08
>>> [Feb 1 09:50:23] DEBUG[12104] chan_dahdi.c: Chan 22 - CAS Rx << [0x08]
>>> 0x08
>>> [Feb 1 09:50:23] ERROR[12104] chan_dahdi.c: Chan 22 - Protocol error.
>>> Reason = Invalid CAS, R2 State = Seize ACK Received, MF state = MF Engine
>>> Off, MF Group = Forwar$
>>> DNIS = 04149898199, ANI = 2748100, MF = 0x20
>>> [Feb 1 09:50:23] DEBUG[12104] chan_dahdi.c: Chan 22 - CAS Tx >> [IDLE]
>>> 0x08
>>> [Feb 1 09:50:23] DEBUG[12104] chan_dahdi.c: Chan 22 - CAS Raw Tx >> 0x09
>>> [Feb 1 09:50:23] ERROR[12104] chan_dahdi.c: MFC/R2 protocol error on
>>> chan 22: Invalid CAS
>>> [Feb 1 09:50:23] VERBOSE[12104] chan_dahdi.c: -- Hungup 'DAHDI/22-1'
>>> [Feb 1 09:50:23] VERBOSE[12104] app_dial.c: == Everyone is
>>> busy/congested at this time (1:0/0/1)
>>> [Feb 1 09:50:23] VERBOSE[12104] pbx.c: -- Executing
>>> [s at macro-dialout-trunk:20] NoOp("SIP/116-000089f0", "Dial failed for
>>> some reason with DIALSTATUS = CHANUNAVAIL$
>>> [Feb 1 09:50:23] VERBOSE[12104] pbx.c: -- Executing
>>> [s at macro-dialout-trunk:21] Goto("SIP/116-000089f0", "s-CHANUNAVAIL,1")
>>> in new stack
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Rafael A Angulo R
>>> Director Gerente
>>> Tarma Consultores C.A.
>>> Cel. (58)(414)106.04.73
>>> Ofi. (58)(212)793.49.81
>>>
>>>
>>> _______________________________________________
>>> --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
>>>
>>
>>
>>
>> --
>> Rafael A Angulo R
>> Director Gerente
>> Tarma Consultores C.A.
>> Cel. (58)(414)106.04.73
>> Ofi. (58)(212)793.49.81
>>
>>
>
>
> --
> Rafael A Angulo R
> Director Gerente
> Tarma Consultores C.A.
> Cel. (58)(414)106.04.73
> Ofi. (58)(212)793.49.81
>
>
> --
> _____________________________________________________________________
> -- 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/20130225/3706283c/attachment-0001.htm>
More information about the asterisk-r2
mailing list