[VOIPSEC] Session Border Controller use

[Hadriel Kaplan]

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Dorgham Sisalem
> Sent: Thursday, June 22, 2006 4:06 AM
> To: micaela giuhat
> Cc: 'Kaalund, Bruce'; Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Session Border Controller use
> 
> Hello
> 
> On Wednesday, June 21, 2006 at 3:46 PM your wrote:
> 
> mg> Bruce,
> 
> mg> 1. You don't need an SBC for handing calls to the PSTN.
> right, the PSTN gateway are hidden behind the proxy and should be
> configured in such a manner as to only accept signaling traffic coming
> from the
> proxy
> mg> 2. You will need an SBC between the two networks. The best placement
> will be
> mg> before the layer 2 switch on the hosting center (as close to the edge
> as
> mg> possible).
> 
> I am not sure what the added value of SBC might be here. If we want to
> secure the communication between two peer networks then there are
> already standardized tools based on TLS or IPSEC. 

TLS and Ipsec are encryption and/or authentication mechanisms between 2
points.  That's it.  If that's what you think is synonymous with security,
and all you think is required to secure a peering border (or access, or
anything), then sure you could do them on a proxy or the softswitch or
whatever.  


> An SBC would only
> increase
> the complexity and add unnecessary delay and processing. Not even
> 3GPP IMS suggest using SBC for network boundaries

Actually, they do.  They specify functions, not equipment.  The
IBCF/IWF+I-BGF functions are an SBC on the peering side, and P-CSCF+C-BGF
are an SBC on the access side.  They can be decomposed or integrated, that's
up to the operator to decide.  Of course most SBCs do more than those
functions, for a lot of reasons.


> mg> 3. SBCs are mainly use to solve demark issues such as FW and NAT
> traversal,
> IETF has already provided a set of solutions allowing NAT traversal of
> all kinds. Using an SBC would mean using the most complex
> approach for NAT traversal always. This will not only increase the
> complexity
> and costs of the network but also might increase the delay and
> interoperability problems.

Yeah right.  Exactly how many deployments of STUN/TURN/ICE/Outbound are
there?  Have you read the drafts?  And you think the way SBCs solve it is
more complex than that???


> mg> as well as provide session admission control,
> SIP already provides sufficient admission control (I do not think
> that a proxy can do more here than the proxy behind it could do)

SIP is a protocol, not a piece of equipment.  SBCs are typically not
proxies, and usually can do more than a proxy behind them for admission
control, but obviously that depends on the proxy's capabilities.  You
definitely don't have to be an SBC to do admission control, it's just
something they also do and have been doing for a long time.


> mg> session detail records,
> Session records are best collected at PSTN gateways 

Most service providers collect them at multiple places.  Not all calls go
to/from their PSTN gateways (and hopefully even less in the future).  Most
service providers I've seen seem to use the ones generated by their
softswitch/S-CSCF for actual billing purposes, but collect them from many
elements for tracking, auditing, and troubleshooting purposes.


> (for the SBC to
> provide CDRs with the same level of accuracy it would have to also
> route media traffic. This would in general mean longer media paths
> -i.e., higher delay-, even higher hardware costs and a more complex
> network architecture

Only for non-infrastructure providers. (i.e., ones without a physical
network) 


> mg> QOS mediation
> I am not sure how a component in the middle of the network will be
> capable of improving any QoS? If the parts of the network before it or
> behind lose packets then the SBC will not be able to do anything about
> this. The only thing an SBC could do is to smooth out jitter, but this
> can only be achieved by adding more delay (i.e.,  possibly
> reducing the QoS)

Then you're not thinking of it in terms of routing.  Routing doesn't follow
the shortest physical path, the least jitter path, nor the highest bandwidth
path (although it typically does do this last bit in an IGP because
costs/metrics are typically set to reflect link speed, but it's not
necessarily available bandwidth).  An interesting property of an SBC in
terms of media relaying is that you always know the source and/or dest
addresses of the media, and it can steer the media and mark it, put it in a
different VLAN, etc.  So if you own the network infrastructure, you can use
that to your advantage and provide either diffserv, policy routing, or
MPLS-TE engineered paths that are only available/used for media and not
best-effort data.  In effect you can make the media go a non-best-effort
path which is better, if you wish to, and yet control what traffic and what
amount of it gets into those engineered paths.  Note that most SBCs in the
service provider market do media-relaying in hardware with the same
jitter/latency as one router hop.  

-hadriel