66.48 Seminario de Redes. Trabajo Práctico Nº3. H.323 vs. SIP. vs. Grupo: MOG

Transcripción

1 66.48 Seminario de Redes Trabajo Práctico Nº3 H.323 vs. SIP vs. Grupo: MOG 2º Cuatrimestre 2004

2 H.323 Introducción 2 Protocolos 3 Señalización y Control de la Llamada 5 Procesamiento de Audio y Video 6 Transporte 7 SIP Introducción 9 Aspectos generales 9 Componentes 10 Mensajes 12 Modo de operación 13 Ejemplos de señalización SIP Llamada Básica 15 Proxying 16 Redirection 17 Registration 17 Generalizando 18 Comparación entre SIP y H Página 1

3 H.323 Introducción H.323 es un Standard de la ITU-T, publicado hacia El Protocolo H.323, describe terminales, y otras entidades, que proveen servicios de comunicación multimedia sobre redes que emplean conmutación de paquetes, las cuales no necesariamente puedan proveer una Calidad de Servicio (QoS) garantizada. Las entidades H.323, pueden proveer comunicaciones de datos, video o audio en tiempo real. En este enfoque, se definen 4 tipos de dispositivos, de acuerdo a la función que cumplen durante una llamada: 1. Terminal 2. Gatekeeper 3. Gateway 4. Unidad de Control Multipunto (MCU) El Terminal, es el dispositivo que inicia una llamada, enviando la información de destino al Gatekeeper. Son los puntos de acceso de los clientes que proveen comunicación bidireccional en tiempo real. Todas las terminales deben soportar comunicaciones de voz, siendo la comunicación de video y datos opcional. H.323 define la manera en que diferentes tipos de terminales, que soportan diferentes servicios, pueden comunicarse. Además todos los terminales deben soportar H.245, el cual es utilizado para la negociación de capacidades y uso de los canales lógicos. Los otros componentes requeridos son Q.391 para la señalización y el establecimiento de la llamada, RAS (Registration Admisión Status) para comunicarse con el Gatekeeper, y por último RTP/RTCP para la secuenciación y temporización de paquetes de audio y video. Opcionalmente los terminales incluyen codecs de video, el protocolo de conferencia T.120, y capacidades de MCU (Multipoint Control Unit). Página 2

4 Si el destino final es un abonado a la red pública convencional, en algún punto, necesariamente, se debe producir la conversión de paquetes IP, a paquetes de voz digitalizada, capaces de atravesar una central pública (PSTN), y una red de conmutación de circuitos hasta llegar al abonado llamado. El elemento donde se produce esta conversión se denomina Gateway. El Gateway es un elemento opcional en una conferencia H.323. Proveen traducción entre terminales H.323 y otros puntos terminales, por ejemplo para intercomunicar la PSTN con una LAN que trabaja con IP/H.323, el Gateway trabaja en la capa tres del modelo OSI. Establecen vínculos con terminales de la PSTN, con terminales H.320 a través de ISDN, etc. Los Gateways no son requeridos sino se realizarán comunicaciones entre distintos tipos de redes. Los terminales se comunican con los Gatways a través de los protocolos H.245 y Q.391. Los puntos terminales deben registrarse con el Gatekeeper. Todos los terminales registrados con un mismo GK forman una zona. La traducción de direcciones realizada por el GK es de Alias a direcciones IP. Cada llamado en la zona es autorizado por el GK. En la norma H.323, el Gatekeeper, es el encargado de autorizar la llamada y rutearla (a través de la red IP) a su destino final, traduciendo direcciones y controlando el acceso a los recursos de la red H.323 por parte de los Terminales, Gateways y MCUs. Actúa como el centro de todas las llamadas de la zona, y provee servicios de control a los puntos terminales registrados. Además actúa administrando el ancho de banda. De esta manera el Gatekeeper puede aceptar o rechazar nuevas conexiones dependiendo de de la disponibilidad de ancho de banda. Finalmente, el MCU se utiliza en el caso de realizarse conferencias con múltiples participantes simultáneos, lo que es mucho más simple de hacer en IP que con líneas telefónicas convencionales. Las conferencias pueden se realizadas de manera centralizada, con el MCU como centro de la conferencia; o descentralizada, usando mensajes Multicast; o una combinación de ambas. La conferencia Centralizada requiere la existencia de un MCU. Todos los terminales mandan paquetes de audio, video, datos y de control al MCU en mensajes Unicast. El MCU está integrado por el MC (Multipoint Controller) y el MP (Multipoint Processor). El MC hace de moderador de la conferencia, usando para ello las funciones de control de H.245. El MP hace las mezclas de Audio y video, asì como la distribución de datos, y manda las paquetes a los participantes, pudiendo usar para ello mensajes Multicast. Protocolos El H.323, en realidad, no es un protocolo único, sino una especificación tipo Paraguas, que abarca la transmisión de Audio/Video propiamente dichos, la transmisión de fax, y todo lo relacionado con la señalización y el control de las llamadas, utilizando las normas H.225, H.245, y de más. Página 3

5 Puertos IP y Protocolps usados por dispositivos H.323 Puerto Tipo de Puerto Descripción Cliente H.323 Microsoft ILS H.323 MCU 80 Estático TCP HTTP Interface (optional) X 389 Estático TCP ILS v2.0 Registration (LDAP) x x 1002 Estático TCP Win 2000 ILS Registration x x 1503 Estático TCP T.120 x x H.323 Gatekeeper 1718 Estático UDP Gatekeeper Discovery x X X 1719 Estático UDP Gatekeeper RAS x x X 1720 Estático TCP H.323 Call Setup x x 1731 Estático TCP Audio Call Control x x 8080 Estático TCP HTTP Server Push (optional) x Dinámico TCP H.245 (Call Parameters) x x Dinámico UDP RTP (Video Stream Data) x x Dinámico UDP RTP (Audio Stream Data) x x Dinámico UDP RTCP (Control Information) x x Del gráfico anterior se observa que H.323 está por encima de la capa de transporte. En el caso de IP, el audio y el video son transportados por UDP, mientras que los datos y las señales de control son transportados por TCP. Las señales de control, y el tráfico de datos, no pueden ser entregados fuera de orden ni pueden ser perdidos, de ahí el transporte en TCP. El tráfico de audio y video no puede ser retardado, aunque pude ser extraviado eventualmente si grandes pérdidas de información para el receptor. El transporte en UDP del audio y video resultará por ello adecuado, siempre que se pueda reordenar la secuencia de los paquetes recibidos, tarea asociada al protocolo RTP. Página 4

