rtsp简介

阅读量：4949 次

发布时间：2019-06-11

本文共 14004 字，大约阅读时间需要 46 分钟。

https://wenku.baidu.com/view/b10415dabd64783e08122b9c.html

1 概要

RTSP（Real Time Streaming Protocol）实时流协议：一种流媒体控制协议，可对流媒体进行暂停、快进、快倒等操作。

流媒体就是实时在线点播。而流媒体与普通媒体的差别在于：对于普通媒体，在访问它之前要得到全部的内容；对于流媒体，则在完全接收到全部内容之前就开始访问。

本文主要介绍RTSP的基本消息信令及手机与HMS的RTSP的消息交互过程。

2 RTSP 介绍

3.1 RTSP是什么？

RTSP（Real Time Streaming Protocol），实时流协议，是一种应用层的协议，用于实时的控制数据的传输。RTSP提供一个可扩展的架构来实现控制实时媒体的在线点播，如音频或是视频内容。数据源可以是直播信号也可以是制作好的媒体文件。RTSP能够同时控制多个数据传输会话过程，

3.2 RTSP URL[a1] 的语法结构

一个终端用户是通过在播放器中输入URL地址开始进行观看流媒体业务的第一步，而对于使用RTSP协议的移动流媒体点播而言，URL的一般写法如下：

一个以“rtsp”或是“rtspu”开始的URL链接用于指定当前使用的是RTSP 协议。RTSP URL的语法结构如下：

