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

[Roman Shpount <[e-mail]>]

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.

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.

Regards,
_____________
Roman Shpount