[MMUSIC] IETF#72 MMUSIC WG meeting minutes posted

The minutes from the Dublin meeting are now posted at:
http://www.ietf.org/proceedings/08jul/minutes/mmusic.html

I paste them in txt format below.

Let Joerg and I know if you have any comments.
Thanks,
Jean-Francois.
---

---
--- ============================================================
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- IETF#72 MMUSIC Meeting Minutes
--- Friday, August 1, 2008, 0900-1130
--- ============================================================

    The MMUSIC WG met once at IETF#72.  The meeting was chaired by
    Joerg Ott and Jean-Francois Mule.  The session was attended by
    about 70 participants on Friday morning.

Minutes reported by Jean-Francois Mule

1/ Introduction and progress report

    The chairs reminded everyone of the Note Well text and the IETF
    Intellectual Property policy.  There were no comments on the agenda
    and Joerg Ott gave a brief status update of the working group
    deliverables.

         - MMUSIC WG Charter:
           The charter has been revised since IETF#71.  All working
           group drafts have milestones - see charter page for
           details.  Additional comments to the chairs are welcome.

         - RFCs Published since IETF#71 in Philadelphia:
           RFC 5159: from draft-dondeti-oma-mmusic-sdp-attrs-00.txt
           RFC 5168: from draft-levin-mmusic-xml-media-control-13.txt

         - RFC Editor Queue:
           http://tools.ietf.org/html/draft-ietf-mmusic-ice-19 still in
           the editor queue due to dependencies on other drafts.

         - Publication Requested:

http://tools.ietf.org/html/draft-ietf-mmusic-qos-identification-01.txt

         - Awaiting Write-up and/or Publication Request:

http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-
09

http://tools.ietf.org/html/draft-ietf-mmusic-file-transfer-mech-08.txt

http://tools.ietf.org/html/draft-ietf-mmusic-sdp-source-attributes-01

         - Ready for WGLC:

http://tools.ietf.org/html/draft-ietf-mmusic-connectivity-precon-04.txt

         - Needs Update

http://tools.ietf.org/html/draft-ietf-mmusic-decoding-dependency-01.txt

http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-08.txt
            (it was noted that the media loopback draft 09 was posted
            after the IETF#72 cut-off dates and exists in the ID
            repository as of August 5).

         - Other Drafts

http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-01.txt

http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework-02.txt
                and SDP proto parameters in
                http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-03

http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-01.t
xt

    The MMUSIC working group received a Liaison Statement (LS) from
    3GPP which asked for IETF input on "whether the .INVALID address
    may be used to indicate an unspecified IPv4 connection address".
    See chair slides for link and details.
    Based on mailing list discussions, Jean-Francois Mule presented a
    proposed response for working group review:
       Recommend that 3GPP continues to use 0.0.0.0 to signal an
       invalid connection address in SDP connection lines with IPv4
       addresses based on the following:
                 - while the SDP aBNF allows .invalid (RFC 4566), the
                   SDP offer/answer RFC has a normative requirement for
                   implementations to support 0.0.0.0 as a connection
                   address to indicate that neither RTP nor RTCP should
                   be sent to the peer.
                 - feedback received on the IETF MMUSIC mailing list
                   from several SIP implementers indicate that only
                   0.0.0.0 is supported by IPv4-only endpoints.
                 - Note that this feedback is from the SIP community,
                   not the H.248 one.
    A few comments were made at the mike by Roni Even, Gonzalo
    Camarillo and Tom Taylor:
       - Roni Even asked that the port should not be zero per RFC 3264.
       - Gonzalo stressed the fact that this LS was related to SDP use
         in H.248 and hence that we should indicate in the LS reply
         that most of the feedback we got was from the SIP community
         (already integrated in the proposal presented in the meeting);
       - Jean-Francois stated that while the question seems related to
         H.248 SDP use, MGCs tend to have SIP legs and re-use SDP
         across the H.248 and SIP exchanges
       - Tom Taylor added that H.248 SDP interop with SIP UA SDP is
         indeed important.
    There was consensus to respond that 0.0.0.0 is preferred over
    .invalid based on the comments but we should add more text to
    put this IETF feedback in the context of SDP use in SIP.
    Jean-Francois will circulate a draft LS reply to the working group
    shortly after IETF.  The LS reply will then be finalized and sent.

    There were additional LS received by MMUSIC on RTSP and on an
    "image size" SDP attribute; some were discussed during the MMUSIC
    Interim meeting held in May on RTSP and the LS content along with a
    proposed response is covered below with the related Internet-Drafts.

    Gonzalo Camarillo relayed some information about the HIP working
    group.  The HIP WG met in Dublin and had a live demo of two
    implementations using ICE.

