Voz dobre IP
TESINA DE TITULACIÓN.
“PRINCIPIO Y FUNCIONAMIENTO DE VoIP”
correo del profesor: primitivo_reyes@yahoo.com.mx
ALUMNOS:
DOMINGUEZ PERES ULISES
HERNANDEZ GRAJALES RAUL
1
Voz dobre IP
C O N T E N I DO
CAPITULO I.- Analogía de la Telefonía IP vs Telefonía tradicional.
1.1 Telefonía tradicional.
1.2 Arquitectura de una central telefónica.
1.3 Procesamiento de llamadas.
1.4 Conexión entre centrales.
1.5 Ruteo, Señalización y Protocolos.
1.6 Telefonía IP.
1.7 Ancho de banda necesario.
1.8 Calidad en la transmisión de la voz.
1.9 Estándares.
1.10 Aplicaciones.
1.11 Ventajas e inconvenientes de los servicios IP.
CAPITULO 2.- Protocolos para multimedia.
2.1 Protocolo H.323.
2.2 Descripción del sistema.
2.3 Características del terminal.
2.4 Elementos terminales en la recomendación 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 Función de control H.245.
2.5 Capacidades de intercambio.
2.6 señalización del canal lógico.
2.7 Características del Gateway
2.8 Características del Gatekeeper.
2.9 Importancia del estándar H.323.
2
Voz dobre IP
2.10 H.323 perspectiva histórica.
2.11 Establecimiento de llamadas.
CAPITULO 3.- Telefonía IP.
3.1 Selección para implementar telefonía IP.
3.2 Componentes de la telefonía IP.
3.2.1 Call Manager.
3.2.2 La plataforma Call Manager.
3.3 Protocolos de la telefonía IP.
3.3.1 SSP.
3.3.2 H.323.
3.3.3 MGCP.
3.3.4 SMDI
3.4 Clustering.
3.5 Telèfonos IP.
3.6 Gateways.
3.7 Introducción 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 analógica.
3.11.1 FXS.
3.11.2 FXO.
3.12 Interfaces de voz digital.
3.13 Encolados para voz y video.
3
Voz dobre IP
3.14 Introducción a los Gateways.
3.15 capacidad de los protocolos de los Gateways.
3.16 Elección 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 Cómo trabaja el protocolo RSVP.
4.3 SIP Protocolo Inicial de Sesion
4.4 Funcionalidad de SIP
4.5 Operación 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
4
Voz dobre IP
PRINCIPIO Y FUNCIONAMIENTO DE VoIP
Introducción
La convergencia de las redes de telecomunicaciones actuales pretende
encontrar la tecnología que permita la transmisión de voz y datos sobre la misma
línea. Esto ha obligado a establecer modelos o sistemas que permita
“empaquetar” la voz para que pueda ser transmitida en la línea de datos.
Tomando en cuenta que Internet es la “Red de Redes”, desarrollar una tecnología
de ámbito mundial nos dirige al protocolo IP (Internet Protocol) y a encontrar el
método que nos permita transmitir voz sobre IP; la solución a este problema nos
lleva a VoIP (Voice Over Internet Protocol).
Esta tecnología tuvo sus inicios con la empresa VocalTec en el año 1995
que con su producto Internet Phone dio las posibilidades reales de establecimiento
de llamadas telefónicas de PC a PC con la ayuda de un software en la PC y como
medio de transmisión, la Internet.
En el año de 1996 se dan las primeras experiencias de establecimientos de
llamadas de PC a teléfono y de teléfono a teléfono. A partir de 1997 aparecen
nuevos dispositivos y métodos que nos llevan hoy en día a mantener el término
XoIP. Este acrónimo X, significa cualquier contenido susceptible a ser transmitido
por una red, (X = datos, Voz, Fax, Multimedia, etc.).
Cuando hacemos una llamada telefónica por IP, nuestra voz se digitaliza,
se comprime y se envía en paquetes de datos IP. Estos paquetes se envían a
través de Internet a la persona con la que estamos hablando. Cuando alcanza su
destino son ensamblados de nuevo, descomprimidos y convertidos en la señal de
voz original.
5
Voz dobre IP
En el capítulo uno, se realiza una analogía de la telefonía convencional con
la telefonía IP, así como sus ventajas y desventajas.
En el capítulo dos, se explica los protocolos para transmisión de datos
multimedia, H323, H225, H245 y codificación de voz y audio.
En el capítulo tres, se profundiza el funcionamiento de VoIP, sus
componentes, Gatekeeper y Gateway.
En el capítulo 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, características y protocolos.
6
Voz dobre IP
CAPITULO I.- Analogía de la Telefonía IP vs Telefonía tradicional.
Voz sobre IP es transmitir Voz utilizando IP. Si bien es una tecnología
novedosa, tiene muchas características similares y otras diferentes a las de la
telefonía tradicional.
Por eso, a continuación se explica brevemente el esquema de una red
telefónica tradicional, y luego las coincidencias y diferencias con la tecnología de
VO/IP, para poder hacer una buena evaluación de las ventajas y desventajas.
Telefonía Tradicional.
El servicio telefónico es, junto con la red eléctrica, uno de los más
confiables que conocemos y usamos, ya que todo es muy redundante y está
pensado para funcionar siempre. Una central telefónica esta diseñada para
minimizar los tiempos de interrupción del servicio.
Es una tecnología en que la interfaz es muy importante, la gente la conoce,
espera que cuando levanta el teléfono se escuche el tono, y si no es el mismo que
el que esperaba escuchar, molesta; además es muy universal y difundida. Todo
esto se tiene en cuenta a la hora de prestar el servicio telefónico.
7
Voz dobre IP
Arquitectura de una central telefónica.
Todos tenemos un teléfono en nuestra casa. En general, sabemos que el
cable del teléfono 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 telefónico. Ese par
telefónico es el que va hasta la central telefónica, a una placa que se la suele
denominar placa de abonado. Es la placa que controla nuestra línea.
En realidad, puede controlar muchas líneas, no una sola, y tiene una
densidad de puertos que depende del fabricante, ronda entre los 8 y 16 abonados
(a veces más, a veces menos). El valor exacto depende del equipo en particular.
La central telefónica 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 telefónicas suelen estar diseñadas para
tener una muy alta disponibilidad (se suele decir que son carrier class, dado que
se dice están disponibles el 99,999% del tiempo, que representa alrededor de 5
minutos al año de interrupción de servicio). Para lograr este objetivo, cuentan con
redundancia en múltiples niveles (procesadores, enlaces, etc.); y en general se
conectan a un sistema de energía interrumpida, que tiene un buen número de
baterías que se conectan a un grupo electrógeno que se activa cuando se corta la
energía.
Procesamiento de Llamadas
Hasta la central, la voz va en forma analógica. Actualmente ya no existen
centrales analógicas, todo lo que hay desde que llega la señal a la central y sale
de la otra central hacia el otro abonado, es digital.
8
Voz dobre IP
La placa de abonado es la que se encarga de hacer la conversión de una
señal analógica a una digital y viceversa. La señal se convierte a un PCM de
64kbps, que es una señal digital sin pérdida de información y sin compresión, es el
formato que se está utilizando desde prácticamente sus comienzos. También es la
placa de abonado la que decodifica los tonos de discado (DTMF).
Es decir que, se utiliza el concepto de señalización en banda: comandar a
la central utilizando la misma banda por la que se habla.
Conexión 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 teléfono.
Esta multiplexación es la que hace una diferencia a la hora de la calidad del
servicio para el usuario. El sistema de multiplexación que utilizan las centrales
telefónicas 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, podría haber hasta 32 abonados hablando a la vez. Con esta multiplexación
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.
9
Voz dobre IP
Lo bueno de esta tecnología 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
comunicación, 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 telefonía
común y la de voz sobre IP, permite tener una red predictiva y garantizar calidad.
Ruteo, señalización y protocolos.
Otro tema importante es el "ruteo" entre centrales, es decir, cómo sabe la
central del abonado con que central se tiene que conectar.
Vamos a denominar señalización a la información relacionada con una
llamada que se transmite entre dos equipos (la definición 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 través de la señalización, 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 comunicación, que dio ocupado, etc.
Las centrales entre sí se comunican utilizando diversos protocolos, los
cuales generalmente son estándares públicos, aunque en muchos casos las
especificaciones no son fáciles (o baratas) de conseguir. Los protocolos más
comunes son tres: R2, PRI y SS7.
10
Voz dobre IP
El protocolo R2, es uno de los más viejos y tiene muchas variantes
distintas, hay -incluso- una variante argentina, y pasa toda su información
utilizando 4 bits. SS7 es, por otra parte, uno de los más nuevos y complejos.
Se necesita que las dos centrales que se están 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 información.
Acerca del enlace por el cual se pasa tanto la señalización como la voz en
sí, existen muchísimos tipos. Los más 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 también nos
interesa el número 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 información.
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 señalización (el 15). En el de framing se suele
encontrar (entre otras cosas) el CRC de los otros 31 (aunque depende de la
configuración), de manera que si un determinado frame está mal, se le puede
notar y actuar en consecuencia.
11
Voz dobre IP
Telefonía IP
La telefonía IP, necesita un elemento que se encargue de transformar las
ondas de voz en datos digitales y que además los divida en paquetes susceptibles
de ser transmitidos haciendo uso del protocolo IP. Este elemento es conocido
como Procesador de Señal Digital (DSP), el cual está ya disponible y utilizan los
Teléfonos 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 través del DSP pero a la
inversa con lo cual el receptor podrá recibir la señal analógica correspondiente a la
voz del emisor.
La transmisión de paquetes de voz según la forma expuesta, es similar a la
transmisión de un correo electrónico 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" algún paquete, es necesario solicitar la retransmisión
del mismo y su recuperación es factible. Pero en el caso de la transmisión 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 pérdidas y de conseguir una tasa de
transmisión mínima hacen prácticamente necesaria la implantación de sistemas de
Calidad de Servicio (QoS: Quality of Services). Estos sistemas suponen hoy en día
el gran reto de la industria ya que garantizar "Quality of Service Over IP" supondrá
la inmediata implantación de los sistemas de transmisión de voz.
A modo de resumen el verdadero problema hoy en día es que la Telefonía
Conmutada establece circuitos virtuales dedicados entre el origen y el destino y
ahí la calidad es innegable y segura. Por el contrario la transmisión 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 lógicas
deficiencias en la transmisión de paquetes de voz.
A continuación se plantean otras cuestiones referentes a esta tecnología y
que tienen que ser obligatoriamente consideradas a la hora de llevar a cabo una
12
Voz dobre IP
posible implantación real de un sistema de telefonía IP para uso comercial o
profesional:
Ancho de Banda Necesario
Hasta hace muy poco tiempo el ancho de banda necesario para la
transmisión de voz y vídeo 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
según distintos algoritmos (GSM, G.723.1, G.711, G.729) los cuales se
caracterizan por conseguir mayores ratios de compresión 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 añade al paquete
de voz digitalizado y comprimido una serie de cabeceras para su correcto
transporte a través de la red, lo que hace que el ancho de banda necesario se
incremente hasta unos 16 Kbps.
Hay que considerar así mismo el parámetro denominado "supresión de
silencio". Con este parámetro activado, se consigue que la transmisión de
paquetes (uso de ancho de banda) se reduzca a las situaciones en que los
agentes están 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
tamaño medio de un paquete de voz durante una conversación es de 8 Kbps.
Con todo lo anterior se puede afirmar que con un canal B de cualquier línea
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 comunicación de 8 llamadas
simultáneas. Esta situación suele coincidir con las dimensiones de cualquier
central de una PYME (Pequeña y Mediana Empresa). Esto viene a demostrar que
13
Voz dobre IP
las necesidades de ancho de banda para este tipo de aplicaciones están al
alcance de prácticamente cualquier empresa.
Calidad en la Transmisión de La Voz
Referente a la calidad de la transmisión de la voz, todos los fabricantes e
investigaciones hacen referencia a tres factores determinantes.
Codificadores de Voz: influyen en la digitalización de la voz en paquetes de datos
que contienen voz y que serán transmitidos por la red IP, también influyen por el
retardo necesario para la descompresión de esos paquetes voz, lo que imputa un
retardo añadido a la comunicación.
Cancelación de Eco: requerimiento necesario para una comunicación a través de
Telefonía IP, que elimina de forma automática y en tiempo real posibles ecos, ya
que si no lo hiciera haría inteligible la comunicación.
Latencia: tiempo necesario para que la voz viaje de un extremo al otro, incluyen
los tiempos necesarios para la compresión, transmisión y descompresión. Este
tiempo tiende a minimizarse pero jamás podrá ser suprimido. Actualmente los
tiempos que se están obteniendo de latencia giran alrededor de 120 ms.
Estándares
Actualmente existen estándares que regulan este tipo de comunicaciones,
estándares que provienen de organismos internacionales de estandarización como
el ITU (International Telecommunication Union) que ha establecido unas normas
para la interconexión de los distintos elementos que intervienen en una
comunicación sobre Telefonía IP.
El estándar que regula este tipo de comunicaciones es el H.323 de la ITU.
Esta norma realmente es una serie de normas para la transmisión de datos
multimedia (audio, vídeo 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
transmisión en tiempo real de los paquetes de voz.
El protocolo H.323 ha sido adoptado prácticamente por todas las empresas
líderes en este sector como Netscape, Microsoft, Intel, Vocaltec. La adopción de
este estándar permite la interconexión de equipos y software de cualquier
fabricante que lo haya adoptado.
Por tanto es lógico deducir que en la actualidad cualquier empresa que
quiera trabajar en servicios de VoIP debe adoptar este estándar en todos sus
desarrollos. De esta manera se garantizará una perfecta integración 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 Telefonía IP, mejorando la calidad
de la información intercambiada en cada sesión. Por ejemplo un usuario podría
navegar por información on-line, antes de realizar la consulta a un operador. Una
vez en comunicación con el operador, se podría trabajar con un documento
compartido a través de la pantalla. De esta forma se consigue sistemas de una
gran calidad en el servicio a ofrecer, además de reducir de forma considerable el
costo de líneas telefónicas y de Distribuidores Automáticos de Llamadas (ACD).
15
Voz dobre IP
Redes Privadas virtuales de Voz:
Esta aplicación consiste en la interconexión de las centrales telefónicas a
través de la red IP corporativa, de manera que se puede realizar una llamada
desde una extensión de la oficina A otra extensión de la oficina B a través de la
red de datos de la empresa, produciéndose esta llamada de forma gratuita ya que
se aprovecha la infraestructura de datos ya existente. Un ejemplo claro de este
servicio serían los bancos y su red de oficinas.
Centros de llamadas por el WEB:
Si una compañía tiene su información disponible en un Web en Internet, los
usuarios que visitan este Web podrían no solo visualizar la información que esta
compañía les ofrece, sino que podría establecer una comunicación con una
persona del departamento de ventas sin necesidad de cortar la conexión. De esta
manera el operador de ventas cuando atienda la llamada tendrá en su pantalla la
misma información que esta viendo el usuario. Esta aplicación tiene las siguientes
ventajas:
Al ser la llamada a través de Internet, para el usuario no tiene costo
adicional, aprovecha la llamada telefónica que tenía establecida para la
comunicación de datos, para mantener también la comunicación de voz.
El usuario puede mantenerse on-line mientras habla con un operador de
ventas.
El cliente trata con operadores humanos, que le podrán asesorar, esta
característica mejorará sin lugar a duda el resultado de un sistema de comercio
electrónico.
El operador puede cerrar la venta de manera más fácil ya que el usuario es
bastante precavido para dar los datos de su tarjeta de crédito en una pagina Web
por temas de seguridad que todos conocen, sin embargo no tendrá ningún
16
Voz dobre IP
inconveniente de dar esos datos verbalmente al operador de ventas, teniendo el
usuario plena garantía de que sus datos están a salvo.
Aplicaciones de FAX:
Al igual que se hace con la voz, cabe la posibilidad de realizar
transmisiones de FAX sobre redes de Telefonía IP, consiguiendo de esta manera
reducir de forma significativa los costos de una empresa en transmisión 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 seguirán recibiendo a través de una máquina de
fax convencional. Una aplicación típica en este tema es el envío masivo de fax, ya
que el usuario sólo enviará una copia del fax que desea enviar, así como la lista
de números telefónicos de destino y el sistema se encargará de realizar todos los
envíos enrutando los faxes al punto desde donde la llamada de destino es más
económica.
Multiconferencia:
La telefonía IP permite la conexión de 3 o más usuarios simultáneamente
compartiendo las conversaciones de voz o incluso documentos sobre el que todos
los miembros de la multiconferencia pueden participar en la revisión, 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 sección se analizan por separado tanto las ventajas como los
inconvenientes del uso de los servicios IP en los ámbitos más comunes. Así
mismo se analizan los aspectos más relevantes que impiden una rápida
implantación de estos servicios:
17
Voz dobre IP
Ventajas:
Los servicios de VoIP presentan una multitud de ventajas en todos los
aspectos. Su enumeración y explicación debe de realizarse de forma sencilla y
transparente al objeto de hacer llegar a los posibles usuarios la bondad de su
implantación en un futuro no muy lejano. Hay que evitar la confusión y prematuro
rechazo ante algo que se plantea como la solución universal y que no se termina
de entender. En esta línea destacan tres grandes bloques:
Entorno empresarial:
Amplia reducción en los costos de la factura telefónica. Los costos de todo
tipo de llamadas se equipararán al de una llamada local de forma que la reducción
en los costos del tráfico de voz será a todas luces muy importante.
Nuevas posibilidades de marketing directo y potenciación del servicio de
atención al cliente. Podrán implantar la filosofía "Push 2 Talk" que consiste en un
icono situado en una página Web a través del cual un navegante podrá dialogar
con personal especializado de la compañía mientras continúa navegando por la
red.
Potenciación del tele - trabajo y de los tele - trabajadores. Con una única
conexión se podrá acceder a aplicaciones corporativas, al correo vocal, atender
llamadas o buscar información sobre nuevos proyectos.
Usuarios Finales:
En este momento el usuario final que ocupe su línea de teléfono doméstica
para transmisión de datos no puede recibir comunicaciones de voz al estar la línea
ocupada. Los nuevos servicios de VoIP no sólo le permitirán atender llamadas de
forma simultánea sino que además 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 más
claro es la nueva vertiente estadounidense denominada Internet Telephony
Service Providers (ITSPs) quienes ya ofrecen todo tipo de servicios a través de
redes IP.
Inconvenientes
Si todo está tan claro, si ya existe la tecnología, si los estándares están validados
por organismos internacionales (caso del H.323 definido por la ITU), si la ley en
principio no presenta inconvenientes y si además las consultoras internacionales
presentan esta solución como la verdadera alternativa de negocio en el año 2005,
la lógica hace pensar que la implantación 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 envía al canal de transmisión y aquí no
existen soluciones que nos garanticen o permitan establecer anchos de banda,
orden de paquetes y retrasos asumibles en su transmisión. Las posibles
soluciones pasan por diferenciar los paquetes de voz de los paquetes de datos,
priorizar la transmisión de los paquetes de voz y hacer que los retrasos añadidos a
la transmisión de los paquetes no superen en ningún caso los 150 milisegundos
(recomendación de la ITU).
Distintos organismos y fabricantes empiezan a definir soluciones y
estándares, pero su aplicación o implantación no se considera posible en un
mínimo de 2 a 3 años.
Las líneas 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 relación existente entre los distintos algoritmos de
compresión de voz utilizados y el ancho de banda requerido por los mismos:
VoCodecs Ancho de Banda
(BW)
G.711 PCM 64 kbps
G.726 ADPCM 16, 24, 32, 40
kbps
G.727 E- 16, 24, 32, 40
ADPCM kbps
G.729 CS- 8 kbps
ACELP
G.728 LD-CELP 16 kbps
G.723.1 CELP 6.3 / 5.3 kbps
Tabla 1: Ancho de Banda requerido por los VoCodecs actuales
Retardo:
Una vez establecidos los retardos de procesado, retardos de tránsito y el retardo
de procesado la conversación se considera aceptable por debajo de los 150 ms.
Eco:
El eco es debido a una reflexión, habitualmente se debe a un desajuste de
impedancias.
20
Voz dobre IP
Obtener QoS:
Las líneas de trabajo actuales de cara a conseguir Calidad de Servicio en
una Transmisión IP, están basadas en:
a) Supresión de silencios y VAD (voice activity detection): Establecer diferencia
entre habla y silencio, no transmitir paquetes de silencio y generación de silencios
al otro extremo.
b) Compresión de cabeceras: Definido por los estándares 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 realimentación sobre la calidad
c) Reserva de Ancho de Banda: Implantación del estándar RSVP (Protocolo de
Reserva de Recursos) de la IETF (Internet Engineering Task Force). RSVP
incorpora reserva de ancho de banda y retardo además de establecer una lista de
acceso dinámica de extremo a extremo. Sus principales deficiencias se establecen
en su defectuoso crecimiento (solución válida en redes pequeñas) y en su
deficiente autorización y autentificación. Además 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): Asignación de un porcentaje del ancho de banda
disponible.
2.- PQ: Establecer prioridad en las colas de envío.
3.- WFQ (Weight Fair Queuing): Asignar prioridad al tráfico de menos carga.
21
Voz dobre IP
4.- DiffServ: Definido en borrador por la IETF, evita tablas en routers intermedios y
establece decisiones de rutas por paquete.
e) Control de Congestión: uso del protocolo RED (Random Early Discard), Técnica
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 recomendación, cubre los requerimientos técnicos para servicios de
telefonía visual de banda estrecha, en situaciones donde el camino de
transmisión incluye más 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 configuración multipunto y se
pueden interconectar con terminales H.320 en B-ISDN, terminales H.321 en N-
ISDN, terminales H.322 en LANs donde se garantiza la calidad del servicio,
terminales en GSTN (General Switched Telephone Network) y conexiones
inalámbricas (wireless).
Esta recomendación describe los componentes básicos 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 recomendación define la comunicación
de todos los componentes antes descritos.
Con el estándar H.323, fabricantes, proveedores de servicios e integradores
de sistemas, disponen de las herramientas necesarias para construir una solución
23
Voz dobre IP
completa y unificada: un conjunto de tecnologías capaces de soportar diversas
aplicaciones de videoconferencia.
Scope of
H.323
H.323 H.323
Terminal MCU
Non-Guaranteed QoS LAN
(Note)
H.323 H.323 H.323 H.323
Gatekeeper Gateway Terminal Terminal
GSTN Guaranteed N-ISDN B-ISDN
QOS
LAN
H.310 terminal
operating in
H.321 mode
V.70 H.324 Speech H.322 Speech H.320 H.321 H.321
Terminal Terminal Terminal Terminal Terminal Terminal Terminal Terminal
Note: A gateway may support one or more of the GSTN,
N-ISDN and/or B-ISDN connections.
Como se puede ver este estándar define un amplio conjunto de características y
funciones. Algunas son necesarias y otras opcionales, se abordara mas adelante
cada elemento antes mencionado con el objetivo de comprender el funcionamiento
e importancia del H.323 dentro de la tecnología de VoIP.
24
Voz dobre IP
DESCRIPCION DEL SISTEMA
Los componentes de un teléfono visual se comunican a través de la transmisión
de cadenas de información. Estas cadenas de información son clasificadas en
video, audio, datos, control de comunicación y control de llamada como sigue:
Las señales de audio contienen voz codificada y digitalizada a fin de
reducir el promedio de la tasa de transmisión de las señales de
audio.
Las señales de video contienen movimiento en tiempo real codificado
y digitalizado. La señal de video esta acompañada por un control de
señal de video.
Las señales de datos incluyen fotos, documentos, archivos de
computadora y otras cadenas de datos.
Las señales de control de comunicaciones son usadas para
administrar el intercambio, apertura y cierre de los canales lógicos, el
modo de control y otras funciones son parte del control de
comunicaciones.
Las señales de control de llamada son usadas para establecer,
terminar y otras funciones básicas de control de llamada
Las características de las cadenas de información mencionadas anteriormente son
descritas en la norma H.225 que se vera mas adelante.
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 telemático,
recomendación 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,
25
Voz dobre IP
cumplir la recomendación H.225, una interfase de red y una unidad de codificación
de audio.
La unidad de codificador de video y las aplicaciones de datos de usuario
son opcionales.
Scope of Recommendation H.323
Video Codec
Video I/O equipment H.261, H.263
Receive
Path
Delay
Audio Codec
Audio I/O equipment
G.711, G.722,
H.225.0 Local Area
G.723, G.728,
Layer Network
G.729
Interface
User Data Applications
T.120, etc.
System Control
H.245 Control
System Control Call Control
User Interface H.225.0
RAS Control
H.225.0
ELEMENTOS TERMINALES EN LA RECOMENDACIÓN H.323
Los siguientes elementos están dentro de la recomendación H.323 y están
por lo tanto sujetos a estandarización:
El codificador de video (Video Codec) basado en la recomendación
(H.261) como su nombre lo indica, codifica el video de alguna fuente
de video como puede ser una cámara de video, para la transmisión y
26
Voz dobre IP
decodificación posterior del video recibido, el cual será desplegado
por ejemplo en un monitor.
El codificador de audio (Audio Codec) basado en la recomendación
(G.711) como su nombre lo indica, codifica la señal de audio de un
micrófono para la transmisión y decodificación del audio recibido el
cual encontrara como salida un altavoz.
El canal de datos soporta aplicaciones telemáticas tales como
pizarrones electrónicos, transferencia de imágenes, intercambio de
archivos, accesos a base de datos, conferencias audio gráficas, etc.
La estandarización de la aplicación de datos para conferencia audio
grafica en tiempo real esta basada en la recomendación T.120
La Unidad de Control del Sistema (recomendación H.245, H.225)
provee señalización para la propia operación de la terminal H.323.
Esta provee control de llamada, capacidad de intercambio,
señalización de órdenes e indicaciones así como mensajes para
apertura y descripción completa del contenido de los canales lógicos.
Recomendación 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. Además esto
mejora el desempeño del entramado lógico, numero de secuencia,
detección de errores y corrección apropiada para cada tipo de medio.
INTERFASE LAN
La interfase LAN es una implementación específica y esta fuera del ámbito de esta
recomendación, sin embargo la interfase LAN podría proveer los servicios
descritos en la recomendación H.225. Esto incluye lo siguiente:
Un servicio extremo a extremo (end-to-end) confiable (TCP, SPX) es
obligatorio para el canal de control (recomendación H.245), canales
de datos, y canal de señalización de llamada.
27
Voz dobre IP
Un servicio extremo a extremo (end-to-end) no confiable es
obligatorio para canales de audio, canales de video y canal RAS
(Registration,Admisión,Status)
Estos servicios descrito pueden ser duplex o simples, unicast o multicast
dependiendo de la aplicación, la capacidad de las terminales y la configuración de
la LAN.
CODIFICADOR DE VIDEO (VIDEO CODEC)
El codificador de video es opcional. Todas las terminales H.323
proveedoras de comunicación de video deben ser capaces de codificar y
decodificar video de acuerdo a la recomendación H.261 QCIF. Opcionalmente,
una terminal puede ser también 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 resolución más alta, esta debe soportar
también H.261 CIF. Los codificadores H.261 y H.263 en la LAN deben ser usados
sin corrección de errores BCH y sin corrección de errores en trama.
Otros codificadores de video y otros formatos de imagen pueden ser
también usados vía la negociación de H.245. Más de un canal de video puede ser
transmitido o recibido, según sea la negociación 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 después una fuentes de
video. La terminal H.323 puede opcionalmente recibir más de un canal de video,
por ejemplo, para desplegar múltiples participantes en una multiconferencia
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 recomendación 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 vía H.245 para un
28
Voz dobre IP
cierto modo, pero el codificador ignorara aquellas solicitudes si estas no están en
modo de prioridad alta. Los decodificadores, los cuales indican capacidad para un
a opción de algoritmo en particular, deben ser capaces también de aceptar tramas
de bits de video, que no estén haciendo uso de esa opción.
Las terminales H.323 deben ser capaces de operar en tasas de bits de
video asimétricas, tasas de trama y si más de una resolución de imagen es
soportada, en resolución de imágenes. Por ejemplo, esto permitirá a una terminal
CIF tener la capacidad de transmitir QCFI mientras esta recibiendo imágenes CIF.
Cuando cada canal de video lógico es abierto, el máximo modo de
operación para ser usado en ese canal, se le describe al receptor en el mensaje
OpenLogicalChannel. El máximo modo indicado incluye el formato máximo de
imagen, opciones de algoritmo, máxima tasa de bits del codificador, etc. La
cabecera dentro del canal lógico de video indica que modo es actualmente usado
para cada imagen, dentro del estado máximo. Por ejemplo, un canal lógico de
video abierto para formato CIF puede transmitir CIF, QCIF o imágenes SQCIF
pero no 4CFI o 16CFI.
CODIFICADOR DE AUDIO (AUDIO CODEC)
Todas las terminales H.323 deberían tener un codificador de audio (audio
codec). Todas las terminales H.323 deben ser capaces de codificar y decodificar
voz de acuerdo a la recomendación 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
codificación esta descrito en la recomendación H.245.
La Terminal H.323 debes ser capaz de una operación asimétrica para todas
las capacidades de audio, es decir debe poder trabajar a la hora de enviar
29
Voz dobre IP
información con la recomendación G.711 y a la hora de recibir la información con
la recomendación G.728.
La Terminal H.323 puede opcionalmente enviar más 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
periódicamente en un intervalo determinado por la recomendación 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 después de un completo
intervalo múltiple 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 máximo parámetro 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 máximo retardo jitter está en la entrada de la
capa de transporte.
CANAL DE DATOS
Uno o más canales de datos son opcionales: los canales de datos pueden
ser unidireccionales o bidireccionales dependiendo de los requerimientos de la
aplicación de datos.
La recomendación 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
aplicación opcional de datos es implementada usando una o mas de las
recomendaciones de la Unión Internacional de Telecomunicaciones (ITU), las
cuales pueden ser negociadas vía la recomendación H.245 el equivalente de la
aplicación T.120.
30
Voz dobre IP
CANALES DE DATOS T.120
Hay 2 formas de establecer una conexión T.120 dentro del contexto de una
llamada H.323. La primera es el establecimiento de la conexión T.120 durante una
llamada H.323 como una parte inherente de la llamada, usando los procedimientos
de la recomendación H.245 para la apertura de los canales lógicos. La segunda es
el establecimiento de la conexión T.120 previa al establecimiento de la llamada
H.323.
La capacidad de intercambio toma lugar y un canal lógico bidireccional debe
ser abierto para la conexión T.120 de acuerdo al procedimiento normal de la
recomendación H.245 indicando que una nueva conexión deberá ser creada
como se describe a continuación.
La apertura de un canal lógico 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 lógico bidireccional de la recomendación
H.245.
Para abrir el canal lógico, la entidad que inicializa debe enviar un mensaje
open Logical Channel indicando que un canal de datos T.120 será abierto en los
parámetros de canal lógico hacia delante (forward Logical Channel Parameters)
así como en los parámetros de canal lógico hacia atrás (reverse Logical Channel
Parameter).
El equipo origen puede decidir si incluir ó no una dirección de transporte en
el mensaje open Logical Channel y si el equipo destino acepta este canal lógico,
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
dirección de transporte para ser usada para establecer la conexión T.120 si el
equipo origen no le ha proporcionado ninguna dirección. De lo contrario el equipo
31
Voz dobre IP
destino no podrá establecer la conexión. En ambos casos, la dirección de
transporte para la conexión T.120 debe ser llevada en un parámetro de pila (stack)
separado.
La entidad que transmite la dirección de transporte debe estar preparada
para aceptar la conexión T.120. La entidad receptora de la dirección de transporte
debe iniciar el establecimiento de la conexión T.120 usando la previa dirección de
transporte recibida.
En ambos mensajes open Logical Channel y open Logical Channel Ack, el
parámetro associate Conference debe ser puesto a Falso.
NOTA: La operación completa de la recomendación T.120 después del completo
establecimiento de la conexión esta fuera del alcance de este trabajo, se
recomienda consultar la bibliografía.
En el caso donde la conexión 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 conexión T.120 con la llamada
H.323. Los procedimientos de la recomendación H.245 suelen ser usados para
abrir un canal lógico bidireccional para la recomendación T.120 como se describe
a continuación:
La apertura de un canal lógico bidireccional para T.120 puede ser iniciada
por ambas entidades, enviando el mensaje open Logical Channel y después
siguiendo los procedimientos para un canal lógico bidireccional de la
recomendación H.245. El que originad el establecimiento de la conexión debe
incluir información de la identificación para la ya existente conexión en el mensaje
open Logical Channel para indicar al destino cual conexión T.120 (si existen
diferentes) será asociada.
Para abrir el canal lógico, la entidad que inicializa la conexión debe enviar
un mensaje open Logical Channel indicando que un canal de datos T.120 será
32
Voz dobre IP
abierto en los parámetros de canal lógico hacia delante (forward Logical Channel
Parameters) así como en los parámetros de canal lógico hacia atrás (reverse
Logical Channel Parameter). Si el equipo destino acepta este canal lógico, debe
confirmar la apertura del canal usando el mensaje open Logical Channel Ack al
equipo origen en el cual puede incluir su identificación local para la conexión de
transporte, en ambos mensajes el parámetro associate Conference deberá ser
puesto a verdadero (True).
Como información de identificación la dirección local de transporte de la
conexión inicial de transporte de la conexión T.120 debe ser provista en un
parámetro de pila (Stack) por separado. Además el parámetro external Reference
puede ser usado para proveer más información sobre la conexión T.120 a la que
será asociada.
Si cualquiera de esta información no esta disponible para el equipo origen,
este puede omitir los valores respectivos.
NOTA: Si la dirección de transporte no es especificada y las dos terminales
extremos comparten más de una conexión T.120 esta puede ser ambigua para la
conexión T.120 a la que es referida.
FUNCION DE CONTROL H.245
La función de control H.245 usa el canal de control H.245 para llevar de
extremo a extremo la administración de la operación del control de mensajes de la
entidad H.323, incluyendo la capacidad de intercambio, apertura y cierre de los
canales lógicos así como solicitud de preferencia de modo, control de flujo de
mensajes y ordenes e indicaciones generales.
La señalización de la recomendación H.245 es establecida entre los dos
puntos extremos, un extremo y un controlador multipunto (Multipoint Controller-
MC) o un punto extremo terminal y un Gatekeeper. El punto extremo debe
33
Voz dobre IP
establecer exactamente un canal de control H.245 para cada llamada en la que
cada punto extremo terminal esta participando.
Este canal debe usar los mensajes y procedimientos de la recomendación
H.245. Nótese 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 lógico 0. El canal lógico 0 debe ser
considerado para permanentemente abierto para el establecimiento de el canal de
control H.245 hasta la terminación de este canal. Los procedimientos normales
para la apertura y cierre de los canales lógicos no aplicaran para el canal de
control H.245.
La recomendación H.245 especifica un número de entidades de protocolo
independiente las cuales soportan la señalización extremo a extremo. Una
entidad de protocolo es especificada por su sintaxis (mensajes), semántica y los
procedimientos de establecimiento los cuales especifican el intercambio de
mensajes y la interacción con el usuario. Las terminales H.323 deben soportar la
sintaxis, semántica y procedimientos de las siguientes entidades de protocolo.
Determinación Maestro/Esclavo
Capacidad de Intercambio
Señalización de Canales lógicos
Señalización Bidireccional de Canales lógicos
Señalización de Cierre de Canal lógico
Modo de Solicitud
Determinación de Retardo Durante el Viaje
Mantenimiento de una señalización cíclica.
Indicaciones y órdenes generales deben ser elegidas del establecimiento del
mensaje contenido en la recomendación H.245. Además otras señales de
órdenes e indicaciones pueden ser enviadas, las cuales han sido específicamente
34
Voz dobre IP
definidas para ser transferidas en la banda dentro de las cadenas de audio, video
o datos.
Los mensajes H.245 caen dentro de cuatro categorías: Solicitud,
Respuesta, Orden e Indicación. Los mensajes de Solicitud y Respuesta son
usados por las entidades de protocolo. Los mensajes de Solicitud requieren una
acción específica 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 acción específica, pero
no requieren una respuesta. Los mensajes de Indicación son solamente
informativos y no requieren de ninguna acción o respuesta. Las terminales H.323
deben responder a todas las solicitudes y ordenes H.245, y deben transmitir
indicaciones para reflejar el estado de la terminal.
Las terminales H.323 deben ser capaces de analizar sintáctica 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 indicación H.245, user Input Indicación, esta disponible para de
transporte de usuario y soportar la entrada de caracteres alfanuméricos de un
teclado o su equivalente para las señales DMTF usadas en telefonía analógica.
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 información etc. Las terminales H.323 deben soportar la transmisión
entrada de usuario de los caracteres 0-9,‟*‟ y „#‟. La transmisión 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
35
Voz dobre IP
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 transmisión y recepción, así como
un método por el cual la terminal puede describir su capacidad para operar en
diferentes modos simultáneos.
Las capacidades de recepción describe la habilidad de la terminal para
recibir y procesar cadenas de información de entrada. Los transmisores deben
limitar el contenido de la información transmitida de acuerdo a la capacidad que el
receptor le haya indicado que es capaz de recibir. La ausencia de de una
capacidad de recepción indica que la terminal no puede recibir información (es
solo un transmisor).
Las capacidades de transmisión describen la habilidad de la terminal para
transmitir cadenas de información. Las capacidades de transmisión sirven para
ofrecer una elección de los posibles modos de operación, entonces el receptor
puede solicitar el modo en el cual desea recibir la información. La ausencia de una
capacidad de transmisión indica que la terminal no esta ofreciendo la opción de
elegir un modo preferido para recibir la información (pero esta puede transmitir
cualquier modo dentro de la capacidad de recepción).
La terminal de transmisión asigna cada modo individual que esta es capaz
de operar, con un numero, dentro de una tabla (capability Table).
Estos números 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,
36
Voz dobre IP
G.728} significa que la terminal puede operar en uno de esos modos de audio,
pero no más de uno.
Estas estructuras alternative CapabilitySet son agrupadas dentro de las
estructuras simultaneous Capabilities. Cada estructura simultaneous Capabilities
indica el establecimiento del modo que cada terminal es capaz de usar
simultáneamente. Por ejemplo, una estructura simultaneous Capabilities contiene
las dos estructuras alternative CapabilitySet {H.261, H.263} y {G.711, G.723,
G.728}, esto significa que la terminal puede operar con dos canales de video y un
canal de audio simultáneamente. 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 señalar dependencias entre modos
operando bajo diferentes establecimientos o modos que pueden tener uso
simultáneo. 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 también con el
H.262 codificador de video (video codec), pero no así con la complexión-baja de
G.711 codificador de audio (audio codec).
Las terminales pueden agregar capacidades durante la sesión de
comunicación por medio de la emisión 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.
37
Voz dobre IP
SEÑALIZACION DEL CANAL LOGICO
Cada canal lógico lleva la infamación del transmisor a más de un receptor y
es identificado por el número del canal lógico el cual es único para cada dirección
de transmisión.
Los canales lógicos son abiertos y cerrados usando los mensajes open
Logical Channel y close Logical Channel y los procedimientos H.245. Cuando un
canal lógico es abierto, el mensaje open Logical Channel describe completamente
el contenido del canal lógico, incluyendo el tipo de medio, el algoritmo en uso,
cualquier opción y toda la información necesaria para que el receptor interprete el
contenido del canal lógico. Los canales lógicos pueden ser cerrados cuando existe
un periodo de inutilidad. La apertura del canal lógico puede estar inactiva si la
información de la fuente que desea establecer la comunicación no ha sido
enviada.
La mayoría de los canales en H.323 son unidireccionales, entonces la
operación asimétrica esta permitida, en la cual el número y tipo de cadenas de
información es diferente en cada dirección. Sin embargo si el receptor es capaz de
trabajar con ciertos tipos de modos de operación simétrico 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 dirección
de transmisión. Ciertos tipos de medio, incluyendo protocolo de datos como T.120,
requieren inherentemente un canal bidireccional para su operación. En tales casos
un par de canales lógicos unidireccionales, uno en cada dirección, pueden ser
abiertos y asociarse juntos para formar un canal lógico bidireccional usando el
procedimiento de apertura de un canal lógico bajo la recomendación H.245. Como
los pares de los canales asociados no necesitan compartir el mismo número de
canal lógico entonces los números de los canales lógicos son independientes en
cada dirección de transmisión.
Los canales lógicos deben ser abiertos usando el siguiente procedimiento:
38
Voz dobre IP
La terminal que requiere el procedimiento de apertura del canal debe enviar
un mensaje como se describe en la recomendación H.245. Si el canal lógico es
usado para llevar un tipo de medio usando RTP (audio o video), el mensaje
OpenLogicalChannel debe incluir el parámetro media Control Channel incluyendo
la dirección 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 recomendación H.245. Si el canal
lógico se usa para llevar una clasificación de medio RTP (audio o video), el
mensaje Open Logical Channel Ack debe incluir ambos, tanto el parámetro de
medio transport Channel incluyendo la dirección de transporte RTP para el canal
del medio y el parámetro media Control Channel incluyendo la dirección de
transporte para el canal hacia delante RTCP.
La clasificación del medio (como datos T.120) el cual no usa RTP/RTCP
debe omitir el parámetro media Control Channel.
Si un canal inverso correspondiente es abierto para una sesión RTP
existente (identificada por RTP session ID), el transporte de las direcciones media
control Channel intercambiado por el proceso OpenLogicalChannel debe ser
idéntico para las que son usadas del canal en la dirección opuesta. Deberá ocurrir
una colisión donde ambas terminales intenten establecer una sesión conflictiva
RTP al mismo tiempo, la terminal que tome el papel de administrador maestro
debe rechazar el intento conflictivo, esto se puede ver el recomendación H.245. El
intento de la apertura de canal lógico rechazado OpenLogicalChannel debe volver
a intentarse mas tarde.
CARACTERISTICAS DEL GATEWAY
El Gateway debe proveer la apropiada interpretación entre los formatos de
transmisión (por ejemplo H.225.0 de/para H.221) y entre los procedimientos de
comunicación (por ejemplo H.245 de/para H.242). El Gateway debe también
desempeñar el establecimiento de llamada.
39
Voz dobre IP
En general el propósito del Gateway (cuando no esta operando como MCU)
es reflejar las características 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.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 están dentro de la LAN) no son requeridas.
El Gateway tiene las características de una Terminal H.323 o MCU (Multi
Controller Unit) en la LAN y por otro lado las características de una terminal de red
de circuitos conmutados o un MCU en la Red de Circuitos Conmutados. El
Gateway provee la conversión necesaria entre los diferentes tipos de terminales.
Nótese que el Gateway puede inicialmente operar como una terminal, pero
después utilizando señalización 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 envía datos T.120 entre la Red de Circuitos Conmutados y
la LAN, debe contener un proveedor de Sistema Controlador Multipunto T.120
MCS (Multipoint Controller System) el cual conecta al proveedor de Sistema
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.
40
Voz dobre IP
Ejemplos de las configuraciones de un Gateway H.323 son mostrados en la
figura siguiente:
H.323 SCN
Conversion
LAN Terminal Terminal SCN
Function
Function Function
Gateway A
H.323 SCN
Conversion
LAN MCU Terminal SCN
Function
Function Function
Gateway B
H.323 SCN
Conversion
LAN Terminal MCU SCN
Function
Function Function
Gateway C
H.323 SCN
Conversion
LAN MCU MCU SCN
Function
Function Function
Gateway D
Configuraciòn del Gateway en H.323
Gateways ínter operando con solo terminales de voz en GSTN o ISDN
deben generar y detectar señales DMTF correspondientes a H.245 user Input
Indication para los caracteres 0-9, *, #.
41
Voz dobre IP
La función de conversión provee la conversión necesaria del formato de
transmisión, control, video y/o cadenas de datos entre las diferentes
recomendaciones de la terminal. Como mínimo, el Gateway debe proveer:
función de conversión para el formato de transmisión.
Establecimiento y procedimiento de señales de llamada.
Control y procedimiento de señales de comunicación.
El Gateway desempeña la conversión apropiada entre la señalización de la
llamada H.225.0 y el sistema de señalización de la Red de Circuitos Conmutados
(Q.931, Q.231, etc.).
Todas las señalizaciones 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 señalizaciones 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 señalización de llamada, de
la Red de Circuitos Conmutados requiere un estudio más amplio, por lo que en
este trabajo se abordara solo una parte del tema.
Esta recomendación describe la conexión de una terminal H.323 en la LAN
a una terminal externa en una Red de Circuitos Conmutados a través del
Gateway. El actual número de terminales H.323 que pueden comunicarse a través
del Gateway no es objeto de estandarización. De manera similar el número de
conexiones de Redes de Circuitos Conmutados, el número de conferencias
simultáneas independientes, la conversión de funciones audio/datos/video y la
inclusión de funciones multipunto son dejadas a los diferentes fabricantes.
Un Gateway puede ser conectado vía Red de Circuitos Conmutados a otros
Gateways para proveer una comunicación entre terminales H.323, las cuales no
están en la misma LAN. Equipos que proveen interconexión transparente entre
LANs sin usar la recomendación H.320 (como rutas y marcado remoto en las
42
Voz dobre IP
unidades) no son Gateways como es definido en el ámbito de esta
recomendación.
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. Más de un Gatekeeper puede
estar presente y comunicarse con otro en un modo no especificado. El
Gatekeeper es lógicamente separado de lo equipos extremo, sin embargo, su
implementación física 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:
Resolución de direcciones: El Gatekeeper debe desempeñar direcciones
seudónimas para resolver Direcciones de Transporte. Esto debe hacerse
usando una tabla de resolución la cual es actualizada usando los mensajes
de Registro. Otros métodos de actualización de la tabla de resolución son
permitidos también.
Control de Admisión: El Gatekeeper debe autorizar el acceso LAN usando
los mensajes ARQ/ACF/ARJH225.0. esto puede ser basado en una
autorización 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 administración del ancho de
banda.
43
Voz dobre IP
IMPORTANCIA DEL ESTÁNDAR H.323
H.323 es el primero y sigue siendo el mas importante protocolo estándar de
comunicaciones multimedia, a través de este se logra una convergencia de voz,
video y datos. Construido para redes de paquetes de datos, H.323 a encontrado
una gran aceptación en las redes IP, teniendo una gran importancia en VoIP.
Como otros protocolos de comunicaciones, H.323 es un estándar publicado
por la ITU (Internacional Telecommunications Union). Este fue aprobado como un
estándar internacional para voz, video y datos, definiendo como algunos
dispositivos por ejemplo computadoras, teléfonos, celulares, PDAs, teléfonos
inalámbricos y sistemas de videoconferencia, dan una nueva pauta a la tecnología
y al usuario final.
El estándar H.323 es la primera especificación completa bajo la cual, los
productos desarrollados se pueden usar con el protocolo de transmisión más
ampliamente difundido (IP). Es debido a esto que existe tanto interés y
expectación entorno al H.323 porque apareció en el momento más adecuado,
porque se tienen amplias redes ya instaladas y la mayoría de las aplicaciones son
basadas en IP, tales como el acceso a la Web. Además, los ordenadores
personales son cada vez más potentes y por lo tanto, capaces de manejar datos
en tiempo real tales como voz y vídeo.
Como logros principales de esta recomendación podemos señalar:
La estandarización de los protocolos permite a los diversos fabricantes
evolucionar en conjunto.
Los usuarios no deben preocuparse sobre las posibilidades de su
interlocutor, existiendo una negociación de las capacidades de cada punto
de la línea.
44
Voz dobre IP
Debido a su apoyo sobre IP es independiente del tipo de red física que lo
soporta, permitiendo la integración con las grandes redes IP actuales.
Por su propia estructura, es independiente del hardware, si bien permite ser
implementado en los ordenadores actuales, también se desarrolla hardware
específico como Teléfonos IP y consolas de videoconferencia.
Otra característica importante es el control de tráfico que se puede realizar
dentro de la red.
De esta forma no deben producirse caídas importantes de rendimiento en
las redes de datos.
La negociación previa permite conectar terminales de muy diversas
características, como pueden ser teléfonos de voz, consolas de
videoconferencia, ordenadores, etc.
Se ha llevado una rápida adopción del H.323. El gráfico siguiente explica por sí
mismo esta tendencia.
Figura.2.1.1 Crecimiento del mercado H.323
45
Voz dobre IP
H.323 PERSPECTIVA HISTORICA
Anteriormente al H.323, el ITU se enfocó exclusivamente en la
estandarización de las redes globales de telecomunicaciones. Por ejemplo, en
1985 se comenzó el trabajo en la especificación que define el envío de imagen y
voz sobre redes de circuitos conmutados, tales como RDSI. La ratificación de la
norma (H.320) tuvo lugar 5 años después (fue aprobada por el CCITT en
Diciembre de 1990). Sólo 3 años después se dispuso de equipos que cumplieran
En Enero de 1996, un grupo de fabricantes de soluciones de redes y de
ordenadores propuso la creación de un nuevo estándar ITU-T para incorporar
videoconferencia en la LAN. Inicialmente, las investigaciones se centraron en las
redes de área local, pues éstas son más fáciles de controlar. Sin embargo, con la
expansión de Internet, el grupo hubo de contemplar todas las redes IP dentro de
una única recomendación, lo cual marcó el inicio del H.323.
El H.323 soporta vídeo 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
recomendación para "los sistemas multimedia de comunicaciones en aquellas
situaciones en las que el medio de transporte sea una red de conmutación de
paquetes que no pueda proporcionar una calidad de servicio garantizada.
Nótese que H.323 también soporta videoconferencia sobre conexiones
punto a punto, telefónicas y RDSI. En estos casos, se debe disponer un protocolo
de transporte de paquetes tal como PPP.
Una recomendación del ITU.
Aunque se hable del H.323 como de un estándar, el ITU lo considera una
recomendación. Como cualquier recomendación de un origen similar, está abierta
a la interpretación de diferentes fabricantes. Una ventaja es que deja libertad a los
46
Voz dobre IP
fabricantes para implementar capacidades que cumplan con los requerimientos de
aplicaciones especiales.
ESTABLECIMIENTO DE LLAMADAS
El paso previo al establecimiento de una comunicación entre dos terminales
es la resolución de la dirección IP del destinatario de la llamada. En este proceso
el usuario llamante invoca mediante H.225 RAS al Gatekeeper para conocer la
dirección IP del destinatario. Si el proceso de registro del destinatario fue
satisfactorio el Gatekeeper conocerá su dirección IP, esta dirección física será
entregada al llamante para que inicie la llamada. En este punto hay que recordar
que el Gatekeeper tiene la autorización para denegar una llamada, es decir, puede
no autorizar al llamante y así mismo, puede no autorizar al llamado a atender la
llamada. Toda comunicación de naturaleza H.225 RAS es transportada sobre
UDP.
Si el Gatekeeper ha autorizado la llamada a continuación entra en juego la
especificación H.225.0 Call Control. Este protocolo deriva de Q.931 y aporta el
servicio básico de llamada. Call Control será empleado por el llamante para
ponerse en contacto con el usuario deseado. Como evolución 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 proliferación de terminales H.323 y algoritmos de compresión ha
obligado a incorporar un canal por el que los participantes en una conversación
acuerden las prestaciones de terminal que emplearan y qué tipo de compresión
aplicarán a la voz o el vídeo. Este canal de negociación es desarrollado a través
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 información se codifican respectivamente según las especificaciones
47
Voz dobre IP
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 información para la correcta secuenciación y posterior
reconstrucción de caudal de voz o video.
El proceso descrito es el procedimiento básico de establecimiento de
llamadas. A partir de la versión 2 de H.323 se han incorporado numerosas
facilidades de usuario conocidas como Servicios Suplementarios. Estos servicios
se reúnen sobre la especificación H.450.1 que a su vez se sitúa 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 desvío de llamada y H.450.6
para la llamada en espera.
Estándar 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 cálculo, hacer un dibujo estilo pizarra, y que sea compartido entre
ambos conferenciantes, etc. Mucho más todavía 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 estándar 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, asegurándose la integridad de los datos. Además este estándar 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 conexión de los terminales a este puede ser en estrella,
48
Voz dobre IP
en cadena, en cascada, etc. Si el proveedor se cae, la conferencia (de datos) se
interrumpe.
En las conferencias de datos hay un 'dominio', que básicamente es la
conferencia en sí, y 'canales' dentro del dominio, que pueden ser públicos (para
difusión, broadcast) o privados entre usuarios.
Estos canales son los siguientes:
1. Canal de errores de control. Prioridad máxima.
2. Canal de anotaciones. Prioridad alta.
3. Canal de Imágenes 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
común, e independiente del medio de transporte.
T.122: Servicio de datos genérico orientado a conexión que junta varias
comunicaciones punto a punto para formar un dominio multipunto. Entre otras
cosas, proporciona difusión de datos con control de flujo, direccionamiento
49
Voz dobre IP
multipunto, busca el camino más corto entre estaciones, etc. Los problemas de
reserva y resolución de recursos se solucionan mediante testigos.
T.125: Protocolo de servicio de comunicación multipunto. Especifica los mensajes
de protocolo necesarios según T.122
T.124: Control Genérico 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 carácter opcional, T.121: Plantilla General de Aplicaciones (GAT,
General Aplication Template). Define una plantilla con la funcionalidad de una
aplicación. Permite que quien se enfrente a programar algo de esto, se asegure de
ajustarse a la recomendación.
T.126: Protocolo de intercambio de imágenes fijas y anotaciones.
T.127: Transferencia multipunto de ficheros binarios. Permite la difusión de varios
ficheros de forma simultánea, transmisión 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.
50
Voz dobre IP
Las aplicaciones de usuario podrían 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 telefonía IP es un término usado para describir un juego de productos y
soluciones usados para transportar tráfico de voz sobre una red de datos.
Utilizando IP (Internet Protocol) como mecanismo de transporte, la telefonía 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
administración simplificada, ahorro de costos en telecomunicaciones y unificación
de servicios de mensajes.
SELECCIÓN PARA IMPLEMENTAR TELEFONIA IP
Es importante tener en cuenta que el tráfico de voz y el tráfico regular de
datos IP son dos soluciones completamente diferentes. El trafico de datos RTCP
/IP (Regular Transmisión Control Protocol / Internet Protocol) es muy flexible es
decir no da mucha importancia a una WAN con enlaces de transmisión lentos,
perdida de paquetes y recepción de paquetes fuera de secuencia. De hecho,
TCP/IP opera de esa forma, tomando datos y segmentándolos dentro de
diferentes paquetes y transmitiendo los datos vía 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 resegmentación de los datos.
Por otro lado el tráfico 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 telefonía IP depende de los paquetes que están 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 confundiría a
la persona destino que esta recibiendo la llamada. Para lograr esto, se debe
52
Voz dobre IP
incorporar nuevas y diferentes características en los Switches y Routers como
encolado (Queuing) y RTP (Real Time Control Protocol)
COMPONENTES DE TELEFONIA IP
Los componentes que deben ser sumados a la infraestructura para facilitar
la telefonía IP son los que realmente opacaran la línea 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.
53
Voz dobre IP
CALL MANAGER
CallManager provee una solución de telefonía IP basado en un software de
plataforma de procesamiento de llamada para desempeñar el papel del tradicional
PBX. EL CallManager representa una solución a gran escala y responde a las
necesidades de la telefonía IP. Se han introducido diferentes soluciones de Vos
sobre IP, por ejemplo diferentes programas de Chat como: Microsoft NetMeeting,
América 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 solución confiable, escalable y manejable
para cualquier organización de cualquier tamaño en el que se desee implementar
la telefonía IP.
LA PLATAFORMA CALL MANAGER
El Call manager es probablemente la plataforma más integral de la telefonía
IP. Este provee al resto de la arquitectura de la telefonía IP con un punto central
para el procesamiento de llamada, servicios de conexión, señalización y registro
para teléfonos IP, análogos, gateway digitales y hereda dispositivos de telefonía
como en un sistema basado en PBX. La comunicación con dispositivos de
telefonía IP esta habilitada para usar diferentes protocolos de telefonía 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 teléfonos IP a 5000 dispositivos de telefonía IP por
cada servidor. Un dispositivo IP puede ser cualquiera de los siguientes:
54
Voz dobre IP
Teléfono IP
Gateway analógico o digital
IP softphone (Software de un teléfono IP normal)
Procesador Digital de Señales
PROTOCOLOS DE TELEFONIA IP
SKINNY STATION PROTOCOL (SSP)
Es un protocolo de comunicaciones basado en el estándar SGCP (Simple
Gateway Protocol). SSP fue primero introducido como un método de comunicación
entre la primera generación de teléfonos IP, Gateways y servidores CallManager y
aun es ampliamente usado para el mismo propósito. SSP depende del servidor
CallManager para difundir la configuración y control de la información. Este es
creado en TCP/IP y utiliza los puertos TCP 2000-2002.
H.323
H.323 es un estándar ampliamente usado para audio, video y datos en
tiempo real sobre redes de paquetes. H.323 es un estándar de la ITU
(Internacional Telecommunication Union) y es parte de la familia de
protocolos H.32X. H.323 fue construido basándose en el protocolo H.320,
permitiendo la transmisión de video y audio basado en redes de paquetes como
Ethernet.
55
Voz dobre IP
MEDIA GATEWAY CONTROL PROTOCOL (MGCP)
Es utilizado como un protocolo más veloz que H.323 y SSP, utilizando UDP (User
Datagram Protocol) en oposición a utilizar TCP para la transmisión.
SIMPLIFIED MESSAGING DESK INTERFACE (SMDI)
Es un protocolo estándar 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 teléfonos IP sobre un servidor CallManager a alrededor de 10,000
teléfonos 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 lógica conocida como Grupo. Un grupo consiste de
servidores CallManager y sus dispositivos asociados como teléfonos IP, gateways
y dispositivos lógicos como SoftPhones que es una versión en Software de un
teléfono IP normal. Cuando el concepto de grupo es utilizado, todos los servidores
CallManager comparten la misma configuración de la base de datos, entonces si
un servidor CallManager falla, los demás ya tienen la configuración, entonces no
se requiere una nueva configuración manual.
La idea principal del agrupamiento (clustering), consiste en proveer
suficientes servidores para que si uno de ellos llega a fallar los demás dentro del
56
Voz dobre IP
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:
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 configuración 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 grabación de una llamada telefónica IP.
Esta puede ser usada para análisis de tráfico y funciones adicionales de
contabilidad. El servidor TFTP es usado para proveer una imagen del sistema para
los dispositivos como teléfonos IP y gateways.
Como se estructura el grupo depende de cuantos dispositivos de telefonía
IP serán soportados. Hay muchas limitaciones que se deben tomar en cuenta
antes de implementar un grupo. Un importante punto es tomar en consideración es
que un grupo no puede cruzar un enlace WAN. Todos los grupos de servidores
deben existir en la misma LAN además 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 máximo de 100 grupos
pueden ser interconectados, permitiendo soporte para cerca de 1, 000,000
57
Voz dobre IP
teléfonos IP dentro de una organización. La siguiente figura muestra el
funcionamiento de un grupo y su protección:
Agrupamiento de CallManagers
58
Voz dobre IP
Protección sobre falla
TELEFONOS IP
Los teléfonos IP proveen al usuario final una interfase dentro de la
arquitectura de la telefonía IP. Algunos soportan estándares abiertos y la
habilidad de interactuar con Microsoft NetMeeting.
Los teléfonos IP interactúan con la red con una conexión a 10/100Mbps,
aparte de tener un puerto extra para PC o cualquier otro periférico así como
también un puerto RS-232 para capacidades adicionales. Ofrecen una pantalla
LCD para desplegar un menú con sus características establecidas dejando atrás
los botones convencionales.
59
Voz dobre IP
GATEWAYS
Son dispositivos usados para conectar la infraestructura de telefonía IP a la
Red de telefonía 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
estándar SGCP, sin embargo es usado solo por una marca de proveedor en
particular, en otras palabras mientras SGCP es un estándar abierto SGP es
propiedad estandarizada de CISCO, haciendo comparación con el protocolo
HDLC que cada fabricante tiene su propia implementación.
H.323 es un estándar de la ITU. Los Gateways H.323 son mas comúnmente
encontrados en un dispositivo enrutador con gateway integrado y en comunicación
con el CallManager.
MGCP (Media Gateway Control Protocol) es un estándar también y se usa
para comunicar el enrutador-gateway y el CallManager.
60
Voz dobre IP
INTRODUCCION AL VIDEO
Las tradicionales transmisiones de video típicamente consistían de una
adiferentes líneas de interfaz de tasa básica (BRI) de ISDN conectando
propiamente estaciones terminales de videoconferencias. Estas líneas ISDN
típicamente operan en una infraestructura punto a punto utilizando la
recomendación 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 utilización de los
recursos disponibles.
Aunque algunos avanzados sistemas PBX pueden terminar las líneas BRI
(Basic Rate Interface) para sistemas de videoconferencia, las líneas BRI y las
líneas de voz están resguardadas de forma completamente separada unas de las
otras.
La videoconferencia basada en IP, por otra parte, utiliza la recomendación
H.323 permitiendo utilizar la videoconferencia sobre una variedad de medios,
incluyendo medios compartidos y conmutados como Ethernet, líneas alquiladas y
redes multiacceso sin difusión como Frame Relay y ATM (Asynchronous
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
video sobre IP las cosas se complican. Por ejemplo si se tiene una video
61
Voz dobre IP
conferencia importante y la información es recibida fuera de secuencia y con
retardos, no se entendería nada.
Las transmisiones de video basadas en IP así como la telefonía 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. A continuación se
describirán algunos de los componentes requeridos para facilitar la video
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 organización. Los gateways proveen la resolución
de protocolo como H.323 a H.320, y resolución a ISDN de otros medios de red.
Existen en el mercado plataformas modulares ofreciendo opciones de conexión
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 están
disponibles para que la videoconferencia se lleve acabo y si el dispositivo que
solicita la videoconferencia puede obtener el acceso a los recursos solicitados.
62
Voz dobre IP
UNIDADES DE CONTROL MULTIPUNTO
Las Unidades de control Multipunto (MCUs) sirven como un centro, para la
comunicación 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 más participantes
necesitan acceso a la misma video conferencia en tiempo real. Un simple MCU
puede controlar diferentes videoconferencias simultáneamente.
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 resolución de
protocolo entre la recomendación H.320 para videoconferencia sobre ISDN y el
protocolo de telefonía 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, es típico
encontrar los mismos componentes, usualmente: una video cámara una video
pantalla y componentes de audio.
63
Voz dobre IP
MEJORAR LA INFRAESTRUCTURA DE RED
Como se ha descrito la telefonía 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, teléfonos 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 propósito 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 módulos-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 analógica para interactuar
directamente con los teléfonos convencionales o para conectarse con el antiguo
sistema PBX o la Red Publica Conmutada. Como la tecnología análoga es
considerada como una vieja y estable tecnología, estas interfases son
estandarizadas. Existen actualmente tres tipos de interfaces analógicas
soportadas por algunos enrutadores, que son las siguientes:
64
Voz dobre IP
FXS (FOREIGN EXHANGE STATION)
Los puertos de esta interfaz utilizan un conector RJ-11 para conectarse con
los teléfonos convencionales, módems o faxes. Este es el tipo de interfaz mas
comúnmente encontrada en los enrutadores.
FXO (FOREIGN EXCHANGE OFFICE)
Los puertos de esta interfaz utilizan también un conector telefónico RJ-11.
Los puertos son comúnmente utilizados para conectar por medio de una
negociación los sistemas PBX al proveedor de servicio telefónico de la red.
E&M (EAR & MOUTH)
Esta interfaz ofrece una solución mas avanzada que las anteriores, así
como otras características que los anteriores no ofrecen, como por ejemplo
almacenamiento y transmisión análoga o digital. Esta interfaz utiliza un puerto RJ-
48 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 módulos de compresión de voz (VCMs Voice
Compression Modules). Las tarjetas de almacenamiento digital de voz interactúan
comúnmente con líneas ISDN BRI y PRI. Utilizando canales individuales en cada
línea, este permite para una línea sencilla soportar dos líneas de voz usando BRI
(Basic Rate Interface) y cerca de 23 líneas usando PRI (Primary Rate Interface) en
los Estados Unidos y cerca de 30 líneas en Europa.
65
Voz dobre IP
El procesador de voz digital VCMs permite al enrutador llevar una
conversación de voz y comprimirla lo mas que se pueda, aproximadamente a 5.3
Kbps, dependiendo del método de compresión utilizado, una gran diferencia con el
canal de 56 Kbps. Esto permite una mejor utilización del ancho de banda
disponible.
ENCOLADOS PARA VOZ Y VIDEO
El encolado es un importante punto de diseño y desempeño que debe ser
examinado en la telefonía IP. El encolado ha sido tradicionalmente una función 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 tráfico de
voz y video del tráfico regular de datos y se ponga este tráfico 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 para la
operación 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 información de capa que
llevan esos paquetes se pierde, en otras palabras 802.1Q es solo una solución
LAN. Para el tráfico que cruza enlaces WAN, el encolado de capa 3 debe ser
incorporado.
66
Voz dobre IP
INTRODUCCION A LOS GATEWAYS PARA LA ARQUITECTURA DE VOZ,
VIDEO Y DATOS INTEGRADOS.
Un Gateway por definición 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 telefonía IP a la Red Telefónica 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 Telefónica Conmutada o
ISDN. También desempeña resoluciones entre diferentes formatos de transmisión
y procedimientos de comunicación, y es responsable para establecer y liberar
llamadas en ambos lados de la red. La comunicación entre las terminales y un
Gateway son hechas a través 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 implementación, 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 características que se requieren
por default son: transmisión DMTF, redundancia del CallManager y servicios
suplementarios. Servicios suplementarios que permitan a los usuarios
desempeñar 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 teléfono IP o
67
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 recomendación estándar hecha por la ITU
(Internacional Telecommunications Union) para los paquetes basados en audio,
video, voz y conferencia. Es el estándar 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 vía 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 información.
Señalización como RAS (Registration, Admisión y Status), H.245 y Q.931
es transportada sobre señalización TCP.Q.931, para el establecimiento y
terminación de una llamada. Sin embargo las capacidades son intercambiadas
utilizando H.245, el cual se usa para el control de llamada y estable la
comunicación 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 aplicación que
puede establecer, modificar y terminar sesiones multimedia o llamadas. Estas
sesiones multimedia incluyen conferencias IP, llamadas telefónicas y distribución
multimedia. Una solución para este tipo consiste de un agente SIP, un teléfono IP,
un Gateway SIP y un servidor Proxy SIP.
68
Voz dobre IP
SIP soporta cinco elementos de establecimiento y terminación de comunicaciones:
Localización 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
tecnología 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
aplicación Windows Messenger, el cual es parte de Windows XP. Windows
Messenger es un software de comunicaciones en tiempo real que provee punto a
punto telefonía IP. SIP es un protocolo de comunicación multiparte, pero la
primera versión de Windows Messenger solo soporta dos formas de conversación.
ELECCION DE UN GATEWAY DE VOZ
Hay un número de diferentes Gateways de voz disponibles para el
CallManager y las implementaciones de Voz sobre IP, las cuales están divididas
en categorías, por el tipo de Gateway y el protocolo que esta corriendo para la
comunicación del Gateway. La selección del Gateway esta basada sobre algunas
de las siguientes variables: análogo o digital, capacidad, tipo de conexión,
servicios, características e instalación.
69
Voz dobre IP
Los Gateways analógicos proveen conectividad a un teléfono analógico,
oficina central y a un PBX. Los puertos FXS (Foreign Exchange Station) son
usados para proveer un tono de marcado para teléfonos analógicos, faxes y
teléfonos 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 analógico a la Red Telefónica Publica Conmutada. Por otro lado los
puertos E&M (Ear & Mouth) son utilizados para la señalización de comunicación
de PBX a PBX.
Si se requiere una más alta capacidad de los canales de voz para la
Red Publica Telefónica Conmutada o PBX, un Gateway digital podría ser mas
efectivo. Los diferentes Gateway soportan dos tipos de señales principales: ISDN
PRI (Primary Rate Interface) o CAS (Channel Associated Signaling) para un T1 o
E1. ISDN PRI utiliza un canal D para señalización. ISDN PRI es clasificado como
señalización fuera de banda, porque hay un canal dedicado para señalización,
mientras que, la señalización 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 Telefónica 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
Telefónica 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 señalización. DMTF usa dos
frecuencias, un tono alto y uno bajo para distinguir los números en un teclado
telefónico. Esta señalización es usualmente transmitida sobre un circuito de voz de
70
Voz dobre IP
64Kbps y lograda con poco problema, pero con un CODEC de resolución baja de
bits la señal puede ser perdida o irreconocible.
Los Gateways proveen un soporte fuera de banda para pasar señales
DTMF a través de una red de Voz sobre IP vía protocolos de Gateway. El
Gateway de una Arquitectura de Video, Voz y Datos Integrados necesita proveer
soporte para otros servicios de telefonía de usuario como llamada en espera,
manejo de llamada y conferencia.
71
Voz dobre IP
GATEKEEPERS
El Gatekeeper actúa 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 configuración) que estaciones (equipo
de usuario/endpoints) pueden participar en la red. También pueden restringir las
llamadas basadas en un equipo de usuario que hace o recibe la llamada. Además
puede desempeñar varias funciones de administración como resolución de
direcciones, servicio de directorio, así como autorización de llamada y
contabilidad.
En algunas redes el Gatekeeper es también conocido como Administrador
de Conferencia Multimedia (MCM – Multimedia Conference Manager). El
Gatekeeper puede ser configurado en un enrutador existente o en uno dedicado.
72
Voz dobre IP
FUNCIONES DEL GATEKEEPER
Los Gatekeepers son componentes de una red H.323, una red diseñada
para transportar trafico en tiempo real, como voz, video y datos. Un gatekeeper
interactúa con los equipos de usuario final (endpoints), las cuales son estaciones
capaces de establecer llamadas H.323 como por ejemplo una estación de trabajo
corriendo Microsoft NetMeeting o un CallManager. Un Gatekeeper también
interactúa 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 telefónica o llamadas sobre la
Red Digital de Servicios Integrados en común con videoconferencia.
Como es definido por la recomendación H.323, el Gatekeeper es requerido
para desempeñar una cierta gama de funciones. Estas funciones requeridas
desempeñan los servicios básicos H.323. Por ejemplo, los Gatekeepers localizan
los equipos de usuario que están recibiendo llamadas y los liberan de esta tarea.
El Gatekeeper también controla totalmente la participiacion en la red así
como las llamadas establecidas ahí. Funciones adicionales son opcionales y
pueden agregar valor en ciertos casos.
Los Gatekeepers usan el protocolo H.225 para comunicarse con los
equipos de usuario final (endpoints) y Gateways. El protocolo H.225 tiene dos
partes básicas: Registro, Admisión y Estado (RAS- Registration, Admisión and
Status) y señalización 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 admisión y el control de llamada en la red H.323. Los equipos
de usuario final (endpoints) y gateways también usan una parte de la señalización
de llamada del protocolo, para el establecimiento de llamada.
73
Voz dobre IP
FUNCIONES REQUERIDAS
Los Gatekeepers son requeridos para desempeñar 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:
Resolución de direcciones: El Gatekeeper resolverá una dirección H.323
(por ejemplo un numero telefónico E.164) en una dirección IP. El
Gatekeeper hará esto resolviendo el número telefónico a un equipo de
usuario final ya registrado con el Gatekeeper o encontrando la localización
del número telefónico por solicitud a otros Gatekeepers configurados,
utilizando el protocolo H.225 (RAS). Por ejemplo el Gatekeeper puede
traducir el número 212-555-1212 en una dirección IP 10.5.6.1. El
Gatekeeper también puede resolver sobre H.323 IDs (cadenas de
caracteres).
Control de admisión: 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 también restringir la participación de equipos
de usuario por otras características 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.
74
Voz dobre IP
Control de ancho de banda: El Gatekeeper es responsable del monitoreo
y control del ancho de banda de la red que están 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
sufrirán 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) y la señalización de la llamada entre los equipos de usuario
(endpoints).
El Gatekeeper usas toda esta información para prevenir que el total del
ancho de banda utilizado por las llamadas de voz y video excedan el límite
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) limitarían el límite del
número de llamadas que pudieran ser establecidas. En una red IP, este límite no
existe, por lo tanto el Gatekeeper debe aplicar este límite.
75
Voz dobre IP
CAPITULO 4 .- PROTOCOLO RSVP.
El protocolo RSVP (Resource Reservation Protocol) fue el primer intento en
la industria para la implementación del estándar “Intserv” (Internet Integrated
Services), que es el modelo de QoS. Investigadores del Instituto de ciencias
Informáticas 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 señalización que hace reservaciones del medio
para las aplicaciones del cliente en la que garantiza mejor calidad de servicio
(QoS). Es considerado como protocolo de señalización porque las reservaciones
son llevadas a cabo durante la comunicación 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 transmisión
de los paquetes típicos IP; o más específicamente los paquetes IP son enviados y
los paquetes RSVP se encargan de la calidad de servicio. Por esta razón, 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 través de la red. Estos flujos
reservados son usualmente referidos como sesiones. Una sesión es definida como
paquetes que tienen la misma dirección de destino (unicast o multicast). Los
clientes usan la disposición RSVP para garantizar la calidad de servicio a través
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, refiriéndose 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 también con ipv6. el camino que toma sobre la red es el
76
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). Además de la Inter - operabilidad con estos protocolos de
ruteo, RSVP también trabaja con la implementación 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 implementación no son usados de forma directa con
RSVP?, esto depende de los routers que determina cómo 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 métodos de trafico (unicast y multicast) son soportados por RSVP.
El soporte para multicast, desde que RSVP es comúnmente 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 básico de que es RSVP, veamos el
mecanismo poniendo una sesión RSVP, en el caso de una llamada telefónica o
video conferencia. No nos enfocaremos específicamente en la configuración de
RSVP pero, mas bien, nos concentraremos en la estrategia global.
77
Voz dobre IP
Iniciar sesión.
El protocolo RSVP es puesto a menudo entre dos clientes de punto a punto
(semejante a una llamada telefónica), o entre múltiples transmisores y múltiples
receptores (multicast). Para RSVP es constantemente posible negociar un
multipunto escogiendo un punto de transmisión. En algún caso, la sesión RSVP
levanta los procesos reservados en una sola dirección. Para tener garantía de
calidad de servicio en full - duplex, es necesario que la sesión levante los
procesos que se están ejecutando al mismo tiempo, una vez en cada dirección.
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 necesitaría solo un camino de reservación.
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 separación de las
reservaciones de voz y video. Considerando que ambos elementos ( voz y video),
necesitarían estar en forma bi – direccional, esto quiere decir que tendríamos 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 fórmula A x (B – 1) = C, donde A = flujo bi -
direccional, B = Número total de Routers, y C = Reservaciones totales por router,
esto no es difícil de realizar estos cambios, se solucionarán cuando intentes
extender la RSVP en una larga escala.
Ahora que hemos explorado algo de esta información a fondo, se necesitará
guardar en mente, considerar cuantas sesiones podremos levantar, ponemos
estos pasos a través de el proceso de una sesión levantada de un RSVP.
78
Voz dobre IP
4.3 SIP PROTOCOLO INICIAL DE SESION
El protocolo inicial de sesión SIP es un protocolo de control de la capa de
aplicación para crear, modificar y terminar sesiones con uno o más participantes.
Estas sesiones incluyen conferencias multimedia a través de Internet, llamadas
telefónicas sobre Internet y distribución multimedia.
Los miembros en una sesión multimedia pueden comunicar vía multicast
(multidifusion) o vía una malla de relaciones unicast o combinaciones de esta.
Las invitaciones SIP usadas para crear sesiones, llevan descripciones de sesión
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 localización actual del usuario. Los usuarios pueden registrar su
localización actual. SIP no es ligado a ningún protocolo particular de control de
conferencia. SIP esta diseñado 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 sesión es un protocolo de control de la capa de aplicación
que puede establecer, modificar y terminar sesiones multimedia o llamadas. Estas
79
Voz dobre IP
sesiones multimedia incluyen conferencias multimedia, aprendizaje a distancia,
telefonía 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
sesión a la cual se le esta invitando. Medios y participantes pueden ser agregados
a una sesión 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 implementación de ISDN y servicios de subscripción de red de
telefonía inteligente. Estas facilidades también 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 identificación personal (por ejemplo un numero
personal)”. La movilidad personal complementa la movilidad de la terminal por
80
Voz dobre IP
ejemplo la habilidad para mantener comunicación cuando se mueve una sencilla
terminal de una sub-red a otra.
SIP soporta cinco facetas de establecimiento y terminación de comunicaciones
multimedia:
Sitio de usuario: Determinación del sistema final para ser usado para la
comunicación.
Capacidades de usuario: Determinación del medio y parámetros del medio
(audio/video) para ser usados.
Disponibilidad de usuario: Determinación de buena voluntad de la llamada
para ser empleada en las comunicaciones
Establecimiento de la llamada: “timbrado”, establecimiento de los
parámetros de llamada tanto en la llamada como la sesión de llamadas.
Manejo de llamada: Incluyendo transferencia y terminación de llamadas.
SIP además puede iniciar llamadas multi-sesiones usando una Unidad de Control
Multipunto (MCU) o enredado completo de interconexiones en lugar de multicast.
Gateways de telefonía sobre Internet que conectan las sesiones de llamadas con
la Red Pública Telefónica Conmutada pueden usar SIP para establecer llamadas
entre ellos.
81
Voz dobre IP
SIP esta diseñado 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 retroalimentación de calidad del servicio, protocolo
en tiempo real de streaming (RTSP) para controlar la entrega o media streaming,
el protocolo de anuncio de sesión (SAP) para anunciar las sesiones multimedia vía
multidifusion (multicast) y el protocolo de descripción de sesión (SDP) para
describir las sesiones multimedia. Sin embargo, la funcionalidad y operación 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 señalización. En ese modo un sistema final usa intercambios
SIP para determinar la dirección apropiada del sistema final y el protocolo de esa
dirección dada que es un protocolo independiente. Por ejemplo SIP puede ser
usado para determinar que la sesión puede ser alcanzada vía H.323 obteniendo la
dirección del Gateway H.245, la dirección del usuario y entonces usar H.225 para
establecer la llamada.
En otro ejemplo, SIP podría ser usado para determinar que la llamada es lograda
vía PSTN (Red Telefónica Publica Conmutada) e indicar el numero telefónico que
será llamado con la posible sugerencia de ser usado un Gateway de Internet a
Red Telefónica 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
82
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 reservación. SIP no reserva
fuentes, pero puede convenir con el sistema invitado la información necesaria para
hacer esto.
OPERACIÓN DE SIP
Personas que llaman y personas llamadas son identificadas por una dirección SIP.
Cuando se hace una llamada SIP, el llamador primero localiza el servidor
apropiado y entonces envía una solicitud SIP. La más común operación de SIP es
la invitación. 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 dirección mail o una URL
Telnet, por ejemplo user@host. La parte de usuario es un nombre de usuario o un
número telefónico. La parte de Host es también un nombre de dominio o una
dirección numérica de red.
83
Voz dobre IP
Una dirección de usuario SIP puede ser obtenida fuera de banda, puede ser
aprendida vía agentes existentes de medio, puede ser incluida en algunas
cabeceras de mensaje de mail o puede ser grabada durante interacciones previas
de invitación. En muchos casos una URL de SIP puede ser supuesta de una
dirección de correo.
Una dirección 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 dirección, 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 través de una dirección que es fácil
de adivinar de un nombre de una persona y de una afiliación organizacional, el
método tradicional de asegurar privacia para tener un número telefónico enlistado
es comprometido. Sin embargo a la nada parecida telefonía tradicional, SIP ofrece
mecanismos de autenticación 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.
84
Voz dobre IP
ESTABLECER UN SERVIDOR SIP
Cuando un cliente desea enviar una petición/solicitud, el cliente también lo envía
para un servidor Proxy SIP configurado localmente (como en HTTP),
independientemente de la solicitud URL, o la envía a la dirección IP y puerto
correspondiente de la solicitud URL.
Para el último caso, el cliente debe determinar el protocolo, puerto y dirección IP
de un servidor para el cual enviara la petición. En cada caso el cliente debe tratar
de contactar un servidor en el número de puerto listado en la solicitud URL. Si el
número de puerto no es presentado en la petición 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 expiración.
Si el cliente encuentra que el servidor es inalcanzable en una dirección en
particular, este deberá comportarse como si este hubiera recibido una respuesta
de error de clase 400 para esa solicitud.
85
Voz dobre IP
TRANSACCION SIP
Una vez que la parte del host ha sido resuelta a un servidor SIP, el cliente envía
una o más solicitudes SIP a ese servidor y recibe una o más respuestas del
servidor. Una solicitud (y sus retransmisiones) juntas con las respuestas
disparadas por esa solicitud establecen una transacción 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 transacción
simple son llevadas sobre la misma conexión TCP. Diferentes solicitudes SIP
provenientes del mismo cliente al mismo servidor pueden usar la misma conexión
o pueden usar una nueva conexión para cada solicitud.
Si el cliente envía la solicitud vía unicast UDP, la respuesta es envida a la
dirección contenida en el siguiente campo de la cabecera de la respuesta. Si la
solicitud es enviada vía multicast UDP, la respuesta es dirigida a la misma
dirección multicast y puerto de destino. Para UDP la confiabilidad es llevada
acabo usan retransmisión. El formato de los mensajes SIP y la operación es
independiente del protocolo de transporte.
INVITACION SIP
Una invitación exitosa SIP consiste de dos peticiones, INVITE seguido por un
ACK. La petición INVITE pregunta al sistema llamado enlazar un conferencia
86
Voz dobre IP
particular o establecer una conversación entre dos. Después que el sistema
llamado ha aceptado participar en la llamada, el sistema que llama confirma que
este ha recibido esa respuesta por medio del envío de una petición ACK. Si el
participante no quiere participar más en la llamada, este enviara una petición BYE
en lugar de un ACK.
La petición INVITE típicamente contiene una descripción de sesión, por ejemplo
escrita en el formato SDP, que provee la sesión de llamada con suficiente
información para establecer la sesión. Para sesiones multicast, la descripción de
sesión enumera los tipos de medio y formatos que serán permitidos para ser
distribuidos para esa sesión.
Para sesión unicast, la descripción de sesión 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 invitación retornando una descripción
similar listando el medio que el desea usar. Para una sesión multicast, el sistema
llamado debe solo regresar una descripción de sesión si este esta inhabilitado
para recibir el medio indicado en la descripción del sistema que llama o quiere
recibir datos vía unicast.
87
Voz dobre IP
LOCALIZAR A UN USUARIO
Un sistema llamado puede moverse entre un número de diferentes sistemas
sobre tiempo, Estas ubicaciones pueden ser dinámicas registradas con el servidor
SIP. La ubicación del servidor puede también 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 podría ser alcanzable. La ubicación del servidor puede
regresar diferentes ubicaciones porque el usuario es registrado en diferentes hosts
simultáneamente o porque la ubicación del servidor tiene (temporalmente)
información imprecisa. El servidor SIP combina los resultados para producir una
lista de cero o más ubicaciones.
La acción tomada de recibir una lista de ubicaciones varía 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 envía una petición SIP, este debe agregarse por si mismo al
comienzo de la lista de envíos notados en las cabeceras vía. El trayecto vía
asegura que las replicas pueden tomar el mismo camino de regreso, asegurando
la operación correcta a través de los dóciles firewalls y evitando loops de
88
Voz dobre IP
peticiones. Sobre el camino de respuestas, cada host debe eliminar su vía, para
que el enrutado de la información 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 parámetros vía sent-by, vía received o vía-madrr.
PROPIEDADES DE PROTOCOLO
ESTADO MINIMO
Una simple sesión 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 transacción SIP. Por eficiencia un servidor debe obtener los
resultados de la ubicación de servicio de petición.
CAPAS DE PROTOCOLO INFERIORES NEUTRALES
SIP hace las suposiciones mínimas 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 aplicación un
control más cuidadoso del tiempo de los mensajes y sus retransmisiones, para
desempeñar paralelamente búsquedas sin necesidad de un estado de conexión
89
Voz dobre IP
TCP para cada petición sobresaliente y uso d multicast. Los enrutadores pueden
interpretar con mayor facilidad paquetes SIP UDP. TCP permite una mayor
facilidad de paso a través de los firewalls existentes.
Cuando TCP es usado, SIP puede usar una o más conexiones para intentar
contactar un usuario o modificar parámetros de una conferencia existente.
Diferentes peticiones SIP para la misma llamada SIP pueden usar diferentes
conexiones TCP o una sencilla conexión persistente según sea apropiado.
En concreto en este trabajo solo se hace referencia a protocolos de Internet. Sin
embargo SIP puede también ser usado directamente con protocolos tales como
ATM AAL 5, Frame Relay o X.25.
BASE DE TEXTO
SIP es basado en texto usando ISO 10545. Esto permite una fácil implementación
en lenguajes como Java, Tcl y Perl, permite una fácil supresión de errores y lo
más importante hace a SIP flexible y escalable. Porque SIP es usado para iniciar
conferencias multimedia más que para entrega de datos multimedia.
SIP URL (Uniform Resource Locatión- Ubicación Uniforme de Recursos)
SIP URLs son usados dentro de los mensajes SIP para indicar el originador de la
llamada, la ubicación del destino y el recipiente final de una petición SIP y para
90
Voz dobre IP
especificar el redireccionamiento de direcciones. Una URL SIP puede también
implantarse en páginas Web u otros hiperlinks para indicar que un usuario en
particular o servicio en particular puede ser llamado vía SIP. Cuando es usado
como hiperlink, el URL SIP indica el uso del método de INVITADO.
El esquema URL SIP es definido para permitir las características de los campos
de la cabecera de petición 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 través de una página 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
91
Voz dobre IP
Dentro de un mensaje SIP las URLs son usadas para indicar la fuente y el destino
de una petición, redireccionamiento de direcciones y la actual ubicación de una
petición, Normalmente todos estos campos contendrán las URLs SIP.
METODOS
Los métodos son definidos a continuación. Los métodos que no son soportados
por un Proxy o un servidor redirigido son tratados por ese servidor como si estos
fueran un método de opción y son enviados acordadamente. Los métodos que no
son soportados por un agente usuario un registro cusan una respuesta 501 para
ser notificada. Como en http al método Token es un caso sensible.
Un método puede ser “INVITE”, “ACK”,”OPTIONS” “BYE”, “CANCEL”,
“REGISTRER”.
METODO INVITE
El método INVITE indica que el usuario o servicio esta siendo invitado a participar
en una sesión. El cuerpo del mensaje contiene una descripción de la sesión 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 parámetros 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.
92
Voz dobre IP
No todos los formatos de descripción tienen la habilidad para indicar el tipo de
medio a enviar. Un servidor puede automáticamente responder a una invitación
para una conferencia en la que el usuario esta listo para participar en ella,
identificada también por el SIP call-ID (identificador de llamada), debe checar
cualquier versión de identificadores, el contenido de descripción de la sesión para
ver si esta ha cambiado. Si hay algún cambio, el agente de usuario debe actualizar
cualquier estado interno o la información generada como resultado de esa
cabecera.
Si la descripción de la sesión ha cambiado, el servidor de agente de usuario debe
ajustar los parámetros de sesión acordadamente, posiblemente después de
preguntar al usuario para la confirmación.
Este método debe ser soportado por servidores Proxy, redirigidos y agentes de
usuario así como también clientes.
93
Voz dobre IP
Hola Ulises,
Hoy debería 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 introducción y las conclusiones.
Numerar tablas y figuras con el número de capítulo y secuencia, ejemplo tabla 1.1,
fig., 1.1, etc.
En el capítulo 1 se le podrían agregar algunos esquemas para hacer la lectura
más fácil.
En general al inicio de cada capítulo agregar una explicación breve de lo que se va
a tratar y poner conclusiones al final del mismo.
El capítulo 2 y 3 numerar los incisos más importantes, así como las figuras.
El título del capítulo 4 debe resaltar de otros textos, faltan esquemas de apoyo
(figuras y tablas) así como las conclusiones.
Falta uns sección de conclusiones generales de la tesina.
Falta la bibliografía y de ser necesario un glosario de términos.
94
Voz dobre IP
Saludos
95