FreePBX Extension Attached to ALGO 8301 Paging server - Dead Air from 3:30 - 3:32pm

I have a weird issue that just cropped up. From my Centralized FreePBX server on my WAN (School Division), We have 28 schools, mostly a flat network, that is divided up into Subnet Octets per site on a /16 network. Example Site 1 - 10.75.XX.XX/16 Site 2 - 10.77.XX.XX/16 (Just giving you an idea of the topology). My endpoints are marked to give some priority to DSCP 26 and 46. This had worked great from day 1, and I’ve never had FreePBX or call quality issues, and I still do not. However, we use an RTP-based intercom system that uses an ALGO 8301 as its paging server. There is an extension for it on the FreePBX server, and the ALGO is registered to that. It was working perfectly 100% of the time, for about 2 years.

For the past 2 weeks, a weird new problem is occurring. Between 3:30 to 3:32 MST time (sometimes a little less), the ALGO 8301 cannot be called. When the paging Extension is called, they just get Dead AIR for about 1 - 2 mins. At first, I thought maybe there was a power bump happening, and or maybe something was disrupting the paging server. So for the last 2 days, we have been observing, from a network perspective, and observing the environment at 3:30 - 3:32. Sure enough no pages can be made at this time, Now here is the weird thing. I ran a constant ping to the:

  • Paging Server (ALGO 8301)
  • The VOIP POE Switches Swtiches (All POE+)
  • The VOIP Phones (GrandStream 2170 and Grand Stream 1630)
  • The network Edge device

I also had a tech on the site for observation. There was NO Network Disruption that occurred for the whole period of time. Pings were perfect and latency was perfect to all devices IE:

  • Paging Server (ALGO 8301)
  • The VOIP POE Switches Switches (All POE+)
  • The VOIP Phones (GrandStream 2170 and Grand Stream 1630)
  • The network Edge device

No disruption at all, we could constantly ping all devices internally and Externally over the WAN, I made sure all devices could ping to the centralized FreePBX server the whole time as well. But sure enough, ALL the devices were pinging each other internally and externally the whole time, the DEAD AIR to the ALGO 8301 still occurred. I could watch pages happen on the ALGO 8301 web interface up until 3:30, but for those 2 mins, it would not answer pages, Yet All devices above were still able to ping each other including the paging server, with no disruption to the WAN or the internet. As well there were no power issues and no disruptions from the environment. Even weirder, they can make VOIP calls during this period, so they are NOT losing any sort of SIP connectivity to the FreePBX server.

Since it doesn’t seem to be a Network connectivity issue, I thought about running a packet capture test Against one of the VOIP phones with Wireshark. (Divert the traffic to Wireshark). What command would I use from the command line on the FreePBX server to Isolate the paging extension and observe it in real-time during this period of time? I want to see if anything weird is happening with the extension. But yes they can make calls while the ALGO extension cannot be paged, but appears to be fully functional.

Does anyone have any other ideas to problem-solve the dead air issue at 3:30 - 3:32 pm when calling the 8301 and or to isolate the issue further? Even though I don’t see any Network issues on the ALGO 8301, I thought about upgrading its firmware…which seems odd to have to do when it’s been working fine for 2 years up until now.

Is there a command to isolate one extension and call trace it in real time or something close to that? I may have to do this. Hmm maybe this will do:

What is the best way to filter the logs on the FreePBX from the period of 15:30 0 15:33, to see if there is any weird behavior in calling at this period in time?

cat logfile|egrep ‘15:3[1-3,0]’

Thank-you @dicko. I also Manually dug through the Asterisk full logs for this time period and analyzed them…I don’t see anything weird for the time period 15:30-15:33…I will have to explore this more externally.

tshark/wireshark would be better tools

Yes, that’s the next on my checklist, do a packet trace.

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