专栏首页用户1692782的专栏手撕RTSP协议系列(5)——DESCRIBE

手撕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,欢迎持续关注!

本文分享自微信公众号 - 视界音你而不同(WorldOfVideoAndAudio),作者:马龙飞

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-10-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 手撕RTSP协议系列(6)——SETUP

    SETUP请求的作用是指明媒体流该以什么方式传输;每个流PLAY之前必须执行SETUP操作;发送SETUP请求时,客户端会指定两个端口,一个端口用于接收RTP数...

    视界音你而不同
  • 手撕RTSP协议系列(13)——RTCP协议

    之前的文章,介绍了RTSP和RTP协议,RTSP用于建立连接及发送请求等,RTP用于实际的媒体数据传输。整个RTSP的流程中,还有一种不可或缺的协议, 那就是R...

    视界音你而不同
  • 手撕RTSP协议系列(7)——PLAY

    上一篇我们熟悉了RTSP_SETUP消息,SETUP可以说是PLAY的准备流程,只有SETUP请求被成功回复之后,客户端才可以发起PLAY请求。本篇我们就来看一...

    视界音你而不同
  • 手撕RTSP协议系列(8)——PAUSE

    上一篇我们讲解了RTSP PLAY消息,PLAY请求成功之后,RTSP server就会一直向客户端发送RTP数据包!开始“播放”之后,我们相应的就会有暂停,停...

    视界音你而不同
  • 手撕RTSP协议系列(9)——TEARDOWN

    上一篇我们讲了RTSP PAUSE消息,本篇我们来看下RTSP TEARDOWN消息!

    视界音你而不同
  • 手撕RTSP协议系列(10)——GET_PARAMETER

    上一篇我们介绍了RTSP的TEARDOWN指令,用于结束一个RTSP的会话!本篇我们来介绍RTSP GET_PARAMETER!

    视界音你而不同
  • 手撕RTSP协议系列(11)——RTSP_SET_PARAMETER

    上一篇介绍了RTSP的GET_PARAMETER消息,看到这个消息类型,我们很容易习惯性的想到应该还要有一个RTSP_SET_PARAMETER消息,如我我们所...

    视界音你而不同
  • 手撕RTSP协议系列(4)——OPTION

    上一篇,我们介绍了sdp相关信息,接下来开始我们介绍RTSP相关的选项,本篇我们首先来看一下OTPION选项。

    视界音你而不同
  • 手撕RTSP协议系列(1)——Rtsp基本流程

    哈喽,久违的小伙伴们!之前开了一个专辑手撕了rtmp协议!对于流媒体协议,rtsp协议也是很常见的,接下来我们继续手撕,手撕rtsp协议!本篇我们首先来简单了解...

    视界音你而不同

扫码关注云+社区

领取腾讯云代金券