Real world cloud based 3CX - SIP and RTP ports

[rc179]

This is the scenario;
Cloud based 3CX, no SBC, Yealink phones
Whenever I've done a similar system whether it's a major name or Asterisk variant, I use SIP port 5060 and an RTP port range and these are the same for all phones. For example, I would provision the phones for SIP 5060 and RTP 14000-14100. And all the phones would share these settings.

But with the 3CX I'm told that each phone needs to be on a unique port for the SIP, so phone-a has SIP 5061, and phone-b has SIP 5062, and so on so that phone-z would have SIP 5086. And phone-a would have RTP 14000-14019 and phone-b would have RTP 14020-14039 and so on through phone-z at 14500-14519

Is this how you've done it in a similar environment?

 

[Saqqara]

It does not matter how other similar environment handles remote phone,

As you have correctly highlighted each phone at one location requires different sip & rtp ports , fixed IP and portforwarding setup on the firewall to redirect the correct ports to the correct phone. This is the 3CX supported setup for stun.

If you have multiply phones at one location, look at installing SBC will make your life so much easier

 

[rc179]

It does not matter how other similar environment handles remote phone,

As you have correctly highlighted each phone at one location requires different sip & rtp ports , fixed IP and portforwarding setup on the firewall to redirect the correct ports to the correct phone. This is the 3CX supported setup for stun.

If you have multiply phones at one location, look at installing SBC will make your life so much easier

Actually it does matter what competing product do, since it adds significantly to installation/support/maintenance and that means the cost are higher.

As for the use of an SBC, i am well aware of this, but it introduces a single point of failure, which is one of the primary points of going with a cloud based system. I I have to put a box on-site anyway I might as well do a PBX, hardware costs are minimal.

I was hoping to hear from some real world implementations since we have only done 3 phones in our lab, not following "the 3CX way", and didn't see any issues. So I was curious how they ended up going this way and what goes wrong if it's not followed.

Understand, I wouldn't implement a production system that was not in line with what is supported.

 

[cobaltit]

The short version is this. STUN (or direct SIP) is highly dependent on the firewall playing nicely. If you do it the 3CX way (specific port forwarding or SBC) it ALWAYS works. If you do it the way you describe, it sometimes/usually/maybe works. The forum is littered with threads of folks saying things like 'I setup (more than one) phone for STUN 6 months ago and all of sudden I have one way audio'. Single phone without port forwarding usually works. Multiple phones is where the problem comes into play. Chances are if you have folks using Asterisk or something else with direct SIP/STUN you could probably keep the same setup. But if things don't work, don't expect any support from 3CX.

 

[rc179]

I get it, but it's not just asterisk and it's not coincident that it works, it's by design, and yes your firewall needs to be correct. There used to be real issues with ALG and so we would disable it, and many still do. But ALG has come a long way and most of the time there are no issues with leaving it enabled, it even does what it's supposed to. So the standard ports do work with Cisco, Avaya, Shortel, Mitel, Asterisk, even the old Nortel BCM, with as few as 10 users up to 250 users, no problem.

What this means is there is no practical advantage, and some disadvantage, to using the 3CX in a cloud only solution. I'll just go with 3CX as an on-prem solution, it does very well in that environment. Can also see it in a many-small-site environment where I'd have a cloud based PBX and SBCs at all the sites, this would definitely reduce licensing costs, but increases hardware costs.

Unfortunately it leaves me short if I want a HA/fault tolerant solution. I'd like to have a fail over pair in case of system failure and protection if the sites local ISP fails (at least AA and voicemail). If I put a pair on-prem I still have the ISP as a single point of failure, and if I put the two in the cloud I have to use an SBC onsite which adds yet another single point of failure.

For now we'll go on prem with failover, and I'll have to put together a more creative solution to protect against internet failure.

Maybe at some point they will fix this problem.

 

[cobaltit]

So the problem with your assumption is outside of Asterisk (and if you are talking about FreePBX using Sangoma phones then it also applies) is that all of those systems are proprietary and the vendor controls both the PBX and the endpoint and often isn't using SIP or at least a standards compliant SIP. 3CX has a variety of endpoints to work with and they can't control what those vendors do. For the pieces they do control (soft clients) it works just fine because they have the tunnel protocol built-in.

Also, I'm not sure if you've come across this but it may address your concerns in some scenarios:

https://www.3cx.com/community/threa...ilability-clustering-technical-preview.70800/

 

