Re: [MMUSIC] Do we really need TCP/DTLS/SCTP proto field?
Roman Shpount <roman@telurix.com> Mon, 20 February 2017 02:42 UTC
Return-Path: <roman@telurix.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 D3738129623 for <mmusic@ietfa.amsl.com>; Sun, 19 Feb 2017 18:42:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
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 rmHsdDlcwKTZ for <mmusic@ietfa.amsl.com>; Sun, 19 Feb 2017 18:42:21 -0800 (PST)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 8F35D129629 for <mmusic@ietf.org>; Sun, 19 Feb 2017 18:42:21 -0800 (PST)
Received: by mail-it0-x22c.google.com with SMTP id y135so12615545itc.1 for <mmusic@ietf.org>; Sun, 19 Feb 2017 18:42:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Pmkxa3L5a4x0V7EfO1JfeMA/9H4sVU810xL3f1Imbo=; b=dTIh8jM3uTAHr2guUwU+jVDgiY7mTzj4+zkCEUHVe4PxpvMDV1giWlW3vZdxsnKeO/ lbPa72N3BXA5koiXy8JC/P9xybpSHs4iH8a69T47eBuJyZkFyeXitySi0LrpXEth7TOm KTWmJxbtcg/Qs9bWYjbSraL3MCSM/W1pTIRXUBjXGBKGLR5uLtHFYOeqtAnZQbwulCkQ VMLlCsydjQkLcuJsW0EOpuB+gnD5G34ndka1Km+hKNeTjCwPAO5w8f+d6VsKazyhsnZA nau4EvXOOTI0KSrnAJkSAUr9lz5lSnbzK2cr1vr7n4jFsqFUjBAh4kQW/VxCf1wq6Yrd rX3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Pmkxa3L5a4x0V7EfO1JfeMA/9H4sVU810xL3f1Imbo=; b=MGRptD2QHz0P0L3HaeDEQxM7mTX3MCreyYTr5ymXSLsJG5KuKSu82jGx8jMeUZB3x7 uGsS9MHgY23KNV6ezQKxceSMKC71MVNBYJYlJ1dvmzlOmQ2XAA9dt+EKoofbrE59It7v mY2cLIcmx+rE/I3wwvd7awuaHMf+WLTFxvoSsFjYrer5Ry0Jo8g1UyvQQVYXBmlI9/v3 wQn7sax1nIHpOv769+oUhn56R9iNhDEBzIcWpYbEoRm8eZr5QIj05kOb+8jb5XW4dbXP Z9EOuI4k5QeynpS9cCGLEDC6z6mF1SQEP5wyjDFXCQBTa4dQ6k+q70xMNH3O/C864It6 Hp+Q==
X-Gm-Message-State: AMke39loDtwV5eQfGzotwqxpm9Qj3vuevS/kjQHqwOFrZ+4rcEqLV61eCS+jOR9SP6QzkQ==
X-Received: by 10.36.123.136 with SMTP id q130mr18893465itc.25.1487558540706; Sun, 19 Feb 2017 18:42:20 -0800 (PST)
Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id l3sm8481549ioa.31.2017.02.19.18.42.19 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Feb 2017 18:42:19 -0800 (PST)
Received: by mail-it0-f42.google.com with SMTP id y135so12615294itc.1 for <mmusic@ietf.org>; Sun, 19 Feb 2017 18:42:19 -0800 (PST)
X-Received: by 10.36.219.3 with SMTP id c3mr7694718itg.52.1487558538941; Sun, 19 Feb 2017 18:42:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.233.3 with HTTP; Sun, 19 Feb 2017 18:42:18 -0800 (PST)
In-Reply-To: <CALiegfnV97hgRHaZrV_5dFf1r5186TtDko6tCNZ3TtDCx++hMA@mail.gmail.com>
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> <CALiegfnV97hgRHaZrV_5dFf1r5186TtDko6tCNZ3TtDCx++hMA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Sun, 19 Feb 2017 21:42:18 -0500
X-Gmail-Original-Message-ID: <CAD5OKxvsrF70oxk3mw3pK4QyXYPu4Bowz658yw5jsDWthJ8Tgg@mail.gmail.com>
Message-ID: <CAD5OKxvsrF70oxk3mw3pK4QyXYPu4Bowz658yw5jsDWthJ8Tgg@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Content-Type: multipart/alternative; boundary="94eb2c05fe704c020e0548ed36ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Tq0bHz0kN3RAFuQaHPBaTdipVXE>
Cc: Ben Campbell <ben@nostrum.com>, mmusic WG <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
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: Mon, 20 Feb 2017 02:42:24 -0000
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 On Sun, Feb 19, 2017 at 7:19 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote: > 2017-02-16 18:38 GMT+01:00 Eric Rescorla <ekr@rtfm.com>: > > 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 > <ibc@aliax.net> >
- [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