IDENTIFICACION DE LAS FUNCIONALIDADES, POTENCIALIDADES Y REQUERIMIENTOS TECNICOS PARA LA IMPLEMENTACION DE ASTERISK.

ING. GUSTAVO ADOLFO HERAZO PEREZ

KONRAD LORENZ - FUNDACION UNIVERSITARIA FACULTAD DE MATEMTICAS E INGENIERAS BOGOT D.C.

Identificacin de las Funcionalidades, Potencialidades y Requerimientos Tcnicos para la Implementacin de Asterisk.

GRUPO DE INVESTIGACIN TELEMENTE Lnea de Investigacin en Telecomunicaciones-TELEMENTE

ING. GUSTAVO ADOLFO HERAZO PEREZ

KONRAD LORENZ- FUNDACION UNIVERSITARIA FACULTAD DE MATEMATICAS E INGENIERAS PROGRAMA DE INGENIERA DE SISTEMAS 2

TABLA DE CONTENIDO INDICE DE TABLAS. 4 INDICE DE FIGURAS 5 LISTA DE ANEXOS6 GLOSARIO DE TERMINOS. 7 INTRODUCCION 8 1. ASPECTOS DE LA INVESTIGACION 1.1. Descripcin del problema.. 9 1.2. Justificacin...................................................................................................9 1.3. Delimitacin 1.3.1. Espacial.10 1.3.2. Cronolgica...11 1.4 Objetivos 1.4.1. General12 1.4.2. Especficos..12 2. BASES CONCEPTUALES 2.1. Antecedentes
2.1.1. Antecedentes Histricos..13 2.2. Marco Teorico.15 2.2.1. Iniciando con Asterisk17 2.2.2. Asterisk con arquitectura de Sistemas Pequeos19 2.2.3. Asterisk con arquitectura de Sistemas Medianos.19 2.2.4. Asterisk con arquitectura de Sistemas Grandes.. 20 2.2.5. Protocolo de Sealizacion y Transporte de Voz IP en Asterisk..20 2.2.6. La sealizacin como tcnica utilizada en telefona Empresarial. 21 2.2.7. Funciones de Sealizacin...21 2.2.8. Funciones de deteccin del equipo colgado o descolgado22 2.2.9. Proceso de Supervisin de comienzo de la marcacin22 2.2.10. Proceso de Transmisin de Dgitos y marcacin por pulsos..23 2.2.11. Sistemas de Marcacin por Tonos..24 2.3. Consideraciones tcnicas sobre la telefonia

Por el Protocolo Internet (IP)

2.3.1. Elementos tcnicos asociados 24
2.4. 2.4.1. 2.4.2.

Supervision de telefonia IP sobre Asterisk

Nmeros de telfonos asociados.. 32 Tonos de progreso de llamadas. 33 2.4.3. Manejo y gestin de troncales para entornos Asterisk.. 33 2.5. Inicio de Bucle.35 2.6. Circuito Libre...36

2.7.
2.8. 2.9. 2.9.1. 2.9.2. 2.10.

Definicion y medida de la voz sobre Asterisk.36

Variables que afectan la calidad de la voz37 Control de Ruido de Fondo en Asterisk 38 Recorte de Amplitud. 38 Distorsion de Cuantificacion38 Medida Subjetiva de la calidad de la conversacin41

2.11. Protocolo de Control Rapido.. 42 2.12. Protocolo de Control Rpido como elemento diferenciador en Telefona IP.. 44 2.13. Uso de Gateways en Asterisk 45 2.14. Uso de Gatekeeper.. 46 2.15. Direccionamiento. 48 2.16. Direcciones de Red e identificadores TSAP. 49 2.17. Alias H323 50 2.18. Convenciones de alias para la comunicacin interzonal 51 2.19. Registros TXT. 51 2.20. Control de llamadas en Asterisk con H.225.0.. 52 2.21. Control de llamadas en Asterisk con Medios H.245 54 2.22. Protocolo SIP en Asterisk. 55 2.23. Atributos del protocolo SIP 56 2.24. Componentes del Sistema 57 2.25. Direccionamiento de SIP.. 58 2.26. Sintaxis de la Direccin SIP. 59 2.27. Mtodo de registro SIP. 60 2.28. Cabeceras SIP 62 2.29. MGCP (Media Gateway Controller Protocol) 66 3. RESULTADOS OBTENIDOS 3.1. Plataforma de Sistema Operativo... 67 3.2. Inicio de la descarga y ajustes previos de instalacin de Asterisk . 67 3.3. Estado del Arte de las funcionalidades frente a diversos proveedores. 70 3.4. Analisis de funcionalidades con Wireshark 3.4.1. Funcionalidades SIP con Wireshark. 71 3.4.2. Funcionalidades H323 con wireShark.. 76 3.4.3. Consolidado de funcionalidades y potencialidades.. 77 4. CONCLUSIONES Y RECOMENDACIONES 78 5. BIBLIOGRAFIA 80

INDICE DE TABLAS
Tabla 1. Cronograma de Actividades 12 Tabla.2. Frecuencias DTMF asignadas a un teclado de telfono estndar.. 23 Tabla 3. Cdigos de respuesta SIP.. 63 Tabla 4. Respuestas ms comunes del protocolo SIP 66 Tabla 5. Comparativo entre plataformas Asterisk, Avaya y Cisco. 71 Tabla 6. Directorios y archives que se requieren en Asterisk. 72 Tabla 7. Estadstica para protocolo RTP prueba llamada IAX2 a H.323.. 77 Tabla 8. Estadstica consolidada de H323, IAX, SIP e IAX 77

INDICE DE FIGURAS

Figura No. 1 Modelo inicial de la primera central telefnica anloga.. 15 Figura No. 2 Modelo hibrido de central telefnica anloga y digital 17 Figura No. 3 Modelo integral y total de telefona digital Figura 4. Esquema de interconectividad de Servidor a Servidor En la FUKL (Lab. 302). 29 Figura 5. Laboratorio dedicado al Proyecto telefona IP-Asterisk Saln 302 de la FUKL 29 Figura 6. Laboratorio dedicado al Proyecto telefona IP-Asterisk Saln 302 de la FUKL. 30 Figura 7. Esquema de interconectividad Utilizando adaptadores ATA 31 Figura 8. Esquema de interconectividad Utilizando Telefona IP A Telfono a telfono.. 32 Figura 9. Esquema cuando el recorte de amplitud cambia la forma de la seal.. 58 Figura 10. Fenmeno de Eco presentado en Asterisk. 42 Figura 11. Estructura lgica de un Gateway en H323 sobre Asterisk 47 Figura 12. Intercambio entre puntos finales a travs de H225 en Asterisk.. 55 Figura 13. Sealizacin bajo el protocolo SIP 76 18

LISTA DE ANEXOS Anexo 1. Consolidado de Requerimientos y parmetros de instalacin Anexo 2. Configuracion Servidor Asterisk Anexo 3. Documentacion Archivo Users Anexo 4. Configuracion Archivo start Anexo 5. Configuracion app_conference Anexo 6. Flags de eventos de Asterisk Anexo 7. Configuracion Archivo SIP Anxo 8. Configuracion Archivo IAX Anexo 9. Configuracion Archivo H323

GLOSARIO DE TERMINOS

ACD (Automatic Call Distributor): Distribuidor Automtico de llamadas. Esta entidad representa el sistema telefnico cuya funcin es poder manejar todas las llamadas entrantes o por el contrario las llamadas salientes. Adicionalmente interacta con la base de datos para tomar la accin pertinente cuando una llamada entrante se realiza. Tambin puede reproducir grabaciones y grabar respuestas. CODEC. Programas y/o algoritmos que sirven para compresin y descompresin de la voz. Es Utilizado en entornos multimedia como por ejemplo audio y video. E1. Representa el estndar de conexin de las lnea telefnicas y trabajan para el envo de datos hasta 1920 Mbps. Este enlace posee 30 canales de datos de 64 Kbps y 2 canales B de sealizacin. SIP (Protocolo de inicio de sesin). Este protocolo es utilizado en asterisk para sealizacin y permite toda la gestin (creacin. Modificacin y control de sesiones de las llamadas). H323. Este estndar de la ITU se caracteriza para iniciar sesiones de comunicacin en videoconferencia en entornos de telefona IP. Este protocolo no garantiza QoS y es independiente de la topologa de la red. PBX (Private Branch Exchage). conmutar todo el trfico de VoIP. Corresponde a una centralita IP, cuya funcin es

PLANTA IP. Se define como un Gateway que es el encargado de la calidad de las llamadas, reemplazando a lo que hoy en da se conoce como la plata telefnica tradicional IAX (Inter-Asterisk eXchange protocol): Herramienta de asterisk para controlar las conexiones entre elementos de VoIP, servidor a servidor y servidor-cliente. RTCP. Es un protocolo de comunicacin que proporciona informacin de control que est asociado con un flujo de datos. SDP. Protocolo de descripcin de sesin. Formato para describir parmetros de inicializacin de Streaming Streaming Media. Tecnologa que permite almacenar en un bfer lo que se escucha o ve en una comunicacin.

INTRODUCCIN

La Fundacin Universitaria Konrad Lorenz, en su proceso de formacin investigativa y con miras a fortalecer la lnea TELEMENTE, se crea el Semillero en Investigacin en TELEFONIA IP BAJO ASTERISK. Actualmente con el aumento y la necesidad de las comunicaciones basadas en IP, se hace indispensable utilizar el esquema de interconexin que nos brinda la red de redes Internet y por ello las redes de telefona estn encaminadas hacia la convergencia e integracin de voz, datos y video. Las redes de comunicacin actuales en telefona, se caracterizan por tener un funcionamiento complejo que implica la interaccin de muchos sistemas que en muchos casos no ofrecen ventajas competitivas en la nueva era de la Tecnologas de Informacin y comunicaciones. Gracias a la convergencia de los servicios de redes, la Telefona IP convierte un PC o cualquier laptop en un telfono heredando todas las ganancias y ventajas del protocolo IP y su inclusin en nuevos mercados competitivos que ofrecen ahorro financiero, disminucin de tiempo y una gran gestin en las pequeas, medianas y grandes empresas.

La Facultad ofrece este semillero con la oportunidad de que los estudiantes participen activamente en investigacin, orientada a lograr y establecer las funcionalidades, potencialidades y requerimientos tcnicos que se necesiten para implementar este tipo de necesidades en pequeas y medianas empresas.

La Investigacin se har directamente en las instalaciones de la Universidad, proyectando diversas herramientas que permitan establecer un estado del arte, para lograr las

ventajas y desventajas de las diferentes versiones tanto de los sistemas operativos utilizados y los componentes asterisk que se trabajarn.

La primera etapa del proyecto corresponder al levantamiento de informacin, polticas y elementos que se involucrarn en la instalacin de los diversos sistemas operativos y elementos de asterisk utilizados.

CAPITULO 1 ASPECTOS DE LA INVESTIGACION

1.1.

DESCRIPCION DEL PROBLEMA Actualmente los modelos recursivos en telefona IP sobre asterisk que se encuentran en el mercado, algunas veces son poco comprensibles y no logran establecer polticas claras de funcionamiento, requerimientos claros y precisos y sobre todo que enfoquen funcionalidades asociadas a los tipos de empresas, ya sean pequeas, medianas o grandes y que enfaticen los mejores componentes de acuerdo a sus areas de negocios. La fundacin Universitaria Konrad Lorenz y en especial el Programa de Ingeniera de Sistemas pretender llevar a cabo fortalecer el espritu investigativo de los estudiantes a partir de la creacin de grupos de trabajo que participen activamente como semillero de investigacin en el rea de Telefona IP con asterisk, con miras a la concientizacin de evaluar las funcionalidades, potencialidades y

requerimientos tcnicos en la toma de decisiones para la implantacin de una solucin Asterisk en un mercado empresarial pequeo o mediano, y que cuyos logros se reflejen ms adelante en consultoras y acompaamientos a este tipo de mercado para que se fortalezca la inclusin de este tipo de tecnologas como elemento competitivo en la sociedad de las comunicaciones y la era de la tecnologas de informacin y comunicaciones.

1.2.

JUSTIFICACION La nueva era de la Sociedad de la informacin pretender la convergencia total de los servicios informticos y de telecomunicaciones, por ende la tecnologa de Telefona IP, busca la interseccin y/o unin de de dos mundos histricamente separados uno el de transmisin de voz y el otro el de transmisin de datos. Dentro de los marcos incidentes y de gran impacto tecnolgico, est el resurgimiento de la Telefona IP, ya que en el pasado este servicio careca de parmetros de Qos (Quality of Service) y de niveles de seguridad que no

aportaban un elemento garantizado de confianza.

10

Sin embargo gracias a los adelantos de la Red Digital de Servicios Integrados y el surgimiento y estandarizacin de la Banda ancha, este campo ha adoptado un resurgir en los proyectos de investigacin a escala nacional y mundial. En el marco de la globalizacin y convergencia del rea de las telecomunicaciones se hace necesario y vital que las organizaciones incurran en este modelo de integracin y de fusin de tecnologas, y que con mayor razn la era de Internet 2, recomienda este tipo de tecnologas como elemento diferencial para ahorrar costos, integrar y armonizar la era de la sociedad de la informacin y la validacin y fluctuacin de la web 3.0 y 4.0 en lo concerniente al cambio del paradigma de la sociedad de base y la Web social como apoyo al campo de las investigaciones. Por ello, la Fundacin Universitaria Konrad Lorenz es participe de este campo y con miras a establecer el impacto que pueda generar estos modelos integradores de telefona en aquellos sectores empresariales de pequea y mediana empresa, para que incursionen como elementos fundamentales e integradores en la Nueva era de la Sociedad del conocimiento. Se hace evidente que en un futuro no muy lejano desaparecern por completo las lneas telefnicas convencionales que se utilizan en nuestra vida cotidiana y por ende estamos a la gran puerta del mercado competitivo y de gran demanda de la Telefona IP. Para finalizar este Proyecto permitir la comunidad universitaria estudiantil integrarse a Grupos de estudios, crear conciencia de investigacin y participar en compaa de Docentes investigadores a canalizar los conocimientos en busca de nuevas soluciones y aportes a la comunidad universitaria.

1.3.

DELIMITACION DE LA INVESTIGACION

1.3.1. Delimitacin Espacial

El Presente Proyecto de Investigacin se realiza en la Fundacin Universitaria Konrad Lorenz y se contar con la disponibilidad del Laboratorio 302 para los montajes respectivos, ubicados en el tercer piso de la Institucin. Se cuenta con dos equipos multincleo con dos Gigas en RAM, conectados directamente a la Red de la Universidad y con direcciones IP estticas y acceso a Internet.

11

1.3.2. Delimitacin Cronolgica El proyecto se llevar a cabo siguiendo el cronograma que se muestra a continuacin:

Meses 1.1.1 Actividad a desarrollar

Levantamiento de Informacin inicial. Instalacin de las diferentes distribuciones de Linux en la sala de laboratorio del tercer piso de la FUKL y gestin de los elementos necesarios para esta primera actividad. Revisin de la Bibliogrfia disponible Exploracin inicial de las compatibilidades y modelos ptimos de las distribuciones Linux con las diferentes versiones de Asterisk. Identificacin de los requerimientos tcnicos para la realizacin de un plan de pruebas completo y bsico sobre Asterisk Realizacin del plan de pruebas bsicas. Documentacin del proyecto Tabla 1. Cronograma de Actividades
Enero-Febrero Marzo Abril Mayo-Junio

1.4.

OBJETIVOS DEL PROYECTO

1.4.1. Objetivo General

Identificar las funcionalidades, potencialidades y requerimientos tcnicos para la implementacin de la herramienta del Software de ASTERISK bajo sistema operativo Linux

1.4.2. Objetivos Especficos Realizar un levantamiento de informacin acerca de las distribuciones Linux que sean ms consistentes en la correlacin con el esquema de trabajo de asterisk.

