Hi,
As many of you may know, we are undertaking several tests in order to test the interoperability between several PBX IP from different vendors. Until now, we were trusting that the VoIP IP PBX were good enough to be interconnected directly, however, one of the vendors have presented the "SBC" concept.
The "SBC" (Session Border Controller) is not a new concept since we were using it anyway when we setup a (Asterisk+SER+SIP Proxy) Box to handle the "on-net dialout" calls.
I'm now overwhelmed with the amount of SBCs that are suggested by the vendors to implement a solution. (http://www.juniper.net/solutions/literature/solutionbriefs/351085.pdf)
Can anyone drop me some lines about this? I urgently need some feedback on this.
Thanks!
Joao Pereira www.fccn.pt
Hi Joao,
Joao Pereira schrieb:
Hi,
As many of you may know, we are undertaking several tests in order to test the interoperability between several PBX IP from different vendors. Until now, we were trusting that the VoIP IP PBX were good enough to be interconnected directly, however, one of the vendors have presented the "SBC" concept.
The "SBC" (Session Border Controller) is not a new concept since we were using it anyway when we setup a (Asterisk+SER+SIP Proxy) Box to handle the "on-net dialout" calls.
I'm now overwhelmed with the amount of SBCs that are suggested by the vendors to implement a solution. (http://www.juniper.net/solutions/literature/solutionbriefs/351085.pdf)
Can anyone drop me some lines about this? I urgently need some feedback on this.
the SBC must be present whenever you leave your IP network.
If you deal with residential users, and you work with a SIP Proxy, you want to hide your proxy and your internal topology from the outside. So you need an SBC there, or, speaking more precisly, one interface of the SBC must concentrate the external network traffic,
The same is true, when you do interconnection with other carriers, instead of publishing the IP address of your proxy, you provide them with (another) IP address assigned to an interface of the SBC.
The amount of SBC is dependng on the expected network traffic, and the amount of interfaces, you require. Some boxes work perfectly with logical interfaces, i.e. assign multiple IP addresses to a single physical interface.
I propose to do detailed network and traffic engineering to ensure that you select an appropriate solution.
Hope this helps.
Thanks!
Joao Pereira www.fccn.pt
Regards,
Michael
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 07:54 PM 2/6/2006, Michael Heckner wrote:
Hi Joao,
Joao Pereira schrieb:
Hi, As many of you may know, we are undertaking several tests in order to test the interoperability between several PBX IP from different vendors. Until now, we were trusting that the VoIP IP PBX were good enough to be interconnected directly, however, one of the vendors have presented the "SBC" concept. The "SBC" (Session Border Controller) is not a new concept since we were using it anyway when we setup a (Asterisk+SER+SIP Proxy) Box to handle the "on-net dialout" calls. I'm now overwhelmed with the amount of SBCs that are suggested by the vendors to implement a solution. (http://www.juniper.net/solutions/literature/solutionbriefs/351085.pdf)
Can anyone drop me some lines about this? I urgently need some feedback on this.
the SBC must be present whenever you leave your IP network.
No.
With all respect I would urge people not to use words like "must" if there is no prove for necessity. As long as I have a counterproof -- most of our customers under our consultancy, very big ISPs among those, actually don't use SBCs -- it is very easy to show how mistaken such a statement is and how optional these boxes are.
I would actually be easy to go much further. SBCs cause lot of pain. In the field some SBCs disconnected lot of subscribers because they are single point of failure and they fail. (Even if you have a pair, given the fact that both pair members use the same software and software failure is one of the most frequesnt failure causes, it happens that the complete pair fails.)
Other SBCs, faithful to the principle "to be safe, filter all things you don't understand" filtered useful valid traffic which SBC's implementors didn't foresee/understand. Which successfuly prohibited use of messaging/presence services.
I would consider money put in SBCs a poor investment. I think companies that give the money to education and bonuses of their administrative IT personal will meet better operational results.
-jiri
If you deal with residential users, and you work with a SIP Proxy, you want to hide your proxy and your internal topology from the outside. So you need an SBC there, or, speaking more precisly, one interface of the SBC must concentrate the external network traffic,
The same is true, when you do interconnection with other carriers, instead of publishing the IP address of your proxy, you provide them with (another) IP address assigned to an interface of the SBC.
The amount of SBC is dependng on the expected network traffic, and the amount of interfaces, you require. Some boxes work perfectly with logical interfaces, i.e. assign multiple IP addresses to a single physical interface.
I propose to do detailed network and traffic engineering to ensure that you select an appropriate solution.
Hope this helps.
Thanks!
Joao Pereira www.fccn.pt
Regards,
Michael
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Hello I believe the "must" was to emphasize the position of the SBC in the architecture :)
What I want to know is what software can I use to make the SBC job. A B2BUA? Is vovida B2BUA the solution to substitute the SBC? Is the payed version of SER the best solution?
My SER has a public IP, routable from the Internet..... is this an acceptable solution? Im going to deploy a very large VoIP network. Can I trust in a PBX available from the Internet???
From the pdf in attachment, I see that SBCs are not only a solution for clients, they are also a solution for telcos. For registering a lot of client SBCs, and for registering a lot of phones. Is the open source solution (I mean SER/Asterisk/B2BUA/RTPproxy) being used in telcos? Thanks Joao Pereira
With all respect I would urge people not to use words like "must" if there is no prove for necessity. As long as I have a counterproof -- most of our customers under our consultancy, very big ISPs among those, actually don't use SBCs -- it is very easy to show how mistaken such a statement is and how optional these boxes are.
I would actually be easy to go much further. SBCs cause lot of pain. In the field some SBCs disconnected lot of subscribers because they are single point of failure and they fail. (Even if you have a pair, given the fact that both pair members use the same software and software failure is one of the most frequesnt failure causes, it happens that the complete pair fails.)
Other SBCs, faithful to the principle "to be safe, filter all things you don't understand" filtered useful valid traffic which SBC's implementors didn't foresee/understand. Which successfuly prohibited use of messaging/presence services.
I would consider money put in SBCs a poor investment. I think companies that give the money to education and bonuses of their administrative IT personal will meet better operational results.
Jiri Kuthan wrote:
At 07:54 PM 2/6/2006, Michael Heckner wrote:
Hi Joao,
Joao Pereira schrieb:
Hi, As many of you may know, we are undertaking several tests in order to test the interoperability between several PBX IP from different vendors. Until now, we were trusting that the VoIP IP PBX were good enough to be interconnected directly, however, one of the vendors have presented the "SBC" concept. The "SBC" (Session Border Controller) is not a new concept since we were using it anyway when we setup a (Asterisk+SER+SIP Proxy) Box to handle the "on-net dialout" calls. I'm now overwhelmed with the amount of SBCs that are suggested by the vendors to implement a solution. (http://www.juniper.net/solutions/literature/solutionbriefs/351085.pdf)
Can anyone drop me some lines about this? I urgently need some feedback on this.
the SBC must be present whenever you leave your IP network.
No.
With all respect I would urge people not to use words like "must" if there is no prove for necessity. As long as I have a counterproof -- most of our customers under our consultancy, very big ISPs among those, actually don't use SBCs -- it is very easy to show how mistaken such a statement is and how optional these boxes are.
I would actually be easy to go much further. SBCs cause lot of pain. In the field some SBCs disconnected lot of subscribers because they are single point of failure and they fail. (Even if you have a pair, given the fact that both pair members use the same software and software failure is one of the most frequesnt failure causes, it happens that the complete pair fails.)
Other SBCs, faithful to the principle "to be safe, filter all things you don't understand" filtered useful valid traffic which SBC's implementors didn't foresee/understand. Which successfuly prohibited use of messaging/presence services.
I would consider money put in SBCs a poor investment. I think companies that give the money to education and bonuses of their administrative IT personal will meet better operational results.
-jiri
If you deal with residential users, and you work with a SIP Proxy, you want to hide your proxy and your internal topology from the outside. So you need an SBC there, or, speaking more precisly, one interface of the SBC must concentrate the external network traffic,
The same is true, when you do interconnection with other carriers, instead of publishing the IP address of your proxy, you provide them with (another) IP address assigned to an interface of the SBC.
The amount of SBC is dependng on the expected network traffic, and the amount of interfaces, you require. Some boxes work perfectly with logical interfaces, i.e. assign multiple IP addresses to a single physical interface.
I propose to do detailed network and traffic engineering to ensure that you select an appropriate solution.
Hope this helps.
Thanks!
Joao Pereira www.fccn.pt
Regards,
Michael
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Michael Heckner wrote:
Hi Joao,
Joao Pereira schrieb:
Hi,
As many of you may know, we are undertaking several tests in order to test the interoperability between several PBX IP from different vendors. Until now, we were trusting that the VoIP IP PBX were good enough to be interconnected directly, however, one of the vendors have presented the "SBC" concept.
The "SBC" (Session Border Controller) is not a new concept since we were using it anyway when we setup a (Asterisk+SER+SIP Proxy) Box to handle the "on-net dialout" calls.
I'm now overwhelmed with the amount of SBCs that are suggested by the vendors to implement a solution. (http://www.juniper.net/solutions/literature/solutionbriefs/351085.pdf)
Can anyone drop me some lines about this? I urgently need some feedback on this.
the SBC must be present whenever you leave your IP network.
Ok, but can I do the same with a B2BUA in my SER/Asterisk box?
If you deal with residential users, and you work with a SIP Proxy, you want to hide your proxy and your internal topology from the outside. So you need an SBC there, or, speaking more precisly, one interface of the SBC must concentrate the external network traffic,
The same is true, when you do interconnection with other carriers, instead of publishing the IP address of your proxy, you provide them with (another) IP address assigned to an interface of the SBC.
The amount of SBC is dependng on the expected network traffic, and the amount of interfaces, you require. Some boxes work perfectly with logical interfaces, i.e. assign multiple IP addresses to a single physical interface.
Yes, thats something I can put in my SER/Asterisk box, instead of buying some proprietary SBC.
I propose to do detailed network and traffic engineering to ensure that you select an appropriate solution.
Do you know where can I find more information about VoIP WAN deployments? I want to know if the SBC is the only solution, or if it is the market demanding solution. Thats because I m already calling outside my LAN, and doing trunking with telcos, without the SBC....
Joao Pereira FCCN
There is great pressure from large vendors of boxes to use Session Border Controllers. SBCs is one of the few, new big "new product class" opportunitites for network equipment providers (as well as VoIP/video equipment providers). The marketing machines of these giants have been quite successful at scaring others to design recommended interconnect etc using SBCs. Why is that?
IMHO, there are several reasons: 1. Traditional telcos and operators are used to "walled garden" setups and are mighty uncomfortable with alternative ways of handling traffic over their network edges 2. Sometimes it easier (and faster) to throw hardware at a problem (the "magic fix-it box") instead of upgrading competence and people. You contain a set of rather technical issues in a box and you have somebody to blame (the vendor) 3. The telco industry is highly reliant on the equipment and software vendors. Over years, there has been established a perception in the industry (also among executives) that unless you control and manage the full stack, from end-to-end, you are not taking seriously the threats to security and service outage ("hiding your internal topology" is a typical security argument that sometimes/often translates to "internal servers/boxes = no security", "public servers/boxes = security deliver by vendor") 4. Using SBCs you can control in more detail media streams, signalling, etc and some telcos and operators actually has something to gain from that. They want to charge for the video conference service, not allow multiple, concurrent and uncharged mediastreams between endpoints.
In fact, some SBCs started out as something like SER+rtpproxy + a nice web interface (maybe even in implementation ;-). Then they added all sorts of options and control niceties. Many SBCs' implementations have (as Jiri pointed out) bugs, simplistic implementations, and will most definitely over time constitute a large part of the cost of a roll-out for many telcos. You see the same problem in smaller scale with Application Layer Gateways (ALGs) in NATs and firewalls. Also, the firewalls look into more and more packets on the application layer. A simple change (or new combination of options) in the application layer protocol will cause problems when the ALG does not understand. See the business opportunity for vendors? (Software maintenance is already a large part of equipment manufacturers' revenues.)
IMO, there will be two different approaches: Some will use SBCs, some will not. Those who don't will increase their competence and gain experience that will help them every time a new service is brought the market. The SBC users will have trouble with "time-to-market" compared to non-SBC users. Both models may be successful dependent on the market they serve.
Jiri's post describes very well how SBCs in the long run can be a greater cost than benefit.
So, to the recommendations (yes, free ;-): - If the endpoints are routable on the public Internet anyway (or behind a NAT with a public address), why do you need to hide your topology? (that's one of the big problems for mobile operators as phones with Internet connection can get services and "only" pay for bandwidth...) - Need for a quick, get-started, basic service with interconnect, NAT handling etc and have enough money: Go for SBCs (or use the SER - Getting Started document from ONsip.org if you don't have the money ;-) - You're business model is based on tightly controlled services (charged per service/option) with high service level agreement and slow introduction of new services: Go for SBCs - If you expect to introduce new services quickly, experiment with what sticks, want to have a flexible pricing model for bundles etc: Drop the SBCs
So, regarding interconnect: There will be providers who require SBCs (or recommend). Go for those without, if you don't use them yourself. (or maybe more important: do your business models fit?)
g-)
----- Original Message ----- From: "Joao Pereira" joao.pereira@fccn.pt To: "Michael Heckner" ser@michas-zuhause.de; "Rui Ribeiro" racr@fccn.pt; serusers@lists.iptel.org Sent: Monday, February 06, 2006 9:58 PM Subject: Re: [Serusers] Deploying VoIP on a WAN
Michael Heckner wrote:
Hi Joao,
Joao Pereira schrieb:
Hi,
As many of you may know, we are undertaking several tests in order to test the interoperability between several PBX IP from different vendors. Until now, we were trusting that the VoIP IP PBX were good enough to be interconnected directly, however, one of the vendors have presented the "SBC" concept.
The "SBC" (Session Border Controller) is not a new concept since we were using it anyway when we setup a (Asterisk+SER+SIP Proxy) Box to handle the "on-net dialout" calls.
I'm now overwhelmed with the amount of SBCs that are suggested by the vendors to implement a solution. (http://www.juniper.net/solutions/literature/solutionbriefs/351085.pdf)
Can anyone drop me some lines about this? I urgently need some feedback on this.
the SBC must be present whenever you leave your IP network.
Ok, but can I do the same with a B2BUA in my SER/Asterisk box?
If you deal with residential users, and you work with a SIP Proxy, you want to hide your proxy and your internal topology from the outside. So you need an SBC there, or, speaking more precisly, one interface of the SBC must concentrate the external network traffic,
The same is true, when you do interconnection with other carriers, instead of publishing the IP address of your proxy, you provide them with (another) IP address assigned to an interface of the SBC.
The amount of SBC is dependng on the expected network traffic, and the amount of interfaces, you require. Some boxes work perfectly with logical interfaces, i.e. assign multiple IP addresses to a single physical interface.
Yes, thats something I can put in my SER/Asterisk box, instead of buying some proprietary SBC.
I propose to do detailed network and traffic engineering to ensure that you select an appropriate solution.
Do you know where can I find more information about VoIP WAN deployments? I want to know if the SBC is the only solution, or if it is the market demanding solution. Thats because I m already calling outside my LAN, and doing trunking with telcos, without the SBC....
Joao Pereira FCCN
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Greger V. Teigre -
Jiri Kuthan -
Joao Pereira -
Michael Heckner