Talk:Session border controller

message: 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)
thread_title: article really bad

message: 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)
thread_title:  Remove "To date STUN, TURN, ICE and others have not seen wide deployment, and their complexity leaves much to be desired. "  

message: 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)
thread_title:  Some nuances 

message: Please somebody clarify. --Jangirke (talk) 02:52, 17 December 2013 (UTC)
thread_title:  What is a peering environment?