12

 Determinar el nivel ptimo de gestin, de operatividad, de integridad y de coexistencia entre los componentes bsicos asterisk y la distribucin Linux que se adopte. Realizar un estado del arte que determine las funcionalidades,

potencialidades y requerimientos tcnicos de las diferentes versiones de asterisk en modelos de pequeas y medianas empresas. Elaboracin de anexos donde se plasme cada uno de los archivos de instalacin, requerimientos tcnicos y las diferentes pruebas bsicas de asterisk tomando como entorno un diseo microempresarial. Elaboracin de un artculo sobre el tema de investigacin.

13

CAPITULO 2 MARCO TEORICO Y ESTADO DEL ARTE

2.1.

ANTECEDENTES 2.1.1. Antecedentes Histricos El mundo de la telefona desde sus orgenes ha pasado por innumerables etapas o generaciones que visualizan la evolucin y progreso de las investigaciones en esta rea del conocimiento. Por consiguiente se da a conocer en resumen un poco de esos cambios vertiginosos hasta llegar a la era actual. 1era. Generacin: Corresponde al inicio de los primeros descubrimientos en telefona y para ello se utilizo el uso de telgrafos.

Los telgrafos inicialmente fueron creados como dispositivos o aparatos ubicados preferiblemente en unidades de mando o en buques de guerra para que pudieran transmitir ciertas seales a distancia. Tambin se le conoce como semforo y aunque hoy en da se conocen innumerables tipos de telgrafos en todos los pases del mundo, la forma de operacin y control es idntica en todos. Su diseo bsico consiste en colocar el telgrafo en un sitio totalmente visible del prximo telgrafo a transmitir para que los mensajes enviados no tengan ningn problema de comunicacin y as sucesivamente una detrs de otro, logrando abarcar grandes distancias.

2da. Generacin: Es conocida como la era de telefona analgica de switches manuales, desarrollada por el Seor Alexander Graham Bell en donde se hace posible y efectiva la patente del primer telfono y la primera central telefnica del mundo, esto ocurre en los aos de 1876 y 77. (Ver figura 1)

14

Figura No. 1 Modelo inicial de la primera central telefnica anloga

Luego vino la telefona analgica de switch mecnico1, en donde los procesos de conmutacin se realizaban de forma mecnica y posteriormente entro la era de la telefona anloga pero los procesos de conmutacin ya eran automticos. Terminando esta fase se crea una ruptura total en la era anloga y entra la Red pblica de telefona conmutada digital, seguida por la telefona Mvil celular y la ultima que se denomina Telefona Sobre Protocolo IP. Determinando antecedentes histricos se sabe que en Colombia especialmente en la Universidad de San Buenaventura en la Bogot en el ao 1999 se empezaron los primeros avances en telefona IP2.

Dispositivo de red que filtra, enva e inunda de frames en base a la direccin de destino de cada frame. El switch opera en la capa de enlace de datos del modelo OSI. 2.) Trmino general que se aplica a un dispositivo electrnico o mecnico que permite establecer una conexin cuando resulte necesario y terminarla cuando ya no hay sesin alguna que soporta
2

La Telefona IP es una solucin tecnolgica que sirve para transmitir comunicaciones de voz sobre una red de datos basada en el estndar IP. Con la solucin de Telefona IP, la organizacin reduce costos integrando sus aplicaciones de voz y datos sobre una nica plataforma de Red. Esta solucin permite elevar la productividad, reducir costos operativos de la empresa mediante la convergencia de las comunicaciones; adems de escalar las soluciones de acuerdo a las necesidades de las empresas, las cuales pueden ser corporativas, medianas o pequeas.

15

2.2.

MARCO TEORICO

Una increble revolucin est en marcha. Ha sido un largo tiempo en llegar, pero ahora que ha comenzado, no se detiene. La industria de telecomunicaciones est siendo alimentada por una fuente privada (PBX) llamado Asterisk. El mundo de las Telecomunicaciones esta enfocndose por la revolucin de cdigo abierto.

Anteriormente los sistemas propietarios construan sistemas de telefona supremamente costosos e incompatibles, con rutinas muy complicadas, con cdigos obsoletos y

asociados con hardware obsoleto. Como ejemplo, Nortel Business Communications Manager kludges basado en VxWorks, sistema que trabaja en un conmutador telefnico, bajo un PC de 700-MHz. Esta arquitectura se podra obtener en un rango entre 5 y 15 mil dlares, no incluyendo los telfonos. [5]

El futuro de la tecnologa telefnica va a desprenderse del imperio de las normas y la era de la libertad, para ello asterisk converge hacia este tipo de soluciones.

Nunca en la historia de las telecomunicaciones haba existido un sistema adecuado a las necesidades telefnicas y que resolviera de manera eficaz las necesidades de negocios de las medianas y pequeas empresas a unos costos mnimos. Linux como sistema operativo base da la alternativas de acoplamiento y cohesin perfectas para el maravillo mundo de asterisk3.

No podramos estar hablando de la libertad de construir nuestra propia red telefnica sin la existencia de los estndares abiertos y el cdigo libre. Los estndares abiertos permiten que cualquiera pueda implementar un sistema con garantas de interoperabilidad.

Gracias a esa interoperabilidad de nuestro diseo no slo podemos crear nuestra red telefnica sino que, adems, podemos conectarla a la red telefnica global. Con el cdigo libre podemos aprender de experiencias parecidas, integrar sus soluciones y compartir nuestros propios resultados con los dems.

Asterisk es un proyecto de cdigo libre http://www.asteriskdocs.org/modules/tinycontent/index.php?id=10

16

Una de las primeras preguntas que merece una respuesta es: por qu deberas crear tu propia infraestructura de voz sobre IP y no seguir usando servicios gratuitos como Skype? La respuesta es simple: sostenibilidad y flexibilidad. Los servicios gratuitos te pueden Solucionar una necesidad a corto plazo pero nunca garantizar tu independencia o el control de tu propio proceso de aprendizaje y desarrollo. No se trata de una cuestin puramente tcnica. El problema no es decidir cul es la mejor de las tecnologas sino cul es la que permite que las comunidades sean dueas de su propio desarrollo y que puedan adaptarla a sus propias necesidades [1].

Dentro de los marcos de diseo, asterisk provee mltiples variedades de diseo en los cuales se generalizan como se muestran a continuacin:

Modelo 1: Este modelo permite convivir las arquitecturas de telefona tradicional y la telefona IP.

Figura No. 2 Modelo hibrido de central telefnica anloga y digital

Modelo 2. Adaptacin total e integral de telefona IP.

17

Figura No. 3 Modelo integral y total de telefona digital

2.2.1 Iniciando con Asterisk

En trminos de las necesidades de recursos, las necesidades de Asterisk son similares a las de un embebido en tiempo real aplicacin. Esto se debe en gran parte a su necesidad de tener prioridad el acceso al procesador y al sistema de buses de control del sistema operativo. Por lo tanto, es imperativo que todas las funciones en el sistema no estn directamente relacionados con las tareas de procesamiento de Asterisk a baja prioridad. En sistemas ms pequeos, esto podra no ser tanto un problema. Sin embargo, en sistemas de alta capacidad, el rendimiento deficiencias se manifiestan como problemas de calidad de audio para los usuarios, dando como respuesta a menudo problemas de eco y esttica, Los sntomas se asemejan a los experimentados en un telfono celular cuando se sale del radio de alcance de la seal. Por tanto a medida que la carga aumenta, el sistema tendr dificultades para mantener el aumento de las conexiones. Para un PBX4, esta situacin es poco menos que desastrosa y se hace necesario prestar atencin cuidadosa a los requisitos inciales de la plataforma durante el proceso de seleccin.

La siguiente tabla enumera algunas directrices bsicas que se deberan tener en cuenta cuando se defina la planificacin del sistema.
4

PBX: (Central Telefnica Digital). Sistema telefnico dentro de una organizacin que maneja las llamadas entre sus usuarios en lneas locales mientras permite que entre todos los usuarios compartan un nmero determinado de lneas telefnicas externas.

18

Propsito Empresarial
Sistema de pruebas (Tipo1) Sistema SOHO (Small OfficeHome Office)-Pequea oficina en casa Pequea Empresa Mediana Empresa
5

Nmero de Canales
No ms de 5 conexiones
5 a 10 conexiones

Mnimo Recomendado
400-MHz x86, 256 MB RAM
1-GHz x86, 512 MB RAM

Hasta 15 conexiones Ms de 15 extensiones

3-GHz x86, 1 GB RAM

Dual

Core,

Posibilidad

de

mltiples servidores en una arquitectura distribuida-

Por otro lado a la hora de seleccionar el hardware de una instalacin Asterisk se debe tener en cuenta cmo el sistema podra crecer? Esta no es una pregunta fcil de responder, porque la manera en que el sistema es utilizado desempear un papel muy importante en los recursos que se consumen y la relacin a futuro en lo concerniente al trafico esperado en funcin de sus extensiones es un paso difcil de lograr. Por tanto se tendr que comprender cmo Asterisk utiliza el sistema con el fin de hacer decisiones inteligentes acerca de qu tipo de recursos a futuros se necesitarn. Existen varios factores que se tendrn que considerar incluyendo:

El nmero mximo de conexiones simultneas que el sistema trabajar, producir cada conexin se incrementar la carga de trabajo a nivel de procesador.

El porcentaje de trfico que requiere de un uso intensivo del procesador de seales digitales de procesamiento (DSP) de los cdecs de compresin (tales como G.7296 y GSM) se har evidente en el aumento del trfico.

El trabajo del DSP [9], [12] de Asterisk puede tener un impacto sorprendente sobre el nmero de llamadas simultneas, que genera. Un sistema que puede manejar alrededor de 50 llamadas simultneas G.71177, pueden ser crticos en el caso de una

SOHO: Acrnimo de Small Office-Home Office (Pequea Oficina-Oficina en Casa). Ues un trmino que se aplica para denominar a los aparatos destinados a un uso profesional o semiprofesional pero que, a diferencia de otros modelos, no estn pensados para asumir un gran volumen de trabajo. http://www.mastermagazine.info/termino/6753.php 6 G.729 es un algoritmo de compresin de datos de audio para voz que comprime audio de voz en trozos de 10 milisegundos. La msica o los tonos tales como los tonos de DTMF o de fax no pueden ser transportados confiablemente con este cdec, y utilizar as G.711 o mtodos de sealizacin fuera de banda para transportar esas seales. http://es.wikipedia.org/wiki/G.729 7 G.711 es un estndar para representar seales de audio con frecuencias de la voz humana, mediante muestras comprimidas de una seal de audio digital con una tasa de muestreo de 8000 muestras por segundo. El codificador G.711 proporcionar un flujo de datos de 64 kbit/s. http://es.wikipedia.org/wiki/G.711

19

solicitud Las

de

conferencia

junto

a del

10

canales una

G.729

comprimido. y

conferencias

requieren

sistema

codificacin

una combinacin de entrada de audio en mltiples flujos salientes. Mezcla mltiples flujos de audio en tiempo casi real y puede colocar una enorme carga sobre la CPU y producir la cancelacin de eco.

2.2.2. Asterisk con arquitectura de Sistemas pequeos

Se entienden como sistemas pequeos aquellas arquitecturas empresariales que tienen hasta 10 telfonos, stas no son inmunes a los requisitos de Asterisk, pero la carga estar dada dentro de las capacidades de un procesador moderno. Si usted est construyendo un pequeo sistema de componentes en asterisk, su gestin a nivel de sistema operativo en Linux no requiere de altos controles de rendimiento para ajustar su carga a nivel de trfico. Si se est configurando un sistema Asterisk para fines de aprendizaje y

academia, se podr para construir una plataforma completamente sencilla, utilizando baja potencia de CPU. Los procesadores ms utilizados en el mercado estn los de 433 MHz a 700 MHz, los procesadores Celeron en donde la carga de trabajo de estos sistemas suele ser mnima. [13]

2.2.3 Asterisk con arquitectura de Sistemas Medianos

Los sistemas de tamao mediano convergen de 10 a 50 telfonos.

Las polticas y

consideraciones de adecuar el rendimiento ser ms difcil de resolver. Generalmente, estos sistemas se desplegado en uno o dos servidores y, por tanto, cada mquina ser necesaria para manejar ms de una tarea especfica. Como aumentar las cargas y definir los lmites de la plataforma. [10], [11] Los usuarios podrn comenzar a percibir los problemas de calidad sin darse cuenta de que el sistema no est defectuoso. Estos problemas sern tendrn progresivamente a medida que crece la convergencia de la red y su carga sobre el sistema ir aumentando y produciendo degradacin del

servidor. Es fundamental que el problema del rendimiento se identifique y se atienden las necesidades a tiempo, antes de que sean percibidas por los usuarios.

20

2.2.4 Asterisk con arquitectura de Sistemas Grandes

Los sistemas grandes corresponden a ms de 50 usuarios, se puede distribuir a travs de mltiples procesadores y, por tanto, el rendimiento causa preocupaciones de alto nivel y se pueden gestionar a travs de la adicin de mquinas y/o servidores. Una arquitectura asterisk se considera de mbito grande cuando definimos de 500 a ms de 1000 usuarios. La construccin de un gran sistema requiere un nivel avanzado de conocimientos en diferentes disciplinas.

2.2.5 Protocolo de serializacin y Transporte de Voz IP en Asterisk

Los protocolos asociados a VolP se dividen en dos grupos: los que soportan el transporte de la ruta de audio, y aquellos que soportan la sealizacin de llamada y las funciones de control. Los protocolos que administran el transporte de la ruta de audio ofrecen informacin de temporizacin para asegurar una reproduccin de audio consistente en el lado receptor, as como una retroalimentacin del rendimiento de la calidad del servicio (QoS) con respecto a la red subyacente. La sealizacin de llamada y las funciones de control proporcionan la configuracin y la cancelacin de la llamada, direccionamiento y enrutamiento, servicios de informacin adicionales y mtodos para trabajar con otros tipos de sealizacin. En este esquema se encuentra el Protocolo de transporte rpido (RTF) [3],[4] y el Protocolo de control RTF (RTCP, RTF Control Protocol), como protocolos de ruta de audio VolP universalmente aceptados. Con el fin de proporcionar una revisin del H.323, del Protocolo de inicio de sesin (SIP, Session Initiation Protocol) [7], [8] y de los protocolos de sealizacin H.248/Megaco/Media Gateway Control Protocol (MGCP), tambin se analizar estos protocolos que se complementan entre ellos. [1], [2]

2.2.6 La sealizacin como tcnica utilizada en telefona Empresarial En un entorno empresarial tpico, el CPE es un PBX (Intercambio privado de ramas) que conecta a los usuarios con la Red pblica de telefona conmutada (PSTN) a travs de la CO. El CPE tambin puede ser un sencillo telfono, como el existente en el hogar, o un equipo un poco ms complejo, como el existente en una pequea oficina.

21

En algunos casos, la CO no est implicada en la sealizacin telefnica, excepto para proporcionar la infraestructura de transmisin (por ejemplo, T-l/E-1) entre los emplazamientos de los clientes. En estos casos, los switches telefnicos situados en cada uno de los emplazamientos del cliente se relacionan con los dems a travs de los switches situados en la CO. La sealizacin troncal utilizada en estas lneas punto a punto o troncales tambin caer dentro de este mbito [3].

2.2.7. Funciones de Sealizacin Aparte de la transmisin de una ruta de audio en ambas direcciones, existe un conjunto de importantes funciones de sealizacin que deben ser proporcionadas por una lnea o un troncal de telefona. Una troncal se refiere a una conexin entre switches telefnicos (por ejemplo, las PBX, los sistemas de clave o las CO) y una lnea se refiere a una conexin entre un telfono y un switch telefnico. Los siguientes representan los tipos de sealizacin: Deteccin de equipo colgado-descolgado (on-hook/off-hook). Supervisin de comienzo de marcacin. Transmisin de dgitos. Identificacin de nmero. Tonos de progresin de la llamada. Supervisin de respuesta y desconexin.

Adems de las funciones de sealizacin fundamentales descritas aqu, son necesarios otros tipos de sealizacin para posibilitar las opciones de llamada avanzadas.

2.2.8. Funciones de deteccin del equipo colgado o descolgado

Como su nombre implica la sealizacin on-hook/off-hook (colgado-descolgado) requiere solo dos estados: on-hook/off-hook. El telfono est colgado cuando la parte del microtelfono (micrfono y altavoz) est descansando sobre la base del telfono. El telfono esta descolgado cuando el micro-telfono se alza de la base del telfono para realizar o recibir una llamada. Los puntos finales troncales del telfono deben permitir la transmisin

22

y recepcin de seales que indican los estados on-hook/off-hook. El mtodo de sealizacin de estos dos estados difiere entre los tipos de enlaces troncales.

La serializaran on-hook/off-hook es obligatoria para todos los tipos de troncales excepto para las conexiones troncales permanentes [4], [5]. (Por ejemplo, conexiones always-on o hoot-n-holler). Los enlaces troncales normalmente se implementan configurando la interfaz troncal a un estado off-hook.

2.2.9. Proceso de Supervisin de comienzo de la marcacin La supervisin de comienzo de marcacin asegura que el switch telefnico receptor est preparado para interpretar los dgitos (es decir, el numero del telfono de destino) transmitidos por el switch telefnico emisor. Sin supervisin de comienzo de marcacin, el switch telefnico receptor puede perder los primeros dgitos de una direccin destino entonces se producir un intento de llamada fallido. Por esta razn, debera utilizar un tipo de sealizacin de enlace troncal que incluya supervisin de comienzo de marcacin siempre que sea posible. Para enlaces troncales analgicos, E&M wink start es la mejor opcin y adems ampliamente disponible. Algunos enlaces troncales digitales que utilizan sealizacin de canal comn (CCS) proporcionan la funcionalidad de supervisin de comienzo de marcacin. [13] Aunque la supervisin de comienzo de marcacin proporciona confirmacin positiva de que el switch remoto este preparado para recibir dgitos, no proporciona confirmacin de que los dgitos se hayan recibido correctamente. La confirmacin de recibo para dgitos individuales no es un elemento de los protocolos de sealizacin utilizados aca en Colombia; sin embargo, la sealizacin R2 MFC, [5], [9] que se usa en muchos pases, proporciona esta fiabilidad aadida.

2.2.10. Proceso de Transmisin de Dgitos y marcacin por pulsos Los telfonos y los switches telefnicos transmiten dgitos para representar las direcciones de destino y proporcionar entradas desde los usuarios a los sistemas automatizados como buzn de voz, auto-asistidos, distribuidores automticos de llamada (ACD) y sistemas de respuesta interactiva de voz (IVR). Los sistemas de telefona normalmente utilizan dos clases de transmisin de dgitos: Marcacin por pulsos y marcacin por tonos.

23

Los telfonos y circuitos originales no tienen un mtodo para transmitir dgitos. Los operadores humanos de una oficina central responderan el telfono tan pronto como descolgaran (off-hook) y utilizaran parches de cables para conectar fsicamente su circuito telefnico al circuito telefnico de la parte destino. El esquema de pulsos original se implemento con telfonos de marcacin giratoria, que estaban diseados para trabajar con lneas loop-start existentes y para permitir a la parte emisora conectar automticamente con la parte destino sin intervencin de una operadora. Cada nmero en el esquema de marcacin por pulsos se seala como una serie de pulsos make/break, donde make es el estado off-hook (alrededor del 60 % del tiempo de pulso) y break es el estado on-hook (alrededor del 40% del tiempo de pulso).

2.2.11. Sistemas de Marcacin por Tonos Hay varios estndares para transmitir dgitos mediante tonos audibles: Marcacin multifrecuencia (DTMF). Marcacin multifrecuencia por pulsos (MF-P). Multifrecuencia obligada (MF-C). Las normas de transmisin de dgitos multifrecuencia (MF) [12], [3], [4] son generalmente un subconjunto de protocolos de serializaran mas amplios basados en los tonos MF audibles. Estos protocolos de serializaran ms amplios describen la transmisin de dgitos y seales de supervisin, seales de lnea y otros tipos de control de llamada y de informacin. La marcacin multifrecuencia (DTMF) es el mtodo mas utilizado para la transmisin de dgitos, tanto para la transmisin del numero de destino como para el intercambio de informacin dentro de banda entre los que llaman y los sistemas automatizados de telefona (buzn de voz, IVR, ACD, etc.). [3],[5] La planificacin entre dgitos y frecuencias audibles se basa en el diseo fsico de un teclado numrico de telfono estndar. Se asigna una frecuencia distinta a cada fila y columna del teclado numrico, de manera que cada tecla se corresponda con dos frecuencias, como se muestra en la siguiente Tabla 2.

24

1209 Hz 697 Hz 770 Hz 852 Hz 941 Hz 1 4 7 *

1336 Hz 1477 Hz 1633 Hz 2 5 8 0 3 6 9 # A B C D

Tabla.2. Frecuencias DTMF asignadas a un teclado de telfono estndar

La tecla * se utiliza normalmente para sealar solicitudes de funciones procedentes del usuario a la red pblica. Muchos fabricantes de PBX tambin siguen este convenio para las redes privadas. La tecla # se utiliza normalmente como un digito de terminacin en redes pblicas, de modo que la conexin de llamada puede empezar sin esperar a que termine la interrupcin de dgitos.

5.1.

CONSIDERACIONES TECNICAS SOBRE LA TELEFONA POR EL PROTOCOLO INTERNET (IP)

5.1.1. Elementos tcnicos asociados.

Debido a que la telefona IP actualmente no presenta, ni constituye an un porcentaje sustancial y elevado en el volumen de trfico telefnico en todo el mundo, est expandindose rpidamente debido a las siguientes motivaciones tcnicas: La red con conmutacin de circuitos se dise y optimiz con el objetivo de ofrecer un solo producto, establecer canales vocales dplex entre puntos con conmutacin de 4 kHz (canales digitales de 64 kbit/s). Por lo general, los datos se caracterizan por rfagas de informacin y no por flujos de velocidad binaria constante que se asocian comnmente con la voz. Las rfagas de datos pueden ser transportadas de una manera ms eficaz utilizando paquetes de informacin que pueden intercalarse en funcin del tiempo en una red con otros paquetes que estn siendo transportados entre otras fuentes y destinos.

25

 Durante ms de 40 aos, la voz ha sido codificada digitalmente en trenes de 64 kbit/s que pueden transportarse por canales de 64 kbit/s. No obstante, los avances de la tecnologa de codificacin vocal permiten una amplia gama de opciones, por ejemplo, desde audio a 5-8 kbit/s a audio de calidad superior a 64 kbit/s. La multiplexacin vocal a velocidades distintas de 64 kbit/s resulta difcil en la red con conmutacin de circuitos a 64 kbit/s. Sin embargo, los abonados a la telefona IP necesitan interconectar con ms de mil millones de abonados a la telefona convencional en todo el mundo y cuando se emplea un mecanismo de transcodificacin es necesario transformar su velocidad binaria ms baja a la codificacin tradicional de 64 kbit/s (bastante similar a lo que sucede cuando se conecta la codificacin de baja velocidad de las redes mviles a las redes RTPC fijas). [1], [5], [10] El Grupo de la ITU (Unin Internacional de las telecomunicaciones) y otros organismos han diversificado investigaciones y trabajos destacados con el propsito de ofrecer capacidades en tiempo real o casi real utilizando el protocolo IP, que permite transportar la voz por este protocolo empleando la gama de codificacin vocal. Los diferentes operadores en Colombia, han estado evaluando e introduciendo productos que integran estos protocolos y que determinen el cumplimiento que caracteriza la calidad de servicio necesaria para satisfacer a los clientes potenciales. La ITU-T est trabajando actualmente en la creacin de protocolos que garanticen el cumplimiento de las condiciones de QoS de manera compatible cuando es necesario atravesar un conjunto de redes y en especial en la nueva era de internet2 o tambin conocida como la era next generation8.

Internet2: Es una red de cmputo sustentada en tecnologas de vanguardia que permiten una alta velocidad en la transmisin de contenidos y que funciona independientemente de la Internet comercial actual.

26

Actualmente las redes basadas en IP pueden aprovechar las mismas facilidades de transporte de capas ms bajas subyacentes, por consiguiente la evolucin a las redes basadas en IP puede lograrse de una forma econmica mediante la instalacin de conmutadores o routers de paquetes que pueden conectarse mediante las facilidades de transporte existentes lograr la convergencia. Esto ha representado un vehculo muy importante para poder ofrecer el acceso masivo a Internet para fines comerciales en los pases desarrollados gracias a la disponibilidad y ubicuidad de esas facilidades de transporte.

De acuerdo a las diversas funcionalidades que surgieron en el desarrollo del proyecto de Investigacin, se determinaron tres casos que involucran la utilizacin de la voz por IP teniendo en cuenta el equipo terminal y los diversos tipos de redes.

El primer caso corresponde al esquema de Equipo PC a equipo PC, y se define en que ambas partes, el que est ejecutando la llamada y la llamada, disponen de varios PC, que tienen a accesos y permisos para conectarse a la red Internet, a travs de un proveedor de servicio de Internet.

Los procesos de sealizacin en Asterisk se dan cuando las dos partes estn de acuerdo en establecer una comunicacin vocal slo mediante acuerdo previo, ya que ambos usuarios tienen que estar conectados a Internet al mismo tiempo (para lo cual habrn fijado con anterioridad la hora en la que se comunicarn a travs de Internet, a menos que se encuentren en lnea permanentemente) y utilicen software especializado que sea compatible con VoIP.

Por otro lado, la persona que llama debe conocer la respectiva direccin IP de la parte llamada; para ello, se hace obligatorio que ambas partes deben ponerse de acuerdo y sincronizarse para consultar un servidor de directorio en lnea (que se actualiza con cada conexin) en el cual se registran los usuarios antes de cada comunicacin o deben disponer de otras formas para localizarse o tener conocimiento de la disponibilidad de la conexin de su contacto a Internet.

Inicialmente

se accede a la red del proveedor a travs de la red telefnica pblica

mediante una simple llamada telefnica. Este medio de acceso an predomina, incluso en los pases desarrollados. Las soluciones alternativas conocidas como RDSI de banda estrecha y basadas en la red telefnica basada en xDSL, una red de televisin por cable o una red de acceso inalmbrico (tecnologa LDMS) se encuentran hoy en da en la fase inicial de despliegue, y su uso no se ha generalizado, a pesar de que algunos pases ya disponen de los equipos adecuados.

En este caso, el proveedor de servicios de internet solo se limita a proporcionar acceso a la red, lo que a su vez permite que el usuario acceda a Internet. La aplicacin vocal que emplea el cliente es transparente para el ISP, que no toma medidas especficas para garantizar la calidad del servicio vocal. En pocas palabras, en tal escenario no puede hablarse de telefona en el sentido convencional de la palabra, es decir la prestacin de un servicio por un tercer proveedor, sino simplemente de la utilizacin de una aplicacin vocal a travs de Internet, utilizacin que se ha vuelto tan comn como cualquier otra aplicacin de red. A menudo, el protocolo utilizado entre las dos partes en comunicacin es el protocolo H.323 [5], [9], [10], [11] (por ejemplo, la aplicacin de NetMeeting); no obstante, el protocolo SIP podra tener una utilizacin ms generalizada en el futuro. Este modelo que se plasma esta referenciado en el siguiente grafico. Mostrando las ventajas de software de telefona.9

Todos los productos de software orientados a telefona que estn disponibles en el mercado tienen una estructura similar, ya que muestran un panel de control a partir del cual pueden controlarse las principales funciones de telefona y pueden consultarse los mens de configuracin y de opciones. Todos esos softwares proporcionan acceso a las zonas de charla interactiva Internet (IRC), donde los usuarios pueden intercambiar mensajes de texto en tiempo real, para cuyo fin se visualiza una lista de los individuos que utilizan el mismo software y se encuentran en lnea. Segn el producto, tambin hay un men que permite al usuario llamar a una direccin IP especfica que es permanente y corresponde a una mquina que ya est conectada a la red.

Figura 4. Esquema de interconectividad de Servidor a Servidor en la FUKL (Lab. 302)

Figura 5. Laboratorio dedicado al Proyecto telefona IP-Asterisk Saln 302 de la FUKL,

Figura 6. Laboratorio dedicado al Proyecto telefona IP-Asterisk Saln 302 de la FUKL,

Existe otro modelo que involucra telfono a telfono por conexin IP, en donde ambas partes estas abonadas a la red telefnica pblica, que puede ser fija o mvil y utilizan su aparato telefnico para comunicacin vocal en la forma normal. Hay dos mtodos para comunicarse mediante dos aparatos telefnicos ordinarios a travs de una red IP o Internet.

El primer mtodo utiliza pasarelas, Esto significa que uno o varios actores de telecomunicaciones han establecido pasarelas que posibilitan la transmisin de voz a travs de una red IP de un modo que es transparente para los usuarios telefnicos. En este caso no se trata de la red Internet sino de una red IP gestionada, es decir, una red dimensionada de tal manera que permite el transporte de la voz con una calidad de servicio aceptable.

Otro esquema que puede ser utilizado es el uso de dispositivos o adaptadores. Muchas empresas en Colombia ofrecen adaptadores muy parecidos a un mdem llamados

dispositivos ATA, que se instalan entre el aparato telefnico del usuario y su conexin a la RTPC.

Para que este tipo de configuracin funcione adecuadamente, cada uno de los dos usuarios debe disponer de una conexin con un proveedor de servicios de internet, cuyos parmetros de acceso hayan sido programados en el dispositivo.

El procedimiento se inicia cuando la parte llamante inicia la llamada de la misma manera que en una red de telecomunicaciones convencional, y la primera fase es en realidad el establecimiento de la comunicacin en esa red; sin embargo, inmediatamente despus del establecimiento, los dispositivos intercambian la informacin necesaria para la segunda fase. Luego de esto se disocia la llamada convencional y los dispositivos, en funcin de los datos que se han intercambiado y los parmetros preestablecidos, se establece una conexin entre cada uno de los corresponsales y su respectivo ISP.

Una vez es establecida la llamada, los dispositivos ATA, convierten localmente las seales vocales a paquetes IP para transportarlos por la red Internet como se ilustra en la Figura 4. En principio, este caso es muy similar al caso 1, salvo que los dos usuarios no requieren un PC y la necesidad de una cita Internet se facilita mediante el procedimiento iniciado en forma de una llamada telefnica. Sin embargo, este tipo configuracin ha tenido xito slo marginalmente ya que requiere, como en el caso de PC a PC, que los dos corresponsales dispongan del mismo tipo de dispositivo.

Figura 7. Esquema de interconectividad Utilizando adaptadores ATA

Se puede tener otra modalidad y es cuando la parte que llama es el usuario telefnico y la parte llamada es el usuario con un PC.

Un usuario telefnico puede marcar esencialmente un nmero para establecer comunicacin con la parte llamada, el usuario con un PC puede disponer marcando:

Indirectamente: Se presenta teniendo interconexin a la red como abonado de una centralita privada automtica (PABX) con tecnologa IP conectada a la red pblica (en realidad, en este caso cabra hablar ms apropiadamente de un telfono IP en lugar de un PC conectado a la red LAN gestionada por la PABX IP).

Directamente: en este caso, se trata del abonado del lado IP que tiene una direccin atribuida por un operador de telefona IP. Tcnicamente, hoy en da slo funciona el primero de los casos anteriores a travs de dispositivos PABX IP. El segundo caso funcionar dependiendo de la disponibilidad de un mecanismo de traduccin intermediario implantado por el lado IP que pueda traducir el nmero seleccionado pblico a la direccin IP de la parte llamada.

Este modelo se muestra en el siguiente grafico:

Figura 8. Esquema de interconectividad Utilizando Telefona IP a Telfono a telfono

5.2.

SUPERVISION DE TELEFONIA IP SOBRE ASTERISK

5.2.1. Nmeros de telfonos asociados. En una configuracin particular, la aplicacin asterisk puede ser telfonos separados, con un ring distinto que identifique la parte a la que se llama. En una configuracin comercial, las aplicaciones incluyen marcacin directa (DID). Hay dos clases de identificacin de la parte que llama: Marcacin directa (DID). Servicio de identificacin de numero marcado (DNIS).

La clase DID se utiliza generalmente para dirigir las llamadas a un abonado especfico en una empresa que comparte lneas telefnicas. [3], [4] La marcacin directa se puede proporcionar en enlaces troncales analgicos o digitales, utilizando cualquier mecanismo de transmisin de dgitos:

Marcacin por pulsos (DP). Marcacin multifrecuencia (DTMF). Rl multifrecuencia (MF). R2 multifrecuencia obligada (MF-C).

La clase DNIS se utiliza generalmente para dirigir llamadas a travs de un sistema distribuidor automtico de llamadas (ACD) a un grupo de agentes apropiado, o para proporcionar informacin mejorada screen-pop en entornos de centrales de llamada.

DNIS se suministra en un mensaje RDSI Q.931 SETUP (basado en el contenido de un mensaje ISUP IAM en la red SS7). DNIS tambin se puede proporcionar mediante tonos MF.

5.2.2. Tonos de progreso de llamadas.

Las redes de voz sealan una variedad de condiciones para los usuarios a travs de tonos audibles de progreso de llamada. Los tonos de progreso de llamada son familiares a los usuarios dentro de un pas; sin embargo, varan entre pases. Al integrar redes en una escala global, es importante que el equipo en cada pas proporcione los tonos de progreso de llamada acostumbrados en el pas. Esto asegura que los usuarios dentro de cada pas tengan una experiencia familiar y consistente al usar el sistema telefnico.

La supervisin de respuesta en el extremo lejano y la supervisin de desconexin son elementos que proporcionan confirmacin positiva del inicio y del fin de sesiones de llamada. Estos elementos son importantes para los proveedores de servicios con propsitos de facturacin y contabilidad. Las compaas telefnicas no son los nicas proveedores de servicios; otros ejemplos de proveedores de servicios que se benefician de la supervisin de respuesta y de desconexin incluyen compaas que aplican programas departamentales charge-back para los gastos de telecomunicacin, y hoteles que cobran a los huspedes las llamadas telefnicas.

Sin la supervisin de respuesta, los proveedores de servicios no tienen un punto fijo para empezar a facturar una conexin. En tales casos, el proveedor de servicios puede comenzar a facturar veinte o treinta segundos despus de que se marque el nmero, con la suposicin de queja del destino cuando habr contestado en este tiempo. En otros casos, el proveedor de servicios puede empezar a facturar inmediatamente despus de que se haya marcado el nmero. El problema de estos planteamientos es que las llamadas incompletas tambin se facturan, muy a pesar de los abonados.

5.2.3. Manejo y gestin de troncales para entornos Asterisk

Los enlaces troncales de voz analgicos se utilizan cuando el switch telefnico no soporta conexiones digitales, o cuando se necesitan pocos canales de voz. Por ejemplo, las oficinas pequeas con sistemas de teclas utilizan tradicionalmente enlaces troncales analgicos para lneas tie y conexiones PSTN. Las oficinas grandes con PBX utilizan lneas tie analgicas para conectar con las oficinas remotas pequeas. Los enlaces troncales analgicos tambin son comunes para lneas tie Internacionales porque el costo de las funcionalidades T1/E1 es elevado.

Hay tres tipos comunes de enlace troncal analgico: Inicio de bucle (loop-start). Inicio de tierra (ground start). E&M.

Las descripciones de las siguientes secciones consideran el switch telefnico de la CO y el CPE como los puntos extremos del enlace troncal; sin embargo, son posibles otras combinaciones. Por ejemplo, un puerto de estacin analgica PBX puede actuar como la CO para los siguientes dispositivos conectados: Un telfono de Servicio telefnico analgico convencional (POTS); por ejemplo, un telfono particular. Fax. Modem. Oficina o puerto de enlace troncal en un PBX o en un sistema de teclas. Puerto FXO en un router Cisco.

Alternativamente, un puerto FXS en un router puede actuar como la CO para el mismo grupo de dispositivos. En general, las etiquetas denominadas como oficina y estacin son ms apropiadas que CO y CPE. Por lo tanto los puertos FXS en los routers proporcionan batera y tono de marcacin a las estaciones, y los puertos FXO en routers esperan batera y tono de marcacin desde la oficina.

5.3.

Inicio de Bucle

Los sistemas de telefona residencial de todo el mundo utilizan sealizacin loop-start. Debido a que los enlaces troncales conectan entre los switches telefnicos y las lneas conectan un switch telefnico a un telfono, las facilidades particulares se denominan lneas loop-start. Un circuito entre una CO y un PBX se puede llamar enlace troncal desde la perspectiva del cliente, o lnea desde la perspectiva del vendedor del circuito. En Colombia, el servicio enlace troncal o lnea loop-start se puede llamar 1-MB; identifica un solo circuito de telfono de velocidad corporativa medida. El nombre indica que el servicio

10

de telfono se mide y se factura segn el uso, en oposicin a la tarifa plana cargada para el servicio de telfonos domsticos. [5] 5.4. Circuito Libre

La sealizacin analgica loop-start utiliza solo un par de cables entre el switch telefnico en una CO y el telfono o switch telefnico conocido como CPE.

La CO proporciona una batera de corriente continua (DC) de -48-volt (V), que genera corriente elctrica a travs del bucle del circuito. Los telfonos particulares no necesitan fuentes de potencia separadas por esta razn. Las CO tambin proporcionan un generador. Cuando el CPE est en el estado on-hook (es decir, el telfono est colgado), hay un switch elctrico abierto que evita que la electricidad fluya a travs del bucle del circuito. Cuando el CPE inicia una llamada cambiando al estado off-hook (es decir, el telfono esta descolgado), el switch elctrico se cierra y la corriente fluye a travs del bucle del circuito. Cuando la corriente fluye por el bucle, la CO detecta la condicin off-hook del CPE. La CO responde transmitiendo un tono de marcacin en el bucle, el cual informa al CPE de que la CO est preparada para recibir dgitos del nmero de telfono de destino. Esto es una forma de supervisin de comienzo de marcacin. La deteccin off-hook y la supervisin de comienzo de marcacin para enlaces troncales loop-start.

5.5.

DEFINICION Y MEDIDA DE LA VOZ SOBRE ASTERISK

La definicin y medida de la calidad de la voz es un reto que ha sido estudiado desde muchas perspectivas. Todava es un rea activa de investigacin en la Unin internacional de las telecomunicaciones (grupo de estudio 12, ITU-T). Los esfuerzos han incluido la caracterizacin precisa de la transmisin fsica en forma de onda, pruebas subjetivas de escucha y modelos fisicoqumicos. Estos esfuerzos han dado lugar a numerosas recomendaciones para la transmisin en circuitos y el rendimiento de los equipos, adems de la medida y caracterizacin de la calidad de la voz. Las investigaciones ms recientes se centran en la calidad de la conversacin para sistemas que utilizan los nuevos cdecs de baja velocidad binaria (como G.723.1 y G.729) [1], [3], [4] y en sistemas que integran VoIP con la Red pblica de telefona conmutada (PSTN).

11

5.6.

Variables que afectan la calidad de la voz.

Hay muchas maneras posibles de considerar y agrupar las variables que afectan a la calidad de la voz. En la siguiente tabla aparecen las siguientes variables.

Variables de punto final

Ruido de fondo en el emisor y receptor Nivel de entrada y salida de serial Recorte de amplitud Distorsin de cuantificacin

Variables de red
Ruido de circuito. Distorsiones dependientes de la frecuencia. Retraso y fluctuacin de fase. Eco del que habla y del oyente. Errores binarios aleatorios Errores rfaga (perdida de paquetes). Distorsin cdec/cuantificacin

Distorsin del codec Errores binarios aleatorios Mltiples hablantes

5.7.

Control de Ruido de Fondo en Asterisk

El ruido de fondo en los extremos del flujo de audio, tanto en la emisin como en la recepcin, puede tener un impacto importante en la calidad de la voz percibida por el oyente. Entre los ejemplos de ruido de fondo se incluyen una oficina ruidosa, una calle concurrida o un centro de computadoras de datos con numerosos equipos de ventilacin y de aire acondicionado. Los efectos del ruido de fondo en el lado oyente, generalmente, se hallan fuera del tema de diseo y planificacin de redes, dado que la red no contribuye a este problema. El ruido de fondo en el lado del hablante es de gran importancia, porque afecta a la operatividad de los codecs y de los sistemas de deteccin de actividad de voz (VAD).

Nivel de Seal: El nivel de la seal es importante en numerosos puntos a lo largo de la ruta de audio, incluyendo la entrada y salida, rutas analgicas intermedias y puntos de conversin A/D o D/A (A/D es analgico/digital). El nivel de la seal se refiere al volumen de audio, el voltaje o la corriente elctrica analgica, el nivel de la muestra de modulacin

12

por impulsos codificados (PCM) en un byte digital, o cualquier cosa que represente el nivel de audio en un medio dado. Generalmente hablando, el nivel de la seal permanece constante cuando se convierte en la forma digital. Sin embargo, los elementos de red pueden aadir "relleno digital" que reduce el nivel de la seal, o el procesado de otra serial que puede afectar al nivel cuando est en el dominio digital. En el dominio analgico, las seales se pueden atenuar en funcin de la distancia de transmisin. Las rutas de transmisin mas largas debilitan la fuerza de la seal. Los retrasos intermedios y los dispositivos de regeneracin tienen el inconveniente efecto de amplificar el ruido acumulado en el circuito adems de la seal deseada. Si los niveles de la seal son demasiado bajos o demasiado altos en cualquier punto a lo largo de la ruta de audio, entonces la seal comienza a distorsionarse (es decir, la informacin de audio se puede perder). [1], [2], [3]

5.7.1. Recorte de Amplitud

El recorte de amplitud ocurre cuando el nivel de una seal es demasiado grande para ser representado exactamente en algn dispositivo al medio de transmisin. La seal se rebaja al nivel al que puede ser transmitida, lo cual causa una distorsin de la forma de la onda original. La Figura 6 ilustra este concepto. La forma de la onda en el lado izquierdo esta dentro de los lmites de amplitud de alguna parte de la red. A medida que la onda se mueve hacia una parte de la red con menos capacidad para acomodar seales altas, la onda original es "recortada" para ajustarse a la envoltura restringida de transmisin. [2]

Figura 9. Esquema cuando el recorte de amplitud cambia la forma de la seal

13

5.7.2. Distorsin de cuantificacin La distorsin de cuantificacin es el efecto de convertir una seal analgica que varia continuamente con respecto al tiempo y a la amplitud en una seal digital que cambia la forma de la amplitud de forma discreta con el tiempo. Para redes que emplean codecs con velocidad de transmisin baja (como muchas redes VoIP, en el caso de asterisk), el efecto de distorsin de cuantificacin es despreciable comparado con otras alteraciones.

Distorsin Codec: La distorsin codec ocurre debido a que muchos algoritmos de codificacin de conversacin con baja velocidad binaria emplean un esquema de compresin por perdida. Esto significa que el lado del oyente no recibe toda la informacin de la seal original. La distorsin codec afecta tanto a las seales de conversacin como a las de no conversacin, como marcacin multifrecuencia (DTMF) y tonos multifrecuencia (MF). Los efectos de la distorsin codec dependen de otras variables, incluyendo la mayor parte de las variables presentadas en esta seccin. Por tanto, el impacto de la distorsin codec en un sistema no debera ser considerado hasta que otras alteraciones hayan sido localizadas con exactitud.

Recorte temporal: El recorte temporal (es decir, recorte con respecto al tiempo) lo presentan los sistemas VAD, los cuales estn diseados para ahorrar ancho de banda y eliminar el ruido de fondo durante los periodos de silencio en una conversacin. Cuando el hablante comienza a hablar, los sistemas VAD requieren una cantidad finita de tiempo para cambiar de un modo de supresin de silencios a un modo de transmisin de conversacin. El comienzo de las palabras o de las frases se puede perder durante este tiempo. [2], [3], [4]

Hablantes mltiples: Los hablantes mltiples pueden afectar a un sistema telefnico de diversas maneras. Los codificadores de lenguaje de baja velocidad binaria modelan los patrones de la seal de un hablante individual; por ello, no pueden proporcionar una calidad ptima de voz cuando varias personas hablan desde el mismo lugar (por ejemplo, mltiples telfonos en una lnea analgica). Las conferencias de audio que tienen mltiples y simultneos hablantes desde diferentes localizaciones tienen problemas

14

similares. Observe que las conexiones de audio hoot-n-holler, o siempre activas, pueden usar tambin una configuracin multipunto que puede verse afectada por los codecs de conversacin de baja velocidad binaria. Adems de la codificacin de la calidad de voz, la anulacin de eco puede no funcionar correctamente cuando las partes en dos o ms terminaciones de una conexin hablan simultneamente. La funcin de procesador no lineal de un anulador de eco, que es responsable de una significativa reduccin del eco, se desactiva cuando ambas partes hablan simultneamente. No se puede cambiar este comportamiento fundamental de un procesador no lineal. La relevancia de estos efectos para un entorno dado debe ser considerada como parte de la evaluacin de la calidad de la voz en el entorno de su red.

Ruido de circuito: El ruido de circuito es fundamentalmente de inters para circuitos analgicos de telefono en la PSTN. Los circuitos analgicos que transportan una seal pueden introducir seales no deseadas, como ruido elctrico aleatorio, cruce de conversaciones o inductancia10 mutua entre cables adyacentes, y clicks y pops desde puntas elctricas en curso durante el switching. El ruido de circuito puede ser un factor significativo para los circuitos analgicos de tramo largo porque la seal deseada puede ser muy dbil cuando se introduce ruido. Como resultado, la capacidad de la seal de ruido (SNR) [2], [9] puede ser muy bajo para tales circuitos. Se puede considerar a los errores binarios como la versin digital del ruido.

Distorsiones dependientes de la frecuencia: Las distorsiones dependientes de la frecuencia ocurren porque los cables analgicos tienen diferentes propiedades de transmisin elctrica para seales de diferentes frecuencias. Por ejemplo, una seal elctrica viaja ligeramente mas rpido a travs de un cable en el rango de frecuencia medio que a frecuencias ms altas o ms bajas. Como resultado, los diferentes componentes de frecuencia de la misma muestra de conversacin alcanzan el destino en tiempos diferentes. Este fenmeno se llama distorsin por retraso de grupo. Efectos similares provocan la atenuacin dependiente de la frecuencia a travs de un circuito, y otros fenmenos relacionados con el tiempo y la amplitud. Las transmisiones por fax y modem de alta velocidad deben considerar los efectos de estos fenmenos; sin embargo, la calidad de la voz no se ve afectada significativamente.
10

La Inductancia mutual es fenmeno que se produce a cabo con dos inductancias cada una afectada por la auto inductancia las cuales se transmiten energa a travs del campo magntico.

15

Retraso y fluctuacin de fase: El retraso y la fluctuacin de fase son factores prominentes en redes por paquetes de voz y en especial en telefona IP. En asterisk el retraso puede ser una consideracin para cualquier comunicacin de larga distancia; sin embargo, las redes de voz de paquete introducen los retrasos adicionales de codecs de baja velocidad binaria, cola y formacin de paquete. Las redes por paquetes de voz tambin deben considerar los efectos de retraso variable, o fluctuacin de fase, ya que la conexin extremo a extremo no es una corriente sncrona en serie, como lo es en redes digitales de circuitos conmutados.

