IETF Logo Mail Archive

Re: [rtcweb] Default proto transport in JSEP

Justin Uberti <juberti@google.com> Mon, 19 November 2018 23:08 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 67FC8130DF6 for <rtcweb@ietfa.amsl.com>; Mon, 19 Nov 2018 15:08:54 -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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 K9jJVKuZCjKX for <rtcweb@ietfa.amsl.com>; Mon, 19 Nov 2018 15:08:51 -0800 (PST)
Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 228FC127598 for <rtcweb@ietf.org>; Mon, 19 Nov 2018 15:08:51 -0800 (PST)
Received: by mail-it1-x12a.google.com with SMTP id o19so645765itg.5 for <rtcweb@ietf.org>; Mon, 19 Nov 2018 15:08:51 -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=r+7dZ3hdCZ/aoe/AoBePuHtA73U8DB7H3YzhcZXb+Ho=; b=J/fk3mmRwi0yN2z6+6fse2zRN76GNAUIsEgr1Xw/rqVriXeLGxoR1Y+5VnqkzesXH7 6SoP0UzuN58kctqE8RvZqqZHxIiE/STLbvi2DgA0KSTN/Ub8YXGfPvAKwK62U+mJYCcW 1HXZyU/l2EHxLmhER1AQY4ksMzN6nE0z59nNTMAe1YEiPLfFsEyJcCoTes/E0owWGhGh I8T4RHWI8RS+XnnfA9ZoLL4SLHheUUgGlx+klgH5MeZ8uZifp/TXDuMKMt7ESsGPBAHb E2T10XZszjd1MJeuUV/txTR+2hXnH8Z1HpcKFit10aVF+R8heTqUKRsd1WC6aW0EuaqQ IxaA==
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=r+7dZ3hdCZ/aoe/AoBePuHtA73U8DB7H3YzhcZXb+Ho=; b=DeVk6bS91HOgBlQKehoI7xYsCCA6njS7FseC/mDjSXhbQzIDJqGK8Ii3J9ewaRAf4w 9Yt8V/pzhD3fzJiWQo/3h89sf8/QiFMR6buqFdjjkTrCZnCX1DrkSnFFepGobcLcfCFt PTVTLbCCoUG2R38fBSz3q708AODnvlIEn0uTCMFnDlmo8xzHgoIDCbXRLMnweoc0+Q4m DmVZw5QnYiO0ZwhUSUJmXOhRTnP7cJnX6PTFTB5kO+JvITamJcAJedde6Xns9mpaa1QQ Dt6pazGO5MzOTxalrB7qRq51HGsEaVlNVPiYaLeA4rpdoLs4Ze7OgxJ430KEOlNQd/dU PMYA==
X-Gm-Message-State: AA+aEWZucJPlvoEMdkiIs4ZN/FJe7U/9eVUK1Z+BHf9jlEaRhfmerkIH BrWkmePhqLDDn+oUnh6doiC7H7doJ0uMG0wjFXgVlw==
X-Google-Smtp-Source: AFSGD/WPjxmmpRsjNhR3TXjpSMF0YJiUQsXSR94lYes1RpfS0ZJTC2IcNsfnSOkIhLfHjFa+Uh5GcI6RDt4Z8F3VRo0=
X-Received: by 2002:a24:e50d:: with SMTP id g13-v6mr114503iti.8.1542668930090; Mon, 19 Nov 2018 15:08:50 -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>
In-Reply-To: <CALiegfno4y5P-qLkrxSs0zLbEEUo1HWyp0rfEA8KecRjTQ43sQ@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Mon, 19 Nov 2018 15:08:38 -0800
Message-ID: <CAOJ7v-2o1Se9zaMgktQtwNW46zvB2i7Hk7+GK1yhWJV5xcT7ZA@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: Roman Shpount <roman@telurix.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic@ietf.org
Content-Type: multipart/alternative; boundary="000000000000960f7e057b0c9970"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/osGzMHvDgICtFw9Xe2WFk7a1v2g>
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 23:08:54 -0000

Pretty clear that the 0.0.0.0/9 behavior being proposed violates 5245
<https://tools.ietf.org/html/rfc5245#section-5.1>:

   The agent will proceed with the ICE procedures defined in this
   specification if, for each media stream in the SDP it received, the
   default destination for each component of that media stream appears
   in a candidate attribute.  For example, in the case of RTP, the IP
   address and port in the c and m lines, respectively, appear in a
   candidate attribute and the value in the rtcp attribute appears in a
   candidate attribute.

Ergo, I don't think this proposal will fly. Of the three options being
considered (below), only #1 avoids violating 5245 while simultaneously
minimizing busywork.

1) (current) Match IP and port, but stipulate an exact proto value
2) Match IP, port and proto
3) Set IP, port, and proto to fixed values

If we think avoiding ice-mismatch when interacting with 5245 endpoints is
not important, that point needs to be made clearly. Otherwise, I think the
easiest path is to update ice-sip-sdp to permit #1 as a legacy interop
behavior (and it can continue to recommend #3 for interop with 8445
clients).

On Mon, Nov 19, 2018 at 1:24 PM Iñaki Baz Castillo <ibc@aliax.net> wrote:

> On Mon, 19 Nov 2018 at 22:21, Roman Shpount <roman@telurix.com> wrote:
> > In SIP land it is the the difference between RTP/AVP, RTP/SAVP, and
> UDP/TLS/RTP/SAVP which is the problem. In first case no encryption is
> allowed, in second case SDES-SRTP is required, and in third case DTLS-SRTP
> is required. Then there are AVP vs AVPF differences.
>
> Instead of UDP/TLS/RTP/SAVP, I still suggest ICE/TLS/RTP/SAVP, so
> everything covered. ICE itself handles UDP or TCP, so no need to
> specify it in the m= proto.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

v2.23.0 | Report a Bug | By Email