NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Ruth Lang <firstname.lastname@example.org>
Eve Schooler <email@example.com>
Mark Handley <firstname.lastname@example.org>
Joerg Ott <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <email@example.com>
Transport Area Advisor:
Allison Mankin <firstname.lastname@example.org>
To Subscribe: email@example.com
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:
Conduct WG Last Call for SAP Internet-Draft
Submit a revised Internet Multimedia Conferencing Architecture I-D.
Submit SDP to the IESG for consideration as a Proposed Standard.
Submit a revised SIP I-D.
Submit a revised ITU Interoperability Scenarios I-D.
Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol.
Conduct WG Last Call for RTSP Internet-Draft.
Submit Internet-Draft on Internet Multimedia Conferencing Architecture.
Submit RTSP to IESG for consideration as a Proposed Standard.
Submit ITU Interoperability Scenarios Internet-Draft to IESG for consideration as an Informational RFC.
Conduct WG Last Call for SIP Internet-Draft.
Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard.
Conduct WG Last Call for SAP Security Internet-Draft.
Conduct second WG Last Call for SAP.
Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard.
Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard.
Request For Comments:
Real Time Streaming Protocol (RTSP)
SDP: Session Description Protocol
SIP: Session Initiation Protocol
Minutes of the MMUSIC WG Meeting at the 48th IETF
The MMUSIC WG met twice at the 48th IETF, Monday night 1930-2200 and Wednesday afternoon 1530-1730. Some 180 participants attended these meetings. In addition, the chairs organized an informal meeting to further the requirements discussion on SDPng which was held on Thursday night 2200-2330.
Notes taken and written up by Tom Taylor (Thanks a lot!).
Session 1, Monday, 31 July 2000, 19:30-22:00
1. Agenda Bashing
Joerg Ott <firstname.lastname@example.org>
The proposed agenda was as follows:
- Agenda Bashing (Joerg Ott, 5)
- WG Status Update (Joerg Ott, 5)
- Mbus Update (Dirk Kutscher, 15)
- Report from the RTSP Bakeoff (Ron Frederick, 30)
- RTSP Extensions (Sean Sheedy, 15)
The proposed agenda was accepted.
2. WG Status Update
New WG co-chair: Colin Perkins (ISI) <email@example.com>
New mailing list almost ready
Announcements of these changes await the charter page update.
b. Conferencing Architecture (draft-ietf-mmusic-confarch-03.txt)
Some non-substantive fixes needed -- will be done during Last Call period. The document should go to Last Call now.
c. SAP (draft-ietf-mmusic-sap-v2-06.txt)
Awaiting IESG approval.
d. SDP Source Filter (draft-ietf-mmusic-sdp-srcfilter-00.txt)
Last Call to be issued.
3. MBus Transport (draft-ietf-mmusic-mbus-transport-02.txt)
Dirk Kutscher <firstname.lastname@example.org>
Gave URL, quick refresher
- local coordination mechanism
- the original specification was split into three drafts, one of which covers transport
Changes in mbus-transport-02
- heartbeat hello intervals now dynamically calculated
- scale per number of entities -- basic principle that the total number received per unit time should be constant
- similar to RTCP timer reconsideration
- problem -- slows down bootstrapping process
- added mbus.ping to query for other entities
- considered stable
- could add procedures for behaviour in absence of multicast
- intend one more cycle before Last Call (2-8 weeks from now)
- split into individual parts
- informational documents
- connecting physically separate Mbus domains
- simple devices -- Mbus bootstrapping, allowing for broadcast rather than multicast
4. RTSP Bakeoff
Ron Frederick <email@example.com>
Hosted at Entera, 24-25 Jul
27 attendees, 7 organizations
Interoperability of various RTSP clients, proxies, and servers
- Passing real URL rather than * is useful when proxies are involved
- proxy can pass on to origin server rather than reporting its capabilities
- Unclear whether servers must allow SETUP without preceding DESCRIBE
- Must servers allow setup on subset of tracks e.g. audio only?
- Proposed to allow * for URL when PLAY specifies a session
- Queued PLAY
- Should specify that the CSeq numbers should be unique within a session
- Quoting the URLs would be useful
Comment: Jonathan Rosenberg suggested that angle brackets be used
- Clarify meaning of "seq" and "rtptime"
- more detailed example in the specification?
- Should RTP-info also specify the timestamp of the first real packet in the track?
- Useful to get session ID to associate state with before setting up a particular media stream
- All session ID examples are numeric -- should show alphanumeric
- Should SETUP always return Session? -- needed for some types of control
- More explanation of session timeouts
- distinguish session vs. control connection
- RTP/AVP/TCP and default multicast mutually contradictory
-- implies "unicast" should appear in header if TCP used
Comment: Steve Casner noted that the lack of multiple implementations of RTP/../TCP is an issue in AVT.
But -- does RTP/AVP/TCP imply interleaved? If not, no current means for client to request it except by specifying channel numbers.
Suggestion: specify that interleaved is always implied.
- Port numbers: specification should clarify what it means to specify only one port.
- What is the meaning of port range where port2 is not port1 + 1?
Christian Huitema cited an example where multiple non-adjacent ports might be used. He noted difficulties when trying to coordinate IP4 and IP6 port use.
Steve Casner reports reluctance to commit to the RTP convention.
- useful for proxies to add "source" field to transport to direct client RTCPs
- Servers should take more care with sequence numbers and timestamps when seeking
- Setting marker bit for audio in a server is difficult -- servers may not know it is audio
- preferable to have clients rely on "seq" field in RTP-info to force playout adaption to occur at the transition point -- works for both audio and video
- a=control: relative URL handling
- How to process Content-Location to obtain base
- legality of relative URL at session level
- when session-level control specified, does it replace the base URL?
- How to do content negotiation
- some non-standard extensions e.g. quiktime
- On video tracks, "cliprect" field very useful even when playing back at natural size
- "Stream done" notification would be useful
- Should RTSP proxies preserve port nos.?
- multiple Setups
- How should multiple instances of same header be handled
- could be legal and sensible for some but not for others
- Jonathan Lennox comment: same question in SIP - allow multiple instances for any header which permits comma-separated list of items
Note from Colin: be sure to share any RTP-related interop results with AVT
5. RTSP Extensions (draft-sheedy-mmusic-rtsp-ext-01.txt)
Sean Sheedy <seans@nCube.com>
Changes since Adelaide:
- ATM address syntax now matches the atmsdp syntax
- Unified play queue control syntax
- Restrictions on reuse of transport
- Simplified profile and lower transport -- MP2T/AVP/AAL5
- NSAP Address -- optional dots
- VPI/VCI address -- uses server-spec port addr
Didn't include the complete gamut of addressing possibilities
- doesn't see as desirable -- too complicated
Play Queue Control
- Previously much interaction between play- , flush-now
- now combined in one command
Reuse of transports
- Restricted to presentation URI, ...
- Wildcard URIs
- clarified restrictions
- notes interop suggestions
- never allowed in SETUP
- URI header in response indicates what specific URIs were
matched by wildcard
- Define ATM addressing syntax by reference to ATM SDP document
- QAM and DVB addressing syntax
Someone noted that the transport reuse extension works only with simultaneous presentation
- typical of nCube applications
- would be nice if the mechanism were more general.
Sean expressed concern that without restrictions one can get into trouble.
The questioner explained that he wanted to play one item after another without setup between. A typical use would be for targeted trailers preceding the main feature. They would use the same codec and bit rate.
It was suggested that one could at least relax the bit rate restriction -- wireless has a scalable bit rate. Sean found this acceptable.
A further question was raised regarding bandwidth: what is the relationship between the quantity specified when reserving via RSVP and the quantity specified in the RTSP? Which overheads are included?
Sean indicated this needed more thought -- the relationships are clearer with QAM and DVB.
RTSP Going Forward
- Cleanup -> Draft Standard
- bug fixes
- issues -- to go to list
- Implementation survey
- remove unnecessary parts from draft
- demonstrate interoperability
-- preconditions for getting to Draft Standard
- New bake-off 3-6 months from now -- details TBD
- Had other work items
- fctl extensions -- Sheedy draft + bakeoff findings
- fold into RTSP?
- Extensions for other Transports
- generalization needed
- largely SDP issue
- work continues -- keep as separate spec.
- Ron Frederick asked for additional participants to talk through the issues
Session 2, Wednesday, 2 August 2000, 15:30-17:30
1. SDP Extensions for ATM (draft-rajeshkumar-mmusic-sdp-atm-02.txt)
Rajesh Kumar <firstname.lastname@example.org>
- key question: will this be accepted as an MMUSIC work item?
- applications include Megaco and MGCP control of ATM connections, SIP signalling for ATM
- Extensive comments have been received on the list at email@example.com and have been assimilated into the document.
- hoping to finalize in next month and forward for WG Last Call.
Summary Of Descriptive Capabilities
- Bearer network identifier (ATM)
- ATM address self-identification
- VC and CID addressing
- RTP payload type declarations for AAL1 and AAL5 audio
- AAL2 profile declarations - standard, custom
- AAL5 applications include data, video, H.323 Annex C, af-vtoa-83
- correlation of service-level connections with ATM bearer connections
- mapping of codecs into services (per Q.BICC)
- ATM parameters
- special capabilities: leaf-initiated join, anycast, lawful wiretap, SVC caching.
Rajesh displayed a few examples of the proposed syntax.
Discussion: the reference to the AAL5/AVP transport stack is incorrect as it stands: a reference to a profile document is needed.
Colin noted that SDP does not currently provide for the use of dollar signs ($). It was explained that these are used for wildcarding.
Joerg asked SDP experts to re-review the document. He noted that it had made definite progress. He had some small comments, which he would convey to the author off-line.
2. SDP Media Alignment in SIP (draft-camarillo-sip-sdp-00.txt)
Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
Gonzalo's proposal is intended as an interim measure before SDPng becomes available.
The problem is how to signal mid-session changes in media stream characteristics, where multiple media streams have been defined. A more elegant scheme is needed than matching the Nth line of the new SDP against the Nth line of the earlier description.
Gonzalo provided examples justifying changes in port number: in cellular communications, when alternative RTP stacks are being used, or when the signalled device is a transcoding point.
Gonzalo proposes a flow identifier (fid) attribute. However, there is a backward compatibility problem. The workaround is that the "a" line should activate the current session description.
The question posed to the meeting was whether the proposal is seen to be useful. Christian Huitema expressed his support. There are situations where you want to express alternatives as opposed to simultaneous media flows. You may need different routes for the alternatives, implying different "m=" lines. He suggested "mediaID" labels for the "m=" lines, rather than "fid" as proposed.
The key point is that a method of stating alternatives and switching between them is needed.
Flemming Andreassen asked how RTCP would be managed under the proposal. Gonzalo agreed that this is an open issue.
Henning Schulzrinne wondered whether the means exist to achieve end-to-end agreement that this feature would be supported. He noted the option to use MIME types (e.g. multipart/alternative).
There was a remark on how a need for precisely this capability was identified at the RTSP bakeoff.
Colin expressed his reaction: this was a medieval way of mangling SDP. Jonathan Rosenberg suggested that typically there will be no switching between options: the requirement is just "pick one" expression. Colin suggested that was easy to express in an attribute.
There was initial disagreement on whether one or multiple sessions would be needed to achieve the necessary expressiveness. One person noted that there is also the need to support multiple streams (audio in particular) at once. Another remarked that it is also desirable to be able to switch dynamically without waiting for a signalling round-trip. The conclusion from this discussion was that the alternatives should be expressed as multiple RTP sessions.
Christian Groves noted Megaco's use of streamIDs and multiple alternative sessions. Tom Taylor added that Megaco uses additional semantic tags to indicate whether the intent is "pick one" or "reserve all so a choice can be made later".
Henning Schulzrinne noted an appplication to DTMF routing.
Colin concluded that the proper approach would be to use MIME multipart/alternative.
3. SIP for xcast-based Multiparty Conferences
Bart van Doorselaer <Bart.Van_Doorselaer@alcatel.be>
The problem: how to set up multiparty conferences.
- Sip or SAP? or E-mail or web?
- multicast, bridge vs. mesh?
There are three known SIP schemes:
- conference bridge
- single point of failure
- extra element in the conference
- special case of a local bridge still a single point of
- distributed multi-party conference
- bandwidth hog
- classical multicast
- complexity of address allocation
At this point the speaker provided a brief introduction to Xcast technology. Xcast is a work in progress. There are different proposals for how it should work. Distribution is via a tree. The packet header contains the (multiple) destinations to which it is to be delivered. In the simple Xcast case, the list of IP addresses in the header all use the same UDP port. The block diagram Bart showed placed the Xcast capability within the IP stack.
The speaker walked through a three-party call setup, in five steps with the call initiator controlling each. The conclusion was that rules need to be established for use of SDP in the Xcast case. There is an issue with UDP port numbers, in that they are allocated dynamically. Possible solutions are:
- use UDP-enhanced Xcast
- require the destination to allocate the same port as the originator
- negotiate the port.
Conclusion: Xcast is attractive for small conferences, but the port issue is present or the UDP-enhanced version of Xcast must be used.
The speaker was asked what happens if the conference grows too large. He confirmed that this would trigger a change in the call paradigm.
Stephen Casner noted that Xcast may or may not be developed.
Bart was asked whether he himself had developed an Xcast application. He has not yet done so.
The last question was what sort of device it would be run on.
4. MPEG-4 (draft-singer-mpeg4-ip-00.txt)
David Singer <firstname.lastname@example.org>
David Singer gave a brief report on the status of the MPEG-4 framework draft as it related to MMUSIC.
The draft currently assumes at most one MPEG-4 session is specified in any SDP description. They hope to lift that restriction.
They have worked on reducing round-trips required to describe MPEG-4 sessions.
RTSP requires particular care in the mapping of streams. The mapping must take account that MPEG-4 features multiple independent streams.
It was necessary to use MIME types to describe MPEG-4 data.
They are working on dual consensus between ISO and the IETF.
No comments were received.
5. TIPHON Requirements For SDPng (draft-tiphon-background-00.txt,
Paul Sijben <email@example.com>
The focus of the TIPHON architectural work is on QOS parameters and QOS budget allocation to individual networks along the call path. The TIPHON model deals with user, application, and transport views. Within this framework, SDP deals with the application view.
Paul's presentation suggested a set of mechanism-independent QOS parameters. Parameters dependent on specific transport mechanisms could be examined in the future.
The basic concept of the architecture is that the QOS budget is negotiated between elements on the path.
TIPHON expects to release their documentation in the first quarter of 2001.
[To understand the discussion which followed, it is necessary to be aware that Paul's architectural diagram showed a series of networks along the call path, with the signalling entities controlling the media entities at the boundaries between these networks. Because both signalling and media pass along the same path in this model, signalling can meaningfully control transport QOS. - PTT]
Henning Schulzrinne commented that the architecture was puzzling: in general, transport and signalling follow separate paths. Moreover, the preconditions draft (draft-manyfolks-sip-resource-01.txt) is available to coordinate QOS setup. Jonathan Rosenberg seconded the comment on the architecture. Radhika Roy said he could accept the concepts, but was not sure how they would be implemented.
Paul replied to all of these comments that there has to be some relationship between the QOS supplier and the user for billing.
Christian Huitema remarked that the internet requires an absolute separation between applications and transport -- for example, billing would be based on RSVP.
Paul Sijben maintained that people were reading too much into the architecture. There will be points through which media must pass, with transcoders as an example, and these points will get into a QOS discussion.
Mark Handley expressed similar objections to other members of the audience. Henning Schulzrinne maintained that there was no way service providers know how many MGs are in the media path.
Richard Swale <Richard.Swale@bt.com> suggested that other TIPHON documents dealing with QOS may promote a more productive discussion.
6. SDPng -- Requirements (draft-kutscher-mmusic-sdpbg-req-00.txt)
Dirk Kutscher <firstname.lastname@example.org>
A "bar BOF" on SDPng was announced at the start of this topic.
Joerg asked for limited attendance.
Dirk noted that he had published a URL:
pointing to a collection of relevant documents. The presentation would cover motivation, terminology, general requirements, session description requirements, and capability negotiation requirements.
- no negotiation in SDP
- primary extension mechanism is through "a="
- free extensibility
- unknown attributes ignored
- problem: no way to indicate attributes which MUST be understood or the session fails.
- extensions are getting unmanageable
Henning Schulzrinne suggested that the choices for indicating mandatory attributes are MIME or an out-of-band indication of intent. Mark Handley noted that PINT solved the issue by specifying the "required" attribute tag.
Dirk added one other motivation for looking at SDPng: the limited expressiveness of SDP.
- ... (see charts)
- text encoding
- SDP-mapping (SDPng to SDP)
- may not always be possible
Henning Schulzrinne suggested that this last requirement be dropped and replaced with an advance negotiation of SDP vs. SDPng. On the other hand, it is important that the mapping from SDP to SDPng be simple.
Joerg Ott noted the possibility of a gateway between the two protocols -- a mapping is needed in both directions.
Mark Handley noted the value of SDP. He indicated a requirement to control extensibility of the new protocol.
Session Description Requirements
- media types
- fit RFC 1889/1890 model of standard and dynamic payload types
- reuse payload formats, format names
Christian Huitema added the need to be able to specify "pick one" versus "support all" semantics.
- transport parameters
- different transports, QOS models, and associated parameters
- asymmetric configurations
- conciseness, structured extensibility
- implies grouping of definitions, ability to refer to groups.
Capability Negotiation Requirements
- model for specifying alternatives
- negotiation model
- syntax, semantics
- fit with SIP three-way handshake
- feature-unaware negotiation
- ability to group capabilities
Tom Taylor noted the need for the ability to negotiate increments to the current session.
- able to express constraints
- simultaneous capabilities
- processing rules.
- gather more requirements
- Megaco input
- specific link layers and protocols
Mark Handley commented that the new protocol should not obsolete SDP: it should be an alternative. SDP should go to draft standard. If this does not happen, it will be a problem for deployed implementations.
Someone else commented that SDPng should not reproduce the complexity of H.245. Another comment: there could be different needs for different entities in the signalling path -- endpoints vs. gateways vs. proxies.
7. SDP Next Steps
Colin volunteered to be the RFC 2327 bis editor. Mark noted about fifteen known errata.
What is the future?
- need an implementation overview and interoperability statements.
Henning asked if compatibility is necessary. For example, it would be nice to get rid of the requirement for characters in the "s=" line. It was agreed that this can't be fixed.
Mark was especially concerned to learn of implementations for the "v=" field -- it is essential to make the specification work (the time adjustment part), but no one seems to do it.
8. SDPng Reprise
Should SDPng break backward compatibility? It was agreed that it might as well do so, since it was introducing new semantics.
The timeline was set at a March, 2001 finish.
The design team would be settled at the bar BOF.
MPEG-4 on IP Framework
RTSP Interoperability Bakeoff
Status of ATM SDP work
SDP Media Alignment in SIP
SIP for Xcast