Leer el diagrama de escalera SIP

Para qué sirve

El diagrama de escalera SIP muestra la señalización de una llamada como una secuencia de flechas entre los interlocutores implicados. Lo encontrará en la pestaña Call flow de Call diagnostics y en la pestaña Call flow de Call analysis. Ambas utilizan el mismo diagrama. Para las llamadas de Teams a través del SBC integrado existe un diagrama de escalera propio con dos carriles, que se lee del mismo modo.

Este capítulo explica la estructura del diagrama y muestra, con seis flujos típicos, qué mensajes se ven y en qué orden. Con estos patrones reconocerá rápidamente, en un flujo desconocido, dónde se aparta del caso normal.

SIP trabaja con solicitudes y respuestas. Una solicitud lleva un método como INVITE o BYE. Cada respuesta lleva un código de tres cifras: 1xx es provisional, 2xx éxito, 3xx redirección, de 4xx a 6xx error. Una llamada consta de al menos un diálogo, reconocible por el Call-ID común. CUCM se sitúa entre las partes y mantiene un diálogo propio con cada lado. Por eso, una llamada de teléfono a teléfono muestra dos diálogos.

Requisitos previos

• Un diagnóstico de llamada finalizado o una llamada con flujo de llamada de Call analysis. Rol ROLE_APP_CALL_DIAGNOSTICS.
• En CUCM, Cisco CallManager utiliza el nivel de traza Detailed con Enable SIP Call Processing Trace. De lo contrario, las trazas no contienen mensajes SIP.
• El diagrama muestra solo SIP. Los teléfonos con SCCP, los puertos analógicos y los gateways con MGCP o H.323 no aparecen como carril propio.
• Para los mensajes del CUBE: captura de depuración activada en el CUBE y acceso de lectura a los CUBE.

Paso a paso: cómo proceder

1. Lea primero la fila de cabecera de los carriles. Determine qué carril es el llamante, cuál es el nodo CUCM y cuál es el destino o el trunk.
2. Busque el primer INVITE. Está arriba del todo y va del llamante a CUCM.
3. Siga el diálogo del llamante hacia abajo hasta la última respuesta a ese INVITE. Su color le indica cómo terminó la llamada: verde contestada, rojo fallida.
4. Busque el INVITE que CUCM envía al destino. Compare si el error procede del destino o si lo generó el propio CUCM.
5. Utilice Hide 100 Trying y Hide NOTIFY, INFO and OPTIONS para ocultar lo que no es relevante.
6. Utilice los botones de diálogo para desactivar diálogos individuales hasta que solo quede visible el tramo que está examinando.
7. Haga clic en el mensaje decisivo y lea las cabeceras y el SDP en la vista del mensaje.
8. Observe los intervalos en la columna de hora. Una pausa larga antes de una respuesta muestra dónde hubo una espera.
9. Compare el flujo con los patrones de las secciones siguientes.

Campos y opciones: estructura del diagrama

Flujo: llamada correcta

1. INVITE con SDP del llamante a CUCM. El llamante ofrece sus códecs.
2. 100 Trying de vuelta al llamante. CUCM ha aceptado la solicitud.
3. INVITE de CUCM al destino. Es un diálogo nuevo con otro color.
4. 180 Ringing del destino a CUCM y de CUCM al llamante. El destino está sonando.
5. 200 OK con SDP del destino. El llamado ha descolgado e indica su códec.
6. ACK en ambos diálogos. El establecimiento de la llamada queda confirmado y el audio fluye.
7. BYE del lado que cuelga y 200 OK como confirmación. En Call analysis el resultado es Answered.

Flujo: ocupado

1. INVITE del llamante a CUCM, 100 Trying de vuelta.
2. INVITE de CUCM al destino.
3. 486 Busy Here del destino, en rojo. Con menos frecuencia, 600 Busy Everywhere.
4. ACK de CUCM al destino. Toda respuesta final a un INVITE se confirma con ACK.
5. 486 Busy Here de CUCM al llamante y el ACK del llamante. Resultado Busy, causa Q.850 17.
6. Si el 486 aparece solo en el diálogo con el llamante y no hay ningún INVITE al destino, CUCM decidió por sí mismo, por ejemplo porque se ha alcanzado el busy trigger de la línea.

Flujo: inaccesible o no contestada

