Bridging 3CX PBXs

[tapmendesuk]

Hi All,

Is it possible to Bridge more than one 3CX PBX instance together. On the article 3CX wrote about this they say "You can connect two remote 3CX Systems together". Does this mean a limit of two systems, one being a Master and one being a Slave.

Here is our situation, we have 4 sites, 3 are on-premise PBXs and 1 is cloud hosted. The customer would like to be able to call internal extensions between all sites and see visibility of extensions. Is this possible, would they also be to use the Hot Desk function if they belong to 1 PBX and go to another site? How would you suggest the Master/Slave is configured in this type of setup.

Thanks in advance!

 

[Alphabetic]

Absolutely. we bridge all our customers to our pbx.

You would need to create a master/slave between each PBX

 

[tapmendesuk]

Oh great! So would you set Site 1 to be the master for all sites and then sub sites are just slaves? Or do they need to be masters too, so a two way connection can take place?

 

[NicholasP_3CX]

No, the assigning of Master and Slave is on a per connection basis.

So one system can be a Master and a Slave on another connection.

 

[tapmendesuk]

Thanks Nicholas, how would this setup look for the 4 sites in terms of best practice please. Can you suggest the breakdown of connections I need to establish.

 

[Alphabetic]

Thanks Nicholas, how would this setup look for the 4 sites in terms of best practice please. Can you suggest the breakdown of connections I need to establish.

See my highly technical drawing above but instead of a triangle, a square.

 

[NicholasP_3CX]

Site A - Site B
Site A - Site C
Site A - Site D
Site B - Site C
Site B - Site D
Site C - Site D

Bridges are always a 1 to 1 connection between the 2 sites.

You would then need to create outbound rules to allow the users to dial each other.

Presence can also be optionally enabled between each site.

 

[VoIPTools]

Perhaps it is time to ask the question "why separate phone systems?" There was a time where having separate phone systems at each location was justifiable given the instability and limited bandwidth of the internet infrastructure (yes, I am old). But today it is very feasible to have a central phone system that serves the entire world. We have staff in 5 states in the US and two states in India and we all share the same phone system.

The only reason I can see for having separate phone systems is in rural environments where traditional POTS / PRI phone lines are required, or for REALLY big 3CX implementations (tens of thousands of extensions) where it would be difficult to provide sufficient infrastructure to support the number of users.

My suggestion for both small and very large implementations is to host a single instance of 3CX at a large hosting company (AWS, Google, Azure, etc.). These providers have huge redundant internet pipes, a large team of engineers dedicated to providing a high availability infrastructure, and real-time monitoring. You can cluster your 3CX server, implement the 3CX HA design, and use hot migration features possible with many virtualization solutions. I just do not see many reasons to have separate phone systems anymore.

I was pondering whether there would be an advantage to having multiple 3CX servers when performing upgrades. You might be able to have a phased roll out of a new version of 3CX, but often bridging between 3CX servers requires that they all be on the same version. Perhaps in the case where physical phone firmware updates were necessary to be compatible with a new version of 3CX -- that might benefit from the ability to do a phased upgrade, but in the end, even these challenges would not be sufficient justification for having separate per-location phone systems. Most trunks these days depend on the internet (SIP trunks) so if a location has poor internet, they are going to have issues whether they have their 3CX on a local instance of 3CX or if 3CX is hosted in the cloud.

The only scenario that makes any sense, in my mind, for a local PBX is if you don't have reliable internet and you are forced to use traditional phone lines.

 

[NicholasP_3CX]

Perhaps it is time to ask the question "why separate phone systems?" There was a time where having separate phone systems at each location was justifiable given the instability and limited bandwidth of the internet infrastructure (yes, I am old). But today it is very feasible to have a central phone system that serves the entire world. We have staff in 5 states in the US and two states in India and we all share the same phone system.

The only reason I can see for having separate phone systems is in rural environments where traditional POTS / PRI phone lines are required, or for REALLY big 3CX implementations (tens of thousands of extensions) where it would be difficult to provide sufficient infrastructure to support the number of users.

