[Serusers] Deploying VoIP on a WAN

[Joao Pereira]

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 at lists.iptel.org
>>>http://lists.iptel.org/mailman/listinfo/serusers
>>>      
>>>
>>_______________________________________________
>>Serusers mailing list
>>serusers at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
>>    
>>
>
>--
>Jiri Kuthan            http://iptel.org/~jiri/ 
>
>
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SBC_juniper.pdf
Type: application/pdf
Size: 287554 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060206/bbf86a00/attachment.pdf>