Wifi phones loosing registration


#1

Hello All,

I have a situation where when you first turn on a wifi phone it registers, everything works great, and at some point the phone is no longer registered.
The issue is when a call comes in the phone won’t get the invite since it’s not registered, if you power cycle the whole thing goes through the same process.
Are there any additional criteria I need to add to the device in order to maintain it’s connection?

Using current FreePBX & EPM.
I have the grandstream WP810, but utilizing grandstream WP715 as a template.

Thanks


(Greg Kujawa) #2

Are the phones moving around a fair amount? Personally I’ve run into lots of WiFi issues in terms of RSSI variances when they move too far from the access point or router. Larger facilities I manage required installing a more robust mesh WiFi network using Orbi Pro Business and the like.


#3

Phones are basically on the charging stand and we have solid coverage everywhere.


(Greg Kujawa) #4

Firmware updated? https://firmware.grandstream.com/Release_Note_WP810_1.0.7.83.pdf


#5

Yes, I have those working with the .77 flawless and the .83 as well… just this environment isn’t working.
Using same routers/AP’s as other locations as well, so kind of stuck figuring out why the phone looses registration and then inbound calls don’t get to invite since they aren’t registered.
If you dial out, works like a champ.


#6

bump… anyone


(Greg Kujawa) #7

So the site that has this issue…is the FreePBX on the same LAN, or is it remote? If it’s remote then perhaps looking at the firewall/router logs around the time of the registration loss might shed some light.


#8

When the failure occurs, do the phones still respond to ping? If not, it’s a phone or networking problem unrelated to FreePBX.

If ping is still working, are attempted registrations coming in? If not, the phone’s syslog may show what’s wrong.

If registrations are coming in, does anything get logged by Asterisk for the attempts? If not, it’s likely a firewall issue. If yes, what does the log show?


#9

In respect to local/remote the phones are remote. So an office LAN, and then Cloud PBX.

A ping wouldn’t be possible because of this fact, and unfortunately nothing good in firewall related logs.


#10

Why are you being so negative?

When the failure occurs, do the phones still respond to ping issued from a host on the office LAN?

You can tell this with pjsip logger (or sip debug if you are using chan_sip), sngrep, tcpdump or similar tools.

If not, see what the phone’s syslog shows.


#11

I would also point out that there is nothing in VOIP connections that use ICMP , so pinging is not particularly diagnostic.Watching packet flow is far more productive :slight_smile:

So listen to @Stewart1 here . . .


(Yois) #12

@VoIPTek - Is the router a SonicWALL?


#13

Good point. In fact, for any router/firewall that randomizes source port numbers, if the NAT connection is somehow lost, re-registration might be rejected by pjsip if Max Contacts is set to 1.

@VoIPTek please check the Asterisk log to see when the device becomes UnReachable (whether it’s the result of a qualify failing, or caused by registration expiry).

Things to try: Shorter expiry, e.g. 120 seconds (this eats battery, but the 120 hours standby time is probably way longer than you need). Shorter qualify interval and/or longer qualify timeout. Keep-alive from phone. Setting the firewall to preserve source port numbers (this requires setting a unique local SIP port on each phone behind the same NAT). Increasing the UDP timeout in the firewall.

However, I don’t recommend taking potshots at the above; it’s better to first understand what is going wrong.


(Ted Mittelstaedt) #14

Do you even have a NAT in between the FreePBX and the phones? I did not think so.

I have run into stuff like this during rather extensive testing with dd-wrt. (documented elsewhere and it’s very long)

If your phones allow it try changing the SIP transport from UDP to TCP. I am betting you are running into a retransmit issue. Wifi access points today are smart enough to transmit a packet and if the wifi link damages or corrupts the packet, to retransmit it again - except they don’t need to do that with UDP packets - since UDP packets by definition are not guaranteed delivery. So they may not.

The problem with SIP implementations in my opinion is that the designers of phones assume virtually perfect transmission and reception of UDP packets because they were thinking “well the phones are going to be sitting on a gigabit LAN…” Some phones are fine with retransmission of missing UDP packets. Some are not. By default most phones have UDP transport selected for SIP.


#15

Hello All,

Let me review each of these, a lot of info.
Part of my issue is I technically don’t have access to the local LAN where the wifi phones reside.
I do see the phones becoming unregistered, but usually they re-register in a normal environment, here I’m not seeing that.
I will dig through these details and post back.
Thanks to all!