Eco en Asterisk: El eco es el resultado de seales de conversacin en un sentido que se reflejan o se escapan en sentido opuesto. El eco del que llama se produce cuando la seal de la conversacin viaja hacia el destino y se refleja o se fuga en la ruta de audio de vuelta en un punto cercano al destino. Este reflejo o fuga de la seal alcanza los odos del que habla, quien oye su propia voz. Si la seal de eco se refleja o se fuga de nuevo, se convierte en eco del oyente para la parte remota. Debido a que una seal reflejada habitualmente es ms dbil que la seal original, el eco del que habla es ms comn que el eco del oyente. El grado al que un eco es molesto se relaciona con el retraso y el nivel de seal de la seal de eco. La siguiente grafica muestra como se reproduce el fenmeno presentado.

RED TCP/IP CON CANAL INTERNET

ECO DEL QUE HABLA

CURSO DEL ENLACE EN ASTERISK

Figura 10. Fenmeno de Eco presentado en Asterisk

16

Errores en rfaga: Los errores en rfaga se producen cuando se degradan bits adyacentes en una corriente digital. En las redes por paquetes y en especial los datos tomados por el sniffer, los errores que se presentaron en rfaga son menos destructivos que los errores binarios, porque solo se necesitan retransmitir los paquetes con el grupo de errores. Los errores binarios aleatorios estn ms distribuidos, de modo que hay ms paquetes afectados y que deben ser retransmitidos. En una red de voz, se observa el comportamiento opuesto; es decir, los errores en rfaga son ms destructivos que los errores binarios aleatorios. Una corriente de voz no es adversamente afectada por una tasa baja de cambios de serial aleatorios que se sucedan en el tiempo; sin embargo, cualquier agrupacin de errores causa un efecto pronunciado. Los efectos de errores en rfaga en los codecs de baja velocidad binaria se amplan, ya que cada bit de una corriente de voz comprimida representa ms informacin. Una perdida consecutiva de bits significativos puede afectar a una notable porcin de la corriente de audio de salida.

Ciertamente hay otros factores que contribuyen a la calidad de voz percibida por un oyente. Se observa que el rendimiento del codec, que puede ser la mayor alteracin observada en una red VoIP y en especial en Asterisk, es altamente dependiente de un nmero de variables.

5.8.

Medida subjetiva de la calidad de la conversacin

La medida subjetiva de la calidad de conversacin es el planteamiento ms fiable y respetado para medir la calidad de la voz. Este planteamiento determina empricamente la calidad de la voz medida de un codec o sistema a travs del uso del oyente o pruebas de conversacin con personas que se hicieron respectivamente en el laboratorio 302 de la FUKL. Los estudiantes de los grupos de investigacin y los del semillero, actuando como los sujetos experimentales, escuchan muestras de audio y proporcionan su reaccin en forma de una escala de categoras. Las respuestas a diferentes muestras de audio y escenarios de consulta se evalan estadsticamente a travs de wireshark y de la consola del log de asterisk para determinar la respuesta media del grupo. Esta respuesta media

17

refleja el rendimiento del sistema bajo consulta y los efectos de vares factores (como ruido de fondo, mltiples hablantes, niveles bajos de seal, etc.) se pueden cuantificar individualmente. Existen tres mtodos de prueba subjetiva que son por los que aboga la ITU y se recomiendan en entornos de telefona IP. Puntuacin media de opinin (MOS). Puntuacin media de opinin de comparacin (CMOS). Puntuacin media de opinin de degradacin (DMOS). [2], [3], [11]

5.9.

Protocolo de Control Rpido RTP

Utilizado en enlaces de asteruisk de tiempo real, que dispone de extremo a extremo para los servicios de entrega de datos en tiempo real, sus caractersticas, tales como audio y vdeo interactivo. Estos servicios incluyen identificacin del tipo de carga til, numeracin de secuencia, tiempo de entrega y seguimiento. Aplicaciones suelen ejecutar en la parte superior de RTP UDP al hacer uso de sus servicios de verificacin y de multiplexado. Sin embargo, RTP [2], [6] puede ser usado con otro protocolo de la red de transporte o protocolos adicionales que soportan transferencia de datos a mltiples destinos utilizando distribucin de multidifusin

Se tiene en cuenta que RTP no proporciona ningn mecanismo para garantizar la oportuna entrega de paquetes o tampoco aporta calidad del servicio con ptimas garantas, sino que se basa en la capa inferior de servicios para hacerlo. No garantiza la entrega viable o evita que fuera de la orden de entrega, ni asume que las la red es confiable. La secuencia de nmeros incluidos en el receptor RTP permiten reconstruir los paquetes de secuencia al remitente, pero los nmeros de secuencia tambin podra utilizarse para determinar la correcta ubicacin de un paquete, por ejemplo, en vdeo o conferencia mltiple, sin necesidad de hacer decodificacin de paquetes en secuencia. [6], [9]

18

Aunque RTP est diseado principalmente para satisfacer las necesidades de mltiples participantes en conferencias multimedia, no se limita a que se utilice en una aplicacin particular.

5.10. Protocolo de Control Rpido como elemento diferenciador en Telefona IP El Protocolo de control rpido RTP (RTCP) [2], [6], [10] administra los aspectos relacionados con los informes y la administracin de una conferencia RTP multidifusin. RTCP aparece en la RFC 1889 como parte del RTP. Aun cuando RTCP est asignado para escalar conferencias extensas, es til en llamadas VolP punto a punto para proporcionar retroalimentacion QoS desde el receptor al emisor en cada direccin. En el caso de conferencias multidifusin extensas, el ancho de banda de los flujos de medios de RTP tiende a permanecer constante porque solo pueden hablar pocas personas al mismo tiempo, incluso aunque estn escuchando cientos de ellas. La informacin de control de RTCP se enva desde cada participante a otro y cobra importancia la escalabilidad. Si cada oyente enva un paquete de 100 bytes por segundo, en una

conferencia con 10.000 personas cada participante recibe 1 Mbps de informacin de control. RTCP resuelve este problema transmitiendo paquetes con menor frecuencia, al tiempo que aumenta el nmero de participantes detectados en la conferencia.

El algoritmo RTCP limita el control del ancho de banda aproximadamente al 5 del ancho de banda del flujo de medios predeterminado, aunque las aplicaciones pueden ajustar esta cantidad., en el contexto de los cinco tipos de mensaje RTCP estn: Informe del emisor (SR) e informe del receptor (RR). Descripcin de fuente (SDES). Desconexin (BYE). El algoritmo de RTCP en encuentra descrito en la ubicacin web:
http://translate.google.com.co/translate?hl=es&langpair=en|es&u=http://tools.ietf.org/html/draft-wenger-avtrtcp-feedback02&prev=/translate_s%3Fhl%3Des%26q%3Dalgoritmo%2BRTCP%26tq%3DRTCP%2Balgorithm%26sl%3Des %26tl%3Den

19

Estructura de la Cabecera RTCP

FUNCION DEL RTCP PROPOSITO DE LA FUNCION Numero de paquetes RTP perdidos de la sesin

Cumulative Packets Lost

Numero de secuencia mas alto recibido del emisor dgitos adicionales para prevenir la reiniciacin.

Extended Sequence Number Received Interarrival Jitter (J) Last SR (LSR) Time

D = Diferencia entre tiempos entre paquetes en el emisor y en el receptor. 1= Desviacin de D Fecha y hora NTP (Versin de 32 bits) en el ltimo paquete SR recibido del emisor. Diferencia de tiempo entre recibir el ltimo SR y enviar el informe de recepcin.

El RR es idntico al SR, excepto en el tipo de paquete, PT=201, y en que se elimina la seccin de informacin del emisor (es decir, los datos de fecha y hora, y paquetes/bytes enviados). Los campos RTCP de los SR y RR ofrecen a los emisores de medios retroalimentacin QoS de los receptores. Adems, cada receptor puede determinar si su calidad de recepcin concuerda con otros receptores, o si los problemas locales pueden impactar negativamente en su calidad de recepcin. Concretamente, los emisores pueden aprender las siguientes estadsticas de la red: Tiempo de ida y vuelta (RTT). Tasa de paquetes perdidos. Fluctuacin de fase. [2], [6]

Los emisores de medios calculan el RTT, percatndose de cuando se reciben los paquetes RR y usando los campos LSR y DLSR. Un emisor calcula el RTT como la diferencia entre cuando enva un SR a los receptores y cuando recibe un RR de estos. Esto se expresa en la siguiente frmula:

RTT = (LSR -A)- DLSR

20

Todos los participantes en la sesin pueden conocer las tasas de paquetes perdidos en la red, examinando los RR RTCP. La fraccin perdida muestra la velocidad perdida sobre el intervalo de tiempo ms reciente, y la acumulacin de paquetes perdidos permite a los participantes conocer la complejidad del problema, sin necesidad de recordar y rastrear los datos. [2], [6], [12]

La fluctuacin de fase se calcula en cada receptor, notificando cuando llegan los paquetes RTP, y usando el valor del campo de fecha y hora RTP que contenan esos paquetes. En primer lugar, el receptor calcula el tiempo de ida y vuelta para cada paquete recibido. La diferencia en tiempos de trnsito entre dos paquetes adyacentes se calcula siguiendo la formula que se da a continuacin:

Las variables se definen como: D(i,j) es la diferencia en los tiempos de trnsito entre los paquetes adyacentes i y j. RJ es la hora en la que se recibi el paquete j. Sj es la hora en la que se envi el paquete j (determinada por la fecha y hora RTP). R; es la hora en la que se recibi el paquete i. Sj es la hora en la que se envi el paquete i (determinada por la fecha y hora RTP).

Cada paquete de medios RTP entrante provoca un nuevo clculo de la diferencia de los tiempos de trnsito entre el actual paquete i recibido y el anterior paquete i-1 recibido. En lugar de escribir esta diferencia como D(i-l,i), se considera la sintaxis ms simple Dj. [9]

5.11. Uso de Gateways en Asterisk.

Los gateways proporcionan interworking con tecnologas que no son H.323, como videoconferencias RDSI H.320 [3] o redes telefnicas tradicionales. Un ejemplo de gateway H.323 es un router Cisco con interfaces de voz. Un telfono puede conectarse a la PSTN a travs del gateway Cisco, y aparecer para la red H.323 como un punto final H.323 (aunque limitado para las capacidades de audio). Un

21

punto final H.323, por su parte, puede colocar una llamada en la PSTN a travs del gateway Cisco, y aparecer la llamada como generada por un abonado telefnico. La siguiente figura representa la estructura lgica de un Gateway para telefona IP.
Red H323

PSTN

Terminal H323 (MCU)

Funcin de conversin del Gateway Asterisk

Punto final PSTN

Gateway H323 a la PSTN

Figura 11. Estructura lgica de un Gateway en H323 sobre Asterisk

Se observa que los gateways administran 1) la conversin de sealizacin de llamada, 2) la conversin de sealizacin de medios y 3) la conversin de medios cuando se conecta una red H.323 a otra de distinto tipo. Para que los gateways VoIP/PSTN puedan escalar econmicamente grandes volmenes de trfico, tanto la IETF como la ITU dividen los componentes funcionales de un gateway y definen las interacciones estndar de los mismos.

5.12. Uso de Gatekeeper Como su nombre indica, un gatekeeper H.323 controla una zona H.323. Al igual que el centinela de un castillo, que controla quien entra y quin sale, un gatekeeper H.323 regula los puntos finales dentro de su zona que pueden iniciar o recibir llamadas. Un gatekeepeer H.323 tambin puede regular el procedimiento de las llamadas, permitiendo la comunicacin directa entre los puntos finales, o bien actuando como intermediario para transmitir la sealizacin de llamada.

Una zona H.323 es el conjunto de dispositivos administrativamente definidos que controla un gatekeeper. La ultima versin de H.323 trata el asunto relacionado

22

con la redundancia de un gatekeeper en una zona, pero no se refiere al equilibrio de la carga para varios gatekeepers dentro de una zona. H.323 permite que un gatekeeper este activo dentro de una zona en un momento determinado.

Los gatekeepers no son un requisito obligatorio en las redes H.323. Las recomendaciones H.323 especifican que, cuando los gatekeepers estn

presentes, deben desarrollar las siguientes funciones para los puntos finales: Traduccin de la direccin. Control de admisiones y ancho de banda.

Se aclara que un gatekeeper debe proporcionar estos servicios solo para los puntos finales que se encuentran en la zona del gatekeeper que se ha registrado con este. Traduccin de la direccin: El gatekeeper convierte los alias de H.323 o E.164 en direcciones de red e identificadores de puntos de acceso del servicio de transporte (TSAP). Por ejemplo, un gatekeeper puede recibir una peticin de llamada desde un terminal para gustavoa.herazop@fukl.edu.co o +1-408-555-1212. El gateway debe

convertir estas direcciones en una direccin IP (como 192.168.254.1) y un nmero de puerto TCP o UDP (como el puerto TCP 1720 para el establecimiento de la conexin H.225.0). [2], [11] Control de admisiones y ancho de banda: En el control de admisiones, el gatekeeper autoriza terminales, gateways y MCU para colocar las llamadas en la red a travs del canal RAS H.225.0. El control de admisiones es la parte A de RAS. El gatekeeper emite los mensajes de confirmacin de admisin (ACF) o rechazo de la misma (ARJ), en respuesta a los mensajes de peticin de admisin (ARQ) procedentes de los puntos finales. La decisin puede basarse en el criterio de no especificacin dentro de H.323, o un sistema menos complejo puede aceptar todas las peticiones. En respuesta a las

23

peticiones de ancho de banda (BRQ) de los puntos finales, un gatekeeper enva mensajes de confirmacin del ancho de banda (BCF) o rechazo de la misma (BRJ). Solo en el caso del control de admisin, el control del ancho de banda se puede basar en criterios mas ala de H.323, o en una simple poltica de aceptacin de todo. [12] Funciones opcionales del Gatekeeper: Los gatekeepers ofrecen un mecanismo centralizado para administrar planes de Conexin y enrutamiento de llamada en una red VolP. Sin ellos, cada gateway VolP debe mantener informacin de enrutamiento de llamada (iguales de llamada) para cualquier otro destino, a no ser que se implemente un mtodo de enrutamiento de llamada distinto de H.323. Los gatekeepers proporcionan acceso a las funciones de autenticacin, autorizacin y recuento (AAA), esenciales en los sistemas de seguridad y facturacin. La interaccin de nodo entre los gatekeepers y otros sistemas de funciones AAA no se encuentra en el ambito de H.323. Los gatekeepers proporcionan un punto centralizado para la localizacin de recursos basados en polticas. Por ejemplo, un servidor de polticas puede instruir a un gatekeeper para que registre llamadas en base al destino, disponibilidad de ancho de banda, privilegio del usuario, fecha del da, etc. [1], [2] Los gatekeepers facilitan el control de llamadas a terceros, esencial en entornos call-center y otras aplicaciones especializadas en llamadas. Por ejemplo, un automarcador en un centro de llamadas salientes puede iniciar llamadas a clientes objetivo, y conectar un agente call-center despus de que el cliente conteste el telfono. Por estos motivos, se debera considerar los gatekeepers como parte esencial para todas las instalaciones VolP bsicas que usen H.323.

5.13. DIRECCIONAMIENTO

H.323 emplea un esquema de nombres independiente de la tecnologa subyacente de la red, e identifica los requisitos especficos de direccin para H.323 sobre IP, el protocolo de red estndar entre los cuales se encuentran:

24

Identificadores de punto de acceso al servicio de transporte y direcciones (TSAP). Alias H.323. Convenciones de alias para la comunicacin interzonal. Determinacin de las direcciones de red e identificadores TSAP. [4]

2.16. Direcciones de Red e identificadores TSAP

El establecimiento de la comunicacin con cualquier dispositivo H.323 requiere del conocimiento de su direccin de red y un identificador TSAP. En el caso de redes IP, la

direccin de red es una direccin IP, y el identificador TSAP un nmero de puerto TCP o UDP.

Todas las entidades H.323 deben tener, como mnimo, una direccin

de red (direccin

IP), pero pueden tener mltiples direcciones de red en lo referente a la redundancia (es decir, una direccin separada para cada interfaz fsica). Los routers no necesitan direcciones mltiples para la redundancia, ya que una interfaz loopback lgicamente definida permite la comunicacin a travs de cualquier interfaz fsica activa.

