Voz dobre IP

TESINA DE TITULACIN. PRINCIPIO Y FUNCIONAMIENTO DE VoIP correo del profesor: primitivo_reyes@yahoo.com.mx ALUMNOS: DOMINGUEZ PERES ULISES HERNANDEZ GRAJALES RAUL

Voz dobre IP C O N T E N I DO CAPITULO I.- Analoga de la Telefona IP vs Telefona tradicional. 1.1 Telefona tradicional. 1.2 Arquitectura de una central telefnica. 1.3 Procesamiento de llamadas. 1.4 Conexin entre centrales. 1.5 Ruteo, Sealizacin y Protocolos. 1.6 Telefona IP. 1.7 Ancho de banda necesario. 1.8 Calidad en la transmisin de la voz. 1.9 Estndares. 1.10 1.11 Aplicaciones. Ventajas e inconvenientes de los servicios IP.

CAPITULO 2.- Protocolos para multimedia. 2.1 Protocolo H.323. 2.2 Descripcin del sistema. 2.3 Caractersticas del terminal. 2.4 Elementos terminales en la recomendacin H.323. 2.4.1 Interface LAN. 2.4.2 Codificador de video. 2.4.3 Codificador de Audio. 2.4.4 canal de datos. 2.4.5 Canal de datos T.120. 2.4.6 Funcin de control H.245. 2.5 Capacidades de intercambio. 2.6 sealizacin del canal lgico. 2.7 Caractersticas del Gateway 2.8 Caractersticas del Gatekeeper. 2.9 Importancia del estndar H.323. 2

Voz dobre IP 2.10 H.323 perspectiva histrica. 2.11 Establecimiento de llamadas. CAPITULO 3.- Telefona IP. 3.1 Seleccin para implementar telefona IP. 3.2 Componentes de la telefona IP. 3.2.1 Call Manager. 3.2.2 La plataforma Call Manager. 3.3 Protocolos de la telefona IP. 3.3.1 SSP. 3.3.2 H.323. 3.3.3 MGCP. 3.3.4 SMDI 3.4 Clustering. 3.5 Telfonos IP. 3.6 Gateways. 3.7 Introduccin al video. 3.8 Componentes de video. 3.8.1 Gateway. 3.8.2 Gatekeeper. 3.8.3 Unidades de control multipunto. 3.8.4 Adaptadores de video. 3.8.5 Dispositivos extremo. 3.9 Mejorar la infraestructura de red. 3.10 Enrutadores para una red convergente. 3.11 Interfaces de voz analgica. 3.11.1 FXS. 3.11.2 FXO. 3.12 Interfaces de voz digital. 3.13 Encolados para voz y video.

Voz dobre IP 3.14 Introduccin a los Gateways. 3.15 capacidad de los protocolos de los Gateways. 3.16 Eleccin de un Gateway de voz. 3.17 Gatekeepers. 3.18 Funciones del Gatekeeper. 3.18.1 Funciones requeridas. CAPITULO 4.- PROTOCOLO RSVP Y PROTOCOLO SIP. 4.1 Qu es el protocolo RSVP. 4.2 Cmo trabaja el protocolo RSVP. 4.3 SIP Protocolo Inicial de Sesion 4.4 Funcionalidad de SIP 4.5 Operacin de SIP 4.6 Direccionamiento SIP 4.7 Establecer un sevdior SIP 4.8 Transaccion SIP 4.9 Invitacion SIP 4.10 Localizar a un usuario 4.11 Propiedades de protocolo 4.11.1 Estado minimo 4.11.2 Capas de protocolo Inferiores Neutrales 4.11.3 Base de Texto 4.11.4 SIP URL 4.12 Metodos 4.12.1 Metodo INVITE

Voz dobre IP

PRINCIPIO Y FUNCIONAMIENTO DE VoIP Introduccin La convergencia de las redes de telecomunicaciones actuales pretende encontrar la tecnologa que permita la transmisin de voz y datos sobre la misma lnea. Esto ha obligado a establecer modelos o sistemas que permita empaquetar la voz para que pueda ser transmitida en la lnea de datos. Tomando en cuenta que Internet es la Red de Redes, desarrollar una tecnologa de mbito mundial nos dirige al protocolo IP (Internet Protocol) y a encontrar el mtodo que nos permita transmitir voz sobre IP; la solucin a este problema nos lleva a VoIP (Voice Over Internet Protocol). Esta tecnologa tuvo sus inicios con la empresa VocalTec en el ao 1995 que con su producto Internet Phone dio las posibilidades reales de establecimiento de llamadas telefnicas de PC a PC con la ayuda de un software en la PC y como medio de transmisin, la Internet. En el ao de 1996 se dan las primeras experiencias de establecimientos de llamadas de PC a telfono y de telfono a telfono. A partir de 1997 aparecen nuevos dispositivos y mtodos que nos llevan hoy en da a mantener el trmino XoIP. Este acrnimo X, significa cualquier contenido susceptible a ser transmitido por una red, (X = datos, Voz, Fax, Multimedia, etc.). Cuando hacemos una llamada telefnica por IP, nuestra voz se digitaliza, se comprime y se enva en paquetes de datos IP. Estos paquetes se envan a travs de Internet a la persona con la que estamos hablando. Cuando alcanza su destino son ensamblados de nuevo, descomprimidos y convertidos en la seal de voz original.

Voz dobre IP

En el captulo uno, se realiza una analoga de la telefona convencional con la telefona IP, as como sus ventajas y desventajas. En el captulo dos, se explica los protocolos para transmisin de datos multimedia, H323, H225, H245 y codificacin de voz y audio. En el captulo tres, se profundiza el funcionamiento de VoIP, sus componentes, Gatekeeper y Gateway. En el captulo cuatro, se explica la importancia del protocolo RSVP y el protocolo SIP para garantizar la calidad de servicio dentro de una red de VoIP.

En general, en esta tesina abordamos el funcionamiento y los componentes de una red de voz sobre IP, caractersticas y protocolos.

Voz dobre IP

CAPITULO I.- Analoga de la Telefona IP vs Telefona tradicional.

Voz sobre IP es transmitir Voz utilizando IP. Si bien es una tecnologa novedosa, tiene muchas caractersticas similares y otras diferentes a las de la telefona tradicional. Por eso, a continuacin se explica brevemente el esquema de una red telefnica tradicional, y luego las coincidencias y diferencias con la tecnologa de VO/IP, para poder hacer una buena evaluacin de las ventajas y desventajas.

Telefona Tradicional.

El servicio telefnico es, junto con la red elctrica, uno de los ms confiables que conocemos y usamos, ya que todo es muy redundante y est pensado para funcionar siempre. Una central telefnica esta diseada para minimizar los tiempos de interrupcin del servicio.

Es una tecnologa en que la interfaz es muy importante, la gente la conoce, espera que cuando levanta el telfono se escuche el tono, y si no es el mismo que el que esperaba escuchar, molesta; adems es muy universal y difundida. Todo esto se tiene en cuenta a la hora de prestar el servicio telefnico.

Voz dobre IP

Arquitectura de una central telefnica. Todos tenemos un telfono en nuestra casa. En general, sabemos que el cable del telfono tiene un conector (RJ-11) parecida a la del cable de red, y que adentro tiene dos cables de cobre, al que se denomina par telefnico. Ese par telefnico es el que va hasta la central telefnica, a una placa que se la suele denominar placa de abonado. Es la placa que controla nuestra lnea. En realidad, puede controlar muchas lneas, no una sola, y tiene una densidad de puertos que depende del fabricante, ronda entre los 8 y 16 abonados (a veces ms, a veces menos). El valor exacto depende del equipo en particular. La central telefnica es un conjunto de equipos relacionados. Todo este conjunto forma un equipo muy grande que puede llegar a ocupar varias habitaciones. Como mencionamos, las centrales telefnicas suelen estar diseadas para tener una muy alta disponibilidad (se suele decir que son carrier class, dado que se dice estn disponibles el 99,999% del tiempo, que representa alrededor de 5 minutos al ao de interrupcin de servicio). Para lograr este objetivo, cuentan con redundancia en mltiples niveles (procesadores, enlaces, etc.); y en general se conectan a un sistema de energa interrumpida, que tiene un buen nmero de bateras que se conectan a un grupo electrgeno que se activa cuando se corta la energa. Procesamiento de Llamadas Hasta la central, la voz va en forma analgica. Actualmente ya no existen centrales analgicas, todo lo que hay desde que llega la seal a la central y sale de la otra central hacia el otro abonado, es digital.

Voz dobre IP La placa de abonado es la que se encarga de hacer la conversin de una seal analgica a una digital y viceversa. La seal se convierte a un PCM de 64kbps, que es una seal digital sin prdida de informacin y sin compresin, es el formato que se est utilizando desde prcticamente sus comienzos. Tambin es la placa de abonado la que decodifica los tonos de discado (DTMF). Es decir que, se utiliza el concepto de sealizacin en banda: comandar a la central utilizando la misma banda por la que se habla.

Conexin entre centrales La llamada que sale de nuestra central tiene que llegar hasta la central donde est la persona con la que queremos hablar. No hay doscientos millones de cables entre una y otra, sino que hay un enlace, el cual puede ser de diversos tipos. Este enlace se debe multiplexar para que todos los abonados de la central puedan hablar por telfono. Esta multiplexacin es la que hace una diferencia a la hora de la calidad del servicio para el usuario. El sistema de multiplexacin que utilizan las centrales telefnicas se llama TDM: Time Division Multiplex. Consiste en dividir el stream de datos en partes iguales de 64k (llamadas time-slots), de manera que los datos correspondientes al primer abonado van en el primer time-slot, los correspondientes al segundo en el segundo, y as sucesivamente. Suponiendo un enlace de 2 Mbps de ancho de banda, como se transmiten 64k, podra haber hasta 32 abonados hablando a la vez. Con esta multiplexacin en tiempo se separan y luego vuelven a unir los streams de voz que van de una central a otra, de manera transparente para el que lo est utilizando.

Voz dobre IP Lo bueno de esta tecnologa es que como se divide por un tiempo fijo, se puede garantizar el time-slot y saber que siempre lo que corresponde al primer abonado va en el primer time-slot y as sucesivamente. Una vez establecida la comunicacin, sea de ac a una cuadra o de ac a China, est garantizado el ancho de banda necesario para poder hablar sin interrupciones. En definitiva, TDM es una de las diferencias esenciales entre la telefona comn y la de voz sobre IP, permite tener una red predictiva y garantizar calidad.

Ruteo, sealizacin y protocolos. Otro tema importante es el "ruteo" entre centrales, es decir, cmo sabe la central del abonado con que central se tiene que conectar. Vamos a denominar sealizacin a la informacin relacionada con una llamada que se transmite entre dos equipos (la definicin en s es mas amplia, pero esto es en particular lo mas relevante para el caso). Podemos dividirla en dos grupos: la que refiere al abonado y las llamadas en s (levant, marc, cort), y otra parte entre las centrales (que se le caiga algo y le quiera avisar, etc). A travs de la sealizacin, la central puede ubicar a qu otra central tiene que llamar, a qu abonado dentro de esa central hay que llamar, saber que se cort la comunicacin, que dio ocupado, etc. Las centrales entre s se comunican utilizando diversos protocolos, los cuales generalmente son estndares pblicos, aunque en muchos casos las especificaciones no son fciles (o baratas) de conseguir. Los protocolos ms comunes son tres: R2, PRI y SS7.

10

Voz dobre IP El protocolo R2, es uno de los ms viejos y tiene muchas variantes

distintas, hay -incluso- una variante argentina, y pasa toda su informacin utilizando 4 bits. SS7 es, por otra parte, uno de los ms nuevos y complejos. Se necesita que las dos centrales que se estn queriendo comunicar puedan hablar un mismo protocolo, de manera que si se quieren intercomunicar dos centrales que no soportan los mismos protocolos, es necesario que utilicen una central intermedia que traduzca la informacin. Acerca del enlace por el cual se pasa tanto la sealizacin como la voz en s, existen muchsimos tipos. Los ms conocidos y comunes son E1 o E3 (europeos), con sus variantes T1 o T3 (utilizadas principalmente en los Estados Unidos). Son cables de cobre, muy parecidos al cable coaxial, que pueden ser de 75 o 120 ohms. El E1 tiene 2Mbps (32 canales de 64kbps), el E3 tiene 32Mbps (512 canales de 64kbps).

En muchos mbitos cuando se habla de este tipo de enlaces se le da importancia solo al ancho de banda; sin embargo en nuestro caso tambin nos interesa el nmero de times - slots en el cual se puede dividir. Sin embargo, no se pueden ocupar todos los canales para pasar todos los abonados. En necesario poder avisar que hay llamadas y ese tipo de informacin. Por ejemplo, en el caso de una E1 se suelen utilizar 30 canales para el paso de la voz, 1 para framing (el 0) y 1 para sealizacin (el 15). En el de framing se suele encontrar (entre otras cosas) el CRC de los otros 31 (aunque depende de la configuracin), de manera que si un determinado frame est mal, se le puede notar y actuar en consecuencia.

11

Voz dobre IP Telefona IP La telefona IP, necesita un elemento que se encargue de transformar las ondas de voz en datos digitales y que adems los divida en paquetes susceptibles de ser transmitidos haciendo uso del protocolo IP. Este elemento es conocido como Procesador de Seal Digital (DSP), el cual est ya disponible y utilizan los Telfonos IP o las propias Gateways o Pasarelas encargadas de transmitir los paquetes IP una vez paquetizada la voz. Cuando los paquetes alcanzan el Gateway de destino se produce el mismo proceso a travs del DSP pero a la inversa con lo cual el receptor podr recibir la seal analgica correspondiente a la voz del emisor. La transmisin de paquetes de voz segn la forma expuesta, es similar a la transmisin de un correo electrnico desde el origen hasta el destino. El problema es que en las transmisiones IP no est garantizado el xito, por lo cual si el correo no es legible o se "pierde" algn paquete, es necesario solicitar la retransmisin del mismo y su recuperacin es factible. Pero en el caso de la transmisin de voz esto no es as, ya que la necesidad de recibir los paquetes en un determinado orden, la necesidad de asegurar que no haya prdidas y de conseguir una tasa de transmisin mnima hacen prcticamente necesaria la implantacin de sistemas de Calidad de Servicio (QoS: Quality of Services). Estos sistemas suponen hoy en da el gran reto de la industria ya que garantizar "Quality of Service Over IP" supondr la inmediata implantacin de los sistemas de transmisin de voz. A modo de resumen el verdadero problema hoy en da es que la Telefona Conmutada establece circuitos virtuales dedicados entre el origen y el destino y ah la calidad es innegable y segura. Por el contrario la transmisin de voz sobre IP comparte el circuito y el ancho de banda con los datos y los paquetes pueden atravesar multitud de nodos antes de llegar a su destino lo que supone lgicas deficiencias en la transmisin de paquetes de voz. A continuacin se plantean otras cuestiones referentes a esta tecnologa y que tienen que ser obligatoriamente consideradas a la hora de llevar a cabo una 12

