[asterisk-r2] Failed calls CANTV (suspect on fast-busy tone)
Rafael Angulo
rafael.angulo at tarma.com.ve
Mon Feb 25 21:22:05 CST 2013
Saludos amigos de la lista, mil gracias por sus respuestas, me han dado
algunas ideas interesantes, sin embargo avance un poco mas en
la comprensión del problema y acá les relato esperando que puedan
ayudarme.Como ya he mencionado en varios mensajes, sigo trabajando sobre el
problema de la Elastix -> sangoma E1 -> R2/DMTF -> CANTVHoy descubrí casi
por azar que las llamadas fallidas ocurren (no se si siempre) cuando CANTV
envía un fast busy tone justo después de que se envía el numero discado por
DTMF(no era como pensaba el técnico de CANTV, que el numero no se enviaba).
Lo comprobé llamando al numero desde mi celular y evidenciando el fast-busy
tone(el numero esta dañado), para ese numero, la central siempre falla,
colocando en los logs lo que les he mandado en los otros correos(mas abajo
en el correo están los log). Esto en mi experiencia ocurre aleatoriamente
con números que no tienen problemas, y siempre con números dañados.
Debo suponer que estas lineas del log:
[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
Indican que para la maquina de estados de openR2, recibir un fast-busy
tone después de enviar el numero marcado por DTMF es un estado invalido.
Entonces me surgen estas preguntas:
1) Se podrá modificar el comportamiento de OpenR2 para que envíe el
fast-busy tone al llamante (creo que es lo mas justo) en este caso.
2) Habrá forma de evitar que asterisk responda "todas las
lineas están ocupadas"?
3) Servirá el busydetect de asterisk para ayudar al problema como se
menciona en este post:
http://lists.digium.com/pipermail/asterisk-r2/2011-July/002244.html
Si divido las lineas salientes en tres grupos(por ejemplo
17-21,22-27,28-31) y el primero falla, intentara por el segundo o el
tercero, esto debería funcionar si el fast busy tone se genero por error de
CANTV para un numero bueno, pero si el numero esta dañado, CANTV siempre
responderá con el Fast-Busy tone, y asterisk intentará sacar la llamada por
los tres grupos después de lo cual enviara al llamante el mensaje de "todas
las lineas están ocupadas" y de igual manera el llamante pensara que las
lineas están ocupadas y no que el numero esta malo.
Alguna experiencia de los amigos de la lista al respecto?
Mil gracias de antemano,
rafa
>
>
> On Mon, Feb 25, 2013 at 2:39 AM, <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. Re: Failed calls CANTV updated again (Rafael Angulo)
>> 2. Re: Failed calls CANTV updated again (Gerardo Barajas)
>>
>>
>> ---------- Forwarded message ----------
>> From: Rafael Angulo <rafael.angulo at tarma.com.ve>
>> To: asterisk-r2 at lists.digium.com
>> Cc:
>> Date: Mon, 25 Feb 2013 01:33:58 -0430
>> Subject: Re: [asterisk-r2] Failed calls CANTV updated again
>> 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
>>>
>>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20130225/25b56ba4/attachment-0001.htm>
More information about the asterisk-r2
mailing list