MMUSIC IETF 87 minutes

IESG review of SDP-CS draft resulted in correlation mechanisms being mandatory and that is problematic for 3GPP.
Gonzalo: Status is the draft defines 3 correlation mechanisms; IESG decided they should all be mandatory. Discussion on the list but apparently people didn’t have time to catch up. Subsequently, some people had concerns with that.
Gonzalo: Will probably pull out of RFC editor queue and find a way forward (maybe do another IETF Last Call). Will report what to do.

RFC 2326bis: GEN-ART review comments that would benefit from WG input.

Publication has been requested for delayed-duplication and duplication-grouping drafts.

Middleboxes draft:

The chairs noted that there has been very little interest in working on the draft, and that the WG needs to make a decision on whether to continue the work:

The draft was originally WGLC’d in 2009
Limited interest and updates since then
Subsequent questions on scope and technical concerns have been raised (e.g., references to MIDCOM architecture)

The Chairs asked about the WG’s interest to continue working on the draft:

6 people in the room indicated they have read the draft in the last 2 years
Nobody in the room indicated interest in it
Nobody in the room indicated willingness to contribute to it

Decision: Based on the above feedback, the chairs called that the middleboxes draft milestone will be removed in accordance with what has previously been noted on the list. The authors are free to pursue the document as an individual effort outside the WG. There were no objections to this.

The “SDP negotiation for DataChannel Sub-protocols” draft authors have asked people to review SDP extension aspects of the draft. Comments should be directed to the DISPATCH list at this point.

3GPP Liaison Request on missing SDP attributes for RTSP

Cullen Jennings asked for clarification on why we would register etag and not mtag?
Answer is because it applies to RTSP 1.0 (RFC 2326). Registration would be for RFC 2326 only.

RTP Payload Types Registry

MMUSIC list discussion suggesting the “Reference” section should include “[RFC5761]”:

Roni Even (AVTCORE co-chair): Another problem is that the registry has been closed so need to see what is the procedure.
Flemming: And the discussion should continue in the AVTCORE
Roni Even: Agreed

Decision: AVTCORE will handle this as it is an RTP issue.

Mobility Using ICE (MICE) (Tirumaleswar Reddy)

draft-wing-mmusic-ice-mobility-04

Compared to ICE restart, MICE avoids new TLS handshake, round trips for candidate discovery, and SIP server Offer/Answer. Trickle ICE needs support from both endpoints (MICE does not).

Emil Ivov:

Bullet is kind of misleading; agree that trickle ICE alone wouldn't work that well for mobility, however it would make a lot of sense for MICE to explain how it would work a lot better with trickle ICE.
Tiru agrees and will update accordingly in the next version.

Chairs asking:

People read the latest version: 8 people.
Anybody still having concerns with ICE restart: Nobody.

Cullen Jennings:

Still think there are some interaction issues but too busy with other stuff right now to engage.
Unidentified also said he was too busy right now.

Chairs:

Working group has a lot of work going on right now. Taking hum on WG adoption of the work at this point in time. Very weak support. Chairs calling not enough support at this time.

Happy Eyeballs (Tirumaleswar Reddy)

draft-reddy-mmusic-ice-happy-eyeballs-01

Multihomed host has many IPv6 addresses which should have high priority (based on RFC 5245) which results in delay with broken IPv6. Proposing algorithm to promote candidates from the less preferred IP-address family to be tested earlier.

New ICE-option has been introduced that indicates how to promote candidates.

Cullen Jennings

Both endpoints have to do it in the same order for this to work (was raised last time).
Does not believe current draft addresses the fact what happens if only one endpoints supports this.

Tiru: This algorithm only kicks in if both endpoints support it

Jonathan Lennox:

Why isn't changing the candidate priorities order sufficient?
Tiru: Thought about that but problem is that policy table on each host may be quite different. Will send examples showing the issue.
Lennox: Signaling precedence values should solve that.

Jonathan Lennox: Confusion with attribute versus ice-option.

Martin Thomson: Looking at RFC 5245, don't see any reason to need extra signaling. IPv6 preference is only recommendation.

Bernard Adoba: moving things with changing priorities works fine; have been doing it for years

Jonathan Lennox: recommendation of 5245 should be able to be changed in backward compatible way.

Flemming: seem to be going through the same discussion as last meeting. Is it just clarification to 5245bis or do we need stand-alone spec?

Tiru: Think we need more than just clarification, can show example on the list.

Justin Uberti:

Still think 5245bis should be updated to be more clear on how candidates should be prioritized; IPv6 prioritized higher even if we know it doesn’t work

Tiru: simply changing candidate priorities is not enough; need to adjust the candidate pair list.

Ari:

Isn’t it sufficient if both endpoints do the same (new) prioritization?
Need more clarification and examples. Tiru to send to the list.

Martin Thomson:

Good point that the RFC 5245 algorithm doesn’t allow pushing server reflexive pairs above host-only pairs. Type preference overrides individual preferences. Justification to do something for this.

Conclusion: General agreement that clarifications and more discussion are needed for 5245bis. Authors believe that we need more than just clarification of existing ICE procedures. Authors will send mail to the list to initiate discussion.

Negotiating Human Language (Randall Gellens)

draft-gellens-mmusic-negotiating-human-language-01

Want to enable matching capabilities and language preferences of a user that is making a call with the capabilities of the called party to use those languages and medium. Particularly useful e.g., with emergency calls, where there is no context between the caller and callee. SDP stream attribute with language tags.

Open issues: how much need for language preferences? Is SDP right choice? Complexity vs. completeness.

Randall noted that the issue of whether to use SDP for this or not has been re-opened.

Henning Schulzrinne:

Reopened the SDP debate.
Always a tension between the signaling and media part. Original idea was that call routing would be done by signaling (e.g. SIP), whereas media parameters would be handled by SDP. If media parameters were to influence routing, we then had caller preferences developed for SIP (i.e. a signaling level solution). And this seems like preference since you don’t want the call to fail if the preferences are not met.
SDP is more of "sorry, I can't speak your codec".
Agree it's a per-media issue, but except for a few border cases, you don't really have different languages for different streams.
Henning's proposal would be to see if we can make caller preferences work for this instead. If that doesn't work, then let's look at other options. The fact that we have SIP indications in here suggests that we are on the wrong track.

Randall response:

Looked at caller preferences originally.
The call doesn’t necessarily fail as how the draft is currently written

Henning responding we are fundamentally breaking the SDP model with this.

Randall:

Not fixed on particular way on doing this. If other people are convinced some other way is good, we should do that.

Christer Holmberg:

Caller preferences seem to be the right way.
RFC 3840 provides this capability. If that’s not sufficient, we can define new media feature tags.
If you want the call to fail in case receiver doesn’t speak language, should use option tag with require header

Bernard Adoba:

SIP stuff needs to be more than a hint.

Cullen:

As DISPATCH co-chair, it seems like we should bring up the two different architectural ways to deal with the problem to DISPATCH and then take it from there to the right WG

Keith Drage:

There are some 3GPP requirements for this and use cases floating around (not communicated formally).
Think there are more cases than we are alluding to. Sign language is one of them.

Jonathan Lennox:

When you looked at caller preferences, what were the problems you encountered? If it’s just about prettiness or technical issues?

Randall: No decisions were made on prettiness.

Conclusion: Discussion to continue in DISPATCH.

Trickle ICE (Emil Ivov)

draft-ivov-mmusic-trickle-ice-01

draft-ivov-mmusic-trickle-ice-sip-00

Main open issue: How do we handle candidate unfreezing

There is currently a failure scenario that can be resolved in two different ways.

1) We forget about freezing

Slim (?) chance of timeouts if STUN & signaling lag

2) We preserve component order; e.g., don’t send RTP candidates before we have the RTCP candidates

May slow delay ICE processing a bit in some cases.

Emil asking for any preference opinion

Jonathan Lennox:

3rd possibility; vanilla ICE arbitrarily assigns an order to candidates with the same foundation across components. I think it would work if we kept that high level algorithm but changed what we mean by "first", based on trickled first (first one you hear is the highest priority one)

Eric Rescorla:

The order of discovery may not be what you think. Host candidates come in first. TURN candidates come in later. Attempting to think about sequencing does not make sense.
Not suggesting a solution; just exploring the problem.

Emil:

And also need to try at the same time at both parties. Otherwise checks fail.

Jonathan Lennox:

Question of what you want to freeze.
In RFC5245 you have frozen list and waiting list. Stuff goes inevitably in different order to waiting list. Believe the frozen algorithm can be adapted pretty cleanly.

Cullen Jennings:

Going back to the 2 suggested algorithms. Do not believe the first proposal works. Not convinced the second proposal works either.
Do believe the problem is solvable.
Maybe you could say host candidates never come in trickle ICE (always know those).
Can make assumptions on total number of things and the narrowest window firewalls leave open for checks
Believe more work and analysis is needed.

Eric Rescorla:

ICE does not discriminate between different candidates based on the time they came in.

Emil:

Does believe second option works; it’s basic RFC 5245. Asking Cullen to explain why it won't (off-line).

Martin Thomson:

Sent some comments to list.
Number of candidates can exist in transit which means both ends can have a different idea about the candidates.
Believe safe choice is the last one. May not get the optimizations, but believe it will work.

Jonathan Lennox:

In RTCWEB context there’s only one component
With one component bundle total it makes it a lot easier
Multiple ports for media is getting more rare

Emil asked people to also review Trickle ICE SIP document since it has open issues.

Martin Thomson:

Could raise a point that raises some concerns with the second option

Conclusion: Second option to be investigated further. Cullen and Ekr raised concerns that should be discussed. Also need people to review “Trickle ICE SIP” document.

SDP Application Token Attribute (Roni Even)

draft-even-mmusic-application-token-00

Need mechanism for mapping single source identified by SSRC to application logic.

Colin Perkins (slide 3):

Second bullet point: change "can" to "must"; will need to do all three (or at least "some signaling" and RTP).

Colin Perkins (slide 5):

How can you change the camera without changing the video coding context?
Roni: All the cameras use the same encoding parameters.
Colin: Always assumed the SSRC would change if the camera changes
Jonathan Lennox clarified the media source (camera) doesn't change (see slide 4, camera 2). Whether it's the left or the right camera is what changes.

Cullen Jennings:

In unified type plan context these were under one m-line
Don’t understand how application ID can have image resolution associated; other things seem OK
m-line would negotiate with a=image attribute resolution of all cameras; app-id just an identifier

Jonathan Lennox:

As co-author, was trying to cover both Plan A and Plan B scenario. Draft was written before the Unified Plan document. Layer of indirection that you negotiate app-id instead of SSRCs

Martin Thomson:

Not sure you get this functionality in WEBRTC without some API changes. Relying on fact this gets through with no packet loss etc.

Uwe Rauschenbach:

Seems to be an application specific mapping that we put down in the media path layer. We already have the SSRC. Why don't we use that.

Jonathan Lennox:

You could do that, but would have to send at several second intervals information that this SSRC is for this purpose

Bernard Adoba:

Seems like a good thing that can solve a bunch of problems. Keep working on it.

Adam Roach:

To Uwe’s question, second application for this is RTCWeb. Need something similar for this for WebRTC / unified anyway.

Colin Perkins:

Think there is a use case for some way of mapping an RTP stream to some high level concept of a stream. This seems like a reasonable starter, but looks overly complicated; believe it can be simplified
Suggest to decouple it from the different plan proposals and make it independent of the plans. Should be able to simplify signaling and make it plan-independent.

Conclusion: Authors to continue working on the draft and update based on feedback received here.

Economical Use of the Offer/Answer Model in Sessions with Multiple Media Sources (Emil Ivov)

draft-ivov-mmusic-multiple-sources-00

Main reason to use SDP is legacy interoperability, and many of the common issues are already hashed out. How about beyond that?

Cullen Jennings:

SDP is about setting up and configuring RTP
XCON, RFC 4575, WebRTC JS, and CLUE are not about SDP; the examples are not motivating

Roni Even (commenting on slide 4):

This is not enough; the receiver won’t know how many streams to receive.
Need at least max-ssrc

Eric Rescorla:

How do you differentiate between multiple SSRCs that are switched vs. displayed simultaneously?

Bernard Adoba:

Implementation dependent (for video at least).
Depends what experience is delivered to end user.

Cullen Jennings:

For audio, it's not implementation dependent; pretty universal that it means one at a time.
There are things that work and are fairly well-defined

Bernard Adoba:

It actually works without being standardized. It's ok that one system renders one way and another system renders it differently.
For audio, agree we need agreement for interoperability.

Emil:

Not suggesting that you should not do something like unified plan (A)
Suggesting you may also do something different than that

Martin Thomson (commenting on slide 7):

Sort of arguing a number of things. Trying to get to "what semantics does SDP carry”
What are the assumptions you are making ?