rtsp_URL = (“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name

host：可以是一个有效的域名或是IP地址。

port：端口号，对于RTSP协议来说，缺省的端口号为554，即如HTTP的缺省端口号是80一样。当我们在确认流媒体服务器提供的端口号为554时，此项可以省略

说明：当HMS服务器使用的端口号为554时，我们在写点播链接时，可以不用写明端口号，但当使用非554端口时，在RTSP URL中一定要指定相应的端口。

注：我们在点播时使用的都是rtsp，而没有使用到rtspu。

3.3 RTSP 消息

3.3.1 消息

RTSP是一种基于文本的协议，用CRLF[a2] 作为一行的结束符。使用基于文本协议的好处在于我们可以随时在使用过程中的增加自定义的参数，也可以随便将协议包抓住很直观的进行分析。

RTSP从传输方向上有两种消息，即“请求消息”及“回应消息”。一个消息一般由头和内容组成，不过也有很多的消息是只有消息头（message head or header）而没有消息体（message body）的。

3.3.2 请求消息

一个请求消息（a request message）即可以由客户端向服务端发起也可以由服务端向客户端发起。请求消息的语法结构如下：

Request = Request-Line

*( general-header | request-header | entity-header)

CRLF

[message-body]

Request Line

请求消息的第一行的语法结构如下：

Request-Line = Method 空格 Request-URI 空格 RTSP-Version CRLF

其中在消息行中出现的第一个单词即是所使用的信令标志。目前已经有的信息标志如下：

Method = “DESCRIBE”

| “ANNOUNCE”

| “GET_PARAMETER”

| “OPTIONS”

| “PAUSE”

| “PLAY”

| “RECORD”

| “REDIRECT”

| “SETUP”

| “SET_PARAMETER”

| “TEARDOWN”

| extension-method

extension-method = 标志

我们可以使用自己定义的信令标示符

Request-URI = “*” | absolute_URI

请使用请求媒体存放的绝对路径

RTSP-Version = “RTSP” “/” 1*DIGIT “.” 1*DIGIT

RTSP的版本号

例子：

DESCRIBE rtsp://211.94.164.227/3.3gp RTSP/1.0

Request Header Fields

在消息头中除了第一行的内容外，还有一些需求提供附加信息。其中有些是一定要的，后续我们会详细介绍经常用到的几个域的含义。

Request-header = Accept

| Accept-Encoding

| Accept-Language

| Authorization

| From

| If-Modified-Since

| Range

| Referer

| User-Agent

3.3.3 响应消息

客户端或是服务端在接收并解释一个请求消息后，会回复一个消息（response message）给请求方。响应消息的语法结构如下：

Response = Status-Line

*( general-header |response-header|entity-header)

CRLF

[message-body]

Status-Line

响应消息的第一行是状态行（status-line），每个元素之间用空格分开。除了最后的CRLF之外，在此行的中间不得有CR或是LF的出现。它的语法格式如下，

Status-Line = RTSP-Version 空格 Status-Code 空格 Reason-Phrase CRLF

Status-Code 是一个三位数的整数，用于描述接收方对所收到请求消息的执行结果，而Reason-Phrase是对Status-Code给出一个简短的文字描述，便于我们在收到一个消息后，不用每次都去查看code的解释，而只需要看Reason-Phrase就可以大概了解当前请求的执行状态。

Status-Code的第一位数字指定了这个回复消息的种类，一共有5类：

n 1XX: Informational – 请求被接收到，继续处理

n 2XX: Success – 请求被成功的接收，解析并接受

n 3XX: Redirection – 为完成请求需要更多的操作

n 4XX: Client Error – 请求消息中包含语法错误或是不能够被有效执行

n 5XX: Server Error – 服务器响应失败，无法处理正确的有效的请求消息

我们在处理问题时经常会遇到的状态码有如下：

Status-Code = “200” :OK

| “400” :Bad Request

| “404” :Not Found

| “500” Internal Server Error

RTSP的状态码也是可以扩展的。服务器可以根据实际情况定义相应的状态码及描述信息。

Response Header Fields

在响应消息的域中存放的是无法放在Status-Line中,而又需要传送给请求者的一些附加信息。

Response-header = Location

| Proxy-Authenticate

| Public

| Retry-After

| Server

| Vary

| WWW-Authenticate

3.4 信令

信令指的是在Request-URI中指定的需要被接收者完成的操作。信令（The method）大小写敏感，不能以字符”$”开始，并且一定要是一个标记符。

概要描述如下：

信令	发送方向	是否一定需要
DESCRIBE	C->S	建议
ANNOUNCE	C->S, S->C	可选择的
GET_PARAMETER	C->S, S->C	可选择的
OPTIONS	C->S, S->C	必需 (S->C: 可选择的)
PAUSE	C->S	建议
PLAY	C->S	必需
RECORD	C->S	可选择的
REDIRECT	S->C	可选择的
SETUP	C->S	必需
SET_PARAMETER	C->S, S->C	可选择的
TEARDOWN	C->S	必需

表1：信令简要描述

C：客户端

S：服务端

下面介绍几个常用的信令

3.4.1 OPTIONS （查询功能）

例子：

C->S:

OPTIONS * RTSP/1.0

CSeq: 1

Require: implicit-play

Proxy-Require: gzipped-messages

S->C:

RTSP/1.0 200 OK

CSeq: 1

Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

OPTIONS消息可以在任何时间被发起，如MOTO835手机就会每隔60秒左右向服务器端发送一个OPTIONS的消息，而HMS服务器在检查MOTO835是否仍在线时，也是通过来检查服务器端是否定时收到OPTIONS的消息来实现的。但需注意的是，并不是所有的手机和播放器会定时发送OPTIONS消息到服务器端，即使有发送，发送OPTIONS的消息的时间间隔也是不尽相同的。

3.4.2 DESCRIBE

DESCRIBE消息是由客户端发送到服务器端，用于客户端得到请求链接（request URL）中指定的媒体文件的相关描述。DESCRIBE的这一对交互消息完成了RTSP的媒体初始化。

例子：

C->S:

DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0

CSeq: 312

Accept: application/sdp, application/rtsl, application/mheg

S->C:

RTSP/1.0 200 OK

CSeq: 312

Date: 23 Jan 1997 15:35:06 GMT

Content-Type: application/sdp

Content-Length: 376

v=0 （这里就是MESSAGE BODY，它的长度由Content_Length来指定）

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

s=SDP Seminar

i=A Seminar on the session description protocol
u= e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait

DESCRIBE的响应消息必须包含所有的媒体初始化信息。对于基于RTSP的系统，媒体初始化是必须的，但是并不一定要通过DESCRIBE消息来得到，这里是一个RTSP的客户端得到初始化信息的三种方式：

n 通过RTSP的DESCRIBE

n 一些其它的协议，如HTTP，email attachment等

n 命令行方式

3.4.3 SETUP

SETUP请求用于指定流媒体使用的传输机置。在请求消息中会指定客户端在数据传输时相关的传送参数，而在响应消息中将包含由服务器端所指定的传输参数。服务器端在回复SETUP消息时将会生成一个session ID.

例子：

C->S:

SETUP rtsp://example.com/foo/bar/baz.3gp RTSP/1.0

CSeq: 302

Transport: RTP/AVP;unicast;client_port=4588-4589

S->C:

RTSP/1.0 200 OK

CSeq: 302

Date: 23 Jan 1997 15:35:06 GMT

Session: 47112344

Transport: RTP/AVP;unicast;

client_port=4588-4589;server_port=6256-6257

服务器端在回复SETUP消息时将会生成一个session ID.

3.4.4 PLAY

PLAY消息是告诉服务器端可以使用在SETUP消息中所指定的传输机置开始传送数据。需要指出的是，客户端不应该发送任何PLAY请求直到所有的SETUP消息被成功解析。PLAY消息会在range中指定媒体的播放时间，服务器在接到PLAY消息后会由range中指定的开始点开始发送媒体数据直到range中指定的结束点。

所有的PLAY消息都是必须按顺序被处理的，即当一个PLAY的请求到达时，而上一个PLAY请求还未完成，后面的PLAY请求将被延时，直到第一个PLAY处理完成时才会被处理。

例子：

C->S:

PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 835

Session: 12345678

Range: npt=10-15

3.4.5 PAUSE

PAUSE消息是用于暂时中断流媒体的传送。当暂停的时间过长（这个值应在SETUP消息中由timeout参数指定），服务器可以自动断开这个会话，释放所占用的资源。

例子:

C->S:

PAUSE rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 834

Session: 12345678

S->C:

RTSP/1.0 200 OK

CSeq: 834

Date: 23 Jan 1997 15:35:06 GMT

服务器不是必须要支持PAUSE信令的，例如，对于直播的节目，就可以不支持暂停。当一个服务器不支持某一个信令时，必须要返回给客户端以“501 Not Implemented”的响应消息，并且客户端应该不再尝试向服务器端发送这个请求。

3.4.6 TEARDOWN

TEARDOWN消息是用于停止媒体数据的传送，并释放所占用的资源。

例子：

C->S:

TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 892

Session: 12345678

S->C:

RTSP/1.0 200 OK

CSeq: 892

3.5 Header Field 解析

在每个消息中都会包含一定的字段用于描述一些信息。

Type ”g” 指通用，在请求消息和响应消息中都可能出现

Type “R” 指请求消息

Type “r” 指响应消息

Type “e” 指实体头字段

头	类型	支持	信令
Accept	R	opt.	entity
Accept-Encoding	R	opt	entity
Accept-Language	R	opt	all
Allow	r	opt.	all
Authorization	R	opt.	all
Bandwidth	R	opt	all
Blocksize	R	opt.	all but OPTIONS, TEARDOWN
Cache-Control	g	opt.	SETUP
Conference	R	opt	SETUP
Connection	g	req	all
Content-Base	e	opt.	entity
Content-Encoding	e	req.	SET_PARAMETER
Content-Encoding	e	req.	DESCRIBE, ANNOUNCE
Content-Language	e	req	DESCRIBE, ANNOUNCE
Content-Length	e	req.	SET_PARAMETER, ANNOUNCE
Content-Length	e	req.	entity
Content-Location	e	opt	entity
Content-Type	e	req.	SET_PARAMETER, ANNOUNCE
Content-Type	r	req.	entity
CSeq	g	req	All
Date	g	opt.	All
Expires	e	opt.	DESCRIBE, ANNOUNCE
From	R	opt.	All
If-Modified-Since	R	opt.	DESCRIBE, SETUP
Last-Modified	e	opt.	Entity
Proxy-Authenticate Proxy-Require	R	req.	All
Public	r	opt.	All
Range	R	opt	PLAY, PAUSE, RECORD
Range	r	opt.	PLAY, PAUSE, RECORD
Referer	R	opt.	All
Require	R	req.	All
Retry-After	r	opt.	All
RTP-Info	r	req.	PLAY
Scale	Rr	opt.	PLAY, RECORD
Session	Rr	req.	all but SETUP, OPTIONS
Server	r	opt.	All
Speed	Rr	opt.	PLAY
Transport	Rr	req.	SETUP
Unsupported	r	req.	All
User-Agent	R	opt.	All
Via	g	opt.	All
WWW-Authenticate	r	opt.	All

表2：RTSP头字段简述

下面简要介绍一些在RTSP中常用到的头字段，详细的信息请查看RFC 2326。

3.5.1 Accept

Accept字段可用于指定可被接受的描述类型

例子:

Accept: application/rtsl, application/sdp;level=2

3.5.2 Cseq

Cseq域指定一对RTSP请求-响应消息的序列号。在请求消息及响应消息中一定要指定这个域。对于请求消息，会有一个具有相同Cseq域内容的响应消息与之对应。

例子：

C->S:

SETUP rtsp://example.com/foo/bar/baz.3gp RTSP/1.0

CSeq: 302

Transport: RTP/AVP;unicast;client_port=4588-4589

S->C:

RTSP/1.0 200 OK

CSeq: 302

Date: 23 Jan 1997 15:35:06 GMT

Session: 47112344

Transport: RTP/AVP;unicast;

client_port=4588-4589;server_port=6256-6257

3.5.3 Range

Range用于在请求消息和响应消息中指定播放的时间段。

例子：:

Range: clock=19960213T143205Z-;time=19970123T143720Z

3.5.4 RTP-Info

这个域用于在回复PLAY消息中指定RTP特殊的参数

url: 与设置的RTP参数对应的流媒体链接

seq: 流媒体第一个包的序列号

rtptime: 用于回复range域对应的RTP时间戳

RTP-Info语法结构：

RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter

stream-url = "url" "=" url

parameter = ";" "seq" "=" 1*DIGIT

| ";" "rtptime" "=" 1*DIGIT

例子：

RTP-Info:url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,url=rtsp://foo.com/bar.avi/streamid=1;seq=30211

3.5.5 Session

Session域在请求与响应消息中用于识别一个RTSP会话（RTSP session即一个完整的RTSP交互过程。例如：在点播流媒体时，一个典型的会话过程包括一个客户建立一个传输通道（SETUP），用PLAY开始传输流，最后用TEARDOWN来断开这个连接）。一旦客户端接收到Session标识，在这个会话中的任何请求都需要附加这个域。

Session语法结构：

Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]