[bigdessert]

We have done multiple installs with multiple STUN phones. We standardize on either mikrotik or untangle for firewalls onsite and make sure "PBX delivers audio" is checked for each extension.

 

[rc179]

So the problem with your assumption is outside of Asterisk (and if you are talking about FreePBX using Sangoma phones then it also applies) is that all of those systems are proprietary and the vendor controls both the PBX and the endpoint and often isn't using SIP or at least a standards compliant SIP. 3CX has a variety of endpoints to work with and they can't control what those vendors do. For the pieces they do control (soft clients) it works just fine because they have the tunnel protocol built-in.

Also, I'm not sure if you've come across this but it may address your concerns in some scenarios:

https://www.3cx.com/community/threa...ilability-clustering-technical-preview.70800/

To be honest, it's your assumption that is incorrect. I'm well aware of the use of proprietary protocols and since this whole discussion was about SIP it can be taken as a given that I'm referring to the use of SIP on all these systems. They all support it, some also support MGCP, as well as their own protocol, but this whole discussion is about SIP.

Here's the bottom line, everyone else using SIP phones uses a common SIP port and RTP range. If 3CX wants to do something different, that's fine, it's their choice. But don't be making excuses that it is somehow the only way to make it work, it's not. I've been doing VoIP since before there was SIP, and I know what it can do, and what others are doing.

The clustered SBC is just a band-aid to try and create an HA implementation, which would be much simpler if they didn't complicate things with the SIP/RTP ports. It's also a "technical preview for PBX administrators" so it doesn't sound like it's intended for a production environment (would I get support for it?).

I'll give 3CX their due for creating a robust on-prem solution, and I've shifted our approach to work with their on-prem system. The tight control of the system configuration makes it supportable and reliable. I've used the same approach when developing both voice and data offerings, it works.

But I don't drink the kool-aid, and I'll point out a shortfall if it exists. The hope is that it will be noted and perhaps addressed. This is a highly competitive market, and hosted systems have been taking over.

If they fixed the SIP issue, and got it to work around ALG, it would be near ideal in an environment with a fail-over pair of cloud hosted PBXs. It's not as flashy as adding new features but it will make things simpler for their partners.

 

[Justin Scott]

I must be lucky. I’ve done multiple installs with the phones registered via STUN, as per @bigdessert, without needing to use different SIP ports on each phone, and they’ve just worked. 40+ Handsets on one install and never had an issue.

 

[rc179]

I must be lucky. I’ve done multiple installs with the phones registered via STUN, as per @bigdessert, without needing to use different SIP ports on each phone, and they’ve just worked. 40+ Handsets on one install and never had an issue.

I suspect this would be the case, it's inline with virtually every other SIP based system. In my testing, the intercom feature (calling with auto answer) did not work, but that's a rare feature to use. The bigger issue is a lack of support from 3CX, if the implementation doesn't fit their standards there is no support.

The problem with the SBC approach with the PBX in the cloud is that it defeats the primary purpose of using a cloud based system. That being no equipment on-site and the reliability of a cloud system. With the SBC you still have a single point of failure on-site.

I've changed what we are offering to fit what 3CX requires, putting in an SBC, but I'm not happy about it. And if you want to do it right, with the SBC or local PBX having true out of band management, you need a box with an IPMI (or virtual), either way it costs more, which can be hard to justify on these small systems.

 

[JohnS_3CX]

@rc179 we don't by any means prevent you from deploying the phones in STUN using the same ports, on the contrary, the system allows you to use the same ports for all during provisioning.

Many firewalls are smart enough to understand the traffic and NAT it properly, but not all our customers will have the same firewall, there are 1000s of models out there as you are aware and each one has various firmware revisions. This creates a lot of variables that we do not control, so for best quality and reliability, we recommend to remove these variables by setting specific ports, and forwarding them statically rather than rely on NAT. If you contact support with this issue, they will tell you to do this exact thing for the reason I just described.

As for the SBC, it does not defeat the purpose of a cloud install at all - unless you have another purpose in mind, a cloud install takes the PBX out of the premises so it is accessible from all devices and clients and from all over the internet. As for other customers or partners that use it, they gain some benefits like easier provisioning, full encryption, bypassing of ALG, NAT and Ports management, as well as keeping RTP of local calls between devices. HA SBC is also something we will offer to defeat the single point of failure even though the SBC has had a very good track record so far already.

