Subject: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 07:43:49 -0800

I raised this with the authors, but maybe it is worth asking the mailing
list.

It seems like we are trending towards a world where we just ignore the
transport
component of the proto field and let ICE work things out. In that vein, I
wonder
do we really need to register/define TCP/DTLS/SCTP. It's only really useful
if
we think people will do SCTP over DTLS with TCP without ICE. Is that
actually
likely. I note that per previous discussions, JSEP already requires that
you use
UDP/DTLS/SCTP all the time:
http://rtcweb-wg.github.io/jsep/#rfc.section.5.1.2

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 15:51:01 +0000

Hi,

Note that the mechanism is also used at least by CLUE, which does not mandate ICE (or JSEP).

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 16 February 2017 17:44
To: mmusic WG <[email-masked]>; Ben Campbell <[email-masked]>
Subject: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

I raised this with the authors, but maybe it is worth asking the mailing list.

It seems like we are trending towards a world where we just ignore the transport
component of the proto field and let ICE work things out. In that vein, I wonder
do we really need to register/define TCP/DTLS/SCTP. It's only really useful if
we think people will do SCTP over DTLS with TCP without ICE. Is that actually
likely. I note that per previous discussions, JSEP already requires that you use
UDP/DTLS/SCTP all the time: http://rtcweb-wg.github.io/jsep/#rfc.section.5.1.2

-Ekr

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 16 Feb 2017 09:52:24 -0600

Process background: draft-ietf-mmusic-sctp-sdp was on today's IESG 
telechat. The draft is approved for publication, but with a point raised 
to ask the WG resolve Ekr's question.

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 16:55:53 +0000

Hi,

My suggestion is to keep the TCP/DTLS/SCTP definition.

We earlier made a choice to restrict the scope of the document (by removing plain SCTP and DTLS-over-SCTP proto values), and I think we should keep the current scope.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: 16 February 2017 17:52
To: Eric Rescorla <[email-masked]>
Cc: mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

Process background: draft-ietf-mmusic-sctp-sdp was on today's IESG telechat. The draft is approved for publication, but with a point raised to ask the WG resolve Ekr's question.

Thanks!

Ben.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Thu, 16 Feb 2017 12:16:37 -0500

The way ICE is currently defined, ICE enabled end points are supposed to
send a re-INVITE after nomination process is completed with the selected
candidate address in the m= line. So, if tcp candidate is selected,
re-INVITE must be sent with TCP/DTLS/SCTP in the m= line. Also, any
offers/answers after the ICE nomination is complete, are supposed to send
the currently selected candidate in the m= line, which will also be
TCP/DTLS/SCTP in case tcp candidate is selected.

Based on all of this, I would strongly suggest to keep TCP/DTLS/SCTP.

Regards,

_____________
Roman Shpount

On Thu, Feb 16, 2017 at 11:55 AM, Christer Holmberg <
[email-masked]> wrote:

> We earlier made a choice to restrict the scope of the document (by
> removing plain SCTP and DTLS-over-SCTP proto values), and I think we should
> keep the current scope.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Ben
> Campbell
> *Sent:* 16 February 2017 17:52
> *To:* Eric Rescorla <[email-masked]>
> *Cc:* mmusic WG <[email-masked]>
> *Subject:* Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?
>
>
>
> telechat. The draft is approved for publication, but with a point raised to
> ask the WG resolve Ekr's question.
>
> Thanks!
>
> Ben.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 09:38:05 -0800

I also think the re-INVITE is unnecessary.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 17:40:35 +0000

Hi,

It’s not only the re-INVITE, it’s ANY subsequent offer sent during the session.

However,  I think we changed that part. The draft now says that when sending an offer or answer, the m- line proto value must reflect the DEFAULT candidiate.

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]]
Sent: 16 February 2017 19:38
To: Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Ben Campbell <[email-masked]>; mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

-Ekr

On Thu, Feb 16, 2017 at 9:16 AM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
The way ICE is currently defined, ICE enabled end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m= line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP in the m= line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m= line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.

Regards,

_____________
Roman Shpount

