The SBC evolution toward media

The SBC evolution toward media

  • Comments 2
  • Likes

 As networks grow, session border controllers need to do more in order to keep pace. There’s no reason why SBCs shouldn’t incorporate the functions of a media server. SBCs came into their own as edge devices that could insulate one IP network from another. This applies to both enterprise IP-IP networks, service provider IP-IP networks, and enterprise/service provider IP networks.  There are even different names for SBC use cases, such as peering SBCs and access SBCs.

Dialogic long believed that SBCs would someday begin incorporating media transcoding. After all, media gateways are edge devices that translate signaling to and from one network, to and from another network. They also transcode media from one type of format to another media format between networks. So, it wasn’t a stretch to reason that media transcoding would find its way into the SBC. 
Now, in a theoretical IP multimedia system (IMS) network, one could argue that transcoding “shouldn’t” happen in the SBC since it would typically occur in the media server or media resource function (MRF).  But not all networks, even IP networks, are IMS networks. And all IMS networks aren’t theoretical IMS networks. Practicality, amazingly enough, enters the picture.
Let’s examine some use cases where transcoding as part of the SBC would make sense. First of all, while one could create a type of WebRTC gateway that only involves signaling and SRTP/RTP conversion, some SBCs are also evolving into WebRTC gateways. At the same time, it would also make sense to include Opus and VP8 transcoding to non-WebRTC audio and video codecs in the same node.  
LTE networks will require SBCs, since they are based on IP. As we move to VoLTE, we’ll also see more and more AMR-WB (HD Voice codec) to G.711 IP or G.729 conversion. In LTE networks, there will likely also need to be video transcoding, transrating or transsizing requirements. The enterprise, also protected by SBCs, typically uses another form of HD Voice codec internally, possibly G.722.1. As the voice exits the enterprise through the SBC, codec conversion will also need to occur.
As you can see, it makes sense for media transcoding to occur in the SBC instead of a media server. Dialogic has recently included native transcoding in our SBC for these very reasons. Incorporating the field-proven and time-tested transcoding from a media server makes sense. Our heritage helps us bring this technology into SBCs, which allows us to support new codecs in the SBCs quickly as well.
Views: 4094
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Jim,

    you mention key points such as VP8 and Opus that are being widely adopted, but we don't see yet any Dialogic product supporting those, neither WebRTC/XMS media server and neither SBCs. why is Dialogic avoiding to be the leader in this area?