"本文转载自:
- [^一二三^]的流媒体协议之RTSP详解
- [Chiang木]的实时流协议---RTSP【详解】"
1.概述
RTSP(Real Time Streaming Protocol 实时流协议)建立并控制一个或几个时间同步的连续流媒体,对媒体流提供了诸如开始、暂停、快进、停止等控制。它是TCP/IP协议体系中的一个应用层协议,协议主要规定了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP体系结位于RTP和RTCP之上(RTCP用于控制传输,RTP用于数据传输),使用TCP或UDP完成数据传输。RTSP的作用相当于流媒体服务器的远程控制,而它本身并不传输数据。
RTSP流媒体协议交互及码流传输过程中所用的协议如下:
官方指导文档参考:RFC 2326 - Real Time Streaming Protocol (RTSP)
RTSP的语法和运作跟HTTP 1.1类似,但并不特别强调时间同步,所以比较能容忍网络延迟。它具有重新导向功能,可视实际负载情况来转换提供服务的服务器,以避免过大的负载集中于同一服务器而造成延迟。
(1)RTSP协议与HTTP协议的区别:
状态:RTSP是有状态的,它的命令总是按照顺序来发送,其中某个命令可能需要总在另外一个命令之前要发送。而http则是无状态,协议在发送一个命令以后,连接就会断开,且命令之间是没有依赖性的。
端口:RTSP协议使用554端口,http使用80端口。
请求:RTSP的请求服务器和客户端都可以发送,而HTTP请求则只能由客户端发送。
(2)RTSP的优点:
易扩展:RTSP中很容易加入新的方法及参数,只需要服务器和客户端共同协商即可
易解析:RTSP可以由标准HTTP或MIME解析器进行解析
安全:RTSP使用网页安全机制,所有HTTP授权机制如basic、digest都可以直接使用
传输协议多选:RTSP可以使用TCP()或UDP作为其底层传输协议支持
多服务器支持:请求的多股流可以放在不同的服务器上,客户端自动与这几个服务器建立连接,在传输时完成媒体流同步
2.RTSP协议交互过程
RTSP协议通常是基于TCP的方式进行协议交互,另外也可基于HTTP,其交互过程有所不同,协议交互主要实现流媒体信息描述/码流通道建立/流媒体控制等功能,这里要区分RTSP协议交互与流媒体码流传输,RTSP协议交互,只做流媒体会话交互功能:
通过describe来同步流媒体编码、封装、连接等信息;
通过setup来建立流媒体传输通道;
通过play来开启流媒体播放;
通过teardown来结束播放。
流媒体码流的传输是通过RTSP交互建立的流媒体传输通道来传输码流,其传输协议一般为RTP/RTCP,其传输层可以为UDP或者TCP。
2.1 RTSP基于TCP交互过程
承载RTSP的协议为TCP,其主要交互过程如下图所示:
RTSP返回的状态码与HTTP类似,各个方法的说明也很简单也不做过多的说明。
(1)在开发中,RTSP客户端可以直接发送describe,而无强制要求必须要发送option。
(2)describe之后,根据其携带的SDP信息,判断流媒体的编码格式,封装格式,payloadtype,timescale,track标识等信息,客户端保存此信息用于后续码流的解复用和解码。
(3)根据track标识去申请想要的类型的码流;
(4)客户端通过setup来建立码流通道,如果有多路,需要根据不同的track 调用setup方法多次;
(5)一般setup建立通道可以是rtp/avp或者rtp/avp/tcp类型,这里标识以rtp传输音视频;
(6)rtp/avp基于UDP传输,rtp/avp/tcp基于TCP传输;
(7)如果基于UDP传输码流时(rtp/avp类型),需要根据setup交互的信息,单独建立RTP/RTCP两路UDP通道;
(8)如果基于TCP传输码流时(rtp/avp/tcp类型),则与RTSP共用一个TCP通道,通过在RTP/RTCP头加上$开头的四个字节的tcpheader来区分是哪一路的RTP/RTCP,还是RTSP。
RTP/AVP类型传输模式:单独建立RTP和RTCP两路UDP通道传输码流数据。
RTP/AVP/TCP类型传输模式:与RTSP共用一个TCP通道。
2.2 RTSP基于HTTP的交互过程
RTSP-over-HTTP tunneling,通过HTTP隧道来传输RTSP协议和媒体流,需要RTSP服务器支持此种方式,开启HTTP隧道监听端口。
客户端首先会建立一个链接通过HTTP-GET方法来获取协议响应消息和媒体流,然后再建立一个链路,通过HTTP-POST方法来发送请求消息,两个tcp链接都是长连接,POST 连接中发送RTSP请求消息,一般要进行BASE64编码,来隐藏RTSP信息。数据流的发送封装方式与RTP/TCP一样,通过GET链路发送给客户端,响应消息也是通过GET链路发送给客户端,其流程如下:
3.RTSP方法
RTSP常用的方法包括:OPTIONS、DESCRIBE、ANNOUNCE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER等。详细使用介绍如下:
4.RTSP报文解析
RTSP有两类报文:请求报文(request)和响应报文(ressponse)。请求报文是指从客户向服务器发送请求报文,响应报文是指从服务器到客户的应答。RTSP报文由三部分组成,即开始行、首部行和实体主体。如下使用wireshark抓取的数据包:
4.1 请求报文
在请求报文中,开始行就是请求行,RTSP请求报文的结构如下图所示:
下面是OPTIONS请求消息的一个wireshark抓包,我们以此为例进行报文解析:
(1)RTSP的第一行(请求行)
Request: OPTIONS rtsp://127.0.0.1:554/desktop RTSP/1.0\r\n
内容格式:
方法名称(OPTIONS) + 空格 + URL地址 + 空格 + RTSP版本 + 回车符(CR)和换行符(LF)
其中方法包括:OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等;URI是接受方的地址,例如:rtsp://127.0.0.1:554/desktop
RTSP版本一般都是 RTSP/1.0。每行后面的CR LF表示回车换行,需要接受端有相应的解析。
(2) 第二、第三、第四行表示的是该消息的各字段名称及其对应的值:
CSeq:表示序列号,本次请求的序列号为1(服务器端回复此请求的数据包的序列号也是1);
User-Agent:表示用户代理,值为 “Lavf60.4.100”;
最后一行:\r\n,表示本次请求报文结束。
内容格式:
字段名 + 空格 + 字段值 + 回车符(CR)和换行符(LF)
4.2 响应报文
响应报文的开始行是状态行,RTSP响应报文的结构如下图所示:
下面是OPTIONS响应消息的一个wireshark抓包,我们以此为例进行报文解析:
(1)RTSP的第一行(状态行)
Response: RTSP/1.0 200 OK\r\n
内容格式:
RTSP版本 + 空格 + 状态码 + 空格 + 状态语 + 回车符(CR)和换行符(LF)
(2)第二、第三、第四、第五行表示的是该消息的各字段名称及其对应的值:
Public:表示RTSP服务器支持的方法,值为“DESCRIBE,SETUP,TEARDOWN,PLAY,PAUSE,OPTIONS,ANNOUNCE,RECORD”
CSeq:表示序列号,本次响应的序列号为1(对应恢复请求序列号1);
Session:表示一个RTSP会话,值为 “ipAyvSBVR”;
最后一行:\r\n,表示本次响应报文结束。
4.3 常用字段含义
Accept:用于指定客户端通知服务器自己可以接受的实体数据结构类型。例如: Accept: application/sdp,之后服务器通过Content-Type字段返回其实体数据结构类型;
Accept-Encoding:用于客户端通知服务器自己可以接受的数据压缩格式,例如:Accept-Encoding: gzip, compress, br,之后服务器将通过Content-Encoding字段通知客户端它的选择;
Accept-Language:用于客户端通知服务器自己可以理解的语言及其接受度,例如:Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5 ,之后服务器将通过Content-Language字段通知客户端它的选择;
Authorization:客户端请求消息头含有服务器用于验证用户代理身份的凭证;
Bandwidth:用于描述客户端可用的带宽值。例如: Bandwidth: 4000;
Blocksize:此字段由客户端发送到媒体服务器,要求服务器提供特定的媒体包大小,服务器可以自由使用小于请求的块大小。 此数据包大小不包括 IP、UDP 或 RTP 等低层标头;
CSeq:指定了RTSP请求响应对的序列号,对每个包含一个给定序列号的请求消息,都会有一个相同序列号的回应消息,且每个请求或回应中都必须包括这个头字段;、
Cache-Control:通过指定指令来实现缓存机制。缓存指令是单向的,这意味着在请求中设置的指令,不一定被包含在响应中;
Conference:通知服务器不得更改同一 RTSP 会话的会议 ID;
Connection:该字段决定当前的事务完成后,是否会关闭网络连接。如果该值是“keep-alive”,网络连接就是持久的,不会关闭,使得对同一个服务器的请求可以继续在该连接上完成或者Connection: close;
Content-Length:该字段指明在RTSP协议最后一个标头之后的双 CRLF 之后的内容长度。例如在服务器响应DESCRIBE中,指明sdp信息长度;
Content-Type:告诉客户端实际返回的内容的内容类型;
User-Agent:该字段用来让网络协议的对端来识别发起请求的用户代理软件的应用类型、操作系统、软件开发商以及版本号;
Expires:指明过期的时间;
Rang: 用于指定一个时间范围,可以使用SMPTE、NTP或clock时间单元;
Session:Session头字段标识了一个RTSP会话。Session ID是由服务器在SETUP的回应中选择的,客户端一旦得到Session ID后,在以后的对Session 的操作请求消息中都要包含Session ID.例如:Session: 411B4161;timeout=65;
Transport:Transport头字段包含客户端可以接受的传输选项列表,包括传输协议,地址端口,TTL等。服务器端也通过这个头字段返回实际选择的具体选项。如: Transport: RTP/AVP/TCP;unicast;destination=192.168.31.222;source=192.168.31.222;interleaved=0-1。
5.RTSP协议推拉流
5.1 RTSP协议拉流详解
RTSP协议交互无论是基于TCP,还是HTTP,或者其他方式,其协议交互流程都不变,以下按照客户端拉流的协议交互顺序,对RTSP协议各个方法极其响应进行详细说明。
5.1.1 OPTION方法
请求及响应实例如下:
OPTIONS rtsp://10.45.12.141:554/h264/ch1/main/av_stream RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
=======================
RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER
Date: Wed, Jul 27 2022 10:37:06 GMT
此方法主要用来询问流媒体服务器支持哪些RTSP方法,此例子说明服务器支持OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER,此方法不是交互必须的,客户端可以跳过此方法直接发describe,服务器需要注意兼容。
响应报文遵循RTSP response消息的格式:
第一行:RTSP的版本,状态码,状态描述;
CSeq:与OPTION请求中的序列号相同;
Public:用于描述服务器当前提供了哪些方法;
Date:表示日期。
5.1.2 DESCRIBE方法
从服务器获取媒体流相关的信息,可以包含多个媒体流类型极信息,通过SDP来描述和区分不同媒体类型的媒体源,客户端根据服务器支持的媒体源通过setup建立媒体流通道,其实例如下:
DESCRIBE rtsp://10.45.12.141:554/h264/ch1/main/av_stream RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp
=======================
RTSP/1.0 401 Unauthorized
CSeq: 3
WWW-Authenticate: Digest realm="IP Camera(C7627)", nonce="c4c4e29b1620211e44ec28b077e2eb52", stale="FALSE"
Date: Wed, Jul 27 2022 10:37:06 GMT
---------------------------------------------------------------------------------------
DESCRIBE rtsp://10.45.12.141:554/h264/ch1/main/av_stream RTSP/1.0
CSeq: 4
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="c4c4e29b1620211e44ec28b077e2eb52", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream", response="be7cde07af4a08db991dd58a89db7621"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp
=======================
RTSP/1.0 200 OK
CSeq: 4
Content-Type: application/sdp
Content-Base: rtsp://10.45.12.141:554/h264/ch1/main/av_stream/
Content-Length: 574
v=0
o=- 1658918226996159 1658918226996159 IN IP4 10.45.12.141
s=Media Presentation
e=NONE
b=AS:5050
t=0 0
a=control:rtsp://10.45.12.141:554/h264/ch1/main/av_stream/
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://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1
a=rtpmap:96 H265/90000
a=fmtp:96 sprop-sps=QgEBAWAAAAMAsAAAAwAAAwB7oAPAgBDlja5JMvTcBAQEAg==; sprop-pps=RAHA8vA8kAA=
a=Media_header:MEDIAINFO=494D4B48010300000400050000000000000000000000000000000000000000000000000000000000;
a=appversion:1.0
这里客户端发送describe时,一般服务器会进行用户鉴权,如果未携带Authorization鉴权信息,或者认证失败,服务器会返回错误号为401的响应,客户端接收到401响应时,需要根据已知的用户鉴权信息,生成Authorization,再次发送describe,如果认证成功,服务器返回携带有SDP的响应信息。
5.1.3 SETUP方法
此方法根据流媒体服务器返回的SDP描述信息,进行流媒体传输通道的建立,如果sdp描述多个媒体源,客户端可根据需要建立媒体传输链路,play方法后,服务器根据setup建立的媒体流传输通道发送媒体流,一般有RTP over udp和RTP over tcp两张流的传输方式,其setup有一定的区别。
(1)RTP OVER UDP抓包实例:
SETUP rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1 RTSP/1.0
CSeq: 5
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="c4c4e29b1620211e44ec28b077e2eb52", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="ac52cf287fe4aa6be5bb168bc9d01446"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=63538-63539
=======================
RTSP/1.0 200 OK
CSeq: 5
Session: 1279114011;timeout=60
Transport: RTP/AVP;unicast;client_port=63538-63539;server_port=8312-8313;ssrc=3cc5faf7;mode="play"
Date: Wed, Jul 27 2022 10:37:07 GMT
首先客户端侧,SETUP的path路径,加上了trackID=1,表示建立的时trackID=1的媒体源的码流传输通道,通过上面SDP描述可知,此路时编码类型为H265,payloadtype=96的视频源,这里要注意,一个setup只能给一种媒体源建立流传输通道。如果服务器需要认证,setup也需要带上认证信息Authorization,Transport字段表示客户端通过何种方式申请建立媒体流传输通道,这里RTP/AVP表示通过UDP方式;unicast表示单播方式(也支持组播,比较少用,这里不做介绍),如果为UDP方式,则有client_port字段,client_port=63538-63539表示客户端测此路码流的RTP端口为UDP63538,RTCP端口为UDP63539;这里注意建立RTP码流传输通道时,RTP和RTCP要成对出现,一般码流端口号为RTCP=RTP+1。
服务器响应时,如果支持客户端的传输方式,则Transport字段中,RTP/AVP;unicast;client_port=63538-63539;要与客户端申请的消息保持一致,增加server_port字段,表示服务器发送RTP/RTCP的UDP端口,可选增加ssrc标识。这里要注意,服务端回复setup时,将会生成一个session ID.后续消息必须带有此Session字段。
(2)RTP OVER TCP抓包实例:
SETUP rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1 RTSP/1.0
CSeq: 5
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="59db6d7ba1acb14582356c8bb8e61ce8", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="129818708e48cd0326f8b6f1b19613a3"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
=======================
RTSP/1.0 200 OK
CSeq: 5
Session: 2095163832;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=24e4e500;mode="play"
Date: Fri, Aug 26 2022 14:35:46 GMT
RTP通过TCP传输时,与UDP方式在SETUP方法上有一定的区别,主要是Transport头,RTP/AVP/TCP表示RTP流通过TCP传输,当此值出现时,其没有client_port字段,出现interleaved字段,interleaved=0-1,表示streamid;当码流通过TCP传输时,与RTSP共用一个TCP链路,所以其不需要建立新的连接,为了区分RTP、RTCP及RTSP协议,需要增加包头标识,这里采用TCPHEAD头字段,tcphead为四个字节,格式如下:
| magic number | channel number | embedded data length | data |
magic number: 1 byte value of hex 0x24($),标识传输的是数据不是rtsp协议;
channel number: 1 byte value to denote the channel,信道ID,标识流的类型;
embedded data length :2 bytes to denote the embedded data length,流长度;
data:表示RTP/RTCP包数据。
当TCP接收到的包开头为24时,可以判定其为RTP或者RTCP,通过streamid来区分,setup方法中interleaved=0-1,标识RTP的streamid=0;RTCP的streamid=1。
(3)tcphead抓包实例如下:
第一个24 00 00 14标识此包为RTP包长度为0x14,解析时只需要根据streamid及长度读取完整的RTP帧,去掉四字节头,通过RTP方式解析即可。由于TCP是流式传输,需要连续根据24标识判断。
5.1.4 PLAY方法
PLAY消息是告诉服务器端可以使用在SETUP消息中所指定的传输机制开始传送数据。需要指出的是,客户端不应该发送任何PLAY请求直到所有的SETUP消息被成功解析。PLAY消息会在range中指定媒体的播放时间,服务器在接到PLAY消息后会由range中指定的开始点开始发送媒体数据直到range中指定的结束点,PlAY可带有scale和speed字段用于点播速度控制。对于实时流range一般为Range: npt=0.000
PLAY rtsp://10.45.12.141:554/h264/ch1/main/av_stream/ RTSP/1.0
CSeq: 6
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="59db6d7ba1acb14582356c8bb8e61ce8", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="0eef224891c12e902ca9185c70f969cc"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Session: 2095163832
Range: npt=0.000-
=======================
RTSP/1.0 200 OK
CSeq: 6
Session: 2095163832
RTP-Info: url=rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1;seq=29458;rtptime=2518517708
Date: Fri, Aug 26 2022 14:35:46 GMT
play方法需要带上Session字段表示同一会话,此Session由setup时服务端返回,客户端发送play方法后,即可准备接收码流,服务器接收到play后,即可打开码流发送通道,发送码流;这里要注意服务器在给出play响应时,最好带有RTP-Info字段描述将要发送码流的RTP信息,比如第一包RTP的seq和rtptime,客户端可以根据此字段进行解复用。
5.1.5 TEARDOWN方法
客户端发起表示停止媒体占用,并释放相关资源,其实例如下:
TEARDOWN rtsp://10.45.12.141:554/h264/ch1/main/av_stream/ RTSP/1.0
CSeq: 7
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="e3dfa4549e00a1d53c0e9f28c3348e2c", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="0c530cba910c33ea3ef7a554dda8d0b2"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Session: 391346974
这里teardown一般会停止RTSP会话及视频传输通道,服务器接收到此方法时,释放相关资源。
5.1.6 其他方法
(1)PAUSE:录像回放时会用到,用以暂停流媒体传输;
(2)SET_PARAMETER/GET_PARAMETER:基本没啥用,一般用来作为心跳使用,也是用option来维持心跳。
5.2 RTSP协议推流详解
RTSP推流流程如下:
抓包实例如下:
OPTIONS rtsp://10.45.12.141:554/live/0001 RTSP/1.0
CSeq: 1
User-Agent: znv
=======================
RTSP/1.0 200 OK
Server: EasyDarwin/7.3
Cseq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD
=======================
ANNOUNCE rtsp://10.45.12.141:554/live/0001 RTSP/1.0
Content-Type: application/sdp
CSeq: 2
User-Agent: znv
Content-Length: 325
v=0
o=- 0 0 IN IP4 127.0.0.1
s=Media Server
c=IN IP4 192.168.1.108
t=0 0
a=tool:libavformat 57.71.100
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QAHqw0ygsBJ/wFuCgoKgAAB9AAAYah0MALFAALE9d5caGAFigAFieu8uFA,aO48MA==; profile-level-id=64001E
a=control:streamid=0
=======================
RTSP/1.0 200 OK
Server: EasyDarwin/7.3 (Build/17.0325; Platform/Win32; Release/EasyDarwin; State/Development; )
Cseq: 2
=======================
SETUP rtsp://10.45.12.141:554/live/0001/trackid=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
CSeq: 3
User-Agent: znv
=======================
RTSP/1.0 200 OK
Server: EasyDarwin/7.3
Cseq: 3
Cache-Control: no-cache
Session: 132169028622239
Date: Tue, 13 Nov 2018 02:49:48 GMT
Expires: Tue, 13 Nov 2018 02:49:48 GMT
Transport: RTP/AVP/TCP;unicast;mode=record;interleaved=0-1
=======================
RECORD rtsp://10.45.12.141:554/live/0001 RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent:znv
Session: 132169028622239
=======================
RTSP/1.0 200 OK
Server: EasyDarwin/7.3
Cseq: 4
Session: 132169028622239
RTP-Info: url=rtsp://192.168.1.108:554/live.sdp/live.sdp
RTSP推流,一般作为流媒体代理,应用CDN等场景,推流由客户端发起,视频由客户端推送给服务器端,因此流媒体描述需要由客户端通知到服务器,通过ANNOUNCE方法完成,其SDP描述与DESCRIBE一致,传输开始时,由客户端发送RECORD方法,然后由客户端推送rtp流到服务器。
6.RTSP错误码
RTSP的响应内容通常包含3位整数响应码以及一个原因短语,短语的目的是给出状态代码的简短文本描述, 客户端不需要检查或显示原因短语。 按照响应码的首位数字区别,可以分为以下五个类别:
1xx: 提示- 请求已经收到,正在处理中
2xx: 成功- 请求已经被成功处理
3xx: 重定向- 必须采取进一步行动才能完成请求
4xx: 客户端错误 - 请求中包含错误的参数或语法导致请求无法被满足
5xx: 服务器错误 - 服务器无法满足客户端正确的请求
当然,RTSP的错误码和RTSP方法是强相关的,某些错误可能只会在特定方法中才会触发,详细错误码信息如下:
错误码 | 原因短语 | 方法 |
---|---|---|
100 | Continue | All |
200 | Success | All |
201 | Created | RECORD |
300 | Multiple Choices | All |
301 | Moved Permanently | All |
302 | Moved Temporarily | All |
303 | See Other | All |
305 | Use Proxy | All |
400 | Bad Request | All |
401 | Unauthorized | All |
402 | Payment Required | All |
403 | Forbidden | All |
404 | Not Found | All |
405 | Method Not Allowed | All |
406 | Not Acceptable | All |
407 | Proxy Authentication Required | All |
408 | Request Timeout | All |
410 | Gone | All |
411 | Length Required | All |
412 | Precondition Failed | DESCRIBE, SETUP |
413 | Request Entity Too Larg | All |
414 | Request-URI Too Long | All |
415 | Unsupported Media Type | All |
451 | Invalid parameter | SETUP |
452 | Illegal Conference Identifier | SETUP |
453 | Not Enough Bandwidth | SETUP |
454 | Session Not Found | All |
455 | Method Not Valid In This State | All |
456 | Header Field Not Valid | All |
457 | Invalid Range | PLAY |
458 | Parameter Is Read-Only | SET_PARAMETER |
459 | Aggregate Operation Not Allowed | All |
460 | Only Aggregate Operation Allowed | All |
461 | Unsupported Transport | All |
462 | Destination Unreachable | All |
500 | Internal Server Error | All |
501 | Not Implemented | All |
502 | Bad Gateway | All |
503 | Service Unavailable | All |
504 | Gateway Timeout | All |
505 | RTSP Version Not Supported | All |
551 | Option not support | All |