Minutes of the Meeting: MMUSIC working Group at IETF 86
The MMUSIC working group of the IETF met at IETF #86 in Florida, USA.
The MMUSIC WG met on Tuesday March 12, 2013 from 15:20 to 18.30.
The MMUSIC WG also met jointly with the AVTEXT WG on Friday March 15, 2013 from 9:35 to 11:00
The meeting was chaired by Flemming Andreasen and Ari Keranen.
Thomas Stach, Andrew Hutton and the chairs took notes on March 12 and Jonathan Lennox acted as Jabber scribe
Jonathan Lennox, Mary Barnes and the chairs took notes on March 15 and Dan Burnett acted as Jabber scribe.
The meeting was broadcast live and recorded by the Meetecho team. The recording of the sessions are available at the following URLs:
Below is the final agenda with links to the draft and relevant sub-sections below:
Tuesday, March 12
á Introduction and Status Update (15 mins)
á Miscellaneous Drafts (55 mins)
á Trickle ICE (30 mins)
o draft-ivov-mmusic-trickle-ice-00 (20
Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
o draft-ivov-dispatch-trickle-ice-sip-00 (5
A Session Initiation Protocol (SIP) usage for Trickle ICE
o draft-ivov-dispatch-sdpfrag-00 (5
A Session Initiation Protocol (SIP) usage for Trickle ICE
á RTCWEB and CLUE Related Drafts, part 1 (90 mins)
á ICE Extensions (20 mins)
Friday, March 15, 2013 (AVTEXT/MMUSIC joint session)
á Grouping - AVTEXT/MMUSIC joint discussion (30 mins)
A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources
o UML Model
Multi-Media Concepts and Relations
á RTCWEB and CLUE Related Drafts, part 2 (55 mins)
The chairs presented the agenda and asked for agenda bashing. The chairs noted that a few agenda items had been shuffled around to accommodate constraints from a couple of the presenters.
Roni Even noted that his draft (draft-even-mmusic-multiple-streams-02) relates to the rtcweb-plan draft (draft-jennings-rtcweb-plan-01) and the two documents should preferably be presented close to each other. Unfortunately, the rtcweb-plan author (Cullen Jennings) was not able to attend the Tuesday session and due to the overall time constraints, it was not possible to have the two drafts presented the same day.
The chairs presented the status of the working group as noted in the chairs' slides.
The following is of particular note to the WG:
Drafts getting ready for WGLC – review and comments encouraged
á draft-ietf-mmusic-delayed-duplication-00 [avtext dependency]
á draft-ietf-mmusic-duplication-grouping-00 [avtext dependency]
WG drafts not on the agenda
á draft-ietf-mmusic-msid-00 [awaiting outcome of Ôrtcweb-planÕ]
á draft-ietf-mmusic-sctp-sdp-03 [awaiting outcome of RTCWEB and CLUE discussions]
á draft-ietf-mmusic-rfc4566bis-07 [still taking updates]
á draft-ietf-mmusic-media-path-middleboxes-06 [authors to clarify scope and goals]
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) Offer/Answer and Session Initiation Protocol (SIP)
Ari presented his slides giving an overview of changes in rfc5245bis and the proposed document split with SDP and Offer/Answer for ICE in a separate document.
SDP Split Discussion
á Christer Holmberg noted that ICE originally was meant to be SIP-independent, but it turned out to be difficult. Christer encouraged Ari to discuss with original ICE authors about feasibility of split.
á Eric Rescorla (Ekr) noted that trying to detach from SDP would be helpful at least. That said, not clear how easy it is to detach from offer/answer.
á Justin Uberti believed you only end up negotiating ice-lite and what extensions you might have.
á Martin Thomson suggested we could also just use the tie-breaker (without O/A)
á Emil Ivov asked why we can only control who is controller/controlled if we use O/A ?
á Jonathan Lennox said the protocol carrying it has responsibility to determine who is the controlling entity.
á Justin Uberti thought it seems like a good idea to the separation.
á Emil Ivov thought it is going to be complicated because 5245 relies a lot on offer/answer. It will be a time consuming exercise, but will be worth the effort. Emil took a look at this as well with Trickle ICE; lesson learned is that it is important to get some terminology in place to describe generically about offerer and answerer.
á Martin Thomson noted we have to accommodate race conditions (there is not always a first sender), however you do have a controller and controlling
Decision: General agreement to try and separate SDP from ICE.
Separate RTP Usage Document Discussion
á Jonathan Lennox asked how much is really RTP specific. May make sense to structure it separately, but doesn't see a need for a separate RTP usage document.
á Magnus Westerlund though a split seems reasonable, but may not need to be in separate document (RTP could be example use in the doc).
á Eric Rescorla thought it was reasonable to have a split, but it doesn't necessarily have to be a separate document.
á Martin Thomson stated that guidance on pacing from RTP is almost irrelevant, so making it transport agnostic with separate usages seems reasonable. Can have some specific text for RTP somewhere else.
Decision: General agreement to go forward with RTP usage split
Media-level ice-options SDP attribute
á Jonathan Lennox asked about backwards compatibility issues. If you have a media-level option, you'd better make sure it works with aggressive mode.
Nobody opposing media-level ice-options, but need to consider backwards compatibility.
IPv6 Address Selection
á Jonathan Lennox noted it may be an issue in large corporations. Is it worth the complexity to do this?
á Emil Ivov said that ICE is making no assumptions. This seems like making an assumption and that may not be a good idea. Emil noted there are currently a lot of cases where people have PBX'es on the edge on their networks with one leg in the private network and one in the public network.
á Jonathan Lennox noted that the relay does not necessarily mean relay to the public Internet. Principle of no assumptions is probably best. Probably best to keep current mechanism as is.
á Ted Hardie asked if "pair Unique Local Addresses (ULAs) with ULAs" means pairing same ULAs only? Ari was not sure. Ted suggested that you pair a ULA only with other addresses from that same ULA. There are some considerations and potential complexities here.
á Eric Rescorla suggested we may want to take a step back. Do you believe there is a price to pay for pairing everything with everything, as long as you put things at low priority ?
More discussion is needed on the list (some complexities here). Also, we should keep the ICE principle of "making no assumptions".
ice-option: willing and/or able ?
It is currently not clear (in RFC 5245) if an ice-option implies ability and/or willingness to use it.
á Jonathan Lennox said it could be up to each option to decide between "can" or "will" semantics.
á Bernard Adoba noted that Trickle ICE for example can have one side saying it wants to do, but if the other side says not, it won't be done.
[Connectivity] Check Pacing
Suggestions around changing the connectivity check pacing in RFC 5245.
á Martin Thomson: Recommendation right now is for max 100 outstanding, and you could have a lot of NAT bindings.
á Emil Ivov asked where did 100 ms recommendation come from ? Ari replied they basically made it up. Emil then asked why not make it 20 ms ?
The discussion and presentation ran out of time at this point (additional issues were not presented). Further discussion is needed on list.
The Tuesday session ended slightly earlier than expected, and the chairs brought up the ICE drafts again at the end. The WG was asked for consensus on adopting the two documents as WG documents.
Consensus call: A hum revealed strong consensus in the room for WG adoption of the two documents with nobody against.
James presented his slides covering changes in the latest draft and one remaining open issue on possibly adding an "Intermittent" (data) Category
James noted discussion at the last IETF on RFC 6648 (deprecating X- prefixes, etc.).
James asked the WG if we need an "intermittent" (data) category. So far, James has only seen an interest in this from Dan Wing.
á Richard Ejzak was not sure if it's needed. Why is it different from any other default traffic ? James replied that if it is default handling, then we wouldn't need it.
á Charles Eckel was not sure we know how to deal with Intermittent (may be bursty). Perhaps we should define it a bit more narrowly (e.g. intermittent and small).
á James replied that right now, Intermittent is not in the document: The question is whether it should be ?
James asked for reviewers of the document as he believes we are getting ready for WGLC soon
á Charles Eckel volunteered
á Flemming Andreasen volunteered
Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
A Session Initiation Protocol (SIP) usage for Trickle ICE
A Session Initiation Protocol (SIP) usage for Trickle ICE
Emil presented his slides covering the above three documents. The presentation covered decisions made at the Boston interim meeting as well as some comments and open issues that remain.
Discussion around "end-of-candidates" and "m= line index" (slide 4)
á Jonathan Lennox noted that we have both "mid" [RFC5888] and "label" [RFC4574] as ways to identify "m=" lines and should use one of those. Believe label is for app-level reference to the SDP whereas mid is just for grouping.
á Charles Eckel had the same understanding.
á Jonathan Lennox noted that the problem with more candidates coming is that it means that there might be more candidates coming. End-of-candidates would mean we are done.
á Paul Kyzivat believed that "label" fits exactly here.
á Justin asked whether we need both mid and label (since also doing ICE).
á Suhas Nandakumar suggested we use something different
á Justin said that looking at the text for the "label", he's not sure it's really the right choice.
á Paul Kyzivat wouldn't object to always using mid if it was always there, however he's not sure it always is. Response was that we can make sure it's always there with trickle ICE.
Further discussion needed.
Advertising support for trickle ICE (slide 6)
á Adam Roach said not to use "0.0.0.0"
á Harald Alvestrand noted that IANA has a set of "special" addresses we might be able to use.
Starting checks and unfreezing pairs (slides 8-11)
Cannot use same mechanism in trickle ICE here as in regular ICE.
á Eric Rescorla noted this may change the pacing dramatically. What algorithm is being proposed ?
á Martin Thomson stated this does have a significant effect on overall operation.
á Eric Rescorla said we need we need an algorithm proposal, and then we can try it out. The current Mozilla implementation is very aggressive and barely has frozen candidates; tries stuff as soon as anything comes in.
á Justin Uberti said Google (Jingle ?) has a similar aggressive approach.
á Ted Hardie asked if there are some issues with being too aggressive ?
á Jonathan Lennox said the problem is you may end up trying things you shouldn't be trying if you are overly aggressive (putting stuff in queue that probably shouldn't be tried at this point).
Further discussion needed.
Chairs noting that trickle ICE has been presented at a few meetings now, and would like to hear if the WG is interested in adopting it as a WG item:
á Consensus call: Strong consensus in favor of adopting trickle ICE as WG item
Chairs then asking if the WG is interested in adopting draft-ivov-mmusic-trickle-ice-00 as a WG document for the above WG item:
á Consensus call: Strong consensus in favor of adopting the document as a WG document.
The chairs will work with the Area Directors to confirm and add a milestone, subject to WG mailing list confirmation of the above.
Eric Rescorla (Ekr) presented his slides on (mostly) RTCWEB related media negotiation and transport requirements for MMUSIC.
á Flemming Andreasen (as individual) asked about the relationship to the rtcweb-plan document (draft-jennings-rtcweb-plan-01). Ekr stated that the two documents should be consistent in their requirements, but they may not be currently.
á Flemming (as individual) then asked for clarification about what a "single O/A exchange" means in lieu of the current bundle draft proposal (draft-ietf-mmusic-sdp-bundle-negotiation-03). Ekr clarified that media should be flowing in a single offer/answer exchange, however another O/A exchange may be needed for fixup.
Discussion around "Push as many media flows as possible over one transport 5-tuple"
á Justin Uberti said that less than 10 NAT bindings would be highly desirable.
á Peter Thatcher said to keep complexity at bay; less than 10 bindings would be good.
Discussion around "Single O/A Exchange"
á Justin Uberti noted there are cases where you cannot do with one O/A exchange; for example if answerer wants to add more streams than were offered. Should say 2 or less O/A exchanges.
á Roni Even asked if we are saying we are not changing RFC 3264 ? Ekr responded that we do not want to change RFC 3264.
á Roni asked if we could extend O/A for rtcweb to allow adding more m= lines in the answer ?
á Justin Uberti said he was also of the understanding that we have to stay within the constraints of existing O/A (RFC 3264).
á Adam Roach suggested it should be something that can get communicated in 1.5 RTT.
Discussion around "Negotiate parameters for each flow independently"
á Justin Uberti said that some things are obvious (e.g. resolution). RTX [retransmission payload] is already solved (by RFC 4588).
á Bernard Adoba noted you either have to change the model if you want to do everything in a single m=line, or you will have to accept some constrained set (or forget about a single m= line). Ekr agreed with that.
á Martin Thomson said the most important thing is that that you negotiate the stream at all
á Magnus Westerlund noted that for each set of media flows you transport: Those you put in the same RTP session must have a consistent RTP session level configuration (specification).
á Bernard Adoba noted that today's negotiation model (RFC 3264) has each side saying what it wants to receive. We need something that can specify both send and receive.
A few other observations were offered as well – further discussion is needed.
Discussion around "Add new tracks without worrying about glare"
á On the question around whether "is it important/valuable to do this without signaling at all ?", Roni Even said to change this point to "without per source signaling".
á Jonathan Lennox noted there could also be another signaling channel (as per CLUE signaling channel).
Discussion around "Somehow directly reference individual WebRTC tracks"
á Justin Uberti said the MSID draft (draft-ietf-mmusic-msid-00) tries to address this by relating SSRC and MSID.
á Colin Perkins noted we have SSRC Source Description that has some of this machinery and he is not convinced MSID is the right answer here. Also, some of these issues were dealt with in large scale conferences already with RTCP/SSRCs.
á Roni Even noted they had a similar issue in CLUE; they converged on using a new identifier rather than source name. Another mechanism is using an event package to tie to application, but Roni thought this was probably not relevant to rtcweb.
á Jonathan Lennox said that SSRC probably handles one level of abstraction. It's not a 1:1 mapping, but there is some mapping that can be used here.
á Harald Alvestrand said that wrt. MSID, they determined the identifier should not have semantics embedded in it. We need to get out of the SDP description and into the application description space. If using an RTCP-based solution, then he has concerns about getting RTCP in a timely manner.
á Charles Eckel was not clear on port usage in the answer (see e-mail to list as well).
á Eric Rescorla had issues with the use of the term "port" in the document and said we should find a different term. Otherwise, he thinks he's ok with the mechanism.
á Justin Uberti suggested the answerer initiates the second O/A exchange to cut down on round-trip time.
á Hadriel Kaplan said there was an open question on port usage in answer (see Charles's e-mail to the MMUSIC list). As a general idea, the draft seems like a reasonable way forward. Hadriel noted we should try to stick closely to the way SIP works (or O/A) since the reason for using SDP and O/A was backwards compatibility.
á Richard Ejzak asked for clarification on "Intermediary will have correct port information": Are we saying that legacy intermediary would work with this. What is the fundamental requirement on the intermediary here ?
á Christer replied it is to convey the ports that are being used for the transport. Richard did not accept that as a requirement for intermediaries.
á Uwe Rauschenbach (?) said we are designing a scheme to signal multi-plexing using two round-trips. Wouldn't it be desirable if we could negotiate the future thing in a single round-trip, and if that fails then fall back to the legacy thing ? Uwe thought that an approach like the one taken in KUMQUAT is a better way forward. Christer replied that such an approach had been proposed to the WG previously (the MMT proposal) but it did not gain support.
Richard said that he is a BUNDLE fan, but he thinks we should consider some small modifications to address a few concerns he has (3rd party call control in particular where endpoints may change mid-session and hence a mid-session O/A exchange should not make assumptions about a previous O/A exchange in the session). Richard presented his slides with suggested modifications to BUNDLE as it relates to the location of transport information with a goal of maximizing compatibility with legacy equipment (incl. 3pcc).
á Eric Rescorla stated that if intermediaries are going to check payload types, then Richard's proposal will not work. In Bundle, the reasoning for having all the m= lines use the same 5-tuple was that they presumably would allow for the union of what is conveyed.
á Randall Jessup asked what happens if the first "m=" line gets rejected ? Richard clarified how different "m=" lines between the offer and answer will then be matched up and a second offer/answer exchange will be done (fixup).
á Christer Holmberg said he does not believe the proposal will work. Christer does not believe 3pcc will work anyway in the examples (consider ICE, etc.). Christer would like to see a specific example where this 3pcc scenario would actually work.
á Hadriel Kaplan said that with Bundle, the SBC ports will end up being different and hence we end up not doing Bundle, which is why that mechanism actually works. What Richard's proposal seems to assume is more of a monitoring intermediary that doesn't actually understand or modify the SDP: Hadriel believes you have a lot of other problems anyway if you have this type of intermediary.
Roni presented his slides pointing out ambiguity between SDP signaling and the intended RTP session details. The draft intends to cover certain CLUE requirements and proposed clarifications to SDP/RTP signaling relationships. Part of this is clarifications around how many "streams" are really allowed for "m=" line in the SDP (based on explicit signaling).
á Flemming Andreasen (as chair) asked if the draft affects the current BUNDLE proposal. Roni said "no"; the authors are looking for some SDP and offer/answer clarifications as well as some SSRC-specific signaling. Can work with BUNDLE.
á Justin Uberti also does not see the draft affecting BUNDLE, however it seems to be relevant to Ekr's requirements presentation. It doesn't address all of the requirements though. Justin was concerned that the actual proposal seems to be limited to a small set of specific use cases.
á Jonathan Lennox saw this as a superset of the Plan B proposal (from the Boston Interim meeting) with possible addition of out-of-band signaling added (as done by CLUE). CLUE motivation is to handle dynamic source scenario. Justin Uberti was ok with that.
á Peter Thatcher asked for clarification on new SSRCs that have not been signaled. Roni clarified this would use an RTP header extension for CLUE.
Suhas presented his slides on how to deal with SDP attributes and other SDP parameters when using "m=" line multiplexing (as done with BUNDLE). The draft covers a general framework with different classifications as well as an initial classification of the SDP attributes currently registered with IANA.
á A comment was made that "ssrc" should perhaps not be in the Bad category. Jonathan Lennox noted that "ssrc" will in fact be required for some things to work.
á Jonathan Lennox noted that if SHIM (multiple RTP sessions over single transport) gets accepted, then we may need a split between transport and session.
á Suhas asked for volunteers to help finish the classification of the various attributes and parameters.
The chairs asked the WG for general feedback on the draft:
á Jonathan Lennox said it was essential for BUNDLE to work.
á Eric Rescorla was supportive.
á Harald Alvestrand was impressed. It is good work and needed.
á Christer Holmberg liked it and was willing to help.
á Justin Uberti liked it too.
Dan presented a short version of his slides giving a very brief overview of the mechanism and changes in the latest version with the goal of gauging overall WG interest.
Based on show of hands, some people had read this or a previous version of the document. The chairs then asked the WG for a hum on interest in taking on the work as a WG item:
á Consensus call: There was a weak hum in favor of adopting it and nobody opposed.
Following this, additional comments were provided:
á Martin Thomson had not read the current version of the draft, however it appeared that it might have addressed some concerns he had with an earlier version, so he would take another look.
á Jonathan Lennox thought it seemed like a small optimization over ICE restart, so not sure how much value in it.
á Ari Keranen (as individual) initially thought it was a bad idea since we have already plenty of mobility mechanisms, but this may be a good idea after all and it's worth having a close look at the details.
á Peter Thatcher thought it would be interesting to have as a backup in case the primary path goes down (like active/standby).
á Justin Uberti noted there will be some time before ICE restart will get engaged. Need to figure out what that time is and if this mechanism is then really better than ICE restart.
á Emil Ivov said that when comparing with ICE restart, we should also compare with Trickle ICE
Conclusion: The draft is not adopted as WG item at this point. The draft authors should address the ICE restart comments and we can then revisit it.
Dan presented a very short version of this slides outlining the problem he is trying to address (ICE connectivity check order between IPv6 and IPv4 addresses when IPv6 checks are failing).
Dan is looking for feedback on how to publish these recommendations; standalone or as part of ICE-bis.
á Bernard Adoba agrees the problem is real, but not clear you need to make any ICE changes (RFC 5245). Simply a matter of setting the ICE candidate priorities correctly.
á Jonathan Lennox agreed with Bernard; maybe we just need some guidance to implementers.
Please refer to AVTEXT minutes.
Christer Holmberg presented the slide (#3) with the major changes to the bundle since last meeting. Comments and discussion on the approach.
á Steve Botzko noted that there's potentially an optimization: first offer has only one stream, second offer is after you know the peer supports bundle. Framework sounds right, but there might be some optimizations (combine offer/answer).
á Andrew Hutton commented that there are optimizations we can make and further analysis is required for ICE. We have not looked at all the details and need further investigation, e.g., in dual-stack v4/v6 scenarios and ICE interactions (maybe use ICE candidates instead of m-lines for port negotiation). Requiring second offer to be sent before media can be sent is a concern. Christer clarifying that it is really about making sure intermediaries will work. Andrew's prime concern is getting media flowing quickly and maybe some optimization can be made if it is known that ICE is supported.
á Eric Rescorla commented that he has some nit-picks, but think itÕs basically sound approach and we should take the draft and then we can nit-pick the details later. Regarding second offer, that can be combined with the updated ICE offer which is totally fine.
á Adam Roach agreed with Eric about moving forward with this.
á Randall Jessup emphasized that call setup time is important: sending an offer is one thing but sending an offer and waiting for the answer to come back is another thing (need to clarify).
á Richard Ejzak very much supported the basic approach, but notes that we still need to think whether the two phases are really necessary since it may be possible to do better. Also need to analyze that optimizing for a corner case, intermediaries forwarding bundle without understanding it, instead of for main RTCWEB use cases is the right thing.
á Hadriel Kaplan noted that someone raised a point that what happens if one starts with an offer that has only one m= line and then have second offer with multiple m= lines. The SBC is detected only on the second round. Draft should be clear that one has to constantly keep checking for intermediaries; cannot just be a one time thing. Regarding media, there is no reason you cannot start sending media as soon as you get the offer or the answer (of course ICE has to complete). You can put the ICE candidates in just for the first (audio) m-line, since clipping is only important for audio. We can get to these details once we start working on the draft. There are optimizations you can do for RTCWeb; we have to handle the worst case in MMUSIC because we need to support SIP, even though it's super-ugly, just like for video codecs we'll probably have to handle H.261
á Cullen Jennings commented that is the right approach but we shouldnÕt say you need to wait for the second offer before sending media.
á Andrew Allen commented that a second offer coming from the remote endpoint may be something to consider
á Charles Eckel commented that it needs to be made clear that when bundle is supported the answer must have same ports to detect SBCs not handling bundle properly. Otherwise looks really good.
á Paul Kyzivat was in favor of using this as the baseline but wasnÕt sure what it exactly means. We have discarded MMT and same port on the initial offer, but there's still a lot up in the air. Also need to say more about how you then demux (above and beyond what's there now, e.g., if you need to use different payload types on different m lines). Christer noted thatÕs an open issue but not specific to bundle
á Randall Jessup pointed out that clipping of video is something we should care about; either should never be clipped.
á Richard Ejzak noted that if we need two differ offer formats, you need to be able to control when you use one versus the other (may be advantages to revert to separate ports in the middle of a call). Christer responded that this is an API issue and should be discussed at the W3C.
á Hadriel Kaplan clarified on clipping problem that with audio clipping you donÕt know if the other one hears you but with video you see if they can see you.
á Suhas Nandakumar noted he generally supports the approach but we need to analyze different offer/answer exchanges and how do they interact with JSEP.
The chairs took a hum on use the presented draft as a baseline approach meaning:
á The offer/exchange method show in the draft, subject to the clarifying comments made during the meeting
á The way port numbers are used in those offer/answer exchanges.
Option 1: Agree to the above
Option 2: Opposed to the above
á People in favor of option 1: 30+
á People opposed (i.e. option 2): 4
Conclusion: Rough consensus on using this approach as the way forward.
Cullen presented the slides about proposed plan for usage of SDP and RTP.
á Paul Kyzivat asked who is "we" in slide 2 ("How we can be done now with to changes to SDP")? Is it the RTCWEB-folks or somebody else? Cullen clarified it is the people who type code and who use the output of MMUSIC WG, but mostly looking at it from RTCWEB point of view.
á Roni Even pointed out that if you don't have a=ssrc, you only have the payload type number for demux and there's not enough of them. Cullen responded that thatÕs why the recommendation is to use both.
á Jonathan Lennox (about slide 3): new identifier is useful for more than just startup race; it's a stable identifier across SSRC changes for various reasons.
á Colin Perkins noted that RFC 3550 says header extensions have to be ignorable. Not clear if current proposal satisfies that. Somebody has to write a specification with the extension in it, maybe updating RFC 3550 as part of that based on the previous point.
á Cullen notes that up to the glareless add the presentation is roughly an evolution of plan A. And the following is about plan B.
á Justin Uberti noted that this is good work to make Plan A meet the requirements, but a lot of it seems like a lot of work to meet the requirements, a lot of stuff needs a lot more explanation before it meets the requirement, still a lot of known unknowns and maybe unknown unknowns.
á Richard Ejzak agreed with some of Peter's and Justin's comments that glareless looks complicated. Cullen agreed the glareless stuff is less than ideal but just something one could do.
á Roni Even pointed out itÕs hard to understand this without SDP examples. One m-line per source needs some way to distinguish them. Cullen noted thereÕs SDP example in the draft.
á Magnus Westerlund noted that between plan A and plan B, we already took a very big step with Bundle because it impacts m-line to RTP session mapping. The real open issue is what would be the reason to use multiple m= lines and what would not ? Need clarity on that. Otherwise we donÕt get interoperability. Cullen responded that plan A was to use SDP like we've always used it, before we decide the architecture and thinks Magnus is saying we need to decide the architecture or we'll fail.
á Paul Kyzivat said that at the interim he didn't understand Plan A; Ekr tried to explain it on Monday and Paul liked it better; now he doesnÕt know if theyÕre explaining the same thing, and not sure if he likes this.
á Hadriel Kaplan (about plan B, slide 6): so this is cap-neg for SSRC? Cullen: yes / Justin: no.
á Justin Uberti said this is a good summary; there's work to be done, Jonathan Lennox has a draft that describes what needs to be done. We have implementation experience with this, it works well, the unknowns are known, and needs to be written done. We reviewed Squash's document to see what needs to be pushed down, the ones to be done are indicated on the slide.
á Eric Rescorla clarified that the objective is to support a large number of flows that are independently renderable; either have the paradigm that each independently negotiable thing has its own m-line, or else move the negotiable thing down to the m-line.
á Suhas Nandakumar said advantage of Plan A is that most things today work that way; things like FEC and RTX need analysis in the Plan B case. Supporting plan A; makes things simpler.
á Hadriel Kaplan clarifies he is not saying you shouldn't keep working on it, but also doesnÕt think this is ready to be a working group item. And this needs to work beyond RTCWEB. Also worried since all this stuff is so brittle.
á Ted Hardie agreed with Suhas, that Plan A mechanism is more in-line with SDP, but doesn't see that as an advantage. Plan B is more of a departure from how things work in the past, so it has to blaze a trail but not walk around existing paths. If we expect this mechanism to be used broadly in a variety of contexts, then Plan A is the right approach; but if it's tightly scoped to the needs of another WG, Plan B is more work but easier to get done. Cullen responded that the problem exists in the narrow contexts as well, due to signaling gateways.
á Adam Roach asked if Ted suggests forking protocols whenever things become difficult? Ted responded that sometimes you need to fork protocols, when community of use is non-overlapping.
á Justin Uberti notes he is not asking people to choose if they hate legacy or not; surely interop is part of the key requirements, but plan B fulfills those requirements.
á Eric Rescorla is not taking a position on plan A versus plan B but would like the maximal amount of interoperability with legacy things, not just a G.711 call with a Cisco hard phone.
á Cullen asked what should we do between now and Berlin; if we do something quick, or work thoroughly on the architecture.
á Hadriel Kaplan said we should take it to the list.
á Jonathan Lennox notes that ignoring architecture won't work out well for us.
á Justin Uberti reminded that we agreed not to do plan B on interim, now we should write down plan B going forward. Justin will finish implementing plan B and we can evaluate the running code
á Gonzalo Camarillo commented that this is important and urgent and we canÕt wait until summer (Berlin meeting). Many people have claimed they do not fully understand plan A or plan B or the variants. Having some concrete examples and better proposals will help. Will work with chairs on virtual interim, physical interim or something, but we need to make some progress before Berlin.