美文网首页
RTSP协议简析及抓包分析

RTSP协议简析及抓包分析

作者: 神迹12 | 来源:发表于2023-07-30 09:26 被阅读0次

RTSP协议栈

rtsp流媒体协议其实主要涉及到4种协议：RTP、RTCP、RTSP、SDP。典型流媒体框架体系参考如下图：


image.png

RTSP协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。

RTP

RTP(Real Time Transport Protocol)是针对Internet上多媒体数据流的一个传输协议。, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

RTCP

RTCP(Real Time Contorl Protocol)负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。

RTSP

RTSP( Real Time Streaming Protocol，RFC2326)，实时流传输协议，是TCP/IP协议体系中的一个应用层协议。协议主要规定定了一对多应用程序如何有效地通过IP网络传送多媒体数据，并允许同时多个串流需求控制。RTSP体系结位于RTP和RTCP之上（RTCP用于控制传输，RTP用于数据传输），使用TCP或UDP完成数据传输。承载RTSP的传输层协议为TCP，默认端口554。
交互流程图如下：


image.png

wireshark抓包图如下：


image.png
Options：客户端向服务器端发送OPTIONS，请求可用的方法。服务器端回复客户端，消息中包含当前可用的方法。截图中可看到支持的方法包括：OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER。截图中发送了2次OPTIONS，是因为用户鉴权问题。
DESCRIBE：客户端向服务器请求媒体描述文件。服务器回复客户端sdp文件，该文件告诉客户端服务器有哪些音视频流，有什么属性，如编解码器信息，帧率等。
SETUP：客户端向服务器端发起建立连接请求，请求建立会话连接，准备开始接收音视频数据，请求信息描述了期望音视频数据包基于UDP还是TCP传输，指定了RTP，RTCP端口，以及是单播还是组播等信息。

服务器端收到客户端请求后，根据客户端请求的端口号确定发送控制数据的端口以及音视频数据的端口。一个setup只能给一种媒体源建立流传输通道。
PLAY：客户端向服务端请求播放媒体。服务器回复客户端200 OK! 之后开始通过SETUP中指定的端口开始发送数据。PLAY消息会在range中指定媒体的播放时间，服务器在接到PLAY消息后会由range中指定的开始点开始发送媒体数据直到range中指定的结束点。

Wireshark抓包详解

抓包过滤方式：rtsp or rtp or rtcp
右键-->Follow -->TCP Stream，可以看到整个协议交互的流程。


image.png
image.png

OPTIONS

OPTIONS rtsp://192.168.8.169:554/Streaming/Channels/201 RTSP/1.0
CSeq: 1
User-Agent: Lavf59.16.100

RTSP/1.0 401 Unauthorized
CSeq: 1
WWW-Authenticate: Digest realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", algorithm="MD5"
WWW-Authenticate: Basic realm="/"

OPTIONS rtsp://192.168.8.169:554/Streaming/Channels/201 RTSP/1.0
CSeq: 2
User-Agent: Lavf59.16.100
Authorization: Digest username="admin", realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", uri="rtsp://192.168.8.169:554/Streaming/Channels/201", response="805c395830e56d283f4797d5eb03c5a5", algorithm="MD5"

RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN, PAUSE, SET_PARAMETER, GET_PARAMETER
Date: Mon, 17 Jul 2023 13:22:31 GMT

可以看到第一次发送OPTIONS请求，服务端返回了401。
RTSP 可以未经身份验证来访问。rtsp url直接携带明文的用户名和密码不安全，一般不使用。现在一半使用HTTP认证。
RTSP的HTTP认证有2种方式：
● 基本认证（basic authentication）是http1.0提出的认证方案，其消息传输不经过加密转换，存在严重的安全隐患
● 摘要认证（digest authentication）是http1.1提出的基本认证的替代方案，其消息经过MD5加密转换，具有更高的安全性

DESCRIBE

image.png 
RTSP/1.0 200 OK
CSeq: 3
Content-Type: application/sdp
Content-Length: 630
Date: Mon, 17 Jul 2023 13:22:31 GMT

v=0
o=- 1109162014219182 0 IN IP4 0.0.0.0
s=HIK Media Server V4.51.026
i=HIK Media Server Session Description : standard
e=NONE
c=IN IP4 0.0.0.0
t=0 0
a=control:*
b=AS:1034
a=range:npt=now-
m=video 0 RTP/AVP 96
i=Video Media
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4D0014;packetization-mode=0;sprop-parameter-sets=Z00AH42NQCgC3QgAAEZQAAr8gCA=,aO44gA==
a=control:trackID=video
b=AS:1024
m=audio 0 RTP/AVP 0
i=Audio Media
a=rtpmap:0 PCMU/8000
a=control:trackID=audio
b=AS:10
a=Media_header:MEDIAINFO=494D4B48020100000400000110710110401F000000FA000000000000000000000000000000000000;
a=appversion:1.0

服务端对DESCRIBE的请求回复中包含了媒体信息，媒体信息包含在了SDP描述信息中。如上图所示：视频编码格式为H264，音频编码格式为PCMU。
SDP描述中可以包含多个流媒体描述，每个流媒体都是以m开头，到遇到下个m为止，媒体流选择是通过媒体描述的附加属性a=control:

SDP媒体描述信息说明

SDP（Session Description Protocol）是一种会话描述协议，用于描述多媒体会话的参数。它是一种文本协议，通常用于VoIP（Voice over Internet Protocol）和视频会议等应用中。SDP协议定义了一种标准的格式，用于描述会话的各种参数，包括媒体类型、媒体格式、媒体地址等。
SDP媒体描述极其扩展属性，在不同的协议中有定义有所不同，需要参照不同协议的协议规范来看，这里介绍的是比较通用的定义，以RTSP协议中SDP的媒体描述定义。媒体描述扩展属性中有关c、b等属性不在做介绍，主要介绍m极其扩展属性a=control\a=rtpmap\a=fmtp进行详细介绍。

m属性介绍

m属性的格式如下：

m=<media> <port> <proto> <fmt> ...

实例如下：

m=video 0 RTP/AVP 96

每个字段代表的含义如下：
media：媒体类型，目前应用到的有video/audio/application等表示视频/音频/元数据等类型，根据不通协议规范，可扩展其他类型。
port：流媒体服务器发送数据的传输端口号，表示服务器从本端口发送流，0表示随机端口发送，如果是RTSP协议，一般为0，后继协议SETUP时确定传输端口。
proto：传输的协议类型， RTP/AVP表示支持UDP传输，RTP/AVP/TCP支持TCP传输，主流交互协议中，也用RTP/AVP表示既支持UDP又支持TCP。
<fmt>：媒体格式描述，RTP中用payloadtype来赋值，表示流的类型，这里会和后面"a=rtpmap:"、“a=fmtp:”相关联，具体对媒体进行描述。

a=control附加属性介绍

SDP描述中可以包含多个流媒体描述，每个流媒体都是以m开头，到遇到下个m为止，媒体流选择是通过媒体描述的附加属性a=control:来区分。如前面的

a=control:trackID=video
...
a=control:trackID=audio

a=rtpmap附加属性介绍

附加属性的格式如下：

a=rtpmap:<payload type><encoding name>/<clock rate>[/<encodingparameters>]

实例如下：

a=rtpmap:96 H264/90000

详解如下：
payloadtype:负载类型在多路复用技术中表示一个流通道，这里与媒体信息中的fmt对应
扩展描述媒体打包信息
encodingname：编码方式，表示流的编码方式，比如H264、H265等
clock rate：采样的时钟频率，这里视频流一般为90000，如果为RTP流，时钟频率将作为RTP帧间隔的衡量，例如帧间隔为40ms，则RTP包的时间戳间隔为（40/1000）*90000=3600

a=fmtp附加属性介绍

附件属性的格式，H264和H265有一定的区别，这里分开来说明，首先看下H264格式

a=fmtp:<payload type> profile-level-id=<xxx>; packetization-mode=1;sprop-parameter-sets=xxx,xxx

profile-level-id：为三个十六进制表示的字节，第一个字节表示profile_idc（编码规格），第二个字节表示profile-iop，第三个字节表示level_idc编码等级，profile_idc一般有三个取值0x42(66)-baseline profile,0x4D(77)-main profile,0x58(88)-extened profile;profile-iop, 0x64(100)-high profile;
packetization-mode：表示封装方式，0或不存在时, 必须使用单一NALU 单元模式；1-必须使用非交错(non-interleaved)封包模式；2-必须使用交错(interleaved)封包模式，一般采用非交错模式。

SETUP

SETUP rtsp://192.168.8.169:554/Streaming/Channels/201/trackID=audio RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=19848-19849
CSeq: 5
User-Agent: Lavf59.16.100
Session: 1634076345
Authorization: Digest username="admin", realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", uri="rtsp://192.168.8.169:554/Streaming/Channels/201/trackID=audio", response="d0386129e2de040df32acb7893bdf0ee", algorithm="MD5"

RTSP/1.0 200 OK
Session: 1634076345;timeout=60
Transport: RTP/AVP/UDP;unicast;client_port=19848-19849;server_port=62360-62361;ssrc=616606ba
CSeq: 5
Accept-Ranges: NPT
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0
Date: Mon, 17 Jul 2023 13:22:31 GMT

SETUP指令指定某个媒体流要如何传输，每一个流需要一个SETUP命令，视频流一个SETUP，音频流一个SETUP。
重点看一下Transport：
RTP/AVP：表示RTP通过UDP发送；RTP/AVP/TCP则表示RTP通过TCP发送
unicast：表示单播，如果是multicast则表示多播
client_port=54492-54493：由于这里希望采用的是RTP OVER UDP，所以客户端发送了两个用于传输数据的端口，客户端已经将这两个端口绑定到两个udp套接字上，9848表示是RTP端口，19849表示RTCP端口(RTP、RTCP端口成对出现，RTP端口为某个偶数，RTCP端口为RTP端口+1)。
服务端回复setup时，将会生成一个session ID.后续消息必须带有此Session字段。可以通过查看视频、音频的sesseionID，确定两个媒体流是否共享同一个会话。

PLAY方法

PLAY rtsp://192.168.8.169:554/Streaming/Channels/201 RTSP/1.0
Range: npt=0.000-
CSeq: 6
User-Agent: Lavf59.16.100
Session: 1634076345
Authorization: Digest username="admin", realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", uri="rtsp://192.168.8.169:554/Streaming/Channels/201", response="d422b155bd6516dad0d5b2faa3632b20", algorithm="MD5"

RTSP/1.0 200 OK
Session: 1634076345
CSeq: 6
Date: Mon, 17 Jul 2023 13:22:31 GMT

GET_PARAMETER rtsp://192.168.8.169:554/Streaming/Channels/201 RTSP/1.0
CSeq: 7
User-Agent: Lavf59.16.100
Session: 1634076345
Authorization: Digest username="admin", realm="ed7d7cc54ddef26fc9b44484", nonce="13a518147", uri="rtsp://192.168.8.169:554/Streaming/Channels/201", response="9b5ff41796895b08b6d87296b2857a64", algorithm="MD5"

RTSP/1.0 200 OK
CSeq: 7
Date: Mon, 17 Jul 2023 13:23:01 GMT

PLAY方法会再range中指定媒体的播放时间。PLAY可带有scale和speed字段用于点播速度控制。对于实时流range一般为Range: npt=0.000。

TEARDOWN

结束流传输，同时释放与之相关的资源，TEARDWON之后，整个RTSP连接也就结束了。TEARDOWN中发送的字段Session为之前SETUP请求后服务端返回的session字段的值，用于表示此次会话连接。

RTP包格式分析

服务端回复PLAY消息之后，客户端就开始向服务端推流。通过RTP协议传输音视频流。
RTP包由RTP header和RTP payload2部分组成。


image.png

