[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
- [MMUSIC] Minutes from Dallas Colin Perkins