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