[asterisk-r2] FW: Error con MFC-R2 y E1 de Movistar

[Raúl Gómez C.]

Hola Mc Grath,

Muchas gracias por tu respuesta, voy a revisar ese parámetro y les comento
como me fue.

También les comento que el problema que tenía con los grupos solapados era
debido a que habíamos cambiado varias veces los cables de las líneas de mi
central vieja a la nueva y viceversa y por algún motivo algunos canales
estaban bloqueados, por lo que Asterisk asumió que no existían y los omitió
al cargar el módulo dahdi, una vez que reinicié los Redfone (fonulator -R
/etc/redfone.conf) se les pasó la moridera y volvieron a activarse. Pude
confirmar que los canales se bloqueaban al conectar y desconectar los
cables repitiendo esta acción obteniendo el mismo resultado.

¿A alguno de ustedes les ha ocurrido esto de los canales bloqueados en los
Redfone? (en dahdi_tool los canales bloqueados por este motivo aparecen en
cero los campos RxA,RxB,RxC,RxD y dentro de Asterisk aparecen como BLOCKED)

Una vez reiniciado los Redfone las llamadas empezaron a salir sin problema,
pero sin embargo en los logs se puede observar los mensajes de error antes
mencionados, por lo que seguiré la recomendación quee Mc Grath me dio en su
correo anterior a ver si los puedo corregir.

Aparte, también apareció por primera vez este error:

"Protocol error. Reason = Invalid CAS, R2 State = Clear Back Transmitted,
MF state = MF Engine Off, MF Group = Backward Group A, CAS = 0x0C DNIS =
7777, ANI = 4244731397, MF = 0x20"

Que me imagino debe estar ligado a lo que me comenta Mc Grath, seguiré
investigando.


Muchas gracias a todos por la ayuda y consejos, los mantendré al tanto de
como va este proyecto en caso de que alguien tenga un problema similar en
el futuro.

Saludos...

*           **
*
*Raul (Nacho) Gomez
Linux Counter #156439*



2012/11/28 Mc GRATH Ricardo <mcgrathr at mail2web.com>

>   Raul
>
> He realizado pruebas, pero puede llegar a una alternativa;
> En el archivo chan_dahdi.conf en la linea comentada
> de mfr2_advance_protocol_file des comentar y poner el path, en mi caso
> esta por defecto en /usr/etc/
> mfcr2_advanced_protocol_file=/usr/etc/r2proto.conf
> timers.mf_back_cycle=1500 cambiar a un valor mayor según las normas
> debiera de ser 15 segundo podes modificar a
> timers.mf_back_cycle=15000
>
> este seria para los caso de los log con Reason = Multi Frequency Cycle
>  Timeout los salientes tendrás que ver el porque aparece la señal como
> respuesta E.
>
> Saludos
>
>  Mc GRATH Ricardo
> E-Mail mcgrathr at mail2web.com
>
>  ------------------------------
> *From:* Mc GRATH Ricardo
> *Sent:* 28 November 2012 20:28
> *To:* asterisk-r2 at lists.digium.com
> *Subject:* RE: [asterisk-r2] Error con MFC-R2 y E1 de Movistar
>
>    Raúl
>
> Te comento que en el trace dela información hay puntos inconsistente por
> ejemplo;
> chan-49-forward-0-20121127190311.call
> En este caso se observa que la llamda saliente cuando se envía el digito
> 0 correspondiente al DNIS=04241234567 se recibe como respuesta al digito
> enviado la señal E, debiendo de ser 1.
>
> chan-49-forward-0-20121127191256.call
> En este caso a posterior del envió del primer digito se ha enviado una
> liberación, desde el interno que origino la llamadas, tal vez hayas
> cortado o abortado.
>
> chan-66-backward-0-20121127182922.call y subsiguientes
> Se observa que a posterior de envió de dígitos sea en la petición de ANIo DNISpor parte de Elastixse observa un timeoutde 5 seg
>
> Por otro lado  no me queda claro el porque la peticion de envio de digitosde ANIes 9 y no 5 tal vez me pueda decir el porque.
> En lo que se refiere al tema de tiemout de 5  trate de ubicar
> alguna información de parámetros para corregir y  no encontré, tal
> vez Moisés puede brindar información al respecto.
> Saludos
>
>
> Mc GRATH Ricardo
> E-Mail mcgrathr at mail2web.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20121129/8e9838cd/attachment.htm>