Wednesday 1-Aug @ 9:00am - MMUSIC

Note takers: Paul Kyzivat, Christer Holmberg, Brian Rosen

Jabber Scribe: Jonathan Lennox

Intro & Status Update – Chairs: Miguel Garcia & Flemming Andreasen

Chairs noted that we (again) have more drafts to be discussed than we have meeting time allotted.

Gonzalo (as AD) noted that several drafts have only been allocated only 5 minutes on the agenda, which is generally not the most productive use of meeting time. However, there is generally not a lot of discussion and feedback on the mailing list and hence people feel they need to bring even small topics up at the meeting. Gonzalo encouraged people to pay attention to new drafts and issues on the list and discuss them there so we don’t need to waste meeting time introducing drafts and discuss minor issues.

draft-ietf-mmusic-sdp-bundle-negotiation-00.txt – Christer Holmberg

Discussed issues.

ICE Peer Reflexive Candidates issue [Alice supports bundle, Bob does not, Alice sends offer with identical address:port in each m-line, Bob answers with different address:port for each m-line]: Cullen said the proposal would work for the specific issue, but there is a bigger problem. He says putting the same port in each m-line in the offer isn’t working for some implementations (compatibility issue with deployed implementations), so its going to be necessary to supply a different port in each m-line. Then if far side supports bundle then you use only one of the ports. Christer says that then won’t work if intermediaries don’t support bundle. He and Cullen disagreed about failure modes for intermediaries.

Harald said we have previously discussed same port vs. different port and wg gave guidance to use same port. Now that seems wrong. He doesn’t want to have the same discussion again. Cullen said attempts to implement show that this doesn’t work. Harald asked for actual results backing up that claim. Bernard said (Microsoft) they shipped a version of their product that does this and it broke a lot of things. Some vendors are rejecting the offer because of bad SDP. Jonathan Lennox noted that another issue with answerer not supporting bundle is that you will potentially get “audio” sent back to a “video” stream, however that’s a general issue with bundle you can’t get around. Christer concluded we need to continue discussions of this on the list.

RTCP-MUX issue [Alice includes a=rtcp-mux and a-rtcp with RTP port value, Bob does not support a=rtcp-mux and creates separate ports for RTP and RTCP]: Justin said this isn’t really an issue. There is already enough encoded (component id) to decipher which is for RTP and RTCP. Cullen had issues with this – disagrees with assumption that can use a=rtcp with a port the same as the RTP port (similar issue as above). Christer asked what you should use for a=rtcp if you support rtcp-mux. Colin Perkins said that RFC 5761 doesn’t clearly state one way or the other, but it assumes different ports – we may want to clarify RFC 5761. Hadriel said they have done some testing of this and not run into problems yet. Christer said there is clearly a problem and need to continue discussion on list.

SDP Restrictions issue [Which information must be identical in bundled m-lines]:
a) Identical information between different media descriptions
Cullen wanted Eric Rescorla (not present) to weigh in – Cullen speculates there may be security attributes which get different results. Worried about two-time pad issue. Magnus noted it shouldn’t be an issue since they will use different SSRC values. Jonathan Lennox had another issue about keying if it turns out the answerer doesn’t support bundle and you use the same keying material for them; need to ensure use of different SSRCs again for the two streams. Cullen doesn’t see an advantage to keeping the keying material the same in all the m-lines. Christer expressed concern that we can’t rely on intermediaries that don’t support bundle either passing on bundle or removing it. Hadriel said you can’t rely on much from the intermediaries that don’t support bundle.

b) Non-identical information between different media descriptions

Re info that may be different in the bundled m-lines: some comment on direction attributes. Cullen said its essential that they can be different. Roni said the list of these attributes may not be complete. Christer said those in slides are just examples. Jonathan said that there will need to be an exhaustive classification of which SDP attributes fall in which category. Christer said that we will need to make a rule that every attribute defined in the future includes a description of bundle behavior.

