Resumen del protocolo SIP

Resumén del protocolo SIP

Giovanni Andrés Nopal Pascual – giovanni@voip.unam.mx

SIP (Session Initiation Protocol) fue desarrollado por la IETF (RFC3261 1 ); por tanto su
desarrollo esta orientado a la integración con aplicaciones y servicios de Internet. Tiene
mayor flexibilidad para incorporar nuevas funciones y su implementación es más
simple.

SIP es un protocolo de la capa de Aplicación del Stack de Protocolos TCP/IP. Cómo se

puede observar, esta relacionado estrechamente con el Protocolo SDP y coexiste junto
con otros protocolos del mismo nivel y funciones, como lo son: Megaco y H323.

El protocolo SIP es un protocolo de señalización para VoIP. Sus principales funciones

son:
• Establecer, modificar y finalizar sesiones entre dos o mas participantes.
• Registro y localización de participantes. Movilidad.
• Gestión del conjunto de participantes y de los componentes del sistema.
• Descripción de características de las sesiones y negociación de capacidades de
los participantes.
Algunas de sus características son:
• Basado en Texto
• Sintaxis similar a HTTP o SMTP.
• Uso de URIs (con esquemas sip, sips y tel).
• Métodos básicos: INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS.
• Los mensajes se agrupan en transacciones y llamadas.
• Generalmente, el cuerpo de los mensajes contiene descripciones de sesiones
multimedia (SDP).
• Códigos de respuesta similares a los de HTTP. (Ejemplo: 200 – OK)
• Localización basada en DNS.
• Cabeceras como método de ampliación.

1
http://www.ietf.org/rfc/rfc3261.txt

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

El protocolo SIP no es un protocolo de propósito general. Como ya se mencionó

anteriormente, su objetivo es ayudar a establecer y finalizar la comunicación. SIP se
ayuda de otros protocolos para lograr una llamada telefónica, una sesión de video
conferencia o de Mensajería Instantánea, etc. Los protocolos que apoyan comúnmente a
SIP son: SDP y RTP (RTCP). RTP es usado para transportar los datos multimedia en
tiempo real mientras que SDP se emplea para describir y codificar las características y
capacidades de los participantes en la sesión.

SIP es un protocolo de señalización orientado a conexiones end-to-end. Esto significa

que toda la lógica se encuentra almacenada en los dispositivos finales (salvo el ruteo de
mensajes SIP). La ventaja es la escalabilidad que se obtiene pues los servers no son
saturados con mensajes SIP. La desventaja de esto es que los encabezados son mucho
mayores.

La forma de identificar a una entidad SIP es similar a la empleada para definir una
cuenta de correo electrónico. A esta forma se le denomina URI (Uniform Resource
Identifier). El URI de SIP es de la forma sip:usuario@dominio, por ejemplo:
sip:pumas@voip.unam.mx.

Elementos de Red del protocolo SIP

La configuración mas simple para establecer una sesión SIP es utilizando sólo dos
agentes de usuario (UA) conectados uno a otro. Los elementos básicos de un sistema
SIP son los UA (Agentes de usuario) y los servidores de Red. Estos últimos pueden ser
de diferentes tipos, Proxies, Registrars y Redirect Servers. A menudo estos elementos
son sólo entidades lógicas y comúnmente se sitúan en el mismo lugar.

UA – El agente de usuario se conforma por el UAS (User Agent Server) y UAC (User
Agent Client). Son las entidades finales que usan SIP para contactarse uno con otro y
definir las características de la sesión. Se encuentran, por ejemplo, en un softphone,
teléfonos celulares (SIP), Hard-IPphones, etc. El UAC es la parte del UA que se encarga
de generar peticiones y recibir respuestas a esas peticiones, mientras que el UAS tiene
como tarea el recibir peticiones y generar respuestas a las mismas.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

SIP Proxy Server – Un SIP Proxy Server es aquel que realiza una petición a nombre de
un UA hacia otro Proxy u otro UA. La tarea más importante de un Proxy Server es
encaminar las invitaciones de sesión para llevarlas hasta el UA llamado. Una invitación
de sesión atravesará comúnmente un conjunto de Proxies hasta encontrar a aquel que
conozca la localización exacta del UA buscado. Existen dos tipos de SIP Proxy Servers:
stateful y stateless.

• Stateful Proxy – Este tipo de servidor crea un estado de petición y lo mantiene

hasta que la transacción finalice.
• Stateless Proxy – Sólo reenvía los mensajes SIP.

