Re: [Wish] WHIP should also allow *media* to be sent over the HTTPS connection
Alexandre GOUAILLARD <agouaillard@gmail.com> Sat, 13 March 2021 03:56 UTC
Return-Path: <agouaillard@gmail.com>
X-Original-To: wish@ietfa.amsl.com
Delivered-To: wish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB993A1477 for <wish@ietfa.amsl.com>; Fri, 12 Mar 2021 19:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, THIS_AD=0.699] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PidNbmbjP7gy for <wish@ietfa.amsl.com>; Fri, 12 Mar 2021 19:56:22 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 CDF293A1476 for <wish@ietf.org>; Fri, 12 Mar 2021 19:56:22 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id g27so27937971iox.2 for <wish@ietf.org>; Fri, 12 Mar 2021 19:56:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6uNlsZEAXNKbGw9vkLwMpIO9PO59o9kft4O7WanYdCQ=; b=BuIHglps/hRqKyCXgsGRH2j6VF0wXrFHaolrP4JEH84yEzuW/aLl3OsUVctmabckUy S1ncbudnuHcA4eaMCx+F3tNGGtUF/zupwZCX5TtVXs8HoA4RdfCbHzNySqYQF8c4LIuc n43yBQdmzCWCnWyL44qxLDFJ3ptu4OqoGNwwwQtM+JB1oz669AUVOd11TwJwV8vaP9WQ br/P1XMZUGqRvaAYUQ2Z4sGjqBrRWgvTEkDtsvo+6cjnlRfwzLybA6a3GbvQmUBR4A4K X1LFAy908B4PQX7BRqJBdRB5W+YIm1L1UcZQPX/fHk+4ddwm1/8niroIwih0M4+YGoBv JNEA==
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=6uNlsZEAXNKbGw9vkLwMpIO9PO59o9kft4O7WanYdCQ=; b=Hc0+uhxY75wOjSjPWWnhbseOVptzAADn9mCEc+QX3/ERt+rVBQcTHgTeDPF5tWl3mU S0vFirSq+wDq2NuMkqLdsUWCVUFs+TONS1n+jo83ibmJP3d0VGnDJ4qgXTGe0dmsYnW1 WzGuMlpF3y2T143sKGQ/k6rmA7REQs+LOI6lmHfz+9OW9JZYW61FH7A6kMuiExbJhFD7 znId7cV15so2nl/AR0ns7tvZT9h8O1mlb0ad5A9oHrXg82So1S/dpIt15VkCJPdPTjaR 7JwghuRkqrxnor3g9ySi+kbXXWLpXENZv6woueUxE4m+629q30yjHzb+xzWcca0cBK+j /Vwg==
X-Gm-Message-State: AOAM531zONTiQatiLnoxtF8pDVxH4knfLCuATqUUPFzBkd0DbF8wOdey rI5ZLqA8DXT5svyqSQv2TYiCfmzPPWUMmCRMqvoiRocKZbOdhIXE
X-Google-Smtp-Source: ABdhPJz3R+1G1WSqmrt9Z2UtrKCwdKWUktr4L0E5+h/VCysSUS2DSxGKSkRoIe58j1PmxaUa60bMVFxEZNE9PVyJpJU=
X-Received: by 2002:a5d:8249:: with SMTP id n9mr1745836ioo.31.1615607780251; Fri, 12 Mar 2021 19:56:20 -0800 (PST)
MIME-Version: 1.0
References: <EA0DDB88-D685-4646-8BC8-D694EA2274D7@live555.com> <YEwpfcKceVutkbQ5@SeanLaptop.sioBuD.com>
In-Reply-To: <YEwpfcKceVutkbQ5@SeanLaptop.sioBuD.com>
From: Alexandre GOUAILLARD <agouaillard@gmail.com>
Date: Sat, 13 Mar 2021 10:56:09 +0700
Message-ID: <CAHgZEq5iUvVgZYa4c61swFoSHiveiPHMHPZKwdPG9TS2-mPJRw@mail.gmail.com>
To: Sean DuBois <sean@siobud.com>
Cc: Ross Finlayson <finlayson@live555.com>, wish@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d69c9a05bd62ff28"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/ZvGTT1fdUXSzVkaRY8b3kVUpZpE>
Subject: Re: [Wish] WHIP should also allow *media* to be sent over the HTTPS connection
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS <wish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wish>, <mailto:wish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wish/>
List-Post: <mailto:wish@ietf.org>
List-Help: <mailto:wish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wish>, <mailto:wish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Mar 2021 03:56:24 -0000
hi sean, # WHIP needs to define more > WebRTC has some complicated features that I think WHIP will benefit from > As mentioned to Ross, WHIP is aimed at being a 'companion' signalling protocol to RTCWEB, not a replacement. The goal is for people to get most if not all the rtcweb features when using WHIP for the signalling. > # WHIPs narrow usage will mean not many implementations > WHIP does not aim to be a companion for all webrtc use cases. While the number of implementations of WHIP will be at least one order of magnitude less than those of RTCWEB, the IETF decided the use case was important enough to justify this work and to create a working group. Here is the official main use case, with some words emphasized by myself: ""*At the same time, the use of WebRTC as a mechanism for large-scale media broadcast is gaining popularity, with companies such as Millicast, Caffeine, Janus/Meetecho, Evercast, Wowza, Liveswitch, Antmedia, and Strivecast deploying WebRTC-based media distribution networks. Unlike more vertically integrated uses of WebRTC, these networks would benefit immensely from being able to re-use the several broadcasting tools that have been developed over time (such as Wirecast, OBS, Stretchcast, NewBlue Stream, XSplit, FFSplit, Lightstream, vMix, and a host of other applications). * *To date, these media distribution networks have employed their own proprietary signaling protocols to establish the connection between broadcasting tools and the network, generally requiring either bespoke software or customized modifications to existing broadcasting tools.* *With the large number of available tools and the growing number of real-time media distribution networks, this ad-hoc approach to creating custom protocols for establishing sessions clearly does not scale. The real-time broadcasting ecosystem would benefit immensely from a single, shared protocol to meet this goal.*" It is likely that any one-way output from video conferencing feature to connect to delivery networks (zoom RTMP out, SKype RTMP out, Jitsi RTMP out, ...) would also benefit from this without a lot of modifications. The role of the IETF is to provide specifications, and not implementations, or unified test suites like e.g. W3C which has a specific mandate for at least two browsers implementations, and a reasonable level of testing. I hope this clarifies. -
- [Wish] WHIP should also allow *media* to be sent … Ross Finlayson
- Re: [Wish] WHIP should also allow *media* to be s… Sean DuBois
- Re: [Wish] WHIP should also allow *media* to be s… Alexandre GOUAILLARD
- Re: [Wish] WHIP should also allow *media* to be s… Alexandre GOUAILLARD
- Re: [Wish] WHIP should also allow *media* to be s… Ross Finlayson
- Re: [Wish] WHIP should also allow *media* to be s… Alexandre GOUAILLARD
- Re: [Wish] WHIP should also allow *media* to be s… Tim Panton
- Re: [Wish] WHIP should also allow *media* to be s… Ross Finlayson
- Re: [Wish] WHIP should also allow *media* to be s… Juliusz Chroboczek
- Re: [Wish] WHIP should also allow *media* to be s… T H Panton
- Re: [Wish] WHIP should also allow *media* to be s… Sergio Garcia Murillo