ietf 61 (november 2004) mmusic1 application sharing henning schulzrinne jonathan lennox jason nieh...
Post on 02-Jan-2016
216 Views
Preview:
TRANSCRIPT
IETF 61 (November 2004)
MMUSIC 1
Application sharing
Henning SchulzrinneJonathan Lennox
Jason NiehRicardo 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
IETF 61 (November 2004)
MMUSIC 3
Components
• Session setup
• User input (HMI)
• Screen output to remote users
• Moderating access to input focus (devices)
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
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?
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
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)
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
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
top related