Hispanopedia Wiki
Articulo de referencia

Extensiones SIP para el subsistema multimedia IP

El Protocolo de Inicio de Sesión ( SIP ) es el protocolo de señalización para telecomunicaciones móviles adoptado por el 3rd Generation Partnership Project (3GPP) [ 1 ] [ 2 ] pa...

Hispanopedia WikiContenido en espanolLectura gratuita

El Protocolo de Inicio de Sesión ( SIP ) es el protocolo de señalización para telecomunicaciones móviles adoptado por el 3rd Generation Partnership Project (3GPP) [ 1 ] [ 2 ] para sesiones multimedia con múltiples participantes en el Subsistema Multimedia IP (IMS). Por lo tanto, se considera un componente central del marco IMS.

SIP fue desarrollado por el Grupo de Trabajo de Ingeniería de Internet (IETF) como una tecnología estándar para sesiones de comunicación multimedia sobre redes de Protocolo de Internet (IP). Ubicado en la capa de aplicación del conjunto de protocolos de Internet , SIP proporciona mecanismos para iniciar, controlar y finalizar sesiones en tiempo real que incluyen voz, video y mensajes de texto.

Desde su estandarización, se han publicado varias extensiones SIP como RFC para ampliar las capacidades del protocolo, incluyendo soporte para control avanzado de llamadas, funciones de seguridad e integración con otras aplicaciones de Internet. [ 3 ] [ 4 ] [ 5 ]

El 3GPP, una colaboración entre grupos de asociaciones de telecomunicaciones cuyo objetivo es desarrollar y mantener el IMS, estableció una serie de requisitos para que SIP [ 1 ] se utilizara con éxito en el IMS. Algunos de estos requisitos podían abordarse utilizando las capacidades y extensiones existentes de SIP, mientras que, en otros casos, el 3GPP tuvo que colaborar con el IETF para estandarizar nuevas extensiones de SIP [ 6 ] que cumplieran con los nuevos requisitos. El IETF desarrolla SIP de forma genérica, de modo que el uso de extensiones no se limita al marco del IMS.

Requisitos de 3GPP para SIP

El 3GPP ha establecido varios requisitos generales para el funcionamiento del IMS. Estos incluyen un uso eficiente de la interfaz de radio minimizando el intercambio de mensajes de señalización entre el terminal móvil y la red, un tiempo mínimo de establecimiento de sesión realizando tareas antes del establecimiento de la sesión en lugar de durante el mismo, un soporte mínimo requerido en el terminal, soporte para escenarios de roaming y no roaming con gestión de movilidad del terminal (compatible con la red de acceso, no con SIP) y soporte para direccionamiento IPv6 .

Otros requisitos incluyen extensiones de protocolo, como campos de encabezado SIP para intercambiar información de usuario o servidor, y métodos SIP para admitir nuevas funcionalidades de red: requisitos para el registro, el re-registro, la cancelación del registro, las notificaciones de eventos, la mensajería instantánea o las primitivas de control de llamadas con capacidades adicionales como la transferencia de llamadas.

Otros requisitos específicos son: [ 1 ]

  • Garantizar la calidad del servicio mediante el control de políticas y tarifas, así como la negociación y asignación de recursos antes de alertar al usuario final.
  • Identificación de usuarios para fines de autenticación, autorización y contabilidad . La seguridad entre usuarios y la red, así como entre los nodos de la red, es un aspecto fundamental que debe abordarse mediante mecanismos de autenticación mutua , como claves públicas y privadas y resúmenes , además de extensiones de autorización de medios . Asimismo, debe ser posible presentar tanto al emisor como al receptor la identidad de sus contrapartes, con la posibilidad de ocultar esta información si fuera necesario. El anonimato en el establecimiento de la sesión y la privacidad también son importantes.
  • Se requiere protección de la señalización SIP con soporte para integridad y confidencialidad basado en autenticación inicial y claves criptográficas simétricas ; también se necesita recuperación de errores y verificación.
  • Liberación de sesión iniciada por la red (por ejemplo, en caso de que el terminal del usuario salga de la zona de cobertura o se quede sin crédito).
  • Mecanismos de enrutamiento de origen . El enrutamiento de mensajes SIP tiene sus propios requisitos en el IMS, ya que todos los intentos de establecimiento de sesión originados por el terminal deben transitar tanto por el P-CSCF como por el S-CSCF para que estos servidores de funciones de control de sesión de llamada (CSCF) puedan prestar sus servicios correctamente. También puede haber requisitos de ruta especiales para ciertos mensajes.
  • Interoperabilidad entre el sistema IMS y la red telefónica pública conmutada (RTPC).

Finalmente, también es necesario que otros protocolos y servicios de red como DHCP o DNS [ 7 ] se adapten para funcionar con SIP, por ejemplo para la localización de proxy de salida (P-CSCF) y la resolución de identificador uniforme de recursos (URI) de SIP a dirección IP , respectivamente.

mecanismo de negociación de prórrogas

En SIP existe un mecanismo [ 2 ] para la negociación de extensiones entre agentes de usuario (UA) o servidores, que consta de tres campos de encabezado : supported , require y unsupported , que los UA o servidores (es decir, terminales de usuario o función de control de sesión de llamada (CSCF) en IMS) pueden usar para especificar las extensiones que entienden. Cuando un cliente inicia un diálogo SIP con un servidor, indica las extensiones que requiere que se utilicen y también otras extensiones que entiende ( supported ), y el servidor enviará una respuesta con una lista de las extensiones que requiere . Si estas extensiones no están listadas en el mensaje del cliente, la respuesta del servidor será una respuesta de error. Del mismo modo, si el servidor no admite ninguna de las extensiones requeridas por el cliente, enviará una respuesta de error con una lista de sus extensiones no admitidas . Este tipo de extensiones se denominan etiquetas de opción , pero SIP también se puede extender con nuevos métodos . En ese caso, los agentes de usuario o servidores usan el encabezado Allow para indicar qué métodos admiten. Para requerir el uso de un método específico en un cuadro de diálogo determinado, deben utilizar una etiqueta de opción asociada a dicho método.

extensiones SIP

