Trama e1 de TELECOM con Elastix 2.4
 

Hace algunos años atrás cuando Jim Dixon comenzó el "Zapata Telephony Project", eligió ese nombre ya que creía que este proyecto daría comienzo a una revolución... y la realidad le da la razón con creces, hoy "Digium", lugar de origen del "Zapata Telephony Project" es uno de los principales productores de hardware para equipamiento de VoIP y también de software.... y a que viene todo esto... bien... hace un par de meses nos tocó lidiar con una trama E1 de TELECOM (en Argentina) y su configuración en un servidor de telefonía, para el cual utilizamos placas Digium y una distribución de Asterisk denominada Elastix.

Software

Hay varias distribuciones de Asterisk que funcionan correctamente.

Particularmente yo prefiero Elastix, que si bien requiere algún que otro ajuste, la realidad es que funciona correctamente y es un software "vivo" en constante evolución.

Para este proyecto, utilizamos Elastix 2.4 con los siguientes componentes.

  • Elastix 2.4
  • FreePBX 2.8.1 rel 16
  • Asterisk 11.15.0 rel 2
  • Dahdi 2.10.0.1 rel 3

Luego veremos que ajustes tuvimos que hacer sobre la base del Elastix para lograr que la trama E1 de TELECOM iniciara su funcionamiento, pero sigamos con la interfaz de hardware.

Conectando la trama E1 - Hardware

Existen numerosas formas de conectar la trama E1 (o T1) a un servidor, en este caso utilizamos una placa Digium de la gama T2xx. Esta placa se utiliza para tramas E1 y T1 cambiando de un tipo de trama a otra a través de un conjunto de jumpers en la propia placa .

En este caso, nuestra placa tiene 2 SPANs, o sea 2 conectores RJ45 para enlazar, cada uno de estos conectores se relaciona con 1 jumper. Cada SPAN, puede configurarse independientemente, o sea que podemos tener 1 SPAN con E1 y otro con T1. En nuestra caso ambos SPANs se configurarán como E1, para lo cual deberemos cerrar los 2 primeros jumpers (1-2 y 3-4).

Detectando el Hardware

Colocada la (o las placas) en el servidor e instalado Elastix, podemos recurrir a la linea de comandos de Linux a los efectos de ver si Linux ha "visto" correctamente nuestra placa ( o placas), como en este caso estamos utilizando placas "Digium", bastará con ejecutar el comando

lspci | grep "Digium"

Como nuestro servidor contiene 2 placas Digium, una con 4 conectores analógicos y otra con 2 E1, lspci nos muestra ambos registros

Una de las funciones que tiene Elastix "in the box", es la detección del hardware que se utilizará, una vez instalado Elastix, con la placa en su interior, podemos ejecutar la detección de hardware para que Elastix realice la configuración por nosotros... bueno... aqui es donde se acaba el idilio y deberemos comenzar a configurar algunos aspectos en forma manual...

En la imagen superior podemos ver la detección de Elastix (luego de los ajustes), donde se muestra en primera instancia una placa con 4 conexiones analógicas FXO, y luego nuestra nueva placa de trama TE220 para el primer SPAN detectado y conectado (observese en la parte inferior que se muestra el 2do SPAN en RED o sea en alarma, ya que no hay nada conectado a él).

Que datos debemos tener de la trama?

Cuando se contrata una trama o 1/2 trama, normalmente los vendedores nos dicen la cantidad de canales y números que nos están vendiendo, y los "fabulosos" planes de llamadas, pero rara vez saben que consideraciones técnicas hay que tener en cuenta para hacer funcionar la trama, y tal vez éste sea el dato más complejo de obtener.

En nuestro caso, TELECOM (de Argentina) nos indicó lo siguiente

Para la conexión a nivel troncal, se utilizarán enlaces E1, con señalización Loop R2 Digital con cómputo, las que deberàn cumplir con la recomendaciòn G.703 del CCITT, cuyas principales caractreristicas son:

a - Interface física a 2048 kbit/s.
b - Impedancia de la interface: 75 ohms no balanceados.
c - Conector eléctrico: BNC coaxil tipo 1.6/5.6 (DIN 47295).
d - Velocidad binaria: 2048 kbit/s ± 50 ppm.
e - Código de línea: HDB3 (bipolar de alta densidad de orden 3).
f - Amplitud de pulso: +2,37 V +- 10%.

Señalización

2-4-1 La señalización a utilizar será CAS debiendo estar en un todo de acuerdo con la NORMA DE SEÑALIZACION POR CANAL ASOCIADO de TELECOM ARGENTINA

