* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Mmusic Status Pages

Multiparty Multimedia Session Control (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 1993-Jun-24 —  

IETF-103 mmusic minutes

Session 2018-11-08 1350-1550: Boromphimarn 4 - Audio stream - mmusic chatroom


minutes-103-mmusic-00 minutes

          Minutes of Meeting: MMUSIC Working Group at IETF 103
          The MMUSIC working group met at IETF #103 in Bangkok on Thursday November
          8, 2018 from 13:50 to 14:25.
          The meeting was chaired by Flemming Andreasen and Bo Burman.
          Christer Holmberg and the chairs took notes, and Jonathan Lennox acted
          as Jabber relay.
          The meeting was broadcast live and recorded by the Meetecho team,
          available at:
          Final agenda:
          13:50-14:05 Introduction and Status Update (15 mins, Chairs)
          14:05-14:20 Charter Update to Combine with ICE (15 mins, Chairs)
          14:20-14:50 DCSA Attribute Registration (30 mins, Roni Even)
          There were no comments on the agenda.
          Introduction and Status Update (Chairs)
          The chairs presented their slides with the agenda and an update about
          activities since the last meeting.
          Flemming: The authors of draft-ietf-mmusic-sdp-uks plans an update during
          next week.
          Christer: draft-ietf-mmusic-sdp-mux-attributes will need some small
          updates based on updates in draft-ietf-bfcpbis-rfc4583bis; there are
          some attributes in -mux-attributes with a MUX category of TBD that has
          a different category in -rfc4583bis.
          Ben Campbell (ART AD): Make sure that the WG is aware of this change,
          unless there are material changes, which does not seem to be the case.
          Charter Update to Combine with ICE (Chairs)
          Ari Keranen (ICE co-chair): We're done with ICE documents. There are no
          new documents at this point so ICE WG is declaring success.
          The proposed charter change is that MMUSIC maintains ICE
          specifications. ICE was originally defined in MMUSIC, then further
          developed in the ICE WG.
          Ben (relaying a comment from Eric Rescorla): Do we really need to add that
          to the charter vs. handling it like any other extension with existing
          charter text? Do we have the right expertise in MMUSIC to deal with ICE
          core changes for example?
          Roni Even: If not chartered, would new ICE work go through DISPATCH WG?
          Ben: That depends on the change.
          Jonathan Lennox: A few years back there were various ICE
          changes/extensions proposed. Not sure what current status is.
          Bernard Aboba: There are proprietary extensions to ICE that have shipped
          in rather large scales.
          Ben: Is it likely those will be brought back to the IETF?
          Bernard: Could be. Individual drafts have been written, but don't know
          about plans to bring them to IETF. There are some corner cases in the
          drafts they are based on - would help with some chartered work to document
          the extensions.
          Ben: If we were to take that work back up - would it be considered
          maintenance or reworked?
          Bernard: Some of these things are not maintenance but fairly core to
          ICE and would need significant analysis.
          Ben: Could potentially be an ICE bis-bis?
          Bernard: There are probably not energy for a bis-bis at this point, but
          there are a number of things that would lead to important performance
          Christer Holmberg: I have read a few of those drafts and they are
          definitely not maintenance - they are new functionality (e.g. continuous
          Chair: ICE extensions may have to go via DISPATCH WG anyway, no matter
          what WG handles ICE. Is it then worth to close ICE WG, if extensions
          would be provided?
          Ari: The ICE WG is a very small group of people, the same group of people
          in MMUSIC and ICE related to this work. there is not a lot of work in
          either group - think it makes sense to have it done in MMUSIC.
          Jonathan: In favor of doing it in MMUSIC, unless it seems the amount of
          work justifies another WG.
          Ben: It seems like people in general is in favor of keeping it in. I
          think what I hear is that MMUSIC could do small tasks, but they should not
          take on major new work without re-charter, and/or via DISPATCH WG, etc.
          Bernard: Lots of it is about performance optimization, which may not be
          the scope for MMUSIC and don't know if MMUSIC has the right expertise
          and desire to engage in it.
          Ben: How many people were active in ICE that don't also come to MMUSIC?
          Ari: Haven't followed MMUSIC closely lately. We can always pull people
          from different communities, if needed. For transport related extensions,
          we will anyway need transport expertise.
          Ben: Have the chairs agreed on the proposal?
          Chairs: Yes.
          Bernard: In case people want to make a speed optimization, an example
          activity would be a hackathon where people can prove the performance
          enhancements are actually real - needs to be some empirical evidence.
          Ben: Add a sentence to the charter proposal that any new ICE extension
          need demonstrated interest and value.
          Jonathan: Leave out the ICE history part in the charter update.
          Chairs: Noted.
          DCSA Attribute Registration (Roni)
          The latest version should address most of the comments given, mainly by
          There was an open question from Roni on what to do with the SDP dcsa
          attribute defined in draft-ietf-mmusic-data-channel-sdpneg: The current
          IANA considerations introduces a new dcsa usage level in the IANA SDP
          att-field registry. The proposal is to define a new registry "att-field
          (dcsa level)". There is no option to add a usage level to the current
          "att-field" registries.
          Martin Thomson: Do we use this attribute to signal datachannel priority
          in RTCWEB?
          Jonathan: No. RTCWEB doesn't use this for priority.
          Flemming (as individual): draft-ietf-mmusic-rfc4566bis is already covering
          the IANA registry rewrite.
          Ben: Is this part of the RTCWEB dependency cluster (C238)?
          Roni: No. There are only CLUE dependencies to this draft.
          Ben: Assuming the registries are created in -rfc4566bis, the way forward
          for this issue is for -sdpneg to reference -rfc4566bis, which probably
          needs to reference -sdpneg as well - so we have a new mini-cluster.

Generated from PyHt script /wg/mmusic/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -