Mensaje SIP INVITE: estructura y encabezados

Toda llamada SIP comienza con un INVITE. Es la solicitud que un agente de usuario emisor envía para iniciar una sesión, y también es el mensaje que los ingenieros pasan más tiempo leyendo cuando algo falla. Un INVITE transporta las identidades del origen y del destino, la ruta de enrutamiento que la llamada ha recorrido hasta el momento, los códecs y parámetros de transporte que el emisor ofrece, y una larga lista de campos opcionales que influyen en todo, desde la presentación del identificador de llamadas hasta la atestación STIR/SHAKEN.

Este artículo es una referencia estructural del INVITE en sí. Recorre las tres secciones del mensaje, cada encabezado obligatorio que un INVITE debe incluir, el cuerpo SDP y los encabezados opcionales que aparecen con mayor frecuencia en trazas de producción. Para una visión más amplia de cómo funciona SIP como protocolo, consulte Fundamentos de señalización SIP.

Las tres secciones de un INVITE

RFC 3261 define un mensaje SIP como tres partes separadas por secuencias de retorno de carro/salto de línea: una línea de inicio, un conjunto de campos de encabezado y un cuerpo opcional. La línea de inicio de un INVITE es la request line. Los encabezados transportan información de enrutamiento, identidad y capacidades. El cuerpo, si está presente, contiene la oferta SDP que describe los medios que el emisor desea negociar.

La línea en blanco entre el último encabezado y el cuerpo es estructural. Es la forma en que un parser determina que los encabezados han terminado. Un CRLF faltante en este punto es una de las razones más comunes por las que un INVITE malformado es rechazado por una pila SIP estricta antes de que llegue siquiera a la lógica de enrutamiento.

La request line

La request line es una línea única con la forma METHOD Request-URI SIP-Version. Para un INVITE siempre comienza con la palabra literal INVITE, seguida del Request-URI y luego SIP/2.0.

El método indica a la pila receptora qué acción realizar. INVITE significa “establecer una sesión”. Otros métodos que comparten la mayor parte de la misma estructura de encabezados incluyen ACK, BYE, CANCEL, OPTIONS, REGISTER, REFER, NOTIFY, SUBSCRIBE, UPDATE, INFO, MESSAGE y PRACK. INVITE es el método SIP más común que crea un diálogo. Otros métodos como SUBSCRIBE también pueden establecer diálogos dependiendo de la extensión en uso.

El Request-URI indica hacia dónde se envía la solicitud en ese momento. No es necesariamente el destino original. A medida que el INVITE atraviesa proxies y SBC, el Request-URI puede reescribirse para que el siguiente salto sepa hacia dónde reenviar. El encabezado To representa la identidad de destino lógica de la llamada y normalmente se preserva durante el tránsito, incluso cuando el Request-URI se reescribe con fines de enrutamiento. Confundir el Request-URI con el encabezado To es uno de los errores más comunes al leer una traza; el Request-URI responde “¿hacia dónde va esto ahora mismo?”, mientras que el encabezado To responde “¿para quién estaba destinado originalmente?”.

La versión SIP ha sido SIP/2.0 desde que RFC 3261 se publicó en 2002. No existe SIP/3.0 en producción.

Los encabezados obligatorios

RFC 3261 requiere seis encabezados en toda solicitud SIP: Via, Max-Forwards, To, From, Call-ID y CSeq. Las solicitudes INVITE casi siempre incluyen Contact, porque proporciona el destino para solicitudes posteriores dentro del diálogo, como BYE y re-INVITE. Cuando el mensaje incluye un cuerpo, Content-Type y Content-Length también se vuelven obligatorios.

Via

El encabezado Via registra la ruta de red que la solicitud ha recorrido. Cada salto que reenvía un INVITE agrega un nuevo Via en la parte superior. Las respuestas siguen la cadena Via en orden inverso para regresar hacia el emisor. El parámetro branch dentro de cada Via identifica de manera única esa transacción en ese salto. RFC 3261 establece que los valores branch deben comenzar con la cookie mágica z9hG4bK.

