Application sharing
This presentation is the property of its rightful owner.
Sponsored Links
1 / 9

Application sharing PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on
  • Presentation posted in: General

Application sharing. Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University. Overview. No good way to share application state in a conference T.120 does not integrate well with SIP proprietary solutions

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Application sharing

Application sharing

Henning Schulzrinne

Jonathan Lennox

Jason Nieh

Ricardo Baratto

Columbia University

MMUSIC


Overview

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


Components

Components

  • Session setup

  • User input (HMI)

  • Screen output to remote users

  • Moderating access to input focus (devices)

MMUSIC


Basic requirements

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


Input

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


Video output

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


Audio and full motion video

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


Transport

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


What s next

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


  • Login