User Defined Source Port Ranges for PAT Overview
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.
Here is an example from a debug ip nat sip I did:
02:02:14: NAT: SIP: [1] translate embedded port 1029->5060
Here is an example from show ip nat trans:
Pro Inside global Inside local Outside local Outside global
udp 192.1.271:1024 10.1.1.252:5060 192.168.8.13:5060 192.168.8.13:5060
Even Port Parity
Cisco IOS NAT SIP gateways normally select the next available port+1 for SIP fixup in the NAT translations. The NAT gateway does not check for even/odd pair for RTP/TRCP port numbers, and as a result issues may arise with SIP user agents that are strictly following the encouraged even/odd parity for RTP/RTCP port numbers.
Even port parity for SIP, H.323, and skinny is supported by default and it can be turned off forcing the odd RTP ports allocation.
User Defined Source Port Ranges for PAT: Example
The following examples shows how to assign a set of ports and associate a map to them.
ip nat portmap NAT-I
cisco-rtp-h323-low
appl sip-rtp startport 32128 size 128
appl sip-rtp startport 32000 size 64
ip nat inside source list 1 pool A overload portmap NAT-I
Table 1 Macro Names and Ports
|
Macro Name
|
Ports
|
Application
|
|
cisco-rtp-h323-low
|
16384-32767
|
H.323
|
|
cisco-rtp-h323-high
|
49152-65535
|
H.323
|
|
cisco-rtp-skinny-low
|
16384-32767
|
Skinny
|
|
cisco-rtp-skinny-high
|
49152-65535
|
Skinny
|
|
cisco-rtp-sip-low
|
16384-32767
|
SIP
|
|
cisco-rtp-sip-high
|
49152-65535
|
SIP
|
Configuration Examples for Even Port Parity
Even Port Parity: Example
The following example enables even port parity for H.323.
ip nat service allow-h323-even-rtp-ports
The following example enables even port parity for SIP.
ip nat service allow-sip-even-rtp-ports
The following example enables even port parity for the skinny protocol.
ip nat service allow-skinny-even-rtp-ports
source: http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iad_pat_pt_rng.html
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6640/prod_white_paper0900aecd80597bc7.html