Los proxies stateful pueden desempeñar tareas mucho mas complejas; por ejemplo
hacer retransmisiones como lo sería el caso del servicio “sígueme” ó reemitir un mismo
mensaje SIP hacia dos proxies diferentes con el fin de localizar a un usuario en
específico.

Registrar Server – Cuando un usuario se conecta a la Red (ejecuta su Softphone en su

PC o enciende su IPphone), este envía un mensaje Register hacía su Proxy con el fin de
que éste conozca su ubicación. La labor de un registrar Proxy consiste en atender estos
mensajes, autenticar y validar la cuenta contra una base de datos interna o externa y
“registrar” la localización actual del usuario. Un Registrar Server es comúnmente sólo
una entidad lógica y la mayoría de las veces se localiza junto con el Proxy SIP Server.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

Redirect Server – Entidad que escucha peticiones y regresa (no reenvía mensajes)
respuestas que contienen la localización actual de un usuario en particular. Este servidor
escucha las peticiones y realiza la búsqueda en la Base de Datos creada por el Registrar
Server. Este tipo de Server contesta con mensajes SIP de clase 3XX.

El usuario o Proxy que realizó la petición original extrae la información de la respuesta

y envía otra petición directamente al resultado de la búsqueda.

Los mensajes SIP

SIP utiliza una serie de mensajes para “señalizar” las sesiones. El mensaje se conforma
de una línea inicial (Start – Line ó Request – Line), el encabezado del mensaje (Mesage
Header) y el cuerpo del mensaje (Message Body).

La línea inicial contiene la versión del protocolo SIP, el método y direcciones

involucradas en la sesión para las peticiones, mientras que el estado de la sesión para el
caso de las respuestas.

El encabezado contiene información relacionada con la llamada en forma de texto; por

ejemplo: el origen y destino de la petición, el identificador de la llamada, etc.

