Sistemas de telecomunicaciones. Concepto de IP en las nuevas redes Integradas (página 2)

Partes: 1, , 3

CAPITULO 2

PROTOCOLOS DE SEÑALIZACIÒN

2.- PROTOCOLO H.323.

H.323 es el estándar creado por la Unión Internacional de Telecomunicaciones (ITU) que se compone por un protocolo sumamente complejo y extenso, el cual además de incluir la voz sobre IP, ofrece especificaciones para vídeo-conferencias y aplicaciones en tiempo real, entre otras variantes.

El H.323 es una familia de estándares definidos por el ITU para las comunicaciones multimedia sobre redes LAN. Está definido específicamente para tecnologías LAN que no garantizan una calidad de servicio (QoS). Algunos ejemplos son TCP/IP e IPX sobre Ethernet, Fast Ethernet o Token Ring. La tecnología de red más común en la que se están implementando H.323 es IP (Internet Protocol).

2.1. COMPONENTES H.323.

Este estándar define un ámplio conjunto de características y funciones. Algunas son necesarias y otras opcionales. El H.323 define mucho más que los terminales. El estándar define los siguientes componente más relevantes como se muestra en la siguiente figura:

• Entidad:

La especificación H.323 define el término genérico entidad como cualquier componente que cumpla con el estándar.

• Extremo:

Un extremo H.323 es un componente de la red que puede enviar y recibir llamadas. Puede generar y/o recibir secuencias de información.

• Terminal:

Un terminal H.323 es un extremo de la red que proporciona comunicaciones bidireccionales en tiempo real con otro terminal H.323, gateway o unidad de control multipunto (MCU). Esta comunicación consta de señales de control, indicaciones, audio, imagen en color en movimiento y /o datos entre los dos terminales. Conforme a la especificación, un terminal H.323 puede proporcionar sólo voz, voz y datos, voz y vídeo, o voz, datos y vídeo.

Las funciones de control que realizan los terminales son las siguientes:

• H.245 para negociación del canal.
• H.225.0 (Q.931) para señalización y control de llamada.
• H.225.0 (RAS) para comunicación con el gatekeeper.

También implementan los protocolos RTP/RTCP para el manejo de los flujos de audio y video.

• Gatekeeper:

El gatekeeper (GK) es una entidad que proporciona la traducción de direcciones y el control de acceso a la red de los terminales H.323, gateways y MCUs. El GK puede también ofrecer otros servicios a los terminales, gateways y MCUs, tales como gestión del ancho de banda y localización de los gateways o pasarelas. El Gatekeeper realiza dos funciones de control de llamadas que preservan la integridad de la red corporativa de datos. La primera es la traslación de direcciones de los terminales de la LAN a las correspondientes IP o IPX, tal y como se describe en la especificación RAS. La segunda es la gestión del ancho de banda, fijando el número de conferencias que pueden estar dándose simultáneamente en la LAN y rechazando las nuevas peticiones por encima del nivel establecido, de manera tal que se garantice ancho de banda suficiente para las aplicaciones de datos sobre la LAN. El Gatekeeper proporciona todas las funciones anteriores para los terminales, Gateways y MCUs, que están registrados dentro de la denominada Zona de control H.323.

Las funciones que debe desarrollar un gatekeeper son las siguientes:

• Control de la señalización.

• Control de acceso y administración de recursos, autorización de llamadas.

• Traducción de direcciones de transporte entre direcciones IP y alias.

• gestión del ancho de banda.

• gestión de llamadas(concesión de permisos…)

• gestión del ancho de banda.

Para desarrollar estas funciones , entre el gatekeeper y el endpoint se emplea el protocolo RAS (Registration /Admission /Status) sobre UDP.

Un gatekeeper y sus endpoints definen una zona H.323, de manera que en entornos LAN's es suficiente un gatekeeper, pero en entornos como Internet, son necesarios varios de ellos, cada uno definiendo una zona H.323.

Lógicamente, entre gatekeepers se requerirá comunicación, por lo que actúa como el punto central para todas las llamadas en una zona, comportándose como un conmutador virtual.

Si bien el gatekeeper no es obligatorio, su empleo en un entorno H.323 sí posibilita emplear más eficientemente la plataforma, por ejemplo mediante el enrutamiento de llamadas a su través.

Los gatekeepers son entidades funcionales separadas de los endpoints H.323, pero es posible incluir funcionalidades gatekeepers en los gateways y las MCU's.

• Gateway:

Un gateway H.323 (GW) es un extremo que proporciona comunicaciones bidireccionales en tiempo real entre terminales H.323 en la red IP y otros terminales o gateways en una red conmutada. En general, el propósito del gateway es reflejar transparentemente las características de un extremo en la red IP a otro en una red conmutada y viceversa. los gateways, son los sistemas encargados de permitir que los equipos H.323 puedan operar con otras redes. Desarrollan la traducción de la señalización, información de control e información de usuario, posibilitando así interoperabilidad entre redes, terminales y servicios, haciendo viable la integración de servicios aún con plataformas dispares, llámese PSTN y redes IP.

Una diferencia respecto a los gatekeepers, es que los gateways sí cursan información de usuario, soportada en RTP/UDP/IP.

• Funciones de los gateways:
• transcodificación de audio y vídeo.
• traducción de procedimientos de comunicación.
• traducción de formatos de transmisión.

Evidentemente, dada su funcionalidad, los gateways son elementos opcionales en entornos H.323, y sólo son necesarios cuando se requiere una interconexión entre entornos H.323 y entornos no H.323:

• MCU (Multipoint Control Units):

La Unidad de Control Multipunto está diseñada para soportar la conferencia entre tres o más puntos, bajo el estándar H.323, llevando la negociación entre terminales para determinar las capacidades comunes para el proceso de audio y vídeo y controlar la multidifusión.

La comunicación bajo H.323 contempla las señales de audio y vídeo. La señal de audio se digitaliza y se comprime bajo uno de los algoritmos soportados, tales como el G.711 o G.723, y la señal de vídeo (opcional) se trata con la norma H.261 o H.263. Los datos (opcional) se manejan bajo el estándar T.120 que permite la compartición de aplicaciones en conferencias punto a punto y multipunto.

Dado el jitter, que sufren los paquetes IP en la red, y las consecuencias negativas de esto para el tráfico de audio y vídeo, en el terminal H.323 se requiere un buffer de recepción para absorber, en la medida de lo posible, estas fluctuaciones en la demora de los paquetes IP, anulando o reduciendo el efecto negativo que el jitter puede producir en flujos de información de usuario con requerimientos de tiempo real.

