关于RTSP_RTP_RTCP协议的深刻初步介绍

TCP 专栏收录该内容
6 篇文章 0 订阅

前记

作为一个软件工程师,特别是偏向安防应用或者互联网对接,都应该听说RTSP,RTP,RTCP等协议的概念。本篇博文详细介绍一下关于RTSP等协议,让读者更加方便的理解透彻。另外后续还会从RTSP的应用方面继续编写。

三个协议简单描述

RTSP(Real Time Streaming Protocol),RFC2326,实时流传输协议,是TCP/IP协议体系中的一个应用层协议,由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或UDP完成数据传输。

Real-time Transport Protocol或简写RTP,它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它是创建在UDP协议上的。

Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP)是实时传输协议(RTP)的一个姐妹协议。RTCP由RFC 3550定义(取代作废的RFC 1889)。RTP 使用一个 偶数 UDP port ;而RTCP 则使用 RTP 的下一个 port,也就是一个奇数 port。RTCP与RTP联合工作,RTP实施实际数据的传输,RTCP则负责将控制包送至电话中的每个人。其主要功能是就RTP正在提供的服务质量做出反馈。

简单的说,以上三个协议就是负责以下图片内容:

三个协议其实相辅相成,只是读完简单介绍其实并不能深刻理解其协议的深刻内涵或者使用方法以及其架构。下面我们对其协议进行详细拆分深刻挖掘。

RTP详解

背景知识:

流(Streaming)是近年在Internet上出现的新概念,其定义非常广泛,主要是指通过网络传输多媒体数据的技术总称。

流式传输分为两种

    • 顺序流式传输 (Progressive Streaming)
    • 实时流式传输 (Real time Streaming)

实时流式传输是实时传送,特别适合现场事件。“实时”(real time)是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系,这需要相应的协议支持,这样RTP和RTCP就相应的出现了

RTP协议原理:

较简单,负责对流媒体数据进行封包并实现媒体流的实时传输,即它按照RPT数据包格式来封装流媒体数据,并利用与它绑定的协议进行数据包的传输。

RTP在端口号1025到65535之间选择一个未使用的偶数UDP端口号,而在同一次会话中的RTCP则使用下一个基数UDP端口号。RTP默认端口号5004,所以RTCP端口号默认为5005,姊妹协议背景有说。

从下图可看出RTP被划分在传输层,它建立在UDP上。同UDP协议一样,为了实现其实时传输功能,RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步,但并不保证服务质量。服务质量由RTCP来提供。

RTP协议封装

详细见下:

  • 填充位(1bit)若p=1则在该报文的尾部填充一个或多个额外的八位组,它们不是有效载荷的一部分。填充可能用于某些具有固定长度的加密算法或者用在底层数据单元中传输多个RTP包
  • 扩展(X):1个比特,置“1”表示RTP报头后紧随一个扩展报头
  • 参与源数(CSRC计数(CC) )4位,CSRC计数包括紧接在固定头后CSRC标识符个数。
  • 标记(M):1个比特,其具体解释由应用文档来定义。例如,对于视频流,它表示一帧的结束,而对于音频,则表示一次谈话的开始
  • 有效载荷类型,7个比特,它指示在用户数据字段中承载数据的载荷类别,记录后面资料使用哪种编码,接收端找出相应的 decoder 解码出来。

音频:μ律PCM(0),GMS(3)

A律PCM(8),G.722(9),G728(1)

视频:活动JPEG(26)、H.261(31)、

MPEG1(32)、MPEG2(33)等

  • 序列号16比特 每发送一个RTP数据包,序列号加一,接收机可以据此检测包损和重建包序列.序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做),对加密算法泛知的普通文本攻击也会更加困难
  • 时间戳,32位,时标反映RTP数据包中第一个八进制数的采样时刻,采样时刻必须从单调、线性增加的时钟导出,以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。 只有系列号而没有时标,并不能完整按照顺序的将data播放出来,因为如果data中间有一段是没有资料的,只有系列号的话会造成错误.
  • SSRC ,32位,SSRC段标识同步源。此标识不是随机选择的,目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低,所有RTP实现都必须探测并解决冲突。
  • CSRC列表,0到15项,每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源,也仅标识15个。

RTCP协议详解

RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。RTCP有如下五种分组类型。

RTCP协议详细拆解:

1、SR:

发送端报告包,用于发送和接收活动源的统计信息;

发送端报告分组SR(Sender Report)用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有:相应的RTP流的SSRC,RTP流中最新产生的RTP分组的时间戳和NTP,RTP流包含的分组数,RTP流包含的字节数。SR包的封装如下图所示:

  • 版本(V):同RTP包头域。
  • 填充(P):同RTP包头域
  • 接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。
  • 包类型(PT):8比特,SR包是200。

  • 长度域(Length):16比特,其中存放的是该SR包以32比特为单位的总长度减一。
  • 同步源(SSRC of sender):SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。
  • NTP Timestamp(Network time protocol)SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。
  • RTP Timestamp:与NTP时间戳对应,与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。
  • Sendr’s packet count:从开始发送包到产生这个SR包这段时间里,发送者发送的RTP数据包的总数. SSRC改变时,这个域清零。
  • Sender`soctet count:从开始发送包到产生这个SR包这段时间里,发送者发送的净荷数据的总字节数(不包括头部和填充)。发送者改变其SSRC时,这个域要清零。
  • 同步源n的SSRC标识符:该报告块中包含的是从该源接收到的包的统计信息。
  • 丢失率(Fraction Lost):表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。
  • 累计的包丢失数目:从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。
  • 收到的扩展最大序列号:从SSRC_n收到的RTP数据包中最大的序列号,
  • 接收抖动(Interarrival jitter):RTP数据包接受时间的统计方差估计
  • 上次SR时间戳(Last SR,LSR):取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包,则该域清零。
  • 上次SR以来的延时(Delay since last SR,DLSR):上次从SSRC_n收到SR包到发送本报告的延时。

2、RR:

接收者报告包,用于接收非活动站的统计信息;

3、SDES:

源描述包,用于报告和站点相关的信息,包括CNAME;

4、BYE:

断开RTCP包,是站点离开系统的报告,表示结束;

5、APP:

应用特定函数。

RTP&&RTCP的协议关键技术

时间戳

时间戳字段是RTP首部中说明数据包时间的同步信息,是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间,要求发送方时间戳的时钟是连续、单调增长的,即使在没有数据输入或发送数据时也是如此。在静默时,发送方不必发送数据,保持时间戳的增长,在接收端,由于接收到的数据分组的序号没有丢失,就知道没有发生数据丢失,而且只要比较前后分组的时间戳的差异,就可以确定输出的时间间隔。

RTCP 中的 SR (Sender Report发送端报告)控制分组包含NTP(网络时间)时间戳和RTP时间戳可用于同步音视频媒体流。

RTP时间戳是依据邻近的RTP数据包中的时间戳结合NTP时间差得到的。

公式表达为:RTP_tsi = tsi + NTPi - NTP'i

RTP_tsi表示RTCP中的RTP时间戳;tsi表示邻近的RTP包中的时间戳;NTPi表示RTCP的网络时间戳;NTP'i表示邻近的RTP包对应的网络时间戳;下标表示第i个源

因此,i和源j之间的相对时差可以表示为

(RTP_tsi – tsi)-( RTP_tsj - tsj) = (NTPi –NTP'i) - (NTPj—NTP'j)

由于NTP同步,差值可以反映出两个源的相对时差。因为要同步不同来源的媒体流,必须使得同步他们的绝对时间基准,而NTP时间戳正是这样的绝对时间基准。应用RTP时间戳来保证同一来源的媒体流同步

时延:

影响时延的因素有多个方面:

      • 编解码
      • 网络
      • 防抖动缓冲
      • 报文队列

其中有些是固定时延,如编解码网络速率等;有些是变化的,如防抖动缓冲等,固定的时延可以通过改变编解码方式和提高网络速率来改变,而变化时延通常采用提高转发效率来提高。

抖动

到达时刻抖动J的定义:一对包中接收机相对发射机的时间跨度差值的平均偏差。

该值等于两个包相对传输时间的差值,相对传输时间是指包的RTP时间标志和到达时刻接收机时钟,以同一单位的差值.若Si是包i的RTP时间标志,Ri是包i以RTP时间标志单位的到达时刻值。对于两个包i和j,D可以表达为

D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)

到达时刻抖动可以在收到从源SSRC_n来的每个数据包i后连续计算,利用该包和前一包i-1的偏差D。

根据公式J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16计算

丢包率

丢包率是通过计算接收包数量和发送包数量的比率得到。
发送方:每间隔一定时间读取每个发送通道的发包数量和数据长度,组成一个此通道的RTCP报文发送给接收方,同时将发送数据包计数清零。
接收方:收到RTCP包后,读取接收通道接收到的包数量,并计算出丢包率,通过一个RTCP接收汇报包发送给发送方,同时对接收数据包计数清零

RTSP协议:

RTSP(Real-Time Stream Protocol)协议是一个基于文本的多媒体播放控制协议,属于应用层。RTSP以客户端方式工作,对流媒体提供播放、暂停、后退、前进等操作。该标准由IETF指定,对应的协议是RFC2326。RTSP作为一个应用层协议,提供了一个可供扩展的框架,使得流媒体的受控和点播变得可能,它主要用来控制具有实时特性的数据的发送,但其本身并不用于传送流媒体数据,而必须依赖下层传输协议(如RTP/RTCP)所提供的服务来完成流媒体数据的传送。RTSP负责定义具体的控制信息、操作方法、状态码,以及描述与RTP之间的交互操作。RTSP媒体服务协议框架如下:

所以从上述架构图中可以看出,RTSP和RTP,RTCP配合使用。RTSP传输的一般是TS、MP4格式的流,其传输一般需要2~3个通道,命令和数据通道分离。使用RTSP协议传输流媒体数据需要有专门的媒体播放器和媒体服务器,也就是需要支持RTSP协议的客户端和服务器。

客户端要播放RTSP媒体流,就需要知道媒体源的URL,RTSP的URL格式一般如下:

rtsp://host[:port]/[abs_path]/content_name

host: 有效的域名或IP地址;

port: 端口号,缺省为554,若为缺省可不填写,否则必须写明。

例如,一个完整的RTSP URL可写为:

rtsp://192.168.1.67:554/test

又如目前市面上常用的海康网络摄像头的RTSP地址格式为:

rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[subtype]/av_stream

示例rtsp://admin:12345@192.168.1.67:554/h264/ch1/main/av_stream

RTSP是一种基于文本的协议,用CRLF(回车换行)作为每一行的结束符,其好处是,在使用过程中可以方便地增加自定义参数,也方便抓包分析。从消息传送方向上来分,RTSP的报文有两类:请求报文和响应报文。请求报文是指从客户端向服务器发送的请求(也有少量从服务器向客户端发送的请求),响应报文是指从服务器到客户端的回应。RTSP请求报文的常用方法与作用:

一次基本的RTSP交互过程如下,C表示客户端,S表示服务端。

首先客户端连接到流媒体服务器并发送一个RTSP描述请求(DESCRIBE request),服务器通过一个SDP(Session DescriptionProtocol)描述来进行反馈(DESCRIBEresponse),反馈信息包括流数量、媒体类型等信息。客户端分析该SDP描述,并为会话中的每一个流发送一个RTSP连接建立请求(SETUPrequest),该命令会告诉服务器用于接收媒体数据的端口,服务器响应该请求(SETUP response)并建立连接之后,就开始传送媒体流(RTP包)到客户端。在播放过程中客户端还可以向服务器发送请求来控制快进、快退和暂停等。最后,客户端可发送一个终止请求(TEARDOWN request)来结束流媒体会话。

而实际使用中还会用到两个协议,SIP 和SDP

SIP协议

SIP(Session Initiation Protocol,会话初始协议)是由IETF(Internet Engineering Task Force,因特网工程任务组)制定的多媒体通信协议。

它是一个基于文本的应用层控制协议,用于创建、修改和释放一个或多个参与者的会话。SIP 是一种源于互联网的IP 语音会话控制协议,具有灵活、易于实现、便于扩展等特点。SIP协议用于两个或多个端点之间的互联网电话和多媒体分发。例如,一个人可以使用SIP发起对另一个人的电话呼叫,或者有人可以与许多参与者建立电话会议。SIP协议的设计非常简单,配置有限的命令。它也是基于文本的,所以任何人都可以读取SIP会话中的端点之间传递的SIP消息。

有一些实体帮助SIP创建其网络。在SIP中,每个网元由SIP URI(统一资源标识符)来标识,它像一个地址。以下是网络元素

  • 用户代理
  • 代理服务器
  • 注册服务器
  • 重定向服务器
  • 位置服务器

用户代理

它是SIP网络的端点和最重要的网络元素之一。端点可以启动,修改或终止会话。用户代理是SIP网络中最智能的设备或网络元件。它可以是软电话,手机或笔记本电脑。

用户代理在逻辑上分为两部分 -

  • 用户代理客户端(UAC) - 发送请求并接收响应的实体。
  • 用户代理服务器(UAS) - 接收请求并发送响应的实体。

SIP基于客户机 - 服务器架构,其中呼叫者的电话充当发起呼叫的客户端,被叫方的电话充当响应呼叫的服务器。

代理服务器

网络元素接收来自用户代理的请求并将其转发给另一个用户。

  • 基本上代理服务器的作用就像一个路由器。
  • 它有一些智慧来了解SIP请求,并在URI的帮助下发送它。
  • 代理服务器位于两个用户代理之间。
  • 源和目的地之间最多可以有70个代理服务器。

有两种类型的代理服务器 -

  • 无状态代理服务器 - 它只是转发收到的消息。这种类型的服务器不存储任何呼叫或交易的信息。
  • 有状态代理服务器 - 这种类型的代理服务器可以跟踪收到的每个请求和响应,并且如果需要,可以将来使用它。如果对方没有响应,它可以重新发送请求。

注册服务器

注册服务器接受用户代理的注册请求。它可以帮助用户在网络中进行身份验证。它将URI和用户的位置存储在数据库中,以帮助同一域内的其他SIP服务器。

看看下面的示例,显示SIP注册的过程。

这里呼叫者想要向TMC域注册。因此,它向TMC的Registrar服务器发送REGISTER请求,并且服务器在授权客户端时返回200 OK响应。

重定向服务器

重定向服务器接收请求,并在注册器创建的位置数据库中查找请求的预期收件人。重定向服务器使用数据库获取位置信息,并以3xx(重定向响应)响应给用户。我们将在本教程的后面讨论响应代码。

位置服务器

位置服务器提供有关呼叫者可能的位置到重定向和代理服务器的信息。只有代理服务器或重定向服务器可以联系位置服务器。

下图描绘了每个网络元素在建立会话中所扮演的角色。

SIP - 系统架构

SIP被构造为分层协议,这意味着其行为根据一组相当独立的处理阶段来描述,只有每个阶段之间的松散耦合。

  • SIP的最低层是其语法和编码。其编码使用增强的Backus-Naur表格语法(BNF)来指定。
  • 第二层是传输层。它定义客户端如何发送请求并接收响应,以及服务器如何接收请求并通过网络发送响应。所有SIP元素都包含传输层。
  • 接下来是事务层。事务是由客户端事务(使用传输层)发送到服务器事务的请求,以及从服务器事务发送回客户端的对该请求的所有响应。用户代理客户端(UAC)完成的任何任务都将使用一系列事务进行。无状态代理不包含事务层。
  • 事务层上面的称为事务用户。除了无状态代理之外,每个SIP实体都是一个事务用户。

下图显示了SIP会话的基本呼叫流程。

以下是对上述呼叫流程的逐步说明 -

  • 发送到代理服务器的INVITE请求负责启动会话。
  • 代理服务器发送100 尝试立即响应呼叫者(Alice)以停止INVITE请求的重新发送。
  • 代理服务器在位置服务器中搜索Bob的地址。获取地址后,进一步转发INVITE请求。
  • 此后,Bob手机生成的180 振铃(临时响应)返回给爱丽丝。
  • 鲍勃拿起手机后一个200 OK响应很快产生。
  • 一旦200 OK到达Alice,Bob 从Alice 收到一个ACK。
  • 同时,会话建立,RTP数据包(会话)从两端开始流动。
  • 会话结束后,任何参与者(Alice或Bob)都可以发送一个BYE请求来终止会话。
  • BYE直接从Alice到Bob绕过代理服务器。
  • 最后,Bob发送200 OK响应来确认BYE,会话终止。
  • 在上述基本呼叫流程中,可以使用三个事务(标记为1,2,3)。

完整的呼叫(从INVITE到200 OK)称为对话Dialog

上述的架构中可以看出是SIP在先,RTP在后。下面再说一下SDP协议

SDP协议

SDP(Session Description Protocol)是一个用来描述多媒体会话的应用层控制协议,它是一个基于文本的协议,用于会话建立过程中的媒体类型和编码方案的协商等。

Sdp是描述一个会话时SIP消息正文是一个会话描述协议

SDP消息,消息正文格式:

v=0

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

s=SDP Seminar

i=A Seminar on the session description protocol

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps

e=mjh@isi.edu (Mark Handley)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

m=audio 3458 RTP/AVP 0 96 97

a=rtpmap:0 PCMU

a=rtpmap:96 G726-32/8000

a=rtpmap:97 AMR-WB

m=video 3400 RTP/AVP 98 99

a=rtpmap:98 MPV

a=rtpmap:99 H.261

v=0//该行指示协议的版本。

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

0行中包含与会话所有者有关的参数

第一个参数表明会话发起者的名称,该参数可不填写,如填写和SIP消息中,from消息头的内容一致。

第二个参数为主叫方的会话标识符。

第三个参数为主叫方会话的版本,会话数据有改变时,版本号递增。

第四个参数定义了网络类型,IN表示Internet网络类型,目前仅定义该网络类型。

第五个参数为地址类型,目前支持IPV4和IPV6两种地址类型。

第六个参数为地址:表明会话发起者的IP地址,该地址为信令面的IP地址,信令PDP激活时为手机分配。

s=SDP Seminar //表明本次会话的标题,或会话的名称。

i=A Seminar on the session description protocol//会话的描述

u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps//会话的URI,通过该地址可以查阅到会话的更多内容。

e=mjh@isi.edu (Mark Handley)//会话责任人的EMIAL地址

c=IN IP4 224.2.17.12/127

C行包含为多媒体会话而建立的连接的信息,其中指出了真正的媒体流使用的IP地址。

第一个参数为网络类型,目前仅定义INTERNET网络类型。用“IN”表示。

第二个参数为地址类型,目前支持两种地址类型:IPV4和IPV6。

第三个参数为地址,该地址为多媒体流使用的IP地址。

t=2873397496 2873404696//表示会话的开始时间和结束时间。

第一个参数表明会话的开始时间,数字表明从1900年1月1日00:00以来所经过的秒数。

第二个参数表明会话的结束时间,数字表明从1900年1月1日00:00以来所经过的秒数。

m=audio 3458 RTP/AVP 0 96 97

m行又称媒体行,描述了发送方所支持的媒体类型等信息。

第一个参数为媒体名称:表明支持音频类型。

第二个参数为端口号,表明UE在本地端口为3458上发送音频流。

第三个参数为传输协议,一般为RTP/AVP协议。

四-七参数为所支持的四种净荷类型编号。

a=rtpmap:0 PCMU

a=rtpmap:96 G726-32/8000

a=rtpmap:97 AMR-WB

a行为媒体的属性行,以属性的名称:属性值的方式表示。

格式为:a=rtpmap:<净荷类型><编码名称>

净荷类型0固定分配给了PCMU,

净荷类型96对应的编码方案为G.726,为动态分配的。

净荷类型97对应的编码方式为自适应多速率宽带编码(AMR-WB),为动态分配的。

m=video 3400 RTP/AVP 98 99

m行又称媒体行,描述了发送方所支持的媒体类型等信息。

第一个参数为媒体名称:表明支持视频类型。

第二个参数为端口号,表明UE在本地端口为3400上发送视频流。

第三个参数为传输协议,一般为RTP/AVP协议。

四、五参数给出了两种净荷类型编号

格式为:a=rtpmap:<净荷类型><编码名称>

a=rtpmap:98 MPV

a=rtpmap:99 H.261

净荷类型98对应的编码方案为MPV,为动态分配的。

净荷类型97对应的编码方式为H.261,为动态分配的。

总结理解

其实挺烦的!!!大家没必要纠结这么细节的东西,协议终归是协议。协议里面的字段细节不必追究,但是大概使用流程应该清楚。SIP SDP RTSP RTP RTCP,就像他们出现的顺序一样,他们在实际应用中的启用也是这个顺序: SIP(一般基于tcp)用于设备或用户(准确的说是 Internet endpoints)地址管理、设备发现并初始化一个Session,并负责传输SDP包;而SDP(是一个资源描述协议,与传输无关,大多数时候只能包含到其它协议中作为资源描述,更像是一个规范)包中描述了一个Session中包含哪些媒体数据,邀请的人等等;当需要被邀请的人都通过各自的终端设备被通知到后,就可以使用RTSP(串流协议,一般基于tcp传送,主要作用是使用sdp来描述流而非设备的信息)来控制特定Media的通信; 最后,若RTSP控制信息要求开始Video的播放,那么就开始使用 RTP(或者TCP)实时传输数据,

本文很多内容来自互联网整理,后续会继续学校live555开源项目,它是一个为流媒体提供解决方案的跨平台的C++开源项目,它实现了对标准流媒体传输是一个为流媒体提供解决方案的跨平台的C++开源项目,它实现了对标准流媒体传输协议如RTP/RTCP、RTSP、SIP等的支持。

作者水平比较菜,欢迎提建议审核,thanks~

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值