--- SDP Image Attribute
http://tools.ietf.org/html/draft-johansson-mmusic-image-attributes-01

    Ingemar Johansson presented a proposal to add an SDP attribute for
    image size.  This document is related to a Liaison Statement the
    MMUSIC WG received from 3GPP.

    A set of comments on the problem statement (slide 3) followed:
       - H.264 allows custom-sized picture formats and
         regarding the rescaling, a receiver must be able to scale any
         size it gets from the encoder per H.264 as long as it is
         within the level (Roni Event)
       - the main issue is the negotiation problem, doing it with the
         payload types is difficult (Magnus Westerlund).  Magnus also
         asked if combining all of this information into one SDP
         parameter is the right choice.

    The objectives of the draft were discussed and commented.
       - Joerg Ott asked a question concerning the asymmetry
         (send-only, receive-only).  How much of that asymmetry should
         be negotiated vs. just declared (declare what can be
         supported)?  It is unclear whether we should have complete
         negotiation capabilities on every parameter.
       - Roni reiterated comments he sent to the list: for Roni, the
         objective should be to enable the receiver to request a
         specific size from the sender.  The receiver should not include
         all the sizes it can support.  The receiver can request a
         specific size.  The sender can reject it, or it can choose a
         size as close as possible to what the receiver asks in some
         cases.
         Roni recommended that the receiver should be capable of
         requesting a specific size with an indication of whether it is
         the exact size or if the receiver can approximate.
       - Magnus agreed that the main goal is probably to allow a
         receiver to express preferences about what it can receive
       - there were additional comments from Roni, Magnus and Stephan
         debating the scope and the requirements.

    Joerg noted that parts of the problem description seem to be
    related to the resolution of the screen on the receiver side,
    independent from the codec capabilities.

    Stephan Wenger added that we should be careful about making
    assumptions on what the user interface can or cannot do.  For e.g.,
    overscaling TV is a reality where you do not display the outside of
    the capture.
    Roni Even added that even if the application knows what display the
    phone can support, the user can change the display settings.  You
    may connect your camera onto a display information. The document
    should say that we should have the ability to request a specific
    resolution from the sender.

    Jonathan Lennox commented that the semantics should be close to
    this: "if you send me something that in the sender's opinion would
    look good in this size, it is good" rather than "send me exactly
    this".

    Additional speakers expressed comments in favor of having this as a
    work item.  The working group chairs concluded that there was
    interest in this work based on the discussions and consensus that
    having an SDP mechanism to signal some preferences could be
    beneficial.  We need however to get a better understanding of the
    requirements and what the scope of the problem is.

    Hannu Hietalahti closed the mike line by thanking the working group
    for the discussion and for providing a first level of guidance back
    to 3GPP.  There seems to be some interest in defining an SDP-based
    solution for this.
    Hannu asked where should this work be done.  Based on the MMUSIC
    discussions, Jean-Francois Mule as chair requested that 3GPP
    brings requirement to the MMUSIC working group, possibly in the
    form of an Internet-Draft.  Hannu agreed with the proposed approach.

    The MMUSIC chairs will respond to the 3GPP LS based on the
    mailing list and the meeting's discussions.

--- SDP Media Capability Negotiation

http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-05

    Roni Even presented the updates on the SDP Media Capability
    Negotiation draft.  Two revisions have been posted between the 2
    meetings.

    Based on comments from Ingemar Johansson, Christer Holmberg and
    Hadriel Kaplan requesting that the mechanism removes the c= line,
    Roni indicated that if folks don't want the c= line, it will be
    removed.  Christer was in favor of moving this into a separate
    document.

    Jonathan Lennox made a comment about one of the examples in the
    slides that seem to imply that video cannot be negotiated.
    Roni answered that this is just an example for this discussion, not
    an inherent limitation of the mechanism.

    Ingemar raised a comment on the size of the potential
    configuration.  Roni indicated that this is the type of input that
    is required to optimized the syntax.  The authors tried to find the
    proper shortcuts to express it.  Ingemar will send an email to the
    list.

    Al Morton may have comments and will talk to Roni, and send
    comments to the list.

    The chairs asked that folks interested in this framework are
    encouraged to review this document in-depth.

