La Guía Absoluta para Asterisk

La Gua
Absoluta Para
VoIP,
Asterisk
y trixbox
Por: Radhams Fernndez
La Gua Absoluta Para VoIP, Asterisk y trixbox
Contenido
1.
Sobre Telefona
1.1.
Qu es una PBX?
1.2.
Convirtiendo de Anlogo a Digital
1.3.
Protocolos de Sealizacin
1.3.1.
Sealizacin en redes telefnicas clsicas
1.3.2.
Videoconferencia sobre redes paquetes: H.323
10
1.3.3.
Propuesta del IETF para la transmisin de VoIP: SIP
15
1.3.4.
VoIP en la red de transito: MEGACO y MGCP
19
1.3.5.
Redes Mviles de Tercera Generacin: Hacia una Arquitectura ALL-IP
21
1.3.6.
Conclusiones sobre los protocolos de sealizacin
24
1.3.7.
Referencias
24
2.
VoIP
27
2.1.
En qu se diferencia la telefona IP de la telefona 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 verificacin en Linux tiles en Asterisk
34
4.2.
Principales Comandos en Asterisk
35
4.3.
Archivos de Configuracin y Logs en Asterisk
37
5.
Instalando Asterisk
38
2

6.
Recursos para Ventas
39
6.1.
Lista de Verificacin Preventa
39
6.2.
Valor agregado
40
6.3.
Recursos para elaborar el presupuesto de un proyecto
40
6.4.
Cmo calcular el Costo Total de Propiedad
40
6.5.
Retorno de la Inversin (ROI)
41
6.6.
Diseo, implementacin, puesta en marcha y mantenimiento de Asterisk
42
6.6.1.
Mtodos de Conexin
42
6.6.2.
Conceptos bsicos de T1
43
6.6.3.
Equipos Terminales
48
6.6.4.
Equipos de comunicacin
52
6.6.5.
Especificaciones del Servidor:
53
6.7.
7.
Calidad en el uso de los recursos de voz en la empresa

Trixbox
54
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 solucin de telefona
61
7.5.
Soluciones de Asterisk existentes en el mercado
61
7.6.
Instalacin y Administracin de trixbox CE
63

7.6.1.
Pasos para empezar a trabajar con trixbox
63
7.6.2.
Administracin desde la consola Web:
63
7.7.
Confeccin del plan de marcado y enrutamiento de llamadas
65
7.8.
Conceptos bsicos de CRM
70
7.9.
Concepto bsico de Comunicacin 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 inters
81
9.
Caso de Estudio:
82
10.
Laboratorios
83
1. Sobre Telefona
Telefona es la ciencia de convertir sonido en seales elctricas y transmitirlo entre puntos

extensamente apartados.
El telfono es un dispositivo de telecomunicacin diseado para transmitir seales acsticas

por medio de seales elctricas a distancia. Muy parecido al teletrfono.
Quin invent el Telfono?

Durante mucho tiempo Alexander Graham Bell fue considerado el inventor del telfono, 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 resolucin 269, por la que se reconoca que el inventor del telfono haba sido
Antonio Meucci, que lo llam teletrfono, y no Alexander Graham Bell. En 1871 Meucci slo
pudo, por dificultades econmicas, presentar una breve descripcin de su invento, pero no
formalizar la patente ante la Oficina de Patentes de EE.UU (Artculo Tomado de Wikipedia).
1.1. Qu es una PBX?

Una PABX, comnmente conocida como PBX, es traducida al espaol como, Central Secundaria
Privada Automtica. Una PBX es privada porque pertenece a la empresa, aunque la compaa
Telefnica le provea el servicio. En sus orgenes las PBX eran anlogas, aunque en estos tiempos
se puede notar que la mayora de los equipos recientes son digitales. El uso de las PBX para las
empresas tiende a ser atractivo, en relacin a costo beneficio, debido a que es ms factible
manejar el volumen de telfonos que se requieren, que correr una lnea separada para cada
equipo, sin mencionar que provee ms servicios que los simples telfonos estacionarios.
Figura: Central Telefnica Antigua
1.2. Convirtiendo de Anlogo a Digital
Figura: Conversin de Anlogo a PCM

La voz es una seal anloga. Para transportar las seales de voz a travs de una red de
computadores, las ondas de sonido son convertidas en una seal anloga elctrica, la cual debe
ser filtrada por un rango de frecuencia especifico (entre los 300 y 3,600 Hz) para as ser
convertida en una seal digital (la representacin de las seales de voz analgicas usando 1s y
0s tambin conocidos como bits) para su transmisin a travs de la Red.
Cuando la seal digital llega a su destino, es convertida otra vez en una seal anloga para
recrear ondas de sonido que el usuario pueda escuchar. La conversin de anlogo a digital y
viceversa ocurre en diferentes puntos durante la transmisin.
Durante el proceso de conversin de anlogo a digital ocurren una serie de pasos como
detallamos a continuacin:
Filtrar la seal anloga entrante
La seal anloga entrante debe ser filtrada por un rango en la frecuencia de 300 a 3,600 Hz.
Este paso prepara la seal para la aplicacin del Teorema de Nyquist, como se detalla en el
paso 2. Este rango de frecuencia es requerido para lograr las metas originales del sistema
telefnico: 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 numrica. Pulse
Code Modulation (PCM) es usado para hacer el muestreo del sonido. PCM asigna 8 bit de
cdigo binario a una amplitud especfica (muestra) de una seal. Usando PCM, una seal
anloga es muestreada a una velocidad de 8,000 veces por segundo. Este tipo de muestreo se
deriva de la teora desarrollada por Harry Nyquist, quien estableci que para garantizar la
calidad de la secuencia numrica resultante, el muestreo de una onda de sonido debe ser al
menos dos veces la frecuencia mxima de la seal a ser muestreada.
Cuantizar la muestra de voz y codificarla (asignarle un nmero)
La muestra da como resultado un Pulse Amplitude Modulation (PAM), el cual es una serie de
pulsos que representan la amplitud de la seal anloga al momento de cada muestra.
Transmitir el cdigo como una serie de bits a travs de la Red
En la Telefona tradicional basada en TDM, cada cdigo de 8 bit es enviado a travs de la Red
individualmente en un periodo de tiempo asignado a una llamada telefnica particular. En VoIP,
no podemos permitirnos el overhead que generaran el protocolo IP y la Capa 2 al enviar cada
byte producido por el CODEC a travs de la Red. Por consiguiente, las series de bytes son
grabadas y agrupadas en muestras por un periodo especfico de tiempo, usualmente en
incrementos de 10 ms. A esto se le conoce como tasa de empaquetado o tamao de la muestra
de voz. Cuando el periodo de muestreo se ha alcanzado, la muestra de voz es empaquetada y
enviada a travs de la Red. Los paquetes salen del origen en intervalos regulares.
Figura: Conversin de anlogo a Digital
1.3. Protocolos de Sealizacin

En los ltimos aos, los protocolos de sealizacin para el servicio de transmisin de voz han
experimentado una fuerte evolucin junto con la tendencia a trasportar dicho trfico desde las
redes de conmutacin de circuitos hacia las redes de conmutacin de paquetes. Esta tendencia
queda reflejada con la fuerte evolucin de estndares en este mbito y la aparicin 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 prximos 5 aos debido a la
evolucin de las redes mviles basadas en tecnologa UMTS hacia entornos ALL-IP. En este
artculo se presentan las diferentes arquitecturas que estn siendo propuestas para soportar la
sealizacin de sistemas VoIP, debidas principalmente a los estndares H.323, SIP y MGCP,
junto con un breve resumen de los mecanismos de sealizacin en redes telefnicas clsicas
(SS7) y algunas ideas sobre la evolucin hacia ALL-IP en redes mviles de 3G basadas en
UMTS.
1.3.1. Sealizacin en redes telefnicas clsicas

La sealizacin en las redes telefnicas clsicas ha experimentado una intensa evolucin a lo
largo del siglo XX, al ritmo marcado por el propio desarrollo de las tecnologas de conmutacin
de circuitos en las que estas redes se fundamentan. Tras la conmutacin manual de finales del
siglo XIX y principios del XX, 1910 trajo la conmutacin electromecnica. En esta etapa
tecnolgica, que dur hasta los aos 60, la sealizacin se transportaba "en banda" (cambios de
nivel y tonos dentro del propio canal telefnico) y era interpretada por elementos
electromecnicos (rels) y electrnicos (filtros) en su trnsito por la red.
A mediados de los 60, el proceso de digitalizacin de la red alcanz la propia tecnologa de
conmutacin - red digital integrada de transmisin ms conmutacin - con la llegada de las
centrales digitales y el control de la conmutacin por CPU (control por programa almacenado).
De este modo, los canales sncronos de 64 Kb/s son conmutados octeto a octeto espacial y
temporalmente. Estos conmutadores ya estn controlados ntegramente por procesadores que
hablan un protocolo de sealizacin con procesadores de otras centrales. Los primeros
protocolos de sealizacin instalados en estos sistemas tenan 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 seales analgicas de los sistemas
precedentes.
El salto cuntico se consigui realmente cuando se aplic totalmente la tecnologa de redes de
ordenadores y las seales devinieron en mensajes intercambiados por aplicaciones sobre una
red de conmutacin de paquetes independiente y dedicada a este fin.
Si bien en la actualidad la red telefnica utiliza internamente esta forma de funcionamiento
prcticamente en su totalidad, el ltimo segmento por digitalizar, la red de acceso del abonado,
permanece masivamente analgica, con una penetracin discreta de accesos ntegramente
digitales (RDSI). Consecuentemente, la sealizacin de abonado del servicio de telefona
tradicional ha evolucionado muy poco y es dentro de la red donde se realiz una revolucin
muy importante, transparente al usuario, que ha permitido la introduccin de servicios
suplementarios, de telefona mvil, de red inteligente, B-ISDN e inter funcionamiento con
sistemas de telefona sobre IP (VoIP) entre otros.
El sistema de sealizacin de red que ha soportado esta evolucin con gran flexibilidad es el
Sistema de Sealizacin 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 Sealizacin n 7 es una arquitectura de protocolos de sealizacin completa en
el que las unidades de seal son mensajes de las aplicaciones de sealizacin transportados en
paquetes. Las caractersticas esenciales de este sistema son:
Los enlaces y nodos de sealizacin constituyen una red de conmutacin de paquetes

lgicamente independiente de la de conmutacin de circuitos, con un plan de direccionamiento
distinto y definido a nivel internacional por ITU-T.
Es un sistema de sealizacin por canal comn. Existe un conjunto predefinido de canales entre
centrales (y puntos de transferencia de sealizacin sin capacidad de conmutacin de circuitos)
dedicados a transportar mensajes de sealizacin relativa al establecimiento, liberacin y
supervisin de cualquier canal de 64 Kb/s de voz o datos. En los sistemas de sealizacin
previos, por canal asociado, la sealizacin asociada a cada circuito de voz se transportaba por
un canal de transmisin 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 sealizacin en telefona est diseada especficamente para funcionar
sobre canales de 64 Kb/s y a gestionar dichos enlaces. Por consiguiente no parece improbable
una tendencia no slo 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 evolucin de la infraestructura de red de sealizacin y gestin. Revisada aqu
brevemente la historia de los sistemas de sealizacin, resulta curioso observar cmo la
conmutacin de paquetes, introducida en las redes tradicionales para ofrecer flexibilidad y
fiabilidad a las labores de sealizacin en el plano de control de las torres de protocolos, se
ampla en la actualidad al plano de usuario para el transporte de voz empaquetada,
integrndose de nuevo voz y sealizacin.
1.3.2. Videoconferencia sobre redes paquetes: H.323

La ITU-T fue el primer comit de estandarizacin que desarroll un estndar para la
transferencia de trfico multimedia sobre redes de paquetes. El estndar denominado H.323
fue estandarizado en 1996 y se denomino: Sistemas y terminales de telefona visual sobre
redes de rea local sin garantas de calidad de servicio. La principal aportacin de este
estndar fue el desarrollo de un conjunto de protocolos de sealizacin que permiten controlar
el establecimiento, mantenimiento y liberacin de conexiones de multimedia (audio, vdeo y
datos) sobre redes de paquetes, ya que los protocolos para la transmisin de estos medios
fueron adoptados de trabajos previos, principalmente desarrollados por el IETF a travs de los
protocolos RTP y RTCP.
Tras esta primera versin, en 1998 apareci la segunda versin del protocolo H.323v2 con un
nuevo nombre: Packet based multimedia communications systems, nombre que permanece
hasta la actualidad (la versin 4 fue aprobada en Nov 2000 [6]). H.323 es considerado un
paraguas de estndares y define 4 tipos de elementos funcionales:
10
Figura: Arquitectura de H.323
Terminal H.323, es un terminal de la red que proporciona en tiempo real comunicacin

