1. IETF WG Presentation1 Nathan Mittler Multiparty Multimedia Session Control (mmusic)

2. IETF WG Presentation2 General Description (Cont.) URL: –http://www.ietf.org/ html.charters/mmusic- charter.html How to get on mailing list: –General discussion: confctrl@isi.edu –To subscribe: confctrl- request@isi.edu

3. IETF WG Presentation3 General Description Chartered to develop Internet standards track protocols to support Internet teleconferencing

4. IETF WG Presentation4 General Description (Cont.) has drafted protocols for: –distributing session description (SDP) –providing security for session announcements (SAP Security) –controlling on-demand delivery of real-time data (RTSP) –initializing sessions and inviting users(SIP) –managing tightly-controlled sessions (SCCP)

5. IETF WG Presentation5 General Description (Cont.) Additional documents (informal) –architectural framework for MMUSIC –interoperability scenarios for Internet-based teleconferencing systems

6. IETF WG Presentation6 General Description (Cont.) Intermediate goals: –bring several protocols to Proposed Standard (SDP,RTSP) or Experimental RFC status –to produce Informational RFCs for all informational drafts

7. IETF WG Presentation7 General Description (Cont.) Long-term goals: –bring remaining protocols to Proposed standard status –to investigate the requirements for a next-generation session description protocol

8. IETF WG Presentation8 Internet Draft 1: Real-Time Streaming Protocol (RTSP) Application-level protocol controls either a single or several time-synchronized streams of continuous media Continuous media: –Data where there is a timing relationship between source and sink –the sink must reproduce the timing relationship that existed at the source.

9. IETF WG Presentation9 Internet Draft 1: Real-Time Streaming Protocol (RTSP) (Cont.) Protocol supports the following operations: –Retrieval of media from media server: Client can request a presentation description If presentation is being multicast the presentation description contains the multicast addresses and ports to be used for the continuous media If presentation is to be sent only to the client via unicast, the client provides the destination for security reasons

10. IETF WG Presentation10 Internet Draft 1: Real-Time Streaming Protocol (RTSP) (Cont.) –Invitation of a media server to a conference: A media server can be “invited” to join an existing conference –to play back media into a presentation –to record all or a subset of the media in a presentation »is useful for distributed teaching applications

11. IETF WG Presentation11 Internet Draft 2: Internet Multimedia Conferencing Architecture Determining factors of a conferencing architecture are: –communication (possibly large) groups of humans –real-time delivery of information

12. IETF WG Presentation12 Internet Draft 2: Conferencing Architecture (Cont.) Early conferencing systems used a fan-out of data streams –1 connection between each pair of participants –same info must cross some networks more than once

13. IETF WG Presentation13 Internet Draft 2: Conferencing Architecture (Cont.) Internet architecture uses more efficient approach of multicasting info to all participants

14. IETF WG Presentation14 Internet Draft 2: Conferencing Architecture (Cont.) IP multicast service model: –Senders send datagrams to the address of a multicast group –Receivers express an interest in (join) certain multicast groups –Multicast routers conspire to deliver multicast group addressed datagrams from the senders to receivers

15. IETF WG Presentation15 Internet Draft 2: Conferencing Architecture (Cont.) Separate Flows for each Media Stream –no need for the different media comprising a conference to be carried in same packets –simplifies receivers –allows the different media to be given different quality of service ie) under congestion, a router might preferentially drop video packets over audio packets

16. IETF WG Presentation16 Synchronisation –audio and video that were grabbed at same time may not arrive at same time –at the receiver, each flow will need a playout buffer to remove network jitter –Synchronisation is performed by adapting playout buffers so that samples/frames that originated at same time get played at same time Internet Draft 2: Conferencing Architecture (Cont.)

17. IETF WG Presentation17 41st IETF Meeting in Los Angeles Dates of 41st meeting –Sunday March 29, 1998 - Friday April 3rd, 1998 Meetings - Tuesday, March 31 at 1:00 p.m. - 3:15 p.m. –Session Initiation Protocol (SIP) –Session Announcement Protocol (SAP) Security –SIP call control

18. IETF WG Presentation18 42nd IETF Meeting Meeting August 23-28 1998 in Chicago.