Subject: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

From: Christer Holmberg <[email-masked]>
Date: Mon, 2 Sep 2013 14:11:14 +0000

Hi,

The text below applies to the INITIAL Offer only.

Currently, BUNDLE (-04) specifies that:

1)      In the initial Offer, the "1st Offer", the Offerer assigns a unique address to each m- line in a BUNDLE group.

2)      When the Answer is received, if the Answerer accepted BUNDLE, the Offerer MUST send a "2nd Offer" (called a BAS in the draft), in which the selected BUNDLE address is assigned to each m- line associated with a BUNDLE group.

This is based on the "merger" of the earlier BUNDLE version, and Cullen's CUNDLE suggestion, and currently there are NO exceptions defined to the rule above (we have agreed to relax this in mid-call Offers, but that's a separate topic).

Now, lately people have suggested exceptions to the rule.

E.g. the following has been suggested:

1)      The Offerer does NOT need to send the 2nd Offer (BAS), it the Offerer "knows" it is operating in an environment where there are no intermediaries etc that need to get the correct address for each m- line.

2)      The Offerer can already in the 1st Offer assign the same address to each m- line associated with a BUNDLE group, if it "knows" entities will be able to handle it.

Then, there are variants of the suggestions, where there are specific rules to bundle-only m- lines, where it depends on whether BUNDLE is used in the API or on the wire, etc etc etc.

At the moment it is impossible for me to parse the input, and try to come up with some new suggested text that would make everyone happy.

So, those of want to change the current rules, I would be really happy if you could explain exactly how you want to change it :)

Thanks!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Sep 2013 16:27:39 -0400

On 9/2/13 10:11 AM, Christer Holmberg wrote:
> 1)In the initial Offer, the “1^st Offer”, the Offerer assigns a unique
> address to each m- line in a BUNDLE group.
>
> 2)When the Answer is received, if the Answerer accepted BUNDLE, the
> Offerer MUST send a “2^nd Offer” (called a BAS in the draft), in which
> the selected BUNDLE address is assigned to each m- line associated with
> a BUNDLE group.
>
> This is based on the “merger” of the earlier BUNDLE version, and
> Cullen’s CUNDLE suggestion, and currently there are NO exceptions
> defined to the rule above (we have agreed to relax this in mid-call
> Offers, but that’s a separate topic).
>
> 1)The Offerer does NOT need to send the 2^nd Offer (BAS), it the Offerer
> “knows” it is operating in an environment where there are no
> intermediaries etc that need to get the correct address for each m- line.
>
> 2)The Offerer can already in the 1^st Offer assign the same address to
> each m- line associated with a BUNDLE group, if it “knows” entities will
> be able to handle it.
>
> Then, there are variants of the suggestions, where there are specific
> rules to bundle-only m- lines, where it depends on whether BUNDLE is
> used in the API or on the wire, etc etc etc.
>
> At the moment it is impossible for me to parse the input, and try to
> come up with some new suggested text that would make everyone happy.
>
> So, those of want to change the current rules, I would be really happy
> if you could explain exactly how you want to change it :)

I have a feeling we aren't being very consistent.
We (mostly) embrace ICE, which is based on the assumption that you can't 
know in advance what is going to work, and must test every time.

Then we have proposals like these that assume there may be cases where 
you do know in advance.

I'm as guilty as others. I've been in support of (2), but not 
necessarily because I think people will *know* with certainty. IMO 
people may know that this case is highly probable in the deployments 
they care about. And that they may be willing to take the risk, and 
attempt to cope with the side effects in cases where it turns out to be 
true. But bundle-only gives most of the same advantage.

I don't see a strong justification for (1). While it takes extra 
signaling, it doesn't slow anything down except in those cases when it 
was actually necessary.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Sep 2013 11:18:05 +0000

Hi Paul,

Thanks for your input!

I'd really also like to hear from others who have had opinions on this. Ekr, Hadriel, Cullen (perhaps - he still hasn't clarified what he meant by his previous statement regarding this :), to name a few...

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Paul Kyzivat
Lähetetty: 2. syyskuuta 2013 23:28
Vastaanottaja: [email-masked]
Aihe: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

