当今的网络和设备中使用了大量不同的语音和视频编码算法或编解码。多年来，编解码已经开发出来，以适应各种目的; 一些被设计为减少带宽消耗 (例如iBLC、G729ab和AMR这样的窄带编解码)，而另一些被设计为提供卓越的语音质量 (例如，AMR-WB、G.722和Opus等宽带编解码)，如下图所示。

　　世界上所有领先的服务提供商都推出了端到端高清语音服务，因此所有终端之间媒体互通是必要的。   例如，对于高清语音服务，WebRTC使用Opus，企业有线使用G.722，而无线网络可能使用AMR-WB。这些不同端点的互通将需要在这些HD编解码之间进行媒体转码。随着移动通信的发展以及诸如WebRTC之类的技术继续获得认可，还将开发新的创新编解码器来支持它们。编解码的激增将对服务提供商提出更高的要求，以支持其网络中新编解码和旧编解码的媒体互通。

　　为了满足媒体转码的需求，服务提供商使用SBC提供转码以及广泛的其他媒体处理功能，例如: 媒体监管和门控; 媒体格式转换和流管理; 传真和DTMF检测和生成; 带内到带外DTMF转换; 和静音抑制。

　　即使是像传真音调检测这样的简单要求，也需要对媒体流进行解码和分析。在SBC硬件中进行语音呼叫转码的能力有助于简化服务提供商的通信流程，并提供高性价比且可靠的方式进行实时通信。但高会话数的实时语音和视频呼叫需要密集的计算，随着媒体互通需求的增加，这将给媒体处理功能带来额外的负担。

　　为了满足媒体互通要求，SBC历来使用基于硬件的数字信号处理器 (DSP)，但是在云原生解决方案中，基于硬件的DSP不适合软件的部署模型。  这些选项变成使用中央处理单元 (CPU)或图形处理单元 (GPU)来替代，正如我们将展示的那样，这就是GPU闪耀的地方。

　　通信服务提供商提供云原生实时通信的能力将在很大程度上取决于下一代媒体处理平台的能力及其对各种编码的支持。我们认为，云原生的媒体转码解决方案意味着它是为虚拟云部署设计的，利用了基于云的应用程序的纯软件、分布式、动态、可编排的特性。

　　对于Ribbon SBC，这意味着采用微服务体系结构将核心SBC应用程序组件分发到信令，媒体和转码中。这使得能够根据每个组件的规模、成本和性能独立选择技术。Ribbon SBC微服务体系结构和可用的技术选择如下图2所示

　　在云环境中，支持虚拟云环境中的媒体转码主要有两种选择: CPU和GPU

　　英特尔x86是一款通用CPU，它可以支持媒体互通所需的矢量计算，也支持与媒体处理无关的大量附加指令。因此，英特尔x86在功率和性能方面通常都不太有效，尽管英特尔在其最近的CPU体系结构演变中继续加强矢量算术功能。

　　然而，即使使用最好的处理器，基于CPU的转码解决方案也比使用专用DSP处理的同时转码的会话数量少得多。在成本、转码、功率效率和机架空间方面，DSP比CPU有更高效率和性价比。一个基本的估计是，与英特尔CPU相比，现代DSP可以产生每瓦信道吞吐量的五倍或更多倍。然而，在纯软件环境中，基于CPU的媒体互通仍然为用户提供了某些好处。

　　GPU是高性能的多核处理器，能够非常高的计算和数据吞吐量。曾经很难编程，但是今天的GPU是通用并行处理器，支持可访问的编程和C语言等借口。在并行化计算的情况下，将其应用程序移植到GPU的开发人员通常会比优化的CPU实现速度提高几个数量级。