Minutes of the Meeting: MMUSIC Working Group at IETF 90
The MMUSIC working group met at IETF #90 in Toronto, Canada on Monday July 21, 2014 from 9:00 to 11:30 and on Friday July 25, 2014 from 9:00 to 11:30.
The meeting was chaired by Flemming Andreasen and Ari Kernen.
Justin Uberti, Ben Campbell and the chairs took notes on
Monday, and Cullen Jennings acted as Jabber relay.
Brian Rosen, Marc-Petit Huguenin, 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:
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF90_MMUSIC&chapter=chapter_0
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF90_MMUSIC_II&chapter=chapter_0
Below is the final agenda with links to the relevant sub-sections below:
Monday, July 21, 2014
09:00-09:15 Introduction and Status Update
09:15-09:45 A Framework for SDP Attributes when Multiplexing (30
mins)
09:45-10:30 Negotiating Media Multiplexing Using the SDP (45 mins)
10:30-11:00 Using Simulcast in RTP Sessions (30 mins)
11:00-11:15 SDP bis (15 mins)
Friday, July 25, 2014
09:00-9:40 ICE bis (40 mins)
09:40-09:55 Happy Eyeballs Extension for ICE (15 mins)
09:55-10:30 Trickle ICE (35 mins)
The chairs presented their slides.
There were no comments on the agenda.
RTP Taxonomy draft
● Keith Drage asking who has read the draft and if key authors in MMUSIC have read it (all lead authors in MMUSIC should have read this draft and become familiar with the terminology used.)
● Action: Chairs to ask on mailing list for people to review and make sure it gets reviewed
● Paul Kyzivat: Is this a draft that ought to be WGLC'ed in multiple groups ?
● Keith: sending a WGLC indication when we get to that point would certainly be good. Keith trying to figure out if we are at that point yet, and it seems we are not.
MSID:
● No technical changes since last time
● No controversy over functionality for WebRTC MS/MST
● Chairs and authors discussing what should be done for non-WebRTC usages, possibly limiting to WebRTC usages only
● The draft needs reviewers
● Action: Ted Hardie and Adam Roach volunteered to review.
Partial Offer/Answer
● RTCWeb related drafts, not urgent at the moment
● Adam Roach presented the draft at the previous IETF meeting (#89) and asked for feedback to validate direction then; not much has been received.
● The chairs are asking people to review to make sure itŐs on the right track.
● Adam clarifies that:
○ draft-roach-mmusic-pof-pan-02 needs review
○ the groupid draft (draft-roach-mmusic-groupid) is no longer relevant
draft-ietf-mmusic-sdp-mux-attributes-02
Cullen presented his slides.
● Not a lot has changed since last time
● 2 major open issues
○ PT-scoped attributes
○ Encapsulating attributes
● New category: identical-per-pt, where the parameters for a specific PT must be identical across m-lines (e.g. fmtp)
a=rtcp-fb - should this be NORMAL or IDENTICAL-PER-PT?
● Jonathan Lennox: What if you got a packet from a new source, how would you know whether to NACK it or not?
● Cullen: Safest is IDENTICAL-PER-PT. We can change later. Does that work for folks?
● Bernard: Yes. (nobody else disagrees)
● Conclusion: Leave as IDENTICAL-PER-PT
a=framerate, frameside, ptime, maxptime - IDENTICAL-PER-PT, SPECIAL, or ?
● Jonathan Lennox: What does "per-pt" mean without actually mentioning a PT. Some of the attributes don't have a pt
● Cullen: We can clarify that in the draft.
● Cullen: Does anybody think this should not be "identical-per-pt" ?
○ Nobody disagrees
● Conclusion: Leave as IDENTICAL-PER-PT
a=fec-flow, a=fec-repair-flow, a=repair-window - NORMAL, SPECIAL, or IDENTICAL-PER-PT?
● Roni Even: Don't think they need to be identical-per-pt. Repair flow may have different payload type numbers.
● Cullen: Seems to argue for "NORMAL"
○ Nobody disagrees with that.
● Conclusion: Leave as NORMAL
Encapsulating attributes
● Category: INHERIT
● Transport Capability
○ Flemming (as individual): The configuration text seems a little backwards, but general idea is right:
■ You want to make sure the potential configurations are constructed (by the offerer) to make it easy for the answerer to pick something compatible between the multiplexed m= lines.
■ If you want to do more complex stuff, that's up to the implementation.
■ Maybe a guideline that says if you pick the same potential configuration numbers, that's by definition compatible.
○ Cullen: Can you send some text?
○ Flemming: Sure.
○ Action: Flemming to send text
Next steps
Follow up on decisions, finish security considerations (ensure no two-time pads), doc cleanup, get ready for last call
● Paul: Fine with next steps. Lots of work invested in classifications. In future it will have to be maintained. IANA section says you should add a column to table for classifications. There are 4 tables, not 1. We are talking about reorganizing those tables. This all has to be coordinated. Might need better template. Have to consider 4566bis as part of this.
○ Cullen: 4566bis should clean up the tables and the process to cover Bundle going forward. In the meantime, new RFCs/Drafts that come out will just have to do this manually (WG must verify for now).
○ Paul: Would be a little weird for 4566bis to populate the updated tables with all the mux-attributes values
● Ali Begen (4566bis author): Separate IANA issues from 4566-bis draft, let us deal with IANA issues separately. 4566-bis may take some time, one more reason to do it separately
○ Cullen: I don't want this draft to depend on a yet-unwritten draft, because RTCWEB depends on this draft. Is it okay if this draft has no IANA update, then a future draft adds it?
○ Ali: ThatŐs fine.
● Flemming (as chair): We need to think about how we maintain all of this going forward. Do all new drafts need to consider BUNDLE? I welcome additional inputs (need more WG discussion on this)
● Keith Drage: Mixing 2 things.
○ Keeping iana tables current. Draft updates table in a point of time.
○ Background discussion on how two documents interact [going forward ?].
● Cullen: 4566bis should say something about when defining new attributes, then they must assign a bundle category
○ Ali agrees
○ Remaining issue seems to be around where/how the updates tables are defined.
● Conclusion: 4566bis to add requirements around Ňbundle/muxÓ considerations for new extensions going forward.
● Action: Need further WG discussion on where/how the updated IANA tables to use for this are defined.
draft-ietf-mmusic-sdp-bundle-negotiation-07
Christer presented his slides.
RECEIVER-ID
● Need a mechanism for the offerer to associate incoming RTP packets with associated m-line, when 5-tuple, PT, SSRC are not usable for demux.
● Offerer can define an id for each m-line, and answerer includes that value in RTP packets associated with that m-line.
● Suggestion is to use existing SDP mid attribute as receiver-id
○ Unique per m-line, proper semantics, always present
○ Define RTP header extensions/RTCP SDES item for this
○ Support mandatory, usage optional
○ Bernard: Agree this works for BUNDLE, but is this intended to replace app-id?
■ Christer: No.
■ Adam: This allows us to get what we need without changing AppID.
■ Roni: AppID is also useful for simulcast, FEC
○ Bernard: Does this mean we could end up with 2 RTP header extensions?
■ Lennox: We can have several RTP header extensions in general
● Where do we document it?
○ Mid already defined in 5888
○ BUNDLE spec can specify usage of mid for receiver-id, along with header extension, RTCP SDES
■ Roni: Offer and answer mid value is the same, so it's not just a "receiver-id" (just a clarifying point).
Q1: Putting mid into RTP/RTCP
● May want to say something about length since it affects packet size, but nothing normative
● Jonathan Lennox: Discontinuity at 16 bytes (short versus long form), so may need to say something about if you ever have > 16 byte mid, you have to use long-form extensions (you canŐt just change between long and short form; need to point out in spec as well)
Q2: Used in all streams, or only bundled streams
● Include in m-lines where header extension is negotiated, or all m-lines?
● Flemming (as individual): Characters are cheap, we shouldn't do anything contrary to existing RFCs.
● Cullen: Right, if we started sending non-negotiated header extensions for any reason I would be opposed to that
● Justin: I just think we need some normative text to say that the answerer, if it chose not to bundle, should not negotiate the header extension, as it's not needed
● Jonathan: It seems that demux needs to consider the 5-tuple and not just the mid, but I guess you can do that
● Jonathan: Early media without answerer bundling seems to make this complicated.
○ What happens if answerer rejects so many m-lines that you no longer have overlapping PT types ? Do you still need to use the RTP header extension ?
■ Christer: Not sure about that level of detail yet.
○ Adam: You need to do that anyway, since you always have to be prepared for early media being bundled (without getting the answer first)
● Agreement to go with "Alt 1", only send where it's negotiated, with text about how answerer should negotiate the header extension.
Q3: Usage in both directions
● Allow usage from answerer toward offerer only (Alt 1), or both directions (Alt 2)
○ Suggestion is Alt 2 (both)
● Jonathan: Needed for renegotiation cases, if early media starts going the other way (e.g. from caller-callee)
● Justin: Agree you want to allow this, but you might not need to send this, e.g. from initial caller-callee media. Will this be discussed in future slide?
○ Christer: Yes
● Agreement it should be supported in both directions (ŇAlt 2Ó)
Q4: When is the RTP/RTCP mid value sent?
● Alt 1: Always,
● Alt 2: Send RTCP SDES mid whenever CNAME is sent. Send RTP mid whenever new SSRC appears, optionally for critical media frames, talkspurt start - need to figure out how long
● Cullen: Need to consider monitoring boxes that don't see everything. Maybe send in a few packets every 15 seconds (plus X times at the beginning).
● Colin Perkins: Agree with alternative 2 as well. RFC 3550 has some guidelines for how often you send non-CNAME items, and should probably look at those (may not send with every CNAME).
● Jonathan Lennox: All the other SDES items are informational, whereas this is necessary for correct operation. So we need something more robust than just informational stuff; maybe we need an update to RFC 3550 here.
● Eric Rescorla: This only needs to be sent in the beginning of the stream - can't display video without it. If it doesn't show up in the first 5 seconds, no need for it (other party will likely hang up).
● Christer: Refer to Cullen's comment about sending throughout the session.
● Eric: OK
● Colin: Send this in the first few RTP packets, as well as RTCP packets, in case middlebox is stripping RTP header extensions
● Jonathan: RTCP solves middlebox problem (JU: assuming it can decrypt the RTCP)
● Agreement to move forward with Alt 2, and figure out the details in a followup meeting
● Action: Christer asking for people to send text. Christer will also organize a call to sort this out. Noting AVT issues here as well (more than MMUSIC).
Q5: RTCP SDES item also in RTP
● Alt 1 - mid-specific RTP header extension
● Alt 2 - Use RTCP SDES item in RTP (defined in westerlund-avtext-sdes-hdr-ext)
○ Would be a new dependency for BUNDLE
● Jonathan: No difference between the two. Just a documentation thing. Can other SDES items refer to document or do they need to copy text. Process thing.
● Cullen: Prefer simpler (alternative 1). Let's not take a new dependency when we could have 2 paragraphs and be done.
● Bernard: Agree with Cullen. Avoids the complexity of privacy problems, e.g. sending phone numbers in RTP
● Keith Drage (AVTEXT co-chair): Let's discuss for 5 minutes in AVTEXT.
● Colin: Privacy issues already exist for RTCP. Mechanism to make this generic is trivial. We need to make something new, but let's do one mechanism we can reuse - this shouldn't be hard. (Support for SDES approach)
● Roni: Co-author on draft, I think we can use this.Not good to have two solutions
● Jonathan: Need to decide whether header extensions are encrypted or not. I think not, since this info could be determined from 5-tuple in non-BUNDLE scenarios. No difference on wire, since SDES byte doesn't need to be sent.
● Colin: Privacy is red herring. Don't send private data in RTP. We have the same protection mechanisms for RTP and RTCP.
● Bernard: Disagree on privacy. If it were generic, probably needs to be encrypted; if not, it doesn't have to be. More complicated to say that SDES items sometimes need to be encrypted and sometimes not. Also, in AVTEXT, no case was made for this other than MID and/or AppID.
● Flemming (as chair): Getting away from MMUSIC discussions, into AVTEXT. Can this be handled in AVTEXT?
○ Keith: We have agenda time.
○ Flemming: Any Area Director guidance?
● [Proposal] Ted Hardie (RTCWeb co-chair): We understand how to do the RTP header extension now, but we have a potential general mechanism. I suggest we go ahead with the specific approach now (Alt 1), and replace this with the general mechanism (Alt 2) if it shows up in time.
○ Keith: Did not mean to suggest moving the documentation, just that some discussion needed to happen in avtext. One possibility is the generic mechanism is defined in this document.
○ Flemming: Does that make sense to everyone?
● Colin: If we do the signaling right, we can do this in a backwards-compatible way.
○ Flemming: Can you assist ? Colin agrees to help out.
● Conclusion: People generally ok with TedŐs proposal above, so proceed in accordance with that.
○ Colin Perkins will help.
○ Keep AVTEXT in the loop
Q6: Usage in RTCP only?
● Alt1: Use in RTP and RTCP (recommended)
● Alt2: Use in RTCP only?
● Colin: No problem with both RTP and RTCP. But possible that something will strip header extensions. So receiver needs to deal with this.
● Jonathan: Don't think this stripping can happen with DTLS-SRTP, since it would break auth. Main concern is whether additional bits are going to break some transports (there has been concerns in the past about expanding RTP packet sizes). If someone says this is a real issue, we need to handle it.
● Cullen: It could be a real issue, but we just won't BUNDLE in that case. The data needs to be there in the first RTP packet, so falling back to RTCP is problematic anyway.
● Adam: Same as Cullen.
● Colin: Not sure. You could have some media clipping and still survive. We should be robust about this. You want this for the first RTP packet, but if you don't have it, you shouldn't fail. Should be able to throw away a few initial packets while waiting for the RTCP to show up (presumably pretty quickly).
● Christer: The main question is whether we want to explicitly support a RTCP-only mode.
● Roni: Think alternative 1is the best one; always use in both RTP and RTCP (don't need to negotiate).
● Adam: If we are willing to wait for this stuff to show up, you could just put the SSRC in the answer and wait for that.
○ Colin: General robustness principle to allow for RTP and/or RTCP
● Justin: Given this, and the fact that the RTCP will be encrypted (making the MID inaccessible to many monitoring boxes), is there any value in sending the MID in RTCP?
● Jonathan: Well, maybe we should reconsider SSRCs in signalingÉ
● Harald Alvestrand (relayed from Jabber room): 3rd party boxes that are not explicitly allowed to be part of the session is not something we should spend time on.
● <lots of conversation>
● Conclusion:
Agreement to send in both RTP and RTCP (Alt 1).
● Follow-on discussion: If the rtcp is encrypted, then putting in rtcp wonŐt solve the monitoring box use case. (No objection to using rtcp in first place).
Next Steps
AVTEXT is another next step.
Update from AVTEXT meeting discussion (on Tuesday, July 22):
● Agreement [with AVTEXT] that Bundle draft will be WGLC'ed in MMUSIC and AVTEXT at the same time since there will be RTP header extension in the document. For the joint WGLC, all comments should be sent to the MMUSIC mailing list so we donŐt need to split the discussion needlessly. Comments from AVTEXT will have to be resolved as part of the WGLC.
draft-westerlund-avtcore-rtp-simulcast-04
Bo presented his slides.
Changes
● Significantly simplified, relies on PT for media format of each simulcast stream
● New syntax, a=simulcast [send|recv|sendrecv]
Simplified approach
● PT fully specifies each unique encoding for each simulcast stream
a=simulcast
● Bernard: Not sure why these aren't two m-lines, we could just have an a=group attribute and we're done.
● Bo: This is conformant with unified plan, where a single media source is used for each m= line.
● Bernard: I don't think it's conformant with RFC 4566.
● Mo Zanaty: We discussed having multiple usages, for unified plan or conventional SDP.
● Adam: Unified plan talked about using multiple SSRCs to disambiguate
● Jonathan: There are different SSRCs.
● Adam: Nevermind.
● Cullen: The sender can choose what PTs they send.
● Bernard: The answer can choose between PTs. It's the offer that is the issue. Simulcast is inherently asymmetric. You're sending multiple streams and receiving one. It's a bit of a weird thing.
● Jonathan: I'm willing to receive simulcast is a valid thing, e.g. cascaded MCU. Unified plan is a little weird in this regard, but I don't think we want to reopen that.
● Mo: Could have multiple simultaneous streams
● Paul: Can you have simulcast with MediaStreamTracks?
● Jonathan: Browser could send simulcast, but probably not receive. Unless it was a MCU, currently out of scope.
Alternatives
● Cullen: I don't think we need this. So complicated to have multiple a=simulcast lines. If we need to do that, we're in CapNeg (RFC 5939) territory.
● Jonathan: Mixing and matching codecs is fine, and need to support different sizes.
● Mo: Some folks want to express aggregate capabilities. e.g. can support a single 4K stream, or simulcast of HD + low res streams
● Jonathan: Let's not reinvent CapNeg. This complexity is what CapNeg was designed for.
● Cullen: No real objections to going forward, I don't need to code this.
● Stephan Wenger: H.265 ver 2 just completed two weeks ago, includes scalability.
● Bo: Room seems to think comma-separated list is the way forward, and if you want more, use CapNeg.
● If you combine simulcast with a depend line, you get scalability
● Works with BUNDLEd media
Next steps (discussion)
● Use cases - compelling and sufficient to progress the work ?
● Are the semantics sufficient for most use cases ?
● Repair
flows - RTX uses PT bindings, so no problem. FEC needs more work.
● Flemming (as chair): previous drafts had IPR declarations. Has that changed here?
○ Bo:
Don't know.
● Emil: Can you have multiple payload types in receive?
○ Bo: Yes
○ Emil: WebRTC clients would typically only have a single PT for receive?
○ Bo:
Yes
● Flemming (as chair): Comments on the draft from the group?
○ Bernard Adoba: I don't think it's acceptable to have such a fundamental thing with an IPR declaration
○ Jonathan: Fundamental question - do we want PT to be our fundamental demux point? Worried, but not scared, but we are using up a bunch of PTs by doing this. I don't have a proposal right now, but we should work through the use cases, with multiple cameras etc.
■ Mo : To question of whether PT is sufficient - we may want to have payload-specific mechanism, or something like fmtp that applies to a broad family of codecs. How would you have simulcast of different bitrates with VP8?
■ Bernard: PT might not handle all cases, but it's a place to start, we know how to do it.
■ Jonathan: One thing hard to hang on PT is bandwidth. b= is complicated regardless.
○ Flemming (as chair): Use cases. Do we need to tighten any of these up?
■ Cullen: Glad to send text to improve use cases, but I think you got the main ones.
○ Flemming: Any other comments, feedback? Anything to do at this point?
■ <silence>
draft-ietf-mmusic-rfc4566bis-10
Ali presented his slides.
Outstanding issues:
IANA registry
● Flemming: Any comments from the room?
○ <silence>
● Flemming (as individual): Just a question of timing. Not sure there is a lot of urgency for IANA registry draft. Seems OK to leave in 4566bis.
● Paul: Originally I thought we could handle this in 4566-bis. But now I think we need to rethink this given the stuff discussed today.
○ Ali: New extensions need to follow guidelines in this draft.
○ Jonathan: 4566-bis would have a normative ref on mux-attributes, and this doc would have a normative ref on 4566, which is a bit weird, but weirder things have happened.
■ Ali: 4566-bis needs to normatively reference mux-attributes?
■ Jonathan: If it talks about mux-attributes, it needs to reference it.
○ <lots of discussion>
○ Paul: Does mux-attributes need to reference 4566-bis?
○ Keith: Please separate discussion of drafts from what the draft needs to say about IANA. If it's the IANA table, it has no normative meaning whatsoever. The draft needs to say that.
○ Cullen: Mux draft won't change the tables, but will add a new column. It will also add a new table (for IDENTICAL, etc). If new things are created before this doc is published, IANA will ask for the proper contents for this column. Then, as a completely separate issue, we can consider reorganizing the tables IANA has as a whole. I want to get the mux draft out before we try reorganize anything.
■ Ali: I think this is a good idea, since the mux draft is almost done.
○ Colin: I think we are making something simple very complicated. Some text to add a new column and say that when making a new thing, need to fill in this table, referencing the mux draft for contents of said column. Let mux draft do what it needs; reorganize later in 4566bis.
● Conclusion: Mux-draft will add column, 4566bis will add normative reference to mux-draft. 4566bis may reorganize the tables later (and separately).
ABNF syntax for all attributes
● Paul: Not sure I can get them all right, but will try
● Ari (as chair): Could we have some volunteers to help Paul?
● Paul: I know ABNF, but need to figure out all the proper semantics
● Cullen volunteers Suhas
● Christer volunteers
Should source-level attributes in 5576 be included in same registry?
● Ali: I think so.
● Flemming (as individual): Are you suggesting that if someone comes up with a new extension, they need to consider how it applies to 5576?
○ Jonathan: The default answer is that it doesn't.
○ Jonathan: New attributes can choose between session-level, media-level, source-level. New extensions must say whether they have source specific behavior.
● Flemming (as individual): When you come up with a new extension, need to consider these behaviors and how it interacts with multiplexing.
● Conclusion: 4566bis must require new extensions to consider session-level, media-level, source-level and bundle/mux behavior and include in registry.
Consistent format for defining new attributes
● Eric: I'm volunteering Paul to write a template for this that we can then fall in.
● Paul: It's a matter of picking. Being on SDP directorate, I see a lot of things, and some are really messed up.
● Paul: Subtleties that ought not to be discussed here. On list should figure out which way to go.
● Ali: Can we discuss what people prefer (see slides) ?
○ Jonathan: option 2 or 3 please, not 1 or 4.
○ Paul: I like 4.
○ Colin: Definitely not 1. Not 4 either. I would guess 3, but 2 would probably work as well.
Eric: Chairs should convene a design team and decide this. Not a plenary discussion.
Conclusion: Seems option 2 or 3 are the preferred ones (people not favoring 1 and 4). Discuss further on the list/off-line with interested parties
draft-ietf-mmusic-rfc5245bis-02
draft-ietf-mmusic-ice-sip-sdp-03
Ari presented his slides.
Connectivity Check (STUN Transaction) Pacing (slide 3)
Peter Thatcher (for Justin):
● NAT binding tests were not finished; will try to finish for the next IETF
Pl-Erik: Will try to provide numbers. Earlier tests have shown that 20 or 50ms works.
Emil:
● Using 20 ms doesn't seem to be breaking anything (based on Chrome datachannel).
● Ari: pointer to this info would be good
ICE Restart (without SIP) (slide 4)
Proposal: ICE ufrag and and password changed in ICE restart even in non-SIP cases
Proposal accepted (nobody disagreeing; some nodding).
ICE Restart (without SIP) (slide 5)
Lennox: What is the concern with making it the same as with SIP? Implementation level needs to be there; lite is part of ICE core.
Emil: Not impacting signaling protocols only. There will be signaling interworking functions with different protocols on each side and ICE have to work through those. Argues heavily in favor of having same mechanism for SIP and non-SIP
Ari: So keep as MUST requirement
Lennox: media stream is an ICE concept; or at least should be.
Conclusion: Keep same mechanism for SIP and non-SIP as MUST.
Choosing default candidates (slide 6)
Christer: Is this really what is deployed? Thought default candidate today was typically just the local port. Which, if you have NAT, doesnŐt work.
Ari: Yes, and this is not such a good idea.
Emil: ICE has existed for a while with people doing what they do. If you put local addresses there, it may still work due to these workarounds.
Ari: yes, and in these cases you would know that the local addresses would work.
Lennox: Thought the point of default candidate was to make things work when ICE is not used. So should strike the word "even" from the proposal; otherwise seems OK.
Lennox: Other question: Do you have to have a default candidate. If your protocol does always ICE do you need to add an ICE default candidate? Default candidate is SDP concept. More general would be Ňconcept for anything that needs to maintain backward compatibility to an earlier declarative addressesÓ.
Ari: Agree with comment. Will have to check the exact wording and add consideration to 5245bis if needed.
Seriously-USE-CANDIDATE (slide 7)
Peter Thatcher (for Justin): If we are using DTLS, then we could use the traffic from DTLS as an indication for the pair controlling side wants to use. In some cases not only priorities (e.g. also RTT) could be used. In these cases we would want the controlled side keep candidates around for more than 3 seconds as well. If we don't have DTLS, then we need something else. Seems only use for this is then for non-DTLS.
Ari: we have something like this already for the aggressive nomination bug.
Lennox: If people want this behavior, then don't use aggressive nomination (regular nomination should effectively give you the same behavior). If I remember correctly, you can send media on pairs even before theyŐre selected. Seems they want behavior of regular nomination with freedom to send media early. Then do that. Issue with aggressive is that controlled side starts cleanup time after it gets USE-CANDIDATE.
Ari: Currently, we only have 3 second timer recommendation. If we donŐt want to do something like this, maybe we want to add recommendation for example for a 15 second clean-up timer?
Jonathan: something may go wrong if peer never sends USE-CANDIDATE?
Emil: Looked at ICE RFC, and didn't find text supporting Lennox's claim that you can send media on any confirmed candidate pair when using aggressive nomination. If that is true, why do we have aggressive nomination.
● Lennox: One fewer ICE check. ICE RFC says you must be prepared to receive media on any pair. But will have to check again.
Emil: Don't believe Lennox's interpretation is what is conveyed by 5245; need to look more into. If we go down that way, need to make it clear in bis.
● Lennox: Will DTLS be OK if we do handshake on one pair and then move to another?
● Emil: not OK, since bound to port and address (donŐt remember the RFC). This has been causing issues in real world and thatŐs what started the discussion.
● Jonathan: need to look more into DTLS case
● Emil: need to start thinking if we need aggressive in that case. Many implementations implement only one mode. Removing one would be a good win.
● Ari: that is allowing to send media before sending USE-CANDIDATE?
● Emil: yes, but not sure how to fix backward compatibility. New option?
Peter Thatcher: Somebody who knows more about aggressive nomination need to look further into this. Suggesting Justin should chime in.
Pl-Erik: Don't believe you are allowed to send media before completed connectivity checks. DonŐt do that in our implementation. If we would unify aggressive and regular nomination, that would be desirable. Needs more investigation.
Adam Roach: The phrase "MUST be prepared to receive" should not be used to mean that you are allowing to send. SIP still suffers from this; need to make that clear in the spec.
Conclusion: Need to understand existing behavior better; can you send on any pair media, how stacks behave, aggressive nomination, and DTLS interaction.
Unexpected ICE (SDP) answer (slide 8)
Thomas Stach: Make sure call is not dropped or ICE is shut down. Simplest remedy is to just do an ICE restart and then fallback to 3264 and do next restart when moving back and use ICE again. May not solve every case, but is a good recommendation.
● Ari: What are the situations where this would not be the right behavior?
● Thomas: Need to think further about.
Eric Rescorla: Technology aside; what is the intended behavior?
● Ari: Intended behavior is to do the part not supporting ICE without ICE and then move back using ICE.
● Eric: in cases not supporting ICE you will get dead air and people will hang up
● Thomas: If you don't have media as a result, that may be ok in some scenarios, e.g. music-on-hold (may just not get media while on hold).
● Eric pushing back on whether this is really useful; won't called just hang up when there is dead air?
● Emil: Think we are complicating this. This is not really different from the initial O/A exchange where we just fallback to 3264 if the peer did not support ICE. This is essentially the same; just mid-call. Should just say this.
● Ari: yes, want to avoid dropping the call in this case. So probably the right guideline in ICE SIP draft would be Ňif this happens, donŐt drop the callÓ
● Andrew Hutton: if you get offer without ICE, still try ICE the next time
Conclusion: These guidelines seem reasonable. Thomas will send text contributions.
Choosing Component ID (for non-RTP cases) (slide 9)
Lennox: Is there any need for restrictions for usage documents (beyond maybe saying between 0 and 256 and unique as an example)?
● Ari: Good question. Don't see obvious reasons. Needs to be unique.
● Emil: Matters for the frozen algorithm. Convey the intention of RTP and RTCP, so need to number them. Will be un-freezed in the right order.
Emil: Ňstart at one and continue from thereÓ.
Jonathan: having section for what usage documents must define would probably be helpful.
Ari: seems SHOULD is good level for this for consistency and easier debuggin
Peter Thatcher: The only reason we have component is because of RTP/RTCP. Don't see any other protocol that will be split like this.
● Ari: well, never say never
● Eric Rescorla: Should strongly discourage the use of multiple components in future specifications (frozen is really complicated).
Conclusion: Start with 1, and continue. If you have more than 255 components you are doing something wrong ;-). Requirement is a SHOULD (not MUST). Discourage use of multiple components in future specifications/usages as well.
Offer/Answer Terminology (slide 10)
Some thumbs-up for removing Ňfor offer and answer protocolsÓ part from the title and abstract.
Eric Rescorla: there are pieces of ICE that assume symmetry between "offer" and "answer". For example controlling and controlled determined based on that. Can't just remove that. Need to think about it.
● Emil: Intention is that we don't bind it to 3264, but still need to recognize the roles of initiating message and the response to that; hence ICE offer and answer. Two messages but not 3264.
● Lennox: itŐs clearly for more than just protocol for NAT traversal; itŐs protocol for NAT traversal in cases where you have some signaling. O/A protocols in general sense is OK. The red stuff should be black.
● Peter: Like moving away from the words offer and answer, because there are ICE scenarios where you wonŐt be dong typical offer/answer but still do ICE. You just need to exchange info from both sides and pick controlling side. Could be ICE controlling info and controlled info.
● Simon: ICE is an offer/answer protocol. Remove the red part because it is implied.
● Christer: There needs to be a mapping between 3264 terminology and whatever we use here. Other SDOs are using ICE and are referring to SDP o/a. If they refer to old RFC, no problem. With bis need SDP o/a from somewhere.
○ Ari: ICE-sip is the place we define that. Could be used also outside of SIP, but this terminology would be in ICE-sip doc.
● Mary Barnes: Think it would be confusing the terms "ICE offer" and "ICE answer"; stay away from offer and answer if we change the terminology.
○ Ari: any recommendation?
○ Mary: send/receive?
● Christer: What are differences between SDP O/A and ICE O/A? Why canŐt we talk about SDP o/a? DoesnŐt mean SIP.
● Ari: We do need something that is more generic than SIP; ICE o/a can be done with SDP, but is not necessarily done with SDP.
● Mary: Make sure we don't overload terminology. ICE-give/take?
● Peter: controller-info and controlled-info
○ EKR noted they may not match to offerer and answerer
● Lennox: ICE lite complicates things.
● Eric Rescora: no inherent reason for offerer to be controlling. Just design choice. Could have tie-breaker in SDP. More tending towards terminology without symmetry; but donŐt care too much.
Conclusion: No clear agreement. Will do as proposed and if we come up with something else really good weŐll switch.
Updated Offer with SIP (slide 11)
Lennox: This should probably be specified in the usage document (SIP in this case).
Ari: yes, and the updated offer would not be even discussed in the base doc.
Eric Rescorla: Question for implementers: How many clients actually do the updated offer? Cisco phones do (from Pl-Erik); Chrome and Firefox do not. Can we get measurements on the fraction of implementations that do the updated offer and then indications of failure rates to see if this is really needed. It is not clear it is really needed in practice, and it is a clear implementation complication.
Pl-Erik: Have not tried what happens if you don't send the updated offer.
Christer: Don't understand the "configure-option". Believe it should be a MUST for SIP (strongly support). Helps with a lot of error cases that have occurred with middleboxes as well as some client implementations.
Emil: TURN relay candidates insertion is an example where you want the updated O/A (so you know you can release the candidates). Can be solved with a time-out as well of course. It is not guaranteed currently to happen (in practice), so every proper implementation today can handle not getting the updated O/A. Think config option is OK, but maybe with a default to not send the updated O/A.
Andrew Hutton: Agree with Emil. Middleboxes that care remove ICE from the offer. Complicates a lot of call flows when you send the updated O/A.
Thomas Stach: Agree with Andrew.
Eric Rescorla: Argument for doing this originally was that middleboxes do path enforcement. Christer suggested it was helpful for debugging and diagnostics (especially on middleboxes), however it's a big inconvenience for implementers and hence preferably we should not do it. If I can unilaterally decide that I donŐt do updated o/a, thatŐs good. Better to have indication that I would do updated o/a though.
● It either has to be implemented or it is not required. If not required, then there has to be a clear indication that you are not doing it (and vice versa).
Tiru Reddy: Believe updated offer is very useful with SDN. SIP box would help the SDP box to configure the network. Go with current proposal.
Christer: Suggest you must always do it. Could add a negotiation mechanism to determine if need to do.
● EKR does not want to add negotiation mechanism; even more complication.
Lennox: Negotiating it is bad (especially since it's for the middlebox which would have to look at that negotiation). You can always send new offer. Negotiation seems silly.
Parthasarathi Ravindran (from Jabber room): New O/A has to be MUST.
Christer: if nothing changes, sending new offer is somewhat silly. Problem is you donŐt know if there is new offer coming. If this is optional, how long should one wait? Problem is that nodes donŐt know.
Emil: if we make this must, weŐre turning SIP into 4-way handshake.
3 options
1. Current 5245 behavior (only if change from default candidate)
2. MUST always do updated O/A (whether change or not)
3. "Ekr's" proposal: you do it or donŐt do it, but you indicate in the o/a if youŐre going to do it. Basically want to have option to never do the updated O/A exchange, with an indication in the signaling that you will not be doing it. Of course can always initiate a new O/A exchange whenever you want to.
Consensus call by chair (Flemming):
0 for option 1
3 for option 2
15 for option 3
Chair calls consensus on option 3.
Jonathan: if you configure yes, is it #1 or #2?
Eric Rescorla: need tri-state, yes, no, maybe?
Ari: option to indicate if you do or donŐt; if absent, 5245 behavior.
Simon: IPv6 privacy addresses? (no slide Đ raised
on mailing list)
When sending list of host candidates, and have IPv6 privacy addresses, one should not advertise other types of the same interface. ICE bis should say something about this.
Pl-Erik: SimonŐs proposed text was good. Should also not send IPv4 addresses?
Lennox: you want ŇdonŐt send any that include MACÓ
Simon: not useful, if lower bits are constant, itŐs problematic.
Alissa Cooper: Now we have concept of stable privacy addresses as well; need to be clear which this considers.
● Simon: if youŐre advertising stable, donŐt advertise unstable
● Jonathan: IPv4 addresses donŐt expose anything.
● Emil: is there API for recognizing these addresses?
● Simon: yes
Simon: need to advertise IPv4: not trackable and need to support dual-stack
Lennox: Do we want to recommend between privacy and non-privacy IPv6-addresses?
● Simon: Should recommend IPv6 privacy addresses. No reason not to use them.
● Ari: is there some cases need to use non-privacy?
● Simon: maybe local firewall, doesnŐt make much sense
Lennox: Can you expect same connectivity level between privacy and non-privacy IPv6 addresses on a given interface?
● Simon: Believe so. On the same interface. If there are multiple prefixes on the same interface, that could end up via different ISP. Per interface, per prefix would work.
Conclusion: Seems some text would be good; not clear on SHOULD or MUST and further guidelines. Discuss further on the list.
draft-reddy-mmusic-ice-happy-eyeballs-07
Pal-Erik presented his slides.
slide 7
Simon: There is no limit on the number of IPv6 addresses an interface can have. Usually you have 3.
Martin Thomson: Not sure how much of a problem there is; more a set of considerations to keep in mind.
● Pal-Erik: Trying to solve a problem around the order in which you perform connectivity checks.
Emil: Think document is generally good. Does it need to be standards track or could it just be informational?
● Helps with optimizing connectivity latency as well as avoid breaking connectivity
Ari (as individual):
● Like the idea and recognize the problem. Some guidance is needed.
● Earlier mechanism was a bit flawed; this version seems to work and makes sense to do something like this.
Lennox: Should this just be an input to ICE-bis?
Ari (individual): Think ICE-bis should reference this and make sure itŐs aligned with this document. This is more than just a few pages so having a separate document makes sense.
Lennox: Don't remember if this is relaxing a SHOULD in 5245, so would this be an update to 5245?
Pl-Erik: the section this is updating is recommendations only.
Ari: Doesn't violate anything in 5245.
Lennox: Verify it's not changing anything that has 2119 language in 5245.
Lennox: Do we want to have any of the IPv6 privacy address considerations in this draft?
● Pl-Erik: good question; there is IPv6 spec for choosing one over the other, but doesnŐt apply here since doing ICE
Ari: Think we need to have some text on privacy IPv6-addresses in ice-bis; if more extensive then maybe some should go in this document. Need to get reviews from IPv6 people. Maybe present in one of the groups or at least send a pointer to the mailing list.
Chair poll of the group:
People believing there is a problem to solve: 6 for, 0 against.
People believing we should take on this work: 7-8 for, 0 against.
Chairs will discuss further with the AD if we should take on the work based on these indications.
draft-ietf-mmusic-trickle-ice-01
draft-ivov-mmusic-trickle-ice-sip-02
Emil presented his slides.
trickle-ice
trickle-ice document has not changed since last IETF; authors believe it is ready for WGLC; need people to read/review.
trickle-ice-sip
Document is now a WG document.
Martin: if you get Trickle back, you can remember GRUU.
slide 19-20
This (SDP fragment answer) may need some considerations in Bundle (and rtcp-mux).
Christer: based on if you use bundle, depends what info you put here.
Emil: Normally you have to wait for answer (or media) to determine if you do bundle or not.
Christer: or we could define option / media-feature tags that you support bundle. There are many reason why already in 183 you want to send SDP frag, even without bundle.
Proposal enables taking a regular O/A implementation and add trickle-ice support to it fairly easily.
● Christer: Need to think further about it.
Lennox: Need to consider what information you need here; ice-options, rtcp-mux, etc. Also related to bundle. Related to info OK; that is now full state. Yet another format of PRACK.
Emil: good point; should be mentioned.
Martin Thomson: With trickle-ice, you have to be prepared to not have all candidates for all components anyway. With bundle or rtcp-mux, you can send candidates for which ever line you choose. With bundle/mux you send only one.
Jonathan: (slide 20) how trickle and un-freezing interact. In 5245 after stream #1 component #1, you do stream #1 component #2, and then other streams. If no candidates for #2, can you move to other streams? May be an issue in determining whether you got all the components and can move on in candidate selection or not if you do rtcp-mux.
Emil: maybe need to have rtcp-mux attribute here. Enforces additional communication between ICE/RTP stacks. But maybe need to have it.
Martin: probably safe to do. And note that if you donŐt do, these are consequences. Many implementations put rtcp-mux always. Logic is: Always put RTCP on component 2; when rtcp-mux is present, component 2 equals component 1.
Emil: we agreed that with trickle you go only in order. You can safely move within the list.
Lennox: How does this interact with Partial Offer/Answer
Christer: This starts to affect offer/answer. Need to look more into the whole proposal.
Emil: Not looking for a final answer today; wanted to start the discussion and there is some good feedback.
Lennox: The information in trickle-ice is the information ICE(bis) needs for usage to set.
draft-ivov-dispatch-sdpfrag-03
Original idea was you could put any combination of SDP lines in there.
London feedback was that if both trickle-ice and pof/pan are going to use this, then we should give it some structure (incl. m= lines)
Martin: Propose you can have "m=" as break and/or "mid" as break. If you see both, then "m=" is the break. If you see "mid" first then "m=", it's fault.
Christer: This is offer/answer now. You can't use INFO by semantics for O/A.
● Emil: Nobody is suggesting that either
● Christer: This is more than just trickle-ice
● Emil: Agreed, that is why we are discussing it here in this context.
Lennox: How do you trickle candidates with pof/pan?
Martin: How much is missing (from SDP) here and how much do we need to include? t-lines and such; do they need to be in fragments. Go through the list of SDP items and figure out for each.
Lennox: Do we need sdpfrag usages (e.g for trickle-ice use and pof/pan use currently)?
● Martin: We probably do. Specify what is needed for each. Could be done by simply saying "just include everything needed for ICE", etc.
Kyzivat: Content types aren't scarce resources; why not have two content types?
● Martin: We have now basically separate profiles/usages. Separate content types seems reasonable. Can figure out right parsing and handling.
Adam: Content-Disposition may be another option.
● Martin: That might work too
● Lennox not in favor of that; parsing rules based on disposition seems wacky
Kyzivat: Be careful about overloading content-disposition and content-type. They're orthogonal.
Emil: Maybe go back to the original proposal but with specific content-types.
Adam: Believe it should be "correct SDP with lines removed", so not necessarily just "any order". For example, no t-lines after m-line.
Lennox: There has to be some structure; cannot just remove some m=lines and not others, for example.
Christer: The problem with not having the m= lines is you don't know where the parameters belong to.
Emil: Do we need a common content-type so we don't have to come up with a new every time you have to define a new one.
Lennox: Probably need to include the m= lines always, but they may not carry any useful information in some scenarios beyond identifying a media description. There is some structure in SDP that we will need to preserve.
Emil: Can we agree that we go for common content-type that uses m= lines as a grouping mechanism that requires mid as a way of mapping structures to m=lines (media description). Still have the session level information as needed as well. Have to be defined by usages if allowed by certain messages.
Kyzivat: Not entirely agreeing. You're imposing syntax rules in disposition. Shouldn't do that.
Adam: not really syntax rules. Seems reasonable at a high level based on this conversation.
[Meeting ended]