IETF Logo Mail Archive

Re: [MMUSIC] [rtcweb] Default proto transport in JSEP

Iñaki Baz Castillo <ibc@aliax.net> Mon, 19 November 2018 21:17 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 C020A130DE5 for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2018 13:17:10 -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 j14rbptCb5Yk for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2018 13:17:08 -0800 (PST)
Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 E742E130DF3 for <mmusic@ietf.org>; Mon, 19 Nov 2018 13:17:07 -0800 (PST)
Received: by mail-vk1-xa31.google.com with SMTP id 197so7122064vkf.4 for <mmusic@ietf.org>; Mon, 19 Nov 2018 13:17:07 -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=2uVAY0zEpnoWt0c28GfJglKDTw9zYUypq+ouETrIedA=; b=ZKJ6KbBFfTcHWcc3rYWwafzWtUTlRMEdgSmM/ME9uAGWTz7QVKGHSlYtN9IfjD7kPk ETi0nmVAl/5zrRrYI03m29cSd1VNQJ068/Kwd3ow9aPq4gN5tDWqklps/2ryZ9Wzk7IT 3A2ZUnyEYTi9tMOSur0FDZah9ps1HGgd9zL3MChmJfrqJuOpXRL6uZXF9+/n6rqM9fxR VfVB4BUaXMeH8myG6Wwy2Ez31nn12fAZyli+J4SNsVGdnFLbatq0N2lMXU0zPH5whsWK Z8G8tu2Ggnyyz8ZFDIM88uNrfxHSzCvHyrjKNiHnfIKv3f4dOTUzIpT5qKtMc3lKj20a OKlA==
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=2uVAY0zEpnoWt0c28GfJglKDTw9zYUypq+ouETrIedA=; b=KxwbdGcryrHRHr5DZqQ06QVG1LVzApvAgX3xvZimZI3P1lEkbgeJ4bZpgQUNeZeJYV PdDsrCDWlVGM5Y4HXUC3KtlnaFZtpR+o+F/atva4PghpJEtM9zn7JBrPe6mJCSGcV/nC ddiPr2LD0cRN4Z4ppd6He20Ln/fXa7vVT5lwUjukrjVL1rWInwzARKX5hu1dKJygRGL0 +GcQCuF8BeF/f4KbQKEuAaF82UyifyjrFY6iZyL7uZk0ay1mk9LPJ0sjRX3eC8n0wMfD 2tnBQBcMBpx1JxumieVEWvyTfdzghbN5U+LIQ/MOvQV0ev9v7f4NkGt1k29gHXVU11j+ wukQ==
X-Gm-Message-State: AGRZ1gJ8Q1idlHSFuOAc9EM8DK2d0EXB8BR7AXoT4czdoAh9o2NcWANI Q+oY1NJQocxcweJqOFQuw/6tbKs/KCjQ0srjXUUhQIvy
X-Google-Smtp-Source: AJdET5dnMg5BHWOUlsMbzbSMkQwWoBIntKB2NGVN38EWNviQET9xLEKvpFjxW5Obij5y6LqZMqBQE5egj0BpcC3H0dc=
X-Received: by 2002:a1f:9042:: with SMTP id s63mr9552151vkd.17.1542662226630; Mon, 19 Nov 2018 13:17:06 -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>
In-Reply-To: <CAD5OKxtpepraJWVbJy2+x_4pFbeqF57=yh1GVF-WoYGBX1OV-Q@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 19 Nov 2018 22:16:54 +0100
Message-ID: <CALiegf=ffb1UL0FPrk770Q-ACQL-ySAqxBzB1M0yJXZUM6y9sg@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/GUFcUrUvwaPSJH_s-B4k9em7Mug>
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:17:11 -0000

On Mon, 19 Nov 2018 at 22:08, Roman Shpount <roman@telurix.com> wrote:

> 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.

I understand your points, and you are right in all of them. I just
don't believe that this is gonna happen in SIP world within next 25
years. I mean: in order to explain this you have moved to
DataChannels, which will never exist in SIP-land (BFCP already exists
which is implemented by 2-3 devices).


> 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

No problem other than announcing UDP while the effective candidate
pair may use TCP. If that's not a problem, then ok.


>> > 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

Didn't know that. Thanks.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email