Subject: [MMUSIC] Can we use "a=bundle-only" in subsequent offers, instead of using a "shared address"?

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 8 Feb 2017 15:23:51 -0800

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=audio 10000 ...
a=mid:A
...
m=video 0 ...
a=mid:B
a=bundle-only

In subsequent offers, this is accomplished by duplicating the IP
address/port (see section 8.3.3):

a=group:BUNDLE A B
m=audio 10000 ...
a=mid:A
...
m=video 10000 ...
a=mid:B

Is this initial vs. subsequent offer difference necessary? Both blobs of
SDP are communicating the same information, so the "shared address" rules
seem to only add complexity.

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 specifically to use "a=bundle-only" in subsequent offers.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Feb 2017 08:55:40 +0000

Hi,

In principle, sending port zero + bundle-only also in subsequent offers should be ok.

However, there always needs to be at least one m- line containing the actual used port, and the answerer must not reject that m- line (no matter whether it’s an initial or subsequent request). The advantage of sending the “shared address” is that the answerer can reject any m- line, as all the other m- lines contain the used port.

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Date: Thursday 9 February 2017 at 01:23
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] Can we use "a=bundle-only" in subsequent offers, instead of using a "shared address"?

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=audio 10000 ...
a=mid:A
...
m=video 0 ...
a=mid:B
a=bundle-only

In subsequent offers, this is accomplished by duplicating the IP address/port (see section 8.3.3):

a=group:BUNDLE A B
m=audio 10000 ...
a=mid:A
...
m=video 10000 ...
a=mid:B

Is this initial vs. subsequent offer difference necessary? Both blobs of SDP are communicating the same information, so the "shared address" rules seem to only add complexity.

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 specifically to use "a=bundle-only" in subsequent offers.

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 9 Feb 2017 01:46:38 -0800

Well, the advantage of using port zero + bundle-only in subsequent offers
would be to eliminate the complexity of the "shared address" logic. So
there wouldn't be much point in allowing it if we need shared addresses
anyway.

This relates to another issue Christer and I have been talking about. I had
thought that this use case was supported:

Offer (A, B, C, bundle-only):

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

Answer (rejects A, keeps B and C):

a=group:BUNDLE B C
m=video 0
a=mid:A
m=video 20000
a=mid:B
m=video 20000
a=mid:C

But I realized recently it isn't. The answerer can't reject "A" without
rejecting the whole BUNDLE group. So, as long as that restriction exists,
"shared addresses" have an advantage over using "a=bundle-only".

On Thu, Feb 9, 2017 at 12:55 AM, Christer Holmberg <
[email-masked]> wrote:

> However, there always needs to be at least one m- line containing the
> actual used port, and the answerer must not reject that m- line (no matter
> whether it’s an initial or subsequent request). The advantage of sending
> the “shared address” is that the answerer can reject any m- line, as all
> the other m- lines contain the used port.
>
> Regards,
>
> Christer
>
>
>
> From: mmusic <[email-masked]> on behalf of Taylor Brandstetter <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Feb 2017 10:46:38 +0000

Hi,

>Well, the advantage of using port zero + bundle-only in subsequent offers would be to eliminate the complexity of the "shared address" logic. So there wouldn't be much point in allowing it if we need shared addresses anyway.

At the end of the day (this was also raised by Ekr some time ago), once the bundle group has been created, it doesn’t really matter what address:port you use in subsequent offers – as long as the actual BUNDLE address is present in at least one m- line.

The advantage of using the “shared address” is that the answerer can reject any m- line in a subsequent offer, as the BUNDLE address will be present in the other m- lines. I don’t know how often that happens in reality – typically, if an endpoint wants to remove media, it will send an offer itself in order to do so.

Regards,

Christer

On Thu, Feb 9, 2017 at 12:55 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

a=group:BUNDLE A B
m=audio 10000 ...
a=mid:A
...
m=video 0 ...
a=mid:B
a=bundle-only

a=group:BUNDLE A B
m=audio 10000 ...
a=mid:A
...
m=video 10000 ...
a=mid:B