Leer más - Fundación Universitaria Konrad Lorenz

IDENTIFICACION DE LAS FUNCIONALIDADES, POTENCIALIDADES Y
REQUERIMIENTOS TECNICOS PARA LA IMPLEMENTACION DE
ASTERISK.
ING. GUSTAVO ADOLFO HERAZO PEREZ
KONRAD LORENZ - FUNDACION UNIVERSITARIA
FACULTAD DE MATEMÁTICAS E INGENIERÍAS
BOGOTÁ D.C.
Identificación de las Funcionalidades, Potencialidades y Requerimientos
Técnicos para la Implementación de Asterisk.
GRUPO DE INVESTIGACIÓN TELEMENTE
Línea de Investigación en Telecomunicaciones-TELEMENTE
ING. GUSTAVO ADOLFO HERAZO PEREZ
KONRAD LORENZ- FUNDACION UNIVERSITARIA
FACULTAD DE MATEMATICAS E INGENIERÍAS
PROGRAMA DE INGENIERÍA DE SISTEMAS
2
TABLA DE CONTENIDO
INDICE DE TABLAS……………………………………………………………………. 4
INDICE DE FIGURAS…………………………………………………………………… 5
LISTA DE ANEXOS………………………………………………………………………6
GLOSARIO DE TERMINOS……………………………………………………………. 7
INTRODUCCION………………………………………………………………………… 8
1. ASPECTOS DE LA INVESTIGACION
1.1. Descripción del problema……………………………………………………….. 9
1.2. Justificación...................................................................................................9
1.3. Delimitación
1.3.1. Espacial……………………………………………………………………….10
1.3.2. Cronológica…………………………………………………………………...11
1.4
Objetivos
1.4.1. General……………………………………………………………………12
1.4.2. Específicos………………………………………………………………..12
2. BASES CONCEPTUALES
2.1. Antecedentes
2.1.1. Antecedentes Históricos………………………………………………………..13
2.2.
Marco Teorico…………………………………………………………………………….15
2.2.1. Iniciando con Asterisk……………………………………………………………………17
2.2.2. Asterisk con arquitectura de Sistemas Pequeños……………………………………19
2.2.3. Asterisk con arquitectura de Sistemas Medianos…………………………………….19
2.2.4. Asterisk con arquitectura de Sistemas Grandes…………………………………….. 20
2.2.5. Protocolo de Señalizacion y Transporte de Voz IP en Asterisk……………………..20
2.2.6. La señalización como técnica utilizada en telefonía Empresarial…………………. 21
2.2.7. Funciones de Señalización……………………………………………………………...21
2.2.8. Funciones de detección del equipo colgado o descolgado…………………………22
2.2.9. Proceso de Supervisión de comienzo de la marcación………………………………22
2.2.10. Proceso de Transmisión de Dígitos y marcación por pulsos………………………..23
2.2.11. Sistemas de Marcación por Tonos……………………………………………………..24
2.3.
Consideraciones técnicas sobre la telefonia
Por el Protocolo Internet (IP)
2.3.1. Elementos técnicos asociados………………………………………………………… 24
2.4.
Supervision de telefonia IP sobre Asterisk
Números de teléfonos asociados…………………………………………………….. 32
Tonos de progreso de llamadas………………………………………………………. 33
2.4.3. Manejo y gestión de troncales para entornos Asterisk…………………………….. 33
2.5.
Inicio de Bucle…………………………………………………………………………….35
2.6.
Circuito Libre……………………………………………………………………………...36
2.4.1.
2.4.2.
2.7.
Definicion y medida de la voz sobre Asterisk……………………………….36
2.8.
2.9.
2.9.1.
2.9.2.
2.10.
Variables que afectan la calidad de la voz……………………………………………37
Control de Ruido de Fondo en Asterisk……………………………………………… 38
Recorte de Amplitud……………………………………………………………………. 38
Distorsion de Cuantificacion……………………………………………………………38
Medida Subjetiva de la calidad de la conversación…………………………………41
3
2.11. Protocolo de Control Rapido……………………………………………………….. 42
2.12. Protocolo de Control Rápido como elemento diferenciador en Telefonía IP….. 44
2.13. Uso de Gateways en Asterisk……………………………………………………… 45
2.14. Uso de Gatekeeper………………………………………………………………….. 46
2.15. Direccionamiento……………………………………………………………………. 48
2.16. Direcciones de Red e identificadores TSAP……………………………………. 49
2.17. Alias H323…………………………………………………………………………… 50
2.18. Convenciones de alias para la comunicación interzonal……………………… 51
2.19. Registros TXT………………………………………………………………………. 51
2.20. Control de llamadas en Asterisk con H.225.0………………………………….. 52
2.21. Control de llamadas en Asterisk con Medios H.245…………………………… 54
2.22. Protocolo SIP en Asterisk…………………………………………………………. 55
2.23. Atributos del protocolo SIP………………………………………………………… 56
2.24. Componentes del Sistema………………………………………………………… 57
2.25. Direccionamiento de SIP………………………………………………………….. 58
2.26. Sintaxis de la Dirección SIP………………………………………………………. 59
2.27. Método de registro SIP……………………………………………………………. 60
2.28. Cabeceras SIP……………………………………………………………………… 62
2.29. MGCP (Media Gateway Controller Protocol)…………………………………… 66
3. RESULTADOS OBTENIDOS
3.1.
Plataforma de Sistema Operativo…………..……………………………………. 67
3.2.
Inicio de la descarga y ajustes previos de instalación de Asterisk …………. 67
3.3.
Estado del Arte de las funcionalidades frente a diversos proveedores……. 70
3.4.
Analisis de funcionalidades con Wireshark
3.4.1. Funcionalidades SIP con Wireshark……………………………………………. 71
3.4.2. Funcionalidades H323 con wireShark………………………………………….. 76
3.4.3. Consolidado de funcionalidades y potencialidades………………………….. 77
4. CONCLUSIONES Y RECOMENDACIONES……………………………………… 78
5. BIBLIOGRAFIA………………………………………………………………………… 80
4
INDICE DE TABLAS
Tabla 1. Cronograma de Actividades………………………………………………… 12
Tabla.2. Frecuencias DTMF asignadas a un teclado de teléfono estándar…….. 23
Tabla 3. Códigos de respuesta SIP……..………………………………………… 63
Tabla 4. Respuestas más comunes del protocolo SIP…………………………… 66
Tabla 5. Comparativo entre plataformas Asterisk, Avaya y Cisco………………. 71
Tabla 6. Directorios y archives que se requieren en Asterisk……………………. 72
Tabla 7. Estadística para protocolo RTP prueba llamada IAX2 a H.323……….. 77
Tabla 8. Estadística consolidada de H323, IAX, SIP e IAX……………………… 77
5
INDICE DE FIGURAS
Figura No. 1 Modelo inicial de la primera central telefónica análoga………….. 15
Figura No. 2 Modelo hibrido de central telefónica análoga y digital…………… 17
Figura No. 3 Modelo integral y total de telefonía digital………………………
18
Figura 4. Esquema de interconectividad de Servidor a Servidor
En la FUKL (Lab. 302)………………………………………………………………. 29
Figura 5. Laboratorio dedicado al Proyecto telefonía IP-Asterisk
Salón 302 de la FUKL………………………………………………………………… 29
Figura 6. Laboratorio dedicado al Proyecto telefonía IP-Asterisk
Salón 302 de la FUKL…………………………………………………………………. 30
Figura 7. Esquema de interconectividad Utilizando adaptadores ATA………… 31
Figura 8. Esquema de interconectividad Utilizando Telefonía IP
A Teléfono a teléfono………………………………………………………………….. 32
Figura 9. Esquema cuando el recorte de amplitud cambia la forma de la señal.. 58
Figura 10. Fenómeno de Eco presentado en Asterisk……………………………. 42
Figura 11. Estructura lógica de un Gateway en H323 sobre Asterisk…………… 47
Figura 12. Intercambio entre puntos finales a través de H225 en Asterisk…….. 55
Figura 13. Señalización bajo el protocolo SIP……………………………………… 76
6
LISTA DE ANEXOS
Anexo 1. Consolidado de Requerimientos y parámetros de instalación
Anexo 2. Configuracion Servidor Asterisk
Anexo 3. Documentacion Archivo Users
Anexo 4. Configuracion Archivo start
Anexo 5. Configuracion app_conference
Anexo 6. Flags de eventos de Asterisk
Anexo 7. Configuracion Archivo SIP
Anxo 8. Configuracion Archivo IAX
Anexo 9. Configuracion Archivo H323
7
GLOSARIO DE TERMINOS
ACD (Automatic Call Distributor): Distribuidor Automático de llamadas. Esta entidad
representa el sistema telefónico cuya función es poder manejar todas las llamadas
entrantes o por el contrario las llamadas salientes. Adicionalmente interactúa con la base
de datos para tomar la acción pertinente cuando una llamada entrante se realiza. También
puede reproducir grabaciones y grabar respuestas.
CODEC. Programas y/o algoritmos que sirven para compresión y descompresión de la
voz. Es Utilizado en entornos multimedia como por ejemplo audio y video.
E1. Representa el estándar de conexión de las línea telefónicas y trabajan para el envío
de datos hasta 1920 Mbps. Este enlace posee 30 canales de datos de 64 Kbps y 2
canales B de señalización.
SIP (Protocolo de inicio de sesión). Este protocolo es utilizado en asterisk para
señalización y permite toda la gestión (creación. Modificación y control de sesiones de las
llamadas).
H323. Este estándar de la ITU se caracteriza para iniciar sesiones de comunicación en
videoconferencia en entornos de telefonía IP. Este protocolo no garantiza QoS y es
independiente de la topología de la red.
PBX (Private Branch Exchage).
conmutar todo el tráfico de VoIP.
Corresponde a una centralita IP, cuya función es
PLANTA IP. Se define como un Gateway que es el encargado de la calidad de las
llamadas, reemplazando a lo que hoy en día se conoce como la plata telefónica tradicional
IAX (Inter-Asterisk eXchange protocol): Herramienta de asterisk para controlar las
conexiones entre elementos de VoIP, servidor a servidor y servidor-cliente.
RTCP. Es un protocolo de comunicación que proporciona información de control que está
asociado con un flujo de datos.
SDP. Protocolo de descripción de sesión. Formato para describir parámetros de
inicialización de Streaming
Streaming Media. Tecnología que permite almacenar en un búfer lo que se escucha o ve
en una comunicación.
8
INTRODUCCIÓN
La Fundación Universitaria Konrad Lorenz, en su proceso de formación investigativa y con
miras a fortalecer la línea TELEMENTE, se crea el Semillero en Investigación en
TELEFONIA IP BAJO ASTERISK.
Actualmente con el aumento y la necesidad de las comunicaciones basadas en IP, se
hace indispensable utilizar el esquema de interconexión que nos brinda la red de redes
“Internet” y por ello las redes de telefonía están encaminadas hacia la convergencia e
integración de voz, datos y video.
Las redes de comunicación actuales en telefonía, se caracterizan por tener un
funcionamiento complejo que implica la interacción de muchos sistemas que en muchos
casos no ofrecen ventajas competitivas en la nueva era de la Tecnologías de Información
y comunicaciones. Gracias a la convergencia de los servicios de redes, la Telefonía IP
convierte un PC o cualquier laptop en un teléfono heredando todas las ganancias y
ventajas del protocolo IP y su inclusión en nuevos mercados competitivos que ofrecen
ahorro financiero, disminución de tiempo y una gran gestión en las pequeñas, medianas y
grandes empresas.
La Facultad ofrece este semillero con la oportunidad de que los estudiantes participen
activamente en investigación, orientada a lograr y establecer las funcionalidades,
potencialidades y requerimientos técnicos que se necesiten para implementar este tipo
de necesidades en pequeñas y medianas empresas.
La Investigación se hará directamente en las instalaciones de la Universidad, proyectando
diversas herramientas que permitan establecer un estado del arte,
para lograr las
ventajas y desventajas de las diferentes versiones tanto de los sistemas operativos
utilizados y los componentes asterisk que se trabajarán.
La primera etapa del proyecto corresponderá al levantamiento de información, políticas y
elementos que se involucrarán en la instalación de los diversos sistemas operativos y
elementos de asterisk utilizados.
9
CAPITULO 1
ASPECTOS DE LA INVESTIGACION
1.1.
DESCRIPCION DEL PROBLEMA
Actualmente los modelos recursivos en telefonía IP sobre asterisk que se
encuentran en el mercado, algunas veces son poco comprensibles y no logran
establecer políticas claras de funcionamiento, requerimientos claros y precisos y
sobre todo que enfoquen funcionalidades asociadas a los tipos de empresas, ya
sean pequeñas, medianas o grandes y que enfaticen los mejores componentes de
acuerdo a sus aéreas de negocios.
La fundación Universitaria Konrad Lorenz y en especial el Programa de Ingeniería
de Sistemas pretender llevar a cabo fortalecer el espíritu investigativo de los
estudiantes a partir de la creación de grupos de trabajo que participen activamente
como semillero de investigación en el área de Telefonía IP con asterisk, con miras
a
la
concientización
de
evaluar
las
funcionalidades,
potencialidades
y
requerimientos técnicos en la toma de decisiones para la implantación de una
solución Asterisk en un mercado empresarial pequeño o mediano, y que cuyos
logros se reflejen más adelante en consultorías y acompañamientos a este tipo de
mercado para que se fortalezca la inclusión de este tipo de tecnologías como
elemento competitivo en la sociedad de las comunicaciones y la era de la
tecnologías de información y comunicaciones.
1.2.
JUSTIFICACION
La nueva era de la Sociedad de la información pretender la convergencia total de
los servicios informáticos y de telecomunicaciones, por ende la tecnología de
Telefonía IP, busca la intersección y/o unión de de dos mundos históricamente
separados uno el de transmisión de voz y el otro el de transmisión de datos.
Dentro de los marcos incidentes y de gran impacto tecnológico, está el
resurgimiento de la Telefonía IP, ya que en el pasado este servicio carecía de
parámetros
de Qos (Quality of Service) y de niveles de seguridad que no
aportaban un elemento garantizado de confianza.
10
Sin embargo gracias a los adelantos de la Red Digital de Servicios Integrados y el
surgimiento y estandarización de la Banda ancha, este campo ha adoptado un
resurgir en los proyectos de investigación a escala nacional y mundial.
En el marco de la globalización y convergencia del área de las telecomunicaciones
se hace necesario y vital que las organizaciones incurran en este modelo de
integración y de fusión de tecnologías, y que con mayor razón la era de Internet 2,
recomienda este tipo de tecnologías como elemento diferencial para ahorrar
costos, integrar y armonizar la era de la sociedad de la información y la validación
y fluctuación de la web 3.0 y 4.0 en lo concerniente al cambio del paradigma de la
sociedad de base y la Web social como apoyo al campo de las investigaciones.
Por ello, la Fundación Universitaria Konrad Lorenz es participe de este campo y
con miras a establecer el impacto que pueda generar estos modelos integradores
de telefonía en aquellos sectores empresariales de pequeña y mediana empresa,
para que incursionen como elementos fundamentales e integradores en la Nueva
era de la Sociedad del conocimiento.
Se hace evidente que en un futuro no muy lejano desaparecerán por completo las
líneas telefónicas convencionales que se utilizan en nuestra vida cotidiana y por
ende estamos a la gran puerta del mercado competitivo y de gran demanda de la
Telefonía IP.
Para finalizar este Proyecto permitirá la comunidad universitaria estudiantil
integrarse a Grupos de estudios, crear conciencia de investigación y participar en
compañía de Docentes investigadores a canalizar los conocimientos en busca de
nuevas soluciones y aportes a la comunidad universitaria.
1.3.
DELIMITACION DE LA INVESTIGACION
1.3.1. Delimitación Espacial
El Presente Proyecto de Investigación se realiza en la Fundación Universitaria
Konrad Lorenz y se contará con la disponibilidad del Laboratorio 302 para los
montajes respectivos, ubicados en el tercer piso de la Institución.
Se cuenta con dos equipos multinúcleo con dos Gigas en RAM, conectados
directamente a la Red de la Universidad y con direcciones IP estáticas y acceso a
Internet.
11
1.3.2. Delimitación Cronológica
El proyecto se llevará a cabo siguiendo el cronograma que se muestra a
continuación:
Meses
1.1.1 Actividad a
Enero-Febrero
Marzo
Abril
Mayo-Junio
desarrollar
Levantamiento de Información inicial.
Instalación de las diferentes
distribuciones de Linux en la sala de
laboratorio del tercer piso de la FUKL
y gestión de los elementos
necesarios para esta primera
actividad.
Revisión de la Bibliográfia disponible
Exploración inicial de las
compatibilidades y modelos óptimos
de las distribuciones Linux con las
diferentes versiones de Asterisk.
Identificación de los requerimientos
técnicos para la realización de un
plan de pruebas completo y básico
sobre Asterisk
Realización del plan de pruebas
básicas.
Documentación del proyecto
Tabla 1. Cronograma de Actividades
1.4.
OBJETIVOS DEL PROYECTO
1.4.1. Objetivo General
Identificar las funcionalidades, potencialidades y requerimientos técnicos para la
implementación de la herramienta del Software de ASTERISK bajo sistema
operativo Linux
1.4.2. Objetivos Específicos
 Realizar un levantamiento de información acerca de las distribuciones Linux