Voz dobre IP posible implantacin real de un sistema de telefona IP para uso comercial o profesional: Ancho de Banda Necesario Hasta hace muy poco tiempo el ancho de banda necesario para la transmisin de voz y vdeo en tiempo real era considerablemente elevado, lo que hacia imposible este tipo de comunicaciones sobre redes de datos que no garantizaran una calidad de servicio, como por ejemplo Internet o redes basadas en protocolo IP. Actualmente la voz que recibe un gateway es digitalizada y comprimida segn distintos algoritmos (GSM, G.723.1, G.711, G.729) los cuales se caracterizan por conseguir mayores ratios de compresin en detrimento del tiempo de latencia (tiempo necesario para descomprimir la voz para que pueda ser entendida de nuevo). Algunos de estos algoritmos consiguen comprimir los paquetes de voz en 8 Kbps aproximadamente. El protocolo IP aade al paquete de voz digitalizado y comprimido una serie de cabeceras para su correcto transporte a travs de la red, lo que hace que el ancho de banda necesario se incremente hasta unos 16 Kbps. Hay que considerar as mismo el parmetro denominado "supresin de silencio". Con este parmetro activado, se consigue que la transmisin de paquetes (uso de ancho de banda) se reduzca a las situaciones en que los agentes estn hablando. El resto del tiempo (cuando no existe voz a transmitir) se libera el ancho de banda. Considerando este aspecto, se puede afirmar que el tamao medio de un paquete de voz durante una conversacin es de 8 Kbps. Con todo lo anterior se puede afirmar que con un canal B de cualquier lnea RDSI (Red Digital de Servicios Integrados: 2 canales B y 1 canal D), cuyo ancho de banda es de 64 Kbps se puede realizar una comunicacin de 8 llamadas simultneas. Esta situacin suele coincidir con las dimensiones de cualquier central de una PYME (Pequea y Mediana Empresa). Esto viene a demostrar que 13

Voz dobre IP las necesidades de ancho de banda para este tipo de aplicaciones estn al alcance de prcticamente cualquier empresa. Calidad en la Transmisin de La Voz Referente a la calidad de la transmisin de la voz, todos los fabricantes e investigaciones hacen referencia a tres factores determinantes. Codificadores de Voz: influyen en la digitalizacin de la voz en paquetes de datos que
contienen voz y que sern transmitidos por la red IP, tambin influyen por el retardo necesario para la descompresin de esos paquetes voz, lo que imputa un retardo aadido a la comunicacin.

Cancelacin de Eco: requerimiento necesario para una comunicacin a travs de Telefona IP,
que elimina de forma automtica y en tiempo real posibles ecos, ya que si no lo hiciera hara inteligible la comunicacin.

Latencia: tiempo necesario para que la voz viaje de un extremo al otro, incluyen los tiempos
necesarios para la compresin, transmisin y descompresin. Este tiempo tiende a minimizarse pero jams podr ser suprimido. Actualmente los tiempos que se estn obteniendo de latencia giran alrededor de 120 ms.

Estndares Actualmente existen estndares que regulan este tipo de comunicaciones, estndares que provienen de organismos internacionales de estandarizacin como el ITU (International Telecommunication Union) que ha establecido unas normas para la interconexin de los distintos elementos que intervienen en una comunicacin sobre Telefona IP. El estndar que regula este tipo de comunicaciones es el H.323 de la ITU. Esta norma realmente es una serie de normas para la transmisin de datos multimedia (audio, vdeo y datos) sobre redes que no garantizan una calidad de servicio (redes IP).

14

Voz dobre IP Las funciones cubiertas por el H.323 son acerca del control de llamadas, uso de codificadores de voz y normas de otros organismos que especifican la transmisin en tiempo real de los paquetes de voz. El protocolo H.323 ha sido adoptado prcticamente por todas las empresas lderes en este sector como Netscape, Microsoft, Intel, Vocaltec. La adopcin de este estndar permite la interconexin de equipos y software de cualquier fabricante que lo haya adoptado. Por tanto es lgico deducir que en la actualidad cualquier empresa que quiera trabajar en servicios de VoIP debe adoptar este estndar en todos sus desarrollos. De esta manera se garantizar una perfecta integracin con plataformas hardware y software de distintos fabricantes cuyos productos sigan la misma norma.

Aplicaciones Con todo lo anteriormente descrito, se pueden poner en marcha una serie de aplicaciones que son de gran demanda que producen de forma inmediata un ahorro de costes muy significativo. Centros de llamadas (Call centers): Los centros de llamadas pueden usar la Telefona IP, mejorando la calidad de la informacin intercambiada en cada sesin. Por ejemplo un usuario podra navegar por informacin on-line, antes de realizar la consulta a un operador. Una vez en comunicacin con el operador, se podra trabajar con un documento compartido a travs de la pantalla. De esta forma se consigue sistemas de una gran calidad en el servicio a ofrecer, adems de reducir de forma considerable el costo de lneas telefnicas y de Distribuidores Automticos de Llamadas (ACD).

15

Voz dobre IP Redes Privadas virtuales de Voz: Esta aplicacin consiste en la interconexin de las centrales telefnicas a travs de la red IP corporativa, de manera que se puede realizar una llamada desde una extensin de la oficina A otra extensin de la oficina B a travs de la red de datos de la empresa, producindose esta llamada de forma gratuita ya que se aprovecha la infraestructura de datos ya existente. Un ejemplo claro de este servicio seran los bancos y su red de oficinas. Centros de llamadas por el WEB: Si una compaa tiene su informacin disponible en un Web en Internet, los usuarios que visitan este Web podran no solo visualizar la informacin que esta compaa les ofrece, sino que podra establecer una comunicacin con una persona del departamento de ventas sin necesidad de cortar la conexin. De esta manera el operador de ventas cuando atienda la llamada tendr en su pantalla la misma informacin que esta viendo el usuario. Esta aplicacin tiene las siguientes ventajas: Al ser la llamada a travs de Internet, para el usuario no tiene costo adicional, aprovecha la llamada telefnica que tena establecida para la comunicacin de datos, para mantener tambin la comunicacin de voz. El usuario puede mantenerse on-line mientras habla con un operador de ventas. El cliente trata con operadores humanos, que le podrn asesorar, esta caracterstica mejorar sin lugar a duda el resultado de un sistema de comercio electrnico. El operador puede cerrar la venta de manera ms fcil ya que el usuario es bastante precavido para dar los datos de su tarjeta de crdito en una pagina Web por temas de seguridad que todos conocen, sin embargo no tendr ningn

16

Voz dobre IP inconveniente de dar esos datos verbalmente al operador de ventas, teniendo el usuario plena garanta de que sus datos estn a salvo. Aplicaciones de FAX: Al igual que se hace con la voz, cabe la posibilidad de realizar transmisiones de FAX sobre redes de Telefona IP, consiguiendo de esta manera reducir de forma significativa los costos de una empresa en transmisin de fax. En este caso no es necesario para el usuario que recibe el fax de disponer de equipos especiales ya que los faxes se seguirn recibiendo a travs de una mquina de fax convencional. Una aplicacin tpica en este tema es el envo masivo de fax, ya que el usuario slo enviar una copia del fax que desea enviar, as como la lista de nmeros telefnicos de destino y el sistema se encargar de realizar todos los envos enrutando los faxes al punto desde donde la llamada de destino es ms econmica. Multiconferencia: La telefona IP permite la conexin de 3 o ms usuarios simultneamente compartiendo las conversaciones de voz o incluso documentos sobre el que todos los miembros de la multiconferencia pueden participar en la revisin, esto resulta de gran utilidad para empresas que realicen reuniones virtuales, con los consiguientes ahorros de gastos que supone el desplazamiento de personas. Ventajas e Inconvenientes de los Servicios IP: En esta seccin se analizan por separado tanto las ventajas como los inconvenientes del uso de los servicios IP en los mbitos ms comunes. As mismo se analizan los aspectos ms relevantes que impiden una rpida implantacin de estos servicios:

17

Voz dobre IP Ventajas: Los servicios de VoIP presentan una multitud de ventajas en todos los aspectos. Su enumeracin y explicacin debe de realizarse de forma sencilla y transparente al objeto de hacer llegar a los posibles usuarios la bondad de su implantacin en un futuro no muy lejano. Hay que evitar la confusin y prematuro rechazo ante algo que se plantea como la solucin universal y que no se termina de entender. En esta lnea destacan tres grandes bloques: Entorno empresarial: Amplia reduccin en los costos de la factura telefnica. Los costos de todo tipo de llamadas se equipararn al de una llamada local de forma que la reduccin en los costos del trfico de voz ser a todas luces muy importante. Nuevas posibilidades de marketing directo y potenciacin del servicio de atencin al cliente. Podrn implantar la filosofa "Push 2 Talk" que consiste en un icono situado en una pgina Web a travs del cual un navegante podr dialogar con personal especializado de la compaa mientras contina navegando por la red. Potenciacin del tele - trabajo y de los tele - trabajadores. Con una nica conexin se podr acceder a aplicaciones corporativas, al correo vocal, atender llamadas o buscar informacin sobre nuevos proyectos. Usuarios Finales: En este momento el usuario final que ocupe su lnea de telfono domstica para transmisin de datos no puede recibir comunicaciones de voz al estar la lnea ocupada. Los nuevos servicios de VoIP no slo le permitirn atender llamadas de forma simultnea sino que adems podr conocer quien le llama y de esa forma admitir y rechazar llamadas e incluso desviarlas.

18

Voz dobre IP Proveedores de Servicios: XoIP ser su nuevo argumento comercial. X supone poder ofrecer voz, datos, fax o cualquier servicio susceptible de ser transmitido por una red IP. El ejemplo ms claro es la nueva vertiente estadounidense denominada Internet Telephony Service Providers (ITSPs) quienes ya ofrecen todo tipo de servicios a travs de redes IP. Inconvenientes Si todo est tan claro, si ya existe la tecnologa, si los estndares estn validados por organismos internacionales (caso del H.323 definido por la ITU), si la ley en principio no presenta inconvenientes y si adems las consultoras internacionales presentan esta solucin como la verdadera alternativa de negocio en el ao 2005, la lgica hace pensar que la implantacin de XoIP se realizar de forma inmediata. Pero el verdadero problema se resume con tres letras "QoS". Quality of Service: garantizar calidad de servicio en base a retardos y ancho de banda disponible en una red IP no es realmente posible sobre una red IP. Una vez digitalizada la voz y paquetizada, se enva al canal de transmisin y aqu no existen soluciones que nos garanticen o permitan establecer anchos de banda, orden de paquetes y retrasos asumibles en su transmisin. Las posibles soluciones pasan por diferenciar los paquetes de voz de los paquetes de datos, priorizar la transmisin de los paquetes de voz y hacer que los retrasos aadidos a la transmisin de los paquetes no superen en ningn caso los 150 milisegundos (recomendacin de la ITU). Distintos organismos y fabricantes empiezan a definir soluciones y estndares, pero su aplicacin o implantacin no se considera posible en un mnimo de 2 a 3 aos. Las lneas de trabajo actuales y las soluciones hasta el momento desarrolladas, se basan en:

19

Voz dobre IP Anchos de Banda: En la tabla 1 se muestra la relacin existente entre los distintos algoritmos de compresin de voz utilizados y el ancho de banda requerido por los mismos:

VoCodecs

Ancho de Banda (BW)

G.711 PCM G.726 ADPCM

64 kbps 16, 24, 32, 40 kbps

G.727 E-ADPCM 16, 24, 32, 40 kbps G.729 ACELP G.728 LD-CELP G.723.1 CELP 16 kbps 6.3 / 5.3 kbps CS- 8 kbps

Tabla 1: Ancho de Banda requerido por los VoCodecs actuales Retardo: Una vez establecidos los retardos de procesado, retardos de trnsito y el retardo de procesado la conversacin se considera aceptable por debajo de los 150 ms. Eco: El eco es debido a una reflexin, habitualmente se debe a un desajuste de impedancias. 20

Voz dobre IP

Obtener QoS: Las lneas de trabajo actuales de cara a conseguir Calidad de Servicio en una Transmisin IP, estn basadas en: a) Supresin de silencios y VAD (voice activity detection): Establecer diferencia entre habla y silencio, no transmitir paquetes de silencio y generacin de silencios al otro extremo. b) Compresin de cabeceras: Definido por los estndares RTP/RTCP. RTP: Comprime cabeceras de 40 bytes a 2 - 4 la mayor parte del tiempo sin resolver reserva de recursos o calidad de servicio garantizada TCP (Real-Time Control Protocol): Proporciona realimentacin sobre la calidad c) Reserva de Ancho de Banda: Implantacin del estndar RSVP (Protocolo de Reserva de Recursos) de la IETF (Internet Engineering Task Force). RSVP incorpora reserva de ancho de banda y retardo adems de establecer una lista de acceso dinmica de extremo a extremo. Sus principales deficiencias se establecen en su defectuoso crecimiento (solucin vlida en redes pequeas) y en su deficiente autorizacin y autentificacin. Adems hay que tener en cuenta que las actuales infraestructuras no la tienen en cuenta.

d) Priorizar: Existen diferentes tendencias tales como: 1.- CQ (Custom Queuing): Asignacin de un porcentaje del ancho de banda disponible. 2.- PQ: Establecer prioridad en las colas de envo.

21

Voz dobre IP 3.- WFQ (Weight Fair Queuing): Asignar prioridad al trfico de menos carga. 4.- DiffServ: Definido en borrador por la IETF, evita tablas en routers intermedios y establece decisiones de rutas por paquete. e) Control de Congestin: uso del protocolo RED (Random Early Discard), Tcnica que fuerza descartes aleatorios. f) Uso de Ipv6: mayor espacio de direccionamiento y posibilidad de Ipv6 y Tunneling.

22

Voz dobre IP

CAPITULO 2.- PROTOCOLOS PARA MULTIMEDIA

PROTOCOLO H.323 Esta recomendacin, cubre los requerimientos tcnicos para servicios de telefona visual de banda estrecha, en situaciones donde el camino de transmisin incluye ms de una LAN, la cual no puede garantizar una calidad de servicio (QoS). Ejemplos de estos tipos de LAN son:

-Ethernet (IEEE 802.3) -Fast Ethernet (IEEE 802.10) -FDDI (en modo de servicio donde se garantiza la calidad) -Token Ring (IEEE 802.5) Las terminales H.323 pueden ser usadas en configuracin multipunto y se pueden interconectar con terminales H.320 en B-ISDN, terminales H.321 en NISDN, terminales H.322 inalmbricas (wireless). Esta recomendacin describe los componentes bsicos de un sistema H.323, esto incluye Terminales Gateways, Gatekeepers, Controladores Multipunto, multiprocesadores y Unidades de Control Multipunto (MCU). El control de mensajes y procedimientos dentro de esta recomendacin define la comunicacin de todos los componentes antes descritos. en LANs donde se garantiza la calidad del servicio, terminales en GSTN (General Switched Telephone Network) y conexiones

23

Voz dobre IP Con el estndar H.323, fabricantes, proveedores de servicios e integradores de sistemas, disponen de las herramientas necesarias para construir una solucin completa y unificada: un conjunto de tecnologas capaces de soportar diversas aplicaciones de videoconferencia.

Scope of H.323 H.323 Terminal Non-Guaranteed QoS LAN (Note) H.323 Gatekeeper H.323 Gateway H.323 Terminal H.323 Terminal H.323 MCU

GSTN

Guaranteed

QOS LAN

N-ISDN

B-ISDN

H.310 terminal operating in H.321 mode V.70 Terminal H.324 Terminal Speech Terminal H.322 Terminal Speech Terminal H.320 Terminal H.321 Terminal H.321 Terminal

Note: A gateway may support one or more of the GSTN, N-ISDN and/or B-ISDN connections.

Como se puede ver este estndar define un amplio conjunto de caractersticas y funciones. Algunas son necesarias y otras opcionales, se abordara mas adelante

24

Voz dobre IP cada elemento antes mencionado con el objetivo de comprender el funcionamiento e importancia del H.323 dentro de la tecnologa de VoIP.

DESCRIPCION DEL SISTEMA Los componentes de un telfono visual se comunican a travs de la transmisin de cadenas de informacin. Estas cadenas de informacin son clasificadas en video, audio, datos, control de comunicacin y control de llamada como sigue: Las seales de audio contienen voz codificada y digitalizada a fin de reducir el promedio de la tasa de transmisin de las seales de audio. Las seales de video contienen movimiento en tiempo real codificado y digitalizado. La seal de video esta acompaada por un control de seal de video. Las seales de datos incluyen fotos, documentos, archivos de computadora y otras cadenas de datos. Las seales de control de comunicaciones son usadas para administrar el intercambio, apertura y cierre de los canales lgicos, el modo de control y otras funciones son parte del control de comunicaciones. Las seales de control de llamada son usadas para establecer, terminar y otras funciones bsicas de control de llamada Las caractersticas de las cadenas de informacin mencionadas anteriormente son descritas en la norma H.225 que se vera mas adelante.