El cuerpo del mensaje o carga útil (payload) lleva información (comúnmente SDP ó
ISUP en caso de una troncal hacia la PSTN.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

Existen dos tipos básicos de mensajes SIP, peticiones y respuestas. Las peticiones se
emplean para iniciar alguna acción o para información. Las respuestas se usan para
confirmar que una petición fue recibida y procesada, y contiene el estado del
procesamiento.

En el ejemplo mostrado se indica que este mensaje es una petición y corresponde a una
invitación para iniciar una sesión (INVITE). Delante de la palabra INVITE se encuentra
la SIP URI del siguiente brinco para el mensaje, en esta caso 132.248.214.121.

El campo VIA se usa para registrar (grabar) la ruta que ha recorrido la petición o
mensaje. En el caso de un mensaje INVITE, éste contendrá sólo un campo VIA, el cual
registrará el origen de la petición. Los campos FROM y TO son transparentes por si
solos.

El campo CALL-ID identifica mensajes que pertenecen a la misma llamada. Así es

como el analizador de Red que utilizamos pudo reconocer todos los mensajes
correspondientes a esta llamada. Cseq se utiliza para mantener el orden de las
peticiones.

El campo CONTACT contiene la IP y puerto en dónde el emisor de la petición espera

respuesta a su mensaje. Existen otros campos que por el momento no describiremos a
detalle.

Finalmente el cuerpo del mensaje INVITE contiene una descripción de los medios
aceptados por el emisor codificados en SDP.

Otros mensajes de peticiones SIP que debemos considerar son las siguientes:

• ACK – Se usa para pedir la confirmación de que el extremo llamado recibió el

INVITE. (3 Way Handshaking)
• BYE – Empleados para finalizar una sesión.
• CANCEL – Para cancelar una sesión que no se ha completado del todo.
• REGISTER – Para que el Proxy conozca la localización actual del emisor del
mensaje.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

Estas peticiones no contienen por lo general un cuerpo de mensaje porque no lo

requieren.

Cuando un Proxy recibe una petición (menos ACK), este debe dar una respuesta. Un
ejemplo se muestra a continuación:

Los mensajes de respuesta son similares a los de peticiones, excepto por la primera
línea, la cual contiene la versión del protocolo y el código de la respuesta (ej. 200 = Ok)
y una frase que explica, en términos mas humanos, la razón de la respuesta. Los códigos
de respuesta son enteros entre 100 y 699. El primer dígito indica la clase.

Existen 6 clases de respuestas:

• 1XX Provisionales (Petición fue recibida pero se desconoce aún el resultado del
procesamiento). El emisor detiene el envío de retransmisiones después de recibir
una respuesta de este tipo. Un ejemplo es el código 180 = ringing ó 100 = trying.
• 2XX Son respuesta finales positivas. La petición fue recibida y procesada
exitosamente. Por ejemplo 200 = Ok significa que el extremo llamado aceptó la
invitación a la sesión.
• 3XX Son usados para redireccionar llamadas. Dan información acerca de la
nueva localización de un usuario ó sobre un Proxy alterno que pueda resolver
satisfactoriamente alguna petición. El emisor del mensaje de petición debe
reenviar su petición a otro lado para que su petición sea atendida.
• 4XX son respuestas finales negativas. Falla del lado del emisor, mala sintaxis
del mensaje, etc.
• 5XX Falla del lado del servidor. Aparentemente la petición es válida pero el
Proxy es incapaz de procesarla. El emisor debe reintentar después.
• 6XX la petición no puede ser atendida en ningún Proxy.

Transacciones SIP

Una transacción SIP es una secuencia de mensajes entre dos elementos de Red. Una
transacción corresponde a una petición y todas las respuestas a esa petición. Esto quiere
decir que una transacción incluirá cero o mas respuestas provisionales y una o mas
respuestas finales (en el caso de un mensaje INVITE, recuerde que este puede ser
dividido por un Proxy, por lo tanto tendrá múltiples respuesta finales. Las entidades SIP
que almacenan el estado de las transacciones son denominadas Stateful. Lo hacen por
medio del registro de cada transacción a través de un identificador contenido en el

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

encabezado VIA 2 . A continuación se muestra un ejemplo los mensajes que pertenecen a

una misma transacción dentro de una conversación SIP.

Diálogos SIP

Un diálogo SIP es una conversación peer-to-peer entre dos UA (Agentes de Usuario).

Los diálogos son identificados usando los campos Call-ID (Id. De llamada), From (De)
y To (Para). Los mensajes con estos campos iguales pertenecerán al mismo diálogo. El
campo Cseq, del que hablamos anteriormente, es utilizado para ordenar los mensajes en
un diálogo. De hecho el Cseq representa el número de transacción. De forma breve
podemos decir que un diálogo es una secuencia de transacciones.

2
En la versión anterior del protocolo SIP (RFC-2543) éste identificador era calculado en base a los
encabezados, pero resultaba bastante complicado y era fuente de problemas. A partir del RFC-3261 SIPv2
el identificador se incluye directamente en el mensaje.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

En la figura abajo mostrada se muestra el proceso conocido como routing y como los
diálogos SIP favorecen este proceso.

Escenarios SIP clásicos

Registro

Para que un usuario pueda ser llamado por otro, este debe registrarse primero ante el
Proxy. El registro consiste en el envío de un mensaje REGISTER seguido de su
correspondiente respuesta 200 Ok. En caso de que el usuario no haya dado credenciales
válidas recibirá por respuesta un mensaje 407, con lo cual tendrá que reenviar el
mensaje de Registro hasta que tenga éxito.

Invitación a una sesión

Una invitación inicia con el mensaje INVITE dirigido comúnmente al Proxy. Éste
responde con un TRYING (100) para detener las retransmisiones y reenvía las
peticiones hacia el usuario llamado. Todas las respuestas provisionales generadas por el
usuario llamado son regresadas al usuario origen. Por ejemplo RINGING (180) que es
un mensaje que se envía cuando el usuario llamado es contactado y comienza a timbrar.
Una respuesta 200 (Ok) es generada en cuanto el usuario llamado descuelga el auricular.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

Terminación de sesión

Una sesión es finalizada cuando uno de los usuarios envía el mensaje BYE al otro
extremo. El otro usuario confirma el final de la conversación enviando por respuesta un
mensaje 200 (Ok). La transacción para finalizar la sesión se realizará de un extremo a
otro sin pasar por el Proxy a menos que en el mismo se haya establecido un proceso de
Registro de ruta.

Registro de ruta

Existen situaciones en las que el Proxy requiere estar presente en la ruta de todos los
mensajes con fines de control del tráfico, o por ejemplo, cuando existe un NAT. El
Proxy o los Proxies logran esto por medio de la inserción del campo RECORD ROUTE
en los encabezados de los mensajes SIP.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

Protocolo de Descripción de Sesión SDP

SDP, significa “Session Description Protocol” (Protocolo de Descripción de Sesión), es

un formato para describir parámetros de inicialización de flujo de medios. Ha sido
publicado por la IETF como RFC 4566.

SDP esta diseñado para transportar información de la sesión hacia los destinatarios, así
como información de los medios referentes a la misma. Éste permite además asociar
más de un flujo de medios a una misma sesión; por ejemplo en una misma sesión puede
existir un flujo para audio y uno mas para video o transferencia de documentos.

SDP es exclusivamente para propósitos de descripción y negociación de los parámetros

de sesión. No transporta el medio en sí. Fue pensado para trabajar en conjunto con otros
protocolos como SIP, Megaco ó HTTP. El transporte de información acerca de los
flujos de medios permite a los destinatarios participar en la sesión si ellos soportan
dichos flujos. Además, SDP permite la negociación de los parámetros del flujo tales
como la tasa de muestreo de la señal, el tamaño de los paquetes, etc.

La información que SDP incluye en sus paquetes de forma general es la siguiente:

- La versión del protocolo

- El nombre de la sesión y su propósito
- El tiempo que la sesión esta activa
- Los medios relacionados con la sesión (Video, Audio y formatos para
Video o audio, etc).
- Las direcciones IP y los puertos pertinentes para el establecimiento de la
sesión.
- Los atributos específicos a la sesión o a los medio dentro de ella
ƒ a= <atributo>, a=<atributo>:<valor>

Los mensajes SDP están codificados como texto plano (ISO 10646 UTF-8). Los
nombres de campo y atributos usan US-ASCII pero lo demás es ISO 10646. Se eligió el
formato texto plano para aumentar la “portabilidad” hacia sistemas basados en Web.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

Analicemos el paquete SDP que se incluye en el mensaje SIP INVITE de la figura que
se muestra arriba:

1. Versión del Protocolo (v=0),

2. Propietario/Creador de la sesión e Identificador de la misma conformado por
<usuario> <Id. Sesión> <Versión> <Tipo de Red> <Tipo Dirección> <Dir. IP>.
3. Nombre de la Sesión
4. Información de la Sesión (i = info), URI (u = www.dominio.net), email (e =
email@dominio.net), teléfono (p = número telefónico).
5. Información de la conexión (c = <Tipo de Red> <Tipo Dirección> <Dir. IP>).
6. Ancho de Banda propuesto (b = BW en kbps).
7. Tiempo de sesión Activa (t = <inicio> <paro>).
8. Llave de cifrado (k = <método> k = <método>:<llave de encriptado>
9. Definición de Medios y atributos
- m = <medio> <puerto> <transporte> <Lista de formatos de medios>
ƒ Medio – “audio”, “video”, “application”, “data” y “control”.
ƒ Puerto – Identifica el puerto de transporte
ƒ Transporte – Depende del campo “c” (RTP/AVP)
ƒ Lista de formatos de Medios de acuerdo con el Perfil de
Audio/Video para RTP 3 , en donde existen por ejemplo el perfil 0
correspondiente a PCM Ley µ y el perfil 8 a PCM ley a. La
asignación de perfiles puede ser estática (como en el caso de
PCM monoaural muestreado a 8 kHz (perfil 0) o dinámica en
Cuyp caso se requiere información adicional por medio de los
atributos de medios (a= etc).
10. Atributos sugeridos
- Categoría (a=cat:<categoría>)
- Palabras clave (a=keywds:<keywords>)
- Heramienta (a=tool:<nombre y versión de la herramienta>
- Tiempo de paquete (a=ptime:<packet time>
- Sólo recibe (a=recvonly)
- Envía y recibe (a=senrecv)

3
http://www.iana.org/assignments/rtp-parameters

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

- Sólo envía (a=sendonly)

- Orientación de pizarra (a=orient:<orientación>)
- Tipo de conferencia (a=type:<tipo de conferencia>
- Juego de caracteres (a=charset:<juego de caracteres>)
- Idioma (a=sdplang:<etiqueta_idioma>)
- Tasa de frames (a=framerate:<framerarte>)
- Calidad (a=quality:<quality>)
- Formato Específico (a=fmtp:<formato> <àrámetros específicos de
formato>

v=0 
o= ‐ 8 2 IN IP4 132.248.120.88 
s=CounterPath X‐Lite 3.0 
c=IN IP4 132.248.120.88 
t=0 0 
m=audio 9076 RTP/AVP 107 119 100 106 0 105 9 
a=alt:1 3 : umQbFZnU vQmtoQmN 132.248.120.88 9076 
a=alt:2 2 : rWQPKjhjkbZZNvx0 192.168.0.1 9076 
a=alt:3 1 : TGSOKOpCM9pDMrs8 192.168.144.1 9076 
a=fmtp:101 0‐15 
a=rtpmap:107 BV32/16000 
a=rtpmap:119 BV32‐FEC/16000 
a=rtpmap:10  0 SPEEX/16000 
a=rtpmap:106 SPEEX‐FEC/16000 
a=rtpmap:105 SPEEX‐FEC/8000 
a=rtpmap:98 iLBC/8000 
a=rtpmap:101 telephone‐event/8000 
a=sendrecv 

Protocolos RTP/RTCP

Son los protocolos usados para transportar flujos de medios en Telefonía IP. Ambos
fueron definidos en el RFC 1889. El primero para transportar flujos en tiempo real (Real
Time Media Streaming) y el segundo para monitorear la calidad de servicio, así como
para transportar información acerca de los participantes en la sesión.

Sus funciones son:

• Identificación del tipo de carga útil transportada (Codecs de Audio/Video)

• Verificar la entrega de los paquetes en orden (Marca de tiempo) y si resulta
necesario reordenar los bloques fuera de orden.
• Transportación de información de sincronización para la codificación y
decodificación.
• Monitoreo de la entrega de información.

RTP utiliza UDP para el transporte de la información y aprovechar la suma de

verificación del mismo (checksum) para verificar integridad de los datos. Es importante
resaltar que RTP no posee ningún método para garantizar la QoS ni la entrega ordenada
de paquetes. Por otro lado RTCP utiliza el mismo protocolo que RTP para enviar
paquetes de control hacia todos los participantes de una sesión.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

Los servicios que provee RTCP son los siguientes:

Dar seguimiento a la calidad en la distribución de los datos, así como mantener el

control de los codecs activos.
Transportar un identificador constante para la fuente RTP (CNAME)
Anunciar el número de participantes por sesión con el fin de ajustar la tasa de
transmisión de datos.

UNAM - DGSCA Grupo de Trabajo VoIP

 Resumen del protocolo SIP

Anexos

Algunas de las respuestas SIP más comunes

1xx = respuestas informativas • 415 Tipo de medio no soportado
• 100 Tratando (Trying) • 416 Esquema URI no soportado
• 180 Teléfono sonando (Ringing) • 420 Mala extensión: Mala extensión de protocolo
• 181 Llamada esta siendo redireccionada SIP utilizada, no entendida por el servidor
• 182 En cola (Queued) • 421 Extensión requerida
• 183 Progreso de sesión • 423 Intervalo muy corto
• 480 Temporalmente no disponible
2xx = respuestas de éxito • 481 Llamada/Transacción no existe
• 200 OK • 482 Lazo detectado
• 202 aceptada: Utilizada por referidos • 483 Muchos saltos
• 484 Dirección incompleta
• 485 Ambiguo
3xx = respuestas de redirección
• 486 Ocupado acá
• 300 Múltiples opciones
• 487 Solicitud terminada
• 301 Movido permanentemente
• 488 No aceptable acá
• 302 Movido temporalmente
• 491 Solicitud pendiente
• 305 Utiliza Proxy
• 493 No descifrable: No pudo desencriptar la
• 380 Servicio alternativo
parte del cuerpo S/MIME
4xx = errores de solicitud 5xx = errores de servidor
• 400 Solicitud errónea
• 500 Error interno del servidor
• 401 No autorizado: Utilizado solamente por
• 501 No Implementado: La solicitud / método SIP
registradores. Proxys deben utilizar autorización
no está implementado acá
proxy 407
• 502 Pasarela errónea
• 402 Pago requerido (Reservado para uso futuro)
• 503 Servicio no disponible
• 403 Prohibido
• 504 Expiración de servidor
• 404 No Encontrado: Usuario no encontrado
• 505 Versión no soportada: El servidor no soporta
• 405 Método no permitido
esta versión del protocolo SIP
• 406 No Aceptable
• 513 Mensaje demasiado largo
• 407 Autenticación Proxy Requerida
• 408 Expiración de solicitud: No pudo encontrar
al usuario a tiempo 6xx = errores globales
• 410 Ido: El usuario existió una vez, pero ya no • 600 Ocupado en todas partes
esta disponible acá. • 603 Declinación
• 413 Solicitud de entidad muy larga • 604 No existe en ninguna parte
• 414 Solicitud URI muy larga • 606 No Aceptable

Referencias

Trans-European Research and Education Networking Asociation – TERENA

“IP Telephony cookbook”
Marzo 2004

Black, Uyless
“Internet Telephony” – Call Processing Protocols
Prentice Hall Series in Advanced Communications technologies
E. U. – 2001

UNAM - DGSCA Grupo de Trabajo VoIP