Preferencias del llamante y capacidades del agente de usuario

Estas dos extensiones permiten a los usuarios especificar sus preferencias sobre el servicio que proporciona el IMS.

Con la extensión de preferencias de llamada, [ 8 ] la persona que llama puede indicar el tipo de agente de usuario al que quiere comunicarse (por ejemplo, si es fijo o móvil, un buzón de voz o una persona, personal o para negocios, qué servicios puede proporcionar o qué métodos admite) y cómo buscarlo, con tres campos de encabezado: Accept-Contact para describir los agentes de usuario de destino deseados, Reject-Contact para indicar los agentes de usuario que se deben evitar y Request-Disposition para especificar cómo deben manejar la solicitud los servidores de la red (es decir, si se debe redirigir o no y cómo buscar al usuario: secuencialmente o en paralelo).

Al utilizar la extensión de capacidades del agente de usuario, [ 9 ] los agentes de usuario (terminales) pueden describirse a sí mismos cuando se registran para que otros puedan buscarlos según sus encabezados de extensión de preferencias de llamada. Para ello, enumeran sus capacidades en el campo de encabezado Contacto del mensaje REGISTER.

Notificación de evento

El objetivo de la notificación de eventos es obtener el estado de un recurso determinado (por ejemplo, un usuario, el servicio de correo de voz ) y recibir actualizaciones de ese estado cuando cambie.

La notificación de eventos es necesaria en el marco de IMS para informar sobre la presencia de un usuario (es decir, "en línea" o "fuera de línea") a otros que puedan estar esperando para contactarlo, o para notificar a un usuario y a su P-CSCF sobre su estado de registro , de modo que sepan si están localizables y qué identidades públicas han registrado. Además, la notificación de eventos puede utilizarse para proporcionar servicios adicionales como el correo de voz (es decir, para notificar que tienen nuevos mensajes de voz en su bandeja de entrada ).

Para este fin, la extensión de notificación de eventos específicos [ 10 ] define un marco para la notificación de eventos en SIP, con dos nuevos métodos: SUBSCRIBE y NOTIFY, nuevos campos de encabezado y códigos de respuesta y dos roles: el suscriptor y el notificador . La entidad interesada en la información de estado de un recurso (el suscriptor ) envía un mensaje SUBSCRIBE con el Identificador Uniforme de Recursos (URI) del recurso en la línea inicial de la solicitud y el tipo de evento en el encabezado Evento . Luego, la entidad encargada de mantener el seguimiento del estado del recurso (el notificador ) recibe la solicitud SUBSCRIBE y envía de vuelta un mensaje NOTIFY con un encabezado de estado de suscripción , así como la información sobre el estado del recurso en el cuerpo del mensaje. Cada vez que cambia el estado del recurso, el notificador envía un nuevo mensaje NOTIFY al suscriptor . Cada tipo de evento al que un suscriptor puede suscribirse se define en un nuevo paquete de eventos . Un paquete de eventos describe un nuevo valor para el encabezado del evento SUBSCRIBE , así como un tipo MIME para transportar la información de estado del evento en el mensaje NOTIFY.

También hay un encabezado allow-events para indicar las capacidades de notificación de eventos, y los códigos de respuesta de evento 202 accepted y 489 bad para indicar si una solicitud de suscripción ha sido aceptada preliminarmente o ha sido rechazada porque el notificador no entiende el tipo de evento solicitado.

Para un uso eficiente de los mensajes de señalización, también es posible establecer una tasa de notificación limitada (no en tiempo real) mediante un mecanismo denominado limitación de eventos . Además, existe un mecanismo de notificación de eventos condicional que permite al notificador decidir si envía o no el mensaje NOTIFY completo, dependiendo de si hay novedades que notificar desde la última suscripción.

Publicación estatal

El marco de notificación de eventos define cómo un agente de usuario puede suscribirse a eventos sobre el estado de un recurso, pero no especifica cómo se puede publicar ese estado. La extensión SIP para la publicación del estado del evento [ 11 ] se definió para permitir que los agentes de usuario publiquen el estado de un evento a la entidad ( notificador ) que es responsable de componer el estado del evento y distribuirlo a los suscriptores .

El marco de publicación de estado define un nuevo método: PUBLISH, que se utiliza para solicitar la publicación del estado del recurso especificado en la URI de la solicitud, con referencia al evento indicado en el encabezado Evento y con la información contenida en el cuerpo del mensaje.

Mensajería instantánea

La funcionalidad de envío de mensajes instantáneos para proporcionar un servicio similar al de los mensajes de texto se define en la extensión de mensajería instantánea. [ 12 ] Estos mensajes no están relacionados entre sí (es decir, no originan un diálogo SIP) y se envían a través de la red de señalización SIP, compartiendo recursos con los mensajes de control.

Esta funcionalidad es compatible con el nuevo método MESSAGE, que permite enviar un mensaje instantáneo al recurso especificado en la URI de la solicitud, con el contenido incluido en el cuerpo del mensaje. Este contenido se define mediante un tipo MIME , siendo text/plain el más común.

Para tener una sesión de mensajería instantánea con mensajes relacionados, está disponible el Protocolo de retransmisión de sesión de mensajes (MSRP) [ 13 ] .

Transferencia de llamada

La extensión del método REFER [ 14 ] define un mecanismo para solicitar a un agente de usuario que contacte con un recurso identificado por una URI en el campo de encabezado Refer-To del mensaje de solicitud. Un uso típico de este mecanismo es la transferencia de llamadas: durante una llamada, el participante que envía el mensaje REFER indica al destinatario que contacte con el agente de usuario identificado por la URI en el campo de encabezado correspondiente. El mensaje REFER también implica una suscripción a un evento sobre el resultado de la operación, de modo que el remitente sabrá si el destinatario pudo o no contactar con la tercera persona.

Sin embargo, este mecanismo no se limita a la transferencia de llamadas, ya que el campo de encabezado Refer-To puede ser cualquier tipo de URI, por ejemplo, una URI HTTP , para requerir que el destinatario visite una página web .

Fiabilidad de las respuestas provisionales