25

Voz dobre IP CARACTERISTICAS DEL TERMINAL Un ejemplo de una Terminal H.323 es mostrada en la figura 2.XXXX. El diagrama muestra la interfaces del equipo de usuario, codificadores de video (video codec), codificadores de audio (audio codec), equipo telemtico, recomendacin H.225, funciones del sistema de control y las interfaces a la LAN. Todas las terminales H.323 deben tener una Unidad de Control del Sistema, cumplir la recomendacin H.225, una interfase de red y una unidad de codificacin de audio. La unidad de codificador de video y las aplicaciones de datos de usuario son opcionales.

Scope of Recommendation H.323 Video I/O equipment Video Codec H.261, H.263 Receive Path Delay Audio I/O equipment Audio Codec G.711, G.722, G.723, G.728, G.729 H.225.0 Layer Local Area Network Interface

User Data Applications T.120, etc. System Control H.245 Control System Control User Interface Call Control H.225.0 RAS Control H.225.0

ELEMENTOS TERMINALES EN LA RECOMENDACIN H.323

26

Voz dobre IP Los siguientes elementos estn dentro de la recomendacin H.323 y estn por lo tanto sujetos a estandarizacin: El codificador de video (Video Codec) basado en la recomendacin (H.261) como su nombre lo indica, codifica el video de alguna fuente de video como puede ser una cmara de video, para la transmisin y decodificacin posterior del video recibido, el cual ser desplegado por ejemplo en un monitor. El codificador de audio (Audio Codec) basado en la recomendacin (G.711) como su nombre lo indica, codifica la seal de audio de un micrfono para la transmisin y decodificacin del audio recibido el cual encontrara como salida un altavoz. El canal de datos soporta aplicaciones telemticas tales como pizarrones electrnicos, transferencia de imgenes, intercambio de archivos, accesos a base de datos, conferencias audio grficas, etc. La estandarizacin de la aplicacin de datos para conferencia audio grafica en tiempo real esta basada en la recomendacin T.120 La Unidad de Control del Sistema (recomendacin H.245, H.225) provee sealizacin para la propia operacin de la terminal H.323. Esta provee control de llamada, capacidad de intercambio, sealizacin de rdenes e indicaciones as como mensajes para apertura y descripcin completa del contenido de los canales lgicos. Recomendacin H.225 define el formato del video, audio, datos y cadenas de control dentro de mensajes para la interfaz de salida de la red, los cuales han entrado por la interfase de red. Adems esto mejora el desempeo del entramado lgico, numero de secuencia, deteccin de errores y correccin apropiada para cada tipo de medio. INTERFASE LAN

27

Voz dobre IP La interfase LAN es una implementacin especfica y esta fuera del mbito de esta recomendacin, sin embargo la interfase LAN podra proveer los servicios descritos en la recomendacin H.225. Esto incluye lo siguiente: Un servicio extremo a extremo (end-to-end) confiable (TCP, SPX) es obligatorio para el canal de control (recomendacin H.245), canales de datos, y canal de sealizacin de llamada. Un servicio extremo a extremo (end-to-end) (Registration,Admisin,Status) Estos servicios descrito pueden ser duplex o simples, unicast o multicast dependiendo de la aplicacin, la capacidad de las terminales y la configuracin de la LAN. CODIFICADOR DE VIDEO (VIDEO CODEC) El codificador de video es opcional. Todas las terminales H.323 proveedoras de comunicacin de video deben ser capaces de codificar y decodificar video de acuerdo a la recomendacin H.261 QCIF. Opcionalmente, una terminal puede ser tambin capaz de codificar y decodificar video de acuerdo a las recomendaciones H.261 CFI o H.263 SQCIF, QCFI, CIF, 4CFI y 16CFI. Si una terminal soporta H.263 CIF o una resolucin ms alta, esta debe soportar tambin H.261 CIF. Los codificadores H.261 y H.263 en la LAN deben ser usados sin correccin de errores BCH y sin correccin de errores en trama. Otros codificadores de video y otros formatos de imagen pueden ser tambin usados va la negociacin de H.245. Ms de un canal de video puede ser transmitido o recibido, segn sea la negociacin establecida por el control de canal H.245. La terminal H.323 puede opcionalmente enviar mas de un canal de video al mismo tiempo, por ejemplo, transportar voz y despus una fuentes de video. La terminal H.323 puede opcionalmente recibir ms de un canal de video, no confiable es obligatorio para canales de audio, canales de video y canal RAS

28

Voz dobre IP por ejemplo, distribuida. La tasa de bits de video, el formato de imagen y las opciones del algoritmo que pueden ser aceptadas por el decodificador son definidos durante la capacidad de intercambio usando la recomendacin H.245. El codificador es libre de transmitir cualquier cosa que este dentro de las capacidades del decodificador. El decodificador debe tener la posibilidad de generar solicitudes va H.245 para un cierto modo, pero el codificador ignorara aquellas solicitudes si estas no estn en modo de prioridad alta. Los decodificadores, los cuales indican capacidad para un a opcin de algoritmo en particular, deben ser capaces tambin de aceptar tramas de bits de video, que no estn haciendo uso de esa opcin. Las terminales H.323 deben ser capaces de operar en tasas de bits de video asimtricas, tasas de trama y si ms de una resolucin de imagen es soportada, en resolucin de imgenes. Por ejemplo, esto permitir a una terminal CIF tener la capacidad de transmitir QCFI mientras esta recibiendo imgenes CIF. Cuando cada canal de video lgico es abierto, el mximo modo de operacin para ser usado en ese canal, se le describe al receptor en el mensaje OpenLogicalChannel. El mximo modo indicado incluye el formato mximo de imagen, opciones de algoritmo, mxima tasa de bits del codificador, etc. La cabecera dentro del canal lgico de video indica que modo es actualmente usado para cada imagen, dentro del estado mximo. Por ejemplo, un canal lgico de video abierto para formato CIF puede transmitir CIF, QCIF o imgenes SQCIF pero no 4CFI o 16CFI. para desplegar mltiples participantes en una multiconferencia

CODIFICADOR DE AUDIO (AUDIO CODEC) Todas las terminales H.323 deberan tener un codificador de audio (audio codec). Todas las terminales H.323 deben ser capaces de codificar y decodificar

29

Voz dobre IP voz de acuerdo a la recomendacin G.711. Todas las terminales opcionalmente pueden ser capaces de codificar y decodificar voz usando las recomendaciones G.722, G.728, G.729, MPEG 1 audio y G.723. El algoritmo de audio usado para la codificacin esta descrito en la recomendacin H.245. La Terminal H.323 debes ser capaz de una operacin asimtrica para todas las capacidades de audio, es decir debe poder la recomendacin G.728. La Terminal H.323 puede opcionalmente enviar ms de un canal de audio al mismo tiempo, por ejemplo; permitir dos lenguajes convenidos. Los paquetes de audio deben ser entregados a la capa de transporte trabajar a la hora de enviar informacin con la recomendacin G.711 y a la hora de recibir la informacin con

peridicamente en un intervalo determinado por la recomendacin del codificador de audio (audio codec) en uso (intervalo de trama de audio). La entrega de cada paquete de audio no debe tardar mas de 5 milisegundos despus de un completo intervalo mltiple de trama de audio, medida con respecto a la primer trama de audio que se entrega (retardo de audio jitter). Los codificadores de audio deben ser capaces de limitar mas su retardo de audio jitter usando el mximo parmetro de retardo jitter recomendado en la estructura de H.245 dentro de la capacidad de una terminal para colocar un mensaje, y los receptores opcionalmente pueden reducir su retardo de buffers jitter. NOTA: El punto de prueba para el mximo retardo jitter est en la entrada de la capa de transporte. CANAL DE DATOS Uno o ms canales de datos son opcionales: los canales de datos pueden ser unidireccionales o bidireccionales dependiendo de los requerimientos de la aplicacin de datos. 30

Voz dobre IP La recomendacin T.120 es por default la base de la interoperabilidad entre una terminal H.323 y otra terminal H.323 (H.324, H.320, H.310). Donde cualquier aplicacin opcional de datos es implementada usando una o mas de las recomendaciones de la Unin Internacional de Telecomunicaciones (ITU), las cuales pueden ser negociadas va la recomendacin H.245 el equivalente de la aplicacin T.120.

CANALES DE DATOS T.120 Hay 2 formas de establecer una conexin T.120 dentro del contexto de una llamada H.323. La primera es el establecimiento de la conexin T.120 durante una llamada H.323 como una parte inherente de la llamada, usando los procedimientos de la recomendacin H.245 para la apertura de los canales lgicos. La segunda es el establecimiento de la conexin T.120 previa al establecimiento de la llamada H.323. La capacidad de intercambio toma lugar y un canal lgico bidireccional debe ser abierto para la conexin T.120 de acuerdo al procedimiento normal de la recomendacin H.245 indicando que una nueva conexin deber ser creada como se describe a continuacin. La apertura de un canal lgico bidireccional para T.120 puede se iniciada por cualquiera de las dos entidades enviando el mensaje open Logical Channel y siguiendo el procedimiento del canal lgico bidireccional de la recomendacin H.245. Para abrir el canal lgico, la entidad que inicializa debe enviar un mensaje open Logical Channel indicando que un canal de datos T.120 ser abierto en los parmetros de canal lgico hacia delante (forward Logical Channel Parameters) as como en los parmetros de canal lgico hacia atrs (reverse Logical Channel Parameter).

31

Voz dobre IP El equipo origen puede decidir si incluir no una direccin de transporte en el mensaje open Logical Channel y si el equipo destino acepta este canal lgico, debe confirmar la apertura del canal usando el mensaje open Logical Channel Ack. En el mensaje open Logical Channel Ack, el equipo destino debe incluir una direccin de transporte para ser usada para establecer la conexin T.120 si el equipo origen no le ha proporcionado ninguna direccin. De lo contrario el equipo destino no podr establecer la conexin. En ambos casos, la direccin de transporte para la conexin T.120 debe ser llevada en un parmetro de pila (stack) separado. La entidad que transmite la direccin de transporte debe estar preparada para aceptar la conexin T.120. La entidad receptora de la direccin de transporte debe iniciar el establecimiento de la conexin T.120 usando la previa direccin de transporte recibida. En ambos mensajes open Logical Channel y open Logical Channel Ack, el parmetro associate Conference debe ser puesto a Falso. NOTA: La operacin completa de la recomendacin T.120 despus del completo establecimiento de la conexin esta fuera del alcance de este trabajo, se recomienda consultar la bibliografa. En el caso donde la conexin T.120 es establecida primero, la llamada H.323 es realizada siguiendo el procedimiento normal. La capacidad de intercambio toma lugar y es deseable asociar la conexin T.120 con la llamada H.323. Los procedimientos de la recomendacin H.245 suelen ser usados para abrir un canal lgico bidireccional para la recomendacin T.120 como se describe a continuacin: La apertura de un canal lgico bidireccional para T.120 puede ser iniciada por ambas entidades, enviando el mensaje open Logical Channel y despus siguiendo los procedimientos para un canal lgico bidireccional de la recomendacin H.245. El que originad el establecimiento de la conexin debe 32

Voz dobre IP incluir informacin de la identificacin para la ya existente conexin en el mensaje open Logical Channel para indicar al destino cual conexin T.120 (si existen diferentes) ser asociada. Para abrir el canal lgico, la entidad que inicializa la conexin debe enviar un mensaje open Logical Channel indicando que un canal de datos T.120 ser abierto en los parmetros de canal lgico hacia delante (forward Logical Channel Parameters) as como en los parmetros de canal lgico hacia atrs (reverse Logical Channel Parameter). Si el equipo destino acepta este canal lgico, debe confirmar la apertura del canal usando el mensaje open Logical Channel Ack al equipo origen en el cual puede incluir su identificacin local para la conexin de transporte, en ambos mensajes el parmetro associate Conference deber ser puesto a verdadero (True). Como informacin de identificacin la direccin local de transporte de la conexin inicial de transporte de la conexin T.120 debe ser provista en un parmetro de pila (Stack) por separado. Adems el parmetro external Reference puede ser usado para proveer ms informacin sobre la conexin T.120 a la que ser asociada. Si cualquiera de esta informacin no esta disponible para el equipo origen, este puede omitir los valores respectivos. NOTA: Si la direccin de transporte no es especificada y las dos terminales extremos comparten ms de una conexin T.120 esta puede ser ambigua para la conexin T.120 a la que es referida. FUNCION DE CONTROL H.245 La funcin de control H.245 usa el canal de control H.245 para llevar de extremo a extremo la administracin de la operacin del control de mensajes de la entidad H.323, incluyendo la capacidad de intercambio, apertura y cierre de los

33

Voz dobre IP canales lgicos as como solicitud de preferencia de modo, control de flujo de mensajes y ordenes e indicaciones generales. La sealizacin de la recomendacin H.245 es establecida entre los dos puntos extremos, un extremo y un controlador multipunto (Multipoint ControllerMC) o un punto extremo terminal y un Gatekeeper. El punto extremo cada punto extremo terminal esta participando. Este canal debe usar los mensajes y procedimientos de la recomendacin H.245. Ntese que una terminal, MCU, Gateway o Gatekeeper pueden soportar muchas llamadas, y de esta manera muchos canales de control H.245. El canal de control H.245 deber ser llevado en el canal lgico 0. El canal lgico 0 debe ser considerado para permanentemente abierto para el establecimiento de el canal de control H.245 hasta la terminacin de este canal. Los procedimientos normales para la apertura y cierre de los canales lgicos no aplicaran para el canal de control H.245. La recomendacin H.245 especifica un nmero de entidades de protocolo independiente las cuales soportan la sealizacin extremo a extremo. Una entidad de protocolo es especificada por su sintaxis (mensajes), semntica y los procedimientos de establecimiento los cuales especifican el intercambio de mensajes y la interaccin con el usuario. Las terminales H.323 deben soportar la sintaxis, semntica y procedimientos de las siguientes entidades de protocolo. Determinacin Maestro/Esclavo Capacidad de Intercambio Sealizacin de Canales lgicos Sealizacin Bidireccional de Canales lgicos Sealizacin de Cierre de Canal lgico debe establecer exactamente un canal de control H.245 para cada llamada en la que

34

Voz dobre IP Modo de Solicitud Determinacin de Retardo Durante el Viaje Mantenimiento de una sealizacin cclica.

Indicaciones y rdenes generales deben ser elegidas del establecimiento del mensaje contenido en la recomendacin H.245. Adems otras seales de rdenes e indicaciones pueden ser enviadas, las cuales han sido especficamente definidas para ser transferidas en la banda dentro de las cadenas de audio, video o datos. Los mensajes H.245 caen dentro de cuatro categoras: Solicitud,

Respuesta, Orden e Indicacin. Los mensajes de Solicitud y Respuesta son usados por las entidades de protocolo. Los mensajes de Solicitud requieren una accin especfica por el receptor, incluyendo una respuesta inmediata. Los mensajes de Respuesta como su nombre lo indica, responden a una solicitud correspondiente. Los mensajes de rdenes requieren una accin especfica, pero no requieren una respuesta. Los mensajes de Indicacin son solamente informativos y no requieren de ninguna accin o respuesta. Las terminales H.323 deben responder a todas las solicitudes y ordenes indicaciones para reflejar el estado de la terminal. Las terminales H.323 deben ser capaces de analizar sintctica mente todos los mensajes Multimedia System Control Message y deben enviar y recibir todos los mensajes necesarios para implementar las funciones requeridas y esas funciones opcionales son soportadas por la terminal. Las terminales H.323 deben enviar el mensaje the function Not Supported en respuesta a cualquier mensaje de solicitud, respuesta u orden no reconocido que este reciba. La indicacin H.245, user Input Indicacin, esta disponible para de transporte de usuario y soportar la entrada de caracteres alfanumricos de un teclado o su equivalente para las seales DMTF usadas en telefona analgica. 35 H.245, y deben transmitir

