SBC - BLFs drop off

[ian.watts]

3CX VPS, SBC in the office.

Cisco SPA5xx units, seems that the BLFs for other extensions which are subscribed to appear to drop off.. they go into the error state. The registered extension itself is fine.. sends/receives calls via the SBC just fine.

The BLFs do end up coming back.

I started a tcpdump on the rPi SBC for capturing SIP traffic between it and one of the Cisco units. My guess is the SUBSCRIBE/NOFITY pair is missing some interval, causing the subscribed BLFs to time out or something.

Anybody else behind and SBC with subbed BLFs with this behavior?

 

[Anonymous]

As I understand it from forum posts and support feedback, the SBC rewrites some sip messages and is not simply a tunnel. Also the Cisco SPA phones are not supported as remote phones or behind an SBC, probably because the sbc doesn't rewrite Cisco dialect properly.

Have you tried using a vpn tunnel instead of the SBC? With a Tunnel, there is no chance of your sip traffic being modified and fields truncated or otherwise not passed on.

 

[ian.watts]

At this point we are using ourselves to test/vet using a VPS to host 3CX, with the SBC at the office(s).

Other than some added latency, this is the only hangup.
I did manage to wire up tcpdump to pcap on the rPi, nabbed a spare 504G and rigged it with some extension and a sub/blf to itself on BLF4 (manual config).

Seems I can get the issue to come up if I decrease the subscribe expires.. similarly the subscribe retry interval.
When it decides to "die" on that sub.. the status drops.. seems to either hit again on the first or second retry.

I need to get a good grasp from my SIP trace as to "what" the dialog between SBC and handset should be normally.. versus what I am ending up with.

I have another setup with 50x units with SBCs to their home office on-prem.. they don't exhibit this behavior. Maybe I can get a compare on some traces.

Ideally I wanted to Wireshark from my PC workstation in real-time.. my head blew up and my time ran out before I could try successfully.

What I DID see thus far were some odd VIA lines from the SBC.. namely 127.0.0.1. Unclear if that is calling out the tunnel with the PBX.. but I did rebind the service to my LAN address and verify netstat shows me the service is listening solely on that address (not 0.0.0.0:5060 but <lanip:5060>).

The VPS only has a WAN address as you'd expect. Configuring a VPN tunnel with a VPS would be 'tricky' as it stands already.

Need to figure out what the SUBSCRIBE/NOTIFY dialog should be doing.. and identify where/when it fails.