RTSP
本篇我们来重温一下RTSP协议。编排如下先重读RFC2326协议文档回顾理论，然后举例4个最基本简单的应用场景观察RTSP如何工作。
RFC2326协议文档参考章节分别有：
4个最基本简单的应用举例场景分别是：
1. ffmpeg向ffplay推送节目
2. ffplay向rtsp服务器拉节目播放
3. ffmpeg向rtsp服务器提供节目源，ffplay播放rtsp服务器上的节目。
4. ffplay与rtsp服务器通过http隧道，播放节目。
本篇使用的rtsp服务器是DarwinStreaming。
(草稿)
Abstract
The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 1889).
rtsp的作用是用来控制实时数据的传递，并且是一个可扩展的框架，协议的目标是控制多个数据传递会话，会话可以选用UDP，多播UDP以及TCP作为传送通道，可以选用任何基于RTP协议的传送机制。
1.1 Purpose
The Real-Time Streaming Protocol (RTSP) establishes and controls
either a single or several time-synchronized streams of continuous
media such as audio and video. It does not typically deliver the
continuous streams itself, although interleaving of the continuous
media stream with the control stream is possible (see Section 10.12).
In other words, RTSP acts as a "network remote control" for
multimedia servers.
rtsp负责建立和控制一个或多个时间同步的连续数据流，例如音频和视频。但它本身并不自己对连续流进行传送。尽管在控制流（指的就是RTSP会话）中插入连续媒体流（指的就是RTP会话）是可行的。也就是RTP会话借用了RTSP会话的连接，将流的发送插入进去，而不是RTSP会话在向连接发送连续流数据，所以叫做插入。RTSP只为多媒体用途的服务器（进程）扮演网络远程控制的角色。
The set of streams to be controlled is defined by a presentation
description. This memorandum does not define a format for a
presentation description.
要控制的流都会集中在一起由"presentation description"来定义。
1.4 Protocol Properties
HTTP-friendly:
Where sensible, RTSP reuses HTTP concepts, so that the
existing infrastructure can be reused. This infrastructure
includes PICS (Platform for Internet Content Selection
[15,16]) for associating labels with content. However, RTSP
does not just add methods to HTTP since the controlling
continuous media requires server state in most cases.
Extendable:
New methods and parameters can be easily added to RTSP.
Easy to parse:
RTSP can be parsed by standard HTTP or MIME parsers.
Secure:
RTSP re-uses web security mechanisms. All HTTP authentication
mechanisms such as basic (RFC 2068 [2, Section 11.1]) and
digest authentication (RFC 2069 [8]) are directly applicable.
One may also reuse transport or network layer security
mechanisms.
RTSP重用了HTTP的概念，HTTP上的建设都可以使用RTSP，而RTSP可以被标准的HTTP服务器解释，并且是扩展起来和HTTP一样容易，还可以重用web现有的机制。
总结来说，RTSP负责对多媒体流进行建立和控制，
下面是４个实际例子，观察rtsp如何动作。
1. ffmpeg向ffplay推送节目
ffplay作为rtsp服务端，监听ＴＣＰ连接，并响应rtsp请求。
ffmpeg作为rtsp客户端，向ffplay推送数据。
ffplay响应了来自ffmpeg一连串的一共５个rtsp请求，OPTIONS,ANNOUNCE,SETUP,SETUP,RECORD。
ffplay依据ffmpeg通知过来的presentation description，结合SETUP请求，与ffmpeg建立起RTP会话，并接收由ffmpeg推送过来的流数据，并播放。
2. ffplay向rtsp服务器拉节目播放
ffplay作为rtsp客户端，向ＤＳ请求播放数据。
3. ffmpeg向rtsp服务器提供节目源，ffplay播放rtsp服务器上的节目。
4. ffplay与rtsp服务器通过http隧道，播放节目。
首先ffplay在67370端口向darwin streaming server的rtsp协议端口554，发送http请求（GET），表示接受隧道"Accept:application/x-rtsp-tunnelled"。server返回响应，发送隧道内容的数据"Content-Type:application/x-rtsp-tunnelled"，并且"Connection:close"。这里的连接关闭，并不是真正将连接关闭，根据http/1.1文档，当http协议的客户端接收到带有"Connection:close"的响应后不能够向server端发送任何数据，也就是当前连接建立起一条隧道，随后只由server端继续发送数据，http隧道的结束以server关闭连接为准。这就是利用http/1.1协议建立起接收方向的隧道。
然后ffplay在67371端口向darwin stteaming server的rtsp协议端口554，发送http请求（POST），表示发送隧道"Content-Type:application/x-rtsp-tunnelled"。http协议的客户端并不希望server端在这条连接上发送任何数据（响应），所以慌称要向server端POST一条长度为0x7fff的消息，但实际上是在这个长度的配额内，向server发送另一性质消息数据。
好这样就由ffplay向server通过http协议发起了两条连接，并且利用http协议分别在两条连接上协商好只接收数据和只发送数据。这就是隧道的基本原理，利用http协议客户端在NAT后发起连接，有效避开在NAT后的端口监听。利用两条单向通讯连接，完成一条双向通讯隧道的任务。形如只读和只写两条管道来代替一条读写管道。
由于POST建立的连接有Content-Length配额限制，因此有必要对数据进行处理减少流量。所以可以看到ffplay在67371发送的请求都变成了压缩后的Base64。
自此，ffplay与darwin streaming server在隧道（67370接收554，以及67371发送554）上完成rtsp协议通讯，还在这上面建立起RTP会话，或者说插入了RTP会话。ffplay在67371端口发送rtsp请求，在67370端口接收rtsp响应以及rtp数据包。
由于在一条连接上需要对不同协议格式框架的消息包进行划分，所以消息包的解析处理要变复杂。试想一下，对于同类型应用的协议的一般都有相同的传输长度协议位置或参数，对于基于二进制的协议格式如IP报文，都由报头的开始的规定位置读出长度然后确定报文长度。而基于文本的协议格式，如http协议，必须先逐行读入直至空行解析出头字段，再来判断http消息是否包含Body或结束。所以协议的消息包解析需要切换。
补充：20171226
1. 另外 rtsp协议 支持重用 rtsp连接用作RTP的底层传输。
rtsp_transport Set RTSP transport protocols. It accepts the following values: ‘udp’ Use UDP as lower transport protocol. ‘tcp’ Use TCP (interleaving within the RTSP control channel) as lower transport protocol. ‘udp_multicast’ Use UDP multicast as lower transport protocol. ‘http’ Use HTTP tunneling as lower transport protocol, which is useful for passing proxies. Multiple lower transport protocols may be specified, in that case they are tried one at a time (if the setup of one fails, the next one is tried). For the muxer, only the ‘tcp’ and ‘udp’ options are supported. rtsp_flags Set RTSP flags. The following values are accepted: ‘filter_src’ Accept packets only from negotiated peer address and port. ‘listen’ Act as a server, listening for an incoming connection. ‘prefer_tcp’ Try TCP for RTP transport first, if TCP is available as RTSP RTP transport. Default value is ‘none’.
2. ffmpeg - rtsp 帮助手册的 example
24.28.1 Examples The following examples all make use of the ffplay and ffmpeg tools. Watch a stream over UDP, with a max reordering delay of 0.5 seconds: ffplay -max_delay 500000 -rtsp_transport udp rtsp://server/video.mp4
Watch a stream tunneled over HTTP: ffplay -rtsp_transport http rtsp://server/video.mp4
Send a stream in realtime to a RTSP server, for others to watch: ffmpeg -re -i input -f rtsp -muxdelay 0.1 rtsp://server/live.sdp
Receive a stream in realtime: ffmpeg -rtsp_flags listen -i rtsp://ownaddress/live.sdp output
3. RTSP的简明文档
https://en.m.wikipedia.org/wiki/Real_Time_Streaming_Protocol