例子：

Session: 12345678

3.5.6 Transport

这个域在请求消息中是标识哪一种传输协议将被使用，并指定一些在描述说明中没有指定的参数的值。使用的传输协议之间用逗号分隔，参数之间用分号分隔

常用参数：

unicast | multicast: 单播还是组播（缺省值为multicast）.

destination: 指定流将被传送到到哪个地址

port: (RTP协议):指定RTP/RTCP端口号（multicast）。一般为一个范围。e.g., port=3456-3457.

Client_port: 客户端选择的用于接收媒体数据及控制信息的单播 RTP/RTCP端口号。e.g., port=3456-3457

Server_port: 服务器端用于接收媒体数据和控制信息的单播 RTP/RTCP端口号。e.g., port=3456-3457

例子:

Transport:RTP/AVP;multicast;ttl=127;mode="PLAY", RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

3.5.7 User-Agent

这个域用于用户标识，不同公司或是型号的手机发出的消息中的这个域的内容都不大相同。有时会指出手机的版本号，播放器的型号等等。在HMS中的terminal.xml文件就是根据这个域中的内容来完成简单的终端适配的功能。

例子：

User-Agent:01056SS68001117616022101802836055;14;41;4578;327;13824;0;1;0x0202;0x00000B;0x028010

4 移动流媒体与RTSP

