La Guía Absoluta Para Asterisk

La Guía

Absoluta Para

VoIP,

Asterisk

y trixbox

Por: Radhamés Fernández

La Guía Absoluta Para VoIP, Asterisk y trixbox

Por: Radhamés Fernández 2

Contenido 1. Sobre Telefonía 5

1.1. ¿Qué es una PBX? 5

1.2. Convirtiendo de Análogo a Digital 6

1.3. Protocolos de Señalización 7

1.3.1. Señalización en redes telefónicas clásicas 8

1.3.2. Videoconferencia sobre redes paquetes: H.323 10

1.3.3. Propuesta del IETF para la transmisión de VoIP: SIP 15

1.3.4. VoIP en la red de transito: MEGACO y MGCP 19

1.3.5. Redes Móviles de Tercera Generación: Hacia una Arquitectura “ALL-IP” 21

1.3.6. Conclusiones sobre los protocolos de señalización 24

1.3.7. Referencias 24

2. VoIP 27

2.1. ¿En qué se diferencia la telefonía IP de la telefonía normal? 27

2.2. ¿Qué compone un paquete de VoIP? 27

2.3. Calidad de Servicio (QoS) 28

2.3.1. Factores que alteran la calidad de la voz en VoIP 28

3. CODECS 32

4. Asterisk 34

4.1. Comandos de verificación en Linux útiles en Asterisk 34

4.2. Principales Comandos en Asterisk 35

4.3. Archivos de Configuración y Logs en Asterisk 37

5. Instalando Asterisk 38



6. Recursos para Ventas 39

6.1. Lista de Verificación Preventa 39

6.2. Valor agregado 40

6.3. Recursos para elaborar el presupuesto de un proyecto 40

6.4. Cómo calcular el Costo Total de Propiedad 40

6.5. Retorno de la Inversión (ROI) 41

6.6. Diseño, implementación, puesta en marcha y mantenimiento de Asterisk 42

6.6.1. Métodos de Conexión 42

6.6.2. Conceptos básicos de T1 43

6.6.3. Equipos Terminales 48

6.6.4. Equipos de comunicación 52

6.6.5. Especificaciones del Servidor: 53

6.7. Calidad en el uso de los recursos de voz en la empresa 54

7. Trixbox 55

7.1. ¿Qué es? 55

7.2. trixbox - Arquitecturas de Red 55

7.2.1. Arquitectura de una sola oficina 55

7.2.2. Arquitectura de una empresa con usuarios remotos 56

7.2.3. Arquitectura de una empresa con sucursales y un solo proveedor 56

7.2.4. Arquitectura de una empresa con sucursales y varios proveedores 57

7.2.5. Arquitectura de una empresa con sucursales, varios proveedores y un proveedor de VoIP. 59

7.3. Diferencias entre Asterisk y trixbox 60

7.4. Limitaciones y ventajas en el uso de trixbox como solución de telefonía 61

7.5. Soluciones de Asterisk existentes en el mercado 61

7.6. Instalación y Administración de trixbox CE 63



7.6.1. Pasos para empezar a trabajar con trixbox 63

7.6.2. Administración desde la consola Web: 63

7.7. Confección del plan de marcado y enrutamiento de llamadas 65

7.8. Conceptos básicos de CRM 70

7.9. Concepto básico de Comunicación Unificada 71

7.10. Concepto de “Autodialer” 71

7.11. Concepto de “Hosted PBX” 72

7.12. Mantenimiento y seguridad en trixbox 73

7.12.1. Cambiando las claves que vienen por defecto en trixbox 73

7.12.2. Copias de Respaldo (Backup) 78

7.12.3. Seguridad adicional 80

8. Enlaces de interés 81

9. Caso de Estudio: 82

10. Laboratorios 83



1. Sobre Telefonía Telefonía es la ciencia de convertir sonido en señales eléctricas y transmitirlo entre puntos

extensamente apartados.

El teléfono es un dispositivo de telecomunicación diseñado para transmitir señales acústicas por medio de señales eléctricas a distancia. Muy parecido al teletrófono.

¿Quién inventó el Teléfono?

Durante mucho tiempo Alexander Graham Bell fue considerado el inventor del teléfono, junto con Elisha Gray. Sin embargo Bell no fue el inventor de este aparato, sino solamente el primero en patentarlo. Esto ocurrió en 1876. El 11 de junio de 2002 el Congreso de Estados Unidos aprobó la resolución 269, por la que se reconocía que el inventor del teléfono había sido Antonio Meucci, que lo llamó teletrófono, y no Alexander Graham Bell. En 1871 Meucci sólo pudo, por dificultades económicas, presentar una breve descripción de su invento, pero no formalizar la patente ante la Oficina de Patentes de EE.UU (Artículo Tomado de Wikipedia).

1.1. ¿Qué es una PBX?

Una PABX, comúnmente conocida como PBX, es traducida al español como, Central Secundaria Privada Automática. Una PBX es privada porque pertenece a la empresa, aunque la compañía Telefónica le provea el servicio. En sus orígenes las PBX eran análogas, aunque en estos tiempos se puede notar que la mayoría de los equipos recientes son digitales. El uso de las PBX para las empresas tiende a ser atractivo, en relación a costo beneficio, debido a que es más factible manejar el volumen de teléfonos que se requieren, que correr una línea separada para cada equipo, sin mencionar que provee más servicios que los simples teléfonos estacionarios.

Figura: Central Telefónica Antigua



1.2. Convirtiendo de Análogo a Digital

Figura: Conversión de Análogo a PCM

La voz es una señal análoga. Para transportar las señales de voz a través de una red de

computadores, las ondas de sonido son convertidas en una señal análoga eléctrica, la cual debe

ser filtrada por un rango de frecuencia especifico (entre los 300 y 3,600 Hz) para así ser

convertida en una señal digital (la representación de las señales de voz analógicas usando 1s y

0s también conocidos como bits) para su transmisión a través de la Red.

Cuando la señal digital llega a su destino, es convertida otra vez en una señal análoga para

recrear ondas de sonido que el usuario pueda escuchar. La conversión de análogo a digital y

viceversa ocurre en diferentes puntos durante la transmisión.

Durante el proceso de conversión de análogo a digital ocurren una serie de pasos como

detallamos a continuación:

Filtrar la señal análoga entrante

La señal análoga entrante debe ser filtrada por un rango en la frecuencia de 300 a 3,600 Hz.

Este paso prepara la señal para la aplicación del Teorema de Nyquist, como se detalla en el

paso 2. Este rango de frecuencia es requerido para lograr las metas originales del sistema

telefónico: a) reconocer la voz de la otra persona, y b) poder entender lo que la otra persona

está diciendo.

Tomar una muestra del sonido

Muestreo es el proceso de convertir las ondas continuas en una secuencia numérica. Pulse

Code Modulation (PCM) es usado para hacer el muestreo del sonido. PCM asigna 8 bit de

código binario a una amplitud específica (muestra) de una señal. Usando PCM, una señal

análoga es muestreada a una velocidad de 8,000 veces por segundo. Este tipo de muestreo se



deriva de la teoría desarrollada por Harry Nyquist, quien estableció que para garantizar la

calidad de la secuencia numérica resultante, el muestreo de una onda de sonido debe ser al

menos dos veces la frecuencia máxima de la señal a ser muestreada.

Cuantizar la muestra de voz y codificarla (asignarle un número)

La muestra da como resultado un Pulse Amplitude Modulation (PAM), el cual es una serie de

pulsos que representan la amplitud de la señal análoga al momento de cada muestra.

Transmitir el código como una serie de bits a través de la Red

En la Telefonía tradicional basada en TDM, cada código de 8 bit es enviado a través de la Red

individualmente en un periodo de tiempo asignado a una llamada telefónica particular. En VoIP,

no podemos permitirnos el overhead que generarían el protocolo IP y la Capa 2 al enviar cada

byte producido por el CODEC a través de la Red. Por consiguiente, las series de bytes son

grabadas y agrupadas en muestras por un periodo específico de tiempo, usualmente en

incrementos de 10 ms. A esto se le conoce como tasa de empaquetado o tamaño de la muestra

de voz. Cuando el periodo de muestreo se ha alcanzado, la muestra de voz es empaquetada y

enviada a través de la Red. Los paquetes salen del origen en intervalos regulares.

Figura: Conversión de análogo a Digital

1.3. Protocolos de Señalización

En los últimos años, los protocolos de señalización para el servicio de transmisión de voz han

experimentado una fuerte evolución junto con la tendencia a trasportar dicho tráfico desde las

redes de conmutación de circuitos hacia las redes de conmutación de paquetes. Esta tendencia

queda reflejada con la fuerte evolución de estándares en este ámbito y la aparición de

productos en el mercado que cubren las necesidades de operadores, grandes empresas y

PYMES [1] [2] [3]. Esta tendencia se verá incrementada durante los próximos 5 años debido a la

evolución de las redes móviles basadas en tecnología UMTS hacia entornos “ALL-IP”. En este

artículo se presentan las diferentes arquitecturas que están siendo propuestas para soportar la

señalización de sistemas VoIP, debidas principalmente a los estándares H.323, SIP y MGCP,



junto con un breve resumen de los mecanismos de señalización en redes telefónicas clásicas

(SS7) y algunas ideas sobre la evolución hacia “ALL-IP” en redes móviles de 3G basadas en

UMTS.

1.3.1. Señalización en redes telefónicas clásicas

La señalización en las redes telefónicas clásicas ha experimentado una intensa evolución a lo

largo del siglo XX, al ritmo marcado por el propio desarrollo de las tecnologías de conmutación

de circuitos en las que estas redes se fundamentan. Tras la conmutación manual de finales del

siglo XIX y principios del XX, 1910 trajo la conmutación electromecánica. En esta etapa

tecnológica, que duró hasta los años 60, la señalización se transportaba "en banda" (cambios de

nivel y tonos dentro del propio canal telefónico) y era interpretada por elementos

electromecánicos (relés) y electrónicos (filtros) en su tránsito por la red.

A mediados de los 60, el proceso de digitalización de la red alcanzó la propia tecnología de

conmutación - red digital integrada de transmisión más conmutación - con la llegada de las

centrales digitales y el control de la conmutación por CPU (control por programa almacenado).

De este modo, los canales síncronos de 64 Kb/s son conmutados octeto a octeto espacial y

temporalmente. Estos conmutadores ya están controlados íntegramente por procesadores que

hablan un protocolo de señalización con procesadores de otras centrales. Los primeros

protocolos de señalización instalados en estos sistemas tenían una expresividad muy limitada y

se basaban en el estado de ciertos bits de la trama TDM permanentemente asociados a cada

canal de voz, como meras representaciones binarias de las señales analógicas de los sistemas

precedentes.

El salto cuántico se consiguió realmente cuando se aplicó totalmente la tecnología de redes de

ordenadores y las señales devinieron en mensajes intercambiados por aplicaciones sobre una

red de conmutación de paquetes independiente y dedicada a este fin.

Si bien en la actualidad la red telefónica utiliza internamente esta forma de funcionamiento

prácticamente en su totalidad, el último segmento por digitalizar, la red de acceso del abonado,

permanece masivamente analógica, con una penetración discreta de accesos íntegramente

digitales (RDSI). Consecuentemente, la señalización de abonado del servicio de telefonía

tradicional ha evolucionado muy poco y es dentro de la red donde se realizó una revolución

muy importante, transparente al usuario, que ha permitido la introducción de servicios

suplementarios, de telefonía móvil, de red inteligente, B-ISDN e inter funcionamiento con

sistemas de telefonía sobre IP (VoIP) entre otros.



El sistema de señalización de red que ha soportado esta evolución con gran flexibilidad es el

Sistema de Señalización nº 7. La primera norma del CCITT definiendo este sistema data de

1981 (Libro Amarillo), y ha sido refinada y extendida en ediciones sucesivas en 1985 (Libro

Rojo), 1989 [4] (Libro Azul) y subsiguientes de ITU-T.

El Sistema de Señalización nº 7 es una arquitectura de protocolos de señalización completa en

el que las unidades de señal son mensajes de las aplicaciones de señalización transportados en

paquetes. Las características esenciales de este sistema son:

Los enlaces y nodos de señalización constituyen una red de conmutación de paquetes

lógicamente independiente de la de conmutación de circuitos, con un plan de direccionamiento

distinto y definido a nivel internacional por ITU-T.

Es un sistema de señalización por canal común. Existe un conjunto predefinido de canales entre

centrales (y puntos de transferencia de señalización sin capacidad de conmutación de circuitos)

dedicados a transportar mensajes de señalización relativa al establecimiento, liberación y

supervisión de cualquier canal de 64 Kb/s de voz o datos. En los sistemas de señalización

previos, por canal asociado, la señalización asociada a cada circuito de voz se transportaba por

un canal de transmisión dedicado exclusivamente a él.

Es una arquitectura de protocolos estructurada en cuatro niveles.

Figura: El Protocolo SS7 desde la perspectiva del Modelo OSI

La red de paquetes para señalización en telefonía está diseñada específicamente para funcionar

sobre canales de 64 Kb/s y a gestionar dichos enlaces. Por consiguiente no parece improbable



una tendencia no sólo al desarrollo de formas de inter funcionamiento de arquitecturas

basadas en SS7 con arquitecturas basadas en IP, sino a que IP influya poderosamente en la

siguiente evolución de la infraestructura de red de señalización y gestión. Revisada aquí

brevemente la historia de los sistemas de señalización, resulta curioso observar cómo la

conmutación de paquetes, introducida en las redes tradicionales para ofrecer flexibilidad y

fiabilidad a las labores de señalización en el plano de control de las torres de protocolos, se

amplía en la actualidad al plano de usuario para el transporte de voz empaquetada,

integrándose de nuevo voz y señalización.

1.3.2. Videoconferencia sobre redes paquetes: H.323

La ITU-T fue el primer comité de estandarización que desarrolló un estándar para la

transferencia de tráfico multimedia sobre redes de paquetes. El estándar denominado H.323

fue estandarizado en 1996 y se denomino: “Sistemas y terminales de telefonía visual sobre

redes de área local sin garantías de calidad de servicio”. La principal aportación de este

estándar fue el desarrollo de un conjunto de protocolos de señalización que permiten controlar

el establecimiento, mantenimiento y liberación de conexiones de multimedia (audio, vídeo y

datos) sobre redes de paquetes, ya que los protocolos para la transmisión de estos medios

fueron adoptados de trabajos previos, principalmente desarrollados por el IETF a través de los

protocolos RTP y RTCP.

