# Meeting minutes of ICE WG at IETF 99 Chairs: Ari Keränen & Flemming Andreasen Note takers: Nils Ohlmeier & chairs Jabber relay: Jonathan Lennox ## WG status Dual-stack fairness in RFC editor queue waiting for ICE-bis. Trickle ICE completed WGLC. Next: publication request. ## Agenda bash Objective of the meeting: Finalize ICE-bis. No objections against 2 hours of bashing on the one remaining pull request: ## ICE issues ICE state: Lets keep it Check list state & check list status: Check list status can be removed, pending double check. ICE priorities: Only uniqueness per stream is required ### After nomination Christer: You should be able to re-nominate after nomination and switch Nils: What to do with the not nominated pairs after nomination? Following issues are from the pull request #38. Numbers before issue reference to instances of "for IETF 99 session" in the pull request comments. The issue text refers to text from the draft. ### 1: Selected Pair, Selected Candidate Pair definition Jonathan: was there normative text saying to throw away packets on non-nominated pairs? Cullen: we switch pairs without restart Jonathan: no after selection you need a restart to switch the selected pairs Christer: this comes down to the question if you can re-nominate during an ICE session Christer & Peter: Needs to be checked against the rest of the spec ### 2: An agent SHOULD gather server reflexive and relayed candidates Is this only editorial? Nils: I think it’s okay to reduce this paragraph to one sentence Ben: every SHOULD should have an explanation, to avoid questions in IESG review Find a briefer and more accurate reason why SHOULD ### 3: An agent MUST support the backwards compatibility mode for the Binding Jonathan: only use multiple TURN servers if you believe they have different network characteristics Nils: WebRTC allows to specify multiple TURN servers Jonathan: Makes sense to use multiple if you believe they have different network characteristics (DMZ vs public, TCP vs UDP, etc.). Use same set of TURN servers across all your checklists and pick the same IP-address across all of them. The limitation from the first sentence to a single server should go. Try to come up with better text how to handle multiple servers. ### 4: The RECOMMENDED values for type preferences Cullen: can go either way (with or without the old text) Jonathan: Existing text does not take dual-stack-fairness into consideration so a change is definitely needed. Ben: some advice on why there is a SHOULD here Move to explanatory text to an appendix and reference it ### 5: When choosing type preferences, agents may take into account Move to explanatory text to an appendix and reference it ### 6: The check list is neither Completed yet nor Failed yet Looks good to most people ### 7: The agent pairs each local candidate with each remote candidate for Jonathan: “IP address” is wrong it should be “IP address family” New text appears to be okay. Need to include NAT64 recommendations. ### 8: The priority attribute MUST be included in a Binding request and be Approved ### 9: If the request had included a USE-CANDIDATE attribute Cullen: Seems like a non-editorial change - not clear if omission of the "unless..." part is correct or not. Probably better in a media handling section Cullen: this can happen in case STUN gets through the firewall which later blocks RTP Conclusion: OK with the change, but we MUST add text somewhere else to deal with the scenario where media doesn't work subsequently. ### 10: If the response was the result of a triggered check Approved ### 11: In certain usages of ICE, both agents may end up choosing Merge with given one example of how this could happen (like 3PCC) ### 12: When ICE concludes, a lite agent can free host candidates Christer & Jonathan will read this and make sure it's OK Cullen: concerns that is changes behavior ### 13: A full agent SHOULD NOT stop sending checks and responses Cullen: Believe this is an RTCWeb thing - don't belive this is correct for the general ICE spec. Jonatham: Believe this is also trying to handle forking Conclusion: Safer to keep old text, but also need to consider forking. Old text has some confusing parts to it too as well (Completed part for example is not clear). So old text still need some updates. Christer will take a stab at updating. ### 14: An agent MAY restart ICE for existing media streams Christer: The new text is not clear enough Suggestions for improvement in Github ### 15: If an agent wants to change the destinations of media streams MAY appears to be a strange way to describe this is the only way to accomplish this Cullen: change MAY to MUST Nils: implementation level only occurs in this one sentence replace “implementation level” with explicit description of full vs. lite Conclusion: Change the MAY to MUST in the new text. Change "implementation level" to description of full/lite switch. ### 16: An agent sends media from the base of the local candidate to the Looks good, except a missing “is”. Cullen: is not sure if it is really equivalent Cullen: Want to think more about it - not clear the old and new are equivalent. Due July 27. ### 17: The selected pair for a component of a media stream is Skipped because Peter put the original text back in ### 18: ICE has interactions with jitter buffer adaptation mechanisms Jonathan: don't remove it all Cullen: very important because it affects RTP and there is no other spec to reference to Ben: maybe material to appendix, but can’t move normative text there Conclusion: Keep as is ### 20: It is RECOMMENDED that, when an agent receives an RTP packet Keep as is ### 21: for all streams, within an ICE session. The ICE agent MUST NOT change. Jonathan: Elsewhere it says you do not change roles on an ICE restart. 3PCC is a challenge though - new party has now idea what the previous role was Cullen: Not an editorial change. Will not interwork with old implementations. Conclusion: keep as is ### STUNbis discussion Jonathan: do we want to use STUNbis? It changes SHA1 to SHA256 Ben: Ask the Sec AD. Not clear if the IESG will approve a spec without crypto agility at this point. If we do keep SHA-1, then will need to clearly cover it in the Security Considerations. Maybe ask the Sec AD to help write the security considerations if we keep it. Christer: will ask a Sec AD about this and to provide a paragraph Cullen: Need to ensure interoperability between ICE and ICEbis (in general). Do the new and old timing really match up? Bring it to the list please