[MMUSIC] Draft minutes from San Francisco

Enclosed are draft minutes from MMUSIC in San Francisco. These need to be
submitted by tomorrow (Monday 14th), so please send any comments quickly. 
Copies of the minutes and presentation materials are available at
http://www.dmn.tzi.org/ietf/mmusic/

Colin

===============================================================================

Multipary Multimedia Session Control (MMUSIC) Working Group Minutes

Reported by Colin Perkins

    The MMUSIC working group met once at the 56th IETF meeting in San
    Francisco. The group discussed connection oriented media, various
    SDP extensions, Offer/Answer examples, SDPng, Internet Media Guides,
    and RTSP.

Introduction and Status Update

    Joerg Ott began the meeting with an introduction and status update.
    One RFC has been published since the last meeting (RFC 3388 on Flow
    Identification), and one draft is with the RFC Editor (draft-ietf-
    mmusic-reservations-flows-01.txt). The revision to SDP (draft-ietf-
    mmusic-sdp-new-12.txt) is under AD review, as are drafts in the RTCP
    attribute in SDP (draft-ietf-mmusic-sdp4nat-03.txt) and the SDPng
    Transition Strategies (draft-ietf-mmusic-sdpng-trans-03.txt). The
    SDP bandwidth parameters (draft-ietf-mmusic-sdp-bwparam-01.txt) are
    in working group last call, and comments are solicited.

    Joerg noted that the SDP specification has been revised due to Area
    Director feedback. Colin Perkins described the changes: a number of
    minor fixes to the ABNF, and significant updates to the description
    of the "k=" field and the IANA Considerations section. The registration
    requirements for attributes and other parameters have been significantly
    tightened with this revision, and comments are solicited regarding the
    degree to which these changes are appropriate.

    The SDP source filter draft (draft-ietf-mmusic-srcfilter-03.txt) is
    essentially complete, just needing editorial work. The chairs noted
    that they expect to issue working group last call on this in early
    April, and that anyone with comments should post them shortly.

    There is a new draft on SDP implementation status and interoperability
    (draft-ietf-mmusic-sdp-implem-00.txt), which is a first cut at the
    documentation needed to advance SDP to draft standard. Please read and
    comment.

    The working group has completed its charter, and a draft for a revised
    charter was sent to the mailing list prior to the meeting. This draft
    is under discussion between the chairs and area director, and comments
    are solicited from the group. It is expected that the revision will
    include work on SDP, SDPng, RTSP and Internet Media Guides. Conference
    Control has been ruled out of scope at this time.

Connection-Oriented Media Transport in SDP

    David Yon discussed comedia (draft-ietf-mmusic-sdp-comedia-05.txt). The
    changes in -05 include removal of source address/port per discussion on
    the mailing list, and removal of the current security considerations in
    preparation for a revision in the next version (again, as discussed on
    the mailing list).

    David noted that the main security issue is session hijacking, which
    can be solved by using secure media streams. In the absence of this,
    the attack can be downgraded to a denial of service, if the endpoints
    follow the rules in Section 4(b) and (c) of the draft, using duplicate
    incoming connections as a signal of the attack (this works for TCP and
    bidirectional RTP). Jonathan Rosenberg noted that using double connect
    as an indication of an attack might fail in the presence of forking
    invites; this needs further consideration.

    Next steps are to come to closure on the RTSP issues discussed on the
    mailing list, and to fold in the expanded security considerations into
    -06. Colin Perkins confirmed that the "eid" would be implemented as a
    separate draft if needed. David expressed the hope that the -06
    version would be ready for working group last call.

SDP key management extensions

    Elisabetta Carrara discussed changes to the key management extensions
    work (draft-ietf-mmusic-kmgmt-ext-07.txt).  The changes are primarily
    for clarification, and include a more detailed description of the
    interactions between SDP and the key management module, and rekeying.
    In addition, the IANA considerations section has been updated.

    The main issue previously noted was a bidding down attack, which
    Elisabetta described, but this has been solved in -07 by authenticating
    the list of proposed key management protocols in the SDP.

    Mark Baugher noted that another way to avoid the attack is to use only a
    single key management protocol, to avoid the possibility of bidding. Ran
    Canetti described how the attack is still valid in that case, since the
    bid down can be done over multiple INVITEs with different protocols
    meaning that the addition of authentication is the correct solution
    (even though it complicates the protocol).

    It was asked if Kerberos still works with the changes? Elisabetta said
    it should, but she would check to make sure.

    Colin Perkins noted that approval is needed from the transport area
    security advisor before this draft can advance, but that the changes
    appear to address the previously open issues.

