Dedicatoria - Fundación Universitaria Konrad Lorenz

ANALISIS DE REQUERIMIENTOS E IMPLEMENTACIÓN DE LA
PLATAFORMA ASTERISK UTILIZANDO ESTANDAR H.323/IAX2
YANNETH DIMAS A.
LUIS CARLOS MORALES S.
Proyecto de grado, presentado como requisito parcial para optar al título
de Ingenieros de Sistemas
Director:
ING. GUSTAVO HERAZO
FUNDACION UNIVERSITARIA KONRAD LORENZ
FACULTAD DE INGENIERÍA DE SISTEMAS Y MATEMÁTICAS
BOGOTÁ D.C.
2009
Nota de Aceptación
______________________________________________
______________________________________________
Presidente del jurado
____________________________________________
____________________________________________
Jurado
____________________________________________
____________________________________________
Jurado
____________________________________________
____________________________________________
Jurado
____________________________________________
____________________________________________
Bogotá 10 de Mayo del 2009
Dedicatoria
Dedicamos este trabajo a nuestras familias
Y seres queridos que nunca dejaron
De creer en nosotros.
Agradecimientos
Gracias a nuestras familias que nos apoyaron incondicionalmente, a nuestros
profesores que nos otorgaron su conocimiento, a nuestro director de proyecto
Gustavo Herazo por darnos la oportunidad de trabajar a su lado y por su
dirección. A William el encargado de las salas de la FUKL, por soportar las
largas horas de trabajo con nosotros y toda la ayuda que nos prestó en este
recorrido y a Leandro Baena nuestro amigo y compañero por brindarnos su
ayuda en momentos de dificultad.
4
CONTENIDO
LISTA DE TABLAS ............................................................................................. 3
LISTA DE FIGURAS ........................................................................................... 6
LISTA DE ANEXOS ............................................................................................ 8
GLOSARIO ......................................................................................................... 9
INTRODUCCIÓN .............................................................................................. 10
1. ASPECTOS INICIALES ................................................................................ 11
1.1. OBJETIVOS ........................................................................................... 11
1.1.1. General............................................................................................. 11
1.1.2. Específicos. ...................................................................................... 11
1.2. PROPOSITO. ......................................................................................... 11
1.3. CRONOGRAMA ..................................................................................... 11
2. MARCO TEORICO. ...................................................................................... 12
2.1. ANTECEDENTES................................................................................... 12
2.1.1. Históricos.......................................................................................... 12
2.1.2. Legales ............................................................................................. 13
2.1.3. Investigativos .................................................................................... 13
2.2. BASES TEORICAS ................................................................................ 13
2.2.1. PBX .................................................... ¡Error! Marcador no definido.
2.2.2. Asterisk y Protocolo H.323 ............................................................... 15
2.2.2.1. Códecs H.323 ................................................................................ 23
2.2.2.2. Protocolos de H.323 ...................................................................... 24
2.2.2.3. Direccionamiento de H.323 ........................................................... 26
2.2.2.4. Proceso de señalización en H.323 ................................................ 27
2.2.2.5. Fases de señalización en H.323.................................................... 32
2.2.3. IAX2 Inter-Asterisk Exchange Protocol............................................. 38
1
2.2.3.1. Tramas de IAX2............................................................................. 38
2.3. TEORIAS GENERICAS BASADAS EN INGENIERIA. ........................... 44
2.4. CONSTRUCCION DEL MARCO CONCEPTUAL ................................... 49
2.4.1. Metas a alcanzar .............................................................................. 49
2.4.2. Enfoque ............................................................................................ 50
2.4.3. Necesidades a satisfacer ................................................................. 50
3. DISEÑO METODOLÓGICO.......................................................................... 51
3.1. TIPO DE INVESTIGACIÒN .................................................................... 51
3.2. ANÁLISIS DE LA SITUACIÓN ACTUAL................................................. 51
3.3. DIAGNÓSTICO DE LA SITUACIÓN ACTUAL ........................................ 52
3.3.1. Sistemas Operativos ........................................................................ 52
3.3.2. Evaluación y selección de la mejor alternativa ................................. 54
3.4. Plan de Pruebas ..................................................................................... 55
3.4.1. Prueba de H323 a H323 ................................................................... 60
3.4.2. Prueba de H323 a IAX2.................................................................... 66
3.4.3. Prueba de H323 a SIP...................................................................... 72
3.4.4. Prueba de SIP a H.323..................................................................... 73
3.4.5. Prueba de SIP a IAX2 ...................................................................... 79
3.4.6. Prueba de IAX2 a IAX2 .................................................................... 84
3.4.7. Prueba de IAX2 a SIP ...................................................................... 90
3.4.8. Prueba de IAX2 a H323.................................................................... 95
3.4.9. Análisis general .............................................................................. 101
4. CONCLUSIONES Y RECOMENDACIONES .............................................. 103
2
LISTA DE TABLAS
Tabla 1. Cronograma ........................................................................................ 11
Tabla 2. Propiedades RTC y Internet ................................................................ 14
Tabla 3. Servicios suplementarios .................................................................... 25
Tabla 4. Mensajes de establecimiento de llamada ........................................... 29
Tabla 5. Mensajes de información de llamada .................................................. 30
Tabla 6. Mensajes de liberación de llamada .................................................... 30
Tabla 7. Mensajes Misceláneas ........................................................................ 30
Tabla 8. Servicios del protocolo H.225 ............................................................. 31
Tabla 9. Valores para type en tramas F ............................................................ 40
Tabla 10. Valor de subclase con tipo de trama para datos de voz................... 41
Tabla 11. Valor de subclase con tipo de trama control ..................................... 41
Tabla 12. Valor de subclase con tipo de trama control iax ............................... 42
Tabla 13. Directorios Asterisk ........................................................................... 45
Tabla 14. Códec y canales en Asterisk ............................................................. 46
Tabla 15. Configuración de los ordenadores para las pruebas ......................... 55
Tabla 16. Configuración de extensiones para pruebas ..................................... 55
Tabla 17. Descripción de tabla plan de pruebas. .............................................. 57
Tabla 18. Definición tabla de protocolos parte A............................................... 57
Tabla 19. Definición de protocolos parte B ....................................................... 58
Tabla 20. Estadística protocolo RTP parte A .................................................... 58
Tabla 21. Estadística protocolo RTP parte B .................................................... 59
Tabla 22. Prueba de h323 a h323..................................................................... 60
Tabla 23. Resumen prueba llamada de H.323 a H.323 .................................... 63
Tabla 24. Estadística para protocolo IP prueba llamada H.323 a H.323........... 63
Tabla 25. Estadística para protocolo TCP prueba llamada H.323 a H.323 ....... 64
Tabla 26. Estadística para protocolo UDP prueba llamada H.323 a H.323 ...... 64
3
Tabla 27. Estadística para protocolo RTP prueba llamada H.323 a H.323 ....... 64
Tabla 28. Resumen de paquetes llamada Prueba 1 ......................................... 65
Tabla 29. Prueba de h323 a iax2 ...................................................................... 66
Tabla 30. Estadísticas generales prueba 2 ....................................................... 68
Tabla 31. Resumen prueba llamada de H.323 a IAX2 ...................................... 69
Tabla 32. Estadística para protocolo IP prueba llamada H.323 a IAX2 ........... 70
Tabla 33. Estadística para protocolo TCP prueba llamada H.323 a IAX2 ........ 70
Tabla 34. Estadística para protocolo UDP prueba llamada H.323 a IAX2 ....... 70
Tabla 35. Estadística para protocolo RTP prueba llamada H.323 a IAX2 ......... 71
Tabla 36. Prueba de H.323 a SIP ..................................................................... 72
Tabla 37. Prueba de SIP a H323 ...................................................................... 73
Tabla 38. Resumen prueba llamada de SIP a H.323 ........................................ 76
Tabla 39. Estadística para protocolo IP prueba llamada SIP a H.323 ............. 76
Tabla 40. Estadística para protocolo TCP prueba llamada SIP a H.323 ........... 76
Tabla 41. Estadística para protocolo UDP prueba llamada SIP a H.323 .......... 77
Tabla 42. Estadística para protocolo RTP prueba llamada SIP a H.323 ........... 77
Tabla 43. Estadísticas generales prueba 4 ....................................................... 78
Tabla 44. Prueba de SIP a IAX2 ....................................................................... 79
Tabla 45. Resumen prueba llamada de SIP a IAX2.......................................... 81
Tabla 46. Estadística para protocolo IP prueba llamada SIP a IAX2 ............... 82
Tabla 47. Estadística para protocolo TCP prueba llamada SIP a IAX2 ............ 82
Tabla 48. Estadística para protocolo UDP prueba llamada SIP a IAX2 ............ 82
Tabla 49. Estadística para protocolo RTP prueba llamada SIP a IAX2 ............ 83
Tabla 50. Estadística paquetes y bytes protocolos prueba llamada SIP a IAX2
.......................................................................................................................... 83
Tabla 51. Prueba de IAX2 A X2 ........................................................................ 84
Tabla 52. Resumen prueba llamada de IAX2 a IAX2 ........................................ 87
Tabla 53. Estadística para protocolo IP prueba llamada IAX2 a IAX2 ............. 88
Tabla 54. Estadística para protocolo TCP prueba llamada IAX2 a IAX2 .......... 88
4
Tabla 55. Estadística para protocolo UDP prueba llamada IAX2 a IAX2 .......... 88
Tabla 56. Estadística para protocolo RTP prueba llamada IAX a IAX2 ............ 89
Tabla 57. Estadística para protocolo RTP prueba llamada IAX a IAX2 ............ 89
Tabla 58. Prueba de IAX2 a SIP ....................................................................... 90
Tabla 59. Resumen prueba llamada IAX2 a SIP.............................................. 92
Tabla 60. Estadística para protocolo IP prueba llamada IAX2 a SIP ............... 93
Tabla 61. Estadística para protocolo UDP prueba llamada IAX2 a SIP ............ 93
Tabla 62. Estadística para protocolo RTP prueba llamada IAX2 a SIP ............ 93
Tabla 63. Estadística paquetes y bytes protocolos prueba llamada IAX2 a SIP
.......................................................................................................................... 94
Tabla 64. Prueba de IAX2 a SIP ....................................................................... 95
Tabla 65. Resumen prueba llamada IAX2 a H.323 .......................................... 98
Tabla 66. Estadística para protocolo IP prueba llamada IAX2 a H.323 ........... 98
Tabla 67. Estadística para protocolo TCP prueba llamada IAX2 a H.323......... 99
Tabla 68. Estadística para protocolo UDP prueba llamada IAX2 a H.323 ........ 99
Tabla 69. Estadística para protocolo RTP prueba llamada IAX2 a H.323......... 99
Tabla 70. Estadística paquetes y bytes protocolos prueba llamada IAX2 a
H.323 .............................................................................................................. 100
Tabla 71. Consolidado de pruebas H323 ........................................................ 101
Tabla 72. Estadística paquetes y bytes protocolos prueba llamada IAX2 a
H.323 .............................................................................................................. 101
Tabla 73. Estadística paquetes y bytes protocolos prueba llamada IAX2 y
H.323 .............................................................................................................. 102
5
LISTA DE FIGURAS
Figura 1. Esquema PBX ................................................................................... 15
Figura 2. Esquema PBX y Asterisk ................................................................... 16
Figura 3. Esquema Alcance de la Rec. ............................................................. 17
Figura 4. Estructura lógica de un Gateway H.323............................................. 18
Figura 5. Funciones Distribuidas de MP y MD .................................................. 20
Figura 6. Conferencia unidifusión centralizada ................................................. 20
Figura 7. Conferencia multidifusión centralizada .............................................. 21
Figura 8. Conferencia multidifusión descentralizada ........................................ 21
Figura 9. Conferencia Mixta .............................................................................. 22
Figura 10. Pila del protocolo H.323 ................................................................... 24
Figura 11. Protocolo UDP ................................................................................. 27
Figura 12. Protocolo TCP ................................................................................. 28
Figura 13. Protocolos definidos con estándar Q.931 ........................................ 29
Figura 14. Solicitud de llamada entrante ........................................................... 33
Figura 15. Autorización petición llamada .......................................................... 33
Figura 16. Establecimiento de conexión ........................................................... 34
Figura 17. Autorización respuesta llamada ....................................................... 34
Figura 18. Establecimiento canal H.245 ........................................................... 35
Figura 19. Intercambio de capacidades ............................................................ 35
Figura 20. Intercambio de información audio visual. ......................................... 36
Figura 21. Terminación de llamada................................................................... 37
Figura 22. Trama F fullframe ............................................................................ 39
Figura 23. Trama M miniframe .......................................................................... 40
Figura 24. Flujo de datos en IAX2..................................................................... 43
Figura 26. Esquema conceptual Asterisk .......................................................... 44
Figura 27. Arquitectura Asterisk ........................................................................ 45
6
Figura 28. Ventana de control Wireshark .......................................................... 48
Figura 29. Ventana Sjphone. ............................................................................ 48
Figura 30. Ventana Zoiper ................................................................................ 49
7
LISTA DE ANEXOS
Anexo A1. Secuencia de protocolos en llamada H.323 a H.323 ...................... 62
Anexo A2. Secuencia de protocolos en llamada H.323 a IAX2 ....................... 69
Anexo A3. Secuencia de protocolos en llamada SIP a H.323. ........................ 75
Anexo A4. Secuencia de protocolos en llamada SIP a IAX2. .......................... 81
Anexo A5. Secuencia de protocolos en llamada IAX2 a IAX2. ........................ 86
Anexo A6. Secuencia de protocolos en llamada IAX2 a SIP. .......................... 92
Anexo A7. Secuencia de protocolos en llamada IAX2 a H.323. ...................... 97
8
GLOSARIO
ASTERISK: Software de licencia GPL que permite constituir centrales
telefónicas (PBX) utilizando telefonía IP.
GATEKEEPER: Controlador de Acceso para el protocolo H.323.
GATEWAYS: enlace de la red VoIP con la red telefónica analógica o RDSI.
H.323: Recomendación UIT-T, para sistemas de comunicación multimedia
basados en paquetes (PBN) que no puede proporcionar una calidad de servicio
garantizada.
IAX2: Protocolo basado en la reunión de varios protocolos como el Real-Time y
el SIP, el cual se utiliza para manejar conexiones de VoIP entre servidores
Asterisk.
PBX (Private Branch Exchange): Central secundaria privada o centralita,
central telefónica conectada a través de líneas troncales a la red pública y que
permite la gestión y administración de los recursos telefónicos internos,
salientes y entrantes.
RTB/PSTN: Red telefónica Básica / Public Switched Telephone Network.
VoIP: Voz sobre IP, Telefonía IP, Hardware y software que permite tener
telefonía por paquetes (Internet).
9
INTRODUCCIÓN
En la actualidad las empresas buscan optimizar cada vez más los recursos
tecnológicos con los que cuenta. El crecimiento de la mediana y pequeña
empresa, demanda más inversión y productividad, pero con esto también
crecen los costos operativos.
Las tecnologías de comunicación, particularmente los PBX que ofrecen
servicios de distribución automática de llamadas, buzón de voz, entre otras,
representan un requerimiento básico para la operación de cualquier empresa,
sin embargo, tradicionalmente, se habían considerado casi inaccesibles para
las PYMES, debido a sus altos costos. Como respuesta a esta situación, se
han desarrollado diferentes herramientas de Telefonía IP que permiten a las
pequeñas y medianas empresas, acceder a los beneficios que ofrecen las
diferentes formas de transmisión de información (voz, datos y video) pero a
muy bajos costos. Estas herramientas son basadas en software libre y están
soportadas por grandes comunidades que permanentemente las actualizan y
mejoran, logrando una robustez similar y a veces superior que las soluciones
propietarias. Un ejemplo destacable de lo mencionado anteriormente es
Asterisk, una plataforma de comunicaciones basada en software libre de gran
penetración en el mercado, que responde exitosamente a las necesidades de
las pequeñas y medianas empresas de todo el mundo.
Por lo anterior, La Facultad de Matemáticas e Ingenierías de la Fundación
Universitaria Konrad Lorenz, ha decidido tomar como línea de investigación
formativa referente a la tecnología IP e Incursionar en el uso de aquellas
nuevas tecnologías de la comunicación..
Este documento se compone de cuatro capítulos. En el primer capítulo, se
trata aspectos que fueron definidos para el desarrollo de la investigación,
dentro de los que se encuentran; los objetivos, alcance y recursos. En el
segundo capítulo, se describen las bases teóricas que soportan el objeto de la
investigación tratando los antecedentes, marco teórico sobre el protocolo
H.323/IAX2, luego un tercer capítulo, en el cual se plasma el desarrollo de la
investigación sobre los protocolos de señalización H.323/IAX2 bajo la
plataforma de Asterisk, aquí es en donde se describe el contexto, las pruebas
realizadas y el análisis correspondiente; y por último un cuarto capítulo, en el
cual se exponen las conclusiones y las recomendaciones.
10
1.ASPECTOS
INICIALES
1.1.OBJETIVOS
1.1.1.General Presentar un análisis de requerimientos y plan de pruebas de
la plataforma Asterisk utilizando estándar H.323 e IAX2 en entornos clienteservidor.
1.1.2.Específicos.
Identificar las generalidades de la plataforma Asterisk para la configuración
del H.323.
Identificar las generalidades de la plataforma Asterisk para la configuración de
IAX2.
Realizar la configuración de los estándar H.323 e IAX2 en Asterisk.
Impulsar el grupo de investigación para dar apoyo al proyecto macro.
1.2.PROPOSITO.
Este proyecto tiene como fin realizar investigación formativa a través del
análisis documentado sobre el comportamiento, funcionalidad, las ventajas y
desventajas de implementación del estándar H.323 y el protocolo IAX2 bajo
Asterisk.
1.3.CRONOGRAMA
Este proyecto está regido por el cronograma estipulado para el desarrollo del
proyecto macro: Identificación de las funcionalidades, potencialidades y
requerimientos técnicos, para la implementación de ASTERISK.
Tabla 1. Cronograma
Meses
Actividad a desarrollar
Enero-Febrero
Instalación de Asterisk y Revisión
de la Bibliográfica disponi ble
Exploración inicial de las
funcionali dades de Asterisk
Identificación de los requeri mientos
técnicos para la realización de un
plan de pruebas complet o y básico
sobre Asterisk.
Realizaci ón del plan de pruebas
básicos.
Docum entación del proyecto
11
Marzo
Abril
Mayo-Junio
2.MARCO
TEORICO.
2.1.ANTECEDENTES
En la década de los 90’s, se produjo una evolución
tecnológica en las redes de de datos, gracias al interés de las empresas en
involucrar a las redes como medio de comunicación dentro de su entorno
(redes empresariales). Dentro de las redes utilizadas para este propósito, se
destacan las redes ATM, que luego fueron sustituidas por redes IP/Ethernet. A
finales de esta década, surgió y creció de manera impresionante el fenómeno
de la Internet, lo cual motivo desarrollar el concepto NGN (New Generation
Network).
2.1.1.Históricos
De acuerdo a la ITU, una NGN es una red por paquetes que proporciona
múltiples servicios de banda ancha, que utiliza tecnologías de transporte con
una calidad de servicio mínima y en la cual las funciones relacionadas con el
servicio son independientes de las tecnologías de transportes subyacentes.
Este tipo de redes soporta servicios de: Multimedia, Simulación de servicios
PSTN/ISDN, Acceso a Internet, entre otros. Uno de los estándares utilizados
en las NGN es H.323, para proveer a los usuarios de la red tele-conferencias
(transmisión de voz, video y datos en tiempo real).
La primera versión del H.323 fue expuesta en el año 1996 , con el objetivo de
proveer videoconferencia en tiempo real para tecnología LAN y WAN, en el
año 1998 se expuso la segunda versión del estándar, que incluyo funcionalidad
de voz sobre IP. Hasta el momento la ITU ha expuesto la versión 6, la cual fue
aprobada el 13 de junio de 2006 por la Comisión de Estudio 16 (2005-2008) del
UIT-T por el procedimiento de la Recomendación UIT-T A.8
Paralelamente al progreso del estándar H.323, se desarrollaba PBX Asterisk,
tecnología integradora de la telefonía convencional y la emergente telefonía IP.
Esta tecnología fue creada por Mark Spencer, quien a través de GPL logro
obtener una alternativa de PBX libre en el Mercado. El estudio y el desarrollo
estuvieron soportados por los resultados y trabajos realizados por Jim Dixon en
el proyecto Zapata, el cual impulsaba la creación de hardware (tarjetas
telefónicas) open source. De la información e investigación del desarrollo de
software y hardware para Asterisk, se concluye que el objetivo en común que
comparten estos proyectos es ofrecer una alternativa de comunicación a través
de la red de datos de una empresa al mejor costo posible y al alcance de todos.
12
2.1.2.Legales En Colombia no existe una legislación acerca de la transmisión
de voz vía internet por no considerarse como un servicio de valor agregado
citado en el decreto 3055 de 2003, con lo cual no se considera un delito el
hacer uso de estas herramientas para la comunicación.
2.1.3.Investigativos
A continuación exponemos ideas centrales de
investigaciones, proyectos y trabajos, en el cual el objeto de estudio es la
Telefonía IP y Proyectos de desarrollo en Asterisk:
Dnic- Telefonía: proyecto Voz IP, desarrollado para establecer a través del a
red telefónica comunicación entre las diferentes sedes de la Universidad
Nacional, sin ningún costo. Así mismo, se adelantan investigaciones que
permitirán a la Universidad extender el servicio a través de la red WAN de la
universidad. El fin del proyecto, es aprovechar la red de datos e implementar
sobre la red diversos servicios via IP como; telefonía, fax y mensajería, entre
otros.
Diseño e implementación de experiencias docentes para el servicio de voz
sobre IP mediante la utilización de la plataforma Asterisk – Proyecto de grado
de la Universidad Austral de Chile de la Facultad de ciencias de la ingeniería,
con el que se pretendía mostrar una solución que permitiera mejorar los
sistemas de comunicación y mensajería de voz , desde lo residencial hasta lo
organizacional, el trabajo consta de una extensa documentación que va desde
la explicación de protocolos y arquitecturas usadas para implementar redes
para telefonía IP, hasta la implementación de la herramienta Asterisk como
PBX y un análisis de los resultados.
2.2.BASES TEORICAS
Una red telefónica agrupa a un número de centralitas teléfono, en las cuales se
realiza el proceso de conmutación1. En sus inicios las redes telefónicas
clásicas, se fundamentaron en la conmutación de circuitos (RTC)2, luego con
el transcurrir de los años se implemento la conmutación electromecánica. Hacia
los años 60, se desarrollo la conmutación de red digital y, posterior a esta
revolución se sumo la implementación de la tecnología de ordenadores, que
permitió el intercambio de mensajes sobre una red de conmutación de
paquetes independiente y dedicada3.
La red telefónica conmutada (RTC) es una red conmutada de circuitos
tradicional. La RTC abarca el conjunto de redes telefónicas existentes, sobre la
1
Conmutación es la interconexión necesaria para la comunicación entre dos aparatos
telefónicos.
2
RTC es la traducción en castellano de la sigla inglesa PSTN (Public Switched Telephone
Network)
3
Protocolos de señalización para el transporte de Voz sobre redes IP.
13
cual existe flujo de información (Cada una de las llamadas realizadas a través
de este tipo de redes). Esta red es de tipo dedicado, principalmente su diseño
está orientado en primer instancia para la transmisión de voz reservando un
canal para este proceso. La RTC utiliza números telefónicos para identificar la
conmutación de llamadas en las centrales telefónicas.
La internet representa la unión de redes de comunicación no centralizadas, la
cual utiliza la familia de protocolos TCP/IP. Para la internet el flujo de
información representa los paquetes de datos que se intercambian en este tipo
de redes. La internet no es una red dedicada, lo que permite que varios
servicios puedan ser llevados a cabo de manera simultánea a través de un
mismo canal. La internet utiliza direcciones IP para la conmutación de paquetes
entre routers4.
A continuación se hace un resumen de las propiedades del RTC y la Internet.
Tabla 2. Propiedades RTC y Internet
Propiedad
RTC
flujo de información
tipo de red
llamadas
dedicada
número
identificador en la red
telefónico
Donde se conmutan los flujos de información Central telefónica
Internet
paquetes
no dedicada
direcciones
IP
Router
Fuente. “Una guía para crear una infraestructura de voz en regiones en desarrollo”;
autor: Alberto EscuderoPascua.
2.2.1.PBX
Es la sigla de Private Branch Exchange (Central secundaria
privada automática), es una central telefónica que gestiona y administrar los
teléfonos que se encuentran en una empresa a partir de una sola línea
telefónica, sin permitir que los teléfonos tengan una salida independiente hacia
la RTC. Esta central telefónica, es de uso privado, con la cual se pueden
gestionar las llamadas internas, entrantes y/o salientes a través de una sola
línea telefónica. El PBX es una central telefónica de tipo secundario, ya que
representa una derivación de la RTC en una empresa y a través de la cual la
empresa puede gestionar llamadas entrantes de la RTC y llamadas salientes
hacia la RTC.
4
VoIP para el desarrollo – Una guía para crear una infraestructura de voz en regiones de
desarrollo.
14
Figura 1. Esquema PBX
EMPRESA
PSTN
(RTC -RTB)
PBX
Fuente. Autores Yanneth Dimas y Luis Morales
El PBX cumple funciones primordiales para que se lleve a cabo una llamada
tanto interna como externa, como lo son; establecer la conexión entre los
usuario de la llamada, mantener la llamada durante su ejecución y gestionar
información sobre la tarifación de llamadas. Adicional a las funciones
mencionadas, tiene la posibilidad de implementar servicios adicionales, las más
conocidas son:
Llamada en espera, contestador automático, música en espera, transferencia
de llamadas, buzón de voz, conferencia, contestar llamadas de otra extensión
que este timbrando, directorio automatizado, mensajes de bienvenida, entre
otras no menos importantes.
2.2.2.Asterisk y Protocolo H.323 La telefonía IP, se basa en el hecho de
transportar comunicaciones telefónicas a través de paquetes IP, telefonía por
internet, las alternativas tecnológicas se dividen en dos subgrupos , que son las
tecnologías cerradas propietarias y los sistemas abiertos.
Asterisk es un sistema de comunicaciones de tipo centralita telefónica, el cual
brinda calidad en cuanto a llamadas, distribución en diferentes sectores y
registros. Asterisk se puede controlar gracias a que posee código abierto, lo
cual permite adaptarlo a las necesidades que se den en el momento y se
necesiten configurar en el sistema, llevando a cabo diferentes comunicaciones
(llamadas internacionales IP, conferencias, ingreso a red de celulares, sistema
de recepcionista virtual- menú interactivo, notificaciones de correo, etc.) con un
muy bajo costo.
De lo anterior, se indica que Asterisk representa una central telefónica análoga
en un PBX digital. Asterisk es un PBX que integra tecnologías de telefonía
convencional y telefonía IP. Los teléfonos que pueden utilizarse son teléfonos
IP, analógicos o ADSI – teléfono analógico con display digital.
15
Figura 2. Esquema PBX y Asterisk
Voz IP
PSTN
(RTC -RTB)
EMPRESA
Troncal Análoga
PBX IP
Troncal Digital (E1-T1)
Fuente. Autores Yanneth Dimas y Luis Morales
Asterisk es interoperable, lo cual permite que se integren a otras aplicaciones
de forma efectiva y funcional. Dentro de los protocolos que se puede
configurar una red telefónica Asterisk permite utilizar el estándar H.323, el cual
es usado en entornos multimedia para la transmisión de datos, audio y video en
tiempo real.
El estándar H.323, abarca un conjunto de protocolos para establecimiento de
sesión (o llamada), codificación, transporte entre otros. El estándar pertenece a
la familia H.32X, la cual maneja las recomendaciones que refieren a
comunicación multimedia en la cual se pueden destacar los siguientes
estándares:
H.324 en redes SCN. Permite la comunicación sobre SCN- Redes públicas
conmutadas, conocidas comúnmente como teléfonos convencionales.
H.320, H.321, H.310 en redes RDSI. Estas recomendaciones permite la
comunicación en líneas RDSI - Redes de Servicios Digitales Integrales.
H.322 para redes de paquetes con capacidades de QoS.
El H.323 es una recomendación extendida del H.320, pero optimizada para
Internet. Esta recomendación fue diseñada para incluir Voz y telefonía sobre IP
en servicios de comunicaciones entre redes PBN (Redes Basadas en
Paquetes), dentro de las cuales se encuentran; redes que incluyen las de tipo
IP como Internet, las de Intercambio de paquetes (IPX), redes de área amplia
(WAN), redes de área Local (LAN) y conexiones telefónicas que utilicen el
16
protocolo PPP (Protocolo punto a punto) y que se encuentran sobre Redes
telefónicas conmutadas(RTC) y Redes digitales de servicios integrados (RDSI).
Una entidad H.323, se define como aquel componente que hace parte de la
arquitectura del H.323
Una entidad H.323 puede tener las siguientes características:
Llamable: Se considera a una entidad que puede ser llamable, es decir, que en
el proceso de comunicación un usuario determine que la entidad es una
entidad destino.
Direccionable: Es una entidad que tiene una dirección de transporte
Son entidades llamable; los terminales, las MCU, las pasarelas, y los MGC, no
son llamables los controles de acceso,los MC , ni los MG.
A continuación se muestra el esquema que plantea el alcance de la Rec. UITH.323.
Figura 3. Esquema Alcance de la Rec.
Fuente. UIT-T H.323 “Serie H: Sistemas audiovisuales y Multimedia; Sistemas de
comunicación Multimedia basados en paquetes”
El H.323 reconoce las siguientes entidades dentro de su arquitectura:
17
Terminales. Representan a los dispositivos físicos, que se encuentran en
cualquier extremo de la red, los cuales proporcionan la comunicación
bidireccional en tiempo real con otro terminal H.323, Gateway o unidad de
control multipunto (MCU), dentro de los cuales están incluidos la pila de
protocolos, que se mencionarán más adelante. Esta entidad se considera
llamable y direccionable. Todas las terminales H.323 poseen; interfaces del
equipo de usuario, códecs de video y audio, el equipo telemático, la capa
H.225, las funciones de control y la interfaz de red. Un terminal puede estar en
la capacidad de facilitar servicios de voz y datos, datos y video, voz y voz o
vídeo o únicamente voz. Los requisitos mínimos para tener una terminal
H.323, es que soporte voz y posea el códec G.711, H.245, Q.931 y el
componente RAS, de Los cuales se hablará más adelante.
Gateways (Pasarela). Son entidades llamables y direccionables. Permiten la
interconexión entre diferentes tipos de redes, es decir, facilita la comunicación
bidireccional en tiempo real entre terminales que se encuentren en redes por
paquetes y otras redes que cumplan con recomendaciones ITU, tales como;
UIT-T H310 (H320 sobre RDSI-BA), H.320 (RDSI),H321(ATM),H.322(LAN con
GQoS),H.324(RTG),H.324M(Móviles) y V.7(Señales vocales y datos
simultáneos digitales).[1]. Una de las funciones fundamentales en el proceso
de la comunicación la realiza el Gateway, ya que es el encargado de realizar
las traducciones entre formatos de transmisión, procedimientos de
comunicación y traducción de códecs de audio y video entre redes, permitiendo
enlaces; con terminales telefónicos análogos sobre redes de telefonía básica
(RTB), con terminales remotos con estándar H.320 sobre redes RDSI que
soportan circuitos conmutados (SNC) y terminales remotos con estándar H.324
sobre redes de telefonía básica (RTB).
Figura 4. Estructura lógica de un Gateway H.323
Fuente. Cisco Systems “Integración de redes de voz y datos”
Gatekeepers (Control de acceso). Es una entidad que representa el punto
principal y central, el cual administra las zonas5, el ancho de banda y controla
la señalización, las autorizaciones de todas las llamadas6 y los terminales
5
Una zona H.323 es un conjunto de dispositivos (Terminales, GW,MCU y GK. Una zona tiene
solamente un controlador de acceso. Una zona puede ser independiente de la topología de la
red y comprende múltiples segmentos de red conectados mediante dispositivos como en
caminadores.
6
La autorización de llamadas es opcional en los gatekeepers, a través de esta se acepta o
rechazan las llamadas efectuadas por puntos terminales por restricciones predeterminadas en
los gateways o puntos terminales.
18
registrados en una zona. Dentro de los servicios que ofrece están; la
traducción de direcciones de una red H.323 a direcciones IP o IPX, gestión del
ancho de banda y control del acceso de terminales H.323, gateways y MCU a
la red7, emitiendo mensajes de petición (ARQ)8, obteniendo como respuesta
mensajes de confirmación (ACF)9 o mensajes de rechazo (ARJ)10. Esta
entidad contiene el enrutamiento lógico, lo que permite administrar el
enrutamiento de llamadas y balanceo de los gateways.
Para todas las instalaciones VoIP básicas que usen el estándar H.323, es
necesario considerar el gatekeeper, ya que este permite: Una administración
central de planes de conexión y enrutamiento de llamadas, Acceso a funciones
AAA11 importantes en la seguridad y facturación de una red VoIP, Localización
de recursos basados en políticas12 y facilita el proceso de llamada a terceros.
Unidades de Control Multipunto (MCU). Esta entidad representa un extremo
de una red, la cual permite que más de dos terminales y pasarelas se
encuentren en una conferencia multipunto. Permite conectar dos terminales
para llevar a cabo una comunicación punto a punto, la cual puede tender a ser
multipunto. La MCU es una entidad direccionable y llamable. La MCU está
conformada por un controlador multipunto (MC), que permite gestionar los
canales H.245 y define que capacidades se encuentran comunes entre las
terminales para el procesado de audio y video, una vez determinadas las
capacidades este informa a los extremos de la red el modo por el cual pueden
efectuar la transmisión, mientras que el procesador multipunto (MP), es el
encargado de procesar, mezclar y conmutar los trenes de información (voz,
video y/o datos) y enviar resultados de estos a las terminales que hacen parte
de una conferencia multipunto.
7
El gatekeeper realiza este control de acceso a través del canal H.225 RAS para colocar o no
llamadas en la red.
8
ARQ mensajes de petición RAS enviado por un terminal para establecer comunicación o para
solicitar el ancho de banda y el permiso necesario para continuar con el inicio de la llamada.
9
ACF mensajes de confirmación de admisión RAS enviado por el gatekeeper al punto terminal
que está solicitando el ARQ (generando la llamada).
10
ARJ mensajes de rechazo de admisión RAS enviado por el gatekeeper al punto terminal que
está solicitando el ARQ.
11
AAA funciones de autenticación, autorización y recuento, esenciales en los sistemas de
seguridad y facturación.
12
Las políticas son establecidas para el registro de llamadas, en base a los privilegios del
usuario, destinos, ancho de banda, etc.
19
Figura 5. Funciones Distribuidas de MP y MD
Fuente. Cisco Systems “Integración de redes de voz y datos”
Los tipos de conferencia multipunto son:
Unidifusión centralizada: En este tipo de conferencia, el MC y el MP se
encuentran ubicados en una MCU, en la cual los terminales y Gateway que
participan en la conferencia establecen sesiones de control conexión con el MC
a través de H.245 y envían flujos de medios al MP realizando la interpretación
de códecs, luego el MP mezcla el audio de todas las fuentes y luego devuelve
a cada fuente por independiente el resultado de la mezcla.
Figura 6. Conferencia unidifusión centralizada
Fuente. Cisco Systems “Integración de redes de voz y datos”
20
Multidifusión centralizada: El MC y el MP se encuentran ubicados en una
MCU, se establece sesión de control a través de H.245 tal como lo hace la
conferencia unidifusión centralizada. El MP después de recibir el flujo de
medios de cada una de las fuentes, ejecuta la mezcla de audio, sin embargo
envía el resultado de la mezcla al grupo de multidifusión, el cual se encarga de
enviarlo a cada una de las fuentes participantes en la conferencia.
Figura 7. Conferencia multidifusión centralizada
MCU
Multidifusión
MC+MP
H.245 Sesiones de control de
medios con el MC
Flujos de medios al
MP
Flujo de audio
mezclado por MP
Fuente. Cisco Systems “Integración de redes de voz y datos”
Multidifusión descentralizada: El MCU solamente tiene integrado el MC, ya
que para este tipo de conferencias no se requiere del MP, ya que a través de
multidifusión los participantes reciben directamente el audio de cada uno de los
demás participantes. Es de aclarar, que para poder realizar este tipo de
conferencia, cada uno de las fuentes, debe estar en la capacidad de mezclar
audios que recibe de las demás fuentes, comprendiendo el códec utilizado.
Figura 8. Conferencia multidifusión descentralizada
Fuente. Integración de redes de voz y datos; Cisco
21
Mixtas: Este tipo de conferencia es una mezcla de los anteriores tipos de
conferencia, en la cual la MCU actúa como puente para la conexión de los
participantes, los cuales inician sesión a través de H.245 bidireccional, el MC
se une a la multidifusión a través del MP para soportar la porción de
conferencia multimedia descentralizada. La MCU proporciona acceso a
conferencias multidifusión a los host que no soportan la multidifusión, es decir,
no cuentan con la capacidad de mezclar audios que recibe de las demás
fuentes y la interpretación de los códecs utilizados en la conferencia.
Figura 9. Conferencia Mixta
Fuente. Cisco Systems “Integración de redes de voz y datos”
Los componentes del H.323 se comunican a través de la transmisión de trenes
de información, los cuales pueden ser:
Trenes de datos: corresponden a señales que incluyen imágenes sin
movimiento, documentos, ficheros de computador entre otros datos (Según
Rec. UIT-T H.323).
Trenes de audio: corresponden a señales vocales digitalizadas y codificadas,
la cual va acompañada de una señal de control de audio (Según Rec. UIT-T
H.323).
Trenes de video: Señales de video digitalizado y codificado, la cual va
acompañada de una señal de control de video. Este tipo de señales se
22
transmite a una velocidad menor a la que resulta de intercambio de
capacidades de transmisión entre los componentes (Según Rec. UIT-T H.323).
Control de comunicaciones: Señales que se dan entre los componentes para
el intercambio de capacidades, apertura y cierre de canales lógicos, control de
modo, entre otras propias del proceso de comunicación (Según Rec. UIT-T
H.323).
Control de la llamada: Señales utilizadas para el establecimiento de la
comunicación y la desconexión de la misma, entre otras propias del control de
llamadas (Según Rec. UIT-T H.323).
Para poder recibir, procesar y enviar las señales que provienen de las fuentes
de video y de audio (dispositivos como: cámaras, monitores, micrófonos,
aparatos telefónicos entre otros que emitan video y/o audio), el estándar H.323
utiliza los códecs.
2.2.2.1. Códecs H.323
Los códecs representan los codificadores y
decodificadores que son utilizados para codificar las señales de video y audio
recibidas de las entradas (dispositivos) y que luego se decodifican para enviar
una salida de transmisión (el video o el audio enviado a un dispositivo). La
recomendación H.323 identifica los siguientes códecs:
El códec de video, que se trata en las recomendaciones H.261, H.263 y H.263+
realizadas por la UIT, para la codificación y decodificación de video.
El códec de audio, que se trata en las recomendaciones G.711, G.722, G.723,
G.728 y G.729 elaboradas por la UIT, para la codificación y decodificación de
audio.
Para el caso de la transmisión de datos, el estándar H.323 identifica un canal
de datos, el cual soporta aplicaciones telemáticas, acceso a bases de datos,
conferencias audiográficas.
Para este canal, la UIT desarrolló la
recomendación T.120 (A través del cual se permite prestar servicios
interoperables durante una conferencia multipunto de datos en tiempo real) y
para ejecutar otros servicios la negociación con el H.245.
Las terminales H.323 que tengan la capacidad de transmisión de video, deben
ser capaces de codificar y decodificar video en los medios H.261 o H.263. Las
negociaciones para trabajar a través de codificación y decodificación con
medios H.264 se encuentran descritos en la Rec. UIT-T H.241. Una terminal
H.323 puede enviar y recibir más de un canal de video al mismo tiempo, esto
de acuerdo a las negociaciones a través del canal de control H.245.
Toda terminal H.323 tendrá un códec de audio que le permitirá codificar y
decodificar las señales vocales, sin embargo puede hacer uso de códecs
opcionales que se encuentren dentro de la negociación h.245. Así mismo,
tendrá la posibilidad del envío simultáneo de canales de audio y para el caso
de las conferencias podrá recibir más de un canal de audio, para lo cual la
23
terminal tendrá que realizar una mezcla de audio para dar origen a una señal
de audio compuesta a presentar al usuario. El terminal H.323 utilizará el
H.245, con el fin de conocer cuántos trenes de audio simultáneos es capaz de
decodificar. La cantidad de canales de datos para una terminal H.323 pueden
ser opcionales, estos canales pueden ser unidireccionales o bidireccionales, lo
cual supervisado por la recomendación T.120 para efectos de interoperabilidad
entre terminales H.323 y otros terminales.
2.2.2.2. Protocolos de H.323 El estándar H.323 presenta dentro de su
arquitectura una unidad de control de sistema, la cual se compone de los
siguientes protocolos de control:
Figura 10. Pila del protocolo H.323
Fuente. Cisco Systems “Integración de redes de voz y datos”
H.245. Protocolo de transporte entre terminales que lleva información referente
a las capacidades, descripción de canales lógicos y medios disponibles para el
intercambio, mensajes de control y control de flujo entre las mismas. Los
mensajes H.245 se clasifican en: mensajes de petición, mensaje de respuesta
(es una acción de respuesta al emisor), instrucción (requiere una acción por
parte del receptor) e indicación (estos últimos informativos y no requieren
alguna acción de petición o respuesta).
H.225. Protocolo de conexión, que realiza el formateo de los trenes de
información en mensajes para ser enviados a la interfaz de red y formatea los
mensajes que han sido introducidos a través de la interfaz de red. La capa de
H.225 controla la alineación de las tramas lógicas, detección de errores y
corrección de los mismos dependiendo el tipo de medio.
H.225 RAS (Registration/Admission and Status). Permite establecer sesión
para realizar la comunicación entre terminales a través de los dispositivos de
red necesarios para esta. Este protocolo determina la forma en la que se
24
conecta, se desconecta una terminal, efectuando cambios en el ancho de
banda para su optimización.
Los protocolos H.225 y H.225RAS se soportan en los protocolos de transporte
RTP/UDP/IP13 para la sobrecarga de audio y protocolos IP/UDP o IP/TCP para
los mensajes de control.
RTP (Real-Time Transport Protocol). Este protocolo a nivel sesión, es
requerido para realizar la transmisión de información en tiempo real. Este
protocolo es utilizado en las videoconferencias para transmitir audio y video
entre los participantes.
RTCP (Real-Time Transport Control Protocol).Este protocolo se basa en la
transmisión de paquetes en forma periódica cuando se establece una sesión
RTP, que permite saber a través de informes de emisor y receptor la calidad
del servicio e identificar a través de un identificador llamado CNAME efectuar el
seguimiento constante de un participante en una conferencia, esto con el fin de
sincronizar el audio y video en una sesión multimedia.
H.450 - Servicios suplementarios. El estándar H.323 define a los servicios
suplementarios14 en los puntos terminales, ya que utiliza la red solo para
encaminamiento. El conjunto de recomendaciones H.450 define la señalización
entre los puntos terminales para ejecutar los servicios suplementarios. A
continuación se relacionan los servicios suplementarios básicos:
Tabla 3. Servicios suplementarios
Servicio Suplementario
Recomendación UIT-T
Funciones genéricas
H.450.1
Transferencia de llamadas
H.450.2
Desvío de llamadas
H.450.3
Retención de llamadas
H.450.4
Aparcar/ recuperar llamadas
H.450.5
Llamada en espera
H.450.6
Mensajes en espera
H.450.7
Identificación de nombre
H.450.8
Conclusión de llamada
H.450.9
Oferta de llamada
H.450.10
Llamada intrusa
H.450.11
Servicios de información de red comunes
H.450.12
Fuente. Cisco Systems “Integración de redes de voz y datos”
13
UDP es un protocolo basado en la transmisión de datagramas sin conexión, lo que permite
que no se valide que los paquetes enviados lleguen completos y en orden a su destino.RTP es
un protocolo utilizado para transmitir señal vocal sobre UDP. UDP y RTP se encuentran en la
capa de transporte del modelo OSI.
14
Los servicios suplementarios son capacidades añadidas que mejoran, simplifican o
complementan la funcionalidad de un servicio o aplicación de comunicaciones.
25
Para que el protocolo se ejecute, los puntos terminales deben entender la
lógica del servicio. El protocolo de H.450x se ejecuta sobre el protocolo de
señalización para el establecimiento de llamadas Q.931.
2.2.2.3. Direccionamiento de H.323
El estándar H.323 maneja un
esquema de direcciones, con el fin de poder establecer una comunicación entre
dispositivos H.323. En este esquema de direcciones se compone de una
dirección de red IP y un identificador TSAP15 .
El estándar H.323 utiliza un método alterno para la identificación de los puntos
terminales y conferencias multiparte. Un punto terminal puede contar con varias
direcciones alias, esto facilita el proceso de identificación de un punto terminal
ó de una conferencia multiparte y permite que H.323 opere
independientemente de la IP en cualquier capa de red. Los alias, pueden estar
compuestos por cadenas alfanuméricas – identidades H.323 (Ej:
[email protected] ) y direcciones de dialledDigits o de partyNumber (números
telefónicos privados y números públicos E.164)16.
Los gatekeepers, los MC y los MP no contiene la dirección alias, ya que son
entidades H.323 no llamables. Es importante aclarar, que las direcciones alias
dentro de una zona deben ser únicas y en el evento en tener diferentes zonas,
los alias deben estar compuestos por el identificador personal acompañado por
el nombre de la zona (usuario@nombre_zona), teniendo en cuenta que el
nombre de la zona debe ser igual al nombre del dominio DNS donde reside el
gatekeeper.
El proceso de descubrimiento del gatekeeper es fundamental en una red que
está bajo el estándar de H.323, ya que permite la integración entre los puntos
terminales y los gatekeeper17. A continuación se relacionan tres métodos para
descubrir el TSAP y la dirección de la red de un gatekeeper:
Preconfiguración: Este método indica que en el punto terminal se puede
preconfigurar la IP del gatekeeper, lo que indica que la terminal ya tiene la
dirección con la cual establecer comunicación con el gatekeeper a través de
peticiones GRQ18, para negociar la conexión H.225 RAS.
Multidifusión: Este método permite a los puntos terminales que no tienen
preconfigurado la IP del gatekeeper enviar mensajes GRQ a los nombres DNS
15
Representa a un punto de acceso al servicio de transporte (puede ser un puerto TCP o UDP).
Al TSAP se le denomina también como la dirección a nivel de transporte, la cual sirve para
establecer comunicación entre dos entidades. Los identificadores TSAP permiten
multiplexación de varios canales que comparten la misma dirección de red (Rec. H.323
06/2006- Sistemas de comunicación multimedia basados en paquetes).
16
La recomendación UIT-T H.225.0 define otro tipo de direcciones aceptadas como alias en el
estándar H.323.
17
El gatekeeper forma los límites de las zonas H.323
18
GRQ es un mensaje que un punto terminal envía para localizar un gatekeeper con el que se
pueda registrar. Cuando se lanza esta solicitud, se espera un mensaje de rechazo del
gatekeeper (GRJ) o un mensaje de aceptación (GCF) para el registro de la terminal en el
gatekeeper.
26
conocidos o direcciones de grupos multidifusión IP: Gatekeeper.mcast.net
224.0.1.41.
DNS: Este método consiste en que los puntos terminales utilicen el DNS a
través de registros SRV o registros TXT para descubrir el gatekeeper para
registro o para la búsqueda de un gatekeeper de otro para realizar el LRQ19.
2.2.2.4. Proceso de señalización en H.323 Para entender el proceso de
señalización en una red H.323, a continuación se muestra la estructura de los
paquetes que maneja cada uno de los protocolos que intervienen en el proceso
de comunicación:
Figura 11. Protocolo UDP
16 bits
32 bits
Puerto de Origen
Puerto de Destino
Longitud
Suma de comprobación del encabezado
Datos
Fuente. UDP: User Datagram Protocol aviable [online]. Aviable from internet
<http://javvin.com/protocolUDP.html>, Abril-Mayo 2009
Es un protocolo que no está orientado a conexión.
Puerto de origen: Corresponde al número de puerto del remitente.
Puerto de destino: Corresponde al número de puerto del remitido.
Longitud: indica la longitud del segmento, incluyendo el encabezado de este.
Suma de comprobación: Esta operación se realiza con el fin de verifica que el
segmento se encuentre completo.
El protocolo TCP es un protocolo orientado a la conexión, su estructura es la
siguiente: (Véase Figura 12)
19
LRQ es un mensaje de solicitud enviado para este caso de un gatekeeper a otro gatekeeper
de una zona distinta con el fin de conocer la ubicación de un punto terminal.
27
Figura 12. Protocolo TCP
Fuente. UDP: User Datagram Protocol aviable [online]. Aviable from internet <
http://www.javvin.com/protocolTCP.html>, Abril-Mayo 2009
Puerto de origen: Corresponde al número de puerto del remitente.
Puerto de destino: Corresponde al número de puerto del remitido.
Número de secuencia: Corresponde al número de secuencia con el que se
comenzó a sincronizar los números de secuencia.
Número de acuse de recibo: Corresponde al número de secuencia del último
segmento esperado.
Margen de datos: Permite identificar el inicio de los datos del paquete.
Reservado: Es una reserva para implementar alguna función en el futuro.
Indicadores (UGR,ACK,PSH,RST,SYN,FIN): corresponden a los indicadores de
los mensajes.
Ventana: Permite visualizar el número de bytes que el receptor está dispuesto
a recibir sin acuse de recibo.
Suma de Control: Es una suma de control para validar la integridad del
encabezado del paquete.
Puntero urgente: indica el número de secuencias que se tienen después de
haber sabido que el paquete se torna urgente.
Relleno: Se rellena con ceros para tener una longitud que sea múltiplo de 32
bits.
El protocolo H.225 y el protocolo H.245 manejan la estructura de paquete
definida en el estándar Q.931, el cual se estructura de la siguiente forma:
28
Figura 13. Protocolos definidos con estándar Q.931
Fuente. UDP: User Datagram Protocol aviable [online]. Aviable from internet <
http://www.javvin.com/protocolH245.html>,Abril-Mayo 2009
El Discriminador de Protocolo (PD): Es el mensaje de control de llamada en la
interfaz usuario a red.
Referencia de llamada en la conexión usuario-red (RF): Utiliza un Byte para
indicar la longitud CRV, el cual utiliza 4 bits para la longitud y 4 bits de relleno
0000 y utiliza un segundo Byte para asignar el valor del CRV (utilizando 7 bits),
el cual se asigna al inicio de la comunicación y permanece hasta la finalización
de la llamada. El bit más significativo se utiliza como bandera para indicar que
extremo de la red origino la referencia de llamada (CRF). Cuando el bit tiene
valor cero ¨0¨, significa que ese punto fue el que origino la llamada y su valor es
uno ¨1¨, cuando el punto es el destino de la llamada.
Tipo mensaje (MT): Utiliza un Byte, en el cual se tiene el tipo de mensaje
(acción a realizar), este tipo de mensajes están clasificados en: Establecimiento
de llamada, Información se llamada, Liberación de llamada y Misceláneas.
Tabla 4. Mensajes de establecimiento de llamada
Mensaje
Significado
ALERTING
Indicación o aviso de llamada.
CALL PROCEEDING
Recibida la información para establecer la llamada.
CONNECT
Establecimiento de llamada completado.
CONNECT ACKNOWLEDGE
Reconocimiento de CONNECT.
PROGRESS
Señalización temporal durante el establecimiento.
SETUP
Llamada con requerimientos de servicios portadores.
SETUP ACKNOWLEDGE SETUP Recibido, pero se necesita más información.
Fuente. María Carmen España Boquera. “Servicios avanzados de telecomunicación”
29
Tabla 5. Mensajes de información de llamada
Mensaje
Significado
HOLD
Petición para poner una llamada en retención
HOLD ACKNOWLEDE
Petición de retención
HOLD REJECT
Petición de retención denegada
RESUME
Petición para reanudar una llamada
RESUME ACKNOWLEDGE Acuse de petición de llamada reanudada
RESUMEN REJECT
Rechazo de petición de petición de reanudación de llamada
RETRIEVE
Petición para recuperar una llamada retenida
RETRIEVE ACNOWLEDGE Acuse de petición de recuperación de llamada.
RETRIEVE REJECT
Rechazo de petición de petición de recuperación de llamada
SUSPEND
Petición de suspensión de llamada.
SUSPEND ACKNOWLEDGE Acuse de suspensión de llamada.
SUSPEND REJECT
Rechazo de petición de suspensión de llamada.
USER INFORMATION
Información de user-user a través de la señalización.
Fuente. María Carmen España Boquera. “Servicios avanzados de telecomunicación”
Tabla 6. Mensajes de liberación de llamada
Mensaje
DISCONNECT
RELEASE
RELEASE COMPLETE
RESTART
RESTART ACKNOWLEDGE
Significado
Finalizar una llamada.
Liberar la llamada
Acuse de RELEASE
Rearranque del protocolo de nivel de red
Acuse de rearranque
Fuente. María Carmen España Boquera. “Servicios avanzados de telecomunicación”
Tabla 7. Mensajes Misceláneas
Mensaje
CONGESTION CONTROL
FACILITY
INFORMATION
NOTIFY
REGISTER
STATUS
STATUS ENQUIRY
Significado
Control de flujo de USER INFORMATION
Petición opcional de servicios de usuario
Información adicional durante el establecimiento
Indica la información pertinente para una llamada
Asigna un valor de referencia de llamada
Indica el estado del canal
Petición del estado del canal después de congestión
Fuente. María Carmen España Boquera. “Servicios avanzados de telecomunicación”
Dentro de los otros elementos de información, se encuentran los:
ID Identificador de mensaje, indica en un Byte si el mensaje que sigue es de
usuario-usuario, un estado de desconexión, el número de llamada.
30
LON Representa en un Byte la longitud del mensaje.
CON Contiene el mensaje propio y utiliza Bytes de acuerdo al tamaño del
mensaje
El H.225 a través del MT determina la función del mensaje. El H.225 es el
canal fiable de control de llamadas, a través del cual se intercambian
conexiones, cancelaciones y mensajes de servicios suplementarios,
respondiendo al puerto T1720 de las peticiones de llamadas entrantes. El
protocolo H.225 está basado en las recomendaciones Q.931 y Q.932, sin
embargo completa en menor tiempo una llamada y simplifica la secuencia ¨
desconexión-envío-envío-completo ¨ en un solo mensaje.
El protocolo H.225 RAS20 trata de las interacciones entre un terminal H.323 y
un gatekeeper (el descubrimiento de un gatekeeper y las señalizaciones entre
un punto final y un gatekeeper). A través del RAS las entidades terminales
hacen peticiones a un gatekeeper y este responde en confirmación o rechazo
de la solicitud. Para distinguir el tipo de solicitud y respuesta se denominan
tres letras de las siguiente forma; RQ para solicitudes, CF respuesta de
confirmación de solicitud y RJ para respuesta de rechazo de la solicitud. A
continuación se indican los servicios que se ejecutan a través del protocolo
H.225 RAS:
Tabla 8. Servicios del protocolo H.225
Servicio
Descubrimiento del gateway
Registro con gatekeeper
Sin registros con gatekeeper
Localización de puntos finales en una zona
diferente
Solicitud
GRQ
RRQ
URQ
Confirmación
GCF
RCF
UCF
Rechazo
GRJ
RRJ
URJ
LRQ
LCF
JRJ
Fuente. María Carmen España Boquera. “Servicios avanzados de telecomunicación”
Estas funciones solamente son mencionadas, ya que en la integración del
protocolo H.323 con Asterisk, este actúa como un Gateway y la figura del
gatekeeper no necesariamente es utilizada. Sí se quisiera que Asterisk actúe
como gatekeeper, esto se puede lograr al integrarlo con GNUGk (Gatekeeper
open source).
En la fase de comunicación el protocolo H.245, hace uso de los siguientes
mensajes21 en orden:
20
RAS Abreviatura de registro, admisión y estado.
El mensaje en este sentido, corresponde al tipo de acción que se encuentran incluido en el
paquete.
21
31
Intercambio de las capacidades de un punto final Los puntos finales
intercambian información referente a capacidades de transporte y entrantes
del usuario:
o Tipos que soporta RTP (códecs)
o Si soporta RSVP (Q0SCapabilities)
o Qué tipos de canales de medios soporta (IP UDP, IP RTP)
o Si soporta RSVP, que tipo de parámetros soporta (RSVPParameters)
o Si soporta RSVP, que tipo de reservas soporta (servicio garantizado
frente a servicio de carga controlada)
o Si soporta retransmisión DMTF (para tonos o durante una llamada
activa)
o Si soporta retransmisión ¨hook-flash¨( Para funciones de acceso en
swithches telefónicos remotos)
Determinación de maestro-esclavo El H.245 utiliza una secuencia de
determinación de maestro-esclavo, para definir qué punto final posee las
mejores capacidades para soportar el control de sesión.
Establecimiento de un canal lógico Inicia cuando se establecen sesiones
RTP y TCP por el flujo de medios. El H.245 inicia el flujo de medios a través
del mensaje openLogicalChannel, el cual contiene los siguientes
parámetros:
o Número de puertos UDP para iniciar sesión RTP y RTCP.
o Formato del medio (Códecs de audio y video, o formatos T.120).
o Información RSVP.
o Si soporta retransmisión DMTF y ¨hook-flash¨.
El retardo que tuviera el proceso de establecimiento de un canal lógico en una
LAN, era insignificante, sin embargo cuando el protocolo fue utilizado para
establecer flujo de medios en una red WAN a través de una sesión de llamada,
el protocolo no construía la ruta para transmisión hasta que no se realizará la
negociación de medios, lo que no era eficiente y se podían perder las primeras
palabras de la llamada. Por lo anterior el estándar H.323 en su versión dos
presenta una solución a este problema y a través de enviar la conexión
openLogicalChannel a través del mensaje de SETUP del protocolo H.225, lo
que permite la conexión inmediata para que los puntos finales estén listos para
enviar y recibir flujo de medios.
2.2.2.5. Fases de señalización en H.323 A continuación se muestra la
comunicación entre dos terminales H.323 que se encuentran dependientes de
un gatekeeper, las cuales se desarrollan en cuatro fases:
Establecimiento de la Llamada (Fase A): La entidad H.323 llamante envía un
mensaje H.225 RAS, en este caso ARQ al gatekeeper solicitando una llamada
entrante. El mensaje ARQ contiene identificador del gatekeeper, ancho de
banda necesario para la llamada, el tipo de llamada (punto a punto, de uno a
muchos, de muchos a uno y de muchos a muchos), alias de fuente y destino,
32
dirección IP de la fuente y destino y puerto TCP para el control de llamadas
H.225), si la parte que llama es una MC y cualquier capacidad de reserva de
QoS (RSVP).
Figura 14. Solicitud de llamada entrante
TERMINAL H.323
(Entidad llamante)
GK
154
TERMINAL H.323
(Entidad llamada)
454
Fuente. Cisco System. “ Integración de redes de voz y datos”
Una vez Gatekeeper acepta la solicitud, enviara un mensaje RAS (ACF) a la
terminal para autorizar la petición de llamadas entrantes o salientes. Dentro de
lo que compone este mensaje se encuentra:
Identificador del gatekeeper H.323
Ancho de banda asignado a la llamada
La identificación del destino (alias, dirección y puerto TCP).
Figura 15. Autorización petición llamada
TERMINAL H.323
(Entidad llamante)
GK
154
TERMINAL H.323
(Entidad llamada)
454
Fuente. Cisco System. “ Integración de redes de voz y datos”
Luego la entidad llamante establecerá conexión a través del protocolo TCP con
el terminal llamado para iniciar el canal de señalización H.225.0, utilizando la
información suministrada en el mensaje ACF (Dirección y puerto).
33
Figura 16. Establecimiento de conexión
TERMINAL H.323
(Entidad llamante)
TERMINAL H.323
(Entidad llamada)
454
GK
154
SETUP
Fuente. Cisco System. “ Integración de redes de voz y datos”
Una vez recibida la conexión por la terminal H.323 llamada, solicitará al GK
autorización para contestar la llamada a través de un mensaje ARQ,
obteniendo a través de mensaje ACF la autorización para de tomar la llamada.
Figura 17. Autorización respuesta llamada
TERMINAL H.323
(Entidad llamante)
TERMINAL H.323
(Entidad llamada)
454
GK
154
SETUP
Fuente. Cisco System. “ Integración de redes de voz y datos”
Luego a través del canal H.225.0. se enviará la dirección IP y puerto para
establecer el canal H.245 para intercambiar capacidades de punto final y
negociar los medios de comunicación que estarán presentes en la llamada.
34
Figura 18. Establecimiento canal H.245
TERMINAL H.323
(Entidad llamante)
TERMINAL H.323
(Entidad llamada)
454
GK
154
SETUP
Fuente. Cisco System. “ Integración de redes de voz y datos”
Intercambio de capacidades (H.245) (Fase B). Se realiza una conexión TCP,
entre las entidades llamante y llamada, con el fin de intercambiar capacidades
de punto final, para negociar los códecs, los números de conexiones,
direcciones, puertos, determinación de maestro-esclavo y establecimiento del
canal lógico
Figura 19. Intercambio de capacidades
TERMINAL H.323
(Entidad llamante)
TERMINAL H.323
(Entidad llamada)
454
GK
154
SETUP
MENSAJES H.245:
termCapabilitySet Openlogicalchannel
Fuente. Cisco System. “ Integración de redes de voz y datos”
35
Intercambio de información audiovisual (Fase C) Ambos terminales
establecen canales para la transmisión de medios a través de TCP/UDP/IP y
canales de control RTCP/UDP/IP, para validar la calidad de los flujos de
medios
Figura 20. Intercambio de información audio visual.
TERMINAL H.323
(Entidad llamante)
TERMINAL H.323
(Entidad llamada)
454
GK
154
SETUP
MENSAJES H.245:
termCapabilitySet Openlogicalchannel
FLUJO RTP
FLUJO RTP
FLUJO RTCP
Fuente. Cisco System. “ Integración de redes de voz y datos”
Terminación de la llamada (Fase D) Una vez completado el flujo de medios,
las entidades enviarán a través del canal H.245 primitivas de finalización de
llamadas (EndSessionCommand), lo que hará que el canal H.245 se cierre. Así
mismo, enviarán mensajes RAS (DRQ) que permitirá la liberación de recursos
al GK.
36
Figura 21. Terminación de llamada
TERMINAL H.323
(Entidad llamante)
TERMINAL H.323
(Entidad llamada)
454
GK
154
SETUP
MENSAJES H.245:
termCapabilitySet Openlogicalchannel
FLUJO RTP
FLUJO RTP
FLUJO RTCP
MENSAJES H.245:
CloselogicalChannel EndSessionCommand
Fuente. Cisco System. “ Integración de redes de voz y datos”
En la versión 2 de H.323 se evita el coste que sufre el tiempo de conexión al
gatekeeper para poder establecer conexión entre los puntos finales H.323 a
través del tunneling del protocolo H.245 sobre el protocolo H.225, lo que
pretende utilizar un solo canal para transmitir mensajes tanto de H.225 como
mensajes H.245.
37
2.2.3.IAX2 Inter-Asterisk Exchange Protocol
Sus siglas traducen Inter-Asterisk eXchange Protocol , Creado por Mark
Spencer como parte del desarrollo del PBX Asterisk está basado en la reunión
de varios protocolos como el Real-Time y el SIP, se utiliza para manejar
conexiones de VoIP entre servidores Asterisk o que utilicen IAX, pero también
puede ser manejado en la configuración de extensiones individuales, posee un
gran manejo de Códecs lo que le permite manejar diversos tipos de datos entre
ellos el de video.
La señalización es de tipo peer to peer AIX2 usa un par de flujos que reúnen
voz y datos (in-band), está en la capacidad de
El mayor atributo que se le puede reconocer a este protocolo es la capacidad
que posee para realizar un empaquetamiento de múltiples llamadas en un
canal, en otras palabras empaquetar múltiples flujos de paquetes IP (trunking)
en un solo lo que quiere decir que envía voz, datos su respectiva señalización
con un mismo encabezado. En otras palabras usa en el mismo puerto UDP
para señalización y media,
Algunas de sus características principales son:
Utiliza un puerto UDP22 para realizar la comunicación entre terminales de
voz IP.
La voz se transmite vía in-band23
Posee soporte de Trunking24
Ideal para manejo de NAT’s25
Diseñado para reducir el uso de banda ancha.
El diseño de su cabecera posee 4 octetos (32 Bits) y 12 octetos para los
puntos de control.
En Asterisk el protocolo IAX2 usa el puerto UDP = 4569 .
2.2.3.1. Tramas de IAX2
En IAX2 existen 2 tipos de tramas, para las
tramas completas, puede ser usado para enviar señalización de audio y video
de forma confiable, pues el espera recibir un mensaje de confirmación que
indique el éxito de la transmisión. Para las miniframes no se hacen necesarios
estos mensajes de verificación.
22
UDP (User Data Protocol ) protocolo de datos de usuario, es un protocolo definido en la capa
de transporte, no proporciona seguridad de las comunicaciones
23
In-Band sistema de Broadcast digital, permite el manejo en convivencia de señales
analógicas y digitales
24
Empaquetamiento de llamadas simultaneas bajo un solo flujo de paquetes IP , ahorro de
ancho de banda
25
NAT (Network Address Translation - Traducción de Dirección de Red)
38
Figura 22. Trama F fullframe
F
Número de llamada de Origen
R
Número de llamada de Destino
Sello de Tiempo
Secuencia de
Secuencia de
Salida
Entrada
Tipo de Trama
C
Subclase
Datos
Tipos de trama [Online]. España. Avianle from internet: < http://voipforo.com/IAX/IAXframes.php>, Abril-Mayo 2009
Las características que posee está trama son las siguientes
La trama debe dar respuesta de confirmación de recepción al ser
enviada.
Este tipo de trama es el único que necesita de una confirmación de
recepción explicita.
El campo F en la trama indica si la trama es Full Frame, para que sea
así el valor debe ser 1.
El Número de llamada de Origen o Source Call Number es el número
de identificación de llamada de origen, esto ocurre debido a que pueden
existir varias llamadas que se encuentren multiplexadas por el mismo
canal, es te número está compuesto de 15 Bits.
El Número de llamada de Destino o Destination Call Number Es el
número de identificación de el destino de la llamada, ya que al igual que
con el número de origen pueden existir varios destinos multiplexados en
la misma línea. Está compuesto de 15 Bits.
El Campo R es el que indica si la tramas está siendo retransmitida, se
activa con 1 Bit.
El Campo Sello de Tiempo o Timestap Marca el tiempo del paquete
completo de 32 Bits.
La Secuencia de Salida o OSeqno es la secuencia compuesta por 8
bits indica el número de los mensajes de salida.
La Secuencia de Entrada o ISeqno es la secuencia compuesta por 8
bits e indica el número de los mensajes de entrada.
El Tipo de Trama o Frame Type Indica el tipo de trama de que se trata,
Compuesto por 8 Bits.
El campo C compuesto por 1 Bit, indica si la subclase debe tomarse
como 1 o 2 mensajes consecutivos, si su valor es 0 se toman 7 bits si es
1 se toman 14 Bits.
Subclase o Subclass Indica el tipo de subclase.
Datos es la información que se envía en formato binario.
39
Figura 23. Trama M miniframe
F
Número de llamada de Origen
Sello de Tiempo
Datos
Tipos de trama [Online]. España. Avianle from internet: < http://voipforo.com/IAX/IAXframes.php>, Abril-Mayo 2009
Las características que posee está trama son las siguientes.
Están hechas para ahorrar ancho de banda esto se logra enviado la
menor cantidad de información posible.
Estás tramas no necesitan de mensaje de confirmación de recepción.
Si sufre algún fallo o no llegan se descartan.
En general el significado de los campos de esta trama son los mismos
que en la trama F pero, el valor del campo F es 0.
El Sello de Tiempo se encuentra cortado y posee únicamente 16 Bits
Para el tipo de trama junto con la subclase sirven como Señalización de control
y determinan las funciones del paquete dependiendo de los valores pueden
indicar:
Tabla 9. Valores para type en tramas F
Valor del
Type Frame
00000001
00000002
Descripción
Detalles
DTMF
Sirve para enviar dígitos DTMF.
El campo subclase indica el tipo de códec de audio
Datos de voz
que se utiliza.
00000003
Datos de
video
00000004
Control
00000005
No usado
00000006
Control IAX
00000007
00000008
00000009
Texto
Imagen
HTML
El campo subclase indica el tipo de códec de video
que se utiliza.
Mensajes de control de sesión. Sirve para controlar
el estado de los dispositivos finales. El campo
subclase indica el tipo concreto de mensaje de
control.
Mensajes de control del protocolo IAX. Gestiona las
interacciones necesarias entre los dispositivos
finales. El campo subclase indica el tipo concreto de
mensaje de control.
Valores
de
las
tramas
[Online].
España.
Avianle
http://voipforo.com/IAX/IAX-F-frames.php>, Abril-Mayo 2009
40
from
internet:
<
Tabla 10. Valor de subclase con tipo de trama para datos de voz
Valor subclase
(Type Frame =0x02)
Datos de Voz
0x0001
Descripción
(códec que se
utiliza en la
conversación)
G.723.1
0x0002
GSM
0x0004
G.711 u (u-law)
0x0008
G.711 a (a-law)
0x0080
LPC10
0x0100
G.729
0x0200
Speex
0x0400
iLBC
Valores de las tramas [Online]. España. Avianle from internet: <
http://voipforo.com/IAX/IAX-F-frames.php>, Abril-Mayo 2009
Tabla 11. Valor de subclase con tipo de trama control
Valor subclase
(Type Frame
=0x04) Control
Descripción
0x01
Hangup
0x02
Ring
0x03
Ringing
(ringback)
0x04
Answer
Respuesta
0x05
Busy Condition
El usuario está
ocupado
0x08
Congestion
Condition
Existe congestión
0x0e
Call Progress
Progreso de la
llamada
Detalles
La llamada se ha
colgado
El telefono esta
sonando
Valores de las tramas [Online]. España. Avianle from internet: <
http://voipforo.com/IAX/IAX-F-frames.php>, Abril-Mayo 2009
41
Tabla 12. Valor de subclase con tipo de trama control iax
Valor subclase (Type
Frame =0x06) Control
IAX
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0a
0x0b
0x0c
0x0d
0x0e
0x0f
0x10
0x11
0x12
0x13
0x14
0x15
0x16
0x17
0x18
0x19
0x1a
0x1b
0x1c
Descripción
NEW
PING
PONG
ACK
HANGUP
REJECT
ACCEPT
AUTHREQ
AUTHREP
INVAL
LAGRQ
LAGRP
REGREQ
REGAUTH
REGACK
REGREJ
REGREL
VNAK
DPREQ
DPREP
DIAL
TXREQ
TXCNT
TXACC
TXREADY
TXREL
TXREJ
QUELCH
0x1d
UNQUELCH
0x20
MWI
0x21
UNSUPPORT
Detalles
Iniciar una nueva llamada
Enviar un ping
Responder un ping
Respuesta afirmativa
Inicio de desconexión
Rechazo
Aceptación
Petición de autenticación
Respuesta de autenticación
LLamada no válida
Petición de Lag
Respuesta de Lag
Petición de registro
Autenticación de registro
ACK de registro
Denegación de registro
Liberación de registro
Petición de retransmisión
Petición de dialplan
Respuesta de dialplan
Marcado
Petición de transferencia
Conexión de transferencia
Aceptación de transferencia
Transferencia preparad
Liberación de transferencia
Rechazo de transferencia
Parar transmisión de audio
Continuar transmisión de
audio
Indicador de mensaje en
espera
Mensaje no soportado
Valores de las tramas [Online]. España. Avianle from internet: <
http://voipforo.com/IAX/IAX-F-frames.php>, Abril-Mayo 2009
42
Ejemplo de flujo de datos en IAX2
Figura 24. Flujo de datos en IAX2
Valores de las tramas [Online]. España. Avianle from internet: <
http://voipforo.com/IAX/IAX-ejemplo-mensajes.php>, Abril-Mayo 2009
Cuando empieza el establecimiento de la llamada, se envía el mensaje “new”,
desde la terminal A hacia la terminal B, si acepta la terminal B envía un
mensaje a la terminal A aceptando “Accept”, cuando esté es recibido por el
terminal B responde con un mensaje “Ack”26, la terminal B envía a la terminal la
señal “ringing"27, la terminal A responde con un “Ack” en donde reafirma la
llegada del mensaje, al final terminal B acepta y responde el mensaje con la
señal “Answere”. Después empieza el intercambio de datos o voz, esto se
realiza de manera bidireccional entre las terminales, en esta se envían los
Frames M y F, para liberar la llamada desde una de las terminales se envía un
mensaje de tipo “hangup” y a la terminal a la que se envía confirma la
recepción del mensaje.
26
Ack : Mensaje que se envía para anunciar que un conjunto de uno o más mensajes han sido
recibidos.
27
Ringing: Llamada (Acústica); oscilación transitoria
43
2.3.TEORIAS GENERICAS BASADAS EN INGENIERIA.
Como la idea en general del proyecto va orientado a minimizar costos pero sin
perder beneficios y calidad, se hacen uso de las herramientas de licencia GPL
más reconocidas para cada área que se necesite, siguiendo esto se tienen:
Es una plataforma de gestión de comunicaciones
para voz IP, en otras palabras es un PBX en su
versión digital, es de licencia GPL, que se
ejecuta sobre diferentes plataformas de sistemas
operativos, pero su plataforma nativa es Linux y
Unix,
permite la conexión de diferentes
interfaces de comunicación, ya sean líneas
digitales o analógicas, esto se puede realizar utilizando diferentes recursos de
hardware. Provee servicios de directorios, cola de llamadas, conferencias,
Video conferencias,
llamadas tripartitas, manejo de diversos tipos de
protocolos para IP, SIP, H.323, ADSI, IAX, reconocimiento de voz,
administradores únicos de llamadas MGCP, llamadas salientes y entrantes
entre diferentes proveedores VoIP, DialPlan, registro detallado de llamadas
para realizar tarificación, entre otros. Este puede ser obtenido en
http://www.Asterisk.org/.
Figura 26. Esquema conceptual Asterisk
Fuente. Joranda de voz sobre IP empresa digitala.
<http://creativecommons.org/licenses/by/2.5/es/deed.es> , Abril-Mayo 2009
Con respecto a la versión usada en el proyecto la 1.4 posee herramientas de
autoconfiguración ( /configure) , que orientan a los usuarios sobre el uso y
configuración a través de ejemplos. Posee módulos de selección o procesos de
construcción (menuselect) que sirve para habilitar o deshabilitar opciones
globales de configuración de herramientas que se necesiten. Sonidos (prompt)
y música de espera que se encuentra disponible en español. Posee cambios en
el PBX básicos, como modificaciones de la sintaxis para la redirección de
llamadas, transferencias de contextos, líneas de comandos para las interfaces,
nuevos valores estándar en la configuración que dejan deshabilitadas cosas
44
que se consideraban obsoletas para su funcionamiento en versiones anteriores
y nuevas formas de sintaxis de funciones como por ejemplo, para las variables
globales, Set (GLOBAL(nombre) = valor), entre otras muchas mejoras.
Figura 27. Arquitectura Asterisk
Fuente. Alberto escudero Pascual. Asterisk PBX guía de la configuración Como
construir y configurar un PBX con software libre Asterisk versión 1.4.
Dentro de Asterisk existen un conjunto de directorios que contienen todos los
archivos de configuración, desde los bloques de programación hasta las
carpetas de contenidos de imágenes para usuarios del DialPlan, algunos de los
principales directorios usados por Asterisk son:
Tabla 13. Directorios Asterisk
Ruta
/etc/Asterisk
/usr/sbin
/usr/lib/Asterisk
Contenido
Archivos de configuración
Archivos binarios, scripts y ejecutables
Objetos binarios de Asterisk
/usr/lib/Asterisk/modules
Modulos de ejecución de aplicaciones
(canales,dirvers,formatos)
/usr/incluye/Asterisk
/var/lib/Asterisk
/var/lib/Asterisk/agi/bin
/var/lib/Asterisk/astdb
/var/lib/Asterisk/images
Archivos de cabecera de los modulos
Variables utilizadas en la ejecución normal
scripts AGI para ser utilizados con las
aplicaciones AGI en el plan de numeración
Base de datos de Asterisk
Imágenes
45
/var/lib/Asterisk/keys
/var/lib/Asterisk/moh/mp3
/var/lib/Asterisk/sounds
/var/run
/var/run/Asterisk/pid
/var/run/Asterisk/ct
/var/spool/Asterisk
var/log/Asterisk/cdr-csv
/var/spool/Asterisk/vm
keys públicas y privadas( Autenticación
RSA)
Música para llamadas en espera en
formato MP3
Prompts , archivos de audio
Runtime (pipes, archivos PID)
Identificadores de proceso primarios (PID)
Modo remoto de operación
Cola de espera para el buzón de voz
Archivo Master registro de llamda
Almacenamiento de los buzones de voz,
saludos…
Fuente: Directorios Asterisk 1.4
Otros componentes básicos son los Canales, que se pueden explicar a través
de una analogía de decir que son las líneas telefónicas analógicas pero
representadas a través de un circuito digital, pueden ser combinaciones de
códec, protocolos de señalización o POST. Los Códec son los que se encargar
de codificar las llamadas de tal forma que sirvan para realizar al compresión de
las señales, dependiendo del códec es el nivel de uso por parte del ancho de
banda, lo ideal es que se minimice el espacio que se utiliza de la banda pero si
perder fidelidad en la comunicación.
Tabla 14. Códec y canales en Asterisk
Canales Red Pública
Chan_zap
TDM400P – 4 puertas analógicas FXS o
FXO
TDM800P - 8 puertas analógicas
TDM2400 - 24 puertas analógicas FXS o
FXO
chan_phone
Tarjeta quicknet
Tarjeta phonejack
Tarjeta linejack
chan_ss7
Tarjetas Digium con señalización 7 (ISUP)
chan_bluetooth
Permite el uso de dispositivos Bluetooth
Canales para Voz
IP
Chan_sip
Canales internos
Asterisk
Chan_agent
Chan_iax
Chan_h323
Chan_console
Chan_local
Fuente Flavio E. Goncalvez. “Manual Asterisk”
46
Chan_mgcp
Chan_sccp
Códecs
G.711 ulaw (usado en EUA) – (64 Kbps).
G.711 alaw (usado en Europa – (64 Kbps).
GSM – (12-13 Kbps)
iLBC – (15 Kbps)
LPC10 - (2.5 Kbps)
Speex - (2.15-44.2 Kbps)
G.729 (8Kbps)
Para realizar el manejo de los archivos de configuración es necesario tener en
cuenta:
(;) el punto y coma es usado para realizar comentarios.
(=) o (=>) son usados para realizar asignaciones de valores de
diferentes tipos.
([ ]) los corchetes cuadrados son usados para indicar contextos.
Para el proyecto se realizaron configuraciones sobre los archivos de
configuración /etc/Asterisk/ , User.conf, Extensions.conf ,Iax.conf y h.323.conf
Archivos de configuración Extensions.conf: contienen el plan de marcado del
DialPlan y de cada contexto que sea usado para los usuarios. Adicionalmente,
definen el flujo de las llamadas
Es un software de licencia GPL, que ofrece
todas las opciones de análisis de una red a
través de una interfaz como una Ethernet, esto lo
hace realizando una captura del flujo de
paquetes entrantes y salientes que pasan por la
interfaz seleccionada. El Wireshark nos ofrece la posibilidad de realizar
estadísticas detalladas por protocolos, gráficos detallados de cada una de las
estadísticas, identificación de errores en los flujos como latencia y jitter, filtrado
de paquetes por filtro personalizado, entre otras. Ofrece estadística entre
endpoints, protocolos por jerarquía, detección conversaciones de VoIP y
tiempos entre solicitud y entrega. Este software se encuentra disponible para
varias plataformas de sistemas operativos entre ellas Linux y Windows. La
versión utilizada para el proyecto es la 1.0.7. el Wireshark se puede obtener en
http://www.Wireshark.org/.(Vease Figura 28)
47
Figura 28. Ventana de control Wireshark
Fuente Captura Wireshark
SJPHONE, es un software de licencia GPL, que permite hablar
sobre internet con cualquier ordenador, portátil, PDA u otros
softhphones, este soporta los estándares H323 y SIP, es
interoperables con la mayoría de que proveedores de servicios
de telefonía IP, entre ellos Asterisk, con este se pueden
construir sus propias rede de Voz IP, usando cualquier
gatekeeper y Gateway h323, Proxy SIP, Ip-PBX entre otros componentes de
voz IP. La versión que se usa en el proyecto es la 1.65. Este lo puede
descargar en http://www.sjlabs.com/.
Figura 29. Ventana Sjphone.
Fuente captura ventana principal Sjphone
48
ZOIPER es un softphone para windows y Linux que utiliza los
estándares IAX y SIP, apoyo STUN, varios soportes de
códecs, múltiples cuentas, amortiguación de jitter adaptable,
reducción de eco, voicemail, entres otras funciones para el
desarrollo del proyecto se usara la versión gratuita 2.0 que se
encuentra en http://www.zoiper.com.
Figura 30. Ventana Zoiper
Fuente captura ventana principal Zoiper
2.4.CONSTRUCCION DEL MARCO CONCEPTUAL.
2.4.1.Metas a alcanzar
Lograr elaborar una investigación documentada
referente a los protocolos H.323 y protocolo IAX2 bajo la plataforma Asterisk,
que permitan introducir una solución alternativa, analizada y evaluada, para
suplir las necesidades de comunicación con tecnologías de la información
dentro de las pequeñas y medianas empresas.
Para esto se requiere como metas a corto plazo:
Realizar un levantamiento de documentación técnica referente a la
implementación de Asterisk sobre el protocolo H.323 e IAX2.
La instalación, configuración y prueba inicial de Asterisk bajo el protocolo
H.323 y el protocolo IAX2.
Metas a mediano plazo:
Realizar un estudio estadístico, basado en pruebas reales de la
implementación de los protocolos H.323 e IAX2.
Realizar un consolidado de documentación formativa realizada,
presentada con sus respectivas conclusiones.
49
Metas a largo plazo:
Realizar la instalación y puesta en marcha del proyecto, en las
instalaciones de la Fundación Universitaria Konrad Lorenz, si resulta
como la solución que brinda los mejores beneficios con respecto a los
costos.
2.4.2.Enfoque
El enfoque de este proyecto es realizar a través de una
investigación formativa un análisis de requerimientos y plan de pruebas de la
plataforma Asterisk utilizando el estándar H.323 e IAX2 en entornos cliente
servidor.
2.4.3.Necesidades a satisfacer El desarrollo del proyecto es implementar
una red de telefonía IP para uso de transmisión de Voz y datos en la Fundación
Universitaria Konrad Lorenz y, aportar en cuanto a referencia investigativa
experiencia en implementación de telefonía IP a las pymes, que ven en esta
tecnología una oportunidad de transmisión de Voz y datos a un mejor costobeneficio.
También se busca contribuir académicamente, con el semillero de investigación
de telecomunicaciones “Telemente” de la fundación, para que en el futuro se
puedan desarrollar nuevos proyecto que continúen y referencias los resultados
obtenidos en este proyecto.
50
3.DISEÑO
METODOLÓGICO
3.1.TIPO DE INVESTIGACIÒN
La investigación es de tipo descriptiva ya que la meta es lograr una exploración
detallada de los componentes de sistema de comunicaciones Asterisk bajo el
protocolo H.323 e IAX2, en donde se describan los requisitos de instalación y
funcionamiento basado en cada uno de los protocolos teniendo en cuenta:
Requisitos de funcionamiento hardware.
Requisitos de funcionamiento software (Librerías y herramientas
necesarias para el correcto funcionamiento de Asterisk).
Sistema Operativo.
De esta manera, se debe realizar una investigación que toque los puntos
referentes a la calidad de transmisión y descripción de cada protocolo.
3.2.ANÁLISIS DE LA SITUACIÓN ACTUAL
El grupo de investigación para el desarrollo de pruebas, cuenta con los
siguientes recursos:
Descripción de Ordenadores I y II
Marca: DELL
Memoria: 1Ghz
Procesador: Intel 2140 de 1.60Ghz
Disco Duro de 160Ghz
La red es de tipo
El ancho de banda es de 3Ghz.
Norma del cableado es 6 esté suministra un servicio de
telecomunicaciones que soporta voz, datos y video, permite transmitir
hasta de 1Gigabit por segundo.
Tipo de ponchado es la norma b.
Estos equipos se encuentran disponibles en la sala 302, y están accionados
para el proyecto, poseen además la característica de tener su IP fija y están
sobre el mismo segmento de red, totalmente disponibles a cualquier cambio en
la configuración del software mientas este cumpla con la reglamentación de ley
necesaria o sean bajo licencias de software libre, el acceso a la red de estas
ordenadores no se encuentra limitado como el de las demás, es decir no tienen
la restricción del proxy, ya que para la configuración e instalación del sistema
operativo y en general para todo el software requerido en el proyecto ,se
necesitan realizar descargas en línea y el proxy no permitiría esto.
También adicional a los servidores, se cuentan con ordenadores locales, pero a
diferencia de los primeros que van a ser usados como los servidores de
51
Asterisk,, estos no están restringidos exclusivamente al uso dentro del proyecto
pero se permitirá el acceso a la configuración e instalación de software como
softphones, mientras estos estén bajo la ley o sean de licencia libre.
Los demás ordenadores que se disponen para el proyecto son computadoras
portátiles que en podrán realizar la conexión con los servidores a través de la
red física o inalámbrica.
Esté proyecto asume nuevos retos en cuanto a ciertos campos de
conocimientos como lo son la incursión a las telecomunicaciones de la nueva
generación y todo lo relacionado a la telefonía IP y el uso de herramientas
software libres como Asterisk, lo que genera un gran valor agregado para la
experiencia ingenieril y técnica de los participantes.
3.3.DIAGNÓSTICO DE LA SITUACIÓN ACTUAL
3.3.1.Sistemas Operativos
Como una de las metas a evaluar son los
costos en tiempo y dinero en la implementación de la herramienta Asterisk,, los
sistemas operativos escogidos desde el inicio y la finalización del proyecto
tocaron estos puntos, más que todo los sistemas escogidos para realizar la
implementación fueron la facilidad en su uso y las recomendaciones
encontradas en diversas fuentes de documentación dentro del proyecto se
probaron con las siguientes distribuciones de Linux:
Debian 4.0 Principal distribución de Linux, creada en 1993 por el Proyecto
Debian fundado por Ian Murdock. Posee un núcleo Monolítico, y como interfaz
gráfica posee GNOME, KDE, Xfce o Lxde da soporte a varias arquitecturas de
computadores, dentro de las que se encuentran la i386(x86 ó x32), amd64(x86x64), powerPc, sparc(SunSparc),s390 Arquitectura IBM ESA/390 Y
z/Architecture.
Posee más de 18733 paquetes de software y un paquete de herramientas para
facilitar el proceso de instalación y actualización del software APT,Aptitude,
Dselect, /etc/apt/sourcelist, entre otras.
Diseño especialmente para personas que ya hayan tenido experiencia previa
con el manejo de distribuciones Linux ya que el manejo es complicado.
Los requerimientos mínimos de funcionamiento son:
Procesador: 1Ghz
Memoria RAM: 64Mb
Disco Duro: 5Ghz
Ubuntu Server 8.10 Ubuntu es una distribución de Linux orientada a los
computadores personales, es una de las distribuciones más importantes de
Linux ya que tiene gran reconocimiento mundial, está basada en la distribución
Debian, pero está orientado a dar más facilidad en instalación y uso , su
principal patrocinador es Canonical Ltda, empresa fundada por Matk
52
Shuttleworth. Ubunto entrega versiones de sus sistemas cada 6 meses. La
versión 8.10 fue lanzada el 30 de octubre del 2008, y dentro las mejoras están
la mejor y mayor conectividad a internet y dispositivos móviles, sesión de
invitados y soporte 3G .
Soporta las arquitecturas la i386(x86 ó x32), amd64(x86-x64), la interfaz
gráfica que maneja es la GNOME, el manejo para el software lo maneja a
través de cuatro componentes que son el main, el restricted el universe y
multiverse
Los requerimientos técnicos mínimos para su funcionamiento son:
Procesador 300Mhz x86
Memoria RAM 64 Mb
Disco duro de 4 Gigas
Placa de video VGA
Unidad lectora CD-Rom
Para el grupo de investigación, el punto más débil al incursionar dentro de
sistemas operativos Linux, es que no se cuenta con una experiencia amplia de
manejo de los mismos. Este manejo es requerido para la administración de
Asterisk, aunque se sabe que en el mercado se pueden recurrir a opciones
como el sistema operativo CentOS pre compilado para Asterisk que ofrecen
algunas empresas colombianas que proveen esta herramienta, el
inconveniente es que estas vienen incluidas en planes empresariales o cursos
de certificación que oscilan entre los $2’000.000 y $2’600.00, lo cual es una
gran limitante, otra ventaja de escoger sistemas operativos que se pueden
conseguir de manera gratuita es que están a la mano de realizar
modificaciones con mayor libertad que utilizar uno que venga diseñado para
usar la herramienta, el proceso de auto aprendizaje es otra ventaja que viene
con esto ya que para los integrantes del proyecto se tuvo la posibilidad de
evaluar todo el proceso para la aplicación de la herramientas desde cero, tal
vez el mayor costo que se presenta a realizarlo de esta manera es el tiempo
que se invierte en la línea de aprendizaje.
El primer sistema operativo que se tomo para realizar las pruebas fue el Debian
4.0, se escogió gracias a su respaldo, historia y estabilidad, para el caso del
proyecto se presentaron muchos fallos en la instalación, en el momento de
habilitar las conexiones de red, era complicado al manejar,
desafortunadamente al ser tan robusto es difícil conseguirlo o descargarlo y
presento demasiados fallos de compatibilidad de paquetes.
Cuando se decidió usar sistema operativo Ubuntu, se tenía cierta desconfianza
ya que este también proviene de la distribución Debian, pero se encontró que
era un sistema que poseía muchas de las ventajas de su predecesor, pero era
mucho más amigable y su gestor de descargas online era rápido, tanto así que
se logró operar este sistema desde el entorno gráfico xinit.
Se decidió escoger como sistema operativo base para los servidores Asterisk el
Ubuntu.
53
3.3.2.Evaluación y selección de la mejor alternativa
ASTERISK: (Versión estable 1.4.23.1) De acuerdo al enfoque del proyecto se
utiliza Asterisk, ya que es una herramienta libre (bajo la licencia de Open
source) completa, que posee las funcionalidades requeridas para ser utilizada
como solución de implementación de redes de telefonía IP.
Posee
escalabilidad, que le permite que este servicio sea implementado en una
pequeña empresa de 10 usuarios hasta 10.000 de una empresa que tenga
diferentes sedes. Asterisk por ser una herramienta bajo código libre, permite
que los costos de su instalación e implementación sean cada vez mejores. A
través del desarrollo de Asterisk se han ido desarrollando los diferentes
estándares de telefonía en los TDM como la telefonía IP, dentro de los cuales
se encuentra el estándar H.323 e IAX2, objeto de estudio en este proyecto.
La escogencia de Asterisk también corresponde a que es la herramienta de
software libre líder, para la implementación de centrales telefónicas IP, lo que
hace que sea un software probado por miles de usuarios, que además
contribuyen con sus inquietudes y desarrollos a una mejor comprensión de esta
tecnología.
54
3.4.Plan de Pruebas
A continuación se relacionan nueve pruebas, con el fin de analizar las estadísticas del protocolo de señalización del estándar
H.323 e IAX2. Para estas pruebas, se utilizaron los siguientes equipos:
Tabla 15. Configuración de los ordenadores para las pruebas
Equipo
Procesador
RAM
S.O.
Mascara de
subred
IP
DNS
Gateway
Servidor
Pentium IV
1 Ghz
Ubunto server 8.10
192.168.100.249
255.255.255.0
192.168.100.2
192.168.100.1
Ordenador_1
Pentium IV
256 Mb
Windows XP
192.168.99.240
255.255.248.0
192.168.100.3
192.168.100.3
Ordenador_2
Pentium IV
256 Mb
Windows XP
192.168.103.16
255.255.248.0
192.168.100.3
192.168.100.3
Portátil_1
AMD
Pentium Dual
Core
4 Ghz
Windows Vista
192.168.100.238
255.255.255.0
192.168.100.2
192.168.100.1
3 Ghz
Windows Vista
192.168.100.240
255.255.255.0
192.168.100.2
192.168.100.1
Portátil_2
Fuente recopilación de configuración de ordenadores sala 302
Para las pruebas se destinaron la siguiente configuración de extensiones en Asterisk
Tabla 16. Configuración de extensiones para pruebas
Equipo Extensión Protocolo Softphone
Ordenador
1
6000
SIP
X-Lite
Ordenador
1
8001
IAX2
Zoiper
Ordenador
1
9001
H.323
Sjphone
Ordenador
6001
55
SIP
x-Lite
2
Ordenador
2
Ordenador
2
8000
IAX2
Zoiper
9000
H.323
Sjphone
Portátil 1
7000
SIP
X-Lite
Portátil 2
7001
SIP
X-Lite
Fuente configuración de archivos sip.conf, h323.conf e iax.conf en Asterisk
A continuación se describen las pruebas realizadas para el proyecto, las cuales contiene la siguiente información:
Numero de la prueba.
Nombre de la prueba.
Recursos.
Descripción de Prueba.
Resultados esperados.
Resultado de la prueba.
Resultados obtenidos.
Análisis de la prueba.
Cada análisis de prueba, contiene la siguiente información:
Secuencia de señalización.
Corresponde a la secuencia que sigue cada uno de los protocolos que intervienen durante la llamada. Esta secuencia
de señalización se encuentra como anexo al documento.
Estadística de paquetes y bytes transmitidos durante la llamada. Es una tabla que sigue la estructura y contiene la
siguiente información
56
Tabla 17. Descripción de tabla plan de pruebas.
Nombre del campo
Paquetes
Descripción
Número de paquetes transmitidos durante la llamada.
tiempo entre la primera y último paquete
(seg)
Corresponde al tiempo que transcurre entre el instante de tiempo en el cual se
transmite el primer paquete y el instante en el que finaliza la transmisión del
último paquete.
Prom. Paquetes por segundo (bytes)
Prom. Tamaño de Paquetes
Bytes
Prom. Bytes por segundo
Prom. Mbits por segundo
Corresponde al promedio de paquetes enviados por segundo.
Es el promedio del tamaño de paquetes que captura y analiza Wireshark
Es el número de bytes transmitidos durante la llamada
El promedio de bytes que se transmiten por segundo
El promedio de Mbits que se transmiten por segundo
Fuente Estadística tomada con Wireshark
Estadística por protocolo (TCP, UDP y RTP), de los paquetes y bytes transmitidos durante la llamada entre direcciones
IP.
Tabla 18. Definición tabla de protocolos parte A
NOMBRE DE PROTOCOLO
Address A
Address B
Packets
Bytes
Total
de
bytes
Corresponde al total de
enviados
de
la
Corresponde
a
la Corresponde a la paquetes enviados de la
dirección IP de
dirección IP que envía dirección IP destino dirección IP origen a la
origen a la dirección
origen del paquete
del paquete
dirección IP destino del
IP
destino
del
paquete
paquete
Fuente Estadísticas de protocolos por Wireshark
57
Packets A->B
Bytes A->B
Número de
paquetes enviados
de la dirección A a
la B.
Número de bytes
enviados de la
dirección A a la B.
Tabla 19. Definición de protocolos parte B
Packets A<-B
Bytes A<-B
Número de paquetes
enviados de la
dirección B a la A.
Número de bytes
enviados de la
dirección B a la A.
NOMBRE DE PROTOCOLO
Rel Start
Duration
bps A->B
Tiempo en segundos Bits por segundo
de la transmisión de enviados de la
paquetes
dirección A a la B
Instantes de
Tiempo
bps A<-B
Bits por segundo
enviados de la
dirección B a la A
Fuente Estadísticas de protocolos por Wireshark
Estadística por protocolo RTP. Corresponde a información estadística de paquetes transmitidos a través del protocolo RTP.
Tabla 20. Estadística protocolo RTP parte A
Src IP addr
Dest IP addr
Dirección IP que Dirección IP destino
origina el paquete.
del paquete.
Payload
Códecs
RTP
Packets
Max Delta (ms)
Corresponde a la máxima
Numero
de
Número de paquetes
latencia que presenta un
paquetes perdidos
transmitidos.
paquete, en el momento de la
durante la llamada.
transmisión.
Fuente Estadística protocolo RTP Wireshark
58
Lost
Tabla 21. Estadística protocolo RTP parte B
Max Jitter (ms)
RTP
Mean Jitter (ms)
Pb?
Campo
control que indica si durante la
Corresponde a la máxima Promedio de variación de tiempo transmisión de paquetes se dio falla. Sí es así,
variación de tiempo entre la entre la llegada de los distintos el analizador de Wireshark colocará el carácter
llegada de los distintos paquetes. paquetes.
"X" (equis), para identificar que esa línea de
paquetes tuvo inconsistencias.
Fuente Estadística protocolo RTP Wireshark
Estadística por envíos de paquetes entre direcciones. Corresponde al número de paquetes y bytes transmitidos en
cada protocolo por cada dirección IP involucrada en la llamada. Al final del capítulo, se muestra análisis en conjunto de
las pruebas teniendo en cuenta los protocolos H.323 e IAX2, objetos de estudio de la investigación.
59
3.4.1.Prueba de H323 a H323
Tabla 22. Prueba de h323 a h323
NUMERO DE
PRUEBA:
1
NOMBRE DE
PRUEBA:
Llamada extensión H.323 a extensión H.323
RECURSOS:
Servidor, ordenador 1, Ordenador 2
DESCRIPCION La extensión 9001 configurada en el softphone SJPHONE
DE PRUEBA:
(Ordenador 1) realizada llamada a extensión 9000 con
SJPHONE(Ordenador 2).
RESULTADOS La extensión 9001 se pueda comunicar con la extensión 9000, a
ESPERADOS: través del servidor Asterisk.
RESULTADO
DE LA
PRUEBA:
EXITOSA
DESCRIPCION L a extensión de llamada saliente 9001 corresponde a la dirección IP
DE
192.168.99.44
RESULTADOS
:
La extensión llamada entrante es la 9000 la cual se encuentra
ubicada con la dirección IP 192.168.103.16
60
En este momento la extensión 9001 está marcando a la extensión
9000 y solicita respuesta.
61
La extensión 9000 acepta la llamada.
Mensaje enviado por extensión 9001: Este es un mensaje de la
Fundación Universitaria Konrad Lorenz.
Mensaje Recibido por la extensión 9000: Resultado de prueba
exitosa
Fuente Desarrollo de llamada entre estándares h323
Análisis de prueba: A continuación se muestra la secuencia de protocolos de
señalización durante la llamada, a través de lo cual se logra validar la
secuencia de la señalización de H.323. Esta secuencia se puede validar
completamente, en el anexo digital de las pruebas adjuntas a este documento.
Anexo A1. Secuencia de protocolos en llamada H.323 a H.323
62
A continuación se reflejan estadísticas de la prueba:
Tabla 23. Resumen prueba llamada de H.323 a H.323
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
1641
8,762
187,291
89,513
146891
16765,037
0,134
Fuente Estadísticas tomadas con Wireshark Prueba 1
En la estadística, se indica que se transmitieron 1.641 paquetes, los cuales tuvieron una duración de transmisión de 8,762
segundos. Lo que indica que por segundo se transmiten 187,291 paquetes.
Tabla 24. Estadística para protocolo IP prueba llamada H.323 a H.323
Address A
Address B
192.168.100.249 192.168.103.16
192.168.99.44 192.168.100.249
Packets
746
895
POR PROTOCOLO IP
Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
68224
381
34894
365
33330
78667
447
39349
448
39318
Fuente Estadísticas protocolo IP tomadas con Wireshark de Prueba 1
63
Rel Start
Duration bps A->B bps A<-B
2.507.465.000
8,7118 32043,04
82
2.493.599.000
8,7617
35928
69
Tabla 25. Estadística para protocolo TCP prueba llamada H.323 a H.323
Address A
192.168.100.249
192.168.99.44
192.168.100.249
192.168.100.249
Address B
192.168.103.16
192.168.100.249
192.168.99.44
192.168.103.16
Packets
14
20
22
26
POR PROTOCOLO TCP
Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
2180
8
1312
6
868
2893
10
1476
10
1417
1544
13
907
9
637
1828
16
1118
10
710
Rel Start
Duration bps A->B
2.892.530.000
8,3204 1261,47
2.493.599.000
8,7356 1351,71
2.651.306.000
8,604 843,32
3.027.397.000
8,1919 1091,82
bps A<-B
834,57
1297,68
592,28
693,37
Rel Start
7.994.637.000
9.474.627.000
2.507.800.000
2.507.465.000
4.276.536.000
2.679.325.000
bps A<-B
N/A
N/A
N/A
7117,81
35081,66
34553,67
Fuente Estadística protocolo TCP tomada con Wireshark de Prueba 1
Tabla 26. Estadística para protocolo UDP prueba llamada H.323 a H.323
Address A
192.168.99.44
192.168.103.16
192.168.100.249
192.168.100.249
192.168.103.16
192.168.99.44
Address B
192.168.100.249
192.168.100.249
192.168.103.16
192.168.103.16
192.168.100.249
192.168.100.249
Packets
1
1
4
7
694
852
POR PROTOCOLO UDP
Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
106
0
0
1
106
106
0
0
1
106
344
4
344
0
0
3388
3
1651
4
1737
60378
345
30015
349
30363
74124
428
37236
424
36888
Duration
0
0
3,9502
1,9523
6,9240
8,5405
bps A->B
N/A
N/A
696,68
6765,40
34679,58
34879,65
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 1
Tabla 27. Estadística para protocolo RTP prueba llamada H.323 a H.323
Src IP addr
Dest IP addr
SSRC
Payload
192.168.99.44 192.168.100.249 0x10838907 GSM 06.10
192.168.100.249 192.168.99.44 0x46255EE9 GSM 06.10
192.168.103.16 192.168.100.249 0x264DA484 GSM 06.10
192.168.100.249 192.168.103.16 0x38948A95 GSM 06.10
RTP
Packets
428
424
345
349
Lost
0 (0.0%)
0 (0.0%)
0 (0.0%)
0 (0.0%)
Max Delta (ms)Max Jitter (ms)Mean Jitter (ms) Pb?
20.11
0.02
0.01
X
56.49
107.64
2.01
X
20.15
0.05
0.03
X
52.36
97.49
5.91
Fuente Estadística protocolo RTP tomada con Wireshark de Prueba 1
Dentro de la estadística del protocolo RTP, se encuentra el campo Pb, este campo cuando se encuentra con el carácter “X”,
indica que en el transcurso del envío de paquetes ocurrieron errores en marcación de tiempo por parte de Wireshark, es
64
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 hubo un 0% de paquetes perdidos. De los 1.641 paquetes que fueron transmitidos durante la llamada,
895 corresponden a la extensión llamante 9000 con una participación del 54.54% sobre el total de los paquetes, mientras que
la extensión llamada 9001 tuvo una participación de paquetes del 45.46%
Tabla 28. Resumen de paquetes llamada Prueba 1
Llamada entre extensiones configuradas en H.323
IP
192.168.99.44 / 192.168.100.249
192.168.100.249 / 192.168.103.16
TCP
192.168.99.44 / 192.168.100.249
192.168.100.249 / 192.168.103.16
192.168.100.249 / 192.168.99.44
UDP
192.168.103.16 / 192.168.100.249
192.168.99.44 / 192.168.100.249
192.168.100.249 / 192.168.103.16
Fuente Resumen estadísticas tomadas con Wireshark de la Prueba 1
65
Packets
1.641
895
746
82
20
40
22
1.559
695
853
11
Bytes
146.891
78.667
68.224
8.445
2.893
4.008
1.544
138.446
60.484
74.230
3.732
3.4.2.Prueba de H323 a IAX2
Tabla 29. Prueba de h323 a iax2
NUMERO DE
PRUEBA:
2
NOMBRE DE
PRUEBA:
Llamada extensión H.323 a extensión IAX2
RECURSOS:
Servidor, Ordenador 1, Ordenador 2
DESCRIPCION
DE PRUEBA:
La extensión 9001 configurada en el softphone SJPHONE(Ordenador 1)
realizada llamada a extensión 8000 con ZOIPER
RESULTADOS
ESPERADOS:
La extensión 9001 se comunica con la extensión 8000, a través del
servidor Asterisk.
RESULTADO DE
LA PRUEBA:
EXITOSA
DESCRIPCION L a extensión de llamada saliente 9001 corresponde a la
DE
dirección IP 192.168.99.44
RESULTADOS
:
La extensión llamada entrante es la 8000 la cual se
encuentra ubicada con la dirección IP 192.168.103.16
66
En este momento la extensión 9001 está marcando a la
extensión 8000 y solicita respuesta.
La extensión 8000 acepta la llamada.
67
Mensaje enviado por extensión 9001: Este es un mensaje de
la Fundación Universitaria Konrad Lorenz.
Mensaje Recibido por la extensión 8000: Resultado de
prueba exitosa
Fuente Desarrollo de llamada Prueba 2
Análisis de prueba: A continuación se muestra la secuencia de protocolos de
señalización durante la llamada, a través de lo cual se logra validar la
secuencia de la señalización de H.323 e IAX2. Esta secuencia se puede validar
completa en el anexo digital de las pruebas adjuntas a este documento.
Tabla 30. Estadísticas generales prueba 2
Llamada entre extension H.323 y extensión IAX2
IP
192.168.99.44 192168100249
192168100249 192.168.103.16
TCP
192.168.99.44 192168100249
192168100249 192.168.99.44
UDP
192.168.99.44 192168100249
192168100249 192.168.103.16
Total general
Packets
4.314
2442
1872
37
21
16
4.269
2397
1872
8.620
Fuente Estadísticas generales prueba 2 tomadas con Wireshark
68
Bytes
361.166
213818
147348
4.059
2947
1112
356.187
208839
147348
721.412
Anexo A2. Secuencia de protocolos en llamada H.323 a IAX2
A continuación se reflejan estadísticas de la prueba:
Tabla 31. Resumen prueba llamada de H.323 a IAX2
Fuente Estadísticas tomadas con Wireshark Prueba 2
En la estadística, se indica que se transmitieron 4.306 paquetes, los cuales
tuvieron una duración de transmisión de 35,96 segundos. Lo que indica que por
segundo se transmiten 199,743 paquetes. De los paquetes transmitidos 1.897
tienen un tamaño entre 40-70 bytes y 2.403 tienen un tamaño entre 80 y 159.
69
Tabla 32. Estadística para protocolo IP prueba llamada H.323 a IAX2
Address A
Address B
192.168.99.44
192.168.100.249
192.168.100.249 192.168.103.16
192.168.99.44
192.168.100.249
Packets
4
1872
2393
POR PROTOCOLO IP
Bytes
Packets A->B Bytes A->B Packets A<-B Bytes A<-B
Rel Start
Duration bps A->B bps A<-B
424
0
0
4
424 21.006.340.000
15 N/A
226,13
147348
1135
89405
737
57943 5.412.270.000 32,9678 21695,12 14060,52
208415
1277
111323
1116
97092 15.994.706.000 25,3611 35116,9 30627,2
Fuente Estadística protocolo IP tomada con Wireshark de Prueba 2
Tabla 33. Estadística para protocolo TCP prueba llamada H.323 a IAX2
Address A
192.168.100.249
192.168.99.44
Address B
192.168.99.44
192.168.100.249
Packets
16
21
POR PROTOCOLO TCP
Bytes
Packets A->B Bytes A->B Packets A<-B Bytes A<-B
Rel Start
Duration bps A->B bps A<-B
1112
9
615
7
497 15.975.562.000
25,3964
193,73
156,56
2947
10
1476
11
1471 15.926.922.000
25,4457
464,5
462,47
Fuente Estadística protocolo TCP tomada con Wireshark de Prueba 2
Tabla 34. Estadística para protocolo UDP prueba llamada H.323 a IAX2
POR PROTOCOLO UDP
Address A
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
Rel Start
Duration bps A->B bps A<-B
192.168.99.44
192.168.100.249
4
424
0
0
4
424 21.006.340.000
15 N/A
226,13
192.168.100.249 192.168.103.16
1872 1E+05
1135
89405
737
57943 5.412.270.000
32,9678 21695,12 14060,52
192.168.99.44
192.168.100.249
2393 2E+05
1277
111323
1116
97092 15.994.706.000
25,3611 35116,9
30627,2
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 2
70
Tabla 35. Estadística para protocolo RTP prueba llamada H.323 a IAX2
RTP
Src IP addr
Dest IP addr
SSRC
Payload
Packets
Lost
192.168.99.44
192.168.100.249 0x23E35831
GSM 06.10
1269 0 (0.0%)
192.168.100.249 192.168.99.44 0x304E272E
GSM 06.10
1116 0 (0.0%)
Fuente Estadística protocolo RTP tomada con Wireshark de Prueba 2
Max Delta (ms) Max Jitter (ms) Mean Jitter (ms) Pb?
20.22
0.07
0.03
X
54.58
4.16
1.37
Dentro de la estadística del protocolo RTP, 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.44 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 hubo un 0% de paquetes perdidos.
Dentro del análisis del campo Pb, se encuentra que el paquete que presentó error fue el paquete N. 346 enviado por la
dirección IP 192.168.99.44 (Extensión 9001) a la dirección IP 192.168.100.249 (Servidor Asterisk).
De los 4314 paquetes que fueron transmitidos durante la llamada, 2442 corresponden a la extensión llamante 9000 con una
participación del 56.61% sobre el total de los paquetes, mientras que la extensión llamada 8000 tuvo una participación de
1872 paquetes, con una participación del 43.39%.
71
3.4.3.Prueba de H323 a SIP
Tabla 36. Prueba de H.323 a SIP
NUMERO DE
PRUEBA:
3
NOMBRE DE
PRUEBA:
Llamada extensión H.323 a extensión SIP
RECURSOS:
Servidor, ordenador 1, Ordenador 2
DESCRIPCION DE
PRUEBA:
La extensión 9001 configurada en el softphone
SJPHONE(Ordenador 1) realizada llamada a extensión 6000 con XLITE (Ordenador 2).
RESULTADOS
ESPERADOS:
La extensión 9001 se comunica con la extensión 6000, a través del
servidor Asterisk.
RESULTADO DE LA
PRUEBA:
NO EXITOSA
DESCRIPCION DE No se pudo establecer comunicación, ya que al llamar
desde una extensión de H.323 a una extensión SIP, el
RESULTADOS:
servidor Asterisk no reconoce el flujo normal de la
llamada, y por ende no hay registros en el servidor de la
llamada.
Fuente Desarrollo de llamada Prueba 3
Análisis de Prueba: Los resultados obtenidos indican que la comunicación no
fue bidireccional, ya que no se obtuvo audio en ambos sentidos de la llamada y
tampoco quedo registrada en el servidor Asterisk. Una hipótesis para sustentar
el fallo, es que el resultado hace referencia a un problema conocido como
“Audio en una sola dirección” ó “One way Audio” que ocurre cuando en la red
hay presencia de NAT (Network Address Traslator) debido a que estas no
permiten recibir conexiones iniciadas desde el exterior, en donde solo el flujo
de adentro hacia fuera no es bloqueado por la NAT, cosa que no es igual
cuando el flujo viene de fuera hacia adentro de la NAT. Lo anterior, podría
estar soportado en la prueba realizada, ya que la extensión H.323 transmitía
voz pero no era escuchado por su contraparte (extensión SIP).
72
3.4.4.Prueba de SIP a H.323
Tabla 37. Prueba de SIP a H323
NUMERO DE
PRUEBA:
4
NOMBRE DE
PRUEBA:
Llamada extensión SIP a extensión H.323
RECURSOS:
Servidor, maquina 1, Maquina 2
DESCRIPCION DE
PRUEBA:
La extensión 6001 configurada en el softphone X-LITE(Maquina 1)
realiza llamada a extensión 9000 con SJPHONE.
RESULTADOS
ESPERADOS:
La extensión 6001 se pueda comunicar con la extensión 9000, a través
del servidor Asterisk.
RESULTADO DE
LA PRUEBA:
DESCRIPCION
DE
RESULTADOS:
Exitoso
L a extensión de llamada saliente es 6001 correspondiente
a la dirección IP 192.169.100.240
La extensión llamada entrante es la 9000 la cual se
encuentra ubicada con la dirección IP 192.168.100.243
73
En estos momentos la extensión 6001 está marcando a la
extensión 9000, y solicita respuesta de la llamada.
La extensión 9000, acepta la llamada.
74
Mensaje enviado por extensión 6001: Este es un mensaje
de la Fundación Universitaria Konrad Lorenz.
Mensaje Recibido por la extensión 6001: Resultado de
prueba exitosa.
Fuente Desarrollo de llamada Prueba 4
Análisis de prueba: A continuación se muestra la secuencia de protocolos de
señalización durante la llamada, a través de lo cual se logra validar la
secuencia de la señalización de SIP a H.323. Esta secuencia se puede validar
completa en el anexo digital de las pruebas adjuntas a este documento.
Anexo A3. Secuencia de protocolos en llamada SIP a H.323.
75
Tabla 38. Resumen prueba llamada de SIP a H.323
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
2548
16,320
156,994
152,092
387531
23877,528
0,191
Fuente Estadísticas tomadas con Wireshark Prueba 4
En la estadística, se indica que se transmitieron 2548 paquetes, los cuales tuvieron una duración de transmisión de 16,320
segundos. Lo que indica que por segundo se transmiten 156,994 paquetes. De los paquetes transmitidos 1275 tienen un
tamaño entre 80-159 bytes, 1.232 tiene un tamaño entre 160-319 bytes, 11 tienen un tamaño entre 320-639, 7 tienen un
tamaño entre 640-1279 y 23 paquetes tienen un tamaño entre 40-79 bytes.
Tabla 39. Estadística para protocolo IP prueba llamada SIP a H.323
POR PROTOCOLO IP
Address A
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B Rel Start
Duration bps A->B bps A<-B
192.168.100.240 192.168.100.249
1242 3E+05
617
134832
625
135506 7.877.351.000
15,4092 70000,84 70350,76
192.168.100.243 192.168.100.249
1306 1E+05
674
60265
632
56928 7.883.602.000
16,2237 29717,3 28071,53
Fuente Estadística protocolo RTP tomada con Wireshark de Prueba 4
Tabla 40. Estadística para protocolo TCP prueba llamada SIP a H.323
POR PROTOCOLO TCP
Address A
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.100.249 192.168.100.243
11 1922
6
1174
5
748
192.168.100.249 192.168.100.243
14
994
9
628
5
366
Fuente Estadística protocolo TCP tomada con Wireshark de Prueba 4
76
Rel Start
Duration bps A->B bps A<-B
7.886.790.000
15,5258
604,93
385,42
8.130.569.000
15,1584
331,43
193,16
Tabla 41. Estadística para protocolo UDP prueba llamada SIP a H.323
Address A
192.168.100.243
192.168.100.243
192.168.100.243
192.168.100.240
192.168.100.240
192.168.100.240
192.168.100.243
POR PROTOCOLO UDP
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
Rel Start
Duration bps A->B bps A<-B
192.168.100.249
2
212
0
0
2
212 16.109.218.000
4,995 N/A
339,23
192.168.100.249
5
453
0
0
5
453 7.909.680.000
11,9989 N/A
302,3
192.168.100.249
7 3383
4
1731
3
1652 7.883.602.000
3,1835 4349,89
4151,37
192.168.100.249
7 1242
5
1030
2
212 11.070.197.000
12,1731
676,9
139,32
192.168.100.249
10 6946
5
3904
5
3042 7.877.351.000
15,4092 2026,84
1579,32
192.168.100.249
1225 3E+05
607
129898
618
132252 11.094.511.000
12,1866 85272,6
86817,9
192.168.100.249
1267 1E+05
660
57420
607
52809 11.094.339.000
13,13 35300,2 32465,49
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 4
Tabla 42. Estadística para protocolo RTP prueba llamada SIP a H.323
Src IP addr
192.168.100.243
192.168.100.249
192.168.100.240
192.168.100.249
Dest IP addr
192.168.100.249
192.168.100.240
192.168.100.249
192.168.100.243
SSRC
0x28967D
0x51C0939E
0xE6B498E7
0x1B30444C
RTP
Payload
Packets
Lost
GSM 06.10
660 0 (0.0%)
ITU-T G.711 PCMU
618 0 (0.0%)
ITU-T G.711 PCMU
607 0 (0.0%)
GSM 06.10
607 0 (0.0%)
Max Delta (ms)
23.69
51.46
38.40
56.74
Max Jitter (ms)
3.56
5.99
7.13
7.14
Mean Jitter (ms) Pb?
2.60
X
2.79
X
2.14
2.36
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 4
Dentro de la estadística del protocolo RTP, 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 y 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, así mismo ocurre con los paquetes que fueron enviados de la dirección IP 192.168.100.249 a la
dirección IP 192.168.100.240. 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 hubo un 0% de paquetes perdidos. Dentro del
análisis del campo Pb, se encuentra que el paquete que presentó error fue el paquete N. 257 enviado por la dirección IP
192.168.100.243 (Extensión 9000) a la dirección IP 192.168.100.249 (Servidor Asterisk). El paquete que presento el error de
77
marcado de tiempo fue el paquete N. 258, respuesta del servidor a la extensión 9000. Sin embargo, esto no influye en la
transmisión de paquetes. De los 2.548 paquetes que fueron transmitidos durante la llamada, 1242 corresponden a la
extensión llamante 6001 con una participación del 48,74% sobre el total de los paquetes, mientras que la extensión llamada
9000 tuvo una participación de 1.306 paquetes, con una participación del 51,26%
Tabla 43. Estadísticas generales prueba 4
Llamada entre SIP y H.323
Packets
IP
192168100240 192168100249
192168100243 192168100249
TCP
192168100249 192168100243
UDP
192168100240 192168100249
192168100243 192168100249
Total general
Fuente Estadísticas generales prueba 4 tomadas con Wireshark
78
Bytes
2548
1242
1306
25
25
2523
1242
1281
5096
387531
270338
117193
2916
2916
384615
270338
114277
775062
3.4.5.Prueba de SIP a IAX2
Tabla 44. Prueba de SIP a IAX2
NUMERO DE
PRUEBA:
5
NOMBRE DE
PRUEBA:
Llamada extensión SIP a extensión IAX2
RECURSOS:
Servidor, maquina 1, Maquina 2
DESCRIPCION La extensión 6000 configurada en el softphone X-LITE(Maquina 1)
DE PRUEBA:
realiza llamada a extensión 8000 con ZOIPER FREE.
RESULTADOS
ESPERADOS:
La extensión 6000 se pueda comunicar con la extensión 8000, a
través del servidor Asterisk.
RESULTADO
DE LA
PRUEBA:
EXITOSA
DESCRIPCION L a extensión de llamada saliente 6001 corresponde a la dirección
DE
IP 192.169.100.240
RESULTADOS:
la extensión llamada entrante es la 8000 la cual se encuentra
ubicada con la dirección IP 192.168.100.243
79
En estos momentos la extensión 6001 está marcando a la extensión
8000, y solicita respuesta de la llamada.
La extensión 8000, acepta la llamada.
80
Mensaje enviado por extensión 6001: Este es un mensaje de la
Fundación Universitaria Konrad Lorenz.
Mensaje Recibido por la extensión 6001: Resultado de prueba
exitosa
Fuente Desarrollo de llamada Prueba 5
Análisis de prueba: A continuación se muestra la secuencia de protocolos de
señalización durante la llamada, a través de lo cual se logra validar la
secuencia de la señalización de SIP a IAX2. Esta secuencia se puede validar
completa en el anexo digital de las pruebas adjuntas a este documento.
Anexo A4. Secuencia de protocolos en llamada SIP a IAX2.
A continuación se reflejan estadísticas de la prueba:
Tabla 45. Resumen prueba llamada de SIP a IAX2
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
Fuente Estadísticas tomadas con Wireshark Prueba 5
81
2194
12.805,000
171,343
149,087
327097
25545,082
0,204
En la estadística, se indica que se transmitieron 2194 paquetes, los cuales tuvieron una duración de transmisión de 12,805
segundos. Lo que indica que por segundo se transmiten 171,343 paquetes. De los paquetes transmitidos 5 tienen un tamaño
entre 80-159 bytes, 1.079 tiene un tamaño entre 160-319 bytes, 10 tienen un tamaño entre 320-639, 6 tienen un tamaño
entre 640-1279 y 1.094 paquetes tienen un tamaño entre 40-79 bytes.
Tabla 46. Estadística para protocolo IP prueba llamada SIP a IAX2
POR PROTOCOLO IP
Address A
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.100.240 192.168.100.249
1092 2E+05
540
118200
552
119884
192.168.100.243 192.168.100.249
1102 89013
559
44889
543
44124
Fuente Estadística protocolo RTP tomada con Wireshark de Prueba 5
Rel Start
Duration bps A->B bps A<-B
5.914.029.000
12,797 73892,58 74945,33
5.922.982.000 12,7957 28064,96 27586,67
Tabla 47. Estadística para protocolo TCP prueba llamada SIP a IAX2
POR PROTOCOLO TCP
Address A
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.100.249 192.168.100.243
1
74
1
74
0
0
Fuente Estadística protocolo TCP tomada con Wireshark de Prueba 5
Rel Start
Duration bps A->B bps A<-B
6.058.626.000
0 N/A
N/A
Tabla 48. Estadística para protocolo UDP prueba llamada SIP a IAX2
POR PROTOCOLO UDP
Address A
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.100.243 192.168.100.249
6 2796
3
1147
3
1649
192.168.100.240 192.168.100.249
7 1242
5
1030
2
212
192.168.100.240 192.168.100.249
11 7006
6
3964
5
3042
192.168.100.240 192.168.100.249
1074 2E+05
529
113206
545
116630
192.168.100.243 192.168.100.249
1095 86143
556
43742
539
42401
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 5
82
Rel Start
Duration bps A->B bps A<-B
5.922.982.000
2,0256 4529,92
6512,5
7.971.657.000
10,6361
774,72
159,46
5.914.029.000
12,797
2478,9
1901,7
7.942.932.000
10,7564 84196,46
86743,4
5.934.120.000
12,7846 27371,67 26532,54
Tabla 49. Estadística para protocolo RTP prueba llamada SIP a IAX2
Src IP addr
Dest IP addr
SSRC
192.168.100.249 192.168.100.240 0x411D781B
192.168.100.240 192.168.100.249 0x5F1E1FFF
Payload
ITU-T G.711 PCMU
ITU-T G.711 PCMU
RTP
Packets
Lost
545 0 (0.0%)
529 0 (0.0%)
Max Delta (ms) Max Jitter (ms) Mean Jitter (ms) Pb?
57.10
6.39
1.36
31.70
3.49
1.11
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 5
De los 2.194 paquetes que fueron transmitidos durante la llamada, 1.092 corresponden a la extensión llamante 6001 con una
participación del 49,77% sobre el total de los paquetes, mientras que la extensión llamada 8000 tuvo una participación de
1.102 paquetes, con una participación del 50,23%
Tabla 50. Estadística paquetes y bytes protocolos prueba llamada SIP a IAX2
Llamada entre extension SIP y extensión IAX2
IP
192168100240 192168100249
192168100243 192168100249
TCP
192168100249 192168100243
udp
192168100240 192168100249
192168100243 192168100249
Total general
Fuente Estadísticas generales prueba 5 tomadas con Wireshark
83
Packets
2.194
1092
1102
1
1
2.193
1092
1101
4.388
Bytes
327.097
238084
89013
74
74
327.023
238084
88939
654.194
3.4.6.Prueba de IAX2 a IAX2
Tabla 51. Prueba de IAX2 A X2
NUMERO DE
PRUEBA:
6
NOMBRE DE
PRUEBA:
Llamada extensión IAX2 a extensión IAX2
RECURSOS:
Servidor, maquina 1, Maquina 2
DESCRIPCION
DE PRUEBA:
La extensión 8000 configurada en el softphone ZOIPER
FREE(Maquina 1) realiza llamada a extensión 8001 con ZOIPER
FREE.
RESULTADOS
ESPERADOS:
La extensión 8000 se pueda comunicar con la extensión 8001, a
través del servidor Asterisk.
RESULTADO
DE LA
PRUEBA:
EXITOSO
DESCRIPCION
DE
RESULTADOS: L a extensión de llamada saliente 8001 corresponde a la dirección
IP 192.169.100.240
La extensión llamada entrante es la 8000 la cual se encuentra
ubicada con la dirección IP 192.168.100.243
84
En estos momentos la extensión 8001 está marcando a la
extensión 8000, y solicita respuesta de la llamada.
La extensión 8000, acepta la llamada.
85
Mensaje enviado por extensión 8001: Este es un mensaje de la
Fundación Universitaria Konrad Lorenz.
Mensaje Recibido por la extensión 8001: Resultado de prueba
exitosa
Fuente Desarrollo de llamada Prueba 6
Análisis de prueba: A continuación se muestra la secuencia de protocolos de
señalización durante la llamada, a través de lo cual se logra validar la
secuencia de la señalización de IAX2 a IAX2. Esta secuencia se puede validar
completa en el anexo digital de las pruebas adjuntas a este documento.
Anexo A5. Secuencia de protocolos en llamada IAX2 a IAX2.
86
Dentro de la secuencia, se encuentra el protocolo SIP, lo que indica que dentro
de la llamada de IAX2 a IAX2, se identifico que en la maquina en la cual se
configuro la extensión de la llamada entrante, se encontraba activo el softphone
que soporta llamadas SIP, al estar activo se muestra dentro de la secuencia,
sin embargo si se filtra por el protocolo se observa que la llamada es
cancelada, y que no hay transferencia de UDPS. En llamadas realizadas, se
muestra que la solicitud de registro de llamada con protocolo SIP ha sido
cancelada.
A continuación se reflejan estadísticas de la prueba:
Tabla 52. Resumen prueba llamada de IAX2 a IAX2
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
45
17,432
2,581
118,889
5350
306,903
0,002
Fuente Estadísticas tomadas con Wireshark Prueba 6
En la estadística, se indica que se transmitieron 45 paquetes, los cuales
tuvieron una duración de transmisión de 17,432 segundos. Lo que indica que
por segundo se transmiten 2,581 paquetes. De los paquetes transmitidos 7
tienen un tamaño entre 80-159 bytes, 5 tienen un tamaño entre 320-639,1
tienen un tamaño entre 640-1279 y 32 paquetes tienen un tamaño entre 40-79
bytes.
87
Tabla 53. Estadística para protocolo IP prueba llamada IAX2 a IAX2
POR PROTOCOLO IP
Address A
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.100.240 192.168.100.249
20 1333
11
742
9
591
192.168.100.243 192.168.100.249
25 4017
11
1651
14
2366
Fuente Estadística protocolo IP tomada con Wireshark de Prueba 6
Rel Start
Duration bps A->B bps A<-B
4.955.516.000
17,4322
340,52
271,22
4.957.788.000
3,4942
3780
5417
Tabla 54. Estadística para protocolo TCP prueba llamada IAX2 a IAX2
Address A
192.168.100.249
POR PROTOCOLO TCP
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.100.243
2
148
2
148
0
0
Rel Start
Duration bps A->B bps A<-B
4.968.239.000
2,9942
395,42 N/A
Fuente Estadística protocolo TCP tomada con Wireshark de Prueba 6
Tabla 55. Estadística para protocolo UDP prueba llamada IAX2 a IAX2
POR PROTOCOLO UDP
Address A
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.100.243 192.168.100.249
6 2790
3
1144
3
1646
192.168.100.243 192.168.100.249
17 1079
8
507
9
572
192.168.100.240 192.168.100.249
20 1333
11
742
9
591
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 6
88
Rel Start
Duration bps A->B bps A<-B
4.957.788.000
3,4564 2647,88
3809,8
4.961.835.000
3,4901 1162,13
1311,12
4.955.516.000
17,4322
340,52
271,22
Tabla 56. Estadística para protocolo RTP prueba llamada IAX a IAX2
RTP
Src IP addr
Dest IP addr
SSRC
Payload
Packets
Lost
192.168.100.249 192.168.100.240 0x411D781B
ITU-T G.711 PCMU
545 0 (0.0%)
192.168.100.240 192.168.100.249 0x5F1E1FFF
ITU-T G.711 PCMU
529 0 (0.0%)
Fuente Estadística protocolo RTP tomada con Wireshark de Prueba 6
Max Delta (ms) Max Jitter (ms) Mean Jitter (ms) Pb?
57.10
6.39
1.36
31.70
3.49
1.11
De los 45 paquetes que fueron transmitidos durante la llamada, 20 corresponden a la extensión llamante 8000 con una
participación del 44,44% sobre el total de los paquetes, mientras que la extensión llamada 8001 tuvo una participación de 25
paquetes, con una participación del 55,56%
Tabla 57. Estadística para protocolo RTP prueba llamada IAX a IAX2
Llamada entre extension IAX2 y extensión IAX2
IP
192168100240 192168100249
192168100243 192168100249
TCP
192168100249 192168100243
UDP
192168100240 192168100249
192168100243 192168100249
Total general
Fuente Estadísticas generales prueba 6 tomadas con Wireshark
89
Packets
45
20
25
2
2
43
20
23
90
Bytes
5.350
1333
4017
148
148
5.202
1333
3869
10.700
3.4.7.Prueba de IAX2 a SIP
Tabla 58. Prueba de IAX2 a SIP
NUMERO DE
PRUEBA:
7
NOMBRE DE
PRUEBA:
Llamada extensión IAX2 a extensión SIP
RECURSOS:
Servidor, maquina 1, Maquina 2
DESCRIPCION
DE PRUEBA:
La extensión 8000 configurada en el softphone ZOIPER
FREE(Maquina 1) realiza llamada a extensión 6000 con X-LITE.
RESULTADOS
ESPERADOS:
La extensión 8000 se pueda comunicar con la extensión 6000, a
través del servidor Asterisk.
RESULTADO
DE LA
PRUEBA:
DESCRIPCION
DE
RESULTADOS:
Exitosa
L a extensión de llamada saliente 8001 corresponde a la dirección
IP 192.169.100.240
La extensión llamada entrante es la 6000 la cual se encuentra
ubicada con la dirección IP 192.168.100.243
90
En estos momentos la extensión 8001 está marcando a la
extensión 6000, y solicita respuesta de la llamada.
La extensión 9000, acepta la llamada.
Mensaje enviado por extensión 8001: Este es un mensaje de la
Fundación Universitaria Konrad Lorenz.
91
Mensaje Recibido por la extensión 8001: Resultado de prueba
exitosa
Fuente Desarrollo de llamada Prueba 7
Análisis de prueba: A continuación se muestra la secuencia de protocolos de
señalización durante la llamada, a través de lo cual se logra validar la
secuencia de la señalización de IAX2 a SIP. Esta secuencia se puede validar
completa en el anexo digital de las pruebas adjuntas a este documento.
Anexo A6. Secuencia de protocolos en llamada IAX2 a SIP.
A continuación se reflejan estadísticas de la prueba:
Tabla 59. Resumen prueba llamada IAX2 a SIP
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
Fuente Estadísticas tomadas con Wireshark Prueba 7
92
2889
20,758
139,173
146,806
424130
20431,73
0,163
En la estadística, se indica que se transmitieron 2.889 paquetes, los cuales tuvieron una duración de transmisión de 20,758
segundos. Lo que indica que por segundo se transmiten 139,173 paquetes. De los paquetes transmitidos 6 tienen un tamaño
entre 80-159 bytes, 1429 tienen un tamaño entre 160-319,4 tienes un tamaño entre 320-639, 2 tienen un tamaño entre 6401279 y 1.448 paquetes tienen un tamaño entre 40-79 bytes.
Tabla 60. Estadística para protocolo IP prueba llamada IAX2 a SIP
Address A
Address B
192.168.100.243 192.168.100.249
192.168.100.240 192.168.100.249
Packets
1438
1451
POR PROTOCOLO IP
Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
Rel Start
309880
729
157021
709
152859 4.513.137.000
114250
721
56817
730
57433 4.506.953.000
Duration
bps A->B bps A<-B
20,7522 60531,76
58927,3
16,6577 27286,76
27582,6
Fuente Estadística protocolo IP tomada con Wireshark de Prueba 7
Tabla 61. Estadística para protocolo UDP prueba llamada IAX2 a SIP
Address A
192.168.100.243
192.168.100.243
192.168.100.243
192.168.100.240
POR PROTOCOLO UDP
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.100.249
7 3898
4
1907
3
1991
192.168.100.249
8 1460
6
1248
2
212
192.168.100.249
1423 3E+05
719
153866
704
150656
192.168.100.249
1451 1E+05
721
56817
730
57433
Rel Start
Duration bps A->B
4.513.137.000
207.522 735.15
6.840.937.000
142.252 701.85
6.872.120.000
141.929 86728.72
4.506.953.000
166.577 27286.76
bps A<-B
767.53
119.22
84919.36
27582.60
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 7
Tabla 62. Estadística para protocolo RTP prueba llamada IAX2 a SIP
Src IP addr
192.168.100.243
192.168.100.249
Dest IP addr
SSRC
192.168.100.249 0x6084FDB5
192.168.100.243 0x7C39359C
Payload
ITU-T G.711 PCMU
ITU-T G.711 PCMU
RTP
Packets
Lost
719 0 (0.0%)
704 0 (0.0%)
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 7
93
Max Delta (ms) Max Jitter (ms) Mean Jitter (ms)
36.81
7.17
5.02
44.18
12.02
1.19
Pb?
De los 2889 paquetes que fueron transmitidos durante la llamada, 1451 corresponden a la extensión llamante 8000 con una
participación del 50.22% sobre el total de los paquetes, mientras que la extensión llamada 6000 tuvo una participación de
1438 paquetes, con una participación del 49,78%.
Tabla 63. Estadística paquetes y bytes protocolos prueba llamada IAX2 a SIP
Llamada entre extension IAX2 y extensión SIP
IP
192168100240 192168100249
192168100243 192168100249
UDP
192168100240 192168100249
192168100243 192168100249
Total general
Fuente Estadísticas generales prueba 7 tomadas con Wireshark
94
Packets
2.889
1451
1438
2.889
1451
1438
5.778
Bytes
424.130
114250
309880
424.130
114250
309880
848.260
3.4.8.Prueba de IAX2 a H323
Tabla 64. Prueba de IAX2 a SIP
NUMERO DE
PRUEBA:
8
NOMBRE DE
PRUEBA:
Llamada extensión IAX2 a extensión H.323
RECURSOS:
Servidor, maquina 1, Maquina 2
DESCRIPCION
DE PRUEBA:
La extensión 8000 configurada en el softphone ZOIPER FREE
(Maquina 1) realiza llamada a extensión 9000 con SJPHONE.
RESULTADOS
ESPERADOS:
La extensión 8000 se pueda comunicar con la extensión 9000, a
través del servidor Asterisk.
RESULTADO
DE LA
PRUEBA:
DESCRIPCION
DE
RESULTADOS:
EXITOSA
L a extensión de llamada saliente 8001 corresponde a la dirección
IP 192.169.100.240
La extensión llamada entrante es la 9000 la cual se encuentra
ubicada con la dirección IP 192.168.100.243
95
En estos momentos la extensión 8001 está marcando a la
extensión 9000, y solicita respuesta de la llamada.
La extensión 9000 acepta la llamada.
96
Mensaje enviado por extensión 8001: Este es un mensaje de la
Fundación Universitaria Konrad Lorenz.
Mensaje Recibido por la extensión 8001: Resultado de prueba
exitosa
Fuente Desarrollo de llamada Prueba 8
Análisis de prueba: A continuación se muestra la secuencia de protocolos de
señalización durante la llamada, a través de lo cual se logra validar la
secuencia de la señalización de IAX2 a SIP. Esta secuencia se puede validar
completa en el anexo digital de las pruebas adjuntas a este documento.
Anexo A7. Secuencia de protocolos en llamada IAX2 a H.323.
97
A continuación se reflejan estadísticas de la prueba:
Tabla 65. Resumen prueba llamada IAX2 a H.323
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
2057
18,331
112,212
84,482
173780
9479,924
0,076
Fuente Estadísticas tomadas con Wireshark Prueba 8
En la estadística, se indica que se transmitieron 2.057 paquetes, los cuales tuvieron una duración de transmisión de 18,331
segundos. Lo que indica que por segundo se transmiten 112,212 paquetes. De los paquetes transmitidos 1000 tienen un
tamaño entre 80-159 bytes, 2 tienen un tamaño entre 160-319, 6 tienes un tamaño entre 320-639, 2 tienen un tamaño entre
640-1279 y 1.047 paquetes tienen un tamaño entre 40-79 bytes.
Tabla 66. Estadística para protocolo IP prueba llamada IAX2 a H.323
Address A
192.168.100.240
192.168.100.243
POR PROTOCOLO IP
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
Rel Start
Duration bps A->B bps A<-B
192.168.100.249
1020 80188
506
39798
514
40390 0.000361000
18,3314 17368,26 17626,61
192.168.100.249
1037 93592
519
46727
518
46865 4.404.498.000
13,8577 26975,36
27055,3
Fuente Estadística protocolo IP tomada con Wireshark de Prueba 8
98
Tabla 67. Estadística para protocolo TCP prueba llamada IAX2 a H.323
Address A
192.168.100.249
192.168.100.249
POR PROTOCOLO TCP
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.100.243
11 1912
7
1230
4
682
192.168.100.243
23 1630
14
986
9
644
Rel Start
Duration bps A->B bps A<-B
4.914.696.000
13
3475
737
4.950.225.000
13
3115
592
Fuente Estadística protocolo TCP tomada con Wireshark de Prueba 8
Tabla 68. Estadística para protocolo UDP prueba llamada IAX2 a H.323
Address A
192.168.100.243
192.168.100.243
192.168.100.243
192.168.100.243
192.168.100.240
POR PROTOCOLO UDP
Address B
Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
Rel Start
Duration bps A->B bps A<-B
192.168.100.249
1
106
0
0
1
106 13.471.262.000
0 N/A
N/A
192.168.100.249
5
438
0
0
5
438 4.408.661.000
11,9996 N/A
292,1
192.168.100.249
7 3376
4
1727
3
1649 4.404.498.000
4,0581 3404,55
55,325
192.168.100.249
990 86130
502
43674
488
42456 8.296.193.000
9,9557 35094,69 69,34115
192.168.100.249
1020 80188
506
39798
514
40390 0.000361000
18,3314 17368,26 26,17626
Fuente Estadística protocolo UDP tomada con Wireshark de Prueba 8
Tabla 69. Estadística para protocolo RTP prueba llamada IAX2 a H.323
Src IP addr
Dest IP addr
SSRC
192.168.100.243 192.168.100.249 0xA3F435B
192.168.100.249 192.168.100.243 0x7CDBB9D1
Payload
GSM 06.10
GSM 06.10
RTP
Packets
Lost
502 0 (0.0%)
488 0 (0.0%)
Fuente Estadística protocolo RTP tomada con Wireshark de Prueba 8
99
Max Delta (ms) Max Jitter (ms) Mean Jitter (ms) Pb?
28.99
4.24
3.10
X
34.44
6.19
0.79
Dentro de la estadística del protocolo RTP, 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 hubo 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%.
Tabla 70. Estadística paquetes y bytes protocolos prueba llamada IAX2 a H.323
Llamada entre extension IAX2 y extensión H.323
IP
192168100240 192168100249
192168100243 192168100249
TCP
192168100249 192168100243
UDP
192168100240 192168100249
192168100243 192168100249
Total general
Packets
2057
1020
1037
34
34
2023
1020
1003
4114
Fuente Estadísticas generales prueba 7 tomadas con Wireshark
100
Bytes
173780
80188
93592
3542
3542
170238
80188
90050
347560
3.4.9.Análisis general
La tabla que se relaciona a continuación, consolida las pruebas efectuadas
para el análisis del comportamiento del protocolo de señalización H.323.Una
primera división indica los resultados que se obtuvieron de llamadas de
extensiones configuradas bajo el protocolo H.323 a llamadas a extensiones con
el mismo protocolo y a extensiones configuradas con protocolos IAX2 y SIP.
Tabla 71. Consolidado de pruebas H323
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
Fuente Estadísticas generales llamadas en H323 tomadas con Wireshark
Durante las llamadas entre extensiones que tienen configurado el protocolo
H.323, cada una de las direcciones IP de las extensiones 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 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.
Tabla 72. Estadística paquetes y bytes protocolos prueba llamada IAX2 a H.323
Address A
Address B Packets Bytes Packets A->B Bytes A->B Packets A<-B Bytes A<-B
192.168.99.44 192.168.100.249
895 78667
447
39349
448
39318
llamada de H.323 A H.323 192.168.100.249 192.168.103.16
746 68224
381
34894
365
33330
192.168.100.249 192.168.103.16
1872 147348
1135
89405
737
57943
llamada de H.323 A IAX2 192.168.99.44 192.168.100.249
2442 213818
1294 113296
1148 100522
Fuente Estadísticas generales de las prueba tomadas con Wireshark
Como se observa en la tabla anterior, 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, esto se debe a que dentro del proceso
101
de señalización que ocurre durante la llamada, las tramas de señalización del
IAX2 son mucho menores a las enviadas por el protocolo H.323.
En la siguiente tabla, se refleja que la llamada realizada entre extensiones
IAX2, el proceso de señalización es mucho menor a los enviados y recibidos
por las extensiones configuradas con el H.323 y SIP. Lo anterior, se debe a
que en el proceso de señalización los mensajes de codifican en forma binaria y
las tramas se empaquetan en un solo canal, lo que permite enviar voz, con su
respectiva señal con un mismo encabezado, lo que indica un menor consumo
de ancho de banda.
Tabla 73. Estadística paquetes y bytes protocolos prueba llamada IAX2 y H.323
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 IAX2 a protocolos
H.323
IAX2
SIP
2057
45
2889
18,331
17,432
20,758
112,212
2,581
139,173
84,482
118,889
146,806
173780
5350
424130
9479,924
306,903
20431,73
0,076
0,002
0,163
llamada a extensión IAX2 de protocolos
SIP
H.323
2194
1641
12.805,000
8,762
171,343
187,291
149,087
89,513
327097
146891
25545,082
16765,037
0,204
0,134
Uno de los factores influyentes para que el protocolo IAX2 sea el protocolo más
rápido en el proceso de señalización, es que este protocolo fue diseñado para
cubrir la necesidad de comunicación en menor tiempo posible y consumo de
ancho de banda entre servidores, lo que lo hace aún más potente.
102
4.CONCLUSIONES
Y RECOMENDACIONES
Asterisk es una herramienta muy poderosa que ofrece un alto grado de
funcionalidad y escalabilidad en sus soluciones, ajustándose apropiadamente a
los requerimientos que se necesiten. 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.
En lo posible es deseable ajustar tanto el sistema operativo como el hardware
para que Asterisk funcione correctamente, que el servidor sea para uso
exclusivo de Asterisk, ya que al ser un producto de software esta sujeto a las
mismas limitaciones que un software tradicional. Los mayores inconvenientes
que presenta son:
Susceptible a fallos de software
disponibilidad de herramientas.
imprevistos,
compatibilidad
y
Susceptible a fallos de seguridad, como lo son el hacking y los virus.
Susceptible a fallos de hardware, ya que depende totalmente de que se
encuentren en buen estado.
Susceptible a fallos de configuración, esto debido a que, como es de
licencia GPL, su código de desarrollo es accesible, lo hace vulnerable a
errores humanos
Desempeño susceptible a otras herramientas de software, ya que si el
servidor no es dedicado solo a prestar Asterisk, puede que otros
software instalados consuman recursos tanto de red como de máquina
que sean necesarios para que Asterisk de su mayor rendimiento.
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,
empaquetamiento de datos e historia.
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, lo que
hace que a pesar que la duración de una llamada en condiciones normales
(Terminal A realiza una llamada, en donde solo se transmite voz, a la Terminal
B) para el estándar h323 se envían más paquetes y su conexión es más
compleja que la misma llamada realizarla con IAX2, ya que para el H323, se
hace necesario el uso de los protocolos H.225 y H.245.
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
103
esto, el asegurar la calidad de las llamadas depende también del
comportamiento de cada softphone, ya que Asterisk (dentro de lo investigado)
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.
104
REFERENCIAS BIBLIOGRÁFICAS
A. Libros
 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.:

UIT-T. Rec. H.323 (06/2006). “Serie H: Sistemas Audiovisuales y
Multimedia Sistemas de comunicación multimedia basados en
paquetes”. Unión internacional de telecomunicaciones 13 de junio del
2006 procedimiento de recomendación UIT-T A.8.

María Carmen España Boquera. “Servicios avanzados de
telecomunicación” Edo. Illustrated Publicado por Ediciones Díaz de
Santos, 2003. ISBN 8479786078, 9788479786076
 Cisco System, “integración de redes de voz y datos”. ISBN- 84-2832820-X
 Daniel Collins. “ Carrier Grade Voice Over IP”. McGraw-Hill Professional
Publishing, Septiembre 2000
 Syngress Media, Elliot Lewis, Syngress Media, Matt Campisi y Elliott
Lewis,” IP Telephony”. Editoral McGraw-Hill, 1998
 Walter Goralski. Matthew C. Kolon.
Professional Publishing, Agosto 1998
“IP Telephony”. McGraw-Hill
 Flavio E. Gonҫ alves.”Asterisk PBX Guía de configuración”,
Florianópolis, Título independiente, 2007, ISBN 978-85-906904-3-6
B. Publicaciones periódicas
 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
 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
105
 Download
“The
Future
of
Telephony”
Asterisk.
http://www.cyberciti.biz/tips/download-asterisk-howto-tutorial-book.html
(Page On line).
 Digium, Inc. About Asterisk
http://www.asterisk.org
[on-line].
Disponible
en
Internet:
 Voipforo © 2009 [on-line], disponible en internet http://www.voipforo.com
 VOIP-Info.org
© 2003-2008 LLC[on-line]. Disponible en internet
http://www.voip-info.org/
E. Entrevista (Comunicación verbal Privada)
 Dr. Juan David Abreo. Director General de Tecnología. Proyecto
Interconexión WAN – TELEFONIA IP. SENA. Bogotá. Colombia.
106