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

2. IETF 61 (November 2004) MMUSIC2 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

3. IETF 61 (November 2004) MMUSIC3 Components Session setup User input (HMI) Screen output to remote users Moderating access to input focus (devices)

4. IETF 61 (November 2004) MMUSIC4 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

5. IETF 61 (November 2004) MMUSIC5 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?

6. IETF 61 (November 2004) MMUSIC6 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

7. IETF 61 (November 2004) MMUSIC7 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)

8. IETF 61 (November 2004) MMUSIC8 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

9. IETF 61 (November 2004) MMUSIC9 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