On 9/2/13 10:11 AM, Christer Holmberg wrote:
> 1)In the initial Offer, the "1^st Offer", the Offerer assigns a unique 
> Offerer MUST send a "2^nd Offer" (called a BAS in the draft), in which 
> the selected BUNDLE address is assigned to each m- line associated 
> with a BUNDLE group.
>
> This is based on the "merger" of the earlier BUNDLE version, and 
> Cullen's CUNDLE suggestion, and currently there are NO exceptions 
> Offers, but that's a separate topic).
>
> 1)The Offerer does NOT need to send the 2^nd Offer (BAS), it the 
> Offerer "knows" it is operating in an environment where there are no 
> each m- line associated with a BUNDLE group, if it "knows" entities 
> will be able to handle it.
>

I have a feeling we aren't being very consistent.
We (mostly) embrace ICE, which is based on the assumption that you can't know in advance what is going to work, and must test every time.

Then we have proposals like these that assume there may be cases where you do know in advance.

I'm as guilty as others. I've been in support of (2), but not necessarily because I think people will *know* with certainty. IMO people may know that this case is highly probable in the deployments they care about. And that they may be willing to take the risk, and attempt to cope with the side effects in cases where it turns out to be true. But bundle-only gives most of the same advantage.

I don't see a strong justification for (1). While it takes extra signaling, it doesn't slow anything down except in those cases when it was actually necessary.

	Thanks,
	Paul

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 4 Sep 2013 00:07:00 +0530

Hi all,

As Paul mentioned that mandating ICE in RTCWeb as the network is not known
in advance and let us continue the same assumption for BUNDLE as well. Just
adding to that point, ICE requires two offer/answer (O/A) handling anyway
and so, BUNDLE is not the first mechanism in RTCWeb requires two O/A for the
session establishment. 

The advance with the current BUNDLE mechanism is that it provides better
interop with SIP/legacy devices. I prefer the current mechanism.

