--- ============================================================
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- Minutes of IETF#77 MMUSIC WG Meeting
--- Tuesday, March 23, 2010 - 15:20-17:20
--- ============================================================
Thank you Cullen for being the RAI AD for MMUSIC.
Thank you Joerg for chairing MMUSIC for 13 years!
CHAIRS: Jean-Francois Mule <jf.mule@cablelabs.com>
Tom Taylor <tom111.taylor@bell.net>
The MMUSIC WG met on March 23 at IETF#77.
The session was attended over 50 participants. The meeting was
chaired by Tom Taylor and Jean-Francois Mule. The minutes are
reported by the chairs.
0. Introduction and WG progress report
The IPR notice and Note Well text were presented.
There was no comment on the agenda.
The chairs thanked Joerg Ott for his many years of service and
all WG participants gave him a round of applause.
The WG progress report since IETF#76 was presented:
See the new Document Tracker
http://datatracker.ietf.org/wg/mmusic/
- No RFC Published since Hiroshima
- In the RFC Editor queue
draft-ietf-mmusic-ice-19 now in AUTH48
draft-ietf-mmusic-rfc3388bis-04
- IESG Evaluation::AD Follow-up
draft-ietf-mmusic-connectivity-precon-07
draft-ietf-mmusic-sdp-capability-negotiation-12
- Publication Requested:: Waiting for AD Go-ahead
draft-ietf-mmusic-rfc4756bis-06
- Ready for WGLC
draft-ietf-mmusic-sdp-media-capabilities-09
(to be issued by April 19 as a new draft expected)
draft-ietf-mmusic-media-loopback-12
(to be issued by April 26 as a new draft expected)
draft-ietf-mmusic-image-attributes-04
(to be issued by May 10)
- the following documents completed WGLC.
Updates are needed:
draft-ietf-mmusic-media-path-middleboxes-02
(no updates since 3/2009)
- Other Drafts from the WG
draft-ietf-mmusic-sdp-cs-03
draft-ietf-mmusic-rfc4566bis-02
draft-ietf-mmusic-rtsp-nat-08
draft-ietf-mmusic-ice-tcp
Roni Even noted a typo in the slides presented at the meeting
since the current version of sdp-media-capabilities at IETF 77
is draft-09.
To conclude the WG chair report, Jean-Francois clarified the
status of draft-ietf-mmusic-sdp-misc-cap-00 (see the chair's
slides #9).
This Internet-Draft was mistakenly accepted as a WG document
without confirmation on the list.
After a brief recap of the I-D history and scope, several
comments were made in support of continuing the work as part of
a WG item as long as the scope does not overlap with ICE for
IPv4-IPv6 connection address negotiations:
- Roni Even indicated support for the work and noted that the
b parameter was part of the original SDP capability
negotiation framework.
- John Elwell, Gonzalo Camarillo, Jonathan Lennox and Cullen
Jennings are in favor of the work item as long as its scope
is clarified to not overlap with ICE for IPv4-IPv6 address
negotiation.
- Ingemar Johansson also expressed support for it
There was strong support for continuing to define a capability
parameter for b, i and some concerns with the ccap parameter.
More discussions occurred at the end of the meeting when the
document was presented, see notes below.
Jean-Francois proposed the next steps:
- the WG chairs will confirm the interest for a WG item to
define additional SDP cap neg parameters (b and i lines)
- Pending AD approval, the WG item will be chartered
- Simo V. will re-submit an updated Internet-Draft as an
individual submission
- then the chairs will ask the list if the Working Group
supports making Simo's individual submission as the WG
draft.
Robert Sparks speaking as the RAI AD indicated he supported
this plan of action.
1. Primary SDP Capability Negotiation Drafts
1.1 SDP Capability Negotiation Draft
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-12
Flemming Andreasen presented the updates in draft-12 based on
the IESG reviews.
All IESG comments have been addressed, see slides 7&8 for the
key changes. No questions or comments were expressed during
the meeting on these changes.
Flemming discussed the comments raised by Bob Gilman on the
list regarding the use of acap for session level attributes
(slide 9).
Based on additional comments from Jonathan Lennox, there was
consensus to:
- not add a new attribute like scap - keep using acap
- add clarifications in the I-D as part of the processing of
SDP cap neg on the answering side to say that a
session-level attribute not understood by the receiver
should/must be ignored.
There was agreement to accept the text changes on transport
capabilities (see slide 10 and mailing): clarify text as
suggested ("transport protocol" versus "transport protocol
capability").
Additional notes re: TIAS based on a comment from Roni Even:
see mailing list based on discussions held on 3/26 at IETF, it
is recommended to remove the paragraph re: TIAS in SDP cap
neg.
Next steps:
- Cullen Jennings said he was reassured that the Working Group
was comfortable with the post-WGLC changes that had been
made to the document. He cleared the last discuss during
IETF#77.
- Flemming will incorporate the changes as part of the next
updates.
1.2 SDP Media Capability Negotiation Draft
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-09
Roni Even covered the recent updates in draft-09 and mentioned
the good review comments from Kevin Fleming.
There were some comments to move the bcap parameter back into
SDP media capability negotiations. Roni argued against:
keeping bcap in a separate document allows for finer
granularity in the choice of what to implement (or it would
cause some additional work on option tags).
The next steps for this I-D are:
- an update is expected to address Kevin's comments
- a WGLC will be started by April 19 if the update is posted
by then, or shortly after.
2. RTSP 2.0
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-23
Martin Stiemerling presented the ID updates for RTSP 2.0.
All tickets against RTSP are closed.
There were no comments on the set of changes presented (see
slides for details).
The issue related to the handling of media line groupings and
dependencies in RFC 5583 must be taken to the list - see slide
7.
It is the intent of the WG chairs to push for this document's
completion before the next IETF.
There was a call for several volunteers to review RTSP sections.
Tom Taylor and Wolfgang Beck volunteered.
The next step is to issue a 4-week WGLC (done on 3/26, WGLC ends
on 4/23).
3. Secondary SDP capability drafts
3.1 draft-garcia-mmusic-sdp-misc-cap
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-03
Simo Veikkolainen presented the minor changes. There were no
comments. This draft will go through WGLC once we complete the
other higher priority calls.
3.1 http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-01
See minutes from the WG chair report above in this document for
a status clarification on the Internet-Draft.
Simo Veikkolainen presented the draft changes.
Jean-Francois Mule expressed a preference for having the port
number as a distinct capability parameter. Based on comments
from Hadriel Kaplan and Jonathan Lennox, there was a consensus
to keep the port in the ccap parameter as currently proposed
unless there is a good use case for port only.
As noted earlier in these notes, there were some comments about
the potential use of ccap instead of ICE for IPv4-IPv6. ccap
addresses a requirement to be able to negotiate alternative
nettype address. This discussion point should continue on the
list to seek a resolution. For example, one option might be
that the updated draft calls out this particular applicability
of ccap and point to ICE.
3.2 http://tools.ietf.org/html/draft-boucadair-mmusic-altc-00
http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-01
These two drafts were presented one after the other before we
opened the discussion since they address the same use cases but
with different methods.
Mohamed Boucadair presented an alternative connectivity
attribute proposed termed ALTC. This draft is an update from
what was proposed in IETF#75 as draft-boucadair-mmusic-ccap.
Andy Hutton presented a proposal for ICE microlite (ICE lite
without connectivity checks).
There were several comments made by Cullen Jennings, Jonathan
Lennox, Hadriel Kaplan, and Mohamed Boucadair.
- Cullen warned about the cases where IP connectivity cannot
be taken for granted, in particular in IPv6 deployments.
Hence the applicability of this mechanism would be mostly
for walled-garden environment. ICE was designed so that UAs
know that there is connectivity for the media path.
- Hadriel Kaplan commented that these solutions are meant for
use within a SIP Service Provider's network where there is
awareness of connectivity
- Jonathan Lennox asked what is the impediment to having an
ICE lite implementation (just have to respond to
connectivity checks?). If both sides do ICE lite, then you
revert to this microlite solution.
- Andy Hutton confirmed that indeed, the proposed solution
were made to avoid having to respond to STUN connectivity
checks
- Hadriel Kaplan added that there is indeed an impact to
responding to connectivity checks.
- Cullen:
This only works if you are in a walled garden environment.
But if it is meant to change the impact on DSP resources, in
fact you get no significant drop in the number of relevant
audio streams.
- Gonzalo Camarillo reminded the group that a decision was made
to go with ICE and that these proposals keep re-hashing
arguments over and over again without bringing anything new.
- Hadriel Kaplan responded that the decision for ICE lite to
mandate responding to connectivity checks dates back from
IETF 68 and that some folks still do not want to implement a
responder to connectivity checks
- Jonathan Lennox commented that ccap is also part of this discussion.
Perhaps adding a nettype into ICE instead of ccap would be a
possibility to address the delta between ICE and ccap.
There must be more justification for why responding to STUN
connectivity checks is expensive.
Based on the discussions, the chairs concluded that the main
motivation for these two drafts is to simplify ICE lite to remove
the response to connectivity checks. As was pointed out, a number
of scenarios in IPv4 and/or IPv6 deployments drove the ICE design
and solutions developed for walled-garden approaches may not lead
to the expected results.
Based on the current proposal and without further new and
substantive justification, there does not appear to be any path
forward for either altc or ICE microlite.
The meeting was adjourned.
>end.