6 Señalización y Control de la Llamada El flujo de información en H.323 consiste en una mezcla de señales de audio, video, datos y paquetes de control. La información de control es fundamental para el establecimiento de la llamada, intercambio, negociación y para propósitos administrativos. H.323 usa tres protocolos de control: H.245 (control del medio), H.225/Q.931 (señalización de la llamada), y H.225.0/RAS. La señalización se transporta sobre los protocolos TCP/IP o UDP/IP. La familia de protocolos de señalización en H.323 incluye los siguientes protocolos: -H.225. Incluye los mensajes de control de señalización de llamada que permiten establecer la conexión y desconexión. La señalización de control es un requerimiento básico necesario para establecer la llamada y para iniciar y finalizar comunicación entre dos puntos terminales. Para ello, H utiliza un subconjunto del protocolo de señalización Q.931. Q.931 fue desarrollado para señalización de ISDN. H adoptó la señalización de Q.931 al incorporarlo en su formato de mensaje. La señalización de H se envía directamente de un punto terminal a otro cuando no hay ningún Gatekeeper entre ellos. En caso contrario se rutea a través del Gatekeeper. -Q.931. Este protocolo es definido originalmente para señalización en accesos ISDN básico. Es equivalente al ISUP utilizado desde el GW hacia la red PSTN. -RAS (Registration, Admission and Status) utiliza mensajes H.225 para la comunicación entre el GW y GK. Sirve para registración, control de admisión, control de ancho de banda, estado y desconexión. Los mensajes RAS son codificados en ASN.1. Estos mensajes sirven para: descubrir Gatekeepers, resolver nombres (H.323 a IP), Control de Ancho de Banda, etc. Se utilizan los puertos de UDP 1718 (GK discovery)/1719 -H.245. Este protocolo de señalización transporta la información no-telefónica durante la conexión. Es utilizado para comandos generales, indicaciones, control de flujo, gestión de canales lógicos, etc. Se usa en las interfaz GW-GW y GW-GK. El H.245 es una librería de mensajes con sintaxis del tipo ASN.1. En particular codifica los dígitos DTMF (Dual-Tone MultiFrequency) en el mensaje User Input Indication. H.323 requiere que los puntos terminales negocien para determinar ciertos parámetros antes de que se establezca el intercambio de audio, video o datos. H.245 usa mensajes de control y comandos que son intercambiados durante la llanada para informar e instruir. La incorporación de H.245 es mandatoria en todos los puntos terminales. Corre sobre un puerto dinámico de TCP ( ). H.245 provee las siguientes funciones de Control del Medio Intercambio de Capacidades: H.323 permite a los puntos terminales tener distintas capacidades. Cada punto terminal almacena su capacidad de recepción y transmission (bit rates, codecs, tipo de medio, etc) en un mensaje y se lo manda al otro (u otros) punto terminal. Canales lógicos: H.323 usa canales lógicos unidireccionales para el audio y video, mientras que los canales de datos son bidireccionales. Un canal separado es necesario para el intercambio de audio, video y de datos. H.245 controla la apertura y el cierre de esos canales. Los mensajes de H.245 de control usan el canal lógico 0 que está siempre abiertos. Página 5

7 Mensajes de Control de Flujo: Estos mensajes proveen realimentación a los puntos terminales cuando se presenta un problema de congestión. Los mensajes de H.245 de control pueden ser ruteados en caso de que exista un Gatekeeper intermedio Procesamiento de Audio: El tráfico de señal vocal se realiza sobre UDP/IP. La codificación de audio puede ser de diferentes tipos. Con G.711 a velocidad es de 64 kbps. El ITU-T ratificó en 1995 a G.729 para las aplicaciones de VoIP. En tanto, el VoIP-Forum en 1997, liderado por Intel y Microsoft, seleccionó a G con velocidad de 6,3 kbps para la aplicación VoIP. La codificación de vídeo se realiza de acuerdo con H.263. Ambos servicios se soportan en el protocolo de tiempo real RTP. G.711: Modulación de la señal de voz G.722: Codificación de señales de audio de 7 khz para canales de 64 kb/s G.723.1: Codificadores de voz para transmisión de tráfico multimedia entre 5.3 y 6.3 kb/s G.728: Codificación de la voz a16 kb/s G.729: Codificación de la voz a16 kb/s Procesamiento del Video: H.261: Codecs de Video a Px64kps. H.263: Codificación de Video para comunicaciones de bajo bit rate Conferencia de Datos: -T.120. Es el mecanismo para empaquetar y enviar tramas de datos. Permite el intercambio de datos en tiempo real. Algunas de las características que ofrece son las siguientes: Intercambio Multipunto de datos en tiempo real Interoperabilidad Detección y corrección de errores Escalabilidad T.120 está compuesto a su vez de T.121, T.122, T.123, T.120 se basa en que las capas inferiores proveen confiabilidad, de ahí que se monte sobre TCP. Transporte: - Protocolo RTP. El protocolo de transporte en tiempo real (RTP) y su asociado protocolo de control (RTCP) son empleados para brindar servicio de transporte en tiempo real, es decir, entregar tramas de audio y video en tiempo y de manera ordenada. RTP/RTCP son una recomendación de la IETF (RFC 1889) que provee fragmentación, numeración de secuencia, estampado de tiempo, e identificación de ruta. También pueden proveer detección y corrección básica de errores. Entre sus funciones se encuentran: la memorización de datos, la simulación de distribución interactiva, el control y mediciones de aplicaciones. Página 6

8 RTP en si mismo no provee ningún mecanismo para asegurar entrega segura o cualquier tipo de QoS, sino que confía en capas inferiores para ello, así como tampoco garantiza la entrega ordenada de paquetes. Los números de secuencia incluidos en RTP permiten al receptor reconstruir la secuencia de paquetes del transmisor. RTP se basa en los protocolos de capas inferiores para proveer multiplexación de datos y tramas de control RTCP. En redes IP, RTP corre en un puerto par de UDP ( ), y RTCP corre en el siguiente puerto impar. Ambos puertos son dinámicos. El RTP trabaja en capa 4 y sobre UDP, de forma que posee un checksum para detección de error y la posibilidad de multiplexación de puertas (port UDP). Las sesiones de protocolo RTP pueden ser multiplexadas. Para ello se recurre a un doble direccionamiento mediante las direcciones IP y el número de port en UDP. Sobre RTP se disponen de protocolos de aplicación del tipo H.320/323 para vídeo y voz. El RTP funciona en conjunto con RSVP (capa 3, Resource Reservation Protocol) para la reservación de ancho de banda y asegurar de esta forma la QoS del tipo Garantizada. La QoS del tipo Diferenciada se logra mediante la priorización de tráfico que puede adoptar dos alternativas. En IP se pueden asignar diversas alternativas de prioridad para formar una cola de espera en routers. Un algoritmo particular de gestión de prioridad de tráfico es el WFQ (Weighted Fair Queuing) que utiliza un modelo de multiplexación TDM para distribuir el ancho de banda entre clientes. Cada cliente ocupa un intervalo de tiempo en un Round-Robin. La funcionalidad ToS (Type of Service) en IP puede determinar un ancho de banda específico para el cliente. Un servicio sensible al retardo requiere un ancho de banda superior. En IP además del ToS se puede utilizar la dirección de origen y destino IP, tipo de protocolo y número de socket para asignar una ponderación. En redes Multiaccess de capa 2 se requiere extender la gestión de la calidad de servicio a dicha capa. Para ello la IEEE ha determinado el ToS sobre IEEE-802. El RTP además provee transporte para direcciones unicast y multicast. Por esta razón, también se encuentra involucrado el protocolo IGMP para administrar el servicio multicast. El paquete de RTP incluyen un encabezado fijo y el payload de datos; RTCP utiliza el encabezado del RTP y ocupa el campo de carga útil. - Protocolo RTCP (Real-Time Control Protocol). Este protocolo permite completar a RTP facilitando la comunicación entre extremos para intercambiar datos y monitorear de esta forma la calidad de servicio y obtener información acerca de los participantes en la sesión. RTCP se fundamenta en la transmisión periódica de paquetes de control a todos los participantes en la sesión usando el mismo mecanismo de RTP de distribución de paquetes de datos. El protocolo UDP dispone de distintas puertas (UDP Port) como mecanismo de identificación de protocolos. RTCP está basado en la transmisión periódica de paquetes de control a todos los participantes de una sesión. El protocolo inferior es el encargado de proveer multiplexación de los datos y los paquetes de control, usando por ejemplo distintos puertos UDP. RTCP provee una realimentación del QoS efectivo, lo cual es clave en el rol que juega RTP como un protocolo de transporte, y está relacionado al control de flujo y de congestión de otros protocolos de transporte. La realimentación de QoS puede ser utilizada para actualizar algoritmos adaptativos de codificación, asi como obviamente detectar alguna falla den la comunicación. RTCP manda periódicamenete paquetes de control a todos los usuarios. Provee información de los distintos participantes en una sesión. Además, para poder realizar las dos funciones anteriores, se debe controlar el Rate al cual se mandarán y recibirán los paquetes de Página 7

9 control, lo cual también es función del RTCP. El RTCP involucra varios tipos de mensajes, por ejemplo: -Send report para emisión y recepción de estadísticas (en tiempo random) desde emisores activos. -Receiver Report para recepción estadística desde emisores no activos. -Source Description para un identificador de nivel de transporte denominado CNAME (Canonical Name). -Bye para indicar el final de la participación en la conexión. -Application para aplicaciones específicas. Seguridad: -H.235. Provee una mejora sobre H.323 mediante el agregado de servicios de seguridad y encriptación como autentificación y privacidad. El H.235 trabaja soportado en H.245 como capa de transporte. Todos los mensajes son con sintaxis ASN.1. Provee servicios de integridad, autentificación y no repudio. Servicios Suplementarios: H.450.1: Generic functions for the control of supplementary services in H.323 H.450.2: Transferencia de llamados H.450.3: Desviación de llamados H.450.4: Llamado en espera H.450.5: Call park and pick up H.450.6: Call waiting H.450.7: Message waiting indication H.450.8: Names Identification services H.450.9: Call completion services for H.323 networks. Página 8