移动流媒体技术就是把连续的影像和声音信息经过压缩处理后放到网络服务器上，让移动终端用户能够一边下载一边观看、收听，而不需要等到整个多媒体文件下载完成就可以即时观看的技术。实际上移动流媒体技术是网络音视频技术和移动通讯技术发展到一定阶段的产物，它是融合很多网络技术之后所产生的技术，它会涉及到流媒体数据的采集、压缩、存输以及网络通信等多项技术。它大致分为下面两大类业务类型：

·　流媒体点播(VOD)

内容提供商将预先录制好的多媒体内容编码压缩成相应格式，存放在内容服务器上并把内容的描述信息以及链接放置在流媒体的portal上。最终用户就可以通过访问portal，发现感兴趣的内容，有选择的进行播放。

·　流媒体直播

流媒体编码服务器将实时信号编码压缩成相应的格式，并经由流媒体服务器分发到用户的终端播放器。根据实时内容信号源的不同，又可以分为电视直播、远程监控等。

对于点播和直播，都是使用的RTSP协议。下面我们介绍在实际应用中RTSP消息是如何交互来完成点播或是直播功能。

4.1 点播流程

一个移动用户使用手机通过访问网页得到URI，在URI中指定了流媒体服务器的地址及想要访问的媒体内容。通过RTSP SETUP消息来建立客户端与流媒体服务器之间的连接，然后客户端通过发送一个RTSP PLAY的消息来通知服务器开始传送一个或多个媒体流。

具体消息交互过程如下：

图2 RTSP消息交互

每次客户端发送一个请求消息，服务器端都会回一个相应的响应消息。

手机通过上网得到带有流媒体地址的网页，并点播一个节目

手机上发RTSP：DESCRIBE的消息给服务器，服务器处理其中的URL链接，得到相应文件的SDP信息，附加在响应消息中返回给手机。如果此时服务器找不到手机想要点播的文件，就会回应400的错误给手机，显示文件不存在。

手机根据收到的SDP的信息向服务器发送RTSP:SETUP消息，与服务器建立连接。如果媒体文件包含音频和视频，就会有两次SETUP的交互消息。一个是音频的信息，一个是视频的信息。如果交互成功，服务器会发送200的OK消息给手机

手机在SETUP消息执行成功后，会向服务器发送RTSP：PLAY的消息，要求服务器开始发送数据。服务器在收到PLAY消息后，即会开始传送UDP/RTP包。

如果在播放过程中需要暂停，手机会发送RTSP：PAUSE的消息给服务器，服务器在收到暂停消息后，即会停止发数据包，手机停止播放。如果需要继续播放，手机只需要再发送RTSP：PLAY的消息给服务器，服务器根据暂停的位置继续开始播放。

当播放完成后，手机会自动向服务器发送RTSP：TEARDOWN消息，当服务器收到下线消息后，就会断开与手机的连接，释放所占用的资源。

点播过程结束。

4.2 SDP

在播放过程中，手机得到内容的相关信息是很重要的，如果这些内容不正确，也会影响播放的正确性，下面简要介绍一下SDP。

SDP文件（Session Description Protocol）包含了会话的描述，媒体类型，媒体的码率。客户端通过RTSP DESCRIBE来得到SDP文件。

RTSP需要一个内容的描述。而SDP就被用于客户端与服务端的一种内容描述的格式。在传送给客户的SDP内容应该声明了这个对话所要访问的媒体内容的媒体编码类型。对于流媒体服务而言，以下几个域是在SDP中一定要包含的。

“a=control:”

“a=range:”

“a=rtpmap:”

“a=fmtp:”

例子：

v=0

o=ghost 2890844526 2890842807 IN IP4 192.168.10.10

s=3GPP Unicast SDP Example

i=Example of Unicast SDP file

u=http://www.infoserver.com/ae600

e=ghost@mailserver.com

c=IN IP4 0.0.0.0

b=AS:128

t=0 0

a=range:npt=0-45.678

m=video 1024 RTP/AVP 96

b=AS:128

a=rtpmap:96 H263-2000/90000

a=fmtp:96 profile=3;level=10

a=control:rtsp;//mediaserver.com/movie

a=recvonly

就如我们以前所了解的，对于直播，我们在建立了直播源后，就会将生成的SDP文件broadcast.sdp放在服务器上，而用户使用rtsp://ip:port/broadcast.sdp就可以进行直播节目的播放，这里的sdp文件里的内容就是上面所提到的这些。它将我们在建立直播源时所设置的音、视频编码，及相应的码率记录下来存在broadcast.sdp文件中，这样手机在进行进播时，得到了相关的SDP信息，然后根据这些信息与服务器建立连接。

4.3 数据传送

控制及媒体数据的传送是通过TCP/IP和UPD/IP上完成的，下图是一个协议栈的简单描述。媒体数据被打包成RTP包进行传送。

图3 协议栈的简单描述

4.4 消息流程

下面让我们来看一个具体的消息交互过程。我们可以通过ETHEREAL或是TCPDUMP这些抓包工具来获得这些信息。

c->s【向服务器请求SDP信息】

【DESCRIBE】 DESCRIBE rtsp://211.94.164.227/3.3gp RTSP/1.0

【交互标识】 CSeq: 1

【请求内容】 Accept: application/sdp

【用户标识】 User-Agent:01056SS68001117616022101802836055;

14;41;4578;327;13824;0;1;0x0202;0x00000B;0x028010

s->c 【服务端返回SDP信息】

【成功响应】 RTSP/1.0 200 OK

【服务器版本号】 Server: HMS Mobile V100R001B08D023

【交互标识】 CSeq: 1

【SDP长度】 Content-Length: 625

【包含内容类型】 Content-Type: application/sdp

【包含内容信息】 Content-Base: rtsp://211.94.164.227/3.3gp/

【以下为SDP内容】

【SDP版本号】 v=0

【服务器信息】 o=StreamingServer 3276474929 1067418948000 IN

IP4 10.70.139.108

