Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-28.txt

[Suhas Nandakumar <[e-mail]>]

Hi Roman

   I see your point. Will update to clarify the answerer behvaior as
suggested.

Thanks
Suhas

On Sat, Jun 1, 2019 at 2:42 AM Roman Shpount <[e-mail]> wrote:

> Hi Suhas,
>
> On Fri, May 31, 2019 at 1:30 AM Suhas Nandakumar <[e-mail]>
> wrote:
>
>> On Fri, May 31, 2019 at 12:08 AM Roman Shpount <[e-mail]> wrote:
>>
>>> On Wed, May 29, 2019 at 10:03 PM Suhas Nandakumar <[e-mail]>
>>> wrote:
>>>
>>>> On Thu, May 30, 2019 at 4:34 AM Roman Shpount <[e-mail]>
>>>> wrote:
>>>>
>>>>> One of the remaining issues is in Section 3.2.5. Since you have
>>>>> removed the note that "If this condition is not met, the agents MUST
>>>>> process the SDP based on normal [RFC3264] procedures, without using any of
>>>>> the ICE mechanisms described in the remainder of this specification", the
>>>>> document no longer states what happens when "a=ice-mismatch" attribute is
>>>>> included in the answer.
>>>>>
>>>>> To clarify this we need to change current text that states:
>>>>>
>>>>> The presence of certain application layer gateways MAY modify the
>>>>> transport address information as described in Section 8.2.2.  The behavior
>>>>> of the responding agent in such a situation is implementation defined.
>>>>> Informally, the responding agent MAY consider the mismatched transport
>>>>> address information as a plausible new candidate learnt from the peer and
>>>>> continue its ICE processing with that transport address included.
>>>>> Alternatively, the responding agent MAY include an "a=ice-mismatch"
>>>>> attribute in its answer and MAY also omit a=candidate attributes for such
>>>>> data streams.
>>>>>
>>>>>
>>>>> To the following:
>>>>>
>>>>> The presence of certain application layer gateways MAY modify the
>>>>> transport address information as described in Section 8.2.2.  The behavior
>>>>> of the responding agent in such a situation is implementation defined.
>>>>> Informally, the responding agent MAY consider the mismatched transport
>>>>> address information as a plausible new candidate learnt from the peer and
>>>>> continue its ICE processing with that transport address included.  *Alternatively,
>>>>> the responding agent MAY include an "a=ice-mismatch" attribute in its
>>>>> answer for such data streams.  If agent chooses to include an
>>>>> "a=ice-mismatch" attribute in its answer for a data stream, then it MUST
>>>>> also, for this data stream, omit "a=candidate" attributes, MUST terminate
>>>>> the usage of ICE procedures, and MUST instead use **procedures
>>>>> defined in **[RFC3264]  .*
>>>>>
>>>>>
>>>>>
>>>> The point 3 in that para covers this aspect. So this section as a whole
>>>> covers the scenarios you describe above.
>>>>
>>>> 3.  In some cases, controlling/initiator agent may receive the SDP
>>>>        answer that may omit "a=candidate" attributes for the data
>>>>        stream, and instead include a media level "a=ice-mismatch"
>>>>        attribute.  This signals to the offerer that the answerer
>>>>        supports ICE, but that ICE processing was not used for this data
>>>>        stream.  In this case, ICE processing MUST be terminated for this
>>>>        data stream and [RFC3264] procedures MUST be followed instead.
>>>>
>>>>
>>> There are couple of issues with the current text:
>>>
>>> 1. Reading the current text reader might assume that it is acceptable to
>>> include a=ice-mismatch and still include a=candidate in the data stream in
>>> the answer. This is not the case.
>>>
>>> [Suhas] Also for this, i see point 3 covers this
>>
>>  In some cases, controlling/initiator agent may receive the SDP
>>        answer that may omit "a=candidate" attributes for the data
>>        stream, and instead include a media level "a=ice-mismatch"
>>        attribute
>>
>>
>>
>>
>>> 2. The text in point 3 states that offerer is not going to use ICE
>>> procedures for the data stream which includes a=ice-mismatch and will use
>>> RFC3264 instead. Nothing specifies that the answerer is supposed to stop
>>> using ICE procedures when including a=ice-mismatch.
>>>
>>
>>
>> (Suhas) Doesn’t this piece in point 3 say exactly that behavior on the
>> answerer side when it sets ice-mismatch for a data stream
>>
>> This signals to the offerer that the answerer
>>        supports ICE, but that ICE processing was not used for this data
>>        stream.
>>
>>
>>>
> Once again, this tells how the answer is supposed to be interpreted, but
> you have removed the language that specified what responding agent is
> supposed to do. There is nothing in the current document that says that
> agent which generates the answer with "a=ice-mismatch" MUST stop using ICE
> for this specific data stream. Also, current language says that "the
> responding agent MAY include an "a=ice-mismatch" attribute in its answer
> and MAY also omit a=candidate attributes for such data streams", which I
> would interpret that responding agent MAY include "a=ice-mismatch" and not
> omit "a=candidate". Behavior of the agent that receives an m= line with
> both "a=ice-mismatch" and  "a=candidate" is also unspecified. It should be
> illegal to generates such session descriptions.
>
> Regards,
> _____________
> Roman Shpount
>
>