ietf 61 (november 2004) mmusic1 application sharing henning schulzrinne jonathan lennox jason nieh...

9
IETF 61 (November 2004) MMUSIC 1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

Upload: malcolm-atkinson

Post on 02-Jan-2016

216 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: IETF 61 (November 2004) MMUSIC1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

IETF 61 (November 2004)

MMUSIC 1

Application sharing

Henning SchulzrinneJonathan Lennox

Jason NiehRicardo Baratto

Columbia University

Page 2: IETF 61 (November 2004) MMUSIC1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

IETF 61 (November 2004)

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

Page 3: IETF 61 (November 2004) MMUSIC1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

IETF 61 (November 2004)

MMUSIC 3

Components

• Session setup

• User input (HMI)

• Screen output to remote users

• Moderating access to input focus (devices)

Page 4: IETF 61 (November 2004) MMUSIC1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

IETF 61 (November 2004)

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

Page 5: IETF 61 (November 2004) MMUSIC1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

IETF 61 (November 2004)

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?

Page 6: IETF 61 (November 2004) MMUSIC1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

IETF 61 (November 2004)

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

Page 7: IETF 61 (November 2004) MMUSIC1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

IETF 61 (November 2004)

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)

Page 8: IETF 61 (November 2004) MMUSIC1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

IETF 61 (November 2004)

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

Page 9: IETF 61 (November 2004) MMUSIC1 Application sharing Henning Schulzrinne Jonathan Lennox Jason Nieh Ricardo Baratto Columbia University

IETF 61 (November 2004)

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