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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Matthew Kaufman Future Of Communication With Rtmfp Final Revised

Ähnlich wie Matthew Kaufman Future Of Communication With Rtmfp Final Revised (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Matthew Kaufman Future Of Communication With Rtmfp Final Revised