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

Taylor Brandstetter <deadbeef@google.com> Thu, 09 February 2017 09:46 UTC

MIME-Version: 1.0
In-Reply-To: <D4C1FAC7.17AEE%christer.holmberg@ericsson.com>
References: <CAK35n0bys1EUwoJtvok2Qjcg7bqK4hQx1HhwbnKSHZw2TuAPLA@mail.gmail.com> <D4C1FAC7.17AEE%christer.holmberg@ericsson.com>
From: Taylor Brandstetter <deadbeef@google.com>
Date: Thu, 09 Feb 2017 01:46:38 -0800
Message-ID: <CAK35n0ZYDiyJKcTXHWet5=JfdDk+EC5XbWoeRW7Gpd9uptU7-w@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a114104ce9a7e9d054815dbbb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/xWIdl2ZX3LfYZUv02FGpWBrMTZs>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Can we use "a=bundle-only" in subsequent offers, instead of using a "shared address"?
Precedence: list

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 <
christer.holmberg@ericsson.com> wrote:

>
> 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 <mmusic-bounces@ietf.org> on behalf of Taylor Brandstetter <
> deadbeef@google.com>
> Date: Thursday 9 February 2017 at 01:23
> To: "mmusic@ietf.org" <mmusic@ietf.org>
> 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.
>

[MMUSIC] Can we use "a=bundle-only" in subsequent… Taylor Brandstetter
Re: [MMUSIC] Can we use "a=bundle-only" in subseq… Christer Holmberg
Re: [MMUSIC] Can we use "a=bundle-only" in subseq… Taylor Brandstetter
Re: [MMUSIC] Can we use "a=bundle-only" in subseq… Christer Holmberg