Colin Perkins:

Different perspectives: Cullen wants SDP to be prescriptive, Bernard wants it to be looser.
There are two long-standing different interpretations as to what are the proper semantics

Ted Hardie:

Thought this presentation was about "can MMUSIC agree on a common set of semantics for an m= line" as opposed to a plan discussion.
If we have to solve the problem of what the right semantics are, can MMUSIC agree on common set of semantics for SDP and say either it fits or we need to extend it.

Emil:

Trying to get everyone agree on one single set of semantics is virtually impossible
Trying to get to:

If I say nothing, then it means I can do only audio and video
If I say I can do multiple m-lines, it means I can do unified plan
If I use max-ssrc, I can have multiple streams on singe m-line

Ted Hardie:

Getting into syntactic sugar
The big question is should SDP grow or provide hooks?

Eric Rescorla:

Would like to get to interoperability between two devices with arbitrary number of cameras and displays.
Maybe the specifications don’t meet that need, but they ought to
Real question is do we think can SDP provide sufficient description of media?

Flemming (as chair):

Getting into discussion of Wednesday [Unified Plan, etc.]. Need to think about what should be in discussion tomorrow. Don't try and solve everything in last 5 minutes.

Jonathan Lennox:

People have different understanding what SDP means
Has changed quite a bit from one audio and one video
The different mental models generalize in different directions

Roni Even:

Problem is offer/answer. People interpreted that differently.
Proposals are trying to put some information on the intended semantics

Bernard Adoba:

To Ekr, lots of things will break, but not the specific things you mentioned.

Martin Thomson:

What Ekr said is important; how much semantics does it need to carry? Enough to make it work in a consistent manner.

Cullen Jennings:

Colin put it well; people come with different viewpoints.
1 view: when you come with 3 video streams, there is no need to have them show up the same way. Another view is that you should care. Maybe we do need to care about that.
What are the use cases we are trying to drive and how do we express those?

Colin Perkins:

We have a well defined concept of a media stream, SSRC. App will know it's receiving two media streams based on that.
If you are receiving two streams of media you should make sensible decision about what to do with them.

Paul Kyzivat:

CLUE found it didn't make sense to do it on top of SDP, so did layer something on top
In Ekr's case, maybe you shouldn’t layer something on top
If you don't have some way of conveying what should happen with those cameras, you are not likely to get a good result.
For RTCWEB simple cases, maybe you don't need anything else, in other cases you may need

A Framework for SDP Attributes when Multiplexing (Suhas Nandakumar)

draft-nandakumar-mmusic-sdp-mux-attributes-03

Update on where we are now. One open issue: how to categorize encapsulating attributes? 65% has been reviewed, can we make this WG doc?

Christer Holmberg:

Support the work but object to the document recommending for or against use of certain attributes (only if recommendations are due to multiplexing)
Suhas: Comment was made last time and has already been incorporated.

Martin Thomson:

This WG has already far too much work; but Bundle depends on this

Jonathan Lennox:

Reason I didn’t want to do Bundle was that I didn’t want to do all this work, so thank you for doing this since we decided to do bundle

Eric Rescorla:

Don’t care if this is separate doc or appendix to bundle

Flemming (as chair): we are over time so need to continue discussion on the list

Meta-data Attribute signaLling with ICE

draft-martinsen-mmusic-malice-00

[Tuesday session ran out of time and the draft was not presented]

Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers (Christer Holmberg)

draft-ietf-mmusic-sdp-bundle-negotiation-04

Christer presented his slides.

Christed has received a few off-line comments suggesting some of the issues are outside the scope of bundle; intent is to clarify open issues including if they are out of scope.

Slide 4 Questions (Q1, Q2, Q7)

Q1: “Can we agree that, within a BUNDLE group (including all m- lines associated with the group), any given PT value can only be used for a single codec configuration?”
Q2: “If Q1, do we agree that we need EXPLICIT text somewhere*, as there are opinions that simply referencing RFC 3550 might not be clear enough?”
Q7: “Within a BUNDLE group, do we allow the usage of the same PT value in multiple RTP m- lines, for the SAME codec configuration?”

Should we say anything in Bundle about this, and if so what ?

Jonathan Lennox:

H.264 sprop parameters use case; both H.264 but with different parameters. Would that be different values or not ? Should think about how we want to handle that (e.g. do we allow same PT or not)
Related to Roni's question about what is a "codec configuration"

