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

[Christer Holmberg <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> on behalf of Taylor Brandstetter <[e-mail]<mailto:[e-mail]>>
Date: Thursday 9 February 2017 at 01:23
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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.