Ejemplo: Via: SIP/2.0/UDP 198.51.100.10:5060;branch=z9hG4bK74bf9

Max-Forwards

Un contador de saltos que previene bucles de enrutamiento. Se establece en 70 por defecto, se decrementa en cada salto y se rechaza con 483 Too Many Hops cuando llega a cero.

To

El destino lógico de la llamada, expresado como URI. No se modifica en tránsito. El UAS que responde agrega un To-tag en la respuesta 200 OK, y ese tag vincula el diálogo del lado del destinatario.

From

La identidad declarada del emisor. Siempre incluye un tag establecido por el UA emisor. El URI del From es lo que el emisor declara ser, que no es lo mismo que lo que un proveedor upstream ha autenticado (eso es P-Asserted-Identity).

Call-ID

Un identificador globalmente único para todo el diálogo. Cada solicitud y respuesta dentro del diálogo lleva el mismo Call-ID.

CSeq

Command Sequence: un número seguido de un nombre de método (por ejemplo, CSeq: 314159 INVITE). Se incrementa por cada nueva solicitud dentro de un diálogo; se reutiliza para retransmisiones.

Contact

Destino de enrutamiento directo para solicitudes dentro del diálogo como BYE y re-INVITE, normalmente utilizado junto con cualquier conjunto de Route establecido por Record-Route. Casi siempre contiene la IP y el puerto reales del terminal, razón por la cual la ocultación de topología en un SBC casi siempre implica reescribir Contact.

Content-Type y Content-Length

Cuando el INVITE incluye un cuerpo, ambos son obligatorios. Content-Type es casi siempre application/sdp; Content-Length es el tamaño del cuerpo en bytes.

Un INVITE completo en la práctica

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 198.51.100.10:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
To: "Bob" <sip:bob@example.com>
From: "Alice" <sip:alice@atlanta.com>;tag=1928301774
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@198.51.100.10:5060>
P-Asserted-Identity: <sip:+14155551001@carrier.net>
Identity: eyJhbGciOiJFUzI1NiI...JSON-WEB-SIGNATURE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 156

v=0
o=alice 2890844526 2890844526 IN IP4 198.51.100.10
s=SIP Call
c=IN IP4 198.51.100.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000

La request line está en la primera fila, los encabezados obligatorios y opcionales le siguen, la línea en blanco marca el final del bloque de encabezados y la oferta SDP ocupa el cuerpo. Los valores son ilustrativos; los INVITE del mundo real varían en el orden de los campos y en el conjunto exacto de encabezados opcionales, pero todo INVITE conforme incluye los mismos campos obligatorios y la misma estructura de tres secciones.

El cuerpo SDP

El cuerpo es casi siempre una oferta de Session Description Protocol (SDP) (RFC 8866, que reemplazó a RFC 4566 en 2021). Líneas clave:

• v= versión del protocolo (siempre 0)
• o= origen: ID de sesión + dirección del originador
• s= nombre de la sesión
• c= conexión: IP donde el originador espera recibir medios
• t= tiempo (casi siempre 0 0 para SIP en tiempo real)
• m= línea de medios: tipo, puerto, transporte, lista de payload-type
• a= atributos: rtpmap, fmtp, sendrecv/sendonly/recvonly/inactive, crypto (SDES), fingerprint (DTLS-SRTP)

SDP sigue el modelo de oferta/respuesta (RFC 3264). El INVITE lleva la oferta; el 200 OK lleva la respuesta. Una implementación que utilice SRTP con SDES keying debe proteger la ruta de señalización con TLS; de lo contrario, las claves maestras cruzan la red en texto claro dentro de la línea a=crypto.

Encabezados opcionales importantes en un INVITE

El INVITE incluye más encabezados opcionales que cualquier otro mensaje SIP, porque establece el diálogo, negocia capacidades y asevera identidad, todo al mismo tiempo. La referencia completa de encabezados SIP cubre cada encabezado campo por campo; aquí nos enfocamos en los que afectan específicamente el procesamiento del INVITE.

Negociación de capacidades: Allow enumera los métodos que el UA admite, Supported lista las extensiones que comprende, y Require lista las extensiones que el lado remoto debe admitir o el INVITE falla (comúnmente timer, 100rel, replaces). Estos tres encabezados determinan si el diálogo puede establecerse.