En la especificación básica de SIP, [ 15 ] solo las solicitudes y las respuestas finales (es decir, los códigos de respuesta 2XX ) se transmiten de forma fiable; es decir, el remitente las retransmite hasta que llega el mensaje de acuse de recibo (es decir, el código de respuesta correspondiente a una solicitud, o la solicitud ACK correspondiente a un código de respuesta 2XX). Este mecanismo es necesario ya que SIP puede funcionar no solo sobre protocolos de transporte fiables ( TCP ) que aseguran la entrega del mensaje, sino también sobre protocolos no fiables ( UDP ) que no ofrecen garantías de entrega, e incluso es posible que ambos tipos de protocolos estén presentes en diferentes partes de la red de transporte.

Sin embargo, en un escenario como el del marco IMS, es necesario extender esta confiabilidad a las respuestas provisionales a las solicitudes INVITE (para el establecimiento de sesión, es decir, para iniciar una llamada). La extensión de confiabilidad de respuestas provisionales [ 16 ] proporciona un mecanismo para confirmar que las respuestas provisionales, como el código de respuesta 180 Ringing , que informa al emisor que el receptor está siendo alertado, se reciben correctamente. Para ello, esta extensión define un nuevo método: PRACK, que es el mensaje de solicitud utilizado para informar al remitente de una respuesta provisional que su mensaje ha sido recibido. Este mensaje incluye un campo de encabezado RACK, que es un número de secuencia que coincide con el campo de encabezado RSeq de la respuesta provisional que se está confirmando, y también contiene el número CSeq que identifica la solicitud INVITE correspondiente. Para indicar que el agente de usuario solicita o admite respuestas provisionales confiables, se utilizará la etiqueta de opción 100rel .

Actualización de la descripción de la sesión

El objetivo de la extensión del método UPDATE [ 17 ] es permitir que los agentes de usuario proporcionen información actualizada sobre la descripción de la sesión dentro de un diálogo, antes de que se genere la respuesta final a la solicitud INVITE inicial. Esto puede utilizarse para negociar y asignar los recursos de la llamada antes de que se alerte al destinatario.

Precondiciones

En el marco IMS, se requiere que, una vez que el destinatario recibe la alerta, las probabilidades de que falle la sesión sean mínimas. Una causa importante de fallo es la imposibilidad de reservar recursos de red para la sesión, por lo que estos recursos deben asignarse antes de que suene el teléfono. Sin embargo, en IMS, para reservar recursos, la red necesita conocer la dirección IP, el puerto y los parámetros de sesión del destinatario; por lo tanto, es necesario que se haya iniciado el intercambio inicial de oferta/respuesta para establecer la sesión (solicitud INVITE). En SIP básico, este intercambio eventualmente provoca que el destinatario reciba la alerta. Para solucionar este problema, se introdujo el concepto de precondiciones [ 18 ] . En este concepto, el emisor establece un conjunto de restricciones sobre la sesión (por ejemplo, códecs y requisitos de QoS ) en la oferta, y el destinatario responde a la oferta sin establecer la sesión ni alertar al usuario. Este establecimiento se producirá solo si tanto el emisor como el destinatario aceptan que se cumplen las precondiciones.

La extensión SIP de precondiciones afecta tanto a SIP, con una nueva etiqueta de opción ( precondición ) y la definición de intercambios de oferta/respuesta, como al Protocolo de Descripción de Sesión (SDP), un formato utilizado para describir los parámetros de inicialización de medios de transmisión , que se incluyen en el cuerpo de los mensajes SIP. Los nuevos atributos SDP describen el estado actual de la reserva de recursos, el estado deseado de la reserva para proceder con el establecimiento de la sesión y el estado de confirmación , que indica cuándo se debe confirmar el estado de la reserva.

El modelo de oferta/respuesta SDP que utiliza solicitudes PRACK y UPDATE.

En el IMS, la negociación inicial de parámetros de sesión se puede realizar mediante respuestas provisionales y extensiones de actualización de la descripción de sesión , junto con SDP en el cuerpo de los mensajes. La primera oferta, descrita mediante SDP, se puede transmitir mediante la solicitud INVITE y tratará sobre los códecs compatibles con el emisor . Esta solicitud será respondida con el código de respuesta confiable provisional 183 (Progreso de sesión) , que contendrá la lista SDP de códecs compatibles tanto con el emisor como con el receptor. El PRACK correspondiente a esta respuesta provisional se utilizará para seleccionar un códec e iniciar la negociación de QoS .

La negociación de QoS se apoya en la solicitud PRACK, que inicia la reserva de recursos en la red de la parte que realiza la llamada y se responde con un código de respuesta 2XX. Una vez enviada esta respuesta, la parte llamada también ha seleccionado el códec e inicia la reserva de recursos en su lado. Posteriormente, se envían solicitudes UPDATE para informar sobre el progreso de la reserva, y se responden con códigos de respuesta 2XX. En un intercambio típico de oferta/respuesta, [ 19 ] la parte que realiza la llamada enviará una solicitud UPDATE cuando se complete su reserva; luego, la parte llamada responderá y finalmente terminará de asignar los recursos. Es entonces, cuando todos los recursos para la llamada están disponibles, cuando se alerta a la persona que realiza la llamada.

Identificación y cobro

En el marco de IMS, es fundamental gestionar las identidades de los usuarios para fines de autenticación, autorización y contabilidad. IMS está diseñado para proporcionar servicios multimedia a través de redes IP, pero también necesita un mecanismo para facturar a los usuarios por ellos. Toda esta funcionalidad se admite mediante nuevos campos de encabezado especiales.

Encabezados P

Las extensiones de encabezado privado para SIP, [ 6 ] también conocidas como encabezados P, son campos de encabezado especiales cuya aplicabilidad se limita a redes privadas con una topología y características específicas de los protocolos de capas inferiores . Fueron diseñadas específicamente para cumplir con los requisitos de 3GPP, ya que no existía una solución más general.

