pbxnsip with a front end SBC products

[clarity]

This series of questions is geared toward using pbxnsip in a hosted pbx environment (providing services to many many clients).

 

I have to prepare for and expect to be able to support 50,000 phones & up as our company grows & expands.

This started out as an email question and per Kevin's suggestion I am posting it on the forum as well so

Christian can have a look and answer.

---------

 

I have a few questions you might be able to help me with regarding

load balancing large numbers of pbxnsip servers and interrop with session border controllers.

 

Do you have any experience with placing pbxnsip behind any of the well known commercially available and/or open source session border controllers?

And can you share your experiences with us? how did it go? what works what does not work?

 

I'm somewhat familiar with the process of using OpenSER as an SBC and placing asterisk & other servers

behind it and doing all of the nat traversal/call translations etc in the SBC section of the network.

I'm curious of your thoughts toward eventually employing this type of approach with PBXnsip versus having

50+ pbxnsip servers directly on public IP addresses where pbxnsip is handling virtually all of the NAT and call

routing/translations.

 

Do you think this approach makes sense? and do you think it would be relatively 'plug -n- play'?

Or do you think we'd have a HUGE interrop/development task on our hands before it would work.

 

Have you ever been through this interrop process with any SBC product?

 

My thought today would be to put 10-50 pbxnsip servers behind OpenSER and have OpenSER handle

all of the NAT traversal/internal network 'topology hinding' features and place the pnxnsip servers on

private non routable IP space behind OpenSER.. yet still maintain and have ALL of the pbxnsip

features be able to continue to work behind OpenSER. features like BLF intercom IM really all pbxnsip features

that we have today... Do you think they will work behind an SBC like OpenSER? or do you think they

would all break due to interrop issues with an SBC, where pbxnsip no longer has total control of the

public Internet Interface?

 

Thank you very much for your time and your thoughts!!

 

I am currently working with OpenSER and will be steadily becoming much more familiar with all the ins & outs

of this software as we move on.

I've also been working on a daily basis with the Stratus ENTICE Softswitch/SBC for about 3 years now.

 

Take Care!

 

Steve

[Vodia PBX]

Do you have any experience with placing pbxnsip behind any of the well known commercially available and/or open source session border controllers?

And can you share your experiences with us? how did it go? what works what does not work?

 

We know a couple of SBC; for example the people at ACME packet know pretty well what they are doing.

 

The PBX comes with it's own built in "Mini-SBC", which is not exactly what e.g. the SBC from ACME packet is doing. The SBC that are on the market usually address the needs of a typical carrier. Essentially that is NAT traversal for a large number of subscribers, topology hiding, billing (policy enforcement). Essentially the SBC gives subscribes "dial tone" on a SIP trunk. Which is a great thing!

 

The PBX "Mini-SBC" is pure software and not as scalable as a real (mostly hardware-based SBC). It scales for the registrations that you have on that particular PBX, something around 500-1000 extensions depending on CPU and overall load with calls and so on. The Mini-SBC does not deal with billing; but it cares about keeping the media session alive. That's when a call gets disconnected because the PBX does not receive any media (the famous "one-way audio timeout").

 

One problem with the carrier-grade SBC is feature transparency. More and more phones do not only use SIP; they also use HTTP and HTTPS to talk to the address book, show what calls are availble for pickup (AJAX and PAC), and maybe one day do stuff like XMPP. I would expect a lot of problems with the SBC and non-standard events on SIP. Maybe REFER works, but dialog-state, check-sync and whatever extensions we are using to provide the features that customers expect from a PBX today might be a headache and we need to explain and justify everything to the SBC vendor.

 

IMHO the PBX belongs from a logical point of view in front of the SBC. The carrier should have a core that deals with the billing on trunks; the PBX acts like a CPE-PBX; it just happens to be located in the colocation to that the customer does not have to run it on his on power circuit.

 

I'm somewhat familiar with the process of using OpenSER as an SBC and placing asterisk & other servers

behind it and doing all of the nat traversal/call translations etc in the SBC section of the network.

I'm curious of your thoughts toward eventually employing this type of approach with PBXnsip versus having

50+ pbxnsip servers directly on public IP addresses where pbxnsip is handling virtually all of the NAT and call

routing/translations.

 

