ANALISIS DE REQUERIMIENTOS E IMPLEMENTACIÓN · PDF fileEstadística para...

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.

4

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.

1

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

2

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

3

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

4

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

5

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

6

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

7

Figura 28. Ventana de control Wireshark .......................................................... 48

Figura 29. Ventana Sjphone. ............................................................................ 48

Figura 30. Ventana Zoiper ................................................................................ 49

8

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

9

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).

10

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.

11

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 cliente-servidor.

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 Marzo Abril Mayo-Junio

Instalación de Asterisk y Revisión de la Bibliográfica disponible

Exploración inicial de las funcionalidades de Asterisk

Identificación de los requerimientos

técnicos para la realización de un plan de pruebas completo y básico sobre Asterisk.

Realización del plan de pruebas

básicos.

Documentación del proyecto

12

2.MARCO TEORICO.

2.1.ANTECEDENTES

2.1.1.Históricos 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).

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.

13

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. 2RTC 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.

14

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 Internet

flujo de información llamadas paquetes

tipo de red dedicada no dedicada

identificador en la red número telefónico

direcciones IP

Donde se conmutan los flujos de información Central telefónica 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.

15

Figura 1. Esquema PBX

PSTN(RTC -RTB)

PBX

EMPRESA

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.

16

Figura 2. Esquema PBX y Asterisk

PSTN(RTC -RTB)

PBX IP

EMPRESAVoz IP

Troncal Análoga

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

17

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. UIT-H.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:

18

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.

19

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.

20

Figura 5. Funciones Distribuidas de MP y MD


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


21

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

MC+MP

H.245 Sesiones de control de medios con el MC

Flujos de medios al MP

Flujo de audio mezclado por MP

Multidifusión


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

22

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


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

23

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

24

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


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

25

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.

26

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.

mailto:[email protected]

27

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.

28

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:

29

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”

30

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 Significado

DISCONNECT Finalizar una llamada.

RELEASE Liberar la llamada

RELEASE COMPLETE Acuse de RELEASE

RESTART Rearranque del protocolo de nivel de red

RESTART ACKNOWLEDGE Acuse de rearranque Fuente. María Carmen España Boquera. “Servicios avanzados de telecomunicación”

Tabla 7. Mensajes Misceláneas

Mensaje Significado

CONGESTION CONTROL Control de flujo de USER INFORMATION

FACILITY Petición opcional de servicios de usuario

INFORMATION Información adicional durante el establecimiento

NOTIFY Indica la información pertinente para una llamada

REGISTER Asigna un valor de referencia de llamada

STATUS Indica el estado del canal

STATUS ENQUIRY 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.

31

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 Solicitud Confirmación Rechazo

Descubrimiento del gateway GRQ GCF GRJ

Registro con gatekeeper RRQ RCF RRJ

Sin registros con gatekeeper URQ UCF URJ

Localización de puntos finales en una zona diferente 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. 21

El mensaje en este sentido, corresponde al tipo de acción que se encuentran incluido en el paquete.

32

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,

33

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)

154

TERMINAL H.323 (Entidad llamada)

454

GK

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


154


454

GK


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).

34

Figura 16. Establecimiento de conexión


154


454

GK

SETUP


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


154


454

GK

SETUP


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.

35

Figura 18. Establecimiento canal H.245


154


454

GK

SETUP


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


154


454

GK

SETUP

MENSAJES H.245:termCapabilitySet Openlogicalchannel


36

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.


154


454

GK

SETUP


FLUJO RTP

FLUJO RTP

FLUJO RTCP


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.

37

Figura 21. Terminación de llamada


154


454

GK

SETUP


FLUJO RTP

FLUJO RTP

FLUJO RTCP

MENSAJES H.245:CloselogicalChannel EndSessionCommand


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.

38

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)

39

Figura 22. Trama F fullframe

F Número de llamada de Origen R Número de llamada de Destino

Sello de Tiempo

Secuencia de Salida

Secuencia de Entrada Tipo de Trama C Subclase

Datos Tipos de trama [Online]. España. Avianle from internet: < http://voipforo.com/IAX/IAX-frames.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.

40

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/IAX-frames.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 Descripción Detalles

