Grand Stream GXP2000 Phones

Hello,

I hope someone can help me, I have FreePBX up and running behind a NAT, I have multiple SNOM320 phones connecting externally to FreePBX without any issues, can make and receive call o.k. I have a SNOM M9 internally which works o.k. and some Grandstream GXP2000 internally which work ok.

My issue is that I have tried without success to connect up a SNOM M9 or Grandstream GXP2000 externally, I have taken a grandstream that works internally, reconfigured the phone to go to the external address and changed the extension to NAT Mode (Yes-force_rport, comdeia) which works for all my SNOM320 Phones just not the GXP2000 or M9.

I have taken a GXP2000 to a working external SNOM320 location and set them both up next to each other, then SNOM320 works the GXP2000 does not.

The GXP2000 shows asregistered on the phone and on the FreePBX if I do a “sip show peers” on the CLI it shows as follows.

Connected to Asterisk 13.14.0 currently running on AQ3PBX (pid = 1711)
AQ3PBX*CLI> sip show peers
Name/username Host Dyn Forcerport Comedia ACL Port Status
101/101 81.xxx.xxx.xxx D Yes Yes A 5064 UNREACHABLE
102/102 81.xxx.xxx.xxx D Yes Yes A 5060 OK (19 ms)
201/201 86.xxx.xxx.xxx D Yes Yes A 2048 OK (41 ms)
301/301 82.xxx.xxx.xxx D Yes Yes A 2048 OK (55 ms)
601/601 86.xxx.xxx.xxx D Yes Yes A 5060 UNREACHABLE

Ext 201 is SNOM 320 Ext 601 is GXP2000.

I have also tried a IPhone app for voip but it has similar issues to the GXP2000.

I think it could be some thing to do with the RTP ports but I am unsure, I don’t think it is my NAT or Firewall as the SNOM 320’s work with out issues.

Hopefully someone has seen this before and know 320s where to point me.

Many thanks in advance

Derek

Stacks of each phone are different so is worthless to compare it, if the phone shown registered then maybe it was registered for a few minutes and then it went to UNREACHABLE state.

If your NAT settings on the server side are all ok and you are 100% sure that you don’t need to check it then try to configure the GXP by, first enabling the keep alive option and if that didn’t fix the issue try enabling the STUN option too.

I am pretty sure my NAT is configured correctly otherwise my SNOM’s would not work, but I could be wrong.

My firewall redirects port 5060 tcp/udp to the ip of my freepbx
My firewall redirects ports 10000-20000 udp to the ip of my freepbx
also port 80 and 22 to freepbx

Freepbx is set under general sip settings rtp port range 10000-20000
it has my public IP address in
under chan sip settings, NAT is set to NO, bind port is 5060, over ride external IP has my public address in.

If I call from the Grandstream(ext 601) to the SNOM(ext 201) then I get one way audio, can hear on the snom but nothing on the grandstream, I cannot dial the grandstream from the snom. However snom to snom works fine which is why I think my NAT/Firewall is correct.

I have tried google and read various items but I am still struggling for an answer, hopefully someone has had this and managed to find a fix.

cheers

Derek

So basically you ignored my previous comment shrugs

Sorry my bad, should of mentioned on my grandstream I have an option for NAT Traversal(STUN) with NO, NO(but keep alive) and Yes, I have tried all 3 options and still the same.

Should of put that in my original reply

Dirk :slight_smile:

You’re behind NAT. NAT should be set to yes within Settings > Asterisk SIP Settings. If the extension you’re registering TO the PBX is ALSO behind NAT, then the extension’s NAT setting should be set to yes. Please confirm you’ve done this, and retest.

Hello,

Settings > Asterisk SIP Settings > Chan SIP Settings - NAT = YES
Extensions > Advanced - NAT Mode = Yes (force rport,comedia)

I have applied the settings and even rebooted the box, but my Grandstream still behaves the same as above.