Tras esta primera versión, en 1998 apareció la segunda versión del protocolo H.323v2 con un

nuevo nombre: “Packet based multimedia communications systems”, nombre que permanece

hasta la actualidad (la versión 4 fue aprobada en Nov 2000 [6]). H.323 es considerado un

paraguas de estándares y define 4 tipos de elementos funcionales:



Figura: Arquitectura de H.323

Terminal H.323, es un terminal de la red que proporciona en tiempo real comunicación

bidireccional con otro terminal H.323, pasarela, o MCU (unidad de control multipunto). El

intercambio de información incluye controles, indicaciones, audio, video y datos. Un terminal

debe soportar al menos transmisión de voz, voz y datos, voz y video o voz datos y vídeo.

Figura: Estructura de Terminal H.323



Pasarela H.323 (Gateway), es un elemento de la red H.323 que permite inter operar a los

terminales H.323 con terminales en otras redes de circuitos (SCN). Las pasarelas se conectan

directamente con terminales H.323 o bien con otras pasarelas o terminales en otras redes y

realiza las funciones de adaptación entre flujos de información así como entre los protocolos de

control de ambos entornos. La recomendación H.323 incluye los terminales compatibles con las

recomendaciones: H.310, H.320 (B-RDSI), H.320 (RDSI), H.321 (ATM), H.322 (ISO Ethernet),

H.324 (GSTN), H.324M (Redes Móviles), and V.70 (DSVD). La pasarela debe constar al menos de

dos interfaces, realizando las funciones de adaptación y convergencia entre ambos interfaces.

Unidad de Control Multipunto (MCU), es el elemento funcional de la red H.323 que permite

soportar comunicaciones multipunto. A diferencia de entornos como la RDSI, la capacidad de

transmisión Multicast de las redes IP no requiere la utilización de un elemento externo a los

terminales para realizar funciones de mezclado de medios. Por esta razón, la MCU está dividida

en dos partes: el controlador multipunto (MC) que proporciona capacidad de negociación y

control de los miembros del grupos, y el procesador multipunto (MP) que se encarga de realizar

las funciones de mezcla de medios (audio, vídeo, datos). La funcionalidad de MCU puede ser

integrada en un terminal H.323.

Gatekeeper (GK), es un elemento de la red H.323 que proporciona servicios al resto de

elementos. Este elemento constituye la base para el desarrollo de servicios y para la aplicación

de esta tecnología en entornos con un número de terminales medio-grande. El GK es un

elemento opcional de la arquitectura, lo que permitió inicialmente el desarrollo de terminales

que podían comunicarse directamente entre sí sin la necesidad de disponer de GK. Sin embargo

la inexistencia de GK limita el servicio de transferencia de medios. Las funciones que

proporciona son: traslación de direcciones, autorización de llamadas, control de admisión,

control de zonas, gestión de ancho de banda, gestión de llamadas, reserva de ancho de banda,

servicios de directorio, etc.

La arquitectura de protocolos de H.323 se representa en la Figura 4 incluyendo tanto el

transporte de medios como el transporte de protocolos de señalización. La mayor parte de

canales de control utilizan conexiones TCP (también UDP a partir de la versión 3), mientras el

transporte de medios utiliza UDP.



Figura 4: Stack de protocolos H.323

Las entidades H.323 establecen conexiones en diferentes fases. Si consideramos un escenario

en el cual exista un GK, la conexión entre dos terminales dependientes de este GK sigue los

siguientes pasos Figura 5:

Fase A: Establecimiento de Llamada.

La entidad llamante, envía mensajes RAS solicitando la identificación del usuario llamante (ej.:

alias) utilizando un mensaje ARQ. El GK aceptará la llamada y enviará al terminal llamante un

mensaje de confirmación (ACF) o bien rechazará la llamada (ARJ). En caso positivo, la entidad

llamante establecerá una conexión TCP con el terminal llamado para establecer el canal de

señalización H.225.0. Para ello utilizará la información (dirección IP y puerto) recibidos del GK a

través del mensaje ACF. La entidad llamante al recibir dicha conexión contactará con su GK a

través del canal RAS solicitando permiso para poder contestar (ARQ). En caso positivo (ACF), el

llamante aceptara la conexión y a través de dicho canal (H.225.0) enviará la dirección (dirección

IP y puerto) donde establecer el canal H.245 para negociación de parámetros y control de la

comunicación.

Una vez obtenida esta información, la conexión puede ser finalizada, ya que no es necesario

intercambiar más parámetros a través de este canal.

Fase B: Intercambio de capacidades. (H.245)

Establecido el canal H.245 a través de una nueva conexión TCP, las entidades llamante y

llamada determinaran los parámetros de la comunicación: codificadores a utilizar, número de



conexiones y direcciones a utilizar, puertos, número de muestras por trama, función maestro-

esclavo, etc., lo que les permite establecer canales para la transmisión de medios (audio, vídeo

y datos). Esta conexión debe permanecer mientras intercambien información los terminales y

les permite modificar parámetros (CODECS, número de muestras por trama, etc.).

Fase C: Intercambio de información audiovisual

En este punto, ambos terminales establecen canales de información a través de la arquitectura

RTP/UDP/IP para el transporte de medios, así como canales de control a través de la

arquitectura RTCP/UDP/IP para los canales de realimentación, al objeto de controlar la calidad

de los flujos de información recibida por el otro extremo de la comunicación.

Fase D: Terminación de llamada

Tras el intercambio de información audiovisual y al objeto de finalizar la llamada, las entidades

H.323 deben informarse a través del canal H.245 mediante el envío de las primitivas de

finalización de llamadas, que finalizará con el envío de la primitiva EndSessionCommand que

provocará el cierre del canal H.245. Además deberán informar al GK mediante el envío de el

mensaje RAS Disengage Request (DRQ) que permitirá al GK liberar recursos y proporcionar

información de tarificación entre otras.

Sobre este escenario básico existen múltiples variantes en función de la presencia o no del GK y

del role que el mismo realice. El GK podría encaminar la información de control, (H.225.0 y

H.245) o no en función del modelo elegido (Directo o Indirecto).



Figura 5: Ejemplo llamada H.323

Del ejemplo mostrado anteriormente, se observa el coste de establecimiento de llamada

debido a la necesidad de establecer múltiples conexiones previas al intercambio de

información. Esta necesidad fue solventada con la aparición de la versión dos del protocolo,

que proporciona dos posible modos de operación opcionales alternativos: Procedimiento de

Conexión Rápida, que permite abrir canales de información a partir de la fase de intercambio

de información H.225.0 y el procedimiento de establecimiento de túneles H.245 sobre H.225.0,

que permite utilizar el mismo canal para transmitir mensajes H.225.0 y H.245.

1.3.3. Propuesta del IETF para la transmisión de VoIP: SIP

Session Initiation Protocol (SIP), es un protocolo de aplicación desarrollado por el IETF dentro

del grupo MMUSIC (Multiparty Multimedia Session Control) y especificado en la RFC2543 [7].

Este protocolo permite a los usuarios, participar en sesiones de intercambio de información

multimedia soportando mecanismos de establecimiento, modificación y finalización de llamada.

El grupo de trabajo MMUSIC [8] se encarga de desarrollar recomendaciones relacionadas con el

soporte de conferencias y fue el encargado de desarrollar las aplicaciones utilizadas en la red

MBONE. Uno de los objetivos del grupo consiste en desarrollar mecanismos para informar a los

usuarios acerca de las sesiones existentes en la red, requisitos de los medios, direcciones, etc.

En este sentido existen dos modos básicos de identificar y participar en sesiones multimedia:



Mecanismo de Anuncio. Las sesiones son anunciadas mediante email, páginas web, grupos de

noticias o bien mediante el protocolo de anuncio de sesiones (SAP) como sucede en la red

MBONE.

Mecanismo de Invitación. Los usuarios son, mediante invitación, informados por otros a

participar mediante el protocolo de establecimiento de sesiones (SIP).

De entre ambos, SIP ha sido propuesto como un mecanismo genérico para el soporte de

mecanismos de señalización del servicio de telefonía IP. SIP soporta 5 elementos funcionales

para el establecimiento y terminación de comunicaciones multimedia:

Localización de usuarios

Intercambio / negociación de capacidades de los terminales

Disponibilidad de usuarios

Establecimiento de llamada

Mantenimiento de llamada

SIP es un protocolo basado en el modelo cliente-servidor. Los clientes SIP envían peticiones

(Requests Messages) a un servidor, el cual una vez procesada contesta con una respuesta

(Response Messages). Los terminales SIP pueden generar tanto peticiones como respuestas al

estar formados por el denominado cliente del agente de usuario {UAC] y servidor del agente de

usuario [UAS].

Los terminales SIP pueden establecer llamadas de voz directamente sin la intervención de

elementos intermedios, al igual que en el caso de H.323. La Figura 6 muestra un ejemplo de

conexión entre user1 con dirección IP 172.16.10.1 y user2 con dirección IP 172.16.1.2 mediante

el envío de una petición INVITE Request, en la cual el user1 indica al user2 las capacidades de

recepción de audio (codificación ley µ) y el puerto donde espera recibir dicho audio (port

12345). Al recibir la petición, el user2 puede inmediatamente establecer el canal de voz y enviar

la aceptación de conexión mediante el envío de OK Response, en la cual incluye la información

complementaria para el establecimiento del canal opuesto (codificación GSM, puerto 54321 en

nuestro ejemplo). Tras el intercambio de señal de audio, cualquiera de los participantes puede

finalizar la llamada mediante el envío del mensaje BYE Request que debe ser asentido

mediante un mensaje de confirmación (OK).



Figura 6: Establecimiento de llamada SIP

Los mensajes SIP son codificados utilizando la sintaxis de mensajes definidos en HTTP/1.1, [9] y

el contenido de cada mensaje sigue las recomendaciones del protocolo de descripción de

sesiones (SDP) [10], ampliamente utilizado en el contexto de MBONE para distribuir la

información de sesiones.

Además de los terminales H.323 que representan teléfonos IP o pasarelas, la arquitectura SIP

define cuatro tipos de servidores:

Servidor Proxy. Se encarga de encaminar peticiones/respuestas hacía el destino final. El

encaminamiento se realiza salto a salto de un servidor a otro hasta alcanzar el destino final.

Para estos casos, existe un parámetro incluido en las peticiones/respuestas denominado Vía

que incluye los sistemas intermedios que han participado en el proceso de encaminamiento.

Esto evita bucles y permite forzar que las respuestas sigan el mismo camino que las peticiones.

Esto afecta únicamente a la información de control pues el transporte de medios, salvo en el

caso de requerir transcodificación intermedia, se realiza directamente entre origen y destino.



Servidor de Redirección. Realiza una función equivalente al servidor proxy, pero a diferencia de

éste no progresa la llamada, sino que contesta a un INVITE con un mensaje de redirección,

indicándole en el mismo como contactar con el destino.

Servidor de Registro. Mantienen la localización actual de un usuario. Se utiliza para que los

terminales registren la localización en la que se encuentran. Este servidor facilita la movilidad

de usuarios, al actualizar dinámicamente la misma.

Agente de Llamada (Call Agent). Realiza las funciones de los tres servidores anteriores, además

de poder realizar las siguientes acciones:

o Localizar a un usuario mediante la redirección de la llamada a una o varias localizaciones

o Implementar servicios de redirección como reenvío si ocupado, reenvío si no contesta, etc.

o Implementar filtrado de llamada en función del origen o del instante de la llamada

o Almacenar información de administración de llamas

o Realizar cualquier otra función de gestión

Las direcciones SIP son identificadas mediante los denominados URI (Uniform Resource

Identifiers) [11], que sigue la estructura user@host, donde user corresponde con un nombre,

identificador o número telefónico y host es el dominio al que pertenece el usuario o dirección

de red.

En la Figura 7 se muestra un ejemplo de interacción entre servidores SIP. En este ejemplo David

desde su oficina (company.es) desea llamar al usuario jmoreno del dominio upm.es. Para ello

envía una petición (NOTIFY Request) al servidor SIP de su organización, el cual actúa como un

servidor proxy y tras consultar el DNS, localiza el servidor SIP del dominio upm.es, reenviándole

la petición. Este servidor, que actúa como servidor de redirección, contesta a la petición

indicándole que el usuario jmoreno se encuentra localizado en otro dominio (uc3m.es). El

servidor sip.company.es progresa de nuevo la llamada hacia el servidor SIP del dominio

uc3m.es, quien ahora actúa como un Agente (Call Agent) y tras consultar la BD/DNS intenta

localizar al usuario en el sistema host1.uc3m.es. Tras un periodo de espera y al no contestar el

usuario en dicho terminal, cancela la llamada e intenta localizar al usuario en host2.uc3m.es,

quien ahora contesta. La aceptación de llamada progresa hasta el origen pasando por los

servidores de redirección involucrados, momento en el cual origen y destino pueden establecer

los canales de voz.



Figura 7: Ejemplo de Servidores SIP

La principal característica de SIP frente a H.323 es su simplicidad. Mientras H.323v1 necesita 5 o

6 intercambios de información entre los destinatarios antes de establecer una conexión, SIP

requiere únicamente uno y puede ser transmitido por TCP o UDP. Estos aspectos fueron

introducidos en la versión 2 y 3 del protocolo H.323.

1.3.4. VoIP en la red de transito: MEGACO y MGCP

H.323 y SIP se desarrollaron teniendo como objetivo el desarrollo de terminales que estuvieran

directamente conectados a la red IP e intercambiaran tráfico de voz directamente entre sí o

bien con terminales tradicionales (conectados a redes conmutadas) mediante el uso de

pasarelas. El objetivo inicial de MEGACO fue la utilización de redes de paquetes como backbone

para la transmisión de tráfico de voz originado por redes tradicionales. Los operadores

tradicionales fueron uno de los que mayor interés han mostrado en esta propuesta, pensando

en integrar progresivamente sus redes de telefonía basadas en conmutación de circuitos y sus

redes de datos basadas en conmutación de paquetes en una red homogénea que transportará

ambos tipos de tráfico (voz y datos) y que fuera transparente a los usuarios finales.

MEGACO resuelve este problema dividiendo las pasarelas (Gateways) en tres entidades

diferentes:



Controlador de Medios (Media Gateway Controller –MGC-), que proporciona la señalización

H.323 o SIP y realiza el mapping entre la señalización de redes tradicionales y las redes de

paquetes.

Pasarela de Medios (Media Gateway –MG-), que proporciona la adaptación de medios y/o las

funciones de transcodificación. Este bloque realiza las funciones de traslación de direcciones,

cancelación de eco, envío/recepción de dígitos DMTF, etc.

Pasarela de Señalización (SG), que proporciona funciones de mediación de señalización entre

redes IP y SCN.

En un escenario habitual los tres elementos están físicamente separados de modo que pueden

proporcionar ventajas como la concentración de muchos MG (conectados a usuarios finales) en

algunos MGC controlados por un SG. La Figura 8 muestra la arquitectura de MEGACO.

Figura 8: Arquitectura MEGACO

Media Gateway Control Protocol (MGCP) es un protocolo cliente/servidor que controla el

intercambio de información entre MG y MGC. MGCP es el resultado de protocolos

anteriormente propuestos y ha sido propuesto en distintos organismos de estandarización

como el grupo de trabajo MEGACO del IETF [12], [13] y la ITU-T [14] donde se ha denominado

H.248. MGCP utiliza a su vez el protocolo SDP para el intercambio de parámetros entre el MG y

MGC (dirección IP, puerto UDP, codificadores a utilizar, etc.).



1.3.5. Redes Móviles de Tercera Generación: Hacia una Arquitectura “ALL-IP”

El “Third Generation Parnertship Project”, 3GPP [15] tiene como objetivo la estandarización de

sistemas móviles de tercera generación (3G) basados en la evolución del núcleo de red GSM y

en tecnologías WCDMA en el acceso radio. A estos sistemas se les llama Sistemas de

Telecomunicación Móvil Universal (UMTS) y los primeros sistemas comerciales se lanzarán al

mercado durante el último trimestre del año 2000.

La primera fase de la especificación de UMTS finalizó a principios del año 2000 y el resultado se

conoce con el nombre de Release 1999 (R99). El 3GPP continúa desarrollando especificaciones

que definan la evolución de los sistemas UMTS. La Release 4 y la Release 5 (que está previsto

finalizar en diciembre de 2001) son los siguientes pasos de esta evolución. En esta sección

describimos brevemente la arquitectura UMTS R99 así como la evolución prevista y el papel

que los protocolos relacionados con VoIP juegan en ella.

La arquitectura UMTS R99 [17] (Figura 9) es una arquitectura GSM/GPRS [23], [24] con una

nueva red de acceso.

Figura 9: Arquitectura UMTS R99

En esta arquitectura, los RNCs (Radio Network Controler) y los Nodos B forman la red de acceso

radio UMTS (UTRAN) mientras la red de acceso GSM basada en BTSs y BSCs pueden coexistir.

Los MSCs y GMSCs forman el dominio de conmutación de circuitos (CC) y transportan el tráfico



de voz. Los SGSNs y los GGSNs forman el dominio de conmutación de paquetes (CP) y

transportan el tráfico de datos en modo paquete. El VLR, el HLR, el EIR, y el AuC, mantienen

información sobre los usuarios. Los MSCs o GSNs los pueden interrogar utilizando el protocolo

MAP (Mobile Application Part ).

Por tanto, el núcleo de red UMTS está formado por dos redes, una de conmutación de circuitos

(dominio CC) y una de conmutación de paquetes (dominio CP). Este diseño permite a los

operadores de redes GSM/GPRS una fácil evolución hacia sistemas UMTS. Pero, en el futuro,

estos sistemas tendrán un núcleo de red unificado basado en una red de conmutación de

paquetes IP, tal como se indica en la Release 4 y 5 y quizá incluso, la evolución hacia la red IP

incluya también la red de acceso, tal como se trabaja en distintos proyectos de investigación

europeos *19+. Esto se conoce con el nombre de arquitectura “All-IP” *20+. La razón es que las

redes de conmutación de paquetes son eficientes y capaces de transportar las diferentes clases

de tráfico. Además, IP es un protocolo probado y que permite una fácil intercomunicación con

Internet.

Figura 10: Dominio CC

En la Figura 10 se muestra la evolución prevista para el dominio CC de UMTS. Las MSCs se

dividen en dos elementos, el MSC server y la MGW (Media Gateway Function). El MSC server es

responsable del control de movilidad y de llamada, y termina la señalización usuario-red,

traduciéndola a la señalización red-red apropiada. El control de llamada red-red (interfaz entre

MSC servers) se realizará mediante señalización ISUP, o por una evolución de ISUP para control

de llamada independiente de servicio portador (BICC).

La MGW es responsable del transporte de datos de usuario. El dominio CC es ahora

independiente de la tecnología de transporte: VoIP (RTP/UDP/IP), VoATM (AAL2), y TDM, son

opciones para el transporte de voz en este dominio. También hay diferentes opciones para el



control del servicio portador, por ejemplo se puede usar H.245 si los datos de usuario se

transportan mediante RTP. La interfaz entre el MSC server y la MGW usa el estándar

H.248/MEGACO. La T-SGW (Tranport Signalling GateWay function) se encarga de coger la

información de señalización relacionada con llamadas procedentes de la PSTN y ponerla sobre

el servicio portador empleado en el dominio CC (o viceversa). El HSS es equivalente al HLR de la

UMTS R99, pero con información añadida sobre servicios IP multimedia.

Es interesante destacar que, independientemente de la tecnología de transporte empleada en

el dominio CC, los terminales UMTS R99 van a poder utilizar los servicios del dominio CC.

Cualquier nueva función de señalización es realizada por la red.

Figura 11: Dominio CP y subsistema IP multimedia

En la figura 11 se muestra la evolución prevista para el dominio CP de UMTS. Al dominio CP se

le añade un nuevo subsistema llamado IP Multimedia (IM), que contiene los siguientes

elementos: la CSCF (Call State Control Function), la MGCF (Media Gateway Control Function), y

la T-SGW. Este subsistema tiene como objetivo soportar servicios multimedia (por ejemplo,

VoIP) en el dominio CP. La CSCF realiza encaminamiento (a nivel de aplicación) de llamadas

entrantes, establecimiento y liberación de llamadas, manejo de direcciones, etc. La MGCF

controla las MGWs usando H.248. También realiza conversión de protocolos entre ISUP

(empleado en la PSTN) y el protocolo de control de llamadas empleado en el subsistema IM (i.e.

SIP). La T-SGW se encarga de coger la información de señalización relacionada con llamadas



procedentes de la PSTN, ponerla sobre el servicio portador IP (SIGTRAN) empleado en el

subsistema IM, y enviarla hacia la MGCF (o viceversa).

Los terminales móviles que quieren usar los servicios IP Multimedia deben ser terminales IP con

capacidad de señalización SIP. Se comunican con la CSCF para registrarse y para solicitar

servicios.

1.3.6. Conclusiones sobre los protocolos de señalización

Los sistemas de señalización para el transporte de voz han evolucionado desde las redes

basadas en conmutación de circuitos a redes basadas en conmutación de paquetes. Diferentes

estándares han aparecido para tratar de solventar problemas de direccionamiento, control de

admisión, interconexión con redes existentes, intercambio de capacidades, etc. Basados en la

transmisión de VoIP y el tipo de usuarios, dos diferentes escenarios han sido objeto de

desarrollo por parte de los organismos de estandarización: usuarios directamente conectados a

redes IP y operadores que utilizando la red IP como backbone interconectan usuarios

tradicionales conectados a redes SCN. El primer escenario constituye el ámbito de aplicación de

protocolos como H.323 y SIP, mientras el segundo escenario lo forma el ámbito de MEGACO y

H.248.

Actualmente existen operadores y empresas que utilizan estas tecnologías para ofrecer un

servicio de transmisión de voz. Esta tendencia a sustituir las redes de conmutación de circuitos

por redes de conmutación de paquetes se verá incrementada en los próximos años con la

evolución de las redes móviles UMTS hacia la tecnología “ALL-IP”, en la cual los servicios

multimedia, y por tanto el servicio de transmisión de voz, serán transmitidos sobre redes bajo

tecnología IP.

1.3.7. Referencias

[1] Teldat web site: http://www.teldat.es

[2] Cisco web site: http://www.cisco.com

[3] Nortel web site: http://www.nortel.com

[4] Specifications of Signalling System Nº 7. CCITT Blue Book, fascicle VI.7, recommendations

Q.701-Q.716, Q.721-Q.766, Q.771-Q.795. ITU1989.

[5] RFC 1889. H.Shulzrinne, S.Castner, R.Frederick, V.Jacobson. RTP: A transport protocol for

real time protocol.



[6] ITU-T Recommendation H.323: “Packet-based Multimedia Communications Systems”,

November 2000

[7] RFC2543. M.Handley, H.Shulzrinne, E.Schooler, E.Rosenberg. SIP: Session Initiation Protocol.

[8] MMUSIC web site: http://www.ietf.org/mmusic

[9] RFC 2068. R. Fielding and others. Hypertext Transfer Protocol -- HTTP/1.1

[10] RFC 2327. 2327 M. Handley, V. Jacobson, SDP: Session Description Protocol.

[11] RFC 2396. T.Berners-Lee, R.Fielding, Uniform Resource Identifiers (URI): generic syntax.

*12+ RFC2705. M. Arango et al, “Media Gateway Control Protocol (MGCP)”.

*13+ RFC 3015. F. Cuervo, N. Greene, A. Rayhan et al, “Megaco Protocol Version 1.0”

[14] ITU-T H.248: “Gateway Control Protocol”, June 2000

[15] 3GPP web site: http://www.3gpp.org

[16] 3GPP Technical Specification TS 23.002, v5.0.0: Network Architecture (Release 5). October,

2000.

[17] 3GPP Technical Specification TS 23.002, v3.3.0: Network Architecture (Release 1999).

March, 2000.

[18] C. Bettstetter, H-J Vögel, J. Eberspächer; GSM Phase 2+, General Packet Radio Service

GPRS: Architecture, Protocols, and Air Interface; IEEE Communications Surveys Vol. 2, No. 3,

1999.

[19] MobyDick Project: http://www.ist-mobydick.org/

[20] Lieve Bos, Suresh Leroy; Toward an All-IP-Based UMTS System Architecture; IEEE Network,

Vol. 15, No. 1; 2001.

Tomado del artículo: Protocolos de Señalización para el transporte de Voz sobre redes IP

Por: Jose Ignacio Moreno, es Doctor Ingeniero de Telecomunicaciones por la Universidad Politécnica

de Madrid (1996) y trabaja como Profesor Titular de Ingeniería Telemática en la Universidad

Carlos III de Madrid.



Ignacio Soto, es Doctor Ingeniero de Telecomunicaciones por la Universidad de Vigo (2000) y

trabaja como Profesor Ayudante en la Universidad Carlos III de Madrid.

David Larrabeiti, es Doctor Ingeniero de Telecomunicaciones por la Universidad Politécnica de

Madrid (1996) y trabaja como Profesor Titular de Ingeniería Telemática en la Universidad Carlos

III de Madrid.



2. VoIP

Para definir el concepto esencial de VoIP, quisiera romper con la confusión de dos conceptos

altamente mencionados en estos días:

Voice over IP / Voz sobre IP (VoIP): es el conjunto de normas, dispositivos, protocolos, en definitiva la tecnología que permite la transmisión de la voz sobre el protocolo IP.

Telefonía IP: es el conjunto de nuevas funcionalidades de la telefonía, es decir en lo que se

convierte la telefonía tradicional debido a los servicios que finalmente se pueden llegar a

ofrecer gracias a poder portar la voz sobre el protocolo IP en redes de datos.

2.1. ¿En qué se diferencia la telefonía IP de la telefonía normal?

En una llamada telefónica normal, la Central Telefónica establece una conexión permanente entre ambos interlocutores, conexión que se utiliza para llevar las señales de voz. En una llamada telefónica por IP, los paquetes de datos, que contienen la señal de voz digitalizada y comprimida, se envían a través de Internet o nuestra LAN a la dirección IP del destinatario. Cada paquete puede utilizar un camino para llegar, están compartiendo un medio, una red de datos. Cuando llegan a su destino son ordenados y convertidos de nuevo en señal de voz.

2.2. ¿Qué compone un paquete de VoIP?

Comenzando desde lo básico, el paquete de VoIP en un Sándwich multiprotocolo en el cual la

voz es encapsulada en capas de: Real Time Protocol (RTP); User Datagram Protocol (UDP); IP e

Ethernet habilitados con Calidad de Servicio (802.1q). Cada protocolo es definido con

componentes de diferentes dimensiones, que en combinación con la voz toma la forma de un

paquete común y corriente.

Figura: composición paquete de VoIP



2.3. Calidad de Servicio (QoS)

En VoIP se cuenta con diferentes herramientas y mecanismos para lograr la calidad de la transmisión de la voz sobre los medios de datos:

La supresión de silencios, otorga más eficiencia a la hora de realizar una transmisión de voz, ya que se aprovecha mejor el ancho de banda al transmitir menos información.

Compresión de cabeceras aplicando los estándares RTP/RTCP. Priorización de los paquetes que requieran menor latencia. Las tendencias actuales son:

o CQ (Custom Queuing): Asigna un porcentaje del ancho de banda disponible.

o PQ (Priority Queuing): Establece prioridad en las colas.

o WFQ (Weight Fair Queuing): Se asigna la prioridad al tráfico de menos carga.

o DiffServ: Evita tablas de encaminados intermedios y establece decisiones de rutas por paquete.

La implantación de IPv6 que proporciona mayor espacio de direccionamiento y la posibilidad de tunneling.

2.3.1. Factores que alteran la calidad de la voz en VoIP

Jitter

El jitter es un efecto de las redes de datos no orientadas a conexión y basadas en conmutación

de paquetes. Como la información se propaga en paquetes, cada uno de los paquetes puede

seguir una ruta distinta para llegar al destino.

El jitter se define técnicamente como la variación en el tiempo en la llegada de los paquetes,

causada por congestión de red, pérdida de sincronización o por las diferentes rutas seguidas

por los paquetes para llegar al destino.

Las comunicaciones en tiempo real (como VoIP) son especialmente sensibles a este efecto. En

general, es un problema frecuente en enlaces lentos o congestionados. Se espera que el

aumento de mecanismos de QoS (calidad del servicio) como prioridad en las colas, reserva de

ancho de banda o enlaces de mayor velocidad (100Mb Ethernet, E3/T3, SDH) puedan reducir

los problemas del jitter en el futuro, aunque seguirá siendo un problema por bastante tiempo.



o Valores Recomendados

El jitter entre el punto inicial y final de la comunicación debe ser inferior a 100 ms. Si el valor es

menor a 100 ms el jitter puede ser compensado de manera apropiada. En caso contrario debe

ser minimizado.

o Posibles Soluciones:

La solución más ampliamente adoptada es la utilización del jitter buffer. El jitter buffer consiste

básicamente en asignar una pequeña cola o almacén para ir recibiendo los paquetes y

sirviéndolos con un pequeño retraso. Si algún paquete no está en el buffer (se perdió o no ha

llegado todavía) cuando sea necesario se descarta. Normalmente en los teléfonos IP (hardware

y software) se pueden modificar los buffers. Un aumento del buffer implica menos pérdida de

paquetes pero más retraso. Una disminución implica menos retardo pero más pérdida de

paquetes.

Latencia

A la latencia también se la llama retardo. No es un problema específico de las redes no

orientadas a conexión y por tanto de VoIP. Es un problema general de las redes de

telecomunicación. Por ejemplo, la latencia en los enlaces vía satélite es muy elevada por las

distancias que debe recorrer la información.

La latencia se define técnicamente en VoIP como el tiempo que tarda un paquete en llegar

desde la fuente al destino.

Las comunicaciones en tiempo real (como VoIP) y full-duplex son sensibles a este efecto. Al

igual que el jitter, es un problema frecuente en enlaces lentos o congestionados.

o Valores Recomendados:

La latencia o retardo entre el punto inicial y final de la comunicación debe ser inferior a 150 ms.

El oído humano es capaz de detectar latencias de unos 250 ms, 200 ms en el caso de personas

bastante sensibles. Si se supera ese umbral la comunicación se vuelve molesta.


No hay una solución que se pueda implementar de manera sencilla. Muchas veces depende de

los equipos por los que pasan los paquetes, es decir, de la red misma. Se puede intentar

reservar un ancho de banda de origen a destino o señalizar los paquetes con valores de TOS

para intentar que los equipos sepan que se trata de tráfico en tiempo real y lo traten con mayor

http://www.voipforo.com/diccionario/F.php

http://www.voipforo.com/diccionario/T.php



prioridad pero actualmente no suelen ser medidas muy eficaces ya que no disponemos del

control de la red.

Si el problema de la latencia está en nuestra propia red interna podemos aumentar el ancho de

banda o velocidad del enlace o priorizar esos paquetes dentro de nuestra red

Eco

El eco se produce por un fenómeno técnico que es la conversión de 2 a 4 hilos de los sistemas

telefónicos o por un retorno de la señal que se escucha por los altavoces y se cuela de nuevo

por el micrófono.

El eco se define como una reflexión retardada de la señal acústica original.

El eco es especialmente molesto cuanto mayor es el retardo y cuanto mayor es su intensidad

con lo cual se convierte en un problema en VoIP, puesto que los retardos suelen ser mayores

que en la red de telefonía tradicional.


El oído humano es capaz de detectar el eco cuando su retardo con la señal original es igual o

superior a 10 ms. Pero otro factor importante es la intensidad del eco ya que normalmente la

señal de vuelta tiene menor potencia que la original. Es tolerable que llegue a 65 ms y una

atenuación de 25 a 30 dB.


Citamos dos posibles soluciones para evitar este efecto tan molesto.

Supresores de eco: Consiste en evitar que la señal emitida sea devuelta convirtiendo por

momentos la línea full-duplex en una línea half-duplex de tal manera que si se detecta

comunicación en un sentido se impide la comunicación en sentido contrario. El tiempo de

conmutación de los supresores de eco es muy pequeño. Impide una comunicación full-duplex

plena.

Canceladores de eco: Es el sistema por el cual el dispositivo emisor guarda la información que

envía en memoria y es capaz de detectar en la señal de vuelta la misma información (tal vez

atenuada y con ruido). El dispositivo filtra esa información y cancela esas componentes de la

voz. Requiere mayor tiempo de procesamiento.

http://www.voipforo.com/diccionario/F.php

http://www.voipforo.com/diccionario/H.php



Pérdida de paquetes:

Las comunicaciones en tiempo real están basadas en el protocolo UDP. Este protocolo no está

orientado a conexión y si se produce una pérdida de paquetes no se reenvían. Además la

pérdida de paquetes también se produce por descartes de paquetes que no llegan a tiempo al

receptor.

Sin embargo la voz es bastante predictiva y si se pierden paquetes aislados se puede

recomponer la voz de una manera bastante óptima. El problema es mayor cuando se producen

pérdidas de paquetes en ráfagas.


La pérdida de paquetes máxima admitida para que no se degrade la comunicación deber ser

inferior al 1%. Pero es bastante dependiente del CODEC que se utiliza. Cuanto mayor sea la

compresión del CODEC más pernicioso es el efecto de la pérdida de paquetes. Por ejemplo, una

pérdida del 1% degrada más la comunicación si se usa el CODEC G.729 en vez del G.711.


Para evitar la pérdida de paquetes una técnica muy eficaz en redes con congestión o de baja

velocidad es no transmitir los silencios. Gran parte de las conversaciones están llenas de

momentos de silencio. Si solo transmitimos cuando haya información audible liberamos

bastante los enlaces y evitamos fenómenos de congestión.

De todos modos este fenómeno puede estar también bastante relacionado con el jitter y el

jitter buffer.

http://www.voipforo.com/diccionario/U.php



3. CODECS

Un CODEC es un algoritmo, o programa especializado de computadora, que convierte señales

análogas (como la voz) en un resultante digital para su transmisión en una Red de Datos y a su

vez reconvertir esa señal digital generada en una señal análoga al otro lado.

Regularmente los CODECs son usados para minimizar el uso de Ancho de Banda en las

conexiones a la hora de una implementación de Telefonía IP.

Figura: Cálculo de Ancho de Banda según el uso de CODEC:

Codec & Bit

Rate (Kbps)

Codec

Sample

Size

(Bytes)

Codec

Sample

Interval

(ms)

Mean

Opinion

Score

(MOS)

Voice

Payload

Size

(Bytes)

Voice

Payload

Size (ms)

Packets Per

Second

(PPS)

Bandwidth

MP or

FRF.12

(Kbps)

Bandwidth

w/cRTP MP

or FRF.12

(Kbps)

Bandwidth

Ethernet

(Kbps)

G.711 (64

Kbps) 80 Bytes 10 ms 4.1 160 Bytes 20 ms 50 82.8 Kbps 67.6 Kbps 87.2 Kbps