每个字段的含义如下：
V：RTP协议的版本号，占2位，当前协议版本号为2。
P：填充标志，占1位，如果P=1，则在该报文的尾部将填充一个或多个额外的八位组，它们不是有效载荷的一部分。
X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。
CC：CSRC计数器，占 4位，指示CSRC 标识符的个数，因此CSRC数量最多为15。主要用于多流组合传播。
M: 标记，占1位，不同的有效载荷有不同的含义。当多个RTP包携带1帧数据时，前面的RTP包的marker标志设置为0，最后一个RTP包marker标志设置为1。
PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等。
序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。
时戳 (Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源，当数量超过15时，仅识别15个。
扩展头(Extension Header)：可选。
载荷(PayLoad)：真正要传输的数据，比如音频或者视频数据。
视频抓包结构如下图所示：


image.png

RTP payload type取值及含义解释

image.png

上表中列出了一些常用的音视频负载类型，还有些负载类型由于诞生的较晚，没有具体的PT值，只能使用动态（dynamic）PT值，即96到127，这就是为什么普遍指定H264的PT值为96。

视频/音频RTP区别及解析

Wireshark操作：

  1. 右键，选中一个RTP包，选择【Decode As】。


    image.png

  2. 在弹出框中，添加如下：


    image.png

  3. 前后区别
    未设置前，Payload还是


    image.png

    设置后，可以看到前2个包是SPS和PPS。


    image.png
    SPS即Sequence Paramater Set，又称作序列参数集。SPS中保存了一组编码视频序列(Coded video sequence)的全局参数。所谓的编码视频序列即原始视频的一帧一帧的像素数据经过编码之后的结构组成的序列。而每一帧的编码后数据所依赖的参数保存于图像参数集中。一般情况SPS和PPS的NAL Unit通常位于整个码流的起始位置。
    但在某些特殊情况下，在码流中间也可能出现这两种结构，主要原因可能为：
    1、解码器需要在码流中间开始解码；

    2、编码器在编码的过程中改变了码流的参数（如图像分辨率等）；
    SPS包含如下信息Sequence Paramater Set，又称作序列参数集profile_idc：标志是baseline profile(基准档次)、main profile、extended profilelevel_idc：编码的Level定义了某种条件下的最大视频分辨率、最大视频帧率等参数max_num_ref_frames：用于表示参考帧的最大数目。pic_width_in_mbs_minus1：用于计算图像的宽度。单位为宏块个数，因此图像的实际宽度为:frame_width = 16 × (pic_width_in_mbs_minus1 + 1);pic_height_in_map_units_minus1：用于计算图像的高度。
    PPS包含的信息图像参数集Picture Paramater Set(PPS)entropy_coding_mode_flag：熵编码模式标识num_slice_groups_minus1：表示某一帧中slice group的个数weighted_bipred_idc：表示在B Slice中加权预测的方法constrained_intra_pred_flag：若该标识为1，表示I宏块在进行帧内预测时只能使用来自I和SI类型宏块的信息；若该标识位0，表示I宏块可以使用来自Inter类型宏块的信息。

I帧数据开始、结束

开始和结束，RTP头中的Marker分别为false和true。


image.png
image.png

同一帧的timestamp时间戳是相同的。

H.264的RTP负载格式

RTP Payload有很多形式，可以传输编码的数据如视频H264、H265、音频G711、OPUS等数据，也可以传输封装好的数据，如GB28181中常用的PS流等。
由于H264帧大小差别较大，较小的帧小于MTU，则可单包直接发送，或者多帧组合发送，当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包了，比如H264的I帧。
H264 Payload定义了三种不同的基本的负载结构。
○ Single NAL Unit Packet(单个NAL单元数据包)
○ Aggregation Packet(聚合数据包)
○ Fragmenttation Unit(分片单元FU)
单一NAL单元：对于H264 NALU的长度小于MTU的包, 一般采用单一NAL单元模式。
打包时去除"00 00 01" 或 "00 00 00 01"的H264 NALU开始码, 把其他数据封装到RTP负载即可。
接收端可以通过RTP Payload的第一个字节来识别它们。


image.png

● F：在规范中规定了这一位必须为0.
● NRI：取00~11，表示这个NALU的重要性，如00的NALU解码器可以丢弃它而不影响图像的回放.
● Type：这个NALU单元的类型，具体如下：
1-23 NAL unit 单一NAL单元
24 STAP-A 单一时间的组合包模式A
25 STAP-B 单一时间的组合包模式B
26 MTAP16 多个时间的组合包模式A
27 MTAP24 多个时间的组合包模式B
28 FU-A 分片的单元模式A
29 FU-B 分片的单元模式B
RTP包中接收的264包是不含有0x00,0x00,0x00,0x01头的，这部分是rtp接收以后，另外再加上去的，解码的时候再做判断的。
对于FU的分片模式：
RTP头部之后的第一个字节为 FU indicator，第二个字节为 FU header。

image.png
这两个字节之后跟的是NALU的数据。

NAL Header(8位----二进制位) 的组成为：
forbidden_zero_bit(1bit) + nal_ref_idc(2bit) + nal_unit_type(5bit)
nal_ref_idc: 值越大，代表越重要。

Wireshark保存音视频裸流

视频裸流保存

导出H264、H265需要2个lua的wireshark插件。

image.png
重新打开wireshark，在上方菜单栏点击”工具“ -> Video -> Export H264 / Export H265
image.png

选择export all，然后待裸流文件生成后，点击Browser查看生成的文件。可以使用相应播放器进行播放。


image.png

参考

https://blog.csdn.net/feeltouch/article/details/82957377/
https://zhuanlan.zhihu.com/p/478736595?utm_id=0
https://blog.csdn.net/SimpleForest/article/details/129894415
https://www.pianshen.com/article/78351144335/
https://blog.51cto.com/tsingsee/2733044
https://blog.csdn.net/water1209/article/details/128982677?spm=1001.2014.3001.5502
https://blog.csdn.net/water1209/article/details/126019065
https://blog.51cto.com/u_13267193/5986939

相关文章

网友评论

      本文标题：RTSP协议简析及抓包分析

      本文链接：https://www.haomeiwen.com/subject/afsfpdtx.html

      延伸阅读

      深度阅读

      • 您也可以注册成为美文阅读网的作者，发表您的原创作品、分享您的心情！

      栏目导航

      热点阅读

      关于我们|服务条款|联系我们|RTSP协议简析及抓包分析|投稿指南|网站地图|RSS订阅|排版工具|手机版

      提供经典美文摘抄,优美散文欣赏,现代诗歌精选,短篇小说,心情随笔,表白情书范文,故事会在线阅读欣赏

      Copyright © 2014-2023 Haomeiwen.com All Rights Reserved. 好美文阅读网 版权所有

      备案信息：桂公网安备 45052102000051号 · 桂ICP备13007215号-3

      本站所收录作品、热点评论等信息部分来源互联网，目的只是为了系统归纳学习和传递资讯

      所有作品版权归原创作者所有，与本站立场无关，如不慎侵犯了你的权益，请联系我们告知，我们将做删除处理！