Talk:Session border controller

article really bad

I came here to learn what an SBC is, instead, what I read was lots and lots of attempts in trying to describe what an SBC is supposed and not supposed to accomplish, what people use it, etc. Its essentially the description of the common usage, intended deployment and controversity about a blackbox, which adds nothing to a proper definition and understanding about this device. I suggest first things first, define what an SBC is, e.g. these and these NAT rules are performed, this and that packetfiltering is done, etc. (or whatever it actually does) and after that, additional information like seen on the current page can be added. 88.152.88.23 (talk) 12:54, 15 March 2013 (UTC)

---QUESTION----
I was wondering, among all the functions performed by the SBC, doesn't it also encompass the functions of a Signaling Gateway? If we are using an SBC at the edge of a signaling network (say SIP to PSTN), then does it convert signaling information from SIP to ISUP?
---QUESTION----

There is no content about how the voip end terminal connect to the SBC. I wonder if the user need configure the SBC ip in the voip terminal as the proxy or agent? Or can the SBC scan all the data package into the network to find out the SIP / H323 call and modify the IP or other information in the package?

---

In answer to your question, it's the former. The SIP endpoint is provisioned to know about (or has other means to discover) the SBC. Danfreedman 15:04, 28 June 2007 (UTC)

---

Most SBC's are configured as B2BUA's. The end user has no idea that he's connecting to an SBC. To him it just looks like a server UA. Part of the security given by an SBC is the topology hiding that this creates.

>>Or can the SBC scan all the data package into the network to find out the SIP / H323 call and modify the IP or other information in the package?<<

No it can't. Any more than any other kind of networking application could do that. The SBC sits at the network edge - it is the point of entry for all traffic destined for the network sitting behind it. Hence the "border controller" aspect of the name.

There's a good piece about this here by a Dialogic employee : http://www.voipuser.org/forum_topic_10099.html

• The above piece is a pure marketing document; the discussion of the technology is completely misguided. Some highlights of the silliness: "[SBC provides] protection against denial-of-service (DoS) attack at the SIP interface", by providing a central element to DoS to stop all SIP communications? "overcoming connectivity difficulties such as getting past NAT or firewall devices", on the contrary SBCs create new connectivity difficulties, e.g. by breaking standardised NAT traversal mechanisms.

• I don't see the marketing angle, although perhaps I've missed something in there. I can however guide you on the technology aspect of the discussion: "by providing a central element to DoS to stop all SIP communications?" - all client/server type network topologies have central elements. That's what DoS attacks typically try and concentrate on. If you remove any kind of edge controller (such as an SBC) the central elements in a SIP network are the registrar proxies (open-source examples of these are openSER and SER). Edge controllers fronting a registrar use extremely fast operating authentication systems in order to deal with brute force attacks more quickly than a registrar can handle. This is a fairly widely adopted means of handling DoS attacks. See http://en.wikipedia.org/wiki/Denial-of-service_attack#Prevention_and_response and in particular information regarding stateful packet filtering. "on the contrary SBCs create new connectivity difficulties, e.g. by breaking standardised NAT traversal mechanisms." - SBC's that assist with NAT traversal do use standardised traversal mechanisms (STUN and TURN are typical of these), but typically have audio and signalling proxying capabilities for the times when STUN and TURN will not help (two full cone NAT devices in the middle of a call for example). Most SBC's will therefore perform a sequence of NAT traversal attempts using ICE (combination of STUN and TURN) and fallback to a proxy mode in the event of a failure. The Ditech devices work in this way, for example.

All that cleared up the below point is valid. SBC vendors are struggling, and a large part of that struggle comes from the fact that registrar proxies are becoming more and more lean and able to deal with an attempted DoS attack and NAT is becoming less of an issue. IPv6 is likely to end the NAT traversal problem in due course. —Preceding unsigned comment added by 81.130.24.114 (talk) 12:05, 1 February 2009 (UTC)

Reported Newport troubles

The SBC as a concept is having a difficult time in the market. Newport's results indicate that difficulty. The standalone SBC is a concept that has not taken root. One thing that always amuses me is how Internet services follow the same curve to obscurity. - Conception - usefulness - taken over by "regulars - obscurity. —Preceding unsigned comment added by 66.82.9.14 (talk) 19:34, 13 July 2008 (UTC)

You may be right, but I had two reasons to revert you paragraph:

1. Your source is not notable, as nobody should be forced to uncover personal data to continue reading
2. did you read Wikipedia:NOTCRYSTAL?

A short statement about the possible difficulties of Newport with a readable source could be acceptable. Brgds.--Kgfleischmann (talk) 19:49, 13 July 2008 (UTC)

Remove "To date STUN, TURN, ICE and others have not seen wide deployment, and their complexity leaves much to be desired. "

I removed this sentence for two reason:

1. At least STUN can be used by most clients today.

2. A standalone SBC (one that is not integrated in the NAT router) has to use the very same mechanism for NAT traversal. 62.134.46.5 (talk)

Some nuances

I'm a little out of practice in SBCs, but can tell you that the "hosted" or "far-end" NAT traversal available in 2002 on the Jasomi Networks boxes did not use quite the same method as STUN. While similar, the major difference was that in the Jasomi case, the burden of discovering the firewall NAT pinhole maintenance schedule was on the SBC in the cloud, whereas with STUN it is on the behind-the-firewall SIP device. Far-end or hosted NAT traversal solutions required no a priori knowledge of the firewall(s) between it and the clients it served. And the clients also required no knowledge of them whatsoever.

Bottom line: I absolutely agree with the edits you made. But your second point above is not correct because the mechanism previously used by some SBCs was not the same one used by STUN, although it achieved the same ends. I presume it was a major influence for those who created STUN and TURN, or perhaps STUN/TURN came along later, completely independently. Danfreedman (talk) 14:00, 26 February 2010 (UTC)

What is a peering environment?

Please somebody clarify. --Jangirke (talk) 02:52, 17 December 2013 (UTC)