My suggestion for both small and very large implementations is to host a single instance of 3CX at a large hosting company (AWS, Google, Azure, etc.). These providers have huge redundant internet pipes, a large team of engineers dedicated to providing a high availability infrastructure, and real-time monitoring. You can cluster your 3CX server, implement the 3CX HA design, and use hot migration features possible with many virtualization solutions. I just do not see many reasons to have separate phone systems anymore.

I was pondering whether there would be an advantage to having multiple 3CX servers when performing upgrades. You might be able to have a phased roll out of a new version of 3CX, but often bridging between 3CX servers requires that they all be on the same version. Perhaps in the case where physical phone firmware updates were necessary to be compatible with a new version of 3CX -- that might benefit from the ability to do a phased upgrade, but in the end, even these challenges would not be sufficient justification for having separate per-location phone systems. Most trunks these days depend on the internet (SIP trunks) so if a location has poor internet, they are going to have issues whether they have their 3CX on a local instance of 3CX or if 3CX is hosted in the cloud.

The only scenario that makes any sense, in my mind, for a local PBX is if you don't have reliable internet and you are forced to use traditional phone lines.

Distance is one factor. You could have a PBX in London, another in Sydney and one in Los Angeles. Huge distances between them with a lot that could go wrong internet wise, like undersea cables getting cut. Latency could also play a big factor.

Local regulations. This could be the case in some countries where have a SIP connection outside of the country is not possible (UAE for example) and someone either has an office there, or does alot of business there and needs a local number.

Density of users. Have a few hundred or thousands of people in one campus would make sense to have the system locally to save on bandwidth. I agree with the fact that in this day and age bandwidth is not such a restraining factor anymore, but any savings are savings. You might then have another campus close by with another thousand users. You can connect them locally as well and bridge the 2 systems together.

Redundancy. Some companies dont want to have just one system. They would want to spread the load out.

Legal issues. Some companies might be part of a bigger group of companies but still independent entities. They would not want to have information exposed to each other, other than presence.

 

[tapmendesuk]

Perhaps it is time to ask the question "why separate phone systems?" There was a time where having separate phone systems at each location was justifiable given the instability and limited bandwidth of the internet infrastructure (yes, I am old). But today it is very feasible to have a central phone system that serves the entire world. We have staff in 5 states in the US and two states in India and we all share the same phone system.

The only reason I can see for having separate phone systems is in rural environments where traditional POTS / PRI phone lines are required, or for REALLY big 3CX implementations (tens of thousands of extensions) where it would be difficult to provide sufficient infrastructure to support the number of users.

My suggestion for both small and very large implementations is to host a single instance of 3CX at a large hosting company (AWS, Google, Azure, etc.). These providers have huge redundant internet pipes, a large team of engineers dedicated to providing a high availability infrastructure, and real-time monitoring. You can cluster your 3CX server, implement the 3CX HA design, and use hot migration features possible with many virtualization solutions. I just do not see many reasons to have separate phone systems anymore.

I was pondering whether there would be an advantage to having multiple 3CX servers when performing upgrades. You might be able to have a phased roll out of a new version of 3CX, but often bridging between 3CX servers requires that they all be on the same version. Perhaps in the case where physical phone firmware updates were necessary to be compatible with a new version of 3CX -- that might benefit from the ability to do a phased upgrade, but in the end, even these challenges would not be sufficient justification for having separate per-location phone systems. Most trunks these days depend on the internet (SIP trunks) so if a location has poor internet, they are going to have issues whether they have their 3CX on a local instance of 3CX or if 3CX is hosted in the cloud.

The only scenario that makes any sense, in my mind, for a local PBX is if you don't have reliable internet and you are forced to use traditional phone lines.

Majority of our customers installs are all in the Cloud. This particular customer is a Hotel group, their bedroom phones are all analogue and as such in the event of local internet failure they want to be able to still call room to room or room to reception etc.

The reason for the bridging request is because the hotels share some functions like accounts across the hotels and they wish to dial internal extension numbers.

 

[NicholasP_3CX]

Sounds like a perfect scenario for the bridging.

Independent entities, but still need to communicate between themselves.

Do ensure that you limit the inter system calling to just the staff departments.

 

[Drain Bamaged]

This is how I did it. Six offices, each has a bridge connection with the others. The 31, 32, 34... etc. are leading digits.

If I am in office A and want to call someone in office B, I dial 35xxx where the xxx is their extension in office B.

By using this and Outbound rules, I can send what would normally be an international long distance call over the Internet for zero cost dialing. I also route using Outbound rules so if a country code prefix for office C is seen in a dialed number it sends the call to office C which is placed as a local call. If an exec is travelling to office F and calls a hotel in office F's country to make a reservation, it dials out from office F as a local call no matter what office you are in.

This system also allows for real-time routing. If the connection from A - B is down, I can route through office D through a secondary route, for example. Little tricky to set up, but adds redundancy. Call goes through without the caller even knowing there is an issue. All of the calls that go down the bridge are secured by the tunnel encryption as well.

We paid for 3CX in the first ~18 months just from long distance savings.

 

[AWS2P]

Why no use of 33 nor 37 in your scheme ? are they unlucky numbers you avoid ?
Seing your drawing i understand it probably create headaches to create all these outbound rules without making any errors

 

[Drain Bamaged]

Why no use of 33 nor 37 in your scheme ? are they unlucky numbers you avoid ?

33 - Office merged with 38
37 - Decommed DR datacenter

I'm reserving 40 for my volcano lair.

 

[AWS2P]

Just to be curious, how many rules do you have on each location ?

 

[NicholasP_3CX]

This is how I did it. Six offices, each has a bridge connection with the others. The 31, 32, 34... etc. are leading digits.

If I am in office A and want to call someone in office B, I dial 35xxx where the xxx is their extension in office B.

By using this and Outbound rules, I can send what would normally be an international long distance call over the Internet for zero cost dialing. I also route using Outbound rules so if a country code prefix for office C is seen in a dialed number it sends the call to office C which is placed as a local call. If an exec is travelling to office F and calls a hotel in office F's country to make a reservation, it dials out from office F as a local call no matter what office you are in.

This system also allows for real-time routing. If the connection from A - B is down, I can route through office D through a secondary route, for example. Little tricky to set up, but adds redundancy. Call goes through without the caller even knowing there is an issue. All of the calls that go down the bridge are secured by the tunnel encryption as well.

We paid for 3CX in the first ~18 months just from long distance savings.

View attachment 46244

This is what it's all about!

I'm impressed! That is a well thought out setup and it seems you are fully utilising the bridges capabilities. I am also going to assume that you are utilising the presence as well so the users dont need to guess the prefixes.

This is what I like to see on a Monday morning to make my day.

Seing your drawing i understand it probably create headaches to create all these outbound rules without making any errors

The good thing is that these only need to be created once and only need to be tweaked whenever there is a change or addition to this beautiful network.

 

[Drain Bamaged]

Just to be curious, how many rules do you have on each location ?

Depends on the office. In the HQ I have forty. I order based on the number of digits, blocks I want and the call handling I need. They are assessed from top to bottom until they match the call and I try to used one rule per situation so changes to one don't upset many. That works for me, YMMV.

3 digit - 911, 411, etc. come first.
5 digit - Interoffice calls 33xxx,35xxx,36xxx, etc. (Use Route 1, Route 2, etc. for redundancy)
7 digit - local calls

8+ digit - We block 1-900 numbers (by prefix) and specific ext numbers cannot dial long distance (kitchens, break rooms, public phones)

8 - 17 digits are handled by area / country code. If they match a country we have an office in, it is routed to that office, otherwise it goes out regular SIP.

It takes some tweaking with stripping and adding digits where needed, but works well once set up. The branch offices are much easier.

 

[Drain Bamaged]

Seeing your drawing i understand it probably create headaches to create all these outbound rules without making any errors

How do you eat an elephant?

One bite at a time.

Do one rule at a time, test it, tweak where needed, test again then move to the next once working. The first few will take time, but when you get into it, you can rip through them. You will make mistakes, but that's where you learn. You might even find a better way.

Bonne Chance.