Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?
"Ben Campbell" <ben@nostrum.com> Fri, 17 February 2017 17:55 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7A129AC5 for <mmusic@ietfa.amsl.com>; Fri, 17 Feb 2017 09:55:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX3cyaoe_grS for <mmusic@ietfa.amsl.com>; Fri, 17 Feb 2017 09:55:25 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846A212955C for <mmusic@ietf.org>; Fri, 17 Feb 2017 09:55:25 -0800 (PST)
Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1HHtJ0n069389 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 17 Feb 2017 11:55:20 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39]
From: Ben Campbell <ben@nostrum.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Fri, 17 Feb 2017 11:55:19 -0600
Message-ID: <18C350AD-9C5B-4723-B934-4E27DD86FB6B@nostrum.com>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4C0046CD@ESESSMB209.ericsson.se>
References: <CABcZeBOK0T5WbMLi=AS3WOAjDt_D8e8JSTp2czSYdhHv8Xcgtw@mail.gmail.com> <118E7032-775C-46D6-A76A-6DB6EA515528@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4C004589@ESESSMB209.ericsson.se> <CAD5OKxt4mBZ=RaLheOuZCp2TZuhiNZ1E9a86NL8TQ1U2kGsZeQ@mail.gmail.com> <CABcZeBOSt9B43BbNFw29fLOOwvvTTR18eK_ELmF5-carG=ouuA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C00464B@ESESSMB209.ericsson.se> <CAD5OKxvZ7xwQ6eXEFy0p-SPezaVM2XK=K5rThv1w+1Xc511FkA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C0046CD@ESESSMB209.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/XxIqPolI8ba6wkGOvv4hcGLm4FA>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Feb 2017 17:55:28 -0000
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: > 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. 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 > <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 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] Do we really need TCP/DTLS/SCTP proto fi… Eric Rescorla
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Christer Holmberg
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Ben Campbell
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Christer Holmberg
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Roman Shpount
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Eric Rescorla
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Christer Holmberg
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Ben Campbell
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Roman Shpount
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Christer Holmberg
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Paul Kyzivat
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Ben Campbell
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Roman Shpount
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Christer Holmberg
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Christer Holmberg
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Iñaki Baz Castillo
- Re: [MMUSIC] Do we really need TCP/DTLS/SCTP prot… Roman Shpount