Matthew Kaufman Future Of Communication With Rtmfp Final Revised

Future of
Communication
with RTMFP
Matthew Kaufman
17 November 2008

®

Copyright 2008 Adobe Systems Incorporated. All rights reserved.

Introduction

 Who
 Matthew Kaufman
 Background: software + Internet
 Joined Adobe in 2006 from amicima

 What
 RTMFP
 Secure Real-Time Media Flow Protocol

®


Background: RTMP

 How the Flash Player talks to Flash Media Server
 TCP/IP
 NetConnection / NetStream classes
 Audio, Video, Shared Objects, Call, Send

 Flash Media Server streams or relays media, runs server-side applications
 Streaming of pre-recorded content
 Audio/Video playback (with seeking)
Flash
 Real-time Communication Media Server
 Audio/Video communication
 Microphone / Camera classes
 One-to-many or one-to-one
Flash Flash
Player Player

®


Background: RTMP flavors

 RTMP
 TCP (typically on port 1935)

 RTMPT
 “Tunneled”
 Encapsulated in HTTP requests

 RTMPS
 RTMPT-over-HTTPS
 SSL for security

 RTMPE
 RTMP plus lighter-weight encryption for stream protection

 RTMPTE
 RTMPE-over-HTTP

®


Background: RTMP Limitations

 Based on TCP
 Reliable (lossless) in-order stream of bytes
 Retransmission when there is loss (and delivery is held)
 Unavoidable latency
 Allows for (relatively) simple RTMP protocol stack above TCP layer

 Client-Server only
 TCP and direct peer-to-peer connections not compatible with NAT

 Other interesting things also impossible

®


RTMFP: Introduction

 Based on UDP
 Allows direct access to what is received and transmitted at the packet level
 Compatible with NAT and Firewall devices

 Sophisticated network protocol stack on top of UDP
 Rapid session establishment (2 RTT)
 anti-DOS and anti-port-scanning protection, client-side load balancing

 Multiple parallel media flows of messages
 Prioritized
 Variable reliability (full TCP-like, partial, none) controls retransmission
 In-order or as-received delivery at receiver

 TCP-friendly congestion control with variable congestion response (backoff)
 Congestion avoidance by 3rd-party sessions

 Integrated NAT traversal for peer-to-peer applications (“parallel-open” capability)
 IP address mobility (session stays up if address changes)
 Fast recovery from brief outages
®


RTMFP: Security

 RTMFP is secured at the protocol level
 Security “plugs in” to the protocol stack implementation, Flash Media uses a specific plug-in
 Every packet encrypted with block cipher
 AES-128 for Flash Media
 New block cipher key negotiated in first two round trips
 Diffie-Hellman key exchange (static-static or ephemeral-static keys) for Flash Media
 SSL-like authentication (e.g., RSA signing) is supported at connection establishment
 Not used for Flash Media at this time
 Secure nonce exchange
 Values chosen by each party, protected against MITM tampering
 Saves round trips when implementing upper-layer security (authentication, continuity)

 Developers have access at ActionScript level
 Secure peer IDs (infeasible to guess or forge), nearNonce and farNonce properties

®


Using RTMFP with FMS

 Minimal changes for developer
 Substitute “rtmfp://” for “rtmp://” when connecting to FMS
 Use Flash Player 10.0 or later, AIR 1.5 or later with a (future) RTMFP-capable FMS
 Everything works the same except:
 Live (unbuffered) Speex audio will be sent with partial reliability for lower latency
 Plus all other advantages of RTMFP
 Encryption
 Mobility
Flash
 etc.
Media Server

Flash Flash
Player Player

®


RTMFP and Firewalls

 RTMP and RTMPE requires TCP port 1935
 RTMPT and RTMPTE uses TCP port 80 (HTTP)
 RTMPS uses TCP port 443 (HTTPS)
 RTMFP is more complicated
 UDP port 1935 to establish connection
 Multiple high UDP ports (one per FMS application core)
 Does have NAT/Firewall traversal (additional ports used will be initiated from inside)
 Can use an IT-provided TURN proxy (manually configured)

 RTMFP has no tunneled counterpart, must fall back to RTMP

