In order for VoIP traffic to not be in violation of the RTP standards and best practices, even/odd pairing of ports for RTP
and RTCP traffic for SIP ALG, Skinny and H.323 has been made available.
Following is a scenario of what happens to VoIP traffic translated using PAT without user defined ports.
The first VoIP traffic getting translated using PAT, would request for port 16384 and would get to use port 16384 for its
RTP traffic.
The second VoIP traffic stream getting translated using PAT would also request 16384 for its RTP. Since this port number is
already in use by the first call, PAT would translate the 16384 source port for the second phone to 1024 (assuming the port
was free) and this would be in violation of the RTP standards/best practices.
A third call would end up using port 1025 and others would increment from there.
Each call after the first call would end up having its inside source port translated to an external port assignment that is
out of specifications for RTP, and this would continue until PAT binding fir the first call expires.
Problems associated with RTP traffic being assigned to a non-standard port by PAT:
-
Inability for compressed RTP (cRTP) to be invoked in the return direction, as it only operates on RTP flows with compliant
port numbers.
-
Difficulty in properly classifying voice traffic for corresponding QoS treatment.
-
Violation of standard firewall policies that specifically account for RTP/TRCP traffic by specified standard port range.