Unable to make extension to extension, or outbound calls

[jdag]

Setting up a new system (20.0.4.487), on-premise with a local SBC. There are two Yealink T43Us connected, with a VOIP.ms line connected.

There is a Ring Group setup and a call to the VoIP number rings both extensions, as desired. However, not able to make call from extension to extension, nor out-bound calls, calls show "called failed" and "Declined", with all of the logs beginning with:

Unidentified Incoming Call. Review INVITE and adjust source identification: INVITE sip:XXX | [email protected]:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP...

Why does it think calls are coming from 'localhost' (127.0.0.1) rather than the phone, SBC or PBX?

Can anyone point me to docs or other help to address this issue?

 

[jdag]

If I connect to the PBX, rather than the SBC it works - So, why is the SBC reporting as localhost|127.0.0.1....

 

[SteveITS]

The SBC is on the same network as the server? That is not necessary, I would remove that. SBC should be used while on a different network.

 

[DimitrisL_3CX]

Hello @jdag,

As mentioned by @SteveITS, the SBC is necessary when you want to provision IP Phones from a remote location.
See also our guide Installing a 3CX SBC (Session Border Controller).
Leave them as Local Lan and let us know if you have any issue.

 

[fortech]

Footnote in case this is helpful JDAG?
> 3cx host running inside your office LAN <> you don't want to have an add-on SBC in this deployment. It will confuse things, only.
> If you have 3cx host running off-site ("in the cloud") then you maybe want an SBC in your office, to act as a "Bridge" between handsets in your LAN <> and the non-local 3cx server. (* depending on your handsets, if they have built-in tunnel feature - on modern handsets this is a thing - or otherwise yes probably you want SBC generally).
> if you have a secondary / remote-branch-office with handsets, you will probably want SBC at that site / to do a similar 'connectivity bridge' from (remote site) to (3cx box)
- the SBC will basically tunnel all the traffic / remove need for firewall rules / when VOIP traffic needs to transit over firewall / NAT or other drama - all goes away. The small added confusion is that if you read log files too closely, you might wonder "why is 127.0.0.1" in here? I believe in part that is an artefact of how SBC<> tunnels traffic from remote to 3cx_box. As far as 3cx-box is concerned, it talks to localhost<> Tunnel holds the traffic <> bridges it to remote SBC <> which dumps it to the proper registered handset.
- what you maybe will want to review, is how the handsets are identified inside 3cx. If they are connected via an SBC this will be clear / along with the "LAN IP of the SBC" to help remove ambiguity.
- and of course, if not yet done, try some 'sanity test' calls using web-based client, if you want to validate "does this thing work?" and you can examine if you wish how those log entries also look. I'm guessing they might too exhibit similar 127.0.0.1 / since web client is also basically tunneling traffic / to avoid forcing raw SIP/voip traffic to be passing from Client<>server which creates opportunity for drama/firewall mess / things 'not just working'. Which is of course what we all want.

hope this is helpful / not adding mud to the discussion.

Tim