00000001 DTMF Sirve para enviar dígitos DTMF.

00000002 Datos de voz El campo subclase indica el tipo de códec de audio que se utiliza.

00000003 Datos de

video El campo subclase indica el tipo de códec de video que se utiliza.

00000004 Control

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.

00000005 No usado

00000006 Control IAX

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.

00000007 Texto

00000008 Imagen

00000009 HTML

Valores de las tramas [Online]. España. Avianle from internet: < http://voipforo.com/IAX/IAX-F-frames.php>, Abril-Mayo 2009

41

Tabla 10. Valor de subclase con tipo de trama para datos de voz

Valor subclase (Type Frame =0x02)

Datos de Voz

Descripción (códec que se

utiliza en la conversación)

0x0001 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


Tabla 11. Valor de subclase con tipo de trama control

Valor subclase (Type Frame

=0x04) Control Descripción Detalles

0x01 Hangup La llamada se ha

colgado

0x02 Ring El telefono esta

sonando

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


42

Tabla 12. Valor de subclase con tipo de trama control iax

Valor subclase (Type Frame =0x06) Control

IAX Descripción Detalles

0x01 NEW Iniciar una nueva llamada

0x02 PING Enviar un ping

0x03 PONG Responder un ping

0x04 ACK Respuesta afirmativa

0x05 HANGUP Inicio de desconexión

0x06 REJECT Rechazo

0x07 ACCEPT Aceptación

0x08 AUTHREQ Petición de autenticación

0x09 AUTHREP Respuesta de autenticación

0x0a INVAL LLamada no válida

0x0b LAGRQ Petición de Lag

0x0c LAGRP Respuesta de Lag

0x0d REGREQ Petición de registro

0x0e REGAUTH Autenticación de registro

0x0f REGACK ACK de registro

0x10 REGREJ Denegación de registro

0x11 REGREL Liberación de registro

0x12 VNAK Petición de retransmisión

0x13 DPREQ Petición de dialplan

0x14 DPREP Respuesta de dialplan

0x15 DIAL Marcado

0x16 TXREQ Petición de transferencia

0x17 TXCNT Conexión de transferencia

0x18 TXACC Aceptación de transferencia

0x19 TXREADY Transferencia preparad

0x1a TXREL Liberación de transferencia

0x1b TXREJ Rechazo de transferencia

0x1c QUELCH Parar transmisión de audio

0x1d UNQUELCH Continuar transmisión de

audio

0x20 MWI Indicador de mensaje en

espera

0x21 UNSUPPORT Mensaje no soportado


43

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

44

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

45

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 Contenido

/etc/Asterisk Archivos de configuración

/usr/sbin Archivos binarios, scripts y ejecutables

/usr/lib/Asterisk Objetos binarios de Asterisk

/usr/lib/Asterisk/modules Modulos de ejecución de aplicaciones (canales,dirvers,formatos)

/usr/incluye/Asterisk Archivos de cabecera de los modulos

/var/lib/Asterisk Variables utilizadas en la ejecución normal

/var/lib/Asterisk/agi/bin scripts AGI para ser utilizados con las aplicaciones AGI en el plan de numeración

/var/lib/Asterisk/astdb Base de datos de Asterisk

/var/lib/Asterisk/images Imágenes

46

/var/lib/Asterisk/keys keys públicas y privadas( Autenticación RSA)

/var/lib/Asterisk/moh/mp3 Música para llamadas en espera en formato MP3

/var/lib/Asterisk/sounds Prompts , archivos de audio

/var/run Runtime (pipes, archivos PID)

/var/run/Asterisk/pid Identificadores de proceso primarios (PID)

/var/run/Asterisk/ct Modo remoto de operación

/var/spool/Asterisk Cola de espera para el buzón de voz

var/log/Asterisk/cdr-csv Archivo Master registro de llamda

/var/spool/Asterisk/vm 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 Canales para Voz

IP Canales internos

Asterisk

Chan_zap Chan_sip Chan_agent TDM400P – 4 puertas analógicas FXS o

FXO Chan_iax Chan_console TDM800P - 8 puertas analógicas Chan_h323 Chan_local

TDM2400 - 24 puertas analógicas FXS o FXO Chan_mgcp

chan_phone Chan_sccp

