--- ============================================================
--- 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
      - No RFC Published since Hiroshima
      - In the RFC Editor queue
           draft-ietf-mmusic-ice-19  now in AUTH48
      - IESG Evaluation::AD Follow-up
      - Publication Requested:: Waiting for AD Go-ahead
      - Ready for WGLC
            (to be issued by April 19 as a new draft expected)
            (to be issued by April 26 as a new draft expected)
            (to be issued by May 10)
      - the following documents completed WGLC.
         Updates are needed:
           (no updates since 3/2009)
      - Other Drafts from the WG

    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
      - 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

     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

      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

      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

      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
      - Flemming will incorporate the changes as part of the next

1.2  SDP Media Capability Negotiation Draft

      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

    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

    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

    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

    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
      - 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.