que sean más consistentes en la correlación con el esquema de trabajo de
asterisk.
12
 Determinar el nivel óptimo de gestión, de operatividad, de integridad y de
coexistencia entre los componentes básicos asterisk y la distribución Linux
que se adopte.
 Realizar
un
estado
del
arte
que
determine
las
funcionalidades,
potencialidades y requerimientos técnicos de las diferentes versiones de
asterisk en modelos de pequeñas y medianas empresas.
 Elaboración de anexos donde se plasme cada uno de los archivos de
instalación, requerimientos técnicos y las diferentes pruebas básicas de
asterisk tomando como entorno un diseño microempresarial.
 Elaboración de un artículo sobre el tema de investigación.
13
CAPITULO 2
MARCO TEORICO Y ESTADO DEL ARTE
2.1.
ANTECEDENTES
2.1.1. Antecedentes Históricos
El mundo de la telefonía desde sus orígenes ha pasado por innumerables etapas o
generaciones que visualizan la evolución y progreso de las investigaciones en esta
área del conocimiento. Por consiguiente se da a conocer en resumen un poco de
esos cambios vertiginosos hasta llegar a la era actual.
1era. Generación: Corresponde al inicio de los primeros descubrimientos en
telefonía y para ello se utilizo el uso de telégrafos.
Los telégrafos inicialmente fueron creados como dispositivos o aparatos ubicados
preferiblemente en unidades de mando o en buques de guerra para que pudieran
transmitir ciertas señales a distancia. También se le conoce como semáforo y
aunque hoy en día se conocen innumerables tipos de telégrafos en todos los
países del mundo, la forma de operación y control es idéntica en todos. Su diseño
básico consiste en colocar el telégrafo en un sitio totalmente visible del próximo
telégrafo a transmitir para que los mensajes enviados no tengan ningún problema
de comunicación y así sucesivamente una detrás de otro, logrando abarcar
grandes distancias.
2da. Generación: Es conocida como la era de telefonía analógica de switches
manuales, desarrollada por el Señor Alexander Graham Bell en donde se hace
posible y efectiva la patente del primer teléfono y la primera central telefónica del
mundo, esto ocurre en los años de 1876 y 77. (Ver figura 1)
14
Figura No. 1 Modelo inicial de la primera central telefónica análoga
Luego vino la telefonía analógica de switch mecánico1, en donde los procesos de
conmutación se realizaban de forma mecánica y posteriormente entro la era de la
telefonía análoga pero los procesos de conmutación ya eran automáticos.
Terminando esta fase se crea una ruptura total en la era análoga y entra la Red
pública de telefonía conmutada digital, seguida por la telefonía Móvil celular y la
ultima que se denomina Telefonía Sobre Protocolo IP.
Determinando antecedentes históricos se sabe que en Colombia especialmente en
la Universidad de San Buenaventura en la Bogotá en el año 1999 se empezaron
los primeros avances en telefonía IP2.
1
Dispositivo de red que filtra, envía e inunda de frames en base a la dirección de destino de cada frame. El switch opera en la capa de
enlace de datos del modelo OSI. 2.) Término general que se aplica a un dispositivo electrónico o mecánico que permite establecer una
conexión cuando resulte necesario y terminarla cuando ya no hay sesión alguna que soporta
2
La Telefonía IP es una solución tecnológica que sirve para transmitir comunicaciones de voz sobre una red de datos basada en el estándar
IP. Con la solución de Telefonía IP, la organización reduce costos integrando sus aplicaciones de voz y datos sobre una única plataforma de
Red. Esta solución permite elevar la productividad, reducir costos operativos de la empresa mediante la convergencia de las comunicaciones;
además de escalar las soluciones de acuerdo a las necesidades de las empresas, las cuales pueden ser corporativas, medianas o pequeñas.
15
2.2.
MARCO TEORICO
Una increíble revolución está en marcha. Ha sido un largo tiempo en llegar, pero ahora
que ha comenzado, no se detiene. La industria de telecomunicaciones está siendo
alimentada por una fuente privada (PBX) llamado Asterisk. El mundo de las
Telecomunicaciones esta enfocándose por la revolución de código abierto.
Anteriormente los sistemas propietarios construían sistemas de telefonía supremamente
costosos e
incompatibles, con rutinas
muy complicadas, con códigos obsoletos
y
asociados con hardware obsoleto. Como ejemplo, Nortel Business Communications
Manager kludges basado en VxWorks, sistema que trabaja en un conmutador telefónico,
bajo un PC de 700-MHz. Esta arquitectura se podría obtener en un rango entre 5 y 15 mil
dólares, no incluyendo los teléfonos. [5]
El futuro de la tecnología telefónica va a desprenderse del imperio de las normas y la era
de la libertad, para ello asterisk converge hacia este tipo de soluciones.
Nunca en la historia de las telecomunicaciones había existido un sistema adecuado a las
necesidades telefónicas y que resolviera de manera eficaz las necesidades de negocios
de las medianas y pequeñas empresas a unos costos mínimos.
Linux como sistema operativo base da la alternativas de acoplamiento y cohesión
perfectas para el maravillo mundo de asterisk3.
No podríamos estar hablando de la libertad de construir nuestra propia red telefónica sin
la existencia de los estándares abiertos y el código libre. Los estándares abiertos permiten
que
cualquiera pueda implementar un sistema con garantías de interoperabilidad.
Gracias a esa interoperabilidad de nuestro diseño no sólo podemos crear nuestra red
telefónica sino que, además, podemos conectarla a la red telefónica global. Con el código
libre podemos aprender de experiencias parecidas, integrar sus soluciones y compartir
nuestros propios resultados con los demás.
3
Asterisk es un proyecto de código libre
http://www.asteriskdocs.org/modules/tinycontent/index.php?id=10
16
Una de las primeras preguntas que merece una respuesta es: ¿por qué deberías crear tu
propia infraestructura de voz sobre IP y no seguir usando servicios gratuitos como Skype?
La respuesta es simple: sostenibilidad y flexibilidad. Los servicios gratuitos te pueden
Solucionar una necesidad a corto plazo pero nunca garantizar tu independencia o el
control de tu propio proceso de aprendizaje y desarrollo. No se trata de una cuestión
puramente técnica. El problema no es decidir cuál es la mejor de las tecnologías sino cuál
es la que permite que las comunidades sean dueñas de su propio desarrollo y que
puedan adaptarla a sus propias necesidades [1].
Dentro de los marcos de diseño, asterisk provee múltiples variedades de diseño en los
cuales se generalizan como se muestran a continuación:
Modelo 1: Este modelo permite convivir las arquitecturas de telefonía tradicional y la
telefonía IP.
Figura No. 2 Modelo hibrido de central telefónica análoga y digital
Modelo 2. Adaptación total e integral de telefonía IP.
17
Figura No. 3 Modelo integral y total de telefonía digital
2.2.1 Iniciando con Asterisk
En términos de las necesidades de recursos, las necesidades de Asterisk son similares a
las de un embebido en tiempo real aplicación. Esto se debe en gran parte a su necesidad
de tener prioridad el acceso al procesador y al sistema de buses de control del sistema
operativo. Por lo tanto, es imperativo que todas las funciones en el sistema no están
directamente relacionados con las tareas de procesamiento de Asterisk a baja prioridad.
En sistemas más pequeños, esto podría no ser tanto un problema. Sin embargo, en
sistemas de alta capacidad, el rendimiento deficiencias se manifiestan como problemas
de calidad de audio para los usuarios, dando como respuesta a menudo problemas de
eco y estática, Los síntomas se asemejan a los experimentados en un teléfono celular
cuando se sale del radio de alcance de la señal. Por tanto a medida que la carga
aumenta, el sistema tendrá dificultades para mantener el aumento de las conexiones.
Para un PBX4, esta situación es poco menos que desastrosa y se hace necesario prestar
atención cuidadosa a los requisitos iníciales de la plataforma durante el proceso de
selección.
La siguiente tabla enumera algunas directrices básicas que se deberían tener en cuenta
cuando se defina la planificación del sistema.
4
PBX: (Central Telefónica Digital). Sistema telefónico dentro de una organización que maneja las llamadas entre sus usuarios en líneas
locales mientras permite que entre todos los usuarios compartan un número determinado de líneas telefónicas externas.
18
Propósito Empresarial
Sistema de pruebas (Tipo1)
Número de Canales
Mínimo Recomendado
No más de 5 conexiones
400-MHz x86, 256 MB RAM
5 a 10 conexiones
1-GHz x86, 512 MB RAM
Pequeña Empresa
Hasta 15 conexiones
3-GHz x86, 1 GB RAM
Mediana Empresa
Más de 15 extensiones
Dual
5
Sistema SOHO (Small OfficeHome Office)-Pequeña oficina
en casa
Core,
Posibilidad
de
múltiples servidores en una
arquitectura distribuida-
Por otro lado a la hora de seleccionar el hardware de una instalación Asterisk se debe
tener en cuenta cómo el sistema podría crecer? Esta no es una pregunta fácil de
responder, porque la manera en que el sistema es utilizado desempeñará un papel muy
importante en los recursos que se consumen y la relación a futuro en lo concerniente al
trafico esperado en función de sus extensiones es un paso difícil de lograr. Por tanto se
tendrá que comprender cómo Asterisk utiliza el sistema con el fin de hacer decisiones
inteligentes acerca de qué tipo de recursos a futuros se necesitarán. Existen varios
factores que se tendrán que considerar incluyendo:
El número máximo de conexiones simultáneas que el sistema trabajará, producirá cada
conexión
se
incrementará
la
carga
de
trabajo
a
nivel
de
procesador.
El porcentaje de tráfico que requiere de un uso intensivo del procesador de señales
digitales de procesamiento (DSP) de los códecs de compresión (tales como G.7296 y
GSM) se hará evidente en el aumento del tráfico.
El trabajo del DSP [9], [12] de Asterisk puede tener un impacto sorprendente
sobre el número de llamadas simultáneas, que genera. Un sistema que puede manejar
alrededor de 50 llamadas simultáneas G.71177, pueden ser críticos en el caso de una
5
SOHO: Acrónimo de Small Office-Home Office (Pequeña Oficina-Oficina en Casa). Ues un término que se aplica para denominar a los
aparatos destinados a un uso profesional o semiprofesional pero que, a diferencia de otros modelos, no están pensados para asumir un gran
volumen de trabajo. http://www.mastermagazine.info/termino/6753.php
6
G.729 es un algoritmo de compresión de datos de audio para voz que comprime audio de voz en trozos de 10 milisegundos. La música o los
tonos tales como los tonos de DTMF o de fax no pueden ser transportados confiablemente con este códec, y utilizar así G.711 o métodos de
señalización fuera de banda para transportar esas señales. http://es.wikipedia.org/wiki/G.729
7
G.711 es un estándar para representar señales de audio con frecuencias de la voz humana, mediante muestras comprimidas de una señal
de audio digital con una tasa de muestreo de 8000 muestras por segundo. El codificador G.711 proporcionará un flujo de datos de 64 kbit/s.
http://es.wikipedia.org/wiki/G.711
19
solicitud
Las
de
conferencia
conferencias
junto
requieren
a
del
10
canales
sistema
G.729
una
comprimido.
codificación
y
una combinación de entrada de audio en múltiples flujos salientes. Mezcla múltiples flujos
de audio en tiempo casi real y puede colocar una enorme carga sobre la CPU y producir
la cancelación de eco.
2.2.2. Asterisk con arquitectura de Sistemas pequeños
Se entienden como sistemas pequeños aquellas arquitecturas empresariales que tienen
hasta 10 teléfonos, éstas no son inmunes a los requisitos de Asterisk, pero la carga estará
dada dentro de las capacidades de un procesador moderno. Si usted está construyendo
un pequeño sistema de componentes en asterisk, su gestión a nivel de sistema operativo
en Linux no requiere de altos controles de rendimiento para ajustar su carga a nivel de
tráfico.
Si se está configurando un sistema Asterisk para
fines de aprendizaje y
academia, se podrá para construir una plataforma completamente sencilla, utilizando baja
potencia de CPU. Los procesadores más utilizados en el mercado están los de 433 MHz a
700 MHz, los procesadores Celeron en donde la carga de trabajo de estos sistemas suele
ser mínima. [13]
2.2.3 Asterisk con arquitectura de Sistemas Medianos
Los sistemas de tamaño mediano convergen de 10 a 50 teléfonos.
Las políticas y
consideraciones de adecuar el rendimiento será más difícil de resolver. Generalmente,
estos sistemas se desplegado en uno o dos servidores y, por tanto, cada máquina será
necesaria para manejar más de una tarea específica. Como aumentar las cargas y definir
los límites de la plataforma. [10], [11]
Los usuarios podrán comenzar a percibir los problemas de calidad sin darse cuenta de
que el sistema no está defectuoso.
Estos problemas serán tendrán progresivamente a medida que crece la convergencia de
la red y su
carga sobre el sistema irá aumentando y produciendo degradación del
servidor. Es fundamental que el problema del rendimiento se identifique y se atienden las
necesidades a tiempo, antes de que sean percibidas por los usuarios.
20
2.2.4 Asterisk con arquitectura de Sistemas Grandes
Los sistemas grandes corresponden a más de 50 usuarios, se puede distribuir a través de
múltiples procesadores y, por tanto, el rendimiento causa preocupaciones de alto nivel y
se pueden gestionar a través de la adición de máquinas y/o servidores. Una arquitectura
asterisk se considera de ámbito grande cuando definimos de 500 a más de 1000 usuarios.
La construcción de un gran sistema requiere un nivel avanzado de conocimientos en
diferentes disciplinas.
2.2.5 Protocolo de serializaciòn y Transporte de Voz IP en Asterisk
Los protocolos asociados a VolP se dividen en dos grupos: los que soportan el transporte
de la ruta de audio, y aquellos que soportan la señalización de llamada y las funciones de
control. Los protocolos que administran el transporte de la ruta de audio ofrecen
información de temporización para asegurar una reproducción de audio consistente en el
lado receptor, así como una retroalimentación del rendimiento de la calidad del servicio
(QoS) con respecto a la red subyacente. La señalización de llamada y las funciones de
control proporcionan la configuración y la cancelación de la llamada, direccionamiento y
enrutamiento, servicios de información adicionales y métodos para trabajar con otros tipos
de señalización.
En este esquema se encuentra el Protocolo de transporte rápido (RTF) [3],[4] y el
Protocolo de control RTF (RTCP, RTF Control Protocol), como protocolos de ruta de audio
VolP universalmente aceptados. Con el fin de proporcionar una revisión del H.323, del
Protocolo de inicio de sesión (SIP, Session Initiation Protocol) [7], [8] y de los protocolos
de señalización H.248/Megaco/Media Gateway Control Protocol (MGCP), también se
analizará estos protocolos que se complementan entre ellos. [1], [2]
2.2.6 La señalización como técnica utilizada en telefonía Empresarial
En un entorno empresarial típico, el CPE es un PBX (Intercambio privado de ramas) que
conecta a los usuarios con la Red pública de telefonía conmutada (PSTN) a través de la
CO. El CPE también puede ser un sencillo teléfono, como el existente en el hogar, o un
equipo un poco más complejo, como el existente en una pequeña oficina.
21
En algunos casos, la CO no está implicada en la señalización telefónica, excepto para
proporcionar la infraestructura de transmisión (por ejemplo, T-l/E-1) entre los emplazamientos de los clientes. En estos casos, los switches telefónicos situados en cada uno de
los emplazamientos del cliente se relacionan con los demás a través de los switches
situados en la CO. La señalización troncal utilizada en estas líneas punto a punto o
troncales también caer dentro de este ámbito [3].
2.2.7. Funciones de Señalización
Aparte de la transmisión de una ruta de audio en ambas direcciones, existe un conjunto
de importantes funciones de señalización que deben ser proporcionadas por una línea o
un troncal de telefonía. Una troncal se refiere a una conexión entre switches telefónicos
(por ejemplo, las PBX, los sistemas de clave o las CO) y una línea se refiere a una
conexión entre un teléfono y un switch telefónico. Los siguientes representan los tipos de
señalización:
•
Detección de equipo colgado-descolgado (on-hook/off-hook).

