IETF Logo Mail Archive

Re: [MMUSIC] [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: 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 2E680128D0C for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2018 12:09:06 -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=unavailable 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 0FJZXha0ktZg for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2018 12:09:04 -0800 (PST)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 52BB212F1AB for <mmusic@ietf.org>; Mon, 19 Nov 2018 12:09:03 -0800 (PST)
Received: by mail-vs1-xe32.google.com with SMTP id y27so18583426vsi.1 for <mmusic@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=p40yuuUTlBO0VlR62olGfHZ7y2M47rbSaVrYXVMHWRfi1X3jcWbis5qKgHtNgUDHfz FEgoPQ57/xIxs5TXQVFJVfEyCTAoVJabQvFgkur0szRi9rgIsbHvbRVpnKMearhN42X4 HNyonfTtoVoHLTWnx22hh3Yrh3rE/4U6zKgcuuOWHfQvyXEzlAZcKhUL9QWGpU95QaPA STLBdgchj1QuXrc/PNe1TD9k8V7rgKxGrLg2OE89K8JmNd0XfvPC4VHoo7QB3X3pisIc MyY4DYG7DexfgRiB1TmVtGhlgdIaFLPh8JEWZ7W2TbGbZ2z2AzLRiUzzurOp6p9Z8FfY 4CWA==
X-Gm-Message-State: AGRZ1gIedY76Ms89R5N9qO0VFfg20ZpoPtg4ue+QUCCHECX58vXDk+yv e5TbfvcEAo4fEP5rLOolHKvXllAI9olbFdOHIePmpg==
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/mmusic/A5pEevItzXdDGuXUBBXzYYDD-ck>
Subject: Re: [MMUSIC] [rtcweb] Default proto transport in JSEP
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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, 19 Nov 2018 20:09:06 -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