IETF Logo Mail Archive

Re: [rtcweb] Default proto transport in JSEP

Roman Shpount <roman@telurix.com> Mon, 19 November 2018 21:08 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 73BEA130DE5 for <rtcweb@ietfa.amsl.com>; Mon, 19 Nov 2018 13:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 dzXwYy6Bo5nM for <rtcweb@ietfa.amsl.com>; Mon, 19 Nov 2018 13:08:35 -0800 (PST)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 B9CCC130DE8 for <rtcweb@ietf.org>; Mon, 19 Nov 2018 13:08:35 -0800 (PST)
Received: by mail-pg1-x532.google.com with SMTP id n2so7196114pgm.3 for <rtcweb@ietf.org>; Mon, 19 Nov 2018 13:08:35 -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=/Tmik5UtYoAQ39jUilcmo/6XOfzC+DKbVTNAzsX/Txw=; b=svJRCaEOAfqRrEAGDW6AIuWE/LgSDSoXFJG4MBvQYXR5d2RcU8va1IntZSsAYITIKO h0V/h4W4Kdj+q1xi23lYagEnnOZFEhohAENpuLkaByVr4vTmBTnE5ZCTT9orDxiXYDIq WjtqxYDLtz1q1huquXxnMTQBuBcVoa77jF1QfXX62CD+OJGLUreTujJE9LkPBKtVu3tQ yjIufieocVeTuDHp1oPB0uHpjzXxJLREvpjn9D5ToeXfH6VjtB2l2Kb9/LgZPGSRo7qT MYuMJFC7aAiwDx272YYd4611bB7/+OopLgVxm5c+VT1Y2DlgBc82lYZcu20hrqvMuUPO Lf8A==
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=/Tmik5UtYoAQ39jUilcmo/6XOfzC+DKbVTNAzsX/Txw=; b=PdVgYFE1iJf2CafipK3u/m7Tk/Lai/eByZgPDY7GPpdF9Nmj8ULoQ2cZMTO9VC9qsQ yKXxKOnOyTbSqLS21n6kBI/ymKHOsZKHoVVjeTtCvry/M16DD7tqWoQseiZJPltIGQDD DW7NpgYpd+8jZFl+cwzi36cXg1Nkvrj3OxDZb4jqeKXqsC5UwPacGqlrfctuLKzML2rs uxMw5TpO2KPFhJjBEOW1LfGcJHsX0TPVmTpknTckpzm1znjIv7v4BoGZmhueg0Z12P9R Rx9xqiTnRr+GuIc0+tXgroNwDe9JA2H6LE5+FavBEW8rstZfQaf44E0b+xre/9wwTlLS +ULA==
X-Gm-Message-State: AGRZ1gKccBmcExIQcZEVcM7RdtaHrx7hblbA8eenqynb4uu5Jl3lFs1a CTb/zXra3A76l7hPNmLONzucmRGt3Cs=
X-Google-Smtp-Source: AJdET5cT8sv0yGIGo7StWKrBQeuivfDjuvJYxwooOE0ZF40+OJIr14pk4wc0ad3UqaAo4hnkDfIMHg==
X-Received: by 2002:a63:f901:: with SMTP id h1mr21619635pgi.154.1542661715103; Mon, 19 Nov 2018 13:08:35 -0800 (PST)
Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id t66sm16485447pfd.54.2018.11.19.13.08.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 13:08:34 -0800 (PST)
Received: by mail-pl1-f181.google.com with SMTP id x21-v6so12432578pln.9; Mon, 19 Nov 2018 13:08:34 -0800 (PST)
X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr13737510plb.55.1542661713725; Mon, 19 Nov 2018 13:08:33 -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>
In-Reply-To: <CALiegfnVOFvUKYMRp7z0Q3aVyzbi=+JuyXmH+PL6_pNW9j9PVA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 19 Nov 2018 16:08:22 -0500
X-Gmail-Original-Message-ID: <CAD5OKxtpepraJWVbJy2+x_4pFbeqF57=yh1GVF-WoYGBX1OV-Q@mail.gmail.com>
Message-ID: <CAD5OKxtpepraJWVbJy2+x_4pFbeqF57=yh1GVF-WoYGBX1OV-Q@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000748fbd057b0aeb3f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/BHvufoYd-lwa16XBVWv8ndd5lzk>
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 21:08:38 -0000

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

> On Mon, 19 Nov 2018 at 21:47, Roman Shpount <roman@telurix.com> wrote:
> >
> > On Mon, Nov 19, 2018 at 3:31 PM Iñaki Baz Castillo <ibc@aliax.net>
> wrote:
>
> >> I suggest:
> >>
> >> m=KIND 9 ICE [codec PTs]
> >
> >
> > If you are re-inventing the protocol, why would you build SDP or m=
> lines? If you are using an existing protocol, why do you modify it in the
> way it is not compatible with anything in existence?
>
> Why is proto="ICE" not compatible? ICE represents a virtual path that
> does not correspond to a specific 5-tuple (such a tuple may
> dynamically change without requiring any new SDP O/A).
>

There are differences between AVP/SAVP/SAVPF even when ICE is used. You
quietly discarded them which can cause issues.

If anybody ever implements data channels over QUICK vs SCTP, proto is the
place to specify this. ICE candidates will only tell the end point that UDP
vs TCP,. Kind only tells the type of stream. If there is more then one way
to transport this data (SCTP vs QUICK), proto is required.

Also, you ignored the question that I asked you. What is the issue that you
see with:
m=audio 9 UDP/TLS/RTP/SAVPF [codec PTs]
c=IN IP4 0.0.0.0

> Please read
> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5
> > Some people for some reason insist on following specifications. If you
> propose to do two opposite things, random things start being implemented.
>
> So, that spec is completely making it imposible to enable ICE trickle
> because it mandates that the value in c= and m= must already match an
> existing a=candidate line in the same SDP. This is not true when using
> Trickle ICE since candidates may be sent later that the SDP:
>
> https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-18
>
>
ICE trickle is supported. Please read  second bullet point of
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5

Regards,
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email