Supervisión de comienzo de marcación.
•
Transmisión de dígitos.
•
Identificación de número.
•
Tonos de progresión de la llamada.
•
Supervisión de respuesta y desconexión.
Además de las funciones de señalización fundamentales descritas aquí, son necesarios
otros tipos de señalización para posibilitar las opciones de llamada avanzadas.
2.2.8. Funciones de detección del equipo colgado o descolgado
Como su nombre implica la señalización on-hook/off-hook (colgado-descolgado) requiere
solo dos estados: on-hook/off-hook. El teléfono está colgado cuando la parte del microteléfono (micrófono y altavoz) está descansando sobre la base del teléfono. El teléfono
esta descolgado cuando el micro-teléfono se alza de la base del teléfono para realizar o
recibir una llamada. Los puntos finales troncales del teléfono deben permitir la transmisión
22
y recepción de señales que indican los estados on-hook/off-hook. El método de
señalización de estos dos estados difiere entre los tipos de enlaces troncales.
La serializarían on-hook/off-hook es obligatoria para todos los tipos de troncales excepto
para las conexiones troncales permanentes [4], [5]. (Por ejemplo, conexiones always-on o
hoot-n-holler). Los enlaces troncales normalmente se implementan configurando la
interfaz troncal a un estado off-hook.
2.2.9. Proceso de Supervisión de comienzo de la marcación
La supervisión de comienzo de marcación asegura que el switch telefónico receptor está
preparado para interpretar los dígitos (es decir, el numero del teléfono de destino)
transmitidos por el switch telefónico emisor. Sin supervisión de comienzo de marcación, el
switch telefónico receptor puede perder los primeros dígitos de una dirección destino
entonces se producirá un intento de llamada fallido. Por esta razón, debería utilizar un tipo
de señalización de enlace troncal que incluya supervisión de comienzo de marcación
siempre que sea posible. Para enlaces troncales analógicos, E&M wink start es la mejor
opción y además ampliamente disponible. Algunos enlaces troncales digitales que utilizan
señalización de canal común (CCS) proporcionan la funcionalidad de supervisión de
comienzo de marcación. [13]
Aunque la supervisión de comienzo de marcación proporciona confirmación positiva de
que el switch remoto este preparado para recibir dígitos, no proporciona confirmación de
que los dígitos se hayan recibido correctamente. La confirmación de recibo para dígitos
individuales no es un elemento de los protocolos de señalización utilizados aca en
Colombia; sin embargo, la señalización R2 MFC, [5], [9] que se usa en muchos países,
proporciona esta fiabilidad añadida.
2.2.10. Proceso de Transmisión de Dígitos y marcación por pulsos
Los teléfonos y los switches telefónicos transmiten dígitos para representar las
direcciones de destino y proporcionar entradas desde los usuarios a los sistemas
automatizados como buzón de voz, auto-asistidos, distribuidores automáticos de llamada
(ACD) y sistemas de respuesta interactiva de voz (IVR).
Los sistemas de telefonía normalmente utilizan dos clases de transmisión de dígitos:
Marcación por pulsos y marcación por tonos.
23
Los teléfonos y circuitos originales no tienen un método para transmitir dígitos. Los
operadores humanos de una oficina central responderían el teléfono tan pronto como descolgaran (off-hook) y utilizaran parches de cables para conectar físicamente su circuito
telefónico al circuito telefónico de la parte destino. El esquema de pulsos original se
implemento con teléfonos de marcación giratoria, que estaban diseñados para trabajar
con líneas loop-start existentes y para permitir a la parte emisora conectar
automáticamente con la parte destino sin intervención de una operadora.
Cada número en el esquema de marcación por pulsos se señala como una serie de
pulsos make/break, donde make es el estado off-hook (alrededor del 60 % del tiempo de
pulso) y break es el estado on-hook (alrededor del 40% del tiempo de pulso).
2.2.11. Sistemas de Marcación por Tonos
Hay varios estándares para transmitir dígitos mediante tonos audibles:
• Marcación multifrecuencia (DTMF).
• Marcación multifrecuencia por pulsos (MF-P).
• Multifrecuencia obligada (MF-C).
Las normas de transmisión de dígitos multifrecuencia (MF) [12], [3], [4] son generalmente
un subconjunto de protocolos de serializarían mas amplios basados en los tonos MF
audibles. Estos protocolos de serializarían más amplios describen la transmisión de
dígitos y señales de supervisión, señales de línea y otros tipos de control de llamada y de
información.
La marcación multifrecuencia (DTMF) es el método mas utilizado para la transmisión de
dígitos, tanto para la transmisión del numero de destino como para el intercambio de
información dentro de banda entre los que llaman y los sistemas automatizados de
telefonía (buzón de voz, IVR, ACD, etc.). [3],[5]
La planificación entre dígitos y frecuencias audibles se basa en el diseño físico de un
teclado numérico de teléfono estándar. Se asigna una frecuencia distinta a cada fila y
columna del teclado numérico, de manera que cada tecla se corresponda con dos
frecuencias, como se muestra en la siguiente Tabla 2.
24
1209 Hz
1336 Hz 1477 Hz 1633 Hz
697 Hz
1
2
3
A
770 Hz
852 Hz
4
7
5
8
6
9
B
C
941 Hz
*
0
#
D
Tabla.2. Frecuencias DTMF asignadas a un teclado de teléfono estándar
La tecla * se utiliza normalmente para señalar solicitudes de funciones procedentes del
usuario a la red pública. Muchos fabricantes de PBX también siguen este convenio para
las redes privadas. La tecla # se utiliza normalmente como un digito de terminación en
redes públicas, de modo que la conexión de llamada puede empezar sin esperar a que
termine la interrupción de dígitos.
5.1.
CONSIDERACIONES TECNICAS SOBRE LA TELEFONÍA POR EL
PROTOCOLO INTERNET (IP)
5.1.1. Elementos técnicos asociados.
Debido a que la telefonía IP actualmente no presenta, ni constituye aún un porcentaje
sustancial y elevado en el volumen de tráfico telefónico en todo el mundo, está
expandiéndose rápidamente debido a las siguientes motivaciones técnicas:
 La red con conmutación de circuitos se diseñó y optimizó con el objetivo de ofrecer
un solo producto, establecer canales vocales dúplex entre puntos con conmutación
de 4 kHz (canales digitales de 64 kbit/s).
 Por lo general, los datos se caracterizan por ráfagas de información y no por flujos
de velocidad binaria constante que se asocian comúnmente con la voz.
 Las ráfagas de datos pueden ser transportadas de una manera más eficaz
utilizando paquetes de información que pueden intercalarse en función del tiempo
en una red con otros paquetes que estén siendo transportados entre otras fuentes
y destinos.
25
 Durante más de 40 años, la voz ha sido codificada digitalmente en trenes de 64
kbit/s que pueden transportarse por canales de 64 kbit/s. No obstante, los avances
de la tecnología de codificación vocal permiten una amplia gama de opciones, por
ejemplo, desde audio a 5-8 kbit/s a audio de calidad superior a 64 kbit/s. La
multiplexación vocal a velocidades distintas de 64 kbit/s resulta difícil en la red con
conmutación de circuitos a 64 kbit/s. Sin embargo, los abonados a la telefonía IP
necesitan interconectar con más de mil millones de abonados a la telefonía
convencional en todo el mundo y cuando se emplea un mecanismo de
transcodificación es necesario transformar su velocidad binaria más baja a la
codificación tradicional de 64 kbit/s (bastante similar a lo que sucede cuando se
conecta la codificación de baja velocidad de las redes móviles a las redes RTPC
fijas). [1], [5], [10]
 El Grupo de la ITU (Unión Internacional de las telecomunicaciones) y otros
organismos han diversificado investigaciones y trabajos destacados con el
propósito de ofrecer capacidades en tiempo real o casi real utilizando el protocolo
IP, que permite transportar la voz por este protocolo empleando la gama de
codificación vocal. Los diferentes operadores en Colombia, han estado evaluando
e introduciendo productos que integran estos protocolos y que determinen el
cumplimiento que caracteriza la calidad de servicio necesaria para satisfacer a los
clientes potenciales. La ITU-T está trabajando actualmente en la creación de
protocolos que garanticen el cumplimiento de las condiciones de QoS de manera
compatible cuando es necesario atravesar un conjunto de redes y en especial en
la
nueva era de internet2 o también conocida como la era next generation8.
8
Internet2: Es una red de cómputo sustentada en tecnologías de vanguardia que permiten una alta velocidad en la transmisión de
contenidos y que funciona independientemente de la Internet comercial actual.
26

Actualmente las redes basadas en IP pueden aprovechar las mismas facilidades de
transporte de capas más bajas subyacentes, por consiguiente la evolución a las redes
basadas en IP puede lograrse de una forma económica mediante la instalación de
conmutadores o routers de paquetes que pueden conectarse mediante las facilidades de
transporte existentes lograr la convergencia. Esto ha representado un vehículo muy
importante para poder ofrecer el acceso masivo a Internet para fines comerciales en los
países desarrollados gracias a la disponibilidad y ubicuidad de esas facilidades de
transporte.
De acuerdo a las diversas funcionalidades que surgieron en el desarrollo del proyecto de
Investigación, se determinaron tres casos que involucran la utilización de la voz por IP
teniendo en cuenta el equipo terminal y los diversos tipos de redes.
El primer caso corresponde al esquema de Equipo PC a equipo PC, y se define en que
ambas partes, el que está ejecutando la llamada y la llamada, disponen de varios PC,
que tienen a accesos y permisos para conectarse a la red Internet, a través de un
proveedor de servicio de Internet.
Los procesos de señalización en Asterisk se dan cuando las dos partes están de acuerdo
en establecer una comunicación vocal sólo mediante acuerdo previo, ya que ambos
usuarios tienen que estar conectados a Internet al mismo tiempo (para lo cual habrán
fijado con anterioridad la hora en la que se comunicarán a través de Internet, a menos que
se encuentren en línea permanentemente) y utilicen software especializado que sea
compatible con VoIP.
Por otro lado, la persona que llama debe conocer la respectiva dirección IP de la parte
llamada; para ello, se hace obligatorio que ambas partes deben ponerse de acuerdo y
sincronizarse para consultar un servidor de directorio en línea (que se actualiza con cada
conexión) en el cual se registran los usuarios antes de cada comunicación o deben
disponer de otras formas para localizarse o tener conocimiento de la disponibilidad de la
conexión de su contacto a Internet.
2
Inicialmente
se accede a la red del proveedor a través de la red telefónica pública
mediante una simple llamada telefónica. Este medio de acceso aún predomina, incluso en
los países desarrollados. Las soluciones alternativas conocidas como RDSI de banda
estrecha y basadas en la red telefónica basada en xDSL, una red de televisión por cable o
una red de acceso inalámbrico (tecnología LDMS) se encuentran hoy en día en la fase
inicial de despliegue, y su uso no se ha generalizado, a pesar de que algunos países ya
disponen de los equipos adecuados.
En este caso, el proveedor de servicios de internet solo se limita a proporcionar acceso a
la red, lo que a su vez permite que el usuario acceda a Internet. La aplicación vocal que
emplea el cliente es transparente para el ISP, que no toma medidas específicas para
garantizar la calidad del servicio vocal. En pocas palabras, en tal escenario no puede
hablarse de telefonía en el sentido convencional de la palabra, es decir la prestación de
un servicio por un tercer proveedor, sino simplemente de la utilización de una aplicación
vocal a través de Internet, utilización que se ha vuelto tan común como cualquier otra
aplicación de red. A menudo, el protocolo utilizado entre las dos partes en comunicación
es el protocolo H.323 [5], [9], [10], [11] (por ejemplo, la aplicación de NetMeeting); no
obstante, el protocolo SIP podría tener una utilización más generalizada en el futuro. Este
modelo que se plasma esta referenciado en el siguiente grafico. Mostrando las ventajas
de software de telefonía.9
9
Todos los productos de software orientados a telefonía que están disponibles en el mercado tienen una estructura similar, ya que muestran
un panel de control a partir del cual pueden controlarse las principales funciones de telefonía y pueden consultarse los menús de
configuración y de opciones. Todos esos softwares proporcionan acceso a las zonas de charla interactiva Internet (IRC), donde los usuarios
pueden intercambiar mensajes de texto en tiempo real, para cuyo fin se visualiza una lista de los individuos que utilizan el mismo software y
se encuentran en línea. Según el producto, también hay un menú que permite al usuario llamar a una dirección IP específica que es
permanente y corresponde a una máquina que ya está conectada a la red.
3
Figura 4. Esquema de interconectividad de Servidor a Servidor en la FUKL (Lab. 302)
Figura 5. Laboratorio dedicado al Proyecto telefonía IP-Asterisk Salón 302 de la FUKL,
4
Figura 6. Laboratorio dedicado al Proyecto telefonía IP-Asterisk Salón 302 de la FUKL,
Existe otro modelo que involucra teléfono a teléfono por conexión IP, en donde ambas
partes estas abonadas a la red telefónica pública, que puede ser fija o móvil y utilizan su
aparato telefónico para comunicación vocal en la forma normal. Hay dos métodos para
comunicarse mediante dos aparatos telefónicos ordinarios a través de una red IP o
Internet.
El primer método utiliza pasarelas, Esto significa que uno o varios actores de
telecomunicaciones han establecido pasarelas que posibilitan la transmisión de voz a
través de una red IP de un modo que es transparente para los usuarios telefónicos. En
este caso no se trata de la red Internet sino de una red IP gestionada, es decir, una red
dimensionada de tal manera que permite el transporte de la voz con una calidad de
servicio aceptable.
Otro esquema que puede ser utilizado es el uso de dispositivos o adaptadores. Muchas
empresas en Colombia ofrecen adaptadores muy parecidos a un módem llamados
5
dispositivos ATA, que se instalan entre el aparato telefónico del usuario y su conexión a
la RTPC.
Para que este tipo de configuración funcione adecuadamente, cada uno de los dos
usuarios debe disponer de una conexión con un proveedor de servicios de internet, cuyos
parámetros de acceso hayan sido programados en el dispositivo.
El procedimiento se inicia cuando la parte llamante inicia la llamada de la misma manera
que en una red de telecomunicaciones convencional, y la primera fase es en realidad el
establecimiento de la comunicación en esa red; sin embargo, inmediatamente después
del establecimiento, los dispositivos intercambian la información necesaria para la
segunda fase. Luego de esto se disocia la llamada convencional y los dispositivos, en
función de los datos que se han intercambiado y los parámetros preestablecidos, se
establece una conexión entre cada uno de los corresponsales y su respectivo ISP.
Una vez es establecida la llamada, los dispositivos ATA, convierten localmente las
señales vocales a paquetes IP para transportarlos por la red Internet como se ilustra en la
Figura 4. En principio, este caso es muy similar al caso 1, salvo que los dos usuarios no
requieren un PC y la necesidad de una cita Internet se facilita mediante el procedimiento
iniciado en forma de una llamada telefónica. Sin embargo, este tipo configuración ha
tenido éxito sólo marginalmente ya que requiere, como en el caso de PC a PC, que los
dos corresponsales dispongan del mismo tipo de dispositivo.
Figura 7. Esquema de interconectividad Utilizando adaptadores ATA
6
Se puede tener otra modalidad y es cuando la parte que llama es el usuario telefónico y la
parte llamada es el usuario con un PC.
Un usuario telefónico puede marcar esencialmente un número para establecer
comunicación con la parte llamada, el usuario con un PC puede disponer marcando:

Indirectamente: Se presenta teniendo interconexión a la red como abonado de una
centralita privada automática (PABX) con tecnología IP conectada a la red pública
(en realidad, en este caso cabría hablar más apropiadamente de un teléfono IP en
lugar de un PC conectado a la red LAN gestionada por la PABX IP).

