Seis cabeceras son obligatorias en toda solicitud SIP: Via (registra el trayecto y transporta el branch de la transacción), From y To (las partes lógicas, con etiquetas), Call-ID (un identificador único de llamada), CSeq (un número de secuencia más el método) y Max-Forwards (un límite de saltos). Juntas, Call-ID, la etiqueta de From y la de To identifican un diálogo.
Las seis cabeceras obligatorias
RFC 3261 exige seis campos de cabecera en toda solicitud. Via traza la ruta que tomó la solicitud e indica a las respuestas cómo volver. From y To identifican el originador y el objetivo lógicos de la solicitud. Call-ID es un token globalmente único compartido por todos los mensajes de una llamada. CSeq ordena las solicitudes dentro de un diálogo y nombra el método. Max-Forwards es un contador de saltos decreciente que evita bucles. Omite cualquiera de ellas y el mensaje es inválido.
| Encabezado | Propósito |
|---|---|
| Via | Registra cada salto; las respuestas lo siguen de vuelta. Lleva la rama de la transacción |
| From | Originador lógico; lleva una etiqueta |
| To | Destinatario lógico; obtiene una etiqueta en la respuesta |
| Call-ID | Identificador único global para toda la llamada |
| CSeq | Número de secuencia + método; ordena las solicitudes dentro del diálogo |
| Max-Forwards | Límite de saltos (normalmente 70); evita bucles de enrutamiento |
Via y el parámetro branch
Cada proxy que reenvía una solicitud inserta su propia cabecera Via arriba, construyendo una pila que las respuestas recorren de vuelta: una respuesta se enruta puramente siguiendo la lista de Via, así que retraza el trayecto de la solicitud. El parámetro branch de Via identifica la transacción; desde RFC 3261 debe empezar con la cookie mágica fija z9hG4bK, que marca el branch como globalmente único y conforme a RFC 3261. Emparejar respuestas y retransmisiones con la transacción correcta depende de este valor.
Etiquetas, diálogos y transacciones
La identidad del diálogo se compone de tres piezas: el Call-ID más la etiqueta de From y la etiqueta de To. El emisor fija la etiqueta de From cuando envía el INVITE; el destinatario añade la etiqueta de To en su respuesta, y en ese punto el diálogo queda totalmente identificado para ambos lados. Cada solicitud posterior dentro del diálogo (re-INVITE, BYE) transporta las tres para asociarse a la llamada correcta. Las transacciones, en cambio, se emparejan por el branch de Via y el método: una granularidad más fina que la del diálogo.
| Alcance | Identificado por |
|---|---|
| Diálogo (la llamada) | Call-ID + From-tag + To-tag |
| Transacción (solicitud + respuestas) | Rama de Via + método de la solicitud |
| Orden de las solicitudes en un diálogo | Número de CSeq (incrementos por solicitud) |
Contact, enrutamiento y otras cabeceras comunes
Más allá de las seis obligatorias, varias cabeceras dan forma al enrutamiento y las capacidades. Contact da una URI directa en la que el emisor puede ser alcanzado para futuras solicitudes, crítica en REGISTER y en los mensajes que establecen diálogo. Record-Route permite a un proxy permanecer en el trayecto de señalización durante todo el diálogo, y Route dirige las solicitudes posteriores por esos proxies. Expires acota un registro o una suscripción. Allow, Supported y Require anuncian y negocian capacidades y extensiones. Content-Type y Content-Length describen el cuerpo (normalmente SDP).
Via: SIP/2.0/UDP pc.example.com;branch=z9hG4bK74bf9 ← transaction id
From: Alice <sip:alice@example.com>;tag=9fxced76sl ← caller + From-tag
To: Bob <sip:bob@biloxi.com> ← callee (To-tag added in reply)
Call-ID: 3848276298220188511@pc.example.com ← whole-call id
CSeq: 1 INVITE ← sequence + method
Contact: <sip:alice@pc.example.com> ← where to reach the caller
Max-Forwards: 70 ← hop limitPreguntas frecuentes
¿Qué hace la cabecera Via en SIP?
Via registra el trayecto que toma una solicitud: cada proxy añade su propia Via arriba, y las respuestas siguen la pila de Via de vuelta al emisor. Su parámetro branch identifica la transacción, de modo que las respuestas y retransmisiones se emparejan con la solicitud correcta.
¿Qué es el parámetro branch z9hG4bK?
z9hG4bK es la cookie mágica obligatoria con la que debe empezar un parámetro branch de SIP bajo RFC 3261. Señala que el valor del branch es globalmente único y conforme a RFC 3261, y es la clave usada para emparejar una respuesta con su transacción.
¿Cómo se identifica un diálogo SIP?
Por la combinación de Call-ID, la etiqueta de la cabecera From y la etiqueta de la cabecera To. El emisor aporta el Call-ID y la etiqueta de From en el INVITE; el destinatario añade la etiqueta de To en su respuesta. Todas las solicitudes dentro del diálogo transportan los mismos tres valores.
¿Para qué sirve la cabecera CSeq?
CSeq contiene un número de secuencia y el método de la solicitud, ordenando las solicitudes dentro de un diálogo y permitiendo a cada lado detectar retransmisiones y mensajes desordenados. El número se incrementa con cada nueva solicitud; el método debe coincidir con la solicitud que etiqueta.
¿Cuál es la diferencia entre Contact y To?
To es el objetivo lógico de la solicitud y por lo general no cambia. Contact es una URI concreta en la que el emisor puede ser alcanzado realmente para solicitudes posteriores. Los proxies enrutan por To/Request-URI, pero las solicitudes posteriores dentro del diálogo se envían al Contact.
Especificaciones de la fuente
Las normas publicadas en las que se basa esta página. Se abre en una pestaña nueva.