On Thu, Feb 16, 2017 at 11:55 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: mmusic [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ben Campbell
Sent: 16 February 2017 17:52
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: mmusic WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

Thanks!

Ben.

-Ekr

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 16 Feb 2017 11:47:18 -0600

> Note that the mechanism is also used at least by CLUE, which does not 

ISTM that this argument trumps the ongoing ICE usage discussion. Am I 
missing something?

Ben.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 16 Feb 2017 12:49:20 -0500

Once nomination process is completed, it should be the selected, not the
default candidate.

When session is established or during ICE restart, multiple candidates are
sent in offer/answer and DEFAULT candidate must be used in the m= line.

Once nomination process is completed, only the currently selected candidate
is sent in offer/answer and this would be the candidate in the m= line.
Resources associated with other candidates, such as network ports or TURN
allocations, are typically released at that point, so there is no point to
include them any more.

I am all for removing the re-INVITE requirement, but we need to do it
cleanly in backwards compatible manner. In any case, this is a separate
discussion and current RFC 5245 requires it.

Regards,

_____________
Roman Shpount

On Thu, Feb 16, 2017 at 12:40 PM, Christer Holmberg <
[email-masked]> wrote:

> However,  I think we changed that part. The draft now says that when
> sending an offer or answer, the m- line proto value must reflect the
> DEFAULT candidiate.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* 16 February 2017 19:38
> *To:* Roman Shpount <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; Ben Campbell <
> [email-masked]>; mmusic WG <[email-masked]>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 17:54:03 +0000

Hi,

>Once nomination process is completed, it should be the selected, not the default >candidate.
>
>When session is established or during ICE restart, multiple candidates are sent >in offer/answer and DEFAULT candidate must be used in the m= line.
>
>Once nomination process is completed, only the currently selected candidate is >sent in offer/answer and this would be the candidate in the m= line. Resources >associated with other candidates, such as network ports or TURN allocations, >are typically released at that point, so there is no point to include them any >more.

Well, then we need to clarify the text (or remove the text completely, and simply refer to the ICE spec), because the ICE considerations section talks about offers and answers in general.

Regards,

Christer

On Thu, Feb 16, 2017 at 12:40 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 16 February 2017 19:38
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Ben Campbell <[email-masked]<mailto:[email-masked]>>; mmusic WG <[email-masked]<mailto:[email-masked]>>

-Ekr

Regards,

_____________
Roman Shpount

Regards,

Christer

Thanks!

Ben.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Feb 2017 18:19:24 -0500

> ISTM that this argument trumps the ongoing ICE usage discussion. Am I

First, lets note that TCP/DTLS/SCTP is never a desirable thing. It is 
simply a fallback for when for some reason UDP/DTLS/SCTP is impossible.

So something attempting */DTLS/SCTP without ICE would need to have some 
other knowledge that UDP was impossible. This is of course *possible*. I 
don't know how probable a use case it is for something new now that ICE 
exists.

IMO this is really another piece of evidence that we ought to have ICE 
as a transport: ICE/DTLS/SCTP.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 17 Feb 2017 11:55:19 -0600

Hi,

While it's the chairs' prerogative to judge consensus, it seems to me 
that the discussion has been somewhere between "we do need 
TCP/DTLS/SCTP" and "we might need it". Since the draft has already been 
approved by the IESG, we shouldn't make a material change unless we have 
a really good reason. I propose leaving it in.

One more comment inline:

On 16 Feb 2017, at 11:54, Christer Holmberg wrote:

>> When session is established or during ICE restart, multiple 
>> candidates are sent >in offer/answer and DEFAULT candidate must be 
>> used in the m= line.
>>
>> Once nomination process is completed, only the currently selected 
>> candidate is >sent in offer/answer and this would be the candidate in 
>> the m= line. Resources >associated with other candidates, such as 
>> network ports or TURN allocations, >are typically released at that 
>> point, so there is no point to include them any >more.
>
> Well, then we need to clarify the text (or remove the text completely, 
> and simply refer to the ICE spec), because the ICE considerations 
> section talks about offers and answers in general.

To be clear, are you talking about clarifying text in _this_ draft, or 
elsewhere?

Thanks!

Ben.

>
> Regards,
>
> Christer
>
>
>
> On Thu, Feb 16, 2017 at 12:40 PM, Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>> 
> wrote:
> Hi,
>
> Cc: Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>>; 
> Ben Campbell <[email-masked]<mailto:[email-masked]>>; mmusic WG 
> <[email-masked]<mailto:[email-masked]>>
>
> On Thu, Feb 16, 2017 at 9:16 AM, Roman Shpount 
> <[email-masked]<mailto:[email-masked]>> wrote:
> The way ICE is currently defined, ICE enabled end points are supposed 
> to send a re-INVITE after nomination process is completed with the 
> selected candidate address in the m= line. So, if tcp candidate is 
> selected, re-INVITE must be sent with TCP/DTLS/SCTP in the m= line. 
> Also, any offers/answers after the ICE nomination is complete, are 
> supposed to send the currently selected candidate in the m= line, 
> which will also be TCP/DTLS/SCTP in case tcp candidate is selected.
>
> On Thu, Feb 16, 2017 at 11:55 AM, Christer Holmberg 
> <[email-masked]<mailto:[email-masked]>> 
> wrote:
> Hi,
>
> removing plain SCTP and DTLS-over-SCTP proto values), and I think we 
> should keep the current scope.
>
> Regards,
>
> Christer
>
>
> From: mmusic 
> [mailto:[email-masked]<mailto:[email-masked]>] On 
> Behalf Of Ben Campbell
> telechat. The draft is approved for publication, but with a point 
> raised to ask the WG resolve Ekr's question.
>
> Thanks!
>
> Ben.
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 17 Feb 2017 13:26:47 -0500

On Fri, Feb 17, 2017 at 12:55 PM, Ben Campbell <[email-masked]> wrote:

> While it's the chairs' prerogative to judge consensus, it seems to me that
> the discussion has been somewhere between "we do need TCP/DTLS/SCTP" and
> "we might need it". Since the draft has already been approved by the IESG,
> we shouldn't make a material change unless we have a really good reason. I
> propose leaving it in.
>

As you have probably noticed I am strongly for leaving TCP/DTLS/SCTP in the
draft, since things will break otherwise and draft will require substantial
editing to recover.

>>> default >candidate.
>>> When session is established or during ICE restart, multiple candidates
>>> are sent >in offer/answer and DEFAULT candidate must be used in the m= line.
>>>
>>> candidate is >sent in offer/answer and this would be the candidate in the
>>> m= line. Resources >associated with other candidates, such as network ports
>>> or TURN allocations, >are typically released at that point, so there is no
>>> point to include them any >more.
>>>
>>
>> and simply refer to the ICE spec), because the ICE considerations section
>> talks about offers and answers in general.
>>
>
Christer is talking about section 12.2 of the draft-ietf-mmusic-sctp-sdp.
As the language stands right now, it is not incorrect, but is slightly
confusing, since it is talking about default candidates for all ICE related
offer/answer exchanges.  After ICE nomination process is completed, there
is only one candidate left, so there is no default. In session descriptions
that describe the session after ICE nomination is complete only one
candidate is present, so there is typically no confusion about what goes
into the m= line, but this is not spelled out in the draft. I will submit
the PR and Christer can merge and resubmit the draft when he is back.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Feb 2017 09:29:17 +0000

Hi,

I agree with Ben and Roman.

(Also, not too long ago we did discuss what is removed and what is kept in, and the draft reflects that discussion.)

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 17 February 2017 20:27
To: Ben Campbell <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?

On Fri, Feb 17, 2017 at 12:55 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:
While it's the chairs' prerogative to judge consensus, it seems to me that the discussion has been somewhere between "we do need TCP/DTLS/SCTP" and "we might need it". Since the draft has already been approved by the IESG, we shouldn't make a material change unless we have a really good reason. I propose leaving it in.

As you have probably noticed I am strongly for leaving TCP/DTLS/SCTP in the draft, since things will break otherwise and draft will require substantial editing to recover.

To be clear, are you talking about clarifying text in _this_ draft, or elsewhere?

Christer is talking about section 12.2 of the draft-ietf-mmusic-sctp-sdp. As the language stands right now, it is not incorrect, but is slightly confusing, since it is talking about default candidates for all ICE related offer/answer exchanges.  After ICE nomination process is completed, there is only one candidate left, so there is no default. In session descriptions that describe the session after ICE nomination is complete only one candidate is present, so there is typically no confusion about what goes into the m= line, but this is not spelled out in the draft. I will submit the PR and Christer can merge and resubmit the draft when he is back.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Feb 2017 09:31:47 +0000

Hi,

>Christer is talking about section 12.2 of the draft-ietf-mmusic-sctp-sdp. As the language stands right 
>now, it is not incorrect, but is slightly confusing, since it is talking about default candidates for all ICE 
>related offer/answer exchanges.  After ICE nomination process is completed, there is only one candidate 
>left, so there is no default. In session descriptions that describe the session after ICE nomination is complete
>only one candidate is present, so there is typically no confusion about what goes into the m= line, but this is 
>not spelled out in the draft. I will submit the PR and Christer can merge and resubmit the draft when he is back.

Thanks!

Also note that this is something that shall be clear in draft-ice-sip-sdp, because it's not SCTP-SDP specific. But, that's a separate issue.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Feb 2017 01:19:44 +0100

> I also think the re-INVITE is unnecessary.

Such a re-INVITE is like "hey, we have agreed on a candidate pair by
using ICE procedures and, hence, now I send you a message confirming
it to you, which is totally useless because you already know that".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Sun, 19 Feb 2017 21:42:18 -0500

As it was mentioned before, this is not only the re-INVITE caused by ICE
completion, but also any re-INVITE after ICE nomination completes. So, any
re-INVITE sent, for instance to update the codecs, which does not initiate
ICE restart will have one ICE candidate and will use the appropriate
transport in the m= line. We have a current ICE specification and this is
how it works. I agree we can update ICE SDP specification to define ICE
transport tag, which will allow us to stop all this nonsense. Until this is
done we need transport tags for both UDP and TCP ICE candidates. The
discussed draft (draft-ietf-mmusic-sctp-sdp) is not the right place to
update ICE specifications and we do want to finish it before all the ICE
updates.

Regards,
_____________
Roman Shpount