Los protocolos de control comprendidos en H.323, unos se encapsulan en UDP (protocolos H.225.0 (RAS, Registration Admisión Status), que se desarrolla entre el gatekeeper y los endpoints) y otros en TCP (H.225.0 (Q.931), para el control de la llamada y H.245 para el control del canal.

2.2. FLUJO DE LLAMADAS.

El establecimiento de la llamada en H.323 se lleva a cabo en tres fases:

• Fase RAS: intercambio de mensajes entre el gatekeeper y el endpoint., para la traducción de direcciones , autorización de llamadas y gestión del ancho de banda.
• Fase Q.931: intercambio de mensajes entre endpoints para el establecimiento de conexiones lógicas.
• Fase H.245: intercambio de mensajes entre endpoints para acordar en intercambio de información de usuario.

Dependiendo del papel que juegue el gatekeeper en las llamadas H.323 podremos hablar de dos modelos:

• modelo de llamada H.323 directa (direct routed model)
• modelo de llamada H.323 indirecta (gatekker routed model)

A continuación de estas tres fases de establecimiento de llamada, se lleva a cabo la transferencia de información de usuario por medio de los protocolos RTP/RTCP, según lo acordado en la fase H.245, previa apertura de los canales lógicos en los endpoints. Estos canales lógicos son unidireccionales, por lo que para una comunicación bidireccional se requiere abrir uno en cada dirección de transmisión. En la transferencia de medios no interviene el gatekeeper, pues es solo una entidad de señalización, sino que se lleva a cabo directamente entre os endpoints.

Hasta la fecha, el estandar H.323 ha evolucionado desde la primera versión H.323v1, hasta la última versión H323v4, mejorando la primera versión en cuestiones como seguridad, servicios suplementarios, identificación de llamadas, conexión rápida……etc.

2.3. CARACTERISTICAS Y RECOMENDACIONES DEL PROTOCOLO H.323

El estándar H.323 especifica los componentes, protocolos y procedimientos que proveen los servicios de comunicación multimedia sobre redes de paquetes sin garantía de calidad de servicio, tanto para sesiones multipunto como punto a punto. La tecnología de red más común en la que se están implementando H.323 es IP (Internet Protocol). Además, H.323 también define la señalización necesaria para comunicaciones multimedia sobre redes IP (entre otras). Para el transporte de medios utiliza los protocolos RTP/RTCP.Los terminales y equipos H.323 soportan aplicaciones con requerimientos de tiempo real (voz y vídeo), así como aplicaciones de datos y combinaciones de ellas (videotelefonía, etc). Los terminales H.323 pueden ser terminales explícitamente diseñados a este fin o pueden estar integrados en PC's.

El estándar H.323 incluye entre otras las siguientes recomendaciones:

• H.225.0: paquetización, sincronización y señalización.
• H.245: control del canal.
• G.711, G.722, G.723.1, G.728, G.729: codificación audio.
• Además también define recomendaciones sobre conferencias de datos en tiempo real y seguridad.

H.323 define una serie de entidades en una red H.323 con una serie de funcionalidades:

• Direccionamiento:

1. RAS (Registration, Admision and Status). Protocolo de comunicaciones que permite a una estación H.323 localizar otra estación H.323 a través del Gatekeeper.
2. DNS (Domain Name Service). Servicio de resolución de nombres en direcciones IP con el mismo fin que el protocolo RAS pero a través de un servidor DNS.

• Señalización:

1.    Q.931 Señalización inicial de llamada

2.    H.225 Control de llamada: señalización, registro y admisión, y paquetización / sincronización del stream (flujo) de voz

3.    H.245 Protocolo de control para especificar mensajes de apertura y cierre de canales para streams de voz

• Compresión de voz:

1.    Requerido: G.711

2.    Opcionales: G.728, G.729 y G.723

• Transmisión de voz:

1.    UDP. La transmisión se realiza sobre paquetes UDP, pues aunque UDP no ofrece integridad en los datos, el aprovechamiento del ancho de banda es mayor que con TCP.  UDP provee a los usuarios acceso a los servicios IP.  Los paquetes UDP son entregados como paquetes IP no orientados a conexión, los cuales pueden ser descartados antes de alcanzar su objetivo.

2.    RTP (Real Time Protocol). Maneja los aspectos relativos a la temporización, marcando los paquetes UDP con la información necesaria para la correcta entrega de los mismos en recepción.

• Control de la transmisión:

1.    RTCP (Real Time Control Protocol). Se utiliza principalmente para detectar situaciones de congestión de la red y tomar, en su caso, acciones correctoras. Actualmente se puede partir de

una serie de elementos ya disponibles en el mercado y que, según diferentes diseños, permitirán construir las aplicaciones VoIP. Estos elementos son:

• Teléfonos IP.
• Adaptadores para PC.
• Hubs telefónicos.
• Gateways (pasarelas RTC / IP).
• Gatekeeper.
• Unidades de audioconferencia múltiple. (MCU voz)
• Servicios de directorio.

2.4. ARQUITECTURA DEL PROTOCOLO H.323.

En una arquitectura H.323 (como la que se muestra en la Figura 1) se integran como componentes básicos los Terminales, Gateways (para interconexión con resursos PSTN/IN), Gatekeepers (Control de admisión, registro y ancho de banda) y MCUs (Multiconference Control Units).

Dentro de H.323 se incluyen todo un conjunto de protocolos perfectamente integrados (en la Figura 2 se ilustra la pila de protocolos H.323) que toman parte en el establecimiento y mantenimiento de conferencias multimedia: Q.931 para el establecimiento de llamada, H.225 para la señalización, H.245 para la negociación de capacidades y el establecimiento de canales, H.450.x para la definición de servicios suplementarios (Call Park, Call Pickup, Call Hold, Call Transfer, Call Diversion, MWI, …), RAS para el registro de terminales y el control de admisión, RTP/RTCP para el transporte y secuenciación de los flujos multimedia, G.711/G.712 para la especificación de los codecs, T.120 para colaboración y "dataconferencia"… Esto da una idea muy clara de una de las características menos agradables de este protocolo, y que siempre han argumentado sus detractores: su excesiva complejidad, frente a la sencillez del modelo Internet en que se basa SIP. De hecho SIP se podría comparar, grosso modo, con las partes de Q.931 y H.225 de H.323.

Figura 1

Figura 2

2.5. DEFINICIÒN DE PROTOCOLO SIP.

El protocolo "Session Initiation Protocol" (SIP) es un estándar emergente para establecer, enrutar y modificar sesiones de comunicaciones a través de redes Internet Protocol (IP). Utiliza el modelo de Internet y lo convierte al mundo de las telecomunicaciones, utilizando protocolos Internet existentes tales como HTTP y SMTP (Simple Mail Transfer Protocol). También usa una estructura de dirección URL. Usa estas direcciones de tipo correo electrónico para identificar a los usuarios en lugar de los dispositivos que los utilizan. De esta forma SIP no depende del dispositivo y no hace distinción alguna entre voz y datos, teléfono u ordenador.  Como se describe a continuación, SIP es usado mas para el manejo de servicios, mientras que H.323 se usa prácticamente para la conversión del número telefónico en paquetes IP.

2.6. CARACTERÍSTICAS BÁSICAS DEL PROTOCOLO SIP.

Se trata de un protocolo para el establecimiento de sesiones sobre una red IP. Una sesión que puede soportar desde una llamada telefónica hasta una multiconferencia multimedia con elementos de colaboaración. Está siendo desarrollado por el SIPWG del IETF (RFC 2543, 2543bis), con la misma filosofía de sencillez y mínimo esfuerzo de siempre. SIP está pensado como un mecanismo para el establecimiento, la terminación y la modificación de sesiones. Se trata de un protocolo basado en el paradigma de petición/respuesta (request-response), al igual que HTTP o SMTP.

SIP maneja mensajes de petición: [que se estructuran en tres bloques] Request Line + Cabecera + Cuerpo, y mensajes de respuesta: Status Line + Cabecera + Cuerpo. En ambos casos el cuerpo es independiente de SIP y puede contener cualquier cosa. A efectos de estandarización se definen métodos para describir las áreas de especificación; SIP define los siguientes métodos: invite, bye, options, ack, register, cancel, info (rfc 2976), comet, prack, subscribe/, notify/, message.

En la Figura 3 se ilustra un mensaje tipo, con los campos más importantes de la cabecera y el cuerpo rellenos de forma genérica.

Figura 3

Las respuestas son del tipo HTTP:

1xx Informational (100 Trying, 180 Ringing, 181 Call is being forwarded)

2xx Successful (200 OK, 202 Accepted )

3xx Redirection (300 Multiple choices, 301 Moved Permanently, 302 Moved Temporarily)

4xx Client Error (400 Bad Request, 404 Not Found, 482 Loop Detected, 486 Busy here)

5xx Server Failure (500 Server Internal Error, 501 Not Implemented)

6xx Global Failure (600 Busy Everywhere, 603 Decline).

SIP se puede definir como un protocolo de control, pensado para la creación, modificación y terminación de sesiones, con uno o más participantes. Esas sesiones pueden comprender conferencias multimedia, llamadas telefónicas sobre Internet (o cualquier otra red IP), distribución de contenidos multimedia… Las sesiones pueden realizarse en multicast o en unicast; los participantes pueden negociar los contenidos y capacidades que van a utilizar; soporta movilidad de los usuarios, mediante utilización de proxies.

Las funcionalidades que se le exigen a un protocolo de estas características, son básicamente: La traducción de nombres y las ubicación de usuarios, la negociación de capacidades de cada usuario, la gestión de los usuarios que toman parte en una conferencia (sesión) y la gestión de los cambios en las capacidades de cada participante.

SIP propone la utilización de un direccionamiento análogo al que se usa para el servicio de correo electrónico (e.g. sip:paco[arroba]bbva.com). Para la descripción de contenidos, puede utilizar MIME, estándar de facto en Internet; aunque el IETF sugiere, para la descripción de la propia sesión, la utilización de SDP (Session Description Protocol), que no es un protocolo propiamente dicho, sino un formato [de texto plano] para describir los flujos multimedia que se intercambian en una sesión.

Al igual que el servicio de correo, utiliza DNS para encontrar el servidor adecuado al que se le debe pasar una determinada petición. Está pensado para ser independiente de los niveles inferiores; sólo necesita un servicio de datagramas no fiable, con lo cual se puede montar sobre UDP o TCP. Sobre ese servicio no fiable se monta un transporte con RTP/RTCP.

La Figura 4 pretende ponernos un poco en situación, representando los protocolos implicados en los aspectos de señalización (H.323, SIP, RTCP), provisión de calidad de servicio (RTCP, RSVP), transporte y encapsulación de contenidos multimedia y/o de medios múltiples (H.261, MPEG/RTP) que aparecen en escena cuando se aborda el problema del establecimiento, control y transporte de sesiones, que soportan comunicaciones multimedia entre varios participantes.

Figura 4

2.7. ARQUITECTURA DEL PROTOCOLO SIP.

SIP necesita dos componentes básicos: un agente de usuario (UA, User Agent) y un servidor (NS, Network Server). El agente de usuario, comprende un elemento cliente (UAC, User Agent Client) y un elemento servidor (UAS, User Agent Server). El cliente inicia las llamadas, y el servidor las responde: la idea es realizar llamadas (establecer sesiones ‘peer-to-peer’, P2P) con un protocolo Cliente/Servidor.

Las funciones principales de los servidores SIP son la resolución de nombres y la ubicación de usuarios. Se comunican con otros servidores pasándose mensajes en base a protocolos NHR. Los servidores pueden guardar o no información de estado, dando lugar a dos modos de funcionamiento (‘statefull’ o ‘stateless’ respectivamente para los anglosajones). Los servidores sin estado constituirían lo que se podría denominar el ‘backbone’ de una infraestructura SIP, mientras que los servidores con estado serían los dispositivos más cercanos alos agentes de usuario, que se encargarían del control de los dominios de usuarios.

Otras funcionalidades importantes de los servidores son la redirección (de una petición) y la "distribución" (pueden pasar una llamada a un grupo de usuarios, apropiándose de la sesión el primero que conteste).

Con esos componentes, UAC, UAS y NS, se puede montar una infraestructura básica de SIP; sobre la cual se pueden montar servidores de aplicaciones que podrían alojar módulos de servicio: de mensajería instantánea, de presencia, de control de llamada, perfiles de usuario… Al mismo nivel se supone que interaccionarían con otros servidores de contenidos en una arquitectura distribuida que integraría el balanceo de carga y soportaría la interfaz de gestión.

En el Diagrama 1 se pretende ilustrar el establecimiento de una llamada para mostrar cómo interactúan los elementos básicos que hemos mencionado más arriba.

En este ejemplo, el usuario quiere hablar con es decir con un usuario que habitualmente está en su mismo dominio; pero por algún motivo, que desconocemos, hoy no está en bbva.com, sino en bbv.es aunque paco no lo sabe: tal es así que manda una invitación (invocará un método INVITE) para el usuario al servidor responsable de su dominio (en este caso es un servidor proxy con estado, ‘Stateful Proxy 1’). El servidor enviará la invitación a un servidor para de redirección para tratar de averigüar la localización actual de emilio. Es este servidor de redirección el que determina que el usuario emilio está en el dominio bbv.es y le contesta al proxy con un 302 MOVED TEMPORARILY que incluye la nueva dirección de emilio(sip:). El proxy responde con un 302 ACK, puesto que aquí termina la secuencia de la invitación inicial (INVITE(1) de la figura).

A partir de esta situación, el Proxy 1 [con estado] (Stateful Proxy 1) podría mandarle la dirección de emilio a paco para que él tratara de comunicarse con ´directamente con sip:emilio[arroba]bbv.es. En el ejemplo, lo que hace el proxy 1 es modificar la invitación y tratar de encontrar a sip:emilio[arroba]bbv.es. Como no conoce a ningún otro servidor con estado que se responsabilice del dominio bbv.es, pasará la invitación a un servidor sin estado (‘Stateless proxy’) que conocerá el siguiente salto que debe seguir para llegar hasta sip:emilio[arroba]bbv.es.

Para simplificar el ejemplo hemos querido que ese primer proxy sin estado conozca a un servidor proxy que controla el dominio bbv.es (‘Stateful Proxy 2’). Ese segundo proxy completa la entrega de la invitación para sip:emilio[arroba]bbv.es; momento en el cual emilio acepta la llamada enviando un mensaje de respuesta (200 OK), que recorre el mismo camino de vuelta de la invitación hasta llegar a sip:paco[arroba]bbva.com. Ahora paco debería mandarle un ACK de esta respuesta a emilio; y aunque en principio podría hacerlo directamente, en nuestro ejemplo hemos decidido que toda la señalización pase por los proxies de cada dominio (se supone que así lo habrán indicado en los mensajes de invitación que se han cruzado).

SIP sigue el modelo Cliente/Servidor: los proveedores de servicio [de acceso troncal] podrían ofrecer esa infraestructura SIP como un servicio IP más a otros proveedores de servicio, que a su vez podrían montar sobre ella sus propios servicios SIP que comercializarían en modo ISP/ASP.

SIP proporciona los mecanismos necesarios para ofrecer una serie de servicios:

Usuarios:

1. Localización.
2. Disponibilidad y capacidades (servicio de presencia y terminal asociado).
3. Perfil.

Llamadas

1. Establecimiento.
2. Mantenimiento.
3. Desvíos.
4. Traducción de direcciones.
5. Entrega de los números llamado y llamante.
6. Movilidad: direccionamiento único independiente de la ubicación del usuario.
7. Negociación del tipo de termina.l
8. Negociación de las capacidades del terminal.
9. Autenticación de usuarios llamado y llamante.
10. Tranferencias ciegas y supervisadas.
11. Incorporación a conferencias multicast.

SIP mecanismos necesarios para ofrecer una serie de servicios según se puede ver en la figura 5:

Figura 5

2.8. MENSAJERÍA INSTANTÁNEA (IM) DEL SIP.

La mensajería instantánea puede que merezca un apartado aparte, puesto que se ha convertido, por su sencillez e inmediatez, en un medio de comunicación que resulta adecuado para el intercambio rápido de ideas entre pequeños equipos de trabajo distribuidos. El concepto de la "lista de amiguetes" (‘buddy list’) que ha surgido en entornos de IM como AOL o ICQ resulta interesante: es el hecho de poder disponer de una lista de usuarios de un servicio, con su disponibilidad online anunciada constantemente en la red. Es un servicio que se integra fácilmente, puesto que se trata de clientes muy ligeros.

AOL y Yahoo han conseguido congregar una gran comunidad de usuarios en entornos corporativos (¿Quién no se ha pasado la mitad de la jornada mandándose mensajitos con sus colegas en el Yahoo Messanger?). Lotus y Microsoft (M$) están integrando servidores de IM en sus plataformas corporativas; e incluso es una funcionalidad que se está integrando en muchas plataformas CRM, como un canal más de contacto con el cliente.

Una sesión que se establece con SIP puede incluir cualquier medio de soporte, de manera que podemos pasar una comunicación vía IM a una conferencia telefónica, una pizarra compartida tipo NetMeeting o una videoconferencia. Podemos pensar en una especie de "telefonía instantánea" como evolución.

En el mundillo de la telefonía móvil hay un claro precedente de la IM: el servicio de SMS. Tanto Yahoo como AOL han visto la potencialidad de este servicio y ya se están moviendo para alcanzar acuerdos con proveedores de servicios móviles.

Ese concepto de presencia asociado a las ‘buddy lists’ también está evolucionando; se habla de presencia no sólo a nivel del propio PC del puesto, sino asociado con cualquier tipo de dispositivo o aplicación independiente: es el caso de los ‘bots’ que IBM utiliza en su Lotus SameTime: son ‘buddy lists’ que representan realmente consultas a bases de datos o directorios corporativos. En principio se trata de la extensión del concepto de mensajería instantánea a un contexto mucho más amplio del que propició su origen: estamos hablando del intercambio de mensajes entre usuarios, que pueden ser personas (usuarios finales del servicio que tendrán uno u otro perfil asociado), máquinas (cualquier tipo de terminal asociado a un usuario), o aplicaciones (que pueden incluir agentes inteligentes o servicios Web).

Todas las posibilidades que se han mencionado nos llevan a la integración de todo tipo de comunicación en el "escritorio" del puesto de cada empleado, posibilitando la gestión conjunta de todos los medios de comunicación a disposición de aquellos, con un ‘repositorio’ único de contactos a mantener. Este aspecto resulta de un interés indudable en el entorno empresarial, puesto que redunda de forma directa en el incremento de la productividad de los empleados, permitiendo el despliegue de servicios de valor añadido como cualquier otro servicio sobre una arquitectura SIP apoyada en una red IP multiservicio.

A pesar del ámbito de este documento, no debemos olvidar que, la que en boca de muchos es la ‘killer application’ que servirá de catalizador para los servicios de banda ancha en el acceso, los juegos en red, se beneficia enormemente de las posibilidades que ofrece SIP. Una sesión de juego en red (‘online gaming’) es una comunicación sobre UDP que se establece entre sockets seguros, durante la cual se intercambian flujos multimedia RTP. Además hoy en día ya se incorporan servicios de IM para la comunicación y coordinación táctica de los jugadores. SIP va a permitir evolucionar hacia un escenario de mayor interactividad con comunicación vía VoIP entre los jugadores; de la misma forma el servicio de presencia permitirá evitar la necesidad de conectarse con un servidor maestro para iniciar las partidas, pudiendo utilizar una lista para ver quién está conectado en cada momento e invitarle a una partida sobre la marcha.

2.9. PROTOCOLO H.248 ( MEGACO).

Este protocolo se define en la Recomendación H.248 de la ITU-T.  El protocolo H.248 o Megaco permite la conmutación de llamadas de voz, fax y multimedia entre la red PSTN y las redes IP de siguiente generación. El protocolo Megaco, que tiene su origen en el protocolo MGCP (Media Gateway Control Protocol, Protocolo de control de puerta de enlace al medio), proporciona un control centralizado de las comunicaciones y servicios multimedia a través de redes basadas en IP. Megaco está adquiriendo solidez en el mercado porque permite una mayor escalabilidad que H.323, y da respuesta a las necesidades técnicas y a las funciones de conferencia multimedia que se pasaron por alto en el protocolo MGCP.

Funcionalmente, Megaco es un protocolo de señalización utilizado entre los elementos de una arquitectura distribuida que incluye media gateway y controladores de media gateway (conocidos a menudo como softswitches, gatekeeper o call server)

H.248 es el resultado de la cooperación entre la ITU y el IETF. Antes de lograr esta cooperación existían varios protocolos similares compitiendo entre si, principalmente MGCP (la combinación de SGCP e IPDC) y MDCP.   H.248 se considera un protocolo complementario a H.323 y SIP, ya que un Media Gateway Controller (MGC), controlará varios Media Gateways utilizando H.248, pero será capaz de comunicarse con otro MGC utilizando H.323 o SIP.

2.9.1.  MGCP.

El MGCP es, en esencia, un protocolo maestro/esclavo, donde se espera que los gateways ejecuten comandos enviados por el MGC. El Protocolo de Control de Media Gateway (MGCP) es usado para controlar los gateways de telefonía desde los elementos de control de llamadas externos llamados Media Gateways Controllers (MGC) o Gatekeepers. 

Un gateway de telefonía es un elemento de red que provee conversión entre las señales de audio transportadas sobre los circuitos telefónicos y los paquetes de datos transportados sobre la internet o sobre otra red de paquetes.

MGCP asume una arquitectura de control de llamada, donde la inteligencia del control de la llamada está fuera de los gateways y manejada por un elemento de control de llamada externo.  El MGCP asume que estos elementos de control de llamadas o MGC, se sincronizarán entre sí para enviar comandos coherentemente a los gateways que están bajo su control.

Lo que se propuso con MGCP fue sacar el control de la señalización del propio gateway (GW), llevándolo a otro elemento, el ‘media gateway controller’ MGC (que se conoce como ‘softswitch’) que se encargará del control de los media gateways’(MGW).

A nivel de sistemas lo que se ha hecho es desagregar el gatekeeper (GK) en sus equivalentes en el mundo SS7. Esta iniciativa surgió de varios fabricantes con el nombre de IPDC (Cisco, Alcatel, 3Com et al.) por un lado y SGCP (Telcordia) por otro; un esfuerzo que el IETF aglutinó bajo la denominación de MGCP y asignada a la responsabilidad del grupo de trabajo Megaco. MGCP es en la fecha de redacción de este documento un documento de trabajo. Tanto IETF como la ITU-T trabajan para llegar a un estándar, el primero bajo la responsabilidad de Megaco y como H.248 para el segundo.

En MGCP se puede decir que se ha separado la "inteligencia" (las funciones de control) de los datos (los contenidos: ‘the media’). Que se trata de un protoclo Maestro/Esclavo. El maestro es el MGC (‘softswitch’ o ‘call agent’) y el esclavo es el MGW (que puede ser un GW de VoIP, un DSLAM, un router MPLS, un teléfono IP,…). Esta es precisamente la característica que más choca con la filosofía (P2P) de SIP. Otra característica interesante es que intenta reproducir el modelo de la PSTN/IN sobre IP (en la Figura 6 se ilustra el escenario típico para un despliegue tipo ‘Internet Telephony’ que es la aplicación para la que se pensó, al menos en principio esta solución), en contra del modelo distribuido que propone SIP.

Figura 6

El Megaco pretende dar una solución basada en una visión propia de las Telcos tradicionales, una oficina central (Central Office, CO, en este caso IPCO) y una red de sucursales (Branch Offices, BO). Tal y como se observa en la Figura 7, SIP puede complementar a MGCP en un escenario donde tengamos varios MGC.

Figura 7

En la Figura 8 se detalla un poco más lo que sería un escenario integrado con la PSTN, pensando en prestar el servicio de telefonía sobre Internet.

Figura 8

Un tema de debate importante es la utilización de MGCP para controlar los terminales (los teléfonos IP por ejemplo); el problema que surge es que sólo soporta servicios básicos de red inteligente. El tema es que si se quieren desplegar servicios avanzados necesitamos montar SIP tanto en los terminales como sobre la red de señalización, realizando las funciones de control asociadas al servicio.

Ya se ha comentado más arriba que la visión de los partidarios de MGCP es que la inteligencia del servicio esté pegada a los MGC (softswitch), y de hecho en el corto plazo es un planteamiento adecuado puesto que el esfuerzo de convergencia se centrará en los puntos de interconexión entre la PSTN y la red IP, y pro tanto interesará que los servidores SIP estén junto a los MGC en la CO. Pero, según avancemos hacia un escenario más integrado, la atención se centrará en la infraestructura IP, con lo cual la función de los MGC se alejará de los puntos de interconexión. Finalmente, en un entorno IP puro, la función de creación de servicios se distribuirá por toda la red: se puede extender el modelo ASP para dar servicios de voz.

Tanto los ASPs como los ISPs, o incluso los propios usuarios finales pueden crear sus propios servicios. Se puede pensar en un escenario basado en SIP, donde se utilice MGCP para controlar internamente un GW de Telefonía IP (TIP) y los servidores de aplicaciones SIP distribuirían servicios por la red a través de los servidores proxy SIP.

Como conclusión debemos extraer el hecho de que MGCP no se puede considerar como un competidor de SIP, puesto que ambos resultan complementarios en ciertos aspectos, mientras que son mutuamente excluyentes en otros.

Esta idea de dividir el Gateway de voz en varias entidades funcionales se ha propuesto también desde iniciativas como TIPHON (Telecommunications and Internet Protocol Harmonization Over Networks) de la ETSI, con la intención de proporcionar una arquitectura "escalable" que soporte el servicio de Telefonía IP con la necesaria capacidad para convivir con las redes tradicionales de conmutación de circuitos (SCN, Switched Circuit Networks) como la PSTN. Esta división es la que se ilustra en el Diagrama 2 (de la misma forma en la Figura 9 podemos ver los componentes e interfaces en cuya definición trabaja la ETSI en el ámbito de TIPHON).

Figura 9

2.10. SIGTRAN.

2.10.1 ¿QUÉ ES EL SIGTRAN ?

SIGTRAN (de signalling transport) es el nombre del grupo de trabajo del IETF encargado de definir una arquitectura para el transporte de señalización en tiempo real sobre redes IP. A raíz de ello, no sólo se creó una arquitectura, sino que se definió un conjunto de protocolos de comunicaciones para transportar mensajes SS7 sobre IP.

2.10.2 ARQUITECTURA DE LOS PROTOCOLOS SIGTRAN .

La arquitectura definida por el Sigtran [RFC2719] consta de tres componentes:

• IP estándar como protocolo de red.

• Un protocolo común de transporte de señalización. Los protocolos definidos por el Sigtran se basan en un nuevo protocolo de transporte sobre IP, llamado SCTP (Stream Control Transmission Protocol).

• Capas de adaptación específicas para cada capa de la torre SS7 que se necesite transportar. El IETF ha definido las siguientes: M2PA, M2UA, M3UA, SUA, TUA e IUA. IP SCTP Capa de adaptación S7UP/S7AP

11. M2UA [RFC 3331].

M2UA son las siglas de MTP2 User Adaptation. El protocolo M2UA, al igual que M2PA, adapta MTP3 a SCTP, e igualmente gestiona asociaciones SCTP en lugar de enlaces MTP3. M2UA permite el intercambio de mensajes MTP3 entre dos puntos de señalización IP o entre un punto de señalización IP y una pasarela IP-SS7.

M2UA es un protocolo entre pares en caso de que la comunicación comience y

termine en dos puntos de señalización IP, sin SGWs intermedios, tal como muestra la

Figura 12.

Sin embargo, M2UA no es un protocolo entre pares si se implementa en una pasarela de señalización. En ese caso, M2UA no procesa las órdenes (primitivas del protocolo) que le llegan desde la capa superior (MTP3), sino que las envía tal cual hacia un nodo remoto, mediante SCTP.

Como M2UA no procesa las primitivas de MTP3, sino que las reenvía, en caso de que se utilice un SGW se debe entender este protocolo como un medio que comunica la capa MTP3 de un nodo IP con la capa MTP2 de un SGW, tal como muestra la Figura 13.

De esta forma, varios puntos de señalización IP con MTP3 sobre M2UA pueden acceder a la red SS7 tradicional a través de los mismos enlaces MTP2 físicos.

Es importante tener en cuenta que, debido a la propia naturaleza del protocolo, sólo puede existir un SGW M2UA en una misma comunicación MTP3, por lo que no se puede utilizar para transportar mensajes MTP3 entre dos nodos SS7 puros a través de una red IP. Si se utiliza M2UA, alguno de los extremos es un punto de señalización IP.

13. M3UA [RFC 3332].

M3UA son las siglas de MTP3-User Adaptation. M3UA es un protocolo que

transporta mensajes procedentes de un usuario de MTP3 (ISUP, TUP o SCCP) a través de una red SCTP/IP hasta un nodo remoto.

De forma similar a M2UA, M3UA simplemente transporta los mensajes hasta el destino, pero no realiza por sí mismo las funciones de la capa MTP3. Esto significa que M3UA no dispone de tablas de encaminamiento basadas en puntos de señalización, ni realiza ninguna otra función propia de MTP3.

En general, M3UA se utilizará como medio de transporte de primitivas entre la capa usuaria de MTP-3 (SCCP o ISUP) de un punto de señalización IP y la capa MTP3 de un SGW remoto, tal como muestra la Figura 14.

1. UTILIZACIÓN DE M3UA.

Como se ha visto, dado que M3UA transporta primitivas desde la capa ISUP o SCCP de un nodo hasta la capa MTP3 de otro (típicamente un SGW), este protocolo sólo puede utilizarse para conectar nodos con señalización IP a una red SS7. Por tanto, no se puede utilizar M3UA para descargar tráfico SS7 entre dos nodos TDM a través de red IP, a no ser que se utilicen SGWs con SCCP. Pero para esta aplicación es mucho más adecuado utilizar SGWs con M2PA, por los motivos indicados en el apartado 3.3.