GStreamer 和 WebRTC HTTP 信令

我们中的 WebRTC 开发者应该还记得我们了解 WebRTC 的第一件事，那就是它是媒体和数据点对点通信的规范，但它没有规定如何进行信令传输。

或者更简单地说，如果你想在网络上给某人打电话，WebRTC 会告诉你如何传输音频、视频和数据，但它忽略了如何拨打电话本身：如何找到你正在呼叫的人，让他们知道你想打电话给他们，以及在你们可以看到对方并互相交谈之前需要执行的几个步骤。

虽然这允许服务提供自己的机制来管理 WebRTC 呼叫的工作方式，但缺乏标准机制意味着通用应用程序需要单独集成它们想要支持的每项服务。例如，GStreamer 的 webrtcsrc 和 webrtcsink 元素支持各种信号协议，包括 Janus Video Rooms、LiveKit 和 Amazon Kinesis Video Streams。

不过，如果能为客户端提供标准的信令方式，将有助于开发人员专注于自己的应用程序，而不必担心与不同服务的互操作性。

信令标准化

基于这一动机，IETF WebRTC Ingest Signalling over HTTPS (WISH) 工作组一直在制定两个规范：

WebRTC-HTTP Ingestion protocol (WHIP)
WebRTC-HTTP Egress Protocol (WHEP)

正如其名称所示，这些规范提供了一种使用 HTTP 执行信令的方法。WHIP 为我们提供了一种向服务器发送媒体的方式，例如将媒体摄入到 WebRTC 通话或直播流中。

相反，WHEP 则为客户端提供了一种使用 HTTP 信令使用 WebRTC 流的方法——例如，创建一个简单的基于 Web 的 WebRTC 调用消费者，或者接入实时流管道。

从这个角度来看，WHIP 和 WHEP 既可以用于调用应用程序，也可以作为提取或播放实时流的替代方式，具有更低的延迟和近乎无处不在的实时通信 API。

事实上，已经有多项服务支持此功能，包括Dolby Millicast、 LiveKit和Cloudflare Stream。

使用 GStreamer 的 WHIP 和 WHEP

我们知道 GStreamer 已经为开发人员提供了两种处理 WebRTC 流的方法：

webrtcbin：提供低级 API，类似于基于浏览器的 WebRTC 用户熟悉的 PeerConnection API

webrtcsrc 和 webrtcsink：提供可以分别从 WebRTC 端点生成媒体 / 向 WebRTC 端点使用媒体的高级元素

在Asymptotic，我们一直在使用这些构建块来实现 WHIP 和 WHEP 规范的 GStreamer 元素。你可以在GStreamer Rust 插件存储库中找到这些。

我们最初的实现基于webrtcbin，但后来转移到了更高级别的 API 以重用常见功能（例如自动编码/解码和拥塞控制）。

今天，我们有 4 个要素在实施 WHIP 和 WHEP。

Clients

whipclientsink：这是基于 webrtcsink 实现的 WHIP 客户端，通过它可以向 WHIP 服务器发送媒体。例如，将摄像机流式传输到 WHIP 服务器就非常简单：

gst-launch-1.0 -e \
  v4l2src ! video/x-raw ! queue ! \
  whipclientsink signaller::whip-endpoint="https://my.webrtc/whip/room1"

whepclientsrc：这项工作正在进行中，它允许我们构建播放器应用程序以连接到 WHEP 服务器并从中消费媒体。目标是使播放 WHEP 流变得简单，如下所示：

gst-launch-1.0 -e \
  whepclientsrc signaller:whep-endpoint="https://my.webrtc/whep/room1" ! \
  decodebin ! autovideosink

客户端元素与我们想象中的基于 GStreamer 的客户端的工作方式非常吻合。你可以将任意存储或实时媒体流式传输到 WHIP 服务器，并播放 WHEP 服务器提供的任何媒体。这两个管道都隐含地受益于 GStreamer 使用其运行平台的硬件加速功能的能力。

服务器

whipserversrc：允许我们创建一个 WHIP 服务器，客户端可以连接到该服务器并提供媒体，每个服务器都将作为 GStreamer pad 公开，可以根据需要任意路由和组合。我们有一个示例服务器，可以播放发送给它的所有流。
whepserversink：最后，我们正在进行的工作是通过 WHEP 发布任意流，以供基于 Web 的客户端使用这些媒体。

这两个服务器元素开启了许多有趣的可能性。我们可以使用 WHIP 提取任意媒体，然后根据应用程序的要求对其进行解码和处理或转发。我们预计服务器 API 将随着时间的推移而增长，具体取决于我们希望支持的不同类型的用例。