RTP协议: Internet音视频传输

 

 

       Internet一直在不断变化：静态内容让位于流视频，音乐和语音取代了文本，交互式音频和视频正变得越来越常见。这些变化要求我们开发出新的应用，同时这些变化给应用设计者带来了新的、独特的挑战。

         本书讲述了如何构建这些新的应用：IP电话，视频会议，流媒体和网络电台。本书研究了那些在IP网络中可靠地传输音视频所固有的挑战，并且本书还讲解了在面对各种网络问题时如何实现高质量的媒体传输，如何确保系统的安全性。本书的重点在于开放标准，而不是那些私有解决方案，特别关注于那些IETF和ITU所设计的标准。

       我们从本章开始考察RTP协议，本章主要讲述音视频网络传输简史，RTP协议概述，RTP协议和其他协议的关系。

（这里插播一句话，其实市面上有很多这种音视频的解决方案，使用的通信协议也各不相同，其中有佰锐科技提供的AnyChat音视频解决方案，他们的流媒体协议遵循的就是RTP/RTSP协议，如果有兴趣，或者可以到他们的技术论坛bbs.anychat.cn进行更多知识获取，同时他们还提供demo的功能演示，可以值得一看）

 

 

第一节 音视频网络传输简史

 

利用类似Internet这样的基于包交换的网络传输语音和视频的想法并不新鲜。利用包交换网络传输语音的试验可以追溯到1970年代早期。关于这个主题（网络语音协议NVP）的第一个RFC起源于1977年。视频协议出现的晚一些，但是Internet上的视频会议和流媒体传输的历史也超过了10年。

 

早期基于包交换网络的语音和视频传输试验

 

        NVP(Network Voice Protocol)协议的初始开发者是一些利用ARPANET网络进行语音包传输的研究人员，ARPANET网络是Internet的始祖。ARPANET提供可靠的流服务（类似于TCP/IP），但是这会导致较大的延迟，于是，一种所谓的“不受控包”服务被开发出来，类似于现代RTP所使用的UDP/IP数据报。在这种“不受控包“服务之上就是NVP层。后来，试验扩展到分组无线网络和大西洋卫星网络，在这些网络上运行NVP协议，进行交互操作。

        早期网络带宽很低，所以所有这些试验都被限制为只有一个或两个语音通道。在1980年代，拥有3M带宽的宽带卫星网络的出现，使得不但大量的语音通道成为可能，而且还促进了视频包交换传输的发展。为了访问这种仅有一跳、保留带宽、支持多播的卫星网络服务，人们开发了一个面向连接的网间协议，Stream Protocol(ST)。NVP的第二个版本，NVP-II,及其相伴的视频包传输协议都被运行在ST上一起提供了一个基于包交换的视频会议服务原型。

       在1989到1990年间，卫星网络被地面宽带网络和一个研究性的网络DARTNET所取代，同时ST进化到ST-II。基于包交换的视频会议系统已经开始计划生产，以支持网络研究人员和其他人员之间的视频会议。这些会议在地理上是分散的，最多同时支持五个站点。

        ST和ST-II和IP协议并行地运行在网际层，但其仅仅限于部署在政府网络和研究性网络中。做为一个替代，早期的使用IP协议的视频会议的部署开始于DARTNET，这使得基于NVP-II的多方视频会议可以利用UDP/IP多播来运行。在1992年3月的IETF会议上，基于多播通道的音频传输跨越了三个大洲的20个Internet站点，这些多播通道就是Mbone（代表“多播骨干“），是从DARTnet扩展而来。也就是在那次会议上，RTP的开发工作启动了。

 

