Minutes of the Meeting: MMUSIC Working Group at IETF 100
The MMUSIC working group met at IETF #100 in Singapore on Thursday November 16, 2017 from 13:30 to 15:30.
The meeting was chaired by Flemming Andreasen and Ari Keranen (filling in for Bo Burman)
Nils Ohlmeier, Christer Holmberg, and the chairs took notes, and Jonathan Lennox acted as Jabber relay.
The meeting was broadcast live and recorded by the Meetecho team. The recording is available at:
Below is the final agenda with links to the relevant sub-sections below:
Thursday, November 16, 2017 (VIP A), 13:30-15:30 (120 mins)
================================================
13:30-13:40 Introduction and Status Update (10 mins, Chairs)
13:40-14:10 Simulcast and RID - Open Issues (30 mins, Magnus Westerlund)
The chairs presented their slides with the agenda and an update about activities since the last meeting.
Flemming reminded of the importance of document reviews.
No comments on agenda.
Publication was requested for RID draft but will be pulled back shortly. Discussed today.
Trickle ICE moving forward with no issues.
Looking for additional help on SDP-neg draft.
Roni Even: have dependency in CLUE. Can check out if can volunteer.
Christer Holmberg: available after bundle is done
ice-sip-sdp working on one last comment from WGLC.
Christer working on moving bundle forward.
Also looking for help on msrp-usage-data-channel draft.
- Jose Recio later volunteered and will join as co-author
Looking for new authors for data-channel-sdpneg draft.
- Roni Even later volunteered and will join as co-author
Andrew Hutton: 3GPP dependency on the draft. Release -13. A company that cares about this should provide a name.
Christer: same as with the previous draft; after Bundle could help
Opportunistic negotiation some discussion with the authors if it needs to include formall Offer/Answer (O/A) negotiation sections.
Jonathan Lennox: discussion - SIPBRANDY draft the same thing? Should be merged?
Ben Campbell (as AD): SIPBRANDY not chartered for anything normative.
Jonathan: two docs is not helpful. Could take full SIPBRANDY doc here.
Christer: don't care if two docs, problem is that none of the docs contain O/A. The SIP BRANDY doc is informative and refers to this draft but no details here. The MMUSIC draft should have normative O/A.
Ben: history on this; opportunistic security was intended as "you can do this with existing standards". Not as normative "how to do it". Discovered that need profile for this, this draft was supposed to give SRTP details. Now going further specifying details. Don't know what the right solution is but in the process of having AD discussions. If do normative O/A, then comments about separate docs worth thinking about.
Ali Begen: SDP directorate review doc had hundreds of pages. Lots of SDP stuff there.
Flemming reviewed the doc already. No end-to-end review necessarily. Just registration check needed that it's well specified and believe it's possible to come up with interoperable implementation.
Christer: question: there was an email regarding ART reviews. As one of the areas of ART review does that cover SDP?
Ben: haven't talked about moving SDP reviews to ART; no plan that I'm aware of. Could consider things going to ART what went to RAI.
Flemming: Is data-channel-sdpneg dependency?
Roni: noticed that in datatracker a draft mentions it. No depenency mentioned. RFC4566 mentioned. Depends on sdpneg.
Cullen Jennings: area source of confusion. Some docs don't need to be on the list. Once get rest of the docs in the cluster there, will move all that doesn't need to depend on something. May figure out depenceny later. May become non-issue and can sort in RFC editor Queue. If doc has no reason to depend on -bis doc should not use that.
Flemming: specifically on 4566bis?
Cullen: 4566bis is the one problem child
Flemming: data-channel-sdpneg too?
Magnus Westerlund: reference is to 4566-bis. That depends on data-channel-sdpneg.
Cullen: don't find docs depending on data-channel-sdpneg
Roni: mmusic-scpt-sdp shows up as a dependency on the data tracker
Colin Perkins: 4566bis depends on data-channel-sdpneg (registering attributes)
Ali: don't remember why put it there to dependecy, maybe can move to informative reference. Will have to check.
Colin: only reference to data-channel-sdpneg is in IANA registrations. "usage level" reference.
Magnus: don't find where any other webrtc related docs reference 4566bis
Christer: I have been looking into: bigger issue than 4566bis is ICE-bis references (5245bis). Reference 5245 but other drafts reference ICE-bis so they have indirect depencency. Differences between the -bis and 5245 that are substantial and implementors need to be aware of.
Ben: the ADs kind of have a plan for this. The generel idea unlesss the draft has depenency on something new we can figure this out in RFC editor queue.
Colin: we could take this out and just say this updates 4566bis
Flemming: 4566-bis discusses rework in IANA registry
Colin: trivial thing to take out
Magnus presented his slides, which contained the following open issues:
Found a few issues very recently.
1) Handling of related formats in RID and Simulcast
No objections or concerns.
2) How to signal RED
Colin: which one mandating?
Magnus: neither; need PTs in m-line. RID line would have payload types in "RTP header"
Colin: if you only mention the RED PT you can only send that
Magnus: example of other formats that have associated formats that have PTs. Encapsulated in stream.
Colin: can only send RED format but that will specify internally what is sent
Magnus: we need clarification
No disagreement on that. Magnus will propose text on the list.
Christer: are you going to propose the new text?
Magnus: someone from the author team is going to propose new text
3) Use of RepairedRtpStreamId
Jonathan: grammar is terrible. Agree and want to point out that flex is already bundle depencency. But informal reference anyway.
No objections. People in general agreement but bit of wordsmithing required.
4) Dynamic bindings and redundancy
Magnus: Text to be written and sent to the list. Will not do anything to bundle but issue potentially exists there too. Less problem there.
Jonathan: might be problem even with non-bundle if change SSRCs. Something that has been around forever but just noticed it? Having repair flow with different SSRCs and changing the primary.
Magnus: mostly been using binding labels
Colin: payload format has been broken all along. Worked the way people used at the time and no one was interested in fixing this. Known problem. Don't use RTX is the solution.
Magnus: will have documentation of the issue
No objections.
5) Improving SDP examples in Simulcast
May steal examples from rtcweb-sdp. At least one more advanced example coming.
Jonathan: the examples are unchanged from the PT based simulcast approach. Examples should use RIDs and no PTs at all. 3GPP chose what to do before we changed our minds on this.
Magnus: need to modernize examples with full RID support
Christer: you may take the examples, but not point to rtc-sdp-examples as the source of truth
Magnus: yes, just copy-paste relevant parts
Flemming: Agreement with recommendation but per Jonathan's comment modify and add one example.
Magnus: image restrictions and reduncancy
Nils: reviewed RTCWEB examples, good to have in same level or less than SDP examples. Confusing on what was the example doing.
Magnus: need to maybe move simulcast examples up a level for people to understand. Can focus in simulcast on guidance.
Flemming: One of the examples to be advanced to the samel level as we had in RTCWEB examples draft.
6) Use of a=SSRC and a=rid
Roni: OK with removing, but could modify it a bit
Consensus to remove the paragraph.
No need for new text in RID.
7) Use of a=SSRC to pre-bind RID value
Jonathan: whole thing that we went through few months ago with reference to bundle
Colin: where get SSRC clue?
Magnus: previous signaling exchange, used for binding to RID. If use SSRC should have this.
Colin: may still have collisions; nothing breaks badly when signaling is racing?
Magnus: media can work during the collision
Jonathan: if MID is broken it's a bigger deal. It's exactly the same mechanism, just one level down.
Cullen: not sure if following problem; not hitting where the problem is
Magnus: feature parity for signaling capabilities. Have mechanism for all cases but don't get RID binding
Cullen: who would use and when?
Mo: where this came from: originally besides having symmetry there. Chrome currently signals simulcast by signaling multiple SSRCs. Providing that RID binding seemed like a natural solution to move them to unified plan. So it seemed like the natural way from handcoded values to proper signaling. Adam Roach [not present in meeting] questioned why can't go directly to simulcast lines. The simulcast lines tells you that there are two different resolutions. Could prime decoder pipelines with the information. But not enough motivation for new spec for the interim spec.
Mo: they put number of SSRC lines as number of simulcast lines. Different SSRC line is different simulcast line.
Jonathan: not so much of what Chrome is doing/could do, rather than translate Chrome's dialect to standard format. If Chrome is not speaking RID, it needs SSRCs to do anything useful. For bundle don't need to set SSRC, rely on header extension. For compatibility for old system? Might be same motivation for RID as well. Not using header extension bits.
Magnus: priming the whole decoder thing is possible, you only need to tell them the SSRCs, but we have a RID...
Jonathan: append the bits to header section... (?)
Mo: one more potential use case that not discussed with Adam; MID not sent on wire in RTP but signaled. Can do same with RIDs on binding and never send them on wire. Middlebox on wire could actually signal MIDs and RIDs and even manipulate even if not on RTP path. Not sure if want something like that. Could cause more issues. Indication to need RID - MID bindings.
Nils: firefox sends MIDs, RID stuff is in latest Chrome
Magnus: people moving to specified solution
Nils: whole mess should be hopefully over soon
Magnus: anyone thinks we should do this? So far neutral to negative
Jonathan: my suggestion, architecturally cleaner to have it, but not going to fuss about it
Magnus: can always specify new source specific parameters later. Separate doc later could fix this if we see more need for this. It's rough, but rough consesnsu seems to be not to do this.
Flemming: seems group not motivated to do this
Rough consensus: don't allow the a=ssrc pre-binding RID values
Next steps
Ben: the answer to need for targeted calls depends on chair assessment if everyone understands the proposed changes.
Chairs: Anything else ?
Roni: volunteers for the data-channel-sdpneg draft.
Roni will be new co-author on data-channel-sdpneg.
Jose Recio (jose.recio@cosmosoftware.io) volunteered for the msrp-usage-data-channel draft. Jose will be new co-author on that draft.