GXP2170 Will Not Register SIP Accounts


I’ve got a GXP2170 phone that does not appear to be attempting to register any configured SIP accounts. There are three other GXP2170s on this network that work perfectly.

As you can see in the attached image, the ‘SIP Registration’ fields show as ‘UNKNOWN’ rather than ‘YES’ or ‘NO’ as I see on the other phones. The ‘SIP Server’ field is blank, despite the servers being configured under each account.

A packet capture shows no SIP traffic from the phone at all, but there is the usual internet traffic there to grandstream.com, etc., which indicates that the phone does have network access.

The firmware version is currently, but this issue was occurring on 1.0.6 - 1.0.9 as well as I upgraded it to 1.0.11.

I have tried factory resetting the phone through the web UI, but it just appears to reboot with no change in configuration.

Any suggestions?


Hard to say without seeing the account settings page. If the SIP server field is blank, then yes it will be unknown.

Look on the status page and then under system info and look at the user space and see if anything in red in that area.


Thanks for your help.

User Space Used is at 7%, Database Status is Normal.

Here’s what the settings for Account 2 look like. I’ve tried filling in the server with the host name and the IP address with no change.


Is the phone remote to the SIP servers?


The phone is remote to the SIP servers. There are three other phones of the same model that are able to register without issue.


And all three are behind the same router? And are you using a VPN to reach the other SIp servers and do you have a static or dynamic public IP?


All behind the same router, no VPN in play. Public IP is static.

For example, account 2 is just a quick test I created with my VOIP.ms account to see if that would register.


I get it that other phones of the same make and model work. However, that doesn’t necessarily mean much in the scheme of things.

When you remote phones, which was not mentioned, there are other aspects that come into play.

Are you port forwarding, my guess is no.?


When running devices behind a firewall that communicate to remote devices, there may be issues that arise as a result of router inabilities to maintain NAT and PAT tables correctly.

When multiple devices are NAT’ed, when they reach the remote device, the IP seen from all three devices appears to be the same. This IP, should be the public IP of the router which passed the data stream from the phone to the remote device.

When the remote device responds, the response will be sent to the public IP of the router and the router should pass the response back to the phone(s) that made the initial request that elicited the response.

If the phones are using the default ports, then the ports in use are 5060 UDP and 5004 UDP for all phones. So, when the response is seen at the router, the response for any phone will appear to be applicable to any/all of the phones as they are all identical. As a result, it may be difficult for the router to identify the target phone and the message intended for phone A, may accidentally be sent to phone B or C. This is more apt to happen when using a UDP transport rather than TCP.

Some routers are better at handling this than others, but there is no way to know which ones beforehand.

To eliminate the issue, you need some way to make each phone unique from one another.

  1. In each phone there is a setting for local SIP port for each account. If you look at account 1, it will be 5060, account 2 will be 5062 and account 3 will be 5064 and so on. Each account in each phone needs to be unique. So while phone 1 is using 5060, 5062, 5064, you should disable the unused accounts and then make phone 2, use 5066, 5068 and 5070 and disable the unused accounts and then repeat on phone 3 by using 5072, 5074 and 5076 and disable any unused accounts. The key is to make each account on each phone use a different SIP port, The local SIP port is what the remote device will be told to use when responding back.

  2. As you have a static Public IP where the phone are located There is a field called “Use NAT IP” in the phone where you can enter your public IP. This will be sent to the remote device so the remote device will know to what IP all messaging should be sent/returned. If this is not set or STUN is not enabled the phone not knowing what the public IP is will tell the remote phone to use the phone’s private IP. STUN is used to determine the public IP, but as you have a static and know it, then STUN is not needed.

  1. As the RTP ports may be the same in all 3 phones, the range should also be changed to something unique and not overlapping. You should lower the port range to 50 and then alter each so that phone one uses 5004 to 5054, phone 2 from 6004 to 6054 and phone 3 from 7004 to 7054. You can pick any range you wish, but do not overlap and do not duplicate any of the ports that you set for SIP in step 1 above. Do not enable random ports.

  2. In each account under SIP settings, basic there is the following:

Set it up as shown. As it seems that port forwarding was not possible before, we need a way to keep the router ports open and available so that should the SIP providers try and deliver a call the firewall will allow the message to reach the phones. The SIP options keep-alive will do this by sending a message every 30 seconds. This needs to be set in each active account as well. As a remote phone, you will note that I have lowered the registration period from the default 60 minutes to 2. YOu may want to increase to 4 or 5, but the intent is that should something cause the network between the phone and provider to become unavailable, then you want both sides to know this sooner rather than later.

Set up the problematic phone first in this manner making sure that the ports are unique and the NAT IP populated and the keep-alive enabled and see if this helps.