• RTSP协议


    1 前言

    RTSP协议作为音视频实时监控一个非常重要的协议,具有非常广泛的应用。RTSP由RFC 2326规范化,它允许客户端通过请求不同的媒体资源来控制流媒体服务器。RTSP是一种应用层协议,通常基于TCP连接,用于建立和控制媒体会话。这使得RTSP成为了许多实时流媒体应用的核心组成部分,包括视频会议、IP摄像头、流媒体服务器等。本文将深入探讨RTSP协议的原理、交互流程、高级用法以及如何进行抓包分析。

    2 RTSP协议

    RTSP协议定义主要是是在RFC2326规定,这是一个文本类的协议,用于控制实时的音视频流的传输协议。

    2.1 RTSP协议交互流程

    将重点讨论协议协商的过程,RTSP采用的是服务器客户端的模式,一个服务器可以承载多个客户端同时连接。这里需要注意的是服务器一直监听某个端口默认端口554。客户端发起TCP连接后即开始进行RTSP协商。下图是一个基本的RTSP协商流程:
    在这里插入图片描述

    1. OPTIONS
      客户端行为:客户端发送OPTIONS请求,以了解服务器支持哪些方法。
      服务器响应:服务器将支持的方法列表包含在响应中,这有助于客户端了解服务器的功能。
    2. DESCRIBE
      客户端行为:客户端发送DESCRIBE请求,以获取关于媒体资源的描述信息,如编码、分辨率等。
      服务器响应:服务器返回媒体资源的描述信息,通常是SDP(会话描述协议)格式,包括媒体流的属性和相关参数。
    3. SETUP
      客户端行为:客户端发送SETUP请求,用于建立媒体会话,指定传输通道,如UDP或TCP,并请求分配端口。
      服务器响应:服务器确认SETUP请求,指定了媒体流的传输通道和端口,允许客户端与服务器建立连接。
    4. PLAY
      客户端行为:客户端发送PLAY请求,以开始媒体流的播放。
      服务器响应:服务器确认PLAY请求,并启动媒体流的传输。
    5. GET_PARAMETER
      客户端行为:客户端发送GET_PARAMETER请求,以获取有关媒体会话的参数信息,如媒体流的播放状态或其他参数。
      服务器响应:服务器通常返回与GET_PARAMETER请求相关的参数信息。
    6. TEARDOWN
      客户端行为:客户端发送TEARDOWN请求,以终止媒体会话,停止播放并释放资源。
      服务器响应:服务器确认TEARDOWN请求,关闭会话并释放与媒体流相关的资源。

    2.2 RTSP媒体描述

    RTSP协商核心的流程是媒体信息的交换,主要是通过DESCRIBE请求来完成。服务器是通过SDP将媒体信息回复给客户端,这里主要是携带媒体的信息,分为音频和视频两部分。

    音频媒体描述字段:

    m=(媒体行):指定媒体类型,通常为"audio",以及用于传输媒体的协议和端口号。例如:m=audio 5004 RTP/AVP 0,表示音频流使用RTP协议在端口5004上传
    输,媒体格式为0(通常对应PCMU或G.711u编码)。
    a=rtpmap(RTP映射):指定RTP负载类型(Payload Type)和媒体格式。例如:a=rtpmap:0 PCMU/8000,表示Payload Type为0的RTP流使用PCMU编码,采样率
    为8000Hz。
    a=control(控制URL):指定控制媒体流的URL。例如:a=control:audio,表示控制音频流的URL。
    a=recvonly(只接收):指定该媒体流为只接收模式,表示该端只接收媒体,不发送。例如:a=recvonly。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    视频媒体描述字段:

    m=(媒体行):指定媒体类型,通常为"video",以及用于传输媒体的协议和端口号。例如:m=video 5006 RTP/AVP 96,表示视频流使用RTP协议在端口5006上
    传输,媒体格式为96(通常对应H.264编码)。
    a=rtpmap(RTP映射):指定RTP负载类型(Payload Type)和媒体格式。例如:a=rtpmap:96 H264/90000,表示Payload Type为96的RTP流使用H.264编码,
    时钟速率为90000。
    a=control(控制URL):指定控制媒体流的URL。例如:a=control:video,表示控制视频流的URL。
    a=recvonly(只接收):指定该媒体流为只接收模式,表示该端只接收媒体,不发送。例如:a=recvonly。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    这些字段描述了媒体流的基本信息,包括媒体类型、传输协议、端口号、编码格式、时钟速率等。这些描述对于RTSP客户端和服务器之间的媒体会话建立和控制非常重要,因为它们帮助确定如何处理媒体数据以及如何与媒体流进行交互。不同的媒体格式和参数可能会导致不同的媒体流配置。

    2.3 RTSP端口协商

    SETUP命令的主要作用是建立媒体会话的传输通道,它告知服务器客户端希望使用什么协议和端口来接收媒体流。服务器会响应SETUP请求,确认媒体会话的建立,并提供了实际的传输通道信息,以便客户端开始接收媒体流。
    音频SETUP:
    客户端:
    音频SETUP请求用于建立音频媒体会话的传输通道。以下是音频SETUP请求的一般形式:

    SETUP rtsp://server-address/audio-resource RTSP/1.0
    CSeq: [Sequence Number]
    Transport: RTP/AVP;unicast;client_port=5000-5001
    rtsp://server-address/audio-resource:指定音频资源的URL路径。
    
    • 1
    • 2
    • 3
    • 4

    Transport: RTP/AVP:这部分说明音频传输使用的协议和配置,通常为RTP/AVP,表示使用RTP传输协议。
    client_port=5000-5001:客户端指定了用于接收音频的端口范围,即5000到5001,这意味着服务器应该将音频流发送到这个端口范围。
    服务器:
    服务器将响应音频SETUP请求,确认了传输通道的建立,并提供实际的传输参数,如服务器分配的端口号。

    RTSP/1.0 200 OK
    CSeq: [与请求中的CSeq相同]
    Transport: RTP/AVP;unicast;client_port=5000-5001;server_port=6000-6001
    
    • 1
    • 2
    • 3

    视频SETUP:
    客户端:
    视频SETUP请求用于建立视频媒体会话的传输通道。以下是视频SETUP请求的一般形式:

    SETUP rtsp://server-address/video-resource RTSP/1.0
    CSeq: [Sequence Number]
    Transport: RTP/AVP;unicast;client_port=6000-6001
    rtsp://server-address/video-resource:指定视频资源的URL路径。
    
    • 1
    • 2
    • 3
    • 4

    Transport: RTP/AVP:这部分说明视频传输使用的协议和配置,通常为RTP/AVP,表示使用RTP传输协议。
    client_port=6000-6001:客户端指定了用于接收视频的端口范围,即6000到6001,这意味着服务器应该将视频流发送到这个端口范围。

    服务器:
    服务器将响应视频SETUP请求,确认了传输通道的建立,并提供实际的传输参数,如服务器分配的端口号。

    RTSP/1.0 200 OK
    CSeq: [与请求中的CSeq相同]
    Transport: RTP/AVP;unicast;client_port=6000-6001;server_port=7000-7001
    
    • 1
    • 2
    • 3

    2.4 RTSP 播放确认

    RTSP(实时流媒体传输协议)中的PLAY字段用于启动或继续媒体流的播放。它是RTSP协议的一种请求命令,通常在SETUP之后用于开始媒体流的传输。以下是PLAY字段的详细解释:
    客户端:
    PLAY命令格式:PLAY命令通常以如下的格式发送到RTSP服务器:

    PLAY rtsp://server-address/resource RTSP/1.0
    CSeq: [Sequence Number]
    Session: [Session ID]
    Range: [播放范围]
    
    • 1
    • 2
    • 3
    • 4

    rtsp://server-address/resource:这是RTSP服务器的地址和媒体资源的路径。客户端通过此URL指定要播放的资源。
    RTSP/1.0:指定了使用的RTSP协议版本。
    CSeq:用于命令序列的计数器,以确保命令的顺序性和唯一性。
    Session:在SETUP请求成功建立媒体会话后,服务器分配的会话ID,以标识正在播放的会话。
    Range:可选字段,用于指定播放的时间范围。这允许客户端进行时间范围内的媒体流播放,如跳转到某个时间点或从某个时间点开始播放。
    服务器:
    PLAY命令的响应通常遵循RTSP协议的响应格式,以确认播放操作并提供相关信息。以下是PLAY响应的一般格式:

    RTSP/1.0 200 OK
    CSeq: [与请求中的CSeq相同]
    Session: [Session ID]
    RTP-Info: [媒体信息]
    
    • 1
    • 2
    • 3
    • 4

    RTSP/1.0 200 OK:这表示服务器成功接受并处理了PLAY请求,通信正常。
    CSeq:响应中的CSeq与请求中的CSeq相同,以维护命令的顺序性。
    Session:在SETUP请求成功建立媒体会话后,服务器分配的会话ID,以标识正在播放的会话。这个会话ID是客户端和服务器之间识别会话的关键。
    RTP-Info:这是一个可选字段,它包含有关媒体流的信息,如媒体流的SSRC(同步信源标识符)和RTP序列号。这些信息可以用于帮助客户端更好地解析和处理媒体流。

    2.5 异常流程

    在RTSP(实时流媒体传输协议)中,异常流程通常涉及客户端或服务器遇到问题时,通过特定的状态码来表示错误或异常情况。以下是一些常见的RTSP状态码,用于标识异常流程的情况。状态代码的第一位数字定义了响应的类别。这最后两位数字没有任何分类作用。有 5 个
    第一个数字的值:具体状态码需要查RFC2326文档。

    1xx:信息 - 已收到请求,正在继续处理
    2xx:成功 - 操作已成功接收、理解,并接受
    3xx:重定向 - 必须采取进一步的操作才能完成请求
    4xx:客户端错误 - 请求包含错误语法或无法实现了
    5xx:服务器错误 - 服务器未能完成明显的任务有效请求
    
    • 1
    • 2
    • 3
    • 4
    • 5

    3 RTSP高级用法

    3.1 RTSP over TCP

    RTSP over TCP允许使用可靠的TCP连接来进行RTSP握手和媒体传输,与RTSP over UDP相比,具有更高的可靠性和更容易穿越防火墙和代理服务器。在协商过程中,主要差异包括TCP连接的建立,Transport字段的参数以及双工通道的使用。这种方式适用于需要可靠传输和高级控制的实时流媒体应用。RTSP over TCP采用与默认的UDP传输音视频不一样的地方是,音视频也是走服务器端口,比如是554公用一个连接进行数据的传输。协商主要是在SETUP字段上完成。
    RTSP over TCP传输格式:

    SETUP rtsp://server-address/resource/trackID RTSP/1.0
    CSeq: 3
    Transport: RTP/AVP/TCP;interleaved=[双数开始的RTP通道号]-[双数开始的RTCP通道号]
    
    • 1
    • 2
    • 3

    注意,RTSP over TCP使用Transport字段的RTP/AVP/TCP参数来指示TCP传输,而interleaved参数指示了双工通道的RTP和RTCP通道号。
    RTSP over UDP传输格式

    SETUP rtsp://server-address/video-resource RTSP/1.0
    CSeq: [Sequence Number]
    Transport: RTP/AVP;unicast;client_port=6000-6001
    
    • 1
    • 2
    • 3

    媒体数据封装,RTSP over TCP采用的是Magic头部来进行音视频数据的区分,一般第一个字节是固定的 Magic:0x24;第二个字节是指定媒体的通道,第三和第四个字节是指定RTP包的长度,一般不用,直接用Magic头进行分割。
    所描述的 “Interleaved Channel” 头部是一种特定于 RTSP over TCP 的私有协议扩展,用于标识和传输 RTP 和 RTCP 数据。这个头部的格式如下:

    第一个字节(byte 1)为 '$',通常用作 Interleaved Channel 的开始标志。
    第二个字节(byte 2)用于指示通道的 ID,其取值由 RTSP-SETUP 消息中确定。
    通常,0 表示视频的 RTP 数据,1 表示视频的 RTCP 数据,2 表示音频的 RTP 数据,3 表示音频的 RTCP 数据。
    第三和第四个字节(byte 3-4)用于指示 RTP 包的长度
    
    • 1
    • 2
    • 3
    • 4

    4 抓包分析

    rtsp协商过程中抓包分析是一个非常重要的手段,很多时候兼容性问题都需要通过wareshark进行抓包分析,首先抓包后第一步是利用流追踪将抓包转换为文本流进一步分析,下面是rtsp over tcp的一个抓包。
    在这里插入图片描述
    从抓包中可以看出,这里做了两次options操作,第一次没有携带账号密码,服务器回复了401,第二次客户端带上账号密码才协商成功。
    RTSP over TCP协商主要体现在SETUP字段。
    在这里插入图片描述
    下面是一个完整的RTSP over UDP的协商过程:
    在这里插入图片描述

    OPTIONS rtsp://192.168.88.101:554/ch0 RTSP/1.0
    CSeq: 2
    User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
    
    RTSP/1.0 200 OK
    CSeq: 2
    Date: Sun, Jun 25 2023 01:16:55 GMT
    Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER
    
    DESCRIBE rtsp://192.168.88.101:554/ch0 RTSP/1.0
    CSeq: 3
    User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
    Accept: application/sdp
    
    RTSP/1.0 200 OK
    CSeq: 3
    Date: Sun, Jun 25 2023 01:16:55 GMT
    Content-Base: rtsp://192.168.88.101/ch0/
    Content-Type: application/sdp
    Content-Length: 605
    
    v=0
    o=- 1687655781765442 1 IN IP4 192.168.88.101
    s=face recognition live
    i=LIVE555 Streaming Media v2023.05.10
    t=0 0
    a=tool:LIVE555 Streaming Media v2023.05.10
    a=type:broadcast
    a=control:*
    a=range:npt=now-
    a=x-qt-text-nam:face recognition live
    a=x-qt-text-inf:LIVE555 Streaming Media v2023.05.10
    m=video 0 RTP/AVP 96
    c=IN IP4 0.0.0.0
    b=AS:100
    a=rtpmap:96 H264/90000
    a=fmtp:96 packetization-mode=1;profile-level-id=640033;sprop-parameter-sets=Z2QAM6zoBQBbJsgAAB9AAAdTBCA=,aO48sA==
    a=control:track1
    m=audio 0 RTP/AVP 96
    c=IN IP4 0.0.0.0
    b=AS:100
    a=rtpmap:96 PCMA/8000
    a=control:track2
    SETUP rtsp://192.168.88.101/ch0/track1 RTSP/1.0
    CSeq: 4
    User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
    Transport: RTP/AVP;unicast;client_port=52624-52625
    
    RTSP/1.0 200 OK
    CSeq: 4
    Date: Sun, Jun 25 2023 01:16:55 GMT
    Transport: RTP/AVP;unicast;destination=192.168.88.171;source=192.168.88.101;client_port=52624-52625;server_port=6970-6971
    Session: 71F8DA1A;timeout=65
    
    SETUP rtsp://192.168.88.101/ch0/track2 RTSP/1.0
    CSeq: 5
    User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
    Transport: RTP/AVP;unicast;client_port=52626-52627
    Session: 71F8DA1A
    
    RTSP/1.0 200 OK
    CSeq: 5
    Date: Sun, Jun 25 2023 01:16:55 GMT
    Transport: RTP/AVP;unicast;destination=192.168.88.171;source=192.168.88.101;client_port=52626-52627;server_port=6972-6973
    Session: 71F8DA1A;timeout=65
    
    PLAY rtsp://192.168.88.101/ch0/ RTSP/1.0
    CSeq: 6
    User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
    Session: 71F8DA1A
    Range: npt=0.000-
    
    RTSP/1.0 200 OK
    CSeq: 6
    Date: Sun, Jun 25 2023 01:16:55 GMT
    Range: npt=0.000-
    Session: 71F8DA1A
    RTP-Info: url=rtsp://192.168.88.101/ch0/track1;seq=50270;rtptime=1941266457,url=rtsp://192.168.88.101/ch0/track2;seq=32464;rtptime=2232875491
    
    TEARDOWN rtsp://192.168.88.101/ch0/ RTSP/1.0
    CSeq: 7
    User-Agent: LibVLC/3.0.18 (LIVE555 Streaming Media v2016.11.28)
    Session: 71F8DA1A
    
    RTSP/1.0 200 OK
    CSeq: 7
    Date: Sun, Jun 25 2023 01:17:02 GMT
    
    
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66
    • 67
    • 68
    • 69
    • 70
    • 71
    • 72
    • 73
    • 74
    • 75
    • 76
    • 77
    • 78
    • 79
    • 80
    • 81
    • 82
    • 83
    • 84
    • 85
    • 86
    • 87
    • 88
    • 89
  • 相关阅读:
    CSRF / XSRF(跨站请求伪造),XSS/CSS(跨站脚本攻击)
    如何使用 JS 判断用户是否处于活跃状态
    匿名用户上传的Mybatis学习笔记,炸来了阿里P8,网上一片好评
    软件测试/测试开发丨Web自动化—capability参数配置 学习笔记
    mysql 事务 Repeatable Read
    Mysql 日常命令记录
    以客户为中心,CRM系统可以给企业带来哪些价值?值得一看
    纯JavaScript实现表白代码
    .NET 7 预览版2 的亮点之 NativeAOT 正式合并入 .NET 主线
    3D MINS 多模态影像导航系统
  • 原文地址:https://blog.csdn.net/qq_38731735/article/details/133838343