PJSIP Remote Extension Oneway Traffic Followup x2

Gosh it’s really annoying sometimes that these forums automatically close topics, especially with something like this where it might take some time until the next update can be made or if someone wants to post a followup if they have ideas…

Attached here is the output from CLI Logger https://pastebin.freepbx.org/view/25131fa2

Attached here is the one successful attempt that showed up in the CLI https://pastebin.freepbx.org/view/a263ae0c

However it then almost immediately goes back to offline

Anywho appreciate the help from the other topics; please see the following for the history


So we’re back and I’m literally going to loose my Sh… because this is driving me nuts.

So per the previous threads I’ve since updated an SPA to the latest firmware, which the other sites are running no issue. It was thought perhaps there was an issue with the firmware on one of the other adapters as it was running an older version. So the unit I still had for testing I made sure was running the latest.

Once again I ran tests with the SPA once configured I tested it from our testing network at the office, I tested it over a ATT LTE Data Converter, I tested it from my home over a Cox Connection.

Gave it to the client… which finally a month later decided to plug it in. So naturally I asked a few times if they had a chance to plug it in and you know how that goes you don’t get a response until finally one day who knows when they decide to plug it in finally… so I got that email today and I go to check with my fingers crossed hoping just maybe it will work at their site!

Sure enough, same ol same ol. FreePBX Asterisk Info shows that it’s Unavailable just like the previous times it screwed up…

It does show the WAN IP address of the site, so it clearly tried to connect or had connected for a moment, but once again using SNGREP all it shows is constantly Options Request being sent TO the remote site.

(24.) is the WAN IP of the remote site
(45.) is the WAN IP of the FreePBX Server Site

I feel like there’s got to be something insanely simple that’s being missed as I’ve literally spend countless hours wasted on unbillable time trying to figure this out. I would say it seems “site specific” however as mentioned in the other thread an adapter also went to another site that has the same setup as I with Cox internet and they’re just using the cox modem as the router and it also exhibited the same issue.

The site this is at now has a Google WiFi Router. All the other SPAs ive setup on both this system and a dozen others continue to work no problem.

If you have any recommendations on what I could change or experiences with the Google Wifi Router that would be great, although at one point I did completely bypass their google wifi router and connect directly to their cable modem and still had issues.

So what it seems we’re looking for is why on earth the box constantly sends the requests to the WAN IP of the remote site but doesn’t seem to receive a response / successfully register. On occasion it will but it’s very rare.

Supposedly calls can sometimes be made going out (as we found out the hard way when a 911 call was made) and it lasted for 10 min.

In this case it does not look like it’s putting the LAN IP of the adapter in the contact as it occasionally did last time, so it does not seem that’s the issue?

– Contact 425/sip:[email protected]:5060;x-ast-orig-host=192.168.0.21:5060 is now Unreachable. RTT: 0.000 msec

You have NAT issues at the remote side that doesn’t respond to the keep-alives the PBX is sending. So the endpoint goes unreachable until it registers again or replies to the keep-alives.

This occurs both while;

  1. connected directly to the cable modem
  2. connected through the google WiFi router
  3. at another site with a different ISP also connected directly to the cable modem

So my question would be though as I agree this seems to have to be a site side issue, so what setting adjustment could be made specifically on the google WiFi router?

The biggest problem is going to be if the answer is (don’t use the google router and use something else) they’re going to say well that’s not the problem because it didn’t work at the other site! Even though we have a ton of them working at other locations.

So if it seems to be a NAT issue what settings do you recommend I look to adjust?

So I’ve been unable to find anything related to the Google WiFi Router that would lend some assistance. But if anyone has suggestions for settings to modify if it seems that it’s a NAT issue where its not responding

So it seems a possible fix would be to increase the UDP Session Timeouts, however I am not aware if there is a way to do this on the Google Wifi Router, (Sonicwall and other business ones naturally have documentation on it).

Or perhaps something I could modify on the SPA

Is anyone familiar with the google WiFi router? I’ve posted over at their community forms to see if it’s possibly to modify those settings. As I’ve found instructions for most other brands but nothing on the google one.

Would it though be correct to think increasing the UDP session timeout on the router would help?

This help article seems to be the exact issue we’re having

https://support.goto.com/jive/help/what-are-the-recommended-nat-keep-alive-settings-jive-recommended-nat-keep-alive-settings

So since I’ve been unable to get feedback on either googles end if this setting can be modified on their router.

I did change ICE Support to Enabled and changed RTP Symetric to NO (by default it is yes)

That seems to have helped with the issue as now more often than not the extension is staying registered, so now ill see a number of successful back and forth with it sending the packet and getting an ok, but every so often it’ll stall for about a minute sending requests and not getting anything.

So mostly posting this so other people can have some solutions if they come across this problem.

Also want to ask though based on making those changes and being that the registration is staying up for longer, does this further lend it to some to be a NAT keep alive issue?

I still have no confirmation on what settings I can change on the google, as it needs to be managed via a phone so I can’t remote in and modify for the customer and from what I’ve been able to go over that is accessible on the phone it’s very limited.

Would modifying the time on the SPA adapter from 3600 to lower possibly help? I’m just trying to make sure I’ve got as much info as I can if I need to go on site or remote in and get it done.

If the SPA setting of 3600 is for the registration interval/expiration, decreasing that should help. I’d try a setting like 120, assuming it’s seconds. Usually you can verify that this is a problem if a reboot of the SPA always gets things working again, and the problem comes back after some time. Or if you don’t have anyone onsite that can force a reboot, you can try monitoring packets from the SPA, and wait for the next registration to see if things start working after that until they stop again.

1 Like

Yes what seems to happen is it’ll come up initially then go offline for extended periods, sometimes it would come back on sporadically. However outbound calling always seems to work, it’s just the inbound it becomes unavailable as an endpoint. Changing the ICE and RTP setting helped it become available more consistently but it still drops out and stops responding to requests for a period. Then it’ll come back, so I’ll try adjusting the 3600 for registration expiration and see if that helps also

Thanks!

You can set the registration expiration to 120 seconds and also enable keepalive on the SPA to 30 seconds. This should keep it registered and available. I have set my SPAs like that on installations where the router seems to close the connection too quickly and has no way of modifying the session timers.

2 Likes

Fantastic thanks I will give that a try, at the very least I can remote in and access the SPA config page so that’s what I was hoping to hear

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.