Voz dobre IP Esto puede ser usado para un equipo remoto operado manualmente, como un sistema de correo de voz, un sistema de correo de video, un manejador de servicio de informacin etc. Las terminales H.323 deben soportar la transmisin entrada de usuario de los caracteres 0-9,* y #. La transmisin de otros caracteres es opcional. Tres solicitudes de mensaje H.245 tienen conflicto con los paquetes de control de RTCP. Los mensajes de solicitud video Fast Update Picture, video Fast Update GOB y video Fast Update MB deben ser usada en lugar del control de paquetes RTCP FIR (Full Intra Request) y NACK (Negative Acknowledgment).

CAPACIDADES DE INTERCAMBIO Las capacidades de intercambio deben seguir los procedimientos de H.245, el cual provee por separado las capacidades de transmisin y recepcin, as como un mtodo por el cual la terminal puede describir su capacidad para operar en diferentes modos simultneos. Las capacidades de recepcin describe la habilidad de la terminal para recibir y procesar cadenas de informacin de entrada. Los transmisores deben limitar el contenido de la informacin transmitida de acuerdo a la capacidad que el receptor le haya indicado que es capaz de recibir. La ausencia de de una capacidad de recepcin indica que la terminal no puede recibir informacin (es solo un transmisor). Las capacidades de transmisin describen la habilidad de la terminal para transmitir cadenas de informacin. Las capacidades de transmisin sirven para ofrecer una eleccin de los posibles modos de operacin, entonces el receptor puede solicitar el modo en el cual desea recibir la informacin. La ausencia de una capacidad de transmisin indica que la terminal no esta ofreciendo la opcin de

36

Voz dobre IP elegir un modo preferido para recibir la informacin (pero esta puede transmitir cualquier modo dentro de la capacidad de recepcin). La terminal de transmisin asigna cada modo individual que esta es capaz de operar, con un numero, dentro de una tabla (capability Table). Estos nmeros de capacidades son agrupados dentro de la estructuras alternative CapabilitySet. Cada alternative Capability Set indica que la terminal es capaz de operar en exactamente un modo listado en el establecimiento de la llamada. Por ejemplo, una lista alternativa alternative CapabilitySet {G.711, G.723, G.728} significa que la terminal puede operar en uno de esos modos de audio, pero no ms de uno. Estas estructuras alternative CapabilitySet son agrupadas dentro de las estructuras simultaneous Capabilities. Cada estructura simultaneous Capabilities indica las dos el establecimiento del modo que cada terminal es capaz de usar estructuras alternative CapabilitySet {H.261, H.263} y {G.711, G.723, simultneamente. Por ejemplo, una estructura simultaneous Capabilities contiene G.728}, esto significa que la terminal puede operar con dos canales de video y un canal de audio simultneamente. Un canal de video para H.261 otro para H.261 o H.263 y un canal de audio para G.711, G.723 o G.728. Las capacidades totales de la terminal son descritas por el set de

estructuras capability Descriptor, cada una de las cuales es una simple estructura simultaneous Capabilities y una capability Descriptor Number, enviando mas de un capability Descriptor Number la terminal puede sealar dependencias entre modos operando bajo diferentes establecimientos o modos que pueden tener uso simultneo. Por ejemplo, una terminal emitiendo dos estructuras capability Descriptor, una {(H.261.H.263)}, (G.711, G.723, G.728)} como en el ejemplo previo y otra {(H.262), (G.711)} significa que la terminal puede operar tambin con el H.262 codificador de video (video codec), pero no as con la complexin-baja de G.711 codificador de audio (audio codec).

37

Voz dobre IP Las terminales pueden agregar capacidades durante la sesin de comunicacin por medio de la emisin de las estructuras capability Descriptor, o remover capacidades por medio de las estructuras revisadas capability Descriptor. Todas las terminales H.323 deben transmitir por lo menos una estructura capability Descriptor.

SEALIZACION DEL CANAL LOGICO Cada canal lgico lleva la infamacin del transmisor a ms de un receptor y es identificado por el nmero del canal lgico el cual es nico para cada direccin de transmisin. Los canales lgicos son abiertos y cerrados usando los mensajes open Logical Channel y close Logical Channel y los procedimientos H.245. Cuando un canal lgico es abierto, el mensaje open Logical Channel describe completamente el contenido del canal lgico, incluyendo el tipo de medio, el algoritmo en uso, cualquier opcin y toda la informacin necesaria para que el receptor interprete el contenido del canal lgico. Los canales lgicos pueden ser cerrados cuando existe un periodo de inutilidad. La apertura del canal lgico puede estar inactiva si la informacin de la fuente que desea establecer la comunicacin enviada. La mayora de los canales en H.323 son unidireccionales, entonces la operacin asimtrica esta permitida, en la cual el nmero y tipo de cadenas de informacin es diferente en cada direccin. Sin embargo si el receptor es capaz de trabajar con ciertos tipos de modos de operacin simtrico este puede enviar o recibir capacidades de establecimiento que reflejan sus limitaciones. Las terminales pueden ser capaces de usar un modo particular en una nica direccin de transmisin. Ciertos tipos de medio, incluyendo protocolo de datos como T.120, no ha sido

38

Voz dobre IP requieren inherentemente un canal bidireccional para su operacin. En tales casos un par de canales lgicos unidireccionales, uno en cada direccin, pueden ser abiertos y asociarse juntos para formar un canal lgico bidireccional usando el procedimiento de apertura de un canal lgico bajo la recomendacin H.245. Como los pares de los canales asociados no necesitan compartir el mismo nmero de canal lgico entonces los nmeros de los canales lgicos son independientes en cada direccin de transmisin. Los canales lgicos deben ser abiertos usando el siguiente procedimiento: La terminal que requiere el procedimiento de apertura del canal debe enviar un mensaje como se describe en la recomendacin H.245. Si el canal lgico es usado para llevar un tipo de medio usando RTP (audio o video), el mensaje OpenLogicalChannel debe incluir el parmetro media Control Channel incluyendo la direccin de transporte para el canal inverso RTCP. La terminal que acepta la llamada debe responder con un mensaje Open Logical Channel Ack como se describe en la recomendacin H.245. Si el canal lgico se usa para llevar una clasificacin de medio RTP (audio o video), el mensaje Open Logical Channel Ack debe incluir ambos, tanto el parmetro de medio transport Channel incluyendo la direccin de transporte RTP para el canal del medio y el parmetro media Control Channel incluyendo la direccin de transporte para el canal hacia delante RTCP. La clasificacin del medio (como datos T.120) el cual no usa RTP/RTCP debe omitir el parmetro media Control Channel. Si un canal inverso correspondiente es abierto para una sesin RTP

existente (identificada por RTP session ID), el transporte de las direcciones media control Channel intercambiado por el proceso OpenLogicalChannel debe ser idntico para las que son usadas del canal en la direccin opuesta. Deber ocurrir una colisin donde ambas terminales intenten establecer una sesin conflictiva RTP al mismo tiempo, la terminal que tome el papel de administrador maestro 39

Voz dobre IP debe rechazar el intento conflictivo, esto se puede ver el recomendacin H.245. El intento de la apertura de canal lgico rechazado OpenLogicalChannel debe volver a intentarse mas tarde. CARACTERISTICAS DEL GATEWAY El Gateway debe proveer la apropiada interpretacin entre los formatos de transmisin (por ejemplo H.225.0 de/para H.221) y entre los procedimientos de comunicacin (por ejemplo H.245 de/para desempear el establecimiento de llamada. En general el propsito del Gateway (cuando no esta operando como MCU) es reflejar las caractersticas de extremo de LAN a un extremo de red de circuitos conmutados y viceversa, en un modo transparente para el usuario. Un extremo H.323 puede comunicarse directamente con otro extremo H.242). El Gateway debe tambin

H.323 en la misma LAN sin involucrar al Gateway. El Gateway puede ser omitido si las comunicaciones con las terminales de Red de Circuitos Conmutados (terminales que no estn dentro de la LAN) no son requeridas. El Gateway tiene las caractersticas de una Terminal H.323 o MCU (Multi Controller Unit) en la LAN y por otro lado las caractersticas de una terminal de red de circuitos conmutados o un MCU en la Red de Circuitos Conmutados. El Gateway provee la conversin necesaria entre los diferentes tipos de terminales. Ntese que el Gateway puede inicialmente operar como una terminal, pero despus utilizando sealizacin H.245 se puede configurar para operar como MCU para la misma llamada que fue inicialmente punto a punto. Los Gatekeepers se percatan de cuales terminales son Gateway desde que esto es indicado cuando la terminal/Gateway se registra con el Gatekeeper. Un Gateway que enva datos T.120 entre la Red de Circuitos Conmutados y la LAN, debe contener un proveedor de Sistema Controlador Multipunto T.120 de Sistema MCS (Multipoint Controller System) el cual conecta al proveedor

40

Voz dobre IP Controlador Multipunto T.120 MCS (Multipoint Controller System) en la LAN con el Sistema Controlador Multipunto T.120 MCS (Multipoint Controller System) en la Red de Circuitos Conmutados.

Ejemplos de las configuraciones de un Gateway H.323 son mostrados en la figura siguiente:

41

Voz dobre IP

H.323 LAN Terminal Function

Conversion Function

SCN Terminal Function SCN

Gateway A

H.323 LAN MCU Function

Conversion Function

SCN Terminal Function SCN

Gateway B

H.323 LAN Terminal Function

Conversion Function

SCN MCU Function SCN

Gateway C

H.323 LAN MCU Function

Conversion Function

SCN MCU Function SCN

Gateway D

Configuracin del Gateway en H.323

Gateways nter operando con solo terminales de voz en GSTN o ISDN deben generar y detectar seales DMTF correspondientes a H.245 user Input Indication para los caracteres 0-9, *, #. La funcin de conversin provee la conversin necesaria del formato de transmisin, control, video y/o cadenas de datos entre las diferentes recomendaciones de la terminal. Como mnimo, el Gateway debe proveer: funcin de conversin para el formato de transmisin.

42

Voz dobre IP Establecimiento y procedimiento de seales de llamada. Control y procedimiento de seales de comunicacin. El Gateway desempea la conversin apropiada entre la sealizacin de la llamada H.225.0 y el sistema de sealizacin de la Red de Circuitos Conmutados (Q.931, Q.231, etc.). Todas las sealizaciones Q.931 recibidas por el Gateway de un extremo ISDN y que no son aplicables para el Gateway, deben dejarse pasar al extremo LAN y viceversa. Estas sealizaciones incluyen una serie de mensajes Q.932 y Q.950. Esto permite a los extremos H.323 implementar Servicios Suplementarios descritos en esas recomendaciones. El manejo de la sealizacin de llamada, de la Red de Circuitos Conmutados requiere un estudio ms amplio, por lo que en este trabajo se abordara solo una parte del tema. Esta recomendacin describe la conexin de una terminal H.323 en la LAN a una terminal externa en una Red de Circuitos Conmutados a travs del Gateway. El actual nmero de terminales H.323 que pueden comunicarse a travs del Gateway no es objeto de estandarizacin. De manera similar el nmero de conexiones de Redes de Circuitos Conmutados, el nmero de conferencias simultneas independientes, la conversin de funciones audio/datos/video y la inclusin de funciones multipunto son dejadas a los diferentes fabricantes. Un Gateway puede ser conectado va Red de Circuitos Conmutados a otros Gateways para proveer una comunicacin entre terminales H.323, las cuales no estn en la misma LAN. Equipos que proveen interconexin transparente entre LANs sin usar la recomendacin H.320 (como rutas y marcado remoto en las unidades) no son Gateways como es definido en el mbito de esta recomendacin.

43

Voz dobre IP CARACTERISTICAS DEL GATEKEEPER El Gatekeeper, el cual es opcional en un sistema H.323, provee servicios de control de llamada a un equipo extremo H.323. Ms de un Gatekeeper puede estar presente y comunicarse con otro en un modo no especificado. El Gatekeeper es lgicamente separado de lo equipos extremo, sin embargo, su implementacin fsica puede coexistir con una terminal, un Gateway, un Micro Controlador (MC) o un dispositivo de LAN que no sea H.323.

Cuando esto se presenta en un sistema, el Gatekeeper debe proveer los siguientes servicios:

Resolucin de direcciones: El Gatekeeper debe desempear direcciones seudnimas para resolver Direcciones de Transporte. Esto debe hacerse usando una tabla de resolucin la cual es actualizada usando los mensajes de Registro. Otros mtodos de actualizacin de la tabla de resolucin son permitidos tambin.

Control de Admisin: El Gatekeeper debe autorizar el acceso LAN usando los mensajes ARQ/ACF/ARJH225.0. esto puede ser basado en una autorizacin de llamada, ancho de banda o algunos otros criterios los cuales se dejan al fabricante.

Control de Ancho de Banda: El Gatekeeper debe soportar mensajes BRQ/BRJ/BCF. Esto puede estar basado en la administracin del ancho de banda.

IMPORTANCIA DEL ESTNDAR H.323 H.323 es el primero y sigue siendo el mas importante protocolo estndar de comunicaciones multimedia, a travs de este se logra una convergencia de voz,

44

Voz dobre IP video y datos. Construido para redes de paquetes de datos, H.323 a encontrado una gran aceptacin en las redes IP, teniendo una gran importancia en VoIP. Como otros protocolos de comunicaciones, H.323 es un estndar publicado por la ITU (Internacional Telecommunications Union). Este fue aprobado como un estndar internacional para voz, video y datos, definiendo como algunos dispositivos por ejemplo computadoras, telfonos, celulares, PDAs, telfonos inalmbricos y sistemas de videoconferencia, dan una nueva pauta a la tecnologa y al usuario final. El estndar H.323 es la primera especificacin completa bajo la cual, los productos desarrollados se pueden usar con el protocolo de transmisin ms ampliamente difundido (IP). Es debido a esto que existe tanto inters y expectacin entorno al H.323 porque apareci en el momento ms adecuado, porque se tienen amplias redes ya instaladas y la mayora de las aplicaciones son basadas en IP, tales como el acceso a la Web. Adems, los ordenadores personales son cada vez ms potentes y por lo tanto, capaces de manejar datos en tiempo real tales como voz y vdeo.

Como logros principales de esta recomendacin podemos sealar:

La estandarizacin de los protocolos permite a los diversos fabricantes evolucionar en conjunto. Los usuarios no deben preocuparse sobre las posibilidades de su interlocutor, existiendo una negociacin de las capacidades de cada punto de la lnea.

Debido a su apoyo sobre IP es independiente del tipo de red fsica que lo soporta, permitiendo la integracin con las grandes redes IP actuales. Por su propia estructura, es independiente del hardware, si bien permite ser implementado en los ordenadores actuales, tambin se desarrolla hardware especfico como Telfonos IP y consolas de videoconferencia. 45

Voz dobre IP

Otra caracterstica importante es el control de trfico que se puede realizar dentro de la red. De esta forma no deben producirse cadas importantes de rendimiento en las redes de datos. La negociacin previa permite conectar terminales de muy diversas caractersticas, como pueden ser telfonos de voz, consolas de videoconferencia, ordenadores, etc.

Se ha llevado una rpida adopcin del H.323. El grfico siguiente explica por s mismo esta tendencia.

Figura.2.1.1 Crecimiento del mercado H.323

H.323 PERSPECTIVA HISTORICA Anteriormente al H.323, el ITU se enfoc exclusivamente en la estandarizacin de las redes globales de telecomunicaciones. Por ejemplo, en

