After many hours of troubleshooting and helped by raw access to my NAT device (CPE) I have found the following behavior which I think could strike any one any where when using 3CX VoIP Phone (and possibly others):
RTP Local Ports
- By default there are 50 ports selected for "RTP ports" in the "General network settings" of 3CX VoIP Phone (configurable)
- The idea of having numerous ports is to rotate through the different ports with each RTP stream initialization
- some algorithm should ensure no port is re-used "too quickly" (NAT/NAPT tables and timers make this desirable)
STUN Local Ports
- 3CX VoIP Phone supports connecting to a STUN Server to help clients behind NAT "Discover the network" to better support making calls from their location
- the software appears to use the same "RTP ports" for local ports when connecting to the STUN server
Issue Seen
- UDP local port used to connect to STUN server is the same one RTP then attempts to use for a pending call
Result
- NAT device (NAPT really), which does not specifically have support for SIP (and may have a questionable NAPT implementation), has already made an association on the WAN IP for the given UDP port
- therefore NAT device selects a different WAN UDP port for the RTP session which is not the one the SIP/SDP message communicated
Chain of Events (I will leave out some of the return packets which are unnecessary for this)
# Packet sent from local client on LAN to STUN server
192.168.3.2:40044 -> 96.9.132.83:3478
# NAT device picks up packet, performs NAT and sends to STUN server
my.wan.ip:40044 -> 96.9.132.83:3478
# association made in NAT tables for my.wan.ip:40044
192.168.3.2:40044<->96.9.132.83:3478 to my.wan.ip:40044<->96.9.132.83:3478
# SIP OK message with SDP packet sent to SIP server
192.168.3.2:5070 -> my.sip.server:5060
SDP: RTP, my.wan.ip, 40040 (client aware of my.wan.ip thanks to STUN)
# NAT device picks up packet, performs NAT and sends to SIP server
my.wan.ip:5070 -> my.sip.server:5060
SDP: RTP, my.wan.ip, 40040
# RTP Packets are sent to other end-point
192.168.3.2:40044 -> end.point.two:16104
# NAT device picks up packet, performs NAT and sends to other end-point
# Conflict exists for my.wan.ip:40044 as it is already "taken"
my.wan.ip:1029 -> end.point.two:16104
# association made in NAT tables for my.wan.ip:1029
192.168.3.2:40044<->end.point.two:16104 to my.wan.ip:1029<->end.point.two:16104
# RTP Packets are received from other end-point
my.wan.ip:40044<- end.point.two:16104
# Packets are dropped as there is no association in NAT tables
So the other end-point can hear me because I am sending to his correct RTP port. I can not hear him, not because he isn't sending to my correct port, because he is, but because my NAT device changed the port it wanted to receive my RTP stream on. It did this because both the STUN packets and the RTP packets wanted to use UDP port 40044 at the same time.
I have two issues with the NAPT device which I will try and take up with the vendor:
1) No reason to switch WAN port
- NAPT associations are made based on the full transaction addresses: src-ip:src-port:dst-ip:dst-port
- based on that there was no reason to change the WAN port associated with the RTP stream just because there was another UDP stream that had used that WAN UDP port since it was associated with a different destination address
- I'm not sure if this was correct NAPT behavior or not. It certainly wasn't preferred behavior
2) Support SIP
- obviously if the device was SIP aware it would have either not changed the WAN UDP port or it may have modified the SIP/SDP message for the RTP call setup
Having said that, the issue I have with the client is that there should be a more robust implementation of UDP source ports. A client can never fully predict the behavior of the NAPT device it finds itself behind and therefore could provide itself (and it's users) with a bit more protection for the underlying network and its devices.
Suggestions would include:
1) separate settings for STUN Ports
- so as not to interfer with RTP Ports
2) coordinate the rotation of the UDP ports across both STUN and RTP
- it is likely RTP will never use the same source port for some time and STUN will never use the same source port for some time
- however it appears they are unaware of the UDP port the other is selecting which leads to conflicts like this
- since it is likely that both STUN and RTP will start up and use the first port (40000 by default) available and then increment with each call, the possibility for conflicts is very high
I hope this help others who have suffered from this issue.
