PROTOCOLO DE SIP

1 – La definición del protocolo SIP

SIP, que significa Protocolo de Iniciación de Sesión, viene del mundo de la informática a diferencia de los otros. El protocolo SIP fue iniciado originalmente por el grupo MMusic (Multiparty Multimedia Session Control) y ahora es administrado por el IETF (Internet Engeneering Task Force). El protocolo SIP está representado principalmente por el RFC 3261 «SIP: Protocolo de Iniciación de Sesión», que se complementa con los siguientes RFC:

  • RFC 3265, «Protocolo de Iniciación de Sesión (SIP) – Notificación de Evento Específico».
  • RFC 3853, «S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)».
  • RFC 4320, «Acciones para abordar cuestiones identificadas con la transacción no INVITADA del Protocolo de Iniciación de Sesiones (SIP)».
  • RFC 4916, «Identidad conectada en el Protocolo de Iniciación de Sesión (SIP)».
  • RFC 5393, «Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies».

SIP es un protocolo de señalización diseñado para establecer y controlar sesiones multimedia. Para ello, SIP asocia una sesión con medios de audio (llamada telefónica), video (videoconferencia) y datos (gestión de presencia). SIP es un protocolo que funciona bajo TCP/IP. Está basado más precisamente en UDP y funciona por defecto en el puerto 5060.

El protocolo SIP es hoy en día el protocolo más utilizado en el mundo de la Voz sobre IP y la Telefonía sobre IP. Tiene algunas características principales que lo hacen tan atractivo:

Sistema de dirección URL
La dirección puede ser un número de teléfono, una dirección IP o una dirección de correo electrónico. Los mensajes son muy similares a los utilizados por Internet HTTP1.1. Gracias al CPL (Call Processing Language) que utiliza XML, es muy fácil añadir servicios de redirección inteligente.
Multimedia
El protocolo SIP puede tener múltiples sesiones de medios durante una llamada. Como el protocolo SIP es independiente de la transmisión de datos, se puede utilizar cualquier tipo de datos y protocolos para este intercambio.
Simplicidad
El SIP es un protocolo «ligero» que requiere pocos recursos físicos y poco tiempo de desarrollo. Así se convierte en el objetivo favorito de los fabricantes de equipos e integradores de soluciones.

2 – Terminologías

En un sistema SIP hay dos tipos de componentes, agentes de usuario (UAC, UAS) y aplicaciones de servidor (PS, RS, LS, RG):

2.1 – AE – Terminal SIP

El término AE significa «Equipo de Agente» y representa el conjunto de UAC «Cliente de Agente de Usuario» y UAS «Servidor de Agente de Usuario». El AE define más pragmáticamente los terminales clientes IP (teléfono, hardphone, softphone, caja ATA, etc.) que inician o reciben las solicitudes.

2.2 – PS – Servidor Proxy

El término PS significa «Servidor Proxy» o también llamado «Relevo Proxy» y representa al equipo que actúa como cliente de la UAC y como servidor de la UAS. El Proxy es responsable de enrutar una sesión SIP. Cuando recibe una solicitud SIP, la reenvía a otro servidor proxy en la ruta, o directamente al RA correspondiente, si está directamente conectado a él.

2.3 – RS – Servidor de redireccionamiento

El término RS significa «Servidor de Redireccionamiento» y se utiliza para redirigir las llamadas a la ubicación actual de un usuario. Simplemente convierte la dirección contenida en la solicitud de SIP en 0 o más direcciones de nuevos destinatarios dependiendo de si fue reconocida o no.

2.4 – LS – Servidor de localización

El término LS significa «Servidor de Localización» y proporciona la posición actual de los usuarios cuya comunicación pasa a través del RS y PS al que está conectado. Esta función es proporcionada por el servicio de localización que consiste en una base de datos o un archivo de texto que contiene la lista de las unidades administrativas, sus derechos y su contraseña.

2.5 – RG – Servidor de grabación

RG significa «Registrar» y es un servidor que acepta solicitudes de registro. Más concretamente, permite a las unidades de usuario registrarse y proporciona información sobre la ubicación de un usuario.

3 – Cabeceras de mensajes

Los mensajes SIP se codifican utilizando una sintaxis de mensajes similar al protocolo HTTP1.1. Aquí está el esquema que representa la sintaxis básica de un mensaje SIP:

Un message SIP est donc composée de 2 rubriques principales qui sont la méthode et l’entête SIP. La ligne vide représente la possibilité d’utiliser d’autres protocoles multimédia tel que SDP « Session Description Protocol » définit par la RFC 2327.

3.1 – La méthode – Les requêtes