®


Demo: RTMFP and FMS

Demo

®


RTMFP: Direct Peer-to-Peer Communication

 Two use cases for real-time communication
 One-to-many
 One-to-one

 Both have scaling issues for popular services
 Direct peer-to-peer communication addresses the one-to-one case
 Or one-to-few

 Media bypasses FMS and travels directly between Flash Players / AIR
 Uses RTMFP’s NAT/Firewall traversal capability and FMS to “introduce”
 Lower latency
 (Almost) No media load on server
 Better scalability
 Server still available to relay if firewall blocks or RTMFP connection cannot be made

®


RTMFP: Direct P2P Communication – How it works

 Flash Media Server introduces peers
 ActionScript API talks only about Peer IDs, never IP addresses
 FMS gives the originating peer one or more IP addresses for destination
 FMS tells destination peer that originating peer is attempting contact

 NAT traversal
 Destination peer can respond as result of
originator’s packet(s) or FMS message
 “UDP hole punching”
Flash
Media Server
 IP mobility helps establish in certain NAT
configurations, maintain if NAT mapping
changes
 Not all NAT-NAT combinations work
Flash Flash
Player Player

®


Using RTMFP Direct Peer-to-Peer Communication

 API Changes
 Peer IDs
 Available from the NetConnection and Client objects
 Must exchange via FMS or other means (web service, XMPP, etc.)
 Slight modification to publishing and subscribing API

 To publish
nc = new NetConnection();
nc.connect(“rtmfp://my.fms/application”);
ns = new NetStream(nc, NetStream.DIRECT_CONNECTIONS);
ns.publish(“streamName”);

 To play
nc = new NetConnection();
nc.connect(“rtmfp://my.fms/application”);
ns = new NetStream(nc, <peerID of publishing peer>);
ns.play(“streamName”);

®


Demo: RTMFP Direct Communication

Demo

®


Using RTMFP: NetConnection API

 NetConnection
 farID
 farNonce
 maxPeerConnections
 nearID
 nearNonce
 Protocol
 unconnectedPeerStreams array

®


Using RTMFP: NetStream API

 NetStream
 New constructor (NetStream.DIRECT_CONNECTIONS or peerID as second argument)
 farID
 farNonce
 nearNonce
 peerStreams array
 onPeerConnect()

®


Adobe Stratus

 Stratus is a (Beta) hosted rendezvous service for RTMFP
 For any 1:1 or 1:few audio/video application that does not require FMS
 No recording
 No FMS application logic
 No FMS shared objects
 Requires external web service to exchange Peer IDs

 To use Stratus
 Open NetConnection to Stratus Stratus
rtmfp://stratus.adobe.com/<dev-key>/<app-name>

 Exchange Peer IDs
 Open direct peer-to-peer NetStreams

 More info on labs.adobe.com Flash Flash
Player Player

®


Future Possibilities

 Flash Player 10.0 and AIR 1.5 are just the first step
 RTMFP protocol stack as foundation
 Use peer-to-peer technology for the one-to-many cases

 “Groups”
 A dynamic, self-organizing overlay network of RTMFP peers
 Full transitive connectivity with only O(log n) sessions between peers
 Described by a “Groupspec”

 Application-Level Multicast
 Send a stream to all members of a group (multiple senders supported)
 Use Groupspec (instead of peerID) when constructing a NetStream

 Posting
 Directed routing

®


End

Don’t miss the Sneak Peeks

®


Matthew Kaufman Future Of Communication With Rtmfp Final Revised

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Matthew Kaufman Future Of Communication With Rtmfp Final Revised

Similaire à Matthew Kaufman Future Of Communication With Rtmfp Final Revised (20)

Dernier

Dernier (20)

Matthew Kaufman Future Of Communication With Rtmfp Final Revised