Scribes: Roni Even, Daniel Burnett
Jabber Relay: Jonathan Lennox
Chairs
Slides: https://www.ietf.org/proceedings/98/slides/slides-98-mmusic-chair-slides-00.pdf
The agenda was proposed to be changed, moving ICE SIP/SDP presentation after bundle, to allow for needed people to arrive in the room.
It was pointed out that the chair slides do not reflect that draft-ietf-mmusic-4572-update has been published as RFC 8122.
The chairs called for reviewers of draft-ietf-mmusic-sdp-simulcast; Cullen Jennings, Roni Even, and Arun Arunachalam volunteered.
Alan Johnston
draft-hutton-mmusic-opportunistic-negotiation-00
There is an opportunistic security draft in SIPBRANDY WG, which is a WG that does not make normative documents. This document in MMUSIC is therefore needed to provide those normative statements.
It was clarified that the reason to negotiate use of AVPF RTP profile using the rtcp-fb SDP attribute is that you don't know if the other side supports it and don't want negotiation to fail, as would be the case when using AVPF directly on the m= line. The offerer wants to use AVPF, but is willing to fall back to AVP.
It was also clarified that AVP is still kept in subsequent offers, for the same reason; to avoid failures.
Why not use opportunistic DTLS as well? You can apply this approach with DTLS, but that doesn't violate any MUSTs in existing specs and does not require text in this draft. It is mentioned in the SIPBRANDY document.
It was stated that a lot of systems and vendors are already doing this, so would be good to get it documented. Several people expressed support.
Hums were taken in favor of and against adoption: there was strong consensus in the room for adoption and nobody opposed.
Chairs will coordinate with ART AD to get a milestone in MMUSIC. Ben Campbell already indicated he is supportive.
Christer Holmberg
draft-ietf-mmusic-sdp-bundle-negotiation-36
Slides: https://www.ietf.org/proceedings/98/slides/slides-98-mmusic-bundle-00.pdf
The discussion focused on the currently identified open issues.
Solution alternatives:
1. Mandate that tagged m-line is for RTP
2. Allow RTP attribute in non-RTP m-lines
It was pointed out that the problem applies in the other direction as well; data-specific SDP attributes associated with an RTP m-line.
It might not always be possible to have the tag on an RTP m-line, for example when starting the session as data channel only.
Option 1 was therefore not considered generic enough.
Option 2 is better in that sense, but also needs to allow for non-RTP attributes on an RTP m-line.
There was some concern with existing implementations in endpoints that both do not understand Bundle and are also not capable to correctly ignore unknown attributes. This is a known risk that we should document, but the alternative seems worse and it was argued that we should take the risk.
Resolution:
• Will do option 2.
• New section in the bundle draft.
• Note the risk for implementers (although the risk seems quite small).
Christer believes we have a resolution now.
There are comments from Eric Rescorla and Taylor Brandstetter. Some of Taylor's comments are non-editorial and requires fundamental changes - Christer pushing back on those.
There is also an issue on the list on RTP header extension IDs when multiplexing extmap, which does not seem to be controversial. The solution does not seem complicated; just don’t use the same ID number for two different, bundled header extensions. Suhas Nandakumar will submit a Pull Request on it, after which people can respond.
Cullen Jennings
Slides: https://www.ietf.org/proceedings/98/slides/slides-98-mmusic-moving-jsep-appendix-b-to-bundle-00.pdf
Minor issue 1: RTCP BYEs
The proposed solution is to delay removal of SSRC from the stack-internal SSRC list as suggested by RFC 3550. No one objected to that approach. Colin Perkins commented that the current text is in some places contradictory to RFC 3550, but was asked to provide more detail on the contradictions. Colin promised to provide comments in one week if a new draft is submitted.
Minor issue 2: PT demux limitation
The proposed solution is to make the limitation more explicit that PT cannot be used to move a given SSRC to a different m-line.
Peter Thatcher pointed out that the PRs for minor issues 1 and 2 have already been merged in the editors' draft of JSEP.
· Copy JSEP appendix B into Bundle by the end of the meeting
· Remove appendix B from JSEP (already done)
· Submit a new version of Bundle with the pull requests merged (this week). Will ask for comments on that.
· Christer will work on editorial comments meanwhile.
· Within some reasonably short period of time (TBD by Christer), Christer will submit an update (with the editorial stuff fixed). We will then have a complete document that should be final and will issue WGLC on that (one last time hopefully).
Suhas Nandakumar
draft-ietf-mmusic-ice-sip-sdp-12
Slides: https://www.ietf.org/proceedings/98/slides/slides-98-mmusic-ice-sip-sdp-open-issues-00.pdf
Issue: How do we handle SDP for non-SIP cases? What about WebRTC?
The proposed alternatives were to either split the draft into two, describing use of ICE SIP and ICE SDP separately, or keep the draft and make it more generic. The conclusion was to keep the draft, but to change the title to something more generic and to add a SIP considerations section.
Issue: ice-bis & ice-sip-sdp drafts obsolete RFC 5245; what is the state of RFC 6544?
This seems to require a reference change in RFC 6544. It was clarified that, in general, we don't try to fix old references in old documents when new versions are published. The decision was that no action is needed.
Issue: ICE-options support vs activation?
It was stated that the draft needs to distinguish between feature support (capability) and feature activation (actual use). This is an old, general issue with SIP headers. Usually, when you include the option in the offer, you indicate support and must (be prepared to) use it. When the answer also includes the option, you use it. The spec must then as part of the registration procedure define what it means to "use it" in terms of procedures, etc.
This approach was agreed and it was decided that the text will specify what “use” means. The option should be listed as specification required in the IANA registry.
Draft next steps:
Handling ice transport change and default candidates – waiting on pull request from Roman Shpount. Roman commented that there are still some open issues that need to be addressed (3 issues). ice-mismatch is another related issue. Christer Holmberg commented that this was discussed and seemingly agreed in Seoul, asking to raise the issues again if there is no longer agreement.
Roman expects to submit the needed PRs by next week some time.
Adam Roach
draft-ietf-mmusic-rid-10
Slides: https://www.ietf.org/proceedings/98/slides/slides-98-mmusic-rtp-payload-format-restrictions-00.pdf
The current text specifies that if the offer does not support a restriction from the answer, it should discard the a=rid line.
Possible approaches:
1. keep as is
2. change – restrictions in offer stands
3. add mechanism to further negotiate
After some discussion, the conclusion was:
· Keep mechanism as-is but add some explanatory/advisory text.
· Mo Zanaty will write a paragraph to address this and give to Adam.
Bernard Aboba
draft-ietf-mmusic-4572-update-13 (Section 6.2)
The draft was published March 17 as RFC 8122.
Section 6.2 says: “…MUST NOT assume that the data transmitted over the TLS connection is valid until it has received a matching fingerprint in an SDP answer”.
Two specific questions are being asked:
1) May data received over the data channel be provided to the application prior to verification?
2) May received media be played out prior to verification?
Bernard's goal here is to get some consensus on the above.
Most comments in the meeting thought that the current text is good, and that the application can buffer the data for a while, if it so desires, until the data is verified. Discarding data seems bad. It was also commented that DTLS handshake cannot complete until the remote fingerprint is received, due to ICE procedures. For WebRTC, it seems no data can be received before remote fingerprint is also received and the problem then doesn’t occur. It is however still possible that this can happen in other contexts.
There was no clear consensus and the discussion will have to continue on the mailing list. Martin Thomson suggested that it is really up to W3C to decide if they want to allow the application access to unverified data or not.
Martin Thomson
draft-thomson-avtcore-sdp-uks-01
Slides: https://www.ietf.org/proceedings/98/slides/slides-98-mmusic-unknown-key-shares-00.pdf
These were the proposed options:
1) Define a=tls-id for TLS/TCP
2) Rename a=dtls-id to a=tls-id
3) Use sess-id from o= line as in -00
The discussion first concluded that option 3 will not work and is therefore not good. There was support for both option 1 and 2, with some preference for option 2.
Conclusion: Go for option 2, rename a=dtls-id to a=tls-id.
There was no formal consensus call, but there seemed to be a clear preference for option 2, which means the just issued RFC 8122 will need to be updated. Martin will discuss further with Christer Holmberg off-line.