And finally, always remember that you can use the system in any way you want, so long as you are aware that things we do not officially support, you will have to be responsible for yourself. I don't necessarily consider that to be a problem if you know what you are doing, and you can always return the system to our recommended ways in case you have an issue to see if it works as the designers of the system intended.

 

[rc179]

@JohnS_3CX
That's good to hear, but is in direct conflict to what support told me. This has cost me a lot of time and I would like a clear and consistent response. Does 3CX support this or not?

Thomas Delizisis (3CX support, bolding is his)". Each IP Phone requires unique local Sip and local RTP ports. The above ports must be open and forwarded to the local IP address of each IP phone."

 

[cobaltit]

I would read the requires as being from a supported standpoint, not a technical standpoint.

 

[cmp1]

I would read the requires as being from a supported standpoint, not a technical standpoint.

This.

 

[cmp1]

Can also see it in a many-small-site environment where I'd have a cloud based PBX and SBCs at all the sites, this would definitely reduce licensing costs, but increases hardware costs.

Unfortunately it leaves me short if I want a HA/fault tolerant solution. I'd like to have a fail over pair in case of system failure and protection if the sites local ISP fails (at least AA and voicemail). If I put a pair on-prem I still have the ISP as a single point of failure, and if I put the two in the cloud I have to use an SBC onsite which adds yet another single point of failure.

For now we'll go on prem with failover, and I'll have to put together a more creative solution to protect against internet failure.

Maybe at some point they will fix this problem.

Keeping the system in the cloud is your best option. Use SBC virtual or physical locally. You can run it both Virtual, *NIX or WIN, Physical on WIN, or *NIX including on a single or a pair of RPI's. $100 and you have a pair of SBC's in HA mode.
This gives you easy provisioning, secure/tunnel communication back to the PBX in the cloud, and any calls between extensions behind the same SBC are kept local, avoids bandwidth and resources.

 

[rc179]

Keeping the system in the cloud is your best option. Use SBC virtual or physical locally. You can run it both Virtual, *NIX or WIN, Physical on WIN, or *NIX including on a single or a pair of RPI's. $100 and you have a pair of SBC's in HA mode.
This gives you easy provisioning, secure/tunnel communication back to the PBX in the cloud, and any calls between extensions behind the same SBC are kept local, avoids bandwidth and resources.

I appreciate you contribution but it's not relevant given the previous posts/discussion. I'm well aware of the pros and cons and what is supported and isn't. And I've preciously state my intent.

 

[rc179]

I think some are missing the point, and part of this is due to a general acceptance that there will be problems that need to be worked out and the classic "reboot" the system to solve problems.

These beliefs are a result of a declining sense of of proper engineering and implementation in the IT world. No problem is ever solved by rebooting a device, it clears the symptom but does not solve the problem. And if you are resolving problem during implementation, or soon after, then the solution was NOT engineered correctly.

And the point of this is that implementing any system without support, or outside a manufacturers accepted design limitation is nothing short of creating problems for your clients. They may be OK with that, I am not. I have a history of designing and implementing solutions from the small to the large enterprise and they all have common elements, they meet or exceed the performance requirements, and they are reliable. I'm not cutting my standards just to work around a mfg limitation. And yes this means I will walk away if the budget won't allow for this.

If the mfg won't support it, it does not go into a production environment.

 

[Cytranic]

Go with a quality SIP aware firewall. (NOT SIP-ALG). I have 100 phones behind a Sophos, every phone is dynamic IP with 5060 as the sip port. No issues at all.

But i'll echo others and say a HA Raspberry pi is a good solution.

 

[rc179]

Go with a quality SIP aware firewall. (NOT SIP-ALG). I have 100 phones behind a Sophos, every phone is dynamic IP with 5060 as the sip port. No issues at all.

But i'll echo others and say a HA Raspberry pi is a good solution.

Agreed, I'm using Fortigate right now but have also used Sonicwall and ASA. My testing with 3CX had phones working (no sip alg) with only the auto answer (intercom) feature not working. But the audio path for internal calls is going round trip to the 3CX, which isn't great but I can live with it given this is specifically for small environments.

I just need 3CX to support it.

And this is exactly the kind of real world I wanted to hear about. I can't build a 100 phone test environment. Thanks

 

[Justin Scott]

Again, I must be lucky. I've got intercom working on STUN extensions no problem.