webrtc-RTPRTSPRTCP的概念

Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。

RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。

RTP 由两个紧密链接部分组成： RTP ― 传送具有实时属性的数据；RTP 控制协议（RTCP） ― 监控服务质量并传送正在进行的会话参与者的相关信息。

实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（Quality of Service）提供反馈。

RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。

安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC 3711发布。

由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议（RTP Control Protocol或RTCP）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP或SRTCP）；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。

在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。

RTSP（Real Time Streaming Protocol）是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 11类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。 因为与HTTP11的运作方式相似，所以代理服务器《Proxy》的快取功能《Cache》也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

RTP：实时传输协议（Real-time Transport Protocol）

RTP/RTCP是实际传输数据的协议

RTP传输音频/视频数据，如果是PLAY，Server发送到Client端，如果是RECORD，可以由Client发送到Server

整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议（即RTCP）

RTSP：实时流协议（Real Time Streaming Protocol，RTSP）

RTSP的请求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顾名思义可以知道起对话和控制作用

RTSP的对话过程中SETUP可以确定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以开始或者停止RTP的发送，等等

RTCP：

RTP/RTCP是实际传输数据的协议

RTCP包括Sender Report和Receiver Report，用来进行音频/视频的同步以及其他用途，是一种控制协议

以下是每个协议的概要介绍：

一、RTP数据协议

RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。

其中比较重要的几个域及其意义如下：

CSRC记数（CC）：表示CSRC标识的数目。CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者的语音数据组合为一个RTP数据源。

负载类型（PT）：标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。

序列号：用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。

时间戳：记录了负载中第一个字节的采样时间，接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。

从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的。

二、RTCP控制协议

RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。

RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：

SR：发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。

RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。

SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。

BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。

APP：由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是多播方式，因此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。

在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。

三、RTSP实时流协议

作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作（RFC2326）。

RTSP在制定时较多地参考了HTTP/11协议，甚至许多描述与HTTP/11完全相同。RTSP之所以特意使用与HTTP/11类似的语法和操作，在很大程度上是为了兼容现有的Web基础结构，正因如此，HTTP/11的扩展机制大都可以直接引入到RTSP中。

由RTSP控制的媒体流集合可以用表示描述（Presentation Description）来定义，所谓表示是指流媒体服务器提供给客户机的一个或者多个媒体流的集合，而表示描述则包含了一个表示中各个媒体流的相关信息，如数据编码/解码算法、网络地址、媒体流的内容等。

虽然RTSP服务器同样也使用标识符来区别每一流连接会话（Session），但RTSP连接并没有被绑定到传输层连接（如TCP等），也就是说在整个RTSP连接期间，RTSP用户可打开或者关闭多个对RTSP服务器的可靠传输连接以发出RTSP 请求。此外，RTSP连接也可以基于面向无连接的传输协议（如UDP等）。

检索媒体：允许用户通过HTTP或者其它方法向媒体服务器提交一个表示描述。如表示是组播的，则表示描述就包含用于该媒体流的组播地址和端口号；如果表示是单播的，为了安全在表示描述中应该只提供目的地址。

邀请加入：媒体服务器可以被邀请参加正在进行的会议，或者在表示中回放媒体，或者在表示中录制全部媒体或其子集，非常适合于分布式教学。

添加媒体：通知用户新加入的可利用媒体流，这对现场讲座来讲显得尤其有用。与HTTP/11类似，RTSP请求也可以交由代理、通道或者缓存来进行处理。

摘要：视频会议设备中，服务器是很重要的一个设备，视频会议服务器的搭建关系到视频会议设备能否正常使用。搭建视频会议服务器时，先要购买服务器，然后安装docker以及docker-compose，配置安全组、域名解析后，开始安装部署，测试完成后，与自己的系统集成即可。在搭建视频会议服务器时，要注意的点有很多，下面一起来了解一下视频会议服务器如何搭建吧。一、视频会议服务器如何搭建

视频会议是现代职场很常见的，几乎每个职场人都在使用视频会议进行日常沟通和举行线上交流。视频会议设备有很多，服务器就是其中一个，那么视频会议服务器怎么搭建呢？

1、购买服务器

如果没有服务器的话，需要先购买一台服务器。

