1 / 9

Application sharing

The MMUSIC application aims to integrate application sharing and remote desktop capabilities into the IETF session architecture. It addresses challenges such as sharing user input, screen output, and moderating access to input focus. The solution focuses on requirements like application sharing, desktops and windows, multiple users, protocol negotiation, and modular architecture.

jesseg
Download Presentation

Application sharing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University MMUSIC

  2. Overview • No good way to share application state in a conference • T.120 does not integrate well with SIP • proprietary solutions • treat as video source  does not deal well with windows, user input • Goal: integrate into IETF session architecture • Assumption: treat remote access (“vnc”, “terminal server”) and sharing as same problem MMUSIC

  3. Components • Session setup • User input (HMI) • Screen output to remote users • Moderating access to input focus (devices) MMUSIC

  4. Basic requirements • F1: application sharing & remote desktop • F2: desktops (screens) + windows • F3: any number of users • F4: cannot modify applications • F5: protocol negotiation • F6: modular architecture MMUSIC

  5. Input • I1: may not have actual device • I2: private, authenticated, … • I3: at most one simultaneous user typical, but not always • I4: hints (e.g., modal input) • I5: indicate focus • I6: relative timing needed (e.g., video games) • I7: I18N • I8: Copy-and-paste? MMUSIC

  6. Video output • V1: different resolutions, color depth • V2: both lossy (e.g., embedded video, CGA) and lossless data • V3: window layering hints • V4: semi-transparent windows • V5: relative timing information • V6: absolute timing information • V7: variety of encodings • V8: no assumption of common fonts MMUSIC

  7. Audio and full-motion video • A1: share audio streams, sync’ed to video • A2: share full-motion window as part of shared application • A3: receiver may choose not to receive high-bandwidth components (e.g., motion video window during presentation) MMUSIC

  8. Transport • T1: some parts require perfect reliability • T2: large number of receivers • T3: heterogeneous bandwidth • T4: minimize latency • T5: work well in low- and high-latency environments MMUSIC

  9. What’s next? • Is this a problem for MMUSIC or AVT? • Basic architecture assumption – sound? • SIP (or similar) for session setup • SDP(ng) for parameter negotiation • transport: RTP as one option? • keyboard and mouse input • RTP as well? • part of signaling? (KPML etc) • Need to define new payload formats MMUSIC

More Related