11/25/2013

1

WebRTC Monitoring and Alerting

David A. Bryan Assistant Professor, Computer Science St. Edward’s University dbryan@ethernot.org @davidbryan

11/25/2013

2

Speakers

• Chris Cavigioli

– Strategy Planning

– Intel MCG

• Varun Singh

– Co-founder

– callstats.io

11/25/2013

3

IMPACT OF TRANSCODING LATENCY TO USER EXPERIENCE CONNECTING WEBRTC TO 3GPP/IMS

Chris Cavigioli

Strategy Planning

Intel Mobile and Communications Group (MCG)

11/25/2013

4

Latency is critical for conversational uses cases. Long latency results in “double-talking”, making conversation difficult.

VoIP Latency

11/25/2013

5 Source: “Understanding Latency in IP Telephony”, Alan Percy, Brooktrout, Embedded Computing Design, July 2000, http://embedded-computing.com/article-id/?76#

VoIP Latency Measurements

11/25/2013

6

Source (Table 9, Fig.3): “Mouth-To-Ear Latency in Popular VoIP Clients”, Agastya, Mechanic, and Kothari, Columbia University, July 2009, http://bit.ly/1ed6imm

Source: (Fig.1) “Understanding Latency in IP Telephony”, Alan Percy, Brooktrout, Embedded Computing Design, July 2000, http://embedded-computing.com/article-id/?76#

Latency Limits in 3GPP

11/25/2013

7

Source (Table 1): 3GPP TS 22.105 (Rel.11), Nov 2012, http://www.etsi.org/deliver/etsi_ts/122100_122199/122105/11.00.01_60/ts_122105v110001p.pdf

Source (Fig.1): “Understanding Latency in IP Telephony”, Alan Percy, Brooktrout, Embedded Computing Design, July 2000, http://embedded-computing.com/article-id/?76#

UE #2

UE #1

Audio/Video “AV” Transcoding

11/25/2013

8

WebRTC2IMS Gateway

WebRTC Client

IMS N

etw

ork

Opus Encode

Opus Decode

VP8 Encode

VP8 Decode

VP8 Dec

VP8 Enc

H.264 Enc

H.264 Dec

Opus Dec

Opus Enc

AMR-WR Enc

AMR-WB Dec

IMS Client

AMR-WB Dec

AMR-WB Enc

H.264 Dec

H.264 Enc

UE #1 must support 12 codecs instead of 4

• 6 concurrent video codecs in parallel and

• 6 concurrent audio codecs …simultaneously

Codec Latencies add Extra RTD

11/25/2013

9

Function H.264 assumes supports of up to 1080p60, then each frame has up to 16 ms max to complete. VP8 = 1080p30, thus 33 ms

Codec Delay (ms) 320x240p30

Level 1.2 720p30

Level 3.1 1080p30 Level 4.1

A = H.264 decode 16/27 (=0.6 ms) 7.1 = 16/2.25 16 max B = VP8 encode 1.2 15 = 33/2.25 33 max C = VP8 decode 1.2 15 33 max D = H.264 encode 0.6 7.1 16 max H.264 decode + VP8 encode [A+B] =1.8 ms =22 ms =49 ms VP8 decode + H.264 encode [C+D] =1.8 ms =22 ms =49 ms Extra RTD, based purely on V codecs =3.6 ms =44 ms =98 ms 1 frame period @ 30 fps 33 ms 33 ms 33 ms 1 frame period @ 60 fps 16 ms 16 ms 16 ms

Function Delay

A = AMR-WB decode 20 ms B = Opus encode 20 C = Opus decode 20 D = AMR-WB encode 20 AMR-WB decode + Opus encode [A+B] =40 ms Opus decode + AMR-WB encode [C+D] =40 ms Extra RTD, based purely on A codecs =80 ms

Additional

round-trip delay (RTD) incurred purely by transcoding

2x (decode + re-encode)

Implementation-agnostic numbers based on worst case

to maintain frame rate

Call for Action

• Latency is #1 concern for best conversational user experience

• 3GPP, operators target 200-150 ms for VoLTE (and IR.94 video)

• Transcoding adds – Up to 49 ms video or 40 ms audio in parallel for codec delays

– Extra 49 or 40 ms “frame slips” to re-align audio-video mismatches

– Additional 30 ms delay for jitter buffer in network-based transcoder

– Users perceive Round Trip Delay (RTD) which doubles end-to-end delay

• To preserve end-user experience, AVOID transcoding altogether

