IETF Logo Mail Archive

Re: [MMUSIC] [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: 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 DA695130DF4 for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2018 13:08:37 -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=ham 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 HwtXQcGtSlMl for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2018 13:08:35 -0800 (PST)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 9E237130DE5 for <mmusic@ietf.org>; Mon, 19 Nov 2018 13:08:35 -0800 (PST)
Received: by mail-pf1-x429.google.com with SMTP id c73so733149pfe.13 for <mmusic@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=KLnzS5i49jhKRty1zz6vyK4f7uYpQPBn53lPj7bH148hXXz68PFt5lyu1Ixo/vJoHe EaptOAHWEYMAxLavLofdaKHFyKnnFxT7XPdnmACEu/zB4D+wlBPTgJ8Ph91QtiKi1gBs 8m96a42HTi5Av32sWBImhgox3YiP1CL1bOllIQme4/ter2Zfmv3LcFhJVF/5wxA/dMRQ pvdQHsQpnztdCSlLbarAG1K2+3RyRieu1uJJDBmFOxxuWC7AJoY4encBDC9r4k8q8up0 AjiCAEcEBKBOkiuOKGpHt1DnISUU72Hv1RUBwsWKaDi0j1Ifzi2p1ktGW0Iu6wTkI4sH 4dwQ==
X-Gm-Message-State: AGRZ1gIV7T7LwzpkGE0A9YkYw36bJ/y+fBXTuM47P1t6P7AjnXVCn2N5 OXVND9qeZ4jAyc85gIENQjTNgw==
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/mmusic/CU21JfXbZMQGAx6N32ESncesxCA>
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 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