Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Future of
    Communication
    with RTMFP
    Matthew Kaufman
    17 November 2008




                                  ...
Introduction

      Who
               Matthew Kaufman
                        Background: software + Internet
        ...
Background: RTMP

      How the Flash Player talks to Flash Media Server
               TCP/IP
               NetConnec...
Background: RTMP flavors

      RTMP
               TCP (typically on port 1935)

      RTMPT
               “Tunneled...
Background: RTMP Limitations

      Based on TCP
               Reliable (lossless) in-order stream of bytes
          ...
RTMFP: Introduction

      Based on UDP
               Allows direct access to what is received and transmitted at the p...
RTMFP: Security

      RTMFP is secured at the protocol level
               Security “plugs in” to the protocol stack i...
Using RTMFP with FMS

      Minimal changes for developer
               Substitute “rtmfp://” for “rtmp://” when connec...
RTMFP and Firewalls

      RTMP and RTMPE requires TCP port 1935
      RTMPT and RTMPTE uses TCP port 80 (HTTP)
      R...
Demo: RTMFP and FMS




                                                                  Demo




                       ...
RTMFP: Direct Peer-to-Peer Communication

      Two use cases for real-time communication
               One-to-many
   ...
RTMFP: Direct P2P Communication – How it works

      Flash Media Server introduces peers
               ActionScript AP...
Using RTMFP Direct Peer-to-Peer Communication

      API Changes
               Peer IDs
                        Availa...
Demo: RTMFP Direct Communication




                                                                  Demo




          ...
Using RTMFP: NetConnection API

      NetConnection
               farID
               farNonce
               maxPee...
Using RTMFP: NetStream API

      NetStream
               New constructor (NetStream.DIRECT_CONNECTIONS or peerID as se...
Adobe Stratus

      Stratus is a (Beta) hosted rendezvous service for RTMFP
               For any 1:1 or 1:few audio/v...
Future Possibilities

      Flash Player 10.0 and AIR 1.5 are just the first step
               RTMFP protocol stack as...
End




                                   Don’t miss the Sneak Peeks




                                                ...
Upcoming SlideShare
Loading in …5
×

Matthew Kaufman Future Of Communication With Rtmfp Final Revised

24,499 views

Published on

Presentation by Matthew Kaufman of Adobe from MAX North America 2008.

Published in: Technology
  • Be the first to comment

Matthew Kaufman Future Of Communication With Rtmfp Final Revised

  1. 1. Future of Communication with RTMFP Matthew Kaufman 17 November 2008 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  2. 2. Introduction  Who  Matthew Kaufman  Background: software + Internet  Joined Adobe in 2006 from amicima  What  RTMFP  Secure Real-Time Media Flow Protocol ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  3. 3. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  4. 4. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  5. 5. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  6. 6. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  7. 7. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  8. 8. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  9. 9. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  10. 10. Demo: RTMFP and FMS Demo ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  11. 11. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  12. 12. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  13. 13. 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”); ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  14. 14. Demo: RTMFP Direct Communication Demo ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  15. 15. Using RTMFP: NetConnection API  NetConnection  farID  farNonce  maxPeerConnections  nearID  nearNonce  Protocol  unconnectedPeerStreams array ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  16. 16. Using RTMFP: NetStream API  NetStream  New constructor (NetStream.DIRECT_CONNECTIONS or peerID as second argument)  farID  farNonce  nearNonce  peerStreams array  onPeerConnect() ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  17. 17. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  18. 18. 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 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  19. 19. End Don’t miss the Sneak Peeks ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.

×