Bandwidth: Charles Eckel said we also need to consider RS and RR.

Payl Kyzivat stated we will need some testing to determine the proper way forward since a lot of the concerns derive from how existing implementations will behave with the new mechanism (backwards compatibility).

Chair Flemming asked for interest in forming a mini design team since we seem to be discussing a lot of the same issues again. Christer agreed and noted we should involve people from AVTCORE.

Christer has an action item to organize some people and have some calls.

draft-alvestrand-rtcweb-msid-02.txt – Harald Alvestrand

Harald asked for guidance on how to proceed.

Cullen is in favor of the abstract problem being addressed, however he Would like to see some clarification around the problem to be solved. Cullen is not sure he and Harald agree on exactly the problem that needs to be solved. But he doesn’t like the existing text – it still has too much Axx (audio) and Vxx (video) stuff, and so is confusing. Cullen specifically asked why appdata is needed – would like that clarified in the draft (a general issue around more clearly motivating the solution).

Action item was for Harald to work with Cullen and others and publish a new version (and to target it to MMUSIC).

draft-capelastegui-mmusic-3dv-sdp-00.txt - Pedro Capelastegui

Note: Pedro presented his draft remotely

This is in some ways an alternative to the Greevenbosch drafts.

Christer asked if this indicates willingness to receive or what you are going to send? Audio issues in the room made it difficult to hear the response and Christer will post it to the list instead.

Roni said he thought this was indication of what to send. He also said he thinks one of these m-lines is not describing a real stream – it is just a fake to carry separate attributes. Pedro responded there is one specific case where they saw a need, and thought m-line would be a good way of doing it.

draft-greevenbosch-mmusic-sdp-3d-format-00.txt - Bert Greevenbosch

draft-greevenbosch-mmusic-sdp-parallax-00.txt - Bert Greevenbosch

Bert presented the two drafts and noted IPR on them.

There were no comments on the presentation of these two drafts.

Way forward with SDP 3D & Parallax - Chairs

Call for comments from floor didn’t get any takers.

Chairs asked for show of interest in working on this subject – 3d formats in SDP.

Roni expressed interest in working on this problem space (3D). Stephen Wenger said both drafts are a bad idea, because they both assume tying together two streams. While these are currently deployed techniques they are bad legacy techniques. He thinks we should rely on newer technology. Bert did not agree with this assessment and noted use with HDMI as an example.

Kevin Gross indicated he won’t have time to work on this.

Roni responded to Stephan. He said these are the techniques we have, so we need a way to negotiate them.

Chairs say they don’t see clear direction. They aren’t ready to make a decision on this. Further discussion may continue on the mailing list. Encouraged authors to try to generate interest on the list. Bert said it has been on the list and there have been interested people on the list. But those comments have already been addressed in the current drafts.

draft-begen-mmusic-redundancy-grouping-03.txt – Ali Begen

draft-begen-mmusic-temporal-interleaving-04.txt – Ali Begen

These drafts are complementary to work going on in AVTEXT. There is a normative dependency.

A few people indicated they have read these drafts.

Took a hum for interest in working on. There was a bit of interest. Jonathan noted that if there is a dependency in AVTEXT, then we should. Roni agreed.

Keith commented that the work was adopted by AVTCORE and then handed off to AVTEXT. He also said this should be a request for how to proceed – another possibility would be to let AVTEXT do this.

Jonathan commented that the SDP directorate was created for cases like this, so we should consider that.

Kevin Gross indicated he is willing to work on it.

Charles Eckel suggested the work be done in MMUSIC.

Chairs indicates that they would prefer this work be done in MMUSIC.

Magnus says its up to the chairs to decide if this should be in MMUSIC.

Chairs will talk to ADs about adding milestones for these and (subject to mailing list consensus) adopt the documents as WG items.