bidireccional con otro terminal H.323, pasarela, o MCU (unidad de control multipunto). El
intercambio de informacin incluye controles, indicaciones, audio, video y datos. Un terminal
debe soportar al menos transmisin de voz, voz y datos, voz y video o voz datos y vdeo.
Figura: Estructura de Terminal H.323
11
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 adaptacin entre flujos de informacin as como entre los protocolos de
control de ambos entornos. La recomendacin 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 Mviles), and V.70 (DSVD). La pasarela debe constar al menos de
dos interfaces, realizando las funciones de adaptacin 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
transmisin Multicast de las redes IP no requiere la utilizacin de un elemento externo a los
terminales para realizar funciones de mezclado de medios. Por esta razn, la MCU est dividida
en dos partes: el controlador multipunto (MC) que proporciona capacidad de negociacin y
control de los miembros del grupos, y el procesador multipunto (MP) que se encarga de realizar
las funciones de mezcla de medios (audio, vdeo, 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 aplicacin
de esta tecnologa en entornos con un nmero de terminales medio-grande. El GK es un
elemento opcional de la arquitectura, lo que permiti inicialmente el desarrollo de terminales
que podan 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: traslacin de direcciones, autorizacin de llamadas, control de admisin,
control de zonas, gestin de ancho de banda, gestin 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 sealizacin. La mayor parte de
canales de control utilizan conexiones TCP (tambin UDP a partir de la versin 3), mientras el
transporte de medios utiliza UDP.
12
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 conexin entre dos terminales dependientes de este GK sigue los
siguientes pasos Figura 5:
Fase A: Establecimiento de Llamada.

La entidad llamante, enva mensajes RAS solicitando la identificacin del usuario llamante (ej.:
alias) utilizando un mensaje ARQ. El GK aceptar la llamada y enviar al terminal llamante un
mensaje de confirmacin (ACF) o bien rechazar la llamada (ARJ). En caso positivo, la entidad
llamante establecer una conexin TCP con el terminal llamado para establecer el canal de
sealizacin H.225.0. Para ello utilizar la informacin (direccin IP y puerto) recibidos del GK a
travs del mensaje ACF. La entidad llamante al recibir dicha conexin contactar con su GK a
travs del canal RAS solicitando permiso para poder contestar (ARQ). En caso positivo (ACF), el
llamante aceptara la conexin y a travs de dicho canal (H.225.0) enviar la direccin (direccin
IP y puerto) donde establecer el canal H.245 para negociacin de parmetros y control de la
comunicacin.
Una vez obtenida esta informacin, la conexin puede ser finalizada, ya que no es necesario
intercambiar ms parmetros a travs de este canal.
Fase B: Intercambio de capacidades. (H.245)

Establecido el canal H.245 a travs de una nueva conexin TCP, las entidades llamante y
llamada determinaran los parmetros de la comunicacin: codificadores a utilizar, nmero de
13
conexiones y direcciones a utilizar, puertos, nmero de muestras por trama, funcin maestroesclavo, etc., lo que les permite establecer canales para la transmisin de medios (audio, vdeo
y datos). Esta conexin debe permanecer mientras intercambien informacin los terminales y
les permite modificar parmetros (CODECS, nmero de muestras por trama, etc.).
Fase C: Intercambio de informacin audiovisual

En este punto, ambos terminales establecen canales de informacin a travs de la arquitectura
RTP/UDP/IP para el transporte de medios, as como canales de control a travs de la
arquitectura RTCP/UDP/IP para los canales de realimentacin, al objeto de controlar la calidad
de los flujos de informacin recibida por el otro extremo de la comunicacin.
Fase D: Terminacin de llamada

Tras el intercambio de informacin audiovisual y al objeto de finalizar la llamada, las entidades
H.323 deben informarse a travs del canal H.245 mediante el envo de las primitivas de
finalizacin de llamadas, que finalizar con el envo de la primitiva EndSessionCommand que
provocar el cierre del canal H.245. Adems debern informar al GK mediante el envo de el
mensaje RAS Disengage Request (DRQ) que permitir al GK liberar recursos y proporcionar
informacin de tarificacin entre otras.
Sobre este escenario bsico existen mltiples variantes en funcin de la presencia o no del GK y
del role que el mismo realice. El GK podra encaminar la informacin de control, (H.225.0 y
H.245) o no en funcin del modelo elegido (Directo o Indirecto).
14
Figura 5: Ejemplo llamada H.323

Del ejemplo mostrado anteriormente, se observa el coste de establecimiento de llamada
debido a la necesidad de establecer mltiples conexiones previas al intercambio de
informacin. Esta necesidad fue solventada con la aparicin de la versin dos del protocolo,
que proporciona dos posible modos de operacin opcionales alternativos: Procedimiento de
Conexin Rpida, que permite abrir canales de informacin a partir de la fase de intercambio
de informacin H.225.0 y el procedimiento de establecimiento de tneles 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 transmisin de VoIP: SIP

Session Initiation Protocol (SIP), es un protocolo de aplicacin 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 informacin
multimedia soportando mecanismos de establecimiento, modificacin y finalizacin 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 bsicos de identificar y participar en sesiones multimedia:
15
Mecanismo de Anuncio. Las sesiones son anunciadas mediante email, pginas web, grupos de
noticias o bien mediante el protocolo de anuncio de sesiones (SAP) como sucede en la red
MBONE.
Mecanismo de Invitacin. Los usuarios son, mediante invitacin, informados por otros a
participar mediante el protocolo de establecimiento de sesiones (SIP).
De entre ambos, SIP ha sido propuesto como un mecanismo genrico para el soporte de
mecanismos de sealizacin del servicio de telefona IP. SIP soporta 5 elementos funcionales
para el establecimiento y terminacin de comunicaciones multimedia:
Localizacin de usuarios
Intercambio / negociacin 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 envan 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 intervencin de
elementos intermedios, al igual que en el caso de H.323. La Figura 6 muestra un ejemplo de
conexin entre user1 con direccin IP 172.16.10.1 y user2 con direccin IP 172.16.1.2 mediante
el envo de una peticin INVITE Request, en la cual el user1 indica al user2 las capacidades de
recepcin de audio (codificacin ley ) y el puerto donde espera recibir dicho audio (port
12345). Al recibir la peticin, el user2 puede inmediatamente establecer el canal de voz y enviar
la aceptacin de conexin mediante el envo de OK Response, en la cual incluye la informacin
complementaria para el establecimiento del canal opuesto (codificacin GSM, puerto 54321 en
nuestro ejemplo). Tras el intercambio de seal de audio, cualquiera de los participantes puede
finalizar la llamada mediante el envo del mensaje BYE Request que debe ser asentido
mediante un mensaje de confirmacin (OK).
16
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 descripcin de
sesiones (SDP) [10], ampliamente utilizado en el contexto de MBONE para distribuir la
informacin de sesiones.
Adems de los terminales H.323 que representan telfonos IP o pasarelas, la arquitectura SIP
define cuatro tipos de servidores:
Servidor Proxy. Se encarga de encaminar peticiones/respuestas haca 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 parmetro incluido en las peticiones/respuestas denominado Va
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 informacin de control pues el transporte de medios, salvo en el
caso de requerir transcodificacin intermedia, se realiza directamente entre origen y destino.
17
Servidor de Redireccin. Realiza una funcin equivalente al servidor proxy, pero a diferencia de
ste no progresa la llamada, sino que contesta a un INVITE con un mensaje de redireccin,
indicndole en el mismo como contactar con el destino.
Servidor de Registro. Mantienen la localizacin actual de un usuario. Se utiliza para que los
terminales registren la localizacin en la que se encuentran. Este servidor facilita la movilidad
de usuarios, al actualizar dinmicamente la misma.
Agente de Llamada (Call Agent). Realiza las funciones de los tres servidores anteriores, adems
de poder realizar las siguientes acciones:
o
o
o
o
o
Localizar a un usuario mediante la redireccin de la llamada a una o varias localizaciones

Implementar servicios de redireccin como reenvo si ocupado, reenvo si no contesta, etc.
Implementar filtrado de llamada en funcin del origen o del instante de la llamada
Almacenar informacin de administracin de llamas
Realizar cualquier otra funcin de gestin
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 nmero telefnico y host es el dominio al que pertenece el usuario o direccin
de red.
En la Figura 7 se muestra un ejemplo de interaccin entre servidores SIP. En este ejemplo David
desde su oficina (company.es) desea llamar al usuario jmoreno del dominio upm.es. Para ello
enva una peticin (NOTIFY Request) al servidor SIP de su organizacin, el cual acta como un
servidor proxy y tras consultar el DNS, localiza el servidor SIP del dominio upm.es, reenvindole
la peticin. Este servidor, que acta como servidor de redireccin, contesta a la peticin
indicndole 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 acta 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 aceptacin de llamada progresa hasta el origen pasando por los
servidores de redireccin involucrados, momento en el cual origen y destino pueden establecer
los canales de voz.
18
Figura 7: Ejemplo de Servidores SIP

La principal caracterstica de SIP frente a H.323 es su simplicidad. Mientras H.323v1 necesita 5 o
6 intercambios de informacin entre los destinatarios antes de establecer una conexin, SIP
requiere nicamente uno y puede ser transmitido por TCP o UDP. Estos aspectos fueron
introducidos en la versin 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 trfico 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 utilizacin de redes de paquetes como backbone
para la transmisin de trfico de voz originado por redes tradicionales. Los operadores
tradicionales fueron uno de los que mayor inters han mostrado en esta propuesta, pensando
en integrar progresivamente sus redes de telefona basadas en conmutacin de circuitos y sus
redes de datos basadas en conmutacin de paquetes en una red homognea que transportar
ambos tipos de trfico (voz y datos) y que fuera transparente a los usuarios finales.
MEGACO resuelve este problema dividiendo las pasarelas (Gateways) en tres entidades
diferentes:
19
Controlador de Medios (Media Gateway Controller MGC-), que proporciona la sealizacin

H.323 o SIP y realiza el mapping entre la sealizacin de redes tradicionales y las redes de
paquetes.
Pasarela de Medios (Media Gateway MG-), que proporciona la adaptacin de medios y/o las
funciones de transcodificacin. Este bloque realiza las funciones de traslacin de direcciones,
cancelacin de eco, envo/recepcin de dgitos DMTF, etc.
Pasarela de Sealizacin (SG), que proporciona funciones de mediacin de sealizacin entre

redes IP y SCN.
En un escenario habitual los tres elementos estn fsicamente separados de modo que pueden
proporcionar ventajas como la concentracin 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 informacin entre MG y MGC. MGCP es el resultado de protocolos
anteriormente propuestos y ha sido propuesto en distintos organismos de estandarizacin
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 parmetros entre el MG y
MGC (direccin IP, puerto UDP, codificadores a utilizar, etc.).
20
1.3.5. Redes Mviles de Tercera Generacin: Hacia una Arquitectura ALL-IP

El Third Generation Parnertship Project, 3GPP [15] tiene como objetivo la estandarizacin de
sistemas mviles de tercera generacin (3G) basados en la evolucin del ncleo de red GSM y
en tecnologas WCDMA en el acceso radio. A estos sistemas se les llama Sistemas de
Telecomunicacin Mvil Universal (UMTS) y los primeros sistemas comerciales se lanzarn al
mercado durante el ltimo trimestre del ao 2000.
La primera fase de la especificacin de UMTS finaliz a principios del ao 2000 y el resultado se
conoce con el nombre de Release 1999 (R99). El 3GPP contina desarrollando especificaciones
que definan la evolucin 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 evolucin. En esta seccin
describimos brevemente la arquitectura UMTS R99 as como la evolucin 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 conmutacin de circuitos (CC) y transportan el trfico
21
de voz. Los SGSNs y los GGSNs forman el dominio de conmutacin de paquetes (CP) y
transportan el trfico de datos en modo paquete. El VLR, el HLR, el EIR, y el AuC, mantienen
informacin sobre los usuarios. Los MSCs o GSNs los pueden interrogar utilizando el protocolo
MAP (Mobile Application Part ).
Por tanto, el ncleo de red UMTS est formado por dos redes, una de conmutacin de circuitos
(dominio CC) y una de conmutacin de paquetes (dominio CP). Este diseo permite a los
operadores de redes GSM/GPRS una fcil evolucin hacia sistemas UMTS. Pero, en el futuro,
estos sistemas tendrn un ncleo de red unificado basado en una red de conmutacin de
paquetes IP, tal como se indica en la Release 4 y 5 y quiz incluso, la evolucin hacia la red IP
incluya tambin la red de acceso, tal como se trabaja en distintos proyectos de investigacin
europeos *19+. Esto se conoce con el nombre de arquitectura All-IP *20+. La razn es que las
redes de conmutacin de paquetes son eficientes y capaces de transportar las diferentes clases
de trfico. Adems, IP es un protocolo probado y que permite una fcil intercomunicacin con
Internet.
Figura 10: Dominio CC

En la Figura 10 se muestra la evolucin 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 sealizacin usuario-red,
traducindola a la sealizacin red-red apropiada. El control de llamada red-red (interfaz entre
MSC servers) se realizar mediante sealizacin ISUP, o por una evolucin 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 tecnologa de transporte: VoIP (RTP/UDP/IP), VoATM (AAL2), y TDM, son
opciones para el transporte de voz en este dominio. Tambin hay diferentes opciones para el
22
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 estndar
H.248/MEGACO. La T-SGW (Tranport Signalling GateWay function) se encarga de coger la
informacin de sealizacin 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 informacin aadida sobre servicios IP multimedia.
Es interesante destacar que, independientemente de la tecnologa de transporte empleada en
el dominio CC, los terminales UMTS R99 van a poder utilizar los servicios del dominio CC.
Cualquier nueva funcin de sealizacin es realizada por la red.
Figura 11: Dominio CP y subsistema IP multimedia

En la figura 11 se muestra la evolucin prevista para el dominio CP de UMTS. Al dominio CP se
le aade 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 aplicacin) de llamadas
entrantes, establecimiento y liberacin de llamadas, manejo de direcciones, etc. La MGCF
controla las MGWs usando H.248. Tambin realiza conversin 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 informacin de sealizacin relacionada con llamadas
23
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 mviles que quieren usar los servicios IP Multimedia deben ser terminales IP con
capacidad de sealizacin SIP. Se comunican con la CSCF para registrarse y para solicitar
servicios.
1.3.6. Conclusiones sobre los protocolos de sealizacin