Que nos quizo decir con eso?, ... que el método de comunicación sería CAS y la señalización de la trama sería a través del protocolo MFCR2.

El protocolo MFC/R2 es un protocolo de punto a punto que se utiliza para la comunicación o señalización entre dos centrales, o sea, en este punto sabemos que tipos de "señales" se van a enviar entre las 2 centras, ahora debemos saber el "como".

Estos dispositivos normalmente utilizan uno de entre dos metodos de señalización, CCS (Common Channel Signaling) o CAS (Channel Associated Signaling).

En el caso de la trama E1 de TELECOM, se utiliza CAS. CAS y MFCR2 tienen ademas diferentes variantes, las que debemos configurar adecuadamente para que todo funcione.

Con CAS, dado que los dispositivos utilizan señalizacion simple de 4 bits CAS, debemos indicar a Asterisk el orden de estos bits. Los bits se sulen denominar con letras e indican el status de linea, emulando a la telefonía analógica. No logramos obtener esta información en forma directa, por lo que tuvimos que probar. Dado que sabemos que los últimos 2 bits son raramente utilizados, realizamos pruebas con los primeros 2, hasta obtener resultados con el patrón 1101.

Bien.. hasta aqui sabemos que nuestro Asterisk va a tener que funcionar con CAS, con los bits 1101 y con mfcr2... y la variante de mfcr2?.... primero vamos a tener que solucionar otro problema...

Somos todos amigos... pero el poncho no aparece?

Antes de ajustar la configuración de Asterisk para nuestros requerimientos nos aparecerá un problema más... mfcr2 no aparece...

mfcr2 está implementado a partir de la libreria libopenr2, y utiliza una implementación un poco diferente del zaptel tradicional, por lo tanto debemos verificar que esta librería esté actualizada, en nuestro caso, con el elastix instalado desde la ISO, la librería no nos permitia levantar el mfcr2 con la placa Digium y tuvimos que actualizarla a la versión 1.3.3-1.

En Elastix esta actualización es bastante fácil, pueden hacerlo a través de la interfaz gráfica, System -> Updates y alli aplican el filtro con "libopenr2" y presionan el link "Actualizar", si la librería se muestra como "actualizada" y aun asi es una versión anterior, procedan a actualizar los repositorios con "Repositories Update".

Bien... tenemos todos los ingredientes... a cocinar...

Elastix normalmente hace un buen trabajo con la detección de hardware, pero en nuestro ejemplo fallará, primero por la combinación de placas que instalamos y luego por el hecho de las particularidades de configuración de trama que debemos ejecutar.

Antes de comenzar con nuestra configuración, frenaremos los servicios...

Pararemos primero Asterisk y sus servicios asociados, para ello, iniciamos sesión en el server Linux, localmente o a través de SSH y ejecutamos lo siguiente.

amportal stop

Luego frenando el servicio dahdi

service dahdi stop

Ahora, con los servicios frenados, pasaremos a configurar los siguientes componentes

  • etc/dahdi/system.conf
  • etc/asterisk/chan_dahdi.conf
  • etc/asterisk/dahdi_channels.conf
  • etc/asterisk/unicall.conf

Configuración de system.conf

Si bien la revolución comenzó con Zapata, continuó con DAHDI ( Digium Asterisk Hardware Driver Interface), y debemos entonces utilizar el archivo system.con en \etc\dahdi para su configuración.

Allí indicaremos para el primer SPAN (el único que realmente utilizaremos y conectamos), el método de comunicación CAS y el HDB3.

Normalmente la detección de Hardware puede apuntar a CCS, HDB3 y CRC4, pero cuando se utiliza CAS con HDB3, normalmente no hay CRC4.

Luego de configurar el span, deberemos indicar los canales a utilizar, en el ejemplo canales 5 a 19 y 21 a 35 con bits 1101. El canal 20 se utilizará de control, pero no corresponde indicar el control aqui ni por dchan ni por hardhdlc (con otras configuraciones de librerías, métodos y protocolos, corresponde la indicación del canal de control).

Si contamos con cancelación de eco por hardware podemos indicar el tipo de cancelación de eco, de lo contrario deberemos recurrir a cancelación por software, en nuestro caso, utilizaremos oslec como cancelación de eco.

Configuración de etc/asterisk/chan_dahdi.conf

Al fin hace su aparición MFCR2. El protocolor mfc r2 que indicamos se incluía en la libreria libopenr2, debe ser configurado en los canales dahdi que vamos a utilizar, para lo cual editaremos el archivo /etc/asterisk/chan_dahdi.conf. Alli incluiremos las lineas referentes a este protocolo hacia el final del archivo pero antes de las incluisiones (se omiten lineas en el ejemplo a los efectos de clarificar los agregados).

[channels]
......

language=es
resetinterval=never

context=from-pstn
group=0
echocancel=yes
signalling=mfcr2
mfcr2_variant=ar
mfcr2_max_ani=10
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_call_files =yes
mfcr2_mfback_timeout=-1
mfcr2_metering_pulse_timeout=-1
channel => 5-19,21-35

#include dahdi-channels.conf
#include chan_dahdi_additional.conf

Que significan las lineas incorporadas? Lo primero que indicamos a dahdi es la señalización "signalling=mfcr2", luego dado que mfc r2 tiene muchas variantes, debemos indicar que variante utilizaremos, en nuestro caso, utilizamos ar que corresponde a Argentina "mfcr2_variant=ar", a continuación debemos indicar la categoría, como se trata de un enlace entral contra central, corresponde "mfcr2_category=national_subscriber". Luego deberemos indicar la cantidad de digitos que recibiremos del callerid via mfcr2_max_ani, y la cantidad de digitos de nuestro DID, con mfcr2_max_dnis que es normalmente 4. MFCR2 tiene muchas más configuraciones, pero por ahora, nos limitamos a las que harán que la E1 levante y funcione.

Configuración de /etc/asterisk/dahdi-channels.conf

Luego via dahdi-channels.conf indicaremos el tratamiento de los canales, omitiremos aqui las lineas que corresponden a los canales de la placa analógica (por eso siempre empezamos con el canal 5 en lugar del 1).

; Span 1: WCTDM/0 "Wildcard A4B" (MASTER)
....

; Span 2: TE2/0/1 "T2XXP (PCI) Card 0 Span 1"
group=0,12
context=from-pstn
switchtype = euroisdn
signalling = mfcr2
channel => 5-19,21-35
context = default
group = 63

; Span 3: TE2/0/2 "T2XXP (PCI) Card 0 Span 2"
group=0,13
context=from-pstn
switchtype = euroisdn
signalling = mfcr2
channel => 36-50,52-66
context = default
group = 63

Nuevamente aqui, la configuración es simple, le indicamos a dahdi que utilice la señalización mfcr2 y el grupo de canales para las cuales se requiere, también indicamos el tipo de switching, en este caso "euroisdn". Si es necesario, podemos separar más los canales, asignando distintos grupos y contextos, pero escapa al alcance de este documento.

Finalmente /etc/asterisk/unicall.conf

Y finalmente, en el archivo unicall.conf se debe indicar también la configuración de MFCR2 que utilizaremos, por lo que agregaremos las siguientes lineas...

[Channels]
.....
protocolclass=mfcr2
protocolvariant=ar,10,4

Arranque, fracaso y exito

Una vez finalizados todos estos cambios estabamos listos para levantar los servicios, para lo que desde una consola Linux hicimos...

service dahdi start

amportal start

Y nos dispusimos a hacer las primeras pruebas... y..... ocupado !!!!

Cómo...? No puede ser... Conectamos algo mal? El cable ??? El Balún...? Bueno luego de buscar, y buscar... llegamos a la conclusión que el problema estaba del lado del servicio, el comando Asterisk para ver el estado de los canales, nos mostraba los canales como "Blocked", y luego TELECOM nos confirmó que los mismos estaban bloqueados de su lado, luego de desbloquearlos la central comenzó a funcionar correctamente como lo muestra la siguiente traza.

Conclusiones

Elastix hace un excelente trabajo, basado en el excelente esquema que ofrecen Linux + Asterisk, sin embargo, muchas veces debemos realizar ajustes manuales y en estos casos es imprescindible contar con información certera del servicio para evitar horas desgastantes buscando soluciones.

El esquema de configuración de archivos .conf que ofrece Linux, Asterisk, Dahdi es muy potente, pero suelen ser sobreescritos en determinadas circunstancias por las distribuciones, por lo que debemos documentan las configuraciones y ajustar dichos archivos de ser posible, en archivos conf. que no sean generados por la distrubución que utilicemos.

También debemos tomar en cuenta que lo que funciona para una TELCO no será lo mismo que funciones para otra, que lo que se requiere para una versión de DAHDI puede no requerirse para otra, que lo que funciona en una versión de Libopenr2 no funciona en otra y asi sucesivamente.

El mundo del software libre ofrece potenciales ilimitados, y también los da en el área de los dolores de cabeza... pero... nos dedicamos a I.T.... es lo que hacemos... y nuestra gratificación viene por el lado de... "lo hice funcionar"... o no?

 

 

Volver a lista de Notas