search

rtcweb-wg / jsep

33 stars 32 forks source link

BUNDLE answers should contain bundle-only atttribs #843

Closed juberti closed 3 years ago

juberti commented 6 years ago

per @cdh4u, seems like answers should now be handled differently:

The initial offer is as before, i.e., you assign a unique address, SDP attributes etc to each bundled m- section.

But, in the answer, and in every subsequent offer/answer, you only assign the BUNDLE port to the bundled m- section represented by the offerer/answerer BUNDLE-tag. To every other m- section you assign a zero port value and a bundle-only attribute (previously the bundle-only attribute was only defined for offers).

cdh4u commented 3 years ago

shared port in the initial offer

Such behavior has never been part of BUNDLE or JSEP (unless you count port 9 as a shared port).

ekr commented 3 years ago

which is what we would have originally done, but we were concerned that non-bundle-aware endpoints might malfunction upon receiving non-unique ports. That concern no longer really exists, but now we have the new concern that bundle-aware endpoints might malfunction upon receiving zero ports...

@juberti why does that concern no longer exist? Sorry, still paging all this back in.

juberti commented 3 years ago

Exactly one person has complained about Chrome not supporting a=bundle-only over the last 10 years, so I think we have a clear signal that this is not a real-world concern.

However, because we never added this, we now have a real compatibility concern in that apps that use max-bundle may suddenly break when we start sending zero ports. @nils-ohlmeier indicated they hit this as part of adding bundle-only in firefox and may be able to add more specifics here.

IOW, no upside, all downside.

cdh4u commented 3 years ago

Exactly one person has complained about Chrome not supporting a=bundle-only over the last 10 years, so I think we have a clear signal that this is not a real-world concern.

In initial offers, if you don't have bundle-only, you will have to include separate port numbers (and separate candidates, if ICE is used) for each m- line (unless you use trickle, in which case you will use port 9 for each m- line). One of the main reasons for introducing bundle-only was to avoid having to do that.

Using the same non-9 port number in each m- line in the initial offer was shut down more or less the first day we started working on BUNDLE.

juberti commented 3 years ago

Remember, we're really only talking about the max-bundle case here (otherwise, separate port numbers are already used). Evidence shows that a shared port works pretty well in this case (as that's the behavior used by apps today), so I think we can just internalize that and move on.

juberti commented 3 years ago

Let's continue this discussion on the list so that we don't need to reply in both places.

cdh4u commented 3 years ago

Let's continue this discussion on the list so that we don't need to reply in both places.

Yes, I was going to suggest that, and I also noticed that you had suggested it earlier.

juberti commented 3 years ago

Path forward here: https://mailarchive.ietf.org/arch/msg/rtcweb/1P0RH-4AJjTFSvi47T716eRIkR4/

cdh4u commented 3 years ago

The new version of the BUNDLE specification has passed MMUSIC WGLC, and the publication request has been sent to IESG.

https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc8843bis/