WebRTC开发者社区为开发者提供最新最全的WebRTC资料
目录
  • 首页
  • WebRTC概念与基础
  • WebRTC项目与应用
  • WebRTC教程资料
  • WebRTC开发资源
  • WebRTC源码分析
  • WebRTC服务端开发
  • WebRTC网络与通信
  • WebRTC编码与解码
  • WebRTC问题与缺陷
  • WebRTC-Androd端开发
  • WebRTC-RFC文档
  • WebRTC音频处理
  • WebRTC-Mediasoup
  • FFMpeg音视频处理
  • H264编解码基础
  • openCV相关

详解|SRT编码器中Rendezvous模式详解

2022-06-27 11:51:54

 KILOVIEW最近发布SRT相关文章中,大家对caller模式和listener模式比较容易理解,近期收到很多客户反馈,对Rendezvous模式不是特别了解,下面将对Rendezvous模式进行详细介绍。

功能

两台设置Rendezvous模式的设备会共同协商,通过相同的UDP端口号建立一个SRT会话。

使用场景

两台设备所在的网络都有防火墙(或者路由器,功能等同),防火墙Outside接口是公网IP地址,但是没有防火墙的操作权限(即无法配置端口映射),如果防火墙设置了适当的工作模式,可通过Rendezvous模式建立SRT会话。

一旦完成SRT连接的建立,SRT源设备和SRT目标设备便开始交换控制信息,然后直接利用建立起来的SRT通道去传输数据。

示例

Rendezvous模式可以在两端防火墙都没有做端口转发规则时建立SRT连接,从而实现两点之间的视频传输。这时,需要在两端分别设置对方的出口公网IP以及相同的端口号,这样,两台设备将同时向对方的出口公网IP发送控制信息数据包,用来建立SRT连接。

某公司临时决定从长沙办事处将视频信号实时传输到深圳总部,来不及申请在防火墙中做端口转发规则,所以两端的设备都没办法通过对方公网IP的某个特定端口来直接找到对方。这时,就可以使用Rendezvous模式来建立SRT连接,我们需要将长沙的SRT设备(编码器)设置为Rendezvous模式,并写入深圳SRT设备的出口公网IP地址和一个没有被使用的UDP端口号,同时,再将深圳的SRT 设备(解码器)也设置为Rendezvous模式,并写入长沙SRT设备的出口公网IP地址和相同的UDP端口号,这样就可以建立起SRT连接了。

图:SRT源设备(编码器)和SRT目标设备(解码器)的网络关系

原理

在前面的示例场景中很轻松就完成了Rendezvous模式下的SRT连接,看似水到渠成,然而实际情况并不是这么简单,在这背后还隐藏着一些网络的相关知识,下面我们就来简单讨论一下SRT是如何使用Rendezvous模式穿过防火墙建立连接的。

当然,网络安全与防火墙是一门很深奥的专业网络知识,这里就不跟大家讨论深层次的内容了,只针对和SRT相关的知识做简单的分享。

首先,我们需要知道,在使用Rendezvous模式时,设备发出的控制信息数据包的源端口与目的端口都是一样的。在之前的例子中,编码器发出的控制信息数据包的源端口为12345,目标端口也是12345,同样的,解码器发出的控制信息数据包的源端口和目标端口也都是12345。换句话说,这“四个”端口号相同是Rendezvous模式穿越防火墙建立SRT连接的必要条件。

因此,在编解码器之间的防火墙就必须确保不转换数据包包头中的端口号。

图:Rendezvous模式下两端使用相同的端口号穿过防火墙建立SRT连接

现在市场上能够见到的防火墙,基本都是能够进行状态检测的状态防火墙(stateful firewall,现在由于这个功能过于普遍,也就不再有人特意提出这个概念了),它能够进行状态数据包检查或状态查看,实现连接追踪(connection tracking)的功能,而Rendezvous模式正是倚靠这个功能来创建一个贯穿两个防火墙的网络通道,并在其中进行数据传输。

防火墙在工作时,会根据正在传输的流量,创建一个连接追踪表(connection tracking table),并保持动态更新。

