Configuración práctica de Asterisk (5ª parte): Puertos utilizados en los paquetes RTP de audio

En una entrada publica el 12 de junio de 2014 se analizó en este mismo blog el problema de los puertos que deben ser abiertos en el cortafuegos o firewall de la organización a fin de permitir las comunicaciones VoIP. En aquella ocasión, la PBX utilizada para las pruebas fue la NCP 500 de Panasonic, disponible en el aula de telefonía del Instituto de Formación Profesional Tartanga. Las conexiones salientes y entrantes se realizaron a través del operador de VoIP Sarenet, con el cual nuestro instituto tiene contratado el servicio Sarevoz IP. Mediante diversas pruebas y capturas de paquetes con Wireshark comprobamos los tres siguientes hechos:

  • La señalización entre Sarenet y la NCP500 siempre es a través del puerto UDP 5060.
  • En la NCP500,  el tráfico RTP con los paquetes de voz se envía y se recibe a través de puertos UDP comprendidos entre el 12000 y el 12255 y seleccionados de forma dinámica para cada llamada establecida.
  • Sarenet envía y recibe su tráfico RTP mediante puertos UDP seleccionados de forma dinámica y en un rango muy amplio. En las pruebas realizadas comprobamos como a veces los puertos UDP tomaban valores cercanos al 52000 y otras veces valores por encima del 58000.

La NCP500 necesita utilizar un rango de puertos UDP porque para cada llamada IP establecida a su través, ya sea interna o externa, los paquetes de voz RTP se dirigirán a la dirección IP de la tarjeta DSP de la centralita. Puesto que todos los paquetes RTP de diferentes llamadas se dirigen a una única dirección IP, correspondiente a dicha tarjeta DSP, el sistema diferencia los paquetes corresponden a cada llamada a través del número de puerto UDP. Lógicamente, en el caso del proveedor de VoIP Sarenet, el número de puertos utilizados de forma dinámica tiene que ser considerablemente mayor, ya que al utilizar un SBC (Session Border Controller) todo el tráfico RTP de voz entre llamadas de sus clientes pasa a través de dicho SBC.

Puertos UDP utilizados en Asterisk_1Puertos UDP utilizados en el tráfico RTP por la NCP500

Cuando la PBX IP desde la que se realizan las llamadas está basada en Asterisk, también se utilizarán diferentes puertos UDP seleccionados de forma dinámica dentro de un determinado rango, pero dentro de la filosofía de funcionamiento de Asterisk, totalmente configurable por el usuario. Este rango de valores de puertos UDP está fijado en el fichero de configuración /etc/asterisk/rtp.conf

Puertos UDP utilizados en Asterisk_2

 archivo rtp.conf

Como se observa en la configuración por defecto del archivo rtp.conf,  Asterisk utiliza puertos UDP comprendidos entre 10000 y 20000. Si realizamos una captura de paquetes en una llamada recibida desde un interlocutor externo hacia un sistema Asterisk con la configuración del archivo rtp.conf mostrada anteriormente, observaremos lo siguiente:

Puertos UDP utilizados en Asterisk_3

LLamada entrante desde Sarenet a un sistema Asterisk 

En la captura de paquetes anterior se observa que, una vez finalizada la fase de señalización mediante el protocolo SIP, comienza el transporte de voz mediante el envío de paquetes RTP entre Sarenet (194.30.0.111) y el sistema Asterisk (192.168.1.200). Si examinamos los puertos UDP utilizados en dicho tráfico RTP observaremos lo siguiente:

Puertos UDP utilizados en Asterisk_4

Paquete RTP enviado desde Asterisk hacia Sarenet

Puertos UDP utilizados en Asterisk_5

Paquete RTP enviado desde Sarenet hacia Asterisk

Vemos en las capturas anteriores como Asterisk utiliza el puerto UDP número 16088, comprendido en el rango entre 10000 a 20000. Sarenet utiliza el puerto 54026. Recordemos que la información relativa a los puertos que se utilizarán en el tráfico RTP es pasada durante la fase de señalización entre los elementos SIP que intervienen en una llamada SIP, en este caso, el proveedor de VoIP Sarenet y el sistema Asterisk.

Puertos UDP utilizados en Asterisk_6

Puerto UDP a utilizar para audio dentro del mensaje Invite desde Sarenet a Asterisk

Puertos UDP utilizados en Asterisk_7

Puerto UDP a utilizar para audio dentro del mensaje OK desde Asterisk a Sarenet

Si ahora modificamos el rango de valores de puertos UDP utilizados dentro del archivo rtp.conf y fijamos un rango más reducido, por ejemplo de 10000 a 10010, observaremos lo siguiente:

Puertos UDP utilizados en Asterisk_8

Nueva configuración del archivo rtp.conf

Puertos UDP utilizados en Asterisk_9

Paquete RTP enviado desde Asterisk hacia Sarenet

Se observa con claridad que ahora el número de puerto UDP utilizado, el 10008, está en el rango seleccionado en el archivo rtp.conf y lo mismo sucede si examinamos los paquetes RTP enviados desde Sarenet hacia nuestro Asterisk. Las conclusiones que podemos obtener son las siguientes:

  • A la hora de “abrir” puertos en el cortafuegos o firewall de la organización cuando deseamos permitir llamadas desde un sistema Asterisk, es necesario establecer en primer lugar cuantos puertos abiertos son realmente necesarios y ajustar en consecuencia dicho valor en el archivo rtp.conf.
  • El puerto 5060 será necesario abrirlo en todos los casos, ya que es el puerto utilizado por defecto en la señalización SIP.
  • Deberemos de asegurarnos de abrir los puertos UDP que utiliza el proveedor de VoIP cuando nos envía paquetes RTP de audio. En un cortafuegos de tipo doméstico esto no será casi nunca un problema, ya que por defecto suelen tener permitida cualquier entrada desde cualquier dirección IP a la que se ha salido previamente.  Como Asterisk se está registrando periódicamente en nuestro proveedor de VoIP, existe esa “salida” hacia la dirección IP desde la que llegan paquetes RTP de audio. Pero el cortafuegos de una organización puede ser mas restrictivo, y puede permitir todo el tráfico entrante desde una dirección IP  a la que se ha “salido” previamente, pero solo cuando esos paquetes entrantes vienen de determinados puertos TCP o UDP. Si este es el caso, comprobaremos que en una llamada IP, a pesar de que la señalización finaliza con éxito, una vez establecida la llamada, faltará el audio de entrada, de salida o ambos, dependiendo de las restricciones programadas en dicho cortafuegos.
Publicado en Telefonía IP | Deja un comentario

Configuración práctica de Asterisk (4ª parte): Cambio de idioma en los mensajes de audio de Asterisk

Cuando se instala por primera vez Asterisk con los parámetros por defecto, los mensajes de audio de Asterisk se reproducen siempre en el idioma ingles, tal y como se muestra en el siguiente vídeo cuando un usuario quiere consultar el buzón de voz de su extensión:

Para cambiar el idioma de los mensajes en Asterisk a español, por ejemplo, lo primero que debemos de hacer es descargar de algún repositorio dichos archivos de audio. En esta práctica se han elegido los paquetes de sonidos en español que están disponibles www.asterisksounds.org

Asterisk_configuracion_practica_parte4_1

Antes de descargar los paquetes de sonidos y descomprimirlos, necesitamos crear un directorio donde se deberán depositar dichos archivos de audio. En la web anterior se propone crear una carpeta de nombre es  en /var/lib/asterisk/sounds, pero atención, esta información se refiere a versiones anteriores de asterisk donde efectivamente los archivos de audio se situaban en dicho lugar. En la versión 11.7.0 de Asterisk, los archivos de audio están por defecto en el directorio  /usr/share/asterisk/sounds

Asterisk_configuracion_practica_parte4_2

En cualquier caso, la ruta donde se localizan dichos archivos de audio se puede consultar siempre dentro del fichero asterisk.conf en la variable astdatadir (para más información sobre el significado del resto de variables consultar la estructura de ficheros y directorios en la siguiente wiki de Asterisk)

Asterisk_configuracion_practica_parte4_3

Por lo tanto, creamos un directorio de nombre es en dicha ruta:

Asterisk_configuracion_practica_parte4_4

Nos situamos dentro de ese directorio:

cd /usr/share/asterisk/sounds/es

descargamos el  primer paquete de audio:

  • wget -O core.zip http://www.asterisksounds.org/es-es/download/asterisk-sounds-core-es-ES-sln16.zip

Asterisk_configuracion_practica_parte4_9

 Proceso de descarga del primer paquete de ficheros de audio

Y a continuación descargamos el segundo paquete:

  • wget -O extra.zip http://www.asterisksounds.org/es-es/download/asterisk-sounds-extra-es-ES-sln16.zip

Asterisk_configuracion_practica_parte4_10

Proceso de descarga del segundo paquete de ficheros de audio

Una vez descargados los paquetes de audio,  si examinamos el contenido del directorio es encontraremos lo siguiente:

Asterisk_configuracion_practica_parte4_11

procedemos a descomprimir los ficheros core.zip extra.zip:

  • unzip core.zip
  • unzip extra.zip

Asterisk_configuracion_practica_parte4_12

Proceso de extracción de ficheros desde core.zip

(Nota importante: Si unzip no está instalado en el sistema, se debe de instalar mediante la orden sudo apt-get install unzip)

Una vez hecho esto, nos encontraremos en el directorio es con cientos de ficheros de audio y que curiosamente tienen el nombre en ingles. Esto es porque en Asterisk todos los ficheros de audio, independientemente del idioma en que estén, tienen el mismo nombre en ingles. De esta manera, a Asterisk solo le tenemos que indicar en que directorio tiene que buscar los archivos de audio, porque los nombres siempre van a ser los mismos

Asterisk_configuracion_practica_parte4_5

Parte de los archivos de audio del directorio es

Es de señalar igualmente que en este directorio es también nos vamos a encontrar con subdirectorios para archivos de audio específicos, como por ejemplo el subdirectorio digits, donde encontraremos los archivos de audio para los sonidos 0,1, 2, 3, 4……..9 y otros muchos más:

Asterisk_configuracion_practica_parte4_6

 Parte de los archivos de audio del directorio digits

Y una vez hecho todo lo anterior, ya solo resta acudir al fichero de configuración sip.conf e indicarle a Asterisk en la sección general que los archivos de audio del sistema los debe de buscar en el directorio es, en lugar del directorio en, que es el correspondiente al idioma ingles.

Asterisk_configuracion_practica_parte4_7

 Configuración de sip.conf con language=en

Asterisk_configuracion_practica_parte4_8

Configuración de sip.conf con language=es

Y si ahora repetimos la acción de consultar el buzón de voz de una extensión, tal y como se ha hecho al comienzo de esta entrada en el blog, el resultado tiene que ser el siguiente:

Si se observa con detalle el CLI en ambos vídeos, se aprecia que el nombre de los ficheros de audio que se están reproduciendo es siempre el mismo, da igual que la reproducción sea en un idioma o en otro. Lo único que cambia es el directorio donde Asterisk buscará dichos ficheros de audio.

Publicado en Telefonía IP | Deja un comentario

Configuración práctica de Asterisk (3ª parte): Buzones de voz

A diferencia de lo que sucede con las PBX clásicas, añadir un buzón de voz en Asterisk es relativamente fácil. Los buzones de voz en Asterisk se controlan mediante las dos siguientes aplicaciones: VoiceMail() y VoiceMailMain()

  • VoiceMail():Permite al llamante dejar un mensaje de voz en el buzón de la extensión llamada cuando ésta no atiende la llamada en un tiempo determinado
  • VoiceMailMain():Permite al propietario de un buzón recuperar los mensajes y cambiar el tipo de saludo del buzón

La aplicación VoiceMail() tiene dos parámetros:

  1. Mailbox: es un número asignado al buzón de voz, seguido de forma opcional por el símbolo @ y un nombre de contexto del buzón de voz, como por ejemplo 6001@default. El sistema de “contextos” de Mailbox es independiente del sistema de “contextos” del fichero extensions.conf. En la aplicación Mailbox los contextos se utilizan para agrupar los distintos buzones de voz en función de los usuarios que van a acceder a ellos. Por ejemplo, se utilizan contextos cuando un mismo servidor de Asterisk va a dar servicio de telefonía y buzones de voz a varias empresas, o cuando dentro de una misma empresa queremos tener los buzones de voz de los empleados separados por departamentos.
  2. Options: Son opciones que se añaden a las características que presenta el buzón al que llama y que típicamente son u para reproducir un mensaje de “no disponible”, b para reproducir el mensaje de “ocupado” y s para saltar las instrucciones generadas por el sistema.

La aplicación VoiceMailMain() tiene también dos parámetros:

  1. Mailbox: es un número asignado al buzón de voz, seguido de forma opcional por el símbolo @ y un nombre de contexto del buzón de voz, como por ejemplo 6001@default.
  2. Options: Son opciones que se añaden a las características que presenta el buzón al propietario del buzón. La mas utilizada es s  y sirve para saltar la petición del PIN al propietario para acceder a su buzón (atención, con esta opción cualquiera que puede acceder a una extensión podría también acceder a su buzón de voz).

La configuración de los buzones de voz se realiza sobre el fichero voicemail.conf, el cual tiene tres secciones principales:

  • General: Aquí se controlan aspectos generales de los buzones de voz, como el número máximo de mensajes por cada buzón de voz, la máxima longitud de cada mensaje y otras características similares.
  • Zonemessages: En esta sección se definen zonas de tiempo para cada buzón de voz
  • Context: Después de las secciones de General y Zonemessages, cualquier otro nombre entre corchetes es un nombre de contexto. En cada contexto se pueden definir uno o más buzones de voz. Para cada buzón de voz se debe de indicar un número de buzón de voz, un PIN, el nombre del propietario, una dirección de email para las notificaciones y una lista de opciones separadas.

Ejemplo: Si en el fichero voicemail.conf dentro del contexto [default] creamos los tres siguientes buzones:

Asterisk_configuracion_practica_parte3_1

al ejecutar el comando voicemail show users dentro del CLI obtenemos lo siguiente:

Asterisk_configuracion_practica_parte3_2

A continuación en el fichero sip.conf  debemos de configurar los buzones de voz de cada extensión solo cuando se utilicen extensiones IP físicas.  Esto se debe a que los teléfonos físicos IP se comunican con Asterisk mediante el protocolo SIP y por tanto debe de quedar definido que teléfono tiene un buzón de voz. Asterisk enviará notificaciones a las extensiones cuando tengan mensajes de voz en su buzón.

Asterisk_configuracion_practica_parte3_3

Por último, en el fichero extensions.conf debemos de configurar que sucederá cuando algún usuario llame a las extensiones de los buzones de voz y también deberemos de crear nuevas extensiones que permitan a los propietarios de cada buzón acceder a dichos buzones para recuperar los mensajes que contienen. En el ejemplo práctico que se está utilizando en este blog para las prácticas de configuración de Asterisk, tenemos la extensión 201 dentro del contexto de “operadora” y las extensiones 202, 203 y 204 dentro del contexto de “trabajadores”. La configuración de los buzones de voz para la extensión 201 es la siguiente:

Asterisk_configuracion_practica_parte3_4

Se observa que cuando la operadora llame a las extensiones 202, 203 o 204, si estas no descuelgan la llamada en 15 segundos, la llamada será dirigida al correspondiente buzón de voz de cada extensión (buzón 202@default para la extensión 202, buzón 203@default para la extensión 203 y buzón 204@default para la extensión 204). Finalmente, se ha establecido el código 301 para que la operadora pueda consultar su buzón de voz, que es el 201@default. Para las extensiones 202, 203 y 204 hay que realizar algo similar dentro de su contexto, tal y como se muestra a continuación:

Asterisk_configuracion_practica_parte3_5

En el siguiente vídeo se observa de forma práctica lo que sucede cuando la extensión 201 llama a la extensión 203 y ésta no atiende la llamada en 15 segundos:

Y en este otro vídeo se observa como la extensión 203 puede consultar su buzón de voz mediante el código 303 y el PIN 1234:

En cualquier momento un usuario puede configurar fácilmente su buzón de voz mediante un menú asistido por locuciones:

Las opciones de configuración y ejemplos mostrados en esta entrada del blog corresponden solamente al funcionamiento básico de los buzones de voz en Asterisk. En realidad, las posibilidades son muchísimo mayores y las opciones de configuración en el fichero voicemail.conf son sencillamente, abrumadoras.

Publicado en Telefonía IP | Deja un comentario

Configuración práctica de Asterisk (2ª parte): Otras “options” de la aplicación Dial()

Una de las “options” en la aplicación Dial() de Asterisk es A(x), la cual fuerza a Asterisk a reproducir el mensaje de audio en una determinada extensión cuando ésta descuelga la llamada. La utilidad de esta opción puede ser el reproducir un mensaje de audio en la extensión llamada del estilo de “le recordamos que por motivos de seguridad esta conversación puede ser grabada…….”. Un ejemplo práctico de esta opción sería el mostrado a continuación:

