Minutes of the Meeting: MMUSIC Working Group at IETF 102
The MMUSIC working group met at IETF #102 in Montreal on Thursday July 19, 2018 from 13:30 to 15:30.
The meeting was chaired by Flemming Andreasen and Bo Burman
Roni
Even and the chairs took notes, and Jonathan Lennox acted as Jabber relay.
The meeting was only partially broadcast live and recorded by the Meetecho team due to a power outage. The recording is available at:
● https://play.conf.meetecho.com/Playout/?session=IETF102-MMUSIC-20180719-1330
Below is the final agenda with links to the relevant sub-sections below:
Thursday,
July 19, 2018 (Saint-Paul/Sainte-Catherine), 13:30-15:30 (120 mins)
====================================================================
13:30-13:45
Introduction and Status Update (15 mins, Chairs)
13:45-14:15 Offer/Answer Considerations for SDP Extensions
(30 mins, Christer Holmberg)
14:15-14:45 ice-sip-sdp and DNS/mDNS Host Names
(30 mins, Youenn Fablet)
The
chairs presented their slides with the agenda and an update about activities
since the last meeting.
Bo reminded of the importance of document reviews.
No comments on the agenda.
Note well statement:
● Jonathan Lennox asked if it is the latest one. Chairs will double-check.
Comments related to specific documents
sdpneg: Do we need another WGLC ?
● Roni (author) – no technical changes lately. Up to the chairs whether we should do another WGLC on the document
● Bo (chair): Does anybody want another WGLC – if not, proceed with regular publication procedure.
4566bis:
● Paul Kyzivat (author): Done as far as Paul knows. Just looking for comments in case anybody want to review it. Made some syntax changes as part of this – people should look carefully at it and ensure there is no compatibility issue.
● Colin Perkins: Don’t think the time zone syntax changes will be an issue since nobody has been using it. Should consider sending a liason statement to 3GPP and make them aware we have updated the document (incl. some syntax changes) – don’t believe those syntax changes affect what 3GPP is using, but just in case.
● Bo: Should be able to go for publication request at this point (after sending liasion statement to 3GPP)
msrp-usage-data-channel:
● Chairs propose to drop milestone due to lack of interest
● Ben Campbell (AD): Make sure to announce on mailing list.
uks draft:
● Draft needs reviewers
● Adam Roach will review (when he has time – no specific date).
Christer presented his slides (no separate draft currently)
New SDP attribute requires offer answer procedure based on RFC3264
Issue: Unclear what "initial offer" means; it may be later in the session and not the first offer within the session. It may also be added later when a new m-line is offered.
Need to separate between two cases:
Solution options:
Christer suggests option 2
Discussion
Ben (Individual)
● How many more SDP extensions do we expect
● Prefer the second approach.
● We probably want to write it down if we want to do that, but is it really worth the effort ?
● The first alternative is ok as well, especially if we just change the name of the “initial offer” section to something that captures that it is the first time we use the extension.
[Power went out in the conference room]
Lennox: Either alternative works. Can always just refer people to these slides.
Cullen Jennings: Think it is valuable to have a list of things that people writing SDP extensions should cover.
● Lennox: Do we need an RFC for that ?
● Christer: We should document it (standalone document or part of another document). Prefer standalone document.
● Cullen: Probably can’t be a normative document. Informative
Colin Perkins: Don’t make it BCP or something like that. Informative.
Roni: RTP how-to RFC is a good example of what to do.
Flemming (as chair): Asking AD if IESG has a strong position on this or not ?
● Ben (as AD): IESG is looking for clarity in what is written – the actual structure is less important.
Conclusion: Christer to write an Informational draft based on option 2
Youenn presented his slides related to draft-ietf-mmusic-sip-sdp-21
ice-sip-sdp already supports DNS names – just need to extend it to support mDNS name resolution. Youenn and Justin Uberti proposed a small change to Section 4.1 of ice-sip-sdp to accommodate that.
Discussion
Christer: Ok with this, but need another change beyond what was shown on slide 5. If lookup fails, you need to discard the candidate (this was mentioned in rtcweb)
Cullen: Any issue with making sure both sides support it (or only one side does) ? Probably need to know whether both sides support it to make sure we get the the timing of the connectivity checks right. Not sure – asking the question.
● Lennox: Not sure either – how do we deal with DNS resolution failures in general from a timing perspective ?
● Christer: How does the other side figure out the (m)DNS resolution failed ?
● Justin: The browser will learn the private IP-address, because it has to do the lookup anyway (which is OK), however the JS will not. To Cullen’s point: Don’t know if IPv6 works for other side either, but still try it. The mDNS resolution failure is not any different.
[Various discussion comments from Harald, Christer, Cullen, Lennox]
Lennox: May need more document changes than indicated here.
Niels Ohlmeier: Thought that the use case was to not reveal IP-address in case you do not get connected. Once you get connected, you will know the IP-address.
[More discussion getting into potential technical issues]
Lennox: Concerned about this saying RFC6762 procedures. Which IP-address you send to depends on which IP-address you send from.
● Justin: Isn’t this a problem with DNS candidates already ?
● Lennox: Yes. Problem is DNS name may return multiple IP-addresses.
Justin: Agree that the text on RFC6762 needs some clarification.
● Justin asking what text changes people want to see (wrt the green parts of slide 5).
Cullen: Need to discuss backward compatibility.Non-browsers that are not RTCWeb don’t do this today. When do you put in DNS names, when do you not, etc. Need some guidelines for non-RTCWeb use cases as well.
Niels Ohlmeier: Support mDNS for the initial session. How does everything align when you keep using the mDNS names in subsequent offers and answers ? Seem to need more considerations. Peer reflexive is one of them.
● Justin: Agree.
● Cullen: Would like to have a little bit of warning text.
Lennox: Need to look at updates to FQDN rules in 5245bis and make sure we adequately support and understand them in ice-sip-sdp
Justin: IP-handling document is a separate document (in rtcweb) – here we are just talking about what we can put in the ice-sip-sdp.
Cullen: Need to look into whether this can cause a DDOS attack (generate a lot of multi-cast traffic).Using mDNS in ICE has some interesting issues overall and they need to be looked at.
Lennox: How does mDNS affect timing. in which document.
Bernard Adoba: Note that it is a link local address. May cause connectivity problems in ICE.
[More discussion]
At this point, the chairs asked for a concensus call on the following:
● mDNS as well as DNS procedures require more consideration overall. Remove DNS procedures (incl mDNS) from ice-sip-sdp. A separate document can (and probably will) be written to deal with that. Will probably cover both DNS and mDNS in general. Chairs to discuss with ADs and ICE chairs where that work will be done (MMUSIC or ICE) once we see the document.
Conclusion: The WG agreed with the above and hence that will be the path forward.