• End points MUST be able to negotiate and pick identical codecs

11/25/2013

10

11/25/2013

11

Chris.Cavigioli@Intel.com +1 415 254 4545

PERFORMANCE MONITORING OF MEDIA FLOWS IN WEBRTC

Varun Singh

Co-founder, CEO

callstats.io

11/25/2013

12

Recap: WebRTC

Browser Internals

(WebRTC Stack)

Browser Internals

(WebRTC Stack)

WebRTC API WebRTC API

APP APP

WebRTC Server

Signaling Protocol (e.g., SIP, Jingle, …)

PeerConnection SRTP/DTLS/UDP Data/SCTP/DTLS/UDP

13

Latency kills

14

http://geek-and-poke.com/

Berlin-Helsinki

15

0

500

1000

1500

2000

2500

3000

0 50 100 150 200 250 300

Del

ay V

aria

tion

[ms]

time [s]

audio

video

Calls between TU Berlin- Aalto Univ. Helsinki

…but on a bad day

0

500

1000

1500

2000

2500

3000

3500

4000

0 50 100 150 200 250 300 350 400 450 500

De

lay V

ari

atio

n [

ms]

time [s]

16

… and this is just audio

Monitoring

• Annoyances – Call setup time, call failures, NAT traversal

• Transport quality – Relayed or not

– Session throughput, delay and loss

• Per-stream media quality – MoS, User feedback

17

PeerConnection

Browser Internals

(WebRTC Stack)

WebRTC API

APP

Browser Internals

(WebRTC Stack)

WebRTC API

APP

• TURN

• Gateway

WebRTC Server

Monitoring Architecture

Monitoring Server

Clie

nt

Mo

nit

ori

ng

STAT

S A

PI

18

HTTP,

IPFIX, or

NetFlow

Stats API

• Web app queries underlying RTP stack – Per stream statistics (e.g., Audio and Video) – In-bound and out-bound statistics

• Identifiers – RTCP RR – ICE candidates, …

• Query at application defined intervals – Typically, 1s

19

http://tools.ietf.org/html/draft-alvestrand-rtcweb-stats-registry http://tools.ietf.org/html/draft-singh-xrblock-webrtc-additional-stats

StatsAPI: Example

20

var statCollector = setInterval(function () {

if (pc && pc.getRemoteStreams() && active == true) {

if (pc.getStats) {

pc.getStats(onStatsSuccess);

} else {

log('No stats function. Use Chrome >24.0.1285');

}

}

}, 1000);

onStatsSuccess = function (stats) {

// parse the stats.result()

// Audio and Video stats

// Local and Remote stats

} http://dev.w3.org/2011/webrtc/editor/webrtc.html#example

RTCP Monitoring

• Needs support in the WebRTC Stack

• implement RTCP Extension Reports

• Send XRs to a performance monitoring server

21 http://tools.ietf.org/html/rfc6792

Detecting WebRTC flows

• Multiplexing helps – TURN server – WebRTC Gateway

• observe 2 or more categories of packets – STUN messages – DTLS packets – RTP packets

• Audio frames (ptime between 10-30ms) • Video packets (at least 7 frames per second)

22

Implemented in https://github.com/vr000m/ConMon (Connection Monitor)

Receive

UDP Packet

H->

Par

se f

irst

8-b

its

of

UD

P P

aylo

ad

H < 2 0b00 STUN Message 0b01 ChannelData Message (TURN) -> Parse Recursively

19 < H < 64

DTL

S P

roce

ssin

g

Forward to RTP Processing 127 < H < 192

SCTP

DTLS

Packet Monitoring (1/2)

23

Implemented in https://github.com/vr000m/ConMon (Connection Monitor)

Receive

RTP Packet

Pars

e S

SR

C

SSRC #1

SSRC #N

Pars

e P

T

Pars

e P

T

0 < PT < 72 76 < PT < 128

191 < PT < 255 RTCP

RTP

media

FEC…

retx

…

same

as

above

…

media

Codec #1

Codec #2

Codec #3

FEC…

retx

24

Tying it together

• Endpoints monitor their calls – observe raw stats: loss, delay

– Build a QoE model

• Diagnosing by analysing transport – G.1070 for video, P.1201.2 for audio

• Cloud monitoring across calls – http://www.callstats.io

25

Conclusions

• Tools for Performance monitoring

– WebRTC’s StatsAPI

– Packet capture

• Bonus tip: Coupling getUserMedia() constraints

and stats APIs

• Bonus tip: better initial application settings

26