Also, I have earlier replied in the another mail thread
(http://www.ietf.org/mail-archive/web/mmusic/current/msg12184.html), RFC3264
must not be violated to achieve the single offer/answer for BUNDLE. 

Thanks
Partha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: Tuesday, September 03, 2013 4:48 PM
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2
> Offer/Answers during session establishment?
> 
> Hi Paul,
> 
> Thanks for your input!
> 
> I'd really also like to hear from others who have had opinions on this.
> Ekr, Hadriel, Cullen (perhaps - he still hasn't clarified what he meant
> by his previous statement regarding this :), to name a few...
> 
> Regards,
> 
> Christer
> 
> Aihe: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2
> Offer/Answers during session establishment?
> 
> We (mostly) embrace ICE, which is based on the assumption that you
> can't know in advance what is going to work, and must test every time.
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Sep 2013 19:38:31 +0000

Thanks for your input, Partha! :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Parthasarathi R [mailto:[email-masked]] 
Lähetetty: 3. syyskuuta 2013 21:37
Vastaanottaja: Christer Holmberg; 'Paul Kyzivat'; [email-masked]
Aihe: RE: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

Hi all,

As Paul mentioned that mandating ICE in RTCWeb as the network is not known in advance and let us continue the same assumption for BUNDLE as well. Just adding to that point, ICE requires two offer/answer (O/A) handling anyway and so, BUNDLE is not the first mechanism in RTCWeb requires two O/A for the session establishment. 

The advance with the current BUNDLE mechanism is that it provides better interop with SIP/legacy devices. I prefer the current mechanism.

Also, I have earlier replied in the another mail thread (http://www.ietf.org/mail-archive/web/mmusic/current/msg12184.html), RFC3264 must not be violated to achieve the single offer/answer for BUNDLE. 

Thanks
Partha

> Ekr, Hadriel, Cullen (perhaps - he still hasn't clarified what he 
> meant by his previous statement regarding this :), to name a few...
> 
> Regards,
> 
> Christer
> 
> > Then, there are variants of the suggestions, where there are 
> > specific rules to bundle-only m- lines, where it depends on whether 
> > BUNDLE is used in the API or on the wire, etc etc etc.
> >
> attempt to cope with the side effects in cases where it turns out to 
> be true. But bundle-only gives most of the same advantage.
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 6 Sep 2013 11:49:58 -0700

In a closed app environment, you can ensure that the remote side can do
BUNDLE. I expect this sort of deployment to be common for WebRTC.

This is distinct from the ICE case, where it's not the app capabilities
that are in question, but rather the network topology. Even in a closed app
environment, the network will most likely be unknown to the app.

The setup cost of 1 signaling RTT is significant enough that some
applications will want to be able to avoid this.

On Mon, Sep 2, 2013 at 1:27 PM, Paul Kyzivat <[email-masked]> wrote:

> I'm as guilty as others. I've been in support of (2), but not necessarily
> because I think people will *know* with certainty. IMO people may know that
> this case is highly probable in the deployments they care about. And that
> they may be willing to take the risk, and attempt to cope with the side
> effects in cases where it turns out to be true. But bundle-only gives most
> of the same advantage.
>
> signaling, it doesn't slow anything down except in those cases when it was
> actually necessary.
>
>         Thanks,
>         Paul
>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Sep 2013 15:06:19 -0400

On 9/6/13 2:49 PM, Justin Uberti wrote:
> that are in question, but rather the network topology. Even in a closed
> app environment, the network will most likely be unknown to the app.

But one of the main justifications for the 2nd O/A is the presence of 
intermediaries who depend upon this. Even if you know all about the 
application at the other end, you probably don't know about the presence 
of intermediaries that care any more than you know about intermediaries 
that force the use of ICE.

> applications will want to be able to avoid this.

If its just the extra RTT you are concerned with, it shouldn't matter in 
this case, because you have your media flowing and so the extra RTT 
isn't delaying you. Or else the media isn't flowing due to media-gating 
intermediaries, in which case you really must pay that extra RTT to get 
the media going.

Or are you concerned with the other costs (processing, bandwidth) of the 
extra round trip?

	Thanks,
	Paul

> On Mon, Sep 2, 2013 at 1:27 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         Offerer
>         specific
>     signaling, it doesn't slow anything down except in those cases when
>     it was actually necessary.
>
>              Thanks,
>              Paul
>
>     _________________________________________________
>     mmusic mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Sep 2013 12:08:48 -0700

On 6 September 2013 12:06, Paul Kyzivat <[email-masked]> wrote:
> application at the other end, you probably don't know about the presence of
> intermediaries that care any more than you know about intermediaries that
> force the use of ICE.

I think that you are underestimating Justin's case here.  There are no
intermediaries that you don't know about.  When you have the peering
arrangements of a large company like his employer and end-to-end
control over the application, chances are there aren't that many
intermediaries at even the IP layer you have to worry about.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Sep 2013 19:46:29 +0000

Hi,

If you know that the other end supports BUNDLE, then why can't you assign the shared address to each "m=" line already in the FIRST Offer? Why assign unique addresses?

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Martin Thomson [[email-masked]]
Sent: Friday, 06 September 2013 10:08 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Sep 2013 13:09:56 -0700

> If you know that the other end supports BUNDLE, then why can't you assign the shared address to each "m=" line already in the FIRST Offer? Why assign unique addresses?

Exactly.  That's what I'd do.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 6 Sep 2013 17:14:40 -0700

That's what I thought we were talking about. This has the benefit that you
don't need to gather STUN/TURN for the other addresses that you know you
are going to discard.

Regarding intermediaries, I expect that even for less-well-provisioned
WebRTC app providers, there typically won't be any intermediaries, at least
none who have access to the signaling traffic.

On Fri, Sep 6, 2013 at 1:09 PM, Martin Thomson <[email-masked]>wrote:

> > If you know that the other end supports BUNDLE, then why can't you
> assign the shared address to each "m=" line already in the FIRST Offer? Why
> assign unique addresses?
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 7 Sep 2013 05:31:52 +0000

Hi,

Ok, my misstake, I thought you were talking about only sending the 1st Offer with unique addresses, and not sending the 2nd Offer with the shared address.

So, what you are talking about is the original BUNDLE proposal (before it was merged with CUNDLE).

Regards,

Christer

________________________________
From: Justin Uberti [[email-masked]]
Sent: Saturday, 07 September 2013 3:14 AM
To: Martin Thomson
Cc: Christer Holmberg; [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

That's what I thought we were talking about. This has the benefit that you don't need to gather STUN/TURN for the other addresses that you know you are going to discard.

Regarding intermediaries, I expect that even for less-well-provisioned WebRTC app providers, there typically won't be any intermediaries, at least none who have access to the signaling traffic.

On Fri, Sep 6, 2013 at 1:09 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
On 6 September 2013 12:46, Christer Holmberg

Exactly.  That's what I'd do.
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 09 Sep 2013 10:55:58 +0200

On 09/07/2013 02:14 AM, Justin Uberti wrote:
> That's what I thought we were talking about. This has the benefit that 
> you don't need to gather STUN/TURN for the other addresses that you 
> know you are going to discard.
>
> WebRTC app providers, there typically won't be any intermediaries, at 
> least none who have access to the signaling traffic.

For instance, I expect a number of applications to work on the following 
pattern:

- Set up a connection with a data channel only via some relay
- Do all subsequent offer/answer over the data channel

Given the wonderful world of DTLS, we *know* that there are no 
intermediaries.

>
>
> On Fri, Sep 6, 2013 at 1:09 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > If you know that the other end supports BUNDLE, then why can't
>     you assign the shared address to each "m=" line already in the
>     FIRST Offer? Why assign unique addresses?
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Sep 2013 09:27:59 +0000

Hi Harald,

If you only establish a data channel, there is only one m- line, so it is irrelevant whether you are allowed (in the first Offer) to assign the same address to multiple m- lines or not :)

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 9. syyskuuta 2013 11:56
To: [email-masked]
Subject: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

For instance, I expect a number of applications to work on the following pattern:

Given the wonderful world of DTLS, we *know* that there are no intermediaries.

mmusic mailing list

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Sep 2013 10:07:03 -0700

Christer,

The point is really that new m-lines are offered in subsequent exchanges to
add audio and video. Those exchanges can run in a single round.

--Martin
On Sep 9, 2013 2:28 AM, "Christer Holmberg" <[email-masked]>
wrote:

>  Hi Harald,****
>
> ** **
>
> If you *only* establish a data channel, there is only one m- line, so it
> is irrelevant whether you are allowed (in the first Offer) to assign the
> same address to multiple m- lines or not :)****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Harald Alvestrand
> *Sent:* 9. syyskuuta 2013 11:56
> *To:* [email-masked]
> *Subject:* Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2
> Offer/Answers during session establishment?****
>
> ** **
>
> On 09/07/2013 02:14 AM, Justin Uberti wrote:****
>
> you don't need to gather STUN/TURN for the other addresses that you know
> you are going to discard. ****
>
> ** **
>
> none who have access to the signaling traffic.****
>
>
> ****
> ** **
> On Fri, Sep 6, 2013 at 1:09 PM, Martin Thomson <[email-masked]>
> wrote:****
>
> On 6 September 2013 12:46, Christer Holmberg****
>
> assign unique addresses?****
>
> Exactly.  That's what I'd do.****
>
> https://www.ietf.org/mailman/listinfo/mmusic****
>
> ** **
>
>
>
>
> ****
>
> _______________________________________________****
>
> mmusic mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/mmusic****
>
> ** **
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Sep 2013 17:45:51 +0000

Hi,

>The point is really that new m-lines are offered in subsequent exchanges to add audio and video. Those exchanges can run in a single round.

Sure. If the Offerer assigns a previously negotiated BUNDLE address (or, an address that will become the new BUNDLE address) to those m- lines, there is no need for a second o/a exchange.

But, the issue is regarding the initial Offer for a dialog, and whether the Offerer is allowed to assign the same address to multiple m- lines in that Offer. If not, a second o/a exchange will always be needed.

Regards,

Christer

--Martin
On Sep 9, 2013 2:28 AM, "Christer Holmberg" <[email-masked]> wrote:

Hi Harald,

Regards,

Christer

On Fri, Sep 6, 2013 at 1:09 PM, Martin Thomson <[email-masked]> wrote:
On 6 September 2013 12:46, Christer Holmberg

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Sep 2013 11:22:04 -0700

> Sure. If the Offerer assigns a previously negotiated BUNDLE address (or, an address that will become the new BUNDLE address) to those m- lines, there is no need for a second o/a exchange.

Perhaps the single m-line offer/answer performed to establish the data
channel will include BUNDLE, but it would be a little redundant.  It
depends on whether we require that in order to provide knowledge about
support for BUNDLE.

When you talk about initial offer, you should really be talking about
the first offer that contains BUNDLE.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Sep 2013 18:28:28 +0000

Hi,

> channel will include BUNDLE, but it would be a little redundant. 

Correct.

The only advantage of putting a single m- line into a BUNDLE group is that you will, in the Answer, find out whether the Answerer supports BUNDLE.

But, for that we could also define e.g. a feature/option-tag, so that one doesn't have to use BUNDLE just to figure out whether the other end supports it or not...

>When you talk about initial offer, you should really be talking about the first offer that contains BUNDLE.

Or, the offer when the offerer still doesn't know whether the answerer supports BUNDLE - IF there is a way for endpoints to exchange that data without actually using BUNDLE.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Sep 2013 11:29:42 -0700

> Or, the offer when the offerer still doesn't know whether the answerer supports BUNDLE - IF there is a way for endpoints to exchange that data without actually using BUNDLE.

Yes, I think that is the key.  O/A is just one way to learn about
these sorts of things :)

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Sep 2013 18:41:21 +0000