46

Voz dobre IP 1985 se comenz el trabajo en la especificacin que define el envo de imagen y voz sobre redes de circuitos conmutados, tales como RDSI. La ratificacin de la norma (H.320) tuvo lugar 5 aos despus (fue aprobada por el CCITT en Diciembre de 1990). Slo 3 aos despus se dispuso de equipos que cumplieran En Enero de 1996, un grupo de fabricantes de soluciones de redes y de ordenadores propuso la creacin de un nuevo estndar ITU-T para incorporar videoconferencia en la LAN. Inicialmente, las investigaciones se centraron en las redes de rea local, pues stas son ms fciles de controlar. Sin embargo, con la expansin de Internet, el grupo hubo de contemplar todas las redes IP dentro de una nica recomendacin, lo cual marc el inicio del H.323. El H.323 soporta vdeo en tiempo real, audio y datos sobre redes de rea local, metropolitana, regional o de rea extensa. Soporta as mismo Internet e intranets. En Mayo de 1997, el Grupo 15 del ITU redefini el H.323 como la recomendacin para "los sistemas multimedia de comunicaciones en aquellas situaciones en las que el medio de transporte sea una red de conmutacin de paquetes que no pueda proporcionar una calidad de servicio garantizada. Ntese que H.323 tambin soporta videoconferencia sobre conexiones punto a punto, telefnicas y RDSI. En estos casos, se debe disponer un protocolo de transporte de paquetes tal como PPP. Una recomendacin del ITU. Aunque se hable del H.323 como de un estndar, el ITU lo considera una recomendacin. Como cualquier recomendacin de un origen similar, est abierta a la interpretacin de diferentes fabricantes. Una ventaja es que deja libertad a los fabricantes para implementar capacidades que cumplan con los requerimientos de aplicaciones especiales.

ESTABLECIMIENTO DE LLAMADAS 47

Voz dobre IP El paso previo al establecimiento de una comunicacin entre dos terminales es la resolucin de la direccin IP del destinatario de la llamada. En este proceso el usuario llamante invoca mediante H.225 RAS al Gatekeeper para conocer la direccin IP del destinatario. Si el proceso de registro del destinatario fue satisfactorio el Gatekeeper conocer su direccin IP, esta direccin fsica ser entregada al llamante para que inicie la llamada. En este punto hay que recordar que el Gatekeeper tiene la autorizacin para denegar una llamada, es decir, puede no autorizar al llamante y as mismo, puede no autorizar al llamado a atender la llamada. Toda comunicacin de naturaleza H.225 RAS es transportada sobre UDP. Si el Gatekeeper ha autorizado la llamada a continuacin entra en juego la especificacin H.225.0 Call Control. Este protocolo deriva de Q.931 y aporta el servicio bsico de llamada. Call Control ser empleado por el llamante para ponerse en contacto con el usuario deseado. Como evolucin de Q.931 en l se encuentran los habituales mensajes de Setup, Call Proceeding, Alerting, Connect y Release Complete. H.225.0 Call Control emplea TCP como nivel de transporte. La proliferacin de terminales H.323 y algoritmos de compresin ha obligado a incorporar un canal por el que los participantes en una conversacin acuerden las prestaciones de terminal que emplearan y qu tipo de compresin aplicarn a la voz o el vdeo. Este canal de negociacin es desarrollado a travs del protocolo H.245 Media Control que a su vez viaja sobre datagramas TCP. H.323 emplea UDP como nivel de transporte de la voz y el video. Ambos flujos de informacin se codifican respectivamente segn las especificaciones G.7xx y H.26x. Dentro de H.323, complementado a UDP, encontramos los protocolos RTP (Real Time Protocol) y RTCP (Real Time Control Protocol) que entre otras funciones son los responsables de introducir marcas de tiempo en cada datagrama de informacin para la correcta secuenciacin y posterior reconstruccin de caudal de voz o video.

48

Voz dobre IP El proceso descrito es el procedimiento bsico de establecimiento de llamadas. A partir de la versin 2 de H.323 se han incorporado numerosas facilidades de usuario conocidas como Servicios Suplementarios. Estos servicios se renen sobre la especificacin H.450.1 que a su vez se sita sobre H.225 Call Control. Por citar solo algunos de estos servicios indicar la existencia de H.450.2 para la transferencia de llamadas; H.450.3 para el desvo de llamada y H.450.6 para la llamada en espera. Estndar T.120 T.120 surge de la necesidad, en una videoconferencia, de trabajo en equipo, es decir compartir diferentes aplicaciones como por ejemplo: compartir una hoja de clculo, hacer un dibujo estilo pizarra, y que sea compartido entre ambos conferenciantes, etc. Mucho ms todava cuando en vez de una videoconferencia de solo dos sitios, tenemos una multi - videoconferecia. Y en realidad, no est asociada totalmente a 'Videoconferencia', aunque esta su entorno natural, si no que es un estndar para compartir datos. Si se utiliza T.120 los datos pueden ser distribuidos en tiempo real a cada uno de los participantes, existiendo interoperabilidad entre equipos de distintos fabricantes, asegurndose la integridad de los datos. Adems este estndar es independiente de la red (RTC, LAN, RDSI, etc.) y de la plataforma (Unix, PC, Macintosh, etc.). En este tipo de conferencias siempre hay uno administrador (es el 'proveedor principal'), que es el que ofrece los servicios de MCS (Multipoint Conference Services). La conexin de los terminales a este puede ser en estrella, en cadena, en cascada, etc. Si el proveedor se cae, la conferencia (de datos) se interrumpe.

49

Voz dobre IP En las conferencias de datos hay un 'dominio', que bsicamente es la conferencia en s, y 'canales' dentro del dominio, que pueden ser pblicos (para difusin, broadcast) o privados entre usuarios.

Estos canales son los siguientes: 1. Canal de errores de control. Prioridad mxima. 2. Canal de anotaciones. Prioridad alta. 3. Canal de Imgenes de Mapa de bits. Prioridad media. 4. Canal de transferencia de ficheros. Prioridad baja.

Algunos de los componentes de la T.120 son:

T.123: Protocolos de transporte de red. Presenta al nivel superior un interfaz comn, e independiente del medio de transporte.

T.122: Servicio de datos genrico orientado a conexin que junta varias comunicaciones punto a punto para formar un dominio multipunto. Entre otras cosas, proporciona difusin de datos con control de flujo, direccionamiento multipunto, busca el camino ms corto entre estaciones, etc. Los problemas de reserva y resolucin de recursos se solucionan mediante testigos.

50

Voz dobre IP T.125: Protocolo de servicio de comunicacin multipunto. Especifica los mensajes de protocolo necesarios segn T.122

T.124: Control Genrico de Conferencia (GCC). Establece y libera las conexiones, maneja la lista de participantes, listas de aplicaciones y funcionalidades de las mismas, etc... Aqu va, con carcter opcional, T.121: Plantilla General de Aplicaciones (GAT, General Aplication Template). Define una plantilla con la funcionalidad de una aplicacin. Permite que quien se enfrente a programar algo de esto, se asegure de ajustarse a la recomendacin.

T.126: Protocolo de intercambio de imgenes fijas y anotaciones.

T.127: Transferencia multipunto de ficheros binarios. Permite la difusin de varios ficheros de forma simultnea, transmisin privada de ficheros entre grupos de participantes, etc... T.128: Control audiovisual para sistemas multimedia multipunto. Esto controla el manejo de canales de audio y video en tiempo real dentro de una videoconferencia.

Las aplicaciones de usuario podran utilizar los servicios de T.126, 127 y 128, ir directamente sobre T.124 sobre T.122/125, utilizar T.121...

51

Voz dobre IP

CAPITULO 3.- TELEFONIA IP La telefona IP es un trmino usado para describir un juego de productos y soluciones usados para transportar trfico de voz sobre una red de datos. Utilizando IP (Internet Protocol) como mecanismo de transporte, la telefona IP 52

Voz dobre IP permite crear una red convergente en la cual todas las comunicaciones (voz, video y datos) compartan la misma infraestructura. Existen numerosos beneficios para este tipo de infraestructura, incluyendo administracin simplificada, ahorro de costos en telecomunicaciones y unificacin de servicios de mensajes.

SELECCIN PARA IMPLEMENTAR TELEFONIA IP Es importante tener en cuenta que el trfico de voz y el trfico regular de datos IP son dos soluciones completamente diferentes. El trafico de datos RTCP /IP (Regular Transmisin Control Protocol / Internet Protocol) es muy flexible es decir no da mucha importancia a una WAN con enlaces de transmisin lentos, perdida de paquetes y recepcin de paquetes fuera de secuencia. De hecho, TCP/IP opera de esa forma, tomando datos y segmentndolos dentro de diferentes paquetes y transmitiendo los datos va el mejor camino posible que encuentre. No siendo de su importancia el orden en el cual los datos son recibidos, o el camino que toma para llegar a su destino, porque el dispositivo final es el responsable del reensamble y la resegmentacin de los datos. Por otro lado el trfico de Voz no permite este tipo de flexibilidad. Aun cuando el trafico de voz se este convirtiendo a paquetes IP, esto no deja de ser trafico de voz. La telefona IP depende de los paquetes que estn siendo recibidos en el mismo orden en el que fueron enviados, si un paquete se pierde, este deber permanecer perdido, porque retransmitir el paquete solo confundira a la persona destino que esta recibiendo la llamada. Para lograr esto, se debe incorporar nuevas y diferentes caractersticas en los Switches y Routers como encolado (Queuing) y RTP (Real Time Control Protocol)

COMPONENTES DE TELEFONIA IP 53

Voz dobre IP Los componentes que deben ser sumados a la infraestructura para facilitar la telefona IP son los que realmente opacaran la lnea entre la infraestructura de voz tradicional y la infraestructura de datos. Un punto importante que recordar cuando estamos considerando una infraestructura convergente, es que no importa si estamos manejando voz, video o datos, porque a fin de cuentas todo esto son comunicaciones.

Elementos de una red de red de VoIP. CALL MANAGER CallManager provee una solucin de telefona IP basado en un software de plataforma de procesamiento de llamada para desempear el papel del tradicional PBX. EL CallManager representa una solucin a gran escala y responde a las necesidades de la telefona IP. Se han introducido diferentes soluciones de Vos

54

Voz dobre IP sobre IP, por ejemplo diferentes programas de Chat como: Microsoft NetMeeting, Amrica Online, Instant Messenger y Yahoo! Messenger, estos programas ofrecen la capacidad de comunicar voz utilizando Internet otra red como medio, sin embargo estos carecen de confiabilidad.

El Call Manager debe ofrecer una solucin confiable, escalable y manejable para cualquier organizacin de cualquier tamao en el que se desee implementar la telefona IP.

LA PLATAFORMA CALL MANAGER El Call manager es probablemente la plataforma ms integral de la telefona

IP. Este provee al resto de la arquitectura de la telefona IP con un punto central para el procesamiento de llamada, servicios de conexin, sealizacin y registro para telfonos IP, anlogos, gateway digitales y hereda dispositivos de telefona como en un sistema basado en PBX. La comunicacin con dispositivos de telefona IP esta habilitada para usar diferentes protocolos de telefona IP como SSP (Skinny Station Protocol), H.323, MGCP (Media Gateway Control Protocol) y SMDI (Simplified Message Desk Interface). Recientes versiones de la plataforma CallManager permiten a un servidor

CallManager soportar de 2500 telfonos IP a 5000 dispositivos de telefona IP por cada servidor. Un dispositivo IP puede ser cualquiera de los siguientes:

Telfono IP Gateway analgico o digital IP softphone (Software de un telfono IP normal)

55

Voz dobre IP Procesador Digital de Seales

PROTOCOLOS DE TELEFONIA IP SKINNY STATION PROTOCOL (SSP) Es un protocolo de comunicaciones basado en el estndar SGCP (Simple Gateway Protocol). SSP fue primero introducido como un mtodo de comunicacin entre la primera generacin de telfonos IP, Gateways y servidores CallManager y aun es ampliamente usado para el mismo propsito. SSP depende del servidor CallManager para difundir la configuracin y control de la informacin. Este es creado en TCP/IP y utiliza los puertos TCP 2000-2002.

H.323 H.323 es un estndar ampliamente usado para audio, video y datos en

tiempo real (Internacional

sobre redes de paquetes. H.323 es un estndar de la ITU Telecommunication Union) y es parte de la familia de

protocolos H.32X. H.323 fue construido basndose en el protocolo H.320, permitiendo la transmisin de video y audio basado en redes de paquetes como Ethernet.

MEDIA GATEWAY CONTROL PROTOCOL (MGCP)

Es utilizado como un protocolo ms veloz que H.323 y SSP, utilizando UDP (User Datagram Protocol) en oposicin a utilizar TCP para la transmisin.

56

Voz dobre IP

SIMPLIFIED MESSAGING DESK INTERFACE (SMDI) Es un protocolo estndar de correo de voz para integrar los sistemas de

correo de voz heredados por los antiguos sistemas basados en PBX y/o otros dispositivos similares. El CallManager y otras plataformas unificadas de mensajes pueden usarlo para integrar los sistemas de correo de voz basados en PBX.

CLUSTERING El agrupamiento (clustering) permitir extender el soporte para dispositivos de 2500 telfonos IP sobre un servidor CallManager a alrededor de 10,000 telfonos IP dentro de un grupo sencillo. El agrupamiento (clustering) como su nombre lo indica, es el proceso de combinar 2 o mas servidores CallManager dentro de una unidad lgica conocida como Grupo. Un grupo consiste de servidores CallManager y sus dispositivos asociados como telfonos IP, gateways y dispositivos lgicos como SoftPhones que es una versin en Software de un telfono IP normal. Cuando el concepto de grupo es utilizado, todos los servidores CallManager comparten la misma configuracin de la base de datos, entonces si un servidor CallManager falla, los dems ya tienen la configuracin, entonces no se requiere una nueva configuracin manual.

La idea principal del agrupamiento (clustering), consiste en proveer suficientes servidores para que si uno de ellos llega a fallar los dems dentro del grupo puedan tomar la carga del servidor que fallo sin el comprometer el nivel de servicio de los sistemas finales. Se tienen 4 perfiles que puede tomar un servidor dentro de un grupo:

57

Voz dobre IP Servidor Primario CallManager Servidor de respaldo CallManager Servidor Publicador de la Base de Datos Servidor TFTP (Trivial File Transfer Protocol)

El servidor primario y el de respaldo se describen por si mismo.

El papel de servidor publicador de la base de datos es mantener y distribuir la configuracin maestra de la base de datos. Una segunda pero igual de importante tarea es almacenar las grabaciones de los detalles de las llamadas (Call Detail Records). Un CDR es una grabacin de una llamada telefnica IP. Esta puede ser usada para anlisis de trfico y funciones adicionales de contabilidad. El servidor TFTP es usado para proveer una imagen del sistema para los dispositivos como telfonos IP y gateways. Como se estructura el grupo depende de cuantos dispositivos de telefona IP sern soportados. Hay muchas limitaciones que se deben tomar en cuenta antes de implementar un grupo. Un importante punto es tomar en consideracin es que un grupo no puede cruzar un enlace WAN. Todos los grupos de servidores deben existir en la misma LAN adems los servidores deben de interconectarse a 10Mbps. No esta permitido compartir el medio en un grupo, esto es para asegurar que la calidad del servicio (QoS) es conservada. Un mximo de 100 grupos La siguiente figura muestra el pueden ser interconectados, permitiendo soporte para cerca de 1, 000,000 telfonos IP dentro de una organizacin. funcionamiento de un grupo y su proteccin:

58

Voz dobre IP

Agrupamiento de CallManagers

59

Voz dobre IP

