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:
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:
á (SDP Media Capabilities)
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.
(Inter-destination Media Synchronization using RTCP)
á (RTCP XR Block for Delay metric Reporting)
(CS descriptions in SDP)
(Miscellaneous Capabilities Negotiation in SDP)
[chair review in progress]
á (RTSP NAT Traversal Evaluation)
(RTSP NAT Traversal)
The chairs noted that RTSP/ICE knowledgeable reviewers are needed. Ari Keranen kindly volunteered to review the draft.
á (Delayed Duplication Attribute in SDP)
á (Duplication Grouping Semantics in SDP)
(Offer/Answer Considerations for G.723 Annex A & G.729 Annex B)
[Note: draft filename to be fixed to g723]
á (Latching: Hosted NAT Traversal for media in Real-Time Communication)
(Cross Session Stream Identification in SDP)
[discussed later, to be submitted as WG draft]
á ICE Revision [discussed later]
[still taking updates, not urgent]
(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.
(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 Negotiation Using SDP Port Numbers)
á (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 hiswhich 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 ?
á 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 ?
á Not just an SBC issue; needs to be fixed in multiple "products".
á 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.
á 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.
á It is not clear if a middlebox will forward unknown attributes or not.
á The middleboxes that didn't block the stream removed the attribute.
á Need another offer if BUNDLE is accepted.
á Agreed about not supporting non-complient intermediaries.
á 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.
á Presumably that would prevent use of trickle-ICE (?)
á Bandwidth not problem of "Cullen bundle" proposal, but of all proposals.
á 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 (?)
á Currently we do not have a way of doing trickle-ICE with multiple ports
á 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.
á 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.
á 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.
á 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)
á We don't need to redefine things when using BUNDLE.
á 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.
á 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.
á I do share some concerns about forking SDP, we also need to look more at multi-source / multiplexing
á 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 ?
á 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
á 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.
á Does m-line define media sources or RTP session? e're at a fork in the road
á 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
á 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.
á Assumes both BUNDLE and MMT would work.
á Need to see that it also work for scenarios like CLUE with multi-stream
á 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
á 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.
á 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.
á I think suitably chosen random number is fine here.
á SRCNAME draft and this draft are complementary; important to make clear how this overlaps with srcname
á Looks that SRCNAME is human readable
á That is just in the example
á 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
á 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 ?
á Do we need something new given that we have SSRC ?
á Nice thing about an id is you can assign it before you have a session
á Unclear if we should use msid or other grouping semantics
á 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.
á[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).
á 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
á What goes to the main spec and what to extension documents?
á Split sdp from the main spec?
á Backward compatibility
á 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?
á 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.
á Probably need to discuss updated offer / REINVITE in more detail
á 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
á We should try to define our extensions such that it just works. Keep backwards compatibility in mind: new and old ICE should work together.
á Other bugs have been raised, will send to the list
á 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
á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.
á 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
á 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
á Thus half-trickle
á I think an ICE-lite callee can handle a trickle offer
á RFC 3264 uses 0.0.0.0
á Yes, that should work
á Regarding SDP, I don't think we need a=candidate:0.0.0.0 - relax this requirement
á 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
á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.
á If the callee does the check, won't it fail most of the time ?
á In mobility case, won't you need to use a TURN server ?
á Keep the candidates open
á In trickle, we don't have to wait for answer with ice-options, don't see advantage of negotiating in media plane ?
á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.
á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.
á Not sure why need to note the sender SSRCs, I think we could do this in a more general way