Has anyone any more suggestions as I am really struggling with this, still cant really understand why my SNOM320’s work but not the Grandstreams.

cheers

Dirk

Because the stack of the grandstream is shitty nothing to do with your server. You need to tackle this on the gxp side not server side. Update the firmware enable keepalive, stun and any other nat settings on GXP not server.

Do I have to set a STUN server address?

on the GXP under advanced, there are options as below

Use NAT IP:
STUN Server (URI or IP:port)

Under Account there are options

NAT Traversal (Stun) No, No but send keep alive and Yes

and that’s really all I can see for NAT, I have tried all 3 settings for NAT Traversal but have not entered anything for Use NAT IP: and STUN Server as I am unsure what to enter there.

I am sure I am running latest firmware for the phone but will check.
cheers

Dirk

Please show use the actual problem. UNREACHABLE means that Asterisk sent an OPTIONS packet to the phone that was never returned. This does not necessarily mean it’s the phone’s fault. It could just as likely be the remote network’s firewall or 100 other things.
From linux shell:

asterisk -rvvvvvvvvv
sip set debug on
sip reload
<wait to see phone become unreachable>
exit

Pastebin that capture and share the link here.

Hi cullen if you read the thread He put a GXP near a SNOM in the same location, SNOM is working which means the network and firewall from the remote location is working. The GXP is not working on the same location so what’s the las variable to attack? Yeah by logic the GXP I have worked with GXP a lot and yes they have a very crappy sip stack and NAT issues are very common on it.
Why you are asking to go back on troubleshoot on the server side if the server side is working fine?
The user is not editing the GXP side and I guess he don’t know what is a STUN server or configure it since he is not editing that, so are we going to make loops for him, are we going to solve his issue because he cannot google a little or what?

Hello,

I have done sip set debug peer 601 and below is the output I get, it keeps doing the retransmitting over and over again.

Hope this makes sense.

aaa.aaa.aaa.aaa is my client side external IP
nnn.nnn,nnn.nnn is my server side external IP
192.168.1.12 is my grandstream phone local ip
192.168.0.30 is the local ip of the freepbx

Retransmitting #8 (NAT) to aaa.aaa.aaa.aaa:5060:
OPTIONS sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP nnn.nnn.nnn.nnn:5160;branch=z9hG4bK3353a443;rport
Max-Forwards: 70
From: “Unknown” sip:[email protected]:5160;tag=as7d9826f3
To: sip:[email protected]:5060;transport=udp
Contact: sip:[email protected]:5160
Call-ID: [email protected]:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-13.0.190.7(13.14.0)
Date: Mon, 10 Jul 2017 09:52:16 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


Really destroying SIP dialog ‘[email protected]:5160’ Method: OPTIONS
Reliably Transmitting (NAT) to aaa.aaa.aaa.aaa:5060:
OPTIONS sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP nnn.nnn.nnn.nnn:5160;branch=z9hG4bK7e27b593;rport
Max-Forwards: 70
From: “Unknown” sip:[email protected]:5160;tag=as1bc38a91
To: sip:[email protected]:5060;transport=udp
Contact: sip:[email protected]:5160
Call-ID: [email protected]:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-13.0.190.7(13.14.0)
Date: Mon, 10 Jul 2017 09:52:34 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


Retransmitting #1 (NAT) to aaa.aaa.aaa.aaa:5060:
OPTIONS sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP nnn.nnn.nnn.nnn:5160;branch=z9hG4bK7e27b593;rport
Max-Forwards: 70
From: “Unknown” sip:[email protected]:5160;tag=as1bc38a91
To: sip:[email protected]:5060;transport=udp
Contact: sip:[email protected]:5160
Call-ID: [email protected]:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-13.0.190.7(13.14.0)
Date: Mon, 10 Jul 2017 09:52:34 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

Like I have repeated here over and over again its not your server’s fault. The sip debug is useless in this case, You will see the same output always. If you and cullen understand how SIP works you then will notice something important, Who stop the communication with who??