SDP Security Descriptions for Media Streams

    Mark Baugher discussed SDP security descriptions for media streams
    (draft-ietf-mmusic-sdescriptions-00.txt). The aim of this draft is to
    replace k= with an attribute, suitable for signalling SRTP parameters.
    The draft is intended for applications where the signalling channel is
    secure. If the signalling is hop-by-hop, as is common with telephony,
    the intermediate hops must be trusted to maintain security.

    Changes from (draft-baugher-mmusic-sdpmediasec-00.txt) apply parameters
    to media streams, not codecs (see discussion at the previous meeting);
    apply parameters to the SDP media level only (as a result of improving
    offer/answer); add an "application" parameter allowing separate
    descriptions for SRTP and SRTCP; define use with offer/answer and
    augment the ABNF.

    Next steps are to fix known problems, in particular the ambiguities with
    SDP direction attributes, to generalize offer/answer, and to generalize
    to transports beyond SRTP, and to get implementation experience.

    Magnus Westerlund noted that RTSP doesn't currently define a secure
    signalling channel. This will need to be fixed, if this work is to be
    used with RTSP.

    Steve Casner asked if the semantics were well defined if more than one
    of "k=", "a=keymgmt", and "a=crypto" are present? This is not legal, but
    appropriate behaviour needs to be specified. It was asked how a system
    should behave if the key is referenced by a non-secure URI? This is
    clearly not appropriate use.

SDP attribute for qualifying media formats with generic parameters

    Flemming Andreasen discussed (draft-rajeshkumar-mmusic-gpmd-02.txt).
    This is intended to provide an alternative to "a=fmtp:", so that new
    parameters can be added to existing media formats. The example being
    a voice-band data parameter, to apply to codecs such as PCMU when
    used for modem or fax relay.

    Changes since -01 are to firm up the definition of the gpmd attribute,
    clarifying that it is intended for informative hints, and that lack of
    a gpmd parameters MUST NOT render the media format useless. Use with
    offer/answer has also been specified, as have registration procedures.

    Ruediger Kreuter asked if an echo cancellor parameter has been considered?
    Flemming replied that there are many ways of specifying this - see V.150 -
    how should it be specified? Colin Perkins noted that this should be a new
    extension draft, rather than being including in the gpmd draft, to avoid
    delaying the work.

    The chairs asked for comments, noting that they intend to issue a
    working group last call on this draft shortly.

SDP Offer/Answer Examples

    Alan Johnston outlined draft-johnston-mmusic-offer-answer-examples-01.txt
    which provides examples of the use of the offer/answer model. There have
    been a number of minor corrections and clarifications since the -00 draft,
    and the plan is to continue collecting new scenarios and seek review and
    comment from implementors. If you are implementing SIP and offer/answer,
    you are urged to review the draft and send feedback.

SDPng Update

    Dirk Kutscher presented an update on the SDPng work (draft-ietf-mmusic-
    sdpng-06.txt). Changes in -06 include a new document structure, new
    requirements for capability specifications, new capability negotiation
    rules, the removal of XML-Schema-based formal definitions and text on
    session-level information.

    Capability specifications are now required to support feature independent
    negotiation and must not require access to a package definition in order
    to process capability descriptions. This requires definition of a fixed
    set of basic types, encoding the type into values. In addition, names
    must be fully qualified.

    Capability negotiation rules have been updated to describe the general
    behaviour, leaving concrete behaviour implementation specific. Two
    alternative procedures are specified: an offer/answer based scheme
    and an RFC 2533 (conneg) style approach.

    Open issues include a concrete syntax definition, session level data,
    and possible use of libraries of definitions. Next steps are to give
    details on describing actual configurations and transport parameters,
    and a formal definition mechanisms for packasges. Other work items
    include specific package definitions (e.g. audio, video) and session
    level metadata.

Internet Media Guides

    Rod Walsh outlined Internet Media Guides (IMGs), a potential new work
    item for the group. An Internet Media Guide (IMG) is a collection of
    multimedia session descriptions expressed using SDP, SDPng or some
    similar 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.

    This problem lends itself to solution by (extensions of) some existing
    mechanisms: SAP and SDP/SDPng. MMUSIC therefore seems the natural home
    for the work. Other groups (e.g. DVB-IPI, TV Anytime, and the IP datacast
    forum) have identified similar needs, but do not have the experience to
    solve the problem.

    The chairs presented some initial charter text discussing the problem
    (subject to modification/approval from the area directors) and asked
    if the working group considered this an appropriate work item? Strong
    support was received.

