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 | Deja un 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

Prácticas en el certificado de profesionalidad ELES0209: Instalación de un portero automático sobre la centralita TEA308

En el pasado mes de enero de 2015, una de las prácticas realizadas por los alumnos del certificado de profesionalidad ELES0209 dentro del bloque dedicado a instalación y configuración de centralitas telefónicas ha sido la instalación de un portero automático sobre la centralita TEA 308 de Panasonic. Esta es una opción muy utilizada por las empresas ya que permite integrar el servicio de portero automático con la propia centralita, siendo posible atender los interfonos colocados en las puertas de entrada a la empresa desde cualquier extensión de la centralita y dar la orden de apertura de los abridores situados en la puertas.

Portero automatico en la TEA308_1

 Ranuras de ampliación de la TEA308

Portero automatico en la TEA308_2

 Tarjeta KX-TD82460

Portero automatico en la TEA308_3

Tarjeta KX-TE82460NE e Interfono KX-T7765X

Portero automatico en la TEA308_4

 Se necesita romper una pestaña de plástico situada en la parte trasera

Portero automatico en la TEA308_5

Colocación de la tarjeta en la centralita

Portero automatico en la TEA308_6

 Conexión de la tarjeta a la ranura de ampliación de la centralita

Portero automatico en la TEA308_7

Conexión del interfono y del abridor de puerta

Portero automatico en la TEA308_8

Instalación completa sobre una de las mesas del aula de telefonía

Portero automatico en la TEA308_9

El abridor, el transformador 220/12  y el interfono

Portero automatico en la TEA308_10

La configuración del portero automático en la consola de mantenimiento de la centralita es un proceso muy sencillo. En el menú de Interfono  y dentro de la opción Timbre y portero automático, en la pestaña de Interfono seleccionamos en que extensiones se recibirán las llamadas desde los dos posibles interfonos que se pueden instalar en la centralita.

Portero automatico en la TEA308_11

En la pestaña de Portero automático seleccionamos que extensiones podrán dar la orden de apertura de los abridores de las puertas, dentro de las tres franjas horarias disponibles en esta centralita.

Portero automatico en la TEA308_12

Por último, en la opción Otros del menú de Interfono tenemos la posibilidad de ajustar, entre otras cosas,  las cadencias de tonos que se escucharán en las extensiones que reciban las llamadas de interfono, el tiempo de duración de timbre de interfono y el tiempo que durará la apertura del abridor de puertas. El funcionamiento práctico se puede observar en el siguiente vídeo:

Como curiosidad técnica, la apertura del abridor desde un teléfono regular exige previamente un “colgado” de la llamada desde el interfono antes de pulsar la tecla “5” que produce la apertura del abridor. Esto es así para prevenir que con un generador de tonos DTMF, el cual puede ser un simple teléfono móvil con el sonido activado en el teclado, la persona que llama al interfono pueda abrir ella misma la puerta tan pronto como la extensión descuelga la llamada. En los teléfonos específicos,  esto no es necesario ya que la marcación no va por el par de voz sino por el par de datos del teléfono.

Portero automatico en la TEA308_13

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

La telefonía RDSI en el Certificado de Profesionalidad ELES0209: Conectando y probando un TR1 a la centralita del instituto

De nuevo durante este curso 2014/2015 estamos impartiendo en el Instituto Tartanga las clases correspondientes al Certificado de Profesionalidad ELES0209, cuyo título es:  Montaje y mantenimiento de sistemas de telefonía e infraestructuras de redes locales de datos. Este es un curso de nivel 2 organizado por el Servicio Vasco de Empleo “Lanbide”.

Conexión de unTR1 en la centralita del instituto_0

En la parte correspondiente a Montaje y mantenimiento de sistemas de telefonía, los alumnos que asisten al cursillo estudian, entre otros temas, el funcionamiento de la telefonía analógica, la instalación, programación y mantenimiento de PABX básicas, los fundamentos de la telefonía RDSI y la instalación, programación y mantenimiento de PABX con tarjetas de líneas RDSI.

Y en esta ocasión, cuando se ha estudiado la RDSI, además de realizar las habituales prácticas de conexión de un TR1 a las centralitas RDSI situadas en el aula de telefonía (NCP500, KXTD-816 y Neris 2), también se ha realizado la práctica de añadir líneas RDSI a una centralita en servicio: la centralita TDA 200 del instituto. A continuación se muestran fotografías de diferentes momentos de la realización de dicha práctica:

Conexión de unTR1 en la centralita del instituto_1

 Armario con la regleta de entrada de pares de Euskaltel

Conexión de unTR1 en la centralita del instituto_1a

Conexionado en la regleta de entrada de Euskaltel

Conexión de unTR1 en la centralita del instituto_2

 Detalle de la conexión realizada en uno de los pares de entrada (regleta tipo Pouyet)

Conexión de unTR1 en la centralita del instituto_3

 TR1 de pruebas junto al comprobador de enlaces RDSI ARGUS 2

Conexión de unTR1 en la centralita del instituto_3a Comprobación del funcionamiento del TR1 con el ARGUS 2

Conexión de unTR1 en la centralita del instituto_4Verificación del estado del acceso básico mediante el comprobador ARGUS 2

Conexión de unTR1 en la centralita del instituto_4a

Conexión del acceso básico a uno de los puertos RDSI de la TDA200

Conexión de unTR1 en la centralita del instituto_5

TR1 conectado en el puerto 6 de la tarjeta de 8 accesos básicos

Conexión de unTR1 en la centralita del instituto_5a

Detalle de la conexión del TR1 en el puerto 6 

Conexión de unTR1 en la centralita del instituto_6

 Comprobación en la consola de programación de la TDA200 del estado del puerto

Conexión de unTR1 en la centralita del instituto_7

 Prueba de funcionamiento de la línea 11 (asignada al puerto 6)

Conexión de unTR1 en la centralita del instituto_8

Prueba de funcionamiento de la línea 12 (asignada al puerto 6)

Como se puede observar en las fotografías anteriores, en ningún momento del proceso fue necesario interrumpir el servicio telefónico del instituto, ya que el acceso básico conectado fue del tipo Punto a Punto (P-P) y el puerto de la centralita TDA200 ya se encontraba en dicha configuración, con lo que la detección y puesta en servicio (INS) se produjo de forma automática. De haber sido necesario algún cambio en la configuración de la tarjeta RDSI de la centralita, tan solo habría sido puesta en modo “fuera de servicio” (OUS) durante el menor tiempo posible y una vez finalizada la programación se hubiera puesto rápidamente de nuevo en servicio (INS).

Publicado en RDSI | Deja un comentario

Comunicación entre centralitas a través de IP mediante el protocolo H.323

Como continuación a una reciente entrada de este blog titulada “Comunicación entre centralitas a través de RDSI”, ahora vamos a mostrar como se realiza dicha comunicación pero a través de un enlace IP. El siguiente diagrama muestra los equipos a conectar:

Comunicacion por IP entre centralitas_1La centralita NCP500 admite tarjetas virtuales de gateway para SIP  y para H.323. En cambio, en la TDA 200 del Instituto, solo disponemos de una tarjeta gateway de 4 canales mediante el protocolo H.323. Por ello, la conexión se va a realizar mediante dicho protocolo H.323. En cualquier caso, el procedimiento tanto en SIP como en H.323 es muy similar y una vez visto uno de ellos es muy fácil realizar el otro. De nuevo en este caso utilizaremos el método del número de extensión, donde cada una de las centralitas tiene una numeración distinta en las extensiones, tal y como se muestra en el diagrama anterior. En primer lugar, en la centralita TDA200 nos aseguramos de que el bloque de extensiones sea a 3 dígitos y con el número 1 como marcación inicial.

Comunicacion por IP entre centralitas_2A

 Bloque de extensiones en la TDA200

En la centralita NCP500 hacemos lo mismo pero asegurándonos que la marcación inicial del bloque de extensiones comienza por el número 2

Comunicacion por IP entre centralitas_2B

 Bloque de extensiones en la NCP500

