search

cdh4u / draft-sdp-bundle

1 stars 9 forks source link

Rules for using a "shared address" in subsequent offers are needlessly complex. #24

Closed taylor-b closed 6 years ago

taylor-b commented 7 years ago

In an initial offer, if we want to communicate "this 'm=' section must be either bundled or rejected", that's accomplished with "a=bundle-only":

a=group:BUNDLE A B
m=video 1000
a=mid:A
m=video 0
a=mid:B
a=bundle-only

In subsequent offers, this is accomplished by duplicating the IP address/port:

a=group:BUNDLE A B
m=video 1000
a=mid:A
m=video 1000
a=mid:B

Is this difference necessary? This seems like needless complexity. It would be simpler to just continue using "a=bundle-only" in subsequent offers.

Also, the approach of using a shared address to communicate something isn't extensible to protocols that don't use an address for identification, like ICE. We'd need to define additional rules for those cases, or allow them to use "a=bundle-only" in subsequent offers.

cdh4u commented 7 years ago

A little bit of history: in the beginning, the spec required to send a second offer, with duplicated IP address/port, as soon as the first answer arrived, in order to inform middle boxes etc. However, we removed that requirement at some point. Currently the spec says that when a subsequent offer is sent (whenever/if it is sent) it has to be with duplicated IP address/port. That was a kind of a "compromise".

However, what you suggest would make things easier. Ekr has also suggested that we should put less focus on what IP addresses/ports are used, because the only thing that matters is the BUNDLE address.

But, such change would require a discussion/approval by the community, so feel free to suggest it on the list :)

cdh4u commented 7 years ago

One issues with NOT using a shared address in subsequent offers:

Assume the offerer sends an initial offer with A, B, C and D. The answer accepts the bundle group, and the address:port of D becomes the BUNDLE address. Then, the offerer sends a subsequent offer with A, B, C and D - keeping the unique addresses. For whatever reason, the answerer now rejects D, by setting the port to zero in the answer. The BUNDLE address port is no longer present, so the answerer will have to choose a new BUNDLE address (the address:port of A, B or C).

taylor-b commented 7 years ago

The offerer's subsequent offer shouldn't keep using unique addresses; I'm suggesting it should use ports of 0 with "a=bundle-only", if the offerer wants to force the BUNDLE group to continue being used. Then, assuming #22 is resolved, the answerer rejecting D wouldn't cause any problems.

cdh4u commented 7 years ago

I think at least one m- line would need to contain the actual port. But then, if the answerer rejects that m- line, you again have the situation where you have no "active" m- line containing the actual port value. I believe we need to have the actual port in at least one of the "active" m- lines, because there are e.g., intermediaries (gate controlling entities etc) that need that information. We cannot expect such entities to support BUNDLE from day one.

cdh4u commented 6 years ago

Now, the BUNDLE address (previously called shared address) is only assigned to the "m=" section represented by the BUNDLE-tag.