So, with some modified wording, the question is:

When an Offerer sends AN Offer with BUNDLE, and the Offerer has not previously within the dialog received SOME indicator that the Answerer supports BUNDLE, is the Offerer allowed to assign the SAME address to multiple m- lines within a BUNDLE group in the Offer?

I hope I got that right :)

Regards,

Christer
________________________________________
From: Martin Thomson [[email-masked]]
Sent: Monday, 09 September 2013 9:29 PM
To: Christer Holmberg
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 10 Sep 2013 10:41:14 +0200

> But, for that we could also define e.g. a feature/option-tag, so that one doesn't have to use BUNDLE just to figure out whether the other end supports it or not...

I don't like feature tags when I can get away without them.

When I have a feature tag and a feature, I have four possibilities:

- Feature tag and feature: OK.
- Feature tag and no feature: Have to remember the feature tag, 
otherwise OK.
- No feature tag and no feature: OK.
- No feature tag and feature: Bug on the other end, but I am the one who 
have to write code to detect it and do something appropriate.

Just saying "the other guy supports the feature if he uses it, otherwise 
I know nothing" is a state machine with just two states, unlike the four 
states above.
> Or, the offer when the offerer still doesn't know whether the answerer supports BUNDLE - IF there is a way for endpoints to exchange that data without actually using BUNDLE.
An one-element BUNDLE will solve that easily - and offers a hint on 
which transport it makes sense to extend to multiple m-lines.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Sep 2013 09:12:00 +0000

