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

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 <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
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:ekr@rtfm.com<mailto:ekr@rtfm.com>]
Sent: 16 February 2017 19:38
To: Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>
Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>; Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>; mmusic WG <mmusic@ietf.org<mailto:mmusic@ietf.org>>

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

I also think the re-INVITE is unnecessary.

-Ekr

On Thu, Feb 16, 2017 at 9:16 AM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> 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.

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 <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
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:mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>] On Behalf Of Ben Campbell
Sent: 16 February 2017 17:52
To: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>
Cc: mmusic WG <mmusic@ietf.org<mailto:mmusic@ietf.org>>
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.

On 16 Feb 2017, at 9:43, Eric Rescorla wrote:
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

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic