2.8.9 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Joerg Ott <jo@tzi.uni-bremen.de>
Colin Perkins <csp@isi.edu>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>

Transport Area Advisor:

Allison Mankin <mankin@isi.edu>

Mailing Lists:

General Discussion:confctrl@isi.edu
To Subscribe: confctrl-request@isi.edu
Archive: ftp://ftp.isi.edu/confctrl/confctrl.mail

Description of Working Group:

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) is chartered to develop Internet standards track protocols to support Internet teleconferencing sessions. MMUSIC's focus is on supporting the loosely-controlled conferences that are pervasive on the MBone today. However, the WG also will ensure that its protocols are general enough to be used in managing tightly-controlled sessions.

To date, MMUSIC has drafted protocols for:

- distributing session descriptions -- Session Description Protocol (SDP) and Session Announcement Protocol (SAP),

- providing security for session announcements -- SAP Security,

- controlling on-demand delivery of real-time data -- Real-Time Stream Protocol (RTSP),

- initiating sessions and inviting users -- Session Initiation Protocol (SIP), and

- managing tightly-controlled sessions -- Simple Conference Control Protocol (SCCP).

In addition, the WG has drafted two informational documents: the first describes the architectural framework for MMUSIC, and the second describes interoperability scenarios for ITU- and Internet-based teleconferencing systems.

The WG's protocols reflect coordination with other IETF efforts related to multimedia conferencing (e.g., AVT, RSVP). In addition, the WG will collaborate with liaisons to ITU standards bodies and industry consortiums as appropriate to ensure interoperable standards (e.g., SIP/SAP/SDP with ITU H.323 and H.332).

The WG has defined two sets of goals -- immediate goals to be accomplished over the next several months, and longer-term goals which will be reviewed and possibly revised after the immediate goals are met. The immediate goals include bringing several protocols to Proposed Standard (SDP, RTSP), or Experimental RFC status (SAP), and to produce Informational RFCs for the informational drafts listed above. The longer-term goals are to bring the remaining protocols to Proposed Standard status (SIP, SAP Security, SAP), to investigate the requirements for a next-generation session description protocol, and to continue the development of SCCP.

Goals and Milestones:

Done

  

Conduct WG Last Call for SAP Internet-Draft

Done

  

Submit a revised Internet Multimedia Conferencing Architecture I-D.

Done

  

Submit SDP to the IESG for consideration as a Proposed Standard.

Done

  

Submit a revised SIP I-D.

Aug 97

  

Submit a revised ITU Interoperability Scenarios I-D.

Done

  

Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol.

Done

  

Conduct WG Last Call for RTSP Internet-Draft.

Done

  

Submit Internet-Draft on Internet Multimedia Conferencing Architecture.

Nov 97

  

Submit ITU Interoperability Scenarios Internet-Draft to IESG for consideration as an Informational RFC.

Done

  

Submit RTSP to IESG for consideration as a Proposed Standard.

Done

  

Conduct WG Last Call for SIP Internet-Draft.

Done

  

Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard.

Done

  

Conduct WG Last Call for SAP Security Internet-Draft.

Done

  

Conduct second WG Last Call for SAP.

Done

  

Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard.

Done

  

Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard.

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2326

PS

Real Time Streaming Protocol (RTSP)

RFC2327

PS

SDP: Session Description Protocol

RFC2543

PS

SIP: Session Initiation Protocol

RFC2974

E

Session Announcement Protocol

RFC3108

PS

Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections

Current Meeting Report

Minutes of the MMUSIC WG
========================

Notes taken and prepared by Tom Taylor (thanks!).

The MMUSIC WG met on Thursday afternoon, Aug. 9 2001, under the chairmanship of Joerg Ott (jo@tzi.uni-bremen.de) and Colin Perkins (csp@ISI.EDU).

1. Agenda
=========

The revised agenda as published at http://www.dmn.tzi.org/ietf/mmusic/51/agenda.html and advertised in Joerg's note to the list on Aug. 7 was accepted, with the last-minute addition of a presentation and discussion of work on key management for media streams (item 4 below).

2. Working Group Status Update
==============================

Joerg Ott (jo@tzi.uni-bremen.de) presented.

