Re: [rtcweb] Default proto transport in JSEP

Justin Uberti <juberti@google.com> Tue, 20 November 2018 05:58 UTC

Return-Path: <juberti@google.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 AB2B71292AD for <rtcweb@ietfa.amsl.com>; Mon, 19 Nov 2018 21:58:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MdwHwVEkiRjw for <rtcweb@ietfa.amsl.com>; Mon, 19 Nov 2018 21:58:03 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 387F5127332 for <rtcweb@ietf.org>; Mon, 19 Nov 2018 21:58:03 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id x6so521425ioa.9 for <rtcweb@ietf.org>; Mon, 19 Nov 2018 21:58:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LLoT8/owmum7C3OU0Xceo2sRO8oeIu4Gv9SofZ8byvc=; b=NC+/Me7Ow1A+w4oR/y1+5G9AeZ2LJwPpDXBzMIrkAdY/TmeH4Ur4FudkUwfUSZMwwG lYxYypf5v7hmwV5FvIgMswBL0Q71R4u39n9o0Gm0nD9vAVTa57sbjVlJglQmabzWBJIq JgEgN1jnxWZcloy4VtQDY9TQXFOWcml9fkqjvZAZnat+j8tQooAWnJo7LM8CEYfQDtDU REjdbNCEsRtWBW1f1asY7WgadlGi87bYe1b/rEEoZAPlrfbyyAJfpKV9PWlkiq0wLXR8 7Y3+Vy2Gr4dwmASro4UtKeCmqT2prfjIfrkTol6xAAXx2bBJ6JP/VR32KuBIUsgq3qMa TVyg==
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=LLoT8/owmum7C3OU0Xceo2sRO8oeIu4Gv9SofZ8byvc=; b=JMiKciJpykr/uHnPXZPuJUa8FKMDP4ep4tn6M+RrQruPfMxejVdHvx60gOLnmgAsY2 ztqsCeghfbKYyg5vxWRZ0rr+SuZC+a348JICcckrMY+AZEwnl9WiQP0gSdvyTWoW39BT SZWFvp4HdMnbMQN+CIO0QHWLQwGY4LF+n6Mtv1ko3wGzgvX1eMh6t6JNVusorA69Stn1 dHf1WBsVtmeXBohOtjti7G/vJ2mqYz0p83/7eRe7pAPT9Ahvr5eVxDnTsbIEQCxeV3hD 7Ii9zcK9ii5qei3KWkOzPMqBmg5zkyCWa8avT6PwTY70m/lkgcGK3X4IeSI1Zz3EzHeW UBAg==
X-Gm-Message-State: AA+aEWbAJCP4PzTz9NG2H2bhoXFSowdYStlD8m88WisPmqWyTfjgvbX/ YhNylft3KaPdXzNeBbt3UK5j2CHEZvCkWct+81lNSA==
X-Google-Smtp-Source: AFSGD/WbWYJBEnzQg3Fq7OZX+uXAzGJCBUlln99vQmym7vLEF5/GiQyQiTofKuUuANF3bS6LrB5OgjyESqftui2OTo4=
X-Received: by 2002:a5e:9609:: with SMTP id a9-v6mr463875ioq.95.1542693482074; Mon, 19 Nov 2018 21:58:02 -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> <CALiegfmFV=988+WuViUQRGJRgR=mcqS9Y+eDnL4pH6VrbJRvCQ@mail.gmail.com> <CAD5OKxtwuQu0du+ptmJpX0ALQnUtjLG==NanP8OB51D4M9fYhg@mail.gmail.com> <CALiegfnMbwTruVKU-VnsZvddqRhnuCm1k8zLcLSuWSs9zT1JUA@mail.gmail.com> <CAD5OKxtxAiBbVY4HQjfjwqfsGoUxAZzmmrTWVfe7pG6MTsHGRA@mail.gmail.com> <CALiegfnVOFvUKYMRp7z0Q3aVyzbi=+JuyXmH+PL6_pNW9j9PVA@mail.gmail.com> <CAD5OKxtpepraJWVbJy2+x_4pFbeqF57=yh1GVF-WoYGBX1OV-Q@mail.gmail.com> <CALiegf=ffb1UL0FPrk770Q-ACQL-ySAqxBzB1M0yJXZUM6y9sg@mail.gmail.com> <CAD5OKxtj=nEWjOWztcAVMDsFOFRGO7hQaKUsn-Pqbk7Ma64Trg@mail.gmail.com> <CALiegfno4y5P-qLkrxSs0zLbEEUo1HWyp0rfEA8KecRjTQ43sQ@mail.gmail.com> <CAOJ7v-2o1Se9zaMgktQtwNW46zvB2i7Hk7+GK1yhWJV5xcT7ZA@mail.gmail.com> <CAD5OKxveNtx3uD7tD_mTgE-Rv2JTZPBmjk34iUJD9uw25-ZCzQ@mail.gmail.com> <CAOJ7v-1V_vtq+szN6299kw9dH_TOz9sxa+YYwQkBwHeJPoqvgA@mail.gmail.com> <CAD5OKxt6JyFXsdANSX13LytLsosRQUnP5oKoR1PUjZmJyP0kxw@mail.gmail.com>
In-Reply-To: <CAD5OKxt6JyFXsdANSX13LytLsosRQUnP5oKoR1PUjZmJyP0kxw@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Mon, 19 Nov 2018 21:57:47 -0800
Message-ID: <CAOJ7v-1VuktqXrX6NVD85UWNPP6e_cbs=_YOr6ewn7g-KhR_ug@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>, RTCWeb IETF <rtcweb@ietf.org>, mmusic@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ffcc31057b125063"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/OjogERMrIw9Xs3MaUHi6PfwIJCw>
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: Tue, 20 Nov 2018 05:58:05 -0000

On Mon, Nov 19, 2018 at 9:31 PM Roman Shpount <roman@telurix.com> wrote:

> On Mon, Nov 19, 2018 at 11:41 PM Justin Uberti <juberti@google.com> wrote:
>
>> Are you aware of any implementations that will trigger ICE mismatch if
>> the proto does not match? Also, this would only happen in situations where
>> the client offers *only* TCP candidates, which would require manual
>> filtering by the client and is clearly a corner case.
>>
>
> I think a couple of popular hardware VoIP phones and one widely used SIP
> based business communication/messaging product will trigger a mismatch in
> case of incorrect protocol (non UDP if UDP candidates are present and non
> TCP, if only TCP candidates are present according to their ICE
> implementation document). I have to say, that these things do have a
> tendency to change between product updates and I have not tested this
> product for a while. Our own products currently match the protocol to
> default candidate, so we did not need to retest this issue.
>
> TCP based transport will happen for any subsequent offer/answer exchange
> when TCP candidate is nominated. Only a single TCP ICE candidate will be
> present in the session description, so that protocol in m= line will have
> to be TCP. In case of the above mentioned product, their ICE protocol
> implementation document says that call must be terminated, if in subsequent
> offer, protocol in the m= line does not match the protocol in the ICE
> candidate.
>

VoIP phones will almost certainly never receive TCP ICE candidates from a
WebRTC implementation, which only gather active TCP candidates.

Anyway, we have the 3 choices listed below. We differ on which is the most
pragmatic solution. If the WG has enough voices in support of #2 or #3 to
overturn the consensus of #1 from IETF 103, I will write it up accordingly.

>