Download Slide 1

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Computer network wikipedia , lookup

Computer security wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Network tap wikipedia , lookup

Distributed firewall wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

IEEE 1355 wikipedia , lookup

Bus (computing) wikipedia , lookup

Airborne Networking wikipedia , lookup

UniPro protocol stack wikipedia , lookup

Peer-to-peer wikipedia , lookup

Transcript
WebRTC – Challenges and Best Practices
Sumit Amar
Director of Engineering
Electronic 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
• Media plane
– Audio Codecs:
– Video Codecs:
– Relay
– Encryption
– Quality
Telecom
AMR, AMR-WB
H.264
SBCs
SRTP/SDES
Managed
WebRTC
G.711, OPUS
VP8
Not required
DTLS/RTP
Adaptive
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 Control
Mesh 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 Control
Star (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.p
ptx