[asterisk-r2] Failed calls CANTV updated again
Martin Rivero
mrs.81mx at gmail.com
Mon Feb 25 15:29:58 CST 2013
Has intentado colocar la siguiente linea en un contexto de salida, no
directamente el de Elastix?
[LineasOUT]
exten => _ZXXXXXXX,1,Macro(RecordCall,OUT,${EXTEN})
exten => _ZXXXXXXX,n,Macro(LineasOUT,g0,${EXTEN},30,5544332000,)
exten => _ZXXXXXXX,n,Hangup()
exten => _04[45]ZXXXXXXXXX,1,Macro(RecordCall,OUT,${EXTEN})
exten => _04[45]ZXXXXXXXXX,n,Macro(LineasOUT,g0,${EXTEN},30,5544332000,)
exten => _04[45]ZXXXXXXXXX,n,Hangup()
exten => _01ZXXXXXXXXX,1,Macro(RecordCall,OUT,${EXTEN})
exten => _01ZXXXXXXXXX,n,Macro(LineasOUT,g0,${EXTEN},30,5544332000,)
exten => _01ZXXXXXXXXX,n,Hangup()
exten => _001XXXXXXXXXX,1,Macro(RecordCall,OUT,${EXTEN})
exten => _001XXXXXXXXXX,n,Macro(LineasOUT,g0,${EXTEN},30,5544332000,)
exten => _001XXXXXXXXXX,n,Hangup()
;----------------------------------------------------------------------------------------------------
;Macros
;----------------------------------------------------------------------------------------------------
[macro-RecordCall]
exten => s,1,Set(TYPE_CALL=${Arg1}) ;IN - OUT
exten => s,n,Set(PHONE=${Arg2})
exten => s,n,Set(CALLDIRECTORYNAME=/var/spool/asterisk/monitor/)
exten =>
s,n,Set(CALLFILENAME=${TYPE_CALL}-${UNIQUEID}-${STRFTIME(${EPOCH},,%Y%m%d:%H%M%S)}-${PHONE})
exten => s,n,Set(CDR(userfield)=${CALLFILENAME}.gsm)
exten => s,n,MixMonitor(${CALLDIRECTORYNAME}${CALLFILENAME}.gsm)
[macro-LineasOUT]
exten => s,1,Set(TRUNK=${Arg1})
exten => s,n,Set(PHONE=${Arg2})
exten => s,n,Set(TIME_RING=${Arg3})
exten => s,n,Set(DID=${Arg4})
exten => s,n,Set(TIME_CALL=${Arg5})
exten => s,n,Set(CHANNEL(language)=es)
exten => s,n,Set(CALLERID(num)=${DID})
exten => s,n,*Dial(DAHDI/${TRUNK}/${PHONE},${TIME_RING},tTr)*
exten =>
s,n,Noop(-------------------------------------------------------------------------)
exten => s,n,Noop( CAUSE CODE ::: ----- ${HANGUPCAUSE} ----- STATUS :::
${DIALSTATUS} -----)
exten =>
s,n,Noop(-------------------------------------------------------------------------)
El 25 de febrero de 2013 06:45, Mc GRATH Ricardo
<mcgrathr at mail2web.com>escribió:
> Estimados
>
> Esto a mi entender pasa en como OpenR2 maneja los parámetros de la
> interface R2 y configuración.
> Por cuanta configuración apliques los resultados no se corresponden
> (carecen de lógica), ahora no queda claro donde parte la naturaleza del
> problema, si esta es la segmentación de los canales, que dicho sea de
> paso es el segmentación de canales, ya que si particionas de 10 en 10
> te encontras con que la segunda decena se produce un error y no levanta
> en la interface MFCR2 en Asterisk, por el canal 16 de señalizacion, lo
> que se concluye no podes segmentar la trama de 10 canales, no hay una
> relocacion.
> El otro punto relacionado a la configuración es como toma los parámetrosdel chan_dahdi.confy cual es el delimitador y orden en la configuraciónpara que cuando Asterisklevante se correspondan, esto valdríaa decir que si en la configuraciónse repitiera parámetrosde configuracióncomo los parámetros
> de señalización esta la pueda tomar como valida y no la primera (MFCR2 y
> DTMF),o mejor dicho si existe que no pueda repetir parámetros que no son
> comunes.
> Algo similar podría decirse como dial plan en similitud de patterns
> tomaría la primera de arriba hacia abajo.
> esto mismo se le ha cuestionado o consultado a Moises y hay un
> ticket abierto sobre un posible bug y que este tiene que revisar.
> Por otro lado reporta un error de CAS invalido, si tanto en la
> modalidad MFCR2 y DTMF usan el mismo patrón, otra de las incertidumbres
> del OpenR2, porque siendo se señalización hace referencia aun tema de CAS.
> Lo que tal vez pueda ayudar es que apliques la regla prueba y error en
> la configuración para que mínimamente puedas recibir y hacer llamados y
> minimizar el problema.
> Saludos
>
> Mc GRATH Ricardo
> E-Mail mcgrathr at mail2web.com
>
> ------------------------------
> *From:* asterisk-r2-bounces at lists.digium.com [
> asterisk-r2-bounces at lists.digium.com] On Behalf Of Rafael Angulo [
> rafael.angulo at tarma.com.ve]
> *Sent:* 25 February 2013 03:03
> *To:* asterisk-r2 at lists.digium.com
> *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
>>
>>
>
>
> --
> 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
>
--
*AVISO DE CONFIDENCIALIDAD: Este correo electrónico, incluyendo en su caso,
los archivos adjuntos al mismo, pueden contener información de carácter
confidencial y/o privilegiada, y se envían a la atención única y
exclusivamente de la persona y/o entidad a quien va dirigida. La copia,
revisión, uso, revelación y/o distribución de dicha información
confidencial sin la autorización previa, por escrito de Martin Rivero está
prohibida. Mediante la recepción de este correo electrónico usted reconoce
y acepta que en caso de incumplimiento de su parte y/o de sus
representantes a los términos antes mencionados, Martin Rivero tendrá
derecho a los daños y perjuicios que esto le cause.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20130225/4fda41d4/attachment-0001.htm>
More information about the asterisk-r2
mailing list