2、安装docker以及docker-compose

为了方便安装应用，我们需要准备Docker环境。Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux或Windows操作系统的机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。使用docker来部署应用是非常简单的，一般情况下，只需要一行命令即可完成。

3、配置安全组

视频会议功能内部采用WEBRTC技术，会使用比较多的端口，因此需要在轻量服务器的防火墙策略上放行相应的端口，要求开放的端口主要有：

22TCP：SSH端口；80TCP：HTTP端口；443TCP:HTTPS端口；3478TCP+UDP：TURN服务器端口，TURN服务器是在视频双方无法直接建立点对点连接时进行流量转发使用；40000-57000TCP+UDP：KurentoMediaServer建立媒体连接的端口；57001-65535TCP+UDP：TURN服务器建立媒体连接的端口。除此之外，请确保这些端口80，443，3478，5442，5443，6379和8888不能被占用。如果嫌麻烦而且仅仅是测试环境使用，可以直接放行所有的端口。

4、域名解析

将要使用的域名解析到服务器的IP上。如果使用的是国内的服务器，域名需要备案。如果没有备案的域名，需要选购香港的服务器。或者也可以不使用域名，直接使用IP。直接使用IP的话，需要自己来签发并配置证书并配置浏览器信任证书。

5、开始安装部署

准备工作做完以后，就可以开始下载安装了。默认在/opt目录下进行安装：首先进入到/opt目录下，然后使用openvidu提供的脚本进行安装；进入到openvidu目录里，使用熟悉的工具来编辑env文件，本文档中使用letsencrypt来自动签发证书（ov的默认选项），都配置好了以后，然后运行下面命令启动：“/openvidustart”，此命令会拉取并启动相应服务的docker镜像，执行完毕后，用dockerps可以看出启动的容器。

启动完毕后，访问https://xxxxxxxxxxxx:port验证服务器，然后在标签页多打开页面，都加入同样的房间，来测试效果。

6、与自己的系统集成

openvidu提供了各种语言和框架的SDK，包含服务端和客户端，并且提供了大量的可以直接复制粘贴的例子来使用。只要把上面的服务配置好了，只需要花十几分钟，就可以集成到自己的系统中。

二、视频会议服务器搭建有哪些要注意的点

1、视频会议服务器端带宽需要经过合理计算，才能保障带宽在会议进行时充足。而参会终端则可以在普通的adsl网络环境中参会，但是视频会议服务器端对带宽的要求一定是有线的光纤。

2、建议不要自购服务器和软件端进行匹配使用，并不是购买高端软件+高配的企业内网视频会议服务器就可以达到最佳效果。其实，这样存在视频会议软件与服务器不兼容的问题，从而导致服务器搭建的企业内网视频会议不够稳定。采用软硬一体的视频会议服务器，不经可以避免这样的风险，又可以快速部署稳定、完全、流畅的视频会议。

3、视频会议服务器建议搭建到自己公司内部的防火墙和路由器，这种私有部署的视频会议服务器，使得企业内部会议在安全性上有更具优势。

4、企业视频会议服务器搭建采用买断的方式性价比较高，而且企业内网搭建视频会议可以最大限度保证服务器端带宽的稳定，避免服务器端带宽不足导致的视频会议不稳定的问题。

WebRTC 是一个实现浏览器之间实时通信的技术，主要基于 JavaScript，同时需要一些底层支持，比如 ICE，STUN，TURN 等协议。因此，使用 PHP 来开发 WebRTC 可能并不是最合适的选择，因为 PHP 是一种服务器端语言，主要用于生成 HTML 等静态页面，而不是处理实时数据流。

不过，如果您需要在 PHP 中使用 WebRTC 技术，也是可以的，但需要使用一些第三方库和组件，比如 Ratchet、ReactPHP、PHP-WebRTC 等等。这些工具可以让 PHP 与 JavaScript 进行实时通信，并使用 WebRTC 实现音视频通信。

总体来说，使用 PHP 来开发 WebRTC 可能相对较为困难，需要具备一定的底层协议和通信技术的知识，而且需要使用一些第三方库和组件。如果您已经有 WebRTC 的经验，同时也熟悉 PHP 的使用，那么这样的开发可能会相对容易些。