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

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 protected]> 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:[email protected]]
> *Sent:* 16 February 2017 19:38
> *To:* Roman Shpount <[email protected]>
> *Cc:* Christer Holmberg <[email protected]>; Ben Campbell <
> [email protected]>; mmusic WG <[email protected]>
>
> *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 <[email protected]> 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 <
> [email protected]> 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:[email protected]] *On Behalf Of *Ben
> Campbell
> *Sent:* 16 February 2017 17:52
> *To:* Eric Rescorla <[email protected]>
> *Cc:* mmusic WG <[email protected]>
> *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
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic