Minutes of the Meeting: MMUSIC working group at IETF 85

The MMUSIC working group of the IETF met at IETF #85 in Atlanta, USA.

The WG met on November 6, 2012 from 9:00 to 11.30.


The meeting was chaired by Flemming Andreasen and Paul Kyzivat (as stand-in for Miguel Garcia).

Peter Saint-Andre, Bert Greevenbosch and the chairs took notes. Cullen Jennings acted as Jabber scribe.


The meeting was broadcast live and recorded by the Meetecho team. The recording of the session is available at the following URL:


            http://ietf85.conf.meetecho.com/index.php/Recorded_Sessions - IETF85_MMUSIC_PART_II


Introduction and Status Update (Chairs)

The chairs presented the agenda:




No agenda bashing was needed however it was noted that "the trafficlass attribute" would not be presented at the meeting.


The chairs presented the status of the working group as noted in the slides and below:


Published RFCs since last IETF



With RFC Editor



In IETF Last Call

      draft-ietf-mmusic-sdp-media-capabilities-15 (SDP Media Capabilities)


In IESG evaluation

      draft-ietf-mmusic-media-loopback-23 (Media Loopback)
Gonzalo Camarillo (RAI AD) noted that the draft would be discussed with the Transport AD during the week to resolve one remaining IESG question. Brian Rosen noted (again) that the ECRIT WG is dependent on this draft and has been waiting for a long time for it to complete.


Publication Requested



SDP Directorate and Designated Expert reviews

      draft-ietf-avtcore-idms-07 (Inter-destination Media Synchronization using RTCP)
[updates needed]

      draft-ietf-xrblock-rtcp-xr-delay-09 (RTCP XR Block for Delay metric Reporting)


WGLC completed, pending of write-up

      draft-ietf-mmusic-sdp-cs-13 (CS descriptions in SDP)
[updates needed]

      draft-ietf-mmusic-sdp-miscellaneous-caps-02 (Miscellaneous Capabilities Negotiation in SDP)
[updates needed]

      draft-ietf-mmusic-rfc2326-bis-30 (RTSP 2.0)
[chair review in progress]


WGLC completed, pending of a new version

      draft-ietf-mmusic-rtsp-nat-evaluation-05 (RTSP NAT Traversal Evaluation)


Getting ready for WGLC

      draft-ietf-rtsp-nat-13 (RTSP NAT Traversal)
The chairs noted that RTSP/ICE knowledgeable reviewers are needed. Ari Keranen kindly volunteered to review the draft.


New work items

      draft-ietf-mmusic-delayed-duplication-00 (Delayed Duplication Attribute in SDP)

      draft-ietf-mmusic-duplication-grouping-00 (Duplication Grouping Semantics in SDP)

      draft-ietf-mmusic-sdp-g273-g729-00 (Offer/Answer Considerations for G.723 Annex A & G.729 Annex B)
[Note: draft filename to be fixed to g723]

      draft-ietf-mmusic-latching-00 (Latching: Hosted NAT Traversal for media in Real-Time Communication)

      draft-alvestrand-mmusic-msid-01 (Cross Session Stream Identification in SDP)
[discussed later, to be submitted as WG draft]

      ICE Revision [discussed later]


Other WG drafts not on the agenda

      draft-ietf-mmusic-rfc4566bis-06 (SDP/RFC4566bis)
[still taking updates, not urgent]

      draft-ietf-mmusic-sctp-sdp-02 (SCTP Media in SDP)
[RTCWEB and CLUE discussions]
Chairs are unclear on status and plan for the draft. Gonzalo Camarillo (co-author) will ask Salvatore Loreto (co-author) to send an e-mail to the MMUSIC mailing list to clarify what is needed. It was noted that the RTCWEB WG needs this draft.

      draft-ietf-mmusic-media-path-middleboxes-05 (Media Path Middleboxes)
[authors to clarify scope and goals in draft to enable forward progress and possibly new comments on the draft (per previous mailing list and meeting comments from Hadriel Kaplan in particular)]


Multiplexing drafts (Christer Holmberg)

      draft-ietf-mmusic-sdp-bundle-negotiation-01.txt (Multiplexing Negotiation Using SDP Port Numbers)

      draft-holmberg-mmusic-sdp-mmt-negotiation-00.txt (Multiplexed Media Types (MMT) Using SDP Port Numbers)


It was noted that the RTCWEB WG has an urgent need for a multiplexing solution and there are currently different proposals for a solution.


Christer presented his slides which led to a prolonged discussion on how to move forward:


We currently have three solutions under consideration

      Two are similar: BUNDLE grouping with either same or different port numbers in the "bundled" media descriptions (m=)

      Third alternative is MMT (new media type with its own media description)


Question on whether only RTP channels/streams must be multiplexed (consider other types of streams as well, e.g. apps which do not have SSRCs).


Issues with BUNDLE, same port numbers (see slides for further details):

      Offer with same ports may be rejected, but SDP specification is silent on proper behaviour.

      How to combine parameters such as bandwidth and SDP attributes when multiplexing the RTP streams ?


Cullen Jennings:

      Tested use of offer with same port number on 17 devices. Over half of them rejected the offer and error reporting was weak, so do not think it is a workable solution


Issues with BUNDLE, different port numbers (aka. "Cullen BUNDLE" - see slides for further details):):

      Non-supporting middleboxes may be confused

      Some non-supporting implementations may maintain the grouping attribute in the SDP answer.

      Issue with setting of the first m-line to zero (?).

      ICE candidates for multiple ports

      How to combine parameters such as bandwidth and SDP attributes when multiplexing the RTP streams ?


James Polk

      Not just an SBC issue; needs to be fixed in multiple "products".


Hadriel Kaplan

      Middleboxes may close down the connection altogether, when the expected RTP streams don't match those in the offer.

      Also, can't set topmost m-line to zero. Asks for clarfication on the setting of zero of the first advertised stream.


Cullen Jennings

      We cannot consider non-standard compliant middleboxes, since it is hard enough to find a solution that works for compliant implementations. Tests showed that legacy middleboxes that worked set up two sessions, and the BUNDLE grouping was lost in the process.


Christer Holmberg

      It is not clear if a middlebox will forward unknown attributes or not.


Cullen Jennings

      The middleboxes that didn't block the stream removed the attribute.


Richard Ejzak

      Need another offer if BUNDLE is accepted.

      Agreed about not supporting non-complient intermediaries.


Roni Even

      Agrees with Cullen about middleboxes.

      Question what is the issue with ICE for multiple ports, as he considers BUNDLE was required especially for ICE with single port.


Bernard Adoba

      Presumably that would prevent use of trickle-ICE (?)



      Bandwidth not problem of "Cullen bundle" proposal, but of all proposals.


Jonathan Lennox

      This is not just a "bandwidth" issue



Issues with MMT (see slides for further details):

      Rejection of unknown media type => whole offer is rejected

      Large SDP offer; in answer attributes to disabled m-lines do not need to be included.

      ICE Candidates for multiple ports

      RTP Only (?)


Emil Ivov

      Currently we do not have a way of doing trickle-ICE with multiple ports


Harald Alvestrand

      This solution makes fundamental architectural change. The m-line used to be description of RTP session, and description of media in that RTP session.

      BUNDLE solutions change this architecture (RTP session information is now aggregated from multiple m-lines), but MMT leaves it intact.


Richard Ejzak

      Agree regarding the "bandwidth" issue raised earlier.

      May need to specify groups of payload types that go together, e.g. only combining certain types of codecs (e.g. DTMF only for certain payload types). There is no way to specify that with the MMT proposal; seems easier to keep existing approaches.



Discussion on how to move forward

Flemming (as chair)

      We have seen the proposals now and have some knowledge of pros and cons of the different proposals at this point. Would like to sense the room for where to go from here.


Colin Perkins

      Several of Richard's comments are inherent to combining multiple streams in a single RTP session.

      MMT seems the only one that uses existing SDP semantics. It requires extensions but doesn't change the existing framework.


Cullen Jennings

      Originally BUNDLE was a small thing to describe a bit about the transport info, whereas I think MMT is a fork of SDP and a big change for people who have existing implementations (also the failure rate for existing implementations is quite high and the error handling is erratic as evidenced by testing)


Magnus Westerlund

      We don't need to redefine things when using BUNDLE.


Charles Eckel

      When I think of applications I have worked with, BUNDLE seems more natural whereas MMT feels more complex - examples where MMT would work better might help.


Jonathan Lennox

      MMT seems like it would give us something to build on further, not a backfill just for this one particular problem

      would m=application/anymedia help here?



      Glad to run experiments



      Data channel multiplexing is not considered, but should be.



      We'll find a way, irrelevant of the chosen solution.


Andrew Hutton

      I do share some concerns about forking SDP, we also need to look more at multi-source / multiplexing


Richard Ejzak

      More work needed for MMT than would be needed to fix BUNDLE. Is there something we can do with MMT that we can't with BUNDLE ?


Justin Uberti

      Was a big fan of BUNDLE, but not backward-compatible-safe - if we're not okay with that, then we need to go down the MMT path - multi-source / per-SSRC attributes will require more work


Randall Jessup

      Can't just rely on the SSRC, so would need to recontruct the entire m-line structure within each m-line, so I think BUNDLE works better within the existing framework, leery of MMT parsing and definition – the only reasonable way to implement MMT is to encapsulate SDP within SDP



      Yes, but with MMT we need to do the work once, whereas with BUNDLE we need to fix everything from the past, as consider BUNDLE for everything in the future.


Harald Alvestrand

      Does m-line define media sources or RTP session? e're at a fork in the road


Hadriel Kaplan

      With BUNDLE we might have problems with legacy equipment, with MMT we *know* we will have problems - we're not actually going to save ourselves work in the future if we do MMT - so I really don't see the purpose or benefit of MMT - original BUNDLE will work with noncompliant intermediaries without actual bunding, whereas the newer BUNDLE fails but slowly


Eric Rescorla:

      I'd prefer a mechanism that fails quickly or in ways I understand

      Wants the chairs to ask the group with which proposal to go forward.


Roni Even

      Assumes both BUNDLE and MMT would work.

      Need to see that it also work for scenarios like CLUE with multi-stream


Christer Holmberg

      You can group multiple bundles



Chairs would like to at least go from three to two proposals at this point and hence asking for a hum between BUNDLE (whether same or different port) and MMT:

      Hum does not yield rough consensus


Roni Even

      Maybe we do not have enough information.


Chairs asking for show of hands between BUNDLE, MMT, and "need more information":

      BUNDLE type approach: 22 people

      MMT type approach: 10 people

      Need more information: 12 people


Chairs concluding that we can not make a decision at this point and encourages the BUNDLE and MMT proponents to have further discussion to try and find common ground and understanding. A better (more detailed) understanding of the impact of each proposal on existing SDP parameters and attributes would be a good place to start.



      People that do not have enough information, please send e-mails to the list.


Message Stream ID (MSID) (Harald Alvestrand)

      draft-alvestrand-mmusic-msid-01 (Cross Session Stream Identification in the Session Description Protocol)


Harald presented his slides. The draft is needed for RTCWEB but is in the scope of the MMUSIC WG.


Eric Rescorla

      I think suitably chosen random number is fine here.


Magnus Westerland:

      SRCNAME draft and this draft are complementary; important to make clear how this overlaps with srcname


Harald Alvestrand

      Looks that SRCNAME is human readable


Magnus Westerlund

      That is just in the example


Roni Even:

      Discussed similar problem in CLUE and using a separate identifier; srcname seems to provide a good mechanism


Paul Kyzivat (as individual):

      Why pick specific syntax for token format ?

      We should pick a registry for clear semantics


Kevin Gross

      19-bit random number seems to work.

      Architectural comment: It looks like this identifier is used to identify a group, not individual streams. Maybe we rather need IDs for individual streams ? Maybe change to be more consistent with the existing grouping mechanism ?


Cullen Jennings:

      Do we need something new given that we have SSRC ?


Harald Alvestrand:

      Nice thing about an id is you can assign it before you have a session


Jonathan Lennox:

      Unclear if we should use msid or other grouping semantics


Magnus Westerland:

      If you have two media streams with different SSRCs, would you have same or different msid ?


Chairs concluding that we will continue the discussion on the mailing list.

New revision of ICE (RFC 5245) (Ari Keranen)

       [no  draft at this time]


Ari presented his slides based on the poll result last time to create a revision of ICE (obsoleting rfc 5245).


Proposed udates/extensions:

      Media level ice-options sdp attribute

      Update on candidate address selection for ice

      ICE updated offer problematic

      Smaller minimum TA (currently 500ms) for non-rtp traffic.

      Mobility with ice

      Happy eyeballs extension for ice


Open issues:

      What goes to the main spec and what to extension documents?

      Split sdp from the main spec?

      Backward compatibility


Next steps

      draft-ice-bis-00 coming after the meeting

      Gather all updates and extensions

      Ensure that ice-bis fixes all known bugs and enable extensions.

      Something else missing?


Cullen Jennings:

      Why was RTP different from non-RTP for the minimum Ta? I think implementations ignore it, so fixing this seems like a good idea


Gonzalo Camarillo (as AD):

      Please keep the Transport ADs in the loop on this.


Emil Ivov:

      Probably need to discuss updated offer / REINVITE in more detail


Eric Rescorla:

      Option to signal bis-conformance from caller means it can't behave differently until it hears from the callee; would prefer something that doesn't introduce that latency


Cullen Jennings:

      We should try to define our extensions such that it just works. Keep backwards compatibility in mind: new and old ICE should work together.


Jonathan Lennox:

      Other bugs have been raised, will send to the list


Peter Saint-Andre:

      Has much thought been given to the model for extensibility ? Might want to have some guidelines about what kinds of extensions make sense and are consistent with the overall ICE architecture / approach


Trickle ICE (Emil Ivov)

      draft-rescorla-mmusic-ice-tricke-01 (Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol)


Emil presented his slides on trickle ICE which is aimed at making call setup with ICE faster.


Cullen Jennings:

      Not sure I agree with the numbers (not in accordance with pratice), but it's not that I think we shouldn't do Trickle ICE, so let's take it to the list


Flemming Andreasen (as individual):

      As part of this effort, need to make sure it works with SIP in parallel with this work - can't just leave it as an exercise for the reader


Cullen Jennings:

      Regarding backward compatibility: this makes sense, but we can't assume out-of-band mechanism for discovery so need to define something that works in that case


Emil Ivov:

      Thus half-trickle


Christer Holmberg:

      I think an ICE-lite callee can handle a trickle offer


Bernard Aboba:

      RFC 3264 uses


Cullen Jennings:

      Yes, that should work


Eric Rescorla:

      Regarding SDP, I don't think we need a=candidate: - relax this requirement


Jonathan Lennox:

      Not clear why you would need/want to send ufrag/pwd with no candidates

      On half trickle, I think you get better than half the improvement


ICE mobility (Dan Wing)

       draft-wing-mmusic-ice-mobility-02 (Mobility with ICE (MICE))


Dan presented his slides on MICE which supports endpoint IP mobility by use of ICE. Dan reviewed several scenarios, in categories "BREAK before MAKE" and "MAKE before BREAK". The latter is considered easier to solve.


Emil Ivov

      If the callee does the check, won't it fail most of the time ?


Jonathan Lennox

      In mobility case, won't you need to use a TURN server ?


Dan Wing

      Keep the candidates open


Justin Uberti

      In trickle, we don't have to wait for answer with ice-options, don't see advantage of negotiating in media plane ?


ICE happy eyeballs (Dan Wing)

       draft-reddy-mmusic-ice-happy-eyeballs-00 (Happy Eyeballs Extension for ICE)


Due to lack of time, Dan did not get a chance to present his slides. Dan gave a short introduction to the draft, which aims at improving call setup times for IPv4/IPv6 dual-stack entities by making ICE connectivity checks more aggressive when there is a path failure for the preferred address family (e.g. IPv6).


Dan asked for people to comment on the draft.  

Multiple Synchronization Sources (SSRC) (Christer Holmberg)

      draft-westerlund-mmusic-max-ssrc-00 (Multiple Synchronization Sources (SSRC) in SDP Media Descriptions


Christer presented his slides on the draft, which defines a way to signal certain constraints around the simultaneous use of sending and receiving capabilities of multiple media sources (SSRCs) based on their codec usage or combinations of codec usage. A previous version of the draft was originally provided to the AVTCORE WG.


Christer noted that an IPR disclosure has been filed for the draft:




Flemming Andreasen (as individual):

      I think this is a subset of a larger problem, why focusing on only this part ?

      Since there is an IPR declaration that appears to involve royalties, we should clearly separate the problem and the solution to see if we can find a solution that is IPR-free (or at least royalty-free) in case we do want to solve the problem described.


Justin Uberti:

      Not sure why need to note the sender SSRCs, I think we could do this in a more general way