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

From: [email-masked]
Date: Mon, 27 May 2019 04:58:05 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF.

        Title           : Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)
        Authors         : Marc Petit-Huguenin
                          Suhas Nandakumar
                          Ari Keranen
	Filename        : draft-ietf-mmusic-ice-sip-sdp-28.txt
	Pages           : 42
	Date            : 2019-05-27

Abstract:
   This document describes Session Description Protocol (SDP) Offer/
   Answer procedures for carrying out Interactive Connectivity
   Establishment (ICE) between the agents.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-28
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-ice-sip-sdp-28

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-28

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 27 May 2019 17:31:33 +0530

Hello All

  Version 28 address the following issues that were discussed last week
   1. simplify ice-pac reference by not repeating the scenarios
   2. Update connection-address text to include FQDN handling
   3. Clarify ice-mismatch usages

Thanks to Christer , Roman and Bernard for active discussions and
suggesting text for inclusion. (special shout out to Roman)
Please give it  a read and let me know your thoughts.

Cheers
Suhas

On Mon, May 27, 2019 at 5:28 PM <[email-masked]> wrote:

>         Title           : Session Description Protocol (SDP) Offer/Answer
> procedures for Interactive Connectivity Establishment (ICE)
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 29 May 2019 19:03:59 -0400

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]
.*

It would also probably be helpful to include in a=ice-mismatch attribute
definition (section 4.3), that if "a=ice-mismatch" attribute is included
for the data stream, then even though both agents support ICE, ICE
procedures MUST not used for this data stream and and [RFC3264]  procedures
MUST be used instead.

Finally, an editorial nit: Please check how SDP attributes are referenced
in text (various "a=..." such as "a=candidate"). In some cases they are in
double quotes and in some cases they are used without quotes. Probably
should always be quoted.

Regards,
_____________
Roman Shpount

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 30 May 2019 07:33:24 +0530

Hi Roman

please see responses inline

On Thu, May 30, 2019 at 4:34 AM Roman Shpount <[email-masked]> 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
> 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.
> 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.
> continue its ICE processing with that transport address included.  *Alternatively,
> 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.

> procedures MUST not used for this data stream and and [RFC3264]  procedures

[Suhas] I tend to prefer to leave the procedures for a given attribute away
from the grammar definitions.

> double quotes and in some cases they are used without quotes. Probably
[Suhas] Good point. I will fix this

>>>         Title           : Session Description Protocol (SDP)
>>> Offer/Answer procedures for Interactive Connectivity Establishment (ICE)

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 May 2019 14:37:51 -0400

Hi Suhas,

>        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

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 31 May 2019 11:00:33 +0530

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

> [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

> 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.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 May 2019 17:12:08 -0400

Hi Suhas,

>        supports ICE, but that ICE processing was not used for this data
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