10 SIP Introducción En los últimos años el interés por las redes de paquetes IP (Internet Protocol) como soporte de tráfico multimedia ha experimentado notable crecimiento. En tal sentido, tanto ITU (Internacional Telecommunications Union) como el IETF (Internet Engineering Task Force) han estado desarrollando arquitecturas y protocolos para sistemas multimedia sobre IP. Con SIP es posible implementar, sobre redes IP, servicios telefónicos básicos y avanzados. Su sencillez resulta muy atractiva. Aspectos generales SIP (RFC 2543) es un protocolo de control del nivel de aplicación, concebido para la señalización y el control de llamadas, esto es, para el control del establecimiento, modificación y terminación de sesiones o llamadas multimedia. En la figura se muestra su ubicación en la pila de protocolos de telefonía IP. SIP forma parte de las especificaciones del IETF para comunicaciones multimedia, conjuntamente con otros protocolos como RSVP (Resource reservation Protocol), RTP (Real Time Protocol), SDP (Session Description Protocol), etc., pero su funcionalidad no depende de ninguno de éstos. Soporta comunicaciones entre usuarios de redes IP, y también, con el empleo de gateways, con usuarios de otras redes, por ejemplo, con terminales de las redes telefónicas convencionales. SIP es neutral en relación con los protocolos de las capas inferiores, por lo que puede soportarse sobre TCP (Transmisión Control Protocol) o UDP (User Datagram Página 9

11 Protocol, puerto bien conocido 5060). Múltiples transacciones SIP pueden ser soportadas en una simple conexión TCP. En cambio, un simple datagrama UDP solo porta un mensaje SIP. Los datagramas UDP, incluyendo todas las cabeceras, no deben ser mayores que la MTU (Media Transmisión Unit) del trayecto, si es que ésta se conoce, o no mayores de 1500 bytes si no se conoce. SIP es un protocolo basado en texto, utiliza el juego de caracteres ISO con codificación UTF-8 (RFC 2279), lo que posibilita una fácil implementación y depuración. El sobre encabezamiento que implica usar un protocolo basado en texto no tiene aquí mayor trascendencia, pues SIP es un protocolo de señalización. Los puntos clave de SIP son los siguiente: Componentes ya conocidos SIP puede ser considerado como un hijo del Simple Mail Transfer Protocol (SMTP) and HyperText Transfer Protocol (HTTP). Como estos, SIP utiliza las Multipurpose Internet Mail Extensions (MIME) para llevar información. También utiliza Universal Resource Identifiers (URI s) para direccional como lo hace HTTP. Escalabilidad Los Usuarios pueden estar localizados en cualquier parte de Internet y ser invitados a diferentes sesiones al mismo tiempo. Interoperabilidad Es un Estándar abierto, con lo cual la variedad de implementaciones que se pueden desarrollar es muy amplia. Genéricamente, las comunicaciones multimedia con el protocolo SIP comprenden: localización del usuario, determinación de la disponibilidad del usuario para la comunicación, determinación de los medios para la comunicación, esto es, las capacidades de usuario, establecimiento de los parámetros de la comunicación entre las partes involucradas, manipulación de las llamadas, es decir, establecimiento, modificación y terminación de llamadas. SIP lleva información acerca de la sesión como un attachment, similar al . Sólo le concierne la entrega del mensaje y no el contenido. El attachment más comúnmente utilizado en los mensaje SIP es Session Description Protocol (SDP). Utiliza Realtime Transport Protocol (RTP) para el transporte multimedia, y se vale de Realtime Transport Control Protocol (RTCP) para el control del tansporte multimedia. Componentes Los SIP User Agents son los endpoints usados para realizar y recibir llamadas. Pueden ser teléfonos IP, puede ser un software corriendo en una pc (Softphones), o una combinación de un adaptador telefónico analógico con un aparato telefónico clásico. Elementos funcionales Página 10

12 Los elementos funcionales en la arquitectura SIP son Agentes de Usuario (User Agent, UA), y Servidores de red. Los Agentes de Usuario son aplicaciones que residen en las estaciones terminales SIP, y contienen dos componentes: Agentes de Usuario Clientes (User Agent Client, UAC) y Agentes de Usuario Servidores (User Agent Server, UAS). Los UAC originan las solicitudes SIP (asociados al extremo que origina la llamada), y los UAS responden a estas solicitudes, es decir, originan respuestas SIP (asociados al extremo que recibe la llamada). Los UA s deben implementar el transporte tanto sobre TCP como sobre UDP. Los UAC s y UAS s pueden, por si solos y sin los servidores de red, ser capaces de soportar una comunicación básica (modelo de llamada básico, directamente entre endpoints). No obstante, la potencialidad de SIP se aprovecha con el empleo de los servidores de red. Los servidores de red se clasifican, desde un punto de vista lógico, de la manera siguiente: Servidores de redirección (Redirect Server) Procesan mensajes INVITE, que son solicitudes SIP, y retornan la dirección (o direcciones) de la parte llamada, esto es, el SIP URL (Uniform Resource Locator) de la parte llamada, o cómo contactar con ella (respuesta 3xx). De lo contrario rechaza la llamada, enviando una respuesta de error (error de cliente 4xx o error de servidor 5xx). Desarrollan una funcionalidad similar al Gatekeeper H.323. Servidores proxy (Proxy Server) Corren un programa intermediario que actúa como servidor y como cliente, respecto al llamante se comporta como servidor, y respecto al llamado como cliente. Un servidor Proxy puede reenviar solicitudes hasta el destino final sin efectuar cambio alguno en ellas, o cambiar alguno de sus parámetros si se requiere, por ejemplo, en el caso de las cabeceras Via Record Route. Los servidores proxy desarrollan el routing de los mensajes de solicitudes y respuestas SIP. Pueden ser stateful o stateless. Los servidores proxy stateful retienen información de la llamada durante el tiempo que dure el establecimiento de ésta, no así los servidores proxy stateless,los que procesan un mensaje SIP y entonces olvidan todo lo referente a la llamada hasta que vuelven a recibir otro mensaje SIP asociado a la misma. Esto se refiere al estado de la llamada, sin embargo, pueden mantener un estado para una simple transacción SIP, lo que es denominado minimal state. La implementación stateless provee buena escalabilidad, pues los servidores no requieren mantener información referente al estado de la llamada una vez que la transacción ha sido procesada. Además, esta solución es muy robusta dado que el servidor no necesita recordar nada en relación con una llamada. Sin embargo, no todas las funcionalidades pueden ser implementadas en un servidor proxy stateless, por ejemplo, las funcionalidades relativas a la contabilización y facturación de las llamadas puede requerir funcionalidades proxy stateful, de manera que se le pueda seguir el rastro a todos los mensajes y estados de una comunicación. Servidores de registro (Registrar Server) Registran las direcciones SIP (SIP URL) y sus direcciones IP asociadas, es decir, garantizan el mapeo entre direcciones SIP y direcciones IP. Típicamente están localizados con servidores Proxy o servidores de redirección. Es un servidor que acepta solo mensajes de solicitud REGISTER, posibilitando el registro correspondiente a la localización actual de los usuarios, esto es, seguir el rastro de los usuarios, pues por diferentes razones (conexión vía ISP, usuarios móviles, conexión vía LAN con DHCP) las direcciones IP de éstos puede cambiar. También se les denomina servidores de localización (Location Server), pues son utilizados por los servidores proxy y de redirección para obtener información respecto a la localización o Página 11

