共计 1427 个字符，预计需要花费 4 分钟才能阅读完成。
文 / Mark Cymontkowski
译 / John
原文
https://www.srtalliance.org/i…
许多企业现有的内部部署广播工作流程都基于 RTP 协议，但是您是否知道 SRT 可以通过在不可靠的网络（例如公共网络）上利用 SRT 隧道传输 RTP 来扩展这些工作流程的范围？
在这篇文章中，我们将以一个非常简单的端到端工作流为例向您展示这一过程。下图显示了如何使用 RTP 将 MPEG2 传输流从视频编码器发送到受保护网络（例如企业 LAN 或 MPLS 租用线路）内的视频解码器。
通过可靠网络（例如局域网）进行 RTP 传输
用公共互联网取代专用网络并不是那么简单，因为不可靠的网络会引入数据包丢失和抖动。此外，流在离开或进入企业网络时必须穿过防火墙。这期间内容不再受到保护，非常容易被暴露。
RTP 通过不可靠的网络传输，如公共互联网
SRT 能够恢复丢失的数据包，也能加密内容和遍历防火墙，这使其非常适合用作跨公共互联网的隧道。
以下是它的工作原理：
RTP 流量被发送到 UDP 接收器，UDP 接收器通过 SRT 连接转发包括 RTP 报头在内的 MPEG-TS 有效载荷；而在接收器端，流作为 UDP 播放，但由于 RTP 报头仍然存在，因此它会将本地 RTP 流发送到现有的 RTP 解码器。
通过 SRT 在不可靠的网络（例如公共互联网）上隧道传输 RTP
可以使用开源 SRT 包中的 srt-live-transmit 示例应用程序来评估此配置。来自编码器的源 RTP 流必须指向 SRT 发送器的 UDP 输入并将目标位置处接收器的 UDP 输出发送到解码器的 RTP 输入端口。
由于应用程序在从 UDP 读取数据时期望没有 RTP 头的 MPEG-TS 流量，因此默认情况下，它被配置成为每 UDP 包接收 1316 字节（7 个 MPEG-TS 帧）的有效载荷。该命令行选项用于增加 SRT 有效负载大小。
这些是发送方（UDP 到 SRT）和接收方（SRT 到 UDP）的两个 srt-live-transmit 示例命令行：
在该示例中，源（例如 RTP 编码器）正在将 RTP 流发送到 192.168.0.20:2000。发送方端 srt-live-transmit 接收包括端口 2000 上的 RTP 报头在内的 MPEG-TS 流并侦听端口 1000 上的传入接收方连接。在我们的示例中，运行发送方应用程序的计算机的 IP 地址为 192.168.0.10。不同机器上的接收器应用程序作为呼叫者连接到服务器，接收 SRT 流并将该流作为 UDP 数据输出到 IP 地址为 192.168.0.30 和端口 3000 的 RTP 接收器（例如解码器）。
注意：使用 SRT 1.4 版时，在使用 srt-live-transmit 时不再需要指定有效负载和 / 或块大小（-c）。
类似地，具有 FEC（SMPTE 2022- 1 前向纠错）的冗余 RTP 可以通过 SRT 连接进行隧道传输。FEC 列和行数据包的额外 UDP 流可以通过两个额外的 SRT 连接进行路由。但是，所有三个 SRT 连接都可以通过使用 SRT 复用在单个 UDP 端口上发送，SRT 复用是核心协议的一部分。
使用 SRT 复用通过 SRT 与 FEC 隧道传输 RTP
我们可以进一步扩展此设置以支持冗余 RTP（SMPTE 2022-7）工作流程。由于 RTP 报头在冗余设置的任一路径上保持不变，因此系统仍可在接收器侧同步多个 RTP 流。
通过 SRT 隧道传输多路径 RTP 以实现冗余
此时，值得一提的是，在 IBC2019 时间范围内，本机冗余工作流程将进入 SRT 协议。这意味着每个启用 SRT 的端点都可以使用此功能从而大大简化了安装。