Tarjeta quicknet Códecs

Tarjeta phonejack G.711 ulaw (usado en EUA) – (64 Kbps). Tarjeta linejack G.711 alaw (usado en Europa – (64 Kbps).

chan_ss7 GSM – (12-13 Kbps) Tarjetas Digium con señalización 7 (ISUP) iLBC – (15 Kbps)

chan_bluetooth LPC10 - (2.5 Kbps) Permite el uso de dispositivos Bluetooth Speex - (2.15-44.2 Kbps)

G.729 (8Kbps) Fuente Flavio E. Goncalvez. “Manual Asterisk”

47

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)

48

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

49

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.

50

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 costo-beneficio.

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.

51

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

52

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(x86-x64), 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

53

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.

54

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.

55

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. IP Mascara de

subred 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 4 Ghz Windows Vista 192.168.100.238 255.255.255.0 192.168.100.2 192.168.100.1

Portátil_2 Pentium Dual Core 3 Ghz Windows Vista 192.168.100.240 255.255.255.0 192.168.100.2 192.168.100.1

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 SIP x-Lite

56

2

Ordenador 2 8000 IAX2 Zoiper

Ordenador 2 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

57

Tabla 17. Descripción de tabla plan de pruebas.

Nombre del campo Descripción

Paquetes 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) Corresponde al promedio de paquetes enviados por segundo.

Prom. Tamaño de Paquetes Es el promedio del tamaño de paquetes que captura y analiza Wireshark

Bytes Es el número de bytes transmitidos durante la llamada

Prom. Bytes por segundo El promedio de bytes que se transmiten por segundo

Prom. Mbits 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 Packets A->B Bytes A->B

Corresponde a la dirección IP que envía origen del paquete

Corresponde a la dirección IP destino del paquete

Corresponde al total de paquetes enviados de la dirección IP origen a la dirección IP destino del paquete

Total de bytes enviados de la dirección IP de origen a la dirección IP destino del paquete

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.

Fuente Estadísticas de protocolos por Wireshark

58

Tabla 19. Definición de protocolos parte B

NOMBRE DE PROTOCOLO

Packets A<-B Bytes A<-B Rel Start Duration bps A->B bps 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.

Instantes de Tiempo

Tiempo en segundos de la transmisión de paquetes

Bits por segundo enviados de la dirección A a la 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

RTP

Src IP addr Dest IP addr Payload Packets Lost Max Delta (ms)

Dirección IP que origina el paquete.

Dirección IP destino del paquete.

Códecs Número de paquetes transmitidos.

Numero de paquetes perdidos durante la llamada.

Corresponde a la máxima latencia que presenta un paquete, en el momento de la transmisión.

Fuente Estadística protocolo RTP Wireshark

59

Tabla 21. Estadística protocolo RTP parte B

RTP

Max Jitter (ms) Mean Jitter (ms) Pb?

Corresponde a la máxima variación de tiempo entre la llegada de los distintos paquetes.

Promedio de variación de tiempo entre la llegada de los distintos paquetes.

Campo control que indica si durante la transmisión de paquetes se dio falla. Sí es así, el analizador de Wireshark colocará el carácter "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.

60

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 DE PRUEBA:

La extensión 9001 configurada en el softphone SJPHONE (Ordenador 1) realizada llamada a extensión 9000 con SJPHONE(Ordenador 2).

RESULTADOS ESPERADOS:

La extensión 9001 se pueda comunicar con la extensión 9000, a través del servidor Asterisk.

RESULTADO DE LA PRUEBA:

EXITOSA

DESCRIPCION DE RESULTADOS:

L a extensión de llamada saliente 9001 corresponde a la dirección IP 192.168.99.44

La extensión llamada entrante es la 9000 la cual se encuentra ubicada con la dirección IP 192.168.103.16

61

En este momento la extensión 9001 está marcando a la extensión 9000 y solicita respuesta.

62

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

63

A continuación se reflejan estadísticas de la prueba:

Tabla 23. Resumen prueba llamada de H.323 a H.323

Paquetes 1641

tiempo entre la primera y ultimo paquete (seg) 8,762

Prom. Paquetes por segundo (bytes) 187,291

Prom. Tamaño de Paquetes 89,513

