Cloud SIP provider with OXE

[dstrait]

I am trying to bring a Twilio trunk online with our OXE. I engaged with the company that supports our system and they came back saying a local SBC is required as this is a cloud provider. Is this entirely accurate? I have dealt with several other systems that have no problem connecting to a cloud-based SIP trunk with no SBC.

[frank]

SBC is always required if you are using private IP Addressing for your PBX.
What you might have dealt with in the past are cloud providers (cloud = public IP Addressing) which were reachable from the outside world.
If you have a PBX like ALE, Cisco, Avaya, or whatever else hosted in house, you will always need a SBC.

Here is a good article from tele dynamics
https://info.teledynamics.com/blog/five ... ip-network

[dstrait]

The part that gets me is I have worked with several self-hosted/On-Prem PBXs that connect straight to cloud SIP providers, with no SBC. It's a pain poking all the proper holes in the firewall and building the NAT rules, but once it's done it's done. 3CX is one immediate example that comes to mind, plus some random off-brand PBX we bought in an emergency for a small office, which supports cloud SIP trunks. My guess is it's Asterisk-based

I'm now more curious as to why ALE/OXE is different in that if I give it access to the endpoints, why is the same not doable?

I was able to get Twilio to report back the OXE version but was just getting a 402 forbidden from the OXE when I tried calling the test number. So, I figured I missed something. Then our vendor came back saying we needed an SBC.

[frank]

3CX requires ports to be open on the firewall (see: https://www.3cx.com/docs/manual/firewal ... iguration/)
We've used it in the past, and actually stepped away from it because of all the security issues.

I have used OXE without SBC in the past successfully. This works until you have Digital phones in which case you need a digital gateway (GD Board) to go from SIP/IP to Digital. At this point, if you look at the OXE Traces, you will see the REFER SIP message pointing to the private IP of the GD, and it's where your SIP Provider won't work anymore.

You might be able to swing it if all of your extensions are IP. The 402 Forbidden might be a right issue somewhere. Best to run traces.
In my case, the firewall here is too tight in order to do this. Specially since our OXE is on a VM. I'd be curious to try though.

[dstrait]

Your comment about digital phones is an excellent point. We do have a handful of them, but mostly IP. I may do some more experimenting going straight to the cloud, but I think I now understand the situation as a whole a bit better. I was just thrown off a bit that this wasn't doable, but now I see it may be doable, but not ideal. Having an SBC could have some other benefits related to running a PBX alongside the OXE.

Thank you very much for your help and insight.

[frank]

Put it this way. When you have an OXE, SIP Trunking is going through the CS. SIP Packets are often referred with private IP Addresses. Without a SBC, you might find yourself with one way audio, call hanging up, etc.. The SBC will modify all SIP Headers to give your provider the public IP Address of your OXE (Actually of the SBC itself). Packets go through the SBC. SBC Modifies on the fly and forward to the OXE and GD with corrected IP Addresses in it. Without this (and with 3CX for example), I'm pretty sure you have to open more ports on your firewall. Share your findings once you do your tests. thanks

[haroun]

SIP is an application layer from OSI's point of view and should'n be investigated by Firewalls

[frank]

SIP is an application layer from OSI's point of view and should'n be investigated by Firewalls

Until you get contact info with private IP addresses.. hence SBC

[haroun]

SIP is an application layer from OSI's point of view and should'n be investigated by Firewalls

Until you get contact info with private IP addresses.. hence SBC

Of course dear Frank sinc sip is applicative and firewalls are not so friendly with him , SBCs are mandatory when internet (wan) is used as transport instead of leased line to the sip provider softswitch with private ip@