IETF-94 mmusic minutes
Session 2015-11-02 0900-1130: Room 304 - mmusic chatroom
The MMUSIC working group met at IETF #94 in Yokohama, Japan on Monday November 2, 2015 from 09:00 to 11:30.
The meeting was chaired by Flemming Andreasen and Bo Burman.
Stephan Wenger, Roni Even, 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 of the session is available at the following URL:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF94_MMUSIC&chapter=chapter_1
Below is the final agenda with links to the relevant sub-sections:
09:00-09:15 Introduction and Status Update (Chairs)(15 mins)
09:15-09:55 Using the SDP Offer/Answer Mechanism for DTLS (Christer Holmberg) (40 mins)
09:55-10:25 Negotiating Media Multiplexing Using the Session Description Protocol (Christer Holmberg)(30 mins)
10:25-10:55 RTP Payload Format Constraints (Adam Roach)(30 mins)
10:55-11:25 Using Simulcast in SDP and RTP Sessions (Mo Zanaty)(25 mins)
11:25-11:30 Multi-view streams in SDP and RTP Sessions (Rachel Huang) (5 mins)
The chairs presented their slides with an update about activities since the last meeting.
Christer presented his slides.
It was clarified that the answerer can say “new” if the offer says “new”. There was some discussion around what conditions that require a new connection, and where not offering a new DTLS connection should be considered an error. A list of such conditions should be included in the draft.
Christer will let chairs and WG know when the document is ready for WGLC, probably within a month, after a few more updates and discussions.
draft-ietf-mmusic-sdp-bundle-negotiation-23
Christer presented his slides.
The presentation pointed out that there is an issue in the draft around what RTCP port should be used for any RTP stream associated with the BUNDLE group.
Christer presented two proposed options for the WG to discuss around and decide on (repeated here for convenience):
1. When BUNDLE has been negotiated, endpoints MUST use RTCP-MUX (MUST include SDP rtcp-mux attribute in offers/answers). Endpoints still need to support non-MUX, in case the other endpoint does not support BUNDLE nor RTCP-MUX.
2. When RTP is offered, the offerer MUST offer at least one RTP m-line that is not bundle-only. Answerer MUST select an RTP m-line for the offerer selected BUNDLE address (or reject all RTP m-lines).
Christer asked the WG to choose, and suggested to go for option 1.
Cullen Jennings argued that gateways connecting to SIP cannot do this, and that it will break existing deployments:
· B2BUA does not know what the far-end supports.
· If the gateway does not terminate RTP, it is very difficult to make this work.
· Today, it relies on being able to predict what the far-end can do. If we take that away, it will break.
· Option 2 will fix this.
Several people (EKR, Jonathan Lennox, Martin Thomson) were OK with option 2, but some (Paul Kyzivat, Martin) pointed out that it does not always work and will limit what we can do. EKR said that the second half of option 2 is not simple.
EKR argued to use both 1 and 2. Both EKR and Martin wanted to require rtcp-mux with BUNDLE.
Paul K wanted more details on the proposal (both offer and answer side), and said that the rule for option 2 seems wrong. It should only talk about what the answerer does: if it accepts any RTP m-line it must accept at least one non-bundle-only m-line.
Martin summarized the two options: Option 1 essentially says that if you do BUNDLE, you need to do rtcp-mux. Option 2 effectively says, if you do BUNDLE, and you don’t rtcp-mux, don’t mess it up, and here is how to ensure that.
Adam Roach asked if there are actual implementations for which this is an issue?
Cullen: Yes; there are major deployments today that would break with option 1. Some people implemented a version of the draft, deployed it, and this update will break that.
Peter Thatcher: Non-mux for RTCP is less than 1% in what Google sees today with WebRTC.
EKR: Is Google or RTCWEB going to non-mux?
Peter: In Prague (IETF 93; editor’s note), a lot of RTCWEB people were in favor of removing non-mux RTCP, so I looked further into it. Would like to remove support for it eventually.
Cullen and Ted Hardie (RTCWEB chairs): There was no consensus call in RTCWEB around mandating rtcp-mux, only conversations.
Roni Even: BUNDLE is for CLUE as well, not just RTCWEB. Perhaps move issue to those WGs?
Colin: RTCWEB usage draft says today that you must support mux and non-mux. Haven’t seen a consensus call to change that anywhere.
Ted (RTCWEB chair): Will have RTCWEB agenda bashing and if we get a question for the group, we’ll try to accommodate that.
Three sets of consensus hums were made:
1. Does the WG want to close this topic here today, or continue discussing? There was strong consensus in the room to close today, silence to continue the discussion.
2. Does the WG prefer option 1, or option 2? The outcome showed some preference for option 1, but no clear consensus.
3. Hum if you cannot live with 1; silence.
Conclusion: Consensus for option 1; require rtcp-mux with BUNDLE.
Adam presented his slides. It was clarified that “RID” stands for “Restriction ID”, but the acronym can still be changed. It was also clarified that RID can be used outside of simulcast, but no other use cases are currently defined.
Roni: We can do this today already for H.264.
Adam: This is codec agnostic and does not require additional payload types.
Stephan Wenger: Agree with the overall idea, but not the parameters defined. Video experience shows you should not specify these as part of negotiation. Dealing with payload type exhaustion via another mux-point seems reasonable. The parameters here are however too simplistic (width, height, etc).
Cullen: Don’t believe that is what we are saying. We are trying to convey information about the display we are using.
Stephan: I think you are aiming for a different problem; low, medium, high resolution for example, and fixed values to try and express those are just plain wrong.
Adam: Please send text if you have a proposal.
Roni: You have tied this to simulcast, however with simulcast you want to describe what you are actually sending.
Open Issue 1: Do we want to define declarative use of RID?
“Declarative” was clarified: “This is what I’m making available”. Session Announcement Protocol (SAP) is the classic use case.
Adam was leaning towards no, but thinks we probably do need to support it.
Colin: I think we may be confusing some of this with "mid" and stream IDs. It seems we are mixing how to identify a payload format/stream with how we constrain its parameters. You seem to be using this to identify stream rather than encodings of streams?
Adam: Will follow up with Colin offline.
Open Issues 2 and 3 in the presentation were skipped due to lack of time.
Background: Negotiating Supported Parameters
Note: Slide 9 and 10 in the presentation are in wrong order.
Roni: With H.264, receiver must support any resolution it gets, so not sure this makes sense.
Adam: If you can’t negotiate something in common, then it fails.
Proposed enhancement 1: Soft Constraints was skipped due to lack of time.
Proposed enhancement 2: Asymmetric Handling
Cullen and Martin are fine with the proposal.
draft-ietf-mmusic-sdp-simulcast-03
Mo presented his slides.
Roni commented during slide 5 that the shown SDP is not the full offer, lacking the a=imageattr attribute, which is an important omission since it covers some of the parameters targeted here.
Christer Holmberg asked for clarification around the use of payload type numbers in terms of offer/answer direction. Mo answered that the draft may not be entirely correct. The SDP rules will stand as they do today and support different payload type numbers for the offer and answer, and you will then have to figure out how they correspond to each other.
Roni wanted information about what is really being sent, as opposed to just specifying max parameters. The a=imageattr provides this information and is missing here. Colin did not have a particular opinion, except to note that we need to specify how this interacts with the image attribute (and other things).
Action: Clarify and detail text in draft, even though overall intent is clear. The needed text may belong in the RID draft instead of in this simulcast draft.
Flemming (chair) asked to continue the details of this discussion on the list.
The open issue in the presentation whether to have RTP payload type (PT) or RID identification as mandatory was discussed. Mo proposed to use option 3, RID always required to avoid running into PT limitations. This means that if you support simulcast, you must also support RID. There were several people expressing support for this. Cullen noted that would solve an audio clipping issue. Roni wanted to see an example SDP in the document. Mo asked if anybody were against option 3.
A consensus hum was taken and there was strong consensus in favor of option 3.
draft-huang-mmusic-multiview-00
Rachel had prepared slides, but there was unfortunately no time for this agenda point. The chairs encouraged interested parties to discuss this on the mailing list.