En telefonía IP, uno de los escenarios más interesantes ocurre cuando una extensión no contesta directamente una llamada, sino que ordena redirigirla a otro destino usando SIP. Cuando eso pasa, empiezan a aparecer headers como 302 Moved Temporarily, 181 Call Is Being Forwarded y, muy especialmente Header SIP Diversion o solo Diversion.

En este artículo voy a explicar qué significa Diversion, por qué aparece, y por qué puede verse diferente según el tramo de la llamada. Antes de iniciar con la explicación, podemos visualizar en este comic el flujo que describiremos.

Escenario de prueba

Para este ejemplo, usaremos un flujo sencillo y anonimizado:

• Origen: 123456789 desde la PSTN
• Destino inicial: extensión 9001
• Dispositivo registrado: Zoiper, aunque el comportamiento sería similar con un hardphone SIP
• Desvío configurado en el endpoint: hacia 5555555555
• Destino final: 5555555555 saliendo nuevamente a la PSTN
• PBX: 123.124.125.126

123456789 (PSTN) → PBX → extensión 9001
                           |
                           └── 302 Moved Temporarily → 5555555555
PBX → nueva llamada saliente → 5555555555 (PSTN)

1. La llamada entra desde la PSTN y llega a la extensión 9001

La PBX recibe una llamada entrante desde la PSTN y decide entregarla a la extensión 9001. Ejemplo simplificado del INVITE que la PBX envía al softphone o hardphone:

INVITE sip:9001@192.168.1.50:5060 SIP/2.0
Via: SIP/2.0/UDP 123.124.125.126:5060;branch=z9hG4bK123456
From: <sip:123456789@123.124.125.126>;tag=abc123
To: <sip:9001@192.168.1.50>
Contact: <sip:asterisk@123.124.125.126:5060>
Call-ID: test-call-001@123.124.125.126
CSeq: 100 INVITE
User-Agent: PBX-Test
Content-Type: application/sdp
Content-Length: 250

Hasta aquí, todo es normal: la PBX está intentando localizar a la extensión 9001.

2. La extensión 9001 no contesta: responde con 302 Moved Temporarily

Si en Zoiper o en un hardphone SIP está configurado el desvío de llamadas, el endpoint puede responder con un 302 Moved Temporarily.

SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 123.124.125.126:5060;branch=z9hG4bK123456
From: <sip:123456789@123.124.125.126>;tag=abc123
To: <sip:9001@192.168.1.50>;tag=redir001
Call-ID: test-call-001@123.124.125.126
CSeq: 100 INVITE
Contact: <sip:5555555555@pbx.example.com>
User-Agent: Zoiper 5
Content-Length: 0

Aquí está ocurriendo algo clave. La extensión 9001 le está diciendo a la PBX:

“No me entregues esta llamada a mí. Envíala mejor a 5555555555.”

Esto significa que el desvío no lo decidió el dialplan, sino el propio endpoint SIP (ya sea teléfono IP o softphone ).

Ese endpoint puede ser:

• un softphone como Zoiper
• un hardphone SIP
• cualquier UA que soporte redirección SIP mediante 302

3. La PBX avisa al llamante que la llamada está siendo desviada.

Después de recibir el 302, la PBX puede responder hacia el lado llamante con un:

SIP/2.0 181 Call Is Being Forwarded
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bKorig001
From: <sip:123456789@pstn-gateway.net>;tag=gw001
To: <sip:9001@123.124.125.126>;tag=pbx181
Call-ID: incoming-leg-001@pstn-gateway.net
CSeq: 200 INVITE
Contact: <sip:123.124.125.126:5060>
Diversion: <sip:5555555555@pbx.example.com>;reason=unknown
Content-Length: 0

Aquí aparece por primera vez el header que nos interesa:

Diversion: <sip:5555555555@pbx.example.com>;reason=unknown

Y aquí es donde muchos se confunden. ¿Qué significa este Header SIP Diversion ?

En este contexto, la PBX está notificando al origen que:

• la llamada ya no seguirá hacia 9001
• la llamada será redirigida
• el nuevo destino informado por el endpoint fue 5555555555

Por eso en este tramo el Diversion contiene el número de desvío. Dicho simple: este mensaje describe hacia dónde se está redirigiendo la llamada.