Directamente: en este caso, se trata del abonado del lado IP que tiene una
dirección atribuida por un operador de telefonía IP. Técnicamente, hoy en día sólo
funciona el primero de los casos anteriores a través de dispositivos PABX IP. El
segundo caso funcionará dependiendo de la disponibilidad de un mecanismo de
traducción intermediario implantado por el lado IP que pueda traducir el número
seleccionado público a la dirección IP de la parte llamada.
Este modelo se muestra en el siguiente grafico:
Figura 8. Esquema de interconectividad Utilizando Telefonía IP a Teléfono a teléfono
7
5.2.
SUPERVISION DE TELEFONIA IP SOBRE ASTERISK
5.2.1. Números de teléfonos asociados.
En una configuración particular, la aplicación asterisk puede ser teléfonos separados, con
un ring distinto que identifique la parte a la que se llama. En una configuración comercial,
las aplicaciones incluyen marcación directa (DID). Hay dos clases de identificación de la
parte que llama:
• Marcación directa (DID).
• Servicio de identificación de numero marcado (DNIS).
La clase DID se utiliza generalmente para dirigir las llamadas a un abonado específico en
una empresa que comparte líneas telefónicas. [3], [4] La marcación directa se puede
proporcionar en enlaces troncales analógicos o digitales, utilizando cualquier mecanismo
de transmisión de dígitos:
•
Marcación por pulsos (DP).
•
Marcación multifrecuencia (DTMF).
•
Rl multifrecuencia (MF).
•
R2 multifrecuencia obligada (MF-C).
La clase DNIS se utiliza generalmente para dirigir llamadas a través de un sistema
distribuidor automático de llamadas (ACD) a un grupo de agentes apropiado, o para
proporcionar información mejorada screen-pop en entornos de centrales de llamada.
DNIS se suministra en un mensaje RDSI Q.931 SETUP (basado en el contenido de un
mensaje ISUP IAM en la red SS7). DNIS también se puede proporcionar mediante tonos
MF.
5.2.2. Tonos de progreso de llamadas.
8
Las redes de voz señalan una variedad de condiciones para los usuarios a través de
tonos audibles de progreso de llamada. Los tonos de progreso de llamada son familiares
a los usuarios dentro de un país; sin embargo, varían entre países. Al integrar redes en
una escala global, es importante que el equipo en cada país proporcione los tonos de
progreso de llamada acostumbrados en el país. Esto asegura que los usuarios dentro de
cada país tengan una experiencia familiar y consistente al usar el sistema telefónico.
La supervisión de respuesta en el extremo lejano y la supervisión de desconexión son
elementos que proporcionan confirmación positiva del inicio y del fin de sesiones de
llamada. Estos elementos son importantes para los proveedores de servicios con
propósitos de facturación y contabilidad. Las compañías telefónicas no son los únicas
proveedores de servicios; otros ejemplos de proveedores de servicios que se benefician
de la supervisión de respuesta y de desconexión incluyen compañías que aplican
programas departamentales charge-back para los gastos de telecomunicación, y hoteles
que cobran a los huéspedes las llamadas telefónicas.
Sin la supervisión de respuesta, los proveedores de servicios no tienen un punto fijo para
empezar a facturar una conexión. En tales casos, el proveedor de servicios puede
comenzar a facturar veinte o treinta segundos después de que se marque el número, con
la suposición de queja del destino cuando habrá contestado en este tiempo. En otros
casos, el proveedor de servicios puede empezar a facturar inmediatamente después de
que se haya marcado el número. El problema de estos planteamientos es que las
llamadas incompletas también se facturan, muy a pesar de los abonados.
5.2.3. Manejo y gestión de troncales para entornos Asterisk
Los enlaces troncales de voz analógicos se utilizan cuando el switch telefónico no soporta
conexiones digitales, o cuando se necesitan pocos canales de voz. Por ejemplo, las
oficinas pequeñas con sistemas de teclas utilizan tradicionalmente enlaces troncales
analógicos para líneas tie y conexiones PSTN. Las oficinas grandes con PBX utilizan
líneas tie analógicas para conectar con las oficinas remotas pequeñas. Los enlaces
troncales analógicos también son comunes para líneas tie Internacionales porque el costo
de las funcionalidades T1/E1 es elevado.
9
Hay tres tipos comunes de enlace troncal analógico:

Inicio de bucle (loop-start).

Inicio de tierra (ground start).

E&M.
Las descripciones de las siguientes secciones consideran el switch telefónico de la CO y
el CPE como los puntos extremos del enlace troncal; sin embargo, son posibles otras
combinaciones. Por ejemplo, un puerto de estación analógica PBX puede actuar como la
CO para los siguientes dispositivos conectados:

Un teléfono de Servicio telefónico analógico convencional (POTS); por ejemplo, un
teléfono particular.

Fax.

Modem.

Oficina o puerto de enlace troncal en un PBX o en un sistema de teclas.

Puerto FXO en un router Cisco.
Alternativamente, un puerto FXS en un router puede actuar como la CO para el mismo
grupo de dispositivos. En general, las etiquetas denominadas como oficina y estación son
más apropiadas que CO y CPE. Por lo tanto los puertos FXS en los routers proporcionan
batería y tono de marcación a las estaciones, y los puertos FXO en routers esperan
batería y tono de marcación desde la oficina.
5.3.
Inicio de Bucle
Los sistemas de telefonía residencial de todo el mundo utilizan señalización loop-start.
Debido a que los enlaces troncales conectan entre los switches telefónicos y las líneas
conectan un switch telefónico a un teléfono, las facilidades particulares se denominan
líneas loop-start. Un circuito entre una CO y un PBX se puede llamar enlace troncal desde
la perspectiva del cliente, o línea desde la perspectiva del vendedor del circuito. En
Colombia, el servicio enlace troncal o línea loop-start se puede llamar 1-MB; identifica un
solo circuito de teléfono de velocidad corporativa medida. El nombre indica que el servicio
10
de teléfono se mide y se factura según el uso, en oposición a la tarifa plana cargada para
el servicio de teléfonos domésticos. [5]
5.4.
Circuito Libre
La señalización analógica loop-start utiliza solo un par de cables entre el switch telefónico
en una CO y el teléfono o switch telefónico conocido como CPE.
La CO proporciona una batería de corriente continua (DC) de -48-volt (V), que genera
corriente eléctrica a través del bucle del circuito. Los teléfonos particulares no necesitan
fuentes de potencia separadas por esta razón. Las CO también proporcionan un
generador.
Cuando el CPE está en el estado on-hook (es decir, el teléfono está colgado), hay un
switch eléctrico abierto que evita que la electricidad fluya a través del bucle del circuito.
Cuando el CPE inicia una llamada cambiando al estado off-hook (es decir, el teléfono esta
descolgado), el switch eléctrico se cierra y la corriente fluye a través del bucle del circuito.
Cuando la corriente fluye por el bucle, la CO detecta la condición off-hook del CPE. La CO
responde transmitiendo un tono de marcación en el bucle, el cual informa al CPE de que
la CO está preparada para recibir dígitos del número de teléfono de destino. Esto es una
forma de supervisión de comienzo de marcación. La detección off-hook y la supervisión
de comienzo de marcación para enlaces troncales loop-start.
5.5.
DEFINICION Y MEDIDA DE LA VOZ SOBRE ASTERISK
La definición y medida de la calidad de la voz es un reto que ha sido estudiado desde
muchas perspectivas. Todavía es un área activa de investigación en la Unión
internacional de las telecomunicaciones (grupo de estudio 12, ITU-T). Los esfuerzos han
incluido la caracterización precisa de la transmisión física en forma de onda, pruebas
subjetivas de escucha y modelos fisicoquímicos. Estos esfuerzos han dado lugar a
numerosas recomendaciones para la transmisión en circuitos y el rendimiento de los
equipos, además de la medida y caracterización de la calidad de la voz. Las
investigaciones más recientes se centran en la calidad de la conversación para sistemas
que utilizan los nuevos códecs de baja velocidad binaria (como G.723.1 y G.729) [1], [3],
[4] y en sistemas que integran VoIP con la Red pública de telefonía conmutada (PSTN).
11
5.6.
Variables que afectan la calidad de la voz.
Hay muchas maneras posibles de considerar y agrupar las variables que afectan a la
calidad de la voz. En la siguiente tabla aparecen las siguientes variables.
Variables de punto final
Variables de red
Ruido de fondo en el emisor y receptor
Nivel de entrada y salida de serial Recorte
de amplitud Distorsión de cuantificación
Ruido de circuito.
Distorsiones dependientes de la frecuencia.
Retraso y fluctuación de fase.
Eco del que habla y del oyente.
Distorsión del codec
Errores binarios aleatorios
Errores binarios aleatorios
Errores ráfaga (perdida de paquetes).
Múltiples hablantes
Distorsión códec/cuantificación
5.7.
Control de Ruido de Fondo en Asterisk
El ruido de fondo en los extremos del flujo de audio, tanto en la emisión como en la
recepción, puede tener un impacto importante en la calidad de la voz percibida por el
oyente. Entre los ejemplos de ruido de fondo se incluyen una oficina ruidosa, una calle
concurrida o un centro de computadoras de datos con numerosos equipos de ventilación y
de aire acondicionado. Los efectos del ruido de fondo en el lado oyente, generalmente, se
hallan fuera del tema de diseño y planificación de redes, dado que la red no contribuye a
este problema. El ruido de fondo en el lado del hablante es de gran importancia, porque
afecta a la operatividad de los codecs y de los sistemas de detección de actividad de voz
(VAD).
Nivel de Señal: El nivel de la señal es importante en numerosos puntos a lo largo de la
ruta de audio, incluyendo la entrada y salida, rutas analógicas intermedias y puntos de
conversión A/D o D/A (A/D es analógico/digital). El nivel de la señal se refiere al volumen
de audio, el voltaje o la corriente eléctrica analógica, el nivel de la muestra de modulación
12
por impulsos codificados (PCM) en un byte digital, o cualquier cosa que represente el
nivel de audio en un medio dado. Generalmente hablando, el nivel de la señal permanece
constante cuando se convierte en la forma digital. Sin embargo, los elementos de red
pueden añadir "relleno digital" que reduce el nivel de la señal, o el procesado de otra
serial que puede afectar al nivel cuando está en el dominio digital. En el dominio
analógico, las señales se pueden atenuar en función de la distancia de transmisión. Las
rutas de transmisión mas largas debilitan la fuerza de la señal. Los retrasos intermedios y
los dispositivos de regeneración tienen el inconveniente efecto de amplificar el ruido
acumulado en el circuito además de la señal deseada. Si los niveles de la señal son
demasiado bajos o demasiado altos en cualquier punto a lo largo de la ruta de audio,
entonces la señal comienza a distorsionarse (es decir, la información de audio se puede
perder). [1], [2], [3]
5.7.1. Recorte de Amplitud
El recorte de amplitud ocurre cuando el nivel de una señal es demasiado grande para ser
representado exactamente en algún dispositivo al medio de transmisión. La señal se
rebaja al nivel al que puede ser transmitida, lo cual causa una distorsión de la forma de la
onda original. La Figura 6 ilustra este concepto. La forma de la onda en el lado izquierdo
esta dentro de los límites de amplitud de alguna parte de la red. A medida que la onda se
mueve hacia una parte de la red con menos capacidad para acomodar señales altas, la
onda original es "recortada" para ajustarse a la envoltura restringida de transmisión. [2]
Figura 9. Esquema cuando el recorte de amplitud cambia la forma de la señal
13
5.7.2. Distorsión de cuantificación
La distorsión de cuantificación es el efecto de convertir una señal analógica que varia
continuamente con respecto al tiempo y a la amplitud en una señal digital que cambia la
forma de la amplitud de forma discreta con el tiempo.
Para redes que emplean codecs con velocidad de transmisión baja (como muchas redes
VoIP, en el caso de asterisk), el efecto de distorsión de cuantificación es despreciable
comparado con otras alteraciones.

Distorsión Codec: La distorsión codec ocurre debido a que muchos algoritmos de
codificación de conversación con baja velocidad binaria emplean un esquema de
compresión por perdida. Esto significa que el lado del oyente no recibe toda la información
de la señal original. La distorsión codec afecta tanto a las señales de conversación como
a las de no conversación, como marcación multifrecuencia (DTMF) y tonos
multifrecuencia (MF). Los efectos de la distorsión codec dependen de otras variables,
incluyendo la mayor parte de las variables presentadas en esta sección. Por tanto, el
impacto de la distorsión codec en un sistema no debería ser considerado hasta
que otras alteraciones hayan sido localizadas con exactitud.

Recorte temporal: El recorte temporal (es decir, recorte con respecto al tiempo) lo
presentan los sistemas VAD, los cuales están diseñados para ahorrar ancho de banda y
eliminar el ruido de fondo durante los periodos de silencio en una conversación. Cuando
el hablante comienza a hablar, los sistemas VAD requieren una cantidad finita de tiempo
para cambiar de un modo de supresión de silencios a un modo de transmisión de
conversación. El comienzo de las palabras o de las frases se puede perder durante este
tiempo. [2], [3], [4]

Hablantes múltiples: Los hablantes múltiples pueden afectar a un sistema telefónico de
diversas maneras. Los codificadores de lenguaje de baja velocidad binaria modelan los
patrones de la señal de un hablante individual; por ello, no pueden proporcionar una
calidad óptima de voz cuando varias personas hablan desde el mismo lugar (por ejemplo,
múltiples teléfonos en una línea analógica). Las conferencias de audio que tienen
múltiples y simultáneos hablantes desde diferentes localizaciones tienen problemas
14
similares. Observe que las conexiones de audio hoot-n-holler, o siempre activas, pueden
usar también una configuración multipunto que puede verse afectada por los codecs de
conversación de baja velocidad binaria. Además de la codificación de la calidad de voz, la
anulación de eco puede no funcionar correctamente cuando las partes en dos o más
terminaciones de una conexión hablan simultáneamente. La función de procesador no
lineal de un anulador de eco, que es responsable de una significativa reducción del eco,
se desactiva cuando ambas partes hablan simultáneamente. No se puede cambiar este
comportamiento fundamental de un procesador no lineal. La relevancia de estos efectos
para un entorno dado debe ser considerada como parte de la evaluación de la calidad de
la voz en el entorno de su red.

Ruido de circuito: El ruido de circuito es fundamentalmente de interés para circuitos
analógicos de telefono en la PSTN. Los circuitos analógicos que transportan una señal
pueden introducir señales no deseadas, como ruido eléctrico aleatorio, cruce de
conversaciones o inductancia10 mutua entre cables adyacentes, y clicks y pops desde
puntas eléctricas en curso durante el switching. El ruido de circuito puede ser un factor
significativo para los circuitos analógicos de tramo largo porque la señal deseada puede
ser muy débil cuando se introduce ruido. Como resultado, la capacidad de la señal de
ruido (SNR) [2], [9] puede ser muy bajo para tales circuitos. Se puede considerar a los
errores binarios como la versión digital del ruido.

Distorsiones dependientes de la frecuencia: Las distorsiones dependientes de la frecuencia
ocurren porque los cables analógicos tienen diferentes propiedades de transmisión
eléctrica para señales de diferentes frecuencias. Por ejemplo, una señal eléctrica viaja
ligeramente mas rápido a través de un cable en el rango de frecuencia medio que a
frecuencias más altas o más bajas. Como resultado, los diferentes componentes de
frecuencia de la misma muestra de conversación alcanzan el destino en tiempos
diferentes. Este fenómeno se llama distorsión por retraso de grupo. Efectos similares
provocan la atenuación dependiente de la frecuencia a través de un circuito, y otros
fenómenos relacionados con el tiempo y la amplitud. Las transmisiones por fax y modem
de alta velocidad deben considerar los efectos de estos fenómenos; sin embargo, la
calidad de la voz no se ve afectada significativamente.
10
La Inductancia mutual es fenómeno que se produce a cabo con dos inductancias cada una afectada por la auto inductancia las cuales se
transmiten energía a través del campo magnético.
15

Retraso y fluctuación de fase: El retraso y la fluctuación de fase son factores prominentes
en redes por paquetes de voz y en especial en telefonía IP. En asterisk el retraso puede
ser una consideración para cualquier comunicación de larga distancia; sin embargo, las
redes de voz de paquete introducen los retrasos adicionales de codecs de baja velocidad
binaria, cola y formación de paquete. Las redes por paquetes de voz también deben
considerar los efectos de retraso variable, o fluctuación de fase, ya que la conexión
extremo a extremo no es una corriente síncrona en serie, como lo es en redes digitales de
circuitos conmutados.

