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

[Suhas Nandakumar <[e-mail]>]

On Fri, May 31, 2019 at 12:08 AM Roman Shpount <[e-mail]> wrote:

> Hi Suhas,
>
> On Wed, May 29, 2019 at 10:03 PM Suhas Nandakumar <[e-mail]>
> wrote:
>
>> please see responses inline
>>
>> On Thu, May 30, 2019 at 4:34 AM Roman Shpount <[e-mail]> wrote:
>>
>>> Hi Suhas,
>>>
>>> Thank you for publishing the document. I have reviewed it and most of my
>>> comments were addressed.
>>>
>>> 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.


> Regards,
> _____________
>
> Roman Shpount
>
>