RTSP协议
接到这个请求之后，服务器将根据自身情况进行如下测试：
● 利用同客户端建立的RTSP通道，采用TCP协议，下发测试数据包。
● 采用UDP协议，向客户端下发测试数据包。
测试数据包仅做测试用，上面带有相应的时间和顺序信息，其内部数据并无任何意义。 需要向RTSP增加一个新的方法TEST，以支持这种传输前的测试工作。
2、TCP传输
如果在TCP测试中，客户端反馈良好，即丢包率在可承受范围之内，并且在规定时间内到达，那么就认为客户端同服务器之间的 网络状况良好， 可以采用RTP over TCP的方式发送数据。由于TCP没有丢包（其自身具有重传机制），网络状况又属于良好，因此客户端将有较高的视听享受。
当子网内存在防火墙时，就需要采用RTSP附加数据传输方式。即把音视频数据直接打包，在RTSP通信信道内传输。这种传 输方式也存在一定的问题：
● 传输过程中，只是把音视频文件当成一个普通文件来处理，而没有考虑到它的音视频特性，不利于以后的扩展。
● 音频与视频文件没有分离，不利于某些特殊需求的场合。例如，客户端需要对音、视频做不同的处理。
● 客户端的反馈和RTSP的控制信息也是通过同一条RTSP信道传送，因此控制效率不高。 因此，一般情况下，都默认使用RTP over TCP的方式发送数据。
3、UDP传输
如果在TCP测试中，客户端的反馈存在比较大的问题，即网络情况不理想，就应该考虑进行UDP测试。
目前初步采取的措施，在服务器端准备了两种码率的视频文件——高码率和低码率。
收到客户端的TEST方法后，将采用UDP协议下发测试包。采取的策略是每间隔2秒，下发一个1500字节的UDP数据 包。当丢包率处于一定范围（75％～85％）之内，就认为客户端的网络状况基本良好，可以下发高码率的电影文件;否则，认为测试不成功，由于网络状况的限 制，仅对客户端下发低码率的电影文件。
在基于UDP的播放过程中，可能会出现轻微的马赛克，这是完全可以接受的。这些马赛克