13 localizaciones posibles de la parte llamada. Ahora bien, en rigor, los Location Server (LS) no son servidores SIP, ni entidades SIP, si no bases de datos, que pueden formar parte de arquitecturas de comunicaciones que utilicen SIP. Entre un LS y un servidor SIP no se utiliza el protocolo SIP, por ejemplo, en ocasiones se emplea entre éstos el protocolo LDAP (Lightweight Directory Access Protocol). La información registrada en los servidores de registro, esto es, el registro del mapeo de direcciones SIP correspondiente a un usuario, no es permanente, requiere ser refrescado periódicamente, de lo contrario, vencido un time out (por defecto, una hora), el registro correspondiente será borrado. Este valor por defecto del time out puede ser modificado según valor que se especifique en la cabecera Expires de un mensaje de solicitud REGISTER. En consecuencia, para mantener la información de registro, el terminal (o el usuario) necesita refrescarlo periódicamente. Igualmente, un registro vigente puede ser cancelado y/o renovado por el usuario. Usualmente, un servidor de red SIP implementa una combinación de los diferentes tipos de servidores SIP ya comentados: servidor proxy + servidor de registro y/o servidor de redirección + servidor de registro. En cualquier caso deben implementar el transporte sobre TCP y UDP. Mensajes Los mensajes SIP los podemos dividir en: Solicitudes (Métodos) SIP. Son seis los métodos básicos definidos en SIP. INVITE: invita a un usuario, o servicio, a participar en una sesión. ACK: confirma que el cliente solicitante ha recibido una respuesta final desde un servidor a una solicitud INVITE, reconociendo la respuesta como adecuada. Solo para reconocer solicitudes INVITE, y no otros mensajes de solicitud. OPTIONS: posibilita descubrir las capacidades del receptor. BYE: finaliza una llamada, o una solicitud de llamada. Puede ser enviado por el agente llamante o por el agente llamado. CANCEL: cancela una solicitud pendiente, pero no afecta una solicitud ya completada. Este método finaliza una solicitud de llamada incompleta. REGISTER: se utiliza este método como un servicio de localización que registra la localización actual de un usuario. Respuestas (Códigos de estado)sip Después que se recibe e interpreta un mensaje de solicitud SIP, el receptor del mismo (servidor SIP) responde con un mensaje (o varios) de respuesta (código de estado). 1xx: Informativo. Solicitud recibida, se continua para procesar la solicitud. Por ejemplo, 180, RINGING. 2xx: Solicitud exitosa. La solicitud (acción) fue recibida de forma adecuada, comprendida y aceptada. Por ejemplo, 200, OK 3xx: Redireccionado. Más acciones deben ser consideradas para completar la solicitud. Por ejemplo, 302, MOVED TEMPORARILY. Página 12

14 4xx: Error de cliente. La solicitud contiene mal la sintaxis o no puede ser resuelta en este servidor. Por ejemplo, 404, NOT FOUND. 5xx: Error de servidor. El servidor ha errado en la resolución de una solicitud aparentemente válida. Por ejemplo, 501, NOT IMPLEMENTED. 6xx: Fallo global. La solicitud no puede ser resuelta en servidor alguno. Por ejemplo, 600, BUSY EVERYWHERE. Los mensajes respuestas 2xx, 3xx, 4xx, 5xx y 6xx son respuestas finales, y terminan la transacción SIP. En cambio, los mensajes de respuestas 1xx s son respuestas provisionales, y no terminan la transacción SIP. Modo de operación Ya antes se planteó que los UAs pueden, por si solos y sin los servidores de red, ser capaces de soportar una comunicación básica, esto es, directamente entre endpoints. Pero también se dejó establecido que la potencialidad de SIP se aprovecha con el empleo de los Servidores de red. Entonces, la señalización SIP puede desarrollarse por intermedio de servidores proxy, o servidores de redirección, a través de los cuales se llevan a efecto las transacciones SIP. De manera muy resumida, la operatividad SIP es la siguiente: UAC emite una solicitud, servidor proxy interviene en la localización de la parte llamada, UAS acepta (o rechaza) la llamada, o UAC emite una solicitud, servidor de redirección notifica la dirección de la parte llamada, UAS acepta (o rechaza) la llamada Por lo que se requiere la localización de servidores y usuarios SIP, invitaciones SIP, servicios de registro SIP, transacciones SIP, direcciones SIP, etc. Direcciones SIP: los objetos direccionados a través del protocolo SIP son usuarios en hosts, que se identifican mediante SIP URL s del tipo user@host, donde: user: nombre de usuario o número telefónico; host: nombre de dominio o dirección numérica de red. Los SIP- URL s son utilizados en los mensajes SIP para indicar, en relación con una solicitud: origen (from), destino actual (request- URI) y destino final (to). También para especificar direcciones de redirección. Localización de un servidor SIP Cuando un cliente SIP desea enviar una solicitud, debe enviar ésta a un servidor proxy configurado localmente, o Página 13

