Minutes of the Meeting: MMUSIC Working Group at IETF 92
The MMUSIC working group met at IETF #92 in Dallas, Texas on Wednesday March 25, 2015 from 9:00 to 11:30 and on Friday March 27, 2015 from 9:00 to 11:30.
The meeting was chaired by Flemming Andreasen and Ari KerŠnen.
Bo Burman, Thomas Stach, and the chairs took notes on
Wednesday, and Jonathan Lennox acted as Jabber relay.
Martin Thomson, Keith Drage, 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:
● WednesdayÕs recording: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_MMUSIC&chapter=chapter_0
● FridayÕs recording: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_MMUSIC_II&chapter=chapter_0
Below is the final agenda with links to the relevant sub-sections below:
Wednesday, March 25, 2015
09:00-09:15 Introduction and Status Update (15 mins, Chairs)
09:15-10:00 SCTP-Based Media Transport in the SDP (45 mins, Christer Holmberg)
10:00-10:30 Negotiating Media Multiplexing Using the SDP (30 mins, Christer Holmberg)
10:30-10:50 SDP bis (20 mins, Ali Begen)
Friday, March 17, 2015
09:00-09:30 WebRTC MediaStream Identification in the SDP (30 mins, Harald Alvestrand)
09:30-09:50 Using Simulcast in SDP and RTP Sessions (20 mins, Mo Zanaty)
09:50-10:20 ICE bis (30 mins, Ari KerŠnen)
10:20-10:50 Improvements to ICE Candidate Nomination (30 mins, Justin Uberti)
10:50-11:10 Cultural Learnings of ICE/DTLS (20 mins, Justin Uberti)
11:10-11:30 ICE IPv4/IPv6 Dual Stack Fairness (20 mins, PŒl-Erik Martinsen)
The chairs presented their slides.
Richard Barnes was acknowledged for his service as Area Director.
Agenda Bash: On Friday there is a new slot for discussing msid.
See Chairs slides for status update.
Keith Drage (as AVTEXT co-chair) noted that draft-pthatcher-avtext-esid-00 needs some attention from MMUSIC. Keith will send an e-mail with details.
Christer presented his slides
WGLC resulted in mostly editorial comments. There is one remaining issue that came up just recently
Current text: If the underlying transport protocol is modified, the endpoints MUST establish a new DTLS connection.
Christer asking if we need to put the draft on hold until "virtual connection" concept is better defined, or can we simply use the current text from the draft
Cullen Jennings: Idea with ICE was always that you could switch connections (e.g. switch to/from cellular). If reestablishing DTLS connection, that would seem to take some time and lead to issues. Text could be changed to say, just the opposite.
Paul Kyzivat (via Jabber): Draft may or may not be affected. Too early to tell; need more discussion first.
Randall Jessup (via Jabber): Should not destroy DTLS connection
Jonathan Lennox: Don't believe we should destroy the connection.
Harald Alvestrand: Add a new paragraph saying that changing ICE candidate pairs from the same ICE component (RFC5245) should not be considered a change in transport. It is still unclear whether or not an ICE restart is a change in transport.
Christer does not believe this draft is the right place to define the virtual connection concept. In any case, it seems more discussion is needed.
Paul Kyzivat: What Harald suggested belongs in DTLS; not this draft.
Cullen: May agree with Harald's general direction, but should probably be rephrased.
Conclusion (so far):
● More discussion is needed and draft will have to wait until we have more clarity on virtual connections.
Hold the draft for now (see above).
Justin Uberti: Propose to add some time on Friday for discussion of the concept of "virtual connection". The chairs agreed.
Martin Thomson: Don't want to see more DTLS handshakes. Would like to see a concrete text proposal. We should not be afraid to scrap the existing text and start over with something that is more correct.
Bernard Adoba: This is known since quite a while e.g. from EAP.
Jonathan Lennox: Agree in general that ICE restart should not lead to new DTLS, but there are cases where it should (e.g. because of 3PCC).
<more discussion>
Eric Rescorla (EKR): Re-establishing DTLS connection should be avoided as much as possible. A new fingerprint would however be an indication for a new DTLS association.
Justin: Think we are converging on only doing new DTLS handshake if the fingerprint changed.
Martin Thomson: Don't do another handshake on an existing connection.
EKR: Even if you change the fingerprint, it will be very hard to make it work re-using a DTLS connection.
Cullen Jennings: There might be interaction with Act/pass. It might be necessary that a new handshake needs to be started independent of act/pass
Martin Thomson: Punt on fingerprint change and 3PCC. Having thought a bit further about the fingerprint change, demux issues, etc, this could be very complicated Couple the fingerprint change with an ICE restart.
Jonathan Lennox: Makes sense. You also need new candidates.
Paul Kyzivat (via Jabber): Punting on 3rd Party Call Control (3PCC) is not acceptable.
Jonathan: 3PCC will result in changing the fingerprint.
Cullen - summarizing
● Change the existing text saying the opposite; it is not a change of transport if you change to another component.
● New handshake will need completely new candidates/fingerprint/ufrag, i.e ICE restart.
Paul Kyzivat (via Jabber): Suggestion to put the new behaviour e.g. into ICEbis so that its applicable generally.
Martin - summarizing:
● Within the same session, same DTLS connection, unless you update fingerprints
● If you update fingerprints you must restart ICE and generate new 5-tuples.
● If you want to restart DTLS for changes besides fingerprint then you need to make a new session (completely replaces the old one).
● Push-back on virtual connection; just use the terms we already have.
Harald Alvestrand: You only have to specify that DTLS runs over an ICE component. DTLS never speaks about 5-tuples, only connections. Scope of this draft is only DTLS-SCTP for RTP; this is not DTLS in general.
EKR: Agree with the scope point.
Justin: So if you want to change the fingerprint, then you need to do an ICE restart?
Martin: Problem is if we have two DTLS on the same 5-tuple transport; demux is very difficult; don't want to do it. Make sure you get a new 5-tuple, and ICE restart is the way to do that.
Bernard: I have a DTLS connection, I stop it, and open it up again with new certs. Do I need to do ICE restart.
Justin: Not convinced ICE restart solves this. Probably should have a few people sit down and discuss this.
Martin: Agrees with Justin's comment.
Simon Perreault: This doesn't really answer the question I raised on the mailing list.
<more discussion on SimonÕs original question on the mailing list>
Conclusion
● The chairs asked Christer to organize a side meeting for further discussion, come up with a text proposal, and present the results in the Friday session. <In the end there was no time left on Friday session so the discussion was taken to the list>
Christer presented his slides
draft-ietf-mmusic-sdp-bundle-negotiation-18
Post WGLC: Lot of comments, mostly editorial.
2nd WGLC needed.
A few questions were raised:
Martin: I'll send a link; just do what Magnus says.
Cullen: For b=AS, only use them on media level and sum them.
Thomas Stach: Shouldn't these rules be in the mux-attributes drafts? Yes.
Suhas Nandakumar: We have all this in the MUX draft. it says CT only on session level, AS only on media level.
Paul Kyzivat (via Jabber): proposal to deprecate CT on media level in 4566bis
Adam R: We should ask Magnus to pin this down in the 4566bis draft, such that everyone can understand it.
Christer and Suhas: We will put the rules in the mux draft.
Actions:
● Get Magnus Westerlund to write "bandwidth" text for SDP-bis
● Discuss further whether "CT" should be session-level only in SDP-bis.
● Include the bandwidth discussion in the mux-attributes draft rather than the bundle draft. Suhas will need MagnusÕ help on this.
● ALT 1: Keep the text as it is
● ALT 2: Relax the SHOULD-send-BAS
● ALT 3: Remove text about BAS offer
Martin Thomson: We could send BAS, but the browsers don't want the BAS offer; it does no good. Don't care which alternative is chosen.
Thomas Stach: Would be happy with ALT 3.
Cullen Jennings: ICE spec already says you should do BAS, so removing it here does not make a significant change, just not repeating it.
Harald Alvestrand: Discussion has shown to me that BAS offer is application dependent and should be left to the application.
Ari Keranen (as individual): What was the reason it was put into ICE?
Jonathan Lennox: Because it was felt needed by middleboxes.
Adam Roach: Give applications ways to do this, but don't explicitly tell them how to do it.
Jonathan Lennox: For WebRTC "proper", don't do this. For SIP you may want it.
Cullen Jennings: I'm not in favor having different text for different protocols.
Ari (as chair) asks for a show of hands:
● No hands for ALT 1 or ALT 2
● Many hands for ALT 3 (12 plus 3 on Jabber)
Conclusion:
● Consensus for ALT 3, i.e., remove text about BAS offer.
● Christer will update draft and we will do another WGLC
draft-ietf-mmusic-rfc4566bis-14
Ali presented his slides
Are these always integers?
Paul Kyzivat had made a suggestion to allow the use of decimal fractions only when the fractional part is non-zero. This definition could also be used for framerate; question around whether framerate could be zero.
Jonathan Lennox liked Paul's suggestion. Framerate should not be zero.
Roni Even noted that framerate of zero could be a still image.
Conclusion:
● Nobody objects to Ali's/Paul's suggestion, so move forward with fractional values.
Jonathan: Is this used? Shouldn't it be deprecated? What's the semantics?
Roni: Agree with Jonathan.
Ali: We should deprecate
Ari: Is there a good way to find out if anyone is using it?
Cullen: Only way is to publish an RFC, and people will start to complain.
Paul suggested to ask also SIP Forum.
Ari: Good idea
Flemming (as individual): Take care when deprecating things! It is a general question that we have to consider. As long as there is no known issues with it.
Ali: Maybe put a note that it should not be generated?
Harald: Suggest never to create it and ignore it on reception.
Cullen: Would not advice to instruct IANA to remove it from the table, because that could cause conflicts if it is defined again with another semantics. Whatever we do, should make sure it stays in the IANA registry with a reference to the RFC that defines it.
Ari (as chair) summarizing: Don't create it and ignore it when received.
Ari asked for two hums:
1. Keep it with a note saying not to use it.
2. Mark it as deprecated
Conclusion:
● No clear consensus either way.
Martin: If we keep it, we should define better what it means.
Action
● Check with implementers in SIP Forum if anybody is using the attribute and decide where to go from that.
RFC 5576 Attributes:
Ali proposed to include an entry into the IANA table for source-level attributes
Jonathan agreed and nobody was against.
Will probably be published only after sdp-mux attributes, which will add another column. This needs some sync.
draft-ietf-mmusic-data-channel-sdpneg-01
draft-ietf-mmusic-msrp-usage-data-channel-01
Keith presented his slides
Applicability statement accepted. This is only for offer/answer, not for declarative usage.
The document defining the sub-protocol needs to specify the appropriate attributes that go into a=dcsa/a=dcmap for the specific sub-protocol.
Re-using grammar for attribute from 4566 is OK.
Use same registry as for web-sockets with addition of a note that it is also used for data channels.
Martin: This is OK.
Resolution from slide-set was accepted. Draft will be updated accordingly.
Resolution from slide-set was accepted. Draft will be updated accordingly.
No separate applicability statement that this is only for offer/answer, not for declarative usage.
Will be inherited from main document
Some nodding in the room for doing so. No objection in the room.
Keith asked for more reviewers of draft-ietf-mmusic-data-channel-sdpneg and draft-ietf-mmusic-msrp-usage-data-channel
● Georg Mayer and Roni Even volunteered.
Keith would like to move to WGLC soon: CLUE has a dependency on the draft (with a target date of July 2015). Also, WGLC needs to be aligned with dependent drafts:
● draft-ietf-rtcweb-jsep
● draft-ietf-rtcweb-data-channel
● draft-ietf-mmusic-sctp-sdp
Flemming (as chair) asks for how many people have read the latest versions of drafts:
● A show of hands indicates that 5 people have read the latest version.
Action:
● Georg Mayer and Roni Even to review both drafts.
draft-nandakumar-mmusic-proto-iana-registration-01
Suhas presented his slides
Suhas is asking if can adopt as WG document.
Ari (as chair): Should we do this?
Cullen: JSEP draft normatively references this, so yes.
Bernard: We should have both proposed profiles
Martin: No problem to have both profiles, but needs another document that defines which one is used in WebRTC
Cullen: I just want to register both profiles; not say whether it is good or not. The codepoint is effectively already defined; was just never registered.
Ari (chair) asks separate hums for and against adoption:
● Bunch of hums in favor, no hums against.
Conclusion:
● Chairs will approach AD for adding new milestones, if needed
Harald presented his slides.
Questions about what part is WMS-specific and what part is generic. Thesis is that the only defined value is WMS and no other users have emerged.
Harald proposes to use the ÒOnly OneÓ approach.
Martin Thomson: Approves of "highlander approach" to this but would go much further. All this is a baggage and interoperability is not great anyway. Propose to cut a=msid semantic entirely and proposes that msid means this WMS only.
Harald notes that this might affect what is in Section 4 (compatibility with old stuff) when there is a session that doesn't include outbound tracks, there might need to be an indication of support.
Cullen Jennings: Supports idea of cutting down to be as small as possible. In functionality would not go beyond the two semantics on the slides, and if possibly reduce further. New drafts can define new things. Willing to help edit this.
Flemming Andreasen: Thinks that now three years later we indeed need to look at whether there are other use cases and now it is not clear that we have a generic problem to solve. Supports to simplify the mechanism.
Jonathan Lennox: Might have been the one to argue for generic. In meantime have invented other mechanisms to accommodate for different use cases.
Chairs asked if anyone knows of any other use cases than media stream track. No other use cases were identified in the room. Suggest to chime in on the mailing list if such use cases exists.
Martin raises issue around replaceTrack where identifiers change at the source; this doesn't cause an immediate change.
Justin notes that mid is conceptually more stable than msid.
Harald wants to see a proposal for replaceTrack.
Martin notes there is a W3C pull request on a spec on this topic.
Eric Rescorla: when SDP needs to carry this information?
Justin: offer two video streams, mid is container carrying this kind of thing. mid is constants, msid may have different semantics. Should continue simplifying this.
Justin suggests that maybe we can map mid to RtpSender/RtpReceiver.
Harald: replaceTrack needs to be discussed on the WebRTC mailing list.
Peter Thatcher also supports working on this. Can maybe get away with having just mid. Maybe need identifier for MST.
Cullen: wants the information about that too, but it may be duplicative of other things, like LipSync group.
Ari (as chair): seems that we want to simplify, but details need to be taken to the list.
Harald: to summarize going on with ÒOnly OneÓ, further discussion about msid semantics needed. Will produce a new draft and present that to group. W3C hat on: have action item to clarify replaceTrack. Will discuss with chairs of RTCWEB group.
Flemming asks if there is a potential for removing msid entirely.
Martin/Eric/Cullen suggest that might be premature, but we need to get some more clarity on what identifiers are present and their functions.
The discussion on this will continue on the public W3C WebRTC list.
Chairs were prepared to go to WGLC, but will wait for WebRTC/RTCWEB coordination on this one.
Cullen: will need significant revision of the draft and then go to WGLC.
Paul Kyzivat suggests moving the draft to RTCWEB WG.
Cullen wants to work this on MMUSIC.
Justin notes that this is no longer generic so it might belong to RTCWEB.
Ted Hardie (as RTCWEB chair): Support doing the work at MMUSIC.
Paul K says that we let others do SDP all the time, that's what the SDP directorate is for.
Ted notes that MMUSIC has all the context and moving might be disruptive.
Ben (as AD) agrees with Ted.
Ari (as chair): the discussion on simplifying the draft will happen on WebRTC/RTCWEB lists, but should be then summarized also at the MMUSIC list.
Conclusions:
● Will go forward with the ÒOnly OneÓ proposal.
● WebRTC (and/or RTCWEB) will discuss the details and provide a conclusion to the MMUSIC list.
● Will keep the draft in MMUSIC.
Mo presented his slides.
Mo notes that there is a new IPR disclosure from Microsoft.
Roni Even: What will happen if receiver does not understand any one of the simulcast lines?
Mo: No simulcast in this case and only one concurrent RTP stream present.
Roni: Need some guidance on ordering of the payload types and what will happen if the other side does not support simulcast.
Mo: No text of what happens, will just be regular SDP.
Martin Thomson: Concerned there is a bug here. Two payload types one for big and one for small. Someone who is not aware of the simulcast could choose to send the one marked not to receive. Anyone who generates an offer in this form has to be prepared to receive in this form.
Mo: SDP needs to be backward compatible. Key point about simulcast is concurrency (in send and receive directions). Have to be prepared to send any of those streams separately. If you donÕt want stream, it should not be in SDP.
Paul Kyzivat (via Jabber): there is potential confusion with using PT to designate sent streams, because the receiver may receive them on a different PT. (Non-symmetric PTs.)
Mo: now clarified in draft; regular semantics. PT can differ, like with any other.
Martin Thomson: Please check that explanation given is in document.
Bo Burman confirms that it is.
Noted that example on slide contains extra semicolon(s).
Cullen wants to understand how this relates to a=sendonly. How in interacts with Call on Hold. Opens up new ways to use SDP.
Mo: only media level squelch. No SDP exchanges needed.
Jonathan notes that the RTCP won't properly identify the stream, so the pause (or TMMBN (Temporary Maximum Media Bitrate Notification)) won't work until there is data on the stream.
Mo: actually thatÕs an issue need to be looked at; for the paused streams do we have the right information to be able to answer in RTCP.
Magnus Westerlund suggests adding some source identification information in RTCP by expanding it a little. Will be happy to design something for this.
Harald: What is meant by bandwidth in payload type. Could not find attribute on examples that specified the bandwidth.
Mo: no max-br for VP8; H.264 has.
Magnus: need to think about whether this is right way of going forward. Currently overloading payload type.
Mo suggests to look at the backup slides for goof off-line discussion background.
Roni suggests that it might make sense to do something in SDP, since the max-br is more like TIAS than AS.
Cullen wants something generic, but it could be that all codecs need an attribute.
Mo: that was decided in Payload WG some meetings ago.
Roni: need to be clear what are you measuring when measuring bandwidth.
Open question: do we need to bind this to PT, or something more generic?
Conclusion: need feedback on the list.
Ari presented his slides.
For keeping RTP in the base spec, will mention RTP as necessary to explain the use of multiple components. General nodding in the room for the approach. Will go forward with that.
Concern raised in the previous meeting: how bundle affects the Ta calculation. The formula for the Ta already takes into account all media streams, so should not be an issue.
Jonathan agrees on the analysis.
Cullen Jennings: Most important thing about pacing is when create new bindings too quickly then get unpredictable behaviour. Global pacing, bundled or not, has got to be right.
Ari: another issue is overloading your own link with traffic.
Martin Thomson: This is fine guidance to the extent that this limits the amount of data sent in connectivity checks. Should also just have a hard ceiling on the number of bits in checks, otherwise have issues with malicious peers who send large bandwidth estimates.
Ari: the minimum pacing interval will take care of this.
Christer: Side note; if worried about bandwidth then need to remember that using continuous consent has no controls on bandwidth.
Ari: continuous consent should consume less bandwidth than checks since they are sent more seldom.
Justin: continuous consent has 4 packets per minute versus 50 per second for checks.
Jonathan: would be curious to see what happens with old modems etc.
Cullen: Big difference between 20 and 50ms. Even if 50ms works, 20ms might not.
Ari: fully agree; big difference between 20 and 50ms. Next presentation will show how we figure out the right number.
Justin notes that there was a discussion at TRAM day before about signaling what integrity mechanism is desired - for hash agility. Done in STUN bis. There might need to be a way to signal this in SDP to avoid spending extra bytes. Need to look into this for ICE bis. (ice options could be way to do this)
Ari asked for volunteers to perform full reviews of the ICE bis spec. Need still to address the issues we discuss at this meeting (including deprecating aggressive nomination), but then should start reviewing. Justin Uberti, Emil Ivov, and PŒl-Erik Martinsen volunteered.
Justin presented his slides.
ICE check is about 140 bytes (if Ethernet header is not taken into account; included in the numbers in the slides). Can use 50 ms even with 28k modem.
Will use for a large sample of the Internet, with users who some are probably behind 28k modem, Chrome browser to check what interval works. DidnÕt get numbers yet since the experiment is still making itself through code review. But should have numbers by Prague meeting.
Martin suggest a modification to the experiment to move some of the higher-valued timings to the area of more interest, maybe take 35 ms and 45 ms and make them 12.5 and 17.5. Interesting behavior will be likely below 20 ms.
Cullen suggest adding 100 ms too and also recording which country the IP address is from and if possible the pacing of packets at the server so that you can log what the packet scheduling looks like.
Martin notes that this recording could be hard to do.
Cullen takes an action on proposing this modification. For example, bit pattern to identify which test this was from.
Ari also would like to see 100 ms and asks Justin and team to make a publication of this where the results are documented for future reference.
Justin will be presenting this as a paper later.
PŒl-Erik Martinsen wonders if this will be on one interface or many (will discuss).
Justin: please send comments on the methodology. Easy to make changes.
Jonathan: Is this being built into chrome or will it be opt-in to people running experiments.
Justin: in main Chrome. Experiments are run in Chrome all the time.
Justin presented his slides.
Cullen is concerned: didn't realize this feature (can send media before finishing nomination) and think that most implementers didn't realize either.
Martin: Many implementations do not send media until the process completes, but many do not realise received media before process completes. Some implementations will work by accident with this, but Firefox does not. Missed this section when was implementing this. This can work by accident; failure looks like packet loss.
Eric Rescorla is in favor for making the change, but notes that this will have a negative performance impact on implementations that are not updated.
Justin: Three benefits 1) know when nomination completes 2) full control at controlling side 2) will not need to carry code to do aggressive.
Cullen is concerned: this is effectively removing regular nomination, not removing aggressive nomination.
Justin says that this might be coupled to trickle negotiation.
Jonathan says that "passive-aggressive" nomination is the behaviour of aggressive with the wire-format of regular.
Eric observes that ice-options:trickle will drive compliant implementations into regular nomination, assuming that implementations are actually compliant.
Ari notes that ice-options-optional might provide a way to signal this if we don't couple it to trickle signaling. Also some implementations may block because they wait for nomination before reporting success.
Jonathan says trickle thing is a red herring. If offer is trickle then it is the controlling endpoint anyway.
Cullen is concerned: Chrome doesn't connect and test with all the devices that exist.
Ari notes that at least earlier there was some worries about media clipping if did something like this.
Eric: We do not really have a good sense of how the existing specifications work, so do not know if will be thrown into regular nomination. Don't know will be thrown into aggressive. Can continue to update browsers at the moment. Onus is on people with existing equipment to tell us what will improve things.
Martin isn't sure about the really-use-candidate part. Additionally hyper-aggressive nomination does not really work properly, particularly in legacy implementations.
Cullen: Many ICE implementations were done before the spec was done. One thing that was consistently implemented was sending media once got connectivity.
Justin suggests that we concentrate on identifying failure modes.
Cullen is concerned about failure modes that cause ICE to be slower.
Ari: what would need to go to ICE bis for this?
Justin suggests that the bit in page 69 of RFC 5245 be made more prominent; note that aggressive is for backward compatibility only; we might also be able to actively suppress aggressive nomination.
Ari: can do that simply, e.g., with a=ice-options:dont-do-aggressive
Eric restates Cullen's concern for old devices that only do aggressive, but those expect a nomination before sending or accepting media; these devices will be 1 RTT slower to send.
Eric recommends use of ice-options to signal passive-aggressive mode.
Jonathan says that these old boxes will be no worse off than if they were talking to a peer that was doing regular nomination.
Cullen is concerned: why aren't we doing aggressive with a new signal? Add a done message to the end of aggressive mode.
Justin wants to have dynamic control over the pair selection. Invites to make proposals on the list.
Emil postulates that there wasn't a lot of interop on ICE prior to WebRTC; this is much simpler and a painless approach; an alternative would perform worse.
Cullen: People don't take their kit to SIPIT once it is working. Would welcome concrete data.
Eric proposes: if this can be made to work, this is clearly better; negotiation can be used to avoid inflicting this on the installed base; we should adopt this and then leave an open issue to track whether explicit indication/negotiation is needed.
Cullen is concerned: he wanted a chance to create a counter-proposal.
Justin supports Eric's suggestion.
Cullen is concerned: he will drop this concern if we decide on taking this proposal.
Eric wants to understand Cullen's objection: whether it is the backward-compatibility concern or the entire technical proposal.
Cullen: we might create more modes as a result of this.
Eric is willing to wait a limited amount of time for a proposal to emerge, but this needs to be resolved at or before the next meeting.
Martin proposes we set a time limit on new proposals of half way between now and next meeting, otherwise we proceed with this, but still address the issue that ekr identified.
Conclusion: Discussion will go to list. Alternative proposals to list at latest halfway to Prague. Eric et al volunteer to try this and see how it works.
Emil wants to know about release of candidates.
Varun wants to avoid breaking MPRTP; will take action point on that.
Justin thinks that this is OK there, though it doesn't provide explicit hooks; it might help though.
Christer: If peer goes away is it an implementation issue to keep checking whether the old peer comes back?
Justin: definitely cases where pair does not work and later does start working. Certainly cases where should continue testing.
Christer: Can either side at any point switch?
Justin: Controlling side is the only side that can do this.
Martin observes that a consent expiry (in the sense of continuous consent) needs to be treated as fatal for that pair.
Emil prefers an explicit drop (in addition to the continuous consent expiration).
Justin explains why a peer might be able to make predictions about candidate lifetime. For power reasons may want to keep this because do not want to keep sending pings.
Emil: How does one come up with a value of say 5 minutes.
Justin: Option 1 is simplest and has highest power cost. Option 2 does not necessarily save power.
Emil: But option 2 is also covered by option 3.
Martin likes dont-use-candidate but does not want more timers - have enough already.
Emil suggests a STUN error.
Cullen wants either side to be able to end use of a candidate.
Agreement on that point, mechanism to be defined.
Emil wants to know what we do with candidates that were not paired during the process: what do you pair new trickled candidates with?
Ari (as chair) suggests that we work out details before we consider adopting this.
Justin suggests splitting into passive-aggressive nomination (which will go into ICE-bis) and the continuous nomination stuff.
Out of time for JustinÕs second presentation. That was moved to the end of the session.
PŒl-Erik presented his slides.
Jonathan thinks that unreliable candidates can be manifest as just a low priority.
PŒl-Erik: this is that. If candidate causes problem then mark as non-reliable for future call.
Cullen: this is really just noting that information from previous calls can be used to alter how subsequent calls can be setup.
Jonathan wants to keep multihomed support.
Martin wants this to be advice, formulae are a potential hazard, remove them.
Ari was originator of the request for specificity. Better to have some guidance than none: implementors donÕt have to come up with new formulas. Idea behind the formulae was to have roughly similar behaviour on both endpoints.
Chairs: We have a milestone on this topic to fill. Show of hands for adoption ~15 for, none against.
Chairs will confirm call for adoption on the list.
Due to lack of time, Justin gave only a brief run through the slides.
Discussion on this topic will continue on the list.