Minutes of the Meeting: MMUSIC Working Group at IETF 91
The MMUSIC working group met at IETF #91 in Honolulu, Hawaii on Thursday November 13, 2014 from 9:00 to 11:30 and on Friday November 14, 2014 from 9:00 to 11:30.
The meeting was chaired by Flemming Andreasen and Ari Kernen.
Simon Perrault and the chairs took notes on Thursday, and
Jonathan Lennox acted as Jabber relay.
Roni Even and Charles Eckel and the chairs took notes on Friday, and Jonathan
Lennox acted as Jabber relay.
The meetings were broadcast live and recorded by the Meetecho team. The recordings of the sessions are available at the following URLs:
● ThursdayÕs recording: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_MMUSIC&chapter=chapter_0
● FridayÕs recording: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_MMUSIC_II&chapter=chapter_0
Below is the final agenda with links to the relevant sub-sections below:
Thursday, November 13, 2014
09:00-09:15 Introduction and Status Update (15 mins)
09:15-09:35 A Framework for SDP Attributes when Multiplexing (20 mins)
09:35-09:45 IANA Registration of SDP ÔprotoÕ attribute for transporting RTP Media over TCP under various RTP Profiles (10 mins)
09:45-10:15 Negotiating Media Multiplexing Using SDP (30 mins)
10:15-11:00 SCTP-Based Media Transport in SDP (45 mins)
11:00-11:30 SDP bis and IANA Registry Updates for SDP bis (30 mins)
Friday, November 14, 2014
09:00-09:40 ICE bis (40 mins)
09:40-09:55 ICE IPv4/IPv6 Dual Stack Fairness (15 mins)
09:55-10:40 Using Simulcast in SDP and RTP Sessions (45 mins)
10:40-11:05 MSRP over SCTP/DTLS & SDP-based "SCTP over DTLSÓ negotiation (25 mins)
11:05-11:30 RTP Payload Format for Forward Error Correction Packets (25 mins)
The chairs presented their slides.
There were no comments from the room on the agenda.
During the status update, the chairÕs asked Harald Alvestrand to provide a short update on the status of the msid draft (draft-ietf-mmusic-msid-07):
● Harald has received reviews from Adam Roach and Ted Hardie and he will address those comments (Harald believes they are editorial).
● Overall, Harald believes the technology is good enough for its purpose at this point.
● No second use case outside of RTCWeb has been identified so far and hence itÕs not clear the extensibility mechanisms are really needed, but Harald suggests we leave them in there.
● There has also been some changes in WebRTC where a single media-stream track now belongs to a m=line. This change results in a bit of redundant data with the current mechanism, but no change is needed.
● Once the editorial changes have been made, Harald suggests we go to WGLC.
● Ari (co-chair) asked for additional comments from the room. No comments received.
● Conclusion: Once updated draft addressing the review comments has been submitted, we will proceed towards WGLC.
draft-ietf-mmusic-sdp-mux-attributes-04
Suhas presented his slides
The categories for the new SDP attributes were accepted as proposed in the slides.
Suhas believes the draft is ready for WGLC at this point.
Christer Holmberg:
● Don't have any comments, but there are a few drafts we want to discuss this week and they may impact Bundle. If we chose to adopt them then the attributes need to be added to this draft.
Cullen Jennings:
● Draft will never be done if keep adding new drafts to it.
● Would rather we have those new drafts put the categories in them.
Christer Holmberg:
● OK - agree with Cullen.
Mary Barnes:
● Agrees with Cullen
Flemming Andreasen (as individual):
● This needs to be finished at some time. This time is as good as any other. 4566bis would need to add a section that new attributes need to have a section that defines the mux categories.
Harald Alvestrand:
● Seems we are ready for WGLC
Charles Eckel:
● Agrees with CullenÕs suggestion
Flemming (Chair):
Conclusions
1. Seems we are ready for WGLC (asking room); nobody in room disagrees.
2. 4566bis will add procedures that you have to specify mux behavior
3. Drafts not covered by mux-drafts will now have to to start specifying their mux behavior (will be a requirement in the WG).
draft-nandakumar-mmusic-proto-iana-registration-00
Suhas presented his slides
A discussion ensued around how to indicate DTLS over different protocols
Jonathan Lennox:
● Do we have a way to say "DTLS-SRTP over TCP"?
Justin Uberti:
● I agree this is ambiguous. DonÕt want lower layers to buffer data. Thought that TLS in an RTP context always meant DTLS.
Cullen Jennings:
● There is no framing protocol to put DTLS over TCP defined anywhere. We have RTP over TCP. That framing protocol can be used for RTP over TLS. That cannot be used for RTP over DTLS over TCP.
Christer Holmberg:
● I also want something for SCTP over DTLS over TCP
[Note: Quick arguing at the mic.]
Jonathan Lennox:
● The issue is about DTLS-SRTP over TCP.
Ari Kernen:
● We need more clarity what is meant with the last 4 profiles in the slides
Harald Alvestrand:
● This shows that the protocol field is a broken concept.
Jonathan:
● We need a general way to take what you're doing over datagram and frame it and do the same thing over TCP.
Paul Kyzivat:
● We already have the token DTLS together with SCTP. We should re-use that.
Justin Uberti:
● We already have an RFC specifying that (forgot).
● RFC 4571 handles framing.
● Need to agree on whether TLS can ever mean DTLS. They are changing JSEP to now imply that "UDP/TLS" actually means DTLS (the DTLS token was deprecated in jsep-08)
Ari (as chair):
Conclusion:
● Need to start a thread on the mailing list. Give references. Then have this document point to the right documents.
draft-ietf-mmusic-sdp-bundle-negotiation-12
Christer presented his slides covering the following open issues:
1. Symmetric RTP
2. Bundle-only default candidates
3. Move sources
Symmetric RTP
ChristerÕs proposal is to mandate symmetric RTP. This lead to a discussion around support for multicast and non-symmetric RTP:
Jonathan Lennox
● What about multicast? Symmetric RTP would not allow MC to be bundled.
Harald Alvestrand:
● Is it possible to use bundle with multicast? It's only defined for O/A.
Flemming Andreasen (as individual)
● We usually have a separate section for multicast. 3264 also has such a section.
Harald:
● Based on the KISS principle, both non-symmetric RTP and multicast should be specified later when we have more knowledge.
Colin Perkins:
● Symmetric RTP is good but not a requirement for bundle.
Paul Kyzivat:
● I would not object to words saying implications of non-symmetric RTP are not well known.
Ari (as individual):
● Do not mandate it but recommend?
Flemming (as individual):
● We don't know how non-symmetric RTP is going to work. We can do that by leaving non-symmetric RTP out of scope and add warning text.
Christer:
● ICE requires symmetric RTP anyway.
Jonathan Lennox:
● I don't see any reason why bundle would change anything. Use non-symmetric RTP at your own risk, no matter if you're doing bundle or not.
Christer:
● What about saying that you must send all your bundled media from the same transport address, not necessarily symmetric.
Paul:
● What text says that media has to be sent from a single address:port?
Christer:
● Because you're going to have different ICE candidatesÉ
Paul:
● That's an ICE issue, not a bundle issue.
● We should allow sending from different address:port.
Bernard Aboba:
● Does anybody really consider using different sender addresses?
Christer:
● We agreed long ago that both endpoints would be doing bundle, so there's no reason to be sending from different address:port.
Christer:
● Not going to mandate symmetric RTP but mandate sending media from the same address:port
● [Note: there was general agreement on this]
Jonathan:
● We should say this only applies for unicast O/A.
● [Note: There was general agreement on this]
Mo Zanaty:
● Is bundle limited to a type of m= line?
Christer:
● RTP and data channel. You can do it for any m= line but describe in another document how multiplexing is done.
Mo:
● It can never work with TCP.
Christer:
● Right.
Conclusion (verified in the room):
● Will not mandate symmetric RTP
● Will mandate sending from same address:port
● Will limit scope to unicast media streams (state explicitly in the draft).
Bundle-only default candidates
Christer presented 4 alternatives with alternative 1 as the proposed solution:
Alternative 1: ÒDo not assign ICE candidates to bundle-only m- lines with zero port valueÓ
Lennox:
● Alternative 1 makes sense. In general in ICE you don't put candidates on a disabled m= line.
Suhas and Thomas Stach agreed with alternative 1 as well.
Conclusion (verified in the room)
● Alternative 1 is agreed to.
Move sources
The question: Òis it valid for an RTP stream (SSRC) to move between bundled m-lines, or be shared between several bundled m-lines ?Ó.
ChristerÕs proposal is to not allow this
Bernard Aboba:
● There is a special case with simulcast we should think about.
Jonathan Lennox:
● If you have a middlebox that want to leave SSRCs unchanged, then can't change streams. If want to change streams, then would have to rewrite SSRCs.
● I'd prefer to be able to move the SSRC. It adds complexity, but you can do useful things with that.
Mo Zanaty:
● I don't see how moving sources would hurt.
● Moving the SSRC between m-lines does not harm harm BUNDLE as such, so no need to disallow it as it can be useful for certain things.
Roni Even:
● This means that the MID in the RTP header will change.
Jonathan:
● Jonathan volunteered to help come up with some text if we agree to allow sources to move.
● The tricky part is if packets get reordered at the moment you start sending an SSRC with a different MID.
Bernard:
● We can just take this text out, publish this, and worry about it later.
Jonathan:
● I want to have explicit text in the doc that moving SSRC is allowed. Otherwise we might get interoperability issues.
Emil Ivov (from Jabber room):
● Does not want the restriction
Colin Perkins (from Jabber room)
● There is a problem with allowing this (clock-rate switch).
Ari (as chair)
● On the list, was there any argument for not allowing it apart from complexity?
Christer:
● Not really.
Roni:
● Clue has a requirement to actually allow this.
Conclusion (verified in the room):
● Suggestion not agreed to. Jonathan Lennox will help craft some text.
● Ari (as chair) noted we the text ASAP because we need to get the document done.
● Jonathan will provide a date for when he can do this after the meeting.
Christer presented his slides covering the following issues:
1. Active/passive + TLS role
2. Identical 5-tuple
3. Proto values
4. IANA SCTP fmt registry
Active/passive + TLS role and Identical 5-tuple
Profiles "SCTP" and "SCTP/DTLS":
Justin Uberti:
● SCTP permits both sides to be ACTIVE. And it's actually faster. The role is only for DTLS. Chrome does this. I think Firefox as well. Let's leave the setup field only applying to DTLS.
Christer:
● The endpoint behind a NAT is the one that needs to open the connection.
Justin:
● It'll work just as well if both endpoints try to open simultaneously. We will have issues if both are passive. So say that both should be always active and we're done.
Christer:
● Do we need a setup attribute at all?
Justin:
● a=setup attribute is only for DTLS. Pure SCTP doesn't need it.
Conclusion:
● For SCTP, don't use the setup attribute (slide 3)
● For DTLS, you do want to use it (slide 4)
Profile "DTLS/SCTP" Identical UDP/TCP 5-tuple
Justin:
● Want to understand the problem. Why do we need to do multiple associations when SCTP allows for ~65000 channels ?
Christer's suggestion (slide 13, alternative 1): Allow single SCTP association per DTLS connection (this is what is done in RTCWeb; does allow multiple data channels, but single association usage).
Kyzivat:
● The basic problem here is that SDP is a mess.
● In favor of Christer's suggestion.
Peter Thatcher:
● In favor of Christer's suggestion.
Conclusion
● Consensus for alternative 1 (ChristerÕs proposal), "Allow single SCTP association per DTLS connection".
Proto Values
ChristerÕs proposal: UDP/DTLS/SCTP + TCP/DTLS/SCTP are suggested as replacement for DTLS/SCTP
Justin:
● The word "TLS" has to mean the same thing whether we're talking about RTP or SCTP. Because you can put both TLS and DTLS over TCP, we need to say "DTLS" whenever we're talking about DTLS.
● DTLS over TCP is defined in ice-tcp
● Always want to use DTLS.
● Should have TLS mean the same thing between RTP usage and SCTP usage (back to Suhas' draft on IANA)
Kyzivat:
● Need to have normative reference to where DTLS over TCP is defined (ice-tcp it seems).
Charles Eckel:
● BFCP had to go through this. Dropped the "D" for DTLS (basically said "TLS" when over UDP).
Christer:
● We need to have a common definition what TLS or DTLS means in the proto field.
Lennox/Colin:
● 4571 is not a complex draft; could update it to solve the "where is it defined"
Adam Roach:
● This is the biggest bikeshed I've seen in this group in a long time.
Justin:
● This is definitely a bike-shed.
● Justin will start an email thread to choose the right color.
Conclusion
● Email thread to be started on the mailing list about this topic.
IANA SCTP fmt Registry (15)
ChristerÕs proposal: Specification Required.
Kyzivat:
● Is data-channel registration done by this draft or the data-channel draft?
● Doesn't like the term "webrtc-datachannel". Is applicable beyond webrtc.
Mary Barnes:
● Name was brought up long time ago; people didn't care then. Too late to bring up now.
Conclusion:
● Christer's suggestion agreed to.
draft-ietf-mmusic-rfc4566bis-12
draft-begen-mmusic-rfc4566bis-iana-updates-00
Ali presented his 4566bis slides and his 4566bis-iana-updates slides
draft-ietf-mmusic-rfc4566bis-12
Need more reviewers to look at Paul Kyzivat's ABNF updates.
Paul Kyzivat:
● There hasn't been much review, and we really need serious review of these.
Action:
● Christer, Colin & Jonathan Lennox volunteer to review
Note: Also need review of the template.
Bundle classification: Kyzivat didn't put in yet but should be added.
Outstanding Issues:
Issue 1: Christer had reviewed the changes and had some comments around Offer/Answer considerations missing for attributes in 4566bis and if we should add bundle considerations (category) as well.
Christer:
● Clarifying that his comment was more about for new attributes. Need to have template information etc. considering mux'ing for new attributes.
Issue 2: Christian Groves had caught some attributes and values that are missing in the IANA registries. Some of these pre-date RFC 4566 and its IANA registration requirements.
Keith Drage:
● Stuff from old RFCs that has not been registered with IANA falls back to the old procedure before we had IANA considerations sections, which is that the chairs can handle them.
● Chairs can ask IANA to get them registered.
Action: Ali to send list to chairs so they can get registered.
draft-begen-mmusic-rfc4566bis-iana-updates-00
(IANA updates for 4566bis document)
Flemming (as individual):
● Why do we need a separate document instead of putting it into 4566bis?
Ali:
● This is intended to be a temporary document that can be merged into 4566bis once content is agreed.
Paul:
● I don't know what "Attribute is character-set dependent" means.
Jonathan:
● It's for attributes that contain human-readable text, because SDP pre-dates UTF-8.
Paul:
● I would be inclined to deprecate this mechanism
Need volunteers to review the document
Action:
● Jonathan Lennox, Christer and Colin volunteer to review this one as well.
draft-ietf-mmusic-rfc5245bis-03
draft-ietf-mmusic-ice-sip-sdp-04
Ari presented his slides.
Slide 3 (pacing for non-RTP traffic)
Christer:
● RTP with non-RTP traffic may be combined with bundle. Need to consider (may belong to bundle draft though).
Ari:
● Good point; original pacing was assuming a single RTP stream. Need to consider further.
Pl-Erik:
● Still think we only need one timer for all kind of traffic.
Ari:
● Connectivity check different for non RTP since for RTP the rate may be known.
● DonÕt have good numbers for the behavior with arbitrary non-rtp traffic, need to understand it better via measurements.
Slide 4 (Updated Offer with SIP/SDP)
Consensus at IETF 90 to indicate if going to do this, but more discussion since then.
Thomas Stach:
● A lot of arguments indicating doing the updated offer causes problems
Ari:
● Agreed, which is why we can have the indication.
Thomas:
● So if offerer and answerer don't agree, who gets to decide.
Justin:
● Wrong place to do it; should be higher in the protocol stack. Should go into the SIP header. What message need to send different from the content in the message.
● Creates a real problem for WebRTC, forces clients to do SDP inspection and figure out what you are required to do.
● Doing with SIP option would be OK
Christer:
● Can do in either ICE or SIP; ICE can be used without SIP.
● It's also not just about the update offer; there is continuous nomination, etc. all of which you should be able to negotiate the use of. Need some kind of signaling indication (whether in ICE or higher layer)
● Need to decide what the default values are for this.
● Need to make sure it's backwards compatible as well.
Thomas:
● If you have other protocols than SIP; would we also mandate the double O/A exchange?
Ari:
● Are there non-SIP deployments where this could be an issue?
Thomas:
● Fundamental problem remains that some deployments don't work with the second O/A exchange and others don't work without. How to resolve?
Ari:
● Need to negotiate which one to use
Thomas:
● Will still need a tiebreaker. We also have other specs that mandate the second O/A exchange. Need to consider the issue more broadly.
Flemming (chair):
● Should raise that point on those drafts.
Thomas:
● Already did on the mailing list.
Christer:
● Responded to Thomas on mailing list with mechanisms to solve the problems he pointed out. Thomas just hasn't implemented those. Again, default should be backwards compatible, i.e. what current RFC specifies.
Keith:
● SDP is not tied to SIP. In terms of signaling, still haven't heard solid arguments as to whether this (negotiation) indication belongs in SDP or outside of SDP. Preconditions is an example where it got coupled too much.
Andrew Hutton:
● Conclusion at the last meeting was that implementations tend to ignore the second O/A. We want to simplify things, this extra negotiation seems to only complicate things.
Lennox (relaying Emil):
● There is work to be done in ICE anyway. Adding an extra indication in ICE doesn't seem like a big deal.
Lennox (for himself):
● Doing it at the SIP level would be fine; don't have a strong opinion.
Christer
● It's good to simplify things, but there are people deploying this. Cannot break backwards compatibility
● Fine with adding a mechanism that allows the second O/A exchange to be skipped, but has to be done in a backwards compatible manner.
Keith:
● Doesn't automatically belong in SIP just because it doesn't belong to SDP.
Thomas:
● Responding to Christer's point about why don't you implement PRACK, preconditions, etc
Flemming (chair)
● Asking for people to focus on how we move forward. Hear a lot of positioning and opinions, including "there is no solution". Need to focus on what we can do.
Paul
● It is the middle boxes that need this, so why a mechanism for ends to indicate whether or not it is needed. Feels more like session-timers. Need way for middle boxes to control this.
Lennox:
● There is already plenty of stuff in SIP that forces O/A behavior (e.g. offerless INVITE).
Ari:
● Suggest to have a separate off-line session on this and see if we can come up with a proposal for way forward. Need to explore the SIP option; if no solution we default back to RFC 5245.
Slide 5 (ICE nomination)
Justin:
● Agree with Ari's sentiment. We can make aggressive nomination deprecated in ICE bis and do cleanup on that. Continuous nomination should go to separate document.
Bernard:
● Generally agree with Justin. Also multiple validate pairs. Continuous nomination may belong in trickle draft though.
Martin Thomson:
● Not sure about the multiple validated pairs. Explore EmilÕs proposal separately and see how complex it ends up..
Justin:
● Think deprecating aggressive nomination should be in ice-bis.
Ari:
● Does anybody think deprecating aggressive nomination is a bad idea?
Christer:
● If you can negotiate the use of it in a backwards compatible manner, then OK with it. But middleboxes may prevent this working.
Justin:
● In good case with this media goes faster, in bad case as fast as currently. But need to do testing with this.
Lennox:
● In the absence of continuous nomination, still need to support "use-candidate".
Ari:
● Agree; no one seems to think this is a bad idea
Cullen:
● Need to think about it a little more. Why was the "use-candidate" there in the first place (in the spec); should look carefully into
Emil:
● Agree we should deprecate aggressive nomination. Aggressive nomination seems to have been designed as a redundant mechanism
Cullen:
● Keep in mind aggressive nomination is really being used today because it works and normal nomination is way too slow. Does continuous nomination replace this safely? If not, we will have some last call comments on it. Need to look further into this.
Justin:
● This new proposal takes care of this
Next steps:
● Pursue looking into the recommendation (not agreed to as final solution yet by all).
● Christer asking for additional write-up and call flows
● Emil, Justin, and Lennox will do write-up and post to the mailing list, Cullen and Ari will review.
draft-martinsen-mmusic-ice-dualstack-fairness-00
Pl-Erik presented his slides.
Chairs took a show of hands for adopting the document for matching milestone.
For adoption of document: 12
Against adoption: none
Need more information: 2
Bernard:
● Attempted to implement the algorithm. Doesn't work.
● Think it's valuable to work on, but need something that actually works.
● Would like to hear from more implementers (primary problem seems to be with tunneling scenarios).
Flemming (chair) asking if anybody else has implemented it. Only Pl has; says it works, but has not looked at all the tunneling scenarios Bernard says are problematic.
Zahed Sarker:
● Would like more data on whether this works.
Lennox:
● So can Bernard share what does work so we can use that as the baseline?
Bernard:
● Issue is the broken IPv6 routes (predominated for tunnels). Need to change the way you deal with these, the current proposal results in delays that defeat the purpose; solution may be to de-prioritize IPv6 tunnel addresses
Next steps:
● Defer adoption decision
● Pl-Erik work with Bernard (and Simon) on the problems Bernard raised.
draft-burman-mmusic-sdp-simulcast-00
Bo presented his slides.
Want WebRTC and CLUE clients to be able to use N encoded streams for one media source AND have SDP interoperable simulcast AND support layered RTX and FEC mechanisms. Not proposing any changes to SDP, just clarifying usage.
Slide 5 (Offer from Mixer to Client)
Roni:
● Does it require the use of fmtp parameters for all codecs to indicate resolution etc?
Bo:
● No. Can use SDP as usual. Just need separate payload. Resolution and frame rate
Roni:
● Need to clarify in draft the usage of codec parameters vs. image attribute
Bernard:
● Don't think the depend line shown is right. 103 should be SVC.
Mo:
● Key point of example is whether we want to align with the principle of having a payload type to show what you want to send.
Lennox:
● Seems like a reasonable example (with a few minor technical mistakes)
Kyzivat:
● O/A payload types are receive payload types; don't necessarily have to be the same in the other direction.
Mo:
● Same semantics as in normal SDP (receive numbers). Answer can use different payload types, as long as the information lines up consistently.
Harald:
● question on the fmtp; looks inconsistent.
Mo:
● Just a short-hand notation; not intended to be different or constraining compared to normal SDP.
Roni:
● Codec parameters versus imageatt is two different things.
Stephen Botzko:
● What about combination of layered and simulcast, only layered, only simulcast?
Mo:
● covered in draft
Bernard:
● There is an example of simulcast and layered in the draft, so yes, can do it. Seems like it works.
Slide 7 (Answer from Client to Mixer)
[Various clarifying questions]
Bernard:
● Going in the right direction.
● Microsoft declared IPR on draft with very similar text previously, be aware of that.
Bernard to work with his legal team regarding this draft
Bo:
● Ericsson does not have IPR on this one.
Zahed, Roni, Christer, Cullen supporting the draft
Peter Thatcher
● Not excited about different payload type for each
● Can live with it. Best alternative so far.
Chairs took a hum on taking the document as a WG item.
Strong consensus in favor.
Hum on using draft for this WG item.
Strong consensus in favor.
Conclusion:
● Consensus for adding a new WG work item and adopting this document for that item
Chairs will work with the AD on adding a milestone.
draft-ejzak-mmusic-msrp-usage-data-channel-01
draft-ejzak-mmusic-data-channel-sdpneg-02
Keith presented his slides.
Problem Statement: How to negotiate well defined sub protocol over DataChannels. draft-ejzak-mmusic-data-channel-sdpneg-02 is generic one for all protocols, draft-ejzak-mmusic-msrp-usage-data-channel-01 is specific to MSRP, similar draft needed for other protocols to be used over DataChannel.
Proposed Work Plan (slide 17)
Christer:
● Strongly support it. Very important.
● Have some comments on defining new values; not important right now.
Lennox:
● Generally like the idea.
● This is not applicable to browser implementations
● IANA considerations for dcsa may be a bit tricky (not written yet though). Need to spell out in details which attributes are valid in dcsa attribute.
Keith:
● action item accepted
Lennox:
● May be some timing issues wrt CLUE (trying to finish up in CLUE)
Kyzivat:
● Support the work; like it (and important)
● Unclear what the CLUE dependency is. CLUE is in a bit of a hurry.
● Regarding "dcsa"; seems similar to "a=ssrc" and had to define a while IANA registry for that.
● Noting gateway use case as motivation (similar to Christer point earlier).
Chairs took hums for new WG items.
Strong consensus to take on as WG items.
Chairs took hums for adopting the documents:
draft-ejzak-mmusic-data-channel-sdpneg-02:
● Solid consensus to take on document (nobody against or needing more time)
● AD asking how many people have read the document: 10-15
draft-ejzak-mmusic-msrp-usage-data-channel-01:
● 10-12 people have read
● Solid consensus to take on document (nobody against or needing more time).
Conclusion:
● Consensus for adding new WG work items and adopting these documents
Chairs will discuss with AD (and confirm on mailing list).
draft-singh-payload-rtp-1d2d-parity-scheme-00
Mo presented his slides.
Colin:
● Need clarity around SSRC handling / use cases in the draft
Mo:
● Looking for feedback on whether you have to lock-down whether there is a single SSRC or multiple.
Roni:
● How does this work with simulcast.
Mo:
● Draft only protects a single source flow currently.
● Premise of draft is RTX; question for the group is whether that is the right premise.
Option 1, associated FEC with streams it repairs using payload types
Jonathan:
● Is this to determine which FEC stream goes with which simulcast stream? (yes); Then would be useful to have way to say a FEC stream is protecting all the payload types within a given m-line.
Bernard:
● SSRC in FEC is same as SSRC in stream being protected?
Mo:
● same as RTX, declare one FEC but that FEC could be used dynamically to protect any of the streams with which it is associated.
Jonathan:
● Need to disambiguate in SDP whether FEC needs to be separate SSRC or can be same SSRC multiplexed with stream it is repairing.
Mo:
● Not allowing one FEC stream protecting multiple source streams (e.g. not protecting multiple simulcast streams).
Justin:
● Doesn't like the "apt" thing.
Mo:
● Doesn't always know the SSRC.
● Not allowing one FEC stream protecting multiple source streams (e.g. not protecting multiple simulcast streams)
Option 2, specify SSRCs such that single FEC can be used to protect multiple streams (use SSRCs instead of payload types), using ssrc-group semantics.
Peter Thatcher:
● Prefer this option.
Roni and Bernard:
● This is what is currently defined and used, even if not ideal.
Jonathan:
● The unknown SSRC case still exists and needs to be addressed, e.g. requirements addressed by option 1 are important, but may need better solution than option 1.
Mo:
● Goal is to define mechanism(s) that works for most/all working groups rather than explosion of different mechanisms for each use case.
Next steps:
● work toward agreement on multiplexing and binding source and repair streams in SDP, take to list and capture in this doc