例如在上图中,在防火墙A中的连接追踪表会记录下源设备(编码器)的内网IP和端口号、NAT转换后的公网IP和端口号、以及访问的目标设备(解码器)防火墙的公网IP和端口,如下表:

这时,当对端发来数据包时,防火墙A的连接追踪表还会记录下另一条反向入站信息,如下表:

当反向的数据包到达防火墙A时,发送数据与接收数据相同的端口号会对防火墙A产生“欺骗”效果,让它认为收到的入站数据是对出站数据的回复消息,从而允许数据包通过防火墙,一直到这个传输会话断开,SRT连接也就这样建立起来了。

在大多数场景中,我们用的网络设备(防火墙和路由器)都是使用PAT(NAT重载)进行局域网IP到公网IP的地址转换。这时,网络设备在转换地址时都会改变源端口号,所以Rendezvous模式大多无法使用,不如直接用路由器做静态端口映射规则来的方便,这样就可以在这端使用Listener的模式,监听映射的端口,另一端使用Caller模式建立连接;相比之下,Rendezvous模式反而是很少被用到。

 

发布于 2020-05-07 09:54

By:rasp | WebRTC网络与通信 |

  • 分类目录

    • WebRTC概念与基础 (252)
    • WebRTC项目与应用 (33)
    • WebRTC教程资料 (38)
    • WebRTC开发资源 (13)
    • WebRTC源码分析 (19)
    • WebRTC服务端开发 (27)
    • WebRTC网络与通信 (43)
    • WebRTC编码与解码 (15)
    • WebRTC问题与缺陷 (2)
    • WebRTC-Androd端开发 (2)
    • WebRTC-RFC文档 (1)
    • WebRTC音频处理 (6)
    • WebRTC-Mediasoup (2)
    • FFMpeg音视频处理 (3)
    • H264编解码基础 (10)
    • openCV相关 (1)
  • 最新文章

    • TensorFlow 中的通信机制 ——Rendezvous(二)gRPC 传输
    • 详解|SRT编码器中Rendezvous模式详解
    • 完整SIP/SDP媒体协商概论-ICE初始offer发送详解
    • 完整SIP/SDP媒体协商概论-ICE初始offer发送详解
    • WebRTC - ICE 过程简述
    • Webrtc delay-base-bwe代码分析(2): InterArrival模块
    • 从janus中学习webrtc的ice简单交换过程
    • WebRTC PeerConnection 建立连接过程介绍
    • P2P技术详解(三):P2P技术之STUN、TURN、ICE详解(转载)
    • WebRTC ICE 状态与提名处理
    • licode服务端总结
    • libnice调用流程分析
    • libnice调用流程分析
    • licode 学习总结
    • Licode—基于webrtc的SFU/MCU实现
    • ncnn_example
    • opencv-rtsp运动检测
    • WebRTC 基于GCC的拥塞控制(上)
    • WebRTC 基于GCC的拥塞控制(下)
    • LearningWebRTC: 拥塞控制LearningWebRTC: 拥塞控制
    • WebRTC入门(三)---- 目录结构
    • WebRTC之带宽控制部分学习(1) ------基本demo的介绍
    • webrtc视频流程
    • webrtc nack实现原理
    • webrtc QOS方法一(NACK实现)
    • webrtc源码之nack&&rtx详解
    • webrtc的rtp重传代码分析
    • webrtc QOS方法一(NACK实现)
    • WebRTC基于TransportCC和Trendline Filter的发送端码率估计(Sendside-BWE)
    • WebRTC中丢包重传NACK实现分析
  • 链接

    • WebRTC官网
    • xSky 实验室
    • 树莓派技术圈
    • 声网 Agora
    • WebRTC中文网
    • web性能权威指南
    • WebRTC官网
    • webrtc在线源码
    • webrtc在线源码
    • webrtc
    • webrtc示例
    • LiveVideoStack
    • 雷霄骅(leixiaohua1020)的专栏
  • 开源项目


Powered By xblog Copyright 0xsky.com All Rights Reserved.

Copyright WebRTC.ren All Rights Reserved.