draft-ietf-mmusic-traffic-class-for-sdp-01.txt – James Polk

James raised issue with private attributes – similar to X- (RFC 6648) which has been forbidden for cause.

Dan Wing noted that the underscore feels like the “x-“ that we have problems with (per RFC 6648). See the need for defining new categories. Point is we have things that don’t fit the current categories defined, and need to accommodate that. Dan wants to ensure that things that aren’t SDP signaled can still be accommodated.

Cullen also doesn’t want private attributes, but is willing to lower bar to “specification required” to register, in order to avoid the issue with potentially standardizing such attributes later and having to change their name (backwards compatibility issue with deployed implementations).

draft-ivov-mmusic-latching-00.txt- Emil Ivov

Simple request to WG if interested in adopting. Chairs think it would be good to have this document to refer to. Chairs asked for people interested in reviewing it.

Christer asked if it will be possible for it to discuss multiple ways of doing this. Cullen commented that Cisco may have IPR on this, but having something that describes current practice and the limitations with that is of value.

Chairs asking if anybody opposes to document being adopted and adding a milestone. No objections.

Chairs will talk to ADs about adding a milestone for this and (subject to mailing list consensus) adopt the documents as WG item.

draft-muthu-mmusic-offer-answer-g723-g729-00.txt - Parthasarathi Ravindran

Hadriel had clarifying questions on the proposed solution.

Christer asked why this isn’t addressed by change to the document that defined this payload (RFC 4856), to include the o/a considerations. IOW do a bis of that document. Cullen said this should either be an update or a bis to the original doc – it should not be a BCP.

Jonathan agreed with doing a bis. Roni said that when discussed in PAYLOAD WG (with many of same people) they suggested bringing it to MMUSIC and doing as BCP. Robert said BCP is almost certainly wrong.

Chairs noted that nobody disagrees there is an issue. Chairs will discuss with PAYLOAD WG chairs and ADs about what the proper process should be for resolving and documenting it.

draft-zhou-mmusic-sdes-keymod-01.txt – Sujing Zhou

Back now because didn’t get enough presentation time and feedback in Paris.

Issue is key exposure problem of security descriptions (RFC 4568) in forking and re-targeting scenarios.

Cullen says primary alternative is DTLS/SRTP but all the DTLS people are in a different WG right now.

Hadriel asked if there is IPR on this solution. Speaker isn’t aware of any. Hadriel says this was discussed several years ago. He is interested in a solution, but not necessarily this solution. But he isn’t confident that whatever was done would be adopted. He also noted that this would break certain forms of lawful intercept.

Bernard Aboba is also concerned that this won’t be widely implemented. But there should be a discussion about the utility of doing this work.

Brian said everyone is doing SDES and not DTLS/SRTP.

Cullen says that Cisco supports DTLS/SRTP in its products.

Chairs ask to have a discussion on the list about this to ensure we get feedback from the DTLS/SRTP people as well.

draft-wing-mmusic-ice-mobility-01.txt – Tiru Reddy

Jonathan questions what the problem is with ICE restart. Is ICE restart to slow to handle mobility ? What kind of signaling delay is acceptable ? No clear answer provided in the meeting.

Markus Isomaki indicated support for this draft. He thinks it should save some round trips.

Jonathan says there are cases where this will fail but ICE restart will succeed. So he wants to know if there are enough cases where this will succeed to be worth the trouble.

Hadriel said if you are trying to avoid a SIP UPDATE, then don’t – you have to send it anyway. It’s basically an optimization where you get an interim interval where you can still send media (prior to the restart).

Richard Ejzak commented on need to reestablish signaling association. Should mention that too.

Chair encourages continuing work, with possibility to consider for adoption at next meeting. Clarify the problem you are trying to solve, put it into context, and compare with ICE restart.

draft-keranen-mmusic-ice-address-selection-01.txt – Ari Keranen

No time to discuss this. Discussion deferred to the mailing list.