This article explains RTP stream traversal for IP phones, covering NAT media issues, RTP Keep Alive principles, configuration, packet capture checks, and how to maintain stable audio or video communication after Hold and Resume.
When an IP phone communicates across NAT, external media streams may be unable to pass through the private network, which can cause communication failure. This situation may also occur when two connected devices stay on Hold for a long time. Because the NAT mapping information stored by the external router may time out, communication may still fail after Resume.
To ensure normal communication under NAT, RTP stream traversal is especially important.
According to RFC6263, when a device works in INACTIVE or RECVONLY mode, it should periodically send RTP packets by using one of the methods recommended in the specification. The specification recommends multiplexing RTCP with RTP. However, considering compatibility concerns because many terminals may not have implemented this method, another approach is adopted.
Referring to Section 4 of the specification, communication can be maintained by periodically sending RTP packets with an incorrect Payload Type.
1.3.1 Configuration
After the configuration shown above is enabled, RTP stream traversal is activated. RTP Keep Alive packets are sent in the following situations:
1 After the phone call is connected, the phone sends RTP packets to open the NAT channel. This applies to X6 video calls.
2 After the phone call is placed on Hold, the phone periodically sends RTP packets to maintain the NAT connection.
1.3.2 Packet Capture
The following figure shows the transmitted RTP Keep Alive packet. From the packet parsed by Wireshark, the codec of a normal call is G.711 PCMU, which is different from the codec of the transmitted RTP Keep Alive packet.
The following figure shows a complete RTP Keep Alive packet.
