Re: [rtcweb] Default proto transport in JSEP

Iñaki Baz Castillo <> Mon, 19 November 2018 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04FEB130DE5 for <>; Mon, 19 Nov 2018 13:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E-EuDZvw4MoJ for <>; Mon, 19 Nov 2018 13:17:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6FBB130DE8 for <>; Mon, 19 Nov 2018 13:17:07 -0800 (PST)
Received: by with SMTP id n126so7106007vke.12 for <>; Mon, 19 Nov 2018 13:17:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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=QEDoTrwFn6WfqDx4WxDD1JttQE+Ptvc4LNGBxUDkkZFa9GbISDVsrnYBkIuV3mqdCT cQ3jXZM51H3GOwMdvYQQn2297ce0BjlsAJw4xM/BVp6QbI84C62pv6spkDfJFf1M9yY7 lo1Jjp3CIJw3GRvd4OjgZ/AH8m9aNFnqdRgOW0WMj9zQjCl7PCtsZWi2DC3DaBYz1CCG OdNDY81bCnHt8WX/JH0+X6Ms/kHNjBvhk4CTauLzU+gxWn+a0o8JZgP3EOKb5u2ZudB2 dcSNZ3zeFaNtuPl/WtNwM0I11BC07p3IotHAFci2EKgFCcS1EQHK0HnMM2ilf25K1TFq ArQg==
X-Gm-Message-State: AGRZ1gJL0SliYpBoUrAhg0XReLtJVffw3yTJ0tnq0Nr9lF8hiB8SU0dp gXNDNRSXaMnlp+Q4tX4pDVk8+8AgHROi4iPfB0Vp3Q==
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: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Date: Mon, 19 Nov 2018 22:16:54 +0100
Message-ID: <>
To: Roman Shpount <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [rtcweb] Default proto transport in JSEP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Nov 2018 21:17:10 -0000

On Mon, 19 Nov 2018 at 22:08, Roman Shpount <> 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

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

>> > Please read
>> > 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:
> ICE trickle is supported. Please read  second bullet point of

Didn't know that. Thanks.

Iñaki Baz Castillo