Estos campos de encabezado se utilizan para diversos fines, entre ellos la tarificación y la información sobre las redes por las que atraviesa una llamada:

  • Vector de carga P : Un conjunto de información de carga, como el valor de la identidad de carga IMS (ICID), la dirección del proxy SIP que crea el valor ICID y el identificador entre operadores (IOI). Puede completarse durante el establecimiento de una sesión o como una transacción independiente fuera de un diálogo.
  • P-Charging-Function-Address : Direcciones de las funciones de tarificación (entidades funcionales que reciben los registros o eventos de tarificación) en la red doméstica del usuario. También puede completarse durante el establecimiento de un diálogo o como una transacción independiente, e informa a cada proxy involucrado en una transacción.
  • P-Visited-Network-ID : Cadena de identificación de la red visitada. Se utiliza durante los registros para indicar a la red de origen del usuario qué red presta servicios a un usuario en roaming , de modo que la red de origen pueda aceptar el registro de acuerdo con sus acuerdos de roaming.
  • P-Access-Network-Info : Información sobre la tecnología de acceso (la red que proporciona la conectividad), como la tecnología de acceso radioeléctrico y la identidad de la celda . Se utiliza para informar a los servidores proxy de servicio y a la red doméstica, para que puedan optimizar los servicios o simplemente para que puedan localizar al usuario en una red inalámbrica .
  • P-Called-Party-ID : La URI indicada originalmente en la URI de solicitud de una solicitud generada por el agente de usuario que realiza la llamada. Cuando la solicitud llega al registrador (S-CSCF) del usuario llamado, el registrador reescribe la URI de solicitud en la primera línea de la solicitud con la dirección de contacto registrada (es decir, la dirección IP) del usuario llamado y almacena la URI de solicitud reemplazada en este campo de encabezado. En el IMS, un usuario puede ser identificado por varias URI SIP (direcciones de registro), por ejemplo, una URI SIP para el trabajo y otra URI SIP para uso personal, y cuando el registrador reemplaza la URI de solicitud con la dirección de contacto efectiva, la URI de solicitud original debe almacenarse para que la parte llamada sepa a qué dirección de registro se envió la invitación.
  • P-Associated-URI : URI adicionales asociadas a un usuario que se está registrando. Se incluye en la respuesta 200 OK a una solicitud REGISTER para informar al usuario qué otras URI ha asociado el proveedor de servicios con una URI de dirección de registro (AOR).

Se han definido más encabezados privados para el acceso de los usuarios a la base de datos:

  • P-User-Database : [ 20 ] La dirección de la base de datos de usuarios , es decir, el Servidor de Suscriptores Principales (HSS) , que contiene el perfil del usuario que generó una solicitud particular. Aunque el HSS es una base de datos maestra única, puede distribuirse en diferentes nodos por razones de confiabilidad y escalabilidad . En este caso, se necesita una función de localización de suscriptores (SLF) para encontrar el HSS que gestiona un usuario en particular. Cuando una solicitud de usuario llega al I-CSCF en el borde del dominio administrativo , esta entidad consulta la SLF para obtener el HSS correspondiente y luego, para evitar que el S-CSCF tenga que consultar la SLF nuevamente, envía la dirección del HSS al S-CSCF en el encabezado P-User-Database . Entonces, el S-CSCF podrá consultar directamente el HSS para obtener información sobre el usuario (por ejemplo, información de autenticación durante un registro). [ 21 ]
  • P-Profile-Key : [ 22 ] La clave que se utilizará para consultar la base de datos de usuarios (HSS) para obtener un perfil que corresponda al URI SIP de destino de una solicitud SIP específica. Se transmite entre proxies para realizar consultas a la base de datos más rápidas: el primer proxy encuentra la clave y los demás consultan la base de datos utilizando directamente la clave. Esto es útil cuando se utilizan identidades de servicio comodín, es decir, identidades de servicio públicas que coinciden con una expresión regular , ya que la primera consulta tiene que resolver la expresión regular para encontrar la clave.

Identidad afirmada

Las extensiones privadas para la identidad afirmada dentro de redes de confianza [ 23 ] están diseñadas para permitir que una red de servidores SIP de confianza afirme la identidad de los usuarios autenticados , únicamente dentro de un dominio administrativo con políticas previamente acordadas para la generación, el transporte y el uso de esta información de identificación. Estas extensiones también permiten a los usuarios solicitar privacidad para que sus identidades no se difundan fuera del dominio de confianza . Para indicarlo, deben insertar el ID del token de privacidad en el campo de encabezado Privacy. [ 24 ]

La funcionalidad principal se basa en la cabecera de extensión P-Asserted-Identity . Cuando un servidor proxy recibe una solicitud de una entidad no confiable y autentica al usuario (es decir, verifica su identidad), inserta esta cabecera con la identidad autenticada y reenvía la solicitud como de costumbre. De esta forma, otros servidores proxy que reciben esta solicitud SIP dentro del Dominio de Confianza (es decir, la red de entidades confiables con políticas de seguridad previamente acordadas) pueden confiar en la información de identidad contenida en la cabecera P-Asserted-Identity sin necesidad de volver a autenticar al usuario.

También se define el encabezado de extensión P-Preferred-Identity , de modo que un usuario con varias identidades públicas pueda indicar al proxy qué identidad pública debe incluirse en el encabezado P-Asserted-Identity cuando se autentique el usuario.

Finalmente, cuando se solicita privacidad, los proxies deben retener la información de identidad declarada fuera del dominio de confianza eliminando los encabezados P-Asserted-Identity antes de reenviar las solicitudes de los usuarios a identidades no confiables (fuera del dominio de confianza ).

Existen encabezados de extensión análogos para manejar la identificación de servicios de usuarios, [ 25 ] en lugar de los usuarios mismos. En este caso, se utilizan nombres de recursos uniformes para identificar un servicio (por ejemplo, una llamada de voz, una sesión de mensajería instantánea, una transmisión de IPTV ) [ 26 ] .

Mecanismos de seguridad

La seguridad de acceso en el IMS consiste en autenticar y autorizar primero al usuario, lo cual realiza el S-CSCF, y luego establecer conexiones seguras entre el P-CSCF y el usuario. Existen varios mecanismos para lograr esto, tales como:

