live555工程代码路径
live555工程在我的gitee下（doc下有思维导图、drawio图）：
live555
https://gitee.com/lure_ai/live555/tree/master

章节目录链接
0.前言——章节目录链接与为何要写这个？
https://blog.csdn.net/yhb1206/article/details/127259190?spm=1001.2014.3001.5502

学习demo
live555mediaserver.cpp

学习线索和姿势
1.学习的线索和姿势

网络编程
流媒体的地基是网络编程（socket编程）。
[网络编程学习]-0.学习路线。

绘图规则
本文的对象图和思维导图遵守的规则详见：
2.绘图规则

非阻塞服务端网络编程流程
socket创建、bind、listen、select、accept、select、recv/send-close。

rtsp协商流程
options、describe、setup、play、pause、teardown、get parameter、set parameter

rtp打包流程
打开媒体文件、读取一帧媒体数据、rtp打包、rtp发送

本节内容和目标
（1）live555mediaserver的保活机制
（2）rtcp协议学习
（3）wireshark抓包
（4）

正式开始

14.live555mediaserver-setup请求与响应
从第一个setup开始，创建了新对象 RTSPServer::RTSPClientSession ，而它就引入了server端的保活机制——其父类实现的 noteLiveness 方法。设置65s的alarm的定时器加入定时器列表，如果超过65s则server端断开rtsp链接。接下来第2次setup或者play等都会调用noteLiveness 来刷新这个65s的时间。注意这个是客户端下方setup或play，server来被动刷新这个时间的。
那么play之后，server端不断发送rtp包，它是如何刷新？目前发现是server自己间隔一段时间自己调用这个保活的方法，如下，搞不懂。

可以看到在play时把 GenericMediaServer::ClientSession::noteClientLiveness 这个静态方法注册到回调里去了，它其实质就是调用的 noteLiveness 。
看下它注册到哪里去了，追踪下：



可以看到它最终放到rtcp对象里的表格里了，可以猜测是rtcp接管了这个保活。这个注册回调完毕。那么在哪调用呢？追踪下：

noteArrivingRR直接调用它的，在什么时机下调用它呢？继续：

RTCPInstance::processIncomingReport调用的，大概意思也就是说在收到客户端的rtcp的接收⽅报告RR的时候才会调用noteArrivingRR方法，然后自然刷新保活。

那么再追踪谁调用RTCPInstance::processIncomingReport，就属于rtcp业务的流程是什么样的，看一点：

是RTCPInstance::injectReport调用的RTCPInstance::processIncomingReport。继续追踪：

MultiFramedRTPSource::networkReadHandler1() 调用的RTCPInstance::injectReport;
静态方法MultiFramedRTPSource::networkReadHandler调用的RTCPInstance::injectReport

静态方法MultiFramedRTPSource::networkReadHandler是在MultiFramedRTPSource::doGetNextFrame()里注册到socket任务里的，看fAreDoingNetworkReads这个成员保证只注册一次，这个socket任务如何注册的可以参见4.live555mediaserver-第一次select，不再赘诉。

15.live555mediaserver-rtp打包与发送知道音视频的rtp发送是根据帧率计算定时间隔，创建定时器任务加入定时器列表里，每次都是这样的任务循环的。这样不断的发送rtp数据。现在呢，再补充下在MultiFramedRTPSource::doGetNextFrame()里又注册了一个socket任务用于发送和接受客户端的rtcp的回包。

这就是涉及到rtcp了，参见好文章RTCP协议讲解。

总之呢，就是server端发送rtcp信息到客户端，客户端回报，接受到客户端的rtcp回报类型是RR的时候才会刷新这个保活，保持这个链接不断。目前只追踪了这个流程，具体它的时间间隔是怎样的，不知道怎么看？wireshark抓包看下。

抓包看，RR包有时间隔不到1s又时间隔4s，具体间隔不太懂，rtcp协议不懂得看下。

加日志看下
搜索关键字delete alarmHandler|PLAY rtsp|fLivenessCheckTask|SETUP rtsp
发现下

setup开始加入65s的定时任务，setup和play会刷新，那么rtp发送后确实是由rtcp来接管了，每次收到RR后才会刷新这个65s的定时任务。

小结

探索了server端的保活机制，这涉及到了rtcp协议，由rtcp接管了。接受到RTCP的RR时才会刷新，这样保活的。这个保活机制和我想象的不一样，不懂，再说。