Sip is a handshake protocol or ack based protocol. If your server or your agent start the communication it will expect a response from the far end. In this case the server start the communication to “qualify” your peer by sending OPTIONS sip message, it expect a response from the remoter agent. If not receive any response it start re-transmitting the OPTION package until it FAIL and STOP.

In this case you need a network trace from both sides, to catch the moment when the last “ACK” was received from your agent, so do a network capture not a sip debug(actually the network trace will contain the sip debug) on both sides. And match the hours when your server send the first OPTIONS without ACK received. And start from there.

Since your Snom works perfeclty from the same location try to swap accounts between phones, or add the second account in the SNOM and check. If your grandstream still failing burn it!! :smiley: Nah just play with the nat settings and check in your router to disable ALG and SPI options just to help a little the crappy stack of GXP.

This is incorrect. Much like HTTP it uses a request/response transaction model. It will send a request and respect a certain type of response for that request. In this case of a “Keep-Alive” OPTIONs request, Asterisk is sending the OPTION and it expects a “200 OK” reply from destination in 2 second or under. If it doesn’t get a reply in that time for whatever reason it will re-transmit the request. Asterisk does not ACK 200 OKs for OPTIONS (nor is it required).

So if someone knows SIP they know that there is no ACK involved in a Keep-Alive OPTIONS transaction. They would also know that it is a request/response transaction model and not a “handsake and ACK” model. Your are leading him down the wrong path based on incorrect knowledge of how SIP works.

If the phone keeps going UNREACHABLE then this is a NAT issue. It could be related to the PBX’s NAT and local_net settings, it could be related to the NAT settings for the remote locations network. Just because one phone doesn’t have an issue doesn’t mean it is not NAT in this scenario. Sub-par routers have been know to lose their mind when keep NAT-holes open when there are 1) a high amount of devices NATing out or 2) In the case of SIP phones, they are all listening on their own IP but they may all be listening on the same port (5060) which a lot of phones do by default. The router could be having issues keeping multiple IPs listening on the same port straight.

So first thing is to make sure that the PBX and the extension peer settings are correctly setup for the fact both the PBX and the endpoint are being NAT. The next thing is to look at the local network where the phones are at.

@Aquila, follow @cullenl’s advice and join us on IRC. We can probably resolve this pretty quickly with you.

1 Like

double Facepalm Ok let’s get cocky, I was speaking in a way that the user understand how it works. Not actually saying you will receive an ACK and yes SIP is based on that model but I can see you need exactly the name of each transaction.

No I’m not, again you are so pretentious let me go back with my mentors and the opensips course to tell them that we are wrong because you need the exact name of each transaction and more important we do not understand sip protocol because we think that is based in handshakes-responses-acks. Outrageous :grin:

Did you read the thread? Did you saw the settings or you are only here to pretend?

Why in the IRC, the others don’t deserve to see your skills, magic, expertise and have an answer for future use here?

And one more thing Mr SIP expert tell me what do you expect with the sip debug to see if you already know how exactly it works the OPTIONS sip message? I need to write it down so in my next course I can point to that as well…

And just a FYI: I also have access to the IRC :stuck_out_tongue:

WTF who is fighting… Geez what’s going on with the community recently? Someone says no or something and suddenly all become such a girls and start saying “I don’t want to fight with anyone”.

But yeah let’s rant on Twitter about Ward, about users but here be scared and angry for disagreement on how to troubleshoot…

C’mon guys this was a good community what the hell happened.

Ban me if that offends you. But don’t permit the community to convert in a hypocrite community just because someone is not agree with you.

“Fighting”… Geez the kids this days need hungry in their lifes…

Walks away

As others said, server not the issue, your Asterisk settings and router settings look fine.

On your Grandstream phone check the following.

Accounts > Account # > Network Settings > Nat Traversal = AUTO

On all my Grandstream 2xxx phones this defaults to NO and must be enabled per account.