MFC/R2 es un protocolo de señalización dentro de banda por cada canal (CAS channel associated signalling) sobre tramas digitales E1 usado principalmente en Latinoamérica (quizás el más usado todavía hoy). El cual es soportado perfectamente en Elastix® debido a la inclusión de la librería OpenR2 la cual implementa señalización MFC/R2 sobre líneas E1 usando la interfaz de telefonía DAHDI. El autor de dicha librería y los parches de Asterisk® correspondientes es Moisés Silva quien actualmente trabaja para la firma canadiense Sangoma® y a quien personalmente agradezco por todo su trabajo y ayuda.
¿Qué es MFC/R2?
MFC/R2 es una señalización telefónica usada ampliamente en Argentina, Colombia, Venezuela, México, Brasil y otros países de Latinoamérica y Asia con su origen en los inicios de la telefonía digital allá por fines de la década del 70.
Las iniciales de MFC/R2 provienen de Multi-Frequency Compelled R2 (R2 dirigido por multifrecuencia). Comparado con protocolos de señalización más recientes como el ISDN PRI/BRI o SS7, R2 ofrece funcionalidades bastante limitadas. La señalización solo se usa para establecer la llamada o para finalizarla. A su vez algunas de las variantes MFC/R2 envían pulsos de cobro mientras dura la llamada, aunque raramente son usados.
Existen variantes analógicas y digitales de MFC/R2, pero cualquier referencia a MFC/R2 o R2 en éste documento solo se basa en la versión digital usada sobre enlaces E1.
Un dato curioso sobre este protocolo es que a pesar de estar definido y estandarizado por la ITU (International Telecommunication Union), cada país sigue su propia variante… L
¿Cómo funciona MFC/R2?
MFC/R2 es un protocolo de señalización peer-to-peer, lo cual significa que solo hay dos participantes involucrados sobre un enlace E1 R2 y ambos extremos se comportan del mismo modo, muy distinto con respecto a ISDN PRI donde se tiene la un extremo servidor “NET” y otro cliente “CPE” del enlace.
Como se nombró anteriormente, MFC/R2 significa Multi-Frecuency Compelled R2 y dicho nombre describe la naturaleza de ésta señalización, donde se tienen dos tipos de señales (valga la redundancia):
· Señales de Línea. Son usadas para monitorear el estado de la llamada y las señales MF son usadas para transmitir información de la misma durante el establecimiento de la misma (DNIS, ANI, Calling Party Category). Las señales de línea se envían utilizando señales CAS que viajan usando el canal 16 del enlace E1. Todas las señales CAS de cada canal del E1 son multiplexadas en éste canal. Cada 2 milisegundos cada extremo del enlace actualiza sus 4 bits de señal CAS mas conocidos como los infames bits ABCD.
MFC/R2 usa 2 de esos 4 bits para enviar las siguientes señales:
Idle, Block, Seize, Seize Ack, Clear Back, Forced Release, Clear Forward, Answer.
Al usarse sólo 2 bits para 7 posibles señales es imposible no repetir algún patrón, es por eso que algunas de las 7 señales tienen el mismo patrón de bits, pero esto no representa un problema considerando que, por ejemplo, no se puede ir del estado Idle al Forced Release, por lo tanto, aunque el patrón de bits para Forced Release y Seize son los mismos, el protocolo conoce lo que lo que el otro extremo del enlace quiere decir de forma inequívoca.
La razón de usar sólo 2 bits teniendo 4 disponibles es histórica y proviene de la época donde la versión analógica de MFC/R2 fue portada para trabajar en el ese entonces novedoso mundo digital.
La siguiente tabla describe los patrones de bits usados en la señalización R2 mediante los bits ABCD de CAS.
· Las señales de direccionamiento, por el otro lado, son 15 diferentes señales MF, que son tonos audibles compuestos por 2 frecuencias que viajan usando el canal de audio, y es por eso que el analizador/detector de audio es el componente quizás mas importante en el paquete R2.
La librería OpenR2 por defecto usa su propio analizador/detector de MF sobre R2, el cual fue tomado prestado de la librería SpanDSP de Steve Underwood. A diferencia de su antecesor Unicall no es necesario instalar SpanDSP ni otras librerías para usar OpenR2, ya que el detector se encuentra “embebido” dentro de la misma de forma nativa.
La ITU define qué frecuencias pueden ser mezcladas para componer los tonos MF y asigna los significados de cada uno de ellos. Sin embargo tal como fue comentado anteriormente, algunos países asignan diferentes significados a estos tonos MF.
Dichos tonos MF son identificados en la librería OpenR2 usando los números del 1 al 0 (0 siendo 10) y letras de la B a la F (la A no es usada, en su lugar se usa 0). Si nosotros habilitáramos el debugging del módulo de OpenR2 veríamos los detalles de qué tonos son enviados y recibidos durante el transcurso de cada llamada.
Los tonos multifrecuencia (MF) son usados para transmitir los ANI (Automatic Number Identification, mas conocido como Identificador de Llamada), los DNIS (Dialed Number Identification Service, que es, el número marcado o número destino) y las Categorías de Marcado.
Tan pronto como la llamada es aceptada o rechazada, el analizador/detector de MF se deja de usar y no se intercambiarán más señales MF, recién ahí el canal de audio puede ser usada para transmitir la llamada de voz.
Configuración de E1 R2 en Elastix 1.5.2-2 o superior.
· Para tarjetas que usan el driver DAHDI de forma nativa:
o Primero nuestra tarjeta de trama digital debe usar el estándar E1 por lo cual debemos verificar que su correspondiente jumper o configuración este seteada en dicho estándar
o En caso de usar múltiples tarjetas E1 verificar que los controles de identificación de tarjetas estén correctamente seteados (1er tarjeta en 0, 2da en 1, etc.)
o Verificar que la tarjeta es correctamente reconocida en Elastix® usando el comando # lspci desde la consola.
o Utilizar la herramienta # dahdi_genconf para generar una config básica estándar (la vamos a usar para no tener que contar a mano los canales) si tenemos varias tarjetas o varias tramas E1.
o Con la información de nuestro proveedor de telefonía en la mano vamos a proceder a configurar la trama digital a nivel del driver DAHDI, este es un ejemplo típico de 1 trama simple E1 para Argentina:
§ Archivo: /etc/dahdi/system.conf
span=1,1,0,cas,hdb3 ;reloj master, señalización CAS, Coding hdb3
cas=1-15,17-31:1101 ; Canales CAS del 1 al 15 y 17 al 31 bits en block
dchan=16
echocanceller=mg2,1-15,17-31 ;Cancelación eco MG2 en los canales
loadzone=ar
defaultzone=ar ; zonas de tonos argentinos del driver DAHDI
§ Archivo de Asterisk para configurar los canales mfcr2, chan_dahdi.conf, debajo de las configs por defecto del archivo agregamos:
resetinterval=never
context=from-pstn
group=0
echocancel=yes
signalling=mfcr2
mfcr2_variant=ar ; variante de r2 de nuestro país
mfcr2_get_ani_first=no
mfcr2_max_ani=10 ;cantidad de dígitos del caller id a recibir
mfcr2_max_dnis=4; cantidad de dígitos de nuestros DID´s
mfcr2_category=national_subscriber
mfcr2_mfback_timeout=-1
mfcr2_metering_pulse_timeout=-1
channel =>1-15,17-31 ; canales a configurar igual que en system.conf
o Luego restarteamos nuestros drivers Dahdi y el servicio de Asterisk® y verificamos si nuestra trama está en funcionamiento (imágenes de muestra de un sistema real)
§ # service dahdi restart
§ # amportal restart
o Imagen de la herramienta dahdi_tool con trama E1 R2 corriendo correctamente:
o Imagen de la salida del comando mfcr2 show channels de asterisk demostrando que los canales están funcionando:
o Los canales ya pueden ser usados desde el FreePbx y Elastix® tal como los veniamos usando con otras tarjetas. En este caso serían el grupo Dahdi/g0.
· Para tarjetas Sangoma®:
o Parar los servicios de Asterisk®
# amportal stop
o Parar los drivers Dahdi
# service dahdi stop
o Parar el servicio wanrouter de Sangoma
# service wanrouter stop
o Ejecutar el comando # wancfg_dahdi y seguir las instrucciones del mismo, cuando llegue a selección de estándares seleccionar E1, ISDN pri con estándar EuroISDN, elegir que grabe los cambios sin restartear el dahdi ni asterisk.
o Al terminar este paso editar el archivo /etc/wanpipe/wanpipe1.cfg buscar la línea donde dice TE_SIG_MODE = CCS y reemplazarlo por CAS, grabar el archivo y luego retomar la config exactamente igual que como está descripto en el apartado de Dahdi nativo arriba descripto.
o Al finalizar de editar los archivos /etc/dahdi/system.conf y /etc/asterisk/ chan_dahdi.conf debemos levantar de nuevo los servicios en este orden:
§ # service wanrouter start
§ # service dahdi start
§ # amportal start
o Por último verificamos que la trama haya levantado igual que en el ejemplo anterior con el comando de asterisk cli> mfcr2 show channels
· En el caso de varias tramas digitales solo cambian los números de canales y este ejemplo es totalmente válido para 1 a n tramas.
· Es posible en 1 misma tarjeta o en 1 mismo sistema mezclar diferentes spans de trama y cada uno con su propio protocolo ya sean R2 o ISDN primario.
Nuevamente espero que este humilde aporte los ayude y agradezco a Moises Silva, a Alexandre Alencar y a Juan Carlos Huerta por sus aportes en la realización de este documento y por favor si desean soporte, mas info o consultas específicas les solicitamos hacerlas a través del soporte oficial pago de de nuestra empresa y de Elastix® para seguir apoyando el crecimiento del Software Libre.