Asterisk_configuracion_practica_parte2_1

 Como se observa, las options incluidas en la aplicación Dial() son tTA y todas ellas van una a continuación de otras, sin espacios ni ningún símbolo separador entre ellas. El parámetro de la opción A es la ruta del fichero de audio a reproducir y se coloca entre paréntesis inmediatamente a continuación de la propia opción. En el ejemplo indicado, cuando una extensión que esté situada en el contexto de operadora marque un número como *202, *203 y *204, la aplicación Dial() llamará a dicha extensión y en cuanto la llamada sea descolgada reproducirá el mensaje de audio indicado como parámetro. En el siguiente vídeo se observa de forma práctica este proceso:

 Se observa no obstante que mientras se está reproduciendo el mensaje de audio se sigue escuchando el tono de llamada de la extensión 201 a la 203. Esto es debido a que Asterisk no establece el canal de llamada entre ambas extensiones hasta que la extensión 203 termina de reproducir el mensaje de audio. Para evitar este efecto no deseado se debe de utilizar la opción a de la aplicación Dial().  Esta opción solamente se utiliza en estos casos especiales donde la extensión llamada tiene que realizar alguna acción cuando recibe una llamada. En el resto de casos no será necesario. La sintaxis con esta corrección queda de la forma siguiente:

Asterisk_configuracion_practica_parte2_2

En el siguiente vídeo se observa el funcionamiento práctico con esta nueva opción en la aplicación Dial():

Otra de las opciones comunes en cualquier PBX clásica es la que permite ajustar la duración de una llamada. Esta función se utiliza normalmente en llamadas salientes a fin de reducir el gasto en el servicio telefónico, pero también se puede utilizar incluso en llamadas internas, a fin de optimizar el uso del servicio telefónico. Asterisk permite una configuración muy sofisticada mediante la opción L de la aplicación Dial(). Esta opción admite además tres parámetros x,y,z cuyo significado se explica a continuación:

  • L(x[:y][:z]): Limita la llamada a “x” milisegundos, lanzando un aviso de warning a “y” milisegundos, repitiendo este warning cada “z” milisegundos. Solo el parámetro “x” es requerido siendo “y” y “z” opcionales. En cualquier caso tienen que ser numeros enteros.

Para dar mas opciones a esta función de limitación de tiempo de llamada, las siguientes variables afectan a dicho proceso de limitación de tiempo de llamada

  • LIMIT_PLAYAUDIO_CALLER=yes|no: Especifica si el llamante (el que tiene la restricción de tiempo de llamada) escuchará los tonos de aviso de límite de llamada. Por defecto esta variable está en “yes”
  • LIMIT_PLAYAUDIO_CALLEE=yes|no: Idem para el destinatario de la llamada.
  • LIMIT_TIMEOUT_FILEfilename: Especifica que fichero de audio se reproducirá al finalizar el tiempo de llamada
  • LIMIT_CONNECT_FILEfilename: Especifica que fichero de audio se reproducirá al comenzar la llamada
  • LIMIT_WARNING_FILEfilename: Especifica que fichero de audio se reproducirá al cumplirse el tiempo de warning si es que dicho tiempo ha sido fijado. Si dicho fichero no existe, se reproducirá un mensaje donde se indicará “You have XX minutes YY seconds”

Un ejemplo práctico de esta opción requiere en primer lugar grabar los mensajes de audio correspondientes y a continuación introducir esta opción junto con los parámetros deseados en cada una de las aplicaciones Dial() donde deseemos limitar el tiempo de llamada, dentro de nuestro DialPlan. En la siguiente captura de pantalla se muestra un ejemplo:

Asterisk_configuracion_practica_parte2_3

Se puede observar que se utilizarán dos ficheros de audio, uno al principio de la llamada y otro al finalizar la misma. Para ello se han ajustado las variables LIMIT_CONNECT_FILE y LIMIT_TIMEOUT_FILE con la ruta a los ficheros de audio que se deben de reproducir. El tiempo de límite de llamada se ha ajustado a 50 segundos, con un aviso de warning cuando falten 20 segundos y con avisos repetidos cada 10 segundos. Se han puesto limitaciones de tiempo muy reducidas por tratarse de un ejercicio puramente didáctico. En el siguiente vídeo se observa su funcionamiento práctico

Como era de esperar, las posibilidades de programación de Asterisk superan a las que ofrecen la mayoría de las PBX convencionales, ya que en dichas centralitas, normalmente, el aviso se limita a un tono de “beep” al alcanzarse el tiempo de Warning y con posterior repetición de dicho tono a intervalos determinados hasta el agotamiento del tiempo de llamada. No es frecuente que una PBX convencional incorpore la posibilidad de añadir mensajes de audio de la forma en que lo permite Asterisk.

Publicado en Telefonía IP | Deja un comentario

Configuración práctica de Asterisk (1ª parte): La aplicación Dial()

A lo largo del curso 2016/17, dentro del módulo de “Sistemas de Telefonía” del ciclo formativo de “Sistemas de Telecomunicación e Informáticos”, queremos continuar con las prácticas iniciadas en el pasado curso 2015/16 referentes a la instalación, configuración y mantenimiento de sistemas PBX basados en Asterisk. Para ello, los alumnos deberán de utilizar las diferentes aplicaciones incluidas en Asterisk, aplicaciones que forman parte del núcleo de Asterisk y que hacen del mismo un sistema extremadamente potente. Las aplicaciones soportadas por una versión determinada de Asterisk pueden ser consultadas en el CLI mediante la orden core show applications, tal y como se muestra en la siguiente captura de pantalla:

Asterisk_configuracion_practica_0

Aplicaciones de Asterisk

En la versión 11.7.0 de Asterisk son 176 las aplicaciones soportadas y entre todas ellas la aplicación Dial() es, con seguridad, la más importante. El manejo de esta aplicación para realizar una llamada a un determinado usuario es muy simple: la aplicación Dial() simplemente verifica el número marcado por un usuario en un determinado contexto y si coincide con el patrón establecido, procede a realizar la llamada mediante el canal programado a la extensión o extensiones fijadas dentro de los parámetros. En la siguiente captura de pantalla se muestra dos ejemplos simples de dicha aplicación Dial(). En el primero de ellos, si una extensión que está dentro del contexto de “trabajadores” marca el número 201, Asterisk realizará una llamada mediante el protocolo SIP a la extensión 201. En el segundo ejemplo, si una extensión que está dentro del contexto de “trabajadores” marca el número 81, Asterisk llamará de forma simultánea a las extensiones 201 y 202, en ambos casos mediante el protocolo SIP

Asterisk_configuracion_practica_1

Pero la aplicación Dial() es también extremadamente potente y compleja, con un buen número de opciones que ayudan a construir una PBX con Asterisk con tantas o más funcionalidades que una PBX “convencional” de alta gama. La sintaxis completa de la función Dial() es la siguiente:

Asterisk_configuracion_practica_2

Sintaxis de la aplicación Dial(). Wikipedia

Como se observa, son 4 los tipos de parámetros que admite la aplicación Dial(). En primer lugar se indican las diferentes tecnologías y recursos a donde se realizará la llamada. En el ejemplo anterior eso corresponde a (SIP/201) y también a (SIP/201&SIP/202).  A continuación el segundo parámetro opcional es timeout. Este parámetro especifica en segundos el tiempo durante el cual se intentará realizar la llamada. Si no se especifica ningún tiempo, el sistema intentará realizar la llamada de forma indefinida (en realidad, 136 años) hasta que el usuario llamado responda, cuelgue la llamada o el usuario llamado aparezca en modo ocupado o rechazando la llamada. Un ejemplo de programación de este parámetro de timeout se muestra a continuación:

Asterisk_configuracion_practica_3Como se observa, el parámetro de timeout se ha fijado en 15 segundos. Cuando una extensión del contexto de “trabajadores” marque el número 201, Asterisk realizará una llamada SIP a la extensión 201 y si en 15 segundos nadie atiende la llamada, la colgará automáticamente. En la siguiente captura del CLI se observa dicho proceso:

El tercer parámetro de la aplicación Dial() son las denominadas options y pueden ser consultadas en el CLI mediante la orden core show application dial:

Asterisk_configuracion_practica_4