Posteriormente se introdujo la extensión del acuerdo de mecanismos de seguridad para SIP [ 28 ] para proporcionar un mecanismo seguro para negociar los algoritmos y parámetros de seguridad que utilizarán el P-CSCF y el terminal. Esta extensión utiliza tres nuevos campos de encabezado para respaldar el proceso de negociación:

  • En primer lugar, la terminal añade a la solicitud REGISTER un campo de encabezado security-client que contiene los mecanismos, la autenticación y los algoritmos de cifrado que admite.
  • A continuación, el P-CSCF añade un campo de encabezado security-server a la respuesta que contiene la misma información que la del cliente, pero con referencia al P-CSCF. En caso de que exista más de un mecanismo, se les asocia un valor de prioridad.
  • Finalmente, el agente de usuario envía una nueva solicitud REGISTER a través de la conexión segura recién creada con los parámetros negociados, incluido un campo de encabezado security-verify que contiene el mismo contenido que el campo de encabezado security-server recibido previamente . Este procedimiento protege el mecanismo de negociación de ataques Man-in-the-middle : si un atacante eliminara los mecanismos de seguridad más fuertes del campo de encabezado Security-Server para forzar al terminal a elegir algoritmos de seguridad más débiles, entonces los campos de encabezado Security-Verify y Security-Server no coincidirían. El contenido del campo de encabezado Security-Verify no puede alterarse ya que se envía a través de la nueva asociación segura establecida, siempre que esta asociación no pueda ser vulnerada por el atacante en tiempo real (es decir, antes de que el P-CSCF descubra el ataque Man-in-the-middle en curso).

Autorización de medios

La necesidad en el IMS de reservar recursos para proporcionar calidad de servicio (QoS) conlleva otro problema de seguridad: el control de admisión y la protección contra ataques de denegación de servicio . Para obtener recursos de transmisión, el agente de usuario debe presentar un token de autorización a la red (es decir, el punto de aplicación de políticas, o PEP). Este token se obtendrá de su P-CSCF, que puede estar a cargo del control de políticas de QoS o tener una interfaz con la entidad de control de políticas en la red (es decir, la función de decisión de políticas, o PDF) que originalmente proporciona el token de autorización.

Las extensiones privadas para la autorización de medios [ 29 ] vinculan la señalización de sesión con los mecanismos de QoS aplicados a los medios en la red, definiendo los mecanismos para obtener tokens de autorización y el campo de encabezado P-Media-Authorization para transportar estos tokens desde el P-CSCF al agente de usuario. Esta extensión solo es aplicable dentro de dominios administrativos con relaciones de confianza . Fue diseñada particularmente para redes SIP especializadas como IMS, y no para Internet en general .

Mecanismos de enrutamiento de origen

El enrutamiento de origen es el mecanismo que permite al remitente de un mensaje especificar parcial o totalmente la ruta que seguirá. En SIP, el campo de encabezado de ruta , completado por el remitente, admite esta funcionalidad al enumerar un conjunto de proxies que el mensaje visitará. En el contexto de IMS, existen ciertas entidades de red (es decir, ciertos CSCF ) que deben ser atravesadas por las solicitudes de o hacia un usuario, por lo que deben listarse en el campo de encabezado de ruta . Para permitir que el remitente descubra dichas entidades y complete el campo de encabezado de ruta , existen principalmente dos campos de encabezado de extensión: ruta y ruta de servicio .

Camino

El campo de encabezado de extensión para registrar contactos no adyacentes [ 30 ] proporciona un campo de encabezado Path que acumula y transmite las URI SIP de los proxies que se encuentran entre un agente de usuario y su registrador a medida que el mensaje REGISTER los atraviesa. De esta manera, el registrador puede descubrir y registrar la secuencia de proxies que debe atravesar para regresar al agente de usuario.

En la red IMS, cada agente de usuario es atendido por su P-CSCF, que se descubre mediante el Protocolo de Configuración Dinámica de Host (DCP) o un mecanismo equivalente cuando el usuario ingresa a la red IMS. Todas las solicitudes y respuestas desde o hacia el agente de usuario deben pasar por este proxy. Cuando el usuario se registra en el registrador de origen (S-CSCF), el P-CSCF agrega su URI SIP en un campo de encabezado Path en el mensaje REGISTER, de modo que el S-CSCF recibe y almacena esta información asociada con la información de contacto del usuario. De esta manera, el S-CSCF reenviará cada solicitud dirigida a ese usuario a través del P-CSCF correspondiente, incluyendo su URI en el campo de encabezado Route .

Ruta de servicio

La extensión para el descubrimiento de rutas de servicio durante el registro [ 31 ] consiste en un campo de encabezado Service-Route que el registrador utiliza en una respuesta 2XX a una solicitud REGISTER para informar al usuario que se registra de la entidad que debe reenviar cada solicitud originada por él o ella.

En el IMS, el registrador es el S-CSCF de la red de origen y se requiere que todas las solicitudes sean gestionadas por esta entidad, por lo que incluirá su URI SIP en el campo de encabezado service-route . El usuario incluirá entonces esta URI SIP en el campo de encabezado Route de todas sus solicitudes, para que se reenvíen a través del S-CSCF de origen.

URI de agente de usuario enrutables globalmente

En el IMS, un usuario puede tener varios terminales (por ejemplo, un teléfono móvil o un ordenador ) o instancias de aplicaciones (por ejemplo, videotelefonía , mensajería instantánea o correo de voz ) identificados con la misma identidad pública (es decir, URI SIP). Por lo tanto, se necesita un mecanismo para enrutar las solicitudes al dispositivo o aplicación deseado. Esto es lo que es una URI de agente de usuario enrutable globalmente (GRU) [ 32 ] : una URI que identifica una instancia específica de agente de usuario (por ejemplo, un terminal o una instancia de aplicación) y lo hace globalmente (es decir, es válido enrutar mensajes a ese agente de usuario desde cualquier otro agente de usuario en Internet).

Estas URI se construyen añadiendo el parámetro `gr` a una URI SIP, ya sea a la URI SIP pública con un valor que identifica la instancia del agente de usuario, o a una URI creada especialmente que no revela la relación entre la GRUU y la identidad del usuario, por motivos de privacidad. Generalmente se obtienen durante el proceso de registro: el agente de usuario que se registra envía un Nombre Uniforme de Recursos (URN) que identifica de forma única esa instancia SIP, y el registrador (es decir, S-CSCF) construye la GRUU, la asocia a la identidad registrada y a la instancia SIP, y la envía de vuelta al agente de usuario en la respuesta. Cuando el S-CSCF recibe una solicitud para esa GRUU, podrá enrutar la solicitud a la instancia SIP registrada.

