Wenn ein IP-Telefon über NAT kommuniziert, können externe Medienströme möglicherweise nicht durch das interne Netzwerk gelangen, was zu Kommunikationsfehlern führt. Diese Situation kann auch auftreten, wenn zwei bereits verbundene Geräte lange im Hold-Zustand bleiben. Da die vom externen Router gespeicherten NAT-Zuordnungsinformationen ablaufen können, kann die Kommunikation auch nach Resume weiterhin fehlschlagen.
Um eine normale Kommunikation unter NAT sicherzustellen, ist RTP-Stream-Traversal besonders wichtig.
Gemäß RFC6263 muss ein Gerät in den Zuständen INACTIVE und RECVONLY eine der in der Spezifikation empfohlenen Methoden verwenden, um regelmäßig RTP-Pakete zu senden. Die Spezifikation empfiehlt das Multiplexen von RTCP mit RTP. Da jedoch viele Endgeräte diese Methode möglicherweise nicht implementiert haben, wird aus Kompatibilitätsgründen ein anderer Ansatz gewählt.
Unter Bezugnahme auf Abschnitt 4 der Spezifikation kann die Kommunikation durch periodisches Senden von RTP-Paketen mit einem falschen Payload Type aufrechterhalten werden.
1.3.1 Konfiguration
Nachdem die oben gezeigte Konfiguration aktiviert wurde, wird RTP-Stream-Traversal eingeschaltet. RTP Keep Alive-Pakete werden in den folgenden Situationen gesendet:
1 Nachdem der Telefonanruf verbunden ist, sendet das Telefon RTP-Pakete, um den NAT-Kanal zu öffnen. Dies gilt für X6-Videoanrufe.
2 Nachdem der Telefonanruf in Hold versetzt wurde, sendet das Telefon regelmäßig RTP-Pakete, um die NAT-Verbindung aufrechtzuerhalten.
1.3.2 Paketmitschnitt
Die folgende Abbildung zeigt das gesendete RTP Keep Alive -Paket. Im von Wireshark analysierten Paket ist zu sehen, dass der Codec eines normalen Anrufs G.711 PCMU ist und sich vom Codec des gesendeten RTP Keep Alive-Pakets unterscheidet.
Die folgende Abbildung zeigt ein vollständiges RTP Keep Alive-Paket.