WP820 -One Sided Calling Issues


We use our WP820s on our manufacturing floor. We have a Wi-Fi mesh network that is directly connected to our TPx Communications network (our VOIP phone carrier). We have sporadic one side calling issues where only one party can hear. The call back and everything will be fine. We have Polycom desktop phones which do not have this issue. Only the WP820s. TPx level 3 engineers have look at this and everything is fine on their side of things. They do not officially support the WP820s. We used to use the DP750 & 720s, but they did not have the range we needed. We have excellent Wi-Fi building coverage averaging 90-100% signal strength.

Anyone have any thoughts?


Check to make sure that the RTP range matches that of your firewall tables and Voice ISP. Maybe you have an issue there.

I take it this is in a pure hosted solution no on premise IP PBX?


We have a cloud based IP PBX. Internally, we have a mesh wireless network that connects through a VLAN directly into our carriers router. Traffic does not hit our network or firewalls. TPx Communications says everything on their side looks good.


It is their job to say that nothing is wrong on their side and for you to prove is…
You need to use wireshark for voice calls and verify what is the problem.

Have you checked the RTP settings from the TPx Comms guys to your WP820 handsets?

At default the rtp stream is set as:
Local RTP PortDefines local RTP port used to listen and transmit RTP packets. Valid range is 50040 –65000. Default is 50040


Thanks, I will follow-up with TPx. Unfortunately we do not have direct access to their network.


This was TPx’s reply:

Our servers use the following RTP Ports:

UDP (RTP) 2222 - 2300
UDP (RTP) 13384 - 65535

These settings are system level settings on our Session Boarder Controllers. The examples we looked at all fell in the upper range, if possible I would set the WP820 to use the 13384 – 65535 range.

QUESTION: Is their a way to set the WP820 to use the 13384 – 65535 range?



phone settings --> basic settings --> local rtp port


You need to clarify -

There is a reported SBC which I assume to be on-site. If this is correct and the SIP server settings in the phones are pointing to the SBC which is in the same LAN, then a firewall is not involved.

While you can set the RTP port to something different, the issue is that each side (provider and phone) will use their own ports. The INVITE from either end will tell the other end what IP and port to use for audio.

Changing the local RTP ports will only tell the provider what ports to use when sending audio to the WP, no different (than the port itself) than what it is already doing (5004?). The provider also tells the phones, including the WPs, what port(s) they want the phones to use.

You did not mention if the issue is on outbound, inbound or both and which side hears and which side does not.

Are the WP phones on the same LAN subnet as the SBC?



He mentioned that the provider handles the SBC so he has no way of altering what they do apart from changing the RTP stream ports - audio settings to match what they are expecting.

He really needs to do a wireshark on 2 x calls - successful and not succesful to be able to compare, but I am not sure he has the technical support to do it.


I never suggested he could or should change anything. In fact, I suggested that a change to RTP ports will do nothing other than what is already occurring; albeit to a different WP port.

Your post with the link is only setting the local port on the WP which the WP will use in its messaging to the SBC and will then subsequently expect the SBC to communicate with the WP using the port set. It has nothing to do with what the provider will expect for its incoming.

I agree a wireshark would possibly show more of the issue, and it would really help to know which side is not able to hear and if the WPs are running the latest release of firmware.


point 1 customer who is writing here is looking for answers to the problem and doesnt know where to start
point 2 customer only has control of the handset configurations
point 3 TPx Communications network provide the session border controller, voice ip pbx and internet for the phones

i wasnt asking for you to agree or disagree to anything ive written in trying to help Eric…


my answering was in relation to this statement.


Eric you need to perform packet capturing of calls using wireshark. If it is an SBC/Firewall/Nat/RTP/Firmware issue this will show up comparing a good call against a bad call.