Les échanges client-serveur se font à l’aide de requêtes dont voici le détail de chacun des messages :

INVITE (Définit par la RFC 3261)
Le message invite indique que l’application ou l’utilisateur est invité à participer à une session. Le Corps du message décrit cette session (média supportés par l’appelant entre autres). En cas de réponse favorable à l’invitation, l’invité doit spécifier également les médias qu’il supporte dans son Corps du message. Un serveur est tenu de répondre à une telle invitation, identifiée par son CALL-ID, par une réponse OK (code 200). Si un UAS reçoit une requête INVITE avec un numéro de séquence Cseq supérieur à celui de la dernière requête INVITE de même CALL-ID reçue, celui-ci doit mettre à jour cette dernière.
ACK (Définit par la RFC 3261)
Le message ack confirme que le client a reçu une réponse définitive à une requête INVITE. Les réponses de code 2xx sont acquittées par les UAC et les autres types de réponses définitives par les premiers PS ou UAC les ayant reçues. La requête ACK possède, dans son Corps de message, une description définitive de la session que doit utiliser l’appelé. Si le Corps du message est vide (car il est optionnel), l’appelé utilise le descripteur de session de la requête INVITE. Après avoir envoyé une réponse de code 3xx, 4xx, 5xx ou 6xx, un PS doit déterminer si la requête ACK lui est destinée ou si elle est destinée à un autre PS. Cette détermination se fait en examinant le paramètre tag de l’URL TO. Le ACK lui est destiné si :
le tag de l’URL TO de la requête ACK est égal au tag de l’URL TO de la réponse
l’URL FROM, le CALL-ID et le Cseq de la requête ACK sont égaux à ceux de la réponse.
OPTIONS (Définit par la RFC 3261)
Le message option. Un PS en mesure de contacter l’UAS appelé, doit répondre à une requête OPTIONS en précisant ses capacités à contacter l’UAS. Si l’UAS ne supporte pas cette méthode, il renvoie une réponse Busy (code 600) au PS.
BYE (Définit par la RFC 3261)
Le message bye est utilisée par l’UAS de l’appelé pour signaler au PS local qu’il ne souhaite plus participer à la session. Si la requête INVITE contient une URL CONTACT, l’appelé envoie la requête BYE directement à cette adresse plutôt qu’à l’URL FROM. Cette méthode doit être supportée par les PS et devrait être supportée par les RS et UAS.
CANCEL (Définit par la RFC 3261)
Le message CANCEL est envoyée par un UAC ou un PS pour annuler une requête non validée par une réponse finale d’état. Par exemple, un PS peut envoyer une requête CANCEL aux destinataires n’ayant pas retourné une réponse finale après avoir reçu une réponse 2xx ou 6xx du PS. Par contre, un PS qui reçoit une requête d’erreur la retransmet à tous les destinataires qui y sont reliés. Les CALL-ID, Cseq, URL TO de la requête CANCEL sont les mêmes que ceux de la requête l’ayant générée. Pour distinguer une réponse à une requête CANCEL et une réponse à la requête originale, l’entête général est de type Cseq dans le format du message de la requête CANCEL. Quand un RS ou un UAS a reçu une requête CANCEL, il renvoie à l’émetteur une réponse OK(code 200) si la transaction existe bien et une réponse Transaction Does Not Exist (code 481) sinon.
REGISTER (Définit par la RFC 3261)
Le message register est utilisée par le client pour enregistrer l’adresse listée dans l’URL TO par le serveur auquel il est relié. Les requêtes sont traitées par le client dans l’ordre où elles arrivent et celui-ci devra éviter d’envoyer une nouvelle requête REGISTER tant qu’il n’aura pas traité la précédente. Le client doit définir une adresse d’enregistrement du type Utilisateur@Domaine . Cette méthode assure un service de localisation.
INFO (Définit par la RFC 2976)
Information de session en cours.
MESSAGE (Définit par la RFC 3428)
Permettre l’envoi de messages instantanés.
NOTIFY (Définit par la RFC 3265)
Envoyer des notifications d’événements.
PRACK (Définit par la RFC 3262)
Implémenter le mécanisme spécial de sécurisation des réponses provisoires.
REFER (Définit par la RFC 3515)
Permettre la redirection d’appels.
SUSCRIBE (Définit par la RFC 3265)
Demander une notification d’événements.
UPDATE (Définit par la RFC 3311)

3.2 – El método – Respuestas