Proteccin sobre falla TELEFONOS IP Los telfonos IP proveen al usuario final una interfase dentro de la arquitectura de la telefona IP. Algunos soportan estndares abiertos y la habilidad de interactuar con Microsoft NetMeeting. Los telfonos IP interactan con la red con una conexin a 10/100Mbps, aparte de tener un puerto extra para PC o cualquier otro perifrico as como tambin un puerto RS-232 para capacidades adicionales. Ofrecen una pantalla LCD para desplegar un men con sus caractersticas establecidas dejando atrs los botones convencionales.

60

Voz dobre IP GATEWAYS

Son dispositivos usados para conectar la infraestructura de telefona IP a la Red de telefona Publica Conmutada (PSTN) o para heredar los sistemas PBX. Existen diferentes Gateways que soportan diferentes protocolos de gateways. Nos enfocaremos en los que soportan los protocolos siguientes

Skinny Gateway Protocol H.323 MGCP El protocolo SGP (Skinny Gateway Protocol) esta basado en el protocolo

estndar SGCP, sin embargo es usado solo por una marca de proveedor en particular, en otras palabras mientras SGCP es un estndar abierto SGP es propiedad estandarizada de CISCO, haciendo comparacin con el protocolo HDLC que cada fabricante tiene su propia implementacin. H.323 es un estndar de la ITU. Los Gateways H.323 son mas comnmente encontrados en un dispositivo enrutador con gateway integrado y en comunicacin con el CallManager. MGCP (Media Gateway Control Protocol) es un estndar tambin y se usa para comunicar el enrutador-gateway y el CallManager.

61

Voz dobre IP

INTRODUCCION AL VIDEO

Las tradicionales transmisiones de video tpicamente consistan de una adiferentes lneas de interfaz de tasa bsica (BRI) de ISDN conectando propiamente estaciones terminales de videoconferencias. Estas lneas ISDN tpicamente operan en una infraestructura punto a punto utilizando la recomendacin H.320. Usualmente el ancho de banda usado esta en un rango de 128Kbps a 384Kbps y resguardado completamente de forma independiente de la existente infraestructura de voz y datos, lo cual resulta como una baja utilizacin de los recursos disponibles. Aunque algunos avanzados sistemas PBX pueden terminar las lneas BRI (Basic Rate Interface) para sistemas de videoconferencia, las lneas BRI y las lneas de voz estn resguardadas de forma completamente separada unas de las otras. La videoconferencia basada en IP, por otra parte, utiliza la recomendacin H.323 permitiendo utilizar redes multiacceso la videoconferencia sobre una variedad de medios, y ATM (Asynchronous incluyendo medios compartidos y conmutados como Ethernet, lneas alquiladas y sin difusin como Frame Relay Transfer Mode).

COMPONENTES DE VIDEO Como se menciono al principio, la voz sobre IP es muy intolerante al retardo y a la perdida de paquetes, si hablamos de video conferencias basadas en IP o

62

Voz dobre IP video sobre IP las cosas se complican. retardos, no se entendera nada. Las transmisiones de video basadas en IP as como la telefona IP son muy similares en naturaleza. Voz en este caso datos de video, son encapsulados dentro de paquetes IP y transportados a su destino final. describirn A continuacin se algunos de los componentes requeridos para facilitar la video Por ejemplo si se tiene una video

conferencia importante y la informacin es recibida fuera de secuencia y con

conferencia basada en IP, componentes como gateways, gatekeepers, unidades de control multi-punto (MCU) y terminales adaptadoras de video.

GATEWAYS Son usados para proveer a la video conferencia basada en IP el acceso a

la red de fuera de la red de la organizacin. Los gateways proveen la resolucin de protocolo como H.323 a H.320, y resolucin a ISDN de otros medios de red. Existen en el mercado plataformas modulares ofreciendo opciones de conexin LAN, ISDN, BRI, ISDN PRI (Primary Rate Interface) y V.35.

GATEKEEPERS

Un Gatekeeper es un dispositivo usado para permitir o denegar solicitudes para video conferencias, son una parte integral de la video conferencia basada en IP. El Gatekeeper es responsable de decidir si suficientes fuentes estn disponibles para que la videoconferencia se lleve acabo y si el dispositivo que solicita la videoconferencia puede obtener el acceso a los recursos solicitados.

63

Voz dobre IP UNIDADES DE CONTROL MULTIPUNTO Las Unidades de control Multipunto (MCUs) sirven como un centro, para la comunicacin e infraestructura de la video -conferencia. Este centro sirve como un simple punto de control de mando para establecer, enlazar y terminar transmisiones de video. Un MCU es utilizado cuando tres o ms participantes necesitan acceso a la misma video conferencia en tiempo real. Un simple MCU puede controlar diferentes videoconferencias simultneamente.

ADAPTADORES TERMINALES DE VIDEO. El papel de las Terminales Adaptadores de Video (VTA) en la video

conferencia es proveer una interfase para heredar los sistemas de video conferencia anteriores. Esto es un logro porque provee una resolucin de protocolo entre la recomendacin H.320 para videoconferencia sobre ISDN y el protocolo de telefona IP H.323.

DISPOSITIVOS EXTREMO Los dispositivos de extremo (endpoints) son los dispositivos de usuario final

que suscriben y reciben servicios de video conferencia. Actualmente hay una lista de diferentes fabricantes de este tipo de dispositivos de usuario final como son: Picture Tel, Polycom, Sony, TANDBERG, VCON, VTEL y Zydacron. Aunque la manufactura de los dispositivos vari de fabricante en fabricante, pantalla y componentes de audio. es tpico encontrar los mismos componentes, usualmente: una video cmara una video

64

Voz dobre IP MEJORAR LA INFRAESTRUCTURA DE RED Como se ha descrito la telefona IP y las video conferencias basadas en IP crean una Arquitectura para Voz Video y Datos Integrados. Dependiendo de las necesidades de la red se deben ir agregando nuevos dispositivos como servidores CallManager, telfonos IP, video Gateways, Gatekeepers, MCUs, VTAs y dispositivos de usuario final. Todos estos dispositivos son necesarios para llevar acabo la Arquitectura para Voz, Video y Datos Integrados.

ENRUTADORES PARA UNA RED CONVERGENTE Como se sabe un enrutador es un dispositivo que trabaja en la capa del modelo de referencia OSI, su propsito primario es determinar el mejor camino para los paquetes y conmutar los paquetes basados en direccionamiento IP u otro tipo de direccionamiento de capa 3. Cuando se implementa una red convergente, los enrutadores toman un papel muy importante y estos deben ser los dispositivos que deben ser primordialmente actualizados. Algunos enrutadores solamente se actualizan adhiriendo mdulos-chasis con las interfaces correspondientes actualizadas. Actualmente en el mercado existen diferentes tipos de enrutadores que permiten migrar a una red convergente.

INTERFACES DE VOZ ANALOGICA Los enrutadores utilizan interfaces de voz analgica para interactuar directamente con los telfonos convencionales o para conectarse con el antiguo sistema PBX o la Red Publica Conmutada. Como la tecnologa actualmente tres tipos de anloga es considerada como una vieja y estable tecnologa, estas interfases son estandarizadas. Existen interfaces analgicas soportadas por algunos enrutadores, que son las siguientes:

65

Voz dobre IP FXS (FOREIGN EXHANGE STATION) Los puertos de esta interfaz utilizan un conector RJ-11 para conectarse con los telfonos convencionales, mdems o faxes. Este es el tipo de interfaz mas comnmente encontrada en los enrutadores. FXO (FOREIGN EXCHANGE OFFICE) Los puertos de esta interfaz utilizan tambin un conector telefnico RJ-11. Los puertos son comnmente utilizados para conectar por medio de una negociacin los sistemas PBX al proveedor de servicio telefnico de la red.

E&M (EAR & MOUTH) Esta interfaz ofrece una solucin mas avanzada que las anteriores, as

como otras caractersticas que los anteriores no ofrecen, como por ejemplo almacenamiento y transmisin anloga o digital. Esta interfaz utiliza un puerto RJ48 opuestamente al RJ-11 utilizado por los anteriores.

INTERFACES DE VOZ DIGITAL Las interfaces de voz digital son provistas en los enrutadores usando

tarjetas de almacenamiento digital de voz, procesadores de voz digital (DVP DigitaL Voice Processor) y mdulos de compresin de voz (VCMs Voice Compression Modules). Las tarjetas de almacenamiento digital de voz interactan comnmente con lneas ISDN BRI y PRI. Utilizando canales individuales en cada lnea, este permite para una lnea sencilla soportar dos lneas de voz usando BRI (Basic Rate Interface) y cerca de 23 lneas usando PRI (Primary Rate Interface) en los Estados Unidos y cerca de 30 lneas en Europa.

66

Voz dobre IP El procesador de voz digital VCMs permite al enrutador llevar una

conversacin de voz y comprimirla lo mas que se pueda, aproximadamente a 5.3 Kbps, dependiendo del mtodo de compresin utilizado, una gran diferencia con el canal de 56 Kbps. Esto permite una mejor utilizacin del ancho de banda disponible.

ENCOLADOS PARA VOZ Y VIDEO El encolado es un importante punto de diseo y desempeo que debe ser examinado en la telefona IP. El encolado ha sido tradicionalmente una funcin de la capa del modelo de referencia OSI para las conexiones WAN, pero cuando se habla de una red convergente se debe enfocar a las LAN. El trafico en la capa 2 del modelo de referencia OSI puede ser clasificado por el tipo de servicio usando el protocolo 802.1Q. Es recomendado que cuando se usa este protocolo se separe el trfico de voz y video del trfico regular de datos y se ponga este trfico con un encolado de prioridad alta. El protocolo 802.1Q especifica siete clases de servicio (COS), 0 comienza por la mas baja prioridad y 7 comienza por la mas alta prioridad. Se recomienda que COS 4 -7 sea usado para voz y video, y que 0-3 operacin normal de datos. Una nota importante para ser considerada es que en el encolado de capa 2 una vez que los paquetes encuentran un enrutador, la informacin de capa que llevan esos paquetes se pierde, en otras palabras 802.1Q es solo una solucin LAN. Para el trfico que cruza enlaces WAN, el encolado de capa 3 debe ser incorporado. para la

67

Voz dobre IP INTRODUCCION A LOS GATEWAYS PARA VIDEO Y DATOS INTEGRADOS. Un Gateway por definicin es un dispositivo que convierte un medio o protocolo a otro. En el ambiente Voz sobre IP, un Gateway es responsable de conectar una red de telefona IP a la Red Telefnica Publica Conmutada o PBX y sistemas clave. Por ejemplo, el gateway puede conectar una red H.323 a una red basada en SIP (SMDS Interface Protocols), Red Publica Telefnica Conmutada o ISDN. Tambin desempea resoluciones entre diferentes formatos de transmisin y procedimientos de comunicacin, y es responsable para establecer y liberar llamadas en ambos lados de la red. La comunicacin entre las terminales y un Gateway son hechas a travs de los protocolos H.245 y Q.931. Los tipos de Gateways van de dispositivos nicos con niveles de entrada especializados a Gateways de nivel empresarial integrados en Switches y Enrutadores. Basados en los dispositivos o la implementacin, los Gateways se comunican con otros dispositivos sobre diferentes protocolos Gateway. La propia infraestructura o los requerimientos para implementar Voz sobre IP determinaran cual Gateway debe usarse, pero algunas de las caractersticas que se requieren por default son: transmisin DMTF, redundancia del CallManager y servicios Servicios suplementarios que permitan a los usuarios suplementarios. LA ARQUITECTURA DE VOZ,

desempear la llamada en espera, transferencia de llamada y conferencia, por mencionar algunos.

CAPACIDADES DE LOS PROTOCOLOS DE LOS GATEWAYS Los tres protocolos de voz de los Gateways, como se menciono al

principio, son SSP (Skinny Station Protocol), H.323, y MGCP. El primero permite a un cliente usar TCP/IP para transmitir y recibir llamadas y paquetes RTP/UDP/IP para audio. Un ejemplo de un cliente es un telfono IP o

68

Voz dobre IP Gateway. El cliente se comunica con el CallManager sobre TCP en los puertos 2000-2002. H.323 es el protocolo de Gateways mas soportado por los dispositivos de diferentes fabricantes y es una recomendacin estndar hecha por la ITU (Internacional Telecommunications Union) para los paquetes basados en audio, video, voz y conferencia. Es el estndar central para la conferencia (basado en H.245, H.225 y Q.931) y es el nico Gateway que provee capacidad de enrutamiento completo. Este transmite y recibe cadenas va RTP (Real Time Protocol) junto con RTCP (Real-Time Control Protocol) llevadas sobre UDP (User Datagram Protocol), por medio de eso provee estado y control de la informacin. Sealizacin como RAS (Registration, Admisin y Status), H.245 y Q.931 es transportada sobre sealizacin TCP.Q.931, para el establecimiento y terminacin de una llamada. Sin embargo las capacidades son intercambiadas utilizando H.245, el cual se usa para el control de llamada y estable la comunicacin multimedia o los servicios de llamada entre los clientes H.323. El protocolo MGCP funciona en una arquitectura donde la inteligencia del control de llamada es removida de un Gateway. Level3, Bellcore, Cisco y Nortel desarrollaron MGCP el cual es un protocolo maestro/esclavo, donde el gateway es el esclavo sirviendo rdenes del maestro, el cual es el agente que llama. El CallManager funciona como el agente que llama. Otro protocolo que esta siendo implementado en los Gateways es SIP (Session Initial Protocol), es un protocolo de control de la capa de aplicacin que puede establecer, modificar y terminar sesiones multimedia o llamadas. Estas sesiones multimedia incluyen conferencias IP, llamadas telefnicas y distribucin multimedia. Una solucin para este tipo consiste de un agente SIP, un telfono IP, un Gateway SIP y un servidor Proxy SIP.

69

Voz dobre IP SIP soporta cinco elementos de establecimiento y terminacin de comunicaciones:

Localizacin de usuario Capacidades de Usuario Disponibilidad de Usuario Establecimiento de llamada Manejo de llamada Actualmente, el mundo de Voz sobre IP es dominado por H.323, el

surgimiento de SIP y el incremento del numero de aplicaciones que soporta esta tecnologa significa que exista una interoperabilidad de SIP con las redes existentes H.323. NOTA: Un ejemplo de un software nuevo que utiliza la funcionalidad de SIP es la aplicacin Windows Messenger, el cual es parte de Windows XP. Windows Messenger es un software de comunicaciones en tiempo real que provee punto a punto telefona IP. SIP es un protocolo de comunicacin multiparte, pero la primera versin de Windows Messenger solo soporta dos formas de conversacin.

ELECCION DE UN GATEWAY DE VOZ Hay un nmero de diferentes Gateways de voz disponibles para el CallManager y las implementaciones de Voz sobre IP, las cuales estn divididas en categoras, por el tipo de Gateway y el protocolo que esta corriendo para la comunicacin del Gateway. La seleccin del Gateway esta basada sobre algunas de las siguientes variables: anlogo o digital, capacidad, tipo de conexin, servicios, caractersticas e instalacin.

70