Internet上的音视频传输

 

      在这些早期实验之后，Internet社区内对于视频会议的兴趣在1990年代早期开始生根发芽。在这个时候，工作站和PC的处理能力及多媒体性能，已经足以同时进行音视频流的采集、压缩和播放。与此同时，IP多播技术的发展使得我们可以向任意数量的连接到Internet的接收者发送实时数据。

        很明显，视频会议程序和多媒体串流程序都是多播应用程序，而且是精心实施的多播程序。来自劳伦斯伯克利实验室的研究团体开发了vic和vat工具，来自美国马萨诸塞大学的研究团体开发了nevot工具，施乐帕洛阿尔托研究中心开发了INRIA视频会议系统，nv。伦敦大学学院开发了rat。这些工具遵循了一种用于会议系统的新方法，这种新方法基于无连接的协议、端到端的参数和应用层成帧技术。会议是最小化管理的，没有共享控制和发言权控制，传输层是薄的和自适应的。多播既用于广域数据传输，也可做为进程间的通信机制而用于同一台机器上的两个应用程序之间（用于在音视频工具之间交换同步信息）。由此产生的协作环境包括轻度耦合的应用程序和高度分布的参与者。

        多播视频会议（Mbone）工具带来一个重大的影响：它们导致了对基于IP网络传输实时媒体数据的固有问题、对可扩展解决方案及错误和拥塞控制的全面的理解。它们还直接影响了几个关键的协议和标准的发展。

        在1992到1996年期间，在NVP-II和原始vat工具使用的协议的基础上，IETF开发了RTP协议。那些多播会议工具使用RTP作为唯一的数据传输和控制协议;因此，RTP不仅包括媒体传输的设施，还支持成员管理，唇音同步和接收质量报告。

         除了用于传输实时媒体数据的RTP协议，还开发了其他协议用来协调和控制媒体流。会话声明协议（Session Announcement Protocol ，SAP）被开发出来用以公告存在的多播数据流。会话声明本身就是多播，并且任何具有多播能力的主机都可以接收SAP声明，从而了解到当前正在进行的会议和传输。在会话声明内部，使用会话描述协议（Session Description Protocol，SDP）来描述多播会话中发送者和接收者所使用的传输地址，编码和打包方案。缺乏组播部署和万维网的兴起，已经在很大程度上取代了分布式组播目录的概念，但是SDP在今天仍被广泛应用。

        最后，Mbone会议团体领导开发了会话初始化协议（Session Initiation Protocol ，SIP）。SIP协议的目的是提供一个轻量级的手段，用来发现参与者并使用一组特定的参与者来发起一个多播会话。在其早期版本中，SIP几乎不包括呼叫控制和协商支持，因为Mbone会议环境并不使用这些方面。SIP已经成为一个更全面的协议，包括大量的协商和控制功能。

 

 

ITU标准

 

 

        与早期的分组语音工作并行发展的是综合业务数字网（Integrated Services Digital Network ,ISDN，普通的老式电话系统的数字版本）和一组相关的视频会议标准。 这些标准基于ITU推荐的H.320标准，使用电路交换链路，所以和我们这里讨论的基于包的音视频没有直接的关系。然而，它们是今天使用的很多压缩算法的先驱（例如，H.261视频编码算法）。

        在商业世界中，互联网的增长和局域网设备的广泛部署导致ITU扩展了H.320系列协议。具体来说，他们力求使这些协议适用于“那些提供非保证服务质量的局域网络”，作为一个经典协议族，IP协议就是“提供非保证服务质量”的。结果ITU开发了H.323系列建议。

        H.323于1997年首次发布，自那时以来已经经历了几次修订。它提供了一个框架，包括媒体传输，呼叫信令和会议控制。信令和控制功能定义在ITU推荐的H.225.0和H.245中。最初，信令协议主要侧重于和使用H.320的ISDN会议进行互操作，因此不得不忍受繁琐的会话建立过程，这个繁琐的过程在标准的后来的版本中得到简化。对于媒体传输，ITU工作组采用了RTP协议。然而，H.323协议仅使用了RTP协议的媒体传输功能，并没有使用RTP协议的控制和报告部分。

        随着几个内置支持H.323技术的软硬件产品的出现，H.323在市场上取得了合理的成功。H.323的研发经验导致了对其复杂性的抱怨，特别是H.323版本1复杂的创建过程及其二进制格式的信令。其中一些问题在后来的一些H.323版本中得到解决，但是在此期间，人们对于H.323的替代方案的兴趣在增加。

        SIP是替代方案之一，前边我们已经介绍过。最初的SIP规范由IETF于1999年发布，作为一个学术研究项目的成果，几乎没有商业利益。自那时起，SIP在许多方面被视为H.323的替代品，SIP正在被应用于更多不同的应用中，例如文本消息系统和IP语音。此外，SIP正在被考虑使用在第三代蜂窝电话系统中，它已经聚集了相当大的产业依托。

        最近，ITU推荐了H.332协议，它把一个紧耦合的H.323会议和一个轻量级的多播会议结合在一起。其结果对于像在线研讨会这样的场景是非常有用的，一组发言者之间可以通过会议的H.323部分进行密切的互动，而被动的听众可以通过多播来收看收听。

 

 

音视频流化

 

        在多播会议和H.323协议发展的同时，万维网革命的发生，为Internet带来了光鲜丰富的内容和公众对Internet的接受。网络带宽和终端系统能力的提高使得Web网页中包含音视频流成为可能，RealAudio和QuickTime是在这方面领先的系统。市场对于这类系统需求的增长，迫切需要为流式内容控制机制设计一个标准。其结果就是实时流协议（Real-Time Streaming Protocol ，RTSP），RTSP为流式内容的呈现提供了初始化和类似VCR的控制功能；RTSP于1998年完成标准化。RTSP建立于现有标准之上：它在操作上和HTTP极为相似，它能够使用SDP做会话描述，使用RTP做媒体传输。

 

本文属于译文，转载于http://blog.csdn.net/dengzikun/article/details/18353925