2.7.9 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 23-Oct-00

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@east.isi.edu>

Transport Area Advisor:

Allison Mankin <mankin@east.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:

Jul 97

  

Conduct WG Last Call for SAP Internet-Draft

Jul 97

  

Submit a revised Internet Multimedia Conferencing Architecture I-D.

Jul 97

  

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

Jul 97

  

Submit a revised SIP I-D.

Aug 97

  

Submit a revised ITU Interoperability Scenarios I-D.

Aug 97

  

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

Oct 97

  

Conduct WG Last Call for RTSP Internet-Draft.

Oct 97

  

Submit Internet-Draft on Internet Multimedia Conferencing Architecture.

Nov 97

  

Submit RTSP to IESG for consideration as a Proposed Standard.

Nov 97

  

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

Jan 98

  

Conduct WG Last Call for SIP Internet-Draft.

Feb 98

  

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

Apr 98

  

Conduct WG Last Call for SAP Security Internet-Draft.

Apr 98

  

Conduct second WG Last Call for SAP.

May 98

  

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

May 98

  

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

Current Meeting Report

Minutes of the MMUSIC WG

Reported by Colin Perkins and Joerg Ott.
Minutes prepared by Tom Taylor (thanks!).

The MMUSIC Working Group met twice, on Wednesday and Thursday afternoon.  The Chairs were Joerg Ott [jo@tzi.uni-bremen.de] and Colin Perkins [csp@ISI.EDU].  In addition, an informal group met Wednesday evening to discuss SDPng.

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

The proposed agenda was as follows:

Wednesday: status update + SDP + SDPng
Thursday: Mbus + RTSP update
plus Wed. pm SDPng bar BOF

The agenda was accepted without comment.

2. WG Status (Joerg Ott)
   =====================

SAP has been published (RFC 2974).

ATM SDP Last Call is done.  There were no comments.  The author has to make a few small editorial corrections, then the document will be passed to the IESG.

The Internet Multimedia Conferencing Architecture document is at the same stage.

3. SDP Next Steps
   ==============

A new draft, draft-ietf-mmusic-sdp-new-00.txt, has been submitted. This draft is the starting point for moving SDP to Draft Standard; no major changes are intended.  E-mails are requested with exact wording changes proposed to clarify the document.  Specific changes identified at the moment are to include the SDP source filter list and to fixes the "Requires" attribute.

It was noted that further changes and additions should be incorporated, including support for layered codecs, possibly removing the mandatory status of the s= line, allowing to reference m= lines by identifier, and, finally, cleaning up the ABNF.  Those issues will be considered during the revision process.

Rohan Mahy asked the Chairs to confirm his understanding that SDP does not support capability negotiation.  Colin said that this was the main reason for SDPng.

Colin asked people to send E-mails to the list on the changes requested, and to please make them very precise.

Jonathan Rosenberg asked what changes had been made in creating the -sdp-new draft.  The answer was that nothing had been changed from the RFC except for the necessary paragraphs to make this a new document.

The Chairs are aiming for April completion of the work.

4. draft-camarillo-sip-sdp-01.txt
   ==============================

Gonzalo Camarillo [Gonzalo.Camarillo@lmf.ericsson.se]: SDP media alignment in SIP.

The topic of the draft is the same as in the first version: simplifying changes in media encoding and destination in the course of a SIP session.  However, the proposed solution is completely different.  The presentation began with definitions of media stream and RTP session, which Gonzalo considered key to the problem.

  - "media stream" from RTSP -- RTP session maps to it
  - RTP session

Gonzalo now walked through a cellular example, showing the same stream carried by multiple sessions depending on the codec.  Another case where multiple sessions are involved is that of an application server gathering DTMF tones: the latter go to a different place from voice.

Currently, this requires the use of several m= lines.  This is OK for the SIP session initiator.  However, the application server or UAS has to re-INVITE, adding more m= lines.  This means that it takes several

RTTs to move to the new configuration.  Gonzalo provided a call walkthrough example to further make his point.

Proposal: define "media flow" to imply one or more RTP sessions. Users want to negotiate media flows rather than media streams.  The result would be to avoid the need to do re-INVITEs.  The precise mechanism proposed is to use a a=fid: attribute.

Jonathan Rosenberg said it would not work; the flow represents alternate ways to direct the same media stream, with the constraint that the source must not send more than one at once.  But the DTMF example requires replication of flows.  a=fid solves the alternative problem but not the split flow problem.

Rohan Mahy asked if it would be reasonable to have a small list of requirements that the technique should be able to handle.  It becomes a question of the relative burden of the proposals compared with their benefits.

Henning Schulzrinne noted that the technique is not backward compatible - non-comprehension clobbers the SIP negotiation model. Gonzalo presented counter-logic.

More offline discussion is needed.  Gonzalo will submit a revised draft.

5. draft-ietf-mmusic-sdp-tcpmedia-00.txt
   =====================================

David Yon [yon@dialout.net]: TCP-based media transport in SDP.

Problem: SDP is optimized for connectionless media.  We need a way to guide connection setup.  Approach: add new attributes.

Add direction attribute: "active" / "passive" (could specify "both" if indifferent).

Details: SDP syntax demands a port but none is available.  The proposal is for the sender to specify port 9, but the receiver ignores the port specification.  If the direction parameter is omitted it is assumed to be "both".  An endpoint willing to initiate a connection optionally specifies a source port.  This specification allows an endpoint listening at a fixed port to distinguish logical connections to a common IP address.

Going forward: is "both" the right default?
Should SSL/TLS be added to in this draft?

Jonathan Rosenberg expressed support for the draft and said he would like to see TLS there.  He suggested that David add RTP/AVP over TLS and also over SCTP.

Colin Perkins remarked that the syntax has to distinguish between transport and profile.

The Chair suggested that the draft should move forward as quickly as possible.  He sees no objections to the approach.

6. draft-beser-mmusic-capabilities-0x.txt
   ======================================

Burcak Beser [Burcak@pacband.com]: SDP Codec Capabilities Attribute.

The problem: to distinguish between capabilities and expectations, including how to signal preferred codec each way and how to force remote end to change codec.

Burcak presented a call walkthrough.  Both ends agree that they both support G.729 and G.711.  The process does not determine which codec is actually used.  Ordering can give priority of preference.  However, this raises a new issue: asymmetry due to constraints on total processing power.  The solution the draft proposes is to provide groups showing simultaneous capabilities.  The draft shows example applications.

Jonathan Rosenberg remarked that capability negotiation has lots of interesting theoretical problems.  Asymmetry is theoretical, not a real case.  A counter-example was immediately provided from the crowd: voicemail.

Burcak stated a further problem: how to switch codecs.  There is no ordering in the SDP specification, but there is one in the SIP specification.

Jonathan had a basic question: what real problems can't wait for SDPng?  Brian Rosen agreed that he would rather not have a piecemeal negotiation capability.

The overall sentiment in the room seemed to be not to proceed further with this proposal.

7. draft-andreasen-mmusic-sdp-simcap-00.txt
   ========================================

Flemming Andreassen [fandreas@cisco.com]: SDP Simple Capability Negotiation.

Flemming took the same starting point as Burcak.  Problems:

-- if different media types have to be supported in the same session, one needs multiple m= lines. But this implies multiple RTP sessions e.g. for T38 versus voice.

-- also a multiple codec issue.  Listing all supported codecs on the same m= line possibly implies more than the DSPs have capacity to deliver.

Flemming expressed his concerns with SDPng: it will not backward compatible, and it is a work in progress.  The large existing base of SDP users needs a less drastic upgrade path.  The key point is that the upgrade should be simple, limited, and backwards compatible.  The key issue: where do you draw the line?  The draft lists requirements to be satisfied by the short-term fix.  It proposed additional SDP attributes as a solution.  Flemming is looking for input and comments.

A question was raised about the purpose of the proposed sequence number: what is its relationship to the one in draft-camarillo-sip-sdp-01.txt?  Gonzalo indicated that Flemming's does not have the same meaning.

Jonathan Rosenberg remarked that the proposed solution solves the alternative problem.  He didn't see that it solves the codec problem.

Henning Schulzrinne said he could not really follow the application. Flemming said it was for use with gateways.

The Chair sought the Working Group view going forward.  Jonathan Rosenberg said any short-term work should solve real immediate problems.  Get a list of these that cannot wait for SDPng, then choose a minimal solution.  Flemming accepted thiis as a reasonable viewpoint.

Tom Taylor wondered whether timeframes were such that it might be possible to wait for SDPng.  Flemming asked what people were supposed to do about the installed base.  Orit Levin asked where the problem lay.  Flemming responded that all users of SDP conform to standard except for Megaco, and the additional capabilities of the latter are not supported by SIP.  Rohan Mahy asserted that his customers want solutions for MGCP and SIP now.

The Chair affirmed that he was hearing some urgency, but also a desire for a complete view, particularly with a number of proposals aiming roughly in the same direction.  He proposes a two-week comment period for requirements.  Flemming will compile them into his I-D.

8. SDPng
   =====

Dirk Kutscher [dku@Informatik.Uni-Bremen.DE] presented.

The requirements have collected into the updated draft-kutscher-mmusic-sdpng-req-01.txt.  Dirk recalled the motivation for the work: evolution of SDP through attributes is difficult -- the receiver is not sure which attributes are required for a session, and evolution bogs down with too many of them.

The new requirements include the statement that application scenarios must include gateways and Megaco.  The description language must allow explicit labelling of alternatives.  It must be extensible and allow formal validation.  It must allow the expression of preferences. Capability negotiation must support multi-party conferencing, and work when some entities in the negotiation path do not have explicit understanding of the semantics of some of the capabilities.

Dirk proposed a language architecture consisting of four sections: definitions (optional); potential and actual configurations; constraints (optional); session attributes and stream semantics.

The definitions section defines abstractions for later reuse.  Common pieces can be factored out, as profiles, for example, and retrieved from external sources.

The potential and actual configurations section includes capabilities, shown as potential configurations.

The constraints section expresses simultaneous capabilities.  It is separated from the configuration section because the constraints can apply across combinations of configurations.

The session-level attributes section contains SDP-like session-level parameters.  In general, these provide meta-information about the conference and individual media streams.  SDP currently requires implict assumptions which this section would make more explicit.

Based on these thoughts, the following requirements are implied for the description language:

- allow for external definition components
- allow for different data types
- simple minimal implementations.

The requirements draft is an individual submission.  It is proposed to move this into a Working Group requirements draft and separate strawman draft.  The informal meeting scheduled for Wednesday evening would focus on syntax.  There will be further work to refine the requirements draft and update the list of input documents.  The first syntax proposal should be ready for the next IETF meeting.

Thomas Levy asked if it will be possible to correlate input and output capabilities (i.e.) MG capability as a black box to perform specific transformations.  He will spell out his requirement in more detail in an E-mail to the list.

Henning noted that SDP implictly assumes scheduled rather than on-demand events.  Should SDPng carry scheduling information?  The CPL discussion in this area was difficult, and shouldn't be repeated. Dirk replied that he had not thought about it.

Henning suggested that in the meta-description it would be useful to have retrieval as in SMIL, in the form of a profile.  Brian Rosen noted that SMIL is very interested in working with us.

Orit Levin noted that the split between session and media levels introduces potential conflicts in the present SDP which should be avoided in SDPng.

Tom Taylor remarked that it would be nice to improve interoperability between SIP and Bearer Independent Call Control (BICC) by supporting the latter's model of separation of bearer-related and media-related information.

Philip Mart noted the desirability of coordinating whatever is added to SDP in the short term with the implementation within SDPng.

Henning wondered whether H.245 translatability is a goal.  Joerg said the work could aspire to match H.245 _as_actually_implemented. Henning would be interested in what people actually implement.  Joerg said the group would have to review interop event results.

Orit Levin asked if the aim was to create a protocol or a language. Dirk replied that the intent was to create a language.  Orit commented that H.245 goes well beyond language -- it is a multimedia control protocol.  Its advantages and disadvantages both come from that.  Dirk agreed on reflection: the group is talking about negotiation, hence more than just language.

=====================
SESSION II (Thursday)
=====================

1.  SDPng Informal Meeting

Joerg gave a brief report on SDPng discussions.  The group is looking forward to an XML-style strawman syntax proposal well before the next IETF.

2.  RTSP Update

Joerg reviewed the process since last July's bakeoff.  Changes are to be moved into a revised specification.  A volunteer is working on a revision draft.

3.  MBus Update

Dirk Kutscher reviewed the latest changes to the mbus-transport draft.  He reminded the meeting that Mbus is a local coordination mechanism.  The transport protocol draft covers message syntax, addressing, local multicast, and similar issues.

The draft has now been changed to allow for use of broadcast, only when multicast is not available.  It now includes the concept of a scope-relative multicast address.  The actual address has yet to be assigned.  The user MUST NOT use scopes larger than link-local.  The resolution of timestamps has been made finer to protect aginst replay attack.  Some bug fixes have been included.

Some issues remain.  The first is whether congestion control is a requirement.  It may not be possible because link bandwidth cannot be determined reliably: there is not necessarily a receiver behind each hub or bridge.  A request has been sent to IANA for a scope-relative address and port number.  For security the draft currently proposes DES, but could move to AES.  The authors will have to check if everything is ready for the use of IPv6.  Colin Perkins expressed the opinion that it probably is.  Finally, the authors must check the normative references.

Rohan Mahy asked if it was intended to extend conference control to mbus.  Dirk pointed out that conference control lies within the scope of the semantics draft rather than the transport draft.  Control is provided over what can be executed where.

Joerg noted two potential application areas:

-- the original intent: coordination of conference entities on a local LAN e.g. hardware control from a software user agent

-- networked appliances: rather than a UA in each appliance, have a few dedicated ones.

Next steps: the work is essentially done -- perhaps one more cycle before WG Last Call.  The question is whether it should go on Standards Informational Track.  Joerg responded that he would have to consult with the Area Directors.  Stephen Casner suggested the possibility that it be Experimental to start with.

Slides

None received.