Reproducción no se reanuda tras pausarla más de unos 30"

Tengo una teoría de lo que sucede con el Mitrastar (su firmware, claro). Advierto que la explicación es bastante técnica.

Cuando solicitamos reproducir cualquier cosa desde el deco hacemos uso del servicio VoD (Video on Demand), que es el afectado por este problema. Los datos se retransmiten desde algún servidor de Telefónica hacia nuestro deco utilizando el protocolo de transporte UDP. Sin embargo, a diferencia de lo que ocurre con el streaming de los canales de televisión, que se transmite en multicast, el VoD se transmite en unicast. Unicast quiere decir que el destino de esos paquetes de datos es uno y sólo uno.

Muchos de vosotros sabréis que típicamente los routers que conectan una red doméstica o de una empresa no muy grande emplean una técnica lladama NAT (Network Address Traslation) de forma que por lado tienen la red local del cliente, que es una red privada con direcciones del tipo 192.168.x.x 172.16.x.x 10.x.x.x; y por el otro está la red de proveedor de acceso a Internet, el cual sí asigna una dirección IP pública al router por ese lado. Para que desde la red privada del cliente sea posible acceder al resto de Internet es necesario que los paquetes de datos puedan salir desde las máquinas de la red privada hacia Internet, y también que puedan volver desde Internet hacia las máquinas de la red privada. Pero como la red privada usa direcciones IP inaccesibles desde el resto de Internet, el router utiliza la técnica NAT reemplazando las direcciones IP de origen de los paquetes que salen de la red privada con su propia dirección IP pública, la que le ha asignado el proveedor de acceso a Internet.

Esta técnica NAT funciona muy bien con el protocolo de transporte TCP, ya que es un protocolo en el cual siempre se abre primero una sesión (en realidad dos, una para cada sentido), luego se utiliza para enviar y recibir los datos, y por útltimo se cierra la sesión. El router puede seguir fácilmente qué sesiones TCP se están abriendo y cerrando (cada una con números de puerto distintos) y así determinar cómo traducir las direcciones con NAT y a qué máquinas de la red privada debe enviar los paquetes que le llegan desde Internet.

El problema con el protocolo de transporte UDP es que no utiliza sesiones propiamente dichas, por lo que los routers tratan de detectar cuándo se inicia y termina una transmisión de datos mediante UDP midiendo el tiempo que transcurre entre dos paquetes con los mismos números de puerto. Pasado cierto tiempo máximo el router da por "cerrada" la sesión UDP y esa comunicación por terminada. El problema es que esto no siempre funciona: depende de cómo funcione esa comunicación de datos. Generalmente el tiempo máximo que el router espera entre dos paquetes UDP consecutivos con los mismos números de puerto es de unos pocos minutos (en el caso de un streaming de audio o vídeo): por ejemplo 3 minutos.

Sospecho que el problema con el VoD y el Mitrastar va por ahí. Cuando pausamos un vídeo los paquetes UDP dejan de transmitirse hacia nuestro router (y luego desde el router al deco). Apuesto a que lo que sucede es que a partir de cierto tiempo de pausa, el router da por terminada esa sesión UDP, y cuando tratamos de reanudar la reproducción ya es demasiado tarde.

No puedo asegurar que ése sea el problema, pero me da en la nariz de que los tiros van por ahí, o algo muy similar. En ese caso, sólo una nueva versión de firmware que corrija el comportamiento del router a la hora de dar por terminada una sesión de streaming por UDP podría solucionar el problema.