1. INVITE del llamante a CUCM, 100 Trying de vuelta.
2. Número desconocido: 404 Not Found directamente de CUCM, sin INVITE a un destino. Del mismo modo 410 Gone, 484 Address Incomplete, 485 Ambiguous o 604 Does Not Exist Anywhere. Resultado Unreachable.
3. Destino no registrado o temporalmente no disponible: 480 Temporarily Unavailable. Resultado No answer.
4. El destino no responde: después de 180 Ringing no sigue nada durante mucho tiempo, y luego 408 Request Timeout o 480. La columna de hora muestra el tiempo de espera.
5. Trunk o gateway averiado: 503 Service Unavailable o 502 Bad Gateway desde el carril del trunk. Resultado Failed.
6. Los códecs no coinciden: 488 Not Acceptable Here. Compare el SDP del INVITE con los códecs que admite el destino.
7. El destino rechaza: 403 Forbidden o 603 Decline. Resultado Rejected.

Flujo: abandonada por el llamante

1. INVITE del llamante, 100 Trying, INVITE al destino, 180 Ringing.
2. CANCEL del llamante a CUCM. El llamante cuelga antes de que alguien descuelgue.
3. 200 OK al CANCEL.
4. CANCEL de CUCM al destino y su 200 OK.
5. 487 Request Terminated como respuesta al INVITE original, en ambos diálogos, cada una con ACK.
6. El 487 es rojo aunque no hay ningún error. Lo determinante es el CANCEL anterior. Resultado Abandoned by caller.

Flujo: redirección

1. INVITE del llamante a CUCM.
2. Con un desvío de llamadas en CUCM, el INVITE no va al destino marcado, sino al destino del desvío. Lleva una cabecera Diversion con el número marcado originalmente y el motivo.
3. Con un desvío si no contesta, primero verá INVITE y 180 Ringing hacia el primer destino, después CANCEL hacia ese destino y un nuevo INVITE con Diversion hacia el segundo.
4. Si un interlocutor redirige por sí mismo, responde con 302 Moved Temporarily, en naranja. La cabecera Contact indica el nuevo destino. Sigue un nuevo INVITE hacia él.
5. El resto del flujo es igual que en la llamada correcta. En Call analysis la llamada lleva la característica Forwarded, y la pestaña Overview muestra la Redirect chain.
6. Haga clic en el INVITE hacia el destino del desvío y lea la cabecera Diversion para ver el origen y el motivo.

Flujo: transferencia

1. La primera llamada se establece como en el flujo de la llamada correcta.
2. Quien transfiere pone la llamada en espera: otro INVITE en el diálogo existente (re-INVITE) con SDP, respondido con 200 OK y ACK.
3. Quien transfiere establece una llamada de consulta con el destino de la transferencia: un diálogo nuevo con INVITE, 180 Ringing, 200 OK, ACK.
4. REFER de quien transfiere a CUCM. La cabecera Refer-To indica el destino de la transferencia, junto con Replaces en una transferencia con consulta.
5. 202 Accepted al REFER, después NOTIFY con el progreso.
6. CUCM conecta al llamante y al destino de la transferencia con un re-INVITE o UPDATE y un SDP nuevo en ambos diálogos.
7. BYE a quien transfiere. Los dos diálogos restantes continúan. En Call analysis la llamada lleva la característica Transfer.

Comprobar el resultado y acotar errores

• Ha entendido el flujo cuando puede decir en una frase quién terminó la llamada y con qué mensaje.
• 401 Unauthorized o 407 Proxy Authentication Required justo después del primer INVITE, seguido de ACK y de un segundo INVITE con el mismo Call-ID, es la autenticación normal del dispositivo y no un error.
• El diagrama no empieza con INVITE: las trazas de CUCM comenzaron después del inicio de la llamada. El aviso sobre el diagrama lo indica.
• El diagrama termina sin BYE: la llamada seguía en curso cuando se leyeron las trazas, o se alcanzó el límite de 800 mensajes.
• Falta un tramo por completo: el dispositivo no utiliza SIP, no se pudo leer un nodo, o la llamada pasó por un nodo situado más allá del límite de 8 nodos. Revise la tabla de nodos.
• Ambas partes están en el mismo carril: comparten una dirección IP. Distíngalas con los botones de diálogo.
• 200 OK y ACK están presentes, pero no hubo audio: la señalización es correcta. Compare la dirección, el puerto y el códec en el SDP de ambos lados y revise la ruta de medios en la red.
• En la vista del mensaje se eliminan las credenciales y las claves SRTP. Los mensajes muy largos se acortan a 8 KB.