Bytes 146891

Prom. Bytes por segundo 16765,037

Prom. Mbits por segundo 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 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 192.168.103.16 746 68224 381 34894 365 33330 2.507.465.000 8,7118 32043,04 82

192.168.99.44 192.168.100.249 895 78667 447 39349 448 39318 2.493.599.000 8,7617 35928 69

POR PROTOCOLO IP

Fuente Estadísticas protocolo IP tomadas con Wireshark de Prueba 1

64

Tabla 25. Estadística para protocolo TCP prueba llamada H.323 a H.323


192.168.100.249 192.168.103.16 14 2180 8 1312 6 868 2.892.530.000 8,3204 1261,47 834,57

192.168.99.44 192.168.100.249 20 2893 10 1476 10 1417 2.493.599.000 8,7356 1351,71 1297,68

192.168.100.249 192.168.99.44 22 1544 13 907 9 637 2.651.306.000 8,604 843,32 592,28

192.168.100.249 192.168.103.16 26 1828 16 1118 10 710 3.027.397.000 8,1919 1091,82 693,37

POR PROTOCOLO TCP

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


192.168.99.44 192.168.100.249 1 106 0 0 1 106 7.994.637.000 0 N/A N/A

192.168.103.16 192.168.100.249 1 106 0 0 1 106 9.474.627.000 0 N/A N/A

192.168.100.249 192.168.103.16 4 344 4 344 0 0 2.507.800.000 3,9502 696,68 N/A

192.168.100.249 192.168.103.16 7 3388 3 1651 4 1737 2.507.465.000 1,9523 6765,40 7117,81

192.168.103.16 192.168.100.249 694 60378 345 30015 349 30363 4.276.536.000 6,9240 34679,58 35081,66

192.168.99.44 192.168.100.249 852 74124 428 37236 424 36888 2.679.325.000 8,5405 34879,65 34553,67

POR PROTOCOLO UDP

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 Packets Lost Max Delta (ms)Max Jitter (ms)Mean Jitter (ms) Pb?

192.168.99.44 192.168.100.249 0x10838907 GSM 06.10 428 0 (0.0%) 20.11 0.02 0.01 X

192.168.100.249 192.168.99.44 0x46255EE9 GSM 06.10 424 0 (0.0%) 56.49 107.64 2.01 X

192.168.103.16 192.168.100.249 0x264DA484 GSM 06.10 345 0 (0.0%) 20.15 0.05 0.03 X

192.168.100.249 192.168.103.16 0x38948A95 GSM 06.10 349 0 (0.0%) 52.36 97.49 5.91

RTP

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

65

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 Packets Bytes

IP 1.641 146.891

192.168.99.44 / 192.168.100.249 895 78.667

192.168.100.249 / 192.168.103.16 746 68.224

TCP 82 8.445

192.168.99.44 / 192.168.100.249 20 2.893

192.168.100.249 / 192.168.103.16 40 4.008

192.168.100.249 / 192.168.99.44 22 1.544

UDP 1.559 138.446

192.168.103.16 / 192.168.100.249 695 60.484

192.168.99.44 / 192.168.100.249 853 74.230

192.168.100.249 / 192.168.103.16 11 3.732 Fuente Resumen estadísticas tomadas con Wireshark de la Prueba 1

66

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


La extensión 9001 configurada en el softphone SJPHONE(Ordenador 1) realizada llamada a extensión 8000 con ZOIPER


La extensión 9001 se comunica con la extensión 8000, a través del servidor Asterisk.


EXITOSA




67

En este momento la extensión 9001 está marcando a la extensión 8000 y solicita respuesta.


68



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 Packets Bytes

IP 4.314 361.166

192.168.99.44 192168100249 2442 213818

192168100249 192.168.103.16 1872 147348

TCP 37 4.059

192.168.99.44 192168100249 21 2947

192168100249 192.168.99.44 16 1112

UDP 4.269 356.187

192.168.99.44 192168100249 2397 208839

192168100249 192.168.103.16 1872 147348

Total general 8.620 721.412 Fuente Estadísticas generales prueba 2 tomadas con Wireshark

69

Anexo A2. Secuencia de protocolos en llamada H.323 a IAX2


Tabla 31. Resumen prueba llamada de H.323 a IAX2


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.

70

Tabla 32. Estadística para protocolo IP prueba llamada H.323 a IAX2


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 147348 1135 89405 737 57943 5.412.270.000 32,9678 21695,12 14060,52

192.168.99.44 192.168.100.249 2393 208415 1277 111323 1116 97092 15.994.706.000 25,3611 35116,9 30627,2

POR PROTOCOLO IP

Fuente Estadística protocolo IP tomada con Wireshark de Prueba 2

Tabla 33. Estadística para protocolo TCP prueba llamada H.323 a IAX2


192.168.100.249 192.168.99.44 16 1112 9 615 7 497 15.975.562.000 25,3964 193,73 156,56

192.168.99.44 192.168.100.249 21 2947 10 1476 11 1471 15.926.922.000 25,4457 464,5 462,47

POR PROTOCOLO TCP


Tabla 34. Estadística para protocolo UDP prueba llamada H.323 a IAX2


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

POR PROTOCOLO UDP


71

Tabla 35. Estadística para protocolo RTP prueba llamada H.323 a IAX2

Src IP addr Dest IP addr SSRC Payload Packets Lost Max Delta (ms) Max Jitter (ms) Mean Jitter (ms) Pb?

192.168.99.44 192.168.100.249 0x23E35831 GSM 06.10 1269 0 (0.0%) 20.22 0.07 0.03 X

192.168.100.249 192.168.99.44 0x304E272E GSM 06.10 1116 0 (0.0%) 54.58 4.16 1.37

RTP


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%.

72

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


La extensión 9001 configurada en el softphone SJPHONE(Ordenador 1) realizada llamada a extensión 6000 con X-LITE (Ordenador 2).


La extensión 9001 se comunica con la extensión 6000, a través del servidor Asterisk.


NO EXITOSA


No se pudo establecer comunicación, ya que al llamar desde una extensión de H.323 a una extensión SIP, el servidor Asterisk no reconoce el flujo normal de la llamada, y por ende no hay registros en el servidor de la llamada.


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).

73

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


La extensión 6001 configurada en el softphone X-LITE(Maquina 1) realiza llamada a extensión 9000 con SJPHONE.




Exitoso


L a extensión de llamada saliente es 6001 correspondiente a la dirección IP 192.169.100.240


74

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.

75


Mensaje Recibido por la extensión 6001: Resultado de prueba exitosa.


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.

76

Tabla 38. Resumen prueba llamada de SIP a H.323

Paquetes 2548




Bytes 387531




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


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

POR PROTOCOLO IP


Tabla 40. Estadística para protocolo TCP prueba llamada SIP a H.323


192.168.100.249 192.168.100.243 11 1922 6 1174 5 748 7.886.790.000 15,5258 604,93 385,42

192.168.100.249 192.168.100.243 14 994 9 628 5 366 8.130.569.000 15,1584 331,43 193,16

POR PROTOCOLO TCP


77

Tabla 41. Estadística para protocolo UDP prueba llamada SIP a H.323


192.168.100.243 192.168.100.249 2 212 0 0 2 212 16.109.218.000 4,995 N/A 339,23

192.168.100.243 192.168.100.249 5 453 0 0 5 453 7.909.680.000 11,9989 N/A 302,3

192.168.100.243 192.168.100.249 7 3383 4 1731 3 1652 7.883.602.000 3,1835 4349,89 4151,37

192.168.100.240 192.168.100.249 7 1242 5 1030 2 212 11.070.197.000 12,1731 676,9 139,32

192.168.100.240 192.168.100.249 10 6946 5 3904 5 3042 7.877.351.000 15,4092 2026,84 1579,32

192.168.100.240 192.168.100.249 1225 3E+05 607 129898 618 132252 11.094.511.000 12,1866 85272,6 86817,9

192.168.100.243 192.168.100.249 1267 1E+05 660 57420 607 52809 11.094.339.000 13,13 35300,2 32465,49

POR PROTOCOLO UDP


Tabla 42. Estadística para protocolo RTP prueba llamada SIP a H.323


192.168.100.243 192.168.100.249 0x28967D GSM 06.10 660 0 (0.0%) 23.69 3.56 2.60 X

192.168.100.249 192.168.100.240 0x51C0939E ITU-T G.711 PCMU 618 0 (0.0%) 51.46 5.99 2.79 X

192.168.100.240 192.168.100.249 0xE6B498E7 ITU-T G.711 PCMU 607 0 (0.0%) 38.40 7.13 2.14

192.168.100.249 192.168.100.243 0x1B30444C GSM 06.10 607 0 (0.0%) 56.74 7.14 2.36

RTP


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

78

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 Bytes

IP 2548 387531

192168100240 192168100249 1242 270338

192168100243 192168100249 1306 117193

TCP 25 2916

192168100249 192168100243 25 2916

UDP 2523 384615

192168100240 192168100249 1242 270338

192168100243 192168100249 1281 114277

Total general 5096 775062

Fuente Estadísticas generales prueba 4 tomadas con Wireshark

79

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



La extensión 6000 configurada en el softphone X-LITE(Maquina 1) realiza llamada a extensión 8000 con ZOIPER FREE.




EXITOSA



la extensión llamada entrante es la 8000 la cual se encuentra ubicada con la dirección IP 192.168.100.243

80



81




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.


Tabla 45. Resumen prueba llamada de SIP a IAX2

Paquetes 2194

tiempo entre la primera y ultimo paquete (seg) 12.805,000



Bytes 327097




82

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


192.168.100.240 192.168.100.249 1092 2E+05 540 118200 552 119884 5.914.029.000 12,797 73892,58 74945,33

192.168.100.243 192.168.100.249 1102 89013 559 44889 543 44124 5.922.982.000 12,7957 28064,96 27586,67

POR PROTOCOLO IP


Tabla 47. Estadística para protocolo TCP prueba llamada SIP a IAX2


192.168.100.249 192.168.100.243 1 74 1 74 0 0 6.058.626.000 0 N/A N/A

POR PROTOCOLO TCP


Tabla 48. Estadística para protocolo UDP prueba llamada SIP a IAX2


192.168.100.243 192.168.100.249 6 2796 3 1147 3 1649 5.922.982.000 2,0256 4529,92 6512,5

192.168.100.240 192.168.100.249 7 1242 5 1030 2 212 7.971.657.000 10,6361 774,72 159,46

192.168.100.240 192.168.100.249 11 7006 6 3964 5 3042 5.914.029.000 12,797 2478,9 1901,7

192.168.100.240 192.168.100.249 1074 2E+05 529 113206 545 116630 7.942.932.000 10,7564 84196,46 86743,4

192.168.100.243 192.168.100.249 1095 86143 556 43742 539 42401 5.934.120.000 12,7846 27371,67 26532,54

POR PROTOCOLO UDP


83

Tabla 49. Estadística para protocolo RTP prueba llamada SIP a IAX2


192.168.100.249 192.168.100.240 0x411D781B ITU-T G.711 PCMU 545 0 (0.0%) 57.10 6.39 1.36

192.168.100.240 192.168.100.249 0x5F1E1FFF ITU-T G.711 PCMU 529 0 (0.0%) 31.70 3.49 1.11

RTP


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 Packets Bytes

IP 2.194 327.097

192168100240 192168100249 1092 238084

192168100243 192168100249 1102 89013

TCP 1 74

192168100249 192168100243 1 74

udp 2.193 327.023

192168100240 192168100249 1092 238084

192168100243 192168100249 1101 88939

Total general 4.388 654.194


84

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



La extensión 8000 configurada en el softphone ZOIPER FREE(Maquina 1) realiza llamada a extensión 8001 con ZOIPER

FREE.




EXITOSO




85



86




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.

87

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.


Tabla 52. Resumen prueba llamada de IAX2 a IAX2

Paquetes 45




Bytes 5350




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.

88

Tabla 53. Estadística para protocolo IP prueba llamada IAX2 a IAX2


192.168.100.240 192.168.100.249 20 1333 11 742 9 591 4.955.516.000 17,4322 340,52 271,22

192.168.100.243 192.168.100.249 25 4017 11 1651 14 2366 4.957.788.000 3,4942 3780 5417

POR PROTOCOLO IP


Tabla 54. Estadística para protocolo TCP prueba llamada IAX2 a IAX2


