监控。顾名思义，监：古人以水为镜，"监"就是一个人弯着腰，睁大眼睛，从器皿的水中照看自己 的面影。本义：监督，察看督促；控：操纵、制约控制。
因此，监控就要达到既可见又可控的效果。而"可见"和"可控"在使用者面前的实际呈现就是实 况和轮切。
监控业务由传统的模拟监控（CCTV）已经发展到了网络监控的阶段。对于监控数据的实时浏览和摄像机控制的要求也越来越离。
监控系统的主要工作流程依次为：a摄像机采集图像信号；b采音设备采集声音信号；c音视频编解 码设备对信号进行模数转换和数据压缩编码等处理，并通过网络进行传输；d中央管理控制设备接入网络 后对系统进行管理控制认证等工作、通过中心集中存储等方式进行录像数据的处理；e各接收端通过接入网络的电脑终端可方便的查看视频图像，同时通过解码器发送到监视器墙显示。
实况是指将前端摄像头获取的图像实时地显示在监视器或者用户PC的软解客户端上。
轮切是伴随实况产生的一个必然结果。在实际监控环境中，前端的摄像头（编码器）数量是远大于监控中心的解码设备的，往往是摄像头的数量成百上千，而监视器的数量在十几到几十个。这必然不能够保证每一个摄像头的图像都显示在监视器上，而且也没有必要。只要隔一段时间对所有的摄像头图像做一遍巡视即可，当发现某地出现问题时，再进行一对一实况。轮切就是适应这种需求而产生的。
传统监控实况业务采用同轴电缆或模拟*端机光**和数字*端机光**通过把视频及控制信号转换为光信号进行一对一的传输。通过视频切换矩阵在同一个监视器上对若干个监控摄像机的图像进行轮循显示。
网络监控在实时数据的传输和显示，通过对模拟音视频信号进行转换和压缩，利用越来越广的IP网络进行传输，基于IP网络单组播协议实现了一对多的实时业务。
不同于传统监控方式的模拟信号的传输，网络监控的优势就在于将模拟视频信号转换为数字信号， 编码压缩并封装在IP包中进行传输，通过IP传输的特点使其不受线缆的铺设影响而可以在任何网络接入的 地点可以方便的进行实况的浏览和视频数据的查询。
对于实况业务，行业、商业以及各个地方都出台了不少相关的标准。具体的细节本文不加以详述， 概括起来无外乎以下部分：1图像的采集与处理，2接收数据解码与现实，3中心控制与认证服务，4音视频数据的分发和存储。
网络监控系统中，要求实现通过网络的实时音视频浏览。可以在远程计算机上实时监控，亦可实现 在远程通过硬件解码器在监视器、电视墙上观看实时视频。浏览客户端可采用B/S或C/S架构。可实现对电视墙投放视频的灵活控制。
承载网络本身必须对视频监控业务端到端的视频传送服务质呈(QoS)提供保障。网络视频监控系统的 QoS实现要求IP承载网络在承载端到端的视音频IP包码流时，做到延迟小、抖动低、丢包率低。其中对网络视频监控系统Qos影响最重要的指标就是丢包率。
实现音视频数据在IP网络上进行传输，可以采用多种方式。TCP不能支持像交互视频，会议等的实 时服务，原因是由于TCP是一个"慢"协议，需要三次握手。因此在IP层上UDP是比TCP更好的选择。 但是UDP是本质上是一个不可靠协议，不支持在丢包情况下的重传机制。为了消除UDP的缺点，RTP是 作为应用层而被提出来的。
RTP提供各种服务包括有效负载识别，序列编号，时间戳和投递监听。当包在收端不是按顺序到达 的时，RTP能够重新对包进行序列化。序列号用来识别是否存在丢包。时间戳用于媒体有效的*放播**。到 达的数据一直被RTCP监听，以通知RTP层来校正其编码和传输的参数。例如，如果RTCP层检测到包丢失，它会通知RTP层减缓发送速率。
RTP报文的封装
RTP (real-time transport protocol)是用于lnternet±针对多媒体数据流的一种传输协议。RTP被定 义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来 传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两 个端口： 一个给RTP, —个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提 供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现， 而是作为应用程序代码的一部分。实时传输控制协议RTCP。RTCP(real-time transport control protocol) 和RTP-起提供流呈控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包 中含有己发送的数据包的数呈、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态 地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使 传输效率最佳化，因而特别适合传送网上的实时数据。
RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。为 了实现音视频数据的传输，必须对压缩编码后的数据进行封装。RTP报文封装的格式如下：
可以看出RTP承载在UDP协议报文之上的。而RTP报文又将音视频数据进行封装进行传输。RTP头格式如下：
前12个字节出现在每个RTP包中，仅仅在被混合器插入时，才出现CSRC识别符列表。其中：
版本(V)： 2比特，定义RTP的版本"
填充(P): 1比特;
扩展(X): 1比特，若该位置1,固屯头后面跟随一个扩展头；
CSRC计数(CC): 4比特，CSRC计数包含了跟在固定头后面CSRC识别符的数目；
标志(M)： 1比特，它用来允许在比特流中标记重要的事件，如帧边界；
负载类型(PT)： 7比特，此域定义了负载的格式，由具体应用决定其解释。可以规定负载类型码和负 载格式之间一个默认的匹配。其他的负载类型码可以通过非RTP方法动态定义。
序列号(sequence number) : 16 比特
每发送一个RTP数据包，序列号加1,接收端可以据此检测丢包和重建包序列。序列号的初始值是随
机的。
时间戳(timestamp ) 32比特
时间戳反映了 RTP数据包中第一个字节的采样时间。采样时间必须来自于一个线性单调递增的时钟以 保证同步及抖动计算.时钟精度必须足以保证时间同步的精确度和测量包到达的抖动(每视频帧一秒是 绝对不够的).
SSRC: 32 比特
用以识别同步源。识符被随机生成，以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC 识别符.
CSRC列表：0到15项,每项32比特
CSRC列表识别在此包中负载的所有贡献源'
根据上述的封装方式，音视频数据被封装在RTP报文中进行传输。
音视频数据的封装与识别
在对音视频进行封装时，必须对所封装的音视频数据加以标识，以便接收者在接收到音视频数据 包之后，可以直接获知封装的数据为那种编码格式。为此，RTP协议规定了一个默认的音视频映射表。 RTP发送端在任意给定时间切换RTP负载类型；接收者必须忽略它不能识别的负载类型包。如图4所示：
而采用静态对应的方式已经不能满足编解码格式的增多，为此，RTP协议提供动态对应方式，允许 动态分配适合复杂负载格式的使用，同时节约PT域的空间。当今使用的大部分负载格式需要关于负载类 型分配的配置，并通过信令来交互。
信令交互协商编解码格式的方式有多种，可以采用SIP协议内的能力协商，也可以直接进行指定，具 体的方式在本文中不再加以详述。如有兴趣可以参见附录的参考资料。
音视频数据的传输与控制
实时音视频数据的传输方式则有可能是单播，也有可能是组播。当采用单播时，音视频数据被以点 对点的方式进行传输；当采用组播方式传输时，音视频数据被发送到一个组播组内进行传输，而接收者 加入该组来接收并进行显示，这种方式是一对多的形式。
为了实现对实时传输音视频数据传输状态的检测和控制，对应的RTP控制协议（RTCP ）提出并实 施° RTCP协议通过周期性的发送不同类型（主要有5类，发送者报告、接收者报告、源描述项、BYE和 APP报文）来通过发送者和接收者的状态，以便发送源和接收端根据信息进行发送和接收数据的调整。
RTP依赖于底层协议来提供RTP数据的多路化。RTP使用偶数目的端口而对应的RTCP流使用紧接 下来大的那个奇数端口。RTP和RTCP的端口绝对不能相同，因为RTP依靠端口号来多路传输RTP数据和 RTCP控制流。
当音视频数据被正确封装在IP报文中以后，实际的传输则直接采用IP数据传输来实现。对于IP数据 的传输和转发，就不再一一赘述。