Compresión de señales

El uso eficiente de los recursos de red, que pueden incluir una interfaz de radio u otro acceso de bajo ancho de banda, es esencial en el IMS para brindar al usuario una experiencia aceptable en términos de latencia . Para lograr este objetivo, los mensajes SIP se pueden comprimir utilizando el mecanismo conocido como SigComp [ 33 ] (compresión de señalización).

Los algoritmos de compresión realizan esta operación sustituyendo las palabras repetidas en el mensaje por su posición en un diccionario donde todas estas palabras aparecen solo una vez. En un primer enfoque, el compresor puede crear este diccionario para cada mensaje y enviarlo al descompresor junto con el mensaje. Sin embargo, dado que muchas palabras se repiten en diferentes mensajes, las operaciones extendidas para SigComp [ 34 ] definen una forma de utilizar un diccionario compartido entre mensajes subsiguientes. Además, para acelerar el proceso de creación de un diccionario a lo largo de los mensajes subsiguientes y proporcionar altas tasas de compresión desde el primer mensaje INVITE, SIP proporciona un diccionario SIP/SDP estático [ 35 ] que ya está construido con términos comunes de SIP y SDP.

Existe un mecanismo [ 36 ] para indicar que se desea comprimir un mensaje SIP. Este mecanismo define el parámetro `comp=sigcomp` para las URI SIP, que indica que la entidad SIP identificada por la URI admite SigComp y está dispuesta a recibir mensajes comprimidos. Cuando se utiliza en las URI de solicitud, indica que la solicitud debe comprimirse, mientras que en los campos de encabezado `Via` indica que la respuesta subsiguiente debe comprimirse.

Indirección de contenido

Para obtener mensajes SIP aún más cortos y hacer un uso muy eficiente de los recursos, la extensión de indirección de contenido [ 37 ] permite reemplazar una parte del cuerpo MIME del mensaje con una referencia externa, normalmente una URI HTTP . De esta forma, el destinatario del mensaje puede decidir si seguir o no la referencia para obtener el recurso, en función del ancho de banda disponible.

Recorrido NAT

La traducción de direcciones de red (NAT) impide que un terminal sea accesible desde fuera de su red privada , ya que utiliza una dirección privada que se asigna a una pública cuando los paquetes originados por el terminal atraviesan la NAT. Por lo tanto, se necesitan mecanismos de superación de la NAT tanto para el plano de señalización como para el plano de medios .

El RFC 6314 del Grupo de Trabajo de Ingeniería de Internet [ 38 ] resume y unifica diferentes métodos para lograr esto, como el enrutamiento de respuesta simétrica y las conexiones iniciadas por el cliente para la señalización SIP, y el uso de STUN , TURN e ICE , que combina los dos anteriores, para flujos de medios.

Compatibilidad con el protocolo de Internet versión 6

El RFC 6157 del Grupo de Trabajo de Ingeniería de Internet [ 39 ] describe los mecanismos necesarios para garantizar que SIP funcione correctamente entre ambas versiones del Protocolo de Internet durante la transición a IPv6 . Si bien los mensajes de señalización SIP pueden transmitirse a través de redes heterogéneas IPv4 / IPv6 siempre que los servidores proxy y las entradas DNS estén configurados correctamente para reenviar mensajes a través de ambas redes según estas recomendaciones, los agentes de usuario deberán implementar extensiones para poder intercambiar directamente flujos multimedia . Estas extensiones están relacionadas con el intercambio inicial de oferta/respuesta del Protocolo de Descripción de Sesión , que se utilizará para recopilar las direcciones IPv4 e IPv6 de ambos extremos para que puedan establecer una comunicación directa.

Interacción con otras tecnologías

Además de todas las extensiones de SIP explicadas que permiten que el IMS funcione correctamente, también es necesario que el marco IMS interactúe e intercambie servicios con las infraestructuras de red existentes, principalmente la red telefónica pública conmutada (PSTN).

Existen varios estándares que abordan estos requisitos, como los dos siguientes para la interconexión de servicios entre la PSTN e Internet (es decir, la red IMS):

Y también para que las pasarelas PSTN-SIP admitan llamadas con un extremo en cada red:

  • Protocolo de inicio de sesión para teléfonos (SIP-T) , [ 42 ] que describe las prácticas y usos de estas pasarelas.
  • Mapeo de ISDN User Part (ISUP) a Session Initiation Protocol (SIP) [ 43 ] que permite traducir mensajes de señalización SIP a mensajes ISUP del Sistema de Señalización No. 7 (SS7) que se utiliza en la PSTN, y viceversa.

Además, la extensión del método SIP INFO está diseñada para transportar información del usuario entre terminales sin afectar el diálogo de señalización y puede utilizarse para transportar la señalización multifrecuencia de doble tono para proporcionar la función de teclado telefónico a los usuarios. [ 44 ]

Véase también