La respuesta a un mensaje se caracteriza por un código y una razón, llamados código de estado y razón. Un código de estado es un entero codificado de 3 bits que indica un resultado al recibir una solicitud. Este resultado se especifica mediante una frase, basada en texto (UTF-8), que explica el motivo de la denegación o aceptación de la solicitud. El código de estado está destinado a que el PLC gestione el establecimiento de sesiones SIP y las razones de los programadores. Hay 6 clases de respuestas y por lo tanto códigos de estado, representados por el primer bit. Los códigos de respuesta son coherentes con los códigos de respuesta HTTP/1.1. No todos los códigos de respuesta HTTP/1.1 son apropiados, y sólo se dan aquí los que son apropiados. SIP define una nueva clase: El 6xx.

Aquí está la lista de las diferentes clases:

1xx Provisional
Las respuestas provisionales, también conocidas como respuestas informativas, indican que el servidor contactado está realizando ciertas acciones y no tiene todavía una respuesta definitiva. Un servidor envía una respuesta 1xx si espera que la respuesta final tarde más de 200 ms. Tenga en cuenta que la transmisión de las respuestas 1xx no es fiable. Nunca obliga al cliente a enviar un ACK. Las respuestas provisionales (1xx) pueden contener un cuerpo de mensaje, incluida una descripción de la sesión.
2xx Éxito
La solicitud fue exitosa.
3xx Reorientación
Las respuestas de 3xx proporcionan información sobre la nueva ubicación del usuario, o sobre servicios alternativos que podrían satisfacer la llamada.
4xx Fallo de la demanda
Las respuestas 4xx son respuestas de falla específicas de un servidor en particular. El cliente NO debe volver a intentar la misma solicitud sin modificaciones (por ejemplo, añadiendo la autorización correspondiente). Sin embargo, la misma solicitud en un servidor diferente podría tener éxito.

Fallo del servidor 5xx
Las respuestas 5xx son respuestas de fallo que indican que el propio servidor ha cometido un error.
6xx Ajedrez
Las respuestas 6xx indican que un servidor tiene cierta información sobre un usuario en particular, no sólo la instancia particular especificada en la solicitud URI.
Aquí están las respuestas más utilizadas:

SIP 100 – Juicio
Esta respuesta indica que la solicitud ha sido recibida por el servidor de salto siguiente y que se está realizando alguna acción no especificada en el marco de esta llamada (por ejemplo, se está consultando una base de datos). Esta respuesta, como todas las demás respuestas provisionales, detiene las retransmisiones de un INVITADO por una UAC. La respuesta 100 (en curso) se diferencia de otras respuestas provisionales en que nunca se transmite en sentido ascendente por un apoderado completo.
SIP 180 – Timbre en progreso
El agente del usuario que recibe el INVITE está tratando de alertar al usuario. Esta respuesta puede utilizarse para inicializar el tono de retorno de la llamada local.
SIP 181 – La llamada está siendo transmitida.
Un servidor puede utilizar este código de estado para indicar que la llamada se está desviando a un conjunto diferente de destinos.
SIP 183 – Progreso de la sesión
La respuesta 183 (Progreso de la sesión) se utiliza para llevar información sobre el progreso de la llamada que no está clasificada de otra manera. La frase causal, el campo de encabezamiento o el cuerpo del mensaje pueden utilizarse para transmitir más información sobre el progreso de la llamada.

SIP 200 – OK
La solicitud fue exitosa. La información que se devuelve con la respuesta depende del método utilizado en la solicitud.
SIP 202 – Aceptado
SIP 400 – Aplicación incorrecta
La solicitud no pudo ser entendida debido a una sintaxis mal formada. La frase causal debería identificar el problema de sintaxis con más detalle, por ejemplo, «Falta el campo de encabezamiento de la identificación de llamadas».
SIP 401 – No autorizado
La solicitud requiere la autenticación del usuario. Esta respuesta es generada por los SAU y los registradores, mientras que el 407 (Agent Authentication Required) es utilizado por los servidores proxy.
SIP 404 – No encontrado
El servidor tiene cierta información que el usuario no existe dentro del dominio especificado en la solicitud-URI. Este informe también se devuelve si el dominio de la solicitud-URI no coincide con ninguno de los dominios procesados por el destinatario de la solicitud.
SIP 500 – Error interno del servidor
El servidor se encontró con una condición inesperada que le impidió satisfacer la solicitud. El cliente puede mostrar la condición de error específica y puede volver a intentarlo después de varios segundos.
Si la condición es temporal, el servidor puede indicar cuándo el cliente puede reintentar la solicitud utilizando el campo de cabecera Retry-After.
SIP 503 – Servicio no disponible
El servidor no puede procesar la solicitud temporalmente debido a una sobrecarga temporal o al mantenimiento del servidor. El servidor puede indicar cuándo el cliente debe reintentar la solicitud en un campo de encabezamiento de Reintento-Después. Si no se da un Retry-After, el cliente debe actuar como si hubiera recibido una respuesta de 500 (Error interno del servidor).
Un cliente (proxy o UAC) que reciba un 503 (Servicio no disponible) debe intentar reenviar la solicitud a un servidor de reemplazo. No debe transmitir ninguna otra solicitud a ese servidor durante el tiempo especificado en el campo de encabezamiento Reintentar-después, si está presente.
Los servidores pueden rechazar la conexión o abandonar la solicitud en lugar de responder con el 503 (Servicio no disponible).
La lista completa de códigos de respuesta SIP se encuentra en el apéndice.