RTSP

    Magnus Westerlund discussed changes to the Real Time Streaming Protocol
    (draft-ietf-mmusic-rfc2326bis-03.txt). The goal is to update and clarify
    the RTSP specification, with the aim of moving to draft standard RFC (a
    new proposed standard RFC may be required first, depending on the scale
    of the changes). The aim is to have the core specification completed by
    October 2003. The new version will be a minimal core specification, with
    extensions documents for NAT traversal, MUTE and UNMUTE and (possibly)
    a MIB, RECORD, secure RTSP, and RTSP over unreliable transport.

    Since the previous meeting, there have been 5 teleconferences discussing
    the spec (details announce on the mailing list or see http://rtsp.org/).
    A list of known bugs in the specification is also maintained at
    http://rtspspec.sourceforge.net/.

    Changes updates discussed recently include:
    	- Non-persistent connection support is now mandatory
	- IPv6 support added
	- Accept-Ranges as proposed in the core spec
	- Byte ranges will be allowed
	- Via header will not be changed to include client address
	- Clarification of 304 "Not modified"
	- Clarification of redirection
	- Agreed feature extension mechanism
	- Strengthened requirements for Destination header
	- Added source and destination addresses to the Transport header
	- RTP-Info's base URL is a PLAY request URL
	- Clarified interleaved usage
	- A SETUP to change transport parameters leaves the previous state
	  intact if it fails
	- Clarification that RTSP URLs are case sensitive
	- Range header now required in all PLAY responses
	- Range is formulated as start point (inclusive) to stop point
	  (non-inclusive)
	- Use of PAUSE when in Ready clarified

    Open issues include how RTSP extensions registrations are to be handled,
    and what are the requirements for new extensions; can timed requests be
    removed; handling of multiple SSRCs in RTSP; and inclusion of a warning
    header.

    Input from those working with RTSP was sought, since there is a shortage
    of manpower on this effort.

RTSP and NAT

    Magnus Westerlund discussed NAT traversal for RTSP (draft-ietf-mmusic-
    rtsp-nat-00.txt). The issue is not RTSP signalling itself, but how the
    media streams traverse the NAT, and how RTSP knows the correct external
    addresses to use after NAT traversal. Will also address cooperation with
    firewalls.

    The draft currently discusses use of STUN, symmetric RTSP, tunnelled
    media in TCP and application level gateways. Open issues exist with
    the use of STUN for symmetric NATs and symmetric RTP. Mark Baugher asked
    if the authors have considered potential issues with secure RTSP? May
    not be as simple as "just use SSL"? Philippe Gentric noted that the
    attacker is often the client, so a secure channel may not help security.

    Magnus asked for input, and is seeking a co-author to help complete the
    work.

Stream Switching Control

    Philippe Gentric discussed draft-gentric-mmusic-stream-switching-00.txt,
    a new draft describing how a server can signal that it is switching from
    one version of a stream to another (for example, for coarse-grained rate
    adaptation, when the limits of adaptation of a particular codec are
    exceeded).

    Alan Duric was glad to see the work, but asked if Philippe considered
    the problem that routers may not be saturated due to bandwidth, but due
    to packet rate? Maybe we should add a feature to change packetization
    interval? Joerg Ott agreed that this is something to consider, it's just
    another change in the media format.

    Magnus Westerlund asked if you can do other things than switch streams
    for congestion control? Philippe said yes, streams can be adapted in
    various ways, but this doesn't need protocol supoprt from RTSP.

    Ross Finlayson agreed that the concept was useful, but was unsure that
    RTSP is the place to put the signalling? Will the TCP nature of RTSP
    delay the congestion control signalling? Maybe use RTCP? Colin Perkins
    noted that it is important to differentiate between indication of loss
    for a stream (RTCP) and signalling to switch to a different stream (RTSP).

    Anders Klemets also liked the idea, but not the details. We have standard
    ways of specifying alternates in SDP, maybe want to leave those details
    out of this spec?

    Given the interest, it was agreed to move forward with this discussion
    on the mailing list.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic