SBC email notifications "changed status to up"

[lateparty]

I've been getting email notifications like below about every 7-10 days for the past 6 months:

Trunk SBC 'SBC on Linux 2' ([ip removed]) has changed status to Up

Now I wouldn't mind these if the SBC first changed to "status down", but it never does!! Also, it's NOT the SBC rebooting -- has been up the whole time

 

[SteveITS]

From my experience the "up" email is sent at each reconnection, while the down message may take several (up to 5?) minutes. So these are likely short drops causing a reconnect.

 

[cobaltit]

Is there any other issue besides that?

Generally this is an indication of the internet being a little off at that location. Enough packets are missed for 3CX to consider it coming back up, but not enough for it to have considered it to have gone down. You didn't post any information about your setup, either 3CX or SBC side. You also state that it's not the SBC rebooting but not how you determined that was the case. The service itself could have restarted without the host being rebooted.

https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

If you search the forums there are other similar cases. Some of them were due to VM timing issues for virtualized SBCs. Some firewall or possibly even 3CX itself. Switching the SBC to TCP might help. In the Update 7 change log there's mention of TLS improvements that may resolve it as well.

 

[lateparty]

Haven't had enough time to get that in depth about it, as it is really just the email bothering me -- no other signs of an issue.

In regards to the uptime, it's just that, uptime for the SBC. Didn't look at services or anything like that. All I did was follow the setup wizard, haven't had to look under the hood since.

Was hoping there was a quick way to check. The SBC's are running locally at our office on VMware ESXi 6.7. They connect to our Amazon Lightsail 3CX. I'm guessing it's just type of network issue associated with that config.

For the firewall rule I'm allowing both port 5090 TCP/UDP into the SBC, maybe just turning off UDP?

Mainly just wanted to stop getting those "up" emails, and only get "down" ones, but there is no option. Might look into an Outlook rule.

 

[SteveITS]

Just deleting the emails won't stop the problem though...for instance if SBC loses connection I'd expect calls will drop. Try pinging the 3CX server from your office a few thousand times and see if you get packet loss (especially during the time of the SBC "up").
Perhaps https://www.3cx.com/community/threads/near-constant-sbc-status-change-and-dropping-calls.76623/ will help, at least it's a similar thread.

 

[lateparty]

Just deleting the emails won't stop the problem though...for instance if SBC loses connection I'd expect calls will drop. Try pinging the 3CX server from your office a few thousand times and see if you get packet loss (especially during the time of the SBC "up").
Perhaps https://www.3cx.com/community/threads/near-constant-sbc-status-change-and-dropping-calls.76623/ will help, at least it's a similar thread.

Thanks, will look at this post. Never had a report of a dropped call fortunately. I realize now that the "status down" will only happen if it's down for at least 5 minutes. I think the ping is a good place to start, to see if there is any correlation.

 

[cobaltit]

For the port forwarding, that's not on the SBC side right? Because there should be no port forwarding there. The SBC initiates the connection outbound so no inbound port forwarding is needed.

 

[lateparty]

For the port forwarding, that's not on the SBC right? Because there should be no port forwarding there. The SBC initiates the connection outbound so no inbound port forwarding is needed.

No, it's from the 3CX Cloud Instance into the SBC debian VM

 

[SteveITS]

it's from the 3CX Cloud Instance into the SBC debian VM

He's saying there should be no NAT port forwarding going towards the SBC. Nothing from the Internet connects to the SBC.

 

[lateparty]

He's saying there should be no NAT port forwarding going towards the SBC. Nothing from the Internet connects to the SBC.

Good to know, have adjusted it thusly. I'll see if it makes a different, but I don't think that's the issue I'm seeing.