Eco en Asterisk: El eco es el resultado de señales de conversación en un sentido que se
reflejan o se escapan en sentido opuesto. El eco del que llama se produce cuando la
señal de la conversación viaja hacia el destino y se refleja o se fuga en la ruta de audio de
vuelta en un punto cercano al destino. Este reflejo o fuga de la señal alcanza los oídos del
que habla, quien oye su propia voz.
Si la señal de eco se refleja o se fuga de nuevo, se convierte en eco del oyente para la
parte remota. Debido a que una señal reflejada habitualmente es más débil que la señal
original, el eco del que habla es más común que el eco del oyente. El grado al que un eco
es molesto se relaciona con el retraso y el nivel de señal de la señal de eco. La siguiente
grafica muestra como se reproduce el fenómeno presentado.
RED TCP/IP CON CANAL INTERNET
ECO DEL QUE HABLA
CURSO DEL ENLACE EN ASTERISK
Figura 10. Fenómeno de Eco presentado en Asterisk
16

Errores en ráfaga: Los errores en ráfaga se producen cuando se degradan bits
adyacentes en una corriente digital. En las redes por paquetes y en especial los
datos tomados por el sniffer, los errores que se presentaron en ráfaga son menos
destructivos que los errores binarios, porque solo se necesitan retransmitir los
paquetes con el grupo de errores. Los errores binarios aleatorios están más
distribuidos, de modo que hay más paquetes afectados y que deben ser
retransmitidos. En una red de voz, se observa el comportamiento opuesto; es
decir, los errores en ráfaga son más destructivos que los errores binarios
aleatorios. Una corriente de voz no es adversamente afectada por una tasa baja
de cambios de serial aleatorios que se sucedan en el tiempo; sin embargo,
cualquier agrupación de errores causa un efecto pronunciado. Los efectos de
errores en ráfaga en los codecs de baja velocidad binaria se amplían, ya que cada
bit de una corriente de voz comprimida representa más información. Una perdida
consecutiva de bits significativos puede afectar a una notable porción de la
corriente de audio de salida.
Ciertamente hay otros factores que contribuyen a la calidad de voz percibida por
un oyente. Se observa que el rendimiento del codec, que puede ser la mayor
alteración observada en una red VoIP y en especial en Asterisk, es altamente
dependiente de un número de variables.
5.8.
Medida subjetiva de la calidad de la conversación
La medida subjetiva de la calidad de conversación es el planteamiento más fiable y
respetado para medir la calidad de la voz. Este planteamiento determina empíricamente la
calidad de la voz medida de un codec o sistema a través del uso del oyente o pruebas de
conversación con personas que se hicieron respectivamente en el laboratorio 302 de la
FUKL. Los estudiantes de los grupos de investigación y los del semillero, actuando como
los sujetos experimentales, escuchan muestras de audio y proporcionan su reacción en
forma de una escala de categorías. Las respuestas a diferentes muestras de audio y
escenarios de consulta se evalúan estadísticamente a través de wireshark y de la consola
del log de asterisk para determinar la respuesta media del grupo. Esta respuesta media
17
refleja el rendimiento del sistema bajo consulta y los efectos de varíes factores (como
ruido de fondo, múltiples hablantes, niveles bajos de señal, etc.) se pueden cuantificar
individualmente.
Existen tres métodos de prueba subjetiva que son por los que aboga la ITU y se
recomiendan en entornos de telefonía IP.
Puntuación media de opinión (MOS).
Puntuación media de opinión de comparación (CMOS).
Puntuación media de opinión de degradación (DMOS). [2], [3], [11]
5.9.
Protocolo de Control Rápido RTP
Utilizado en enlaces de asteruisk de tiempo real, que dispone de extremo a extremo para
los servicios de entrega de datos en tiempo real, sus características, tales como audio y
vídeo interactivo. Estos servicios incluyen identificación del tipo de carga útil, numeración
de secuencia, tiempo de entrega y seguimiento. Aplicaciones suelen ejecutar en la parte
superior de RTP UDP al hacer uso de sus servicios de verificación y de multiplexado.
Sin embargo, RTP [2], [6] puede ser usado con otro protocolo de la red de transporte o
protocolos adicionales que soportan transferencia de datos a múltiples destinos utilizando
distribución de multidifusión
Se tiene en cuenta que RTP no proporciona ningún mecanismo para garantizar la
oportuna entrega de paquetes o tampoco aporta calidad del servicio con óptimas
garantías, sino que se basa en la capa inferior de servicios para hacerlo.
No garantiza la entrega viable o evita que fuera de la orden de entrega, ni asume que las
la red es confiable. La secuencia de números incluidos en el receptor RTP permiten
reconstruir los paquetes de secuencia al remitente, pero los números de secuencia
también podría utilizarse para determinar la correcta ubicación de un paquete, por
ejemplo, en vídeo o conferencia múltiple, sin necesidad de hacer decodificación de
paquetes en secuencia. [6], [9]
18
Aunque RTP está diseñado principalmente para satisfacer las necesidades de múltiples
participantes en conferencias multimedia, no se limita a que se utilice en una aplicación
particular.
5.10. Protocolo de Control Rápido como elemento diferenciador en Telefonía IP
El Protocolo de control rápido RTP (RTCP) [2], [6], [10] administra los aspectos
relacionados con los informes y la administración de una conferencia RTP multidifusión.
RTCP aparece en la RFC 1889 como parte del RTP. Aun cuando RTCP está asignado
para escalar conferencias extensas, es útil en llamadas VolP punto a punto para
proporcionar retroalimentacion QoS desde el receptor al emisor en cada dirección. En el
caso de conferencias multidifusión extensas, el ancho de banda de los flujos de medios
de RTP tiende a permanecer constante porque solo pueden hablar pocas personas al
mismo tiempo, incluso aunque estén escuchando cientos de ellas. La información de
control de RTCP se envía desde cada participante a otro y cobra importancia la
escalabilidad. Si cada oyente
envía un paquete de 100 bytes por segundo, en una
conferencia con 10.000 personas cada participante recibe 1 Mbps de información de
control. RTCP resuelve este problema transmitiendo paquetes con menor frecuencia, al
tiempo que aumenta el número de participantes detectados en la conferencia.
El algoritmo RTCP limita el control del ancho de banda aproximadamente al 5 del ancho
de banda del flujo de medios predeterminado, aunque las aplicaciones pueden ajustar
esta cantidad., en el contexto de los cinco tipos de mensaje RTCP están:
Informe del emisor (SR) e informe del receptor (RR).
Descripción de fuente (SDES).
Desconexión (BYE).
El algoritmo de RTCP en encuentra descrito en la ubicación web:
http://translate.google.com.co/translate?hl=es&langpair=en|es&u=http://tools.ietf.org/html/draft-wenger-avtrtcp-feedback02&prev=/translate_s%3Fhl%3Des%26q%3Dalgoritmo%2BRTCP%26tq%3DRTCP%2Balgorithm%26sl%3Des
%26tl%3Den
19
Estructura de la Cabecera RTCP
FUNCION DEL RTCP
PROPOSITO DE LA FUNCION
Numero de paquetes RTP perdidos de la sesión
Cumulative Packets Lost
Numero de secuencia mas alto recibido del emisor
dígitos adicionales para prevenir la reiniciación.
Extended Sequence Number Received
D = Diferencia entre tiempos entre paquetes en el
emisor y en el receptor. 1= Desviación de D
Fecha y hora NTP (Versión de 32 bits) en el último
Interarrival Jitter (J)
paquete SR recibido del emisor.
Diferencia de tiempo entre recibir el último SR y
Last SR (LSR) Time
enviar el informe de recepción.
El RR es idéntico al SR, excepto en el tipo de paquete, PT=201, y en que se elimina la
sección de información del emisor (es decir, los datos de fecha y hora, y paquetes/bytes
enviados).
Los campos RTCP de los SR y RR ofrecen a los emisores de medios retroalimentación
QoS de los receptores. Además, cada receptor puede determinar si su calidad de
recepción concuerda con otros receptores, o si los problemas locales pueden impactar
negativamente en su calidad de recepción. Concretamente, los emisores pueden
aprender las siguientes estadísticas de la red:
• Tiempo de ida y vuelta (RTT).
• Tasa de paquetes perdidos.
• Fluctuación de fase. [2], [6]
Los emisores de medios calculan el RTT, percatándose de cuando se reciben los paquetes RR y usando los campos LSR y DLSR. Un emisor calcula el RTT como la diferencia
entre cuando envía un SR a los receptores y cuando recibe un RR de estos. Esto se
expresa en la siguiente fórmula:
RTT = (LSR -A)- DLSR
20
Todos los participantes en la sesión pueden conocer las tasas de paquetes perdidos en la
red, examinando los RR RTCP. La fracción perdida muestra la velocidad perdida sobre el
intervalo de tiempo más reciente, y la acumulación de paquetes perdidos permite a los
participantes conocer la complejidad del problema, sin necesidad de recordar y rastrear
los datos. [2], [6], [12]
La fluctuación de fase se calcula en cada receptor, notificando cuando llegan los paquetes
RTP, y usando el valor del campo de fecha y hora RTP que contenían esos paquetes. En
primer lugar, el receptor calcula el tiempo de ida y vuelta para cada paquete recibido. La
diferencia en tiempos de tránsito entre dos paquetes adyacentes se calcula siguiendo la
formula que se da a continuación:
Las variables se definen como:
• D(i,j) es la diferencia en los tiempos de tránsito entre los paquetes adyacentes i y j.
• RJ es la hora en la que se recibió el paquete j.
• Sj es la hora en la que se envió el paquete j (determinada por la fecha y hora RTP).
• R; es la hora en la que se recibió el paquete i.
• Sj es la hora en la que se envió el paquete i (determinada por la fecha y hora RTP).
Cada paquete de medios RTP entrante provoca un nuevo cálculo de la diferencia de los
tiempos de tránsito entre el actual paquete i recibido y el anterior paquete i-1 recibido. En
lugar de escribir esta diferencia como D(i-l,i), se considera la sintaxis más simple Dj. [9]
5.11. Uso de Gateways en Asterisk.
Los gateways proporcionan interworking con tecnologías que no son H.323, como
videoconferencias RDSI H.320 [3] o redes telefónicas tradicionales. Un ejemplo de
gateway H.323 es un router Cisco con interfaces de voz. Un teléfono puede
conectarse a la PSTN a través del gateway Cisco, y aparecer para la red H.323
como un punto final H.323 (aunque limitado para las capacidades de audio). Un
21
punto final H.323, por su parte, puede colocar una llamada en la PSTN a través del
gateway Cisco, y aparecerá la llamada como generada por un abonado telefónico.
La siguiente figura representa la estructura lógica de un Gateway para telefonía
IP.
Red
H323
PSTN
Función de
conversión
del Gateway
Asterisk
Terminal
H323
(MCU)
Punto final
PSTN
Gateway H323 a la PSTN
Figura 11. Estructura lógica de un Gateway en H323 sobre Asterisk
Se observa que los gateways administran 1) la conversión de señalización de llamada, 2)
la conversión de señalización de medios y 3) la conversión de medios cuando se conecta
una red H.323 a otra de distinto tipo. Para que los gateways VoIP/PSTN puedan escalar
económicamente grandes volúmenes de tráfico, tanto la IETF como la ITU dividen los
componentes funcionales de un gateway y definen las interacciones estándar de los
mismos.
5.12. Uso de Gatekeeper
Como su nombre indica, un gatekeeper H.323 controla una zona H.323. Al igual
que el centinela de un castillo, que controla quien entra y quién sale, un
gatekeeper H.323 regula los puntos finales dentro de su zona que pueden iniciar o
recibir llamadas. Un gatekeepeer H.323 también puede regular el procedimiento
de las llamadas, permitiendo la comunicación directa entre los puntos finales, o
bien actuando como intermediario para transmitir la señalización de llamada.
Una zona H.323 es el conjunto de dispositivos administrativamente definidos que
controla un gatekeeper. La ultima versión de H.323 trata el asunto relacionado
22
con la redundancia de un gatekeeper en una zona, pero no se refiere al equilibrio
de la carga para varios gatekeepers dentro de una zona.
H.323 permite que un gatekeeper este activo dentro de una zona en un momento
determinado.
Los gatekeepers no son un requisito obligatorio en las redes H.323. Las
recomendaciones H.323 especifican que, cuando los
gatekeepers están
presentes, deben desarrollar las siguientes funciones para los puntos finales:
• Traducción de la dirección.
• Control de admisiones y ancho de banda.
Se aclara que un gatekeeper debe proporcionar estos servicios solo para los
puntos finales que se encuentran en la zona del gatekeeper que se ha registrado
con este.
• Traducción de la dirección:
El gatekeeper convierte los alias de H.323 o E.164 en direcciones de red e
identificadores de puntos de acceso del servicio de transporte (TSAP). Por
ejemplo, un gatekeeper puede recibir una petición de llamada desde un terminal
para gustavoa.herazop@fukl.edu.co
o +1-408-555-1212. El gateway debe
convertir estas direcciones en una dirección IP (como 192.168.254.1) y un número
de puerto TCP o UDP (como el puerto TCP 1720 para el establecimiento de la
conexión H.225.0). [2], [11]
• Control de admisiones y ancho de banda:
En el control de admisiones, el gatekeeper autoriza terminales, gateways y MCU
para colocar las llamadas en la red a través del canal RAS H.225.0. El control de
admisiones es la parte A de RAS. El gatekeeper emite los mensajes de
confirmación de admisión (ACF) o rechazo de la misma (ARJ), en respuesta a los
mensajes de petición de admisión (ARQ) procedentes de los puntos finales. La
decisión puede basarse en el criterio de no especificación dentro de H.323, o un
sistema menos complejo puede aceptar todas las peticiones. En respuesta a las
23
peticiones de ancho de banda (BRQ) de los puntos finales, un gatekeeper envía
mensajes de confirmación del ancho de banda (BCF) o rechazo de la misma
(BRJ). Solo en el caso del control de admisión, el control del ancho de banda se
puede basar en criterios mas alía de H.323, o en una simple política de aceptación
de todo. [12]
• Funciones opcionales del Gatekeeper:
Los gatekeepers ofrecen un mecanismo centralizado para administrar planes de
Conexión y enrutamiento de llamada en una red VolP. Sin ellos, cada gateway
VolP debe mantener información de enrutamiento de llamada (iguales de llamada)
para cualquier otro destino, a no ser que se implemente un método de
enrutamiento de llamada distinto de H.323.
Los gatekeepers proporcionan acceso a las funciones de autenticación,
autorización y recuento (AAA), esenciales en los sistemas de seguridad y
facturación. La interacción de nodo entre los gatekeepers y otros sistemas de
funciones AAA no se encuentra en el ambito de H.323.
Los gatekeepers proporcionan un punto centralizado para la localización de
recursos basados en políticas. Por ejemplo, un servidor de políticas puede instruir
a un gatekeeper para que registre llamadas en base al destino, disponibilidad de
ancho de banda, privilegio del usuario, fecha del día, etc. [1], [2]
Los gatekeepers facilitan el control de llamadas a terceros, esencial en entornos
call-center y otras aplicaciones especializadas en llamadas. Por ejemplo, un
automarcador en un centro de llamadas salientes puede iniciar llamadas a clientes
objetivo, y conectar un agente call-center después de que el cliente conteste el
teléfono. Por estos motivos, se debería considerar los gatekeepers como parte
esencial para todas las instalaciones VolP básicas que usen H.323.
5.13. DIRECCIONAMIENTO
H.323 emplea un esquema de nombres independiente de la tecnología subyacente de la
red, e identifica los requisitos específicos de dirección para H.323 sobre IP, el protocolo
de red estándar entre los cuales se encuentran:
24
•
Identificadores de punto de acceso al servicio de transporte y direcciones (TSAP).
•
Alias H.323.
•
Convenciones de alias para la comunicación interzonal.
•
Determinación de las direcciones de red e identificadores TSAP. [4]
2.16. Direcciones de Red e identificadores TSAP
El establecimiento de la comunicación con cualquier dispositivo H.323 requiere del
conocimiento de su dirección de red y un
identificador TSAP. En el caso de redes IP, la
dirección de red es una dirección IP, y el identificador TSAP un número de puerto TCP o
UDP.
Todas las entidades H.323 deben tener, como mínimo, una dirección
de red (dirección
IP), pero pueden tener múltiples direcciones de red en lo referente a la redundancia (es
decir, una dirección separada para cada interfaz física). Los routers no necesitan
direcciones múltiples para la redundancia, ya que una interfaz loopback lógicamente
definida permite la comunicación a través de cualquier interfaz física activa.
2.17.
Alias H323
Dado que las direcciones de red y los identificadores TSAP no son fáciles de recordar,
H.323 proporciona alias para identificar los puntos finales y conferencias multiparte. (Un
alias de conferencia se resuelve a la dirección de red e identificadores TSAP del MC de la
conferencia.) Se observa que los gatekeepers y dispositivos MP no utilizan los apodos
H.323 porque no se les puede llamar directamente. [6], [9]
Y por qué no utilizar nombres DNS en lugar de alias H.323? H.323 esta diseñado para ser
utilizado con cualquier capa de red, y puede operar independientemente de IP. En lugar
de confiar en una resolución de red dependiente del nombre, H.323 específica que los
gatekeepers introduzcan alias en las direcciones de red e identificadores TSAP (los gatekeepers obtienen esta información cuando los puntos finales se registran con ellos). Los
alias H.323 pueden tener varias formas:
• Cadenas alfanuméricas: gustavo, gustavo@host.com, host.com, cadenas arbitrarias.
25
• Direcciones E.164: +1-408-555-1212, 5551212, 4199.
2.18.
Convenciones de alias para la comunicación interzonal
Los alias H.323 cobran importancia dentro de una zona sencilla. Para alcanzar los puntos
finales en una zona distinta, el nombre de dicha zona debería formar parte de los alias
H.323. En el caso de implementaciones de H.323, es importante establecer una
convención relacionada con el alias, como, por ejemplo, usuario@nombre_zona, donde
usuario es un ID de e-mail o cualquier otro identificador personal utilizado en una
empresa. Además, tenga en cuenta que nombre_zona debe coincidir con el nombre de
dominio DNS donde reside el gatekeeper.
La cadena completa usuario@nombre_zona es el alias H.323. Esta convención de
nombre permite la utilización de DNS para superar el abatimiento en la comunicación
interzonal de H.323.
Si los gatekeepers son extensos, es posible que muchos aparezcan (para distintas zonas
H.323) en el mismo dominio DNS. Este es un diseño aceptable (y el más sencillo para
asegurar la consistencia de los apodos H.323), pero sea consciente de las deficiencias de
este enfoque. Cuando un gatekeeper está incapacitado para introducir un alias, pregunta
a todos los gatekeepers en el dominio DNS especificado por el alias H.323. Si todos ellos
se encuentran en un dominio DNS sencillo, entonces cada gatekeeper es obligado a
procesar las solicitudes de localización (LRQ) para cada zona H.323. La mayor parte del
trafico LRQ que recibe cada gatekeeper estará en puntos finales no locales.
Si los gatekeeper no pueden procesar todo el trafico adicional, necesitara imponer una
capa extra de jerarquía DNS que solo utilizaran los gatekeepers H323, para prevenir la
sobrecarga de los gatekeepers. Por ejemplo, si una empresa posee un gran dominio
denominado empresa.com, puede crear zonal.empresa.com, zona2.empresa.com, o
cualquier otro nombre que coincida con el de su empresa. Por tanto se asigna cada
gatekeeper a una zona nueva distinta, pero no se debe cambiar el registro DNS ya
existente de los puntos finales. Dicho de otro modo, todos los puntos finales deberían
permanecer en el dominio DNS empresa.com, mientras cada gatekeeper se encuentra en
un subdominio DNS distinto de empresa.com. Cada zona H.323 (identificada por un
26
subdominio DNS del dominio principal de la empresa) debería alternar los gatekeepers
ante posibles fallos de tolerancia.
Un registro SRV [3], [10] correspondiente al servicio de descubrimiento del gatekeeper.
Son posibles distintas variaciones de la implementación. El punto final puede emitir la
consulta SRV usando su propio dominio, lo que implica que el gateway y el gatekeeper
están en el mismo dominio. Esto puede ser un problema en determinados diseños.
El punto final también se puede configurar con un nombre de dominio para el gatekeeper,
lo que determina la zona a la que pertenece. Ambos métodos influyen en la fuerza de los
registros SRV; es decir, la dirección IP de un puerto UDP para el descubrimiento del
gatekeeper puede cambiarse para cuestiones relacionadas con el mantenimiento, la
administración o la seguridad, sin necesidad de volver a configurar cada cliente.
2.19.
Registros TXT
Si no se ha implementado una versión de DNS que soporte registros SRV, se puede usar
registros TXT para desarrollar funciones parecidas. Un servidor DNS responde a una
consulta TXT devolviendo una lista de todos los registros TXT para el dominio consultado.
Para esto se puede crear un registro para cada gatekeeper de un dominio con la siguiente
sintaxis:
ras [< gk id>@]<nombre de dominio>[:<numeropuerto>] [<prioridad>]
Incluso si se está utilizando registros TXT para otros propósitos, la palabra clave ras
permite al cliente H.323 filtrar los registros TXT que no se necesitan. Esta sintaxis permite
a un punto final H.323 descubrir el gatekeeper de forma análoga a los registros SRV.
Los métodos SRV y TXT de descubrimiento del gatekeeper introducen un nuevo
comportamiento de H.323:
Si existen múltiples gatekeepers en el mismo dominio DNS, los puntos finales pueden
registrarse aleatoriamente con cualquier gatekeeper (lo que identifica una zona H.323)
que se encuentre en el dominio DNS. En estos casos, las zonas H.323 distintas solo
existen para limitar el número de usuarios por gatekeeper Presumiblemente los
27
gatekeeper se configuran para rechazar solicitudes de registro de puntos finales cuando
hayan alcanzado su límite de proceso. Para que este desafío funcione correctamente,
cada zona H.323 (es decir, los gatekeepers) dentro de un dominio DNS debería tener
políticas consistentes y privilegios de acceso al gateway. Todos los puntos finales tendrán
un alias H.323: usuario@dominio.com, y no importa la zona actual H.323 en la que está
registrado el punto final (excepto cuando se trata de resolver problemas).
Cuando un gatekeeper recibe una solicitud para un alias H.323 en una zona distinta, el
envía un LRQ al gatekeeper de la zona de destino H.323. Las soluciones DNS determinan
esta zona buscando el nombre de dominio especificado en el alias H.323 de destino. Si se
localizan múltiples gatekeepers en el dominio DNS especificado por el alias H.323, el
nombre de dominio DNS no se asignara únicamente a una zona H.323. Un gatekeeper
que intente resolver un alias desde una zona diferente deberá entonces enviar un LRQ a
cada uno de los gatekeepers del dominio DNS especificados por el alias H.323.
El gatekeeper correcto responderá con un LCF, pero los otros gatekeepers del dominio
deben procesar la consulta y devolver un LRJ. Si existen muchos gatekeepers en un
dominio sencillo, los mensajes LRQ/LRJ adicionales pueden convertirse en un asunto
legítimo.
2.20. Control de llamadas en Asterisk con H.225.0
Cuando los puntos finales inician una solicitud de conexión de llamada, deben determinar
la dirección de la red y el identificador TSAP de destino. Los puntos finales pueden
descubrir esta información "fuera de banda" (por ejemplo, mediante un mensaje de email),
que se encuentra fuera del alcance de H.323. Además, los puntos finales pueden iniciar
una conexión basada en un alias H.323. En este caso, es responsabilidad del gatekeeper
resolver el alias para una dirección de la red y el identificador TSAP.
El identificador TSAP predeterminado para todos los canales de control de llamada
H.225.0 es el puerto TCP 1720. Un punto final puede avisar de que un identificador TSAP
se encuentra en su mensaje de registro del gatekeeper, lo que es transparente para otros
puntos finales que inician llamadas a los alias H.323. Los puntos finales que inician
28
llamadas a las direcciones IP y números de puerto TCP deben averiguar el número de
puerto determinado a través de un método de fuera de banda.
2.21
Control de llamadas en Asterisk con Medios H.245
La dirección de la red y los identificadores TSAP para canales de control de medios H.245
no son necesarios en asterisk, ya que los puntos finales y las MCU que necesitan
establecer canales H.245 ya están comunicándose a través de un canal de control de
llamada H.225.0. Las direcciones de red para la comunicación H.245 son las mismas que
para el canal de control H.225.0 existente, y las direcciones TSAP para H.245 se
negocian sobre el canal de control de llamada.
El control de llamadas en H.225.0 es un canal fiable por el que se intercambian
conexiones de llamadas, cancelaciones y mensajes de servicio suplementarios. Por
defecto, los puntos finales responden al puerto TCP 1720 de las peticiones de llamadas
entrantes. Los puntos finales pueden recibir llamadas de un puerto TCP diferente y
publicar este puerto a un gatekeeper para la resolución de un alias H323. [2], [3], [9]
PBX
PBX
H323 Zona1
H323 Zona2
GRQ
GRQ
GCF
GCF
RRQ
RRQ
RCF
ARQ
RCF
LRQ
ACF
LCF
MENSAJE DE CONEXIÓN H225.0
ARQ
ACF
SEÑALIZACION H225.0 Y H245..MEDIO ESTABLECIDO
LLAMADA ACTIVA
DRQ
DRQ
DCF
DCF
Figura 12. Intercambio entre puntos finales a través de H225 en Asterisk
29
2.22.
PROTOCOLO SIP EN ASTERISK
Session Initiation Protocol (SIP) es un protocolo de señalización utilizado para el
establecimiento de períodos de sesiones en una red IP, en especial Asterisk. Un sesión
puede ser un período simple bidireccional o llamada telefónica que podría ser una
colaboración multimedios o de de comunicación de conferencias.
La capacidad de establecer estos períodos de sesiones significa que una serie de
servicios innovadores, tales como la voz con el comercio electrónico, las páginas web que
se utilizan para telefonía, la mensajería instantánea o chat y los servicios IP Centrex.
Durante el último par de años, la Voz sobre IP SIP ha adoptado su protocolo de elección
para la señalización. SIP basado en la RFC standard 3261.
SIP es un estándar de la Internet Engineering Task Force (IETF), y es el órgano
encargado de administrar y desarrollar los mecanismos que conforman la Internet. SIP
sigue evolucionando y está ampliando a medida que la tecnología madure.
SIP es mucho más que un molde, ha sido desarrollado exclusivamente como un
mecanismo para establecer sesiones de alta capacidad en telefonía IP, en este protocolo
no se conocen los detalles de los períodos de sesiones, sólo se inicia, termina y se
modifican las sesiones. Esto significa que la simplicidad de SIP es escalable, es
extensible, y está sentado cómodamente en diferentes arquitecturas y escenarios de
despliegue lo que lo hace muy poderoso.
SIP es un protocolo de petición-respuesta que se asemeja a otros dos protocolos de
Internet, HTTP y SMTP (los protocolos de poder de la world wide web y correo
electrónico) y, por consiguiente, SIP es similar al de las aplicaciones de Internet.
Gracias al uso de SIP, la telefonía se convierte en otra aplicación Web y se integra
fácilmente con otros servicios de Internet. SIP es un simple conjunto de herramientas que
los proveedores de servicios pueden utilizar para construir aplicaciones de convergencia
de voz y servicios multimedia. [7], [8], [11]
Con el fin de proporcionar servicios de telefonía existe una serie de normas y protocolos
para implementar y garantizar el transporte (RTP), para autenticar a los usuarios (radio,
30
diámetro), para proporcionar directorios (LDAP), para poder garantizar una calidad de voz
(RSVP, YESSIR) y entre otros a trabajar con la actual red telefónica.
2.23.
Atributos del protocolo SIP
SIP se diseno como una solución a largo plazo para las conferencias multimedia y la
telefonía en Internet. Se han tenido en cuenta muchas consideraciones con el desarrollo
del protocolo para asegurarse de que es una plataforma viable para futuras
comunicaciones que se basen en Internet:
Simplicidad. A diferencia de la mayoría de los protocolos de telefonía e Internet, SIP
emplea mensajes de texto piano que se pueden leer. Seguidos, además, de formatos
estándares como HTTP 1.1 y "mailto:". Esto hace que el protocolo sea relativamente
sencillo para resolver problemas e integrarse con otras aplicaciones.
Eficiencia. El protocolo superior de SIP tiene poco impacto en la eficiencia de la
comunicación, puesto que las funciones de señalización consumen poco ancho de banda
en relación con el flujo de medios. SIP es muy eficaz en términos de tiempo de conexión
de llamada, ya que toda la información que se pide para el establecimiento de la llamada
se incluye en el mensaje inicial.
Escalabilidad. Los servidores no mantienen la información del estado de las sesiones
basadas en UDP en el SIP que procesan, por lo que un solo servidor puede manipular
eficientemente muchos clientes. Los bucles de enrutamiento de mensajes, que pueden
consumir grandes recursos de red, son más comunes a medida que crece la red. SIP
detecta y previene los bucles de enrutamiento de mensajes, lo que aumenta el
rendimiento de las redes extensas
Flexibilidad. Dado que SIP usa SDP para negociar los codecs, se puede utilizar cualquier
codec registrado por la Agenda de asignación de números Internet (IANA). Al contrario
que H.323, donde los codecs se definen explícitamente como parte del cambio lento
estándar, el resto de codecs deben compartir un campo genérico para los "codecs no
estándar".
31
Soporte de movilidad. El modelo de comunicación SIP se dirige a los usuarios que se
pueden mover de terminal a terminal (por ejemplo, teléfonos y computadoras), lo contrario
a los terminales en si mismos. El protocolo proporciona un enorme soporte para proxying
y redirección, por lo que los usuarios tienen la opción de proporcionar u ocultar su
verdadera ubicación.
Programación del usuario. Además del soporte nativo para las funciones de telefonía
tradicional (por ejemplo, reenvió de llamada, transferencia, retención, conferencia y
demás), SIP puede aprovecharse del Lenguaje de procesamiento de llamada (CPL, Call
Processing Language). Este permite a los usuarios proporcionar reglas complejas a un
servidor, sin importar quien pueda localizarlas, cuando, donde y con qué tipo de medios.
Los sistemas H.323 también se pueden aprovechar de CPL. Las herramientas como los
servlets j las extensiones de la interfaz de gateway común (CGI) de SIP se estandarizan
actualmente, lo que facilita el desarrollo de las aplicaciones que este permite.
Extensión. Los creadores del protocolo reconocieron que no podían prever todas las
peticiones de dicho protocolo, por lo que crearon una arquitectura que fuese modular y
flexible. Esto permite mejorar el incremento y las extensiones del protocolo, mientras
asegura una operación más cercana a las versiones más antiguas. También facilita la
posibilidad de retirar las opciones de protocolos no usadas, lo que evitara que dicho
protocolo se haga poco manejable.
2.24.
Componentes del Sistema
Los Agentes del usuario (UA) son las aplicaciones de punto final que envían y reciben
peticiones SIP para beneficio de los usuarios (por ejemplo, personas o sistemas
automatizados). Los Clientes de agentes del usuario (UAC) envían peticiones SIP a la
parte llamante, y los Servidores de agentes del usuario (UAS) reciben las respuestas de la
parte llamada. Cada usuario puede tener varios agentes del usuario. Por ejemplo, puede
tener agentes de usuario independientes para el teléfono de su oficina, de su casa, su
móvil y su computadora multimedia. Se asocia una dirección SIP con cada agente del
usuario.
32
Los Servidores proxy son aplicaciones que reciben peticiones SIP de clientes, e inician
nuevas peticiones para beneficio de los clientes hacia los agentes del usuario de destino.
Puede ver a los servidores proxy como routers SIP, que remiten mensajes de señalización
de llamada hacia el destino. Este comportamiento es análogo al de la señalización
enrutada de gatekeeper (GKRS) en H.323. También es parecido al de los gateways de
correo SMTP, excepto en que los mensajes deben ser remitidos en tiempo real.
La información que emplea un servidor proxy para dirigir peticiones SIP, va mas alía del
ámbito de la especificación SIP. Los servidores proxy SIP pueden tener un
reconocimiento local de los agentes de usuario desde un registrador SIP. También
pueden conocer varias alternativas para localizar a un agente de usuario, y pueden
intentar cada una de ellas en un proceso de bifurcación que puede ser paralelo o
secuencial. Dependiendo de la configuración del proxy SIP, las respuestas pueden fluir a
través de los servidores proxy en dirección opuesta al de las peticiones, o pueden fluir
directamente hacia el emisor original del mensaje de Invitación SIP. Estos servidores
pueden proporcionar también una dirección de redirección para los clientes solicitantes en
lugar de reenviar la solicitud SIP. [7]
Los Registradores aceptan registros de clientes que indican las direcciones en las que se
les puede localizar. La funcionalidad de los registradores se combina frecuentemente con
un proxy o con un servidor de redirección, pero este es un proceso lógico separado y esta
oficialmente fuera del ámbito de SIP. Por ejemplo, un registrador SIP puede ser una
extensión de software en una base de datos LDAP que contenga un directorio de
usuarios.
2.25.
Direccionamiento de SIP
Aunque los servidores proxy, los servidores de redirección y los registradores
pueden entrar en una transacción SIP, solo los usuarios y los agentes de usuario
tienen direcciones SIP. Los servidores SIP (como proxy, de redirección y
registradores) solo se identifican por las direcciones IP y los puertos TCP/UDP.
Por defecto, los servidores SIP escuchan en los puertos TCP y UDP 5060, pero
pueden utilizar cualquier número de puerto. [8]
33
2.26.
Sintaxis de la Dirección SIP
La sintaxis de un URL SIP se modela después de la RFC 2396, con el título "Uniform
Resource Identifiers (URI): Generic Syntax". Un URL SIP básico tiene el siguiente
formato:
"sip:"
[ user [ ":" password ] "@" ] ((hostname [IP-address )[ ::port ] Algunos ejemplos de
URL SIP son los siguientes:
sip:gustavo@company.com
sip:lizza@192.168.100.248
sip:lizza:secret@company.com
sip:gustavo:secret@company.com:5060
sip:luiscarlos@192.168.100.248:5060
Un URL SIP también puede incluir parámetros e información de cabecera, con la siguiente
sintaxis añadida al URL SIP básico:
[";"param "="value ]["?"1st_header "="value ["&"other_headers "="value ]]
Un URL SIP puede tener varios parámetros y campos de cabecera, como se indica en los
ejemplos siguientes:
sip:gustavo@company.com;transport=udp
Otra opción que no requiere estándares nuevos es utilizar la opción (66) de servidor TFTP
de DHCP y tener al cliente UA descargando un archivo de configuración que contenga el
nombre de dominio DNS, o la dirección IP y el puerto TCP del servidor SIP. Esta opción
es muy practica y está disponible actualmente, lo que permite que los clientes SIP UA
sean completamente portátiles.
Los clientes SIP utilizan por defecto el puerto TCP/UDP 5060 para localizar un servidor
SIP, pero emplearan cualquier puerto que este especificado en un URL SIP (devuelto por
una consulta DNS SRV) o configurado mediante TFTP en el momento del inicio.
34
2.27.
Método de registro SIP
Los agentes de usuario SIP se pueden configurar estáticamente para la
localización de un registrador SIP, o pueden emplear la multidifusión para
encontrarlo. La dirección multidifusión bien conocida para que los clientes
Colombianos se registren con un registrador es 224.0.1.75. Hay también un
nombre DNS para estas direcciones, y es sip.mcast.net.
Si utiliza el método multidifusión para localizar registradores, siempre se debe
asegurar de limitar el alcance de las direcciones multidifusión, ya que las
solicitudes de registro SIP nunca abandonan el dominio administrativo (a no ser
que se quiera que determinados clientes se registren en registradores SIP ajenos).
Para limitar el alcance de las direcciones multidifusión, se puede utilizar las Listas
de acceso de los routers fronterizos de multidifusión, o reducir el tamaño del
campo TTL en la cabecera IP basándose en el diámetro de la red.
Es importante que tenga en cuenta que los agentes de usuario SIP de la red
pueden escuchar las direcciones multifusion del registrador SIP para aprender de
la presencia de otros agentes de usuario. Esta técnica puede ser un mecanismo
eficiente para que los agentes de usuario desarrollen mallas localizables en un
dominio administrativo, cuando no existe un servidor proxy local. Sin embargo,
este método puede suponer un trabajo adicional. [7], [8]
Muchos códigos de respuesta SIP/2.0 en cada categoría son idénticos a los
códigos de respuesta HTTP/1.1 correspondientes. Los códigos SIP en una
categoría no coinciden con los códigos HTTP existentes, que normalmente utilizan
el rango x80 a x99, mientras que los nuevos códigos de respuesta HTTP serán
asignados por debajo de x80. Esta consideración permite a SIP y a HTTP adoptar
cada uno de los códigos nuevos ajenos y mantener la consistencia. La
consistencia del código de respuesta es importante porque SIP y HTTP se unen
para compartir los mismos componentes de la aplicación del servidor (por ejemplo,
analizadores sintácticos, tratamiento de errores, etc.).
35
SIP introduce la categoría de códigos 6xx para distinguir entre las respuestas de
error que pudiesen producirse en cualquier servidor y las respuestas de error que
son únicos para un servidor en concreto. Por ejemplo, un servidor UA puede
declinar la respuesta de un cliente porque este ocupado (lo cual es una respuesta
de error por parte de un servidor), pero el cliente necesita saber si debería seguir
con la solicitud en otra parte. El usuario llamado puede que desee estar
ilocalizable para cualquier origen (no molestar en una configuración global), por lo
que el servidor UA puede informar al cliente de su estado con una repuesta 600
denominada “busy everywhere”. El cliente entonces sabe que tiene que dejar de
enviar solicitudes INVITE a otros servidores UA del usuario.
Si un cliente recibe un código de respuesta SIP no reconocido, negocia la
respuesta como una respuesta xOO para una categoría determinada. Este
comportamiento asegura la compatibilidad retrospectiva con los clientes SIP más
antiguos, además de permitir extensiones para los códigos de respuesta SIP. [2],
[8]
Los códigos de respuesta SIP para SIP/2.0 se muestran en la siguiente tabla:
Código
Código
Descripción de la
respuesta
100
180
Intentando
Ringing
411
413
181
La llamada esta
414
182
En cola
415
183
200
Progreso de la sesión
OK
420
480
300
Opciones múltiple
481
301
Movido
permanentemente
Movido
482
302
483
Descripción de la
respuesta
Longitud requerida
Entidad solicitada
demasiado
Solicitud-URI
demasiado grande
Tipo de medio no
soportado
Extensión errónea
No disponible
temporalmente
Circuito de
llamada o
transacción
Detectado un
bucle
Demasiados saltos
36
temporalmente
303
Ver otro
484
305
380
400
Utilizar proxy
Servicio alternativo
Respuesta mala
485
486
487
401
402
Sin autorización
Pago requerido
488
500
403
404
405
Prohibido
No encontrado
Método no permitido
501
502
503
406
No aceptable
504
407
Se requiere
autenticación
Se requiere límite de
tiempo
Conflicto
Hecho
505
408
409
410
600
603
604
606
Dirección
incompleta
Ambiguo
Ocupado aquí
Solicitud
terminada
No aceptable aquí
Error interior del
servidor
No implementado
Gateway erróneo
Servicio no
disponible
Limite de tiempo
del gateway
Versión de SIP no
soportada
Ocupado
completamente
Declinar
No existe en
cualquier parte
No aceptable
Tabla 3. Códigos de respuesta SIP
2.28.
Cabeceras SIP
Las cabeceras en los mensajes SIP efectúan la misma función que los campos en una
cabecera de protocolo normal. Es decir, cada cabecera SIP representa un valor variable
que se transporta a través de la red. Algunas cabeceras SIP son obligatorias en cada
mensaje, y otras se utilizan departiendo del tipo de solicitud o de respuesta. El formato
general para las cabeceras SIP es:
<Nombre cabecera>: <Valor cabecera>
<Continuación de valor de cabecera>
El valor de la cabecera es una o más líneas de información. Los espacios en blanco a la
izquierda identifican las continuaciones de la cabecera multilinea. Una clave de
37
encriptación PGP es un ejemplo de valor de cabecera que necesita varias líneas. Algunos
ejemplos de una sola línea son los siguientes:
From: sip:102@2.0.0.1
User-Agent: Cisco VolP Gateway/ IOS 12.x/ SIP enabled
Content-Type: application/sdp
El orden en el que aparecen las cabeceras SIP en el mensaje no es importante, salvo dos
excepciones: Cuando aparecen en el orden en el que las respuestas SIP deberían fluir de
regreso a través de los servidores proxy para conectarse con el UA de la parte llamante.
Las cabeceras Hop-by-Hop (es decir, las cabeceras que se deberían procesar en los
servidores proxy) tendrían que aparecer antes que las cabeceras End-to-End (como las
cabeceras para los UA de las partes llamante y llamada). [7]
Los detalles de la sesión, tales como el medio de comunicación, el codec, o la
frecuencia de muestreo, no se describen usando SIP. Por el contrario el cuerpo
del mensaje contiene una descripción del periodo de la sesión, codificado en otro
formato como SDP
Existen seis métodos básicos SIP (definidos en RFC 254)11 que describen las
peticiones de los clients:






INVITE: Permite invitar un usuario o servicio para participar en una sesión o
Para modificar parámetros en una sesión ya existente.
ACK: Confirma el establecimiento de una sesión.
OPTION: Solicita información sobre las capacidades de un servidor.
BYE: Indica la terminación de una sesión.
CANCEL: Cancela una petición pendiente.
REGISTER: Registrar al User Agent.
A continuación se mencionaran las respuestas más comunes de este protocolo:
11
RFC 254. Estándares sobre las peticiones y códigos de repuesta en el protocolo SIP.
38
Codigo
Descripcion
100
Trying (Indica intentando la llamada)
180
Ringing (Indica que suena el UA que se llama)
Call is being forwarded (Indica que la llamada es
desviada)
181
182
Queued (LLamada encolada)
Session progress (Indica el progreso de una
sesión SIP)
183
200
OK
202
Accepted
300
Multiple choices
301
302
305
380
400
401
402
403
404
405
406
407
408
409
410
411
413
414
415
420
480
481
482
483
484
485
486
487
488
500
501
502
503
504
505
600
603
604
606
Moved permanently (Indica que el UA/Server ha
sido movido permanentemente a otra dirección.
Moved temporarily (Movido temporalmente)
Use proxy (Necesario usar proxy)
Alternative service
Bad request (Petición errónea)
Unauthorized (Petición sin autorizar)
Payment required (Necesario pago de la
llamada)
Forbidden (Petición no permitida , a números no
permitidos etc...)
Not found (NO se encuentra el UA llamado)
Method not allowed
Not acceptable
Proxy authentication required (Necesiario
autenticar el INVITE )
Request time-out
Conflict
Gone
Length required
Request entity too
Request-URI too large
Unsupported media type
Bad extension
Temporarily not available
Call leg/transaction does not exist
Loop detected
Too many hops
Address incomplete
Ambiguous
Busy here
Request cancelled
Not acceptable here
Internal servere error
Not implemented
Bad gateway
Service unavailable
Gateway time-out
SIP version not supported
Busy everywhere
Decline
Does not exist anywhere
Not acceptable
Tabla 4. Respuestas más comunes del protocolo SIP
39
2.29.
MGCP (Media Gateway Controller Protocol)
Es conocido como el protocolo MEGACO, H.248, es un estándar que posibilita a un MGC
controlar uno o varios MG's (establecer, modificar y terminar conexiones en los MG's). Es
un protocolo de control de dispositivos más no de señalización de VoIP.
MGCP es un protocolo basado en texto y soporta un modelo de llamada centralizado. Es
un protocolo que no requiere una maquina de estados para describir una secuencia de
transacciones entre dos entidades de señalización, y tampoco mantiene memoria de las
transacciones previas entre el MGCP y los MG's.
El MGCP utiliza el protocolo SDP (Session Description Protocol) para describir la sesión,
lo que quiere decir: el nombre y el propósito de la sesión, tiempo en que la sesión está
activa, requerimientos de ancho de banda, etc.
MGCP se transporta sobre UDP, conformándose la pila MGCP/UDP/IP de tal forma que
los mensajes MGCP constituyen el cuerpo de datos de los datagramas UDP.
40
CAPITULO 3
RESULTADOS OBTENIDOS
3.1
PLATAFORMA DE SISTEMA OPERATIVO
De acuerdo a todas las pruebas obtenidas en función de la daptabilidad de los
componentes de asterisk, se escogió como sistema operativo (OS) Ubuntu 8.10, por las
facilidades que presenta en su configuración respecto a los demás sistemas operativos
evaluados como lo fueron (Debian, Centos y Ubuntu).
De igual manera para las exigencias necesarias del proyecto se adopta, por los mínimos
requerimientos que exige es sus configuraciones de hardware para la versión 8.10
RAM Mínima de 64 Mb
Recomendación en Disco Duro de 4 Gg
Procesador 300Mhz x86
Unidad lectora CD-Rom
Ubuntu presenta y cuenta con los requerimientos de distribución de Debian, lo cual brinda
seguridad en la estabilidad, escalabilidad y funcionalidades de este tipo de distribuciones.
Al nivel de costos y revisando hacia la posible expansión del proyecto Ubuntu ofrece
servicio servidor gratuito a diferencia de otras distribuciones de SO operativo basadas en
RedHat.
Si se revisa el soporte de bases de datos que ofrece Ubuntu presenta interoperabilidad
con motores e interpretadores de corte abierto con Mysql, Apache, PHP, PERL,
componentes que son necesarios para la convergencia de los servicios de asterisk.
41
Los volúmenes se instalaron consistentemente y los valores requeridos en tamaños de
bloques se ajustaron exitosamente a la capacidad de los servidores LINUX para minimizar
los tiempos de consumo de CPU y procesador, como se muestra en la siguiente grafica,
3.2
INICIO DE DESCARGA Y AJUSTES PREVIOS DE INSTALACION DE ASTERISK
LAB. 302 FUKL.
Completando los ajustes del Sistema operativo en cuanto a volumnes, tamaño de
bloques requeridos y minimización de recursos de memoria, se continúa con la segunda
fase de descarga y ajustes iniciales de cada uno de los componentes requeridos para el
proyecto.
ADICION DE COMPONENTES REQUERIDOS PARA EL INICIO DE ASTERISK
PROBLEMA
Error “gcc not found”
No
se
CAUSA
SOLUCION
intaló
gcc #apt-get install gcc
correctamente
Error “g++ not found”
No
se
instaló
g++ #apt-get install g++
correctamente
Error
“C
compiler
cannot Falta el paquete libc-dev
#apt-get install libc-dev
create executables”
Error “ c++ not found”
No
se
instaló
c++ #apt-get install c++
correctamente
Error “gpp not found”
No
se
instaló
gpp #apt-get install gppp
correctamente
Error “aCc not found”
No
se
instaló
aCc #apt-get install aCc
correctamente
Error “Cc not found”
No
se
instaló
Cc
#apt-get install Cc
correctamente
Error “cc++ not found”
No
se
instaló
cc++ #apt-get install cc++
correctamente
Error “cxx not found”
No
se
instaló
cxx #apt-get install cxx
correctamente
42
Error “cl.exe not found”
No
se
instaló
cl #apt-get install cl
correctamente
Error “FCC not found”
No
se
instaló
FCC #apt-get install FCC
correctamente
Error “KCC not found”
No
se
instaló
KCC #apt-get install KCC
correctamente
Error “RCC not found”
No
se
instaló
RCC #apt-get install RCC
correctamente
Error “xlC not found”
No
se
instaló
xlC #apt-get install xlC
correctamente
Error “xlC -r not found”
No
se
instaló
xlC
-r #apt-get install xlC -r
correctamente
DIFICULTADES ENCONTRADAS
PROBLEMA
CAUSA
SOLUCION
Error “ apache2 not found”
No se instaló
apache2 #apt-get install apache2
correctamente
Error “iftop not found”
No
se
instaló
iftop #apt-get install iftop
correctamente
Error “ lame not found”
No
se
instaló
lame #apt-get install lame
correctamente
Error
“libmysqlclient15-dev No
not found”
se
instaló #apt-get
libmysqlclient15-dev
install
libmysqlclient15-dev
correctamente
Error “libncurses5-dev
not found”
Error “libploticus0-dev
not found”
Error “libsox-fmt-all not found”
No se instaló libncurses5- #apt-get
dev correctamente
No se instaló
libncurses5-dev
libploticus0- #apt-get
dev correctamente
install
libploticus0-dev
No se instaló libsox-fmt-all #apt-get install libsox-fmtcorrectamente
Error “linux-source not found”
install
all
No se instaló linux-source #apt-get
install
linux-
43
correctamente
Error
“linux-headers
source
not No se instaló linux-headers #apt-get
found”
correctamente
Error “mpg123 not found”
No
se
install
linux-
headers
instaló
mpg123 #apt-get install mpg123
correctamente
Error “mtop not found”
No
se
instaló
mtop No se encontro
correctamente
Error “mysql-client-5.0
not No se instaló mysql-client- No se encontro
found”
Error
5.0 correctamente
“mysql-doc-5.0
not No se instaló mysql-doc-5.0 No se encontro
found”
Error “mysql-server-5.0
correctamente
not No se instaló mysql-server- No se encontro
found”
5.0 correctamente
Error “mytop not found”
No
se
mytop No se encontro
instaló
correctamente
Error “ntp not found”
No
se
instaló
ntp No se encontro
correctamente
Error “openssh-server not
No
found”
server correctamente
Error “php5 not found”
No
se
se
instaló
openssh- No se encontro
instaló
php5 No se encontro
correctamente
Error “php5-cli not found”
No
se
php5-cli No se encontro
instaló
correctamente
Error “php5-dev not found”
No
se
instaló
php5-dev No se encontro
correctamente
Error “php5-mysql not found”
No se instaló php5-mysql No se encontro
correctamente
Si egError “sipsak not found”
No
se
instaló
sipsak No se encontro
correctamente
Error “sox not found”
No
se
instaló
sox No se encontro
correctamente
Error “subversion not found”
No se instaló subversion No se encontro
correctamente
44
Error “subversion-tools
No se instaló subversion- No se encontro
tools correctamente
not found”
Error “2005 mysql”
3.3. ESTADO DEL ARTE DE LAS FUNCIONALIDADES FRENTE A DIVERSOS
PROVEEDORES
Se tomaron las 3 alternativas lideres en el mercado: Asterisk, Avaya y Cisco
ASTERISK
SIP
Protocolos soportados
AVAYA
SIP
IAX/IAX2
OSPF
MGCP
IGRP
H.323
EIGRP
CISCO SKINNY
Codec
CISCO
RIP
BGP
G.711u
G.729a
G.711 u
G.711a
G.723
G.711 a
G.722
G.711
G.723
G.728
G.729
GSM
Speex
Hadware compatible
Telefonos IP
Teléfono IP Avaya 4602
ATA
Teléfono IP Avaya 4602SW
Placas
Teléfono IP Avaya 4606
Telefonos IP
Teléfono IP Avaya 4630SW
Teléfono digital Avaya 2402
Teléfono digital Avaya 2420
Softphone
Funcionalidades
Software libre
Conmutador Avaya
SoftPhone 1.3
Transferencia
Conferencia
Acceso multiservicio
Música en espera
Correo electronico
Contestador automático
Pickup de llamadas
Correo de voz
Llamada en espera
mensajeria Instantanea
Conferencias
Video
Buzón de voz
Sistema de
personas
Distribución
llamadas
localizacion
de
automatica
de
Colas de llamadas
Buzon de Voz
IVR
Configuración en bases de
datos
Mensajeria instantanea
Procesador Intel Pentium III, Procesador Pentium 4 a 2,8 RAM: 256 MB mínimo, 512 MB
700 MHz
GHz o superior con 256 MB de recomendados para un mejor
Memoria 1 GB de RAM
Memoria 1 GB de RAM
Espacio en Disco 30 MB
Requisitos de instalación
20 GB de espacio en disco
mínimo para poder mantener
en línea un mínimo de 10 GB de
grabaciones (más de 1000
Sistema
Operativo
Linux, Microsoft
Windows
XP
Windows 2000, Windows XP
Professional
SP3/
Vista
Business SP1/ Vista Ultimate
Conexión de Red IP (banda Redes y seguridad TCP/IP,
ancha, LAN)
Internet Explorer 5.0 o versión
Buscar y reproducir llamadas
grabadas mediante un PC y una
tarjeta de sonido de PC
Memoria 1 GB de RAM
Espacio en disco duro: 70 MB
sólo para la aplicación, 200 MB
recomendados
Sistemas operativos: Windows
XP, Service Pack 1 ó superior
Velocidad del procesador: 1 GHz
Las versiones de Windows de
64 bit no se han probado ni se
admiten
oficialmente.
Se
necesitará permiso de escritura
en el directorio inicial y hacia el
directorio de instalación de
Network Assistant para que éste
Cantidad de colores: 65536
Resolución: 1024 x 768
Tamaño de fuente: Pequeño
Arquitectura
Cliente-servidor
SOA(Orientada a servicios)
SOA(Orientada a servicios)
45
Tabla 5. Comparativo entre plataformas Asterisk, Avaya y Cisco.
La plataforma Asterisk se denota como la mejor alternativa, permitiendo integrar las
conexiones telefónicas tradicionales a nuevos sistemas de voz, adicionalmente soporta la
mayor parte de los protocolos utilizados en el mercado. De igual manera porque es una
aplicación de tipo cliente - servidor que permite que terminales clientes se conecten a él.
Los directorios y archivos que se utilizaron en Asterisk son:
Tabla 6. Directorios y archives que se requieren en Asterisk
3.4. ANALISIS DE FUNCIONALIDADES CON WIRESHARK
3.4.1. FUNCIONALIDADES SIP
Todo el análisis de funcionalidades del Grupo de Investigacion se realizo con la
herramienta de software libre “Wireshark”, que es un analizador de protocolos utilizado
para el análisis y solución de problemas en redes de comunicaciones y se considera
como uno de los softwares mas integral y de mejores servicios administrativos en lo
relacionado con la gestión de redes y en especial con la telefonía IP, ya que integra todos
los protocolos de señalización que en ella se utilizan.
46
Esta herramienta ofrece múltiples opciones de organización y filtrado de información. El
siguiente pantallazo despliega en el primer panel la lista de paquetes capturados.
47
Si se ubica el cursor sobre alguno de los paquetes obtendremos información detallada
acerca del mismo, como se muestra a continuación:
Asi mismo obtengo información de los paquetes capturada en bytes.
Con respecto a la información de los paquetes podemos obtener:
Time:
Source:
Destination:
Protocol:
Info:
Tiempo.
Dirección.
Dirección destino del paquete.
Nombre del protocolo del paquete.
Información adicional del contenido del paquete.
Si filtramos la información a través de la expresión (ip.addr==192.168.100.240 &&
ip.addr==192.168.100.249) or (ip.addr==192.168.100.243 && ip.addr==192.168.100.249)
obtendremos la señalización de la llamada, como se muestra a continuación:
48
Figura 13. Señalización bajo el protocolo SIP
49
Esta señalizacion nos indica:
En el tiempo 2,644 la extensión configurada con la dirección IP 192.168.100.240 envía
una petición INVITE que se encuentra bajo la dirección IP 109.168.100.243
A esta petición el servidor responde que su autentificación no fue correcta.
En el tiempo 2,646 el usuario 192.168.100.240 confirma que ha recibido la notificación por
parte del servidor.
En el tiempo 2,649 el usuario registrado bajo la dirección IP192.168.100.240 con el
puerto: 57722 indica al servidor que desea volver a intentar una invitación a la dirección IP
192.168.100.243
En el tiempo 2,650 el servidor envía la petición al usuario solicitado (192.168.100.243)
En el tiempo 2,756 el usuario registrado bajo la dirección IP 192.168.100.243 con puerto:
7460 indica al servidor 192.168.100.249 que ha recibido la solicitud y que la está
procesando.
En el tiempo 2,857 el usuario 192.168.100.243 con puerto: 7460 envía un 180 como señal
de respuesta tomado por el servidor ubicado en la dirección IP 192.168.100.249.
En el tiempo 2,858 el servidor ubicado en la dirección IP 192.168.100.249 retorna con un
ring al usuario (192.168.100.240) quien realizó la petición.
En el tiempo 4,135 el usuario informa lo que ha recibido esta información es tomada por el
servidor (192.168.100.249)
En el tiempo 4,167 el usuario (192.168.100.243) acepta la invitación la cual es tomada por
el servidor (192.168.100.249) quien solicita le confirme que desea aceptar la solicitud, de
esta manera comunica al usuario (192.168.100.240) que la petición ha sido aceptada.
En el tiempo 4,183 a 4,337 existe una sesión multimedia donde hay transmisión de datos
utilizando el codec G711u, bajo cierta sincronización.
3.4.2. FUNCIONALIDADES H323
El protocol H323 y su excelente integracion con IAX2, permite que sus comunicaciones en
tiempo real sean de tipo UDP y esto converge a que en algunas instancias se presenten
algunas perdidas de paquetes de señalizacion, que no representan problemas graves en
la transmission de las comunicaciones, pero permiten obtener ganacia en el consume de
ancho de banda y la sencillez de su señalizacion.
50
En la siguiente grafica se encuentra que el campo Pb tiene un carácter “X”, el cual indica
que en el transcurso del envío de paquetes de la dirección ip 192.168.100.243 a la
dirección ip 192.168.100.249 ocurrió un error
en marcación de tiempo, por parte de
wireshark, es decir, que en el momento de transmisión del paquete wireshark no pudo
tomar el tiempo correcto. Sin embargo, esto no influyo en el flujo normal de la llamada, ya
que esta fue completada en su total, lo cual se confirma en el campo Lost, en donde se
reporta que represento un 0% de paquetes perdidos durante la llamada.
Dentro del análisis del campo Pb, se encuentra que el paquete que presentó error fue el
paquete N. 66 enviado por la dirección Ip 192.168.100.243 (Extensión 9000) a la dirección
Ip 192.168.100.249 (Servidor Asterisk). Sin embargo, esto no influye en la transmisión de
paquetes. De los 2.057 paquetes que fueron transmitidos durante la llamada, 1.020
corresponden a la extensión llamante 8000 con una participación del 49,59% sobre el
total de los paquetes, mientras que la extensión llamada 9000 tuvo una participación de
1.037 paquetes, con una participación del 50.41%.
Src IP addr Dest IP addr
SSRC
Payload
192.168.100.243 192.168.100.249 0xA3F435B GSM 06.10
192.168.100.249 192.168.100.243 0x7CDBB9D1 GSM 06.10
RTP
Packets
Lost
502 0 (0.0%)
488 0 (0.0%)
Max Delta (ms) Max Jitter (ms) Mean Jitter (ms) Pb?
28.99
4.24
3.10
X
34.44
6.19
0.79
Tabla 7. Estadística para protocolo RTP prueba llamada IAX2 a H.323
3.4.3. CONSOLIDADO DE FUNCIONALIDADES H323
Los consolidados generals de pruebas obtenidos durante las llamadas entre extensiones
que tienen configurado el protocolo H.323, cada una de las direcciones IP de las
extensions, envió un promedio de 820 paquetes durante la llamada. Durante la llamada
realizada de una extensión H.323 a una extensión IAX2 , se observa que dentro del
proceso de llamada, la extensión H.323 envía un mayor número de paquetes para
mantener el proceso de llamada que la extensión configurada bajo IAX2, tal cual como se
muestra en la siguiente tabla de resultados obtenidas en cada prueba. Haciendo un
comparativo con la llamada de H.323 a IAX2, se tiene que aunque el tiempo entre la
primera y la ultima trama haya sido mucho más largo en la prueba de H.323 a IAX2, el
51
tiempo utilizado para el envío de paquetes es mucho menor cuando se realiza una
llamada de H.323 a IAX2, tal cual lo soporta el resultado de la transmisión de paquetes
por segundo en cada una de las pruebas. Como se observa en los resultados de la
pruebas que involucran extensiones H.323, la extensión configurada bajo el protocolo
H.323 que realiza llamada a IAX2, es la extensión que transmite el mayor número de
paquetes durante la llamada.
Paquetes
tiempo entre la primera y ultimo paquete (seg)
Prom. Paquetes por segundo (bytes)
Prom. Tamaño de Paquetes
Bytes
Prom. Bytes por segundo
Prom. Mbits por segundo
llamada de extensión H.323 a protocolos
H.323
IAX2
1641
4306
8,762
35,96
187,291
119,743
89,513
83,661
146891
360246
16765,037
10017,865
0,134
0,08
llamada a extensión H.323 de protocolos
sip a h.323
iax2 a h.323
2548
2057
16,320
18,331
156,994
112,212
152,092
84,482
387,531
173780
23877,528
9479,924
0,191
0,076
Tabla 8. Estadística consolidada de H323, IAX, SIP e IAX”
52
CAPITULO 4
CONCLUSIONES Y RECOMENDACIONES
Despues de haber obtenido todo el grupo de pruebas y resultados de cada uno de los
subgrupos de investigacion, se concluye que Asterisk representa una herramienta muy
poderosa que ofrece un alto grado de funcionalidad y escalabilidad en las soluciones de
integracion de voz y datos, ajustándose apropiadamente a los requerimientos que se
necesiten. Adicionalmente como valor agregado, posee una dependencia directa de los
recursos de red, sistema operativo y de la configuración en hardware de la PC en donde
se instale, ya que si se requiere para dar soluciones en comunicación en grandes
empresas que abarquen más de 1000 usuarios será distinto a otra que tan solo posea 10
usuarios.
Para esto, no se debe olvidar que en ambitos diferentes, ya sea para pequeñas, medianas
o grandes empresas se debe ajustar tanto el sistema operative, como el hardware para
que Asterisk funcione correctamente y la arquitectura no presente problemas de retard,
eco o un volume alto de perdida de datos.
Por otro lado los factores que determinaron sus incovenientes fueron:

Su sensibilidad a posibles fallos de software y perdida de datos, esecificamente cuando
se integran los protocolos de señalizacion como H323 e IAX.

Susceptible a fallos de seguridad, determinando riesgos de vulnerabilidad como hackeos
y virus.

Si las personas encargadas de la administracion de asterisk, no tienen buen control de las
politicas de trafico, asterisk puede consumir un elevado consumo de ancho de banda,
minimizando la capacidad de integrar otras arquitecturas de datos.
Para los estándares IAX2 y H323, se tienen grandes diferencias en cuanto el envió de
paquetes, tamaños de tramas, forma de realizar la señalización y empaquetamiento de
datos
El estándar H323 es mucho más robusto que el IAX2, ya que está diseñado para dar
calidad en video conferencias, mientras que el IAX2 está diseñado para otorgar velocidad
y mayor uso de los recursos de banda ancha,
53
Los protocolos ofrecen una configuración propia para que se ajuste a las condiciones de
red y usuarios entre las que se encuentra la configuración de códec y otros
comportamientos propios de cada estándar, pero más allá de esto, el asegurar la calidad
de las llamadas depende también del comportamiento de cada softphone, ya que Asterisk
no posee uno propio, que asegure su buena ejecución.
El que una solución de comunicaciones funcione o no, dentro de una organización
depende de la buena selección. Para que al momento de escoger el protocolo para
realizar las comunicaciones, se escoja por que las necesidades de la organización van
acordes con los objetivos de diseño del protocolo.
54
REFERENCIAS
A. Libros
[1]. Alberto Escudero Pascual. “VoIP para el desarrollo Una guía para crear una
infraestructura de voz en regiones en desarrollo” Edo. Alfaomega RA-MA Grupo Editores.
[2]. Cisco System, “integración de redes de voz y datos”. ISBN- 84-283-2820-X
[3]. Daniel Collins. “ Carrier Grade Voice Over IP”. McGraw-Hill Professional Publishing,
Septiembre 2000
[4]. Bill Douskalis,”IP Telephony – The integration of robust VoIP Services”. Editorial
Prentice Hall, Diciembre 1999
[5]. Syngress Media, Elliot Lewis, Syngress Media, Matt Campisi y Elliott Lewis,” IP
Telephony”. Editoral McGraw-Hill, 1998
[6]. Collin Perkins. “RTP: Audio and Video Fort he Internet”.Editorial McGraw-Hill
telecommunication.
[7]. Alan B. Jonhston. “SIP: Understanding the Session Initiation Protocol, Second Edition
(Hardcover)”.Editorial McGraw-Hill telecommunication.
[8]. Henry Sinnreich. Alab B. Jonhston. “Internet Communications Using SIP: Delivering
VoIP and Multimedia Services with Session Initiation Protocol”.Editorial Wiley. Segunda
Edicion 2007
[9]. Bill Douskails. “IP Telephony: The Integration of Robust VolP Services (HewlettPackard Professional Books).Año 2006
[10]. Walter Goralski. Matthew C. Kolon. “IP Telephony”. McGraw-Hill Professional
Publishing, Agosto 1998
B. Publicaciones periódicas
[11] G. Liu, K. Y. Lee, and H. F. Jordan, “Asterisk The Future of Telephony”. IEEE
Transactions on Telephony IP, vol. 46, pp. 695-701, June 2005.
C. Tesis de Magister
[12] Maybelline Reza Robles, “VOZ SOBRE IP: Análisis del servicio Instalado en la
Facultad de Telemática”. Universidad de Colima, Facultad de Telemática, Junio 2001.
D. Tutoriales o Libros Electrónicos
[13]. Download “The Future of Telephony” Asterisk. http://www.cyberciti.biz/tips/downloadasterisk-howto-tutorial-book.html (Page On line).
E. Entrevista (Comunicación verbal Privada)
Dr. Juan David Abreo. Director General de Tecnología. Proyecto Interconexión WAN –
TELEFONIA IP. SENA. Bogotá. Colombia.
55