En la centralita TDA200 indicamos que la numeración de la otra PBX en la red privada comienza por el número 2 y es a tres dígitos

Comunicacion por IP entre centralitas_3A

 Numeración de otra PBX (Red Privada) en la TDA200

Y de nuevo hacemos lo mismo para la NCP500 pero indicando en este caso que la númeración de la otra PBX (Red Privada) comienza por el número 1 y es también a tres dígitos

Comunicacion por IP entre centralitas_3B

  Numeración de otra PBX (Red Privada) en la NCP500

A continuación colocamos las líneas IP H.323 de la TDA200 en un grupo de líneas único, no compartido con otro tipo de líneas. En este caso hemos seleccionado únicamente dos canales IP de la tarjeta Gateway de 4 canales de la TDA200 porque en la NCP500 solo vamos a tener dos canales disponibles, ya que solo disponemos de 4 licencias para canales IP y dos de ellas se van a reservar para las comunicaciones con el proveedor Sarenet.

Comunicacion por IP entre centralitas_4A

 Líneas IP de la TDA200 en el grupo de líneas 3

En la NCP500 seleccionamos dos canales IP de la tarjeta virtual gateway de 16 canales IP  y los colocamos en un grupo propio

Comunicacion por IP entre centralitas_4B

 Líneas IP de la NCP500 en el grupo de líneas 7

En la pantalla de Tabla de Red Privada de la TDA200 indicamos que cuando se marque un número de 3 digitos que comience por 2, esa llamada se debe de sacar por el grupo de líneas externas 3, que es el grupo donde están los dos canales IP H.323 de la TDA200.

Comunicacion por IP entre centralitas_5A

Tabla de red privada en la TDA200

Y hacemos lo mismo para la NCP500 pero seleccionando en este caso el grupo de líneas 7

Comunicacion por IP entre centralitas_5B

Tabla de red privada en la NCP500

Nos aseguramos de que tanto en la TDA200 como en la NCP500 los canales IP H.323 estén en servicio (INS).

Comunicacion por IP entre centralitas_6A

Propiedades de puerto de la tarjeta IP-GW4 de la TDA200

Comunicacion por IP entre centralitas_7A

Canales IP H.323 de la TDA200 en servicio (INS)

Comunicacion por IP entre centralitas_6B

Propiedades de puerto de la tarjeta virtual  V- IPGW16 de la NCP500

Comunicacion por IP entre centralitas_7B

Canales IP H.323 de la NCP500 en servicio (INS)

Al llegar aquí debemos de tener en cuenta que, al tener instalada la centralita NCP500 una tarjeta virtual V-IPGW16 y una tarjeta virtual V-SIPGW16, las licencias de activación disponibles de canales IP deben de ser compartidas por ambas tarjetas. Por eso, en la NCP500 hemos desactivado dos canales SIP y esas licencias de activación que hemos dejado libres se las hemos asignado a los canales IP de la tarjeta virtual V-IPGW16

Comunicacion por IP entre centralitas_8

Solamente dos canales IP de tipo SIP solicitarán la activación

Comunicacion por IP entre centralitas_9

Configuración de las claves de activación para líneas externas IP virtuales

Comunicacion por IP entre centralitas_9a

Es necesario activar únicamente las licencias para las líneas externas H.323

Comunicacion por IP entre centralitas_9b

Activación de dos licencias para las líneas externas H.323

Y ahora entramos en la parte específica de configuración de H.323. Para ello  nos conectamos físicamente con la TDA200 mediante un cable de red cruzado. En el navegador colocamos una IP que esté en la misma red que la tarjeta de gateway de 4 canales (si no conocemos la IP de esa tarjeta, hay que hacerla un “reset” para colocar la IP por defecto. Consultar para ello el manual de la tarjeta)

Comunicacion por IP entre centralitas_10

 Conexión mediante un cable cruzado a la tarjeta IP-GW4 de la TDA200

Comunicacion por IP entre centralitas_11

 Conexión mediante un cable cruzado a la tarjeta IP-GW4 de la TDA200

Comunicacion por IP entre centralitas_12

Conexión mediante el navegador con la tarjeta IP-GW4 de la TDA200

