Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text episode II

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Feb 2016 19:13:14 +0000

New try...

(Note that I have also replaced the reference to RFC 5245 with a reference to draft-5245bis)

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

11.  ICE Considerations

11.1.  General

   This section describes how to use the BUNDLE grouping extension
   together with the Interactive Connectivity Establishment (ICE)
   mechanism [I-D.ietf-ice-rfc5245bis].

   The generic procedures for negotiating usage of ICE using SDP,
   defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE
   with BUNDLE, with the following exceptions:

   o  When BUNDLE addresses for a BUNDLE group have been selected for
      both endpoints, ICE connectivity checks and keep-alives only need
      to be performed for the whole BUNDLE group, instead of per bundled
      "m=" line.

   o  Among bundled "m=" lines with which the offerer has associated a
      shared address, the offerer only associates ICE-related media-
      level SDP attributes with the "m=" line associated with the
      offerer BUNDLE-tag.

   o  Among bundled "m=" lines with which the answerer has associated a
      shared address, the answerer only associates ICE-related media-
      level SDP attributes with the "m=" line associated with the
      answerer BUNDLE-tag.

   Support and usage of ICE mechanism together with the BUNDLE extension
   is OPTIONAL.

11.2.  SDP Offer/Answer Procedures

11.2.1.  General

   When an offerer associates a unique address with a bundled "m=" line
   (excluding any bundle-only "m=" line), the offerer MUST associate SDP
   'candidate' attributes (and other applicable ICE-related media-level
   SDP attributes), containing unique ICE properties (candidates etc),
   with the "m=" line, according to the procedures in
   [I-D.ietf-mmusic-ice-sip-sdp].

   When an offerer associates a shared address with a bundled "m="
   lines, if the "m=" line is associated with the offerer BUNDLE-tag,
   the offerer MUST associate SDP 'candidate' attributes (and other
   applicable ICE-related media-level SDP attributes), containing shared
   ICE properties, with the "m=" line.  If the "m=" line is not
   associated with the offerer BUNDLE-tag, the offerer MUST NOT
   associate ICE-related SDP attributes with the "m=" line.

   When an answerer associates a shared address with a bundled "m="
   lines, if the "m=" line is associated with the answerer BUNDLE-tag,
   the answerer MUST associate SDP 'candidate' attributes (and other
   applicable ICE-related media-level SDP attributes), containing shared
   ICE properties, with the "m=" line.  If the "m=" line is not
   associated with the answerer BUNDLE-tag, the answerer MUST NOT
   associate ICE-related SDP attributes with the "m=" line.

   NOTE: As bundled "m=" lines associated with a shared address will
   share the same ICE properties, there is no need to associated ICE-
   related media-level SDP attributes with each "m=" line.

   NOTE: The following ICE-related media-level SDP attributes are
   defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote-
   candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-
   pacing'.

11.2.2.  Generating the Initial SDP Offer

   When an offerer generates an initial offer, the offerer MUST
   associate ICE-related media-level SDP attributes with each bundled
   "m=" line, according to [Section 11.2.1].

11.2.3.  Generating the SDP Answer

   When an answerer generates an answer that contains a BUNDLE group,
   the answerer MUST associated ICE-related SDP attributes with the "m="
   line associated with the answerer BUNDLE-tag, according to
   [Section 11.2.1].

11.2.4.  Offerer Processing of the SDP Answer

   When an offerer receives an answer, if the answerer supports and uses
   the ICE mechanism and the BUNDLE extension, the offerer MUST
   associate the ICE properties associated with the offerer BUNDLE
   address, selected by the answerer [Section 8.3.2], with each bundled
   "m=" line.

11.2.5.  Modifying the Session

   When an offerer generates a subsequent offer, it MUST associated
   unique or shared ICE properties to one or more bundled "m=" lines,
   according to [Section 11.2.1].

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

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 22 February 2016 22:25
To: Christer Holmberg <[email-masked]>; Roman Shpount <[email-masked]>
Cc: [email-masked]; Peter Thatcher <[email-masked]>; Ari Keränen <[email-masked]>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - suggested text

On 2/22/16 3:18 PM, Christer Holmberg wrote:
> Hi Paul,
>
> I am trying to follow the same style as BUNDLE in general. Yes, I know it's messy, and I've lost count of the number of times I've had to re-write everything, but I am not going to do it again.

Yes, I understand, and appreciate how difficult it has been to get something that everyone can understand and agree with.

> Now, I did put together the new ICE text rather quickly, so there may be some mistakes, though.

