Cuando un teléfono IP se comunica a través de NAT, los flujos de medios externos pueden no atravesar la red interna, lo que provoca fallos de comunicación. Esta situación también puede ocurrir cuando dos dispositivos que ya están comunicándose permanecen en Hold durante mucho tiempo. Debido a que la información de mapeo NAT guardada por el router externo puede expirar, la comunicación puede seguir fallando después de Resume.
Para garantizar una comunicación normal bajo NAT, la travesía de flujo RTP es especialmente importante.
Según RFC6263, cuando un dispositivo trabaja en los modos INACTIVE y RECVONLY, debe utilizar uno de los métodos recomendados por la especificación para enviar paquetes RTP de forma periódica. La especificación recomienda multiplexar RTCP con RTP. Sin embargo, por motivos de compatibilidad, ya que muchos terminales pueden no haber implementado este método, se decide adoptar otra solución.
Tomando como referencia la sección 4 de la especificación, la comunicación puede mantenerse mediante el envío periódico de paquetes RTP con un Payload Type incorrecto.
1.3.1 Configuración
Después de habilitar la configuración mostrada arriba, se activa la travesía de flujo RTP. Los paquetes RTP Keep Alive se envían en las siguientes situaciones:
1 Después de que la llamada del teléfono se conecte, el teléfono envía paquetes RTP para abrir el canal NAT. Esto se aplica a las videollamadas X6.
2 Después de que la llamada del teléfono se ponga en Hold, el teléfono envía paquetes RTP periódicamente para mantener la conexión NAT.
1.3.2 Captura de paquetes
La siguiente imagen muestra el paquete RTP Keep Alive enviado. En el paquete analizado por Wireshark, se puede ver que el códec de una llamada normal es G.711 PCMU, que no coincide con el códec del paquete RTP Keep Alive enviado.
La siguiente imagen muestra un paquete RTP Keep Alive completo.