Paul Kyzivat:

If there is something you think you can vary from one m-line to another about a payload type configuration. You have to be able to tell which m-line a payload type is associated with.

Christer suggests discussing further on the list.

Cullen objects; reason for these meetings is to discuss solution rather than deferring to mailing list.

Martin Thomson asking if we need more people to answer “yes” to these questions ?

Q1:

Answer is yes, with more clarification needed on what constitutes a codec configuration. H.264 use case is a specific concern.
Proposal to say same rtpmap and fmtp.
Mo Zanaty brings up other parameters, e.g. imageattr.
Jonathan Lennox says it should be something that affects the decoder.
Mo: imageattr is not a decoder property

Codec configuration strawman proposal from Lennox:

rtpmap and fmtp. Use that as starting point (put text in draft and discuss further)

Roni Even:

Concerned if you want to change some of the parameters later on in a subsequent offer; would then have to change the payload type.
Christer: Rule applies to all offer/answers

Harald Alvestrand:

Agree with Cullen and Lennox; nail it.

Justin Uberti:

If you can figure it out from the RTP it is not a codec parameter
Also need to look at Opus sprop parameters.

Conclusion on Q1, Q2 and Q7:

Q1: Yes

Q2: Yes, Lennox will send suggested text to clarify the term “codec configuration”.

Q7: Yes.

Slide 5 (Mapping RTP data to m-lines)

Q3: “Do we need to specify a default mechanism for mapping RTP data to m-lines?”
Q4: If Q3, do we mandate applications to support, and use (unless applications are made aware of other mechanisms supported by all endpoints) PT for mapping received RTP media?

Christer noted that he had received off-line comments that it was addressed at the Interim meeting; Christer didn't see it in minutes though, so want to re-confirm.

Q3: Christer suggests answer is no

Cullen Jennings:

Believe we made a decision at the interim that is consistent with the unified plan proposal.

Justin Uberti:

Should it live in the unified plan or here ?
Cullen: Believe it should be in the bundle document, but depends on unified plan. So that text part of unified plan would move to this document.

Colin Perkins:

All this talk about a default seems to be making a distinction where none is needed. Can't see a use case where we need the distinction (there shouldn't be a conflict between SSRC and payload types).
Christer: Mo had specified that if you had the same payload type for multiple m-lines, there may be in issue (which m-line does it belong to ?).
Colin believes we can provide rules

Signaled SSRC: use that
Unique payload types: use those

Colin: Two questions here: 1) Mandating it's possible. 2) How to do it.
Not taking a position on the mandatory part. It's easy to write up a mechanism for how to do it.

Eric Rescorla:

Unified plan has much more on this; suggest we defer discussion until we have gone through Adam's slides.

Paul Kyzivat:

Paul believes they are orthogonal; would like to discuss further now, but agree to defer for now.

Colin Perkins:

The information is there in the SDP; you can choose to either use it or not.

Conclusion on Q1 & Q4: Defer further discussion until we have gone through the unified plan slides.

Slide 6 (Q5)

Q5: “Within a SIP session, once both endpoints have indicated support of BUNDLE, do we allow an Offerer to assign an address:port to multiple m- lines, before the Answerer has selected that address:port as a BUNDLE address?”
Q6: “If Q5, do we allow an Offerer to assign an address:port to multiple m- lines before the Answerer has, within the SIP session, indicated that it supports BUNDLE? A typical example would be assigning an address:port to multiple m-lines already in the initial SDP Offer for a SIP session.”

Christer suggests we allow it

Justin Uberti: What is the difference between Q5 and Q6 ?

Christer:

Q6 is the initial offer
Q5 is the reInvite (new offer)

Q6: Christer suggests not to discuss

Q5: Christer suggests to allow in reInvite

Justin Uberti:

Should be able to do in first offer.

Cullen Jennings:

Disagrees with Justin
Q5 and Q6 are confusing on the slide - ignore text

Justin Uberti:

If you know it is equal to the reInvite, i.e you know somehow out-of-band the receiver’s capabilities to support Bundle, then it shouldn't be prohibited to do that.

Hadriel Kaplan:

Agree with Justin. Should absolutely be allowed (e.g. for JavaScript)
If your initial offer uses different port numbers, then there has to be a second offer with same port numbers

Cullen Jennings:

If you are in a session and doing a reInvite and you know Bundle is supported, then there is no need to do the separate ports.

Decision:

For existing m-lines, doing a reINVITE when you know Bundle is supported, you do not need to use separate port numbers (single O/A exchange is OK).

Eric Rescorla then asking about new m-lines.

Cullen:

For new m-lines in reINVITE where you know other end supports bundle. Can use the same port number on the new m-line.

Christer:

Not forbidding to send m-line with different ports (i.e. could do either).

Jonathan Lennox:

If the answerer wanted to accept, he can reject and then reInvite back unbundled.

Conclusion: Can include same ports; different ports allowed but with consequences as pointed out in the discussion.

Cullen Jennings:

When not using SDP can do whatever want, but when using SDP then need to know what is wanted. The first offer in SDP offer/answer needs to have unique ports.

The above was seen by some as re-opening a previously agreed upon decision in Bundle. Several people were lined up to comment further however the chairs needed to move along the meeting to ensure sufficient time for the Unified Plan discussion.

There was a request for a quick hum on Cullen’s last statement above which was then done by the chairs; the hum was inconclusive.

Conclusion: Need to get closure on port number uniqueness requirement for very first offer (initial Offer) when using SDP Offer/Answer in a session.

A Unified Plan for Using SDP with Large Numbers of Media Flows (Adam Roach)

draft-roach-mmusic-unified-plan-00

The chairs first summarized the background for this work, noting that:

The RTCWeb WG has asked MMUSIC for a solution to better handle large numbers of media flows in SDP

Requirements are outlined in the unified-plan document
RTCWeb urgently needs progress from MMUSIC, but problem/solution space applies beyond RTCWeb

We have explored a number of different and competing proposals since 2011

We now have a combined and unified proposal from the two previously competing proposal camps at this point

The chairs then asked people to focus on the following for the presentation:

Any technical objections to the overall proposal ?

It is understood, that further work is needed (open issues in the current document)

Any use cases that are not supported ?
Anything people cannot live with in the proposal ?

Following that, the different topics covered by the plan were presented by Adam Roach. Adam indicated that the intent is not to publish this as a standalone document. It points to work done in other documents, in other Working groups, and possibly even other SDOs.

During the presentation, the following points were brought up:

Requirements and Solution Outline (slides 2-3)

Roni Even: Need to support more than point-to-point; multipoint must be supported as well.
Adam: Intend to support offer/answer. Do support star topologies as well (via multiple point-to-point)
Bernard Adoba: There is a context problem here. May have different opinions of document depending on whether this is:

Profile for RTCWeb
Overarching architecture for MMUSIC
Guiding future work.

Ted Hardie:

Unified plan is a response to the RTCWeb request and should be read in the context of that

Martin Thomson:

Do we use this for other things as well or not ?
Ted: Suggest we go through the rest of the slides first.

SDP: Semantics and Existing Use - (Slide 5)

Jonathan Lennox:

Need something that says: I think of this in philosophy A and therefore would like to do it the following way; another one may follow philosophy B and therefore would like to do it a different way. Both will need to be able to fall back to something.

Eric Rescorla:

Requesting we allow presentation to conclude first, and then get into discussion.

Flemming (as chair):

Clarifying questions OK during presentation; full-fledged discussion should wait till end.

Glare Reduction (slide 14)

Roni Even:

Not sure if SDP is describing send or receive capabilities the way it's described.
Adam: Not changing existing SDP.
Roni was referring to a different slide.
Adam asking Roni to point to places in the draft where he says potential issues; were not intending to make any changes to existing definitions at least.

Martin Thomson:

Is there any suggestion around use of "sendonly" and "recvonly" to further reduce the change of glare.
Adam: can look further into that; please propose on the list.

Uwe Rauschenbach:

How does it work if only one side supports partial O/A ?
Adam: Would have to be supported by both and negotiated.

Christer Holmberg:

What do you mean by "remove"; Lennox pointed out the same issue (should be set port to zero instead).
Adam will fix.

Simulcast Example (slide 17)

[Note: slide shows simulcast done with a single m= line]

Roni Even:

Draft from Magnus previously shows how you can do simulcast with separate m-lines; haven't done in a single m-line previously (didn't really work).

Bernard and Justin would like to discuss further.

Adam asked to revisit discussion if time.

Colin Perkins:

Some of the older FEC specs do somewhat weird things with the signalling; should take a closer look at those.
Cullen Jennings: Believe Suhas' draft marks those as "don't use with bundle".

Matching RTP Streams to m-lines (slide 23)

Adam: This was written before the app-id draft [and vice versa] (Roni Even/Jonathan Lennox draft).

Colin Perkins: RTP header extension; can use RTCP SDES as a fallback.

Jonathan Lennox:

One race it doesn't solve is sending multiple SSRCs per m-line.
Don't want this mechanism to be separate from the app-id solution.

Justin Uberti:

Need a=ssrc so can set up RTX, etc.

Plan Discusion and Decision on Path Forward

The chairs asked for comments on the unified-plan proposal with intent to use it as the baseline for large number of media flows in SDP going forward.

Christer Holmberg:

Do we always mandate some mechanism to map SSRC to m-line ?

Ted Hardie:

Plea from RTCWeb chairs is to treat this as identifying stuff that is broken. This is not a last call for the document.

Mo Zanaty:

Are there dependencies between bundle and unified-plan so we can't discuss one without agreeing on the other ?
Adam: More work needed, but one RTP stream per m-line use grandfathers a lot of the others.

Bernard Adoba:

Clarifying question on simulcast. A mechanism was defined (a=simulcast group). Didn't define an equivalent construct for layered coding.
Cullen: Intention was to use layered codecs as the current RFCs do them. Believe the existing ones can be used.
Bernard: Not convinced.
Adam: Trying not to change existing mechanisms. Simulcast is more greenfield, so saw a need to define something.

Colin Perkins:

Proposal makes sense for what RTCWeb is trying to do.
Bundle mechanism is more general than WebRTC, and would encourage that it continues to be that way.
Bundle should be generic in scope.

Roni Even:

OK with one RTP stream per m-line.
Have the same concern as Colin. Basically talks about a WebRTC environment; MSID for example is a WebRTC thing.
Should have a document that is generic (not RTCWeb specific). Maybe split the document in two: 1) general MMUSIC draft; 2) specific "profiles".

Hadriel Kaplan:

One of the customers for Bundle was CLUE. CLUE usage is to be able to use existing SIP based deployments. In that context, this does not apply.
Hadriel asking if there is an update to offer/answer.
Adam does not believe it would be an update to Offer/Answer. Partial offer/answer is not an update to RFC 3264. Would need an extension of course (but not an update to RFC 3264).
Hadriel: Is this for WebRTC, or is the goal beyond WebRTC ?

Paul Kyzivat:

On using multiple offer/answers to get X videos instead of 1; Once you have chosen to use a line bidirectionally, it's hard to make it unidirectional.
Glare: Have mechanisms for dealing with that in SIP already.
Need to consider implications of trickle ICE and partial offers.
Adam: Partial offers in webrtc: application needs to explicitly request a partial offer.

Richard Ejzak:

Share concern about partial offers
Asking for clarification on use of port zero; do we still intend to signal port=0 to indicate bundle only m= lines ?
Adam: In initial offer, port=0 has a special semantic.

Harald Alvestrand:

Bi-directionality: Do we expect the default mode to be send/receive and what is the control surface ?
Adam asking for clarification on but believes this is more of a W3C question.

Eric Rescorla:

Believes the unified-plan proposal is technically sound and we should proceed with it.

Mo Zanaty:

Question on scope. Is the unified plan proposal only for bundle media or also for SDP in general ? Mo supports the bundle-only aspect.
How do we deal with general versus RTCWeb specific ?
Adam suggests splitting across multiple groups.
Suhas agreed.

There were more people wanting to comment and ask questions, however as the meeting was nearing the end, the chairs had to end further discussion. Based on the comments received so far, the chairs asked the WG for a hum on the following:

Consensus call

Adopt the unified-plan proposal as the baseline approach for large number of media flows in SDP:

The scope is currently limited to RTCWeb.
Still need to resolve open issues identified and further refine overall solution.

Conclusion:

There was strong WG consensus in favor of the above and hence the unified-plan proposal will form the baseline for large number of media flows in SDP. The scope is currently limited to RTCWeb. Expansion of the scope beyond RTCWeb is not precluded but will require further discussion.

The chairs will discuss further with the Area Directors and other relevant WG chairs (RTCWeb, AVTEXT and possibly others) to identify the list of topics and documents that need to be developed in accordance with the unified-plan proposal.