Son muchas las options que están disponibles, algunas son fáciles de entender y otras no tanto. Las diferentes options se escriben unas a continuación de otras sin ningún tipo de separación y si alguna opción lleva parámetros, estos se colocan entre paréntesis. Algunos ejemplos de opciones son las indicadas a continuación:

  • A(x): Reproduce un mensaje de audio a la parte llamada. El fichero de audio que se reproduce es el indicado por “x”
  • H: Permite al usuario llamado colgar la llamada pulsando la tecla “*”
  • h:Permite al usuario llamante colgar la llamada pulsando la tecla “*” Nota: En ambos casos * está definido en features.conf -> featuremap -> disconnect
  • i: Asterisk ignorará en las llamadas a grupo cualquier intento de desvío de llamada, por ejemplo a un buzón de voz. De esta forma, la llamada a grupo sonará en el grupo y podrá ser atendida por alguno de los miembros del grupo. (si en un grupo alguno de los teléfonos tiene activado el desvío inmediato a un buzón de voz, las llamadas a dicho grupo no sonarán, al activarse automáticamente ese desvío y ser atendida la llamada)
  • j: Asterisk  salta a la prioridad n+101 si todos los canales utilizados para la function DIAL están ocupados
  • K: Permite a la parte llamante activar la function “parking of the call” enviando la correspondiente secuencia DTMF para parking de llamadas definida en features.conf.
  • k: Permite a la parte llamada activar la function “parking of the call” enviando la correspondiente secuencia DTMF para parking de llamadas definida en features.conf
  • L(x[:y][:z]): Limita la llamada a “x” milisegundos, lanzando un aviso de warning a “y” milisegundos, repitiendo este warning cada “z” milisegundos. Solo el parámetro “x” es requerido siendo “y” y “z” opcionales. En cualquier caso tienen que ser numeros enteros
  • S(n): Cuelga la llamada n segundos después desde que la parte llamada ha descolgado la llamada.
  • T: Permiso de transferencia de llamada para la parte llamante.
  • t: Permiso de transferencia de llamada para la parte llamada.
  • W: Permite a la parte llamante comenzar la grabación de la llamada después de presionar *1 o lo que esté definido en features.conf
  • w: Permite a la parte llamada comenzar la grabación de la llamada después de presionar *1 o lo que esté definido en features.conf

Veamos a continuación unos ejemplos prácticos, empezando por una de las opciones más básicas con las que cuenta cualquier PBX, las transferencias de llamadas. En Asterisk esto se consigue con las opciones Tt las cuales dan permiso a la parte llamante y a la parte llamada respectivamente para realizar una transferencia de la llamada. Asterisk dispone de dos tipos de transferencia:

  • Blind Transfer: En esta opción el usuario que inicia la transferencia marca el número de destino y tan pronto como este comienza a sonar, cuelga la llamada. La transferencia se realizará de forma automática a la extensión llamada sin que haya habido ningún tipo de diálogo entre el que transfiere la llamada y el usuario del teléfono a donde va a ser transferida
  • Attended Transfer: En esta opción el usuario que inicia la transferencia marca el número de destino y debe de esperar a que en dicha extensión la llamada sea descolgada. En ese momento, puede colgar su teléfono y la llamada será transferida.

Aunque los códigos para realizar las transferencias de llamada son absolutamente personalizables, por defecto Asterisk incluye unos códigos que pueden ser consultados en el fichero de configuración Features.conf. Para conocer el estado de las Features, en el CLI de asterisk podemos escribir la orden features show. Aparecerá algo como lo siguiente:

Asterisk_configuracion_practica_5

Vemos que la opción de Blind Transfer se ejecutará mediante el código #1 y la opción Attended Transfer mediante el código *2.  En el fichero extensions.conf deberemos de escribir en las aplicaciones de tipo Dial() donde se van a permitir las transferencias, algo como lo siguiente:

Asterisk_configuracion_practica_6

En este caso, cuando desde una de las extensiones que esté en el contexto indicado, en este caso la extensión de operadora, se llame a las extensiones 202 o 203, se permitirán ambos tipos de transferencias. En el siguiente vídeo se muestra el funcionamiento práctico de la transferencia BlindTransfer. Observar que en cuanto la extensión 201 introduce el código de transferencia de llamada, #1 en este caso, Asterisk espera a continuación un número de extensión para proceder con la transferencia. En el momento en que se introduce un número de extensión válido, Asterisk realiza la transferencia y la llamada en la extensión 201 es colgada automáticamente:

Para que las transferencias funcionen es imprescindible que el flujo RTP de audio pase por Asterisk y no vaya de forma directa entre extensiones. Esto es así porque los tonos DTMF utilizados para la señalización van dentro del flujo de audio RTP. Para conseguirlo, en el fichero SIP.CONF es necesario indicar la opción canreinvite=no

Observar también que los mensajes de audio de Asterisk se reproducen en Español, pero eso no es lo que sucede cuando se instala Asterisk por primera vez. Más adelante en este mismo blog se verá como cambiar todos los mensajes de audio de Asterisk al idioma deseado.

Por último y aunque en el vídeo anterior no se aprecia, es posible indicar que la música en espera cuando se realiza la transferencia se elija de forma aleatoria de una serie de ficheros de audio. Para ello, en el fichero musiconhold.conf deberemos de configurar que la música en espera se reproduzca en modo random:

Asterisk_configuracion_practica_7

Además, deberemos dejar en la carpeta donde Asterisk buscará la música en espera, los diversos ficheros de música que queremos que se reproduzcan en modo random. En nuestro caso hemos colocado varios archivos de música, todos en formato wav. El nombre de dichos archivos es indiferente, ya que Asterisk los irá utilizando en modo random

Asterisk_configuracion_practica_8

Con esto finaliza esta entrada del blog dedicada a los aspectos básicos de la aplicación Dial(). En posteriores entradas se irán analizando el resto de las options.

Publicado en Telefonía IP | Deja un comentario

Prácticas de telefonía IP de los alumnos de 1 STI del Instituto Tartanga: Instalación y configuración de un sistema Asterisk

Una vez que los alumnos de 1 STI (Sistemas de Telecomunicación e Informáticos) han realizado diversas prácticas de instalación y configuración de PBX IP mediante distribuciones “todo-en-uno” como son Elastix y FreePBX, ha llegado el momento de realizar igualmente la instalación y configuración de una PBX IP basada en un Asterisk “puro”. Para ello se ha seleccionado la versión 14.04.4 LTS de Ubuntu Server y la versión de Asterisk LTS 13.1- cert4, todo ello virtualizado sobre VMware corriendo en equipos con Windows 7.

asterisk_1

 Ubuntu Server 14.04.4 LTS

asterisk_2

 Asterisk LTS 13.1-cert4 (actualizada a la 11.7.0)

Junto con Asterisk se ha instalado también las librerias DAHDI en su versión 2.11.1 y las librerías libpri en su versión 1.5.0.  Las librerías DAHDI (Digium/Asterisk Hardware Device Interface) permiten el funcionamiento de diversas tarjetas fabricadas por Digium para incluir en la centralita Asterisk líneas y extensiones analógicas  accesos básicos RDSI. Estas librerías también permiten el funcionamiento de diversas tarjetas de otros fabricantes. Por otro lado, las librerías libpri dan soporte a la conexión de la centralita Asterisk con accesos primarios, tanto en su versión Europea (E1) como en las versiones para EEUU (T1) y Japón (J1)

asterisk_3

Librerías dahdi y libpri instaladas

En la instalación de Asterisk hemos optado por no incorporar tampoco la nueva librería SIP denomina PJSIP. La versión tradicional de la librería SIP ha sido criticada a veces por ser una librería inestable y por estar escrita de una forma que no facilita la evolución y depuración de errores en la misma. Los desarrolladores de Asterisk han optado por introducir una nueva librería SIP, denominada PJSIP. Esta librería obliga a escribir de forma diferente determinadas porciones de código en los ficheros de configuración de Asterisk (extensions.conf, sip.conf y otros). Aunque desde Asterisk se promueve la utilización de esta nueva librería, Asterisk puede seguir funcionando con la librería nativa de SIP, y eso es lo que hemos hecho en la clase de Sistemas de Telefonía. Más adelante, sin duda que daremos el paso e instalaremos Asterisk con PJSIP, porque parece claro que es el camino a seguir.

Asterisk_3a

Libreria PJSIP

Una vez que el sistema ha arrancado, accedemos a la carpeta /etc/asterisk y procedemos a la edición “desde cero” de los ficheros de configuración sip.conf extensions.conf. En el fichero sip.conf definimos:

  • Las diversas extensiones de la PBX. Cada extensión debe de estar en un “contexto”, que es un concepto equivalente a una “clase de servicio” de las PBX tradicionales.
  • Los enlaces SIP, tanto con operadores de VoIP como Sarenet, como con otras PBX IP. Cada uno de estos enlaces o “trunks” IP se identifica por un nombre, que será usado para enrutar las llamadas salientes. Además, cada enlace o “trunk” IP tendrá también un “contexto” definido y que existirá también en el fichero extensions.conf. En dichos contextos de entrada se “enrutaran” las llamadas entrantes a la PBX Asterisk.

El fichero extensions.conf o Dial Plan, verdadero núcleo de un sistema Asterisk, contendrá información como la siguiente:

  • Para cada uno de los contextos de las extensiones, secuencia de acciones a realizar en función de los diversos patrones de marcado (si la extensión marca 1XX haz esto, si la extensión marca 9XX haz esto otro, si marca 803X prohibe la llamada, etc)
  • Para cada uno de los contextos de los enlaces o “trunk”, secuencia de acciones a realizar con cada llamada entrante (dirigir la llamada directamente a una extensión, dirigir la llamada a un grupo de extensiones, dirigirla hacia una “operadora automática, etc)
  • Para cada uno de los identificadores de enlaces o “trunk” dirigir las llamadas de determinadas extensiones en función del patrón marcado (si la extensión marca 6XX sal por el enlace de Sarenet, si marca 9XX sal por el enlace de este otro proveedor de VoIP, si marca 2XX sal por el enlace que comunica con otra PBX IP de la empresa, etc)

 asterisk_4Carpeta /etc/asterisk con los ficheros de configuración sip.confextensions.conf

asterisk_5

Fragmento de código del fichero sip.conf

asterisk_6

Fragmento de código del fichero extensions.conf

El resultado de la programación de estos dos ficheros, junto con algunas otras cosas que también es necesario modificar, es el mostrado en los siguientes vídeos, grabados en el aula de telefonía del Instituto Tartanga:

Llamada a grupo de extensiones con mensaje de audio incorporado

Llamada saliente a móviles con mensaje de audio incorporado


Llamada saliente a fijos con mensaje de audio incorporado

Llamada entrante a operadora automática

Llamada entrante a operadora automática y con transferencia a extensión de operadora

El código que hemos utilizado en estas primeras prácticas con Asterisk es un código básico, sin macros, sin aplicaciones de cierta complejidad, sin uso de variables, sin utilización de AGI (Asterisk Gateway Interface) que nos permite añadir código en lenguajes como PHP, Java, Phyton y otros, sin consultas a bases de datos como mysql, sin manejo de colas, buzones de voz, informes de llamadas y sin muchas otras cosas mas.

Asterisk_6a

Integración en Asterisk de diversos lenguajes de programación

Estamos solo al comienzo y la potencia y versatilidad de Asterisk necesitaría de una dedicación de horas lectivas que, sin duda, superaría con mucho a las horas disponibles en la programación del módulo de Sistemas de Telefonía para todo el curso. A continuación se muestran unos ejemplos de código programado en el fichero extensions.conf y que corresponde a los vídeos mostrados anteriormente:

asterisk_6Inicio del fichero extensions.conf

asterisk_8

Código de extensions.conf para la grabación de los diferentes mensajes

asterisk_9

Contexto de “trabajadotes” en el fichero extensions.conf 

Tal y como se observa en los ejemplos, es extremadamente fácil construir una operadora automática “a medida” en Asterisk, con cualquier configuración de niveles y con cualquier número de mensajes de audio, cosa que con una centralita tradicional, no es posible. De la misma manera, es muy fácil también establecer restricciones de llamadas para cualquier esquema que se nos ocurra e igualmente es prácticamente inmediato establecer un sistema de enrutamiento de llamadas tan complejo y sofisticado como nos apetezca. Tan solo es necesario escribir el código adecuado en los ficheros de configuración correspondientes.

Como resumen, solo cabe decir que la experiencia del trabajo con Asterisk está siendo muy positiva por los siguiente motivos:

  • Los alumnos están viendo como funciona y como se configura una centralita con Asterisk “puro” sin la ayuda de interfaces gráficos como los de FreePBX o Elastix
  • También los alumnos están aplicando en la práctica los conocimientos adquiridos en el módulo de Sistemas Operativos y Redes en cuanto al manejo de un sistema operativo Linux desde la línea de comandos. Ahora comienza a tener sentido lo que han estudiado meses atrás…..
  • Una configuración con un sistema Asterisk es muchísimo más potente y versatil que la que se pueda realizar con una solución “todo-en-uno” con interface gráfico, como FreePBX o Elastix
  • Las configuraciones realizadas con Asterisk son configuraciones “óptimas”, es decir, los ficheros de configuración, como por ejemplo sip.conf y extensions.conf, tienen solo el código estrictamente necesario, nada mas.
  • Después de haber trabajado en clase con centralitas convencionales como la KXTD-816 de Panasonic o las TEA308, NCP500 o TDA200 del mismo fabricante, es fácil darse cuenta de que con un sistema Asterisk se puede hacer lo que hacen esas centralitas y mucho mas.

Y por último, al estar realizando todas las prácticas con sistemas virtualizados en VMware o en VirtualBox bajo Windows, los alumnos pueden montar estas centralitas en un ordenador de casa y realizar tantas configuraciones prácticas como deseen, llevando a cabo las pruebas sobre softphones como Zoiper, X-Lite o Phoner. Para varios de los alumnos está siendo muy motivador, ya que comprueban que están recibiendo una formación en sistemas de telefonía relativamente actual.

Prácticas con Asterisk y softphones en los portátiles del aula de telefonía

Seguiremos trabajando en esta línea. El próximo reto: Colocar en producción un sistema Asterisk en el Instituto de Formación Profesional Tartanga, virtualizado en alguna de las máquinas con Proxmox disponibles en el CPD del Instituto.

Publicado en Telefonía IP | Deja un comentario

Nuevas prácticas de telefonía IP con sistemas Open Source de los alumnos de 1 STI del Instituto Tartanga

Aunque en el Instituto Tartanga ya llevamos varios años impartiendo formación en VoIP, hasta ahora habíamos trabajado únicamente con soluciones de tipo “propietario”, como es el caso de la centralita NCP500 de Panasonic que tenemos disponible en el aula de telefonía. En esta centralita disponemos de:

  • Extensiones específicas digitales
  • Extensiones específicas IP de Panasonic.
  • Extensiones SIP también de Panasonic.
  • Licencias que permiten el funcionamiento de las extensiones IP y SIP y de softphones de Panasonic y de terceros, como por ejemplo Zoiper o X-Lite.
  • Extensiones DECT y dos antenas de dos canales cada una.

En cuanto a canales externos, en la NCP500 tenemos conectados:

  • Dos accesos básicos RDSI, uno de tipo punto a punto y otro de tipo punto a multipunto, disponiendo en total de 4 canales.
  • Enlace con el proveedor de VoIP Sarenet, mediante el cual disponemos de 10 canales SIP por los que podemos realizar llamadas salientes y recibir llamadas entrantes con total fiabilidad.
  • Enlace IP con la centralita que da servicio al instituto, una TDA200 de Panasonic. La conexión es mediante IP y protocolo H.323, permitiéndonos las llamadas internas entre las extensiones del instituto y las extensiones de la propia NCP500.

En resumen, una configuración suficiente para aprender el funcionamiento de una PBX actual dentro del módulo de Sistemas de Telefonía del ciclo formativo de grado superior de Sistemas de Telecomunicación e Informáticos (STI).

Telefonia IP con sistemas OpenSource_1

 Sistema PBX IP con la centralita NCP500 de Panasonic

En el campo de PBX IP basadas en soluciones Open Source (Asterisk, Elastix, FreePBX, AsteriskNow, etc) si que es cierto que en cursos anteriores ya habíamos realizado la instalación y configuración básica de una PBX con FreePBX, pero sin haber entrado a fondo en ello. Ahora, por fin, ha llegado el momento de dar un paso más hacia adelante, y en el actual curso 2015/2016 estamos impartiendo a los alumnos de 1 STI la instalación, configuración, puesta en marcha y mantenimiento de sistemas PBX basados en soluciones Open Source, con el mayor rigor posible dentro de las escasas horas con las que contamos en el módulo de Sistemas de Telefonía. Para este fin, hemos elegido en primer lugar distribuciones de tipo “todo en uno” y con un entorno gráfico de configuración,  como son las conocidas “distros” de Elastix, FreePBX o AsteriskNow. En una segunda etapa el objetivo es pasar a soluciones “puras” basadas en Asterisk, trabajando desde la línea de comandos del propio Asterisk y editando de forma manual los archivos de configuración.

Telefonia IP con sistemas OpenSource_2_3

                                           Elastix                                                    FreePBX

Telefonia IP con sistemas OpenSource_4_5

                                        AsteriskNOW                                    Asterisk

A la hora de realizar las instalaciones, se ha optado tanto por soluciones virtualizadas como por la utilización de servidores dedicados. Los sistemas de virtualización de uso libre como Vmware Player y VirtualBox nos ha permitido encargar a todos los alumnos la realización de un trabajo personal “para casa” donde cada uno de ellos debe de instalar y poner en marcha dos PBX IP, registrar extensiones IP en dichas PBX, utilizando softphones de uso libre también y finalmente deben de ser capaces de conectar ambas PBX por un canal de salida SIP de tal forma que se puedan realizar llamadas desde las extensiones de una PBX a extensiones de la otra PBX. En una posterior fase se les encargará que configuren la conexión con un proveedor de VoIP y que se enfrenten a las dificultades que pueden surgir con los firewall, los sistemas NAT, los routers con ALG y todas esas otras circunstancias que acompañan de forma ineludible a la telefonía IP.

Telefonia IP con sistemas OpenSource_6

Propuesta de instalación para realizar por los alumnos en casa

 Telefonia IP con sistemas OpenSource_7Ejemplo de virtualización de varias PBX IP en VMware 

Telefonia IP con sistemas OpenSource_8

 Arrancando un Elastix virtualizado en VMware

Telefonia IP con sistemas OpenSource_9

 Dos PBX IP ejecutándose de forma concurrente en VMware

Telefonia IP con sistemas OpenSource_10

 Las dos PBX IP en funcionamiento

Telefonia IP con sistemas OpenSource_11

Añadiendo una extensión en Elastix

Telefonia IP con sistemas OpenSource_12

Configurando un softphone Zoiper para registrarlo en la PBX IP

Telefonia IP con sistemas OpenSource_13

 Softphone Zoiper registrado en dos PBX

Telefonia IP con sistemas OpenSource_14

 Configurando un “Trunk” o enlace SIP

Telefonia IP con sistemas OpenSource_15

 Configurando la ruta cuando se marque un número 2XX

Telefonia IP con sistemas OpenSource_16

 Llamando desde la ext 101 a la 201

Telefonia IP con sistemas OpenSource_17

 Llamando desde la ext 201 a la 101

Como se ha indicado anteriormente, en el aula de telefonía del Instituto Tartanga los alumnos también tienen que realizar la instalación y configuración de PBX IP sobre servidores dedicados y extensiones SIP “físicas”.  Para ello utilizamos unos portátiles ya obsoletos pero que para esta función cumplen con creces su cometido y también utilizamos extensiones SIP de los modelos GrandStream y Linksys cedidos al Instituto Tartanga por una de las empresas líderes en telefonía IP y soluciones Open Source como es Irontec

Telefonia IP con sistemas OpenSource_18

 Instalación con servidores dedicados y extensiones SIP “físicas”

Telefonia IP con sistemas OpenSource_19

Teléfonos GrandStream y Linksys cedidos por Irontec

Telefonia IP con sistemas OpenSource_20

Ejemplo de configuración web de un teléfono Linksys

Telefonia IP con sistemas OpenSource_21

Ejemplo de configuración web de un teléfono GrandStream

Telefonia IP con sistemas OpenSource_22

Comprobación de la IP para los teléfonos GrandStream y Linksys

Telefonia IP con sistemas OpenSource_23

Comprobación en la consola de comandos de Asterisk del correcto registro de las extensiones 101, 102 y 103

Telefonia IP con sistemas OpenSource_24

Comprobación en la consola de comandos de Asterisk del correcto registro de las extensiones 201, 202 y 203

Telefonia IP con sistemas OpenSource_25

Llamada entre las extensiones 101 y 102 de la PBX con Elastix

Telefonia IP con sistemas OpenSource_26

Llamada entre las extensiones 202 y 203 de la PBX con FreePBX

Telefonia IP con sistemas OpenSource_27

Recibiendo una llamada en la ext 101 (Elastix) desde la ext 202 (FreePBX)

Por último, una vez solucionado el problema de las llamadas internas y el problema de las llamadas entre centralitas, los alumnos deberán de configurar la PBX para permitir llamadas al exterior a través de un proveedor IP y de recibir llamadas del exterior, mediante un número geográfico contratado con dicho proveedor de VoIP (Sarenet). En la configuración de la centralita deberán de crear y configurar adecuadamente un enlace o trunk, deberán de crear y configurar una ruta saliente y deberán de crear y configurar una ruta entrante tal y como se muestra en las siguientes imágenes:

Telefonia IP con sistemas Open Source_28

Configuración de un Trunk o enlace con Sarenet

Telefonia IP con sistemas Open Source_29

Configuración del Trunk. La clave secreta es suministrada por el proveedor de VoIP, en este caso la empresa Sarenet

Telefonia IP con sistemas Open Source_29a

Parámetros de registro del Trunk en Sarenet

Telefonia IP con sistemas Open Source_30

Configuración de la ruta para llamadas salientes

Telefonia IP con sistemas Open Source_31

Patrones de marcado que usarán la ruta saliente

Telefonia IP con sistemas Open Source_32

Configuración de la ruta de entrada

Telefonia IP con sistemas Open Source_32a

Destino de llamadas entrantes en la ruta de entrada

Como resumen de la práctica a realizar por los alumnos del módulo de Sistemas de Telefonía de 1 STI, en el siguiente vídeo se puede observar el funcionamiento conjunto de la instalación, con llamadas internas dentro de cada PBX, llamadas entre PBX y llamadas externas entrantes y salientes a través del proveedor de VoIP Sarevoz

Publicado en Telefonía IP | 1 comentario

Servicio suplementario de “Identificación de llamadas” en las líneas analógicas

Entre las múltiples opciones de configuración de la centralita Panasonic TEA308 se encuentra la referente a la Identificación de llamadas. Esta opción permite ver en el display del teléfono el número desde donde estamos recibiendo una llamada. La visualización de dicha información es posible tanto en los displays de los teléfonos específicos de la centralita y como en aquellos teléfonos regulares dotados de pantalla y compatibilidad con el sistema de identificación de llamadas.

Identificacion de llamadas_0

Sorprende a primera vista que sea necesario configurar algunos parámetros de significado dudoso para que pueda funcionar esta utilidad, ya que estamos acostumbrados a que en los teléfonos particulares la identificación de llamadas funcione sin ningún tipo de configuración o ajuste. De entre los parámetros que hay que configurar, el más importante sin duda, es el denominado Tipo de Identificación del Llamante, el cual nos da dos opciones posibles: FSK o Tonos

Identificacion de llamadas_0a

Para entender el significado de las opciones FSK o Tonos es necesario conocer los detalles técnicos del funcionamiento del servicio suplementario de Identificación de Llamadas. Este servicio suplementario está incluido desde el inicio en la telefonía RDSI y también en la telefonía IP, pero no en la telefonía analógica. El servicio suplementario de “Identificación de llamadas” es uno más de los disponibles en las líneas analógicas hoy en día, pero que en realidad son de relativamente reciente implantación:

Identificacion de llamadas_1

Interfaz de Línea Analógica de Telefónica de España (Movistar)

Identificacion de llamadas_2

Algunos de los servicios suplementarios disponibles sobre la línea analógica

El funcionamiento de este servicio suplementario de “Identificación de llamadas” requiere del uso de dos modem, uno en la central telefónica y otro en el propio teléfono del usuario. La información del número que nos está llamando es transmitido por el modem de la central hacia el modem del usuario en forma digital. Para ello se utiliza en la mayoría de los países una modulación FSK (Recomendación V23 de ITU) y un sistema de envío de la información basado en tres capas: Capa física, Capa de enlace y Capa de presentación:

Capa física

Identificacion de llamadas_3

Como se puede observar, la modulación FSK utilizada en la capa física asigna una frecuencia de 1300 Hz para enviar un “1” y una frecuencia de 2100 Hz para enviar un “0”. El código utilizado no es el habitual código ASCII, sino que se utiliza el código IRA, el cual usa únicamente 7 bits para codificar los números del 0 al 9, las letras mayúsculas y minúsculas y otros símbolos de uso frecuente. La velocidad de transmisión es de 1200 bps, conforme al estandar V.23 anteriormente mencionado.

Capa de enlace

