Hi there, I believe that the main idea of this article is that the SBC does not necessary need to be an integral part of WebRTC gateway solution, because some of SBC key features are whether not used or implemented by WebRTC or other elements beyond SBC. For example, let’s take a look at the following SBC key features: Sip-to-SIP translation, or SIP normalization: Not needed for WebRTC gateways, since it uses Web-to-Sip Web-to-Sip : May be done by other network element, or may be implemented by the WebRTC server itself, like it is done in XMS NAT traversal (this may also address WAN to LAN concern): Provided by XMS TLS/ SRTP: Included in XMS IPv4 to IPv6 Supported by XMS As far as media is concern, indeed, WAN congestions must be considered when architecting WebRTC solutions. One of the issues here is to use QoS/ToS to give the most priority to voice, throttling video and data on congested networks. I may be outdated here, but I don’t think that media content discrimination is commonly used in SBCs at present, so looks like we don’t get much SBC’s help here, either. I'd add that there may be situations where the inclusions of SBC may simplify deployments in some application flows or network topologies, but there is often a way it can be made to work without it as well and then comes down to a design choice rather than necessity.
↧