- SDP ATM draft now published as RFC 3108
- draft-ietf-mmusic-mbus-transport-06.txt, Mbus Transport spec: with IESG
- draft-ietf-mmusic-fid-03.txt, SDP Flow Identification (FID): essentially done; requires re-submission
- draft-andreasen-mmusic-sdp-simcap-03.txt, SDP Simultaneous Capabilities: essentially done
- draft-ietf-mmusic-sdp-comedia-00.txt, Connection-oriented media: still issues to be resolved
- RTSP: specification checked in at SourceForge:
http://rtspspec.sourceforge.net/
Log bugs to spec at SourceForge
Will be CC'ed to MMUSIC list
New draft targeted for Salt Lake City.

Re RTSP: Henning Schulzrinne (schulzrinne@cs.columbia.edu) noted that vigorous action is needed now to obtain interoperability results.

Need volunteer to draw up list of features to be tested, volunteers to run tests. A volunteer was found for the first task.

3. SDP Revisions (draft-ietf-mmusic-sdp-new-03.txt)
===================================================

Colin Perkins (csp@ISI.EDU) presented. His slides are available at http://www.dmn.tzi.org/ietf/mmusic/51/agenda.html. He reviewed the changes made in versions -02 and -03 and asked that they be checked over.

Henning Schulzrinne raised some questions that had come up from SIP discussions.

First: allow nettype and addrtype on the c= line to be registerable. Colin noted that this had always been the WG's intention, and accepted an action to ensure that the IANA Considerations section matches the IANA registry recently established.

Second: what does ptime mean: is this the sender's capability or the receiver's? Colin promised to clarify the text.

Third: SIP has a section in back on the use of SDP, which doesn't seem appropriate there. Either create separate draft or describe the SDP negotiation model in general. RTSP has a similar issue. Megaco does not because it is not SDP compliant.

Flemming Andreasen (fandreas@cisco.com) raised some questions to clarify the relationship between maximum acceptable packet time (maxptime) and ptime. He argued that the new text is backward compatible. Christian Huitema (huitema@microsoft.com) and Jonathan Rosenberg (jdrosen@dynamicsoft.com) disagreed. Colin's proposed resolution was to take maxptime out of SDP and put it in the payload spec.

Steve Casner (casner@acm.org) noted that the direction of applicability of parameters can't be in SDP, because it depends on the context. He also notes that any change to maxptime also affects the MIME type registration document. After further discussion, it was agreed that Steve and Colin will resolve the disposition of the maxptime documentation offline.

Jonathan Rosenberg raised a new issue. He had encountered asituation where had a URL for the media address. The resolution of how to handle this was to split the URL, placing the host in the c= line and the port on the m= line, with URL parameters as attribute(s).

Reverting to a general point from the maxptime discussion, Henning & Colin agreed that, to preserve backward compatibility, max.. parameters could perhaps be interpreted as a hint of maximum receiver capabilities.

Tom Taylor (taylor@nortelnetworks.com) referred to the negotiation model issue brought up by Henning, expressing a preference for a separate draft on the topic. He noted that while the Megaco syntax not strictly SDP, the negotiation model is valid. Each direction of flow is negotiated in a separate session description.

Jonathan Rosenberg noted that if a separate negotiation draft is created care will have to be taken with dependencies. Colin Perkins felt it could be done quickly enough that it wouldn't hold up 2543bis. The negotiation draft should not be dependent on SDP-new or vice versa.

4. Key Management For Media Streams
===================================

The presentation provided a quick review of the requirements for key management documented in the draft.

The draft has been accepted as a MSEC WG work item. This information brought strenuous objections from Jonathan Rosenberg. He rated this as a good draft, important for unicast too, hence it should be an MMUSIC work item. Christian Huitema argued that unicast is not subset of multicast, and requires a separate analysis. As a result, the document requires concurrent acceptance by MMUSIC and MSEC.

Colin Perkins informed the meeting that it had been agreed in MSEC that SDP-related content should be last-called here in MMUSIC, while content dealing with group communication should be last-called in MSEC. It was agreed that the document will be submitted as an MMUSIC draft.

5. SDP & RTP & NAT (draft-huitema-natreq4udp-00.txt)
====================================================

Christian Huitema (huitema@microsoft.com) presented. Slides are available at http://www.dmn.tzi.org/ietf/mmusic/51/agenda.html

under the agenda item "RTP/RTCP Port Handling (Huitema)".

Beginning with a brief explanation of how NATs work, Christian identified two problems for VoIP: making NAT UDP friendly, and the fact that NATs assign random port numbers for RTP and RTCP. He made the argument that NATs which change the port number across a boundary do it for increased security, but this enhanced security is an illusion and makes conferencing very difficult. He proposed that the IETF publish a recommendation favouring same-port mapping.