Hi Harald,

Nobody can prevent someone to define e.g. a feature-tag to indicate BUNDLE support, but I'd agree it's not something we should do within the BUNDLE spec :)

But, no matter how an Offerer could "know" that the Answerer supports BUNDLE, the question is still whether the Offerer is allowed to assign a shared address to multiple m- lines in an Offer, before it has received an explicit indicator *in SDP* that the answerer supports BUNDLE.

Regards,

Christer

-----Original Message-----
From: Harald Alvestrand [mailto:[email-masked]] 
Sent: 10. syyskuuta 2013 11:41
To: Christer Holmberg
Cc: Martin Thomson; [email-masked]
Subject: Re: [MMUSIC] BUNDLE DISCUSION Q6: Do we always mandate 2 Offer/Answers during session establishment?

On 09/09/2013 08:28 PM, Christer Holmberg wrote:
>> Perhaps the single m-line offer/answer performed to establish the 
>> data channel will include BUNDLE, but it would be a little redundant.
> Correct.
>

- Feature tag and feature: OK.
- Feature tag and no feature: Have to remember the feature tag, otherwise OK.
- No feature tag and no feature: OK.
- No feature tag and feature: Bug on the other end, but I am the one who have to write code to detect it and do something appropriate.

Just saying "the other guy supports the feature if he uses it, otherwise I know nothing" is a state machine with just two states, unlike the four states above.
> Or, the offer when the offerer still doesn't know whether the answerer supports BUNDLE - IF there is a way for endpoints to exchange that data without actually using BUNDLE.
An one-element BUNDLE will solve that easily - and offers a hint on which transport it makes sense to extend to multiple m-lines.