Comunicacion por IP entre centralitas_13

Menú principal de la tarjeta IP-GW4 de la TDA200

Comunicacion por IP entre centralitas_14

Opciones GW y DN2IP de la tarjeta IP-GW4 de la TDA200

En la opción GW Entry deberemos de crear entradas de Gateway para los gateway disponibles. En nuestro caso solo va a haber dos gateway, uno en la TDA200 y otro en la NCP500, pero en una centralita que forma parte de una red privada IP puede haber más de un gateway, de tal manera que determinadas llamadas se “enruten” hacia un gateway de destino u otro. Es decir, en las pantallas anteriores hemos definido por que canales o líneas IP salen las llamadas que comienzan por un prefijo determinado, mientras que ahora lo que debemos de definir es hacia que IP de destino se deben de dirigir esas llamadas IP.

Comunicacion por IP entre centralitas_15

Entradas de Gateway creadas en la TDA200

Ahora, para cada uno de los gateway creados, debemos de especificar con que prefijos de marcación se activa uno u otro. En nuestro caso, cualquier llamada que tenga como dígito de inicio el número 2 y seguido de otros dos dígitos, deberá de dirigirse al gateway de la NCP500, es decir, al gateway número 1 y que está situado en la dirección IP 192.168.1.52

Comunicacion por IP entre centralitas_16

Tabla DN2IP de la tarjeta Ip-GW4 en la TDA200

Nota: En realidad la línea correspondiente al GW número 0 es innecesaria, ya que todas las llamadas que comiencen por el prefijo “1” serán consideradas llamadas internas de la propia centralita TDA200, pero de esta forma, ambas centralitas tendrán “la misma tabla” DN2IP y evitaremos confusiones en la programación.

Por último, en el gateway de la centralita TDA200 se recibirán llamadas IP provenientes de la centralita NCP500. Debemos de indicar que llamadas se recibirán en el gateway, a fin de que sean “enrutadas” hacia la centralita.

Comunicacion por IP entre centralitas_17

Pantalla de Hunt Pattern para las llamadas entrantes en la TDA200

 Y en la centralita NCP500 debemos de realizar los mismos pasos anteriores en su tarjeta V-IPGW16. Cuando accedemos a dicha tarjeta comprobamos que, efectivamente, tiene las opciones de Gateway, DN2IP y Hunt Pattern. Para ello, deberemos de ir a la opción Propiedades de armario de la tarjeta V-IPGW16 en la NCP500

Comunicacion por IP entre centralitas_18

Comunicacion por IP entre centralitas_19

 Opciones de Gateway, DN2IP y Patrón de Búsqueda en la tarjeta V-IPGW16

Comunicacion por IP entre centralitas_20

Lista de Gateway creados en la V-IPGW16

Comunicacion por IP entre centralitas_21

Tabla DN2IP de la tarjeta V-IPGW16 en la NCP500

Comunicacion por IP entre centralitas_22

Hunt Pattern para las llamadas entrantes en la V-IPGW16 de la NCP500

El resto de opciones de configuración no es necesario modificarlas, con los valores “por defecto” todo funcionará correctamente. Entre esos valores “por defecto” están los números de puerto utilizados por el protocolo H.323, que en nuestro caso coinciden plenamente en ambas centralitas:

Comunicacion por IP entre centralitas_23

Puertos y codecs de voz utilizados en la TDA200

Comunicacion por IP entre centralitas_24

Puertos utilizados por el protocolo H.323 en la centralita NCP500

Comunicacion por IP entre centralitas_25

Codecs de voz disponibles en la centralita NCP500

Cuando todo la configuración anterior ha sido realizada, se deberán de poder hacer llamadas IP entre ambas centralitas sin ningún tipo de problemas. A modo de ejemplo, en el siguiente vídeo se muestra una llamada entre una extensión de la centralita NCP500 (ext nº 241) y una extensión de la TDA200 (ext nº 111)

 

Publicado en Telefonía IP | 6 comentarios

Telefonía mediante par siamés en las redes HFC de Euskaltel, ONO y otros operadores de cable

