IETF Logo Mail Archive

Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

Roman Shpount <roman@telurix.com> Wed, 28 November 2018 16:57 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E527F130E88 for <rtcweb@ietfa.amsl.com>; Wed, 28 Nov 2018 08:57:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.347
X-Spam-Level:
X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 pxrGNO5TM4AG for <rtcweb@ietfa.amsl.com>; Wed, 28 Nov 2018 08:57:26 -0800 (PST)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 9D1BB130E72 for <rtcweb@ietf.org>; Wed, 28 Nov 2018 08:57:26 -0800 (PST)
Received: by mail-pg1-x52d.google.com with SMTP id d72so9744945pga.9 for <rtcweb@ietf.org>; Wed, 28 Nov 2018 08:57:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mSRpCMsmgdpyplRCPGUB0xBEmk2a7sdI7jIvTNkML1A=; b=PoHIqzIRo/Vz5EQnjJJD8at5U9Gw3ldGLLzXjLFNeJ9+XvC5xM1G+tO+Tj3ps9xT24 +EOM2AdC8qaZMLHMRMmkDkIsdFlF/HFNA1ZYf7H22mmOFA5bt30VyLzdcMylgQ1P3aHH zXYcEN0wZiksDWsZywm7bov8eh+0JYsZJ07OJcbZ5OJ0myAH4Dx6NDiN+Yx6w1JV03b4 Nf+NG+v8y2xp8VcZtkQpse+XvXyITKp/dV5vXRfBccy6BgAA87sizsMbjS8uESehWH2B rLRDqsD1C5yPxxvEt+2HgJidLhNdW8i9okmAILTQ2UC/6mDw2mSMK4BE7vvX2NIaGc7F a8og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mSRpCMsmgdpyplRCPGUB0xBEmk2a7sdI7jIvTNkML1A=; b=LbNsWECUYqpf0bxHlsYDRPE7ql8EOY9mmXcjCvqD+n22nzgxxsA1pkbiC1xz/KDk9d wqZV5S9sk1UZ/P8Eo+yyM8kAJbCwA0QwX1ldmtiiIOztOfFrXMSD3eaEU+qzaPa6L6jh 2bmdpBJA+RUAvO8Voel80DCZN2neq6Yc1J0JeDIKymPHbqbSS4GlcINuLKQRkPnciCaj qcFWhe+xlghQL4FZmWF5gyOwgiVT9EcUCGU/YnNiuO9tuVwA6YCdFg8RS2Iqt/itri3F wTfnHW4hdQBBCbtP4xTyC9O6GqkA2e78GYnq/xFvbQCmcrnSvKYkFl5DU1U8/tIdoQvn 7wlg==
X-Gm-Message-State: AA+aEWYvPRzm/ExTyKCL7k0D7UWdp2iXinZAA7AwVz5pfUztbQwnx2lS lJ9LHkQSq0+A7WbRpVlPTWvmqaa859Q=
X-Google-Smtp-Source: AFSGD/XDhQ3dwJAl0Y5VnoW8Qsd0HHgXtuLr5vQrJnIptxon7MqWh/2EpQY19kbX4hk41aTQ/ncEkQ==
X-Received: by 2002:a62:6b85:: with SMTP id g127mr11107344pfc.42.1543424246150; Wed, 28 Nov 2018 08:57:26 -0800 (PST)
Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com. [209.85.210.182]) by smtp.gmail.com with ESMTPSA id w11sm7309429pgk.16.2018.11.28.08.57.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 08:57:25 -0800 (PST)
Received: by mail-pf1-f182.google.com with SMTP id c72so10448164pfc.6; Wed, 28 Nov 2018 08:57:24 -0800 (PST)
X-Received: by 2002:a63:b4c:: with SMTP id a12mr34432396pgl.131.1543424244652; Wed, 28 Nov 2018 08:57:24 -0800 (PST)
MIME-Version: 1.0
References: <CA+9kkMADnZJBaV0hfLuwGU0bGBEP5tCPZ=8Zd_85Dgzi37ghAQ@mail.gmail.com> <CAD5OKxsNFFmER__H0+5Mzts58yn9cWLMEADhSnLR4nreKD9WAQ@mail.gmail.com> <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <CAD5OKxv9r08RLvMSM4h11A6sXU9E=u_8Qvy-TBfjNcwkhcqf3w@mail.gmail.com> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> <CAD5OKxut5Lr+Bmyc20y+vV=+_RESw+h72DYLnt3G1_BjS6sTVA@mail.gmail.com> <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca>
In-Reply-To: <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca>
From: Roman Shpount <roman@telurix.com>
Date: Wed, 28 Nov 2018 11:57:13 -0500
X-Gmail-Original-Message-ID: <CAD5OKxv0N+TF3L3bB9KPm4vqQdPZKE=1zkdw1PaV7CpNJ2kYaQ@mail.gmail.com>
Message-ID: <CAD5OKxv0N+TF3L3bB9KPm4vqQdPZKE=1zkdw1PaV7CpNJ2kYaQ@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: lemming Andreasen <fandreas@cisco.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d72304057bbc75db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/-2TduZErdojzVTpIvjjyncRMX_E>
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2018 16:57:29 -0000

On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <fluffy@iii.ca> wrote:

> On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> wrote:
>
>  I suggest to update JSEP section 5.1.2 to match the rest of the
> documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE
> restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto
> MUST be used if default (only) candidate is a UDP candidate and
> "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is TCP
> candidate.
>
>
> I don’t see any real befits to implementations to this change and I don’t
> think the rtcweb consensus was around the currently solution. Do you see
> some advantage to implementations to this?
>

This is what every other document related to ICE, including JSEP section
5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB
need a really good reason why it needs to be different.

Also, if we are not going to do this, then every ICE implementation for
RTCWEB would be different from every other ICE implementation. For
instance, without this change, when ICE TCP candidate is selected, WebRTC
compliant implementation MUST use UDP/TLS/RTP/SAVPF in subsequent
offer/answer exchanges, but it MUST use TCP/TLS/RTP/SAVPF in the same case
when communicating with VoIP phone. It would be very hard to change this
behavior in ice-sip-sdp, since it will make it incompatible with RFC5245m
so this difference is likely to be permanent.

Regards,
_____________
Roman Shpount

v2.28.0 | Report a Bug | By Email | System Status