La capa de enlace tiene como misión asegurar que los diferentes bits enviados por la capa física son reconocidos correctamente por el modem y que además están libres de errores. Para ello la capa de enlace utiliza una trama como la mostrada en la siguiente figura:

Identificacion de llamadas_4

  • La señal de toma se utiliza para “despertar al modem” y consiste en una secuencia de 300 bits a “1” y a “0” de forma alternada. Es preciso tener en cuenta que los modem contenidos en los teléfonos compatibles con el servicio de identificación de llamadas, normalmente están en un estado reposo o de bajo consumo y necesitan ser “activados” cuando van a recibir información útil enviada desde la central.
  • La señal de marca se utiliza para “sincronizar” al modem del aparato telefónico con el modem situado en la central. Consiste en una secuencia de 180 bits a “1” +/- 25 bits. En los casos en que se envía información con el teléfono descolgado, en el transcurso de una llamada, esta señal de marca consiste solo en 80 bits a “1”, también con un margen de +/- 25 bits.
  • El campo Tipo de mensaje tiene un longitud de 8 bits y en el se especifica si el mensaje enviado por la central es de “identificación de llamada” o de otro tipo, como pueden ser los mensajes de “Indicación de mensaje en espera”, los mensajes que contienen “información de tarificación” o bien mensajes reservados por el operador para servicios futuros.
  • El campo Longitud de mensaje especifica en sus 8 bits la longitud del mensaje enviado, sin incluir los bits correspondientes al sistema de detección de errores o bits de checksum. Es decir, como máximo los mensajes tendrán un contenido útil de 256 bits.
  • El campo de Checksum o de detección de errores consiste en 1 byte que contiene el complemento a 2 en módulo 256 de la suma de todos los octetos transmitidos desde el  campo Tipo de mensaje y hasta que comienza el propio campo de checksum. Este sistema permite únicamente detectar errores y no permite corregir errores en ningún caso. Tampoco está previsto ningún sistema de reconocimiento de la información recibida (ACK) ni de petición de retransmisión de información recibida de forma errónea. Cualquier mensaje incorrecto o desconocido en el terminal telefónico deberá ser descartado.

Capa de presentación

La capa de presentación establece la estructura de la información enviada en cada uno de los mensajes. Estos mensajes tienen una estructura de tipo “mensaje múltiple”, de acuerdo al siguiente esquema:

Identificacion de llamadas_5

Cada uno de los mensajes se identifica por el campo Tipo de Parámetro, el cual establece si el campo denominado “octetos de información” contiene el número de teléfono correspondiente a la identificación del llamante, la fecha y la hora o la razón de ausencia de identidad del llamante. Cuando se trata de la identidad del llamante, la estructura es la siguiente:

Identificacion de llamadas_6

Y cuando en el mensaje se transmite la información correspondiente a la fecha y la hora, la estructura es la siguiente:

Identificacion de llamadas_7

Por último, se debe de tener en cuenta que esta información vista anteriormente, se envía por la central hacia el terminal del usuario unos instantes antes de enviar la primera señal de ring, de acuerdo al siguiente esquema:

Identificacion de llamadas_8

La señal RP-AS es la señal de Ringing Pulse-Alerting Signal y es similar a la señal de ring pero de una duración mucho menor. Se utiliza para alertar al modem acerca del próximo envío de información. El proceso completo se puede ver en el siguiente vídeo, grabado en el aula de telefonía del Instituto de Formación Profesional Tartanga.

Como se puede observar en el vídeo, inmediatamente después de la señal de RP-AS llegan los datos correspondientes a la identificación de llamada (número del que llama y fecha y hora). Estos datos llegan modulados en FSK y antes de la primera señal de ring, lo cual se observa fácilmente, ya que el módulo identificador de llamadas muestra el número del que llama antes de que suene en el teléfono la primera señal de ring.

Identificacion de llamadas_9

Captura de la señal FSK en el osciloscopio

En la pantalla del osciloscopio se muestra un fragmento de la trama de datos correspondiente a una identificación de llamada. Se aprecia sin dificultad que se trata de una modulación en FSK.  Como consecuencias curiosas de este proceso de identificación de llamadas se pueden citar las dos siguientes:

  • Con cada llamada entrante, además del número correspondiente a la identificación de llamadas, se recibe también la fecha y hora de dicha llamada. Por lo tanto, aquellos teléfonos que tienen incorporada la función de identificación de llamadas “se pondrán en hora” después de recibir la primera llamada, no antes.
  • Si se descuelga el teléfono inmediatamente después de recibir la señal RP-AS, la llamada se establecerá con normalidad, pero en la pantalla del teléfono no aparecerán los datos correspondientes a la identificación de llamada, ya que la central deja de enviar dichos datos en cuanto detecta que el teléfono ha sido descolgado.

Además, tal y como se ha indicado al principio de esta entrada en el blog, para que una centralita sea capaz de identificar las llamadas sobre sus líneas analógicas, es imprescindible que tenga incorporada por “hardware” esta función. Es decir, necesita un modem capaz de entender la información enviada por la central por cada una de sus líneas y esto algunas centralitas lo llevan incorporado en la configuración base y otras centralitas, como la Panasonic TEA-308 requieren de una tarjeta de ampliación.

Identificacion de llamadas_10

 Tarjetas de ampliación para la Panasonic TEA-308

Es de señalar que en la mayoría de los países se utiliza la modulación FSK para el envío de la información de identificación de llamadas, pero existen otros pocos países donde el sistema utilizado se basa en el envío de tonos DTMF, al igual que los que se utilizan para enviar el número marcado desde el usuario a la central. Entre estos países que utilizan DTMF-ID se encuentran Finlandia, Dinamarca, Islandia, Holanda, India, Bélgica, Suiza, Brasil, Taiwan, Arabia Saudi y Uruguay. Por ello, el software de la centralita TEA308 contempla ambas posibilidades.

Identificacion de llamadas_11

Estándares de identificación de llamadas (Wikipedia)

En la centralita Panasonic TEA308, la información de identificación de llamadas es llevada a las extensiones específicas a través del par de datos de dichas extensiones, pero en el caso de las extensiones regulares compatibles con el servicio de identificación de llamadas, la única solución es enviar dicha información sobre el único par disponible, el par de voz

Identificacion de llamadas_12

En este último caso, el de las extensiones regulares, puede ser que el sistema de identificación de llamadas de dichas extensiones sea compatible con el método basado en modulación FSK y señal de comienzo RP-AS o bien que sean compatibles con otro método. Por ello, la centralita TEA308 tiene las cuatro siguientes opciones de configuración

Identificacion de llamadas_13

Publicado en Telefonía analógica | Deja un comentario

Aplicación práctica de la detección de los cambios de polaridad en las líneas analógicas

Un aspecto fundamental de las líneas analógicas es la señalización, la cual  incluye la detección de corriente de bucle, diferentes tonos audibles, marcación por pulsos y tonos, señales senoidales de más de 100 voltios de pico y los cambios de polaridad en la línea. De todos estos factores, sin duda el más desconocido es este último, los cambios de polaridad en la línea, que son producidos desde la central hacia el usuario, nunca desde el usuario a la central, y que sirven para notificar al usuario de los diferentes estados de la llamada.

Tarificador e inversion polaridad_1Como se observa en el gráfico anterior, todas las fases de la señalización entre central y usuario y entre usuario y central están basadas en señales analógicas dentro del intervalo de frecuencias utilizado en telefonía analógica (300 -3400 Hz), por lo que son perfectamente audibles y todos los usuarios de la telefonía analógica sabemos que están ahí, aunque no conozcamos muy bien para qué. Pero los cambios de polaridad son simplemente eso, cambios de polaridad en la línea provocados desde la central hacia el usuario, y por lo tanto no audibles en ningún caso, por lo que pasan totalmente desapercibidos y de hecho, la mayoría de los usuarios simplemente ignoran su existencia. Pero lo cierto es que cumplen una función muy importante, tal y como se refleja en la siguiente tabla, obtenida del documento de la interfaz de línea analógica de Telefónica.

Tarificador e inversion polaridad_2

En la tabla se aprecia que el usuario que realiza una llamada sabe con certeza el momento exacto en que el usuario llamado ha descolgado la llamada (1) y también sabe cuando la llamada ha finalizado, bien sea porque el es el primero en colgar la llamada (2) o bien porque el usuario llamado es el que cuelga primero (3). El usuario llamado también conoce el momento exacto en que tiene una llamada entrante (4), antes incluso de que suene la señal de ring y el momento exacto en que la persona que le ha llamado ha colgado la llamada (5).