Cuando se examina la instalación de las redes HFC (Híbrido de Fibra y Cobre) de operadores como Euskaltel, ONO y otros, llama la atención la utilización del denominado par siamés para ofrecer el servicio telefónico, dejando el cable coaxial exclusivamente para servicios de TV y de datos. Surge entonces la duda acerca de los motivos que tienen estos operadores de cable para montar una auténtica red de telefonía construida con pares de cobre en paralelo con el tendido de los cables coaxiales de la red HFC. En las siguientes fotografías se muestran algunos ejemplos de como Euskaltel suministra el servicio de telefonía por medio de una red de pares de cobre independiente:

Par siames en redes HFC_1

 Instalación de red HFC de Euskaltel

Par siames en redes HFC_2

Tendido del cableado de la red HFC hacia las viviendas de los clientes

Par siames en redes HFC_3

Detalle del cableado de la red HFC

Par siames en redes HFC_4

Entrada del cable coaxial y del cable de pares en la vivienda de un cliente

Par siames en redes HFC_5

Otro caso práctico de distribución de cableado en la red HFC de Euskaltel

Par siames en redes HFC_6

Caja de pares de telefonía y repartidores de señal a través de cable coaxial 

Par siames en redes HFC_7

Tendido de cables en vertical hacia las viviendas de los clientes

Par siames en redes HFC_8

Caja de conexión de pares telefónicos abierta (red HFC de Euskaltel)

Par siames en redes HFC_9

Detalle de una caja de conexión de pares telefónicos en la red HFC de Euskaltel

En las fotografías anteriores, obtenidas en el municipio de Berango (Bizkaia) y en el barrio de Santutxu (Bilbao), podemos observar como la red HFC de Euskaltel utiliza, efectivamente, una red superpuesta de cable de pares de cobre para ofrecer el servicio de telefonía a sus clientes. En la siguiente imagen se muestra el diagrama de una red HFC con el servicio de telefonía mediante red de pares de cobre superpuesta:

Par siames en redes HFC_10a

Esquema general de una red HFC (Alcatel-Lucent 2007)

En España, operadores de redes de cable como ONO recurren también a esta solución para ofrecer el servicio de telefonía  a sus clientes. En el siguiente diagrama se muestra la red HFC de ONO basada en el estandar DOCSIS 1.1 (Data Over Cable Service Interface Specification):

Par siames en redes HFC_10b

Red HFC de ONO basada en el estandar DOCSIS 1.1

Obviamente el recurrir a esta solución, aparentemente mucho más costosa que suministrar telefonía IP dentro del servicio de datos de la red HFC, tiene que responder a unas ventajas técnicas claras. Y estas ventajas técnicas de la red de cable de pares se justifican en las especiales características necesarias para la VoIP, ya que la señal de voz por IP es muy sensible a problemas que apenas tienen importancia en la transmisión de datos mediante IP:

  • Packet loss o pérdidas de paquetes: En VoIP un paquete perdido no se vuelve a retransmitir. No tiene sentido la retransmisión de un paquete de voz que no llegó en el momento que el correspondía.
  • Delay o retraso en la entrega de los paquetes de voz: Aunque los paquetes de voz alcancen correctamente su destino, si no lo hacen en el tiempo prefijado tampoco servirán de nada y serán equivalentes a paquetes perdidos.
  • Jitter o espaciado aleatorio entre paquetes de voz consecutivos: Si la separación entre paquetes de voz no es homogénea se produce el efecto de “jitter” que dificulta sobremanera la comunicación de voz. Este problema se soluciona en parte mediante la utilización de buffers, en los que se almacena “por adelantado” varios paquetes de voz, pero habitualmente es difícil ajustar con precisión el tamaño adecuado de estos buffers ya que tanto si son demasiado grandes como si son demasiado pequeños, producirán problemas en la calidad de la voz de la llamada telefónica.