As an interim solution for the RTCP port problem, he proposed an RTCP port number attribute in SDP. This would tag the port number as an item to be changed by an ALG. He asked if there were objections to request to the IESG to last call his document.

Steve Casner asked whether the RTCP port could instead be isentified in a modification to the m= line. Christian pointed out that the proposed approach means backward compatibility issues: the failback would be to no RTCP. One possibility might be to have an m= line for RTCP. This thought brought groans from the crowd.

Comment: essentially first part of Christian's proposal recommends that all NATs be cone NATs. There could be a problem with port limits. The commenter suggested that this proposal for changed behaviour has to be done carefully.

Comment: why would NAT developers pay any attention? MMUSIC might simply lose credibility with NAT developers.

Reverting to previous discussion, Colin noted that he couldn't see any way of changing the m= line without breaking backward compatibility.

Comment: timeouts on NAT bindings could mess things up. Christian suggested that we have natural refresh with RTP and RTCP. If doesn't work, the connection is broken. Jonathan Rosenberg identified silence suppression as a potential issue, as noted in SIP list discussion.

The proposed solution, to send comfort noise in place of silence, should be documented.

Colin Perkins had another suggestion: add address in the proposed RTCP attribute. But this brings in the address family. Christian noted that some NAT behaviour may break this.

Comment: should document behaviour as well as the attribute itself.

Christian viewed this as out of scope: it effectively defines an interface to NAT.

Jonathan Rosenberg saw multiple work items on the table. SIPPING will document procedures and pull everything together. The work product will point to this draft and others. Jonathan has proposed a protocol between a node and an echo server in a separate draft. Comment: that is needed.

Comment: should be solved at transport rather than application level.

Joerg Ott ruled that this proposition should be discussed on the list.

6. SDP Formats for connection-oriented media (draft-fairlie-mmusic-sdp-sctp-00.txt)
===================================================================================

Robert Fairlie-Cunninghame (rfairlie@nuera.com) presented. Slides are available at http://www.dmn.tzi.org/ietf/mmusic/51/agenda.html under the corresponding agenda item.

SCTP is interesting for media transport: it provides fault tolerance, chunk bundling increases transmission efficiency, SCTP is partially connection-oriented (helps with NATs), ...

The draft has two aspects: it maps the SDP announcement onto SCTP streams, and describes SCTP startup. In SDP terms, it proposes three new transports and four additional SDP attributes.

Colin Perkins asked about having to specify formats for RTP/AVP-SCTP transport. Robert indicated that this would be covered in the IANA Considerations section.

Robert noted a number of differences from commedia model, based on the fact that the SCTP association is between two SCTP endpoints, not two media endpoints.

He also noted a number of open issues:
- dependency on unreliable SCTP ratification (TSVWG),
- tracking commedia issues & changes,
- whether a separate association is needed for RTCP.

He asked what the next step would be.

Joerg Ott indicated that he would like to see more discussion on the list: comments are invited. Th port number change on the m= line is problematic. (This change stems from the use of the m= port to convey SCTP stream numbers. An SCTP port supports multiple streams, and stream 0 is valid.)

Brian Rosen (Brian.Rosen@marconi.com) asked how a channel is destroyed. Robert identified this as another open issue. Gonzalo Camarillo (Gonzalo.Camarillo@lmf.ericsson.se) didn't like the idea of yet another layer of demultiplexing: RTCP should go to a separate port number.

7. SDP for TDM (draft-taylor-mmusic-sdp-tdm-00.txt)
===================================================

Tom Taylor (taylor@nortelnetworks.com) presented. His slides are at http://www.dmn.tzi.org/ietf/mmusic/51/agenda.html under the corresponding agenda item.

The presentation indicated the potential applications of the material in the draft, summarized the proposed extensions to SDP, and listed some open questions.

Jonathan Rosenberg asked for clarification of the suggested potential application to SIP control of TDM. Tom indicated that the application was incidental to the purpose of his draft, but possible.

One of the open issues had to do with media type registrations. Steve Casner indicated that new registrations would be necessary for G711 A-law and mu-law on TDM, since MIME types are context-dependent.

The detailed parameter syntax should be checked against sdp-new.

Jim Renkel (james.renkel@3com.com) indicated that the author should harmonize work with work being done for signalling systems other than ISUP, PRI. He will help if needed.

William Hern (whern@nortelnetworks.com) indicated that his group would be submitting a draft on SDP for CAS.

It was agreed that this work would be harmonized with or incorporate the CAS work when it became available.

