Last Modified: 2004-07-29
Multimedia communications protocols use a common platform to express media and session descriptions: the Session Description Protocol, SDP. The many uses of SDP have led to (requests for) numerous extensions and have led to recognition of several flaws in the protocol design. In spite of these, it is widely deployed.
- To support this current deployment, MMUSIC will revise SDP suitable for publication as a Draft Standard RFC. This will involve correcting minor bugs and clarifying the current specification.
- Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings. These will be limited to use of SDP in conjunction with connection-oriented media such as TCP and SCTP, offering support to work with NATs and firewalls (e.g. via the ICE methodology), and exchange of media session security keys.
With the exception of these specific items, only extensions within the existing SDP framework will be done (e.g. registering new codecs and defining parameters for them extending SDP to include new address families).
To address the more fundamental issues with SDP, a next generation of SDP, referred to as SDPng, will be needed. An initial proposal is now available, and will be progressed to Experimental RFC while we gain experience with implementations. An informational document will be produced describing how the transition to a new session description protocol can be managed, to prepare implementors for such a future change.
MMUSIC will maintain and revise the specification of the Real Time Streaming Protocol (RTSP), including fixes and clarifications based on implementation experience. The revised RTSP specification will be re-issued as a Proposed Standard RFC. We will also document how RTSP can be used in the presence of NAT boxes.
An Internet Media Guide (IMG) is a collection of multimedia session descriptions expressed using SDP or some other session description format. It is used to describe a collection of multimedia sessions (e.g. television programme schedules). The IMG must be delivered to a potentially large audience, who use it to join a subset of the sessions described, and who may need to be notified of changes to the IMG.
MMUSIC will investigate delivery mechanisms for IMGs, generalizing our work on session announcement and discovery protocols (SAP, RTSP, SIP). We will investigate and document requirements for IMG delivery mechanisms, and identify the requirements that these delivery mechanisms impose on the session description formats used by the IMG. We will then work to produce a framework document outlining the use of (existing) protocols to create an IMG delivery infrastructure. After successful completion of these initial milestones for IMG delivery, the MMUSIC working group will decide whether or not MMUSIC is the proper place to pursue any needed mechanisms for IMGs, and if so, recharter accordingly
The MMUSIC work items will be pursued in close coordination with other IETF WGs related to multimedia conferencing and IP telephony (AVT, SIP, SIPPING, SIMPLE, XCON, MEGACO and, where appropriate, MIDCOM and NSIS). Where appropriate, new separate working groups may be split off (as has happened with the SIP WG).
The Working Group is also charged with addressing security issues related to the protocols it develops.
|Done||Conduct WG Last Call for SAP Internet-Draft|
|Done||Submit a revised Internet Multimedia Conferencing Architecture I-D.|
|Done||Submit a revised SIP I-D.|
|Done||Submit SDP to the IESG for consideration as a Proposed Standard.|
|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.|
|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.|
|Done||Submit IPv6 Extensions to SDP for Proposed Standard|
|Done||Submit SIP's offer/answer use of SDP for Proposed Standard|
|Done||Submit SDP4NAT for Proposed Standard (Informational?)|
|Done||Submit SDP source filter extensions for Proposed Standard|
|Done||Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG.|
|Done||Submit SDP security extension for Proposed Standard|
|Jun 04||Submit IMG requirements and framework for Informational|
|Jun 04||Submit RTSP MIB for Proposed Standard|
|Aug 04||Review work on IMGs and update charter accordingly|
|Aug 04||Submit revised SDP spec for Proposed (or Draft) Standard|
|Aug 04||Submit SDP Offer/Answer examples for Informational|
|Aug 04||Review work on IMGs and update charter accordingly|
|Sep 04||Submit SDP connection-oriented media draft for Proposed Standard|
|Nov 04||Submit SDPng transition scenarios for Informational|
|Nov 04||Submit SDPng base specification for Experimental|
|Nov 04||Submit ICE draft for Proposed Standard|
|Feb 05||Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)|
|May 05||Submit RTSP NAT considerations draft|
|Jul 05||Consider update of SDP specification for draft standard|
|Dec 05||Submit updated SDP Offer/Answer examples draft for Informational|
|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|
|RFC3259||I||A Message Bus for Local Coordiantion|
|RFC3264||PS||An Offer/Answer Model with SDP|
|RFC3266||PS||Support for IPv6 in SDP|
|RFC3388||PS||Grouping of media lines in Session Description Protocol SDP|
|RFC3524||PS||Mapping of Media Streams to Resource Reservation Flows|
|RFC3605||Standard||RTCP attribute in SDP|
Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
Reported by Colin Perkins and Joerg Ott
The MMUSIC working group met once at the 60th IETF in San Diego. Subjects under discussion included various SDP extensions and new attributes, remote call control using Mbus, the ICE methodology for NAT traversal, and the RTSP specification update.
Introduction and Status Update
The meeting started with an introduction and status update by the chairs. We have had no RFCs published recently, although the SDP bwparam draft is with the RFC Editor. Several drafts are under IESG or Area Director review: the IMG requirements and framework, kmgmt and sdescriptions. The ANAT spec and the revised SDP spec have been reviewed by the IESG and are being updated in response to comments received. Working group last call is complete on the comedia spec and offer/answer examples, and both are expected to go to the IESG shortly.
It was noted that the new charter and milestones have been accepted, although the milestones on the web-page appear to include both old and new milestones (this will be corrected). We have a milestone to decide on how to proceed with the IMG work, which may result in a charter update (this is under discussion between chairs, area director and IMG authors). Besides this, there are no further charter updates planned.
Connection-Oriented Media Transport over TLS
Jonathan Lennox discussed draft-ietf-mmusic-comedia-tls-01.txt. Aim is to provide privacy, authentication, and integrity for connection oriented media using TLS. TLS uses X.509 certificates, so there is a need to specify what identities should be asserted: host-based derived from SDP "c=" line; the certification that secured the SDP end-to-end (e.g. S/MIME or HTTPS, not SIPS); a URI-based identity derived from the protocol transporting the SDP, etc. There is also a need to support the use of self-signed certs by sending certificate fingerprints in SDP, since CA-signed certificates are expensive, hard to configure, etc. This concerned Jon Peterson, who is worried about the allowed identities and integrity validation of the SDP. There was some controversy if integrity validation should be required as a "SHOULD" or a "MUST" level feature, with Cullen Jennings arguing for "MUST", but Jon Peterson arguing in favour of the SSH model, with "SHOULD".
An open issue is that this defines only TCP/TLS, not TCP/TLS/RTP/AVP. Similarly, nothing defines TCP/RTP/SAVP. What should be the preferred way of doing secure connection-oriented RTP? Steve Casner suggested that it might be appropriate to wait until there is a use case for SRTP over connection oriented media, rather than trying to specify it now.
A related problem is the combinatorial explosion of RTP profile names. Steve Casner agreed that the explosion of names is a potential problem, but noted that the work needed to specify new profiles would limit them to those that are useful.
Connection Establishment Preconditions
Gonzalo Camarillo discussed draft-camarillo-mmusic-connection-precon-00. The motivation for this draft is that connections cannot be established until the bearer channel is ready, and some applications want to know that the connection is established and ready to transfer data, before alerting the user. This does not interact with QoS preconditions, since it represents a separate issue: the connection precondition cannot be met until the QoS precondition has been met.
Magnus Westerlund asked if connection establishment is just for TCP, or if it can be used for any transport? Any, potentially, provided there is a notion of a connection.
The consensus of the room was that this is appropriate as an MMUSIC work item.
Alternate Offers/Capabilities in SIP/SDP
Medhavi Bhatia presented draft-bhatia-mmusic-sdp-altcap-01.txt. This is an attempt to solve three classes of problem: better negotiation of codec capabilities, better negotiation when using encryption of SDPng, transparent transport of H.323 or other messaging through a SIP core. Proposal is to use MIME multipart entities in an offer/answer exchange, with content-ID and a (to be defined) Content-Reference header in each to allow an answer to indicate which MIME body in the offer is being responded to.
Jonathan Rosenberg, Rohan Mahy and Jon Peterson commented on various aspects of the problem statement, and on the interoperability issues with how this relates to other solutions. There seemed to be consensus that the encrypted/non-encrypted issue was a real problem, but it was not clear that there was agreement on the other issues. Joerg Ott requested that the next revision to the draft include a more clear problem statement, so we can better decide how the solution fits.
SDP for T.120
Joerg Ott outlined draft-ott-mmusic-sdp-t120-00.txt. T.120 is a TCP based protocol used for various applications, such as shared white-board and application sharing. It can be signalled using H.323, but not with SIP/SDP. The draft proposes a simple approach to support this in SDP: use comedia for connection set-up, indicate desired T.120 applications via SDP attributes, and provide bindings of T.120 conferences to SIP dialogs. This is a straw-man proposal and won't progress without an expression of interest. Feedback is solicited from anyone using T.120 in the context of SIP.
SDP Media Label
Gonzalo Camarillo discussed draft-levein-mmusic-sdp-media-label-00.txt. The motivation here is to provide a means to label "m=" lines in an SDP session description so that they can be referenced by an external application. The scope is intended to be wider than an offer/answer exchange, for example to allow references from an XCON XML document. Gonzalo explained why existing attributes cannot be used: the "i=" line is for display purposes only, and the "a=mid:" provides "m=" line identifiers within the scope of an offer/answer exchange only. He also noted that there is a bidirectional requirement, where a server needs to reference a direction of a media stream.
There was considerable discussion on this topic, relating to the choice of a semantic-free label rather than referencing a particular "m=" by it's position in the SDP file, or by using some existing attribute. It seems clear that there is interest in the problem, but that the authors need to clarify their rationale for this particular solution. The room consensus was to accept this as a work item.
Rohan Mahy outlined draft-mahy-mmusic-mbus-sdp-00.txt. This proposes a way to signal an Mbus control session in SDP, bootstrapping between SIP devices that are geographically close but not topologically close. It solves the discovery and keying problems with Mbus, and works with NAT and firewall traversal (e.g. using STUN). It does not address the congestion issues present in wide-area use of Mbus.
Rohan also outlined draft-mahy-mmusic-remotecc-00.txt. This takes the long expired draft-ietf-mmusic-mbus-call-control draft and proposes a split between call control verbs and notifications, and a re-factoring of the call control verbs. It was noted that the Mbus is defined for multipoint usage, and asked if it fits unicast call control? Yes, mostly: see the draft for details.
After describing the work, Rohan solicited input on these drafts, and discussion of requirements. Comments should be sent to the mailing list.
ICE: A Methodology for NAT Traversal
Jonathan Rosenberg presented an update on draft-ietf-mmusic-ice-02.txt Due to the crowded agenda, he restricts his presentation to a key open issue: concerns were raised that, as specified today, STUN is run as a shim layer on top of other protocols (such as RTP). This requires multiplexing of RTP media and STUN packets -- which is not so difficult for RTP as it can be done by looking at the first two bits. On the upside, it allows STUN to be re-initiated mid-stream as needed. Jonathan also discusses possible options: 1) always require STUN (initially and for keep-alives). 2) Allow for other keepalive mechanisms but define STUN right now. 3) Not do STUN at all but solve the problem for RTP by SSRC muxing. 4) Separate initial and mid-call: Use STUN only for the initial check and then do RTP with no checks. He notes that such a separation may have issues with packet misordering and that no recovery (state loss, route flap) is possible.
Discussion in the room clearly shows that there are concerns with the approach currently taken. It is proposed to consider initial and midstream checks independently. The initial check could also be performed using a connectivity precondition as defined for SDP O/A thereby avoiding the need to do muxing there. The importance of the midstream check is questioned (how likely is this?). Statements are made that the mid-stream case should be dropped. Another opinion was voiced that STUN appears to be the right choice for both initial and mid-stream. Jonathan notes that the mid-call stun doesn't allow you to continue operation in all cases. A question comes up that, if needed at all, whether or not mid-stream STUN is just an optimisation. Could one use another offer as an option? Jonathan would like to avoid such options.
Whether initial or mid-stream, the need for muxing STUN and RTP arises. A point is made that there is a need to indicate that a stun server should run on the port. It would be helpful if the SDP could indicate something that was in the packets to help demuxing (rather than assuming you can do it using the first 2 bits) -- this would make the approach suitable beyond just RTP.
Further points are made mid-stream may show up in RTSP when the client is in pause mode and therefore no RTP traffic is sent to it. There would be a need to either reply to mid-stream STUN or RTP noop packets. It is noted that a similar problem exists with SIP for calls with media on hold.
A comment is made that we disapproved the ITU's muxing T.38 over UDP with RTP on the same port and hence we should not be pursuing a similar -- equally ugly -- approach. Jonathan points out that NATs are ugly and that they fundamentally require to run STUN on the same port (if only for the initial connectivity check). To avoid the necessity for de-muxing (for dealing with re-ordered packets) the idea is brought up to do a three or four phase exchange and rewriting STUN accordingly.
The consensus of the group is that the initial STUN check is pretty much accepted. There is concern for running STUN mid-stream, and as a keep alive.
Magnus Westerlund discussed RTSP (draft-ietf-mmusic-rfc2326bis-07.txt) starting by highlighting the major recent changes to the draft: use of TLS over TCP for RTSP has been defined ("rtsps" -- an example connection was shown), use of the authorisation mechanisms taken from HTTP has been clarified, and a new chapter has been added that defined use cases. Many minor changes were also enumerated (see slides).
Open issues include: which keep-alive mechanism should be normative? should refusal by a server to perform media redirection have its own error code? should we change use of Accept-Language/Content-Language? are the current methods to prevent undesired media redirection okay? is the availability of protection against hijacking sufficient? are clarifications on how re-SETUP works needed? is there a need to specify implicit redirect? how can "#" and "?" in URIs be used? does proxy use need to be clarified? and, finally, are the changes sufficiently backwards compatible, or do we need to raise the RTSP version number?
Magnus solicited review from the group, since the spec is getting into good shape. Editing work will continue between the meetings, and phone conferences may be organised to discuss particular issues. The aim is to have the spec ready to last call after the next meeting.
RTSP NAT Traversal
Thomas Zeng discussed draft-ietf-mmusic-rtsp-nat-03.txt. After giving a recap of the requirements, a new candidate solution was outlined: a variation of symmetric RTP using probe packets. Then, Thomas gave an overview of the five candidate solutions: STUN, ICE, symmetric RTP, variation of symmetric RTP, and TURN; and outlined some of their pros and cons. He noted that the ICE framework, while a more general solution than some of the others, is complex and depends on TURN which is not needed when the RTSP server is in the open -- expected to be the common case. Jonathan Rosenberg explained the motivation of supporting TURN: it ensures that the ICE method always works, even in all edge cases.
It is clear that the working group needs to recommend a common RTSP NAT solution in order to meet market demand. The ICE method has potential, but there is a need to co-ordinate to ensure that the spec is completed in time, especially TURN, to also a need to define the mapping of ICE onto RTSP.
Thomas Zeng outlined draft-zeng-mmusic-rtsp-announce-00.txt. This is a continuation of draft-zeng-rtsp-end-of-stream-00.txt (presented during IETF-58), with the aim of extending the ANNOUNCE mechanism to publish events such as end-of-stream with a new header. It can run both client to server and server to client. The specification of the method was briefly described. Anders Clemets expressed concern about overloading of methods, although since this is written as an extension and the ANNOUNCE method is removed from the core spec, this should not be too bad. The consensus of the room was that this should become a work item.