一个RtspServer的设计与实现和RTSP2.0简介
前段时间着手实现了一个RTSP Server，能够正常实现多路RTSP流的直播播放，因项目需要，只做了对H.264和AAC编码的支持，但是相信其他编码的实现基本逻辑也是想通的。这里我把主要设计和思考过程，以及实现框架分享一下。因为关注的是直播，这里只讨论RTSP直播协议。
RTSP协议概述与RTSP2.0
众所周知，RTSP协议是一个流媒体协议，可以实现直播和点播形式的音频与视频流的播放。RTSP协议定义了多种服务器-客户端之间交互的接口，主要有OPTIONS，DESCRIBE，SETUP，PLAY，TEARDOWN，RECORD，ANNOUNCE。网络上已经有很多针对RTSP协议的文章，我这里不准备进行过多介绍，详细的协议定义，可以参见RFC2326。RTSP并不包括具体数据的传输，该功能一般由RTP与RTCP协议来实现，并可以通过TCP或UDP两种底层传输方式进行。
下图是典型的RTSP直播过程中服务端-客户端主要交互过程：
当然，直播过程中也可能在服务器与客户端之间调用GET_PARAMETER等其他接口，上图偷懒省略了。上图绿色部分表示的是数据传输。之前说过，流媒体数据传输不是RTSP协议的内容，由RTP包来做。但是具体在实现上，RTP包可以通过UDP或TCP的方式来进行，而且这两种传输方式，区别其实还不小，下面具体说下。
RTSP 数据传输流程
1. RTSP over UDP
对于udp模式，客户端在发送PLAY以后，就开始建立udp端口，以接收服务器发来的RTP包，同样，服务器也会建立udp端口，并向客户端发送RTP包。这是网上大部分程序所采用的方式，优点是逻辑清晰，实现方便，不过缺点也很明显，就是udp所固有的，容易丢包，尤其是在高分辨率高码率下。
2. RTSP over TCP
对tcp模式，通过SETUP接口来指定传输方式，服务器返回同样数据以确定双方通过tcp方式来传输数据。不过跟udp最大的不同是，rtsp over tcp的形式，不再创建单独的tcp通道，而是直接使用之前rtsp通信所使用的tcp通道，流程如下所示：
由于跟rtsp消息使用同一个tcp端口，为了区分，rtp以及rtcp包，增加了4个字节额外的字段，并通过特殊的标识'$'，与正常的rtsp消息进行了区分。
RTSP Live Server 设计与实现
1. 程序框架
我这次所实现的RTSP Server，主要功能是采集摄像头和麦克风数据，进行h.264编码以及aac编码，并对外提供RTSP直播流服务。我在实际写代码中，也是首先实现了rtsp over udp的模式，然而，通过实际测试，我发现在高分辨率高码率情况下，由于h.264 NAL单元过大，会拆分成很多的rtp包，而udp不可靠的传输方式，总是难免丢包，在低码率的时候还不明显，高码率情况下，丢包导致的花屏会频繁出现，这样体验特别差。于是我重新实现了一份rtsp over tcp模式的代码，顺利解决了这个问题。
2. 关于h264在sdp中的描述
h264在sdp中的媒体信息,大多都是可以直接填写的，但是有两项数据需要根据编码后的数据来提取，就是profile-level-id和sprop-parameter-sets。这两项字符串数据的计算公式
- profile-level-id = "Base16(sps[1])" + "Base16(sps[2])" + "Base16(sps[3])"
- sprop-parameter-sets = "Base64(sps)" + "," + "Base64(pps)"
3. 主要代码
3.1 Rtsp服务接口
3.2 RtspSession在TCP通道里处理RTSP消息与RTP报文
4. 运行效果
同时用vlc和ffplay进行多路播放，以tcp请求的方式，效果如下，延迟极低。
关于RTSP 2.0
2016年IETF发布了新的RTSP标准，这就是就是RTSP2.0协议（RFC7826），新标准还是有不少修改的，除了完善一些原协议的中的定义，还有一些我觉得比较重要的是，对接口method进行了修改，比如删除了RECORD和ANNOUNCE方法，新增了PLAY_NOTIFY方法。
- 删除了RECORD，这表示你不能再通过这个接口来控制服务器进行数据的录制了，可以选择在PLAY方法中，添加一些参数，来实现服务器对直播数据进行录制，还可以分隔录制。
- 删除了ANNOUNCE，这意味着，不能像RTMP一样，客户端通过向服务器推送数据，来实现本机数据对外直播了，这可能需要其他的推送途径来进行替代了。
- 至于PLAY_NOTIFY，它替代来原来Server向Client端发送ANNOUNCE方法，所实现的功能，也就是告诉客户端，需要根据新参数来调整直播播放状态。
- 删除通过UDP传输RTSP消息的形式
- 删除通过发PLAY消息来keep alive的方式（用SET_PARAMETER来做）
- RTSP Server也可向Client发TEARDOWN消息
- 支持IPV6
- RTSP请求，支持pipelining的形式，也就是聚合Request。比如可以不等服务器返回，把SETUP和PLAY一起发送，这样可以提高至少一个RTT的启动时间。当然需要在消息里加上相关字段。
- 重写了状态机，完善了服务器对客户端来说在各个状态之间的转换和行为
- RTSP消息内支持URI了
- 扩展了REDIRECT方法，等，等等。