Referencias

  1. 1 2 3 Garcia-Martin, M. (mayo de 2005). Requisitos de la versión 5 del Proyecto de Asociación de Tercera Generación (3GPP) sobre el Protocolo de Iniciación de Sesión (SIP) . IETF . doi : 10.17487/RFC4083 . RFC 4083. Recuperado el 29 de noviembre de 2014 .
  2. 1 2 Camarillo, Gonzalo; García-Martín, Miguel A. (4 de noviembre de 2008). El subsistema multimedia IP (IMS) 3G: fusionando Internet y los mundos celulares (3 ed.). John Wiley e hijos. págs. 55 a 336. ISBN   978-0-470-51662-1Consultado el 15 de noviembre de 2014 .{{cite book}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  3. ↑ Poikselkä, Miikka; Mayer, Georg; Khartabil, Hisham; Niemi, Aki (10 de marzo de 2006). El IMS: conceptos y servicios multimedia IP (2.ª ed.). John Wiley & Sons. págs. 320–331 . ISBN   978-0-470-01906-1Consultado el 15 de noviembre de 2014 .{{cite book}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  4. ↑ Red Hat. "8.6. EXTENSIONES SIP E IMS" . redhat.com . Consultado el 15 de noviembre de 2014 .
  5. ↑ Formación en Sistemas y Redes. "SIP en IMS" . snt.co.uk. Archivado del original el 28 de marzo de 2015. Consultado el 15 de noviembre de 2014 .
  6. 1 2 Jesske, R.; Drage, K.; Holmberg, C. (julio de 2014). Extensiones de encabezado privado (P-Header) al protocolo de inicio de sesión (SIP) para el 3GPP . IETF . doi : 10.17487/RFC7315 . RFC 7315. Recuperado el 15 de noviembre de 2014 .
  7. ↑ Rosenberg, J.; Schulzrinne, H. (junio de 2002). Protocolo de inicio de sesión (SIP): localización de servidores SIP . IETF . doi : 10.17487/RFC3263 . RFC 3263. Consultado el 1 de diciembre de 2014 .
  8. ↑ Rosenberg, J.; Schulzrinne, H.; Kyzivat, P. (agosto de 2004). Preferencias del emisor para el protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC3841 . RFC 3841. Consultado el 1 de diciembre de 2014 .
  9. ↑ Rosenberg, J.; Schulzrinne, H.; Kyzivat, P. (agosto de 2004). Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) . IETF . doi : 10.17487/RFC3840 . RFC 3840. Consultado el 1 de diciembre de 2014 .
  10. ↑ Roach, A. (junio de 2002). Notificación de eventos específicos del Protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC3265 . RFC 3265. Recuperado el 1 de diciembre de 2014 .
  11. ↑ Niemi, A. (octubre de 2004). Extensión del Protocolo de Iniciación de Sesión (SIP) para la publicación del estado del evento . IETF . doi : 10.17487/RFC3903 . RFC 3903. Recuperado el 2 de diciembre de 2014 .
  12. ↑ Campbell, B.; Ed., Rosenberg; J., Schulzrinne; H., Huitema; C., y; D., Gurle (diciembre de 2002). Extensión del Protocolo de Iniciación de Sesión (SIP) para mensajería instantánea . IETF . doi : 10.17487/RFC3428 . RFC 3428. Recuperado el 2 de diciembre de 2014 .
  13. ↑ Campbell, B.; Ed., Mahy; R., Ed.; Jennings, C. (septiembre de 2007). El Protocolo de Retransmisión de Sesión de Mensajes (MSRP) . IETF . doi : 10.17487/RFC4975 . RFC 4975. Recuperado el 2 de diciembre de 2014 .
  14. ↑ Sparks, R. (abril de 2003). El método Refer del Protocolo de Iniciación de Sesión (SIP) . IETF . doi : 10.17487/RFC3515 . RFC 3515. Recuperado el 2 de diciembre de 2014 .
  15. 1 2 Rosenberg, J.; et al. (junio de 2002). SIP: Protocolo de inicio de sesión . IETF . doi : 10.17487/RFC3261 . RFC 3261. Recuperado el 15 de noviembre de 2014 . 
  16. ↑ Rosenberg, J.; Schulzrinne, H. (junio de 2002). Fiabilidad de las respuestas provisionales en el protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC3262 . RFC 3262. Consultado el 2 de diciembre de 2014 .
  17. ↑ Rosenberg, J. (octubre de 2002). El método UPDATE del Protocolo de Iniciación de Sesión (SIP) . IETF . doi : 10.17487/RFC3311 . RFC 3311. Recuperado el 2 de diciembre de 2014 .
  18. ↑ Camarillo, G.; Ed., Marshall; W., Ed.; Rosenberg, J. (octubre de 2002). Integración de la gestión de recursos y el protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC3312 . RFC 3312. Recuperado el 3 de diciembre de 2014 .
  19. ↑ EvenHelix. "Llamada IMS a IMS" (PDF) . eventhelix.com/ . Archivado del original (PDF) el 22 de enero de 2015. Consultado el 3 de diciembre de 2014 .
  20. ↑ Camarillo, G.; Blanco, G. (abril de 2006). El encabezado privado de la base de datos de usuario P del protocolo de inicio de sesión (SIP) (encabezado P) . IETF . doi : 10.17487/RFC4457 . RFC 4457. Consultado el 5 de diciembre de 2014 .
  21. ↑ EvenHelix. "Registro IMS" (PDF) . eventhelix.com/ . Consultado el 5 de diciembre de 2014 .
  22. ↑ Camarillo, G.; Blanco, G. (agosto de 2007). El encabezado privado de clave de perfil P (encabezado P) del Protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC5002 . RFC 5002. Consultado el 5 de diciembre de 2014 .
  23. ↑ Jennings, C.; Peterson, J.; Watson, M. (noviembre de 2002). Extensiones privadas al Protocolo de inicio de sesión (SIP) para la identidad declarada dentro de redes de confianza . IETF . doi : 10.17487/RFC3325 . RFC 3325. Recuperado el 3 de diciembre de 2014 .
  24. ↑ Peterson, J. (noviembre de 2002). Un mecanismo de privacidad para el protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC3323 . RFC 3323. Recuperado el 3 de diciembre de 2014 .
  25. ↑ Drage, K. (noviembre de 2010). Una extensión del Protocolo de Iniciación de Sesión (SIP) para la identificación de servicios . IETF . doi : 10.17487/RFC6050 . RFC 6050. Recuperado el 5 de diciembre de 2014 .
  26. ↑ Rosenberg, J. (junio de 2010). Identificación de servicios de comunicaciones en el protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC5897 . RFC 5897. Recuperado el 5 de diciembre de 2014 .
  27. ↑ Niemi, A.; Arkko, J.; Torvinen, V. (septiembre de 2002). Autenticación de resumen del protocolo de transferencia de hipertexto (HTTP) mediante autenticación y acuerdo de clave (AKA) . IETF . doi : 10.17487/RFC3310 . RFC 3310. Consultado el 5 de diciembre de 2014 .
  28. ↑ Arkko, J.; Torvinen, V.; Camarillo, G.; Niemi, A.; Haukka, T. (enero de 2003). Acuerdo sobre el mecanismo de seguridad para el protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC3329 . RFC 3329. Consultado el 5 de diciembre de 2014 .
  29. ↑ Marshall, W. (enero de 2003). Extensiones del Protocolo de Iniciación de Sesión Privada (SIP) para la Autorización de Medios . IETF . doi : 10.17487/RFC3313 . RFC 3313. Recuperado el 5 de diciembre de 2014 .
  30. ↑ Willis, D.; Hoeneisen, B. (diciembre de 2002). Campo de encabezado de extensión del Protocolo de inicio de sesión (SIP) para registrar contactos no adyacentes . IETF . doi : 10.17487/RFC3327 . RFC 3327. Recuperado el 5 de diciembre de 2014 .
  31. ↑ Willis, D.; Hoeneisen, B. (octubre de 2003). Campo de encabezado de extensión del Protocolo de inicio de sesión (SIP) para el descubrimiento de rutas de servicio durante el registro . IETF . doi : 10.17487/RFC3608 . RFC 3608. Recuperado el 5 de diciembre de 2014 .
  32. ↑ Rosenberg, J. (octubre de 2009). Obtención y uso de URI de agente de usuario enrutables globalmente (GRUU) en el protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC5627 . RFC 5627. Recuperado el 5 de diciembre de 2014 .
  33. ↑ Price, R.; Bormann, C.; Christoffersson, J.; Hannu, H.; Liu, Z.; Rosenberg, J. (enero de 2003). Compresión de señales (SigComp) . IETF . doi : 10.17487/RFC3320 . RFC 3320. Consultado el 4 de diciembre de 2014 .
  34. ↑ Hannu, H.; Christoffersson, J.; Forsgren, S.; Leung, K.-C.; Liu, Z.; Price, R. (enero de 2003). Compresión de señales (SigComp) - Operaciones extendidas . IETF . doi : 10.17487/RFC3321 . RFC 3321. Recuperado el 4 de diciembre de 2014 .
  35. ↑ Garcia-Martin, M.; Bormann, C.; Ott, J.; Price, R.; Roach, A. (febrero de 2003). El diccionario estático del Protocolo de Iniciación de Sesión (SIP) y del Protocolo de Descripción de Sesión (SDP) para la compresión de señales (SigComp) . IETF . doi : 10.17487/RFC3485 . RFC 3485. Consultado el 4 de diciembre de 2014 .
  36. ↑ Camarillo, G. (febrero de 2003). Compresión del Protocolo de Iniciación de Sesión (SIP) . IETF . doi : 10.17487/RFC3486 . RFC 3486. Consultado el 4 de diciembre de 2014 .
  37. ↑ Burger, E. (mayo de 2006). Un mecanismo para la indirección de contenido en mensajes del protocolo de inicio de sesión (SIP) . IETF . doi : 10.17487/RFC4483 . RFC 4483. Recuperado el 4 de diciembre de 2014 .
  38. ↑ Boulton, C.; Rosenberg, J.; Camarillo, G.; Audet, F. (julio de 2011). Prácticas de NAT Traversal para SIP cliente-servidor . IETF . doi : 10.17487/RFC6314 . RFC 6314. Recuperado el 5 de diciembre de 2014 .
  39. ↑ Camarillo, G.; El, Malki; K., y; V., Gurbani (abril de 2011). Transición IPv6 en el Protocolo de Inicio de Sesión (SIP) . IETF . doi : 10.17487/RFC6157 . RFC 6157 . Consultado el 5 de diciembre de 2014 .
  40. ↑ Petrack, S.; Conroy, L. (junio de 2000). El protocolo de servicio PINT: extensiones de SIP y SDP para el acceso IP a servicios de llamadas telefónicas . IETF . doi : 10.17487/RFC2848 . RFC 2848. Recuperado el 5 de diciembre de 2014 .
  41. ↑ Gurbani, V.; Ed., Brusilovsky; A., Faynberg; I., Gato; J., Lu; H., y; M., Unmehopa (octubre de 2004). El protocolo SPIRITS (Servicios en PSTN que solicitan servicios de Internet) . IETF . doi : 10.17487/RFC3910 . RFC 3910. Recuperado el 5 de diciembre de 2014 .
  42. ↑ Vemuri, A.; Peterson, J. (septiembre de 2002). Protocolo de inicio de sesión para teléfonos (SIP-T): contexto y arquitecturas . IETF . doi : 10.17487/RFC3372 . RFC 3372. Recuperado el 5 de diciembre de 2014 .
  43. ↑ Camarillo, G.; Roach, A.; Peterson, J.; Ong, L. (diciembre de 2002). Mapeo de la parte de usuario de la Red Digital de Servicios Integrados (RDSI) (ISUP) al Protocolo de Iniciación de Sesión (SIP) . IETF . doi : 10.17487/RFC3398 . RFC 3398. Consultado el 5 de diciembre de 2014 .
  44. ↑ Holmberg, C.; Burger, E.; Kaplan, H. (enero de 2011). Método y marco de paquete INFO del Protocolo de Iniciación de Sesión (SIP) . IETF . doi : 10.17487/RFC6086 . RFC 6086. Recuperado el 5 de diciembre de 2014 .

Libros

  • Poikselkä, Miikka; Mayer, Georg; Khartabil, Hisham; Niemi, Aki (10 de marzo de 2006). El IMS: conceptos y servicios multimedia IP (2  ed.). John Wiley e hijos. ISBN 978-0-470-01906-1Consultado el 15 de noviembre de 2014 .{{cite book}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  • Camarillo, Gonzalo; García-Martín, Miguel A. (4 de noviembre de 2008). El subsistema multimedia IP 3G (IMS): la fusión de Internet y el mundo celular (3.ª  ed.). John Wiley & Sons. ISBN 978-0-470-51662-1Consultado el 15 de noviembre de 2014 .{{cite book}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  • Página del Proyecto de Asociación de Tercera Generación sobre el Subsistema Multimedia IP
  • Flujos de llamadas del subsistema multimedia IP