8. Voice-band Data Media Format (draft-foster-mmusic-vbdformat-00.txt)
======================================================================

Flemming Andreasen (fandreas@cisco.com) presented. His slides are at http://www.dmn.tzi.org/ietf/mmusic/51/agenda.html under the corresponding agenda item.

The draft proposes a new fmtp parameter for voiceband data.
a=fmtp:(payload-type) vbd

This is to be construed as an optimization hint to the other side, allowing it to modify its handling of the media stream accordingly.

Mark Handley (mjh@isi.edu) noted that fmtp is defined with respect to a particular codec. Jim Renkel added that the adjustment for voice-band data goes beyond jitter buffer compensation.

Discussion: there is some question as to what has to be specified for voice-band data. A number of items can be tweaked to serve modems, not just jitter buffer size. After several suggestions, Steve Casner remarked that the proposals were getting unwieldy. An alternative payload type might be the answer. Flemming Andreasen pointed out that we would then have to come up with new codec names. The authors of the draft were also looking for backward compatibility. This is a matter of codec negotiation, so it is not an attribute. Jonathan Rosenberg indicated his acceptance of the proposal to fmtp: this intent is effectively a sub-codec specification.

9. SDPng (draft-ietf-mmusic-sdpng-01.txt)
=========================================

Dirk Kutscher (dku@informatik.uni-bremen.de) presented. His slides are at http://www.dmn.tzi.org/ietf/mmusic/51/agenda.html under the corresponding agenda item.

He began with a review of the basis for the proposed SDPng syntax. It is XML based, as a consequence of a number of arguments in favour of that choice. The proposed description model consists of four sections. The scope of the SDPng standardization project would comprehend the basic syntax specification, basic rules packages ("profiles"), and basic definitions ("libraries").

Extensions to SDPng would be achieved by creation of new schema definitions (profiles) and libraries (each typically based on a given profile).

Looking at XML itself, Dirk noted that it has two definition mechanisms: namespaces and schemas. The latter are extensible through the import mechanism and derived element type definitions.

Dirk gave examples of application of the proposed syntax to codec and payload type definitions and to configuration of a conference.

Dirk reviewed a number of open issues:
- uniqueness of identifiers in attribute values,
- referencing of profiles,
- capabilities vs. specific session identifiers.

He identified several tasks to be performed to flesh out the proposal.

Discussion:
Jim Renkel: saw no requirement to process SDPng in a real-time environment. Joerg assured him that the requirement has been specified (see draft-ietf-mmusic-sdpng-req-01.txt). Other concerns Jim raised have been addressed in the syntax draft itself.

Comment: the proposal seems to be missing some key SDP attributes. Joerg agreed, saying that the design team is looking for the right place to put them.

Joerg summed up by saying that the design team is hoping for the next submission of draft-ietf-mmusic-sdpng within the month, followed by a review by SDP attribute contributors to see if anything is missing.

10. Tunneling RTSP/RTP/RTCP in HTTP (draft-gentric-avt-rtsp-http-00.txt)
========================================================================

RTSP describes a TCP-based streaming mode. This includes interleaved RTP/RTCP packets. The draft proposal is to extend this to HTTP-only firewalls.

Source of proposal: Internet Streaming Media Alliance.

The basic proposal is to use HTTP to create a channel in each direction. The authors are looking for more ideas and thoughts on how to proceed.

Melinda Shore (mshore@cisco.com) expressed her disagreement with the proposal, because it raises serious security concerns. Its whole thrust is to violating site security policy. It would be more consistent with network policy to use Jonathan's SIP approach. If the draft is accepted, HTTP might become characterized as "Horrible Trashcan Transport Protocol". Jonathan Rosenberg noted that it is too late to salvage HTTP's reputation: RFC 3093 "IP Over HTTP" already describes how to do it. Mark Handley also expressed his concern with the security implications. Port 554 is allocated for RTSP; managers can open it if they want to. Apparently some firewall vendors already block strange uses of HTTP. Site administrators are aware of this sort of tunneling and are asking firewall vendors for controls.

Joerg Ott ruled that the responses he had heard make it clear that the proposal is going nowhere in the MMUSIC WG.

Slides

Agenda
'draft-taylor-mmusic-sdp-tdm-00'
Describing SCTP-based media transport using SDP
SDP & RTP & NAT
SDPng Update
Session Description Protocol
Tunneling RTSP/RTP/RTCP in HTTP
Media Format Parameter for Voice-Band Data