手撕RTSP协议系列(5)——DESCRIBE

上一篇我们介绍了RTSP的OPTION指令,客户端发起OPTION请求后,得到了RTSP服务器支持的指令。在此之后,客户端会继续向服务器发送DESCRIBE消息,来获取会话描述信息(sdp)。本篇我们来详细介绍一下DESCRIBE指令。

 

DESCRIBE的作用 

向服务器请求会话描述信息(SDP)。

 

DESCRIBE的格式

1.请求

格式:

描述:

首先用DESCRIBE描述请求类型;然后在URI中请求的服务器端地址;RTSP_VER表示RTSP的版本号,在加入\r\n消息头结束;

消息体包含以下字段:

Accept:指明接收数据的格式,如application/sdp表示接收sdp信息,之后加入\r\n表示此条目结束;

CSeq:RTSP序列号,一般DESCRIBE包在RTSP请求过程中的序列号为2,之后加入\r\n表示此条目结束;

UserAgent : 指明用户代理,由于是最后一个条目,加入两组\r\n表示结束。

我们来看一个抓包文件:

2.回复

对于DESCRIBE消息,服务端的回复有两种可能!如果需要认证,则首先返回401,并要求客户端认证,客户端再次发送包含认证信息的DESCRIBE指令,服务端收到带认证信息的DESCRIBE请求,返回sdp信息给客户端;如果不需要认证,则直接返回sdp。

需要认证的情况

服务端发送回复消息,状态码为401,状态描述为Unauhtorized(未认证);包序列号与DESCRIB请求中的序号相同;发回   WWW-Authenticate消息,告诉客户端认证所需信息;发回日期。

客户端收到该消息之后,需要再次向服务器发送DESCRIBE请求,这一次消息体要增加Authorization字段,realm和nonce填上一步服务器返回的WWW-Authenticate消息,如下图:

服务端收到带认证信息的DESCRIBE请求之后,如果信息正确,则会回复200 ok的消息,同时返回sdp信息!格式如下图:

此时返回的状态码为200,状态描述为OK,包序列号与DESCRIBE请求的序号相同,表示对该请求的回复;

Content-type表示回复内容类型,值为application/sdp;

Cotent-Base:一般用RTSP URI表示;

Content-length表示返回的sdp信息的长度 。

接下来是sdp,具体的描述这里就不赘述了,可以详细查阅之前的sdp格式详解一篇。

 

抓包文件 

服务端返回的401:

客户端再次发送带认证信息的DESCRIBE消息:

服务端返回的sdp信息

 

案例 

 

第一次DESCRIBE请求:

DESCRIBE rtsp://192.17.1.63:554 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf58.42.100

 

 

服务端回复的401消息:

RTSP/1.0 401 Unauthorized
CSeq: 2
WWW-Authenticate: Digest realm="IP Camera(23306)", nonce="a946c352dd3ad04cf9830d5e72ffb11e", stale="FALSE"
Date: Fri, Apr 10 2020 19:07:19 GMT

 

 

第二次DESCRIBE请求

DESCRIBE rtsp://192.17.1.63:554 RTSP/1.0
Accept: application/sdp
CSeq: 3
User-Agent: Lavf58.42.100
Authorization: Digest username="admin", realm="IP Camera(23306)", nonce="a946c352dd3ad04cf9830d5e72ffb11e", uri="rtsp://192.17.1.63:554", response="8f1987b6da1aeb3f3744e1307d850281"

 

验证OK消息

RTSP/1.0 200 OK
CSeq: 3
Content-Type: application/sdp
Content-Base: rtsp://192.17.1.63:554/
Content-Length: 712


v=0
o=- 1586545639954157 1586545639954157 IN IP4 192.17.1.63
s=Media Presentation
e=NONE
b=AS:5100
t=0 0
a=control:rtsp://192.17.1.63:554/
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=recvonly
a=x-dimensions:1920,1080
a=control:rtsp://192.17.1.63:554/trackID=1
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=420029; packetization-mode=1; sprop-parameter-sets=Z01AKI2NQDwBE/LgLcBAQFAAAD6AAAw1DoYACYFAABfXgu8uNDAATAoAAL68F3lwoA==,aO44gA==
m=audio 0 RTP/AVP 8
c=IN IP4 0.0.0.0
b=AS:50
a=recvonly
a=control:rtsp://192.17.1.63:554/trackID=2
a=rtpmap:8 PCMA/8000
a=Media_header:MEDIAINFO=494D4B48010300000400000111710110401F000000FA000000000000000000000000000000000000;
a=appversion:1.0

 

DESCRIBE就介绍到这里了,下一讲说说SETUP,欢迎持续关注!

 

往期精彩推荐

 

手撕RTSP协议系列(1)——Rtsp基本流程

手撕RTSP协议系列(2)——Rtsp消息格式

手撕RTSP协议系列(3)——sdp格式详解

 

 

扫码关注了解更多,还有交流群哦

  • 5
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
海康威视是一家专业从事视频监控产品研发和生产的知名企业,其产品使用了一种被称为RTSP(Real Time Streaming Protocol)的协议RTSP协议是一种用于实时流媒体传输的应用层协议RTSP协议的主要作用是实现客户端和服务器之间的媒体数据传输和控制。它允许客户端通过类似于HTTP的请求和响应方式来发送控制命令和获取媒体数据。与HTTP协议相比,RTSP协议更加轻量级,适用于实时性要求高的视频监控场景。 RTSP协议的工作流程如下: 1. 客户端与服务器建立TCP连接。 2. 客户端发送描述请求,获取服务器支持的媒体格式、编码方式等信息。 3. 服务器响应描述请求,提供媒体相关信息。 4. 客户端发送SETUP请求,请求建立传输通道,并指定传输媒体的相关参数。 5. 服务器响应SETUP请求,告知是否成功建立传输通道。 6. 客户端发送播放请求,开始接收媒体数据。 7. 服务器响应播放请求,开始传输媒体数据。 RTSP协议支持多媒体格式和编码方式,比如H.264、MPEG-4和JPEG等。同时,它也支持实时音频和视频的传输,可以满足不同场景的需求。 在海康威视的产品中,RTSP协议可以通过IP摄像机等设备的访问地址获取实时视频流。用户可以通过支持RTSP协议的客户端软件,如视频监控软件或流媒体播放器,来实时观看和控制监控画面。 总结来说,海康威视的RTSP协议是一种用于实时流媒体传输的协议,通过它可以实现客户端与服务器之间的媒体数据传输和控制。它具有轻量级、实时性高等特点,适用于视频监控和流媒体传输等场景。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值