GRP2616 No microphone level

#1

A brand new phone GRP2616 arrived with no mic audio. very occasionally it will spring to life. We currently have GXP2170s in the network with no issues. 'When you perform a loopback audio test on the phone.
it passes and all audio paths produce audio.

This would seem to rule out the hardware. Also if you press any DTMF key that tone is not heard at the other end. So it appears the whole outgoing audio path is down.

My local provider seems stumped on what to do next. One may assume all ports are open on the router as all the GXP2170’s pass audio ok
Here are the ranges used given to me by my provider
IP RANGES

Range Start Range End
from 5.22.140.128 to 5.22.140.159
from 185.59.180.64 to 185.59.180.128
from 185.59.180.48 to 185.59.180.63
from 212.126.39.1 to 212.126.39.31
from 185.112.244.0 to 185.112.247.255
from 185.118.228.0 to 185.118.231.255

ports 5060 and 8060
ports 10000 to 20000 for audio
ports 8061 to 8300 for the local range via udp
Thank you all in advance

#2

What hosted pbx is involved?

That would indicate the rtp stream is breaking ports 10000 to 20000.

#3

The questions arise as:

  1. To what DTMF key is pushed and what is the destination used to “hear” the tone?
  2. What firmware version is on the phones?
  3. How many phones in total are behind the same router?
  4. How does one define open on the router?
  5. What is the transport type and the ranges above associated to RTP * SIP.

The reasons for the questions -

  1. When using the phones and pressing a key such as the number keypad, a tone may not be sent. It may be a SIP message as a telephone event in the SDP rather than as a tone. If tones are to be sent, then the DTMF setting would be in-band which then the tone would be sent as the normal audio tone. Obviously, the tone being seen/heard at the destination needs to correlate to what the destination needs to see in order to accommodate the key push, so a conversion of the tone from the RFC to inband-audio may occur.

  2. The later firmware versions all contain added SIP headers and info that may cause the packet seen by the provided to be fragmented. How they will respond to the fragment is anyone’s guess. The maximum MTU is 1500 and if you have not limited the codec selection in the phone and unchecked some of the added headers, then there is an excellent chance that the INVITE with the nonce is fragmented and it is this packet that the provider needs to see intact. A simple network capture should reveal this at the provider end.

  3. & 4. While understanding the ports needed by both sides is a good thing, the question arises as to how these ports are used? Open is one thing and forwarded is another, but the terminology of how used may depend on the router manufacturer. To be clear, when the phone initiates an INVITE, it knows how to reach the provider based upon what you have input in the trunk settings. The phone knows or is able to determine the provider IP and port for SIP and in the INVITE to the provider for an outbound call or in the 200OK SDP in response to an inbound call, will tell the provider what IP and port it wants the provider to respond back to phone for both SIP and the RTP stream. As we are not aware of who or how the phones were provisioned, we do not know that the phones are programmed in such a way so as to assist the router in keeping the NAT and PAT tables clean. All the phones will send to the provider using the same IP and port, but the provider, in the response, will use a reply back to the same IP (your public on the router), but a different port for each phone. The RTP streams going out may use a different IP and port to the provider, but coming back, the streams will all use the same IP, but again different ports. Open ports means a 1:1 NAT whereby the phone will send from say port 5060 and the router will maintain the port 5060 as it sends out. In this manner, the port seen by the provider will be 5060 and the SIP messaging will also be 5060. Forwarding is where external traffic is directed to a given internal resource. So, if we assume that you have 10 phones and all have a local SIP port of 5060, then the router will have to use ephemeral ports so that phone 1 is seen at 5060, but the router will assign and use a random port by which to relay to the provider. Phone 2 will do the same with 5060, but the router will assign a different random port. The router will maintain this mapping so that, hopefully, when a response is seen, the provider will send back to random port 1 for phone 1 and random port 2 for phone 2 and so on.

Ideally, each phone behind the same NAT would have a unique local SIP port assigned as well as a unique local RTP port range. Nothing would overlap ranges or duplicate ports. In essence, each phone is unique. In this manner the router is likely more easily able to manage the traffic and if open ports can be used an forwarded, then even better. The reason for this is that tis better to have the messaging agree with what is physically seen by the provider.

  1. You defined what IPs and ranges the provider will use, but not their association to one another. I suspect some of the IPs are associated to SIP while others are RTP. This opens the question as to how set in the router and if there are any issues with how set.

At the moment, I suspect packet fragmentation. If possible, get into a single GRP and make all the codecs the same using g711a/PCMA and then disable all the supplemental headers in the SIP messaging such as Network Info header and emergency-info header. Enable accept SIP messaging from SIP proxy only and then try.