Encabezados SIP: referencia completa

Los encabezados SIP transportan cada pieza de metadatos que una sesión de voz o video necesita. De dónde proviene la llamada, hacia dónde debe ir, qué códecs se ofrecen en el cuerpo SDP, quién afirma estar llamando, si la troncal ha sido autenticada, cuánto tiempo es válida la sesión. El protocolo de señalización entrega todo esto como un conjunto de campos nombrados dentro de cada mensaje SIP, y el valor en cada campo controla un comportamiento específico en el siguiente salto. Leer y razonar sobre esos campos es la diferencia entre una interconexión funcional y una tarde mirando trazas.

Esta página es la referencia campo por campo. Agrupa los encabezados que encontrará en categorías prácticas, muestra la sintaxis de cada uno y explica lo que realmente hace en la red. Si desea la descripción conceptual de cómo funciona SIP a nivel de protocolo, el artículo complementario Fundamentos de señalización SIP cubre roles y arquitectura; Flujo de llamada SIP explicado paso a paso recorre cada mensaje en una llamada típica en orden. Esta página es a la que recurre cuando ya conoce el flujo y necesita conocer los campos.

Anatomía de un mensaje SIP

Cada mensaje SIP tiene tres partes: una línea de inicio, un bloque de campos de encabezado y un cuerpo opcional separado de los encabezados por una línea en blanco. La línea de inicio es una línea de solicitud (por ejemplo, INVITE sip:bob@provider.com SIP/2.0) o una línea de estado (por ejemplo, SIP/2.0 200 OK). El bloque de encabezados es una secuencia de líneas Field-Name: field-value, una por encabezado lógico. El cuerpo, cuando está presente, se describe mediante los encabezados de contenido (más comúnmente SDP para la negociación de medios).

Algunas reglas mecánicas aplican a todo el bloque de encabezados. Los nombres de campo no distinguen mayúsculas de minúsculas: From, FROM y from son el mismo encabezado. Muchos encabezados también tienen una forma compacta de una sola letra para uso en transportes con espacio limitado; f equivale a From, t equivale a To, v equivale a Via, m equivale a Contact, i equivale a Call-ID, l equivale a Content-Length y c equivale a Content-Type. Los valores de encabezado pueden extenderse a través de líneas comenzando la continuación con espacio en blanco, y múltiples valores para el mismo encabezado pueden enviarse como un encabezado con un valor separado por comas o como varios encabezados separados con el mismo nombre.

El orden de los encabezados generalmente no afecta el comportamiento del protocolo. El orden de los parámetros dentro del valor de un solo encabezado a veces sí importa, particularmente en Via, Route y Record-Route. Muchos terminales e intermediarios asumen un orden típico de encabezados al analizar, por lo que una implementación defensiva tolera cualquier orden pero produce uno familiar.

Encabezados de diálogo y direccionamiento

Estos encabezados identifican quién participa en la llamada, identifican el diálogo en sí y le indican a cada parte dónde enviar mensajes posteriores.

From identifica al originador lógico de la solicitud. El valor es un nombre para mostrar más un SIP URI entre corchetes angulares, con un parámetro tag obligatorio que identifica de manera única este extremo del diálogo: From: "Alice" <sip:alice@company.com>;tag=1928301774. El From-tag permanece constante para cada solicitud y respuesta en el diálogo. Note que From no es necesariamente el llamante real; en muchas topologías empresariales y de operadores se reescribe o se verifica por separado a través de P-Asserted-Identity (cubierto más adelante).

To nombra al destinatario lógico de la solicitud y sigue la misma sintaxis que From: To: "Bob" <sip:bob@provider.com>. El lado originador envía la solicitud sin tag; el destinatario agrega un To-tag en la primera respuesta que no sea 100 y a partir de ese punto el To-tag forma parte del identificador del diálogo. El Request-URI en la línea de inicio puede diferir del URI del To a medida que la solicitud se enruta.

Call-ID es una cadena globalmente única que, combinada con el From-tag y el To-tag, identifica un único diálogo SIP a través de cada mensaje que produce: Call-ID: a84b4c76e66710@192.0.2.10. Lo genera el terminal originador y nunca cambia durante la vida del diálogo. Un B2BUA produce dos Call-ID separados, uno por tramo, porque opera dos diálogos independientes.

Contact le indica al otro lado dónde enviar futuras solicitudes dentro del diálogo para esta sesión: Contact: <sip:alice@192.0.2.10:5060>. El valor normalmente es la dirección de transporte real del terminal, no un nombre de dominio, porque el enrutamiento debe alcanzar una instancia específica después de la configuración inicial. Los SBC frecuentemente reescriben Contact durante la ocultación de topología, reemplazando la dirección interna con la dirección pública del propio SBC.

Reply-To indica una dirección alternativa que debería usarse para cualquier respuesta que el llamante desee dirigir a un lugar diferente del URI del From. Es raro en la práctica y mayormente informativo.

Encabezados de enrutamiento

Los encabezados de enrutamiento dictan la ruta explícita que una solicitud debe transitar hacia adelante a través de la red y aseguran que las respuestas puedan retroceder con precisión por esa misma ruta.

Via registra cada salto que una solicitud ha recorrido. Cada proxy agrega un encabezado Via antes de reenviar la solicitud. Un B2BUA genera una nueva solicitud con su propia cadena Via independiente en el tramo de salida. Las respuestas recorren los Via en orden inverso para llegar al originador. Un Via típico se ve así: Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds. El parámetro branch es el identificador de transacción; los valores que comienzan con z9hG4bK cumplen con RFC 3261. Múltiples encabezados Via aparecen apilados cuando hay varios intermediarios en la ruta.

Max-Forwards limita cuántos saltos puede realizar una solicitud antes de ser rechazada: Max-Forwards: 70. Cada proxy decrementa el valor en uno y descarta la solicitud cuando llega a cero, devolviendo 483 Too Many Hops.

Route contiene una lista explícita de intermediarios por los que una solicitud debe transitar. El terminal originador escribe un encabezado Route para cada salto que se le ha indicado usar, y cada salto elimina su propia entrada de la parte superior antes de reenviar. Así es como funciona el enrutamiento flexible en la práctica y cómo los SBC dirigen el tráfico que de otro modo sería libre de elegir su propio camino.

Record-Route funciona en la dirección opuesta: un proxy o B2BUA que desea que las solicitudes posteriores dentro del diálogo recorran la misma ruta se inserta en Record-Route en la solicitud inicial. Cada terminal luego copia la lista de Record-Route en los encabezados Route de las solicitudes posteriores, anclando el diálogo a esa ruta. Record-Route es esencial para cualquier intermediario que necesite permanecer en la señalización para contabilidad, anclaje de medios o aplicación de políticas después de que la llamada se establece.

Encabezados de transacción y secuenciamiento

SIP superpone un modelo de transacciones sobre transportes no confiables, y un pequeño conjunto de encabezados y parámetros mantienen las solicitudes y respuestas correctamente emparejadas.

CSeq lleva un número de secuencia más un nombre de método: CSeq: 314159 INVITE. El número se incrementa en uno por cada nueva solicitud que el originador envía dentro del diálogo, y el método coincide con la solicitud que se está enviando (o la solicitud original, en el caso de ACK, que mantiene el número CSeq del INVITE pero cambia el método). CSeq es cómo un terminal que responde empareja un 200 OK con el INVITE correcto cuando varios están en curso, y cómo sabe que un re-INVITE es una nueva solicitud en lugar de una retransmisión de una anterior.

El parámetro tag en From y To identifica de manera única un extremo de un diálogo. El From-tag lo genera el originador en el momento del INVITE; el To-tag lo genera el destinatario en la primera respuesta que no sea 100. Los dos tags más el Call-ID juntos forman el identificador del diálogo; cualquier solicitud que porte estos tres valores se trata como dentro del diálogo.

El parámetro branch en Via identifica una sola transacción. Cada solicitud obtiene un nuevo valor de branch, y la respuesta correspondiente copia el branch de vuelta para que el originador pueda emparejarlo.

Encabezados de contenido

Cuando un mensaje SIP lleva un cuerpo, los encabezados de contenido lo describen. El cuerpo en sí es más frecuentemente SDP para la negociación de medios, pero SIP puede transportar cualquier tipo MIME, incluyendo text/plain, application/pidf+xml para presencia, multipart/mixed para varios cuerpos en un mensaje, e image/jpeg o message/sipfrag para usos menos comunes.

Content-Type declara el tipo MIME del cuerpo: Content-Type: application/sdp. Para cuerpos multiparte, el tipo también nombra un parámetro boundary que separa las partes.

Content-Length indica el tamaño del cuerpo en octetos: Content-Length: 142. Un Content-Length incorrecto sobre un transporte de flujo rompe el enmarcado del mensaje.

Content-Disposition le indica al destinatario cómo manejar el cuerpo. Valores como session (el cuerpo describe la sesión, el valor por defecto para SDP), render (mostrar esto al usuario) y signal (un cuerpo que afecta la señalización, como un URI de referencia) ayudan a los terminales a dirigir contenidos multiparte al subsistema correcto.

Content-Encoding describe cualquier codificación (compresión, típicamente gzip) aplicada al cuerpo. El destinatario revierte la codificación antes de analizar.

Accept anuncia qué tipos de cuerpo aceptará el remitente en una respuesta. Accept-Encoding y Accept-Language cumplen los roles de negociación correspondientes. Estos encabezados importan más para el descubrimiento de capacidades vía OPTIONS.

Encabezados de capacidad

Los encabezados de capacidad permiten a cada lado describir lo que puede hacer y lo que requiere que el otro lado haga. Son la forma en que las extensiones SIP permanecen compatibles con versiones anteriores.

Allow lista los métodos SIP que el remitente admite: Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, NOTIFY, UPDATE. Se publica en respuestas OPTIONS, respuestas 405 y el 200 OK que establece un diálogo.

Supported anuncia extensiones SIP opcionales que el remitente comprende por nombre (por ejemplo, timer, 100rel, replaces), permitiendo a los dispositivos aguas abajo activar dinámicamente esas funciones para la sesión.

Require da el siguiente paso y exige que el destinatario comprenda una extensión nombrada. Si el destinatario no la comprende, responde con 420 Bad Extension y lista las opciones no reconocidas en Unsupported.

Unsupported aparece solo en respuestas 420 y lista las extensiones nombradas en Require que el destinatario no puede cumplir.

User-Agent identifica el software o dispositivo de origen. Server cumple el mismo rol en las respuestas. Ambos son informativos.

Encabezados de identidad del llamante y privacidad

La identidad en SIP está organizada por capas. El encabezado From es lo que dice el llamante; los encabezados en esta sección son lo que los intermediarios verifican sobre el llamante, quién puede ver esa información y qué manejo histórico ha ocurrido a lo largo del camino. Estos campos controlan la visualización del identificador de llamadas, el comportamiento de interconexión entre operadores y la atestación STIR/SHAKEN, y son los objetivos más comunes de la manipulación de encabezados SIP en el borde del SBC.

P-Asserted-Identity (PAI) transmite la identidad del llamante según la verifica un intermediario de confianza, típicamente el operador de origen: P-Asserted-Identity: <sip:+15145551234@carrier.com>. Muchas PBX receptoras leen el identificador de llamadas del PAI en lugar del From cuando ambos están presentes.

P-Preferred-Identity (PPI) es el lado de solicitud de la misma relación. Un terminal que posee varias identidades válidas envía PPI para indicar cuál desea que la red verifique.

Privacy solicita la retención de información de identidad. Los valores comunes son id (eliminar PAI de los mensajes que salen del dominio de confianza), header (eliminar encabezados que revelan la identidad del usuario) y none.

Diversion registra que la llamada fue redirigida, nombrando el destino original y el motivo: Diversion: <sip:reception@company.com>;reason=no-answer.

History-Info cumple el mismo propósito que Diversion pero es el reemplazo según el estándar, con manejo estructurado de cadenas de redireccionamiento de múltiples pasos. Ambos coexisten en redes de producción actualmente.

Remote-Party-ID es anterior a PAI y transportaba tanto información de identidad como de privacidad en un solo encabezado. Todavía se encuentra en implementaciones heredadas; las interconexiones modernas esperan PAI más Privacy.

Encabezados de autenticación

La autenticación SIP utiliza HTTP Digest, con un par de encabezados para desafíos de terminales y un par paralelo para desafíos de proxy.

WWW-Authenticate aparece en una respuesta 401 Unauthorized y desafía al solicitante a autenticarse. Contiene un realm, nonce y algoritmo.

Authorization lleva la respuesta en la solicitud reintentada. El terminal calcula un hash digest a partir del nonce, el URI de la solicitud, el método y su secreto compartido.

Proxy-Authenticate y Proxy-Authorization funcionan de manera idéntica pero se utilizan cuando un proxy SIP emite el desafío con 407 Proxy Authentication Required.

Encabezados de temporizador de sesión, suscripción y notificación

Estos encabezados gobiernan cuánto tiempo es válida una sesión o suscripción y qué hace cada lado cuando se acerca la expiración.

Session-Expires establece la vida máxima de una sesión establecida: Session-Expires: 1800;refresher=uac. El parámetro refresher indica qué lado enviará la renovación.

Min-SE declara el intervalo mínimo aceptable de sesión. Un destinatario que recibe un Session-Expires inferior a su propio Min-SE rechaza con 422 Session Interval Too Small.

Expires aparece en REGISTER, SUBSCRIBE y ocasionalmente en INVITE. Los valores son enteros en segundos.

Event nombra el paquete de eventos en SUBSCRIBE y NOTIFY (presence, message-summary, refer).

