Subject: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - ICE Interactions

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 23 Oct 2014 15:34:48 +0000

Section 11.2.1

   When an offerer or answerer assigns a unique address to a bundled
   "m=" line (excluding bundle-only "m=" lines), it MUST also assign
   unique ICE candidates [RFC5245] to the "m=" line.
Why does the answerer assign a unique address to a bundled m-line?
The m-line either bundled, then it is shared address.
Or if the answerer assigns a unique address, the m-line is not bundled.

   When an offerer or answerer assigns a shared address (i.e. a
   previously selected BUNDLE address) to one or more bundled "m=" line
   (including bundle-only "m=" lines), and when it assigns an address
   with a zero port value to one or more bundle-only "m=" lines, it MUST
   assign identical ICE candidates (referred to as shared ICE
   candidates) to each of those "m=" lines.

What are these identical ICE candidates? 
Are these the unique ICE candidates from the 1st para?
Are these additional candidates that reflect the port zero in that m-line?
I.e. are they introduced in order to not create an ICE-mismatch for the bundle-only m-lines?

Section 11.2.3
   When an answerer generates an answer, which contains a BUNDLE group,
   the answerer MUST assign shared ICE candidates to each bundled "m="
   line (including "m=" lines that were indicated as bundle-only in the
   associated offer) in the answer.
Does this mean that the answerer copies of all candidates into every m-line of a BUNDLE?
If the ICE candidates are shared, wouldn't it be sufficient to include them only once?

An example for all this would certainly worthwhile.
The interactions quite complex and seems to require more text, to make what needs to be done.

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Oct 2014 16:31:26 +0000

Hi,

> Or if the answerer assigns a unique address, the m-line is not bundled.

Unique addresses must be used in the initial offer, before it is known whether the answerer supports BUNDLE.

---------------------------------

> What are these identical ICE candidates? 

The ICE candidate values are identical.

> Are these the unique ICE candidates from the 1st para?

It is the ICE candidate associated with the m- line that was selected for the offerer BUNDLE address.

---------------------------------

> If the ICE candidates are shared, wouldn't it be sufficient to include them only once?

I believe this was discussed quite a while ago, and the outcome was that we should not use assign candidate values in an implicit way.

Regards,

Christer

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 24 Oct 2014 13:44:04 +0000

Christer,

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Donnerstag, 23. Oktober 2014 18:31
> To: Stach, Thomas
> Cc: 'mmusic'
> Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 -
> ICE Interactions
> 
> Hi,
> 
> > Section 11.2.1
> >
[TS] Certainly true for the offer, but I asked about the answer.
Here is my reasoning with corrected grammar:
The m-line is either bundled, then a shared address was assigned by the answerer.
Or if the answerer assigned a unique address, then the m-line is not bundled.

[TS] Then the candidates for all m-lines in the BUNDLE are identical to these. 
But what happens due to the bundle-only m-lines that carry port zero?
You will not have a default candidate that matches port zero in the m-line.
Wouldn't this result in an ICE-mismatch for all these m-lines if you follow the RFC5245 rules blindly?

I see various ways how this could be addressed: 
by stating an exemption from the 5245 rules for bundle-only m-linesor 
adding an additional candidate with port 0 to bundle-only m-lines or 
just omitting the candidates complete from a bundle-only m-line.
In the latter case, a non-BUNDLE answerer would ignore that m-line in the offer anyhow 
and an answerer in support of BUNDLE would know how to deal with it (based on some text that we would still need to provide).

> > Does this mean that the answerer copies of all candidates into every m-line
> of a
> > BUNDLE?
> >
> I believe this was discussed quite a while ago, and the outcome was that we
> should not use assign candidate values in an implicit way.
[TS] I'll look it up. It might be good to include the reasons in the text to avoid repeated questions.
Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Oct 2014 15:28:02 +0000

Hi,

>Or if the answerer assigned a unique address, then the m-line is not bundled.

Aaah... I hear you. The text is a general statement, but there are no cases where the answerer would assign a unique address to a bundled m- line.

So, I can modify the text, and remove "or answerer".

>Wouldn't this result in an ICE-mismatch for all these m-lines if you follow the >RFC5245 rules blindly?
>
>by stating an exemption from the 5245 rules for bundle-only m-linesor adding an >additional candidate with port 0 to bundle-only m-lines or just omitting the >candidates complete from a bundle-only m-line.
>In the latter case, a non-BUNDLE answerer would ignore that m-line in the offer >anyhow and an answerer in support of BUNDLE would know how to deal with it >(based on some text that we would still need to provide).

When the offerer assigns a shared address, the usage of BUNDLE has already been negotiated. So, in that case we perhaps don't need to assign port zero to new bundle-only m- lines - it is enough to assign the bundle-only attribute.

But, when you send the initial offer, with unique addresses, the bundle-only m- lines will contain port zero. 

>> I believe this was discussed quite a while ago, and the outcome was 
>> that we should not use assign candidate values in an implicit way.

I think the general reason for not having implicit information is to avoid problems with intermediaries.

Regards,

Christer