2.17.

Alias H323

Dado que las direcciones de red y los identificadores TSAP no son fciles de recordar, H.323 proporciona alias para identificar los puntos finales y conferencias multiparte. (Un alias de conferencia se resuelve a la direccin de red e identificadores TSAP del MC de la conferencia.) Se observa que los gatekeepers y dispositivos MP no utilizan los apodos H.323 porque no se les puede llamar directamente. [6], [9] Y por qu no utilizar nombres DNS en lugar de alias H.323? H.323 esta diseado para ser utilizado con cualquier capa de red, y puede operar independientemente de IP. En lugar de confiar en una resolucin de red dependiente del nombre, H.323 especfica que los gatekeepers introduzcan alias en las direcciones de red e identificadores TSAP (los gatekeepers obtienen esta informacin cuando los puntos finales se registran con ellos). Los alias H.323 pueden tener varias formas: Cadenas alfanumricas: gustavo, gustavo@host.com, host.com, cadenas arbitrarias.

25

 Direcciones E.164: +1-408-555-1212, 5551212, 4199.

2.18.

Convenciones de alias para la comunicacin interzonal

Los alias H.323 cobran importancia dentro de una zona sencilla. Para alcanzar los puntos finales en una zona distinta, el nombre de dicha zona debera formar parte de los alias H.323. En el caso de implementaciones de H.323, es importante establecer una convencin relacionada con el alias, como, por ejemplo, usuario@nombre_zona, donde usuario es un ID de e-mail o cualquier otro identificador personal utilizado en una empresa. Adems, tenga en cuenta que nombre_zona debe coincidir con el nombre de dominio DNS donde reside el gatekeeper. La cadena completa usuario@nombre_zona es el alias H.323. Esta convencin de nombre permite la utilizacin de DNS para superar el abatimiento en la comunicacin interzonal de H.323.

Si los gatekeepers son extensos, es posible que muchos aparezcan (para distintas zonas H.323) en el mismo dominio DNS. Este es un diseo aceptable (y el ms sencillo para asegurar la consistencia de los apodos H.323), pero sea consciente de las deficiencias de este enfoque. Cuando un gatekeeper est incapacitado para introducir un alias, pregunta a todos los gatekeepers en el dominio DNS especificado por el alias H.323. Si todos ellos se encuentran en un dominio DNS sencillo, entonces cada gatekeeper es obligado a procesar las solicitudes de localizacin (LRQ) para cada zona H.323. La mayor parte del trafico LRQ que recibe cada gatekeeper estar en puntos finales no locales.

Si los gatekeeper no pueden procesar todo el trafico adicional, necesitara imponer una capa extra de jerarqua DNS que solo utilizaran los gatekeepers H323, para prevenir la sobrecarga de los gatekeepers. Por ejemplo, si una empresa posee un gran dominio denominado empresa.com, puede crear zonal.empresa.com, zona2.empresa.com, o cualquier otro nombre que coincida con el de su empresa. Por tanto se asigna cada gatekeeper a una zona nueva distinta, pero no se debe cambiar el registro DNS ya existente de los puntos finales. Dicho de otro modo, todos los puntos finales deberan permanecer en el dominio DNS empresa.com, mientras cada gatekeeper se encuentra en un subdominio DNS distinto de empresa.com. Cada zona H.323 (identificada por un

26

subdominio DNS del dominio principal de la empresa) debera alternar los gatekeepers ante posibles fallos de tolerancia. Un registro SRV [3], [10] correspondiente al servicio de descubrimiento del gatekeeper. Son posibles distintas variaciones de la implementacin. El punto final puede emitir la consulta SRV usando su propio dominio, lo que implica que el gateway y el gatekeeper estn en el mismo dominio. Esto puede ser un problema en determinados diseos.

El punto final tambin se puede configurar con un nombre de dominio para el gatekeeper, lo que determina la zona a la que pertenece. Ambos mtodos influyen en la fuerza de los registros SRV; es decir, la direccin IP de un puerto UDP para el descubrimiento del gatekeeper puede cambiarse para cuestiones relacionadas con el mantenimiento, la administracin o la seguridad, sin necesidad de volver a configurar cada cliente.

2.19.

Registros TXT

Si no se ha implementado una versin de DNS que soporte registros SRV, se puede usar registros TXT para desarrollar funciones parecidas. Un servidor DNS responde a una consulta TXT devolviendo una lista de todos los registros TXT para el dominio consultado. Para esto se puede crear un registro para cada gatekeeper de un dominio con la siguiente sintaxis:

ras [< gk id>@]<nombre de dominio>[:<numeropuerto>] [<prioridad>]

Incluso si se est utilizando registros TXT para otros propsitos, la palabra clave ras permite al cliente H.323 filtrar los registros TXT que no se necesitan. Esta sintaxis permite a un punto final H.323 descubrir el gatekeeper de forma anloga a los registros SRV.

Los mtodos SRV y TXT de descubrimiento del gatekeeper introducen un nuevo comportamiento de H.323: Si existen mltiples gatekeepers en el mismo dominio DNS, los puntos finales pueden registrarse aleatoriamente con cualquier gatekeeper (lo que identifica una zona H.323) que se encuentre en el dominio DNS. En estos casos, las zonas H.323 distintas solo existen para limitar el nmero de usuarios por gatekeeper Presumiblemente los

27

gatekeeper se configuran para rechazar solicitudes de registro de puntos finales cuando hayan alcanzado su lmite de proceso. Para que este desafo funcione correctamente, cada zona H.323 (es decir, los gatekeepers) dentro de un dominio DNS debera tener polticas consistentes y privilegios de acceso al gateway. Todos los puntos finales tendrn un alias H.323: usuario@dominio.com, y no importa la zona actual H.323 en la que est registrado el punto final (excepto cuando se trata de resolver problemas). Cuando un gatekeeper recibe una solicitud para un alias H.323 en una zona distinta, el enva un LRQ al gatekeeper de la zona de destino H.323. Las soluciones DNS determinan esta zona buscando el nombre de dominio especificado en el alias H.323 de destino. Si se localizan mltiples gatekeepers en el dominio DNS especificado por el alias H.323, el nombre de dominio DNS no se asignara nicamente a una zona H.323. Un gatekeeper que intente resolver un alias desde una zona diferente deber entonces enviar un LRQ a cada uno de los gatekeepers del dominio DNS especificados por el alias H.323.

El gatekeeper correcto responder con un LCF, pero los otros gatekeepers del dominio deben procesar la consulta y devolver un LRJ. Si existen muchos gatekeepers en un dominio sencillo, los mensajes LRQ/LRJ adicionales pueden convertirse en un asunto legtimo.

2.20. Control de llamadas en Asterisk con H.225.0

Cuando los puntos finales inician una solicitud de conexin de llamada, deben determinar la direccin de la red y el identificador TSAP de destino. Los puntos finales pueden descubrir esta informacin "fuera de banda" (por ejemplo, mediante un mensaje de email), que se encuentra fuera del alcance de H.323. Adems, los puntos finales pueden iniciar una conexin basada en un alias H.323. En este caso, es responsabilidad del gatekeeper resolver el alias para una direccin de la red y el identificador TSAP.

El identificador TSAP predeterminado para todos los canales de control de llamada H.225.0 es el puerto TCP 1720. Un punto final puede avisar de que un identificador TSAP se encuentra en su mensaje de registro del gatekeeper, lo que es transparente para otros puntos finales que inician llamadas a los alias H.323. Los puntos finales que inician

28

llamadas a las direcciones IP y nmeros de puerto TCP deben averiguar el nmero de puerto determinado a travs de un mtodo de fuera de banda.

2.21

Control de llamadas en Asterisk con Medios H.245

La direccin de la red y los identificadores TSAP para canales de control de medios H.245 no son necesarios en asterisk, ya que los puntos finales y las MCU que necesitan establecer canales H.245 ya estn comunicndose a travs de un canal de control de llamada H.225.0. Las direcciones de red para la comunicacin H.245 son las mismas que para el canal de control H.225.0 existente, y las direcciones TSAP para H.245 se negocian sobre el canal de control de llamada. El control de llamadas en H.225.0 es un canal fiable por el que se intercambian conexiones de llamadas, cancelaciones y mensajes de servicio suplementarios. Por defecto, los puntos finales responden al puerto TCP 1720 de las peticiones de llamadas entrantes. Los puntos finales pueden recibir llamadas de un puerto TCP diferente y publicar este puerto a un gatekeeper para la resolucin de un alias H323. [2], [3], [9]

PBX
H323 Zona1 H323 Zona2

PBX

GRQ

GRQ

GCF
RRQ RCF ARQ ACF LRQ LCF
MENSAJE DE CONEXIN H225.0

GCF
RRQ RCF

ARQ

ACF
DRQ DCF
SEALIZACION H225.0 Y H245..MEDIO ESTABLECIDO LLAMADA ACTIVA

DRQ DCF

Figura 12. Intercambio entre puntos finales a travs de H225 en Asterisk

29

2.22.

PROTOCOLO SIP EN ASTERISK

Session Initiation Protocol (SIP) es un protocolo de sealizacin utilizado para el establecimiento de perodos de sesiones en una red IP, en especial Asterisk. Un sesin puede ser un perodo simple bidireccional o llamada telefnica que podra ser una colaboracin multimedios o de de comunicacin de conferencias.

La capacidad de establecer estos perodos de sesiones significa que una serie de servicios innovadores, tales como la voz con el comercio electrnico, las pginas web que se utilizan para telefona, la mensajera instantnea o chat y los servicios IP Centrex. Durante el ltimo par de aos, la Voz sobre IP SIP ha adoptado su protocolo de eleccin para la sealizacin. SIP basado en la RFC standard 3261.

SIP es un estndar de la Internet Engineering Task Force (IETF), y es el rgano encargado de administrar y desarrollar los mecanismos que conforman la Internet. SIP sigue evolucionando y est ampliando a medida que la tecnologa madure. SIP es mucho ms que un molde, ha sido desarrollado exclusivamente como un mecanismo para establecer sesiones de alta capacidad en telefona IP, en este protocolo no se conocen los detalles de los perodos de sesiones, slo se inicia, termina y se modifican las sesiones. Esto significa que la simplicidad de SIP es escalable, es extensible, y est sentado cmodamente en diferentes arquitecturas y escenarios de despliegue lo que lo hace muy poderoso. SIP es un protocolo de peticin-respuesta que se asemeja a otros dos protocolos de Internet, HTTP y SMTP (los protocolos de poder de la world wide web y correo electrnico) y, por consiguiente, SIP es similar al de las aplicaciones de Internet. Gracias al uso de SIP, la telefona se convierte en otra aplicacin Web y se integra fcilmente con otros servicios de Internet. SIP es un simple conjunto de herramientas que los proveedores de servicios pueden utilizar para construir aplicaciones de convergencia de voz y servicios multimedia. [7], [8], [11] Con el fin de proporcionar servicios de telefona existe una serie de normas y protocolos para implementar y garantizar el transporte (RTP), para autenticar a los usuarios (radio,

30

dimetro), para proporcionar directorios (LDAP), para poder garantizar una calidad de voz (RSVP, YESSIR) y entre otros a trabajar con la actual red telefnica.

2.23.

Atributos del protocolo SIP

SIP se diseno como una solucin a largo plazo para las conferencias multimedia y la telefona en Internet. Se han tenido en cuenta muchas consideraciones con el desarrollo del protocolo para asegurarse de que es una plataforma viable para futuras comunicaciones que se basen en Internet:

Simplicidad. A diferencia de la mayora de los protocolos de telefona e Internet, SIP emplea mensajes de texto piano que se pueden leer. Seguidos, adems, de formatos estndares como HTTP 1.1 y "mailto:". Esto hace que el protocolo sea relativamente sencillo para resolver problemas e integrarse con otras aplicaciones.

Eficiencia. El protocolo superior de SIP tiene poco impacto en la eficiencia de la comunicacin, puesto que las funciones de sealizacin consumen poco ancho de banda en relacin con el flujo de medios. SIP es muy eficaz en trminos de tiempo de conexin de llamada, ya que toda la informacin que se pide para el establecimiento de la llamada se incluye en el mensaje inicial.

Escalabilidad. Los servidores no mantienen la informacin del estado de las sesiones basadas en UDP en el SIP que procesan, por lo que un solo servidor puede manipular eficientemente muchos clientes. Los bucles de enrutamiento de mensajes, que pueden consumir grandes recursos de red, son ms comunes a medida que crece la red. SIP detecta y previene los bucles de enrutamiento de mensajes, lo que aumenta el rendimiento de las redes extensas

Flexibilidad. Dado que SIP usa SDP para negociar los codecs, se puede utilizar cualquier codec registrado por la Agenda de asignacin de nmeros Internet (IANA). Al contrario que H.323, donde los codecs se definen explcitamente como parte del cambio lento estndar, el resto de codecs deben compartir un campo genrico para los "codecs no estndar".

31

Soporte de movilidad. El modelo de comunicacin SIP se dirige a los usuarios que se pueden mover de terminal a terminal (por ejemplo, telfonos y computadoras), lo contrario a los terminales en si mismos. El protocolo proporciona un enorme soporte para proxying y redireccin, por lo que los usuarios tienen la opcin de proporcionar u ocultar su verdadera ubicacin.

Programacin del usuario. Adems del soporte nativo para las funciones de telefona tradicional (por ejemplo, reenvi de llamada, transferencia, retencin, conferencia y dems), SIP puede aprovecharse del Lenguaje de procesamiento de llamada (CPL, Call Processing Language). Este permite a los usuarios proporcionar reglas complejas a un servidor, sin importar quien pueda localizarlas, cuando, donde y con qu tipo de medios. Los sistemas H.323 tambin se pueden aprovechar de CPL. Las herramientas como los servlets j las extensiones de la interfaz de gateway comn (CGI) de SIP se estandarizan actualmente, lo que facilita el desarrollo de las aplicaciones que este permite.

Extensin. Los creadores del protocolo reconocieron que no podan prever todas las peticiones de dicho protocolo, por lo que crearon una arquitectura que fuese modular y flexible. Esto permite mejorar el incremento y las extensiones del protocolo, mientras asegura una operacin ms cercana a las versiones ms antiguas. Tambin facilita la posibilidad de retirar las opciones de protocolos no usadas, lo que evitara que dicho protocolo se haga poco manejable.

2.24.

Componentes del Sistema

Los Agentes del usuario (UA) son las aplicaciones de punto final que envan y reciben peticiones SIP para beneficio de los usuarios (por ejemplo, personas o sistemas automatizados). Los Clientes de agentes del usuario (UAC) envan peticiones SIP a la parte llamante, y los Servidores de agentes del usuario (UAS) reciben las respuestas de la parte llamada. Cada usuario puede tener varios agentes del usuario. Por ejemplo, puede tener agentes de usuario independientes para el telfono de su oficina, de su casa, su mvil y su computadora multimedia. Se asocia una direccin SIP con cada agente del usuario.

32

Los Servidores proxy son aplicaciones que reciben peticiones SIP de clientes, e inician nuevas peticiones para beneficio de los clientes hacia los agentes del usuario de destino. Puede ver a los servidores proxy como routers SIP, que remiten mensajes de sealizacin de llamada hacia el destino. Este comportamiento es anlogo al de la sealizacin enrutada de gatekeeper (GKRS) en H.323. Tambin es parecido al de los gateways de correo SMTP, excepto en que los mensajes deben ser remitidos en tiempo real.

La informacin que emplea un servidor proxy para dirigir peticiones SIP, va mas ala del mbito de la especificacin SIP. Los servidores proxy SIP pueden tener un reconocimiento local de los agentes de usuario desde un registrador SIP. Tambin pueden conocer varias alternativas para localizar a un agente de usuario, y pueden intentar cada una de ellas en un proceso de bifurcacin que puede ser paralelo o secuencial. Dependiendo de la configuracin del proxy SIP, las respuestas pueden fluir a travs de los servidores proxy en direccin opuesta al de las peticiones, o pueden fluir directamente hacia el emisor original del mensaje de Invitacin SIP. Estos servidores pueden proporcionar tambin una direccin de redireccin para los clientes solicitantes en lugar de reenviar la solicitud SIP. [7]

