14.live555mediaserver-setup请求与响应-创新互联
live555工程代码路径
live555工程在我的gitee下（doc下有思维导图、drawio图）：https://gitee.com/lure_ai/live555/tree/master
学习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
本节内容和目标
（1）rtsp协议的setup请求与响应
（2）思维导图绘制
（3）wireshark抓包
（4）对象图
正式开始
DESCRIBE协商完事，VLC接着下发了setup信令，开始setup协商。
请求报文如下
图14-1
可以参照live555mediaserver-如何解析rtsp请求报文把这请求报文解析出来。需要注意的是解析的只局限于请求方法、CSeq、Session、Content-Length等，它下发的其他字段就过滤了。
需要关注的是，这里服务端会用来识别发送模式——UDP or TCP?——这个字段是Transport字段——如果是RTP/AVP/TCP，则要求采用TCP方式进行数据传输。如果是RTP/AVP那么就是UDP。还有其他下面详说。
根据前面知道，每一个客户端链接，在服务端都绑定一个对象RTSPServer::RTSPClientConnection，每次客户端协议来数据来了，都会调用到RTSPServer::RTSPClientConnection::handleRequestBytes里，如下图目前知道OPTIONS、DESCRIBE、REGISTER、DEREGISTER、特殊url的GET_PARAMETER和SET_PARAMETER是会在这个对象里处理。
图14-2
那么从setup开始，又新建一个处理对象进行处理了。怎么创建的呢？RTSPServer::RTSPClientConnection::handleRequestBytes识别到时setup信令，调用流程如下图14-3。
图14-3
图14-3所示，此时setup处理流程会走到红箭头1，GenericMediaServer::createNewClientSessionWithId，这个是对象DynamicRTSPServer的父类的父类的成员，它主要干2件事，一个是创建对象RTSPServer::RTSPClientSession，另一个是把这个对象加入到GenericMediaServer::fClientSessions这个成员管理的hash链表了，如下图，——后面想想，图是代码的映射，它们应该对应起来，先贴出来代码：
Session的产生
代码图中标记1中sesionId是随机产生的数字，然后和新对象绑定一起，在组响应包时会作为Session字段返回给VLC客户端的，play时vlc又会下发过来，用以找到正确的新对象的。
新对象的产生
代码图中，第2和第3标记执行完就是如下图的14-4和14-5的模样。
14-4
fClientSessions这个成员管理的hash链表如下图14-5。整个图太大，只能截断，可以看我gitee上live555工程doc下的对象图。
图14-5
如上图14-5，和describe一样是同样类型的hash链表，就直接拷贝过来了，只是链表成员不一样的——setup把新创建的对象RTSPServer::RTSPClientSession的父类的指针加入到这个链表里的value里了。注意代码图的标记3在add时把sesionid传给了这个链表成员的key值，后面play下发会再次通过这个sessionid进行查找到这个新对象。
接着调用新对象RTSPServer::RTSPClientSession的handleCmd_SETUP方法，
它又调用GenericMediaServer::lookupServerMediaSession，而它是个虚方法，实际调用的是DynamicRTSPServer::lookupServerMediaSession（原因参见上一节）。然后查找fServerMediaSessions管理的hash链表是否有这个url文件路径，因为describe已经插入了，在这里找到了，又移除它，又重新创建，具体原因，没有细看。
这个最后又调用RTSPServer::RTSPClientSession的回调静态方法SETUPLookupCompletionFunction1，接着调用新对象的handleCmd_SETUP_afterLookup1方法，然后最终来到了setup组响应报文的地方——handleCmd_SETUP_afterLookup2。其流程如下图14-6.
图14-6
如图14-6数字1是调用GenericMediaServer::lookupServerMediaSession的流向，太大了截图放不下，算了。数字2是又回调回来了。最终是数字4来到了handleCmd_SETUP_afterLookup2。
其主要干了啥事，如下思维导图，图14-7.
图14-7
创建对象数组 struct streamState 保存各个ServerMediaSubsession对象，这个保存的就是前面创建的ServerMediaSubsession对象。代码图如下：
代码图对应的对象图如下图14-8——代码图一执行就如下图模样。.
图14-8
模拟类就是示意，因为类图太大了，只能把那个离的远的类在这一张图中表示出来了。
接着是解析协商传输方式，如下图14-9。
图14-9
streamingMode这引用变量默认是RTP_UDP。while来解析RTP_TCP和RAW_UDP，而我们的VLC下发的setup信息如图14-1中是RTP/AVP/TCP，这里自然就是RTP_TCP了。
然后根据根据不同的传输方式组不同的setup响应报文。
图14-10
注意呀，里面除了传输方式，还有个字段非常关键——Session字段，这个就是前面看到的sessionid了，这个告诉VLC客户端，你等会play的时候下发的Session字段应该填什么，这样服务端才能找到新对象RTSPServer::RTSPClientSession。
到此整个setup响应流程完毕。setup的完整处理思维导图如下图14-11.
图14-11。
其组装的setup响应报文用wireshark抓包如下图14-12.。
图14-12
小结
为了实现setup业务，又新增了几个对象如下图14-13.
图14-13.
可以看到，除了模拟的2个类（类图太大了，为了在一张图展现出来就模拟了下就是示意的意思）不是本节新创建的——最左边是早创建了，最右边是describe就创建了，在setup又销毁重建了，就不算了——其他的新增了几个对象：
（1）RTSPServer::RTSPClientSession。SETUP、PLAY、PAUSE、TEARDOWN、正常url的GET_PARAMETER和SET_PARAMETER都在这个新对象里处理了。
（2）struct streamState对象数组。这个为何是数组呢？因为如果describe阶段sdp有2个m字段——假如一个音频一个视频，则VLC会下发2次setup，那也就会走2次setup流程，这个会怎么样呢?没有细看，应该会创建2个subsession吧，回头再说。
（3）一个hash链表。它这个呀主要是把setup新建立的对象RTSPServer::RTSPClientSession管理起来，和sessionid绑定，组sdp响应包。
在追踪setup业务线索的过程中，发现了live555为了实现这个业务新增了这几个对象（目前关注点），然后就把代码转化成图的形式。
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
名称栏目：14.live555mediaserver-setup请求与响应-创新互联
网站链接：http://cdiso.cn/article/eeege.html