4. La PBX genera una nueva llamada hacia el destino final

Luego la PBX crea un nuevo INVITE hacia la PSTN para alcanzar el número final 5555555555. Ejemplo:

INVITE sip:5555555555@198.51.100.10 SIP/2.0
Via: SIP/2.0/UDP 123.124.125.126:5060;branch=z9hG4bKout001
From: ;tag=outbound001
To:
Contact:
Call-ID: outbound-leg-001@123.124.125.126
CSeq: 300 INVITE
Diversion: “Usuario 9001” ;reason=unknown
User-Agent: PBX-Test
Content-Type: application/sdp
Content-Length: 270

Ahora el Diversion cambio, y eso también es correcto: Diversion: “Usuario 9001” ;reason=unknown

Entonces, ¿por qué cambia el Header SIP Diversion?

Porque no siempre está representando lo mismo de la misma manera.

Primer caso:  181 Call Is Being Forwarded

Cuando la PBX notifica al lado llamante que la llamada será desviada, puede usar Diversion para expresar el nuevo destino de redirección:

Diversion: <sip:5555555555@pbx.example.com>;reason=unknown

Aquí la idea es “Tu llamada está siendo desviada hacia este número.”

Segundo caso: nuevo INVITE hacia la PSTN

Cuando la PBX genera la nueva llamada saliente, suele usar Diversion para indicar el origen del desvío, es decir, quién provocó la redirección:

Diversion: "Usuario 9001" <sip:9001@123.124.125.126>;reason=unknown

Aquí la idea es “Esta llamada llegó a este destino porque la extensión 9001 la desvió.”

Por qué existe el header Diversion

El header Diversion existe porque, sin él, el siguiente equipo en la ruta vería solamente una llamada nueva, sin contexto. Y en muchos escenarios sí importa saber que la llamada fue desviada.

Algunas razones:

1. Preservar la historia de la llamada

Permite indicar que el destino original no fue el final y que hubo un forwarding en el camino.

2. Interoperabilidad

Otros SBCs, carriers o PBXs pueden usar esta información para entender mejor el flujo de la llamada.

3. Lógica de negocio

Algunos sistemas usan Diversion para:

• distinguir llamadas directas de llamadas desviadas
• aplicar reglas especiales
• controlar buzones de voz
• registrar reportes más precisos
• mantener trazabilidad de la redirección

4. Facturación o validaciones

En algunos entornos, el carrier analiza estos headers para decidir cómo manejar una llamada reenviada.

¿Qué significa reason=unknown?

En muchos ejemplos aparece como unknown, esto indica que el sistema sabe que hubo un desvío, pero no tiene una causa más específica para describirlo.

Esto indica que el sistema sabe que hubo un desvío, pero no tiene una causa más específica para describirlo.

En otros escenarios podrían verse razones como:

• busy
• no-answer
• unconditional

Pero si el endpoint simplemente devuelve un 302 sin más detalle, es común que la PBX use:

reason=unknown

No implica un error. Solo significa que la razón exacta del desvío no fue especificada de manera más precisa.

Punto importante: el desvío puede originarse en el endpoint, no en la PBX

Este tipo de flujo demuestra algo muy importante en telefonía SIP, no siempre el forwarding ocurre en el dialplan o en la configuración central de la PBX. A veces el propio dispositivo final decide redirigir la llamada.

Por ejemplo:

• Zoiper con call forwarding habilitado
• un hardphone SIP con “always forward”
• un equipo con reglas locales de redirección

En esos casos, la PBX no “inventó” el desvío. Lo que hace es obedecer la respuesta 302 y reconstruir la llamada hacia el nuevo destino.

Conclusión

Cuando se analiza SIP, el header Diversion puede parecer confuso porque no siempre “apunta” a la misma entidad. A veces refleja el nuevo destino de la llamada y otras veces identifica quién provocó el desvío.

La clave está en no leerlo aislado, sino en el contexto del mensaje SIP donde aparece.

Si el endpoint devuelve un 302 Moved Temporarily, la PBX normalmente hará dos cosas:

• notificará que la llamada está siendo redirigida
• generará una nueva llamada hacia el nuevo destino
• conservará la historia del desvío usando Diversion

Y justo ahí está el valor de este header: mantener el contexto de una llamada que ya no sigue su ruta original.