web rtc infrastructure the hard parts v4

COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.1

COMPANY CONFIDENTIAL © COPYRIGHT 2015 DIALOGIC CORPORATION. ALL RIGHTS RESERVED.

WebRTC Infrastructure:THE HARD PARTS

WebRTC Global Summit


Why Terminate Media?

NAT Traversal: TURN Gateway Media Server




TURN Server

TURN for NAT Traversal




Gateway for Interworking

Web signaling

WebRTC media

SIP

VoIP media

GW SIP




Media Servers for…


Many Reasons for a Media Server

Conferencing InterworkingTranscoding

Stream processingRecording Person-to-machine


Why process media server-side?


Many Reasons for a Media ServerConferencing

Conferencing


Mesh model does not scale

Distributed peer-to-peer mesh Centralized with media server


Many Reasons for a Media ServerTranscoding

Transcoding

Transcoding: because we live in an imperfect world


Many Reasons for a Media ServerServer Side Media-Processing

Server-side media handling for:

Application work-flows

Security

Compliance

Performance

Reliability

Stream processingRecording Person-to-machine


Add value to terminated media

+

Today• Audio & video conferencing• Multi-camera switching• Compliance recording• Speech detection• Audio/video insertion• Speech recognition• Automated IVR navigation• Speaker CDR analytics

Not too far away• Live RTC stream distribution• Facial recognition• Voice fingerprinting• Health biometrics• Object detection• Machine vision• Sentiment analysis• Augmented reality


Many Reasons for a Media ServerConferencing

Conferencing


Traditional MCU Resource Usage

Worst-case process:1. Each stream

decoded at the MCU

2. MCU mixes each conferee

3. MCU encodes individual mix for each conferee

MCU

11 2

23

34

455

66

Ingress streams 6

Egress streams 6

MCU decodes 6

MCU encodes 6


Efficient MCU Resource Usage

Efficient process:1. Each stream

decoded at the MCU

2. MCU mixes each conferee

3. MCU shares same encoder for all conferees

MCU

12

3

45

6

Ingress streams 6

Egress streams 6

MCU decodes 6

MCU encodes 1

1

30%-50% reduction in compute resources


Newer Approach: SFU

SFU

Selective Forwarding Unit (SFU) routing

Clients send one & receive many

Client can instruct SFU which streams to send

High throughput

Can be lots of downlink bandwidth

Low latency


New WebRTC Approach: Simulcast

SFU

High bitrate

Low bitrate

Selective Forwarding Unit (SFU) with Simulcast

Clients send multiple streams to SFU

one high-bit rate

one or more lower-bit

Client directs SFU which streams to receive

Reduces bandwidth vs. SFU

Simulcast in WebRTCcoming


Future Approach with VP9 – SVC?

SFU

MediumHigh LowLayered bitrates:

Selective Forwarding Unit (SFU) with Scalable Video Coding (SVC)

Clients send layered stream to SFU

Layers have varying bitrates –time, size, quality

SFU directs who gets what

Coming to WebRTC eventually


Media server network model

Load BalancerMRB

Client Client Client Client Client Client

App ServerApp ServerApp Server

Media Server

Media Resource Broker:Intelligent load balancer & orchestration for media servers


Pseudo Call-flow with a media server

AS MRB MS1 MS2 Client

Call signaling

Media control

MS1 status

MS2 status

Media control Media


Pseudo Call-flow – traditional fail-over with RE-INVITE


Call signaling – REINVITE with new addresses

Media control

MS1 status

MS2 status

Media control + call states

Media


Pseudo Call-flow – fail-over the cloud/NFV way


Media control

MS1 status

MS2 status

New container

Media

Memcache & Virtual IP Address


Conclusions

Terminating media isn’t cheap, so avoid it if you can

Like it or not, you will probably need server-side media sometimes

If you need server-side media, maximize the value you get from it

Architectures are evolving to make media-processing more efficient & scalable

web rtc infrastructure the hard parts v4

Documents