- SyR Consultoría
- 27 abril 2021
- 10:00
Post Dial Delay (PDD)
En cristiano: El tiempo que pasa desde que terminas de marcar hasta que escuchas tono de llamada (o de línea ocupada).
Para un proveedor VoIP es importante porque si intento una llamada por tu red y dicha llamada tarda mucho en dar tono de llamada, quizá antes de que eso pase yo cuelgue y tú pierdas esa llamada (y el beneficio que te proporcionaría).
Todo tiempo que esté por debajo de 7 segundos se suele considerar aceptable. Más allá de ese tiempo indica algún problema relacionado con la red: Demasiados saltos, retraso en procesamiento, DNS demasiado lenta…
Más en detalle
Técnicamente definimos el PDD como la diferencia de tiempo desde el SIP INVITE y un 180 Ringing, un 183 Session Progress o, si la llamada falla, por ejemplo un 480.
La imagen de la derecha lo ilustra mejor.
En SIP, el INVITE se envía al momento que, según esa imagen de la derecha, el llamante pulsa el botón de llamada de su teléfono. A partir de ahí, una vez que el otro extremo recibe la solicitud y responde adecuadamente, al momento que devuelve (en el mejor de los casos) el SIP/2.0 180 Ringing (o un 183) empezaremos a escuchar el tono de llamada.
También podría ser que lo que recibamos de vuelta sea un mensaje de error, ese tipo de respuestas suelen tener códigos del tipo 4xx, 5xx o 6xx.
En esta imagen de abajo podemos ver, sobre la traza de una llamada real, cómo podemos medir el PDD:
Valores de PDD aceptables
Antes decíamos que por encima de 7 segundos el valor es malo, pero hay matices en función de en dónde se encuentra el llamante:
- En Europa y Norteamérica 5 segundos ya es demasiado
- En África y Oriente Medio el umbral son unos 10 segundos
- Y hay donde un llamante puede asumir esperar hasta 15 segundos hasta el ring sin perder la paciencia y colgar
Por supuesto, el tiempo también dependerá de a donde llamamos. Aplica la misma lógica pues, como hemos comentado antes, el PDD depende sobre todo de la red por la que va la llamada.
Razones más concretas para un alto PDD
Empezando desde el lado del llamante, una primera causa puede ser tan simple como no darle al botón de llamada después de teclear los dígitos. Los softphone suelen tener programado un tiempo de espera después de teclear y antes de lanzar la llamada para que personas como mi padre, que marca a cámara lenta, pueda terminar de marcar todos los dígitos. Ahí ya podemos tener 3-5 segundos de espera. Técnicamente esto no hace parte del PDD pero se percibe como tiempo de espera.
Si una llamada toma varias rutas hasta acabar progresando y cada proveedor de cada ruta se tomó sus 2-3 segundos en devolver su rechazo, ahí podemos tener un tiempo acumulado preocupante. En ese sentido, aunque sistemas como MOR o M2 puedan gestionar ese fenómeno que se llama desbordamiento, conviene revisar las estadísticas de terminación por proveedor para afinar el enrutamiento y hacer que las llamadas vayan, en primer lugar, por el proveedor que mejor funcione.
La siguiente fuente de error podría ser debida a errores de señalización SIP. Hemos hablado antes de dos respuestas positivas, la 180 Ringing y la 183 Session Progress. La primera hará que la red de origen le reproduzca al llamante un ringback, mientras que la segunda hará que sea la red de destino la que lo reproduzca. Bien, a veces la red de destino quiere mandar su ringback con una respuesta 180 o no lo quiere hacer con una 183, lo que puede dar comportamientos raros. De hecho a veces, incluso, no se llega a enviar ringback alguno y hay un silencio hasta que alguien responde al otro lado.
Los excesos de tiempo en el procesado, propagación de mensajes y temporizadores a la hora de gestionar la llamada a nivel SIP, también pueden contribuir a este PDD. Procesamiento de cabeceras, autenticación, autorización y enrutamiento pueden suponer un tiempo de consultas en bases de datos que añaden tiempo de espera. Cada nodo por el que pase una llamada puede añadir 5 ms al tiempo de espera.
La distancia afecta también. Hay una serie de mensajes de ida y vuelta antes de que la llamada en sí se inicie. Si los dos extremos están en distintos continentes puede haber hasta 100 ms de tiempo para cada respuesta, y si hay 4-6 respuestas antes del ring, eso también cuenta.
Cuando uno de los elementos dentro de la red no da las respuestas adecuadas ocasiona un tiempo añadido hasta que el procesamiento de la llamada continua. A veces los sistemas están simplemente sobrecargados y tardan en responder.
Llamar a un teléfono móvil añade otro tiempo a añadir si la señal de cobertura del receptor de la llamada no es suficientemente buena.
¿Y si llamamos a un número que está desviado hacia otro? ¿Y si está desviado a un teléfono móvil? Ahí tenemos más tiempo que se nos puede estar añadiendo a nuestra espera.
Es muy interesante trabajar de cara a clientes con dominios y no con IPs. Pero un DNS (servidor de dominios) puede añadir también su tiempo a la hora de procesar las peticiones que recibe.
¿Cómo tirar del hilo?
La forma más sencilla es ir probando el mismo destino con distintos proveedores. Si el PDD cambia sabremos que la pelota estaba en su tejado. Si el PDD se mantiene, la pelota está en el nuestro.
Si hay que escalar el asunto al proveedor lo mejor es ir con un PCAP por delante, ahí estará la evidencia y nos evitaremos discusiones. Aquí un ejemplo de PCAP donde se puede apreciar el PDD en el lado del proveedor:
Ring falso
Este es el parche por excelencia. Donde hay un silencio demasiado largo pongo un ring. Habrá quien aguante más porque, al fin y al cabo escucha el ring. Pero no olvidemos, esto no soluciona el problema, lo enmascara.
Y si como operador sufres esto por parte de tus proveedores, pide que te lo retiren. Hacerlo le ayuda a él, no a ti, si la llamada no va a conectar que sea lo antes posible
Conclusión
Como ves, un PDD alto es algo de lo que preocuparse porque supone perder tráfico (y su beneficio asociado).
La mayoría de las veces se resuelve cambiando de proveedor y no olvides lo útil que es el PCAP para evidenciar la situación.