IETF Logo Mail Archive

Re: [rtcweb] Default proto transport in JSEP

Iñaki Baz Castillo <ibc@aliax.net> Mon, 19 November 2018 20:09 UTC

Return-Path: <ibc@aliax.net>
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 E39C8130DE2 for <rtcweb@ietfa.amsl.com>; Mon, 19 Nov 2018 12:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 f7w8EJTtBl92 for <rtcweb@ietfa.amsl.com>; Mon, 19 Nov 2018 12:09:03 -0800 (PST)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 32FC01292F1 for <rtcweb@ietf.org>; Mon, 19 Nov 2018 12:09:03 -0800 (PST)
Received: by mail-vs1-xe2b.google.com with SMTP id e7so18552545vsc.2 for <rtcweb@ietf.org>; Mon, 19 Nov 2018 12:09:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1hLCtoimb8ovhqCv6C0c8u1SNyWBh72D7RHqtj/keTQ=; b=enL9vXPDMlaxemIbKQG69jELKJNV3SKqqy++5tWEY52KjAQNbKfTLYIstK0NgSpP8l 7wF2IFMVlCV/rQHZ1G3Ke+nWrHmoh3xvhNscAmlOTGzpBKKIF8fEQv+833hCq6JJqybq Zd3FihYyqgYi4DufdQPfppyjXaw0bzxmcMtMv8cM27QxBG1bMYSpOIEVO06J0dYYudSl HP074YyhMRIFcqvNevT/an0TeM3VEXIQ6gyV2z3Q7KBDO/FhvrptU64iJ0ajA0z48NP6 gNp95MNOQTxkKiClzuDF/beonMgPgIQERwY1Y9752R9YuACuEEgyy4R4I8dC2rrykMCQ K9sg==
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:content-transfer-encoding; bh=1hLCtoimb8ovhqCv6C0c8u1SNyWBh72D7RHqtj/keTQ=; b=g/DYmwtV6iW2sEgy3IlHbwtGP2gnJCpmAYnXrtYCavvwBBAbljpxGTig+qICK1fr+s NFyigAZE7NW7J8H/NoiAIkc6IiVYimVfaJQwuVQrSdqg6ddrUMkSEy31uBQ53yUw4WnR XRRKauJPWW8oods6OjAMFWpAVXPpfshZZogFce8O6B1ZK3xr8tzKhtykf6pttXwQaQPO WAzuDjb2xONhD2XopdSgjeqfXjca0Jl1qOcqv5EMSUX89sXT6ytrw4M3gTAxU4d1K8Dv ZlnrtSBh3MG7VVh++nXXxAzwxxPwRvbWY5yKR/kB59SsC7zu/VApvP/+XXB7eniULlVc oPtA==
X-Gm-Message-State: AGRZ1gKVIaoflGrEiHjJIjz2jI+Bpokw87rR7uAmLDoRAhofTShs9Q8d XmqWxMK+IDqJHzUlz3A7hy9rCaMKM3Nne06lveBb2A==
X-Google-Smtp-Source: AJdET5co2YONHmuymQOYfUtFJzXvQ1X+xvBzOCSOiAfX9bNh/iW2/f63oCiHnAr6taBc4G9LnzOEyQs6g+Zi2yXkDdk=
X-Received: by 2002:a67:7106:: with SMTP id m6mr9669607vsc.67.1542658141919; Mon, 19 Nov 2018 12:09:01 -0800 (PST)
MIME-Version: 1.0
References: <CA+9kkMADnZJBaV0hfLuwGU0bGBEP5tCPZ=8Zd_85Dgzi37ghAQ@mail.gmail.com> <CAD5OKxsNFFmER__H0+5Mzts58yn9cWLMEADhSnLR4nreKD9WAQ@mail.gmail.com> <CALiegfkHXv6f8P3C-C=2RKCyxWfzCAzkzOqxBXmmsNCPrZzFfg@mail.gmail.com> <CAD5OKxswZdGm1CYvy=NoyEtN-eFFp7Sc8mmGT7jAJ-q3msJYXA@mail.gmail.com>
In-Reply-To: <CAD5OKxswZdGm1CYvy=NoyEtN-eFFp7Sc8mmGT7jAJ-q3msJYXA@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 19 Nov 2018 21:08:50 +0100
Message-ID: <CALiegfmFV=988+WuViUQRGJRgR=mcqS9Y+eDnL4pH6VrbJRvCQ@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: rtcweb@ietf.org, mmusic@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/M3MAbfR_3oWqyiZVW8nebVfDKAw>
Subject: Re: [rtcweb] 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: Mon, 19 Nov 2018 20:09:05 -0000

On Mon, 19 Nov 2018 at 21:02, Roman Shpount <roman@telurix.com> wrote:
>
> On Mon, Nov 19, 2018 at 2:36 PM Iñaki Baz Castillo <ibc@aliax.net> wrote:
>> We could just assume that no WebRTC capable endpoint will (absolutely
>> never) rely on the content of the c= line or the proto indicated in
>> the m= line (no matter it indicates "CHICKEN" as proto).
>
> This is incorrect. Only the transport part of the proto line does not matter since it is overwritten by the ICE candidate. The rest of the proto is needed to know if this m= line is audio, video, or data channel.

Yes, I just meant the "proto" component.


> In any case, this is about interop with existing (and already WebRTC compatible) implementations. At this point, I would be happy, if either c= and m= line were populated by some constant data

If it's an already WebRTC compatible device, then it does not need to
read the IP in c= nor the proto in m=.


> or modified based on rules which serve some purpose like legacy interop.

Which interop? If a peer is WebRTC compatible then it MUST use ICE, so
whatever is written in the c= line and whatever the m= protoo is, it
won't need to read it. And if the other party is "legacy" and does not
implement WebRTC, then they both just can not communicate.

So this is just cosmetic and has zero value. And there are endless
discussions about this topic for the last 3-4 years just because those
fields exist in the SDP.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email