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

[Roman Shpount <[e-mail]>]

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