Voz dobre IP Los Gateways analgicos proveen conectividad a un telfono analgico, oficina central y a un PBX. Los puertos FXS (Foreign Exchange Station) son usados para proveer un tono de marcado para telfonos analgicos, faxes y telfonos con altavoz., mientras que los puertos FXO (Foreign Exchange Office) en un Gateway son usados para la conectividad con la Oficina Central para un acceso analgico a la Red Telefnica Publica Conmutada. Por otro lado los puertos E&M (Ear & Mouth) son utilizados para la sealizacin de comunicacin de PBX a PBX. Si se requiere una ms alta capacidad de los canales de voz para la Red Publica Telefnica Conmutada o PBX, un Gateway digital podra ser mas efectivo. Los diferentes Gateway soportan dos tipos de seales principales: ISDN PRI (Primary Rate Interface) o CAS (Channel Associated Signaling) para un T1 o E1. ISDN PRI utiliza un canal D para sealizacin. ISDN PRI es clasificado como sealizacin fuera de banda, porque hay un canal dedicado para sealizacin, mientras que, la sealizacin CAS (Channel Associated Signaling) usa una parte del ancho de banda de cada canal. Para determinar cual tipo de interfase PRI es requerida depende si el Gateway se va a conectar a una PBX o a la Red Publica Telefnica Conmutada. Generalmente si el gateway se conecta a un PBX, se necesitara una Interfase de red PRI porque el PBX esta en el lado del usuario. Normalmente la Red Telefnica Publica Conmutada funciona como un Lado de red y el Gateway necesita una Interfase del Lado de Usuario PRI. La redundancia del CallManager es requerida porque una red con Arquitectura de Video, Voz y Datos Integrados necesita tener el mismo alto nivel de disponibilidad y confiabilidad como el tradicional PBX. Ahora otro punto a tomar en cuenta es la sealizacin. DMTF usa dos frecuencias, un tono alto y uno bajo para distinguir los nmeros en un teclado telefnico. Esta sealizacin es usualmente transmitida sobre un circuito de voz de

71

Voz dobre IP 64Kbps y lograda con poco problema, pero con un CODEC de resolucin baja de bits la seal puede ser perdida o irreconocible. Los Gateways proveen un soporte fuera de banda para pasar seales DTMF a travs de una red de Voz sobre IP va protocolos de Gateway. El Gateway de una Arquitectura de Video, Voz y Datos Integrados necesita proveer soporte para otros servicios de telefona de usuario como llamada en espera, manejo de llamada y conferencia.

72

Voz dobre IP

GATEKEEPERS El Gatekeeper acta como un punto de control central inteligente para la red multimedia en tiempo real (H.323). Este monitorea los equipos de usuario (endpoints) y gateways as como el de audio, video y llamadas de datos. El Gatekkeper puede controlar (basado en su configuracin) que estaciones (equipo de usuario/endpoints) pueden participar en la red. Tambin pueden restringir las llamadas basadas en un equipo de usuario que hace o recibe la llamada. Adems puede desempear varias funciones de administracin como resolucin de direcciones, servicio de directorio, as como autorizacin de llamada y contabilidad. En algunas redes el Gatekeeper es tambin conocido como Administrador de Conferencia Multimedia (MCM Multimedia Conference Manager). El Gatekeeper puede ser configurado en un enrutador existente o en uno dedicado.

73

Voz dobre IP FUNCIONES DEL GATEKEEPER Los Gatekeepers son componentes de una red H.323, una red diseada para transportar trafico en tiempo real, como voz, video y datos. Un gatekeeper interacta con los equipos de usuario final (endpoints), las cuales son estaciones capaces de establecer llamadas H.323 como por ejemplo una estacin de trabajo corriendo Microsoft NetMeeting o un CallManager. Un Gatekeeper tambin interacta con Gateways, los cuales son dispositivos capaces de convertir trafico H.323 en otras formas de trafico. Por ejemplo los Gateways convierten trafico H.323 en llamadas de voz sobre la tradicional red telefnica o llamadas sobre la Red Digital de Servicios Integrados en comn con videoconferencia. Como es definido por la recomendacin H.323, el Gatekeeper es requerido para desempear una cierta gama de funciones. Estas funciones requeridas desempean los servicios bsicos H.323. Por ejemplo, los Gatekeepers localizan los equipos de usuario que estn recibiendo llamadas y los liberan de esta tarea. El Gatekeeper tambin controla totalmente la participiacion en la red as como las llamadas establecidas ah. Funciones adicionales pueden agregar valor en ciertos casos. Los Gatekeepers usan el protocolo H.225 para comunicarse con los son opcionales y

equipos de usuario final (endpoints) y Gateways. El protocolo H.225 tiene dos partes bsicas: Registro, Admisin y Estado (RAS- Registration, Admisin and Status) y sealizacin de llamada. Los Gatekeepers primeramente usan el RAS, parte del protocolo H.225, con los equipos de usuario final (endpoints) y gateways para el registro, la admisin y el control de llamada en la red H.323. Los equipos de usuario final (endpoints) y gateways tambin usan una parte de la sealizacin de llamada del protocolo, para el establecimiento de llamada.

74

Voz dobre IP FUNCIONES REQUERIDAS Los Gatekeepers son requeridos para desempear las siguientes funciones. Desde que los equipos de usuario final requieren usar un gatekeeper, si uno esta disponible, este es un excelente punto de control para la red:

Resolucin de direcciones: El Gatekeeper resolver una direccin H.323 (por ejemplo un numero telefnico E.164) en una direccin IP. El Gatekeeper har esto resolviendo el nmero telefnico a un equipo de usuario final ya registrado con el Gatekeeper o encontrando la localizacin del nmero telefnico por solicitud a otros Gatekeepers configurados, utilizando el protocolo H.225 (RAS). Por ejemplo el Gatekeeper puede traducir el nmero 212-555-1212 en una direccin IP 10.5.6.1. El Gatekeeper caracteres). tambin puede resolver sobre H.323 IDs (cadenas de

Control de admisin: El Gatekeeper puede controlar que equipo de usuario final (endpoint) enlazar y participara en la red H.323. Por simplicidad, el Gatekeeper puede ser configurado para permitir a todos los equipos de usuario (endpoints) enlazarse a la red H.323. Alternativamente para una seguridad estricta, este puede admitir solo una lista de equipos de usuario (enpoints) conocidos. El Gatekeeper puede tambin restringir la participacin de equipos de usuario por otras caractersticas configuradas por el administrador, como disponibilidad de ancho de banda o numero de equipos de usuario activos. Aunque una red H.323 no requiere un Gatekeeper, si el Gatekeeper existe, todos los participantes se ven obligados a usarlo, permitiendo que la seguridad sea mejorada.

75

Voz dobre IP Control de ancho de banda: El Gatekeeper es responsable del monitoreo y control del ancho de banda de la red que estn usando todas las llamadas. Se puede restringir la cantidad de ancho de banda utilizado para llamada de voz y video (H.323). Esto es muy importante porque si mas llamadas de las que la red puede soportar son hechas, todas las llamadas sufrirn de calidad muy pobre. Por ejemplo el Gatekeeper activamente monitorea todas las llamadas, el ancho de banda utilizado por cada llamada (ancho de banda solicitado y establecido) (endpoints). El Gatekeeper usas toda esta informacin para prevenir que el total del ancho de banda utilizado por las llamadas de voz y video excedan el lmite configurado para una zona. Esto asegura que todas las llamadas permitidas reciban suficiente ancho de banda. De esta manera el Gatekeeper puede rechazar llamadas si el umbral para el trafico H.323 ha sido rebasado. En la tradicional red de voz los canales disponibles en WAN (Wide Area Network) limitaran el lmite del nmero de llamadas que pudieran ser establecidas. En una red IP, este lmite no existe, por lo tanto el Gatekeeper debe aplicar este lmite. y la sealizacin de la llamada entre los equipos de usuario

76

Voz dobre IP CAPITULO 4 .- PROTOCOLO RSVP. El protocolo RSVP (Resource Reservation Protocol) fue el primer intento en la industria para la implementacin del estndar Intserv (Internet Integrated Services), que es el modelo de QoS. Investigadores del Instituto de ciencias Informticas de la Universidad de California del Sur e investigadores de Xerox, fueron los primeros en trabajar sobre el protocolo RSVP. QUE ES EL PROTOCOLO RSVP RSVP es un protocolo de sealizacin que hace reservaciones del medio para las aplicaciones del cliente en la que garantiza mejor calidad de servicio (QoS). Es considerado como protocolo de sealizacin porque las reservaciones son llevadas a cabo durante la comunicacin entre estaciones. Los paquetes RSVP no son usados para transmitir grandes cantidades de datos, estos coexisten en la red con otros paquetes y son usados para reservar el medio de transmisin de los paquetes tpicos IP; o ms especficamente los paquetes IP son enviados y los paquetes RSVP se encargan de la calidad de servicio. Por esta razn, RSVP parece muy natural su cambio cuando se implementa el AVVID mientras el trafico de datos especifica requerimientos, incluyendo esto para banda ancha. RSVP hace reservaciones de medio para el flujo de datos a travs de la red. Estos flujos reservados son usualmente referidos como sesiones. Una sesin es definida como paquetes que tienen la misma direccin de destino (unicast o multicast). Los clientes usan la disposicin RSVP para garantizar la calidad de servicio a travs de la red.

RSVP no es un protocolo de ruteo, sino que es un protocolo de control en Internet que reside en la capa 4 del modelo OSI, refirindose a la capa de transporte. Es muy similar a otros protocolos, semejante a ICMP (Internet Control Message Protocol) y a IGMP (Internet Group Management Protocol), estos funcionan con Ipv4 y tambin con ipv6. el camino que toma sobre la red es el 77

Voz dobre IP mismo que otros paquetes IP y esta determinado por los siguientes protocolos de ruteo, OSPF (Open Shortest Path First), EIGRP ( Enhanced Interior Gateway Routing Protocol) ], Enhanced Interior Gateway Routing Protocol), BGP (Border Gateway Protocol). Adems de la Inter - operabilidad con estos protocolos de ruteo, RSVP tambin trabaja con la implementacin de calidad de servicio. Estos son los mecanismos que proveen calidad de servicio directamente; WFQ (Weighted Fair Queuing), WRED (Weighted Random Early Detection).

Que mecanismos de implementacin no son usados de forma directa con RSVP?, esto depende de los routers que determina cmo la calidad de servicio ser implementado, basado en su propia capacidad. El protocolo solo hace la solicitud y abandona el nodo intermediario y reparte la QoS. Ambos mtodos de trafico (unicast y multicast) son soportados por RSVP. El soporte para multicast, desde que RSVP es comnmente usado es el protocolo que mas predomina para trafico de voz y video, lo cual es caracterizado por el flujo de multicast. El protocolo RSVP tiene Inter operatibilidad con IGMP y con PIM (Protocol Independent Multicast).

COMO TRABAJA EL RSVP? Ahora que tenemos un entendimiento bsico de que es RSVP, veamos el mecanismo poniendo una sesin RSVP, en el caso de una llamada telefnica o video conferencia. No nos enfocaremos especficamente en la configuracin de RSVP pero, mas bien, nos concentraremos en la estrategia global.

78

Voz dobre IP Iniciar sesin. El protocolo RSVP es puesto a menudo entre dos clientes de punto a punto (semejante a una llamada telefnica), o entre mltiples transmisores y mltiples receptores (multicast). Para RSVP es constantemente posible negociar un multipunto escogiendo un punto de transmisin. En algn caso, la sesin RSVP levanta los procesos reservados en una sola direccin. Para tener garanta de calidad de servicio en full - duplex, es necesario que la sesin levante los procesos que se estn ejecutando al mismo tiempo, una vez en cada direccin. Por ejemplo, al establecer una llamada de VoIP entre dos usuarios, usualmente deberia ser necesario, establecer dos reservaciones, uno en cada caso, para garantizar buena calidad de servicio entre ambas llamadas. Por otro lado la cadena de video necesitara solo un camino de reservacin. Desde que hemos estado hablando acerca del protocolo RSVP, hemos considerado las reservaciones requeridas para una video conferencia entre dos personas. Sabemos que los componentes de voz y video tienen diferentes requerimientos de banda ancha, obviamente necesita la separacin de las reservaciones de voz y video. Considerando que ambos elementos ( voz y video), necesitaran estar en forma bi direccional, esto quiere decir que tendramos la necesidad de un total de 4 reservaciones tomando en cuenta dos routers. Tomando en cuenta el ejemplo y aplicando los 4 puntos uno por uno a la video conferencia, se tiene que 4x (4 1) = 12 reservaciones estando administrado por cada router. Cuando usamos la frmula A x (B 1) = C, donde A = flujo bi -direccional, B = Nmero total de Routers, y C = Reservaciones totales por router, esto no es difcil de realizar estos cambios, se solucionarn cuando intentes extender la RSVP en una larga escala. Ahora que hemos explorado algo de esta informacin a fondo, se necesitar guardar en mente, considerar cuantas sesiones podremos levantar, ponemos estos pasos a travs de el proceso de una sesin levantada de un RSVP.

79

Voz dobre IP 4.3 SIP PROTOCOLO INICIAL DE SESION

El protocolo inicial de sesin SIP es un protocolo de control de la capa de aplicacin para crear, modificar y terminar sesiones con uno o ms participantes. Estas sesiones incluyen conferencias multimedia a travs de Internet, llamadas telefnicas sobre Internet y distribucin multimedia.

Los miembros en una sesin multimedia pueden comunicar va multicast (multidifusion) o va una malla de relaciones unicast o combinaciones de esta.

Las invitaciones SIP usadas para crear sesiones, llevan descripciones de sesin las cuales permiten a los participantes ponerse de acuerdo en el establecimiento de tipos de medio (audio/video).

SIP soporta movilidad de usuario mediante proxying y redireccionamiento de solicitudes a la localizacin actual del usuario. Los usuarios pueden registrar su localizacin actual. SIP no es ligado a ningn protocolo particular de control de conferencia. SIP esta diseado para ser independiente de las capas inferiores de protocolo de transporte y puede ser extendido con capacidades adicionales.

4.4 FUNCIONALIDAD DE SIP (Session Initial Protocol)

El protocolo inicial de sesin es un protocolo de control de la capa de aplicacin que puede establecer, modificar y terminar sesiones multimedia o llamadas. Estas 80

Voz dobre IP sesiones multimedia incluyen conferencias multimedia, aprendizaje a distancia, telefona Internet y aplicaciones similares. SIP puede invitar a ambas personas y robots tal como servicio de almacenamiento de medios. SIP puede invitar tanto sesiones unicast o multicast, el iniciador no tiene que ser un miembro de una sesin a la cual se le esta invitando. Medios y participantes pueden ser agregados a una sesin existente.

SIP puede ser usado para iniciar sesiones tanto como invitar a miembros a sesiones que han sido anunciadas y establecidas por otros miembros. Las sesiones pueden ser anunciadas usando protocolos multidifusion como SAP, mail, grupos, paginas Web o directorios (LDAP) y muchas otras formas.

SIP transparentemente soporta mapeado y redireccionamiento de servicios, permitiendo la implementacin de ISDN y servicios de subscripcin de red de telefona inteligente. Estas facilidades tambin permiten la movilidad personal.

En el lenguaje de servicios de telecomunicaciones de red inteligente, esto es definido como: Movilidad personal es la habilidad del usuario final para originar y recibir llamadas y acceso de servicios subscritos de telecomunicaciones sobre cualquier terminal en cualquier lugar, y la habilidad de la red para identificar a los usuarios finales dondequiera que se encuentren. La movilidad personal esta basado sobre el uso de una identificacin personal (por ejemplo un numero personal). La movilidad personal complementa la movilidad de la terminal por

81

Voz dobre IP ejemplo la habilidad para mantener comunicacin cuando se mueve una sencilla terminal de una sub-red a otra.

SIP soporta cinco facetas de establecimiento y terminacin de comunicaciones multimedia:

Sitio de usuario: Determinacin del sistema final para ser usado para la comunicacin.

Capacidades de usuario: Determinacin del medio y parmetros del medio (audio/video) para ser usados.

Disponibilidad de usuario: Determinacin de buena voluntad de la llamada para ser empleada en las comunicaciones

Establecimiento de la llamada: timbrado, establecimiento de los parmetros de llamada tanto en la llamada como la sesin de llamadas.

Manejo de llamada: Incluyendo transferencia y terminacin de llamadas.

SIP adems puede iniciar llamadas multi-sesiones usando una Unidad de Control Multipunto (MCU) o enredado completo de interconexiones en lugar de multicast. Gateways de telefona sobre Internet que conectan las sesiones de llamadas con la Red Pblica Telefnica Conmutada pueden usar SIP para establecer llamadas entre ellos.

