WebRTC – Challenges and Best Practices Sumit Amar Director of Engineering Electronic Arts.

22

Transcript of WebRTC – Challenges and Best Practices Sumit Amar Director of Engineering Electronic Arts.

WebRTC – Challenges and Best Practices

Sumit AmarDirector of EngineeringElectronic Arts

Agenda• Brief Introduction to Web RTC• WebRTC Challenges and Support Matrix• Best practices• Future WebRTC ideas• Q/A

WebRTC Introduction• Plugin-free RTC communication via browser– Audio, Video, and Data

• P2P channeling aided by a signaling server• Encoding and decoding of media streams• Allows bypassing of interceptors (SBC) • Only supported in a handful of browsers

WebRTC Introduction• WebRTC is being designed by:– IETF (for overall WebRTC design, Media plane, and

security framework)– W3C (HTML5/JavaScript APIs)– 3GPP (to integrate WebRTC into IP Management

Subsystem) to interoperate with Telecom infrastructure

WebRTC Introduction

Loreto, S.; Romano, Simon Pietro, "Real-Time Communications in the Web: Issues, Achievements, and Ongoing Standardization Efforts,“ Internet Computing, IEEE , vol.16, no.5, pp.68,73, Sept.-Oct. 2012

WebRTC Introduction

Key API components• MediaStream– Stream representing audio or video

• PeerConnection– Direct peer to peer connection to exchange data

• DataChannel– API to exchange data from peer to peer

Challenges• Browser support• Telecommunication Infrastructure vs WebRTC• Performance and congestion control• Security• End to end RTC feature support• Competing school of thoughts

Browser Support

Source: http://iswebrtcreadyyet.com/

Telecom Infrastructure vs WebRTC

TelecomAMR, AMR-WBH.264SBCsSRTP/SDESManaged

• Media plane– Audio Codecs:– Video Codecs:– Relay– Encryption– Quality

WebRTCG.711, OPUSVP8Not requiredDTLS/RTPAdaptive

Telecom Infrastructure vs WebRTC• Signaling plane– Codec negotiation with SDP (Session

Description Protocol) aka Offer/Response– Sender, Receiver, and Transport with ‘Tracks’

and ‘data channels’ in case of ORTC (Object RTC)

Performance and Congestion ControlMesh vs Star topologies for communication

Mesh• Increases load on the client machines, and

network• May not scale for more than 4-5 users

Performance and Congestion ControlStar (aka MCU / Media Router):• Reduced CPU load on client machines, but

increased load on the server and network• Scalable solution, router servers can be

scaled out• Might be a regulatory requirement• Addresses firewall/NAT issues in one place

Performance and Congestion Control• Congestion in mobile networks:– VideoAdapter can reduce encoding resolution if

the CPU is overloaded– Remote Bitrate Estimator notified the other

party to reduce bitrate if decoder is slower to react

• Problems:– VideoAdapter is reactive than proactive– Encoder and Decoder are both CPU intensive– Have to modify SDP ‘blob’ to update the bitrate

Security Considerations• Direct browser-to-browser P2P

connections are susceptible are protected by the realm of sandbox (browser)

• Signaling handshake without SSL could be susceptible to several attacks

• Interoperability with IMS (IP Multimedia System) could be challenged by SIP security requirements

End to end feature support• RTC features not supported by WebRTC– Push notifications– Address / ‘number’ blocking– Background processing (requires connected

socket for message passing)– Access to contacts list etc.– Access to device information (CPU, Network)

• Additive RTC features not supported by ORTC– DataChannel for communicating P2P data

Competing school of thoughts(CU-RTC-Web, and now ORTC)

Best practices• Bitrate encoding:– Log captured network speed, and build prediction

model on it to automatically adjust bitrate– Use a native shim to get access to network and CPU

speed• Mesh vs Star– Use star for multiple user conferencing scenarios– Use mesh for data channel based scenarios

Best practices• Determine CPU speed in web application

– By running stress tests on the client machine.• Use a single method CPU intensive task• Use UI thread to do intensive DOM manipulations and run

a few web workers for CPU intensive tasks in the background

• Calculate CPU clock speed and the number of processors

• Determine network throughput– By making synchronized XHR calls in test environment

to various network endpoints and measuring time taken for turns

– By POSTing large amounts of data to determine speed

WebRTC – future ideas– Peer to peer CDN (content delivery network)

Image source: http://inet.cpt.haw-hamburg.de/papers/vws-lwpcd-13.pdf

Resources

• Questions/Suggestions – [email protected] • Slides at –

http://www.amar.co.in/ppt/devcon5webrtc.pptx