192.168.100.249 192.168.100.243 2 148 2 148 0 0 4.968.239.000 2,9942 395,42 N/A

POR PROTOCOLO TCP


Tabla 55. Estadística para protocolo UDP prueba llamada IAX2 a IAX2


192.168.100.243 192.168.100.249 6 2790 3 1144 3 1646 4.957.788.000 3,4564 2647,88 3809,8

192.168.100.243 192.168.100.249 17 1079 8 507 9 572 4.961.835.000 3,4901 1162,13 1311,12

192.168.100.240 192.168.100.249 20 1333 11 742 9 591 4.955.516.000 17,4322 340,52 271,22

POR PROTOCOLO UDP


89

Tabla 56. Estadística para protocolo RTP prueba llamada IAX a IAX2


192.168.100.249 192.168.100.240 0x411D781B ITU-T G.711 PCMU 545 0 (0.0%) 57.10 6.39 1.36

192.168.100.240 192.168.100.249 0x5F1E1FFF ITU-T G.711 PCMU 529 0 (0.0%) 31.70 3.49 1.11

RTP


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 Packets Bytes

IP 45 5.350

192168100240 192168100249 20 1333

192168100243 192168100249 25 4017

TCP 2 148

192168100249 192168100243 2 148

UDP 43 5.202

192168100240 192168100249 20 1333

192168100243 192168100249 23 3869

Total general 90 10.700


90

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



La extensión 8000 configurada en el softphone ZOIPER FREE(Maquina 1) realiza llamada a extensión 6000 con X-LITE.




Exitosa




91




92



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.


Tabla 59. Resumen prueba llamada IAX2 a SIP

Paquetes 2889




Bytes 424130




93

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 640-1279 y 1.448 paquetes tienen un tamaño entre 40-79 bytes.

Tabla 60. Estadística para protocolo IP prueba llamada IAX2 a SIP


192.168.100.243 192.168.100.249 1438 309880 729 157021 709 152859 4.513.137.000 20,7522 60531,76 58927,3

192.168.100.240 192.168.100.249 1451 114250 721 56817 730 57433 4.506.953.000 16,6577 27286,76 27582,6

POR PROTOCOLO IP


Tabla 61. Estadística para protocolo UDP prueba llamada IAX2 a SIP


192.168.100.243 192.168.100.249 7 3898 4 1907 3 1991 4.513.137.000 207.522 735.15 767.53

192.168.100.243 192.168.100.249 8 1460 6 1248 2 212 6.840.937.000 142.252 701.85 119.22

192.168.100.243 192.168.100.249 1423 3E+05 719 153866 704 150656 6.872.120.000 141.929 86728.72 84919.36

192.168.100.240 192.168.100.249 1451 1E+05 721 56817 730 57433 4.506.953.000 166.577 27286.76 27582.60

POR PROTOCOLO UDP


Tabla 62. Estadística para protocolo RTP prueba llamada IAX2 a SIP


192.168.100.243 192.168.100.249 0x6084FDB5 ITU-T G.711 PCMU 719 0 (0.0%) 36.81 7.17 5.02

192.168.100.249 192.168.100.243 0x7C39359C ITU-T G.711 PCMU 704 0 (0.0%) 44.18 12.02 1.19

RTP


94

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 Packets Bytes

IP 2.889 424.130

192168100240 192168100249 1451 114250

192168100243 192168100249 1438 309880

UDP 2.889 424.130

192168100240 192168100249 1451 114250

192168100243 192168100249 1438 309880

Total general 5.778 848.260


95

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



La extensión 8000 configurada en el softphone ZOIPER FREE (Maquina 1) realiza llamada a extensión 9000 con SJPHONE.




EXITOSA




96



97




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.

98


Tabla 65. Resumen prueba llamada IAX2 a H.323

Paquetes 2057




Bytes 173780




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


192.168.100.240 192.168.100.249 1020 80188 506 39798 514 40390 0.000361000 18,3314 17368,26 17626,61

192.168.100.243 192.168.100.249 1037 93592 519 46727 518 46865 4.404.498.000 13,8577 26975,36 27055,3

POR PROTOCOLO IP


99

