Current Meeting Report
2.7.9 Multiparty Multimedia Session Control (mmusic)
NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It
may now be out-of-date. Last Modified:
Joerg Ott <email@example.com>
Colin Perkins <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
Allison Mankin <firstname.lastname@example.org>
Transport Area Advisor:
Allison Mankin <email@example.com>
To Subscribe: firstname.lastname@example.org
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
- initiating sessions and inviting users -- Session Initiation Protocol
- managing tightly-controlled sessions -- Simple Conference Control
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
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.|
Request For Comments:
|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
Reported by Tom Taylor
The meeting was chaired by Joerg Ott <email@example.com> and Colin Perkins <firstname.lastname@example.org>. MMUSIC met in Grand Ballroom D, on Monday from 1530 to 1730.
There were no comments on the proposed agenda. The Chair pointed out a correction on the version for the Olson draft (draft-olson-sdp-ipv6-02.txt) [available only at http://standards.ericsson.net/gonzalo/papers/draft-olson-sdp-ipv6-02.txt at the time of writing] due to a glitch in the IETF archival system.
2. Working Group Document Status (Joerg Ott)
Joerg Ott presented. draft-ietf-mmusic-mbus-transport-06.txt has been passed to the IESG. draft-ietf-mmusic-fid-05.txt will be passed to the IESG shortly.
3. Working Group Charter (Joerg Ott)
The current charter is very much out of date. The IESG is refusing drafts because they are not on the charter. Management is working on a new version with a narrow focus. Basically MMUSIC will be finishing existing work.
SDP revision for Draft Standard
- SIMCAP, FID, offer/answer, NATs
- key management
- new codecs and transports
- base spec + codecs/transports/ ...
MIBs for SDP, SDPng (maybe)
The charter will not include conference control etc. Such work will not be chartered without a BOF.
Joerg showed proposed milestones ranging to Jul 02 for an RTSP MIB, the final item.
Jonathan Rosenberg <email@example.com> noted that offer/answer is scheduled for Feb 02, a bit late from the point of view of SIP and the groups dependent on SIP's revision. Joerg responded that these milestones were meant to represent a pessimistic view, and it was hoped that this work could be completed early.
Flemming Andreasen expressed concern about a shutdown on SDP extensions. Joerg indicated that there is some room for extensions within the existing framework, however there will be close review of any proposals.
Joerg announced that the mailing list is moving to firstname.lastname@example.org as of 2002-10-01. People can subscribe immediately. Web page: http://www.ietf.org/mailman/listinfo/mmusic People MUST resubscribe -- they won't be moved automatically.
4. SDP-new (Colin Perkins)
The Working Group is trying to move SDP to Draft Standard. Hence we will avoid adding new features.
draft-ietf-mmusic-sdp-new has had one revision since last meeting, including the following changes:
- added a=inactive, ...
- complete rewrite of BNF, thanks to Jonathan Lennox. Please check!
- clarifications: a=rtmap a media attribute, b=AS is RTP session bandwidth, s=- SHOULD be used for sessions with no meaningful name.
- Note about a=maxptime: "Note that this attribute is introduced after RFC 2327, and non updated implementations will ignore this attribute." as suggested by Steve Casner.
- add c= example for IPv6
- Add Changes since RFC2327 section
Colin asked people to indicate if any more changes are proposed.
He asked for volunteers for interoperability testing. Christian Huitema <email@example.com> responded. Stephen Casner <firstname.lastname@example.org> asked what defines a feature for purposes of SDP interoperability testing. Colin responded that each line and each attribute constitutes a feature. The follow-up question was what constitutes a test of a feature: is it context dependent? We need someone to put together a list. Henning Schulzrinne <email@example.com> suggested that SIP interop events should generate some of the results. Jonathan Rosenberg remarked that these would cover only a subset of the needed test cases.
Mark Handley <firstname.lastname@example.org> wondered if we would recycle SDP to Proposed, then do tests. Colin expressed his hope that testing would be done soon enough to avoid that step. Mark suggested that the recycle come first, because it would be good to get rid of the old BNF. Henning Schulzrinne advised the group not to recycle -- otherwise SDP will never reach Draft. Christian Huitema agreed. Keith Drage <email@example.com> asked whether we need to demonstrate IPv6 implementations too. The answer was that we do.
Christian Huitema asked whether interoperability tests should be based on the modified specification. The answer was yes: that is what is required.
5. Connection-Oriented Media
David Yon <firstname.lastname@example.org> reported on the status of the draft.
Some of the changes:
- SCTP has been removed to another draft
- RFC 2119 boilerplate has been added
- the source address has been expanded: nettype addr-type unicast-address [port]
One issue was identified in the week before the meeting: specification of direction:reuse creates a potential problem with SIP INVITE when renegotiating a session. The issue revolves around the strength of the wording of endpoint behaviour. Jonathan Rosenberg suggested that the default should be "the endpoint SHOULD reuse a connection to the other endpoint if one is available". Paul Kyzivat <email@example.com> was the one who had raised the issue. It was noted that he was absent from the meeting, but might have a comment on the proposed resolution.
Jonathan Rosenberg had another comment: UDP can act as a connection-oriented transport when messages are sent back to the source address of the original UDP. He proposed adding sentences to point out this possibility. Colin Perkins noted that SDP does NOT assume unidirectionality -- it has traditionally had a bidirectional connotation. Symmetric RTP is not a new feature and nothing should be added which implies this.
Colin further noted that the revised BNF in SDP-new conflicts with this draft. He will update SDP-new to fix the conflict, but the group needs to check that there are no other conflicts with various extensions.
Rohan Mahy <firstname.lastname@example.org> wished to verify that the author is willing to add text on connection-oriented UDP to draft. David responded that he would, assuming ready agreement.
6. SDP and IPv6
The author was unavailable, so Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se> spoke to the draft. The latest archive version of draft is -01. Colin Perkins noted that there had been a couple of comments on the earlier version. The author should make sure they weren't lost. Christian Huitema remarked that the BNF for IPv6 addresses is too complex. The document should point to the actual IPv6 specification for everything below the top level.
Colin Perkins said MMUSIC could undertake WG Last Call as soon as the correct version is submitted.
7. Key Management Extensions
Presented by Fredrik Lindholm <Fredrik.Lindholm@era.ericsson.se>. This draft arose from an earlier one presented at IETF51. Discussion at that meeting resulted in a split of work between MMUSIC and MSEC. Frederik listed several desiderata, including single round-trip for each key exchange, and putting the parsing burden onto the key management protocol rather than applications. The proposed solution involves three new SDP attributes. It also requires one new header for RTSP.
Henning Schulzrinne noted that the attribute syntax will have to use quotedString for the keying data.
Frederik demonstrated the use of the attributes with SIP. Jonathan Rosenberg suggested that usage should be based on the offer/answer draft instead of SIP directly, so that it would have broader applicability. He also asked whether the method for rekeying is the same or different from that for initial keying. He emphasizes desirability of keeping it the same to preserve statelessness of the offer/answer model.
Jonathan noted a major change since last draft: MIKEY is now tunneled over SDP. Jonathan had concerns with this model. The author felt that the one-round-trip nature of protocol helps alleviate those concerns. Following on from this discussion, Colin Perkins noted that the draft doesn't clarify the requirements of the key management protocol.
Martin Euchner <Martin.Euchner@icn.siemens.de> asked what the authen field is used for. He noted that its use should be described.
Jonathan Rosenberg summed up: the real issue is MIKEY -- the SDP part is trivial. What is the outlook for MIKEY? The author responded that MSEC is currently chartered, and there is group agreement to work on MIKEY.
8. SDP, UDP, NATs
Christian Huitema presented. draft-ietf-mmusic-natreq4udp-00.txt was a personal draft discussed at IETF51. The IESG pushed back, since this work was not on the MMUSIC charter. The work was overtaken by events, particularly MIDCOM. Christian is deciding whether to forget about the work, submit it to MIDCOM, or publish it as a personal RFC.
draft-ietf-mmusic-sdp4nat-00.txt is a new version taking account of IETF51 comments and published as an MMUSIC draft. Christian proposed that it go to WG Last Call.
Stephen Casner <email@example.com> noted that the draft should reference the appropriate supporting RTP draft. He also noted an issue on case sensitivity.
The Chair ruled that these could be considered as Last Call comments; the document will be taken to Last Call.
Jonathan Rosenberg presented. As background to the draft, Jonathan recalled that it had originally appeared as RFC2543 Annex B. He noted that 2543bis and hence 3GPP R5 depend on this draft.
Should we allow changes in the media type of a stream? e.g. voice-FAX Proposed: yes. There is a related SIP issue interdependency. Tom Taylor <firstname.lastname@example.org> added voice/text alternation for hearing impaired as an example.
There was a debate over the implications for support of bidirectional streams. Flemming Andreasen <email@example.com> attempted to reword the explanation to indicate that as well a being ready to receive any codecs offered on a bi-directional stream, the offeror must also be prepared to send on any of them should the answeror select just one codec out of the offered set. Tom Taylor supported Flemming. Jonathan noted that this had implications for the Comedia . Potential complications with manyfolks. Accepts change in wording. Lawrence, Keith, Flemming: have challenge to reconcile offer-answer with three-way exchange.
Jonathan noted an issue on the wording of requirements for mixing, and proposed a model. Henning Schulzrinne noted a potential complication with FID (draft-ietf-mmusic-fid-05.txt). Rohan Mahy noted that alternative topological behaviours are possible, so we have to specify particular mixing behaviour. Otherwise we could get strange results. There was general agreement with Jonathan's proposal.
Another issue was that of synchronizing codec changes. There were two proposals: using a timer or providing feedback of the changeover sequence number. The latter approach only works in one direction. Henning Schulzrinne added words to clarify the problem. The difficulty is that the application is actually dealing in sets of codecs. If two sets overlap, the endpoint can't tell easily when transition occurs.
David Oran suggested that a three-way handshake might solve the problem for two parties. Other speakers reacted with some skepticism to this proposal. Colin Perkins noted that using a new payload type but the same format could cause problems. Christian Huitema suggested that we change payload type for all codecs to provide an immediate signal of the changeover. Sascha Ruditsky <sasha@RADVISION.COM> pointed out that misordering of packets could complicate identification of the changeover boundary. Hence the transition point is when the new codec is played out, not when it arrives. Gonzalo Camarillo argued for forced synchronization of media with signalling. Jonathan's response was that this effectively imposes timer. Flemming Andreasen suggested that there is a potential problem with any payload type approach. David Yon wondered if non-RTP media could cause a problem. Jonathan said that the transition becomes obvious in those cases. Roni Even <firstname.lastname@example.org> suggested that knowledge of the other end's capabilities allows more graceful management of the transition, but Jonathan disagreed.
One other issue is that of unidirectional codecs in a bidirectional stream. This is motivated by DTMF interaction with a media server. Jonathan listed various proposals for resolution, noting that the first proposal breaks 3GPP operation. Flemming Andreasen suggested another SDP extension, although the use of FID might be possible. Gonzalo Camarillo was willing to require support for both send and receive in order to signal any codec. Joerg Ott expressed a concern with the general movement to addition of new SDP attributes; applicability of existing ones should be explored first.
Colin Perkins noted that the draft needs security and IANA considerations. He asked if media attributes had any effect on the model. Jonathan had some general words covering this, which Colin thought have to go into the draft.
9. SDPng (Joerg Ott)
There have been two new draft revisions recently. The draft is getting more concrete.
Since last IETF: formal specification, SDPng schema, profiles and notes on usage of libraries usage have been added.
The draft needs an example of Megaco application.
Open issues have to do with the scope of the baseline specification.
- which definitions are implicitly known to all applications:
-- basic SDPng structuring only?
-- SDPng + RTP & AVP profile?
There is a potential performance issue with libraries: accessing them when initiating conferences could add delay and be error-prone. This could be solved by providing a standalone description, or a reasonably comprehensive set of basic definitions.
[See Joerg's charts for other issues.]
The authors are working on splitting the draft into an informative part for requirements and motivation, and a normative part for the rest. They have started on a reference implementation.
The next steps are to define more profiles and document the SDP to SDPng transition path. Everybody is asked to check if SDPng does what is needed.
Dave Thaler <email@example.com> noted a need to be able to express a set of addresses as multiple choice. He gave a couple of examples.
Connection-Oriented Media Transport in SDP
Key Management Extensions for SDP and RTSP
Session Description Protocol