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
The chairs presented the agenda:
http://www.ietf.org/proceedings/85/agenda/agenda-85-mmusic.htm
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:
á
None
á None
á draft-ietf-mmusic-sdp-media-capabilities-15 (SDP Media Capabilities)
á
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.
á None
á
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)
á
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]
á draft-ietf-mmusic-rtsp-nat-evaluation-05 (RTSP NAT Traversal Evaluation)
á
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.
á
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]
á
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)]
á
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
(?)
Cullen
á
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?
Cullen
á
Glad to run experiments
[unidentified]:
á
Data channel multiplexing is not considered, but
should be.
Christer
á
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
Christer
á
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.
Christer:
á
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.
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.
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
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 0.0.0.0
Cullen Jennings:
á
Yes, that should work
Eric Rescorla:
á
Regarding SDP, I don't think we need
a=candidate:0.0.0.0 - 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
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 ?
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.
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:
á https://datatracker.ietf.org/ipr/1639/
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