15 enviar dicha solicitud a la dirección IP y puerto que corresponda, por lo que es evidente que el software cliente debe disponer de una, o de un conjunto de direcciones SIP relativas a servidores SIP. Transacciones SIP Una vez efectuada la localización de un servidor SIP, tienen lugar las transacciones, entendiendo como tal el conjunto de solicitudes (o solicitud) enviadas por el cliente al servidor, y las respuestas (o respuesta) retornadas por éste al cliente. Se trata de solicitudes y respuestas relacionadas, o lo que es lo mismo, con determinados parámetros idénticos (por ejemplo, call- ID, Cseq, to, from). Si se emplea TCP como protocolo de transporte, la solicitud (o solicitudes) y la respuesta (o respuestas) de una transacción usan la misma conexión TCP. Varias solicitudes desde el mismo cliente y al mismo servidor pueden emplear la misma conexión TCP, o para cada transacción una conexión TCP diferente. Esto es, una conexión TCP puede soportar una o varias transacciones entre un cliente y un servidor. Invitaciones SIP Una invitación SIP consta de dos solicitudes, por tanto corre a cargo de un cliente. Estas parejas de solicitudes son INVITE y ACK, o INVITE y BYE, según el caso. La solicitud INVITE contiene, generalmente, la descripción de la sesión, descrita con formato SDP. Esta descripción informa a la parte llamada qué tipo de medios el solicitante puede aceptar, y dónde éste desea le sean enviados los datos. Localización de usuarios SIP Dado que el usuario llamado puede desplazarse entre diferentes terminales, con un Servidor de Localización estas localizaciones pueden registrarse dinámicamente. Para esto puede usarse uno de diferentes protocolos, por ejemplo, finger, LDAP, etc. Un Servidor de Localización puede retornar varias localizaciones, bien porque el usuario esté loggeado en diferentes hosts al mismo tiempo, o porque el Servidor de Localización tenga temporalmente información no actualizada. Con esta información, y según el tipo de servidor SIP, proxy o de redirección, se procede así: Servidor de redirección: retorna dicha información de dirección al cliente solicitante, y éste procede a direccionar a la parte llamada. Servidor proxy: secuencialmente, o en paralelo, intenta éste direccionar a la parte llamada. Servicio de registro SIP Posibilita que el cliente, mediante una solicitud REGISTER, notifique a un servidor, proxy o de redirección, su ubicación. Ya se ha comentado antes que usualmente en la práctica un servidor de localización o registro acompaña a los servidores proxy y redirección. Nótese que, tanto uno como otro, debe consultar a un servidor de localización para poder desarrollar su tarea. Página 14

16 Implementación mínima Una implementación mínima de SIP bebe cumplir, en relación con los elementos funcionales clientes y servidores, lo siguiente CLIENTES: deben ser capaces de generar las solicitudes INVITE y ACK, así como las cabeceras Call-Id, Content-Length, Content-Type, Cseq, Require, From y To. También deben entender el protocolo SDP y ser capaces de reconocer las clases 1 hasta la 6 de los status code. SERVIDORES: deben entender las solicitudes INVITE, ACK, OPTIONS y BYE. De tratarse de servidores proxy, también la solicitud CANCEL..También deben ser capaces de generar de manera apropiada las cabeceras Call-Id, Content- Lenght, Content-Type, CSeq, Expires, From, Max-Forwards, Require, To y Via. Ejemplos de señalización SIP Llamada Básica El primer ejemplo son tan sólo dos teléfono SIP IP conectados por una Ethernet. Uno llama al otro utilizando la dirección IP de este último. 1 INVITE El usuario A disca al usuario B. Esto causa que se le envíe un INVITE a B RINGING B recibe el INVITE, comienza a sonar, y envía el mensaje 180 RINGING hacia A. Página 15

17 3 200 OK B atiende el teléfono, y en consecuencia envía un mensaje de respuesta 200 OK al teléfono A. 4 ACK A recibe el 180 RINGING y el 200 OK y responde a este último con un pedido de ACK. 5 Voice (RTP) En cuanto B responde se establece, a través de RTP, un canal de voz entre ambos teléfonos. En realidad hay dos caminos en el canal de voz. El primero se establece desde el teléfono que suena hacia el que llamó. El segundo, desde el usuario que llamó hacia el usuario llamado, se establece inmediatamente luego de haber respondido. Esto asegura que en cuanto responde al llamado, el que llama pueda escuchar el Hola del usuario al que llamó. 6 BYE Cuando B cuelga por que terminó la conversación, le envía un pedido BYE a A OK A recibe el pedido y responde con un mensaje 200 OK. La llamada concluye y se corta el canal de voz. Luego A cuelga. Proxying El Proxy protege al Redirect Server autenticando a los usuarios que envian INVITEs. No puede generar pedidos pero sí forwardearlos a otros servers o rechazarlos en ciertos casos. Página 16

18 1 INVITE El teléfono A llama a otro teléfono. Así A envía un INVITE a la red TRYING El Proxy A recibe el INVITE y envía una respuesta 100 Trying a A, informándole que la red recibió el INVITE. No se necesita otro INVITE. 3 INVITE Una vez que autentica el INVITE, el Proxy A lo forwardea al Redirect Server para rutearlo Moved Temporarily El Redirect Server recibe el INVITE y busca en su tabla de usuarios registrados a la parte que se la está llamando. Si no está registrada, consulta un plan de discado para determinar a donde debe enviar el INVITE. Genera un mensaje 302 Moved Temporarily, con la información de ruteo y es enviado al Proxy A. 5 ACK Proxy A envía un pedido de ACK al Redirect Server apenas recibe el 302 Moved Temporarily. 6 INVITE Proxy A toma la información de ruteo y genera un nuevo INVITE mandándolo a la siguiente parada en la red TRYING El siguiente Server en la red, un Proxy que no aparece en la figura, recibe el INVITE y devuelve un mensaje 100 Trying indicando que el mensaje fue recibido. Redirection La idea de un Redirect Server es la de instruir a los Proxies sobre el siguiente paso en la ruta para alcanzar al destino. No propaga mensajes, es decir, no forwadea INVITEs u otros mensajes al próximo salto en la red. Se encargan de obtener las información de ruteo. Registration Cuando un teléfono SIP IP es conectado a un sistema telefónico basado en SIP, lo primero que hace es registrarse en el Redirect Server para iniciar el uso del sistema de llamadas y para proveer información de ubicación y así permitir que llamadas entrantes sean correctamente Página 17

19 direccionadas. Generalmente, los mensajes al Redirect Server pasan a través de un Server de Autenticación, que puede ser un Proxy o un Redirect Server en sí. Si es registrado exitosamente se le provee una dirección IP para permitirle la llegada de llamadas entrantes. 1 REGISTER Apenas es prendido el teléfono A y conectado a la red, envía un REGISTER al Proxy A TRYING Proxy A lo recibe y envía un mensaje 100 TRYING en respuesta. Este le informa a A que el REGISTER ha sido recibido. 3 REGISTER En el esquema básico de autenticación, el Proxy A forwardea el REGISTER al Registrtation Server. En otros esquemas, el Proxy intercambia mensajes con el teléfono SIP para pedir datos de autenticación. El Regsitration Server almacena estos datos OK El Registration Server envía una respuesta 200 OK al Proxy. En este caso no hay ACK OK Proxy A forwardea el 200 OK a A, que ya está registrado en el sistema. Generalizando En la figura, el Proxy A es el Proxy de Ingreso por que recibe el INVITE desde fuera del sistema y los forwardea al Redirect Server. Proxy B es el de Egreso ya que forwardea el INVITE a un endpoint que está fuera del sistema. Es posible que estos estén corriendo en el mismo host. 1 INVITE A envía un INVITE a la red TRYING Proxy A recibe el INVITE y devuelve un 100 TRYING en respuesta hacia A. 3 INVITE Página 18

20 Proxy A, habiendo autenticado el INVITE, lo forwardea al Redirect Server para rutearlo Moved Temporarily El Redirect Server genera el mensaje 302 Moved Temporarily de los datos provenientes del INVITE y de la información de ruteo que le provee el Location Server. 5 ACK Proxy A envía un pedido de ACK al Redirect Server apenas recibe el 302 Moved Temporarily. 6 INVITE Proxy A toma la información de ruteo del mensaje 302 Moved Temporarily, generando un nuevo INVITE, y lo envía al Proxy B TRYING Proxy B recibe el INVITE y responde con 100 TRYING. 8 INVITE Proxy B forwardea el INVITE al Redirect Server para rutearlo Moved Temporarily El Redirect Server genera el 302 Moved Temporarily y los envía al Proxy B. 10 ACK Proxy B le hace un pedido de ACK al Redirect Server apenas recibe el Moved Temporarily. 11 INVITE Proxy B toma la información de ruteo del mensaje 302 MT y genera un nuevo INVITE que lo envía a B TRYING B recibe el INVITE y responde con 100 TRYING A continuación se muestra el flujo de mensajes una vez que B comienza a sonar RINGING B comienza a sonar y envía un 180 RINGING hacia la red con destino hacia A. El usuario en el teléfono A escucha tonos de timbre Página 19

21 El usuario de B atiende, así genera un mensaje 200 OK y lo envía a través de la red hacia a A A devuelve un mensaje de ACK a través de la red. 22 RTP Voice Channel Se abre el canal de voz, y las partes ya pueden hablar. Finalización de la conversación BYE and 100 TRYING El usuario de B corta. Envía un mensaje BYE a través de la red para A. A medido que pasa los Proxies, una respuesta 100 TRYING se le envía de vuelta para que frene la retransmisión del BYE OK A cuelga y envía un mensaje 200 OK hacia B. La llamada y el canal de voz finalizan. El Redirect Server no está involucrado en la llamada luego de enviar el mensaje 302. Página 20

22 Comparación entre SIP y H.323 La primera diferencia más importante es el enfoque de ambas arquitecturas. Mientras H.323 especifica como debe realizarse el intercambio de Media Streaming a través de redes que no garantizan QoS, SIP surge como un protocolo genérico para la iniciación de sesiones de servicios. A su vez, es distinto el enfoque de las organizaciones que los crearon. La ITU-T pretende estandarizar todo. Esto se refleja en que los servicios suplementarios deben estar especificados por la ITU-T y cómo se éstos ubican en su jerarquía de protocolos. En cambio, la IETF sólo pretende estandarizar el protocolo de inicio de sesión y no los servicios que se negocian. Vale la pena recalcar que SIP es un protocolo abierto a nuevas características, esto se debe a la codificación de los mensajes del mismo. Al utilizar MIME (Multipurpose Internet Mail Extensions), como HTTP, le permite ignorar a una entidad de SIP los parámetros que no entiende, dando así una compatibilidad hacia atrás que H.323 no puede lograr con sus distintas versiones. Esta última imposibilidad de H.323 se debe a que su protocolo está codificado en ASN.1 binario, y se especifica exactamente donde va cada cosa, no pudiendo entender algo si no se esperaba que llegara. Resumiendo, H.323 debe tener estandarizado todo para poder funcionar y requiere poseer iguales versiones para poder hacer uso de las nuevas características. Como consecuencia de lo dicho en el párrafo anterior SIP posee una amplia interoperabilidad entre fabricantes, mientras que en H.323 es limitada. A continuación se comparan el establecimiento de una llamada en SIP y H.323 con sus variantes: En SIP (realizada con MSN Messenger) No. Time Source Destination Protocol Info SIP/SDP Request: INVITE sip: :4126, with session description SIP Status: 100 Trying SIP Status: 180 Ringing SIP/SDP Status: 200 OK, with session description SIP Request: ACK sip: : media Streaming SIP Request: BYE sip: : SIP Status: 200 OK Podemos observar que tras intercambiar 5 datagramas ya se está compartiendo el stream de voz, por lo que el delay para el streaming es de 2,5 RTT. En H.323 No. Time Source Destination Protocol Info H CS: setup H CS: callproceeding H CS: alerting H CS: connect H.245 TerminalCapabilitySet H.245 MasterSlaveDetermination H.245 TerminalCapabilitySet H.245 MasterSlaveDetermination H.245 TerminalCapabilitySetAck H.245 MasterSlaveDeterminationAck H.245 TerminalCapabilitySetAck H.245 MasterSlaveDeterminationAck H.245 OpenLogicalChannel (g729annexa) H.245 OpenLogicalChannel (g729annexa) Página 21

23 H.245 OpenLogicalChannelAck H.245 OpenLogicalChannelAck...Media Streaming H.245 EndSessionCommand H CS: releasecomplete H.245 EndSessionCommand H CS: releasecomplete Podemos observar que tras intercambiar 16 datagramas más 2 three-way handshake (H.225 TCP y H.245 TCP), que hacen un total de 22 datagramas se empieza a enviar el stream de voz, por lo que el delay para el streaming es de 11 RTT, bastante mayor que para SIP. En H.323 con Fast Start No. Time Source Destination Protocol Info Q.931 SETUP[Short Frame] H CS: callproceeding H CS: alerting H CS: connect OpenLogicalChannel H.245 TerminalCapabilitySet H.245 MasterSlaveDetermination H.245 TerminalCapabilitySet H.245 MasterSlaveDetermination H.245 TerminalCapabilitySetAck H.245 MasterSlaveDeterminationAck H.245 TerminalCapabilitySetAck H.245 MasterSlaveDeterminationAck...Media Streaming H.245 EndSessionCommand H CS: releasecomplete H.245 EndSessionCommand H CS: releasecomplete Podemos observar que tras intercambiar 12 datagramas más 2 three-way handshake (H.225 TCP y H.245 TCP), que hacen un total de 18 datagramas se empieza a enviar el stream de voz, por lo que el delay para el streaming es de 9 RTT, considerablemente mayor que para SIP. Como se puede ver en la descripción, la información de establecimiento se envía en paquetes anteriores, en este punto se produce la no compatibilidad hacia atrás. En H.323 con Fast Start y Tunneling No. Time Source Destination Protocol Info Q.931 SETUP[Short Frame] H CS: callproceeding H.245 CS: alerting TerminalCapabilitySet TerminalCapabilitySetAck MasterSlaveDeterminationAck H.245 CS: empty TerminalCapabilitySetAck MasterSlaveDeterminationAck H.245 CS: empty RoundTripDelayRequest H.245 CS: empty RoundTripDelayResponse...Media Streaming H CS: connect OpenLogicalChannel H.245 CS: releasecomplete EndSessionCommand H.245 CS: releasecomplete EndSessionCommand Con Tunneling se aprovecha la conexión TCP establecida por H.225 para enviar los mensajes H.245, ahorrándose el tiempo de establecimiento de una conexión TCP. Podemos observar que tras intercambiar 6 datagramas más 1 three-way handshake (H.225 TCP y H.245 TCP), que hacen un total de 9 datagramas se empieza a enviar el stream de voz, por lo que el delay para el streaming es de 4,5 RTT, mayor que para SIP pero del orden. Como se puede ver en la Página 22

24 descripción, la información de establecimiento se envía en paquetes anteriores, y nuevamente en este punto se produce la no compatibilidad hacia atrás. En general se puede ver que H.323 fue convergiendo a SIP en lo que respecta a tiempo de establecimiento, pero nunca dejó de lado su codificación de los mensajes, aún cuando no iba a existir compatibilidad hacia atrás. Otras diferencias y similtudes de SIP con H.323 son: o SIP es autocontenido para establecer conferencias punto a punto y multipunto. H.323 requiere de una Unidad de Control Multipunto (MCU). o Servicio de localización de usuario: permite la movilidad del usuario y está basado en un esquema jerárquico al igual que el DNS. En cambio, H.323 utiliza RAS que fue ideado para un ambiente de LAN, aunque se extendió. o User Capabilities: SIP utiliza SDP así como H.323 utiliza H.245 para negociar los parámetros de media. o Disponibilidad de usuario: SIP define códigos de respuesta muy explícitos con información sobre la disponibilidad actual del usuario. o Así como H.323 fue definiendo sus extensiones SIP también lo hizo con el agregado de mensajes REFER/REPLACE (modificación del espacio de conversación), UPDATE (modificar la sesión), desvío (JOIN/FORK), mensajes instantáneos (MESSAGE), eventos (SUBSCRIBE/NOTIFY), información dinámica (INFO). Sin embargo SIP, mantiene compatibilidad hacia atrás. o SIP fue basado en Internet por la IETF mientras que H.323 fue basado en la telefonía. Utilizando como base de sus protocolos HTTP y señalización de ISDN respectivamente. o Debido al esquema de localización de usuarios SIP ofrece una excelente escalabilidad que no puede igualar H.323. Si bien todo parecería indicar que SIP es más apropiado para el intercambio de media streaming, éste surgió cronológicamente en 1999(Ver Reseña Histórica), 3 años después que H.323, con lo que el mercado adoptó la primera y única solución que existía y fue marcando su lugar. Sin embargo, hoy en día las tendencias dicen que SIP se impondrá gracias a su simplicidad y funcionalidad, aunque otros expertos dicen que ambos convergerán, hecho que puede verificarse a través de las extensiones de cada uno para lograr más facilidades. Breve Reseña Histórica 95 Primer transmisión de voz sobre IP de PC a PC, mediante software Internet Phone. A fines del mismo año se aprueba el protocolo RTP (Real Time Transport Protocol) 96 VocalTec y Dialogic presentan el primer proyecto para la fabricación de un Gateway de telefonía IP. Poco después, la ITU aprueba la especificación H El VoIP Forum recomienda la especificación G.723.1, donde se resuelve sacrificar calidad sonora a favor de ganar en eficiencia de ancho de banda. 98 Se aprueba H.323 v.2 que mejora la versión 1. Nuevas funcionalidades, aplicación en redes WAN. 99 Se lanza SIP en la RFC 2543 a la competencia de H.323 Página 23

25 99 Se aprueba H.323 v.3 que mejora la versión 2. Nuevas funcionalidades, fax-over-packet networks, comunicaciones gatekeeper-gatekeeper, mecanismos de conexión rápida, Caller ID. 00 Se aprueba H.323 v.4 que mejora la versión 3. Nuevas mejoras en confiabilidad, escalabilidad y flexibilidad. Multiplexación de audio y video en una sola conexión mejora el sincronismo. Call Intrusion, permite a un tercero interrumpir una comunicación en curso. 02 SIP se actualiza a su versión 2.0 en la RFC Página 24