ITSPA May 2013 - WebRTC, TURN, and WebSocket

740 views

Published on

A presentation by Peter Dunkley (Technical Director, Crocodile RCS Ltd). Presentation date 14-May-2013.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
740
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

ITSPA May 2013 - WebRTC, TURN, and WebSocket

  1. 1. WebRTC, TURN, and WebSocket 1
  2. 2. WebRTC, TURN, and WebSocket WebRTC, TURN, and WebSocket Peter Dunkley, Technical Director, Crocodile RCS Ltd Email: Twitter: peter.dunkley@crocodile-rcs.com @pdunkley
  3. 3. WebRTC is about media ● GetUserMedia Javascript API – ● MediaStreams Javascript API – ● Provides access to microphones, web-cams, and screen (for screen-sharing) Routes streams between microphones/webcams/screens/speakers and network connections PeerConnection Javascript API – Creates low-latency, secure connections between peers – Streams may be audio, video, or data
  4. 4. Security and Quality of Service is built-in ● New profile RTP/SAVPF – – ● The S means DTLS is used – only the endpoints can decode the stream The F means RTCP feedback is used – enables QoS in the endpoints ICE is mandatory – STUN allows traversal of most NAT devices without relays – TURN allows traversal of “badly behaved” NAT devices
  5. 5. Mandatory To Implement (MTI) Codecs ● Audio – – ● G.711 OPUS Video – ● Big debate between H.264 and VP8 Connections and codecs are negotiated using SDP
  6. 6. Media session interworking ● ● Media Gateways or RTCWeb Breakers are required for now The RTP/SAVPF profile used by WebRTC: – Mandates security – Mandates quality of service – Mandates client-based NAT traversal – Contains network optimisations – Is not compatible with most deployed servers and user-agents.
  7. 7. TURN Security ● ● ● ● TURN can use a lot of network bandwidth This may be expensive for service providers so security is needed to make sure it is not abused Ordinary credentials stored in Javascript webapps can be easily read and are not safe Google recently proposed a web-service API for creating ephemeral credentials
  8. 8. Establishing media sessions requires signalling Signalling Server Sig nal ling Server Browser WebRTC media or DataChannel Browser
  9. 9. Many signalling options ● REST based – ● BOSH based – ● For example, PubNub, RestComm, Twilio For example, some XMPP implementations WebSocket based – For example, SIP or XMPP
  10. 10. What is WebSocket? ● ● Safe, client-originated, connection to servers Often used from web-browsers - but does not have to be ● It is an asynchronous protocol ● Traffic from the client is masked ● ● Although carried over TCP WebSocket is a frame based protocol RFC 6455, “The WebSocket Protocol”
  11. 11. Why use SIP over WebSocket? ● SIP is the “Session Initiation Protocol” ● Requires less network infrastructure ● Interoperable with existing infrastructure ● Well understood fail-over and scaling model ● Many regulatory issues already dealt with – ● Billing, CALEA/LI, Privacy It's taken almost 10 years to sort out the SIP issues. Why start from scratch and make the same mistakes all over again?
  12. 12. SIP over WebSocket ● draft-ietf-sipcore-sip-websocket ● WebSocket has limitations – You can't know your local IP address – It's basically a NAT traversal issue ● Use Path (RFC 3327) ● Use SIP Outbound (RFC 5626) ● Use GRUU (RFC 5627)
  13. 13. SIP over WebSocket is widely available ● Open-source server implementations – ● Asterisk, Kamailio, OverSIP, reSIProcate Open-source client implementations – JAIN SIP JavaScript – JsSIP – QoffeeSIP – sipML5
  14. 14. But what about presence and messaging? ● ● ● SIP page-mode messaging is great for one-ata-time messages MSRP is well suited for light-weight sessionbased messaging and file-transfer XMPP is the right solution for advanced messaging, network address book, and presence
  15. 15. XMPP and SIP together? ● SIP is best for media session establishment and interoperability ● XMPP is better for messaging and presence ● Use the right protocol for the job ● CUSAX (Combined Usage of SIP And XMPP) is the future
  16. 16. Efficient messaging MSRP is a natural companion to SIP ● Can be used for IM, file transfer, or any other data streaming you want ● MSRP over WebSocket ● Involves an MSRP relay in the network (local policy can be enforced) – Great for client to server data exchanges – draft-pd-dispatch-msrp-websocket – ● MSRP over WebRTC Low-latency, secure, structured messaging between peers – Often a better option than XMPP messaging (even if using XMPP network address book and presence) as it is peer-to-peer – draft-pd-msrp-webrtc –
  17. 17. MSRP over WebSocket ● Open-source server implementations – ● Kamailio Open-source client implementations – Crocodile MSRP ● ● draft-pd-dispatch-msrp-websocket supported now draft-pd-msrp-webrtc supported soon
  18. 18. Crocodile RCS Ltd www.crocodile-rcs.com

×