Account invalid and "something about a tunnel"

Status
Not open for further replies.

OCWI

Platinum Partner
Advanced Certified
Joined
Jan 17, 2017
Messages
166
Reaction score
57
We have many users this morning (9am CST) complaining of their phones being down showing account invalid and "something about a tunnel". All of our PBX's are hosted on latest version. All on rasp pi 3's.

Any one else having this? Its accross many pbx's/phones.
 
The "Pi" can not run 3cx - so perhaps the Pi is your SBC?

The exact message would be helpful here. Any information in the logs? What about the Dashboard - Are all services running - esp. the Tunneling Proxy?
 
You're running the PBX on Rpi 3's or just the SBC's?

A few details would be good:

On site hosting of PBX or Cloud-hosted PBX with rPi 3 SBC's?
How many phones at each site?
Has there been a power cycle (power interruption)?
 
You're running the PBX on Rpi 3's or just the SBC's?

A few details would be good:

On site hosting of PBX or Cloud-hosted PBX with rPi 3 SBC's?
How many phones at each site?
Has there been a power cycle (power interruption)?

Ooh - and did someone unplug the Pi3 if its the SBC?
 
My mistake, was typing in a rush. Correct the pi is the sbc.

The only thing we can find in common is they all seem to display alot of these, but some working ones do too so im not sure if its related:

11/21/2017 10:52:44 AM - Exception: SipMessage::Exception Missing header Contact @ SipMessage.cxx:1393

We havnt actually seen the symptom in person yet, only the flood of tickets from our customers. They say the phone it self says no service and something about a tunnel. We are used to the no service drill - but never seen it actually mention a tunnel.

All are yealink phones (thats all we use) provisioned via pnp over the sbc
 
sounds like maybe the ethernet link went down somewhere between remote to pbx... the SBC went offline, then didn't recover properly on its own.
 
ya thats about the only explanation we could think of too.

Just odd that it happened at the same time between dozens of sites all with different isps.
 
ahh - many PBX's - strange indeed.
 
yes , that seems to be what is fixing it a reboot. So far any way

The rPi is a nice SBC but you need to realize that there is a slight 'cost' to the low acquisition price - the ARM processor, while it works, is still pretty slow in comparison to an Intel core i3. If you're running more than a 'few' nodes at each site, you may want to consider using something like an i3 or i5 - especially if you have a lot of BLF's in use at each extension.

When an rPi SBC reboots, one of the common complaints is that the 3cxsbc service is trying to start before the system is ready to actually allow it. There's a thread HERE about this, and a workaround, so to speak, that seems to work.
 
right! At least a pi reboot is doing the trick, we are just worried there is something else bigger going on that is going to come back up. too many for it to be a coincidence, those errors are the only common denominate that we can identify so far.

We appreciate the replies.
 
you say PBX's are up to date - what about the SBC?
 
The rPi is a nice SBC but you need to realize that there is a slight 'cost' to the low acquisition price - the ARM processor, while it works, is still pretty slow in comparison to an Intel core i3. If you're running more than a 'few' nodes at each site, you may want to consider using something like an i3 or i5 - especially if you have a lot of BLF's in use at each extension.

When an rPi SBC reboots, one of the common complaints is that the 3cxsbc service is trying to start before the system is ready to actually allow it. There's a thread HERE about this, and a workaround, so to speak, that seems to work.


I appreciate the reply but we have a very significant amount of pi 3's in the field with perfect reliability. The thread you are linking is referring to an issue that was (successfully) corrected in last release.
 
I appreciate the reply but we have a very significant amount of pi 3's in the field with perfect reliability. The thread you are linking is referring to an issue that was (successfully) corrected in last release.

If recycling the power is fixing the issue for you, then keep at it. Write yourself a script that reboots the rPi once a day or week when usage allows for it and you're golden. Probably.
 
  • Like
Reactions: craigreilly
If recycling the power is fixing the issue for you, then keep at it. Write yourself a script that reboots the rPi once a day or week when usage allows for it and you're golden. Probably.


Thank you for the reply!
 
Found another commonality. On the systems with the issue, there also seems to be calls left over to voicemail stuck. Very odd.
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,885
Messages
589,544
Members
164,744
Latest member
johnblackwood1