--- ICE TCP
    http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-07

    Dan Wing presented the status on ICE TCP on behalf of Jonathan
    Rosenberg.  There were no changes or  progress in the document
    since the last IETF.

    Based on the published research, the TCP-SO mechanism in the draft
    provides about 40% effective success.

    Cullen Jennings expressed a strong opinion not to rely on any port
    prediction mechanisms to improve the success rate.  Cullen pointed
    to the current work around on DNS attacks that is to make your port
    randomization be truly random otherwise DNS is really insecure.
    Port prediction is disappearing as a technique.
    Magnus added that there is a draft in the transport area for port
    generalization.

    Dan presented the options to move ICE-TCP forward ("Our choices"
slide):
         1. Discard the document as not effective enough
         2. Remove TCP-SO, issue ICE-tcp with act/pass only ? will work
            in cases with a public TURN server and often relay
         3. Keep TCP-SO
         4. Add additional TCP over UDP mechanisms of some sort to this
         document
    Dan also presented the author's recommendation: go with option 2.
    The working group consensus is between options 2 & 3 and more
    list discussions are required. Some suggested to go with option 2,
    and put the TCP-SO mechanism in a separate draft.

    There were a number of comments from Magnus Westerlund, Christer
    Holmberg, Ron Even, Adam Roach, Cullen Jennings, Hadriel Kaplan and
    a few others. The working group feedback is:
         + to keep ICE-TCP and progress the document.
           No votes for option#1.
           Christer and many others expressed opinions to keep it.
           Cullen Jennings expressed comments as an individual against
           option 1 to keep ICE-TCP because TURN relay can still be
           done and clients could be forced. Besides Cullen, there was
           enough support for the other options to conclude that
           discarding the document is not a way forward.
           The chairs polled the group on option 1: nobody raised hands
           in favor of option 1.

         + to not discuss any methods to transport TCP over UDP as part
           of this draft or any other in MMUSIC (several opinions
against
           option #4 as an MMUSIC discussion).
           No support for option 4 as part of this effort.
           Based on comments Cullen as an AD and Magnus Westerlund,
           this is work for the transport area.

         + go with option 2, and may be split TCP-SO in a separate doc.

    In addition to the above, Ted Hardie suggested to explore making
    ICE-TCP an experimental document with one or more techniques (there
    will be cases where there will be TURN servers with TCP out there
    and having a document is good).

    Cullen added that ICE-TCP and TCP-SO still represent 40% success
    rate and that is interestingly pretty close to what folks first got
    many years ago when testing ICE-UDP.  This could change over a
    5-year period.
    Cullen suggested that perhaps we should keep ICE-TCP with act/pass
    (option 2) and create a separate, may be experimental document on
    TCP-SO to collect data.

    The chairs summarized the consensus above and the best path forward
    is to clarify the new proposal on the list based on the working
    group feedback at this meeting and update the draft.  Jonathan
    Rosenberg was named to complete the document.

--- NICE
    http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01

    Dan Wing presented the updates in draft-01 on NICE.

    Dan asked if anyone was interested in working on this document as
    an editor.  Gonzalo Camarillo indicated interest for NICE in HIP
    and we could look for a volunteer there eventually.  Christer
    Holmberg is also interested in the work; it's been implemented in
    HIP.  Ted Hardie reminded that Bruce Lowekamp's email on the list
    did indicate he was willing to do work on this too.
    Several other folks expressed interest in having NICE (Sumanth
    Channabasappa, Markus Isomaki, Marc Petit Huguenin?, Jean-Francois
Mule,
    ...).
    Cullen Jennings summed it up: "we got a bunch of customers, we got
    people to work on it".

    Ted Hardie reiterated Bruce Lowekamp's comments sent on the list;
    p2psip documents need something like NICE and having this text
    available for p2psip and other protocols would be useful.

    The group will continue to progress this document in MMUSIC.

--- Use of SDP Usage for Circuit-Switched
--- Bearer Connections in PSTN
    http://tools.ietf.org/html/draft-garcia-mmusic-sdp-cs-01

    Simo Veikkolainen presented the updates on this draft.  See the
    draft and slides for details on the changes in draft-01 (removed
    codec negotiation intertwined with CS media, addition of a
    correlation mechanism using User-User Information element of the
    PSTN signaling).

    Based on comments from Christer Holmberg and Hadriel Kaplan, it was
    agreed that this draft should not change the c= line.  The
    resolution is to not deviate from the SDP media capability draft
    and its approach.
    Simo indicated that a new version of the draft could use the SDP
    media cap framework and use media lines instead of connection line
    for negotiation purposes.

    Ted Hardie expressed support for continuing to work on this draft
    for the 3GPP use cases.

    Jonathan Lennox added that this draft looks a lot like offering
    IPv4|IPv6 which was ANAT which has been deprecated by ICE.  He
    suggested to look at ICE or ICE-lite for the solution.  May be what
    you want is have an ICE PSTN-like candidate address.  Comments were
    made that it would not be a good idea by Ted and Cullen (what do
    connectivity checks mean in this context for example?).

    Based on the discussions and list comments, the chairs proposed to
    continue to progress this draft as an individual submission and
    decide later to adopt it as a working group item (this could be
    done on the mailing list before Minneapolis based on progress).

--- RTSP liaison statements

    Jean-Francois Mule presented the liaison statements received by
    MMUSIC on RTSP/2.0 (see chairs' slides for details).  These were
    discussed during the MMUSIC interim meeting.

    The chair slides provide details and proposed next steps.  Based on
    these notes and unless there are any further comments on the list,
    the MMUSIC chairs will draft LS responses where needed by Sept 15.
    - 3GPP LS:
      We need a volunteer to review latest 3GPP spec and Magnus's IETF
      I-D.  The publication request of
      draft-westerlund-mmusic-3gpp-sdp-rtsp-06.txt is imminent.
      The proposed response to 3GPP LS is:
         - Need I-D to explain and potentially register RTSP/FLUTE work
         - Ask 3GPP to bring requirements for time shifting extensions
           to IETF MMUSIC
    - CableLabs LS:
      The proposal is to not respond and await for an update to the ID
      draft-bergren-mmusic-rtsp-ermi-extensions which should have
      updates on the RTSP usage for the ERMI effort at CableLabs based
      on the interim meeting feedback.  A new draft should also
      proposed some IANA registrations, consistent with Colin Perkins's
      request some time ago and the MMUSIC LS to CableLabs.

    - ETSI TISPAN
      Based on the mike's comments, it is proposed to respond to ETSI
      TISPAN the following:
         - ask for why SETUP/PLAY could not be sent in the same message
           (even if SIP  dialogs support media session establishment)
         - indicate that an Internet-Draft has been presented in the
           past
           (http://tools.ietf.org/html/draft-marjou-mmusic-sdp-rtsp-01)
           and that based on the MMUSIC interim meeting in May 2008, an
           update is expected.  At this time, while there is no
           consensus that this work should progress, discussions are
           ongoing.

     - ITU-T SG9
       Draft a response to ITU-T SG9 after RTSP rfc2326bis has been
       updated to include main reasons why RTSP 2.0 is incompatible
       with RTSP 1.0. This should be inserted in the RTSP/2.0 draft
       first per interim and referenced in the MMUSIC response.

     - ITU-T SG16
       No responses required, see slides for details.

     - Open IPTV-Forum
       This group intends to use PLAY without SETUP, which is very
       similar to TISPAN.
       Based on comments from Magnus and others, it is clear that
       several organizations are looking at decomposition models for
       RTSP, splitting roles and functions between SIP and RTSP.
       Based on the mike comments, it is unclear what could be done and
       if RTSP should be reworked to allow this. How difficult is it to
       have one extra RTT or use pipeline commands?  Magnus suggested
       we put this in the response.
       More input is required on the architecture models for separating
       the session controller from the media playback.

--- RTSP and RTSP NAT
    http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rfc2326bis-18

http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rtsp-nat-evaluation-01
    http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rtsp-nat-07

    Magnus Westerlund provided a status on the RTSP documents.  For
    RTSP, there were no updates since the interim meeting where some
    progress was made on things like open issues, scale/speed, etc.
    Magnus indicated an I-D update should be released in September.

    Magnus presented the updates on RTSP NAT.

    There was little feedback on the list and during the meeting on the
    proposed changes in the draft, in particular, the RTSP
    server-initiated changes to use PLAY_NOTIFY with ice-restart as the
    reason.  See slides for details.
    Magnus also discussed some alternatives to the PLAY_NOTIFY approach
    which is to have the RTSP server act as the ICE controller.  One
    comment was raised by Dan Wing on this alternative: the stated con
    is applicable when there is no NATs and no ICE (RTSP PLAY response
    may arrive after media is received).

    More reviews and feedback are needed on this work to progress,
    please send you comments to the list.

    A discussion followed on how we could encourage participants from
    other SDOs to come to IETF meetings to provide feedback.  While
    their participation was great at the interim meeting with folks
    attending from 3GPP, DVB and ETSI, Cullen correctly pointed out
    that there is still a shortage of participating during IETF
    meetings or on the list.

--- SDP Media Loopback
    http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-08

   Kaynam Hedayat covered the changes in the to-be-posted draft -09.
   Kaynam Hedayat will post a request to the AVT list for the AVT WG
   participants to provide feedback on the documents' RTP payload
   types.
   MMUSIC chairs indicated the WGLC on this draft will be sent shortly
   after IETF#72.

--- Multiple Packetization Times in SDP

http://tools.ietf.org/html/draft-garcia-mmusic-multiple-ptimes-problem-0
3

   Joerg presented the slides on behalf of the authors and asked some
   feedback for the authors.
   Jeff Hunt commented that it is does not allow to arrange 2
   packetization times for codec A and 2 packetization times for codec
   B.  It would seem better to recommend an mptime parameter.  This
   proposed solution seems to introduce complexity without solving the
   problem.

   Christer Holmberg commented that the original intention of the ID
   was to allow multiple codec-specific ptime.  This does not seem a
   solution to the original requirements.

   Chairs asked folks to send comments to the list.

The meeting was adjourned.

> end.

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