From nobody Wed Jan 20 15:08:21 2021
Return-Path:
X-Original-To: wish@ietf.org
Delivered-To: wish@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 235143A15B9; Wed, 20 Jan 2021 15:08:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alvaro Retana via Datatracker
To: "The IESG"
Cc: wish-chairs@ietf.org, wish@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana
Message-ID: <161118409965.14212.161938361826270910@ietfa.amsl.com>
Date: Wed, 20 Jan 2021 15:08:20 -0800
Archived-At:
Subject: [Wish] Alvaro Retana's No Objection on charter-ietf-wish-00-01: (with COMMENT)
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 20 Jan 2021 23:08:20 -0000
Alvaro Retana has entered the following ballot position for
charter-ietf-wish-00-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wish/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I don't object to this work, but the list of companies and tools made me wonder
about whether people associated with them will be engaged in this work. Are
they? A quick look at the wish archive doesn't show much, but the discussion
has probably been carried out elsewhere.
In either case, I think it would be a good idea for the charter to only
generically talk about the interest in this type of work and not explicitly
mention companies/tools.
From nobody Thu Jan 21 01:33:57 2021
Return-Path:
X-Original-To: wish@ietf.org
Delivered-To: wish@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 168EE3A1825; Thu, 21 Jan 2021 01:33:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?=
To: "The IESG"
Cc: wish-chairs@ietf.org, wish@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?=
Message-ID: <161122163206.28761.13627585159068349475@ietfa.amsl.com>
Date: Thu, 21 Jan 2021 01:33:52 -0800
Archived-At:
Subject: [Wish] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-ie?= =?utf-8?q?tf-wish-00-01=3A_=28with_COMMENT=29?=
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 21 Jan 2021 09:33:52 -0000
Éric Vyncke has entered the following ballot position for
charter-ietf-wish-00-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wish/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Is SDP "Signaling Description Protocol" or "Session Description Protocol" ?
Like Alvaro, I would prefer to drop the commercial company names as they bring
little to the discussion.
Could the background be more concise ?
Will the 'product' of this WG be a single document that is a specification as
indicated by "The product of this working group will be a specification" ? If
so, could the work be done in another WG ?
We will also need to ensure that this WG is exposed to MOPS WG and vice-versa.
From nobody Thu Jan 21 02:37:32 2021
Return-Path:
X-Original-To: wish@ietf.org
Delivered-To: wish@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED753A1889; Thu, 21 Jan 2021 02:37:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker
To: "The IESG"
Cc: wish-chairs@ietf.org, wish@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton
Message-ID: <161122544697.11632.3889806764005915213@ietfa.amsl.com>
Date: Thu, 21 Jan 2021 02:37:26 -0800
Archived-At:
Subject: [Wish] Robert Wilton's No Objection on charter-ietf-wish-00-01: (with COMMENT)
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 21 Jan 2021 10:37:27 -0000
Robert Wilton has entered the following ballot position for
charter-ietf-wish-00-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wish/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I'm not sure whether this should be part of the charter, but would be helpful
for it to specify which version of HTTPS will be targeted, or state a minimum
version of HTTPS?
From nobody Thu Jan 21 05:36:17 2021
Return-Path:
X-Original-To: wish@ietf.org
Delivered-To: wish@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E34C83A0B9F; Thu, 21 Jan 2021 05:36:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker
To: "The IESG"
Cc: wish-chairs@ietf.org, wish@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper
Message-ID: <161123617433.27442.17148171915344733324@ietfa.amsl.com>
Date: Thu, 21 Jan 2021 05:36:14 -0800
Archived-At:
Subject: [Wish] Alissa Cooper's Yes on charter-ietf-wish-00-01: (with COMMENT)
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 21 Jan 2021 13:36:15 -0000
Alissa Cooper has entered the following ballot position for
charter-ietf-wish-00-01: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wish/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
s/assure/ensure/
As several others have said, it would be helpful to see milestones so that it
is clear whether the objective is a single spec or multiple specs.
From nobody Thu Jan 21 05:43:38 2021
Return-Path:
X-Original-To: wish@ietf.org
Delivered-To: wish@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5820B3A0BC5; Thu, 21 Jan 2021 05:43:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker
To: "The IESG"
Cc: wish-chairs@ietf.org, wish@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund
Message-ID: <161123661527.29515.3808895890497585933@ietfa.amsl.com>
Date: Thu, 21 Jan 2021 05:43:35 -0800
Archived-At:
Subject: [Wish] Magnus Westerlund's No Objection on charter-ietf-wish-00-01: (with COMMENT)
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 21 Jan 2021 13:43:35 -0000
Magnus Westerlund has entered the following ballot position for
charter-ietf-wish-00-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-wish/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I am on the verge of a block here.
So the goal is to establish a one-way media over an WebRTC peer connection
between a media producer and a consumer. What isn't clear in this work is who
is the intended initiator to this communication. After having looked in
draft-imurillo-whip it appears the intention is for the media producer (or its
controller) to initiate the HTTP connection to a consumer (or its controller).
Where the necessary configuration is established.
I assume based on signalling the media flow could be reversed so the consumer
initates the media establishment, but that is also not clear. Clarifying the
high level functionality here in the charter might avoid the need for
specifically commenting on screens. Because that would basically work if the
consumer can be the initiator and request media to it.
The other aspect that I realize is missing is the scope of capability
negotiation here and preference indication. Defining this from a WebRTC API
perspective might be possible but is not clear. What is needed here? What is
assumed about third parties creating media profiles for this type of devices?
From nobody Thu Jan 21 10:10:54 2021
Return-Path:
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 E30C43A0ABB; Thu, 21 Jan 2021 10:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.847
X-Spam-Level:
X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.009, SHORTENED_URL_HREF=0.822, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 fKDVtTO_rGDY; Thu, 21 Jan 2021 10:10:46 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F195D3A0AAF; Thu, 21 Jan 2021 10:10:43 -0800 (PST)
Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 10LIAZSO067136 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Jan 2021 12:10:36 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1611252638; bh=uhcJIwq8YbtU0F6yQ4/rw4v/GRuVWiDQ47Ve+XdZw7w=; h=To:From:Subject:Cc:Date; b=r2OX0VmU/fNxpF77sr4BlZL6zzyUKvLoK045xZg4GdnijBXbr6uww2K4FPLjdX6/n BGWrBZ6GgJ39viXN34tMPDFwIZbRPNMr4l78f7G1C8UbEbDKQFWkCtVgbq3bBTPtN8 VMCmhHp8B1pqDbc2/JqtW4+FttsN4e3JBpKPiCl0=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local
To: The IESG
From: Adam Roach
Cc: Alexandre GOUAILLARD , Sean Turner , "wish@ietf.org"
Message-ID:
Date: Thu, 21 Jan 2021 12:10:30 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------0DBCBDC27E0C07FA4939E9A5"
Content-Language: en-US
Archived-At:
Subject: [Wish] WISH Charter Ballot Comments
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 21 Jan 2021 18:10:49 -0000
This is a multi-part message in MIME format.
--------------0DBCBDC27E0C07FA4939E9A5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Dear IESG:
Thanks for the careful consideration of the WISH charter! I understand
that it has been approved for public comment. Looking at the ballot,
there are a handful of comments that appear to need responses. I have
left off editorial comments and those pertaining to the (now added)
milestone. I have copied the WISH mailing list for the information of
interested parties.
Alvaro Retana No Objection Comment (2021-01-20):
> I don't object to this work, but the list of companies and tools made
> me wonder about whether people associated with them will be engaged in
> this work. Are they? A quick look at the wish archive doesn't show
> much, but the discussion has probably been carried out elsewhere.
For the most part, we've been holding off doing the core discussion of
issues until after charter approval, so as to ensure that the broadest
set of folks are involved in that conversation. The proponents of this
work have a rough notion of some areas that need greater focus, and I
expect to be sending a list of open issues to the working group mailing
list as soon as the group is approved.
In terms of the expected participants, we have strong interest and
commitment from Millicast and Caffeine, as well as provisional but
strong interest from three other major entities in this technology space
(one broadcasting tool, two realtime CDNs) who I don't feel at liberty
to name, as they haven't been public about their interest *yet*. I would
also expect the Janus/Meetecho folks to be keenly interested and
participate, although I haven't yet touched base with them.
> In either case, I think it would be a good idea for the charter to
> only generically talk about the interest in this type of work and not
> explicitly mention companies/tools.
There's a tricky balancing act here. I would expect that most consumers
of this charter -- that is, typical IETF participants -- will not be
familiar with the general notion of what broadcaster studio software is
and how it fits into the ecosystem. The two options here would be either
including a very long description of how these networks work and the
role of broadcasting tools in them; or, alternately, to cite the
specific tools and network to allow folks to explore them and gain an
understanding of their functionality first-hand.
Éric Vyncke No Objection Comment (2021-01-21):
> Like Alvaro, I would prefer to drop the commercial company names as
> they bring little to the discussion.
>
> Could the background be more concise ?
Not if we drop company names -- it'll have to get longer. :)
Again, the challenge here is that we're talking about technology that I
don't believe many IETF participants are all that familiar with, and I
think having some kind of introduction to the space is important if
they're going to understand what the work is about and participate in it
productively. If you want to suggest specific edits that preserve that
property and yet make it shorter, that would be great.
>
> Will the 'product' of this WG be a single document that is a
> specification as indicated by "The product of this working group will
> be a specification" ?
Yes.
> If so, could the work be done in another WG ?
The discussion in DISPATCH pointed proponents to the creation of a small
working group over the other potential options of AD sponsorship or
routing to an existing working group. For deep detail, I encourage you
to listen starting here for the conversation:
. If you'd prefer an executive
summary, the DISPATCH chair conclusion in the minutes
is:
Think this work needs to be done. Discussion of a charter for a small working group.
> We will also need to ensure that this WG is exposed to MOPS WG and
> vice-versa.
Yes, MOPS should be looped in, and the second-to-last paragraph should
be amended to include them. Good catch!
Magnus Westerlund No Objection Comment (2021-01-21):
> I am on the verge of a block here.
Hi, Magnus! I'm glad we're getting your input.
> So the goal is to establish a one-way media over an WebRTC peer
> connection between a media producer and a consumer.
Yes, and it's more narrowly scoped than that. It's one-way media using
WebRTC for broadcasting tools. The general problem of establishing
one-way media for all potential WebRTC use cases is orders of magnitude
more complex, and would involve much more general handling of things
like device capabilities, arbitrary authentication models,
considerations of allocating and deallocating HTTP endpoints, and a host
of additional complications.
Without scoping to a specific use case, this protocol runs the risk of
becoming as complex as SIP, which took several hundred people half a
decade to develop and refine. This is why the charter is careful, in its
opening sentence, to narrow the scope to the use case where we're
actually seeing an acute need and participant interest. If you think
this needs to be made clearer or repeated elsewhere in the charter, I'd
welcome proposed text that aims to avoid this confusion.
> What isn't clear in this work is who is the intended initiator to this
> communication. After having looked in draft-imurillo-whip it appears
> the intention is for the media producer (or its controller) to
> initiate the HTTP connection to a consumer (or its controller). Where
> the necessary configuration is established.
Right, although it's less confusing if you view these roles more
specifically, as is intended by this proposal. The question of which
entity -- a broadcasting tool or a realtime CDN ingest gateway --
initiates a broadcast session is pretty straightforward when the
real-world use cases are considered. Ingest gateways will definitionally
be network servers that can be easily discovered via normal HTTP
resolution techniques. Broadcast tools will (with extremely rare
exception) be scattered around the network on dynamic addresses,
frequently behind NATs, and unable to contribute media to a CDN except
when activated by their operator.
In a purely theoretical sense, the analysis of how to address this
really belongs to the working group rather than the charter. In a
completely practical sense, only one approach is straightforward, so we
know what the working group is almost certain to conclude.
> I assume based on signalling the media flow could be reversed so the
> consumer initates the media establishment, but that is also not clear.
It can't, and it is these kinds of observations that I think would make
you an ideal contributor to the conversation around the protocol
document once we get the working group established. I'd like to make
sure that the model for the protocol is crystal clear in the published RFC.
> Clarifying the high level functionality here in the charter might
> avoid the need for specifically commenting on screens. Because that
> would basically work if the consumer can be the initiator and request
> media to it.
Again, if you can propose different language for the charter that makes
it clear that this kind of use case is explicitly out of scope for the
working group, that would be great. I tried my best to make this clear
by mentioning "broadcasting tools" in the existing text seven times, but
apparently there's still some ambiguity in this version about the scope
of the problem that people have time and energy to work on.
> The other aspect that I realize is missing is the scope of capability
> negotiation here and preference indication. Defining this from a
> WebRTC API perspective might be possible but is not clear. What is
> needed here? What is assumed about third parties creating media
> profiles for this type of devices?
Yes! This is already one of the things I have on my list of open items
that I mention above. It definitely needs consideration by the working
group -- and I'd value your input when we have that discussion -- but
this kind of implementation detail doesn't feel to me like the kind of
thing that rises to the level of a chartering discussion. As an aside,
to reinforce some of the points I make above: solving the issue of
capabilities and preferences is somewhat straightforward for the
specific case of broadcasting tools and network ingest, but arbitrarily
complex for the general case.
Robert Wilton No Objection Comment (2021-01-21):
> I'm not sure whether this should be part of the charter, but would be
> helpful for it to specify which version of HTTPS will be targeted, or
> state a minimum version of HTTPS?
While the revision of BCP 56 has stalled out after reaching consensus in
the HTTPBIS working group (I've just now pinged for status), the current
thinking of HTTP experts is described in its most recent draft revision
:
> Because it is a hop-by-hop protocol, a HTTP connection can be handled
> by implementations that are not controlled by the application; for
> example, proxies, CDNs, firewalls and so on. Requiring a particular
> version of HTTP makes it difficult to use in these situations, and
> harms interoperability for little reason (since HTTP's semantics are
> stable between protocol versions). Therefore, it is RECOMMENDED that
> applications using HTTP not specify a minimum version of HTTP to be
> used.
I would expect that this improved version of BCP 56 will be published
prior to WHIP's conclusion, and wouldn't want to run awry its guidance
in final document review. Even if it isn't published, the rationale in
the quoted passage is sound.
/a
--------------0DBCBDC27E0C07FA4939E9A5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Dear IESG:
Thanks for the careful consideration of the WISH charter! I
understand that it has been approved for public comment. Looking
at the ballot, there are a handful of comments that appear to need
responses. I have left off editorial comments and those pertaining
to the (now added) milestone. I have copied the WISH mailing list
for the information of interested parties.
Alvaro Retana No Objection Comment (2021-01-20):
I don't object to this work, but the list
of companies and tools made me wonder about whether people
associated with them will be engaged in this work. Are they? A
quick look at the wish archive doesn't show much, but the
discussion has probably been carried out elsewhere.
For the most part, we've been holding off doing the core
discussion of issues until after charter approval, so as to ensure
that the broadest set of folks are involved in that conversation.
The proponents of this work have a rough notion of some areas that
need greater focus, and I expect to be sending a list of open
issues to the working group mailing list as soon as the group is
approved.
In terms of the expected participants, we have strong interest
and commitment from Millicast and Caffeine, as well as provisional
but strong interest from three other major entities in this
technology space (one broadcasting tool, two realtime CDNs) who I
don't feel at liberty to name, as they haven't been public about
their interest *yet*. I would also expect the Janus/Meetecho folks
to be keenly interested and participate, although I haven't yet
touched base with them.
In either case, I think it would be a good idea for the charter
to only generically talk about the interest in this type of work
and not explicitly mention companies/tools.
There's a tricky balancing act here. I would expect that most
consumers of this charter -- that is, typical IETF participants --
will not be familiar with the general notion of what broadcaster
studio software is and how it fits into the ecosystem. The two
options here would be either including a very long description of
how these networks work and the role of broadcasting tools in
them; or, alternately, to cite the specific tools and network to
allow folks to explore them and gain an understanding of their
functionality first-hand.
Éric Vyncke No Objection Comment (2021-01-21):
Like Alvaro, I would prefer to drop the
commercial company names as they bring little to the discussion.
Could the background be more concise ?
Not if we drop company names -- it'll have to get longer. :)
Again, the challenge here is that we're talking about technology
that I don't believe many IETF participants are all that familiar
with, and I think having some kind of introduction to the space is
important if they're going to understand what the work is about
and participate in it productively. If you want to suggest
specific edits that preserve that property and yet make it
shorter, that would be great.
Will the 'product' of this WG be a single document that is a
specification as indicated by "The product of this working
group will be a specification" ?
Yes.
If so, could the work be done in another
WG ?
The discussion in DISPATCH pointed proponents to the creation of
a small working group over the other potential options of AD
sponsorship or routing to an existing working group. For deep
detail, I encourage you to listen starting here for the
conversation: <https://youtu.be/d871MoUgAKU?t=4325>. If
you'd prefer an executive summary, the DISPATCH chair conclusion
in the minutes
<https://datatracker.ietf.org/doc/minutes-109-dispatch/> is:
Think this work needs to be done. Discussion of a charter for a small working group.
We will also need to ensure that this WG is exposed to MOPS WG
and vice-versa.
Yes, MOPS should be looped in, and the second-to-last paragraph
should be amended to include them. Good catch!
Magnus Westerlund No Objection Comment (2021-01-21):
I am on the verge of a block here.
Hi, Magnus! I'm glad we're getting your input.
So the goal is to establish a one-way media over an WebRTC peer
connection between a media producer and a consumer.
Yes, and it's more narrowly scoped than that. It's one-way media
using WebRTC for broadcasting tools. The general problem of
establishing one-way media for all potential WebRTC use cases is
orders of magnitude more complex, and would involve much more
general handling of things like device capabilities, arbitrary
authentication models, considerations of allocating and
deallocating HTTP endpoints, and a host of additional
complications.
Without scoping to a specific use case, this protocol runs the
risk of becoming as complex as SIP, which took several hundred
people half a decade to develop and refine. This is why the
charter is careful, in its opening sentence, to narrow the scope
to the use case where we're actually seeing an acute need and
participant interest. If you think this needs to be made clearer
or repeated elsewhere in the charter, I'd welcome proposed text
that aims to avoid this confusion.
What isn't clear in this work is who is
the intended initiator to this communication. After having
looked in draft-imurillo-whip it appears the intention is for
the media producer (or its controller) to initiate the HTTP
connection to a consumer (or its controller). Where the
necessary configuration is established.
Right, although it's less confusing if you view these roles more
specifically, as is intended by this proposal. The question of
which entity -- a broadcasting tool or a realtime CDN ingest
gateway -- initiates a broadcast session is pretty straightforward
when the real-world use cases are considered. Ingest gateways will
definitionally be network servers that can be easily discovered
via normal HTTP resolution techniques. Broadcast tools will (with
extremely rare exception) be scattered around the network on
dynamic addresses, frequently behind NATs, and unable to
contribute media to a CDN except when activated by their operator.
In a purely theoretical sense, the analysis of how to address
this really belongs to the working group rather than the charter.
In a completely practical sense, only one approach is
straightforward, so we know what the working group is almost
certain to conclude.
I assume based on signalling the media
flow could be reversed so the consumer initates the media
establishment, but that is also not clear.
It can't, and it is these kinds of observations that I think
would make you an ideal contributor to the conversation around the
protocol document once we get the working group established. I'd
like to make sure that the model for the protocol is crystal clear
in the published RFC.
Clarifying the high level functionality here in the charter
might avoid the need for specifically commenting on screens.
Because that would basically work if the consumer can be the
initiator and request media to it.
Again, if you can propose different language for the charter that
makes it clear that this kind of use case is explicitly out of
scope for the working group, that would be great. I tried my best
to make this clear by mentioning "broadcasting tools" in the
existing text seven times, but apparently there's still some
ambiguity in this version about the scope of the problem that
people have time and energy to work on.
The other aspect that I realize is missing is the scope of
capability negotiation here and preference indication. Defining
this from a WebRTC API perspective might be possible but is not
clear. What is needed here? What is assumed about third parties
creating media profiles for this type of devices?
Yes! This is already one of the things I have on my list of open
items that I mention above. It definitely needs consideration by
the working group -- and I'd value your input when we have that
discussion -- but this kind of implementation detail doesn't feel
to me like the kind of thing that rises to the level of a
chartering discussion. As an aside, to reinforce some of the
points I make above: solving the issue of capabilities and
preferences is somewhat straightforward for the specific case of
broadcasting tools and network ingest, but arbitrarily complex for
the general case.
Robert Wilton No Objection Comment (2021-01-21):
I'm not sure whether this should be part
of the charter, but would be helpful for it to specify which
version of HTTPS will be targeted, or state a minimum version of
HTTPS?
While the revision of BCP 56 has stalled out after reaching
consensus in the HTTPBIS working group (I've just now pinged for
status), the current thinking of HTTP experts is described in its
most recent draft revision
<https://www.ietf.org/archive/id/draft-ietf-httpbis-bcp56bis-09.txt>:
Because it is a hop-by-hop protocol, a
HTTP connection can be handled
by implementations that are not controlled by the
application; for
example, proxies, CDNs, firewalls and so on. Requiring a
particular
version of HTTP makes it difficult to use in these
situations, and
harms interoperability for little reason (since HTTP's
semantics are
stable between protocol versions). Therefore, it is
RECOMMENDED that
applications using HTTP not specify a minimum version of HTTP
to be
used.
I would expect that this improved version of BCP 56 will be
published prior to WHIP's conclusion, and wouldn't want to run
awry its guidance in final document review. Even if it isn't
published, the rationale in the quoted passage is sound.
/a
--------------0DBCBDC27E0C07FA4939E9A5--
From nobody Thu Jan 21 10:53:48 2021
Return-Path:
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 7EFE03A093D for ; Thu, 21 Jan 2021 10:53:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Level:
X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it
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 0YCi_-4ZLnfH for ; Thu, 21 Jan 2021 10:53:41 -0800 (PST)
Received: from smtpcmd0986.aruba.it (smtpcmd0986.aruba.it [62.149.156.86]) by ietfa.amsl.com (Postfix) with ESMTP id 86BE53A0977 for ; Thu, 21 Jan 2021 10:53:40 -0800 (PST)
Received: from lminiero ([93.35.209.44]) by Aruba Outgoing Smtp with ESMTPSA id 2f5Ol3VF7VOHq2f5Old1Ap; Thu, 21 Jan 2021 19:53:39 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1611255219; bh=dLQffIQBNbjERwxk+KtfFq0AiL4dawdpUtiuJewgg/A=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=FSKMwQOAlN8D5B/F/C+opZO2hduYceCH3KB0tu+opRXax2Z5kRPvK0J2IDQzqWllG ysCXf3rLmdWHa18O7UCXy0Lvr89xm8bYqKPE36K/Tdpd0rDuHpsfFBBZl/QU07If6c W4oMn1518V0okFyMfwtDkn43X4AL/9RsGze/hLLEOBOfGXCewxMVvZc518wN8psTE5 dfrzT7NbInTaGCKmfjhnyrpgHX4hQoG8SGjU5hXfTHIPPgqfJR/roqNMbKqSyX5kb2 arb7d+okkYAruu+ZnZas35rvBdA5XzgZm9LAuzZZGwnMPgSJYzM4gNH2GM3oHRvBSd hUQ0zsVD5PXMQ==
Date: Thu, 21 Jan 2021 19:53:37 +0100
From: Lorenzo Miniero
To: Adam Roach
Cc: The IESG , Alexandre GOUAILLARD , "wish@ietf.org" , Sean Turner
Message-ID: <20210121195337.4809a9ef@lminiero>
In-Reply-To:
References:
Organization: Meetecho
X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfJc02oQcrRDcFXKf/w2qYFjL0bi35IACla5awvNXlbiKR1pT1s9j2WgV42iQQMCwj7VgUlokLITuht9YIpF/h1VuLaTvcGQfwpsZL+BR8OnKqvjr/vCK Xk4pnqCa7r1N3qmRPbubdKFhViuRVEmTGBC2G3WF8+8iL6AMlckLg/YjuxaiyDtCAXd9LQJU9AnbpgQsjgd5ikmvZisoT5mFQ9IqFhwqlti+ME6eQlWAPP/n OlvqrJEsC3vKw9gtG5ld4A==
Archived-At:
Subject: Re: [Wish] WISH Charter Ballot Comments
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 21 Jan 2021 18:53:45 -0000
On Thu, 21 Jan 2021 12:10:30 -0600
Adam Roach wrote:
>
> In terms of the expected participants, we have strong interest and
> commitment from Millicast and Caffeine, as well as provisional but
> strong interest from three other major entities in this technology
> space (one broadcasting tool, two realtime CDNs) who I don't feel at
> liberty to name, as they haven't been public about their interest
> *yet*. I would also expect the Janus/Meetecho folks to be keenly
> interested and participate, although I haven't yet touched base with
> them.
>
Just chiming in to say that yes, we're definitely interested, and I'll
participate actively. We actually did some early prototype already,
using the existing implementation in OBS-WebRTC as a reference, which I
documented a couple of months ago in a blog post. To my knowledge,
there's even people already experimenting with it as we speak, so I'm
definitely interested in following the discussion and contribute.
Lorenzo
--
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero
From nobody Thu Jan 21 19:50:51 2021
Return-Path:
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 DE76A3A0B91 for ; Thu, 21 Jan 2021 19:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.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 CozjT9IC6x8U for ; Thu, 21 Jan 2021 19:50:48 -0800 (PST)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 3B9AA3A0B5A for ; Thu, 21 Jan 2021 19:50:47 -0800 (PST)
Received: by mail-pl1-x631.google.com with SMTP id d4so2485338plh.5 for ; Thu, 21 Jan 2021 19:50:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Te/f26mWP+th94tkMIkS3eRA2j5G0XHZyfHzLNodsso=; b=CQKRhw8KJh9dKsiFleqhd2f39pGxQv+WxS50W78Ek8Lt1/mBX0BlY/XlEYVS0JUHa4 O8BUnzknkl6dvb9HwioeMwF/d3grxFxvH9viKIofNP4nJF3SGLKhjfEjgQBVSHBh5gHt 2ZemuuTzk9D+5Yak9wuRZ+aramANZ5qozFI+ijEtFyMREmi1GFoFGO6PSLBLBw0AhgxM rKl+n8rbsduFhgPdV38lcKGauMiv95Hu30bZO/Sd9mQi4c9HHD7awYmtbCUfqQBBJl2g W5cgmINaEKWKxPyU0GKEk1bsCTi6RR4sfji3wWSXLlNU8b8Tx9e5qCZHxbYaMiLCx3P6 l6vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Te/f26mWP+th94tkMIkS3eRA2j5G0XHZyfHzLNodsso=; b=iL8gstRy0TkRDzQQg3tPVlo54wdPIIuvxnWzvb0H7dgipirNBUBFUFF4tJZeJsIVQ4 p8QZf/l+YsAN8z/De7YFSDoIvpIFp6JawVqI2hVJ+T5ln3TjHJmgqoYm4nEZErE1t/pp +eyf+Xwe1NwW08QoyMZT0Ec2AFB6JSXNERFUDycZ25odbl+7qxSOU14hW56AWJt2WjCE +Ikr2GVCehs6jIywsZbtHzdaOM3neT9XG/ZC4plfOAWl57eyYyvH4anpRbucyR5BEYGw NzdfblbjRvnkBKcJDEYPDTNNe5oQcHiC2nZ81zEtuis7/K4dBEFe2Va2PlZgnIom3j/W lmOg==
X-Gm-Message-State: AOAM530Ptih/cqqTl/rMh6rvDPJwZ+GPYbZg5jQereoQTD4XiZBVzjFG QOTMFqTBcz9NLZuFudDyxJ5dmvlXHkyHzNVhnIA=
X-Google-Smtp-Source: ABdhPJwmPm720t7Z6NHXyDwW6ygPD3RZ0HXgxOGeS0Y1rUPKgRhpTxAC4Y5wY+EyxcDGT+ufIpDJSA==
X-Received: by 2002:a17:902:9b95:b029:df:d859:42bb with SMTP id y21-20020a1709029b95b02900dfd85942bbmr3069672plp.2.1611287447362; Thu, 21 Jan 2021 19:50:47 -0800 (PST)
Received: from [192.168.1.10] ([23.252.60.236]) by smtp.gmail.com with ESMTPSA id r20sm7112567pgb.3.2021.01.21.19.50.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jan 2021 19:50:46 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Sean DuBois
Mime-Version: 1.0 (1.0)
Date: Thu, 21 Jan 2021 19:50:45 -0800
Message-Id: <5E15DFD8-196B-4C58-840F-D52354D93A6D@pion.ly>
References: <20210121195337.4809a9ef@lminiero>
Cc: Adam Roach , Sean Turner , Alexandre GOUAILLARD , The IESG , wish@ietf.org
In-Reply-To: <20210121195337.4809a9ef@lminiero>
To: Lorenzo Miniero
X-Mailer: iPhone Mail (18C66)
Archived-At:
Subject: Re: [Wish] WISH Charter Ballot Comments
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 22 Jan 2021 03:50:50 -0000
I am very interested as well. Developers use Pion to get video into SFUs. Pr=
otocol bridging, pre-recorded etc...=20
Lots of my time is consumed debugging/maintaining signaling code. I am excit=
ed to be involved and eventually see this improve interoperability!
> On Jan 21, 2021, at 10:51, Lorenzo Miniero wrote:
>=20
> =EF=BB=BFOn Thu, 21 Jan 2021 12:10:30 -0600
> Adam Roach wrote:
>=20
>
>>=20
>> In terms of the expected participants, we have strong interest and=20
>> commitment from Millicast and Caffeine, as well as provisional but=20
>> strong interest from three other major entities in this technology
>> space (one broadcasting tool, two realtime CDNs) who I don't feel at
>> liberty to name, as they haven't been public about their interest
>> *yet*. I would also expect the Janus/Meetecho folks to be keenly
>> interested and participate, although I haven't yet touched base with
>> them.
>>=20
>=20
>=20
> Just chiming in to say that yes, we're definitely interested, and I'll
> participate actively. We actually did some early prototype already,
> using the existing implementation in OBS-WebRTC as a reference, which I
> documented a couple of months ago in a blog post. To my knowledge,
> there's even people already experimenting with it as we speak, so I'm
> definitely interested in following the discussion and contribute.
>=20
> Lorenzo
>=20
> --=20
> I'm getting older but, unlike whisky, I'm not getting any better
> https://twitter.com/elminiero
>=20
> --=20
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish
From menglish@llnw.com Fri Jan 22 07:19:47 2021
Return-Path:
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 6AD793A1302 for ; Fri, 22 Jan 2021 07:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=llnw.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 JR0GpjpYg330 for ; Fri, 22 Jan 2021 07:19:45 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 A25E13A1304 for ; Fri, 22 Jan 2021 07:19:44 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id o10so7972243lfl.13 for ; Fri, 22 Jan 2021 07:19:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=llnw.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eyrMF5C6j3vn2moSqaHcP+eoTHsz1SXkct36ogot/Z0=; b=UEBq3amOo0N5eq2qlhx5WlqqTFBXNV/Qh6OfxcU0ieb5pQj5tstuylOFD+RYmMpkrg BpE8v5mT1ibf9YRetlrd8wzjQQrcgTpVXsA6sgZZuVbSCuoMe9kgK71mLruwpA+DVIRg E8vaCEMhJ3AMLafIssRRDPfw61PsMaHW8nUn6uNVv9rsJR+CJrsn4k7hVT/naRJfZvf4 C6apjO7saKnuEOE180G467qEdOfjQ8/iNFAB08XdyiHMECxApD+y2PrOc10cPyIRHGkd LbOFkw8+3ZqEfMOb69Yw51mbk72QhsJPKf00mwNLwWu1pBWZQa58scS1wh1OzUfvwPUM 0uYw==
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=eyrMF5C6j3vn2moSqaHcP+eoTHsz1SXkct36ogot/Z0=; b=jNdLo5uGZ1t3znZFbowLxHOjxXIyauLjyRxB7s/7Dv17v28iVc8gx2DCe12XTgNiq1 PePcgAgnIHntbl93LpW3/FXpglJi1TyKW3TdKhVBd7lkMhom5rJHRaGJmc7qFqsEttI6 zQ56Xb2D0kVf/VtNxU7kXW/85SVBp3ixOHa7bvTDevbSyBbNmIl7uwQKVXvG6yw/A45H J3J4Zb8LmT5SYqm7qUDcuvzllBK/O9+VbUbH0gsk+lVYUQceWXYjtGjBOJCSbW8bLLVw T3ngnwHm3JM82UtPUQHAaOKW7juLZXgm8jH9AmmtY/JOXpjRev1Tb1085lgqCDiGdDVy 8EPw==
X-Gm-Message-State: AOAM532707CtIcS9YblScqsSDt/r0yJchjsWefafkrgDGNsc5amdKQuh jFz44V5au9YAQeavpZV95Z3s/FkFnhKXIgSFkCuIiA==
X-Google-Smtp-Source: ABdhPJwop3BI2KyDkmIePe1u+/pb08teqeaSqC4X44CwXaCj8zbw+2TBt6j++nvNMBmUALv5A23ODNF/dZ8kGSG+rts=
X-Received: by 2002:ac2:4d24:: with SMTP id h4mr1405962lfk.458.1611328782443; Fri, 22 Jan 2021 07:19:42 -0800 (PST)
MIME-Version: 1.0
References:
In-Reply-To:
From: Mike English
Date: Fri, 22 Jan 2021 10:19:31 -0500
Message-ID:
To: Adam Roach
Cc: The IESG , Alexandre GOUAILLARD , "wish@ietf.org" , Sean Turner
Content-Type: multipart/alternative; boundary="000000000000b1c1dc05b97eb709"
Archived-At:
X-Mailman-Approved-At: Fri, 22 Jan 2021 07:52:28 -0800
Subject: Re: [Wish] WISH Charter Ballot Comments
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 22 Jan 2021 15:21:10 -0000
--000000000000b1c1dc05b97eb709
Content-Type: text/plain; charset="UTF-8"
Hello,
Thank you for getting the ball rolling on this!
On Thu, Jan 21, 2021 at 1:10 PM Adam Roach wrote:
> In terms of the expected participants, we have strong interest and
> commitment from Millicast and Caffeine, as well as provisional but strong
> interest from three other major entities in this technology space (one
> broadcasting tool, two realtime CDNs) who I don't feel at liberty to name,
> as they haven't been public about their interest *yet*.
>
I can confirm Limelight's interest in seeing this aspect of the ecosystem
standardized.
I'm personally happy to help in any way I can.
-Mike
--
[image: Limelight Networks]
Mike English* Senior Engineer, SMTS*
EXPERIENCE FIRST.
+1 616 330 2527 <+1+616+330+2527>+1 616 723 0277 <+1+616+723+0277>
www.limelight.com
[image: Facebook] [image:
LinkedIn] [image:
Twitter]
--000000000000b1c1dc05b97eb709
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello,
Thank you for getting the ball rollin=
g on this!
=20
=20
=20
In terms of the expected participants, we have strong interest
and commitment from Millicast and Caffeine, as well as provisional
but strong interest from three other major entities in this
technology space (one broadcasting tool, two realtime CDNs) who I
don't feel at liberty to name, as they haven't been public ab=
out
their interest *yet*.=C2=A0
I can confirm Limelight's interest in seeing thi=
s aspect of the=C2=A0ecosystem standardized.
I'm personally happ=
y to help in any way I can.
-Mike
--
--000000000000b1c1dc05b97eb709--
From nobody Fri Jan 22 10:34:13 2021
Return-Path:
X-Original-To: wish@ietf.org
Delivered-To: wish@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 048613A13E3; Fri, 22 Jan 2021 10:34:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG
To: "IETF-Announce"
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: wish@ietf.org
Reply-To: iesg@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <161134044642.32352.8777181985600426762@ietfa.amsl.com>
Date: Fri, 22 Jan 2021 10:34:06 -0800
Archived-At:
Subject: [Wish] WG Review: WebRTC Ingest Signaling over HTTPS (wish)
X-BeenThere: wish@ietf.org
X-Mailman-Version: 2.1.29
List-Id: WebRTC Ingest Signaling over HTTPS
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 22 Jan 2021 18:34:07 -0000
A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by 2021-02-01.
WebRTC Ingest Signaling over HTTPS (wish)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
Alex Gouaillard
Sean Turner
Assigned Area Director:
Murray Kucherawy
Applications and Real-Time Area Directors:
Barry Leiba
Murray Kucherawy
Mailing list:
Address: wish@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/wish
Archive: https://mailarchive.ietf.org/arch/browse/wish/
Group page: https://datatracker.ietf.org/group/wish/
Charter: https://datatracker.ietf.org/doc/charter-ietf-wish/
The WISH working group is chartered to specify a simple, extensible,
HTTPS-based signaling protocol to establish one-way WebRTC-based audiovisual
sessions between broadcasting tools and real-time media broadcast networks.
Background:
WebRTC defines a set of wire protocols for real-time media transmission, as
well as a profile of the Signaling Description Protocol (SDP) for setting up
and controlling the associated media streams. Because of its typical use
cases, and to increase overall flexibility, WebRTC did not specify a wire
protocol for exchanging SDP messages, leaving the creation of such protocols
up to the applications that use WebRTC. This works well when WebRTC clients
are vertically integrated with the servers they communicate with, as it
allows for rapid iteration of new features.
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.
Deliverables:
The product of this working group will be a specification for a simple,
extensible, HTTPS-based signaling protocol to establish one-way WebRTC-based
audiovisual sessions between broadcasting tools and real-time media broadcast
networks.
This working group will use existing HTTPS, WebRTC, and SDP mechanisms to the
extent possible. While no extensions to those core protocols is expected, the
working group may consider such extensions if they are necessary to meet the
requirements of broadcasting tools and networks. Any such work will be
coordinated with the HTTPBIS and/or MMUSIC working groups, as appropriate.
Additionally, this working group will coordinate with HTTPBIS and HTTPAPI to
assure that the HTTP protocol is being used according to current best
practice.
While there may be other problems that the proposed mechanism may solve or
nearly solve, such as video display clients connecting to the egress of a
media delivery network, adding explicit protocol support for those use cases
is not in scope for the WISH working group.
Milestones:
Dec 2021 - Submit web ingest signaling protocol to IESG for publication