En las redes HFC se dan de forma notable los tres problemas anteriores, en especial en el flujo de subida (Upstream) desde la vivienda del cliente hacia el CMTS (Cable Modem Termination System). En realidad, este flujo de subida es considerado el talón de Aquiles de la VoIP en las redes HFC y los problemas en dicho flujo upstream se producen tanto en la parte “física” o planta de radiofrecuencia como en el protocolo DOCSIS de control de acceso al medio.  Algunos de los problemas que aparecen se enumeran a continuación:

  1. En las redes HFC los usuarios tienen que competir por el canal de subida, mediante un mecanismo que regule el acceso a un medio compartido. Cada vez que un usuario quiere enviar un paquete (datos o voz) hacia el CMTS, deberá de solicitarle en primer lugar un intervalo temporal para ello. Una vez obtenida la respuesta desde el CMTS procederá a ocupar el espacio temporal asignado con los datos a enviar. Este mecanismo funciona bastante bien cuando son pocos los usuarios que están “subiendo” datos hacia el CMTS pero puede congestionarse si son muchos los usuarios que lo intentan a la vez, produciéndose entonces los problemas de delay, jitter e incluso pérdidas de paquetes, que en la transmisión de datos no tendrán excesiva importancia pero sí que tendrán consecuencias nefastas para los paquetes de voz.
  2. Las redes HFC al estar formadas por cables coaxiales se comportan “como antenas” capaces de captar variadas interferencias radioeléctricas. Estas interferencias afectan en mayor grado al flujo de subida debido a las frecuencias utilizadas. Un ejemplo de esto son las interferencias producidas por transmisiones de radio en la denominada Banda Ciudadana.
  3. Las propias instalaciones particulares de los usuarios en redes HFC son una fuente de interferencias que se “inyectan” en la red y que, al igual que en el caso anterior, afectan sobremanera al flujo de subida. Se calcula que el 80% del ruido de las redes HFC es debida a interferencias inyectadas en la red por equipos pobremente apantallados en las viviendas de los clientes. Estas interferencias son además mucho más difíciles de controlar por parte del operador de la red de cable, ya que al suceder en el propio domicilio del cliente, el margen de actuación es mínimo. Normalmente en las redes HFC se instalan unos equipos que reducen el ruido introducido en la red por cada usuario que se conecta. Un ejemplo de esto es el modelo TRIS 202FIN instalado en la conexión HFC que, junto con una conexión por fibra óptica, tenemos disponible en el Instituto Tartanga. Este equipo y otros similares utilizan técnicas de cancelación de fase y consigue mejoras de entre 3 y 12 dB en la relación señal a ruido.

 Par siames en redes HFC_14Módulo de aislamiento colocado en las viviendas de los clientes de redes HFC

Es preciso tener en cuenta además que la transmisión de voz por IP necesita una calidad subjetiva. Es decir, el usuario tiene que “notar” que la señal de voz que recibe de la otra parte es inteligible, clara, sin ruidos y sin cortes. En cambio, en la transmisión de datos solo es necesario disponer de una calidad objetiva, la cual se consigue con un determinado BER (Bit Error Rate) y con los adecuados mecanismos de detección y corrección de errores. De nada sirve disponer en una transmisión de VoIP de un BER extraordinariamente bajo (muy pocos errores) si los paquetes llegan con un retraso notable (delay debido a retransmisiones de paquetes erróneos) y con variaciones significativas entre ellos debido a congestiones en la red (jitter). 

Además de todos los problemas inherentes a la propia red HFC no hay que olvidar que también están los problemas debidos a la parte IP de la red. Entre estos problemas tenemos los siguientes:

  1. Colisiones de paquetes IP debido al mecanismo de contienda CSMA/CD de las redes Ethernet. Obligará a retransmisiones de paquetes con los consiguientes delays.
  2. Delays en switches y routers.
  3. Buffer-overflow en switches y routers, con pérdidas de paquetes.
  4. Entrega de paquetes “fuera de secuencia” provocando delays en el proceso de ordenación e incluso pérdidas de paquetes en casos extremos por no poder ser utilizados al estar fuera del tiempo asignado.

Par siames en redes HFC_11

Principales problemas de la VoIP en redes HFC

Por si todos los problemas anteriores fueran poco,  es necesario tener en cuenta también el eco que se produce en las bobinas híbridas de las líneas analógicas. Este eco normalmente es atenuado en las propias líneas sin mayores problemas pero no sufre tal atenuación en la VoIP y los paquetes con eco alcanzan el otro extremo de la comunicación.

Un último factor a considerar es  la utilización de distintos codecs en cada tramo de la red, produciéndose con ello distorsiones de la señal de voz en el paso de un codec a otro. Este fenómeno se conoce con el nombre de “distorsión multi-tandem”. En el siguiente diagrama se muestran de forma gráfica el conjunto de problemas de la VoIP que influyen negativamente en la calidad de una llamada telefónica:

Par siames en redes HFC_11b

www.jdsu.com/voip

Aunque los nuevos estandar DOCSIS 2.0 DOCSIS 3.0 aportan mejoras que permiten un funcionamiento más fluido de la voz IP, es probable que aun así los operadores sigan manteniendo la red paralela de pares telefónicos, ya que de esta manera evitan muchos de los problemas que de una forma u otra seguirán apareciendo con la VoIP sobre redes HFC. En el siguiente diagrama se muestra la evolución de la red HFC del operador ONO desde el estándar DOCSIS 1.1 al estándar DOCSIS 3.0. En dicho diagrama se observa que se mantiene una red superpuesta de pares de cobre.

Par siames en redes HFC_12

Evolución de la red de ONO al estándar DOCSIS 3.0

Nota técnica: Como se ha indicado anteriormente, el “talón de Aquiles” de las redes HFC para la transmisión de voz por IP es el flujo ascendente o “upstream”. En el flujo descendente (downstream) los problemas son mucho menores y admiten mecanismos de corrección más eficaces por parte del operador.

  • En el flujo “downstream” el ancho de banda disponible es mucho mayor, con lo que los usuarios podrán recibir los paquetes de voz más rápidamente, o lo que es lo mismo, con menos delay y jitter.
  • Por otro lado, al haber un único equipo transmisor, el CMTS, desaparece el problema de “contienda” que se da en el flujo ascendente cuando varios usuarios quieren transmitir a la vez hacia el CMTS. En el flujo descendente el CMTS determina con precisión cuando envía paquetes de voz o datos a cada uno de los usuarios, pudiendo ajustar de forma óptima esta velocidad de envío para minimizar problemas de delays o jitter excesivos.
Publicado en Telefonía analógica | 1 comentario

Comunicación entre centralitas a través de RDSI

Cuando una empresa tiene una oficina principal y una o varias delegaciones en otras localidades, es una buena idea comunicar las centralitas de cada una de las delegaciones junto con la centralita de la oficina principal por medio de una red virtual. De esta manera, las llamadas internas dentro de una delegación y las llamadas a extensiones situadas en otras delegaciones o en la oficina principal serán llevadas a cabo de la misma manera: descolgar y marcar el número de extensión deseado. Con las centralitas Panasonic se puede realizar esta instalación de dos formas diferentes:

  • Método de número de extensión: Consiste en asignar un número de extensión único a todas las extensiones de la red.
  • Método de código de central: Consiste en asignar un código único a cada central, que se marca antes de que el número de extensión llame a una extensión de otra central.

Vamos a ver aquí de forma práctica el primero de los métodos, utilizando para ello dos centralitas NCP500 y la RDSI. El esquema del montaje podría ser como el mostrado a continuación:

Red privada_1

Como se observa en el diagrama, las extensiones de cada una de las sedes de la empresa tienen que tener una numeración única. En este caso las extensiones de la sede principal son a tres cifras y empezando por 1 (101, 102, 103,………) y las extensiones de la delegación son también a tres cifras pero empezando por 2 (201, 202, 203…….). Una vez ajustada la numeración de las extensiones en cada una de las centralitas, debemos de configurar lo siguiente:

Red privada_2

En la primera de las centralitas, configuramos dentro del Plan de Numeración un bloque de extensiones a tres dígitos y con el dígito como marcación inicial. De esta manera las extensiones en esta centralita serán las 101, 102, 103,…………..

Red privada_3

De la misma manera, tal y como se muestra en la captura de pantalla anterior, se indica en la opción Código Acceso Otra PBX  que todo número de extensión de 3 dígitos y que comience por  deberá ser enviado hacia una línea externa para acceder a otra PBX de la empresa (la línea externa podrá ser de cualquier tipo, analógica, RDSI o IP).

Red privada_4

Para la segunda de las centralitas programamos las mismas opciones pero con los valores correspondientes, es decir, las extensiones comenzarán por (201, 202, 203,……) y cada vez que se marque un número de extensión de tres cifras que comience por 1 el sistema deberá de enviar esa llamada a una línea externa

Red privada_5

Las líneas que se van a utilizar para está comunicación privada entre centralitas deberán de estar en un único grupo de líneas. En este ejemplo suponemos que en cada una de las dos centralitas tenemos dos accesos básicos conectados y que utilizamos el acceso básico del puerto 2 para las comunicaciones entre centralitas. En la siguiente captura de pantalla se muestra la asignación de los dos canales del acceso básico que está conectado en el puerto 2 al grupo de líneas 3.  Esta configuración se debe de hacer en ambas centralitas.

Red privada_6

Una vez hecho esto, en la centralita situada en la sede principal de la empresa acudimos a la opción de Red Privada y realizamos la configuración para que cada vez que un número de extensión comience por el dígito 2, se acceda a una línea externa del grupo 3. Como lo que queremos es que a través de la RDSI se alcance a cada una de las extensiones de la centralita situada en la delegación, utilizaremos la función de los números DDI. Para ello basta con asignar un número DDI a cada extensión en la centralita de destino e indicar en la centralita origen que se eliminen los tres dígitos marcados y que se añadan los 9 dígitos del número DDI de RDSI correspondientes a cada una de las extensiones llamadas.

Red privada_7

Como se observa en la captura de pantalla anterior, hemos utilizado para este ejemplo tan solo tres extensiones, la 201, 202 y 203. A cada una de ellas le hemos asignado un número DDI. Ahora debemos de acudir a la centralita de destino de estas llamadas, situada en la delegación de la empresa y debemos de configurar la entrada de llamadas según los números DDI anteriores para que, efectivamente, las llamadas a dichos números se dirijan de forma inmediata a cada una de las extensiones. En la siguiente pantalla se muestra dicha configuración:

Red privada_8Una vez hecho lo anterior,  debemos de programar en esta centralita de la delegación “la salida de llamadas”, igual que hemos hecho en la centralita situada en la sede principal de la empresa. Para ello acudimos a Red Privada y dentro de la opción de Tabla Red Privada indicamos que cada vez que se marque un número de extensión correspondiente a extensiones situadas en la centralita de la sede principal (101, 102, 103,….) se eliminen los tres dígitos marcados y se añada el número DDI correspondiente a cada una de estas extensiones dentro de la centralita de la sede principal:

Red privada_9Y finalmente debemos de programar también en la centralita situada en la sede principal la entrada de llamadas correspondientes a estos números DDI, tal y como hicimos anteriormente en la centralita situada en la delegación de la empresa:

Red privada_10Si todo está bien hecho y no hemos cometido ningún error en la programación, el funcionamiento será correcto y además, debido a la rapidez y fiabilidad de la RDSI las llamadas realizadas a extensiones situadas “en la otra centralita” serán tan inmediatas como las realizadas a extensiones de nuestra propia centralita, aunque dichas centralitas estén situadas a cientos de kilómetros una de otra.

Aunque hoy en día pueda parecer “extraño” utilizar RDSI en lugar de IP, hay que tener en cuenta también que los proveedores de RDSI ofrecen tarifas planas a nivel nacional y que el coste de los números DDI es cero. Por lo tanto, si se tiene un tráfico lo suficientemente intensivo de llamadas que justifique el coste mensual de los TR1, la solución basada en RDSI funcionará de forma impecable y con una rapidez y una fiabilidad que las soluciones basadas en IP no pueden alcanzar.

Nota: En breve se añadirá en este blog una nueva entrada explicando el proceso de configuración de una red privada entre centralitas a través de IP.

Publicado en RDSI | 4 comentarios