Voz dobre IP

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

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

Aplicaciones.

1.11

Ventajas e inconvenientes de los servicios IP.

CAPITULO 2.- Protocolos para multimedia.

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

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

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

Voz dobre IP

PRINCIPIO Y FUNCIONAMIENTO DE VoIP

Introduccin
La convergencia de las redes de telecomunicaciones actuales pretende
encontrar la tecnologa que permita la transmisin de voz y datos sobre la misma
lnea. Esto ha obligado a establecer modelos o sistemas que permita
empaquetar la voz

para que pueda ser transmitida en la lnea de datos.

Tomando en cuenta que Internet es la Red de Redes, desarrollar una tecnologa

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

Voz dobre IP

En el captulo uno, se realiza una analoga de la telefona convencional con

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

En general, en esta tesina abordamos el funcionamiento y los componentes

de una red de voz sobre IP, caractersticas y protocolos.

Voz dobre IP

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

Voz sobre IP es transmitir Voz utilizando IP. Si bien es una tecnologa

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

Telefona Tradicional.

El servicio telefnico es, junto con la red elctrica, uno de los ms

confiables que conocemos y usamos, ya que todo es muy redundante y est
pensado para funcionar siempre. Una central telefnica esta diseada para
minimizar los tiempos de interrupcin del servicio.

Es una tecnologa en que la interfaz es muy importante, la gente la conoce,

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

Voz dobre IP

Arquitectura de una central telefnica.

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

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

Conexin entre centrales

La llamada que sale de nuestra central tiene que llegar hasta la central
donde est la persona con la que queremos hablar. No hay doscientos millones de
cables entre una y otra, sino que hay un enlace, el cual puede ser de diversos
tipos. Este enlace se debe multiplexar para que todos los abonados de la central
puedan hablar por telfono.
Esta multiplexacin es la que hace una diferencia a la hora de la calidad del
servicio para el usuario. El sistema de multiplexacin que utilizan las centrales
telefnicas se llama TDM: Time Division Multiplex. Consiste en dividir el stream de
datos en partes iguales de 64k (llamadas time-slots), de manera que los datos
correspondientes

al

primer

abonado

van

en

el

primer

time-slot,

los

correspondientes al segundo en el segundo, y as sucesivamente.

Suponiendo un enlace de 2 Mbps de ancho de banda, como se transmiten
64k, podra haber hasta 32 abonados hablando a la vez. Con esta multiplexacin
en tiempo se separan y luego vuelven a unir los streams de voz que van de una
central a otra, de manera transparente para el que lo est utilizando.

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

Ruteo, sealizacin y protocolos.

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

10

Voz dobre IP
El protocolo R2,

es uno de los ms viejos y tiene muchas variantes

distintas, hay -incluso- una variante argentina, y pasa toda su informacin

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

canales

de

64kbps).

En muchos mbitos cuando se habla de este tipo de enlaces se le da

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

11

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

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

Voz dobre IP
las necesidades de ancho de banda para este tipo de aplicaciones estn al
alcance de prcticamente cualquier empresa.
Calidad en la Transmisin de La Voz
Referente a la calidad de la transmisin de la voz, todos los fabricantes e
investigaciones hacen referencia a tres factores determinantes.
Codificadores de Voz: influyen en la digitalizacin de la voz en paquetes de datos
que contienen voz y que sern transmitidos por la red IP, tambin influyen por el
retardo necesario para la descompresin de esos paquetes voz, lo que imputa un
retardo aadido a la comunicacin.
Cancelacin de Eco: requerimiento necesario para una comunicacin a travs de
Telefona IP, que elimina de forma automtica y en tiempo real posibles ecos, ya
que si no lo hiciera hara inteligible la comunicacin.
Latencia: tiempo necesario para que la voz viaje de un extremo al otro, incluyen
los tiempos necesarios para la compresin, transmisin y descompresin. Este
tiempo tiende a minimizarse pero jams podr ser suprimido. Actualmente los
tiempos que se estn obteniendo de latencia giran alrededor de 120 ms.
Estndares
Actualmente existen estndares que regulan este tipo de comunicaciones,
estndares que provienen de organismos internacionales de estandarizacin como
el ITU (International Telecommunication Union) que ha establecido unas normas
para la interconexin de los distintos elementos que intervienen en una
comunicacin sobre Telefona IP.
El estndar que regula este tipo de comunicaciones es el H.323 de la ITU.
Esta norma realmente es una serie de normas para la transmisin de datos
multimedia (audio, vdeo y datos) sobre redes que no garantizan una calidad de
servicio (redes IP).
14

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

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

15

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

16

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

17

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

18

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

19

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

VoCodecs

Ancho de Banda
(BW)

G.711 PCM

64 kbps

G.726 ADPCM

16, 24, 32, 40

kbps

G.727 E-ADPCM 16, 24, 32, 40

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 trnsito y el retardo
de procesado la conversacin se considera aceptable por debajo de los 150 ms.
Eco:
El eco es debido a una reflexin, habitualmente se debe a un desajuste de
impedancias.

20

Voz dobre IP

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

d) Priorizar: Existen diferentes tendencias tales como:

1.- CQ (Custom Queuing): Asignacin de un porcentaje del ancho de banda
disponible.
2.- PQ: Establecer prioridad en las colas de envo.

21

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

22

Voz dobre IP

CAPITULO 2.- PROTOCOLOS PARA MULTIMEDIA

PROTOCOLO H.323
Esta recomendacin, cubre los requerimientos tcnicos para servicios de
telefona visual

de banda estrecha, en situaciones donde el camino

de

transmisin incluye ms de una LAN, la cual no puede garantizar una calidad de

servicio (QoS). Ejemplos de estos tipos de LAN son:

-Ethernet (IEEE 802.3)

-Fast Ethernet (IEEE 802.10)
-FDDI (en modo de servicio donde se garantiza la calidad)
-Token Ring (IEEE 802.5)
Las terminales H.323 pueden ser usadas en configuracin multipunto y se
pueden interconectar con terminales H.320 en B-ISDN, terminales H.321 en NISDN, terminales H.322

en LANs donde se garantiza la calidad del servicio,

terminales en GSTN (General Switched Telephone Network) y conexiones

inalmbricas (wireless).
Esta recomendacin describe los componentes bsicos de un sistema
H.323, esto incluye Terminales Gateways, Gatekeepers, Controladores Multipunto,
multiprocesadores y Unidades de Control Multipunto (MCU). El control de
mensajes y procedimientos dentro de esta recomendacin define la comunicacin
de todos los componentes antes descritos.

23

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

Scope of
H.323
H.323
Terminal

H.323
MCU

Non-Guaranteed QoS LAN

(Note)
H.323
Gatekeeper

H.323
Gateway

Guaranteed

GSTN

QOS
LAN

H.323
Terminal

N-ISDN

H.323
Terminal

B-ISDN

H.310 terminal
operating in
H.321 mode
V.70
Terminal

H.324
Terminal

Speech
Terminal

H.322
Terminal

Speech
Terminal

H.320
Terminal

H.321
Terminal

H.321
Terminal

Note: A gateway may support one or more of the GSTN,

N-ISDN and/or B-ISDN connections.

Como se puede ver este estndar define un amplio conjunto de caractersticas y

funciones. Algunas son necesarias y otras opcionales, se abordara mas adelante

24

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

DESCRIPCION DEL SISTEMA

Los componentes de un telfono visual se comunican a travs de la transmisin
de cadenas de informacin. Estas cadenas de informacin son clasificadas en
video, audio, datos, control de comunicacin y control de llamada como sigue:

Las seales de audio contienen voz codificada y digitalizada a fin de

reducir el promedio de la tasa de transmisin de las seales de
audio.

Las seales de video contienen movimiento en tiempo real codificado

y digitalizado. La seal de video esta acompaada por un control de
seal de video.

Las seales de datos incluyen fotos, documentos, archivos de

computadora y otras cadenas de datos.

Las seales de control de comunicaciones son usadas para

administrar el intercambio, apertura y cierre de los canales lgicos, el
modo de control y otras funciones son parte del control de
comunicaciones.

Las seales de control de llamada son usadas para establecer,

terminar y otras funciones bsicas de control de llamada

Las caractersticas de las cadenas de informacin mencionadas anteriormente son

descritas en la norma H.225 que se vera mas adelante.

25

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

Scope of Recommendation H.323

Video I/O equipment

Video Codec
H.261, H.263
Receive
Path
Delay

Audio I/O equipment

Audio Codec
G.711, G.722,
G.723, G.728,
G.729

H.225.0
Layer

Local Area
Network
Interface

User Data Applications

T.120, etc.
System Control
H.245 Control
System Control
User Interface

Call Control
H.225.0
RAS Control
H.225.0

ELEMENTOS TERMINALES EN LA RECOMENDACIN H.323

26

Voz dobre IP
Los siguientes elementos estn dentro de la recomendacin H.323 y estn
por lo tanto sujetos a estandarizacin:

El codificador de video (Video Codec) basado en la recomendacin

(H.261) como su nombre lo indica, codifica el video de alguna fuente
de video como puede ser una cmara de video, para la transmisin y
decodificacin posterior del video recibido, el cual ser desplegado
por ejemplo en un monitor.

El codificador de audio (Audio Codec) basado en la recomendacin

(G.711) como su nombre lo indica, codifica la seal de audio de un
micrfono para la transmisin y decodificacin del audio recibido el
cual encontrara como salida un altavoz.

El canal de datos soporta aplicaciones telemticas tales como

pizarrones electrnicos, transferencia de imgenes, intercambio de
archivos, accesos a base de datos, conferencias audio grficas, etc.
La estandarizacin de la aplicacin de datos para conferencia audio
grafica en tiempo real esta basada en la recomendacin T.120

La Unidad de Control del Sistema (recomendacin H.245, H.225)

provee sealizacin para la propia operacin de la terminal H.323.
Esta provee control de llamada, capacidad de intercambio,
sealizacin de rdenes e indicaciones as como mensajes para
apertura y descripcin completa del contenido de los canales lgicos.

Recomendacin H.225 define el formato del video, audio, datos y

cadenas de control dentro de mensajes para la interfaz de salida de
la red, los cuales han entrado por la interfase de red. Adems esto
mejora el desempeo del entramado lgico, numero de secuencia,
deteccin de errores y correccin apropiada para cada tipo de medio.

INTERFASE LAN

27

Voz dobre IP
La interfase LAN es una implementacin especfica y esta fuera del mbito de esta
recomendacin, sin embargo la interfase LAN podra proveer los servicios
descritos en la recomendacin H.225. Esto incluye lo siguiente:

Un servicio extremo a extremo (end-to-end) confiable (TCP, SPX) es

obligatorio para el canal de control (recomendacin H.245), canales
de datos, y canal de sealizacin de llamada.

Un servicio extremo a extremo (end-to-end)

no confiable es

obligatorio para canales de audio, canales de video y canal RAS

(Registration,Admisin,Status)
Estos servicios descrito pueden ser duplex o simples, unicast o multicast
dependiendo de la aplicacin, la capacidad de las terminales y la configuracin de
la LAN.
CODIFICADOR DE VIDEO (VIDEO CODEC)
El codificador de video es opcional. Todas las terminales H.323 proveedoras
de comunicacin de video deben ser capaces de codificar y decodificar video de
acuerdo a la recomendacin H.261 QCIF. Opcionalmente, una terminal puede ser
tambin capaz de codificar y decodificar video de acuerdo a las recomendaciones
H.261 CFI o H.263 SQCIF, QCFI, CIF, 4CFI y 16CFI. Si una terminal soporta
H.263 CIF o una resolucin ms alta, esta debe soportar tambin H.261 CIF. Los
codificadores H.261 y H.263 en la LAN deben ser usados sin correccin de errores
BCH y sin correccin de errores en trama.
Otros codificadores de video y otros formatos de imagen pueden ser
tambin usados va la negociacin de H.245. Ms de un canal de video puede ser
transmitido o recibido, segn sea la negociacin establecida por el control de
canal H.245. La terminal H.323 puede opcionalmente enviar mas de un canal de
video al mismo tiempo, por ejemplo, transportar voz y despus una fuentes de
video. La terminal H.323 puede opcionalmente recibir ms de un canal de video,

28

Voz dobre IP
por ejemplo,

para desplegar

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

CODIFICADOR DE AUDIO (AUDIO CODEC)

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

29

Voz dobre IP
voz de acuerdo a la recomendacin G.711. Todas las terminales opcionalmente
pueden ser capaces de codificar y decodificar voz usando las recomendaciones
G.722, G.728, G.729, MPEG 1 audio y G.723. El algoritmo de audio usado para la
codificacin esta descrito en la recomendacin H.245.
La Terminal H.323 debes ser capaz de una operacin asimtrica para todas
las capacidades de audio, es decir debe poder

trabajar a la hora de enviar

informacin con la recomendacin G.711 y a la hora de recibir la informacin con

la recomendacin G.728.
La Terminal H.323 puede opcionalmente enviar ms de un canal de audio al
mismo tiempo, por ejemplo; permitir dos lenguajes convenidos.
Los paquetes de audio deben ser entregados

a la capa de transporte

peridicamente en un intervalo determinado por la recomendacin del codificador

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

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

CANALES DE DATOS T.120

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

31

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

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

33

Voz dobre IP
canales lgicos as como solicitud de preferencia de modo, control de flujo de
mensajes y ordenes e indicaciones generales.
La sealizacin de la recomendacin H.245 es establecida entre los dos
puntos extremos, un extremo y un controlador multipunto (Multipoint ControllerMC) o un punto extremo terminal y un Gatekeeper. El punto extremo

debe

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 recomendacin
H.245. Ntese que una terminal, MCU, Gateway o Gatekeeper pueden soportar
muchas llamadas, y de esta manera muchos canales de control H.245. El canal de
control H.245 deber ser llevado en el canal lgico 0. El canal lgico 0 debe ser
considerado para permanentemente abierto para el establecimiento de el canal de
control H.245 hasta la terminacin de este canal. Los procedimientos normales
para la apertura y cierre de los canales lgicos no aplicaran para el canal de
control H.245.
La recomendacin H.245 especifica un nmero de entidades de protocolo
independiente las cuales soportan la sealizacin extremo a extremo.

Una

entidad de protocolo es especificada por su sintaxis (mensajes), semntica y los

procedimientos de establecimiento los cuales especifican el intercambio de
mensajes y la interaccin con el usuario. Las terminales H.323 deben soportar la
sintaxis, semntica y procedimientos de las siguientes entidades de protocolo.

Determinacin Maestro/Esclavo

Capacidad de Intercambio

Sealizacin de Canales lgicos

Sealizacin Bidireccional de Canales lgicos

Sealizacin de Cierre de Canal lgico

34

Voz dobre IP

Modo de Solicitud

Determinacin de Retardo Durante el Viaje

Mantenimiento de una sealizacin cclica.

Indicaciones y rdenes generales deben ser elegidas del establecimiento del

mensaje contenido en la recomendacin H.245.

Adems otras seales de

rdenes e indicaciones pueden ser enviadas, las cuales han sido especficamente
definidas para ser transferidas en la banda dentro de las cadenas de audio, video
o datos.
Los mensajes

H.245 caen dentro de cuatro categoras: Solicitud,

Respuesta, Orden e Indicacin. Los mensajes de Solicitud y Respuesta son

usados por las entidades de protocolo. Los mensajes de Solicitud requieren una
accin especfica por el receptor, incluyendo una respuesta inmediata. Los
mensajes de Respuesta como su nombre lo indica, responden a una solicitud
correspondiente. Los mensajes de rdenes requieren una accin especfica, pero
no requieren una respuesta. Los mensajes de Indicacin son solamente
informativos y no requieren de ninguna accin o respuesta. Las terminales H.323
deben responder a todas las solicitudes y ordenes

H.245, y deben transmitir

indicaciones para reflejar el estado de la terminal.

Las terminales H.323 deben ser capaces de analizar sintctica mente todos
los mensajes Multimedia System Control Message y deben enviar y recibir todos
los mensajes necesarios para implementar las funciones requeridas y esas
funciones opcionales son soportadas por la terminal. Las terminales H.323 deben
enviar el mensaje the function Not Supported en respuesta a cualquier mensaje de
solicitud, respuesta u orden no reconocido que este reciba.
La indicacin H.245, user Input Indicacin, esta disponible para de
transporte de usuario y soportar la entrada de caracteres alfanumricos de un
teclado o su equivalente para las seales DMTF usadas en telefona analgica.
35

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

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

36

Voz dobre IP
elegir un modo preferido para recibir la informacin (pero esta puede transmitir
cualquier modo dentro de la capacidad de recepcin).
La terminal de transmisin asigna cada modo individual que esta es capaz
de operar, con un numero, dentro de una tabla (capability Table).
Estos nmeros de capacidades son agrupados dentro de la estructuras
alternative CapabilitySet. Cada alternative Capability Set indica que la terminal es
capaz de operar en exactamente un modo listado en el establecimiento de la
llamada. Por ejemplo, una lista alternativa alternative CapabilitySet {G.711, G.723,
G.728} significa que la terminal puede operar en uno de esos modos de audio,
pero no ms de uno.
Estas estructuras alternative CapabilitySet son agrupadas dentro de las
estructuras simultaneous Capabilities. Cada estructura simultaneous Capabilities
indica

el establecimiento del modo que cada terminal es capaz de usar

simultneamente. 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 simultneamente. Un canal de video para H.261 otro para H.261 o
H.263 y un canal de audio para G.711, G.723 o G.728.
Las capacidades totales de la terminal son descritas por el

set de

estructuras capability Descriptor, cada una de las cuales es una simple estructura
simultaneous Capabilities y una capability Descriptor Number, enviando mas de un
capability Descriptor Number la terminal puede sealar dependencias entre modos
operando bajo diferentes establecimientos o modos que pueden

tener uso

simultneo. Por ejemplo, una terminal emitiendo dos estructuras capability

Descriptor, una {(H.261.H.263)}, (G.711, G.723, G.728)} como en el ejemplo previo
y otra {(H.262), (G.711)} significa que la terminal puede operar tambin con el
H.262 codificador de video (video codec), pero no as con la complexin-baja de
G.711 codificador de audio (audio codec).

37

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

SEALIZACION DEL CANAL LOGICO

Cada canal lgico lleva la infamacin del transmisor a ms de un receptor y
es identificado por el nmero del canal lgico el cual es nico para cada direccin
de transmisin.
Los canales lgicos son abiertos y cerrados usando los mensajes open
Logical Channel y close Logical Channel y los procedimientos H.245. Cuando un
canal lgico es abierto, el mensaje open Logical Channel describe completamente
el contenido del canal lgico, incluyendo el tipo de medio, el algoritmo en uso,
cualquier opcin y toda la informacin necesaria para que el receptor interprete el
contenido del canal lgico. Los canales lgicos pueden ser cerrados cuando existe
un periodo de inutilidad. La apertura del canal lgico puede estar inactiva si la
informacin de la fuente que desea establecer la comunicacin

no ha sido

enviada.
La mayora de los canales en H.323 son unidireccionales, entonces la
operacin asimtrica esta permitida, en la cual el nmero y tipo de cadenas de
informacin es diferente en cada direccin. Sin embargo si el receptor es capaz de
trabajar con ciertos tipos de modos de operacin simtrico este puede enviar o
recibir capacidades de establecimiento que reflejan sus limitaciones. Las
terminales pueden ser capaces de usar un modo particular en una nica direccin
de transmisin. Ciertos tipos de medio, incluyendo protocolo de datos como T.120,

38

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

sesin RTP

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

Voz dobre IP
debe rechazar el intento conflictivo, esto se puede ver el recomendacin H.245. El
intento de la apertura de canal lgico rechazado OpenLogicalChannel debe volver
a intentarse mas tarde.
CARACTERISTICAS DEL GATEWAY
El Gateway debe proveer la apropiada interpretacin entre los formatos de
transmisin (por ejemplo H.225.0 de/para H.221) y entre los procedimientos de
comunicacin (por ejemplo H.245 de/para

H.242). El Gateway debe tambin

desempear el establecimiento de llamada.

En general el propsito del Gateway (cuando no esta operando como MCU)
es reflejar las caractersticas de extremo de LAN a un extremo de red de circuitos
conmutados y viceversa, en un modo transparente para el usuario.
Un extremo H.323 puede comunicarse

directamente con otro extremo

H.323 en la misma LAN sin involucrar al Gateway. El Gateway puede ser omitido
si las comunicaciones con las terminales de Red de Circuitos Conmutados
(terminales que no estn dentro de la LAN) no son requeridas.
El Gateway tiene las caractersticas de una Terminal H.323 o MCU (Multi
Controller Unit) en la LAN y por otro lado las caractersticas de una terminal de red
de circuitos conmutados

o un MCU en la Red de Circuitos Conmutados. El

Gateway provee la conversin necesaria entre los diferentes tipos de terminales.

Ntese que el Gateway puede inicialmente operar como una terminal, pero
despus utilizando sealizacin H.245 se puede configurar para operar como
MCU para la misma llamada que fue inicialmente punto a punto. Los Gatekeepers
se percatan de cuales terminales son Gateway desde que esto es indicado
cuando la terminal/Gateway se registra con el Gatekeeper.
Un Gateway que enva datos T.120 entre la Red de Circuitos Conmutados y
la LAN, debe contener un proveedor

de Sistema Controlador Multipunto T.120

MCS (Multipoint Controller System) el cual conecta al proveedor

de Sistema

40

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

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

figura siguiente:

41

Voz dobre IP

H.323
LAN

Terminal

Conversion
Function

SCN
SCN

Terminal
Function

Function

Gateway A

H.323
LAN

MCU

Conversion
Function

SCN
SCN

Terminal
Function

Function

Gateway B

H.323
LAN

Terminal

SCN

Conversion
Function

SCN

MCU
Function

Function

Gateway C

H.323
LAN

MCU

SCN

Conversion
Function

SCN

MCU
Function

Function

Gateway D

Configuracin del Gateway en H.323

Gateways nter operando con solo terminales de voz en GSTN o ISDN

deben generar y detectar seales DMTF correspondientes a H.245 user Input
Indication para los caracteres 0-9, *, #.
La funcin de conversin provee la conversin necesaria del formato de
transmisin, control, video

y/o cadenas de datos entre las diferentes

recomendaciones de la terminal. Como mnimo, el Gateway debe proveer:

funcin de conversin para el formato de transmisin.

42

Voz dobre IP

Establecimiento y procedimiento de seales de llamada.

Control y procedimiento de seales de comunicacin.

El Gateway desempea la conversin apropiada entre la sealizacin de la

llamada H.225.0 y el sistema de sealizacin de la Red de Circuitos Conmutados

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

43

Voz dobre IP
CARACTERISTICAS DEL GATEKEEPER
El Gatekeeper, el cual es opcional en un sistema H.323, provee servicios de
control de llamada a un equipo extremo H.323. Ms de un Gatekeeper puede
estar presente y comunicarse con

otro en un modo no especificado. El

Gatekeeper es lgicamente separado de lo equipos extremo, sin embargo, su

implementacin fsica puede coexistir con una terminal, un Gateway, un Micro
Controlador (MC) o un dispositivo de LAN que no sea H.323.

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

siguientes servicios:

Resolucin de direcciones: El Gatekeeper debe desempear direcciones

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

Control de Admisin: El Gatekeeper debe autorizar el acceso LAN usando

los mensajes ARQ/ACF/ARJH225.0. esto puede ser basado en una
autorizacin de llamada, ancho de banda o algunos otros criterios los
cuales se dejan al fabricante.

Control de Ancho de Banda: El Gatekeeper debe soportar mensajes

BRQ/BRJ/BCF. Esto puede estar basado en la administracin del ancho de
banda.

IMPORTANCIA DEL ESTNDAR H.323

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

44

Voz dobre IP
video y datos. Construido para redes de paquetes de datos, H.323 a encontrado
una gran aceptacin en las redes IP, teniendo una gran importancia en VoIP.
Como otros protocolos de comunicaciones, H.323 es un estndar publicado
por la ITU (Internacional Telecommunications Union). Este fue aprobado como un
estndar internacional para voz, video y datos, definiendo

como algunos

dispositivos por ejemplo computadoras, telfonos, celulares, PDAs, telfonos

inalmbricos y sistemas de videoconferencia, dan una nueva pauta a la tecnologa
y al usuario final.
El estndar H.323 es la primera especificacin completa bajo la cual, los
productos desarrollados se pueden usar con el protocolo de transmisin ms
ampliamente difundido (IP). Es debido a esto que existe tanto inters y
expectacin entorno al H.323 porque apareci en el momento ms adecuado,
porque se tienen amplias redes ya instaladas y la mayora de las aplicaciones son
basadas en IP, tales como el acceso a la Web. Adems, los ordenadores
personales son cada vez ms potentes y por lo tanto, capaces de manejar datos
en tiempo real tales como voz y vdeo.

Como logros principales de esta recomendacin podemos sealar:

La estandarizacin de los protocolos permite a los diversos fabricantes

evolucionar en conjunto.

Los usuarios no deben preocuparse sobre las posibilidades de su

interlocutor, existiendo una negociacin de las capacidades de cada punto
de la lnea.

Debido a su apoyo sobre IP es independiente del tipo de red fsica que lo

soporta, permitiendo la integracin con las grandes redes IP actuales.

Por su propia estructura, es independiente del hardware, si bien permite ser

implementado en los ordenadores actuales, tambin se desarrolla hardware
especfico como Telfonos IP y consolas de videoconferencia.
45

Voz dobre IP

Otra caracterstica importante es el control de trfico que se puede realizar

dentro de la red.

De esta forma no deben producirse cadas importantes de rendimiento en

las redes de datos.

La negociacin previa permite conectar terminales de muy diversas

caractersticas, como pueden ser telfonos de voz, consolas de
videoconferencia, ordenadores, etc.

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

Figura.2.1.1 Crecimiento del mercado H.323

H.323 PERSPECTIVA HISTORICA

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

46

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

ESTABLECIMIENTO DE LLAMADAS
47

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

Voz dobre IP
facilidades de usuario conocidas como Servicios Suplementarios. Estos servicios
se renen sobre la especificacin H.450.1 que a su vez se sita sobre H.225 Call
Control. Por citar solo algunos de estos servicios indicar la existencia de H.450.2
para la transferencia de llamadas; H.450.3 para el desvo de llamada y H.450.6
para la llamada en espera.
Estndar T.120
T.120 surge de la necesidad, en una videoconferencia, de trabajo en
equipo, es decir compartir diferentes aplicaciones como por ejemplo: compartir
una hoja de clculo, hacer un dibujo estilo pizarra, y que sea compartido entre
ambos conferenciantes, etc. Mucho ms todava cuando en vez de una
videoconferencia de solo dos sitios, tenemos una multi - videoconferecia. Y en
realidad, no est asociada totalmente a 'Videoconferencia', aunque esta su
entorno natural, si no que es un estndar para compartir datos.
Si se utiliza T.120 los datos pueden ser distribuidos en tiempo real a cada uno de
los

participantes,

existiendo

interoperabilidad

entre

equipos

de

distintos

fabricantes, asegurndose la integridad de los datos. Adems este estndar es

independiente de la red (RTC, LAN, RDSI, etc.) y de la plataforma (Unix, PC,
Macintosh, etc.).
En este tipo de conferencias siempre hay uno administrador (es el
'proveedor principal'), que es el que ofrece los servicios de MCS (Multipoint
Conference Services). La conexin de los terminales a este puede ser en estrella,
en cadena, en cascada, etc. Si el proveedor se cae, la conferencia (de datos) se
interrumpe.

En las conferencias de datos hay un 'dominio', que bsicamente es la

conferencia en s, y 'canales' dentro del dominio, que pueden ser pblicos (para
difusin, broadcast) o privados entre usuarios.

49

Voz dobre IP

Estos canales son los siguientes:

1. Canal de errores de control. Prioridad mxima.
2. Canal de anotaciones. Prioridad alta.
3. Canal de Imgenes de Mapa de bits. Prioridad media.
4. Canal de transferencia de ficheros. Prioridad baja.

Algunos de los componentes de la T.120 son:

T.123: Protocolos de transporte de red. Presenta al nivel superior un interfaz

comn, e independiente del medio de transporte.

T.122: Servicio de datos genrico orientado a conexin que junta varias

comunicaciones punto a punto para formar un dominio multipunto. Entre otras
cosas, proporciona difusin de datos con control de flujo, direccionamiento
multipunto, busca el camino ms corto entre estaciones, etc. Los problemas de
reserva y resolucin de recursos se solucionan mediante testigos.

T.125: Protocolo de servicio de comunicacin multipunto. Especifica los mensajes

de protocolo necesarios segn T.122

50

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

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

T.127: Transferencia multipunto de ficheros binarios. Permite la difusin de varios

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

Las aplicaciones de usuario podran utilizar los servicios de T.126, 127 y

128, ir directamente sobre T.124 sobre T.122/125, utilizar T.121...

51

Voz dobre IP

CAPITULO 3.- TELEFONIA IP

La telefona IP es un trmino usado para describir un juego de productos y
soluciones usados para transportar trfico de voz sobre una red de datos.
Utilizando IP (Internet Protocol) como mecanismo de transporte, la telefona IP
permite crear una red convergente en la cual todas las comunicaciones (voz, video
y datos) compartan la misma infraestructura.