【文件名】 s=3.3gp

【URL】 u=rtsp://211.94.164.227/3.3gp

【e-mail】 e=admin@

【IPv4】 c=IN IP4 0.0.0.0

t=0 0

【控制属性】 a=control:rtsp://211.94.164.227/3.3gp

【视频信息】 m=video 0 RTP/AVP 96【媒体类型】

【视频带宽】 b=AS:16

【视频格式】 a=rtpmap:96 MP4V-ES【格式】/90000【采样率】

【视频格式】 a=fmtp:96 profile-level-id=8;

config=000001B008000001B50EA020202F000001000000012000C788BA9850584121463F

a=mpeg4-esid:201

【厂家信息】 a=x-envivio-verid:00011118

【视频轨道】 a=control:trackID=65737

【音频信息】 m=audio 0 RTP/AVP 97【媒体类型】

【音频带宽】 b=AS:19

【音频格式】 a=rtpmap:97 MP4A-LATM【格式】/11025【采样率】/1

a=fmtp:97 profile-level-id=15; object=2;

cpresent=0; config=40002A103FC0

a=mpeg4-esid:101

【厂家信息】 a=x-envivio-verid:00011118

【音频轨道】 a=control:trackID=65637

c->s 【向服务器发起建立视频连接的呼叫】

【SETUP信令】 SETUP rtsp://211.94.164.227/3.3gp/trackID=65737 RTSP/1.0

CSeq: 2

【传输信息】 Transport: RTP/AVP;unicast【单播区别组播】;

client_port=5004-5005【客户端端口号】

s->c【服务器返回视频连接建立成功信息】

RTSP/1.0 200 OK

Server: HMS Mobile V100R001B08D023

CSeq: 2

【会话标识】 Session: 4

【传输信息】 Transport: RTP/AVP;unicast;client_port=5004-5005;

source=211.94.164.227;【服务器IP】

server_port=8090-8091【服务器端口号】;

ssrc=3e06【同步源描述符】

c->s【向服务器发起建立音频连接的呼叫】

SETUP rtsp://211.94.164.227/3.3gp/trackID=65637 RTSP/1.0

CSeq: 3

Transport: RTP/AVP;unicast;client_port=5006-5007

Session: 4

s->c【服务器返回音频连接建立成功信息】

RTSP/1.0 200 OK

Server: HMS Mobile V100R001B08D023

CSeq: 3

Session: 4

Transport: RTP/AVP;unicast;client_port=5006-5007;

source=211.94.164.227;server_port=8092-8093;ssrc=3e06

c->s【向服务器发出播放请求】

PLAY rtsp://211.94.164.227/3.3gp RTSP/1.0

CSeq: 4

Session: 4

【播放位置】 Range: npt=now- 【从当前位置开始播放】

s->c【服务器返回发出播放成功响应请求】

RTSP/1.0 200 OK

Server: HMS Mobile V100R001B08D023

CSeq: 4

Session: 4

【RTP信息】 RTP-Info: url=trackID=65737;【轨道信息】seq=1;【RTP包序列号】

rtptime=0【RTP包时间戳】,url=trackID=65637;seq=1;rtptime=0

【播放范围】 Range: npt=0.000000-60.193000

s->c【服务器发送视音频数据给终端】

【RTP包略】 xxxx

c->s【向服务器发送终止请求】

【TEARDOWN信令】TEARDOWN rtsp://211.94.164.227/3.3gp RTSP/1.0

CSeq: 5

Session: 4

s->c【服务器返回终止成功信息】

RTSP/1.0 200 OK

Server: HMS Mobile V100R001B08D023

CSeq: 5

Session: 4

[a1]统一定位符（Uniform Resource Locator，缩写为URL）。

[a2]CRLF -- Carriage-Return Line-Feed 回车换行。

转载于:https://www.cnblogs.com/mic-chen/p/8723090.html

你可能感兴趣的文章

Java AmericanFlagSort

查看>>

Mysql远程连接报错

查看>>

C# windows程序应用与JavaScript 程序交互实现例子

mariadb BINLOG_FORMAT = STATEMENT 异常

查看>>

jq工具函数（九）使用$.extend()扩展Object对象

查看>>

如何监视性能和分析等待事件

查看>>

常见错误: 创建 WCF RIA Services 类库后, 访问数据库出错

查看>>

C3P0 WARN: Establishing SSL connection without server's identity verification is not recommended

查看>>

CSUOJ 1541 There is No Alternative