Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
* [Galene] Fwd: WG Action: Formed WebRTC Ingest Signaling over HTTPS (wish)
       [not found] <161254855522.17324.13801347976864604215@ietfa.amsl.com>
@ 2021-02-05 18:14 ` Michael Ströder
  2021-02-05 20:30   ` [Galene] " Juliusz Chroboczek
  0 siblings, 1 reply; 2+ messages in thread
From: Michael Ströder @ 2021-02-05 18:14 UTC (permalink / raw)
  To: galene

FYI although it's not about video conferencing. Maybe some inspiring
discussions will happen there.

Ciao, Michael.

-------- Forwarded Message --------
Subject: WG Action: Formed WebRTC Ingest Signaling over HTTPS (wish)
Date: Fri, 05 Feb 2021 10:09:15 -0800
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: wish-chairs@ietf.org, The IESG <iesg@ietf.org>, wish@ietf.org

A new IETF WG has been formed in the Applications and Real-Time Area. For
additional information, please contact the Area Directors or the WG Chairs.

WebRTC Ingest Signaling over HTTPS (wish)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Alex Gouaillard <agouaillard@gmail.com>
  Sean Turner <sean+ietf@sn3rd.com>

Assigned Area Director:
  Murray Kucherawy <superuser@gmail.com>

Applications and Real-Time Area Directors:
  Barry Leiba <barryleiba@computer.org>
  Murray Kucherawy <superuser@gmail.com>

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 Session 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, MMUSIC, and/or MOPS 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



_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Galene] Re: Fwd: WG Action: Formed WebRTC Ingest Signaling over HTTPS (wish)
  2021-02-05 18:14 ` [Galene] Fwd: WG Action: Formed WebRTC Ingest Signaling over HTTPS (wish) Michael Ströder
@ 2021-02-05 20:30   ` Juliusz Chroboczek
  0 siblings, 0 replies; 2+ messages in thread
From: Juliusz Chroboczek @ 2021-02-05 20:30 UTC (permalink / raw)
  To: Michael Ströder; +Cc: galene

> Mailing list:
>   Address: wish@ietf.org
>   To subscribe: https://www.ietf.org/mailman/listinfo/wish
>   Archive: https://mailarchive.ietf.org/arch/browse/wish/

Thanks for the info, I've just subscribed.

For anyone who's not familiar with the IETF: anyone may participate in an
IETF working group, and while the in-person meetings are outrageously
expensive, online participation is free.  Depending on how the chairs
handle the WG, it may or may not be possible to participate without going
to the in-person meetings.

Before you invest too much time in the IETF, be aware that everything
takes ages, especially when the IESG members decide to get involved.

-- Juliusz

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-02-05 20:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <161254855522.17324.13801347976864604215@ietfa.amsl.com>
2021-02-05 18:14 ` [Galene] Fwd: WG Action: Formed WebRTC Ingest Signaling over HTTPS (wish) Michael Ströder
2021-02-05 20:30   ` [Galene] " Juliusz Chroboczek

Galène videoconferencing server discussion list archives

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lists.galene.org/galene

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 galene galene/ https://lists.galene.org/galene \
		galene@lists.galene.org
	public-inbox-index galene

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git