G.729 (8


G.723.1

(6.3 Kbps) 24 Bytes 30 ms 3.9 24 Bytes 30 ms 34 18.9 Kbps 8.8 Kbps 21.9 Kbps

G.723.1

(5.3 Kbps) 20 Bytes 30 ms 3.8 20 Bytes 30 ms 34 17.9 Kbps 7.7 Kbps 20.8 Kbps

G.726 (32


G.726 (24

Kbps) 15 Bytes 5 ms 60 Bytes 20 ms 50 42.8 Kbps 27.6 Kbps 47.2 Kbps

G.728 (16


Codec Information Bandwidth Calculations



Figura: Definición de los Términos expuestos en el cuadro anterior:

PCM

VOZ A

64Kbps

DIG

ITA

LIZ

AC

ION

MU

ES

TR

EO

Voz a 8Kbps

Voz Digital y

Comprimida

Voz

Análoga

Ancho de Banda

Disponible

Ancho de Banda

Disponible

CompresiónDSP

Figura: Diagrama que representa la compresión luego de aplicar el CODEC:

Codec Bit Rate (Kbps)Basado en el CODEC, este es el número de bits por segundo que necesitan ser transmitidos para

que una llamada de voz progrese. (codec bit rate = codec sample size / codec sample interval).

Codec Sample Size (Bytes)

Basado en el CODEC, este es el número de bytes capturados por el Procesador de Señales

Digitales (DSP) en cada intervalo de de muestreo del CODEC. Por ejemplo, el codificador de G.729

opera en intervalos de muestra de 10ms, correspondientes a 10 bytes (80 bits) por muestra en

un bit rate de 8 Kbps. (codec bit rate = codec sample size / codec sample interval).

Codec Sample Interval (ms)

Este es el intervalo de muestra en el cual el CODEC opera. Por ejemplo, el codificador de G.729

opera en intervalos de muestra de 10ms, correspondientes a 10 bytes (80 bits) por muestra en

un bit rate de 8 Kbps. (codec bit rate = codec sample size / codec sample interval).

MOS

MOS es un sistema de evaluación de la calidad de la voz sobre conexiones telefónicas. Con MOS

un amplio rango de escuchas evalúa la calidad de la muestra de voz en una escala de uno (mal)

a cinco (excelente). Los resultados son promediados para obtener el MOS para el CODEC en

cuestión.

Voice Payload Size (Bytes)

El tamaño de la “carga útil” de voz representa el número de bytes (o bits) que son introducidos

en un paquete. El tamaño de la “carga útil” de voz debe ser múltiplo del tamaño de la muestra

del CODEC. Por ejemplo, los paquetes de G.729 pueden usar 10, 20, 30, 40, 50, o 60 bytes de

tamaño para la “carga útil” de voz.

Voice Payload Size (ms)

El tamaño de la “carga útil” de voz puede ser representado también en términos de muestras del

CODEC. Por ejemplo, una capacidad de “carga útil” de voz de G.729 de 20 ms (dos muestras de

CODEC de 10 ms) representan una carga útil de 20 bytes [ (20 bytes * 8) / (20 ms) = 8 Kbps ]

PPS

PPS representa el número de paquetes que necesitan ser transmitidos cada segundo para que

pueda ser enviado un CODEC bit rate. Por ejemplo, para una llamada con G.729 con una carga

útil de voz por paquete de 20 bytes (160 bits), se necesitarían transmitir 50 paquetes cada

segundo. [50 pps = (8 Kbps) / (160 bits per packet)]



4. Asterisk

Asterisk es el Líder mundial en Sistemas y Herramientas de Telefonía del tipo Open Source o de

Código Abierto. Ofreciendo flexibilidad y compitiendo de cara en el mundo de las soluciones

propietarias de comunicaciones. Asterisk permite a los desarrolladores e integradores crear

soluciones avanzadas de comunicación...gratuitamente.

4.1. Comandos de verificación en Linux útiles en Asterisk

Para entrar a la Consola de Asterisk asterisk -r

Para verificar la Carga actual del sistema top

Información del arreglo RAID cat /proc/mdstat

Inspección de los logs tail -n 200 /var/log/asterisk/*.log

Verificar la tabla de enrutamiento netstat -rn o route

Verificar la información del CPU cat /proc/cpuinfo

Verificar la información de la Memoria cat /proc/meminfo

Ejemplo de una prueba de PING ping -i 0.02 -c 500 -s 270 <host>

Información Intensiva del Desempeño del Sistema vmstat 1

Versión actual de Wanpipe wanrouter version

Procesos actuales del sistema ps aux

Información actual de Red ifconfig -a

Diagnóstico de Duplexing (Estado Half o Full Duplex) mii-tool

Verificar Espacio en Disco df -h

Verificar el Hardware Instalado lspci

Comandos en Linux



4.2. Principales Comandos en Asterisk

restart gracefully Restart Asterisk gracefully, i .e. stop receiving new calls and restart at empty call volumen

restart now Restart Asterisk immediately

restart when convenient Restart Asterisk at empty call volume

Starting Asterisk /etc/init.d/asterisk start

Stopping Asterisk /etc/init.d/asterisk stop

Reload Reload configuration

stop gracefully Gracefully shut down Asterisk, i .e. stop receiving new calls and shut down at empty call volumen

stop now Shut down Asterisk immediately

stop when convenient Shut down Asterisk at empty call volume

Asterisk cli dialplan reload Reload extensions and only extensions (formerly extensions reload)

Unload Unload a dynamic module by name

show modules List modules and info about them

show uptime Show uptime information

show versión Display Asterisk version info

show agi Show AGI commands or specific help

dump agihtml Dumps a l ist of agi command in html format

database del Removes database key/value

database deltree Removes database keytree/values

database get Gets database value

database put Adds/updates database value

database show Shows database contents

database showkey

Shows database contents: An alternative to showing keys by family with database show, this

command shows all the families with a particular key

Comandos de Administracion del Servidor

Comandos AGI

Comandos para el Manejo de la Base de Datos

pri debug span Enables PRI debugging on a span

pri intense debug span Enables REALLY INTENSE PRI debugging

pri no debug span Disables PRI debugging on a span

pri set debug fi le Sends PRI debug output to the specified fi le

pri show debug Displays current PRI debug settings

pri show span Displays PRI Information

pri unset debug fi le Ends PRI debug output to fi le

mgcp audit endpoint Audit specified MGCP endpoint

mgcp debug Enable MGCP debugging

mgcp no debug Disable MGCP debugging

mgcp show endpoints Show defined MGCP endpoints

skinny debug Enable Skinny debugging

skinny no debug Disable Skinny debugging

skinny show lines Show defined Skinny lines per device

Comandos para los Canales Skinny

Comandos para el Canal MGCP

Comandos PRI - Los siguientes comandos estan disponibles solo si el canal fue hecho con soporte para libpri



iax2 debug Enable IAX debugging

iax2 no debug Disable IAX debugging

iax2 set jitter Sets IAX jitter buffer

iax2 show cache Display IAX cached dialplan

iax2 show channels Show active IAX channels

iax2 show netstats Show network and jitter buffer statistics for active IAX calls

iax2 show peers Show defined IAX peers

iax2 show registry Show IAX registration status

iax2 show stats Display IAX statistics

iax2 show users Show defined IAX users

iax2 trunk debug Request IAX trunk debug

show keys Displays RSA key information

sip debug Enable SIP debugging

sip no debug Disable SIP debugging

sip reload Reload sip.conf (added after 0.7.1 on 2004-01-23)

sip show channels Show active SIP channels

sip show cannel Show detailed SIP channel info

sip show inuse List all inuse/limit

sip show peers Show defined SIP peers (clients that register to your Asterisk server), see details here

sip show registry Show SIP registration status (when Asterisk registers as a client to a SIP Proxy)

sip show subscriptions Lists all sip presence (busy lamp indication) subscriptions

sip show users Show defined SIP users

h.323 debug Enable chan_h323 debug

h.323 gk cycle Manually re-register with the Gatekeeper

h.323 hangup Manually try to hang up a call

h.323 no debug Disable chan_h323 debug

h.323 no trace Disable H.323 Stack Tracing

h.323 show codecs Show enabled codecs

h.323 show tokens Manually try to hang up a call

h.323 trace Enable H.323 Stack Tracing

zap destroy cannel Destroy a channel

zap show channels Show active zapata channels

zap show cannel Show information on a channel

zap show status

Lists all the Zaptel spans. A span will appear here whether or not its channels are configured with

chan_zap.

zap show cadences Show the configured ring cadences (available e.g with Zap/1r2).

Comandos para los Canales ZAP

Comandos para los Canales IAX

Comandos para los Canales SIP

Comandos para los Canales H.323



4.3. Archivos de Configuración y Logs en Asterisk

Archivos de Configuración de Asterisk /etc/asterisk/*.conf

Archivo de Configuración para SIP /etc/asterisk/sip.conf

Archivo de Configuración para el Buzón de Voz /etc/asterisk/voicemail.conf

Archivo de Configuración para IAX /etc/asterisk/iax.conf

Archivo de Configuración del log de Asterisk /etc/asterisk/logger.conf

Archivo de Configuración del Dial Plan en Asterisk /etc/asterisk/extensions.conf

Archivo de Configuración del Dial Plan en trixbox /etc/asterisk/extensions_additional.conf

Archivos de Configuración de Wanpipe /etc/wanpipe/*

Archivos de Configuración de Zaptel /etc/asterisk/zaptel.conf

Archivos de Configuración de Zapata /etc/asterisk/zapata.conf

Archivos de los Logs de las Colas /etc/asterisk/queue*.log

Archivo del CDR (Call Detail Record) /var/log/asterisk/cdr*

Archivos Logs de Asterisk /var/log/asterisk/

Mensajes de Voz /var/spool/asterisk/voicemail/default

Música en Hold /var/lib/asterisk/mohmp3

Voces /var/lib/asterisk/sounds

Firmware de Teléfonos /tftpboot/

Archivos Logs del Sistema /var/log/messages

Archivos de Configuración y Logs en Asterisk



5. Instalando Asterisk

Refiérase a: http://www.voip-info.org/wiki/view/Asterisk+Step-by-step+Installation

http://www.voip-info.org/wiki/view/Asterisk+Step-by-step+Installation



6. Recursos para Ventas

6.1. Lista de Verificación Preventa

Crear un estándar para la Lista de Verificación de las necesidades del cliente es una buena

práctica. Esto refleja una alta aceptación por parte del cliente en cuanto a la adquisición del

nuevo Sistema Telefónico. Esto sin mencionar que nos ayuda a tener un control comparativo de

las diferentes necesidades con las que nos topamos en el mercado.

Debemos encontrar las necesidades adecuadas del cliente. Cada necesidad es una oportunidad

para generar una ganancia extra a la hora de ofertar el paquete de la solución.

Un ejemplo de una Lista de Verificación sencillo sería:

¿Qué sabe el cliente de VoIP?

¿Qué clase de negocio tiene el cliente?

¿Qué actividades hacen los empleados en el teléfono?

¿Por que el cliente está interesado en adquirir un nuevo Sistema Telefónico?

¿Qué características está buscando el cliente?

¿Están cambiando de proveedor? El cambio de proveedor o de servicio podría considerarse una

propuesta de ahorro considerable para el cliente.

¿El Cliente tiene empleados que se verían beneficiados del uso del Sistema Telefónico

remotamente (Telecommuter)?

¿Cómo funciona la actual Contestadora Automática?

¿Tienen programado cambios en la contestadora automática para los días feriados?

¿Cuál es el destino que llama con más frecuencia? Si son llamadas internacionales, muéstrele

las alternativas que tiene con troncos SIP o IAX.

¿Tiene algún departamento que le interese manejar con Colas de Llamadas? Por ejemplo en ocasiones hay empresas que tienen su propia división de Servicio al Cliente y es importante que ninguna llamada se pierda.

¿Cuántas extensiones necesita?

¿Está pensando hacer algún tipo de integración con otra Central?

¿Cuál es la fecha estimada para el proyecto?

¿Cómo está constituida su plataforma de Datos? Marca de Switches y tiempo de respuesta de una terminal a otra



6.2. Valor agregado

Siempre que vayamos a realizar una instalación de Asterisk, podemos incluir en nuestra

propuesta los siguientes puntos:

Análisis de la Red del cliente.

Auditoria al proveedor de servicio y los costos de los servicios que este ofrece al cliente.

Entrenamientos de administración de la plataforma y a usuarios finales.

Opciones de soporte de la nueva adquisición.

Opciones de seguimiento post instalación.

6.3. Recursos para elaborar el presupuesto de un proyecto

http://office.microsoft.com/en-us/templates/default.aspx

http://www.insight.com

http://www.voipsupply.com

http://www.voiplink.com/

6.4. Cómo calcular el Costo Total de Propiedad

El Costo Total de Propiedad de cualquier Plataforma es difícil de determinar, pero podemos

puntualizar los factores que entendemos imprescindibles para la adquisición de un sistema

basado en Asterisk siguiendo los lineamientos más importantes.

Asterisk es distribuido gratuitamente, un software de fuente abierta. El único costo envuelto en

la implementación de Asterisk es hardware. ¿O quizás no? Vamos a ver.

Como se ha discutido anteriormente, Asterisk es bastante flexible. Determinar el cómo usar

esta flexibilidad a nuestro favor nos podría ahorrar mucho tiempo y dinero.

Sepamos por ejemplo que en una implementación de Asterisk se incurren en gastos como la

compra de Headsets compatibles, los cuales no son gratuitos; si decidimos usar el CODEC

G.729, el cual comprime el tráfico de VoIP hasta 8 veces menos sin degradar la calidad de la

voz, entonces tendremos que pagar por la licencia para el uso del mismo; los aparatos

telefónicos, las tarjetas de telefonía, etc.

Con los sistemas telefónicos comerciales, los costos de implementación son considerablemente

más altos que los costos en los que incurrimos en una implementación de Asterisk. Sin

embargo, debido a su flexibilidad y uso múltiple, los costos de las soluciones basadas en

Asterisk pueden variar sustancialmente.

http://office.microsoft.com/en-us/templates/default.aspx

http://www.insight.com/

http://www.voipsupply.com/

http://www.voiplink.com/



Debido a que la Plataforma telefónica es un punto esencialmente crítico para las empresas, al

Costo Total de Propiedad debemos necesariamente sumarle los costos de la disponibilidad del

servicio. Para esto es probable que se deba contratar un soporte especializado, regularmente

con disponibilidad 24/7 o tal vez contar con un personal interno capacitado.

EL CTP solo tiene utilidad a la hora de comparar Asterisk con otras soluciones telefónicas. Los

siguientes elementos deben ser incluidos a la hora de comparar el CTP de múltiples sistemas

telefónicos:

Costo de Adquisición: Este es el costo de comprar la PBX. En el caso de Asterisk, es solo el costo

del Hardware; otros sistemas incluyen el elemento del licenciamiento.

Costo de Instalación: Este es el costo de configurar y desplegar la PBX. Algunas compañías

eligen hacer el despliegue in-house; aun bajo esas circunstancias existe un costo y para usar

una comparación equitativa, este punto debería ser incluido.

Costo de Licenciamiento (una solo vez): Este es el costo de cualquier cargo por licenciamiento

que ocurra una vez. Algunas PBXs requerirán una licencia para realizar la administración,

mantenimiento, conectarse a una línea PRI, etc. En Asterisk se debe incluir el licenciamiento

para G.729 si es necesario.

Costo de Soporte: Este es el costo estimado por el soporte brindado “on site” o remotamente.

Regularmente es contratado anualmente.

Costos Anuales de Licenciamiento: Algunos sistemas telefónicos tienen un costo anual de

licenciamiento para el uso de ciertas funcionalidades; por ejemplo el uso de algunos aparatos

telefónicos puede requerir una licencia anual para que estos puedan funcionar con la PBX

(ladrones).

6.5. Retorno de la Inversión (ROI)

Toda empresa quiere saber cómo va a recuperar su dinero a la hora de invertir una alta suma

en una solución de telefonía. La adquisición de la PBX es solo una pieza en el rompecabezas del

Retorno de la Inversión (ROI).

Por mencionar un ejemplo, el sistema telefónico de la empresa X tiene un Contestador

Automático (AA), pero este tiene el “mal hábito” de que cuando un cliente llama y marca el

cero para pedir la Operadora, el sistema cuelga la llamada si el cliente no presiona otra tecla en

los próximos 5 segundos.



¿Cuál es el beneficio a razón de un Retorno de la Inversión en este escenario? Un cliente

enojado puede generar pérdidas a la hora de decidirse por los servicios ofrecidos por la

empresa X. Esto hace el costo de Asterisk fácil de justificar.

El Retorno de la Inversión es básicamente el Costo Total de Propiedad sustraído de la

cuantificación del beneficio (en dinero) para el negocio. Sabiendo esto, si calculamos que un

nuevo Sistema Telefónico nos ahorrará US$8,000.00 y el costo es de unos US$7,000.00,

entonces el Retorno de la Inversión es de unos US$1,000.00.

Otra forma de calcularlo es determinando el tiempo en que se recuperaría la inversión realizada

en el nuevo sistema telefónico.

Suponiendo que debido a la instalación del nuevo sistema telefónico tiene la capacidad de

enlazar con un proveedor SIP o IAX que disponga de tarifas fijas en cuanto a llamadas

internacionales, y esto genera un ahorro para la empresa de US$500.00 mensuales, entonces el

sistema telefónico se pagaría en 16 meses. Luego de ahí lo demás es ganancia neta para la

empresa por privarse del gasto extra.

A la hora de proponer el reemplazo o nueva instalación de un sistema telefónico es

recomendable tener todos los números sobre la mesa.

6.6. Diseño, implementación, puesta en marcha y mantenimiento de Asterisk

6.6.1. Métodos de Conexión

Conexión al PSTN (Interfaces Análogas y Digitales)

Para empezar a hablar de las interfaces usadas en Asterisk debemos establecer dos conceptos

importantes:

FXS (Foreing Exchange Station)

Las interfaces FXS generan el tono de marcado, e inician y envían el voltaje de timbrado a las

interfaces FXO.

FXO (Foreing Exchange Office)

Es la manera de designar el punto final de conexión de la llamada. El FXO es el elemento que recibe la

llamada (un teléfono o una Central Telefónica conectada a la PSTN). La interface FXO no genera tono,

solo los acepta.



Figura: Distribución interfaces FXS y FXO

6.6.2. Conceptos básicos de T1

T1, es el mecanismo físico de envío para la señalización DS1.

DS1 (Digital Signal 1), es el protocolo de transmisión usado sobre una línea física T1. Un DS1 es

constituido por 24 canales de 64Kbps, conocidos también como bahías de tiempo (timeslots) o

DS0s. La T1 fue creada por los Laboratorios Bell alrededor de los años 1950.

La información contenida en un DS1 es enviada en tramas a una tasa de 8,000 tramas por

segundo, donde cada trama tiene 193 bits de ancho.

Explicado:

8 bits por canal x 24 canales por trama + 1 bit de entramado = 193 bits

193 bits por trama x 8,000 tramas por segundo = 1544000 bits por segundo

1544000 bits por segundo = 1.544 Mbps

Debido a la reserva de 8Kbps para el “overhead” (1 bit por trama x 8,000 tramas por segundo),

la tasa máxima de transmisión es de 1.536, haciendo así posible la transmisión de 64Kbps por

espacio de tiempo (timeslot).

Codificación (CODING), determina de qué forma los bits son colocados en el cable. En una T1

los unos (1) son enviados por la aplicación de voltaje, mientras que los ceros (0) son

identificados por la falta del mismo.

AMI (Alternate Mark Inversion)

Es una técnica de codificación de línea para T1, el cual usa pulsos bipolares para representar

lógicamente los valores de unos (1). Es por lo tanto un sistema de tres niveles. El valor lógico

para cero (0) es representado por la ausencia de símbolo, y la representación lógica de los unos



(1) para valores positivos o negativos o “marcas” por pulsos dados por la alternación de la

polaridad.

B8ZS (Binary 8 Zero Substitution)

Reemplaza cada grupo de 8 consecutivos con el patrón especial "000VB0VB" 00011011. Esto

mitiga la desventaja que presenta AMI en transmisiones consecutivas de ceros.

Entramado (FRAMING), en términos general un entramado es una división de datos para su

transmisión en grupos de bits a los que se les añade una cabecera y un código de verificación

para formar una trama.

D4 (SF – Super Frame),

Para determinar el lugar de cada canal en la corriente de datos recibida, cada grupo de 24

canales es alineado en una trama. La trama es de 192 bits de largo (8x24), y es finalizada con un

bit de 193, conocido como bit de entramado, el cual es usado para encontrar el final de la

trama.

Para la ubicación del bit de entramado por parte del equipo receptor, se envía un patrón en

este bit. El equipo busca por el bit que tenga el patrón correcto, y alineará su entramado

basado en ese bit. El patrón enviado es de 12 bits de largo, así que cada grupo de 12 tramas es

llamado una SUPER TRAMA (SF). El modelo usado en el bit de entramado es 1000 1101 1100.

Fue reemplazado en los 80 por el Extended Super Frame (ESF).

Extended Super Frame (ESF), Esta técnica de entramado es llamada en ocasiones como D5. ESF

es preferido frente a SF, debido a que incluye un chequeo de redundancia cíclica e incluye

ancho de banda para un canal de enlace de datos; el cual pasa datos entre los equipos de la

portadora.

Una Súper trama de ESF es de 24 tramas de largo,

8 bits por trama

Las tramas 4, 8, 12, 16, 20, 24 son usadas para alineación.

Las tramas 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23 son usadas para enlace de datos.

Las tramas 2, 4, 6, 10, 14, 18, 22 pasan la información del Chequeo de Redundancia Cíclica

(CRC).

Es importante saber que no puedes usar AMI con ESF debido a que ambos intentan hacer las

veces de temporizador. Deberías tener un reloj maestro (master clock).



Configuraciones de interfaces en zapata.conf

Empiece abriendo el archivo zaptel.conf desde la línea de comandos en el directorio

/etc/asterisk.

Configurando la guía SPAN:

Para cada T1 utilizada se necesitara definir un SPAN. La guía SPAN incluye la definición del

Número de SPAN, Temporizador, construcción en línea (line built out), Entramado y

Codificación.

Nomenclatura:

SPAN => NUMBER, TIMING, LINE BUILT OUT, FRAMING, CODING

Número (NUMBER):

Es el puerto donde el SPAN está conectado. Siendo así el puerto 1 e más alejado de la bahía PCI.

Los números de puerto están anotados en el soporte del puerto PCI.

Temporización (TIMING):

Determina si la tarjeta provee el temporizador (0), si lo recibirá de la portadora (1), si funciona

como respaldo de temporizador (2), si da respaldo al temporizador de la portadora (3), y así

sucesivamente. Solo un SPAN puede ser definido con las especificaciones de temporización y el

resto de las tarjetas SPAN lo heredan de este.

Line built out:

Para la mayoría de las configuraciones el valor de este parámetro es 0.

Entramado (FRAMING):

Las T1 utilizan un conjunto de entramados para D4 (SF) o ESF. E1 utiliza CAS o CCS.

Codificación (CODING):

Para las T1 la codificación puede ser AMI o B8ZS. Para E1 puede ser AMI o HDB3.

Ejemplo típico en USA:

span => 1,1,0,esf,b8zs

Ejemplo típico en Europa:

span=>1,1,0,ccs,hdb3



Más ejemplos específicos (Digium):

Línea E&M

En la configuración de una línea E&M, el archivo de configuración zaptel.conf se ha configurado

para que la tarjeta tome la temporización del proveedor. En este caso se usaría E&M Wink a la

vez que el archivo de configuración de zapata.conf reflejará dicha configuración. Por otro lado

es bueno señalar que Feat_D es un tipo de E&M Wink que acepta DID, pero existen varias

opciones de configuración para E&M: E&M_W, E&M_Feat_B, etc.

/etc/zaptel.conf:

span=1,1,o,esf,b8zs

e&m=1-24

/etc/asterisk/zapata.conf:

group=1

context=incoming

signalling=feat_d

channel=1-24

PRI

Si configuramos la tarjeta para que reciba la temporización en zaptel.conf, se adquieren 23

canales b y canales de voz. El canal 24 lo usamos para manejar el transporte de datos. Para

Asterisk definimos PRI_CPE especificando el lado del cliente. Definimos el tipo de conmutación

al que nos estamos conectando como national. Hay varias opciones para los tipos de

conmutación, incluyendo 5ESS, 4ESS y NI1. Así tendríamos 23 canales de voz para Asterisk.

PRI T1

/etc/zaptel.conf

span=1,1,0,esf,b8zs

bchan=1-23

dchan=24

/etc/asterisk/zapata.conf

group=1

signalling=pri_cpe

switchtype=national

context=incoming

channel=1-23



PRI E1

/etc/zaptel.conf

span=1,1,0,ccs,hdb

bchan=1-15,17-31

dchan=16

/etc/asterisk/zapata.conf

group=1

signalling=pri_cpe

switchtype=euroisdn

context=incoming

channel=1-15,17-31

Luego de configurar las interfaces procedemos a cargar el controlador para la interfaz en

particular (Digium) con el comando modprobe:

TE110P => wcte11xp

TE205P/TE207P/TE210P/TE212P => wct2xxp

TE405P/TE407P/TE410P/TE412P => wct4xxp

TDM400P => wctdm

TDM2400P => wctdm24xxp

Existen varios tipos de tarjetas de telefonía en el mercado. Entre las más usadas se encuentran

las distribuidas por Digium (www.digium.com). Las tarjetas de Digium cuentan con una gran

variedad acorde con nuestra necesidad y capacidad de hardware.

Para este tipo de tarjetas las configuraciones anteriormente mencionadas son funcionales, pero

luego de que trixbox anunciara un acuerdo con los fabricantes de tarjetas de telefonía

Sangoma, esta empresa incluyó estas tarjetas como únicas 100% compatibles en sus soluciones

de VoIP. Siendo las únicas mencionadas en su lista de hardware compatible.

Aunque la realidad no es esta. Las tarjetas Digium son bastantes compatibles con las soluciones

de trixbox, y esta solo ha sido una decisión de mercado.

Para la configuración de las tarjetas Sangoma podemos seguir los siguientes pasos en nuestra

caja trixbox:

El primer paso a seguir es descargar los controladores Wanpipe para estas tarjetas. V

http://www.digium.com/



Verificamos el tipo de Kernel que tenemos en nuestro Linux (SMP o No SMP).

Desde la línea de comandos escribimos:

#>uname –a

Ejemplo de resultado: Linux asterisk1.local 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 19:52:49 CDT

2006 i686 i686 i386 GNU/Linux.

Verifique también la versión de los módulos RPM de Zaptel instalados:

#> rpm -qa | grep zaptel

Ejemplo de resultado: zaptel-modules-1.4.10.1-2.2.6.18_53.1.4.el5

Descargue los controladores basado en los resultados anteriores, usando la tabla que sigue a

continuación, de acuerdo con la versión de trixbox:

6.6.3. Equipos Terminales

Aparatos telefónicos y Softphones

A la hora de elaborar una solución de Telefonía IP se deben tomar en consideración los

terminales. Existen características importantes que siempre nos ayudaran en la elección. Entre

estas se pueden citar:

Cantidad de puertos para interconexión, hay modelos que brindan la capacidad de hacer

troncales con otra terminal (PC).

Trixbox CE Zaptel- Headers

Wanpipe

Version

(Change Log) Wanpipe Utilities RPM

Wanpipe Modules

RPM (non-SMP)

Wanpipe Modules

RPM(SMP)

2.6.1.13 1.4.11-1 3.2.7.1 wanpipe-util.rpm

2.6.1 1.4.10.1-2 3.2.6 wanpipe-util-rpm

2.6.1.9/10 1.4.11-1 3.2.6 wanpipe-util-rpm

2.6.0.7 1.4.9.2-8 3.2.5 wanpipe-util-rpm

2.2.12 1.2.22 3.2.3 wanpipe-util-rpm wanpipe-mod-rpm wanpipe-mod-smp-rpm

wanpipe-module-rpm

wanpipe-module-rpm

wanpipe-module-rpm

wanpipe-module-rpm



PoE, hay equipos que nativamente soportan la capacidad de recibir energía a través de la

conexión Ethernet. Esta característica va muy ligada al tipo de plataforma de datos de la que

disponemos (Switches).

Cantidad de líneas, en el primer levantamiento se debe considerar la necesidad de cada

usuario para conocer si los mismos presentan la necesidad de usar más de una línea en sus

terminales IP.

Consola de Recepción, este tipo de aparatos tienen más capacidad de líneas con el objetivo de

manejar el alto volumen de llamadas entrantes a la recepción de la empresa. Existen algunos

modelos de aparatos IP que disponen de módulos adicionales para este tipo de necesidad.

Protocolo que soporta, debemos ser muy cuidadosos, ya que debido a que VoIP se ha

proliferado tanto existen muchos aparatos que soportan diferentes tipos de protocolos como

SIP, IAX, Cisco Skinny Client Control Protocol (Skinny), etc.

Luego del auge de VoIP existe una gama de aparatos telefónicos y Softphones que soportan

esta tecnología.

Queremos citar los más comunes según el protocolo SIP:



Softphones SIP más comunes

Phoner:

http://www.phoner.de/index_en.htm

XLite from Counterpath:

http://www.counterpath.net/x-lite.html

ZoIPer:

http://www.zoiper.com/

ExpressTalk:

http://www.nch.com.au/talk/

Damaka:

http://www.damaka.com/

FlashPhone:

http://www.flashphone.ru/en/main

FaramPhone:

http://www.faramtech.com/

http://www.phoner.de/index_en.htm

http://www.counterpath.net/x-lite.html

http://www.zoiper.com/

http://www.nch.com.au/talk/

http://www.damaka.com/

http://www.flashphone.ru/en/main

http://www.faramtech.com/



Teléfonos SIP más comunes

Snom

http://www.snom.com/

Grandstream

http://www.grandstream.com/

Polycom

http://www.polycom.com/voip/

Cisco

http://www.cisco.com/en/US/products/hw/phones/ps379/

Linksys

http://www.cisco.com/en/US/products/ps10033/index.html

Aastra

http://www.aastra.com/



6.6.4. Equipos de comunicación

Adaptadores de Terminal (ATA), son dispositivos que permiten la interacción de los sistemas IP

con los teléfonos o equipos análogos convencionales.

Se pueden usar como alternativa para el ahorro en las implementaciones de VoIP, sugiriendo

que el cliente conserve sus actuales aparatos telefónicos. Esto presenta la desventaja de que no

se aprovechan todas las funcionalidades de VoIP, debido a las limitaciones de los terminales.

Figura: Linksys SPA2100

VoIP Gateways, son dispositivos que integran las nuevas Centrales IP con Centrales digitales

convencionales o con otras Centrales IP de diferentes fabricantes. Funcionando como equipo

intermedio, maneja la integración siguiendo la confección de un plan de marcado entre ambas

centrales.

Figura: Quintum VoIP Gateway

Integración con otra PBX

Debido al costo de implementación de las soluciones de Telefonía, existe la opción de crear

híbridos entre Centrales para abaratar los gastos en aparatos telefónicos.

La idea es que la empresa vaya creciendo IP, según va descartando paulatinamente su vieja

plataforma.

Para este tipo de integraciones existen varias alternativas, pero entre las más comunes se citan

dos:



Interconectar ambas Centrales mediante un módulo T1, agrupando cada interconexión

mediante un digito (s). Así a la hora que un usuario decide marcar una extensión de una Central

a otra tomaría un canal del tronco marcando el dígito preestablecido.

Interconectar ambas centrales utilizando un VoIP Gateway como el que ofrece Quintum, este

dispositivo hace la traducción necesaria para que ambas Centrales se comuniquen sin

inconvenientes. Al igual que la solución anterior, se trata de agrupar cada extremo de cada

Central en dígitos.

6.6.5. Especificaciones del Servidor:

Tipo de Procesador RAM # De Llamadas # De Llamadas ACD

Celeron 256MB 5 2

Celeron 512MB 8 3

Pentium 4 512MB 15 6

Pentium 4 1GB 23 9

Core2Duo 1GB 35 14

Core2Duo 2GB 46 18

Dual Core Xeon 1GB 45 25

Dual Core Xeon 2GB 60 33

Quad Core Xeon 1GB 68 37



Quad Core Xeon 6GB 100+ 70+

Especificaciones Recomendadas para el Servidor



Figura: Diagrama de la composición del “trixbox Appliance”:

6.7. Calidad en el uso de los recursos de voz en la empresa

Día a día las empresas tienen el compromiso de mantener los gastos por debajo de la ganancia

resultante. No es un secreto que los servicios de comunicaciones encarecen bastante la

realización de cualquier producto o servicio.

Debido a esto las empresas se ven obligadas a mantener controles. Como por ejemplo en el uso

de los servicios de telefonía. Para cubrir esta necesidad las empresas recurren a herramientas

como:

Una adecuada confección del Dial Plan o Plan de Marcado. Con esto si la empresa posee

servicios de tarifa fija para llamadas internacionales, por ejemplo, el Plan de Marcado puede

decidir por donde la llamada genera un menor gasto para la empresa eligiendo la ruta de ese

proveedor.

El uso de los Reportes Detallados de Llamadas (Call Detail Record). Esta es una herramienta

importante a la hora de controlar los costos por llamadas realizadas. Este tipo de herramientas

es muy popular en el sector Hotelero.

Es bueno mencionar que trixbox cuenta con un CDR muy básico, pero funcional.



7. Trixbox

7.1. ¿Qué es?

trixbox es una solución de IPPBX basada en software diseñada para pequeñas y medianas

empresas esencialmente.

trixbox® Community Edition (CE), es el software de fuente abierta que se ha convertido en

la más popular de las plataformas basadas en Asterisk® en el mundo. trixbox CE combina lo

mejor de las herramientas de telefonía de fuente abierta en un paquete de fácil instalación,

en conjunto con el panel de trixbox que nos brinda una interfaz Web para configurar y

administrar un completo sistema de Telefonía IP.

7.2. trixbox - Arquitecturas de Red Nuestro sistema trixbox puede ser configurado de diversas maneras dependiendo de la necesidad del

cliente. La Arquitectura puede ir desde la configuración para una Oficina Simple hasta la complejidad de

interconectar diversas oficinas con diferentes proveedores y / o con proveedores no convencionales de

Voz sobre IP.

7.2.1. Arquitectura de una sola oficina

Este tipo de Arquitectura está orientada regularmente a Oficinas Pequeñas (SOHO). Estas

empresas cuentan con no más de 10 empleados en su nómina.

Diagrama de ejemplo:



7.2.2. Arquitectura de una empresa con usuarios remotos

Este tipo de Arquitectura está orientada regularmente a Oficinas Pequeñas (SOHO). Estas

empresas cuentan con no más de 10 empleados en su nómina, pero a diferencia de la

Arquitectura anterior, este tipo tiene la facilidad de brindar los servicios telefónicos a usuarios

no presentes en la Oficina Principal. Es muy común ver esta configuración en empresas

dedicadas a ventas o los llamados “telecommuters”.


7.2.3. Arquitectura de una empresa con sucursales y un solo proveedor

Este tipo es ideal para empresas con empleados en más de una localidad. Los servidores trixbox

son enlazados usando el protocolo IAX a través de Internet u otro medio de conexión. Todos los

teléfonos en todas las sucursales son extensiones del mismo sistema, y se realizan llamadas a

través del proveedor de donde está conectada la Oficina Principal.




Pros:

Ahorro de costos debido a que se usa el mismo proveedor para cada localidad.

Todas las llamadas se originan con el mismo Identificador de Llamadas (Caller ID).

Contras:

Un solo punto de fallo, esto la hace susceptible a interrupciones en las sucursales si falla el

enlace entre ambas localidades.

7.2.4. Arquitectura de una empresa con sucursales y varios proveedores








Pros:

Todas las extensiones se aprecian como parte de cada Sistema en particular.

Tolerante a Fallos, si el enlace entre ambas localidades se cae solo dejaría de funcionar la

comunicación de extensión a extensión, pero la comunicación con el exterior no sufriría

inconvenientes.

Contras:

Se incrementan los costos debido a la instalación de una Central IP por localidad

Se incrementan los costos debido al uso de múltiples proveedores.



7.2.5. Arquitectura de una empresa con sucursales, varios proveedores y un

proveedor de VoIP.






Conexión

PRI o POTS

Conexión

PRI o POTS

InternetPSTN

Switch

IP Phones

Router

Oficina Remota

trixbox

Servidor VoIP

trixbox

Servidor VoIP enlazado

Oficina Principal

Router

OOffiicciinnaa CCoonn MMúúllttiipplleess SSuuccuurrssaalleess,, MMúúllttiipplleess PPrroovveeeeddoorreess yy VVooIIPP

ITPITPITPITP

Proveedor de

troncos SIP o IAX

Pros:

Todas las extensiones se aprecian como parte de cada Sistema en particular.

Tolerante a Fallos, si el enlace entre ambas localidades se cae solo dejaría de funcionar

la comunicación de extensión a extensión, pero la comunicación con el exterior no

sufriría inconvenientes.



Proveedor SIP o IAX, usualmente se uso como respaldo a la conexión a la PSTN o como

alternativa para reducción de costos en llamadas de larga distancia

Contras:

Se incrementan los costos debido a la instalación de una Central IP por localidad

Se incrementan los costos debido al uso de múltiples proveedores.

7.3. Diferencias entre Asterisk y trixbox

Una forma simple de establecer una diferencia entre trixbox y Asterisk es conocer que Asterisk

es solo uno de los componentes de trixbox. Mientras Asterisk es el software para la PBX, trixbox

es un paquete autoinstalable de aplicaciones como:

CentOS (un Sistema Operativo completo)

Asterisk PBX

FreePBX (la interfaz de administración Web),

Festival Speech Engine (para el uso de algunas funcionalidades mediante la conversión de texto

a voz)

SugarCRM (la versión Open Source de este magnífico Administrador de la Relación con el

Cliente,

Cisco XML Services (si usamos teléfonos Cisco esta herramienta nos ayuda con el

aprovisionamiento de estos equipos).

Herramientas de instalación automática (compuesta por scripts, todas las herramientas y

archivos de configuración que hacen posible a trixbox su instalación automática.

Digium Card auto-config, para sistemas telefónicos que usan las tarjetas de telefonía de

Digium, trixbox incluye un script de configuración automática que se encarga de la

configuración inicial de este hardware.

El centro de la fortaleza de trixbox radica en la facilidad para su instalación, sin dejar de

mencionar su interfaz de configuración Web.

Para tener el sistema Asterisk arriba y funcionando necesitamos seleccionar una distribución de

Linux compatible, instalar la distribución, configurarla con las medidas de seguridad, y luego

instalar Asterisk y configurarlo. Con trixbox tenemos una sola rutina de instalación, la cual no

solo nos brinda un Sistema Operativo completamente funcional con Asterisk instalado, sino que

también nos preinstala todos los demás componentes por nosotros, al “mínimo esfuerzo”.



7.4. Limitaciones y ventajas en el uso de trixbox como solución de telefonía

La realidad es que se puede hacer casi todo con una instalación de trixbox en comparación con

una de Asterisk. La limitación principal de trixbox, si se le pudiera llamar así, es que FreePBX

requiere una distribución específica de los Archivos de configuración, cualquier cambio hecho a

mano puede ser sobrescrito o puede romper con la estructura del sistema, dañando la interfaz

Web.

Otra “limitación” podría ser, a la hora de la administración, que teniendo múltiples sistemas de

trixbox tendríamos que autenticarnos en diferentes interfaces. Esto es fácilmente manejable

teniendo nuestra plataforma bien documentada.

Ventajas

Con trixbox contamos con un número de aplicaciones personalizadas y creadas específicamente

para trixbox. Estas aplicaciones nos muestran lo poderoso y flexible que trixbox puede ser.

Mucho de este código ha sido creado por el Grupo de Usuarios Avanzados de trixbox, y ha sido

donado a la comunidad para su uso.

La ventaja que consideramos mayor de trixbox, frente a otras distribuciones de Asterisk, es su

fácil administración y configuración a través de su interfaz Web, que ha sido mejorada con el

paso del tiempo por los efectivos de la comunidad.

7.5. Soluciones de Asterisk existentes en el mercado

A continuación una selección de entre las cientos de soluciones de telefonía IP basadas en Asterisk

existentes en el mercado:

Asterisk Open Source PBX

http://www.asterisk.org/

Asterisk Business Edition

http://www.digium.com/en/products/software/abe.php

AastraLink Pro160

http://www.aastra.com/cps/rde/xchg/SID-3D8CCB6A-

0024CB56/04/hs.xsl/27537.htm


http://www.digium.com/en/products/software/abe.php

http://www.aastra.com/cps/rde/xchg/SID-3D8CCB6A-0024CB56/04/hs.xsl/27537.htm



AsteriskNow

http://www.asterisknow.org/

FreePBX

http/www.freepbx.org/

FreeSwitch

http://www.freeswitch.org/

PhoneBochs

http://www.rockbochs.com/pb_Models.php

Trixbox Community Edition

http://www.trixbox.org/

Switchvox

http://www.switchvox.com/

QueueMetrics

http://queuemetrics.loway.it/

Xorcom

http://www.xorcom.com/ts-1/features.html

3Com Asterisk Appliance

http://www.3com.com/voip/

http://www.asterisknow.org/

http://www.freeswitch.org/

http://www.rockbochs.com/pb_Models.php


http://www.switchvox.com/

http://queuemetrics.loway.it/

http://www.xorcom.com/ts-1/features.html

http://www.3com.com/voip/



7.6. Instalación y Administración de trixbox CE

7.6.1. Pasos para empezar a trabajar con trixbox

Descargar el archivo .ISO que contiene el sistema completo (SO; FreePBX; Muchas aplicaciones

más) desde: http://www.trixbox.org/downloads.

Grabar este .ISO en un CD con nuestro software deseado

Modificar el gestor de arranque en el BIOS (algunos te permiten hacer la selección sin

necesidad de modificar el BIOS) de nuestro servidor para que la unidad de CD sea detectada

primero.

Antes de avanzar al paso siguiente debes conocer que trixbox elimina toda la información de tu

partición para crear una instalación totalmente fresca.

Una vez cargue el CD verás la información de la versión de trixbox que estas instalado. Una vez

ahí, debes presionar la tecla de Enter.

Se empezará a instalar trixbox

Durante la instalación debes elegir lo que conviene de las siguientes opciones:

Idioma; teclado; zona horaria; y una clave para el usuario root.

Luego podrás acceder a tu nueva instalación a través de la dirección IP asignada, mediante

cualquier navegador Web. Para verificar la dirección IP puedes usar el comando ifconfig desde

la consola de Linux.

7.6.2. Administración desde la consola Web:

Lo primero que haremos luego de instalar nuestro .ISO es crear una extensión nueva desde la

interfaz Web:

http://www.trixbox.org/downloads



Seleccionamos Extensions desde el menú de

configuración en el margen izquierdo.

Seguido de esto seleccionamos Add

Extension, que es la única opción a la

derecha del panel.

Utilizamos el menú desplegable para

seleccionar el tipo de extensión que vamos a

crear y seleccionamos SIP.

Presionamos Sumit para proceder a

configurar la extensión.

Una vez en la ventana de configuración de la

extensión tendremos varias opciones muy

útiles, pero vamos a enfocarnos en las

opciones principales:

User Extension: Es el número de extensión

que asignaremos al usuario

Display Name: Nombre de la persona que

usará la extensión.

Secret: Clave usada para autenticar la

extensión.

Voicemail & Directory

Status: Si queremos habilitar o deshabilitar



la opción del uso de Buzón de Voz.

Voicemail Password: Clave asignada para el Buzón de Voz.

Email Address: Dirección de correo donde se enviaran los archivos de voz grabados en el Buzón

de Voz

Pager Email Address: Dirección que recibirá una breve notificación de que tenemos un mensaje

sin escuchar

VM Options: Aquí definimos si la persona puede o no revisar su Buzón de Voz y también

especificamos la cantidad de mensajes que puede tener dicha persona.

VM Locater: Otra de las funcionalidades del Buzón de Voz que permite realizar funciones una

vez la persona que llama se encuentra en el menú del Buzón de Voz.

Una vez hayamos configurado la extensión procedemos a asignar esta información en nuestro

aparato telefónico o Softphone favorito.

7.7. Confección del plan de marcado y enrutamiento de llamadas

Las extensiones en el Plan de Marcado (Dialplan) pueden ser simples números como "412" o

"0". O pueden ser representaciones alfanuméricas con nombres como "Juan" o "* A93".

Aunque un teléfono típico no puede marcar una extensión llamada "juan" (aunque algunas si

pueden), a menudo la lógica del Plan de Marcado implica saltar de una extensión a otra, y para

estos saltos se pueden definir exenciones de nombres con cualquier nombre que se quiera,

debido a que no se desea que se marque a estas extensiones directamente.

Patrones para las extensiones

Los nombres para las extensiones no están limitados a simples números de extensiones. Una

simple extensión también puede contener patrones de marcado. En el archivo extensions.conf,

una extensión es un patrón si empieza con el símbolo raya abajo (_).

En un patrón de extensiones, los siguientes caracteres tienen un significado especial:

X, Coincide con cualquier digito de 0-9

Z, Coincide con cualquier digito de 1-9

N, Coincide con cualquier digito de 2-9

[1237-9], Coincide con cualquier digito o letra en el paréntesis (en este ejemplo 1, 2, 3, 7, 8, 9)

., Comodín, coincide con uno o más caracteres

!, Comodín, coincide con cero o mas caracteres de inmediato (desde Asterisk 1.2 en adelante)



Considere el siguiente contexto:

[routing]

Extensión Descripción

_61XX Oficina de Dallas

_63XX Oficina de Dallas

_62XX Oficina Huntsville

_7[1-3]XX Oficina de San José

_7[04-9]XX Oficina de Los Ángeles

Este contexto, que se le ha dado el nombre de "routing", envía las llamadas a distintos

servidores de acuerdo a su extensión. Esta empresa ha decidido que todas sus extensiones

telefónicas sean de 4 dígitos. Si un usuario llama a una extensión que comience con 61 o 63,

será enrutado a la oficina de Dallas, 62 se enrutaria a la oficina de Huntsville, todos los dígitos a

partir de 71, 72, o 73 serían enrutados a la oficina en San José, y cualquier dígito a partir de 70,

74, 75, 76, 77, 78 o 79 se enrutaría a la oficina de Los Ángeles.

Troncales

Tronco entre dos Centrales Asterisk con IAX2 (se usa la misma nomenclatura para SIP).

Para el Plan de Marcado entre Centrales hemos usado 5XXX, de esta forma cada servidor

alcanzaría extensiones con el patrón XXX al otro extremo. Esto puede ser modificado según la

necesidad.

Ejemplo:

[Nomenclatura]

Server1: Nombre del Servidor1

Server2: Nombre del Servidor2

Server1IPAddress: Dirección IP del servidor 1

Server2IPAddress: Dirección IP del servidor 2

Server1User: Cuenta de usuario para el Servidor 1

Server2User: Cuenta de usuario para el Servidor 1

Server1Secret: Clave para el Servidor 1

Server2Secret: Clave para el Servidor 2



Configuración del Servidor 1:



Configuración del Servidor 2:



Rutas de Entrada

En el panel de configuración de la izquierda seleccionar Inbound Routes.

Dejar todos los campos en

blanco y seleccionar el

destino que tendrá la

llamada. Regularmente se

recomienda que vaya a un

IVR, para que los que llaman

tengan opción de marcar

según su necesidad.

Rutas de Salida

Route Name: Escribimos el nombre que le daremos a nuestra ruta.

Route Password: Podemos asignar una clave en particular para esta ruta.

PIN Set: Podemos asignar un conjunto de claves configuradas previamente en las opciones de

PIN Set del panel de la izquierda en nuestra interfaz Web.

Dial Patterns: El patrón de marcado que permitirá esta ruta.



Trunk Secuence: La secuencia que se seguirá según la disponibilidad de los troncos que

asignemos.

Sumit Changes: Grabamos los cambios y luego le damos a recuadro que aparece en la parte

superior del panel que dice: Apply Configuration Changes. Luego confirmamos los cambios

seleccionando Continue with reload.

7.8. Conceptos básicos de CRM

Customer Relationship Management, Es un concepto enfocado a administrar las relaciones de

una empresa con todos sus clientes, es decir compartir con efectividad la información entre los

puntos de contacto de las diferentes áreas específicas que interactúan con el cliente como:

ventas, mercadotecnia, atención a clientes, servicios, etc.

Una de las razones por las que Asterisk ha tomado tanto terreno en el campo de las soluciones

de comunicaciones es debido a la sencilla integración con los más reconocidos sistemas de

Administración de las Relaciones con el Cliente (CRM).

Uno de los sistemas CRM más usados en la actualidad es el SugarCRM. Esto se debe a dos

razones principales, a) SugarCRM cuenta con una versión Open Source, o sea que es sostenida

por la comunidad y por ende es gratuita su distribución; b) En las anteriores versiones de

trixbox CE, SugarCRM venía ya pre instalado y solo se debían hacer los ajustes de

personalización de la compañía.



Figura: SugarCRM

7.9. Concepto básico de Comunicación Unificada

Se trata de combinar todas las formas de comunicación empresarial en una solución unificada.

Entre las más reconocidas tenemos:

Comunicaciones Unificadas de Siemens Enterprise Communications

Comunicaciones Unificadas de Alcatel-Lucent

Comunicaciones Unificadas de Avaya

Comunicaciones Unificadas de Cisco

Comunicaciones Unificadas de Microsoft

Comunicaciones Unificadas de Nortel

7.10. Concepto de “Autodialer”

Un autodialer es un dispositivo electrónico o Software de computadora que puede llamar

automáticamente a números de teléfono previamente programados para comunicar entre

cualesquiera dos puntos de la red telefónica.



Una vez que se ha establecido la comunicación (mediante un intercambio telefónico), el

autodialer anunciará mensajes verbales o transmitirá datos digitales, por ejemplo, mensajes de

texto en formato "servicio de mensajes cortos" (SMS) a la parte llamada.

Este tipo de herramienta se ha vuelto muy común en los servicios de Telemercadeo ofrecidos

en los Call Contact Centers.

Se puede notar también su uso en los sistemas de cobro compulsivo de la Banca.

Figura: VICIDIAL, autodialer usado comúnmente con Asterisk

7.11. Concepto de “Hosted PBX”

En este tipo de sistema las compañías telefónicas le brindan la oportunidad al cliente de tener

un sistema telefónico con todas las funcionalidades de una Central, pero en las facilidades del

proveedor.



7.12. Mantenimiento y seguridad en trixbox

Te preguntarás que para qué necesitas asegurar tu sistema telefónico. Si hemos armado

nuestro servidor Linux desde cero, es muy probable que hayamos configurado todos los

componentes con las claves que deseamos al momento de la instalación. Con trixbox, cada

instalación tiene las mismas credenciales y el sistema base de Linux no está asegurado para

evitar las conexiones desde fuera.

No se requiere de mucho esfuerzo realizar un escaneo de la Red y notar un servidor trixbox

inseguro. La mayoría de las instalaciones se hacen detrás de un Firewall, pero de todas formas

esto no significa que no debemos tomar las precauciones básicas de lugar con el servidor.

Recuerda que la mayoría de los ataques a los servicios vienen de lo interno de las empresas

regularmente.

7.12.1. Cambiando las claves que vienen por defecto en trixbox

La credencial principal para acceder a un sistema Linux es la cuenta de root. Si alguien logra

conseguir este nivel de privilegio, pues tendrá acceso total a nuestro sistema. Ya sea

autenticado localmente o por algún cliente de SSH, necesitamos usar el comando passwd para

cambiar la clave a la cuenta de root.

Ejemplo:

[root@asterisk1 ~] # passwd

Changing password for user root.

New UNIX password:

Retype new UNIX password:

passwd: all authentication tokens updated successfully.

Cuentas maint y wwwadmin

En Segundo lugar, necesitamos cambiar las claves para las cuentas de maint y wwwadmin.

Existen scripts en trixbox que nos ayudan a realizar estas tareas. Para cambiar las claves que se

usan para entrar al panel de administración Web de trixbox usaremos los siguientes comandos

desde la consola:

passwd-maint



Veremos lo siguiente:

-------------------------------------------------------------

Set password for AMP web GUI and maint GUI

User: maint

-------------------------------------------------------------

New password:

Re-type new password:

Updating password for user maint

La cuenta de wwwadmin es similar a la cuenta maint excepto por el hecho de que la cuenta maint te

permite acceso total al panel de administración Web mientras que la cuenta wwwadmin no te permitirá

ver la pestaña Config Edit, donde podemos configurar los archivos actuales de configuración.

Podemos cambiar nuestra cuenta wwwadmin de la siguiente forma:

passwd-amp

Veremos lo siguiente:

-------------------------------------------------------------

Set password for AMP web GUI and maint GUI

User: wwwadmin

-------------------------------------------------------------

New password:

Re-type new password:

Updating password for user wwwadmin



Flash Operator Panel

La clave por defecto del Flash Operator Panel es passw0rd (un cero en vez de O). Si queremos

cambiar esta clave, hay dos formas para hacerlo. Primero, ya sea autenticado localmente o por

algún cliente de SSH, siga las siguientes instrucciones:

cd /var/www/html/panel

nano op_server.cfg

Vamos a la línea que dice security code=passw0rd y reemplace el “passw0rd” por la clave de su

preferencia.

security code=laclavequeprefiera

Entonces presionamos Ctrl+X para salir y luego escribimos Y para guardar los cambios en el

editor de texto nano. Finalmente reiniciamos el FOP.

amportal restart

Alternativamente, podemos hacer estos cambios a través de la interfaz Web haciendo click en

la pestaña Config Edit a mano izquierda del menú. Luego hacemos click en el enlace que nos

lleva a la ruta /var/www/html/panel, ubicado en la parte superior de la página. Una vez ahí

editamos el archivo op_server.cfg, que aparece como enlace a la izquierda de la pantalla. Cerca

de la línea 41, cambie la línea security_code con la nueva clave que desea usar. Finalmente,

hacemos click en el botón Update, ubicado en la parte inferior de la pantalla, luego haga click

en el enlace Re-Read Configs en la parte superior de la pantalla.

Figuras: Editando FOP



Cambiando la clave a MySQL

La base de datos de MySQL contiene toda la información que necesitamos para mantener

nuestro sistema operando. Lo más probable es que no queramos a nadie husmeando en esta

información; dicho esto podemos determinar que es necesario cambiar la clave antes de poner

nuestro sistema en producción.

Desde el menú principal de trixbox, hacemos click en el enlace System. Luego, hacemos click en

el enlace phpMyAdmin, una vez allí seleccionamos en el menú desplegable Database la opción

de mysql.

Cuando vemos la lista de las tablas disponibles, hacemos click en la tabla user y luego en

Browse.

Figura: Panel phpMyAdmin

Aquí podemos notar que la tercera entrada, asterisk1.local, por defecto no contiene clave. Si

este campo está en blanco, entonces no tenemos ningún tipo de seguridad en nuestra base de

datos, y esto necesita ser corregido inmediatamente.

Para realizar esta modificación debemos hacer click en el icono del lápiz a la izquierda de

asterisk1.local. Una vez allí necesitamos hacer click en el menú desplegable Function, y en la

fila password seleccionar la función PASSWORD.



Necesitamos introducir una nueva clave, y asegurarnos de que no sea sencilla de adivinar.

Luego hacemos click en el botón de Go para salvar los cambios realizados. Ahora, si vamos a la

pestaña de Browse, podremos notar la versión encriptada de la clave que seleccionamos para

ambas entradas de root en la tabla.

Importante: Esta configuración dañará phpMyAdmin, y para solucionarlo necesitamos editar el

archivo de configuración. Necesitamos, ya sea autenticado localmente o por algún cliente de

SSH, realizar los siguientes cambios:

nano /var/www/html/maint/phpMyAdmin/config.default.php

Una vez ahí, editamos la siguiente línea de código:

$cfg *‘Servers’+ *$i+ *‘password’+ = ‘passw0rd’ ;

Cambiamos la clave por la que creamos recientemente, presionamos Ctrl+x y luego Y para

grabar los cambios. Finalmente, necesitamos reiniciar el servidor y phpMyAdmin funcionará de

nuevo sin inconvenientes.

Conectar en el servidor con una dirección IP pública

Esta demás decir que esta no es una buena práctica, aunque es posible. Si no tenemos buena

experiencia con seguridad en Linux e iptables, entonces esta sería una “Crónica de una muerte

anunciada”.

Esta posibilidad puede ser agotada si disponemos de un Firewall bien configurado; no hay razón

para tener Asterisk implementado fuera de una red segura.

Actualizar el Sistema Operativo y Asterisk

Para seguridad de nuestro sistema, es una buena práctica mantenerlo actualizado, al igual que

las aplicaciones que lo componen.

En trixbox existe un script que fácilmente realiza esta función por ti:

trixbox-update.sh update

También puedes actualizar el Sistema Operativo con el siguiente comando:

yum update

En trixbox también contamos con un administrador de módulos, que te permite actualizar cada

uno de manera individual. Es bueno mencionar que con esta funcionalidad recibes



notificaciones en línea sobre nuevas actualizaciones a tu sistema, y puedes realizar las

actualizaciones de los módulos a la velocidad de unos cuantos clicks.

7.12.2. Copias de Respaldo (Backup)

Todo sistema debe contar con un buen plan de contingencia, aun sea teniendo pantallas de las

configuraciones existentes. Querremos una manera de restaurar nuestras configuraciones a la

hora de que algo salga mal. Afortunadamente en trixbox existe un método no tan difícil de

seguir para realizar copias de respaldo, el único ligero inconveniente es que necesitamos un

método para lidiar con los archivos que este respaldo genera.

En la pestaña Tools, próxima a b en el panel de administración de trixbox, podremos encontrar

un enlace que nos lleva a la herramienta de respaldo de este poderoso sistema. Este enlace se

llama, Backup and Restore.

Usando esta herramienta podemos crear una gran variedad de copias de respaldo

programadas, según nuestros requerimientos.

Sugerimos al menos realizar el respaldo semanal de los archivos de configuración y el buzón de

voz.

Figura: Programación de copia de respaldo



Un método sencillo para manejar nuestro respaldo de manera remota es poniendo los archivos

respaldados en un servidor FTP. Asumiendo que tenemos un servidor FTP listo, veremos cómo

modificar el script que realiza la copia de respaldo para que la información sea transferida a

nuestro servidor FTP.

La copia de respaldo actual es manejada por el script ampbackup.pl que está ubicado en el

directorio /var/lib/asterisk/bin. Para añadir las líneas necesarias para configurar nuestro

respaldo remoto, editamos el script de la siguiente forma:

nano /var/lib/asterisk/bin/ampbackup.pl

Antes de llegar a la última línea del archivo, añadimos el siguiente código:

open(FILE, ">/tmp/ftp2remote") || die "Failed to open ftp2remote\n"

printf FILE "user username password\n";

printf FILE "binary\n";

printf FILE "cd asterisk\n";

printf FILE "lcd /var/lib/asterisk/backups/$Backup_Name/\n";

printf FILE "put $Stamp.tar.gz\n";

printf FILE "lcd /var/www/html/maint/backup/\n";

printf FILE "put asteriskathome_backup.tar.gz\n";

printf FILE "bye\n";

close(FILE);

system ("/usr/kerberos/bin/ftp -u ftpserveraddress< /tmp/ftp2remote > /dev/null2>&1");

#system ("/bin/rm -rf /tmp/ftp2remote > /dev/null 2>&1");

Debemos asegurarnos de cambiar el nombre de usuario y la clave, así como también sustituir la

dirección del servidor por el nuestro antes de grabar los cambios con Ctrl+x y luego Y. Ahora

cada vez que nuestro respaldo programado inicie, pondrá los archivos de respaldo en nuestro

servidor FTP.



7.12.3. Seguridad adicional

A veces somos muy cuidadosos a la hora de asegurar nuestros sistemas y aplicaciones

relacionadas con los servicios del mismo, pero se nos olvida que todas estas aplicaciones corren

a la par con un grupo de servicios independientes al uso principal de nuestro servidor.

Pegando las siguientes líneas de código dentro de la consola de Linux, apagaremos todos

aquellos servicios innecesarios para el funcionamiento de nuestra central, pero que pueden

acarrearnos vulnerabilidad en la estabilidad de nuestro sistema:

chkconfig kudzu off

chkconfig rawdevices off

chkconfig pcmcia off

chkconfig portmap off

chkconfig rpcidmapd off

chkconfig haldaemon off

chkconfig mdmonitor off

chkconfig netfs off

chkconfig isdn off

chkconfig rpcgssd off

chkconfig iptables off

chkconfig irqbalance off

chkconfig vsftpd off

chkconfig auditd off

chkconfig smartd off

chkconfig readahead off

chkconfig microcode_ctl off

chkconfig cpuspeed off

chkconfig messagebus off

chkconfig readahead_early off

chkconfig nfslock off

chkconfig lm_sensors off

chkconfig ircd off

chkconfig autofs off

reboot -> (para aplicar los cambios es necesario reiniciar el servidor)



8. Enlaces de interés

www.asterisk.org

www.trixbox.org

www.voip-info.org

www.voipforo.com

www.asterisktutorials.com

www.asteriskclub.org



http://www.voip-info.org/

http://www.voipforo.com/

http://www.asterisktutorials.com/

http://www.asteriskclub.org/



9. Caso de Estudio: NetTeam S. A.

La Empresa NetTeam S. A. ha decidido migrar toda su plataforma de telefonía a VoIP.

NetTeam S. A. es una empresa líder en servicios tecnológicos y de Telemercadeo en

diferentes partes del mundo.

Actualmente la empresa cuenta con sucursales en:

Santo Domingo

Estados Unidos

México

Puerto Rico

El número de usuarios de teléfonos en las diferentes oficinas es de:

Santo Domingo = 150

Estados Unidos = 35

México = 100

Puerto Rico = 70

Actualmente esta compañía cuenta con Centrales Digitales Nortel, sin ningún tipo de

enlace entre ellas.

La compañía ha decidido el cambio a VoIP, porque ha investigado sobre la facilidad de

interconexión que pueden tener entre todas las sucursales, considerando ellos que esto

representaría un ahorro en el uso de las comunicaciones internas.

NetTeam S. A. cuenta con un enlace Frame Relay entre todas sus sucursales.



10. Laboratorios Día 1

Estructura de Archivos Linux

Instalar trixbox

Crear extensiones con Buzón de Voz y Follow Me.

Creación Proyecto/Propuesta VoIP basado en Asterisk (1ra. Parte)

Día 2

Crear un IVR “amigable”.

Cómo Grabar la Voz para el IVR y los submenús.

Crear ruta de entrada al IVR

Crear Ruta de Salida entre Centrales y a la PSTN

Crear Tronco entre dos Centrales Asterisk

Creación Proyecto/Propuesta VoIP basado en Asterisk (2da. Parte)

Día 3

Crear un Salón de Conferencia Virtual.

Crear un DISA (Direct Inward Service Access).

Crear un Grupo de Marcado (Ring Group).

Crear una Cola de Llamadas (Call Queues).

Cambiar el idioma por defecto de Asterisk al español.

Creación Proyecto/Propuesta VoIP basado en Asterisk (Final)



Estructura de Archivos en Linux



Añadir un Direct Inward Service Access (DISA)



Crear un salón de conferencias virtual



Crear un grupo de marcado



Crear una cola de distribución de llamadas



Cambiar el idioma de Asterisk

1. Si deseas saca una copia a las voces en ingles

#cp -r /var/lib/asterisk/sounds /var/lib/asterisk/sounds-org

2. Borra los sonidos de la carpeta sounds.

#rm * /var/lib/asterisk/sounds

#rm * /var/lib/asterisk/sounds/digits

#rm * /var/lib/asterisk/sounds/phonetic

#rm * /var/lib/asterisk/sounds/letters

3. Descomprime las voces en una carpeta temporal

# cd /root

# mkdir voces

# cd voces

# unzip Net-Security-Sonidos-Espanol-Asterisk-K-rem.zip

4. Copia los sonidos en español

#cp Net-Security-Sonidos-Espanol-Asterisk-K-rem/es/*

/var/lib/asterisk/sounds

#cp Net-Security-Sonidos-Espanol-Asterisk-K-rem/digits/es/*

/var/lib/asterisk/sounds/digits

#cp Net-Security-Sonidos-Espanol-Asterisk-K-rem/phonetic/es/*

/var/lib/asterisk/sounds/phonetic

#cp Net-Security-Sonidos-Espanol-Asterisk-K-rem/letters/es/*

/var/lib/asterisk/sounds

Nota: dependiendo de la versión de Asterisk o trixbox que estemos usando puede variar la

estructura de estos archivos.



Grabar el mensaje de bienvenida

Para grabar el mensaje de bienvenida tenemos dos opciones:

Opción 1:

1. Grabar el mensaje desde un terminal con la opción *77

2. Una vez grabado marcamos la opción *99 para escucharlo

3. Lo nombramos en la Interfaz Web y presionamos la opción Save.

Opción 2:

1. La segunda opción es grabar el mensaje en un estudio de grabación o en algún lugar

libre de ruido y subir luego el archivo siguiendo las instrucciones del portal.

Nota: Es importante saber que si el audio es grabado en WAV se debe grabar a 16 bit; 8000 Hz;

mono.



Crear el IVR

Documents

La Guía Absoluta Para Asterisk