If you want to run 50 PBX you need a SIP proxy, and SER is a good and obvious choice here. If you are running two or three, you can fix a lot of the routing problems with the dial plan. But when you have a farm then the dial plans get so chaotic that you need a central routing instance.

 

Also, billing is a major issue. The CDR that the PBX generates is not what you want to bill! Customers want to see the CDR for the trunks, and the SER is in the best position to generate CDR for this. You probably need a professional billing software, and pbxnsip is more than happy if the billing takes place on the SER.

 

Many (most?) of the clients that we have actually run the PBX on a public IP address. And fortunately most of the clients are savvy enough to close ports like NFS, FTP, and who-knows what ports on the server. The case of TCP SYN attack is tricky; In order to prevent this a regular firewall can make sure that the PBX does not get overloaded with these packets. If you clients have a fixed IP address, you can also white-list them on the PBX, so that all other packets get rejected and the PBX is invisible to the rest of the Internet.

 

Running multiple PBX instances also give you some kind of "no single point of failure". The PBX is supposed to never crash and we take that pretty serious. But if there should be something going wrong, maybe even a hardware failure, then the damage is limited to 1/50 servers = 2 %. Those customers will not be pleased, but the other 98 % will not even notice.

 

Do you think this approach makes sense? and do you think it would be relatively 'plug -n- play'?

Or do you think we'd have a HUGE interrop/development task on our hands before it would work.

 

Have you ever been through this interrop process with any SBC product?

 

My thought today would be to put 10-50 pbxnsip servers behind OpenSER and have OpenSER handle

all of the NAT traversal/internal network 'topology hinding' features and place the pnxnsip servers on

private non routable IP space behind OpenSER.. yet still maintain and have ALL of the pbxnsip

features be able to continue to work behind OpenSER. features like BLF intercom IM really all pbxnsip features

that we have today... Do you think they will work behind an SBC like OpenSER? or do you think they

would all break due to interrop issues with an SBC, where pbxnsip no longer has total control of the

public Internet Interface?

 

Thank you very much for your time and your thoughts!!

 

I am currently working with OpenSER and will be steadily becoming much more familiar with all the ins & outs

of this software as we move on.

I've also been working on a daily basis with the Stratus ENTICE Softswitch/SBC for about 3 years now.

 

If you already have a SBC than that is a good start. If you already have customers that use a "soft phone" with your service, then that's even better. Then you can keep things like they are, and connect the PBX like you would connect a soft phone to your SIP trunking service. I know one case very well where the carrier already had a SIP trunking product and just put the PBX in front of it. That approach made a lot of sense. The PBX service is a true value-add to his existing portfolio.

 

We got a good exposure with SBC - from the "customers" side. We only hear from customers when the carrier does not use a SBC (the cases when the carrier just says "get a public IP or use STUN and try a couple of DSL routers out until it works"). The interop nightmare known from SIP should not happen when a SBC is used! That what SBC are good for.

 

Saying that this project is a piece of cake would set the wrong expectations. I believe the biggest problems are the efficient management of a large customer base (setting up a new domain, deleting a domain, moving a domain), customer support. I think it is okay to just get started and do the steps manually and then write some scripts that perform steps automatically. Customer support is all about plug and play, and the way the CPE setup is organized.

 

We recently gave some deep thougths about failover, and that will also be an issue that needs some scripting to make the failover happen automatically and quick.

 

And the other topic is of course QoS. If you are able to provide the neccessary bandwidth to the customer, your support life will be so much easier. Maybe VLAN on CPE to keep the traffic seperated from the general data traffic. Combined with the whilelist of allowed IP addresses that is a very robust way of providing hosted PBX which is safe against DoS and QoS-Problems.

[hosted]

We dont use SBC per say. Our SIP phones register directly to PBXNSIP. We are starting to develop our own provisioning server so we can have 1 IP that can provision many pbxnsip box's.

 

you need a switch thats for sure pbxnsip cant handle it. We use SER with PortaSIP we also own Voipswitch and are going to see if we can get a trial for MERA. So far we have been able to get PortaSIP and Voipswitch to work with pbxnsip for billing purposes. PortaSIP tracks the domain and Vosipswitch tracks the callerID information for billing. Both were pretty inexpensive solutions considering. We dont terminate any calls, we leave that for the people who can afford Sonus.