Multi-Tenant Voip Trunk Configuration

[wilsonian88]

Hi,

A quick question regarding Multi-Tenant installs that i haven't been able to find a direct answer to - Even though each install has a serparate port range, is it still best practice to register each sip provider using port 5060? Or will i have to find a provider that can alter the listening port so that i can connect each tenant on a separate one?

Thanks in advance

 

[markshehan]

Most providers will allow port ranges. They have to due to STUN etc.

In our case you can register or use static ip with iport settings - if no port we assume 5060.

LNeblett uses 55060 in a lot of cases for fax ATAs to bypass 3cx for outbound with us.

 

[bardissi]

The answer is NO!

Each voip provider will need to accept and send voip traffic to match the tenant sip port 5060, 6060, etc

Some voip providers can not handle more than 1 port number per public ip (depends on the method that the voip providers hands voip call setup)

We have been able to handle this by using a Session Border Controller which re-writes the sip headers to match the tenant sip port.

If you need more information on a SBC that can do this let me know!

 

[markshehan]

When Larry gets here he will confirm that it can be done without SBC.

He has many customers with us. A lot of customers have their 3cx set up to use us (mostly on 5060) but we find to get the best faxing we connect the ATA directly to our sip servers and bypass 3cx.

So Larry has 3cx and an ATA on the same public ip connecting to our sip trunks. They cant both use 5060 inbound. So when an incoming call comes in our trunks look up the DID and route it to the iport combination.

This would be the same for you if you put 3 of your tenants with us. You would register (or can use static iport combination per DID). We listen on 5060. When an incoming call comes in we would look up your DID. If they were on 5060 (Tenant 1) we would send it to your ip:5060. If it was Tenant 2 we would send it to ip:6060 etc. No magic.

You would have to confirm with the VOIP provider you are using, but most should be like us. We have to allow for non 5060 ports as STUN often results in that.

More than happy to help you if you need more explanation.

 

[wilsonian88]

Thanks for the responses so far everyone,

If there is anyone else who could post how they have their multi-tenant installs set up that would be great so i can weigh up my options,

Thanks

 

[bardissi]

That depends on the upstream carrier.

For example the upstream carrier we are using you can set the inbound ip, port number at the did level.

But then how does outbound calls get handled? This particular carrier could not accept multiple outbound port on the same public ip address. (yes i agree is stupid that they can do it but it is what it is)

So we set up ONLY outbound calls to run call setup through SBC (since each tenant had a different voip sip range.)

Fixed!

 

[markshehan]

That depends on the upstream carrier.

For example the upstream carrier we are using you can set the inbound ip, port number at the did level.

But then how does outbound calls get handled? This particular carrier could not accept multiple outbound port on the same public ip address. (yes i agree is stupid that they can do it but it is what it is)

So we set up ONLY outbound calls to run call setup through SBC (since each tenant had a different voip sip range.)

Fixed!

Ahhh. Our outbound works on authentication for each call. Even if registered (for extra security). So we do not care about the iport for outbound. If you successfully authenticate for that call then you can make the call (subject to some other security rules that the user has with us)

 

[bardissi]

Yup! The conversation on IP based IP authentication vs user authentication for voip trunking will live for quite some time i'm sure.

At the end of the day if it works it works!

I just appreciate the ability to have those remote devices without the tunnel/vpn/special port ranges for each phone/etc.

It just eliminates the headache on the endpoint conversation

 

[lneblett]

I tend to side with Mark on this one. Whether many or most providers, let's just say that many do and more will likely do so going forward as it can be a competitive edge.

A SBC may have its place in a number of scenarios. Many/Most/Some/ or all have expanded their feature set to accommodate a number of different functionalities associated to the VoIP world, but then and again, the phone manufacturers, providers, PBX developers, and others have also tried to improve their products so that connectivity issues are minimized and the need for an SBC is minimized.

However, some issues may be particularly thorny as each network or enterprise is different and may need some help in overcoming the obstacles this is where a SBC may be beneficial.

However, in my case, an SBC would be a last resort type of move. I have nothing against them and certainly not Bardissi who suggests their use, but if I can find a way to provide the service without the added cost, added latency, set-up and maintenance (potential failure and sparing needs), then I am far more inclined to keep the SBC on the sidelines. If, on the other hand, I really need it, I won't hesitate to put it in the game.

I like the fact that I can have multiple registrations to a single account and use different ports. It opens up a number of opportunities and while I may have to endure some programming of the devices, I generally have programming to do anyway as each is still unique and the templates are seldom all-inclusive and it's not like changes are all that frequent.

Depending on the costs ~$400 on up to $KK for SBC devices, it a personal choice of $ spent to what is being returned.

 

[bardissi]

To be quite honest looking at an SBC as a last resort is a bit mind boggling.

Every large cloud player out there (8x8, Ring Central, Nextvia, Vonage, etc) all use SBC's.

And to go a step further since we are 95% remote (cloud) and only 5% on prem had we not made the investment in an SBC we would have never moved forward with 3CX as an offering.

If we had to deal with the 3CX tunnel / VPN for every site with remote or battle with inconsistent STUN 3CX would not have been viable for our organization.

Could we have moved to an upstream provider on the trunk side that does user based authentication sure but that only solves 1 part of the story.

Yes we made the several thousand $$$$ investment in an SBC, made it redundant, tested all the supported handsets with sip srv records etc but this was all well worth the time and money spent.

At the end of the day we aren't even suggesting to have every person looking at 3CX to go out and buy an SBC solution just call me and I will let you use ours ; )

 

[lneblett]

Ahh sensitive are we?

Please re-read the post, I indicated "that in my case" it would be a last resort. I also indicated that it depended on the situation and that I would not hesitate to use if the situation warranted. I have experience with them, both as a function of needing to overcome an issue as well as a few providers or customers requiring them.

I am not suggesting that they do not have their application, but neither am I holding them up as the holy grail.

I am suggesting that they have their place and that it comes down to a cost versus reward for each individual scenario. Did you not see "However, some issues may be particularly thorny as each network or enterprise is different and may need some help in overcoming the obstacles this is where a SBC may be beneficial. " Does that not describe your scenario?

I did not try and address VPN/Tunnels/Cloud/STUN or compare the larger providers and what they use, that was never the question. I did not question your need or use of an SBC. I simply indicated my experience of using a multiple registration capable (user auth) VoIP provider and that in these instances, it negated the need for what otherwise might have benefitted from the use of an SBC. Others will need to make their own decision and I am sure that like you, other factors will come into play and they will move forward accordingly.

In any event, the next time I do run into a situation where a need is about, I will likely take you up on your offer. You did indicate free (for life, correct)?

 

[bardissi]

No worries big guy.

I was just trying to address the multitenant at a bigger picture than just trunking...its a different animal and I didn't want the poor soul who started this string to not look at it logistically from both ends!

For you ????? I will let you test it out and then make you an offer you cant refuse... !

 

[lneblett]

Understood.....cool and thanks. I have not had an offer in a long time.