SETUP
请求在 RTSP 的整个工作流程中,用于建立流媒体会话。本文分析 live555 对 SETUP
请求的处理。
在 RTSPServer::RTSPClientConnection::handleRequestBytes(int newBytesRead)
中,通过 RTSPServer::RTSPClientSession
的 handleCmd_SETUP()
函数处理 SETUP
请求,如下所示:
第一步,在这个函数中,首先查找资源对应的 ServerMediaSession
,先尝试以资源路径不包含 track id 的部分查找,如果失败则会以资源全路径查找:
在这里 lookupServerMediaSession(char const* streamName, Boolean isFirstLookupInSession)
的 isFirstLookupInSession
参数不再是默认值了,而是根据 fOurServerMediaSession
的值来确定。
可见在处理 DESCRIBE
请求时创建的 ServerMediaSession
将总是会被销毁,并重建。
第二步,根据前一步的查找结果做容错处理或更新状态。
如果查找或创建 ServerMediaSession
失败,且 fOurServerMediaSession
为空,向客户端返回 404 错误,这种情况比较容易理解,即在 DESCRIBE
请求之后,资源被移除了;如果查找或创建 ServerMediaSession
失败,且 fOurServerMediaSession
为非空,此时则向客户端返回 400 错误,这种场景似乎是,执行了多次 SETUP
操作,第一次执行的时候资源在,但后面执行的时候,资源不存在了。
查找或创建 ServerMediaSession
失败总是会使函数提前返回。
对于查找或创建 ServerMediaSession
成功的情况,如果此时 fOurServerMediaSession
为空,表明这是这个流媒体会话第一次执行 SETUP
操作,此时需要更新 fOurServerMediaSession
并增加其引用计数;如果 fOurServerMediaSession
非空,且与找到的不同,则向客户端返回 400 错误响应消息,不是很明白这究竟是什么样的场景。
第三部,根据需要创建流状态。为流媒体的每个子会话创建一个流状态结构 streamState
。
第四步,查找特定子会话(track)的信息。对于 URL 中携带了 track id 的请求,就根据 track id 查找,否则对于只有一个子会话的情况,就以该会话作为 track 会话。
第五步,如果 track 子会话的 token 非空,说明已经为该 track 处理过 SETUP
请求,则在重新设置它之前,先停止其已有的流。
会话中流媒体的控制的具体操作过程,暂时先不详细分析。
第六步,从请求字符串中查找 Transport:
头部,并从中提取客户端参数。SETUP
请求的 Transport:
头部看起来可能像下面这样:
在这个头部中,包含有通信的方式,对于 UDP,是单播还是多播,客户端收发 RTP/RTCP 包所用的端口号等。
|
|
我们前面在示例 Transport:
头部中,可以看到 “unicast”,但在 live555 中,不是根据 Transport:
头部的内容来确定流用单播还是多播的。
第七步,检查请求中是否有 Range:
或 x-playNow:
头部。这不是标准 RTSP 支持的做法,但一些客户端可能会用这种方法把 SETUP
和 PLAY
结合起来。
尽管 RTP/RTCP 也支持 TCP 模式,但这种做法不是很主流,后面我们主要来看基于 UDP 单播的模式。
第八步,为会话分配网络资源,如服务器端 RTP 和 RTCP 的端口等。
后面我们再来分析 H264VideoFileServerMediaSubsession
更详细地处理过程。
第九步,生成超时参数字符串。
第十步,生成响应消息。我们仅来看,RTP 的 UDP 单播模式响应消息的生成。
生成的消息看起来大概就像下面这样:
通过 Transport:
将协商的通信参数,如服务器端为会话分配的用于收发 RTP/RTCP 包的 UDP 端口。
抛开容错,总结一下 SETUP 请求的常规处理流程:
- 为会话创建
ServerMediaSession
。 - 解析请求头
Transport:
中包含的关于客户端请求的传输方式的内容,如使用 UDP 传输还是用 TCP 传输,客户端为 RTP/RTCP 传输开辟的端口等。 - 解析请求头中的
Range:
和x-playNow:
以支持SETUP
和PLAY
的合并。 - 为会话分配网络资源,如服务器端的 RTP/RTCP 端口等。
- 产生响应消息。
在 ServerMediaSubsession
中,一些更详细地处理过程,留待后面分析。
打赏
Done.
live555 源码分析系列文章
live555 源码分析:简介
live555 源码分析:基础设施
live555 源码分析:MediaSever
Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作过程
live555 源码分析:RTSPServer
live555 源码分析:DESCRIBE 的处理
live555 源码分析:SETUP 的处理
live555 源码分析:PLAY 的处理
live555 源码分析:RTSPServer 组件结构
live555 源码分析:ServerMediaSession
live555 源码分析:子会话 SDP 行生成
live555 源码分析:子会话 SETUP
live555 源码分析:播放启动