Los sistemas de sealizacin para el transporte de voz han evolucionado desde las redes
basadas en conmutacin de circuitos a redes basadas en conmutacin de paquetes. Diferentes
estndares han aparecido para tratar de solventar problemas de direccionamiento, control de
admisin, interconexin con redes existentes, intercambio de capacidades, etc. Basados en la
transmisin de VoIP y el tipo de usuarios, dos diferentes escenarios han sido objeto de
desarrollo por parte de los organismos de estandarizacin: 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 aplicacin 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 tecnologas para ofrecer un
servicio de transmisin de voz. Esta tendencia a sustituir las redes de conmutacin de circuitos
por redes de conmutacin de paquetes se ver incrementada en los prximos aos con la
evolucin de las redes mviles UMTS hacia la tecnologa ALL-IP, en la cual los servicios
multimedia, y por tanto el servicio de transmisin de voz, sern transmitidos sobre redes bajo
tecnologa 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.
24
[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 Vgel, J. Eberspcher; 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 artculo: Protocolos de Sealizacin para el transporte de Voz sobre redes IP
Por:
Jose Ignacio Moreno, es Doctor Ingeniero de Telecomunicaciones por la Universidad Politcnica

de Madrid (1996) y trabaja como Profesor Titular de Ingeniera Telemtica en la Universidad
Carlos III de Madrid.
25
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 Politcnica de
Madrid (1996) y trabaja como Profesor Titular de Ingeniera Telemtica en la Universidad Carlos
III de Madrid.
26
2. VoIP
Para definir el concepto esencial de VoIP, quisiera romper con la confusin de dos conceptos
altamente mencionados en estos das:
Voice over IP / Voz sobre IP (VoIP): es el conjunto de normas, dispositivos, protocolos, en

definitiva la tecnologa que permite la transmisin de la voz sobre el protocolo IP.
Telefona IP: es el conjunto de nuevas funcionalidades de la telefona, es decir en lo que se

convierte la telefona 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 telefona IP de la telefona normal?
En una llamada telefnica normal, la Central Telefnica establece una conexin permanente
entre ambos interlocutores, conexin que se utiliza para llevar las seales de voz. En una
llamada telefnica por IP, los paquetes de datos, que contienen la seal de voz digitalizada y
comprimida, se envan a travs de Internet o nuestra LAN a la direccin IP del destinatario.
Cada paquete puede utilizar un camino para llegar, estn compartiendo un medio, una red de
datos. Cuando llegan a su destino son ordenados y convertidos de nuevo en seal de voz.
2.2.
Qu compone un paquete de VoIP?
Comenzando desde lo bsico, el paquete de VoIP en un Sndwich 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 combinacin con la voz toma la forma de un
paquete comn y corriente.
Figura: composicin paquete de VoIP

27
2.3.
Calidad de Servicio (QoS)
En VoIP se cuenta con diferentes herramientas y mecanismos para lograr la calidad de la

transmisin de la voz sobre los medios de datos:
La supresin de silencios, otorga ms eficiencia a la hora de realizar una transmisin de voz,

ya que se aprovecha mejor el ancho de banda al transmitir menos informacin.
Compresin de cabeceras aplicando los estndares RTP/RTCP.
Priorizacin de los paquetes que requieran menor latencia. Las tendencias actuales son:
o
CQ (Custom Queuing): Asigna un porcentaje del ancho de banda disponible.
PQ (Priority Queuing): Establece prioridad en las colas.
WFQ (Weight Fair Queuing): Se asigna la prioridad al trfico de menos carga.
DiffServ: Evita tablas de encaminados intermedios y establece decisiones de rutas por

paquete.
La implantacin 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 conexin y basadas en conmutacin

de paquetes. Como la informacin se propaga en paquetes, cada uno de los paquetes puede
seguir una ruta distinta para llegar al destino.
El jitter se define tcnicamente como la variacin en el tiempo en la llegada de los paquetes,
causada por congestin de red, prdida de sincronizacin 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.
28

o
Valores Recomendados
El jitter entre el punto inicial y final de la comunicacin 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 solucin ms ampliamente adoptada es la utilizacin del jitter buffer. El jitter buffer consiste
bsicamente en asignar una pequea cola o almacn para ir recibiendo los paquetes y
sirvindolos con un pequeo retraso. Si algn paquete no est en el buffer (se perdi o no ha
llegado todava) cuando sea necesario se descarta. Normalmente en los telfonos IP (hardware
y software) se pueden modificar los buffers. Un aumento del buffer implica menos prdida de
paquetes pero ms retraso. Una disminucin implica menos retardo pero ms prdida de
paquetes.
Latencia
A la latencia tambin se la llama retardo. No es un problema especfico de las redes no

orientadas a conexin y por tanto de VoIP. Es un problema general de las redes de
telecomunicacin. Por ejemplo, la latencia en los enlaces va satlite es muy elevada por las
distancias que debe recorrer la informacin.
La latencia se define tcnicamente 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 comunicacin debe ser inferior a 150 ms.
El odo 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 comunicacin se vuelve molesta.
o
No hay una solucin 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 sealizar los paquetes con valores de TOS
para intentar que los equipos sepan que se trata de trfico en tiempo real y lo traten con mayor
29
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 fenmeno tcnico que es la conversin de 2 a 4 hilos de los sistemas
telefnicos o por un retorno de la seal que se escucha por los altavoces y se cuela de nuevo
por el micrfono.
El eco se define como una reflexin retardada de la seal acstica 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 telefona tradicional.
o
El odo humano es capaz de detectar el eco cuando su retardo con la seal original es igual o
superior a 10 ms. Pero otro factor importante es la intensidad del eco ya que normalmente la
seal de vuelta tiene menor potencia que la original. Es tolerable que llegue a 65 ms y una
atenuacin de 25 a 30 dB.
o
Citamos dos posibles soluciones para evitar este efecto tan molesto.
Supresores de eco: Consiste en evitar que la seal emitida sea devuelta convirtiendo por
momentos la lnea full-duplex en una lnea half-duplex de tal manera que si se detecta
comunicacin en un sentido se impide la comunicacin en sentido contrario. El tiempo de
conmutacin de los supresores de eco es muy pequeo. Impide una comunicacin full-duplex
plena.
Canceladores de eco: Es el sistema por el cual el dispositivo emisor guarda la informacin que
enva en memoria y es capaz de detectar en la seal de vuelta la misma informacin (tal vez
atenuada y con ruido). El dispositivo filtra esa informacin y cancela esas componentes de la
voz. Requiere mayor tiempo de procesamiento.
30
Prdida de paquetes:
Las comunicaciones en tiempo real estn basadas en el protocolo UDP. Este protocolo no est
orientado a conexin y si se produce una prdida de paquetes no se reenvan. Adems la
prdida de paquetes tambin 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
prdidas de paquetes en rfagas.
o
La prdida de paquetes mxima admitida para que no se degrade la comunicacin deber ser
inferior al 1%. Pero es bastante dependiente del CODEC que se utiliza. Cuanto mayor sea la
compresin del CODEC ms pernicioso es el efecto de la prdida de paquetes. Por ejemplo, una
prdida del 1% degrada ms la comunicacin si se usa el CODEC G.729 en vez del G.711.
o
Para evitar la prdida de paquetes una tcnica muy eficaz en redes con congestin o de baja
velocidad es no transmitir los silencios. Gran parte de las conversaciones estn llenas de
momentos de silencio. Si solo transmitimos cuando haya informacin audible liberamos
bastante los enlaces y evitamos fenmenos de congestin.
De todos modos este fenmeno puede estar tambin bastante relacionado con el jitter y el
jitter buffer.
31
3. CODECS
Un CODEC es un algoritmo, o programa especializado de computadora, que convierte seales
anlogas (como la voz) en un resultante digital para su transmisin en una Red de Datos y a su
vez reconvertir esa seal digital generada en una seal anloga al otro lado.
Regularmente los CODECs son usados para minimizar el uso de Ancho de Banda en las
conexiones a la hora de una implementacin de Telefona IP.
Codec Information
Codec
Sample
Codec & Bit Size
Rate (Kbps) (Bytes)
G.711 (64
Kbps )
80 Bytes
G.729 (8
Kbps )
10 Bytes
G.723.1
(6.3 Kbps ) 24 Bytes
G.723.1
(5.3 Kbps ) 20 Bytes
G.726 (32
Kbps )
20 Bytes
G.726 (24
Kbps )
15 Bytes
G.728 (16
Kbps )
10 Bytes
Codec
Sample
Interval
(ms)
10 ms
Bandwidth Calculations
Mean
Opinion
Score
(MOS)
Voice
Payload
Size
(Bytes)
Bandwidth
Voice
Packets Per MP or
Payload Second
FRF.12
Size (ms) (PPS)
(Kbps)
4.1 160 Bytes 20 ms
50 82.8 Kbps 67.6 Kbps
87.2 Kbps
10 ms
3.92 20 Bytes
20 ms
50 26.8 Kbps 11.6 Kbps
31.2 Kbps
30 ms
3.9 24 Bytes
30 ms
34 18.9 Kbps 8.8 Kbps
21.9 Kbps
30 ms
3.8 20 Bytes
30 ms
34 17.9 Kbps 7.7 Kbps
20.8 Kbps
5 ms
3.85 80 Bytes
20 ms
50 50.8 Kbps 35.6 Kbps
55.2 Kbps
5 ms
60 Bytes
20 ms
50 42.8 Kbps 27.6 Kbps
47.2 Kbps
5 ms
3.61 60 Bytes
30 ms
34 28.5 Kbps 18.4 Kbps
31.5 Kbps
Figura: Clculo de Ancho de Banda segn el uso de CODEC:
Bandwidth
w/cRTP MP Bandwidth
or FRF.12 Ethernet
(Kbps)
(Kbps)
32
Basado en el CODEC, este es el nmero de bits por segundo que necesitan ser transmitidos para
que una llamada de voz progrese. (codec bit rate = codec sample size / codec sample interval).
Basado en el CODEC, este es el nmero de bytes capturados por el Procesador de Seales
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
Codec Sample Size (Bytes) un bit rate de 8 Kbps. (codec bit rate = codec sample size / codec sample interval).
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
Codec Sample Interval (ms) un bit rate de 8 Kbps. (codec bit rate = codec sample size / codec sample interval).
MOS es un sistema de evaluacin de la calidad de la voz sobre conexiones telefnicas. Con MOS
un amplio rango de escuchas evala 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
cuestin.
MOS
El tamao de la carga til de voz representa el nmero de bytes (o bits) que son introducidos
en un paquete. El tamao de la carga til de voz debe ser mltiplo del tamao de la muestra
del CODEC. Por ejemplo, los paquetes de G.729 pueden usar 10, 20, 30, 40, 50, o 60 bytes de
Voice Payload Size (Bytes) tamao para la carga til de voz.
Codec Bit Rate (Kbps)
Voice Payload Size (ms)
PPS
El tamao de la carga til de voz puede ser representado tambin en trminos 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 representa el nmero 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 necesitaran transmitir 50 paquetes cada
segundo. [50 pps = (8 Kbps) / (160 bits per packet)]
Figura: Definicin de los Trminos expuestos en el cuadro anterior:
DIGITALIZACION
MUESTREO
Compresin
DSP
Ancho de Banda
Disponible
PCM
VOZ A
64Kbps
Voz a 8Kbps
Ancho de Banda
Disponible
Voz
Anloga
Figura: Diagrama que representa la compresin luego de aplicar el CODEC:
33
Voz Digital y
Comprimida
4. Asterisk
Asterisk es el Lder mundial en Sistemas y Herramientas de Telefona del tipo Open Source o de
Cdigo 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 comunicacin...gratuitamente.
4.1.
Comandos de verificacin en Linux tiles en Asterisk
Comandos en Linux
Para entrar a la Consola de Asterisk
asterisk -r
Para verificar la Carga actual del sistema
top
Informacin del arreglo RAID
cat /proc/mdstat
Inspeccin de los logs
tail -n 200 /var/log/asterisk/*.log
Verificar la tabla de enrutamiento
netstat -rn o route
Verificar la informacin del CPU
cat /proc/cpuinfo
Verificar la informacin de la Memoria
cat /proc/meminfo
Ejemplo de una prueba de PING
ping -i 0.02 -c 500 -s 270 <host>
Informacin Intensiva del Desempeo del Sistema
vmstat 1
Versin actual de Wanpipe
wanrouter version
Procesos actuales del sistema
ps aux
Informacin actual de Red
ifconfig -a
Diagnstico de Duplexing (Estado Half o Full Duplex)
mii-tool
Verificar Espacio en Disco
df -h
Verificar el Hardware Instalado
lspci
34
4.2.
Principales Comandos en Asterisk

Comandos de Administracion del Servidor
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

Display Asterisk version info
show versin
Comandos AGI
Show AGI commands or specific help
Dumps a list of agi command in html format
show agi
dump agihtml
Comandos para el Manejo de la Base de Datos

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

Shows database contents: An alternative to showing keys by family with database show, this
command shows all the families with a particular key
database showkey
Comandos PRI - Los siguientes comandos estan disponibles solo si el canal fue hecho con soporte para libpri
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 file
Sends PRI debug output to the specified file
pri show debug
Displays current PRI debug settings
pri show span

pri unset debug file
Displays PRI Information

Ends PRI debug output to file
mgcp audit endpoint
Audit specified MGCP endpoint
mgcp debug
Enable MGCP debugging
mgcp no debug
mgcp show endpoints
Disable MGCP debugging

Show defined MGCP endpoints
skinny debug
Enable Skinny debugging
skinny no debug
Disable Skinny debugging

Show defined Skinny lines per device
Comandos para el Canal MGCP
Comandos para los Canales Skinny
skinny show lines
35
Comandos para los Canales IAX

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

show keys
Request IAX trunk debug

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

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

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

Lists all the Zaptel spans. A span will appear here whether or not its channels are configured with
chan_zap.
Show the configured ring cadences (available e.g with Zap/1r2).
Comandos para los Canales SIP
Comandos para los Canales H.323
Comandos para los Canales ZAP
zap show status

zap show cadences
36
4.3.

Archivos de Configuracin de Asterisk
/etc/asterisk/*.conf
Archivo de Configuracin para SIP
/etc/asterisk/sip.conf
Archivo de Configuracin para el Buzn de Voz
/etc/asterisk/voicemail.conf
Archivo de Configuracin para IAX
/etc/asterisk/iax.conf
Archivo de Configuracin del log de Asterisk
/etc/asterisk/logger.conf
Archivo de Configuracin del Dial Plan en Asterisk
/etc/asterisk/extensions.conf
Archivo de Configuracin del Dial Plan en trixbox
/etc/asterisk/extensions_additional.conf
Archivos de Configuracin de Wanpipe
/etc/wanpipe/*
Archivos de Configuracin de Zaptel
/etc/asterisk/zaptel.conf
Archivos de Configuracin 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
Msica en Hold
/var/lib/asterisk/mohmp3
Voces
/var/lib/asterisk/sounds
Firmware de Telfonos
/tftpboot/
/var/log/messages
Archivos Logs del Sistema
37
5. Instalando Asterisk
Refirase a: http://www.voip-info.org/wiki/view/Asterisk+Step-by-step+Installation
38
6. Recursos para Ventas

6.1.
Lista de Verificacin Preventa
Crear un estndar para la Lista de Verificacin de las necesidades del cliente es una buena
prctica. Esto refleja una alta aceptacin por parte del cliente en cuanto a la adquisicin del
nuevo Sistema Telefnico. 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 solucin.
Un ejemplo de una Lista de Verificacin sencillo sera:
Qu sabe el cliente de VoIP?

Qu clase de negocio tiene el cliente?
Qu actividades hacen los empleados en el telfono?
Por que el cliente est interesado en adquirir un nuevo Sistema Telefnico?
Qu caractersticas est buscando el cliente?
Estn cambiando de proveedor? El cambio de proveedor o de servicio podra considerarse una
propuesta de ahorro considerable para el cliente.
El Cliente tiene empleados que se veran beneficiados del uso del Sistema Telefnico
remotamente (Telecommuter)?
Cmo funciona la actual Contestadora Automtica?
Tienen programado cambios en la contestadora automtica para los das feriados?
Cul es el destino que llama con ms frecuencia? Si son llamadas internacionales, mustrele
las alternativas que tiene con troncos SIP o IAX.
Tiene algn departamento que le interese manejar con Colas de Llamadas? Por ejemplo en
ocasiones hay empresas que tienen su propia divisin de Servicio al Cliente y es importante que
ninguna llamada se pierda.
Cuntas extensiones necesita?
Est pensando hacer algn tipo de integracin con otra Central?
Cul es la fecha estimada para el proyecto?
Cmo est constituida su plataforma de Datos? Marca de Switches y tiempo de respuesta de
una terminal a otra
39
6.2.
Valor agregado
Siempre que vayamos a realizar una instalacin de Asterisk, podemos incluir en nuestra
propuesta los siguientes puntos:
Anlisis de la Red del cliente.

Auditoria al proveedor de servicio y los costos de los servicios que este ofrece al cliente.
Entrenamientos de administracin de la plataforma y a usuarios finales.
Opciones de soporte de la nueva adquisicin.
Opciones de seguimiento post instalacin.
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.
Cmo calcular el Costo Total de Propiedad
El Costo Total de Propiedad de cualquier Plataforma es difcil de determinar, pero podemos

puntualizar los factores que entendemos imprescindibles para la adquisicin de un sistema
basado en Asterisk siguiendo los lineamientos ms importantes.
Asterisk es distribuido gratuitamente, un software de fuente abierta. El nico costo envuelto en
la implementacin de Asterisk es hardware. O quizs no? Vamos a ver.
Como se ha discutido anteriormente, Asterisk es bastante flexible. Determinar el cmo usar
esta flexibilidad a nuestro favor nos podra ahorrar mucho tiempo y dinero.
Sepamos por ejemplo que en una implementacin 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 trfico 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
telefnicos, las tarjetas de telefona, etc.
Con los sistemas telefnicos comerciales, los costos de implementacin son considerablemente
ms altos que los costos en los que incurrimos en una implementacin de Asterisk. Sin
embargo, debido a su flexibilidad y uso mltiple, los costos de las soluciones basadas en
Asterisk pueden variar sustancialmente.
40
Debido a que la Plataforma telefnica es un punto esencialmente crtico 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 telefnicas. Los
siguientes elementos deben ser incluidos a la hora de comparar el CTP de mltiples sistemas
telefnicos:
Costo de Adquisicin: 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 Instalacin: Este es el costo de configurar y desplegar la PBX. Algunas compaas
eligen hacer el despliegue in-house; aun bajo esas circunstancias existe un costo y para usar
una comparacin equitativa, este punto debera ser incluido.
Costo de Licenciamiento (una solo vez): Este es el costo de cualquier cargo por licenciamiento
que ocurra una vez. Algunas PBXs requerirn una licencia para realizar la administracin,
mantenimiento, conectarse a una lnea 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 telefnicos tienen un costo anual de
licenciamiento para el uso de ciertas funcionalidades; por ejemplo el uso de algunos aparatos
telefnicos puede requerir una licencia anual para que estos puedan funcionar con la PBX
(ladrones).
6.5.
Retorno de la Inversin (ROI)
Toda empresa quiere saber cmo va a recuperar su dinero a la hora de invertir una alta suma
en una solucin de telefona. La adquisicin de la PBX es solo una pieza en el rompecabezas del
Retorno de la Inversin (ROI).
Por mencionar un ejemplo, el sistema telefnico de la empresa X tiene un Contestador
Automtico (AA), pero este tiene el mal hbito 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 prximos 5 segundos.
41
Cul es el beneficio a razn de un Retorno de la Inversin en este escenario? Un cliente

enojado puede generar prdidas a la hora de decidirse por los servicios ofrecidos por la
empresa X. Esto hace el costo de Asterisk fcil de justificar.
El Retorno de la Inversin es bsicamente el Costo Total de Propiedad sustrado de la
cuantificacin del beneficio (en dinero) para el negocio. Sabiendo esto, si calculamos que un
nuevo Sistema Telefnico nos ahorrar US$8,000.00 y el costo es de unos US$7,000.00,
entonces el Retorno de la Inversin es de unos US$1,000.00.
Otra forma de calcularlo es determinando el tiempo en que se recuperara la inversin realizada
en el nuevo sistema telefnico.
Suponiendo que debido a la instalacin del nuevo sistema telefnico 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 telefnico se pagara en 16 meses. Luego de ah lo dems es ganancia neta para la
empresa por privarse del gasto extra.
A la hora de proponer el reemplazo o nueva instalacin de un sistema telefnico es
recomendable tener todos los nmeros sobre la mesa.
6.6.
Diseo, implementacin, puesta en marcha y mantenimiento de Asterisk
6.6.1. Mtodos de Conexin
Conexin al PSTN (Interfaces Anlogas 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 envan el voltaje de timbrado a las
interfaces FXO.
FXO (Foreing Exchange Office)
Es la manera de designar el punto final de conexin de la llamada. El FXO es el elemento que recibe la
llamada (un telfono o una Central Telefnica conectada a la PSTN). La interface FXO no genera tono,
solo los acepta.
42
Figura: Distribucin interfaces FXS y FXO
6.6.2. Conceptos bsicos de T1

T1, es el mecanismo fsico de envo para la sealizacin DS1.
DS1 (Digital Signal 1), es el protocolo de transmisin usado sobre una lnea fsica T1. Un DS1 es
constituido por 24 canales de 64Kbps, conocidos tambin como bahas de tiempo (timeslots) o
DS0s. La T1 fue creada por los Laboratorios Bell alrededor de los aos 1950.
La informacin 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 mxima de transmisin es de 1.536, haciendo as posible la transmisin de 64Kbps por
espacio de tiempo (timeslot).
Codificacin (CODING), determina de qu forma los bits son colocados en el cable. En una T1
los unos (1) son enviados por la aplicacin de voltaje, mientras que los ceros (0) son
identificados por la falta del mismo.
AMI (Alternate Mark Inversion)
Es una tcnica de codificacin de lnea para T1, el cual usa pulsos bipolares para representar
lgicamente los valores de unos (1). Es por lo tanto un sistema de tres niveles. El valor lgico
para cero (0) es representado por la ausencia de smbolo, y la representacin lgica de los unos
43
(1) para valores positivos o negativos o marcas por pulsos dados por la alternacin de la
polaridad.
B8ZS (Binary 8 Zero Substitution)
Reemplaza cada grupo de 8 consecutivos con el patrn especial "000VB0VB" 00011011. Esto
mitiga la desventaja que presenta AMI en transmisiones consecutivas de ceros.
Entramado (FRAMING), en trminos general un entramado es una divisin de datos para su
transmisin en grupos de bits a los que se les aade una cabecera y un cdigo de verificacin
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 ubicacin del bit de entramado por parte del equipo receptor, se enva un patrn en
este bit. El equipo busca por el bit que tenga el patrn correcto, y alinear su entramado
basado en ese bit. El patrn 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 tcnica de entramado es llamada en ocasiones como D5. ESF
es preferido frente a SF, debido a que incluye un chequeo de redundancia cclica e incluye
ancho de banda para un canal de enlace de datos; el cual pasa datos entre los equipos de la
portadora.
Una Sper trama de ESF es de 24 tramas de largo,
8 bits por trama

Las tramas 4, 8, 12, 16, 20, 24 son usadas para alineacin.
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 informacin del Chequeo de Redundancia Cclica
(CRC).
Es importante saber que no puedes usar AMI con ESF debido a que ambos intentan hacer las
veces de temporizador. Deberas tener un reloj maestro (master clock).
44
Configuraciones de interfaces en zapata.conf

Empiece abriendo el archivo zaptel.conf desde la lnea de comandos en el directorio
/etc/asterisk.
Configurando la gua SPAN:
Para cada T1 utilizada se necesitara definir un SPAN. La gua SPAN incluye la definicin del
Nmero de SPAN, Temporizador, construccin en lnea (line built out), Entramado y
Codificacin.
Nomenclatura:
SPAN => NUMBER, TIMING, LINE BUILT OUT, FRAMING, CODING
Nmero (NUMBER):
Es el puerto donde el SPAN est conectado. Siendo as el puerto 1 e ms alejado de la baha PCI.
Los nmeros de puerto estn anotados en el soporte del puerto PCI.
Temporizacin (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 temporizacin y el
resto de las tarjetas SPAN lo heredan de este.
Line built out:
Para la mayora de las configuraciones el valor de este parmetro es 0.
Entramado (FRAMING):
Las T1 utilizan un conjunto de entramados para D4 (SF) o ESF. E1 utiliza CAS o CCS.
Codificacin (CODING):
Para las T1 la codificacin puede ser AMI o B8ZS. Para E1 puede ser AMI o HDB3.
Ejemplo tpico en USA:
span => 1,1,0,esf,b8zs
Ejemplo tpico en Europa:
span=>1,1,0,ccs,hdb3
45
Ms ejemplos especficos (Digium):

Lnea E&M
En la configuracin de una lnea E&M, el archivo de configuracin zaptel.conf se ha configurado
para que la tarjeta tome la temporizacin del proveedor. En este caso se usara E&M Wink a la
vez que el archivo de configuracin de zapata.conf reflejar dicha configuracin. Por otro lado
es bueno sealar que Feat_D es un tipo de E&M Wink que acepta DID, pero existen varias
opciones de configuracin 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 temporizacin 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 conmutacin
al que nos estamos conectando como national. Hay varias opciones para los tipos de
conmutacin, incluyendo 5ESS, 4ESS y NI1. As tendramos 23 canales de voz para Asterisk.
PRI T1
/etc/zaptel.conf
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24
group=1
signalling=pri_cpe
switchtype=national
context=incoming
channel=1-23
46
PRI E1
/etc/zaptel.conf
span=1,1,0,ccs,hdb
bchan=1-15,17-31
dchan=16
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 telefona en el mercado. Entre las ms 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 telefona
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 decisin de mercado.
Para la configuracin 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
47
Verificamos el tipo de Kernel que tenemos en nuestro Linux (SMP o No SMP).

Desde la lnea 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 tambin la versin de los mdulos 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
continuacin, de acuerdo con la versin de trixbox:
Wanpipe
Version
Wanpipe Modules
Trixbox CE Zaptel- Headers (Change Log) Wanpipe Utilities RPM RPM (non-SMP)
Wanpipe Modules
RPM(SMP)
2.6.1.13
1.4.11-1
3.2.7.1
wanpipe-util.rpm
wanpipe-module-rpm
2.6.1
1.4.10.1-2
3.2.6
wanpipe-util-rpm
wanpipe-module-rpm
2.6.1.9/10 1.4.11-1
3.2.6
wanpipe-util-rpm
wanpipe-module-rpm
2.6.0.7
2.2.12
3.2.5
3.2.3
wanpipe-util-rpm
wanpipe-util-rpm
wanpipe-module-rpm
wanpipe-mod-rpm wanpipe-mod-smp-rpm
1.4.9.2-8
1.2.22
6.6.3. Equipos Terminales
Aparatos telefnicos y Softphones

A la hora de elaborar una solucin de Telefona IP se deben tomar en consideracin los
terminales. Existen caractersticas importantes que siempre nos ayudaran en la eleccin. Entre
estas se pueden citar:
Cantidad de puertos para interconexin, hay modelos que brindan la capacidad de hacer
troncales con otra terminal (PC).
48
PoE, hay equipos que nativamente soportan la capacidad de recibir energa a travs de la
conexin Ethernet. Esta caracterstica va muy ligada al tipo de plataforma de datos de la que
disponemos (Switches).
Cantidad de lneas, en el primer levantamiento se debe considerar la necesidad de cada

usuario para conocer si los mismos presentan la necesidad de usar ms de una lnea en sus
terminales IP.
Consola de Recepcin, este tipo de aparatos tienen ms capacidad de lneas con el objetivo de
manejar el alto volumen de llamadas entrantes a la recepcin de la empresa. Existen algunos
modelos de aparatos IP que disponen de mdulos 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 telefnicos y Softphones que soportan
esta tecnologa.
Queremos citar los ms comunes segn el protocolo SIP:
49
Softphones SIP ms 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/
50
Telfonos SIP ms 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/
51
6.6.4. Equipos de comunicacin

Adaptadores de Terminal (ATA), son dispositivos que permiten la interaccin de los sistemas IP
con los telfonos o equipos anlogos convencionales.
Se pueden usar como alternativa para el ahorro en las implementaciones de VoIP, sugiriendo
que el cliente conserve sus actuales aparatos telefnicos. 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 integracin siguiendo la confeccin de un plan de marcado entre ambas
centrales.
Figura: Quintum VoIP Gateway
Integracin con otra PBX

Debido al costo de implementacin de las soluciones de Telefona, existe la opcin de crear
hbridos entre Centrales para abaratar los gastos en aparatos telefnicos.
La idea es que la empresa vaya creciendo IP, segn va descartando paulatinamente su vieja
plataforma.
Para este tipo de integraciones existen varias alternativas, pero entre las ms comunes se citan
dos:
52
Interconectar ambas Centrales mediante un mdulo T1, agrupando cada interconexin

mediante un digito (s). As a la hora que un usuario decide marcar una extensin de una Central
a otra tomara un canal del tronco marcando el dgito preestablecido.
Interconectar ambas centrales utilizando un VoIP Gateway como el que ofrece Quintum, este
dispositivo hace la traduccin necesaria para que ambas Centrales se comuniquen sin
inconvenientes. Al igual que la solucin anterior, se trata de agrupar cada extremo de cada
Central en dgitos.
6.6.5. Especificaciones del Servidor:
Especificaciones Recomendadas para el Servidor

Tipo de Procesador
Celeron
Celeron
Pentium 4
Pentium 4
Core2Duo
Core2Duo
Dual Core Xeon
Dual Core Xeon
Quad Core Xeon
Quad Core Xeon
Quad Core Xeon
Quad Core Xeon
RAM # De Llamadas # De Llamadas ACD

256MB
5
2
512MB
8
3
512MB
15
6
1GB
23
9
1GB
35
14
2GB
46
18
1GB
45
25
2GB
60
33
1GB
68
37
2GB
83
45
4GB
98
54
6GB
100+
70+
53
Figura: Diagrama de la composicin del trixbox Appliance:
6.7.
Calidad en el uso de los recursos de voz en la empresa
Da a da 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
realizacin 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 telefona. Para cubrir esta necesidad las empresas recurren a herramientas
como:
Una adecuada confeccin 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 bsico, pero funcional.
54
7. Trixbox
7.1.
Qu es?
trixbox es una solucin de IPPBX basada en software diseada para pequeas y medianas
empresas esencialmente.
trixbox Community Edition (CE), es el software de fuente abierta que se ha convertido en

la ms popular de las plataformas basadas en Asterisk en el mundo. trixbox CE combina lo
mejor de las herramientas de telefona de fuente abierta en un paquete de fcil instalacin,
en conjunto con el panel de trixbox que nos brinda una interfaz Web para configurar y
administrar un completo sistema de Telefona 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 configuracin 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 Pequeas (SOHO). Estas
empresas cuentan con no ms de 10 empleados en su nmina.
Diagrama de ejemplo:
55
7.2.2. Arquitectura de una empresa con usuarios remotos

Este tipo de Arquitectura est orientada regularmente a Oficinas Pequeas (SOHO). Estas
empresas cuentan con no ms de 10 empleados en su nmina, pero a diferencia de la
Arquitectura anterior, este tipo tiene la facilidad de brindar los servicios telefnicos a usuarios
no presentes en la Oficina Principal. Es muy comn ver esta configuracin 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 ms de una localidad. Los servidores trixbox
son enlazados usando el protocolo IAX a travs de Internet u otro medio de conexin. Todos los
telfonos en todas las sucursales son extensiones del mismo sistema, y se realizan llamadas a
travs del proveedor de donde est conectada la Oficina Principal.
56
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

57
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 dejara de funcionar la
comunicacin de extensin a extensin, pero la comunicacin con el exterior no sufrira
inconvenientes.
Contras:
Se incrementan los costos debido a la instalacin de una Central IP por localidad
Se incrementan los costos debido al uso de mltiples proveedores.
58
7.2.5. Arquitectura de una empresa con sucursales, varios proveedores y un

proveedor de VoIP.
Oficina Remota
Conexin
PRI o POTS
trixbox
Servidor VoIP enlazado
Router
Internet
ITP
Proveedor de
troncos SIP o IAX
PSTN
Router
Conexin
PRI o POTS
Switch
Oficina Principal
trixbox
Servidor VoIP
Oficina Con Mltiples Sucursales, Mltiples Proveedores y VoIP
IP Phones
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 dejara de funcionar
la comunicacin de extensin a extensin, pero la comunicacin con el exterior no
sufrira inconvenientes.
59
Proveedor SIP o IAX, usualmente se uso como respaldo a la conexin a la PSTN o como
alternativa para reduccin de costos en llamadas de larga distancia
Contras:
Se incrementan los costos debido a la instalacin de una Central IP por localidad
Se incrementan los costos debido al uso de mltiples 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 administracin Web),
Festival Speech Engine (para el uso de algunas funcionalidades mediante la conversin de texto
a voz)
SugarCRM (la versin Open Source de este magnfico Administrador de la Relacin con el
Cliente,
Cisco XML Services (si usamos telfonos Cisco esta herramienta nos ayuda con el
aprovisionamiento de estos equipos).
Herramientas de instalacin automtica (compuesta por scripts, todas las herramientas y
archivos de configuracin que hacen posible a trixbox su instalacin automtica.
Digium Card auto-config, para sistemas telefnicos que usan las tarjetas de telefona de
Digium, trixbox incluye un script de configuracin automtica que se encarga de la
configuracin inicial de este hardware.
El centro de la fortaleza de trixbox radica en la facilidad para su instalacin, sin dejar de
mencionar su interfaz de configuracin Web.
Para tener el sistema Asterisk arriba y funcionando necesitamos seleccionar una distribucin de
Linux compatible, instalar la distribucin, configurarla con las medidas de seguridad, y luego
instalar Asterisk y configurarlo. Con trixbox tenemos una sola rutina de instalacin, la cual no
solo nos brinda un Sistema Operativo completamente funcional con Asterisk instalado, sino que
tambin nos preinstala todos los dems componentes por nosotros, al mnimo esfuerzo.
60
7.4.
Limitaciones y ventajas en el uso de trixbox como solucin de telefona
La realidad es que se puede hacer casi todo con una instalacin de trixbox en comparacin con
una de Asterisk. La limitacin principal de trixbox, si se le pudiera llamar as, es que FreePBX
requiere una distribucin especfica de los Archivos de configuracin, cualquier cambio hecho a
mano puede ser sobrescrito o puede romper con la estructura del sistema, daando la interfaz
Web.
Otra limitacin podra ser, a la hora de la administracin, que teniendo mltiples sistemas de
trixbox tendramos que autenticarnos en diferentes interfaces. Esto es fcilmente manejable
teniendo nuestra plataforma bien documentada.
Ventajas
Con trixbox contamos con un nmero de aplicaciones personalizadas y creadas especficamente
para trixbox. Estas aplicaciones nos muestran lo poderoso y flexible que trixbox puede ser.
Mucho de este cdigo 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
fcil administracin y configuracin a travs 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 continuacin una seleccin de entre las cientos de soluciones de telefona 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-3D8CCB6A0024CB56/04/hs.xsl/27537.htm
61

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/
62
7.6.
Instalacin y Administracin 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
ms) 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 seleccin 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 informacin de tu
particin para crear una instalacin totalmente fresca.
Una vez cargue el CD vers la informacin de la versin de trixbox que estas instalado. Una vez
ah, debes presionar la tecla de Enter.
Se empezar a instalar trixbox
Durante la instalacin debes elegir lo que conviene de las siguientes opciones:
Idioma; teclado; zona horaria; y una clave para el usuario root.
Luego podrs acceder a tu nueva instalacin a travs de la direccin IP asignada, mediante
cualquier navegador Web. Para verificar la direccin IP puedes usar el comando ifconfig desde
la consola de Linux.
7.6.2. Administracin desde la consola Web:

Lo primero que haremos luego de instalar nuestro .ISO es crear una extensin nueva desde la
interfaz Web:
63
Seleccionamos Extensions desde el men de

configuracin en el margen izquierdo.
Seguido de esto seleccionamos Add
Extension, que es la nica opcin a la
derecha del panel.
Utilizamos el men desplegable para
seleccionar el tipo de extensin que vamos a
crear y seleccionamos SIP.
Presionamos Sumit para
configurar la extensin.
proceder
Una vez en la ventana de configuracin de la

extensin tendremos varias opciones muy
tiles, pero vamos a enfocarnos en las
opciones principales:
User Extension: Es el nmero de extensin
que asignaremos al usuario
Display Name: Nombre de la persona que
usar la extensin.
Secret: Clave usada para autenticar la
extensin.
Voicemail & Directory
Status: Si queremos habilitar o deshabilitar
64
la opcin del uso de Buzn de Voz.

Voicemail Password: Clave asignada para el Buzn de Voz.
Email Address: Direccin de correo donde se enviaran los archivos de voz grabados en el Buzn
de Voz
Pager Email Address: Direccin que recibir una breve notificacin de que tenemos un mensaje
sin escuchar
VM Options: Aqu definimos si la persona puede o no revisar su Buzn de Voz y tambin
especificamos la cantidad de mensajes que puede tener dicha persona.
VM Locater: Otra de las funcionalidades del Buzn de Voz que permite realizar funciones una
vez la persona que llama se encuentra en el men del Buzn de Voz.
Una vez hayamos configurado la extensin procedemos a asignar esta informacin en nuestro
aparato telefnico o Softphone favorito.
7.7.
Confeccin del plan de marcado y enrutamiento de llamadas
Las extensiones en el Plan de Marcado (Dialplan) pueden ser simples nmeros como "412" o
"0". O pueden ser representaciones alfanumricas con nombres como "Juan" o "* A93".
Aunque un telfono tpico no puede marcar una extensin llamada "juan" (aunque algunas si
pueden), a menudo la lgica del Plan de Marcado implica saltar de una extensin 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 estn limitados a simples nmeros de extensiones. Una
simple extensin tambin puede contener patrones de marcado. En el archivo extensions.conf,
una extensin es un patrn si empieza con el smbolo raya abajo (_).
En un patrn 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 parntesis (en este ejemplo 1, 2, 3, 7, 8, 9)
., Comodn, coincide con uno o ms caracteres
!, Comodn, coincide con cero o mas caracteres de inmediato (desde Asterisk 1.2 en adelante)
65
Considere el siguiente contexto:

[routing]
Extensin
Descripcin
_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", enva las llamadas a distintos
servidores de acuerdo a su extensin. Esta empresa ha decidido que todas sus extensiones
telefnicas sean de 4 dgitos. Si un usuario llama a una extensin que comience con 61 o 63,
ser enrutado a la oficina de Dallas, 62 se enrutaria a la oficina de Huntsville, todos los dgitos a
partir de 71, 72, o 73 seran enrutados a la oficina en San Jos, y cualquier dgito a partir de 70,
74, 75, 76, 77, 78 o 79 se enrutara 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
alcanzara extensiones con el patrn XXX al otro extremo. Esto puede ser modificado segn la
necesidad.
Ejemplo:
[Nomenclatura]
Server1: Nombre del Servidor1
Server2: Nombre del Servidor2
Server1IPAddress: Direccin IP del servidor 1
Server2IPAddress: Direccin 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
66
Configuracin del Servidor 1:
67
Configuracin del Servidor 2:
68
Rutas de Entrada
En el panel de configuracin 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 opcin de marcar
segn 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 patrn de marcado que permitir esta ruta.
69
Trunk Secuence: La secuencia que se seguir segn 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 bsicos 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 informacin entre los
puntos de contacto de las diferentes reas especficas que interactan con el cliente como:
ventas, mercadotecnia, atencin 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 integracin con los ms reconocidos sistemas de
Administracin de las Relaciones con el Cliente (CRM).
Uno de los sistemas CRM ms usados en la actualidad es el SugarCRM. Esto se debe a dos
razones principales, a) SugarCRM cuenta con una versin Open Source, o sea que es sostenida
por la comunidad y por ende es gratuita su distribucin; b) En las anteriores versiones de
trixbox CE, SugarCRM vena ya pre instalado y solo se deban hacer los ajustes de
personalizacin de la compaa.
70
Figura: SugarCRM
7.9.
Concepto bsico de Comunicacin Unificada
Se trata de combinar todas las formas de comunicacin empresarial en una solucin unificada.
Entre las ms 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 electrnico o Software de computadora que puede llamar
automticamente a nmeros de telfono previamente programados para comunicar entre
cualesquiera dos puntos de la red telefnica.
71
Una vez que se ha establecido la comunicacin (mediante un intercambio telefnico), 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 comn en los servicios de Telemercadeo ofrecidos
en los Call Contact Centers.
Se puede notar tambin su uso en los sistemas de cobro compulsivo de la Banca.
Figura: VICIDIAL, autodialer usado comnmente con Asterisk
7.11. Concepto de Hosted PBX

En este tipo de sistema las compaas telefnicas le brindan la oportunidad al cliente de tener
un sistema telefnico con todas las funcionalidades de una Central, pero en las facilidades del
proveedor.
72
7.12. Mantenimiento y seguridad en trixbox

Te preguntars que para qu necesitas asegurar tu sistema telefnico. 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 instalacin. Con trixbox, cada
instalacin 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 mayora de las instalaciones se hacen detrs de un Firewall, pero de todas formas
esto no significa que no debemos tomar las precauciones bsicas de lugar con el servidor.
Recuerda que la mayora 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 algn 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 administracin Web de trixbox usaremos los siguientes comandos
desde la consola:
passwd-maint
73

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 administracin Web mientras que la cuenta wwwadmin no te permitir
ver la pestaa Config Edit, donde podemos configurar los archivos actuales de configuracin.
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
74
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
algn cliente de SSH, siga las siguientes instrucciones:
cd /var/www/html/panel
nano op_server.cfg
Vamos a la lnea 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 travs de la interfaz Web haciendo click en
la pestaa 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 pgina. Una vez ah
editamos el archivo op_server.cfg, que aparece como enlace a la izquierda de la pantalla. Cerca
de la lnea 41, cambie la lnea security_code con la nueva clave que desea usar. Finalmente,
hacemos click en el botn 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

75
Cambiando la clave a MySQL

La base de datos de MySQL contiene toda la informacin que necesitamos para mantener
nuestro sistema operando. Lo ms probable es que no queramos a nadie husmeando en esta
informacin; dicho esto podemos determinar que es necesario cambiar la clave antes de poner
nuestro sistema en produccin.
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 opcin
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 ningn tipo de seguridad en nuestra base de
datos, y esto necesita ser corregido inmediatamente.
Para realizar esta modificacin debemos hacer click en el icono del lpiz a la izquierda de
asterisk1.local. Una vez all necesitamos hacer click en el men desplegable Function, y en la
fila password seleccionar la funcin PASSWORD.
76
Necesitamos introducir una nueva clave, y asegurarnos de que no sea sencilla de adivinar.
Luego hacemos click en el botn de Go para salvar los cambios realizados. Ahora, si vamos a la
pestaa de Browse, podremos notar la versin encriptada de la clave que seleccionamos para
ambas entradas de root en la tabla.
Importante: Esta configuracin daar phpMyAdmin, y para solucionarlo necesitamos editar el
archivo de configuracin. Necesitamos, ya sea autenticado localmente o por algn cliente de
SSH, realizar los siguientes cambios:
nano /var/www/html/maint/phpMyAdmin/config.default.php
Una vez ah, editamos la siguiente lnea de cdigo:
$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 direccin IP pblica
Esta dems decir que esta no es una buena prctica, aunque es posible. Si no tenemos buena
experiencia con seguridad en Linux e iptables, entonces esta sera una Crnica de una muerte
anunciada.
Esta posibilidad puede ser agotada si disponemos de un Firewall bien configurado; no hay razn
para tener Asterisk implementado fuera de una red segura.
Actualizar el Sistema Operativo y Asterisk
Para seguridad de nuestro sistema, es una buena prctica mantenerlo actualizado, al igual que
las aplicaciones que lo componen.
En trixbox existe un script que fcilmente realiza esta funcin por ti:
trixbox-update.sh update
Tambin puedes actualizar el Sistema Operativo con el siguiente comando:
yum update
En trixbox tambin contamos con un administrador de mdulos, que te permite actualizar cada
uno de manera individual. Es bueno mencionar que con esta funcionalidad recibes
77
notificaciones en lnea sobre nuevas actualizaciones a tu sistema, y puedes realizar las

actualizaciones de los mdulos 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 mtodo no tan difcil de
seguir para realizar copias de respaldo, el nico ligero inconveniente es que necesitamos un
mtodo para lidiar con los archivos que este respaldo genera.
En la pestaa Tools, prxima a b en el panel de administracin 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, segn nuestros requerimientos.
Sugerimos al menos realizar el respaldo semanal de los archivos de configuracin y el buzn de
voz.
Figura: Programacin de copia de respaldo
78
Un mtodo 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 cmo
modificar el script que realiza la copia de respaldo para que la informacin 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 aadir las lneas 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 lnea del archivo, aadimos el siguiente cdigo:
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 tambin sustituir la

direccin 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.
79
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 lneas de cdigo 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)
80
8. Enlaces de inters
www.asterisk.org
www.trixbox.org
www.voip-info.org
www.voipforo.com
www.asterisktutorials.com
www.asteriskclub.org
81
9. Caso de Estudio:
NetTeam S. A.
La Empresa NetTeam S. A. ha decidido migrar toda su plataforma de telefona a VoIP.
NetTeam S. A. es una empresa lder en servicios tecnolgicos y de Telemercadeo en
diferentes partes del mundo.
Actualmente la empresa cuenta con sucursales en:
Santo Domingo
Estados Unidos
Mxico
Puerto Rico
El nmero de usuarios de telfonos en las diferentes oficinas es de:
Santo Domingo = 150

Estados Unidos = 35
Mxico = 100
Puerto Rico = 70
Actualmente esta compaa cuenta con Centrales Digitales Nortel, sin ningn tipo de
enlace entre ellas.
La compaa ha decidido el cambio a VoIP, porque ha investigado sobre la facilidad de
interconexin que pueden tener entre todas las sucursales, considerando ellos que esto
representara un ahorro en el uso de las comunicaciones internas.
NetTeam S. A. cuenta con un enlace Frame Relay entre todas sus sucursales.
82
10. Laboratorios
Da 1
Estructura de Archivos Linux
Instalar trixbox
Crear extensiones con Buzn de Voz y Follow Me.
Creacin Proyecto/Propuesta VoIP basado en Asterisk (1ra. Parte)
Da 2
Crear un IVR amigable.
Cmo Grabar la Voz para el IVR y los submens.
Crear ruta de entrada al IVR
Crear Ruta de Salida entre Centrales y a la PSTN
Crear Tronco entre dos Centrales Asterisk
Creacin Proyecto/Propuesta VoIP basado en Asterisk (2da. Parte)
Da 3
Crear un Saln 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 espaol.
Creacin Proyecto/Propuesta VoIP basado en Asterisk (Final)
83
Estructura de Archivos en Linux
84
Aadir un Direct Inward Service Access (DISA)
85
Crear un saln de conferencias virtual
86
Crear un grupo de marcado
87
Crear una cola de distribucin de llamadas
88
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 espaol
#cp Net-Security-Sonidos-Espanol-Asterisk-K-rem/es/*
#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/*
Nota: dependiendo de la versin de Asterisk o trixbox que estemos usando puede variar la
estructura de estos archivos.
89
Grabar el mensaje de bienvenida

Para grabar el mensaje de bienvenida tenemos dos opciones:
Opcin 1:
1. Grabar el mensaje desde un terminal con la opcin *77
2. Una vez grabado marcamos la opcin *99 para escucharlo
3. Lo nombramos en la Interfaz Web y presionamos la opcin Save.
Opcin 2:
1. La segunda opcin es grabar el mensaje en un estudio de grabacin o en algn 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.
90
Crear el IVR
91

La Guía Absoluta para Asterisk

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

La Guía Absoluta para Asterisk

Transféré par

Droits d'auteur :

Formats disponibles

La Gua

La Gua Absoluta Para VoIP, Asterisk y trixbox

Convirtiendo de Anlogo a Digital

Sealizacin en redes telefnicas clsicas

Videoconferencia sobre redes paquetes: H.323

Propuesta del IETF para la transmisin de VoIP: SIP

VoIP en la red de transito: MEGACO y MGCP

Redes Mviles de Tercera Generacin: Hacia una Arquitectura ALL-IP

Conclusiones sobre los protocolos de sealizacin

En qu se diferencia la telefona IP de la telefona normal?

Qu compone un paquete de VoIP?

Calidad de Servicio (QoS)

Factores que alteran la calidad de la voz en VoIP

Comandos de verificacin en Linux tiles en Asterisk

Principales Comandos en Asterisk

Archivos de Configuracin y Logs en Asterisk

Por: Radhams Fernndez

La Gua Absoluta Para VoIP, Asterisk y trixbox

Recursos para Ventas

Lista de Verificacin Preventa

Recursos para elaborar el presupuesto de un proyecto

Cmo calcular el Costo Total de Propiedad

Retorno de la Inversin (ROI)

Diseo, implementacin, puesta en marcha y mantenimiento de Asterisk

Especificaciones del Servidor:

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

trixbox - Arquitecturas de Red

Arquitectura de una sola oficina

Arquitectura de una empresa con usuarios remotos

Arquitectura de una empresa con sucursales y un solo proveedor

Arquitectura de una empresa con sucursales y varios proveedores

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

Diferencias entre Asterisk y trixbox

Limitaciones y ventajas en el uso de trixbox como solucin de telefona

Soluciones de Asterisk existentes en el mercado

Instalacin y Administracin de trixbox CE

Por: Radhams Fernndez

La Gua Absoluta Para VoIP, Asterisk y trixbox

Pasos para empezar a trabajar con trixbox

Administracin desde la consola Web:

Confeccin del plan de marcado y enrutamiento de llamadas

Conceptos bsicos de CRM

Concepto bsico de Comunicacin Unificada

Concepto de Hosted PBX

Mantenimiento y seguridad en trixbox

Cambiando las claves que vienen por defecto en trixbox

Copias de Respaldo (Backup)

Por: Radhams Fernndez

La Gua Absoluta Para VoIP, Asterisk y trixbox

Telefona es la ciencia de convertir sonido en seales elctricas y transmitirlo entre puntos

El telfono es un dispositivo de telecomunicacin diseado para transmitir seales acsticas

Quin invent el Telfono?

1.1. Qu es una PBX?

Figura: Central Telefnica Antigua

Por: Radhams Fernndez

La Gua Absoluta Para VoIP, Asterisk y trixbox

1.2. Convirtiendo de Anlogo a Digital

Figura: Conversin de Anlogo a PCM

La Gua Absoluta Para VoIP, Asterisk y trixbox

Figura: Conversin de anlogo a Digital

1.3. Protocolos de Sealizacin

La Gua Absoluta Para VoIP, Asterisk y trixbox

1.3.1. Sealizacin en redes telefnicas clsicas