Subscription-State acompaña cada NOTIFY y describe el estado de la suscripción: active, pending o terminated con un motivo.

Encabezados de transferencia y referencia

La transferencia de llamadas en SIP se implementa mediante el método REFER, que utiliza un pequeño conjunto de encabezados para nombrar el destino e informar sobre el progreso.

Refer-To nombra el destino de una transferencia en una solicitud REFER: Refer-To: <sip:carol@company.com>. Para transferencia atendida, el URI lleva un parámetro Replaces.

Referred-By registra la parte que inició la transferencia.

Replaces se incorpora como un parámetro URI escapado dentro de la cadena de destino Refer-To y posteriormente se eleva a su propio encabezado independiente en el INVITE saliente resultante para señalar el reemplazo de un diálogo existente.

Reason lleva un motivo de estado en BYE o CANCEL, típicamente un código de causa Q.850 o un estado SIP, explicando por qué el diálogo está terminando.

El encabezado Identity (STIR/SHAKEN)

Identity es el encabezado que transporta el PASSporT firmado en la autenticación de llamadas STIR/SHAKEN. El valor es un objeto PASSporT firmado serializado como JSON Web Signature (JWS) más parámetros que nombran la URL del certificado y el nivel de atestación que el proveedor de origen afirma: Identity: eyJhbGciOi...<signature>;info=<https://...cer>;alg=ES256;ppt=shaken.

El encabezado Identity es grande para los estándares SIP (frecuentemente 1-2 KB) y es una de las principales razones por las que las interconexiones modernas necesitan transportes que manejen mensajes SIP por encima del límite típico de fragmentación UDP. Se prefiere TCP o TLS para cualquier troncal que firme o verifique.

Encabezados personalizados, de proveedor y P-Headers

SIP permite que cualquier parte introduzca sus propios encabezados, y en la práctica casi todos los proveedores lo hacen. Dos convenciones de nomenclatura cubren la mayoría de estas extensiones.

P-headers utilizan el prefijo P- y están destinados para uso dentro de una red privada o entre redes cooperantes bajo acuerdo explícito. Varios son parte del estándar (P-Asserted-Identity, P-Preferred-Identity, P-Charging-Vector, P-Access-Network-Info).

X-headers llevan el prefijo X- y señalan una extensión de proveedor o aplicación que no está estandarizada. Aunque los X-headers siguen siendo comunes en equipos heredados, la IETF oficialmente dejó en desuso la convención del prefijo X- en el RFC 6648; las implementaciones modernas registran nuevos encabezados directamente bajo nombres descriptivos (por ejemplo, Company-Header en lugar de X-Company-Header). Cualquier sistema que no comprenda un encabezado personalizado dado simplemente lo ignora.

La regla práctica para ambas categorías es que los encabezados personalizados deben eliminarse antes de que una llamada salga del entorno controlado.

Cómo los SBC tratan los encabezados SIP

Un controlador de borde de sesión en modo B2BUA opera dos diálogos SIP unidos por lógica de enrutamiento interno, lo que significa que los encabezados en el tramo de entrada no son los mismos que en el tramo de salida. Cada tramo tiene su propio Call-ID, su propia cadena Via, su propio Contact y su propio contador CSeq. El SBC reconstruye cada encabezado en el tramo de salida a partir de políticas: lo que el sistema aguas arriba necesita ver, independientemente de lo que llegó en el lado de entrada.

Esta es la base de la normalización SIP. Un operador que entrega la identidad del llamante en P-Asserted-Identity puede interconectarse con una PBX que lee From; el SBC lee PAI en el tramo de entrada y reescribe From en el tramo de salida. El panorama completo de estos tratamientos se cubre en Manipulación de encabezados SIP con un SBC.

Preguntas frecuentes

Conclusión

Los encabezados SIP son la capa de metadatos que hace que todo lo demás en la señalización de voz funcione. El enrutamiento, la identidad, la negociación de capacidades, la autenticación, el ciclo de vida de la sesión, la transferencia y STIR/SHAKEN, todo existe como campos nombrados dentro de mensajes cuya estructura es por lo demás sencilla. La fluidez con estos campos es lo que convierte una traza SIP de un muro de texto ilegible en una secuencia de decisiones que puede seguir y razonar, y es la base de cada corrección de interoperabilidad, cada regla de normalización y cada integración con un operador.

Los conceptos mecánicos están en Fundamentos de señalización SIP; el recorrido mensaje por mensaje está en Flujo de llamada SIP explicado paso a paso; y el motor basado en reglas que reescribe encabezados en producción está en Manipulación de encabezados SIP con un SBC.