¿Cual es la utilidad de todo esto? Tiene varias aplicaciones, pero una muy importante es el permitir un correcto funcionamiento de los sistemas de tarificación por tiempo. Estos sistemas se programan en las centralitas para “cobrar” una determinada cantidad de dinero por unidad de tiempo y dependiendo también del número llamado. Posteriormente y mediante conexión a una impresora de tickets o a un PC es posible obtener un registro en papel o en soporte informático del gasto realizado por cada extensión de la centralita (por ejemplo para la facturación del gasto telefónico a los clientes de un hotel o para conocer el gasto telefónico de los diferentes trabajadores de una empresa).

Veamos los pasos sobre una centralita Panasonic TEA 308 y el resultado que se obtiene cuando no está activada la detección de la inversión de polaridad en las llamadas salientes y cuando si está activada dicha detección. Observar que en un sistema de tarificación solo interesa detectar los cambios de polaridad en las llamadas salientes, no en las entrantes.

Tarificador e inversion polaridad_3

En el menú de Tarificación de llamadas indicamos que vamos a realizar el cálculo de tarificación sobre las llamadas salientes por la línea 1, aunque se puede realizar por cualquiera de las tres líneas de forma simultánea.

Tarificador e inversion polaridad_4

Ajustamos en las tablas de secuencias cuales son los horarios de coste máximo, mínimo y económico

Tarificador e inversion polaridad_5

Indicamos los prefijos que tendrán una tarificación distinta en cada caso. En este caso, como se trata tan solo de un ejemplo, se han indicado solo tres prefijos típicos (6=llamadas a móviles, 9=llamadas a fijos nacionales, 118=llamadas a números de información)

Tarificador e inversion polaridad_6

Para cada uno de los prefijos se ajusta el coste máximo, mínimo y económico. En el ajuste del coste se debe de indicar el coste fijo que es el que se cobrará en el momento de establecerse la llamada y el coste Unitario que es el que se cobrará por unidad de tiempo fijada en la casilla de “duración” y solamente cuando finalice el tiempo asignado al coste fijo. En la pantalla anterior se han ajustado los costes de tipo máximo (atención, es un ejemplo, no son costes reales)

Tarificador e inversion polaridad_7

La pantalla anterior corresponde al ajuste de los costes de tipo Mínimo

Tarificador e inversion polaridad_8

Y para finalizar, se ajusta el modo de visualización de la tarificación, que por defecto aparece en los displays de los teléfonos específicos y se ajusta también, si se desea, un límite de presupuesto o límite de gasto para cada una de las extensiones de la centralita.

Una vez hemos realizado toda la programación es el momento de realizar llamadas al exterior y observar los resultados. En primer lugar hacemos una llamada saliente con la detección de los cambios de polaridad en llamadas salientes activada. El tiempo de inicio de llamadas está fijado a 20 segundos.

Y si desactivamos la detección de cambios de polaridad en llamadas salientes, manteniendo el tiempo de inicio de llamadas en 20 segundos, el resultado es muy diferente:

Para terminar, la centralita TEA308 y otras centralitas de Panasonic tienen la detección de la señal CPC (Calling Party Control) tanto para llamadas entrantes como para llamadas salientes. Esta señalización consiste en una breve desconexión del bucle del abonado por parte de la central local, pasando la tensión del bucle a cero voltios. Con esta señalización se informa tanto al teléfono que realiza una llamada saliente como al que recibe una llamada entrante del estado de la llamada. Pero es preciso tener en cuenta que en España no se utiliza la señalización CPC. No obstante, a veces puede dar la impresión de que la centralita si está detectando la señalización CPC, ya que si en la línea hay cambios de polaridad, cuando cambia la polaridad de + a – o bien de – a + hay un momento en que pasa por cero la tensión en la línea, y entonces la centralita puede “entender” que la central ha enviado señalización CPC.

Tarificador e inversion polaridad_12

Como en la TEA308 no hay detección de cambios de polaridad para llamadas entrantes, cuando nos interesa detectar tal circunstancia, como por ejemplo para un correcto funcionamiento de la operadora automática, tendremos que activar la detección de la señal CPC para llamadas entrantes y el resultado será satisfactorio, aun teniendo en cuenta que en realidad la centralita estará detectando los pasos por cero de la tensión del bucle cada vez que hay un cambio de polaridad.

Tarificador e inversion polaridad_13

Pantalla de “Temporizadores” de la TEA 308 donde se ajusta el “tiempo de inicio de llamada”. Este es el tiempo desde que la centralita marca el número hasta que considera que la llamada ya ha sido descolgada, y por lo tanto es el momento de comenzar a tarificar. Evidentemente este es un sistema imperfecto, ya que si nadie coge la llamada y el tiempo ha sido ajustado demasiado bajo, se cobrará por una llamada que en realidad no se ha producido. Por el contrario, si colocamos un tiempo de inicio demasiado alto (50 seg) habrá llamadas salientes de corta duración que no serán tenidas en cuenta por el sistema a la hora de tarificar. La solución por tanto, detectar el momento justo en el que la llamada saliente ha sido descolgada. Y el sistema para detectarlo en las líneas analógicas es el de los cambios de polaridad.

Publicado en Telefonía analógica | 3 comentarios

Activación de licencias de canales IP, extensiones IP y extensiones SIP en la centralita NCP500

Como ya se ha visto en anteriores entradas de este blog, la centralita NCP500 necesita licencias de activación para el uso de canales IP, extensiones IP específicas de Panasonic, softphones y extensiones SIP. Cuando se desea añadir nuevos canales IP o nuevas extensiones IP, ya sean específicas o SIP, es imprescindible “adquirir” un fichero de licencias y cargar dicho fichero en la tarjeta SD de la centralita:

Activacion licencias NCP500_1

Licencias activadas en la centralita

Activacion licencias NCP500_2

Las licencias vienen en un fichero de muy pequeño tamaño y con extensión .lic

Activacion licencias NCP500_3

Fichero .lic de licencias descargado en una carpeta del PC

Activacion licencias NCP500_4

El fichero de licencias se transfiere desde el PC a la tarjeta SD de la centralita

Activacion licencias NCP500_5

Al finalizar la transferencia del fichero es necesario ir a la opción de Clave de activación

Activacion licencias NCP500_6

Opción de “Clave de activación” para actualizar las licencias instaladas

Activacion licencias NCP500_7

Al entrar en la opción de “Clave de activación” se carga la nueva configuración

Activacion licencias NCP500_8

Las nuevas líneas IP disponibles requieren un proceso de activación específico

Activacion licencias NCP500_9

Estado de las licencias al terminar el proceso de instalación de nuevas licencias

Como se observa en la imagen anterior, al finalizar el proceso de activación de nuevas licencias el estado de las licencias activas de la NCP500 es el siguiente:

  • 8 licencias para canales IP de los cuales 2 son de tipo H.323 (conexión con la centralita TDA200 del instituto para llamadas internas entre extensiones del aula de telefonía y extensiones del instituto) y los 6 restantes son de tipo SIP (conexión con el proveedor Sarevoz)
  • 6 licencias para extensiones softphones de Panasonic.
  • 8 licencias para extensiones específicas IP de Panasonic.
  • 11 licencias para extensiones IP de tipo SIP
  • 5 licencias para CA Basic de usuario

Al haber añadido estas nuevas licencias ya hemos podido activar de forma simultánea en clase con los alumnos seis (6) canales SIP con el proveedor Sarevoz para la realización de llamadas externas y también hemos podido instalar y registrar en la NCP500 extensiones SIP con el softphone Zoiper que previamente los propios alumnos han descargado e instalado en sus móviles. La única condición que se ha debido de cumplir para este último paso ha sido la de instalar un punto de acceso WiFi en el aula de telefonía conectado a la red del centro, de tal forma que la aplicación Zoiper instalada en dichos teléfonos móviles sea capaz de encontrar la centralita NCP500, que está en la DMZ de la red del instituto.

Con esta última utilidad, usada en las empresas, el teléfono móvil de un trabajador se convierte en una extensión de la centralita tan pronto se accede al local de la empresa y se conecta con la wifi preparada al efecto. El usuario puede seguir funcionando con su móvil de la forma habitual, recibiendo y haciendo llamadas a través de la red GSM/3G de su operador pero también puede hacer y recibir llamadas mediante la aplicación Zoiper y a través de la centralita de la empresa, Con esto se evita el tener que utilizar un terminal DECT en el interior de la empresa, pues el propio móvil del usuario cumple esa misma función y de una forma más cómoda y práctica.

Publicado en Telefonía IP | 5 comentarios