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

[Paul Kyzivat <[e-mail]>]

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:[e-mail]]
> Sent: 22 February 2016 22:14
> To: Roman Shpount <[e-mail]>; Christer Holmberg <[e-mail]>
> Cc: [e-mail]; Peter Thatcher <[e-mail]>; Ari Keränen <[e-mail]>
> 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
>> <[e-mail]
>> <mailto:[e-mail]>>
>> 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
>