[MMUSIC] Minutes from Dallas

Colin Perkins <csp@csperkins.org> Tue, 18 April 2006 07:38 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkms-0003CW-T3; Tue, 18 Apr 2006 03:38:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkms-0003CR-Bb for mmusic@ietf.org; Tue, 18 Apr 2006 03:38:14 -0400
Received: from [130.209.249.184] (helo=mr1.dcs.gla.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVkmm-0003OG-Ab for mmusic@ietf.org; Tue, 18 Apr 2006 03:38:14 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62973 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FVkm6-0001kN-CE for mmusic@ietf.org; Tue, 18 Apr 2006 08:37:26 +0100
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Transfer-Encoding: 7bit
Message-Id: <21E4C37D-8A69-40DA-8E2C-6573C84850D2@csperkins.org>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
To: IETF MMUSIC WG <mmusic@ietf.org>
From: Colin Perkins <csp@csperkins.org>
Date: Tue, 18 Apr 2006 08:37:24 +0100
X-Mailer: Apple Mail (2.749.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c
Subject: [MMUSIC] Minutes from Dallas
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org

Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
====================================================================

Reported by Colin Perkins

    The MMUSIC working group met once at the 65th IETF meeting (Dallas,
    March 2006). Topics under discussion included the SDP Content  
Attribute,
    ICE, secure media stream setup, SDP for file transfer, RTSP, SIP for
    streaming media, QoS identification for preconditions, codec- 
specific
    parameters in SDP, use cases for session mobility and  
requirements for
    IPsec negotiation in SDP. The meeting was chaired by Joerg Ott  
and Colin
    Perkins and attended by some 130 participants.


Introduction and progress report

    The chairs introduced the session and gave a brief status review.  
The
    group has had one RFC published since the last meeting (offer/answer
    examples -> RFC 4317) and has a further ten drafts in the RFC Editor
    queue (including, finally, draft-ietf-mmusic-sdp-new-26.txt). There
    is one open rechartering issue, on how to continue with the Internet
    Media Guide work, and discussion on that subject is ongoing with the
    authors and area directors.


SDP Content Attribute

    draft-ietf-mmusic-sdp-media-content-02.txt

    Jani Hautakorpi presented the SDP Content Attribute draft.  This  
version
    clarifies the usage with offer/answer, but otherwise has no  
changes from
    the previous version. The group seemed happy with the draft,  
which looks
    to be ready for working group last call.


ICE

    draft-ietf-mmusic-ice-07.txt
    draft-ietf-mmusic-ice-tcp-00.txt

    Jonathan Rosenberg presented ICE, summarising changes since the  
previous
    version (see slides for details). There were some questions and  
comments:

    - Flemming Andreasen asked why the "a=ice-pwd" SDP attribute is  
session
      level only, rather than both session level and media level? It  
has to
      be shared across all candidates, but that doesn't necessarily  
imply it
      is a session level attribute.

    - Derek MacDonald asked for clarification if reliable 183 can  
work with
      "m=" lines that are set to inactive in the 180? Yes.

    - Magnus Westerlund asked if there is a way of saying "don't send  
early
      media" for a particular complete ICE exchange, since this  
option might
      be useful for RTSP. Jonathan didn't want to add this for SIP,  
but it
      can be added for RTSP in a separate draft if needed.

    - Magnus Westerlund noted that the current text regarding setting  
the
      RTP marker bit is audio-codec specific; this should be clarified.

    - Rohan Mahy asked for clarification of the 183 retransmit intervals
      for STUN reliability.

    - Magnus Westerlund asked if a change in the source address could  
trigger
      the RTP SSRC collision detection algorithm? It's not clear that  
this
      is an issue, since one can tell it is a change in address  
rather than
      a collision through the signalling exchanges. Steve Casner also  
noted
      that the wording on SSRC collision detection has changed in RFC  
3550,
      and that may affect this.

    - Erkki Koivusalo reminded the group of issues with using MAPPED- 
ADDRESS
      rather than XOR-MAPPED-ADDRESS and with learning new candidates  
from
      connectivity checks, as discussed on the mailing list.

    Jonathan Rosenberg stated that he considered the draft ready for  
working
    group last call apart from minor details. It is expected that an  
updated
    draft will be submitted shortly after the meeting to address  
these, then
    a working group last call.

    Jonathan Rosenberg also presented changes to the ICE-TCP draft.  
This is
    a major update, due to the changes to STUN and also the  
recognition that
    simultaneous open broke the mechanisms in the previous draft,  
requiring
    a rework of the specification. There are no known open issues,  
and there
    was little discussion (indeed, it appears that few people have  
read the
    draft). Joerg Ott asked for volunteers to provide detailed  
review: Jason
    Fischel, Rohan Mahy and Francois Audet volunteered.


Secure media stream setup

    draft-baugher-mmusic-sdp-dh-00.txt

    Mark Baugher presented a new draft on Diffie-Hellman exchanges for
    multimedia sessions. This adds the ability for sdescriptions to do a
    Diffie-Hellman key exchange (using a new session level "a=DH:" SDP
    attribute), providing perfect forward secrecy for media keys, and
    removing the need for secure transport of the SDP by using public  
key
    cryptography. This does not solve the "early media" problem with  
SIP key
    establishment, but does reduce the potential vulnerabilities of  
sending
    plain text keys and relying on secure SDP transport.

    Alan Johnston commented that he liked the idea better than the  
standard
    sdescriptions. He noted that person to person identification is a  
MUST,
    but the draft does not specify how the fingerprint is to be  
displayed. To
    ensure interoperability, and standard mechanism should be  
defined. Erik
    Rescorla wondered how to propose two different types of DH  
crypto?  This
    can be done by putting both in the SDP.

    Cullen Jennings and Joerg Ott noted that there are numerous  
proposals
    for updating security negotiation for SRTP, and that this fits  
within
    that general space. Discussion of this in comparison with the other
    proposals should take place within the RAI area meeting.


SDP for file transfer sessions

    draft-isomaki-sipping-file-transfer-01.txt
    draft-garcia-sipping-file-transfer-mech-00.txt

    Gonzalo Camarillo presented drafts on file transfer in the offer/ 
answer
    model. The idea is to describe, using a set of new SDP  
attributes, the
    file to be transferred, and so allow MSRP sessions to be  
negotiated to
    transfer the file, e.g. as a part of a SIMPLE instant messaging  
system.

    Discussion centred on whether duplicating MIME headers in SDP is  
a good
    idea, and why content-indirection is not appropriate.  There was  
a fair
    amount of requirements discussion, to understand why this is  
useful and
    to determine the correct home for the work (SIPPING or MMUSIC).  
There
    appears to be interest in the work, and it appears to make sense  
from
    an SDP perspective, so we should figure out the right home and  
proceed.


RTSP

    draft-ietf-mmusic-rfc2326bis-12.txt
    draft-ietf-mmusic-rtsp-nat-04.txt
    draft-westerlund-mmusic-3gpp-sdp-rtsp-02.txt

    Magnus Westerlund presented RTSP/2.0, outlining open issues with the
    base specification. These include: the definition of non-interleaved
    TCP/RTP/AVP, the inclusion of 50 and 60 frames-per-second SMPTE time
    code formats, the format of error message bodies, the format of  
the URI
    list in 300 responses (multiple choices), whether the dest_addr  
should
    contain used addresses, should there be a scoped address for IPv6
    multicast, use of unregistered media types in examples, should  
Expires
    also provide cache-control instructions, and proxy handling of
    Accept-Credentials. Details are provided in the slides.

    Regarding the SMPTE 50 and 60 FPS formats, Stephan Wenger  
volunteered
    to help with up a definition for the formats.

    Regarding the format of the error message body, Colin Perkins and
    Jonathan Rosenberg suggested stating that the format is HTML by  
default,
    with an Accept header being used to signal support for alternatives.

    Regarding the 200 response URI lists, Joerg Ott wondered why  
multiple
    Location headers couldn't be used?

    Regarding cache control, Colin Perkins noted that explicit  
specification
    is usually appropriate, rather than overloading the field, but  
Magnus
    doesn't want to diverge from HTTP behaviour more than necessary.  
Joerg
    Ott asked if live streams affect the cache behaviour? Not clear.

    Magnus noted that he hopes to resolve these open issues quickly,  
and is
    working with the TLS working group to review the TLS solution.  
Review of
    the draft was solicited to get it ready for working group last call:
    Stephan Wenger and Sean Sheedy volunteered to provide reviews.

    Magnus also briefly discussed the RTSP NAT traversal draft,  
noting that
    there have been no changes since the last meeting, and asking for  
help
    to complete the draft.


SIP for Streaming Media

    draft-whitehead-mmusic-sip-for-streaming-media-00.txt

    Marie-Jose Montpetit presented a new draft on evaluating the use  
of SIP
    for streaming media applications. The aim here is to discuss  
whether it
    makes sense to use SIP as an alternative to RTSP to control  
streaming
    media, if the protocols might somehow be combined (e.g. with SIP for
    session initiation handing over to RTSP for control), or if the  
current
    separation is the best approach.

    There was considerable discussion on the requirements and use  
cases. It
    is clear that the idea of blended services is popular, but it is  
not at
    all clear that a combined is needed to achieve them. The authors  
were
    suggested to further consider use cases, looking how the existing  
pieces
    of protocol infrastructure can be combined to address those use  
cases,
    and where potential holes might lie, to come up with a better  
problem
    statement for further discussion.


QoS Identification for Preconditions

    draft-polk-mmusic-qos-mechanism-identification-01.txt

    Gonzalo Camarillo briefly presented a new draft on QoS mechanism
    identification for use with preconditions. This adds a new attribute
    to identify which QoS mechanism is to be used to attempt to  
satisfy a
    QoS precondition. Flemming Andreasen agreed that this is a good  
idea,
    but asked if things like proxy-RSVP could be supported.

    The general consensus of the room was that this is conceptually a  
good
    idea, but not yet sufficiently baked to become a working group  
draft.


Codec Specific Parameters

    draft-xu-mmusic-sdp-codec-param-01.txt

    Peili Xu updated the group of the codec specific parameters  
draft. This
    was discussed at the last meeting, where it was suggested to  
consider
    how existing mechanisms (SDP extensions, SDP grouping, SDPng)  
might be
    used. The draft now makes such a comparison.

    Adam Roach noted that it is much easier to use existing mechanisms,
    rather than defining a new SDP extension, since there is no  
deployment
    challenge. Colin Perkins supported this, noting that codec specific
    parameters could be supported using the SDP grouping mechanism.  
Colin
    also noted that implementations that require codec specific ptime  
are
    broken according to the RTP a/v profile (a point which Flemming
    Andreasen disputed somewhat, noting that there might be  
legitimate use
    cases for this).

    To summarise, it is not clear that there is a problem to solve  
here that
    cannot be solved using existing mechanisms. Further clarification  
of the
    problem is needed, before we consider defining SDP extensions.


Use Cases for Session Mobility

    draft-komiya-mmusic-session-mobility-usecases-00.txt

    This presentation was dropped, due to lack of time.


IPsec negotiation

    draft-saito-mmusic-ipsec-negotiation-req-02.txt

    This presentation was dropped, due to lack of time.


				   - + -



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