Several issues with FusionPBX 4.4

[tkintenn]

1st issue, we have quite a few calls with no voice or the call drops after a few seconds. When we try to call back we get Call Release 512 on our office phones. However it is not EVERY call. I've tried to watch the logs, but I see nothing that would be an error. We're using Skytel for service. Is there an error i can look for or known bug somewhere? Our incoming number was a Google Voice number that we ported into Skytel.

2nd issue, no matter which softphone client I use, they all have issues staying connected. If i'm at the office on wifi and then leave, the registration doesn't seem to update correctly. I won't receive calls until i flush registrations and let my phone reconnect. However it will show multiple registrations for the extension.
We use a DNS registration for the domain and internally override this on the firewall. So if you're on the network it resolves to the internal IP and if you're outside the network it will resolve to the public IP. I've tried Bria Mobile and Zoiper.

Is there a setting for fusionpbx to update registrations when the IP changes? On our old ipitomy this happened pretty fast.

 

[Kenny Riley]

Dropped calls can happen for a number of reasons. I would check your firewall settings and ensure SIP ALG is disabled and that you have the proper ports opened.

I would also check your NAT settings within FusionPBX: https://docs.fusionpbx.com/en/latest/additional_information/nat.html

Finally, an output of the Freeswitch logs would help if you grab them at the time of the dropped call.

As far as your softphone woes, I feel you. I lost a customer today to Intermedia because of the constant instability of Grandstream Wave not being able to stay registered to FusionPBX and our customer missing phone calls.

We set the transmission to TCP and register expiration to 2 minutes within the GS Wave app. It would work for a an hour or so and then it would eventually lose registration to our server. You could open the app and then it would re-register just fine so basically the app was just timing out in the background of the mobile device.

I feel like there are too many variables with mobile softphones that affect reliability that we ultimately have zero control over such as the cell phone carrier, signal strength, internet connectivity when switching networks (like when you leave your WiFi network and your phone switches to your mobile LTE network), mobile device app background refresh settings, etc.

I would love to hear from someone that has figured out how to reliably offer a softphone solution to FusionPBX.

 

[tkintenn]

Dropped calls can happen for a number of reasons. I would check your firewall settings and ensure SIP ALG is disabled and that you have the proper ports opened.

I would also check your NAT settings within FusionPBX: https://docs.fusionpbx.com/en/latest/additional_information/nat.html

Finally, an output of the Freeswitch logs would help if you grab them at the time of the dropped call.

As far as your softphone woes, I feel you. I lost a customer today to Intermedia because of the constant instability of Grandstream Wave not being able to stay registered to FusionPBX and our customer missing phone calls.

We set the transmission to TCP and register expiration to 2 minutes within the GS Wave app. It would work for a an hour or so and then it would eventually lose registration to our server. You could open the app and then it would re-register just fine so basically the app was just timing out in the background of the mobile device.

I feel like there are too many variables with mobile softphones that affect reliability that we ultimately have zero control over such as the cell phone carrier, signal strength, internet connectivity when switching networks (like when you leave your WiFi network and your phone switches to your mobile LTE network), mobile device app background refresh settings, etc.

I would love to hear from someone that has figured out how to reliably offer a softphone solution to FusionPBX.

No sip alg on opnsense, but I can double check. As for ports, that wouldn't explain some calls working and some not, I'll double check that too.

I'll try to remember to grab logs the next time it happens. We've noticed it happens quite a bit with Google voice numbers calling in. Calling out seems fine.

 

[Jonathan Black]

I would love to hear from someone that has figured out how to reliably offer a softphone solution to FusionPBX.

Sorry this is way late, but we've had much better success with Groundwire than with Grandstream Wave when it comes to inbound calls. It's not free and the setup isn't as nice, because you can't use the QR setup like in Wave, but once set up, it's very solid. The way they handle inbound call notifications just seems to bypass the problem with the phone changing IP addresses.

 

[tkintenn]

Sorry this is way late, but we've had much better success with Groundwire than with Grandstream Wave when it comes to inbound calls. It's not free and the setup isn't as nice, because you can't use the QR setup like in Wave, but once set up, it's very solid. The way they handle inbound call notifications just seems to bypass the problem with the phone changing IP addresses.

not late at all. I'll happily pay for a softphone. Heck I'm already subscribed for Bria and the support is terrible. I did get the bria softphone to work inside and outside of my network, had to override dns internally for the public FQDN of the phone system and then it sorta worked. The softphone clients had issues switching DNS, even bria. Then my phone factory reset. After install of bria, it won't work now. I think it's actually a fusion issue, as I assist quite a few telcom companies with SIP based PBX's and bria the usually the softphone of choice. It always works fine.

 

[ad5ou]

I’ll second Jonathan’s pick. Groundwire has worked well for our customers on IOS and Android.

We also always suggest using follow me or call forwarding if at all possible. Soft phone works most of the time, but follow me always works as long as they have cell service

 

[tkintenn]

I’ll second Jonathan’s pick. Groundwire has worked well for our customers on IOS and Android.

We also always suggest using follow me or call forwarding if at all possible. Soft phone works most of the time, but follow me always works as long as they have cell service

I think i've found my issue but i'm not sure why. If i take my cell phone off of my wireless and use Verizon, any softphone I want to use works. If i put it back on my wireless, it doesn't work. Both firewalls are the same, opnsense (pfsense). I know the office firewall is correct, it works on cellular. So i'm not sure whats up with my home firewall. Neither firewall has SIP ALG. Nothing special in the home firewall except VPN... I'm at a loss. I can see the traffic hitting both firewalls but something is getting jacked up somewhere. Does anyone have an idea what I might be missing?

 

[Jonathan Black]

Actually, two things may need to be adjusted: A few months back, we turned on "multiple registrations". This is mentioned here in the context of SLA. While we weren't happy with how SLA works, it had the side benefit of helping with the problem of accidental multiple registrations.
However, if you are using ring groups, you need to switch them from "simultaneous" to "enterprise", or it breaks when you have multiple registrations. See here for more info.

In our LAN, we also do DNS override and it works fine. It's pretty seamless transitioning on and off that network. But that may be because of how Groundwire does its call notification, and also because of the multiple registration thing.

For inbound, @ad5ou has a point. The softphones are only going to be as good as the cell data connection, so it may work better to forward to the cell number.

One issue we've run into on some of the latest Android phones is that the softphone call notification will come in, but will not turn the screen on so the recipient can accept the call. I still don't have a solution for this one aside from forwarding.

One more note about Groundwire (and no I don't work for them)--as opposed to Bria or Zoiper, the purchase is one-time, not a subscription.

 

[tkintenn]

Actually, two things may need to be adjusted: A few months back, we turned on "multiple registrations". This is mentioned here in the context of SLA. While we weren't happy with how SLA works, it had the side benefit of helping with the problem of accidental multiple registrations.
However, if you are using ring groups, you need to switch them from "simultaneous" to "enterprise", or it breaks when you have multiple registrations. See herefor more info.

In our LAN, we also do DNS override and it works fine. It's pretty seamless transitioning on and off that network. But that may be because of how Groundwire does its call notification, and also because of the multiple registration thing.

For inbound, @ad5ou has a point. The softphones are only going to be as good as the cell data connection, so it may work better to forward to the cell number.

One issue we've run into on some of the latest Android phones is that the softphone call notification will come in, but will not turn the screen on so the recipient can accept the call. I still don't have a solution for this one aside from forwarding.

One more note about Groundwire (and no I don't work for them)--as opposed to Bria or Zoiper, the purchase is one-time, not a subscription.

It's just odd. I can see the traffic on both ends, yet it only registers when I goto cellular service. That indicates a NAT problem. Before I spend more money on softclients, I need to figure this out. Otherwise I'm all set to purchase groundwire for my company.

 

[Jonathan Black]

You have several differences that could contribute to this:
The VPN will affect it, no doubt, depending on how you have the routing set up at your office. We use an Adtran firewall with VLANs for various parts of the network, and (for example) if I am connected via VPN, I can't browse one of the web servers. This could be the issue on your home network.
If a wired deskphone works from your office network, while the softphone doesn't while on WiFi, if you can, try a WiFi deskphone. The problem could be the difference between your wired and wireless networks.
In both cases, you might even see SOME traffic, but if the routing isn't right, the softphone on WiFi may not be receiving the response back from the server.
A troubleshooting test would be to go to an off-net WiFi network (neither your office nor your home with the VPN), and try from there. If you can easily do so, turn off the VPN at home and try it. From what you describe, I don't think the problem is with FusionPBX, but rather a network routing problem.
If that doesn't work, try posting some SIP traces and maybe it will reveal something.

 

[tkintenn]

Guess I was't clear. I'm at home, with the my smartphone that has the SIP client. At the office everything works fine. Desk phone and soft client.

At home, using my wifi, sip doesn't register. It times out. However, if i turn off wifi and use cellular it does register and works great. It has to be some sort of wierd nat issue that I can't figure out. .

Both my home and my office have the same firewall, a fork of pfsense called opnsense. My home firewall doesn't have much configured except the default stuff and a VPN. The office has 5 IP's, using port forwarding for various things. All of that works fine. The only issues I'm having is from Home wifi to office pbx registering and using the phone.

this covid stuff has me working 16 hour days, so I'm tired and probably overlooking something. It's never been a big issue before but now it is because we're all working from home.

 

[DigitalDaz]

@tkintenn Use sngrep to determine if you are seeing ANY traffic from the client when using wifi and also post a log of it. Also, are you using TCP.

@Jonathan Black Your opinion is respected so I'll be getting this Groundwire today, I have never tried it

 

[ad5ou]

At home, using my wifi, sip doesn't register. It times out. However, if i turn off wifi and use cellular it does register and works great. It has to be some sort of wierd nat issue that I can't figure out. .

This is clearly a NAT issue. If you have the ability, use TLS and the problem will probably go away. TLS was the answer for all of our customers taking phones home to who know what type of network setup.

If you can't do TLS, either dig through your firewall settings for SIP ALG type settings and disable them or try using a different port number on the server. Most routers will only mess with SIP if it is on 5060, but I've seen some ISPs do some really odd filtering/mangling.

 

[Jonathan Black]

@tkintenn, Are you able to register a deskphone from your home network (either wired or WiFi)? My point in asking is to determine if this is a softphone issue, or a networking issue (either NAT or SIP ALG as @ad5ou mentioned, something with the VPN, or some other problem) that affects all phones on your home network.

If you can't check that, for some reason, I'll second the suggestions about changing the protocol to TCP or TLS or changing local port from 5060. It could make a difference. (I've had situations where there was already a phone on 5060 and the router/phone combo wasn't smart enough to remap the port to an unused one.)

If that doesn't work, post logs/sip traces as @DigitalDaz suggested.

Thanks @DigitalDaz. We've been pretty happy with Groundwire over several years, though it's not perfect. We typically tell our customers that we recommend it but we'll still support GS Wave if they want a free option. Most of our customers have taken the recommendation. As @ad5ou pointed out, the weakness of mobile softphones in general is that they're dependent on your cell data quality, we've had a few customers where it didn't work for them, but I don't think that was the fault of the app. The messaging on Groundwire is pretty good, too, if you do that. I only wish they had a desktop version.

 

[tkintenn]

No deskphone here. The softphone works fine using Verizon. It's only after I switch to my home wifi it won't register.

Ok @DigitalDaz .. not sure what to show you, i'm not a SIP guru. First one is the successful registration attempt via verizon. Second is from my home wifi. They look identical, except one is a private IP. If there's a specific part of sngrep's output that would help, let me know.

REGISTER sip:comm.domain.com SIP/2.0
Via: SIP/2.0/UDP 100.82.4.104:44115;branch=z9hG4bK-524287-1---c06fb19b521b7e28;rport
Max-Forwards: 70
Contact: <sip:102@100.44.4.104:44115;rinstance=45c62fcaf6b4f0e9>;+sip.instance="<urn:uuid:ca9c187a-7ba2-5327-84ac-900c83713211>";reg-id=1
To: "102"<sip:102@comm.domain.com>
From: "102"<sip:102@comm.domain.com>;tag=6252f047
Call-ID: 177920_rel103ZDlkNzNlOTRhOTdhYzRkYTk5YjJmNWEyZmY0NDU0NmU
CSeq: 2 REGISTER
Expires: 900
Allow: OPTIONS, INVITE, ACK, CANCEL, BYE, REFER, INFO, NOTIFY, UPDATE, PRACK, SUBSCRIBE, MESSAGE
Supported: outbound, path
User-Agent: Bria Mobile Android 6.1.1 build 117442
Authorization: Digest username="102",realm="comm.domain.com",nonce="354e0214-7f3c-11ea-af69-dbf6b0944db5",uri="sip:comm.shafertechsotions.com",response="0f59d8a47247e5791f173942849c73f5",cnonce="157d9ec496e71f682c7424a9b208a291",nc=00000001,qop=auth,algorithm=MD5
Content-Length: 0

Here is one through my home wifi:

REGISTER sip:comm.domain.com SIP/2.0
Via: SIP/2.0/UDP 192.168.2.213:45886;branch=z9hG4bK-524287-1---e990f43f8353a5fe;rport
Max-Forwards: 70
Contact: <sip:102@192.168.2.213:45886;rinstance=2fa8034f0a808d89>;+sip.instance="<urn:uuid:ca9c187a-7ba2-5327-84ac-900c83713211>";reg-id=1
To: "102"<sip:102@comm.domain.com>
From: "102"<sip:102@comm.domain.com>;tag=aec3a3a4
Call-ID: 177920_rel103ZDNmNTA4ZGQyZmQxMWM3MmI0YzBiZGQ5MWQ3YjU4NWQ
CSeq: 1 REGISTER
Expires: 900
Allow: OPTIONS, INVITE, ACK, CANCEL, BYE, REFER, INFO, NOTIFY, UPDATE, PRACK, SUBSCRIBE, MESSAGE
Supported: outbound, path
User-Agent: Bria Mobile Android 6.1.1 build 117442
Content-Length: 0

 

[DigitalDaz]

Try changing the transport to TCP as the others have said.

 

[Jonathan Black]

It looks like the request via WiFi is passing the LAN IP address. Unless you have routing set up in your firewall to pass that subnet traffic back via the VPN connection from your server, this won't work.

I strongly suspect that a desk phone on your home network would have the same problem.

 

[DigitalDaz]

It looks like the request via WiFi is passing the LAN IP address. Unless you have routing set up in your firewall to pass that subnet traffic back via the VPN connection from your server, this won't work.

I strongly suspect that a desk phone on your home network would have the same problem.

That shouldn't be a problem, especially with the rport in the via, Freeswitch should be able to handle that no problem.

 

[tkintenn]

I agree. That's where SIP ALG would help but opnsense doesn't have SIP ALG. So I'm trying to think of a work around. I'm reading that some clients will do this for you... but i can't find anywhere in groundwire or bria to change a setting that would affect this. I've already tried two public STUN servers and that didn't work for ground wire or bria.

 

[DigitalDaz]

One of mine looks no different:

REGISTER sip:some.pbx.com:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.50.157:12520;branch=z9hG4bK2425672500;rport
From: "Darren Williams" <sip:200@some.pbx.com:5060>;tag=2487214964
To: "Darren Williams" <sip:200@some.pbx.com:5060>
Call-ID: 1_2632169724@192.168.50.157
CSeq: 10820 REGISTER
Contact: <sip:200@192.168.50.157:12520;transport=TCP>
Authorization: Digest username="200", realm="some.pbx.com", nonce="d2536c12-bf10-411d-9150-2e5f72073399", uri="sip:some.pbx.com:5060", response="d747677b501f9ddafe7729c9624b63f1", algorithm=MD5, cnonce="0a4f113b", qop=auth, nc=000108

Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: Yealink SIP-T46S 66.84.0.35
Expires: 120
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 0