52

Voz dobre IP
Existen numerosos beneficios para este tipo de infraestructura, incluyendo
administracin simplificada, ahorro de costos en telecomunicaciones y unificacin
de servicios de mensajes.

SELECCIN PARA IMPLEMENTAR TELEFONIA IP

Es importante tener en cuenta que el trfico de voz y el trfico regular de
datos IP son dos soluciones completamente diferentes. El trafico de datos RTCP
/IP (Regular Transmisin Control Protocol / Internet Protocol) es muy flexible es
decir no da mucha importancia a una WAN con enlaces de transmisin lentos,
perdida de paquetes y recepcin de paquetes fuera de secuencia. De hecho,
TCP/IP opera de esa forma, tomando datos y segmentndolos dentro de
diferentes paquetes y transmitiendo los datos va el mejor camino posible que
encuentre. No siendo de su importancia el orden en el cual los datos son
recibidos, o el camino que toma para llegar a su destino, porque el dispositivo final
es el responsable del reensamble y la resegmentacin de los datos.
Por otro lado el trfico de Voz no permite este tipo de flexibilidad. Aun
cuando el trafico de voz se este convirtiendo a paquetes IP, esto no deja de ser
trafico de voz. La telefona IP depende de los paquetes que

estn siendo

recibidos en el mismo orden en el que fueron enviados, si un paquete se pierde,

este deber permanecer perdido, porque retransmitir el paquete solo confundira a
la persona destino que esta recibiendo la llamada. Para lograr esto, se debe
incorporar nuevas y diferentes caractersticas en los Switches y Routers como
encolado (Queuing) y RTP (Real Time Control Protocol)

COMPONENTES DE TELEFONIA IP
Los componentes que deben ser sumados a la infraestructura para facilitar
la telefona IP son los que realmente opacaran la lnea entre la infraestructura de
53

Voz dobre IP
voz tradicional y la infraestructura de datos. Un punto importante que recordar
cuando estamos considerando una infraestructura convergente, es que no importa
si estamos manejando voz, video o datos, porque a fin de cuentas todo esto son
comunicaciones.

Elementos de una red de red de VoIP.

CALL MANAGER
CallManager provee una solucin de telefona IP basado en un software de

plataforma de procesamiento de llamada para desempear el papel del tradicional

PBX. EL CallManager representa una solucin a gran escala y responde a las
necesidades de la telefona IP. Se han introducido diferentes soluciones de Vos
sobre IP, por ejemplo diferentes programas de Chat como: Microsoft NetMeeting,
Amrica Online, Instant Messenger y Yahoo! Messenger, estos programas ofrecen

54

Voz dobre IP
la capacidad de comunicar voz utilizando Internet otra red como medio, sin
embargo estos carecen de confiabilidad.

El Call Manager debe ofrecer una solucin confiable, escalable y manejable

para cualquier organizacin de cualquier tamao en el que se desee implementar
la telefona IP.

LA PLATAFORMA CALL MANAGER

El Call manager es probablemente la plataforma ms integral de la telefona

IP. Este provee al resto de la arquitectura de la telefona IP con un punto central

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

a un servidor

CallManager soportar de 2500 telfonos IP a 5000 dispositivos de telefona IP por

cada servidor. Un dispositivo IP puede ser cualquiera de los siguientes:

Telfono IP

Gateway analgico o digital

IP softphone (Software de un telfono IP normal)

Procesador Digital de Seales

55

Voz dobre IP

PROTOCOLOS DE TELEFONIA IP

SKINNY STATION PROTOCOL (SSP)

Es un protocolo de comunicaciones basado en el estndar SGCP (Simple

Gateway Protocol). SSP fue primero introducido como un mtodo de comunicacin

entre la primera generacin de telfonos IP, Gateways y servidores CallManager y
aun es ampliamente usado para el mismo propsito. SSP depende del servidor
CallManager para difundir la configuracin y control de la informacin. Este es
creado en TCP/IP y utiliza los puertos TCP 2000-2002.

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

tiempo real
(Internacional

sobre redes de paquetes. H.323 es un estndar de la ITU

Telecommunication Union) y es parte de la familia de

protocolos H.32X. H.323 fue construido basndose en el protocolo H.320,

permitiendo la transmisin de video y audio basado en redes de paquetes como
Ethernet.

MEDIA GATEWAY CONTROL PROTOCOL (MGCP)

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

56

Voz dobre IP

SIMPLIFIED MESSAGING DESK INTERFACE (SMDI)

Es un protocolo estndar de correo de voz para integrar los sistemas de

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

CLUSTERING
El agrupamiento (clustering) permitir extender el soporte para dispositivos
de 2500 telfonos IP sobre un servidor CallManager a alrededor de 10,000
telfonos IP dentro de un grupo sencillo. El agrupamiento (clustering) como su
nombre lo indica, es el proceso de combinar 2 o mas servidores CallManager
dentro de una unidad lgica conocida como Grupo.

Un grupo consiste de

servidores CallManager y sus dispositivos asociados como telfonos IP, gateways

y dispositivos lgicos como SoftPhones que es una versin en Software de un
telfono IP normal. Cuando el concepto de grupo es utilizado, todos los servidores
CallManager comparten la misma configuracin de la base de datos, entonces si
un servidor CallManager falla, los dems ya tienen la configuracin, entonces no
se requiere una nueva configuracin manual.

La idea principal del agrupamiento (clustering), consiste en proveer

suficientes servidores para que si uno de ellos llega a fallar los dems dentro del
grupo puedan tomar la carga del servidor que fallo sin el comprometer el nivel de
servicio de los sistemas finales.
Se tienen 4 perfiles que puede tomar un servidor dentro de un grupo:

Servidor Primario CallManager

57

Voz dobre IP

Servidor de respaldo CallManager

Servidor Publicador de la Base de Datos

Servidor TFTP (Trivial File Transfer Protocol)

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

El papel de servidor publicador de la base de datos es mantener y distribuir

la configuracin maestra de la base de datos. Una segunda pero

igual de

importante tarea es almacenar las grabaciones de los detalles de las llamadas

(Call Detail Records). Un CDR es una grabacin de una llamada telefnica IP. Esta
puede ser usada para anlisis de trfico y funciones adicionales de contabilidad. El
servidor TFTP es usado para proveer una imagen del sistema para los dispositivos
como telfonos IP y gateways.
Como se estructura el grupo depende de cuantos dispositivos de telefona
IP sern soportados. Hay muchas limitaciones que se deben tomar en cuenta
antes de implementar un grupo. Un importante punto es tomar en consideracin es
que un grupo no puede cruzar un enlace WAN. Todos los grupos de servidores
deben existir en la misma LAN adems los servidores deben de interconectarse a
10Mbps. No esta permitido compartir el medio en un grupo, esto es para asegurar
que

la calidad del servicio (QoS) es conservada. Un mximo de 100 grupos

pueden ser interconectados, permitiendo soporte para cerca de 1, 000,000

telfonos IP dentro de una organizacin.

La siguiente figura muestra el

funcionamiento de un grupo y su proteccin:

58

Voz dobre IP

Agrupamiento de CallManagers

59

Voz dobre IP

Proteccin sobre falla

TELEFONOS IP
Los telfonos IP proveen al usuario final una interfase dentro de la
arquitectura de la telefona IP. Algunos

soportan estndares

abiertos

y la

habilidad de interactuar con Microsoft NetMeeting.

Los telfonos IP interactan con la red con una conexin a 10/100Mbps,
aparte de tener un puerto extra para PC o cualquier otro perifrico as como
tambin un puerto RS-232 para capacidades adicionales. Ofrecen una pantalla
LCD para desplegar un men con sus caractersticas establecidas dejando atrs
los botones convencionales.

60

Voz dobre IP
GATEWAYS

Son dispositivos usados para conectar la infraestructura de telefona IP a la

Red de telefona Publica Conmutada (PSTN) o para heredar los sistemas PBX.
Existen diferentes Gateways que soportan diferentes protocolos de gateways. Nos
enfocaremos en los que soportan los protocolos siguientes

Skinny Gateway Protocol

H.323

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

estndar SGCP, sin embargo es usado solo por una marca de proveedor en
particular, en otras palabras mientras SGCP es un estndar abierto SGP es
propiedad estandarizada

de CISCO, haciendo comparacin con el protocolo

HDLC que cada fabricante tiene su propia implementacin.

H.323 es un estndar de la ITU. Los Gateways H.323 son mas comnmente
encontrados en un dispositivo enrutador con gateway integrado y en comunicacin
con el CallManager.
MGCP (Media Gateway Control Protocol) es un estndar tambin y se usa
para comunicar el enrutador-gateway y el CallManager.

61

Voz dobre IP

INTRODUCCION AL VIDEO

Las tradicionales transmisiones de video tpicamente consistan de una

adiferentes lneas

de interfaz de tasa bsica (BRI) de

ISDN conectando

propiamente estaciones terminales de videoconferencias. Estas lneas ISDN

tpicamente operan en una infraestructura punto a punto utilizando la
recomendacin H.320.
Usualmente el ancho de banda usado esta en un rango de 128Kbps a 384Kbps y
resguardado

completamente

de

forma

independiente

de

la

existente

infraestructura de voz y datos, lo cual resulta como una baja utilizacin de los
recursos disponibles.
Aunque algunos avanzados sistemas PBX pueden terminar las lneas BRI
(Basic Rate Interface) para sistemas de videoconferencia, las lneas BRI y las
lneas de voz estn resguardadas de forma completamente separada unas de las
otras.
La videoconferencia basada en IP, por otra parte, utiliza la recomendacin
H.323 permitiendo utilizar

la videoconferencia sobre una variedad de medios,

incluyendo medios compartidos y conmutados como Ethernet, lneas alquiladas y

redes

multiacceso

sin difusin 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

62

Voz dobre IP
video sobre IP las cosas se complican.

Por ejemplo si se tiene una video

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

retardos, no se entendera nada.
Las transmisiones de video basadas en IP as como la telefona IP son muy
similares en naturaleza. Voz en este caso datos de video, son encapsulados
dentro de paquetes IP y transportados a su destino final.
describirn

A continuacin se

algunos de los componentes requeridos para facilitar la video

conferencia basada en IP, componentes como gateways, gatekeepers, unidades

de control multi-punto (MCU) y terminales adaptadoras de video.

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

la red de fuera de la red de la organizacin. Los gateways proveen la resolucin

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

GATEKEEPERS

Un Gatekeeper es un dispositivo usado para permitir o denegar solicitudes

para video conferencias, son una parte integral de la video conferencia basada en
IP. El Gatekeeper es responsable de decidir

si suficientes fuentes estn

disponibles para que la videoconferencia se lleve acabo y si el dispositivo que

solicita la videoconferencia puede obtener el acceso a los recursos solicitados.

63

Voz dobre IP

UNIDADES DE CONTROL MULTIPUNTO

Las Unidades de control Multipunto (MCUs) sirven como un centro, para la

comunicacin e infraestructura de la video -conferencia. Este centro sirve como

un simple punto de control de mando para establecer, enlazar y terminar
transmisiones de video. Un MCU es utilizado cuando tres o ms participantes
necesitan acceso a la misma video conferencia en tiempo real. Un simple MCU
puede controlar diferentes videoconferencias simultneamente.

ADAPTADORES TERMINALES DE VIDEO.

El papel de las Terminales Adaptadores de Video (VTA) en la video

conferencia es proveer una interfase para heredar los sistemas de video

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

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

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

es tpico

encontrar los mismos componentes, usualmente: una video cmara una video
pantalla y componentes de audio.

64

Voz dobre IP
MEJORAR LA INFRAESTRUCTURA DE RED
Como se ha descrito la telefona IP y las video conferencias basadas en IP
crean una Arquitectura para Voz Video y Datos Integrados. Dependiendo de las
necesidades de la red se deben ir agregando nuevos

dispositivos como

servidores CallManager, telfonos IP, video Gateways, Gatekeepers, MCUs, VTAs

y dispositivos de usuario final. Todos estos dispositivos son necesarios para llevar
acabo la Arquitectura para Voz, Video y Datos Integrados.

ENRUTADORES PARA UNA RED CONVERGENTE

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

INTERFACES DE VOZ ANALOGICA

Los enrutadores utilizan interfaces de voz analgica para interactuar
directamente con los telfonos convencionales o para conectarse con el antiguo
sistema

PBX o la Red Publica Conmutada. Como la tecnologa

anloga es

considerada como una vieja y estable tecnologa, estas interfases son

estandarizadas. Existen

actualmente

tres tipos

de

interfaces analgicas

soportadas por algunos enrutadores, que son las siguientes:

65

Voz dobre IP

FXS (FOREIGN EXHANGE STATION)

Los puertos de esta interfaz utilizan un conector RJ-11 para conectarse con

los telfonos convencionales, mdems o faxes. Este es el tipo de interfaz mas

comnmente encontrada en los enrutadores.

FXO (FOREIGN EXCHANGE OFFICE)

Los puertos de esta interfaz utilizan tambin un conector telefnico RJ-11.

Los puertos son comnmente utilizados para conectar por medio de una
negociacin los sistemas PBX al proveedor de servicio telefnico de la red.

E&M (EAR & MOUTH)

Esta interfaz ofrece una solucin mas avanzada que las anteriores, as

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

INTERFACES DE VOZ DIGITAL

Las interfaces de voz digital son provistas en los enrutadores

usando

tarjetas de almacenamiento digital de voz, procesadores de voz digital (DVP

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

66

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

llevar una

conversacin de voz y comprimirla lo mas que se pueda, aproximadamente a 5.3

Kbps, dependiendo del mtodo de compresin utilizado, una gran diferencia con el
canal de 56 Kbps. Esto permite una mejor utilizacin del ancho de banda
disponible.

ENCOLADOS PARA VOZ Y VIDEO

El encolado es un importante punto de diseo y desempeo que debe ser
examinado en la telefona IP. El encolado ha sido tradicionalmente una funcin de
la capa del modelo de referencia OSI para las conexiones WAN, pero cuando se
habla de una red convergente se debe enfocar a las LAN. El trafico en la capa 2
del modelo de referencia OSI puede ser clasificado por el tipo de servicio usando
el protocolo 802.1Q.
Es recomendado que cuando se usa este protocolo se separe el trfico de
voz y video del trfico regular de datos y se ponga este trfico con un encolado de
prioridad alta. El protocolo 802.1Q especifica siete clases de servicio (COS), 0
comienza por la mas baja prioridad y 7 comienza por la mas alta prioridad. Se
recomienda que COS 4 -7 sea usado para voz y video, y que 0-3

para la

operacin normal de datos.

Una nota importante para ser considerada es que en el encolado de capa 2
una vez que los paquetes encuentran un enrutador, la informacin de capa que
llevan esos paquetes se pierde, en otras palabras 802.1Q es solo una solucin
LAN. Para el trfico que cruza enlaces WAN, el encolado de capa 3 debe ser
incorporado.

67

Voz dobre IP
INTRODUCCION A LOS GATEWAYS PARA

LA ARQUITECTURA DE VOZ,

VIDEO Y DATOS INTEGRADOS.

Un Gateway por definicin es un dispositivo que convierte un medio o
protocolo a otro. En el ambiente Voz sobre IP, un Gateway es responsable de
conectar una red de telefona IP a la Red Telefnica Publica Conmutada o PBX y
sistemas clave. Por ejemplo, el gateway puede conectar una red H.323 a una red
basada en SIP (SMDS Interface Protocols), Red Publica Telefnica Conmutada o
ISDN. Tambin desempea resoluciones entre diferentes formatos de transmisin
y procedimientos de comunicacin, y es responsable para establecer y liberar
llamadas en ambos lados de la red. La comunicacin entre las terminales y un
Gateway son hechas a travs de los protocolos H.245 y Q.931.
Los tipos de Gateways van de dispositivos nicos con niveles de entrada
especializados

a Gateways

de nivel empresarial integrados en Switches y

Enrutadores. Basados en los dispositivos o la implementacin, los Gateways se

comunican con otros dispositivos sobre diferentes protocolos Gateway. La propia
infraestructura o los requerimientos para implementar Voz sobre IP determinaran
cual Gateway debe usarse, pero algunas de las caractersticas que se requieren
por default

son: transmisin DMTF, redundancia del CallManager y servicios

suplementarios.

Servicios

suplementarios

que

permitan

los

usuarios

desempear la llamada en espera, transferencia de llamada y conferencia, por

mencionar algunos.

CAPACIDADES DE LOS PROTOCOLOS DE LOS GATEWAYS

Los tres protocolos de voz

de

los Gateways, como se menciono al

principio, son SSP (Skinny Station Protocol), H.323, y MGCP.

El primero permite a un cliente usar TCP/IP para transmitir y recibir llamadas y
paquetes RTP/UDP/IP para audio. Un ejemplo de un cliente es un telfono IP o

68

Voz dobre IP
Gateway. El cliente se comunica con el CallManager sobre TCP en los puertos
2000-2002.
H.323 es el protocolo de Gateways mas soportado por los dispositivos de
diferentes fabricantes y es una recomendacin estndar hecha por la ITU
(Internacional Telecommunications Union) para los paquetes basados en audio,
video, voz y conferencia. Es el estndar central para la conferencia (basado en
H.245, H.225 y Q.931) y es el nico Gateway que provee capacidad de
enrutamiento completo. Este transmite y recibe cadenas va RTP (Real Time
Protocol) junto con RTCP (Real-Time Control Protocol) llevadas sobre UDP (User
Datagram Protocol), por medio de eso provee estado y control de la informacin.
Sealizacin como RAS (Registration, Admisin y Status), H.245 y Q.931 es
transportada sobre sealizacin TCP.Q.931, para el establecimiento y terminacin
de

una llamada. Sin embargo las capacidades son intercambiadas utilizando

H.245, el cual se usa para el control de llamada y estable la comunicacin

multimedia o los servicios de llamada entre los clientes H.323.
El protocolo MGCP funciona en una arquitectura donde la inteligencia del
control de llamada es removida de un Gateway. Level3, Bellcore, Cisco y Nortel
desarrollaron MGCP el cual es un protocolo maestro/esclavo, donde el gateway es
el esclavo sirviendo rdenes del maestro, el cual es el agente que llama. El
CallManager funciona como el agente que llama.
Otro protocolo que esta siendo implementado en los Gateways es SIP
(Session Initial Protocol), es un protocolo de control de la capa de aplicacin que
puede establecer, modificar y terminar sesiones multimedia o llamadas. Estas
sesiones multimedia incluyen conferencias IP, llamadas telefnicas y distribucin
multimedia. Una solucin para este tipo consiste de un agente SIP, un telfono IP,
un Gateway SIP y un servidor Proxy SIP.

69

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

Localizacin de usuario

Capacidades de Usuario

Disponibilidad de Usuario

Establecimiento de llamada

Manejo de llamada
Actualmente, el mundo de Voz sobre IP es dominado por H.323, el

surgimiento de SIP y el incremento del numero de aplicaciones que soporta esta

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

ELECCION DE UN GATEWAY DE VOZ

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

70

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

71

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

72

Voz dobre IP

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

(MCM Multimedia Conference Manager). El

Gatekeeper puede ser configurado en un enrutador existente o en uno dedicado.

73

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

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 bsicas: Registro, Admisin y Estado (RAS- Registration, Admisin and
Status) y sealizacin de llamada. Los Gatekeepers primeramente usan el RAS,
parte del protocolo H.225, con los equipos de usuario final (endpoints) y gateways
para el registro, la admisin y el control de llamada en la red H.323. Los equipos
de usuario final (endpoints) y gateways tambin usan una parte de la sealizacin
de llamada del protocolo, para el establecimiento de llamada.

74

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

Resolucin de direcciones: El Gatekeeper resolver una direccin H.323

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

tambin puede resolver sobre H.323 IDs (cadenas de

caracteres).

Control de admisin: El Gatekeeper puede controlar que equipo de

usuario final (endpoint) enlazar y participara en la red H.323.

Por

simplicidad, el Gatekeeper puede ser configurado para permitir a todos los

equipos de usuario (endpoints) enlazarse a la red H.323. Alternativamente
para una seguridad estricta, este puede admitir solo una lista de equipos de
usuario (enpoints) conocidos.
El Gatekeeper puede tambin restringir la participacin de equipos
de usuario por otras caractersticas configuradas por el administrador, como
disponibilidad de ancho de banda o numero de equipos de usuario activos.
Aunque una red H.323 no requiere un Gatekeeper, si el Gatekeeper existe,
todos los participantes se ven obligados a usarlo, permitiendo que la
seguridad sea mejorada.

75

Voz dobre IP

Control de ancho de banda: El Gatekeeper es responsable del monitoreo

y control del ancho de banda de la red que estn usando todas las
llamadas. Se puede restringir la cantidad de ancho de banda utilizado para
llamada de voz y video (H.323). Esto es muy importante porque si mas
llamadas de las que la red puede soportar son hechas, todas las llamadas
sufrirn de calidad muy pobre.
Por ejemplo el Gatekeeper activamente monitorea todas las llamadas, el

ancho de banda utilizado por cada llamada (ancho de banda solicitado y

establecido)

y la sealizacin de la llamada entre los equipos de usuario

(endpoints).
El Gatekeeper usas toda esta informacin para prevenir que el total del
ancho de banda utilizado por las llamadas de voz y video excedan el lmite
configurado para una zona.

Esto asegura que todas las llamadas permitidas

reciban suficiente ancho de banda. De esta manera el Gatekeeper puede rechazar

llamadas si el umbral para el trafico H.323 ha sido rebasado. En la tradicional red
de voz los canales disponibles en WAN (Wide Area Network) limitaran el lmite del
nmero de llamadas que pudieran ser establecidas. En una red IP, este lmite no
existe, por lo tanto el Gatekeeper debe aplicar este lmite.

76

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

RSVP no es un protocolo de ruteo, sino que es un protocolo de control en

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

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

Que mecanismos de implementacin no son usados de forma directa con

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

COMO TRABAJA EL RSVP?

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

78

Voz dobre IP
Iniciar sesin.
El protocolo RSVP es puesto a menudo entre dos clientes de punto a punto
(semejante a una llamada telefnica), o entre mltiples transmisores y mltiples
receptores (multicast). Para RSVP es constantemente posible negociar un
multipunto escogiendo un punto de transmisin. En algn caso, la sesin RSVP
levanta los procesos reservados en una sola direccin. Para tener garanta de
calidad de servicio

en full - duplex, es necesario que la sesin levante los

procesos que se estn ejecutando al mismo tiempo, una vez en cada direccin.
Por ejemplo, al establecer una llamada de VoIP entre dos usuarios, usualmente
deberia ser necesario, establecer dos reservaciones, uno en cada caso, para
garantizar buena calidad de servicio entre ambas llamadas. Por otro lado la
cadena de video necesitara solo un camino de reservacin.
Desde que hemos estado hablando acerca del protocolo RSVP, hemos
considerado las reservaciones requeridas para una video conferencia entre dos
personas. Sabemos que los componentes de voz y video tienen diferentes
requerimientos de banda ancha, obviamente necesita la separacin de las
reservaciones de voz y video. Considerando que ambos elementos ( voz y video),
necesitaran estar en forma bi direccional, esto quiere decir que tendramos la
necesidad de un total de 4 reservaciones

tomando en

cuenta dos routers.

Tomando en cuenta el ejemplo y aplicando los 4 puntos uno por uno a la video
conferencia, se tiene que 4x (4 1) = 12 reservaciones estando administrado por
cada router. Cuando usamos la frmula A x (B 1) = C, donde A = flujo bi
-direccional, B = Nmero total de Routers, y C = Reservaciones totales por router,
esto no es difcil de realizar estos cambios, se solucionarn cuando intentes
extender la RSVP en una larga escala.
Ahora que hemos explorado algo de esta informacin a fondo, se necesitar
guardar en mente, considerar cuantas sesiones podremos levantar, ponemos
estos pasos a travs de el proceso de una sesin levantada de un RSVP.

79

Voz dobre IP
4.3 SIP PROTOCOLO INICIAL DE SESION

El protocolo inicial de sesin SIP es un protocolo de control de la capa de

aplicacin para crear, modificar y terminar sesiones con uno o ms participantes.
Estas sesiones incluyen conferencias multimedia a travs de Internet, llamadas
telefnicas sobre Internet y distribucin multimedia.

Los miembros en una sesin multimedia pueden comunicar va multicast

(multidifusion) o va una malla de relaciones unicast o combinaciones de esta.

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

SIP soporta movilidad de usuario mediante proxying y redireccionamiento de

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

4.4 FUNCIONALIDAD DE SIP (Session Initial Protocol)

El protocolo inicial de sesin es un protocolo de control de la capa de aplicacin

que puede establecer, modificar y terminar sesiones multimedia o llamadas. Estas
80

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

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

SIP transparentemente soporta mapeado y redireccionamiento de servicios,

permitiendo la implementacin de ISDN y servicios de subscripcin de red de
telefona inteligente. Estas facilidades tambin permiten la movilidad personal.

En el lenguaje de servicios de telecomunicaciones de red inteligente, esto es

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

81

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

SIP soporta cinco facetas de establecimiento y terminacin de comunicaciones

multimedia:

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

Capacidades de usuario: Determinacin del medio y parmetros del medio

(audio/video) para ser usados.

Disponibilidad de usuario: Determinacin de buena voluntad de la llamada

para ser empleada en las comunicaciones

Establecimiento de la llamada: timbrado, establecimiento de los

parmetros de llamada tanto en la llamada como la sesin de llamadas.

Manejo de llamada: Incluyendo transferencia y terminacin de llamadas.

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

82

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

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

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

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

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

DIRECCIONAMIENTO SIP

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

84

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

Una direccin URL SIP puede designar un individuo (posiblemente localizado en

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

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

85

Voz dobre IP
ESTABLECER UN SERVIDOR SIP

Cuando un cliente desea enviar una peticin/solicitud, el cliente tambin lo enva

para un servidor Proxy SIP configurado localmente (como en HTTP),
independientemente de la solicitud URL, o la enva a la direccin IP y puerto
correspondiente de la solicitud URL.

Para el ltimo caso, el cliente debe determinar el protocolo, puerto y direccin IP

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

Un cliente debe ser capaz de interpretar notificaciones explicitas de red (como

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

86

Voz dobre IP
TRANSACCION SIP

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

Si TCP es usado, solicitudes y respuestas dentro de una simple transaccin simple

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

la confiabilidad es llevada

acabo usan retransmisin. El formato de los mensajes SIP y la operacin es

independiente del protocolo de transporte.

INVITACION SIP

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

Voz dobre IP
particular o establecer

una conversacin entre dos. Despus que el sistema

llamado ha aceptado participar en la llamada, el sistema que llama confirma que

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

La peticin INVITE tpicamente contiene una descripcin de sesin, por ejemplo

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

Para sesin unicast, la descripcin de sesin enumera el tipo de medio y formato

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

88

Voz dobre IP
LOCALIZAR A UN USUARIO

Un sistema llamado puede moverse entre un nmero de diferentes sistemas

sobre tiempo, Estas ubicaciones pueden ser dinmicas registradas con el servidor
SIP. La ubicacin del servidor puede tambin usar uno u otros protocolos mas
como finger, rwhois, LDAP, protocolos basados en multicast o mecanismo
dependientes de

sistemas operativos para determinar activamente el sistema

final donde un usuario podra ser alcanzable. La ubicacin del servidor puede
regresar diferentes ubicaciones porque el usuario es registrado en diferentes hosts
simultneamente o porque la ubicacin del servidor

tiene (temporalmente)

informacin imprecisa. El servidor SIP combina los resultados

para producir una

lista de cero o ms ubicaciones.

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

las

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

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

de los dciles firewalls y evitando loops de

89

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

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

PROPIEDADES DE PROTOCOLO

ESTADO MINIMO

Una simple sesin de conferencia o llamada envuelven una o mas transacciones

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

CAPAS DE PROTOCOLO INFERIORES NEUTRALES

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

Voz dobre IP
TCP para cada peticin sobresaliente y uso d multicast. Los enrutadores pueden
interpretar

con mayor facilidad paquetes SIP UDP. TCP permite una mayor

facilidad de paso a travs de los firewalls existentes.

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

En concreto en este trabajo solo se hace referencia a protocolos de Internet. Sin

embargo SIP puede tambin ser usado

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 fcil implementacin
en lenguajes como Java, Tcl y Perl, permite una fcil supresin de errores y lo ms
importante hace a SIP flexible y escalable. Porque SIP es usado para iniciar
conferencias multimedia ms que para entrega de datos multimedia.

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

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

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

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

Ejemplote URLs SIP son:

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

92

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

METODOS

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

mtodo

puede

ser

INVITE,

ACK,OPTIONS

BYE,

CANCEL,

REGISTRER.

METODO INVITE

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

Voz dobre IP

No todos los formatos de descripcin tienen la habilidad para indicar el tipo de

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

Si la descripcin de la sesin ha cambiado, el servidor de agente de usuario debe

ajustar los parmetros de sesin acordadamente, posiblemente despus de
preguntar al usuario para la confirmacin.

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

94

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

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

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

ms fcil.

En general al inicio de cada captulo agregar una explicacin breve de lo que se va

a tratar y poner conclusiones al final del mismo.

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

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

Falta uns seccin de conclusiones generales de la tesina.

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

95

Voz dobre IP
Saludos

96