Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

Client one-way voice issues - STUN src port mimics RTP port

Discussion in 'Windows' started by BobbyBooey, Mar 11, 2011.

Thread Status:
Not open for further replies.
  1. BobbyBooey

    Mar 11, 2011
    Likes Received:
    This is an FYI for users having one-way voice issues when behind NAT and connecting to an external server. It can also be considered a feature request for 3CX VoIP Phone (I will be posting on the Feature Request web page). This will likely benefit many 3CX users include ones with the phone system who have external 3CX clients behind (questionable) NAT devices and may have suffered one-way voice.

    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

    - 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 ->
    # NAT device picks up packet, performs NAT and sends to STUN server
    my.wan.ip:40044 ->
    # association made in NAT tables for my.wan.ip:40044<-> to my.wan.ip:40044<->
    # SIP OK message with SDP packet sent to SIP server -> 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 -> 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<->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 :cry:
    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.
  2. SY

    SY Well-Known Member
    3CX Support

    Jan 26, 2007
    Likes Received:
    Re: Client one-way voice issues - STUN src port mimics RTP p

    Sorry, but it is symmetric type of the NAT and "STUN server" is completely useless in this environment...

    P.S. You can configure your SIP server to apply a workaround for this situation
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. BobbyBooey

    Mar 11, 2011
    Likes Received:
    Re: Client one-way voice issues - STUN src port mimics RTP p

    Can you elaborate on both points?
Thread Status:
Not open for further replies.