Tabla 67. Estadística para protocolo TCP prueba llamada IAX2 a H.323


192.168.100.249 192.168.100.243 11 1912 7 1230 4 682 4.914.696.000 13 3475 737

192.168.100.249 192.168.100.243 23 1630 14 986 9 644 4.950.225.000 13 3115 592

POR PROTOCOLO TCP


Tabla 68. Estadística para protocolo UDP prueba llamada IAX2 a H.323


192.168.100.243 192.168.100.249 1 106 0 0 1 106 13.471.262.000 0 N/A N/A

192.168.100.243 192.168.100.249 5 438 0 0 5 438 4.408.661.000 11,9996 N/A 292,1

192.168.100.243 192.168.100.249 7 3376 4 1727 3 1649 4.404.498.000 4,0581 3404,55 55,325

192.168.100.243 192.168.100.249 990 86130 502 43674 488 42456 8.296.193.000 9,9557 35094,69 69,34115

192.168.100.240 192.168.100.249 1020 80188 506 39798 514 40390 0.000361000 18,3314 17368,26 26,17626

POR PROTOCOLO UDP


Tabla 69. Estadística para protocolo RTP prueba llamada IAX2 a H.323


192.168.100.243 192.168.100.249 0xA3F435B GSM 06.10 502 0 (0.0%) 28.99 4.24 3.10 X

192.168.100.249 192.168.100.243 0x7CDBB9D1 GSM 06.10 488 0 (0.0%) 34.44 6.19 0.79

RTP


100

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 Packets Bytes

IP 2057 173780

192168100240 192168100249 1020 80188

192168100243 192168100249 1037 93592

TCP 34 3542

192168100249 192168100243 34 3542

UDP 2023 170238

192168100240 192168100249 1020 80188

192168100243 192168100249 1003 90050

Total general 4114 347560


101

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

llamada de extensión H.323 a protocolos

H.323 IAX2 sip a h.323 iax2 a h.323

Paquetes 1641 4306 2548 2057

tiempo entre la primera y ultimo paquete (seg) 8,762 35,96 16,320 18,331

Prom. Paquetes por segundo (bytes) 187,291 119,743 156,994 112,212

Prom. Tamaño de Paquetes 89,513 83,661 152,092 84,482

Bytes 146891 360246 387,531 173780

Prom. Bytes por segundo 16765,037 10017,865 23877,528 9479,924

Prom. Mbits por segundo 0,134 0,08 0,191 0,076

llamada a extensión H.323 de protocolos

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

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

192.168.99.44 192.168.100.249 2442 213818 1294 113296 1148 100522

llamada de H.323 A H.323

llamada de H.323 A IAX2 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

102

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

H.323 IAX2 SIP SIP H.323

Paquetes 2057 45 2889 2194 1641

tiempo entre la primera y ultimo paquete (seg) 18,331 17,432 20,758 12.805,000 8,762

Prom. Paquetes por segundo (bytes) 112,212 2,581 139,173 171,343 187,291

Prom. Tamaño de Paquetes 84,482 118,889 146,806 149,087 89,513

Bytes 173780 5350 424130 327097 146891

Prom. Bytes por segundo 9479,924 306,903 20431,73 25545,082 16765,037

Prom. Mbits por segundo 0,076 0,002 0,163 0,204 0,134

llamada de extensión IAX2 a protocolos llamada a extensión IAX2 de protocolos

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.

103

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 imprevistos, compatibilidad y disponibilidad de herramientas.

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

104

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.

105

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-283-

2820-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. “IP Telephony”. McGraw-Hill Professional Publishing, Agosto 1998

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

106

Download “The Future of Telephony” Asterisk. http://www.cyberciti.biz/tips/download-asterisk-howto-tutorial-book.html (Page On line).

Digium, Inc. About Asterisk [on-line]. Disponible en Internet:

http://www.asterisk.org

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.

http://www.cyberciti.biz/tips/download-asterisk-howto-tutorial-book.html

http://www.voipforo.com/

ANALISIS DE REQUERIMIENTOS E IMPLEMENTACIÓN · PDF fileEstadística para...

Documents

Transcript of ANALISIS DE REQUERIMIENTOS E IMPLEMENTACIÓN · PDF fileEstadística para...