I *think* it is only the one place that is problematic, and I think it is in new text. And since it is the one that has different meaning than the others, changing the wording for it shouldn't disrupt anything else.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 22 February 2016 22:14
> To: Roman Shpount <[email-masked]>; Christer Holmberg 
> <[email-masked]>
> Cc: [email-masked]; Peter Thatcher <[email-masked]>; Ari 
> Keränen <[email-masked]>
> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE - 
> suggested text
>
> Christer,
>
> [I'm replying to Christer, not Roman. For some reason I can't find 
> Christer's original message in my email.]
>
> This generally seems good to me. I noticed one thing:
>
> While I understand the intent, you are using "associate", "associates"
> or "associated" in multiple ways, that may be confusing to some readers.
> E.g.:
>
>      o  Among bundled "m=" lines with which the offerer has associated a
>         shared address, the offerer only associates ICE-related media-
>         level SDP attributes with the "m=" line associated with the
>         offerer BUNDLE-tag.
> ...
>      NOTE: The bundle-only "m=" line, if accepted by the answerer, will
>      inherit the candidates associated with the selected offerer BUNDLE
>      address.  An answerer that does not support BUNDLE would not accept a
>      bundle-only "m=" line.
> ...
>      When an offerer or answerer associates a shared address (i.e. a
>      previously selected BUNDLE address) with one or more bundled "m="
>      lines, the offerer (or answerer) MUST only associate SDP 'candidate'
>      attributes with the "m=" line associated with the offerer BUNDLE-tag
>      (or the answerer BUNDLE-tag) address).  The offerer or answerer MUST
>      NOT associate 'candidiate' attributes with any other bundled "m="
>      line to which the offerer (or answerer) associates a shared address.
> ...
>      When an offerer receives an answer, if the answerer supports and uses
>      the ICE mechanism and the BUNDLE extension, the offerer MUST
>      associate the same ICE candidates, associated with the "m=" line
>      representing the offerer BUNDLE address (selected by the answerer),
>      with each bundled "m=" line.
>
> So, which one of these things is not like the others? (This is a game 
> we play with kids. Do they do it in Sweden too?)
>
> In most cases this is talking about where you put things in the SDP. But the last one above isn't that - it is about the implementation taking data from the answer and using it to update internal data structures.
>
> I don't have a specific suggestion for improving it. But I think it 
> would be good to use someting other that "associate" in this case. I
> *think* it is the only place where it is used this way.
>
> 	Thanks,
> 	Paul
>
>
> On 2/22/16 2:29 PM, Roman Shpount wrote:
>> On Mon, Feb 22, 2016 at 5:10 AM, Christer Holmberg 
>> <[email-masked] 
>> <mailto:[email-masked]>>
>> wrote:
>>
>>      Assuming we will only associated ICE candidates to the “m=” line
>>      associated with the offerer/answerer BUNDLE-tag, below is a first
>>      suggested of modified ‘ICE Considerations’ text:
>>
>>      __ __
>>
>>      -----------------------____
>>
>>      __ __
>>
>>      11.  ICE Considerations____
>>
>>      __ __
>>
>>      11.1.  General____
>>
>>      __ __
>>
>>          This section describes how to use the BUNDLE grouping 
>> extension____
>>
>>          together with the Interactive Connectivity Establishment 
>> (ICE)____
>>
>>          mechanism [RFC5245].____
>>
>>      __ __
>>
>>          The generic procedures for negotiating usage of ICE using 
>> SDP,____
>>
>>          defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of
>>      ICE____
>>
>>          with BUNDLE, with the following exceptions:____
>>
>>      __ __
>>
>>          o  When BUNDLE addresses for a BUNDLE group have been selected
>>      for____
>>
>>             both endpoints, ICE connectivity checks and keep-alives only
>>      need____
>>
>>             to be performed for the whole BUNDLE group, instead of per
>>      bundled____
>>
>>             "m=" line.____
>>
>>      __ __
>>
>>          o  Among bundled "m=" lines with which the offerer has
>>      associated a____
>>
>>             shared address, the offerer only associates ICE-related
>>      media-____
>>
>>             level SDP attributes with the "m=" line associated with 
>> the____
>>
>>             offerer BUNDLE-tag.____
>>
>>      __ __
>>
>>          o  Among bundled "m=" lines with which the answerer has
>>      associated a____
>>
>>             shared address, the answerer only associates ICE-related
>>      media-____
>>
>>             level SDP attributes with the "m=" line associated with 
>> the____
>>
>>             answerer BUNDLE-tag.____
>>
>>      __ __
>>
>>          Support and usage of ICE mechanism together with the BUNDLE
>>      extension____
>>
>>          is OPTIONAL.____
>>
>>      __ __
>>
>>      11.2.  SDP Offer/Answer Procedures____
>>
>>      __ __
>>
>>      11.2.1.  General____
>>
>>      __ __
>>
>>          When an offerer associates a unique address with a bundled "m="
>>      line____
>>
>>          (excluding any bundle-only "m=" line), it MUST also associate
>>      unique____
>>
>>          ICE candidates to the "m=" line, according to the procedures 
>> in____
>>
>>          [I-D.ietf-mmusic-ice-sip-sdp].____
>>
>>      __ __
>>
>>          An offerer MUST NOT associate ICE candidates with a bundle-only
>>      "m="____
>>
>>          line with a zero port value.____
>>
>>      __ __
>>
>>          NOTE: The bundle-only "m=" line, if accepted by the answerer,
>>      will____
>>
>>          inherit the candidates associated with the selected offerer
>>      BUNDLE____
>>
>>          address.  An answerer that does not support BUNDLE would not
>>      accept a____
>>
>>          bundle-only "m=" line.____
>>
>>      __ __
>>
>>          When an offerer or answerer associates a shared address (i.e.
>> a____
>>
>>          previously selected BUNDLE address) with one or more bundled
>>      "m="____
>>
>>          lines, the offerer (or answerer) MUST only associate SDP
>>      'candidate'____
>>
>>          attributes with the "m=" line associated with the offerer
>>      BUNDLE-tag____
>>
>>          (or the answerer BUNDLE-tag) address).  The offerer or answerer
>>      MUST____
>>
>>          NOT associate 'candidiate' attributes with any other bundled
>>      "m="____
>>
>>          line to which the offerer (or answerer) associates a shared
>>      address.____
>>
>>          This also apply to any other ICE-related media-level SDP
>>      attribute.____
>>
>>      __ __
>>
>>          NOTE: The following ICE-related media-level SDP attributes 
>> are____
>>
>>          defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 
>> 'remote-____
>>
>>          candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 
>> 'ice-____
>>
>>          pacing'.____
>>
>>      __ __
>>
>>      11.2.2.  Generating the Initial SDP Offer____
>>
>>      __ __
>>
>>          When an offerer generates an initial offer, it associates unique
>>      ICE____
>>
>>          candidates with the bundled "m=" lines, according to Section
>>      11.2.1.____
>>
>>      __ __
>>
>>      11.2.3.  Generating the SDP Answer____
>>
>>      __ __
>>
>>          When an answerer generates an answer that contains a BUNDLE
>>      group,____
>>
>>          the answerer MUST only associate SDP 'candidate' attributes 
>> (and____
>>
>>          other ICE-related media-level SDP attributes) with the "m="
>> line____
>>
>>          associated with the answerer BUNDLE-tag.____
>>
>>      __ __
>>
>>      11.2.4.  Offerer Processing of the SDP Answer____
>>
>>      __ __
>>
>>          When an offerer receives an answer, if the answerer supports and
>>      uses____
>>
>>          the ICE mechanism and the BUNDLE extension, the offerer 
>> MUST____
>>
>>          associate the same ICE candidates, associated with the "m="
>> line____
>>
>>          representing the offerer BUNDLE address (selected by the
>>      answerer),____
>>
>>          with each bundled "m=" line.____
>>
>>      __ __
>>
>>      11.2.5.  Modifying the Session____
>>
>>      __ __
>>
>>          When an offerer generates a subsequent offer, it associates
>>      unique or____
>>
>>          shared ICE candidates with the bundled "m=" lines, according 
>> to____
>>
>>          (Section 11.2.1).____
>>
>>
>>
>> I am not 100% sure about what exactly is meant by ICE candidate being 
>> associated with an m= line. Does this mean ICE candidate is created 
>> for this m= line and "candidate" SDP attribute is included in this m= line?
>>
>> Overall the text is good, but I would explicitly replace "ICE 
>> candidates" with "ICE candidates or any other ICE-related media-level 
>> SDP attributes" to avoid any potential confusion. This will also make 
>> the phrase "This also apply to any other ICE-related media-level SDP 
>> attribute" unnecessary.
>> _____________
>> Roman Shpount
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2016 16:15:34 -0500

Looks ok to me.

Nit: multiple places use 'a bundled "m=" lines'. That doesn't read 
right. I think it should be just 'bundled "m=" lines'.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2016 08:07:03 +0000

Hi,

>Looks ok to me.
>
>Nit: multiple places use 'a bundled "m=" lines'. That doesn't read right. I think it should be just 'bundled "m=" lines'.

Correct.

Thanks!

Regards,

Christer

On 2/23/16 2:13 PM, Christer Holmberg wrote:
>>>           ICE candidates to the "m=" line, according to the 
>>> procedures in____
>>>
>>>           the answerer MUST only associate SDP 'candidate' 
>>> attributes (and____
>>>
>>>           shared ICE candidates with the bundled "m=" lines, 
>>> according to____
>>>
>>>           (Section 11.2.1).____
>>>
>>>
>>>
>>> I am not 100% sure about what exactly is meant by ICE candidate 
>>> being associated with an m= line. Does this mean ICE candidate is 
>>> created for this m= line and "candidate" SDP attribute is included in this m= line?
>>>
>>> candidates" with "ICE candidates or any other ICE-related 
>>> media-level SDP attributes" to avoid any potential confusion. This 
>>> will also make the phrase "This also apply to any other ICE-related 
>>> media-level SDP attribute" unnecessary.
>>> _____________
>>> Roman Shpount
>>
>