Ruta de enrutamiento: Route preestablece los saltos que el INVITE recorre; Record-Route marca los intermediarios que desean permanecer dentro del diálogo para solicitudes posteriores. Un SBC B2BUA elimina ambos y re-origina enrutamiento nuevo en la pata saliente.

Identidad del emisor: P-Asserted-Identity (RFC 3325) transporta el identificador de llamadas aseverado por el operador, y P-Preferred-Identity es lo que el UA solicita. El encabezado Identity de STIR/SHAKEN (RFC 8224) agrega un PASSporT firmado que vincula el número del emisor a una identidad criptográfica. Privacy (RFC 3323) controla qué información se oculta hacia el destino.

Historial de desvío de llamadas: Diversion y History-Info (RFC 4244) transportan el historial de redirección cuando una llamada ha sido desviada. Son dos estándares competidores; los fabricantes prefieren formatos diferentes, y el SBC frecuentemente normaliza entre ambos.

Ciclo de vida de la sesión: Session-Expires y Min-SE (RFC 4028) establecen el intervalo de actualización que previene sesiones fantasma semicerradas. User-Agent identifica el software emisor, útil para correlación de trazas.

Del INVITE al diálogo

Un INVITE que llega al destino desencadena una secuencia de respuestas: 100 Trying de inmediato, luego una o más respuestas provisionales 18x (180 Ringing, 183 Session Progress), y finalmente 200 OK con el To-tag establecido cuando el destinatario contesta. El emisor confirma con ACK y el diálogo queda completamente establecido.

Los re-INVITE dentro de un diálogo existente reutilizan el mismo Call-ID, To-tag y From-tag con un CSeq superior, modificando la sesión (cambio de códec, espera, transferencia). Los códigos de respuesta provisionales, de éxito y de error que completan la transacción INVITE siguen el mismo patrón de 1xx a 6xx utilizado en todo SIP.

Cómo los SBC intervienen en el INVITE

Un controlador de borde de sesión (SBC) B2BUA termina el INVITE entrante y construye un INVITE saliente completamente nuevo en la otra pata. Cada encabezado del mensaje saliente se construye desde cero, lo que significa que un SBC puede eliminar campos propietarios, reescribir encabezados de identidad, normalizar Diversion a History-Info (o viceversa), inyectar el encabezado Identity de STIR/SHAKEN desde un servicio de firma externo, y reescribir Contact y Via para ocultar la topología interna del originador. La mecánica de esas reescrituras se cubre en manipulación de encabezados SIP; la razón arquitectónica por la que un proxy no puede hacer lo mismo se cubre en SIP proxy vs SBC.

Preguntas frecuentes

¿Por qué un INVITE tiene tanto From como P-Asserted-Identity?

El encabezado From lleva la identidad que el emisor declara. PAI lleva la identidad que el proveedor upstream está dispuesto a respaldar después de autenticar al usuario.

¿Cuál es la diferencia entre el Request-URI y el encabezado To?

El Request-URI es la dirección a la que la solicitud apunta en ese momento (cambia a medida que proxies y SBC la reenvían). El encabezado To es el destino lógico original (no cambia en tránsito).

¿Puede un INVITE no tener cuerpo?

Sí. Un INVITE de “oferta diferida” no tiene SDP. El destinatario responde con su oferta SDP en el 200 OK; el ACK del emisor lleva la respuesta. Es poco común en despliegues modernos de operadores, pero todavía se ve en algunos escenarios legacy de click-to-call.

¿Por qué Max-Forwards se inicializa en 70?

Es una convención de RFC 3261. Lo suficientemente alto para atravesar cualquier ruta SIP realista, lo suficientemente bajo para que los bucles se detecten y resuelvan rápidamente.

¿Para qué sirve el parámetro branch en el encabezado Via?

Identifica una transacción SIP individual en un salto individual. Cada salto inserta un branch nuevo al reenviar. Los branch compatibles con SIP/2.0 deben comenzar con z9hG4bK.