Los Registradores aceptan registros de clientes que indican las direcciones en las que se les puede localizar. La funcionalidad de los registradores se combina frecuentemente con un proxy o con un servidor de redireccin, pero este es un proceso lgico separado y esta oficialmente fuera del mbito de SIP. Por ejemplo, un registrador SIP puede ser una extensin de software en una base de datos LDAP que contenga un directorio de usuarios.

2.25.

Direccionamiento de SIP

Aunque los servidores proxy, los servidores de redireccin y los registradores pueden entrar en una transaccin SIP, solo los usuarios y los agentes de usuario tienen direcciones SIP. Los servidores SIP (como proxy, de redireccin y registradores) solo se identifican por las direcciones IP y los puertos TCP/UDP. Por defecto, los servidores SIP escuchan en los puertos TCP y UDP 5060, pero pueden utilizar cualquier nmero de puerto. [8]

33

2.26.

Sintaxis de la Direccin SIP

La sintaxis de un URL SIP se modela despus de la RFC 2396, con el ttulo "Uniform Resource Identifiers (URI): Generic Syntax". Un URL SIP bsico tiene el siguiente formato:

"sip:"

[ user [ ":" password ] "@" ] ((hostname [IP-address )[ ::port ] Algunos ejemplos de

URL SIP son los siguientes:

sip:gustavo@company.com sip:lizza@192.168.100.248 sip:lizza:secret@company.com sip:gustavo:secret@company.com:5060 sip:luiscarlos@192.168.100.248:5060

Un URL SIP tambin puede incluir parmetros e informacin de cabecera, con la siguiente sintaxis aadida al URL SIP bsico:

[";"param "="value ]["?"1st_header "="value ["&"other_headers "="value ]]

Un URL SIP puede tener varios parmetros y campos de cabecera, como se indica en los ejemplos siguientes:

sip:gustavo@company.com;transport=udp

Otra opcin que no requiere estndares nuevos es utilizar la opcin (66) de servidor TFTP de DHCP y tener al cliente UA descargando un archivo de configuracin que contenga el nombre de dominio DNS, o la direccin IP y el puerto TCP del servidor SIP. Esta opcin es muy practica y est disponible actualmente, lo que permite que los clientes SIP UA sean completamente porttiles. Los clientes SIP utilizan por defecto el puerto TCP/UDP 5060 para localizar un servidor SIP, pero emplearan cualquier puerto que este especificado en un URL SIP (devuelto por una consulta DNS SRV) o configurado mediante TFTP en el momento del inicio.

34

2.27.

Mtodo de registro SIP

Los agentes de usuario SIP se pueden configurar estticamente para la localizacin de un registrador SIP, o pueden emplear la multidifusin para encontrarlo. La direccin multidifusin bien conocida para que los clientes Colombianos se registren con un registrador es 224.0.1.75. Hay tambin un nombre DNS para estas direcciones, y es sip.mcast.net.

Si utiliza el mtodo multidifusin para localizar registradores, siempre se debe asegurar de limitar el alcance de las direcciones multidifusin, ya que las solicitudes de registro SIP nunca abandonan el dominio administrativo (a no ser que se quiera que determinados clientes se registren en registradores SIP ajenos). Para limitar el alcance de las direcciones multidifusin, se puede utilizar las Listas de acceso de los routers fronterizos de multidifusin, o reducir el tamao del campo TTL en la cabecera IP basndose en el dimetro de la red.

Es importante que tenga en cuenta que los agentes de usuario SIP de la red pueden escuchar las direcciones multifusion del registrador SIP para aprender de la presencia de otros agentes de usuario. Esta tcnica puede ser un mecanismo eficiente para que los agentes de usuario desarrollen mallas localizables en un dominio administrativo, cuando no existe un servidor proxy local. Sin embargo, este mtodo puede suponer un trabajo adicional. [7], [8]

Muchos cdigos de respuesta SIP/2.0 en cada categora son idnticos a los cdigos de respuesta HTTP/1.1 correspondientes. Los cdigos SIP en una categora no coinciden con los cdigos HTTP existentes, que normalmente utilizan el rango x80 a x99, mientras que los nuevos cdigos de respuesta HTTP sern asignados por debajo de x80. Esta consideracin permite a SIP y a HTTP adoptar cada uno de los cdigos nuevos ajenos y mantener la consistencia. La consistencia del cdigo de respuesta es importante porque SIP y HTTP se unen para compartir los mismos componentes de la aplicacin del servidor (por ejemplo, analizadores sintcticos, tratamiento de errores, etc.).

35

SIP introduce la categora de cdigos 6xx para distinguir entre las respuestas de error que pudiesen producirse en cualquier servidor y las respuestas de error que son nicos para un servidor en concreto. Por ejemplo, un servidor UA puede declinar la respuesta de un cliente porque este ocupado (lo cual es una respuesta de error por parte de un servidor), pero el cliente necesita saber si debera seguir con la solicitud en otra parte. El usuario llamado puede que desee estar ilocalizable para cualquier origen (no molestar en una configuracin global), por lo que el servidor UA puede informar al cliente de su estado con una repuesta 600 denominada busy everywhere. El cliente entonces sabe que tiene que dejar de enviar solicitudes INVITE a otros servidores UA del usuario.

Si un cliente recibe un cdigo de respuesta SIP no reconocido, negocia la respuesta como una respuesta xOO para una categora determinada. Este comportamiento asegura la compatibilidad retrospectiva con los clientes SIP ms antiguos, adems de permitir extensiones para los cdigos de respuesta SIP. [2], [8]

Los cdigos de respuesta SIP para SIP/2.0 se muestran en la siguiente tabla: Cdigo Descripcin de la respuesta Intentando Ringing La llamada esta En cola Progreso de la sesin OK Opciones mltiple 411 413 414 415 420 480 481 Cdigo Descripcin de la respuesta Longitud requerida Entidad solicitada demasiado Solicitud-URI demasiado grande Tipo de medio no soportado Extensin errnea No disponible temporalmente Circuito de llamada o transaccin Detectado un bucle Demasiados saltos

100 180 181 182 183 200 300

301 302

Movido permanentemente Movido

482 483

36

temporalmente 303 305 380 400 401 402 403 404 405 406 407 408 409 410 Ver otro Utilizar proxy Servicio alternativo Respuesta mala Sin autorizacin Pago requerido Prohibido No encontrado Mtodo no permitido No aceptable Se requiere autenticacin Se requiere lmite de tiempo Conflicto Hecho 484 485 486 487 488 500 501 502 503 504 505 600 603 604 606
Tabla 3. Cdigos de respuesta SIP

Direccin incompleta Ambiguo Ocupado aqu Solicitud terminada No aceptable aqu Error interior del servidor No implementado Gateway errneo Servicio no disponible Limite de tiempo del gateway Versin de SIP no soportada Ocupado completamente Declinar No existe en cualquier parte No aceptable

2.28.

Cabeceras SIP

Las cabeceras en los mensajes SIP efectan la misma funcin que los campos en una cabecera de protocolo normal. Es decir, cada cabecera SIP representa un valor variable que se transporta a travs de la red. Algunas cabeceras SIP son obligatorias en cada mensaje, y otras se utilizan departiendo del tipo de solicitud o de respuesta. El formato general para las cabeceras SIP es:

<Nombre cabecera>: <Valor cabecera> <Continuacin de valor de cabecera>

El valor de la cabecera es una o ms lneas de informacin. Los espacios en blanco a la izquierda identifican las continuaciones de la cabecera multilinea. Una clave de

37

encriptacin PGP es un ejemplo de valor de cabecera que necesita varias lneas. Algunos ejemplos de una sola lnea son los siguientes:

From: sip:102@2.0.0.1 User-Agent: Cisco VolP Gateway/ IOS 12.x/ SIP enabled Content-Type: application/sdp

El orden en el que aparecen las cabeceras SIP en el mensaje no es importante, salvo dos excepciones: Cuando aparecen en el orden en el que las respuestas SIP deberan fluir de regreso a travs de los servidores proxy para conectarse con el UA de la parte llamante. Las cabeceras Hop-by-Hop (es decir, las cabeceras que se deberan procesar en los servidores proxy) tendran que aparecer antes que las cabeceras End-to-End (como las cabeceras para los UA de las partes llamante y llamada). [7]

Los detalles de la sesin, tales como el medio de comunicacin, el codec, o la frecuencia de muestreo, no se describen usando SIP. Por el contrario el cuerpo del mensaje contiene una descripcin del periodo de la sesin, codificado en otro formato como SDP Existen seis mtodos bsicos SIP (definidos en RFC 254)11 que describen las peticiones de los clients:
INVITE: Permite invitar un usuario o servicio para participar en una sesin o Para modificar parmetros en una sesin ya existente. ACK: Confirma el establecimiento de una sesin. OPTION: Solicita informacin sobre las capacidades de un servidor. BYE: Indica la terminacin de una sesin. CANCEL: Cancela una peticin pendiente. REGISTER: Registrar al User Agent.

A continuacin se mencionaran las respuestas ms comunes de este protocolo:

11

RFC 254. Estndares sobre las peticiones y cdigos de repuesta en el protocolo SIP.

38

Codigo Descripcion 100 Trying (Indica intentando la llamada) 180 Ringing (Indica que suena el UA que se llama) Call is being forwarded (Indica que la llamada es desviada) 181 182 Queued (LLamada encolada) Session progress (Indica el progreso de una sesin SIP) 183 200 OK 202 Accepted 300 Multiple choices Moved permanently (Indica que el UA/Server ha sido movido permanentemente a otra direccin. Moved temporarily (Movido temporalmente) Use proxy (Necesario usar proxy) Alternative service Bad request (Peticin errnea) Unauthorized (Peticin sin autorizar) Payment required (Necesario pago de la llamada) Forbidden (Peticin no permitida , a nmeros no permitidos etc...) Not found (NO se encuentra el UA llamado) Method not allowed Not acceptable Proxy authentication required (Necesiario autenticar el INVITE ) Request time-out Conflict Gone Length required Request entity too Request-URI too large Unsupported media type Bad extension Temporarily not available Call leg/transaction does not exist Loop detected Too many hops Address incomplete Ambiguous Busy here Request cancelled Not acceptable here Internal servere error Not implemented Bad gateway Service unavailable Gateway time-out SIP version not supported Busy everywhere Decline Does not exist anywhere Not acceptable
Tabla 4. Respuestas ms comunes del protocolo SIP

301 302 305 380 400 401 402 403 404 405 406 407 408 409 410 411 413 414 415 420 480 481 482 483 484 485 486 487 488 500 501 502 503 504 505 600 603 604 606

39

2.29.

MGCP (Media Gateway Controller Protocol)

Es conocido como el protocolo MEGACO, H.248, es un estndar que posibilita a un MGC controlar uno o varios MG's (establecer, modificar y terminar conexiones en los MG's). Es un protocolo de control de dispositivos ms no de sealizacin de VoIP. MGCP es un protocolo basado en texto y soporta un modelo de llamada centralizado. Es un protocolo que no requiere una maquina de estados para describir una secuencia de transacciones entre dos entidades de sealizacin, y tampoco mantiene memoria de las transacciones previas entre el MGCP y los MG's. El MGCP utiliza el protocolo SDP (Session Description Protocol) para describir la sesin, lo que quiere decir: el nombre y el propsito de la sesin, tiempo en que la sesin est activa, requerimientos de ancho de banda, etc. MGCP se transporta sobre UDP, conformndose la pila MGCP/UDP/IP de tal forma que los mensajes MGCP constituyen el cuerpo de datos de los datagramas UDP.

40

CAPITULO 3 RESULTADOS OBTENIDOS

3.1

PLATAFORMA DE SISTEMA OPERATIVO

De acuerdo a todas las pruebas obtenidas en funcin de la daptabilidad de los componentes de asterisk, se escogi como sistema operativo (OS) Ubuntu 8.10, por las facilidades que presenta en su configuracin respecto a los dems sistemas operativos evaluados como lo fueron (Debian, Centos y Ubuntu).

De igual manera para las exigencias necesarias del proyecto se adopta, por los mnimos requerimientos que exige es sus configuraciones de hardware para la versin 8.10

RAM Mnima de 64 Mb Recomendacin en Disco Duro de 4 Gg Procesador 300Mhz x86 Unidad lectora CD-Rom

Ubuntu presenta y cuenta con los requerimientos de distribucin de Debian, lo cual brinda seguridad en la estabilidad, escalabilidad y funcionalidades de este tipo de distribuciones.

Al nivel de costos y revisando hacia la posible expansin del proyecto Ubuntu ofrece servicio servidor gratuito a diferencia de otras distribuciones de SO operativo basadas en RedHat.

Si se revisa el soporte de bases de datos que ofrece Ubuntu presenta interoperabilidad con motores e interpretadores de corte abierto con Mysql, Apache, PHP, PERL, componentes que son necesarios para la convergencia de los servicios de asterisk.

41

Los volmenes se instalaron consistentemente y los valores requeridos en tamaos de bloques se ajustaron exitosamente a la capacidad de los servidores LINUX para minimizar los tiempos de consumo de CPU y procesador, como se muestra en la siguiente grafica,

3.2

INICIO DE DESCARGA Y AJUSTES PREVIOS DE INSTALACION DE ASTERISK LAB. 302 FUKL.

Completando los ajustes del Sistema operativo en cuanto a volumnes, tamao de bloques requeridos y minimizacin de recursos de memoria, se contina con la segunda fase de descarga y ajustes iniciales de cada uno de los componentes requeridos para el proyecto. ADICION DE COMPONENTES REQUERIDOS PARA EL INICIO DE ASTERISK PROBLEMA Error gcc not found Error g++ not found Error C compiler No se CAUSA intal SOLUCION gcc #apt-get install gcc

correctamente No se instal g++ #apt-get install g++

correctamente cannot Falta el paquete libc-dev #apt-get install libc-dev create executables Error c++ not found Error gpp not found Error aCc not found Error Cc not found Error cc++ not found Error cxx not found No se instal c++ #apt-get install c++

correctamente No se instal gpp #apt-get install gppp

correctamente No se instal aCc #apt-get install aCc

correctamente No se instal Cc #apt-get install Cc

correctamente No se instal cc++ #apt-get install cc++

correctamente No se instal cxx #apt-get install cxx

correctamente

42

Error cl.exe not found Error FCC not found Error KCC not found Error RCC not found Error xlC not found Error xlC -r not found

No

se

instal

cl #apt-get install cl

correctamente No se instal FCC #apt-get install FCC

correctamente No se instal KCC #apt-get install KCC

correctamente No se instal RCC #apt-get install RCC

correctamente No se instal xlC #apt-get install xlC

correctamente No se instal xlC -r #apt-get install xlC -r

correctamente

DIFICULTADES ENCONTRADAS PROBLEMA Error apache2 not found Error iftop not found Error lame not found Error CAUSA No se instal correctamente No se instal iftop #apt-get install iftop SOLUCION apache2 #apt-get install apache2

correctamente No se instal lame #apt-get install lame

correctamente libmysqlclient15-dev No se instal #apt-get libmysqlclient15-dev install

not found Error libncurses5-dev not found Error libploticus0-dev not found Error libsox-fmt-all not found Error linux-source not found

libmysqlclient15-dev correctamente

No se instal libncurses5- #apt-get dev correctamente No se instal libncurses5-dev

install

libploticus0- #apt-get libploticus0-dev

install

dev correctamente

No se instal libsox-fmt-all #apt-get install libsox-fmtcorrectamente all install linux-

No se instal linux-source #apt-get

43

correctamente Error found Error mpg123 not found Error mtop not found Error mysql-client-5.0 found Error found Error mysql-server-5.0 found Error mytop not found Error ntp not found Error openssh-server not found Error php5 not found Error php5-cli not found Error php5-dev not found Error php5-mysql not found Si egError sipsak not found Error sox not found Error subversion not found mysql-doc-5.0 linux-headers

source install linux-

not No se instal linux-headers #apt-get correctamente No se instal headers

mpg123 #apt-get install mpg123

correctamente No se instal mtop No se encontro

correctamente not No se instal mysql-client- No se encontro 5.0 correctamente not No se instal mysql-doc-5.0 No se encontro correctamente not No se instal mysql-server- No se encontro 5.0 correctamente No se instal mytop No se encontro

correctamente No se instal ntp No se encontro

correctamente No se instal openssh- No se encontro

server correctamente No se instal php5 No se encontro

correctamente No se instal php5-cli No se encontro

correctamente No se instal php5-dev No se encontro

correctamente No se instal php5-mysql No se encontro correctamente No se instal sipsak No se encontro

correctamente No se instal sox No se encontro

correctamente No se instal subversion No se encontro correctamente

44

Error subversion-tools not found Error 2005 mysql

No se instal subversion- No se encontro tools correctamente

3.3. ESTADO DEL ARTE DE LAS FUNCIONALIDADES FRENTE A DIVERSOS PROVEEDORES Se tomaron las 3 alternativas lideres en el mercado: Asterisk, Avaya y Cisco
ASTERISK
SIP IAX/IAX2 SIP

AVAYA
RIP OSPF IGRP EIGRP BGP G.729a G.723 G.711 G.711 u G.711 a

CISCO

Protocolos soportados

MGCP H.323 CISCO SKINNY G.711u G.711a G.722 G.723 G.728 G.729 GSM Speex Telefonos IP ATA Placas Telfono IP Avaya 4602 Telfono IP Avaya 4602SW Telfono IP Avaya 4606 Telfono IP Avaya 4630SW Telfono digital Avaya 2402 Telfono digital Avaya 2420

Codec

Telefonos IP

Hadware compatible

Softphone

Software libre Transferencia Msica en espera Pickup de llamadas Llamada en espera

Conmutador Avaya Conferencia Correo electronico Correo de voz mensajeria Instantanea Video

SoftPhone 1.3 Acceso multiservicio Contestador automtico Buzn de voz Sistema de personas Distribucin llamadas localizacion automatica de de

Funcionalidades

Conferencias Colas de llamadas Buzon de Voz IVR Configuracin en bases de datos

Mensajeria instantanea Procesador Intel Pentium III, Procesador Pentium 4 a 2,8 RAM: 256 MB mnimo, 512 MB 700 MHz GHz o superior con 256 MB de recomendados para un mejor Memoria 1 GB de RAM Espacio en Disco 30 MB Memoria 1 GB de RAM Memoria 1 GB de RAM Espacio en disco duro: 70 MB slo para la aplicacin, 200 MB recomendados Sistemas operativos: Windows XP, Service Pack 1 superior Velocidad del procesador: 1 GHz Las versiones de Windows de 64 bit no se han probado ni se admiten oficialmente. Se necesitar permiso de escritura en el directorio inicial y hacia el directorio de instalacin de Network Assistant para que ste Cantidad de colores: 65536 Resolucin: 1024 x 768 Tamao de fuente: Pequeo

Requisitos de instalacin

20 GB de espacio en disco mnimo para poder mantener en lnea un mnimo de 10 GB de grabaciones (ms de 1000 Sistema Operativo Linux, Microsoft Windows XP Windows 2000, Windows XP Professional SP3/ Vista Business SP1/ Vista Ultimate Conexin de Red IP (banda Redes y seguridad TCP/IP, ancha, LAN) Internet Explorer 5.0 o versin Buscar y reproducir llamadas grabadas mediante un PC y una tarjeta de sonido de PC

Arquitectura

Cliente-servidor

SOA(Orientada a servicios)

SOA(Orientada a servicios)

45

Tabla 5. Comparativo entre plataformas Asterisk, Avaya y Cisco.

La plataforma Asterisk se denota como la mejor alternativa, permitiendo integrar las conexiones telefnicas tradicionales a nuevos sistemas de voz, adicionalmente soporta la mayor parte de los protocolos utilizados en el mercado. De igual manera porque es una aplicacin de tipo cliente - servidor que permite que terminales clientes se conecten a l. Los directorios y archivos que se utilizaron en Asterisk son:

Tabla 6. Directorios y archives que se requieren en Asterisk

3.4. ANALISIS DE FUNCIONALIDADES CON WIRESHARK 3.4.1. FUNCIONALIDADES SIP Todo el anlisis de funcionalidades del Grupo de Investigacion se realizo con la herramienta de software libre Wireshark, que es un analizador de protocolos utilizado para el anlisis y solucin de problemas en redes de comunicaciones y se considera como uno de los softwares mas integral y de mejores servicios administrativos en lo relacionado con la gestin de redes y en especial con la telefona IP, ya que integra todos los protocolos de sealizacin que en ella se utilizan.

46

Esta herramienta ofrece mltiples opciones de organizacin y filtrado de informacin. El siguiente pantallazo despliega en el primer panel la lista de paquetes capturados.

47

Si se ubica el cursor sobre alguno de los paquetes obtendremos informacin detallada acerca del mismo, como se muestra a continuacin:

Asi mismo obtengo informacin de los paquetes capturada en bytes.

Con respecto a la informacin de los paquetes podemos obtener: Time: Source: Destination: Protocol: Info: Tiempo. Direccin. Direccin destino del paquete. Nombre del protocolo del paquete. Informacin adicional del contenido del paquete.

Si filtramos la informacin a travs de la expresin (ip.addr==192.168.100.240 && ip.addr==192.168.100.249) or (ip.addr==192.168.100.243 && ip.addr==192.168.100.249) obtendremos la sealizacin de la llamada, como se muestra a continuacin:

48

Figura 13. Sealizacin bajo el protocolo SIP

49

Esta sealizacion nos indica: En el tiempo 2,644 la extensin configurada con la direccin IP 192.168.100.240 enva una peticin INVITE que se encuentra bajo la direccin IP 109.168.100.243 A esta peticin el servidor responde que su autentificacin no fue correcta. En el tiempo 2,646 el usuario 192.168.100.240 confirma que ha recibido la notificacin por parte del servidor. En el tiempo 2,649 el usuario registrado bajo la direccin IP192.168.100.240 con el puerto: 57722 indica al servidor que desea volver a intentar una invitacin a la direccin IP 192.168.100.243 En el tiempo 2,650 el servidor enva la peticin al usuario solicitado (192.168.100.243) En el tiempo 2,756 el usuario registrado bajo la direccin IP 192.168.100.243 con puerto: 7460 indica al servidor 192.168.100.249 que ha recibido la solicitud y que la est procesando. En el tiempo 2,857 el usuario 192.168.100.243 con puerto: 7460 enva un 180 como seal de respuesta tomado por el servidor ubicado en la direccin IP 192.168.100.249. En el tiempo 2,858 el servidor ubicado en la direccin IP 192.168.100.249 retorna con un ring al usuario (192.168.100.240) quien realiz la peticin. En el tiempo 4,135 el usuario informa lo que ha recibido esta informacin es tomada por el servidor (192.168.100.249) En el tiempo 4,167 el usuario (192.168.100.243) acepta la invitacin la cual es tomada por el servidor (192.168.100.249) quien solicita le confirme que desea aceptar la solicitud, de esta manera comunica al usuario (192.168.100.240) que la peticin ha sido aceptada. En el tiempo 4,183 a 4,337 existe una sesin multimedia donde hay transmisin de datos utilizando el codec G711u, bajo cierta sincronizacin.

3.4.2. FUNCIONALIDADES H323 El protocol H323 y su excelente integracion con IAX2, permite que sus comunicaciones en tiempo real sean de tipo UDP y esto converge a que en algunas instancias se presenten algunas perdidas de paquetes de sealizacion, que no representan problemas graves en la transmission de las comunicaciones, pero permiten obtener ganacia en el consume de ancho de banda y la sencillez de su sealizacion.

50

En la siguiente grafica se encuentra que el campo Pb tiene un carcter X, el cual indica que en el transcurso del envo de paquetes de la direccin ip 192.168.100.243 a la direccin ip 192.168.100.249 ocurri un error en marcacin de tiempo, por parte de

wireshark, es decir, que en el momento de transmisin del paquete wireshark no pudo tomar el tiempo correcto. Sin embargo, esto no influyo en el flujo normal de la llamada, ya que esta fue completada en su total, lo cual se confirma en el campo Lost, en donde se reporta que represento un 0% de paquetes perdidos durante la llamada.

Dentro del anlisis del campo Pb, se encuentra que el paquete que present error fue el paquete N. 66 enviado por la direccin Ip 192.168.100.243 (Extensin 9000) a la direccin Ip 192.168.100.249 (Servidor Asterisk). Sin embargo, esto no influye en la transmisin de paquetes. De los 2.057 paquetes que fueron transmitidos durante la llamada, 1.020 corresponden a la extensin llamante 8000 con una participacin del 49,59% sobre el total de los paquetes, mientras que la extensin llamada 9000 tuvo una participacin de 1.037 paquetes, con una participacin del 50.41%.

Src IP addr Dest IP addr SSRC Payload 192.168.100.243 192.168.100.249 0xA3F435B GSM 06.10 192.168.100.249 192.168.100.243 0x7CDBB9D1 GSM 06.10

RTP Packets Lost 502 0 (0.0%) 488 0 (0.0%)

Max Delta (ms) Max Jitter (ms) Mean Jitter (ms) Pb? 28.99 4.24 3.10 X 34.44 6.19 0.79

Tabla 7. Estadstica para protocolo RTP prueba llamada IAX2 a H.323

3.4.3. CONSOLIDADO DE FUNCIONALIDADES H323 Los consolidados generals de pruebas obtenidos durante las llamadas entre extensiones que tienen configurado el protocolo H.323, cada una de las direcciones IP de las extensions, envi un promedio de 820 paquetes durante la llamada. Durante la llamada realizada de una extensin H.323 a una extensin IAX2 , se observa que dentro del proceso de llamada, la extensin H.323 enva un mayor nmero de paquetes para mantener el proceso de llamada que la extensin 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 ms largo en la prueba de H.323 a IAX2, el

51

tiempo utilizado para el envo de paquetes es mucho menor cuando se realiza una llamada de H.323 a IAX2, tal cual lo soporta el resultado de la transmisin 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 extensin configurada bajo el protocolo H.323 que realiza llamada a IAX2, es la extensin que transmite el mayor nmero de paquetes durante la llamada.

Paquetes tiempo entre la primera y ultimo paquete (seg) Prom. Paquetes por segundo (bytes) Prom. Tamao de Paquetes Bytes Prom. Bytes por segundo Prom. Mbits por segundo

llamada de extensin H.323 a protocolos H.323 IAX2 1641 4306 8,762 35,96 187,291 119,743 89,513 83,661 146891 360246 16765,037 10017,865 0,134 0,08

llamada a extensin H.323 de protocolos sip a h.323 iax2 a h.323 2548 2057 16,320 18,331 156,994 112,212 152,092 84,482 387,531 173780 23877,528 9479,924 0,191 0,076

Tabla 8. Estadstica consolidada de H323, IAX, SIP e IAX

52

CAPITULO 4 CONCLUSIONES Y RECOMENDACIONES

Despues de haber obtenido todo el grupo de pruebas y resultados de cada uno de los subgrupos de investigacion, se concluye que Asterisk representa una herramienta muy poderosa que ofrece un alto grado de funcionalidad y escalabilidad en las soluciones de integracion de voz y datos, ajustndose apropiadamente a los requerimientos que se necesiten. Adicionalmente como valor agregado, posee una dependencia directa de los recursos de red, sistema operativo y de la configuracin en hardware de la PC en donde se instale, ya que si se requiere para dar soluciones en comunicacin en grandes empresas que abarquen ms de 1000 usuarios ser distinto a otra que tan solo posea 10 usuarios.

Para esto, no se debe olvidar que en ambitos diferentes, ya sea para pequeas, medianas o grandes empresas se debe ajustar tanto el sistema operative, como el hardware para que Asterisk funcione correctamente y la arquitectura no presente problemas de retard, eco o un volume alto de perdida de datos.

Por otro lado los factores que determinaron sus incovenientes fueron: Su sensibilidad a posibles fallos de software y perdida de datos, esecificamente cuando se integran los protocolos de sealizacion como H323 e IAX. Susceptible a fallos de seguridad, determinando riesgos de vulnerabilidad como hackeos y virus. Si las personas encargadas de la administracion de asterisk, no tienen buen control de las politicas de trafico, asterisk puede consumir un elevado consumo de ancho de banda, minimizando la capacidad de integrar otras arquitecturas de datos.

Para los estndares IAX2 y H323, se tienen grandes diferencias en cuanto el envi de paquetes, tamaos de tramas, forma de realizar la sealizacin y empaquetamiento de datos El estndar H323 es mucho ms robusto que el IAX2, ya que est diseado para dar calidad en video conferencias, mientras que el IAX2 est diseado para otorgar velocidad y mayor uso de los recursos de banda ancha,

53

Los protocolos ofrecen una configuracin propia para que se ajuste a las condiciones de red y usuarios entre las que se encuentra la configuracin de cdec y otros comportamientos propios de cada estndar, pero ms all de esto, el asegurar la calidad de las llamadas depende tambin del comportamiento de cada softphone, ya que Asterisk no posee uno propio, que asegure su buena ejecucin.

El que una solucin de comunicaciones funcione o no, dentro de una organizacin depende de la buena seleccin. Para que al momento de escoger el protocolo para realizar las comunicaciones, se escoja por que las necesidades de la organizacin van acordes con los objetivos de diseo del protocolo.

54

REFERENCIAS

A. Libros
[1]. Alberto Escudero Pascual. VoIP para el desarrollo Una gua para crear una infraestructura de voz en regiones en desarrollo Edo. Alfaomega RA-MA Grupo Editores. [2]. Cisco System, integracin de redes de voz y datos. ISBN- 84-283-2820-X [3]. Daniel Collins. Carrier Grade Voice Over IP. McGraw-Hill Professional Publishing, Septiembre 2000 [4]. Bill Douskalis,IP Telephony The integration of robust VoIP Services. Editorial Prentice Hall, Diciembre 1999 [5]. Syngress Media, Elliot Lewis, Syngress Media, Matt Campisi y Elliott Lewis, IP Telephony. Editoral McGraw-Hill, 1998 [6]. Collin Perkins. RTP: Audio and Video Fort he Internet.Editorial McGraw-Hill telecommunication. [7]. Alan B. Jonhston. SIP: Understanding the Session Initiation Protocol, Second Edition (Hardcover).Editorial McGraw-Hill telecommunication. [8]. Henry Sinnreich. Alab B. Jonhston. Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol.Editorial Wiley. Segunda Edicion 2007 [9]. Bill Douskails. IP Telephony: The Integration of Robust VolP Services (HewlettPackard Professional Books).Ao 2006 [10]. Walter Goralski. Matthew C. Kolon. IP Telephony. McGraw-Hill Professional Publishing, Agosto 1998

B. Publicaciones peridicas
[11] G. Liu, K. Y. Lee, and H. F. Jordan, Asterisk The Future of Telephony. IEEE Transactions on Telephony IP, vol. 46, pp. 695-701, June 2005.

C. Tesis de Magister
[12] Maybelline Reza Robles, VOZ SOBRE IP: Anlisis del servicio Instalado en la Facultad de Telemtica. Universidad de Colima, Facultad de Telemtica, Junio 2001.

D. Tutoriales o Libros Electrnicos

[13]. Download The Future of Telephony Asterisk. http://www.cyberciti.biz/tips/downloadasterisk-howto-tutorial-book.html (Page On line).

E. Entrevista (Comunicacin verbal Privada)

Dr. Juan David Abreo. Director General de Tecnologa. Proyecto Interconexin WAN TELEFONIA IP. SENA. Bogot. Colombia.

55