精华内容
下载资源
问答
  • 实时传输协议RTP/RTCP与SIP协议

    千次阅读 2020-02-18 16:59:08
    RTP(Real-time Transport Protocol):实时传输协议; RTCP(Real-time Transport Control Protocol):实时传输控制协议; 他们是IP协议族中用于实时语音,视频数据传输的标准协议。 RTP标准定义了两个子协议,RTP...

    RTP/RTCP

    一、简介

    RTP(Real-time Transport Protocol):实时传输协议;
    RTCP(Real-time Transport Control Protocol):实时传输控制协议;
    他们是IP协议族中用于实时语音,视频数据传输的标准协议。

    RTP标准定义了两个子协议,RTP和RTCP
    数据传输协议RTP,用于实时 传输数据。该协议提供的信息包括:时间戳(用于同步),序列号(用于丢包和重排序检测),以及负载格式(用于说明数据的编码格式)。
    控制协议RTCP,用于QoS 反馈和同步媒体流。相对于RTP来说,RTCP所占的宽带非常小,通常只有5%。

    为什么要使用RTP?
    一提到流媒体传输,一谈到什么视频监控,视频会议,语音电话(VOIP),都离不开RTP协议的应用。那为何我们使用RTP而不是TCP,UDP或者其他的网络协议不能达到我们的要求呢?
    像TCP这样的可靠传输协议,通过超时和重传机制来保证传输数据流中的每一个bit的正确性,但这样会使得无论从协议的实现还是传输的过程都变得非常的复杂。而且,当传输过程中有数据丢失的时候,由于对数据丢失的检测(超时检测)和重传,会使数据流的传输被迫暂停和延时。或许你会说,我们可以利用客户端构造一个足够大的缓冲区来保证显示的正常,这种方法对于从网络播放音视频来说是可以接受的,但是对于一些需要实时交互的场合(如视频聊天,视频会议等),如果这种缓冲超过了200ms,将会产生难以接受的实时性体验。

    那为什么RTP可以解决上述问题呢?RTP协议是一种基于UDP的传输协议,RTP本身并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。这样,对于那些丢失的数据包,不存在由于超时检测而带来的延时,同时,对于那些丢弃的包,也可以由上层根据其重要性选择性的重传。

    二、RTP的工作机制

    当应用程序建立一个RTP会话时,应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对相邻的端口组成,有两个端口:一个给RTP包(偶数的UDP端口),一个给RTCP包(偶数的UDP端口+1),使得RTP/RTCP数据能够正确发送。 RTP的发送过程如下,接收过程则相反。
    RTP协议从上层接收流媒体信息码流(如H.263),封装成RTP数据包;RTCP从上层接收控制信息,封装成RTCP数据包。

    RTP为具体的应用提供了非常大的灵活性,它将传输协议与具体的应用环境、具体的控制策略分开,传输协议本身只提供完成实时传输的机制,开发者可以根据不同的应用环境,自主选择合适的配置环境、以及合适的控制策略。
    控制策略指的是你可以根据自己特定的应用需求,来实现特定的一些RTP控制算法,比如前面提到的丢包的检测算法,丢包的重传策略,一些视频会议应用等;
    合适的配置环境 主要指RTP的相关配置和负载格式的定义。RTP协议为了广泛地支持各种多媒体格式(如 H.264, MPEG-4, MJPEG, MPEG),没有在协议中体现出具体的应用配置,而是通过profile配置文件以及负载类型格式说明文件的形式来提供。

    RTP/RTCP的不足之处

    RTP和RTCP相结合虽然保证了实时数据的传输,但也有自己的缺点。最显著的是当有许多用户一起加入会话进程的时候,由于每个参与者都周期发送RTCP信息包,导致RTCP包泛滥(flooding)

    补充知识: H.263是由ITU-T(国际电信联盟)制定的视频会议用的低码率视频编码标准,属于视频编解码器。 目前H.263可用于H.323(基于RTP/IP网络的视频会议系统–电路交换),H.320(基于综合业务数字网的视频会议系统),RTSP(流式媒体传输系统)和SIP(基于因特网的视频会议)
    H.323是国际电信联盟(ITU)用于音频,视频和在数据包(IP)网络上共享数据的总括标准。这个标准已经广泛应用并且拥有了巨大的市场份额。
    SIP(会话起始协议)是IETF(互联网工程任务组)制定的多媒体信号协议。由于这个协议具有简单和模块化特点,这个协议正在受到关注,但是,目前为止的商业性应用还很少。
    企业一般都把SIP解决方案与H.323(或者TMD协议)协议一起部署,以便保护投资,保证更有效地向新技术转变,向能够从中受益的用户提供SIP应用。
    两个协议的相同之处:
    H.323和SIP协议原来都是用于在IP网络上提供多媒体服务的。这两个协议都在IP网络上运行,使用TCP和UDP会话发出信号并且使用RTP(实时协议)传输语音/视频流。这两种协议都不产生新的编码/解码方式,而是利用现有的其它协议(如G.711和G.729)。
    SIP同HTTP和SMTP一样,是一种基于文本的协议。许多程序员都非常了解这个协议。他们发现SIP协议非常简单并且很容易排除故障。H.323协议是用二进制代码编写的,没有丰富经验和开发工具的程序员都不熟悉这个协议。
    这两个协议之间的主要区别是,SIP协议用来建立和断开媒体会话,而H.323协议用来具体指定用哪一个协议提供媒体服务。使用H.323协议,媒体本身是不依赖于信号传输协议的。

    SIP

    SIP(Session Initiation Protocol)是一个会话层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以好似Internet多媒体会议、IP电话或多媒体分发。会话的参与者可以通过组播(multicast)、网状单播(unicast)或两者的混合体进行通信。
    SDP作为消息体的在SIP交互中负责双方媒体协商,支持能力的协商。 另外,SIP使用RTP/RTCP的传输参数支持语,视频和数据的参数。因此,SDP和RTP/RTCP 是创建SIP媒体会话的最基本的要求。

    任何协议都有其规范的语法结构,SIP协议也是一样的。它的基本语法结构和HTTP的HTML语法类似。
    .请求消息格式包括三个主要部分:Request-Line, Header 和 Message-Body
    SIP头消息(Header)主要目的是对呼叫方到被呼叫方的sip消息进行路由管理,信令消息中包含如下:
    Request-line—它由请求类型,目的地的SIP URL,或下一跳(next hop),还有SIP版本构成等。
    消息体(Message-Body)—SIP消息体是一个可选项。SIP消息中的消息头和消息体通过空白行来加以区分。

    .响应消息格式包括三个主要部分:Status-Line,Header和Message-Body
    如果SIP请求中创建的会话中包含了会话描述的具体消息内容,会话描述中包含了双方的媒体类型和编码等,那么,消息体重将会作为SDP包含这些会话描述的消息内容。

    展开全文
  • RTP(实时传输协议

    千次阅读 2019-01-17 17:30:12
    RTP(real-time transport protocol),实时传输协议。RTP在多点传送(多播)或单点传送(单播)的网络服务上,提供端对端的网络传输功能,适合应用程序传输实时数据,如:音频,视频或者仿真数据。RTP没有为实时...

    目录

    1概述

    2 RTP使用场景

    3 RTP详解

    4 RTP控制协议RTCP     


    1概述

    RTP(real-time transport protocol),实时传输协议。RTP在多点传送(多播)或单点传送(单播)的网络服务上,提供端对端的网络传输功能,适合应用程序传输实时数据,如:音频,视频或者仿真数据。RTP没有为实时服务提供资源预留的功能,也不能保证QoS(服务质量)。数据传输功能由一个控制协议(RTCP)来扩展,通过扩展,可以用一种方式对数据传输进行监测控制,该协议(RTCP)可以升级到大型的多点传送(多播)网络,并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用。

    RTP由IETF的多媒体传输工作小组1996年在RFC 1889中公布,现行版本为RFC3550,详见:

    https://tools.ietf.org/html/rfc3550

    RFC3550的大多数内容和旧版的RFC1889相同。在线路里传输的数据包格式没有改变,唯一的改变是使用协议的规则和控制算法。为了最小化传输,发送RTCP数据包时超过了设定的速率,而在这时,很多的参与者同时加入了一个会话,在这样的情况下,一个新加入到(用于计算的可升级的)计时器算法中的元素是最大的改变。

    2 RTP使用场景

    • 简单多播音频会议( Simple Multicast Audio Conference)
    • 音频和视频会议(Audio and Video Conference)
    • 混频器和转换器(Mixers and Translators)
    • 分层编码(Layered Encodings)

    3 RTP详解

    RTP头有以下格式(RFC 3550 Page 12:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           synchronization source (SSRC) identifier            |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |            contributing source (CSRC) identifiers             |
       |                             ....                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    版本号(V):2比特,此域定义了RTP的版本。此协议定义的版本是2。

    填充位(P):1比特,如果该位置位,则该RTP包的尾部就包含附加的填充字节。

    扩展位(X):1比特,如果该位置位的话,RTP固定头部后面就跟有一个扩展头部。

    CSRC计数器(CC):4比特,含有固定头部后面跟着的CSRC的数目。

    标记位(M):1比特,该位的解释由配置文档(Profile)来承担.

    载荷类型(PT):7比特,标识了RTP载荷的类型。

    序列号(SN):16比特,发送方在每发送完一个RTP包后就将该域的值增加1,接收方可以由该域检测包的丢失及恢复包序列。序列号的初始值是随机的。

    时间戳:32比特,记录了该包中数据的第一个字节的采样时刻。在一次会话开始时,时间戳初始化成一个初始值。即使在没有信号发送时,时间戳的数值也要随时间而不断地增加(时间在流逝嘛)。时间戳是去除抖动和实现同步不可缺少的。

    同步源标识符(SSRC):32比特,同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的 RFC1889推荐了MD5随机算法。

    贡献源列表(CSRC List):0~15项,每项32比特,用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来,以便接收端能正确指出交谈双方的身份。

     

    RTP扩展头(RFC 3550 Page 18):

     

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      defined by profile       |           length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        header extension                       |
       |                             ....                              |

            若 RTP 固定头中的扩展比特位置 1(注意:如果有CSRC列表,则在CSRC列表之后),则一个长度可变的头扩展部分被加到 RTP 固定头之后。头扩展包含 16 比特的长度域,指示扩展项中 32 比特字的个数,不包括 4 个字节扩展头(因此零是有效值)。

            RTP 固定头之后只允许有一个头扩展。为允许多个互操作实现独立生成不同的头扩展,或某种特定实现有多种不同的头扩展,扩展项的前 16 比特用以识别标识符或参数。这 16 比特的格式由具体实现的上层协议定义。基本的 RTP 说明并不定义任何头扩展本身。

     

    4 RTP控制协议RTCP     

      RTP控制协议(RTCP)向会议中所有成员周期性发送控制包。它使用与数据包相同的传输机制。底层协议必须提供数据包和控制包的复用,例如用不同的UDP端口。RTCP提供以下四个功能:    

    ○基本功能是提供数据传输质量的反馈。这是RTP作为一种传输协议的主要作用,它与其他协议的流量和拥塞控制相关。反馈可能对自适应编码有直接作用,并且IP组播的实验表明它对于从接收端得到反馈信息以诊断传输故障也有决定性作用。向所有成员发送接收反馈可以使"观察员"评估这些问题是局部的还是全局的。利用类似多点广播的传输机制,可以使某些实体,诸如没有加入会议的网络业务观察员,接收到反馈信息并作为第三方监视员来诊断网络故障。反馈功能通过RTCP发送者和接收者报告实现。    

      ○RTCP为每个RTP源传输一个固定的识别符,称为规范名(CNAME)。由于当发生冲突或程序重启时SSRC可能改变,接收者要用CNAME来跟踪每个成员。接收者还要用CNAME来关联一系列相关RTP会话中来自同一个成员的多个数据流,例如同步语音和图像。

      ○前两个功能要求所有成员都发送RTCP包,因此必须控制速率以使RTP成员数可以逐级增长。通过让每个成员向所有成员发送控制包,各个成员都可以独立地观察会议中所有成员的数目。此数目可以用来估计发包速率。

      ○第四个可选的功能是传输最少的会议控制信息,例如在用户接口中显示参与的成员。这最可能在"松散控制"的会议中起作用,在"松散控制"会议里,成员可以不经过资格控制和参数协商而加入或退出会议。RTCP作为一个延伸到所有成员的方便通路,必须要支持具体应用所需的所有控制信息通信。

      ○在RTP用于IP多点广播时,功能1-3是强制的,在所有情况下都推荐使用。建议RTP应用开发商避免使用只能用于单向广播而不能扩充到多用户的方法。

     

     

    展开全文
  • RTP是一种提供端对端传输服务的实时传输协议,用来支持在单目标广播和多目标广播网络服务中传输实时数据,而实时数据的传输则由RTCP协议来监视和控制。 RTP定义在RFC 1889中。信息包的结构包含广泛用于多媒体的...
    
    RTP简介

    RTP是一种提供端对端传输服务的实时传输协议,用来支持在单目标广播和多目标广播网络服务中传输实时数据,而实时数据的传输则由RTCP协议来监视和控制。

    RTP定义在RFC

    1889中。信息包的结构包含广泛用于多媒体的若干个域,包括声音点播(audio-on-demand)、影视点播(video on demand)、因特网电话(Internet telephony)和电视会议(videoconferencing)。RTP的规格没有对声音和电视的压缩格式制定标准,它可以被用来传输普通格式的文件。例如,WAV或者GSM(Global System for Mobile communications)格式的声音、MPEG-1和MPEG-2的电视,也可以用来传输专有格式存储的声音和电视文件。

    使用RTP协议的应用程序运行在RTP之上,而执行RTP的程序运行在UDP的上层,目的是为了使用UDP的端口号和检查和。如图16-12所示,RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中,每个RTP信息包被封装在UDP消息段中,然后再封装在IP数据包中。

     

    TCP/IP模型

     

    应用层(application)

    传输层

    RTP

     

    UDP

     

    IP

     

    数据链路层(data link)

     

    物理层(physical)

    图16-12 RTP是传输层上的协议

    从应用开发人员的角度来看,可把RTP执行程序看成是应用程序的一部分,因为开发人员必需把RTP集成到应用程序中。在发送端,开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中,然后应用程序把RTP信息包发送到UDP的套接接口(socket interface),如图16-13所示;同样,在接收端,RTP信息包通过UDP套接接口输入到应用程序,因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。

    TCP/IP模型

     

    应用层(application)

     

    RTP

     


    套接接口

    UDP

     

    IP

     

    数据链路层(data link)

     

    物理层(physical)

     

    图16-13 RTP和UDP之间的接口

    现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音,并假设应用程序取20毫秒的编码数据为一个数据块(chunk),即在一个数据块中有160个字节的声音数据。应用程序需要为这块声音数据添加RTP标题生成RTP信息包,这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口,在那里再被封装在UDP信息包中。在接收端,应用程序从套接接口处接收RTP信息包,并从RTP信息包中抽出声音数据块,然后使用RTP信息包的标题域中的信息正确地译码和播放声音。

    如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳,而是使用标准的RTP协议,应用程序就更容易与其他的网络应用程序配合运行,这是大家都希望的事情。例如,如果有两个不同的公司都在开发因特网电话软件,他们都把RTP合并到他们的产品中,这样就有希望:使用不同公司电话软件的用户之间能够进行通信。

    这里需要强调的是,RTP本身不提供任何机制来确保把数据及时递送到接收端或者确保其他的服务质量,它也不担保在递送过程中不丢失信息包或者防止信息包的次序不被打乱。的确,RTP的封装只是在系统端才能看到,中间的路由器并不区分那个IP数据报是运载RTP信息包的。

    RTP允许给每个媒体源分配一个单独的RTP信息包流,例如,摄像机或者麦克风。例如,有两个团体参与的电视会议,这就可能打开4个信息包流:两台摄像机传送电视流和两个麦克风传送声音流。然而,许多流行的编码技术,包括MPEG-1和MPEG-2在编码过程中都把声音和电视图像捆绑在一起以形成单一的数据流,一个方向就生成一个RTP信息包流。

    RTP信息包没有被限制只可应用于单目标广播,它们也可以在一对多(one-to-many)的多目标广播树或者在多对多(many-to-many)的多目标广播树上传送。例如,多对多的多目标广播,在这种应用场合下,所有发送端通常都把他们的RTP信息包流发送到具有相同多目标广播地址的多目标广播树上。

    16.6.2 RTP信息包标题域

    RTP标题由4个信息包标题域和其他域组成:有效载荷类型(payload type)域,顺序号(sequence number)域,时间戳(timestamp)域和同步源标识符(Synchronization Source Identifier)域等。RTP信息包的标题域的结构如下图所示:

    Payload

    Type
    (有效载荷类型)

    Sequence Number
    (顺序号)

    Timestamp
    (时间戳)

    Synchronization Source Identifier
    (同步源标识符)

    Miscellaneous Fields
    (其他)

     

    1. 有效载荷类型

    RTP信息包中的有效载荷域(Payload Type Field)的长度为7位,因此RTP可支持128种不同的有效载荷类型。对于声音流,这个域用来指示声音使用的编码类型,例如PCM、自适应增量调制或线性预测编码等等。如果发送端在会话或者广播的中途决定改变编码方法,发送端可通过这个域来通知接收端。表16-01列出了目前RTP所能支持的声音有效载荷类型。

    表16-01 目前RTP所能支持的声音有效载荷类型

    有效载荷号

    声音类型

    采样率(kHz)

    数据率(kb/s)

    0

    PCM mu-law

    8

    64

    1

    1016

    8

    4.8

    2

    G.721

    8

    32

    3

    GSM

    8

    32

    6

    DVI

    16

    64

    7

    LPC

    8

    2.4

    9

    G.722

    8

    48~64

    14

    MPEG Audio

    90

    -

    15

    G.728

    8

    16

    对电视流,有效载荷类型可以用来指示电视编码的类型,例如motion JPEG, MPEG-1,MPEG-2或者H.231等等。发送端也可以在会话或者期间随时改变电视的编码方法。表16-02列出了目前RTP所能支持的某些电视有效载荷类型。

    表16-02 目前RTP所能支持的声音有效载荷类型

    有效载荷号

    电视格式

    26

    Motion JPEG

    28

    -

    31

    H.261

    32

    MPEG-1 video

    33

    MPEG-2 video

     

    2. 顺序号

    顺序号(Sequence Number Field)域的长度为16位。每发送一个RTP信息包顺序号就加1,接收端可以用它来检查信息包是否有丢失以及按顺序号处理信息包。例如,接收端的应用程序接收到一个RTP信息包流,这个RTP信息包在顺序号86和89之间有一个间隔,接收端就知道信息包87和88已经丢失,并且采取措施来处理丢失的数据。

    3. 时间戳

    时间戳(Timestamp)域的长度为32字节。它反映RTP数据信息包中第一个字节的采样时刻(时间)。接收端可以利用这个时间戳来去除由网络引起的信息包的抖动,并且在接收端为播放提供同步功能。

    4. 同步源标识符

    同步源标识符(Synchronization Source Identifier,SSRC)域的长度为32位。它用来标识RTP信息包流的起源,在RTP会话或者期间的每个信息包流都有一个清楚的SSRC。SSRC不是发送端的IP地址,而是在新的信息包流开始时源端随机分配的一个号码。

    16.6.3 实时传输控制协议

    实时传输控制协议(Real-time Control Protocol,RTCP)也定义在1996年提出的RFC 1889中。多媒体网络应用把RTCP和RTP一起使用,尤其是在多目标广播中更具吸引力。当从一个或者多个发送端向多个接收端广播声音或者电视时,也就是在RTP会话期间,每个参与者周期性地向所有其他参与者发送RTCP控制信息包,如图16-14所示。RTCP用来监视服务质量和传送有关与会者的信息。对于RTP会话或者广播,通常使用单个多目标广播地址,属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址,通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。

    图16-14 每个参与者周期性地发送RTCP控制信息包

    RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据,而是封装发送端和/或者接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况,这些反馈信息对发送端、接收端或者网络管理员都是很有用的。RTCP规格没有指定应用程序应该使用这个反馈信息做什么,这完全取决于应用程序开发人员。例如,发送端可以根据反馈信息来修改传输速率,接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的,网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

    16.6.4 实时流放协议

    实时流放协议(Real-Time Streaming Protocol,RTSP)是一个刚开始开发的协议,它的设想描述在RFC

    2326文件中。RTSP是应用级的实时流放协议,它主要目标是为单目标广播和多目标广播上的流式多媒体应用提供牢靠的播放性能,以及支持不同厂家提供的客户机和服务机之间的协同工作能力。

    播放的数据流被分成许多信息包,信息包的大小很适用于客户机和服务器之间的带宽。当客户机已经接收到足够多的信息包之后,用户软件就可开始播放一个信息包,同时对另一个信息包解压缩和接收第三个信息包。这样用户就不需要把整个媒体文件从服务器上下载之后就可立即播放。广播源可以是现场的数据流也可以是存储的数据流。

    RTSP协议想要提供控制多种应用数据传送的功能,提供一种选择传送通道的方法,例如UDP, TCP, IP多目标广播通道,以及提供一种基于RTP协议的递送方法。正在设计的RTSP将工作在RTP的上层,用来控制和传送实时的内容。

    RTSP能够与资源保留协议一起使用,用来设置和管理保留带宽的流式会话或者广播。
    实时传输协议RTP

    1.RTP协议:
    RTP( Real-time Transport Protocol)协议最初是在70年代为了尝试传输声音文件,把包分成几部分用来传输语音,时间标志和队列号。经过一系列发展,RTP第一版本在1991年8月由美国的一个实验室发布了。到本世纪1996年形成了标准的的版本。很多著名的公司如Netscape ,就宣称“Netscape LiveMedia”是基于RTP协议的。. Microsoft 也宣称他们的“NetMeeting”也是支持RTP协议.
    RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议。最初设计是为了数据传输的多播,但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比,它更加侧重的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。RTP与辅助控制协议RTCP一起得到数据传输的一些相关的控制信息。

    2.RTP协议是如何工作的:
    在前面说明过,威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。RTP协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。
    在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是RTP本身并不负责同步,RTP只是传输层协议,为了简化了运输层处理,提高该层的效率。将部分运输层协议功能(比如流量控制)上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能,不提供任何机制来保证实时地传输数据,不支持资源预留,也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文的使用相邻的不同端口,这样大大提高了协议的灵活性和处理的简单性。
    RTP协议和UDP二者共同完成运输层协议功能。UDP协议只是传输数据包,是不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候,有时候一帧数据被分割成几个包具有相同的时间标签,则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递,可以满足多媒体会话的需求。
    RTP协议虽然是传输层协议但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务, RTP只提供协议框架,开发者可以根据应用的具体要求对协议进行充分的扩展。目前,RTP的设计和研究主要是用来满足多用户的多媒体会议的需要,另外它也适用于连续数据的存储,交互式分布仿真和一些控制、测量的应用中。基于RTP的实验和商业产品也层出不穷。

    实时传输控制协议RTCP协议

    1. RTCP协议:
    RTCP(Real-time Transpor、Control Protocol)是设计和RTP一起使用的进行流量控制和拥塞控制的服务控制协议。

    2. RTCP协议如何工作:
    当应用程序开始一个RTP会话时将使用两个端口:一个给RTP,一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息,可以制定流量控制的策略,而会话用户信息的交互,可以制定会话控制的策略。
    RTCP协议处理机根据需要定义了五种类型的报文——
    RR: receiver report
    SR: sender report
    SDES: source description items.
    BYE: indicates end of participation.
    APP: application specific functions
    它们完成接收、分析、产生和发送控制报文的功能。

    实时流协议RTSP协议

    1. RTSP协议:
    RTSP(Real Time Streaming Protocol)协议定义了如何有效地通过IP网络传送多媒体数据,是一种客户端到服务器端的多媒体描述协议。
    RTSP是一个非常类似于HTTP的应用层协议。每个发布和媒体文件也被定义为RTSP UPL。而媒体文件的发布信息被书写进一个被称为媒体发布文件里,这个文件在后面会说明。在这个文件说明的包括编码器,语言,RTSP ULS,地址,端口号以几其它参数。这个发布文件可以在客户端通过EMAIL形式或者HTTP形式获得。
    RTSP是由RealNetworks和Netscape以及哥伦比亚大学共同提出的。它是从RealNetworks的"RealAudio" 和 Netscape的 "LiveMedia"的实践和经验发展来来的。第一份RTSP协议是由IETF 在1996年8月9日正式提交后作为INTERNET的标准,在此后此协议经过了很多明显的变化。它的应用现在是广泛的,APPLE、IBMNetscape, Apple, IBM, Silicon Graphics, VXtreme, Sun 还有其它公司都宣称它们的在线播放器支持RTSP协议,不过微软一直都坚持不支持此协议,不知道这种局面还会持续多久。

    2. RTSP协议的特点:
    RTSP是应用层协议,与RTP、RSVP一起设计来完全流式服务。
    RTSP有很大的灵活性,可被用在多种操作系统上,它允许客户端和不同厂商的服务平台交互。
    RTSP在体系结构上位于RTP和RTCP之上,它使用RTP完成数据传输。它将流式媒体数据可控制的通过网络传输到客户端。
    RTSP可以保持用户计算机与传输流业务服务器之间的固定连接,用于观看者与单播(Unicast)服务器通信并且还允许双向通信,观看者可以同流媒体服务器通信.
    提供类似“VCR”形式的例如暂停、快进、倒转、跳转等操作。操作的资源对象可以是直播流也可以是存储片段。
    RTSP是设还提供了选择传输通道,如使用UDP还是多点UDP或是TCP。

    资源预留协议RSVP

    1. RSVP协议:
    RSVP (Resorce reSerVation Protocol) 资源预留协议并不是一个路由协议,而是一种IP网络中的信令协议,它与路由协议相结合来实现对网络传输服务质量(QoS)的控制。RSVP是为支持因特网综合业务而提出的。这是解决IP通信中QoS(服务质量)问题的一种技术,用来保证点端到端的传输带宽。

    2. RSVP协议是如何工作:
    RSVP使用控制数据报,这些数据报在向特定地址传输时包括了需要由路由器检查(有些时候需要更新)的信息,如果路由器需要决定是不是要检查数据报的内容的时候对上层数据内容进行语法分析。这种分析的代价可不小。现在的情况是,网络终端利用它向网络申请资源,在这种表明“申请” 的信号中,包含着如下的信息:业务的种类?使用者类型?什么时间?需要多大带宽?其他参考信息?网络在接收到上类信息后,会根据实际情况为此次连接分配一个优先代码,用户利用优先代码进行信息传递时,网络不需重新对业务进行分析与判别,从另外一个角度来说,利用RSVP 能从一定程度上减少网络对信息处理的时延,提高网络节点的工作效率,改善信息传输的服务质量(QoS)。实时应用用RSVP是为了在传输路径中保持必要的资源以保证请求能确保到达。
    RSVP是IP路由器为提供更好的服务质量向前迈进的具有深刻意义的一步。传统上IP路由器只负责分组转发,通过路由协议知道邻近路由器的地址。而RSVP则类似于电路交换系统的信令协议一样,为一个数据流通知其所经过的每个节点(IP路由器),与端点协商为此数据流提供质量保证。RSVP协议一出现,立刻获得广泛的认同,基本上被任为较好地解决了资源预留的问题。

    在前面我们讨论了一些实时媒体控制的相近的四个协议。在这里我再概括性的说明一下:
    RTP是实时数据传输协议。它提供时间标志,序列号以及其它能够保证在实时数据传输时处理时间的方法。它是依靠RVSP保证服务质量标准的。
    RTP/RTCP流媒体服务器技术研究

    1 引言
      随着互联网的飞速发展,流媒体技术的应用越来越广泛,从网上广播、电影播放到远程教学以及在线的新闻网站等都用到了流媒体技术。但现有公开文献所报道的大多是利用现有的流媒体服务器来搭建一个流媒体服务系统,或者是针对流媒体数据的编码方式所进行的研究。本文对流媒体服务器技术的研究重点在于如何建立一个服务器,并且在实现流媒体传输的两个基本协议RTP/RTCP的基础上构建一个基本的流媒体服务器。

    2 流媒体技术简介

    2.1 “流”的定义
      现在网上传输视频、音频主要有下载(Download)和流式传输(Streaming)两种方式。流式传输是连续传送视/音频信号,当流媒体在客户机播放时其余部分在后台继续下载。流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送,特别适合现场事件,实时流式传输必须匹配连接带宽,这意味着图像质量会因网络速度降低而变差,以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。
      在Internet中使用流式传输技术的连续时基媒体就称为流媒体,通常也将其视频与音频称为视频流和音频流。实现流式传输一般都需要专用服务器和播放器。

    2.2 流媒体系统组件
      流媒体是由各种不同软件构成的,这些软件在各个不同层面上互相通信,基本的流媒体系统包含以下3个组件:
    播放器(Player),用来播放流媒体的软件。
    服务器(Server),用来向用户发送流媒体的软件。
    编码器(Encode),用来将原始的音频视频转化为流媒体格式的软件。
      这些组件之间通过特定的协议互相通信,按照特定的格式互相交换文件数据。有些文件中包含了由特定编解码器解码的数据,这种编解码器通过特定算法压缩文件的数据量。

    3 流媒体服务器的基本功能和服务方式

    3.1 流媒体服务器的主要功能
    (1)响应客户的请求,把媒体数据传送给客户。流媒体服务器在流媒体传送期间必须与客户的播放器保持双向通信(这种通信是必需的,因为客户可能随时暂停或快放一个文件)。
    (2)响应广播的同时能够及时处理新接收的实时广播数据,并将其编码。
    (3)可提供其他额外功能,如:数字权限管理(DRM),插播广告,分割或镜像其他服务器的流,还有组播。

    3.2 流媒体服务器的服务方式
    (1)单播。在客户端与媒体服务器之间建立一个单独的数据通道,从1台服务器送出的每个数据包只能传送给1个客户机。
    (2)组播。在以组播技术构建的网络上,允许路由器一次将数据包复制到多个通道上。
    (3)点播与广播。点播连接是客户端与服务器之间的主动的连接,在点播连接中,用户通过选择内容项目来初始化客户端连接,用户可以开始、停止、后退、快进或暂停流。广播指的是用户被动地接收流,在广播过程中,数据包的单独一个拷贝将发送给网络上的所有用户,客户端接收流,但不能控制流。

    4 构建流媒体服务器

    4.1 RTP/RTCP协议简介
      实时传输协议RTP(Realtime Transport Protocol):是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上,但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输,并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。
      实时传输控制协议RTCP(Realtime Transport Control Protocol):负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间,各参与者周期性地传送RTCP包,包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,能以有效的反馈和最小的开销使传输效率最佳化,故特别适合传送网上的实时数据。
      RTCP主要有4个功能:
    (1)用反馈信息的方法来提供分配数据的传送质量,这种反馈可以用来进行流量的拥塞控制,也可以用来监视网络和用来诊断网络中的问题;
    (2)为RTP源提供一个永久性的CNAME(规范性名字)的传送层标志,因为在发现冲突或者程序更新重启时SSRC(同步源标识)会变,需要一个运作痕迹,在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得到相联系的数据流(如音频和视频);
    (3)根据与会者的数量来调整RTCP包的发送率;
    (4)传送会话控制信息,如可在用户接口显示与会者的标识,这是可选功能。

    4.2 RTP/RTCP工作过程
      工作时,RTP协议从上层接收流媒体信息码流(如H.263),装配成RTP数据包发送给下层,下层协议提供RTP和RTCP的分流。如在UDP中,RTP使用一个偶数号端口,则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制,它的最大包长只受下层协议的限制。

    4.3 服务器的算法
      服务器软件模型主要有两种,即并发服务器和循环服务器。循环服务器(Iterative Server)是指在一个时刻只处理一个请求的服务器。并发服务器(Concurrent Server)是指在一个时刻可以处理多个请求的服务器。事实上,多数服务器没有用于同时处理多个请求的冗余设备,而是提供一种表面上的并发性,方法是依靠执行多个线程,每个线程处理一个请求,从客户的角度看,服务器就像在并发地与多个客户通信。
      由于流媒体服务时间的不定性和数据交互实时性的请求,流媒体服务器一般采用并发服务器算法。本文构建了一个基本的流媒体服务器,能够同时响应多个用户的请求,把本地硬盘流媒体文件或实时数据流(H.263格式)发送给用户。在应用中,把客户分为请求实时数据的实时客户和请求文件数据的文件客户两类。主要算法为:
    (1)打开设备,分配资源。当设备准备好时,创建一个RTP实时服务线程和一个RTCP实时服务线程。
    (2)创建一个UDP套接字并将其绑定到所提供服务的地址之上。
    (3)反复调用接收模块,接收来自客户的RTCP报告,根据其类型做出响应。对新实时客户的请求,把客户地址添加到实时服务的客户列表中,对新文件客户的请求,则创建一个新RTP文件服务线程和一个新RTCP文件服务线程;对已经在服务中的客户则根据RTCP报告的内容调整服务。
    RTP实时服务线程1:初始化客户列表和RTP首部。
    RTP实时服务线程2:从设备读取媒体数据,把数据发送给实时服务列表中的客户。
    RTP实时服务线程3:更新RTP首部和统计数据。
    RTP实时服务线程4:计算延时,重复第二步。
    RTCP实时服务线程1:初始化RTCP首部。
    RTCP实时服务线程2:发送发送方报告给实时服务列表中的客户。
    RTCP实时服务线程3:计算延时,重复第二步。
    RTP文件服务线程1:初始化RTP首部。
    RTP文件服务线程2.:从文件读取媒体数据,把数据发送给客户。
    RTP文件服务线程3:更新已发送数据的统计信息,为生成发送方报告做准备。
    RTP文件服务线程4:计算延时,调整发送速度,正常情况下开始重复第二步。
    RTCP文件服务线程1:初始化RTCP首部,发送一个源描述(SDES)报文给客户。
    RTCP文件服务线程2:根据已发送数据的统计信息生成发送方报告,发送给客户。
    RTCP文件服务线程3:计算延时,正常情况下开始重复第一步。

    5 流媒体服务器实现中应注意的问题

    5.1 会话和流的两级分用
      一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量,发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流,在接收时也需要进行两级分用,即会话分用和流分用。只有当RTP使用同步源标识(SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来,才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放。

    5.2 多线程的管理
      并发服务器模式要求用多线程来提供服务,所以多线程的管理十分重要。在本文构建的服务器中,不同客户的请求和反馈都由服务器的主线程处理,由于实时数据的独有性,不同实时客户可以共用一个RTP实时服务线程和一个RTCP实时服务线程,这样可以大大减小服务器的负担,而每个文件客户由于请求的文件不同,相应地对速度和开始时间的要求都可能不同,所以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。
      RTP服务线程负责把实时数据流发送给客户,RTCP服务线程根据RTP线程的统计数据,产生发送方报告给客户。RTP线程和RTCP线程之间通过一段共享内存交互统计数据,对共享内存必须设置互斥体进行保护,防止出现错误读写。在这种方式下,服务器可以根据每个用户的不同请求和具体情况方便地提供不同的服务。

    5.3 时间戳的处理
      时间戳字段是RTP首部中说明数据包时间的同步信息,是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant),要求发送方时间戳的时钟是连续、单调增长的,即使在没有数据输入或发送数据时也是如此。在静默时,发送方不必发送数据,保持时间戳的增长,在接收端,由于接收到的数据分组的序号没有丢失,就知道没有发生数据丢失,而且只要比较前后分组的时间戳的差异,就可以确定输出的时间间隔。
      RTP规定一次会话的初始时间戳必须随机选择,但协议没有规定时间戳的单位,也没有规定该值的精确解释,而是由负载类型来确定时钟的颗粒,这样各种应用类型可以根据需要选择合适的输出计时精度。
    在RTP传输音频数据时,一般选定逻辑时间戳速率与采样速率相同,但是在传输视频数据时,必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的,协议标准还允许多个分组具有相同的时间戳值。

    5.4 媒体数据发送速度的控制
      由于RTP协议没有规定RTP分组的长度和发送数据的速度,因而需要根据具体情况调整服务器端发送媒体数据的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区,在有新数据输入时发送数据的方式,时间戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件,以H.263格式的文件为例,由于文件本身不包含帧率信息,所以需要知道录制时的帧率或者设置一个初始值,在发送数据的时候找出发送数据中的帧数目,根据帧率和预置值来计算时延,以适当的速度发送数据并设置时间戳信息。

    5.5 多种流同步
      RTCP的一个关键作用就是能让接收方同步多个RTP流,例如:当音频与视频一起传输的时候,由于编码的不同,RTP使用两个流分别进行传输,这样两个流的时间戳以不同的速率运行,接收方必须同步两个流,以保证声音与影像的一致。为能进行流同步,RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name),尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC),但具有相同的规范名,这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值,接着RTCP报告中给出一个RTP时间戳值,产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟,接收方就可以比较来自同一数据源的两个流的绝对时间,从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。


    6 结论
      流媒体技术的应用日益广泛,对流媒体技术的研究具有很大的实际意义,本文通过对RTP/RTCP协议的研究,分析流媒体服务器的一般功能和结构,给出构建一个基本的流媒体服务器的实现方案,实验证明可以同时满足多个实时和文件客户的要求,并已经应用于一个远程监控系统中。

    展开全文
  • 实时传输协议RTP与RTCP

    千次阅读 2014-07-23 20:34:37
    实时传输协议RTP与RTCP  RTP(Real-timeTransportProtocol)是用于Internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流同步。RTP通常使用...
    实时传输协议 RTP RTCP

      RTP Real-timeTransportProtocol )是用于 Internet 上针对多媒体数据流的一种传输协议。 RTP 被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流同步。 RTP 通常使用 UDP 来传送数据,但 RTP 也可以在 TCP ATM 等其他协议之上工作。当应用程序开始一个 RTP 会话时将使用两个端口:一个给 RTP ,一个给 RTCP RTP 本身并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠 RTCP 提供这些服务。通常 RTP 算法并不作为一个独立的网络层来实现,而是作为应用程序代码的一部分。实时传输控制协议 RTCP RTCP(Real-timeTransportControlProtocol) RTP 一起提供流量控制和拥塞控制服务。在 RTP 会话期间,各参与者周期性地传送 RTCP 包。 RTCP 包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。 RTP RTCP 配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。

    6.2.1 RTP
    数据传输协议

      RTP 提供端对端网络传输功能,适合通过组播和点播传送实时数据,如视频、音频和仿真数据。 RTP 没有涉及资源预订和质量保证等实时服务, RTCP 扩充数据传输以允许监控数据传送,提供最小的控制和识别功能。 RTP RTCP 设计成独立传输和网络层。

    2.1.1 RTP
    固定头
      RTP 头格式如下:
      -----------------------------------------------------------------------------------------------
      |V=2|P|X| CC |M| PT | 系列号 |
      -----------------------------------------------------------------------------------------------
      | 时标 |
      -----------------------------------------------------------------------------------------------
      | 同步源标识 (SSRC) |
      -----------------------------------------------------------------------------------------------
      | 作用标识 (CSRC) |
      | .... |
      -----------------------------------------------------------------------------------------------

     开始 12 个八进制出现在每个 RTP 包中,而 CSRC 标识列表仅出现在混合器插入时。
      2.1.2 复用 RTP 连接
     为使协议有效运行,复用点数目应减至最小。 RTP 中,复用由定义 RTP 连接的目的传输地址(网络地址与端口号)提供。例如,对音频和视频单独编码的远程会议,每个媒介被携带在单独 RTP 连接中,具有各自的目的传输地址。目标不在将音频和视频放在单一 RTP 连接中,而根据 SSRC 段载荷类型进行多路分解。使用同一 SSRC ,而具有不同载荷类型的交叉包将带来几个问题:
     如一种载荷类型在连接期间切换,没有办法识别新值将替换那一个旧值。
    SSRC
    定义成用于标识单个计时和系列号空间。如媒体时钟速率不同,而要求不同系列号空间以说明那种载荷类型有丢包,交叉复用载荷类型将需要不同计时空间。
      RTCP 发送和接收报告可能仅描述每个 SSRC 的计时和系列号空间,而不携带载荷类型段。
      RTP 混合器不能将不兼容媒体流合并成一个流。
     在一个 RTP 连接中携带多个媒介阻止几件事:使用不同网络路径或网络资源分配;接受媒介子集。
    对每种媒介使用不同 SSRC ,但以相同 RTP 连接发送可避免前三个问题,但不能避免后两个问题。

    2.1.3
    RTP 头特定设置的修改
     可以认为,现用 RTP 数据包头对 RTP 支持的所有应用类共同需要的功能集是完整的。然而,为维持 ALF 设计原则,头可通过改变或增加设置来裁剪,并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息,但由于很多应用需要它们,否则要容纳它们,就要增加另外 32 位字,故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求,如采用更多或更少标记位。如有标记位,既然设置无关监控器能观察包丢失模式和标记位间关系,我们就可以定位八进制中最重要的位。
     其它特殊载荷格式(视频编码)所要求的信息应该携带在包的载荷部分。可出现在头,总是在载荷部分开始处,或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能,应用运行的设置应该定义附加固定段跟随在现存固定头 SSRC 之后。这些应用将能迅速而直接访问附加段,同时,与监控器和记录器无关设置仍能通过仅解释开始 12 个八进制处理 RTP 包。如证实附加功能是所有设置共同需要的,新版本 RTP 应该对固定头作出明确改变。

    |-page-|

    实时传输协议 RTP RTCP

       RTP Real-timeTransportProtocol )是用于 Internet 上针对多媒体数据流的一种传输协议。 RTP 被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流同步。 RTP 通常使用 UDP 来传送数据,但 RTP 也可以在 TCP ATM 等其他协议之上工作。当应用程序开始一个 RTP 会话时将使用两个端口:一个给 RTP ,一个给 RTCP RTP 本身并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠 RTCP 提供这些服务。通常 RTP 算法并不作为一个独立的网络层来实现,而是作为应用程序代码的一部分。实时传输控制协议 RTCP RTCP(Real-timeTransportControlProtocol) RTP 一起提供流量控制和拥塞控制服务。在 RTP 会话期间,各参与者周期性地传送 RTCP 包。 RTCP 包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料,因此,服务器可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。 RTP RTCP 配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。


    6.2.2 RTP
    控制协议 -- RTCP
      RTCP 协议将控制包周期发送给所有连接者,应用与数据包相同的分布机制。低层协议提供数据与控制包的复用,如使用单独的 UDP 端口号。 RTCP 执行下列四大功能:
      主要是提供数据发布的质量反馈。是作为 RTP 传输协议的一部分,与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用,但 IP 组播经验表明,从发送者收到反馈对诊断发送错误是致关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的,还是全局的。诸如 IP 组播等发布机制使网络服务提供商类团体可能接收反馈信息,充当第三方监控者来诊断网络问题。反馈功能由 RTCP 发送者和接收者报告执行。
      RTCP 带有称作规范名字( CNAME )的 RTP 源持久传输层标识。如发现冲突,或程序重新启动,既然 SSRC 标识可改变,接收者需要 CNAME 跟踪参加者。接收者也需要 CNAME 与相关 RTP 连接中给定的几个数据流联系
      前两种功能要求所有参加者发送 RTCP 包,因此,为了 RTP 扩展到大规模数量,速率必须受到控制。让每个参加者给其它参加者发送控制包,就大独立观察参加者数量。该数量用语计算包发送的速率。
      第四个可选功能是传送最小连接控制信息,如参加者辨识。最可能用在 " 松散控制 " 连接,那里参加者自由进入或离开,没有成员控制或参数协调, RTCP 充当通往所有参加者的方便通道,但不必支持应用的所有控制通讯要求。高级连接控制协议超出本书范围。
      IP 组播场合应用 RTP 时,前 3 个功能是必须的,推荐用于所有情形。 RTP 应用设计人员必须避免使用仅在单播模式下工作的机制,那将导致无法扩展规模。
     
      6.2.2.1 RTCP 包格式
      下面定义几个携带不同控制信息的 RTCP 包类型:
      SR
      发送报告,当前活动发送者发送、接收统计。
      RR
      接收报告,非活动发送者接收统计。
      SDES
      源描述项,包括 CNAME
      BYE
      表示结束。
      APP
      应用特定函数。
      类似于 RTP 数据包,每个 RTCP 包以固定部分开始,紧接着的是可变长结构元素,但以一个 32 位边界结束。包含安排要求和固定部分中长度段,使 RTCP 包可堆叠。不需要插入任何分隔符将多哥 RTCP 包连接起来形成一个 RTCP 组合包,以低层协议用单一包发送出去。由于需要低层协议提供提供整体长度来决定组合包的结尾,在组合包中没有单个 RTCP 包显式计数。
      组合包中每个 RTCP 包可独立处理,不需要根据包组合顺序。但未了执行协议功能,强加如下约束:
      接收统计(在 SR RR 中)应该经常发送,只要带宽允许,因此每个周期发送的组合 RTCP 包应包含报告包。
      新接收者需要接收 CNAME ,并尽快识别源,开始联系媒介进行同步,因此每个包应该包含 SDES CNAME
      出现在组合包前面的是包类型数量,其增长应该受到限制,以提高常数位数量,提高成功确认 RTCP 包对错误地址 RTP 数据包或其他无关包的概率。
      因此,所有 RTCP 包至少必须以两个包组合形式发送,推荐格式如下:
      加密前缀( Encryption prefix ):
      仅当组合包被加密,才加上一个 32 位随机数用于每个组合包发送。
      SR RR
      组合包中第一个 RTCP 包必须总为一个报告包,方便头的确认。即使没有数据发送,也没有接收到数据,也要发送一个空 RR ,那怕组合包中 RTCP 包为 BYE
      附加 RR
      如报告统计源数目超过 31 ,在初始报告包后应该有附加 RR 包。
     
      SDES
      包含 CNAME 项的 SDES 包必须包含在每个组合 RTCP 包中。如应用要求,其他源描述项可选,但受到带宽限制。
      BYE APP
      其它 RTCP 包类型可以任意顺序排列,除了 BYE 应作为最后一个包发送,包类型出现可不止一次。
      建议转换器或混合器从多个源组合单个 RTCP 包。如组合包整体长度超过网络路径最大传输单元,可分成多个较短组合包用低层协议以单个包形式发送。注意,每个组合包必须以 SR RR 包开始。附加 RTCP 包类型可在 Internet Assigned Numbers Authority (IANA) 处注册。
     
      6.2.2.2 RTCP 传输间隔
      RTP 设计成允许应用自动扩展,连接数可从几个到上千个。例如,音频会议中,数据流量是内在限制的,因为同一时刻只有一两个人说话;对组播,给定连接数据率仍是常数,独立于连接数,但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告,控制流量将随参加者数量线性增长,因此,速率必须按比例下降。
      一旦确认地址有效,如后来标记成未活动,地址的状态应仍保留,地址应继续计入共享 RTCP 带宽地址的总数中,时间要保证能扫描典型网络分区,建议为 30 分钟。注意,这仍大于 RTCP 报告间隔最大值的五倍。
      这个规范定义了除必需的 CNAME 外的几个源描述项,如 NAME (人名)和 EMAIL (电子邮件地址)。它也为定义新特定应用 RTCP 包类型的途径。给附加信息分配控制带宽应引起注意,因为它将降低接收报告和 CNAME 发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的 RTCP 带宽不要超过 20% 。而且并没有有意让所有 SDES 项包含在每个应用中。
      6.2.2.3 发送者与接收者报告
      RTP 接收者使用 RTCP 报告包提供接收质量反馈,报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外,发送者报告与接收者报告间唯一的差别是发送者报告包含一个 20 个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包,就发布 SR ;否则,就发出 RR SR RR 都可没有或包括多个接收报告块。发布报告不是为列在 CSRC 列表上的起作用的源,每个接收报告块提供从特殊源接收数据的统计。既然最大可有 31 个接收报告块嵌入在 SR RR 包中,
      丢失包累计数差别给出间隔期间丢掉的数量,而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量,两者之比等于经过间隔期间包丢失百分比。如两报告连续,比值应该等于丢失段部分;否则,就不等。每秒包丢失绿可通过 NTP 时标差除以丢失部分得到。
      从发送者信息,第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率,两者比值给出平均载荷大小。如假设包丢失与包大小无关,那么特殊接收者收到的包数量给出此接收者收到的表观流量。
     
      6.2.2.4 SDES: 源描述 RTCP
      SDES 包为三层结构,由头与数据块组成,数据块可以没有,也可有多个,组成项描述块所表明的源。项描述如下:
      版本( V )、填充( P )、长度:
      SR 包中所描述。
      包类型( PT ):
      8 位,包含常数 202 ,识别 RTCP SDES 包。
      源计数( SC ):
      5 位,包含在 SDES 包中的 SSRC/CSRC 块数量,零值有效,但没有意义。
      源描述项内容如下:
      CNAME: 规范终端标识 SDES
      CNAME 标识属性如下:
      如发生冲突或重启程序,由于随机分配的 SSRC 标识可能发生变化,需要 CNAME 项提供从 SSRC 标识到仍为常量的源标识的绑定。
      SSRC 标识, CNAME 标识在 RTP 连接的所有参加者中应是唯一的。
      为了提供一套相关 RTP 连接中某个参加者所采用的跨多媒体工具间的绑定, CNAME 应固定为那个参加者。
      为方便第三方监控, CNAME 应适合程序或人员定位源。
      NAME :用户名称 SDES
      这是用于描述源的真正的名称,如 "John Doe, Bit Recycler, Megacorp" ,可是用户想要的任意形式。对诸如会议应用,这种名称也许是参加者列表显示最适宜的形式,它将是除 CNAME 外发送最频繁的项目。设置可建立这样的优先级别。 NAME 值至少在连接期间仍希望保持为常数。它不该成为连接的所有参加者中唯一依赖。
      EMAIL :电子邮件地址 SDES
      邮件地址格式由 RFC822 规定,如 "John.Doe@megacorp.com" 。连接期间,电子邮件仍希望保持为常数。
      PHONE :电话号码 SDES
      电话号码应带有加号,代替国际接入代码,如 "+1 908 555 1212" 即为美国电话号码。
     
      LOC :用户地理位置 SDES
      根据应用,此项具有不同程度的细节。对会议应用,字符串如 "Murray Hill, New Jersey" 就足够了。然而,对活动标记系统,字符串如 "Room 2A244, AT&T BL MH" 也许就适用。细节留给实施或用户,但格式和内容可用设置指示。在连接期间,除移动主机外, LOC 值期望仍保留为常数。
      TOOL :应用或工具名称 SDES
      是一个字符串,表示产生流的应用的名称与版本,如 "videotool 1.2" 。这部分信息对调试很有用,类似于邮件或邮件系统版本 SMTP 头。 TOOL 值在连接期间仍保持常数。
      NOTE: 通知 / 状态 SDES
      该项的推荐语法如下所述,但这些或其它语法可在设置中显式定义。 NOTE 项旨在描述源当前状态的过渡信息,如 "on the phone, can´t talk" ,或在讲座期间用于传送谈话的题目。它应该只用于携带例外信息,而不应包含在全部参加者中,因为这将降低接收报告和 CNAME 发送的速度,因此损害协议的性能。特殊情况下,它不应作为用户设置文件的项目,也不是自动产生。
      当其为活动时,由于 NOTE 项对显示很重要,其它非 CNAME 项(如 NAME )传输速率将会降低,结果使 NOTE 项占用 RTCP 部分带宽。若过渡信息不活跃, NOTE 项继续以同样的速度重复发送几次,但以一个串长为零的字符串通知接收者。然而,如对小倍数的重复或约 20-30 RTCP 间隔也没有接收到,接收者也应该考虑 NOTE 项是不活跃的。
      PRIV: 专用扩展 SDES
      该项用于定义实验或应用特定的 SDES 扩展,它包括由长字符串对组成的前缀,后跟填充该项其他部分和携带所需信息的字符串值。前缀长度段为 8 位。前缀字符串是定义 PRIV 项人员选择的名称,唯一对应应用接收到的其它 PRIV 项。应用实现者可选择使用应用名称,如有必要,外加附加子类型标识。另外,推荐其它人根据其代表的实体选择名称,然后,在实体内部协调名称的使用。
      注意,前缀消耗了总长为 255 个八进制项的一些空间,因此,前缀应尽可能的短。这个设备和受到约束的 RTCP 带宽不应过载,其目的不在于满足所有应用的全部控制通讯要求。 SDES PRIV 前缀没在 IANA 处注册。如证实某些形式的 PRIV 项具有通用性, IANA 应给它分配一个正式的 SDES 项类型,这样就不再需要前缀。这简化了应用,并提高了传输的效率。
      6.2.2.5 BYE :断开 RTCP
      如混合器接收到一个 BYE 包,混合器转发 BYE 包,而不改变 SSRC/CSRC 标识。如混合器关闭,它也应该发出一个 BYE 包,列出它所处理的所有源,而不只是自己的 SSRC 标识。作为可选项, BYE 包可包括一个 8 位八进制计数,后跟很多八进制文本,表示离开原因,如: "camera malfunction" "RTP loop detected" 。字符串具有同样的编码,如在 SDES 中所描述的。如字符串填充包至下 32 位边界,字符串就不以空结尾;否则, BYE 包以空八进制填充。
      6.2.2.6 APP :定义应用的 RTCP
      APP 包用于开发新应用和新特征的实验,不要求注册包类型值。带有不可识别名称的 APP 包应被忽略掉。测试后,如确定应用广泛,推荐重新定义每个 APP 包,而不用向 IANA 注册子类型和名称段。
     
     

    |-page-|
    实时流协议 RTSP

      实时流协议 RTSP(RealTimeStreamingProtocol) 是由 RealNetworks Netscape 共同提出的,该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据。 RTSP 在体系结构上位于 RTP RTCP 之上,它使用 TCP RTP 完成数据传输。 HTTP RTSP 相比, HTTP 传送 HTML ,而 RTP 传送的是多媒体数据。 HTTP 请求由客户机发出,服务器作出响应;使用 RTSP 时,客户机和服务器都可以发出请求,即 RTSP 可以是双向的。


    6.3 RTSP
    协议
      实时流协议( RTSP )是应用级协议,控制实时数据的发送。 RTSP 提供了一个可扩展框架,使实时数据,如音频与视频,的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接,为选择发送通道,如 UDP 、组播 UDP TCP ,提供途径,并为选择基于 RTP 上发送机制提供方法。
      6.3.1 简介
      6.3.1.1 目的
      实时流协议( RTSP )建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的,通常它本身并不发送连续流。换言之, RTSP 充当多媒体服务器的网络远程控制。 RTSP 连接没有绑定到传输层连接,如 TCP 。在 RTSP 连接期间, RTSP 用户可打开或关闭多个对服务器的可靠传输连接以发出 RTSP 请求。此外,可使用无连接传输协议,如 UDP RTSP 流控制的流可能用到 RTP ,但 RTSP 操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与 HTTP/1.1 类似,因此 HTTP 的扩展机制大都可加入 RTSP 。协议支持的操作如下:
      从媒体服务器上检索媒体:
      用户可通过 HTTP 或其它方法提交一个演示描述。如演示是组播,演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户,用户为了安全应提供目的地址。
      媒体服务器邀请进入会议:
      媒体服务器可被邀请参加正进行的会议,或回放媒体,或记录其中一部分,或全部。这种模式在分布式教育应用上很有用,会议中几方可轮流按远程控制按钮。
      将媒体加到现成讲座中:
      如服务器告诉用户可获得附加媒体内容,对现场讲座显得尤其有用。如 HTTP/1.1 中类似, RTSP 请求可由代理、通道与缓存处理。
     
      6.3.1.2 协议特点
      RTSP 特性如下:
      可扩展性:
      新方法和参数很容易加入 RTSP
      易解析:
      RTSP 可由标准 HTTP MIME 解吸器解析。
      安全:
      RTSP 使用网页安全机制。
      独立于传输:
      RTSP 可使用不可靠数据报协议( UDP )、可靠数据报协议( RDP ),如要实现应用级可靠,可使用可靠流协议。
      多服务器支持:
      每个流可放在不同服务器上,用户端自动同不同服务器建立几个并发控制连接,媒体同步在传输层执行。
      记录设备控制:
      协议可控制记录和回放设备。
      流控与会议开始分离:
      仅要求会议初始化协议提供,或可用来创建唯一会议标识号。特殊情况下, SIP H.323
      可用来邀请服务器入会。
      适合专业应用:
      通过 SMPTE 时标, RTSP 支持帧级精度,允许远程数字编辑
      演示描述中立:
      协议没强加特殊演示或元文件,可传送所用格式类型;然而,演示描述至少必须包含一个 RTSP URI
      代理与防火墙友好:
      协议可由应用和传输层防火墙处理。防火墙需要理解 SETUP 方法,为 UDP 媒体流打开一个 " 缺口 "
      HTTP 友好:
      此处, RTSP 明智的采用 HTTP 观念,使现在结构都可重用。结构包括 Internet 内容选择平台( PICS )。由于在大多数情况下控制连续媒体需要服务器状态, RTSP 不仅仅向 HTTP 添加方法。
      适当的服务器控制:
      如用户启动一个流,他必须也可以停止一个流。
      传输协调;
      实际处理连续媒体流前,用户 可协调传输方法。
      性能协调:
      如基本特征无效,必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。
      6.3.1.3 扩展 RTSP
      由于不是所有媒体服务器有着相同的功能,媒体服务器有必要支持不同请求集。 RTSP 可以如下三种方式扩展,这里以改变大小排序:
      以新参数扩展。如用户需要拒绝通知,而方法扩展不支持,相应标记就加入要求的段中。
      加入新方法。如信息接收者不理解请求,返回 501 错误代码(还未实现),发送者不应再次尝试这种方法。用户可使用 OPTIONS 方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。
      定义新版本协议,允许改变所有部分。(除了协议版本号位置)
      6.3.1.4 操作模式
      每个演示和媒体流可用 RTSP URL 识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用 HTTP 或其它途径用户可获得这个文件,它没有必要保存在媒体服务器上。
      为了说明,假设演示描述描述了多个演示,其中每个演示维持了一个公共时间轴。为简化说明,且不失一般性,假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外,网络目标地址和端口也需要决定。下面区分几种操作模式:
      单播:
      以用户选择的端口号将媒体发送到 RTSP 请求源。
      组播,服务器选择地址:
      媒体服务器选择组播地址和端口,这是现场直播或准点播常用的方式。
      组播,用户选择地址:
      如服务器加入正在进行的组播会议,组播地址、端口和密匙由会议描述给出。
      6.3.1.5 RTSP 状态
      RTSP 控制通过单独协议发送的流,与控制通道无关。例如, RTSP 控制可通过 TCP 连接,而数据流通过 UDP 。因此,即使媒体服务器没有收到请求,数据也会继续发送。在连接生命期,单个媒体流可通过不同 TCP 连接顺序发出请求来控制。所以,服务器需要维持能联系流与 RTSP 请求的连接状态。 RTSP 中很多方法与状态无关,但下列方法在定义服务器流资源的分配与应用上起着重要的作用:
      SETUP
      让服务器给流分配资源,启动 RTSP 连接。
      PLAY RECORD
      启动 SETUP 分配流的数据传输。
      PAUSE
      临时停止流,而不释放服务器资源。
      TEARDOWN
      释放流的资源, RTSP 连接停止。
      标识状态的 RTSP 方法使用连接头段识别 RTSP 连接,为响应 SETUP 请求,服务器连
      接产生连接标识。
     
      6.3.1.6 与其他协议关系
      RTSP 在功能上与 HTTP 有重叠,与 HTTP 相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现 RTSP 媒体服务器之间存在不同传递点。例如,演示描述可通过 HTTP RTSP 检索,这降低了浏览器的往返传递,也允许独立 RTSP 服务器与用户不全依靠 HTTP
      但是, RTSP HTTP 的本质差别在于数据发送以不同协议进行。 HTTP 是不对称协议,用户发出请求,服务器作出响应。 RTSP 中,媒体用户和服务器都可发出请求,且其请求都是无状态的;在请求确认后很长时间内,仍可设置参数,控制媒体流。重用 HTTP 功能至少在两个方面有好处,即安全和代理。要求非常接近,在缓存、代理和授权上采用 HTTP 功能是有价值的。
      当大多数实时媒体使用 RTP 作为传输协议时, RTSP 没有绑定到 RTP RTSP 假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。
     
      6.3.2 协议参数
     
      6.3.3 RTSP 信息
      RTSP 是基于文本的协议,采用 ISO 10646 字符集,使用 UTF-8 编码方案。行以 CRLF 中断,但接收者本身可将 CR LF 解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低,处理效率没引起注意。如仔细研究,文本协议很容易以脚本语言(如: Tcl Visual Basic Perl )实现研究原型。
      10646 字符集避免敏感字符集切换,但对应用来说不可见。 RTCP 也采用这种编码方案。带有重要意义位的 ISO 8859-1 字符表示如 100001x 10xxxxxx. RTSP 信息可通过任何低层传输协议携带。
      请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中,信息体长度有如下因素决定:
      不管实体头段是否出现在信息中,不包括信息体的的响应信息总以头段后第一和空行结束。
      如出现内容长度头段,其值以字节计,表示信息体长度。如未出现头段,其值为零。
      服务器关闭连接。
      注意: RTSP 目前并不支持 HTTP/1.1" " 传输编码,需要有内容长度头。假如返回适度演示描述长度,即使动态产生,使块传输编码没有必要,服务器也应该能决定其长度。如有实体,即使必须有内容长度,且长度没显式给出,规则可确保行为合理。
      从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。 RTSP 定义了附加状态代码,而没有定义任何 HTTP 代码。
      6.3.4 实体
      如不受请求方法或响应状态编码限制,请求和响应信息可传输实体,实体由实体头文件和试题体组成,有些响应仅包括实体头。在此,根据谁发送实体、谁接收实体,发送者和接收者可分别指用户和服务器。
      实体头定义实体体可选元信息,如没有实体体,指请求标识的资源。扩展头机制允许定义附加实体头段,而不用改变协议,但这些段不能假定接收者能识别。不可识别头段应被接收者忽略,而让代理转发。
      6.3.5 连接
      RTSP 请求可以几种不同方式传送:
      1 、持久传输连接,用于多个请求 / 响应传输。
      2 、每个请求 / 响应传输一个连接。
      3 、无连接模式。
      传输连接类型由 RTSP URI 来定义。对 "rtsp" 方案,需要持续连接;而 "rtspu" 方案,调用 RTSP 请求发送,而不用建立连接。
      不象 HTTP RTSP 允许媒体服务器给媒体用户发送请求。然而,这仅在持久连接时才支持,否则媒体服务器没有可靠途径到达用户,这也是请求通过防火墙从媒体服务器传到用户的唯一途径。
      6.3.6 方法定义
      方法记号表示资源上执行的方法,它区分大小写。新方法可在将来定义,但不能以 $ 开头。
      某些防火墙设计与其他环境可能要求服务器插入 RTSP 方法和流数据。由于插入将使客户端和服务器操作复杂,并强加附加开销,除非有必要,应避免这样做。插入二进制数据仅在 RTSP 通过 TCP 传输时才可使用。流数据(如 RTP 包)用一个 ASCII 美圆符号封装,后跟一个一字节通道标识,其后是封装二进制数据的长度,两字节整数。流数据紧跟其后,没有 CRLF ,但包括高层协议头。每个 $ 块包含一个高层协议数据单元。
      当传输选择为 RTP RTCP 信息也被服务器通过 TCP 连接插入。缺省情况下, RTCP 包在比 RTP 通道高的第一个可用通道上发送。客户端可能在另一通道显式请求 RTCP ,这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时,为取得同步,需要 RTCP 。而且,这为当网络设置需要通过 TCP 控制连接透过 RTP/RTCP 提供了一条方便的途径,可能时,在 UDP 上进行传输。
      6.3.7 流水线操作
      支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出响应。如果请求不是发送给组播组,接收者就确认请求,如没有确认信息,发送者可在超过一个来回时间( RTT )后重发同一信息。
      RTT TCP 中估计,初始值为 500 ms 。应用缓存最后所测量的 RTT ,作为将来连接的初始值。如使用一个可靠传输协议传输 RTSP ,请求不允许重发, RTSP 应用反过来依赖低层传输提供可靠性。如两个低层可靠传输(如 TCP RTSP )应用重发请求,有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传,接收者也不能充分利用应用层重传。如包损失由阻塞引起,不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题,避免对圆锥算法的依赖。每个请求在 CSeq 头中携带一个系列号,每发送一个不同请求,它就加一。如由于没有确认而重发请求,请求必须携带初始系列号。
      实现 RTSP 的系统必须支持通过 TCP 传输 RTSP ,并支持 UDP 。对 UDP TCP RTSP 服务器的缺省端口都是 554 。许多目的一致的 RTSP 包被打包成单个低层 PDU TCP 流。 RTSP 数据可与 RTP RTCP 包交叉。不象 HTTP RTSP 信息必须包含一个内容长度头,无论信息何时包含负载。否则, RTSP 包以空行结束,后跟最后一个信息头。


    |-page-|
    资源预订协议 RSVP 协议

     由于音频和视频数据流比传统数据对网络的延时更敏感,要在网络中传输高质量的音频、视频信息,除带宽要求之外,还需其他更多的条件。 RSVP(ResourceReserveProtocol) 是正在开发的 Internet 上的资源预订协议,使用 RSVP 预留一部分网络资源(即带宽),能在一定程度上为流媒体的传输提供 QoS 。在某些试验性的系统如网络视频会议工具 vic 中就集成了 RSVP

    6.4 RSVP
    协议
      6.4.1 背景
      资源预订协议( RSVP )是网络控制协议,它使 Internet 应用传输数据流时能够获得特殊服务质量( QoSs ), RSVP 是非路由协议;它同路由协议协同工作,建立与路由协议计算出路由等价的动态访问列表, RSVP OSI 七层协议栈中传输层,开始是研究人员构造的, IETF 正朝标准化方向努力,图 3.4 说明了 RSVP 运行环境。
     


      3.4 RSVP 中主机信息通过数据流发送给接收者示意图
      6.4.2 RSVP 数据流
      RSVP 中,数据流是一系列信息,有着相同的源、目的(可有多个)和服务质量, QoS 要求通过网络以流说明形式通讯。流说明是互连网主机用来请求特殊服务的数据结构,保证互连网处理主机传输。 RSVP 支持三种传输类型:最好性能( best-effort ),速率敏感( rate-sensitive )与延迟敏感( delay-sensitive )。用来支持这些传输类型的数据流服务依赖 QoS 实施,以下部分陈述传输类型与相关服务。
      最好性能传输为传统 IP 传输。应用包括文件传输(如邮件传输)、磁盘映像、交互登录和事务传输。支持最好性能传输的服务称为最好性能服务。速率敏感传输放弃及时性,而确保速率。例如:速率敏感传输请求 100 kbps 带宽,如在扩展期实际发送 200 kbps ,路由器可能延迟传输。速率敏感传输目的不在通过电路交换网络传输,但它通常与电路交换网络( ISDN )应用有联系,现在正运行在数据报网络( IP )上。这类应用如 H.323 视频会议,设计运行在 ISDN H.320 )或 ATM H.310 )上,但发现在 Internet 上也有应用。 H.323 编码是常数速率或准常数速率,它需要常数传输速率。 RSVP 服务支持速率敏感传输,称为位速率保证服务。延迟敏感传输要求传输及时,并因而改变其速率。例如: MPEG-II 视频根据图象改变量大小平均流量为 3 7 Mbps 3 Mbps 可能对应一堵上色的墙,而 7 Mbps 可能是海洋的波浪。 MPEG-II 视频源发送关键和增量帧。典型的,每秒一个或两个关键帧,描述整个图象,而每秒 13 28 帧描述关键帧之间的变化,增量帧通常比关键帧小。因此,帧与帧之间速率变化较大。但由于单个帧要求在一帧时间内发送出去,或解码器速度跟不上,必须对增量帧传输进行特定优先级别协调。 RSVP 服务支持延迟敏感传输,被看作控制延迟服务(非实时服务)与预报服务(实时服务)。
      6.4.3 RSVP 数据流处理
      RSVP 数据流基本特征是连接,数据包在其上流通。连接是具有相同单播或组播目的数据流, RSVP 分别处理每个连接。 RSVP 支持单播和组播连接(这里连接是一些发送者与另一些接收者的会话),而流总是从发送者开始的。特定连接的数据包被导向同一个 IP 目的地址或公开的目的端口。 IP 目的地址可能是组播发送的组地址,也可能是单个接收者的单播地址。公开目的端口可用 UDP/TCP 目的端口段、另外传输协议等价段或某些应用特定信息定义。
      RSVP 数据发布是通过组播或单播实现的。组播传输将某个发送者的每个数据包拷贝转发给多个目的。单播传输特征是只有一个接收者。即使目的地址是单播,也可能有多个接收者,以公开端口区分。多个发送者也可能存在单播地址,在这种情况下, RSVP 可建立多对一传输的资源预订。每个 RSVP 发送者和接收者对应唯一的 Internet 主机。然而,单个主机可包括多个发送者和接收者,以公开端口区分。
      RSVP 服务质量 (QoS)
      RSVP 中,服务质量( QoS )是流规范指定的属性,流规范用于决定参加实体(路由器、接收者和发送者)进行数据交换的方式。主机和路由器使用 RSVP 指定 QoS ;其中主机代表应用数据流使用 RSVP 从网络申请 QoS 级别,而路由器使用 RSVP 发送 QoS 请求给数据流路经的其它路由器。这样做, RSVP 就可维持路由器和主机状态来提供所请求的服务。
      RSVP 连接启动
      为了初始化 RSVP 组播连接,接收者首先使用 Internet 组成员协议( IGMP )加入 IP 目的地址指定的组播组。对单播连接,单播路由就象 IGMP 结合协议无关组播( PIM )在组播时的作用。接收者加入组后,潜在的发送者就开始发送 RSVP 路径信息给 IP 目的地址。接收者应用收到路径信息,开始发送相应资源预订请求信息,使用 RSVP 指定欲点播的流描述。发送者应用接收到资源预订请求信息后,发送者开始发送数据包。
      6.4.4 RSVP 资源预订类型
      资源预订类型指一套指定所支持参数的控制选项。 RSVP 支持两种主要资源预订:独占资源预订和共享资源预订。独占资源预订为每个连接中每个相关发送者安装一个流;而共享资源预订由互不相关的发送者使用。表 3.10 说明这两种资源预订协议的应用范围及所支持的范围与类型的组合情况。
     
      6.4.5 RSVP 软状态实现
      RSVP ,软状态指可被某些 RSVP 信息更新的路由器和终端结点的状态。软状态特征允许 RSVP 网络支持动态组成员变化,并适应路由变化。一般说来,软状态由基于 RSVP 网络维护,使网络可在没有查询终端结点的情况下改变状态。对比电路交换结构,终端结点进行依次呼叫,如失败,进行依次新呼叫。
      RSVP 协议为创建和维护组播和单播混合发送路径的分布式资源预订状态提供了一个通用功能。为维护资源预订状态, RSVP 跟踪路由器和主机结点的软状态。路径与资源预订请求信息创建并周期更新 RSVP 软状态。如在清除时间间隔到期前没有收到相应更新信息,就删除该状态,显式 teardown 信息也可删除软状态。 RSVP 周期扫描欲建立的软状态,并转发路径与预订请求更新信息给下一跳。
      当路由改变,下一个路径信息初始化新路由的路径状态,将来资源预订请求信息建立资源预订状态。现在未使用的网段状态标记为超时。( RSVP 规范要求在拓扑改变后两秒通过网络初始化新资源预订)。当发生状态变化, RSVP 无延迟的将变化从 RSVP 网络的一个终端传到另一个终端。如接收到的状态与存储状态不同,就更新存储状态。如结果改变了欲产生的更新信息,更新信息立即生成并转发出去。
      6.4.6 RSVP 操作模型
      RSVP 下,资源为简单数据流(单向数据流)预订起来。每个发送者逻辑上与接收者不同,但任何应用都可充当发送者和接收者,接收者负责请求资源预订。图 3.5 说明了其基本操作环境,紧接部分将提供特定事件序列的框架。
     


      3.5 RSVP 操作环境:为单向数据流预订资源
      6.4.6.1 基本 RSVP 协议操作
      RSVP 资源预订处理初始化开始于 RSVP 后台服务查询本地路由协议以获得路由。主机发送 IGMP 消息加入组播组,而发送 RSVP 消息预订沿组路径的资源。每个能加入资源预订的路由器将收到的数据包传递给包分类器,然后将它们在包调度器中排队。 RSVP 包分类器决定每个包的路由和 QoS 类; RSVP 调度器给每个接口所使用的特殊数据链路层媒介上传输分配资源。如数据链路层媒介有自身的 QoS 管理能力,包调度器负责协调数据链路层,获得 RSVP 所请求的 QoS 。调度器本身分配无源 QoS 媒介上包传输能力,如双铰线;也可分配其它系统资源,如 CPU 时间与缓存。 QoS 请求一般发源于接收者主机应用,而被传递到本地 RSVP 应用,如 RSVP 后台服务。 RSVP 协议接着将对所有结点(路又器与主机)的请求沿逆向数据路径传到到数据源。在每个结点处, RSVP 程序应用一个称为进入允许控制的本地决定程序决定是否能提供所请求的 QoS 。如进入允许控制成功, RSVP 程序设置包分类和调度器的参数,以获得所申请的 QoS 。如进入允许控制在某结点处失败, RSVP 程序给产生此请求的应用返回一个错误指示。
      6.4.6.2 RSVP 隧道
      在整个 Internet 上同时配置 RSVP 或任意其他协议都是不可能的。实际上, RSVP 决不可能在每个地方都被配置。因此, RSVP 必须提供正确协议操作,即使只有两个支持 RSVP 的路由器与一群不支持 RSVP 的路由器相连。一个中等规模不支持 RSVP 的网络不能执行资源预订,因而服务保证也就不能实现。然而,如该网络有充足额外容量,也可以提供可接受的实时服务。
      为了支持 RSVP 网络连接通过不支持 RSVP 的网络, RSVP 支持隧道技术。隧道技术要求 RSVP 和非 RSVP 路由器用本地路由表转发到目的地址的路径信息。当路径信息通过非 RSVP 网络时,路径信息拷贝携带最后一个支持 RSVP 的路由器的 IP 地址。预订请求信息转发给下一个上游支持 RSVP 的路由器
      6.4.7 加权平均排队方案
      用技术来加强出现瓶颈处的有效资源预订(如 Cisco 的加权平均排队方案)有着正面影响。隧道技术仅在瓶颈出在非 RSVP 域且不可避免时才有风险。图 3.6 表示基于 RSVP 网络间采用隧道技术的 RSVP 环境
     


      3.6 :应用隧道技术的 RSVP 环境
      6.4.8 RSVP 消息
      RSVP 支持四种基本消息类型:资源预订请求消息、路径消息、错误与确认消息和断开消息。
      6.4.9 RSVP 包格式
      3.11 说明了 RSVP 包格式,如下内容列出格式的头和对象段。
      3.11 RSVP 包格式 RSVP 消息头段(长度单位:位) 4 4 8 16 16 8 8 32 15 1 16 版本 标志 类型 校验和 长度 预订 发送 TTL 消息 ID 预订 MF 偏移量 RSVP 对象段(长度单位:位) 16 8 8 可变 长度 分类号 C 类型 对象内容
      RSVP 消息头段
      RSVP 消息头段组成:
      版本号 ---4 位,表示协议版本号(当前版本为 1 )。
      标志 ---4 ,当前没有定义标志段。
      类型 ---8 位, 有几种可能值,如表 3.12 所示。
      3.12 RSVP 消息类型段取值 消息类型 1 路径 2 资源预订请求 3 路径错误 4 资源预订请求错误 5 路径断开 6 资源预订断开 7 资源预订请求确认 校验和 ---16 位,表示基于 RSVP 消息的内容上标准 TCP/UDP 校验和。
      长度 ---16- 位,表示 RSVP 包的字节长度,包括公共头和随后的可变长度对象。如设置了 MF 标志,或片段偏移为非零值,这就是较大消息当前片段长度。
      发送 TTL---8 位,表示消息发送的 IP 生存期。
      消息 ID---32 位,提供下一 RSVP / 前一 RSVP 跳消息中所有片段共享标签。
      更多片段 (MF) 标志 --- 一个字节的最低位,其它 7 位预订,除消息的最后一个片段外,都将设置 MF
      片段偏移 ---24 位,表示消息中片段的字节偏移量。
     
      RSVP 对象段
      RSVP 对象段组成如下:
      长度 ---16- 位,包含总对象长度,以字节计(必须是 4 的倍数,至少是 4 )。
      分类号 --- 表示对象类型,每个对象类型都有一个名称。 RSVP 程序必须可识别分类,类型在表 3.13 列出。如没有识别出对象分类号,分类号高位决定结点采用什么行动。
      C- 类型 ---C 类型,在分类号中唯一。最大内容长度是 65528 个字节。分类号和 C- 类型段 ( 与标志位一起 ) 可用作定义每个对象唯一位的 16 位数。
      对象内容 --- 长度、类型号和 C 类型段指定对象内容的形式。
     
      6.4.10 RSVP 小结
      RSVP 运行在传输层,在 IP 上层。与 ICMP IGMP 相比,它是一个控制协议。 RSVP 的组成元素有发送者、接收者和主机或路由器。发送者负责让接收者知道数据将要发送,以及需要什么样的 QoS ;接收者负责发送一个通知到主机或路由器,这样他们就可以准备接收即将到来的数据;主机或路由器负责留出所有合适的资源。
      RSVP 协议的两个重要概念是流与预定。流是从发送者到一个或多个接收者的连接特征,通过 IP 包中 " 流标记 " 来认证。发送一个流前,发送者传输一个路径信息到目的接收方,这个信息包括源 IP 地址、目的 IP 地址和一个流规格。这个流规格是由流的速率和延迟组成的,这是流的 QoS 需要的。接收者实现预定后,基于接收者的模式能够实现一种分布式解决方案。
      RSVP 领域的发展是非常迅速的,但目前并没有在任何一种网络上得到证实,它的应用只是局限在测试的小 Intranet 网络上。因为 RSVP 的预定必须建立在完全流方式的基础上,其可扩展性问题倍受关注。 RSVP 还存在诸如当一个服务请求被申请控制否决时网络应该怎样通知用户以及用户怎样应答这样的通知等问题。
    展开全文
  • 实时传输协议详解

    千次阅读 2006-07-31 10:47:00
    实时传输协议详解 实时传输协议RTP1.RTP协议:RTP( Real-time Transport Protocol)协议最初是在70年代为了尝试传输声音文件,把包分成几部分用来传输语音,时间标志和队列号。经过一系列发展,RTP第一版本在1991...
  • 基于RTP(实时传输协议)的客户端服务器的程序
  • <br />RTP是一种提供端对端传输服务的实时传输协议,用来支持在单目标广播和多目标广播网络服务中传输实时数据,而实时数据的传输则由RTCP协议来监视和控制。 RTP定义在RFC 使用RTP协议的应用程序...
  • RTP:实时传输协议详解(转)

    千次阅读 2015-03-26 15:45:57
    实时传输协议RTP 1.RTP协议: RTP( Real-time Transport Protocol)协议最初是在70年代为了尝试传输声音文件,把包分成几部分用来传输语音,时间标志和队列号。经过一系列发展,RTP第一版本在1991年8月由美国的一...
  • 实时传输协议RTP

    千次阅读 2011-08-17 10:29:51
    RTP( Real-time Transport Protocol)协议最初是在70年代为了尝试传输声音文件,把包分成几部分用来传输语音,时间标志和队列号。经过一系列发展,RTP第一版本在1991年8月由美国的一个实验室发布了。到本世纪1996年...
  • <br />实时传输协议(RTP)为数据提供了具有实时特征的端对端传送服务,如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务;这两种协议都...
  • 服务于流媒体的实时传输协议RTP

    千次阅读 2006-10-19 20:49:00
    服务于流媒体的实时传输协议RTP作者:清华大学信息学院多媒体中心 赵勇 曾珂 戴琼海 【提 要】流媒体作为新的网络应用主流发展极为迅速,本文从应用的角度描述了服务于流媒体的实时传输协议RTP协议,并介绍了RTP协议...
  • 被定义为传输音频、视频、模拟数据等实时数据的传输协议,与传统的注重的高可靠的数据传输的运输层协议相比,它更加侧重的数据传输的实时性,此协议提供的服务包括数据顺序号、时间标记、传输控制等。 RTP位于传输层...
  • RTP(Real Time Transport Protocol) RTP是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流...
  • 实时传输协议:RTP、RTCP、RTSP介绍

    千次阅读 2012-06-15 12:56:57
        RTP(Real Time Transport ... RTP是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息...
  • 实时视频传输协议RTP

    万次阅读 多人点赞 2017-11-24 10:51:47
    一、RTP(实时传输协议) RTP全名是Real-time Transport Protocol(实时传输协议),RTP协议常用于流媒体系统(配合RTCP协议或者RTSP协议)。因为RTP自身具有Time stamp所以在ffmpeg 中被用做一种formate. 每一个RTP...
  • rtp实时网络传输协议及demo源码 c++
  • 实时消息传输协议(RTMP)详解

    千次阅读 2017-03-30 22:31:34
    概述概念:RTMP协议从属于应用层,被设计用来在适合的传输协议(如TCP)上复用和打包多媒体传输流(如音频、视频和互动内容)。RTMP提供了一套全双工的可靠的多路复用消息服务,类似于TCP协议[RFC0793],用来在一对...
  • 流媒体使用的传输协议

    千次阅读 2013-10-02 11:35:39
    2、RTP:实时传输协议 3、RTCP:实时传输控制协议 4、MMS:微软流媒体服务协议 5、RTSP:实时流传输协议 6、MIME:多目因特网电子邮件扩展协议 7、RTMP(RTMPE/RTMPS/RTMPT):Adobe实时消息协议簇 8、RTMFP:...
  • 简单易懂,高速的UDP协议的图传、视频传输,一个发送端文件,一个接收端文件,因为udp协议的缺点,所以高码率传输时可能会有色差干扰。
  • 流媒体传输协议

    千次阅读 2007-05-28 18:07:00
    目前,支持流媒体传输的协议主要有 1、实时传输协议RTP(Real-time Transport Protocol)。用于Internet上针对多媒体数据流的一种传输协议。RTP通常工作在点对点或点对多点的传输情况下,其目的是提供时间信息和实 现流...
  • 文件传输协议介绍

    万次阅读 2019-06-11 16:23:30
    文件传输协议介绍 文件传输协议是一种极为普遍的档案分享服务,让你可以将你的档案从储存装置传送到ASUSTOR NAS。ASUSTOR NAS 所支援的文件传输协议可分为: CIFS (网络文件共享系统) 通常是指 SMB,SAMBA 或 ...
  • CAN总线传输协议

    万次阅读 多人点赞 2019-06-29 22:12:57
    一、控制器局域网总线(CAN,Controller Area Network)是一种用于实时应用的串行通讯协议总线,它可以使用双绞线、同轴电缆或光纤来传输信号,因其高性能、高可靠性和高实时性等特点,已经成为了世界上应用最广泛的...
  • 文件传输协议FTP

    千次阅读 2018-05-11 14:48:31
    文件传输协议FTP(File Transfer Protocol)是因特网中使用最广泛的文件传输协议。FTP使用交互式的访问,允许客户指定文件的类型和格式(如指明是否使用ASCII码),并允许文件具有存取权限(如访问文件的用户必须经过授权...
  •  实时传输协议RTP(Real-time Transport Protocol)是一个网络传输协议,它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的,后在RFC3550中进行更新。  国际电信联盟ITU-T也发布了自己的RTP文档,作为H....
  • dubbo传输协议

    千次阅读 2018-05-30 10:53:00
    一、dubbo的通讯协议1、dubbo协议,是默认的基于TCP传输协议的长连接,NIO异步通信,适合于小数据量高并发的场景以及服务消费者机器数远大于服务提供者机器数的情况。,不适合大文件,视频的传输连接个数:单连接...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 831,179
精华内容 332,471
关键字:

实时传输协议