3.3 – El encabezado SIP

Hay algunos de los campos de encabezamiento que siempre están presentes en las consultas y respuestas, y forman el encabezamiento general:

Llame a
Este campo de encabezamiento contiene un identificador global único para una llamada.
Cseq
Es un identificador usado para la reconciliación.
De
Identifica a la persona que llama. Debe presentarse en todas las solicitudes y respuestas.
A
Este campo debe estar presente en todas las consultas e indica su destino. Simplemente se copia en las respuestas.
A través de
El campo Via se utiliza para registrar la ruta de una consulta, de modo que los servidores SIP intermedios puedan enrutar las respuestas exactamente en la dirección opuesta.
Cifrado
Este campo de encabezamiento especifica que el cuerpo del mensaje y posiblemente algunos encabezamientos han sido encriptados.
Tipo de contenido
Este campo de encabezamiento describe el tipo de medios contenidos en el cuerpo del mensaje.
Longitud del contenido
Este es el número de bytes en el cuerpo del mensaje.

4 – Cómo funciona el SIP

4.1 – Registro de un DU

El siguiente diagrama ilustra el registro de un teléfono SIP a su Registrador :

Los datagramas del EI se encuentran clásicamente hacia el RG que representa las solicitudes y de derecha a izquierda que representa las respuestas.

He aquí un registro de cabecera-sip echange sip ae (195.7.101.157) con su Registrador (195.7.101.1).

4.2 – Llamar a través de un proxy SIP/RTP

El siguiente diagrama ilustra un intercambio entre un teléfono SIP y su Proxy :

Este esquema toma el caso en que es el Proxy el que termina la sesión informando a la UE (Datagrama número 7). Por supuesto, es posible que sea al revés y que por lo tanto sea la UE la que decida interrumpir la sesión. En este caso, la dirección de los datagramas 7 y 8 se invertirá.

He aquí un encabezado de intercambio de sorbos llamado ae (195.7.101.157) de su Proxy (195.7.101.1).

4.3 – Llamada a través de SIP Proxy

El siguiente diagrama ilustra un intercambio entre dos teléfonos SIP a través de un Proxy :

Este diagrama muestra el funcionamiento directo de SIP entre cada AE y el Proxy. Tengan en cuenta que por defecto, RTP es de igual a igual.

Aquí hay un intercambio de sorbos de cabeza llamado ae proxy. AE A (195.7.101.157), AE B (192.168.101.139) y PS Z (195.7.101.1).

5 – Apéndice – Conjunto de códigos de respuesta

Aquí está el conjunto de códigos de respuesta listados por clase:

1xx Provisional
Las respuestas provisionales, también conocidas como respuestas informativas, indican que el servidor contactado está realizando ciertas acciones y no tiene todavía una respuesta definitiva. Un servidor envía una respuesta 1xx si espera que la respuesta final tarde más de 200 ms. Tenga en cuenta que la transmisión de las respuestas 1xx no es fiable. Nunca obliga al cliente a enviar un ACK. Las respuestas provisionales (1xx) pueden contener un cuerpo de mensaje, incluida una descripción de la sesión.

2xx Éxito

La solicitud fue exitosa.

3xx Reorientación

Las respuestas de 3xx proporcionan información sobre la nueva ubicación del usuario, o sobre servicios alternativos que podrían satisfacer la llamada.

4xx Fallo de la demanda

Las respuestas 4xx son respuestas de falla específicas de un servidor en particular. El cliente NO debe volver a intentar la misma solicitud sin modificaciones (por ejemplo, añadiendo la autorización correspondiente). Sin embargo, la misma solicitud en un servidor diferente podría tener éxito.

Fallo del servidor 5xx

Las respuestas 5xx son respuestas de fallo que indican que el propio servidor ha cometido un error.

6xx Fallas totales

Las respuestas 6xx indican que un servidor tiene cierta información sobre un usuario en particular, no sólo la instancia particular especificada en la solicitud URI.

Categorías Red

Deja un comentario

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Más info

aceptar