82

Voz dobre IP SIP esta diseado como una parte de la IETF de datos multimedia y el control de arquitectura actualmente incorporando protocolos como RSVP para las fuentes de reserva de red, el protocolo de transporte en tiempo real (RTP) para transportar datos en tiempo real y proveer retroalimentacin de calidad del servicio, protocolo en tiempo real de streaming (RTSP) para controlar la entrega o media streaming, el protocolo de anuncio de sesin (SAP) para anunciar las sesiones multimedia va multidifusion (multicast) y el protocolo de descripcin de sesin (SDP) para describir las sesiones multimedia. Sin embargo, la funcionalidad y operacin de SIP no depende de ninguno de estos protocolos.

SIP puede ser usado conjuntamente con otro establecimiento de llamada y otro tipo de protocolos de sealizacin. En ese modo un sistema final usa intercambios SIP para determinar la direccin apropiada del sistema final y el protocolo de esa direccin dada que es un protocolo independiente. Por ejemplo SIP puede ser usado para determinar que la sesin puede ser alcanzada va H.323 obteniendo la direccin del Gateway H.245, la direccin del usuario y entonces usar H.225 para establecer la llamada.

En otro ejemplo, SIP podra ser usado para determinar que la llamada es lograda va PSTN (Red Telefnica Publica Conmutada) e indicar el numero telefnico que ser llamado con la posible sugerencia de ser usado un Gateway de Internet a Red Telefnica Publica Conmutada). SIP no ofrece servicio de control de conferencia como control de fondo o votado y no prescribe como una conferencia que ser administrada, pero SIP puede ser 83

Voz dobre IP usado para introducir protocolos de control conferencia. SIP no designa direcciones mutidifusion. SIP puede invitar usuarios a sesiones con o sin una reservacin. SIP no reserva fuentes, pero puede convenir con el sistema invitado la informacin necesaria para hacer esto. OPERACIN DE SIP

Personas que llaman y personas llamadas son identificadas por una direccin SIP. Cuando se hace una llamada SIP, el llamador primero localiza el servidor apropiado y entonces enva una solicitud SIP. La ms comn operacin de SIP es la invitacin. En lugar de lograr directamente la llamada destinada una solicitud SIP puede ser redirigida o puede provocar una cadena de nuevas solicitudes SIP por medio de proxies. Los usuarios pueden registrar su ubicacion con servidores SIP.

DIRECCIONAMIENTO SIP

Los objetos diseccionados por SIP son usuarios como en hosts, identificados por una URL SIP. La URL SIP toma una forma similar a una direccin mail o una URL Telnet, por ejemplo user@host. La parte de usuario es un nombre de usuario o un nmero telefnico. La parte de Host es tambin un nombre de dominio o una direccin numrica de red.

84

Voz dobre IP Una direccin de usuario SIP puede ser obtenida fuera de banda, puede ser aprendida va agentes existentes de medio, puede ser incluida en algunas cabeceras de mensaje de mail o puede ser grabada durante interacciones previas de invitacin. En muchos casos una URL de SIP puede ser supuesta de una direccin de correo.

Una direccin URL SIP puede designar un individuo (posiblemente localizado en alguno de los diferentes sistemas finales), la primera persona disponible de un grupo e individuos o un grupo completo. La forma de la direccin, por ejemplo, sip: sales@example.com, no es suficiente, en general, para determinar el intento de llamado

Si un usuario o servicio elige ser alcanzado a travs de una direccin que es fcil de adivinar de un nombre de una persona y de una afiliacin organizacional, el mtodo tradicional de asegurar privacia para tener un nmero telefnico enlistado es comprometido. Sin embargo a la nada parecida telefona tradicional, SIP ofrece mecanismos de autenticacin y control de acceso y puede beneficiarse por si mismo de los mecanismos de seguridad de las capas mas bajas, para que el software cliente pueda rechazar intentos de llamada no autorizados o indeseados.

85

Voz dobre IP ESTABLECER UN SERVIDOR SIP

Cuando un cliente desea enviar una peticin/solicitud, el cliente tambin lo enva para un servidor Proxy SIP configurado localmente (como en HTTP), independientemente de la solicitud URL, o la enva a la direccin IP y puerto correspondiente de la solicitud URL.

Para el ltimo caso, el cliente debe determinar el protocolo, puerto y direccin IP de un servidor para el cual enviara la peticin. En cada caso el cliente debe tratar de contactar un servidor en el nmero de puerto listado en la solicitud URL. Si el nmero de puerto no es presentado en la peticin URL, el cliente usara el puerto 5060. Si la solicitud especifica un protocolo (TCP o UDP), el cliente contacta el servidor usando ese protocolo. Si el protocolo no es especificado el cliente usara UDP (si UDP es soportado). Si el intento falla o si el cliente no soporta UDP pero soporta TCP, entonces este intentara con TCP.

Un cliente debe ser capaz de interpretar notificaciones explicitas de red (como mensajes ICMP) los cuales indican que un servidor es inalcanzable, mas que depender solamente de los tiempos de expiracin. Si el cliente encuentra que el servidor es inalcanzable en una direccin en particular, este deber comportarse como si este hubiera recibido una respuesta de error de clase 400 para esa solicitud.

86

Voz dobre IP TRANSACCION SIP

Una vez que la parte del host ha sido resuelta a un servidor SIP, el cliente enva una o ms solicitudes SIP a ese servidor y recibe una o ms respuestas del servidor. Una solicitud (y sus retransmisiones) juntas con las respuestas disparadas por esa solicitud establecen una transaccin SIP. Todas las respuestas a una solicitud contienen los mismos valores en el identificador de llamada Call-ID, Cseg, To y de los campos.

Si TCP es usado, solicitudes y respuestas dentro de una simple transaccin simple son llevadas sobre la misma conexin TCP. Diferentes solicitudes SIP provenientes del mismo cliente al mismo servidor pueden usar la misma conexin o pueden usar una nueva conexin para cada solicitud. Si el cliente enva la solicitud va unicast UDP, la respuesta es envida a la direccin contenida en el siguiente campo de la cabecera de la respuesta. Si la solicitud es enviada va multicast UDP, la respuesta es dirigida a la misma direccin multicast y puerto de destino. Para UDP la confiabilidad es llevada

acabo usan retransmisin. El formato de los mensajes SIP y la operacin es independiente del protocolo de transporte.

INVITACION SIP

Una invitacin exitosa SIP consiste de dos peticiones, INVITE seguido por un ACK. La peticin INVITE pregunta al sistema llamado enlazar un conferencia 87

Voz dobre IP particular o establecer una conversacin entre dos. Despus que el sistema

llamado ha aceptado participar en la llamada, el sistema que llama confirma que este ha recibido esa respuesta por medio del envo de una peticin ACK. Si el participante no quiere participar ms en la llamada, este enviara una peticin BYE en lugar de un ACK.

La peticin INVITE tpicamente contiene una descripcin de sesin, por ejemplo escrita en el formato SDP, que provee la sesin de llamada con suficiente informacin para establecer la sesin. Para sesiones multicast, la descripcin de sesin enumera los tipos de medio y formatos que sern permitidos para ser distribuidos para esa sesin.

Para sesin unicast, la descripcin de sesin enumera el tipo de medio y formato que el sistema que llama esta disponiendo para usar y donde el desea que los datos media sean enviados, En el mismo caso, si el sistema llamado desea aceptar la llamada, este responder a la invitacin retornando una descripcin similar listando el medio que el desea usar. Para una sesin multicast, el sistema llamado debe solo regresar una descripcin de sesin si este esta inhabilitado para recibir el medio indicado en la descripcin del sistema que llama o quiere recibir datos va unicast.

88

Voz dobre IP LOCALIZAR A UN USUARIO

Un sistema llamado puede moverse entre un nmero de diferentes sistemas sobre tiempo, Estas ubicaciones pueden ser dinmicas registradas con el servidor SIP. La ubicacin del servidor puede tambin usar uno u otros protocolos mas como finger, rwhois, LDAP, protocolos basados en multicast o mecanismo dependientes de sistemas operativos para determinar activamente el sistema

final donde un usuario podra ser alcanzable. La ubicacin del servidor puede regresar diferentes ubicaciones porque el usuario es registrado en diferentes hosts simultneamente o porque la ubicacin del servidor tiene (temporalmente) para producir una

informacin imprecisa. El servidor SIP combina los resultados lista de cero o ms ubicaciones.

La accin tomada de recibir una lista de ubicaciones vara con el tipo de servidor SIP. Un servidor SIP redirigido regresa la lista a el cliente como cabeceras de Contacto. Un servidor SIP puede secuencialmente o en paralelo, tratar las

direcciones hasta que la llamada sea exitosa o el sistema llamado haya declinado la llamada. Con los intentos secuenciales, un servidor Proxy puede implementar un servicio anycast.

Si un servidor Proxy enva una peticin SIP, este debe agregarse por si mismo al comienzo de la lista de envos notados en las cabeceras va. El trayecto va asegura que las replicas pueden tomar el mismo camino de regreso, asegurando la operacin correcta a travs de los dciles firewalls y evitando loops de 89

Voz dobre IP peticiones. Sobre el camino de respuestas, cada host debe eliminar su va, para que el enrutado de la informacin interna sea oculto para el sistema llamado y

fuera de la red. Un servidor Proxy debe checar que esto no genere peticiones a un host listado en los parmetros va sent-by, va received o va-madrr.

PROPIEDADES DE PROTOCOLO

ESTADO MINIMO

Una simple sesin de conferencia o llamada envuelven una o mas transacciones de peticiones y respuestas SIP. Los servidores proxys no tienen que guardar el estado para un llamada en particular sin embargo ellos deben mantener el estado para un simple transaccin SIP. Por eficiencia un servidor debe obtener los resultados de la ubicacin de servicio de peticin.

CAPAS DE PROTOCOLO INFERIORES NEUTRALES

SIP hace las suposiciones mnimas acerca del subyacente transporte y protocolos de capa de red. Las capas bajas pueden proveer tanto un paquete como un servicio de cadenas de bits, con la confiabilidad o desconfiabilidad del servicio. Dentro de un contexto de Internet, SIP es capaz de utilizar tanto UDP como TCP como protocolos de transporte., de entre otros. UDP permite a la aplicacin un control ms cuidadoso del tiempo de los mensajes y sus retransmisiones, para desempear paralelamente bsquedas sin necesidad de un estado de conexin 90

Voz dobre IP TCP para cada peticin sobresaliente y uso d multicast. Los enrutadores pueden interpretar con mayor facilidad paquetes SIP UDP. TCP permite una mayor

facilidad de paso a travs de los firewalls existentes.

Cuando TCP es usado, SIP puede usar una o ms conexiones para intentar contactar un usuario o modificar parmetros de una conferencia existente. Diferentes peticiones SIP para la misma llamada SIP pueden usar diferentes conexiones TCP o una sencilla conexin persistente segn sea apropiado.

En concreto en este trabajo solo se hace referencia a protocolos de Internet. Sin embargo SIP puede tambin ser usado ATM AAL 5, Frame Relay o X.25. directamente con protocolos tales como

BASE DE TEXTO

SIP es basado en texto usando ISO 10545. Esto permite una fcil implementacin en lenguajes como Java, Tcl y Perl, permite una fcil supresin de errores y lo ms importante hace a SIP flexible y escalable. Porque SIP es usado para iniciar conferencias multimedia ms que para entrega de datos multimedia.

SIP URL (Uniform Resource Locatin- Ubicacin Uniforme de Recursos)

SIP URLs son usados dentro de los mensajes SIP para indicar el originador de la llamada, la ubicacin del destino y el recipiente final de una peticin SIP y para 91

Voz dobre IP especificar el redireccionamiento de direcciones. Una URL SIP puede tambin implantarse en pginas Web u otros hiperlinks para indicar que un usuario en particular o servicio en particular puede ser llamado va SIP. Cuando es usado como hiperlink, el URL SIP indica el uso del mtodo de INVITADO.

El esquema URL SIP es definido para permitir las caractersticas de los campos de la cabecera de peticin SIP y el cuerpo de mensaje SIP. Esto corresponde al uso del mail: URLs. Esto es posible, por ejemplo, para especificar el sujeto, la prioridad o los tipos de medio o las llamadas iniciadas a travs de una pgina Web o como parte de un mensaje de correo.

Ejemplote URLs SIP son:

sip:j.doe@big.com sip:j.doe:secret@big.com;transport=tcp sip:j.doe@big.com?subject=project sip:+1-212-555-1212:1234@gateway.com;user=phone sip:1212@gateway.com sip:alice@10.1.2.3 sip:alice@example.com sip:alice%40example.com@gateway.com sip:alice@registrar.com;method=REGISTER

92

Voz dobre IP Dentro de un mensaje SIP las URLs son usadas para indicar la fuente y el destino de una peticin, redireccionamiento de direcciones y la actual ubicacin de una peticin, Normalmente todos estos campos contendrn las URLs SIP.

METODOS

Los mtodos son definidos a continuacin. Los mtodos que no son soportados por un Proxy o un servidor redirigido son tratados por ese servidor como si estos fueran un mtodo de opcin y son enviados acordadamente. Los mtodos que no son soportados por un agente usuario un registro cusan una respuesta 501 para ser notificada. Como en http al mtodo Token es un caso sensible. Un mtodo puede ser INVITE, ACK,OPTIONS BYE, CANCEL,

REGISTRER.

METODO INVITE

El mtodo INVITE indica que el usuario o servicio esta siendo invitado a participar en una sesin. El cuerpo del mensaje contiene una descripcin de la sesin para la cual el sistema que es llamado, esta siendo invitado. Para dos sesiones de llamada, el sistema que llama indica el tipo de medio que este esta disponible a recibir y el posible medio que espera enviar as como sus parmetros tales como la red de destino. Una respuesta exitosa debe indicar en su cuerpo de mensaje cual medio el sistema llamado desea recibir (audio/video) y puede indicar el medio que el sistema llamado va a enviar. 93

Voz dobre IP

No todos los formatos de descripcin tienen la habilidad para indicar el tipo de medio a enviar. Un servidor puede automticamente responder a una invitacin para una conferencia en la que el usuario esta listo para participar en ella, identificada tambin por el SIP call-ID (identificador de llamada), debe checar cualquier versin de identificadores, el contenido de descripcin de la sesin para ver si esta ha cambiado. Si hay algn cambio, el agente de usuario debe actualizar cualquier estado interno o la informacin generada como resultado de esa cabecera.

Si la descripcin de la sesin ha cambiado, el servidor de agente de usuario debe ajustar los parmetros de sesin acordadamente, posiblemente despus de preguntar al usuario para la confirmacin.

Este mtodo debe ser soportado por servidores Proxy, redirigidos y agentes de usuario as como tambin clientes.

94

Voz dobre IP Hola Ulises, Hoy debera haberse entregado la tesina en CD e impresa al Ing. Raul Bribiesca, si pueden llevenla el lunes debido a que se ha estado adelantando la toma de protesta. En el contenido te falta indicar la introduccin y las conclusiones.

Numerar tablas y figuras con el nmero de captulo y secuencia, ejemplo tabla 1.1, fig., 1.1, etc.

En el captulo 1 se le podran agregar algunos esquemas para hacer la lectura ms fcil.

En general al inicio de cada captulo agregar una explicacin breve de lo que se va a tratar y poner conclusiones al final del mismo.

El captulo 2 y 3 numerar los incisos ms importantes, as como las figuras.

El ttulo del captulo 4 debe resaltar de otros textos, faltan esquemas de apoyo (figuras y tablas) as como las conclusiones.

Falta uns seccin de conclusiones generales de la tesina.

Falta la bibliografa y de ser necesario un glosario de trminos.

95

Voz dobre IP Saludos

96