live555学习笔记8
八 RTSPClient分析
有RTSPServer，当然就要有RTSPClient。
如果按照Server端的架构，想一下Client端各部分的组成可能是这样：
因为要连接RTSP server，所以RTSPClient要有TCP socket。当获取到server端的DESCRIBE后，应建立一个对应于ServerMediaSession的ClientMediaSession。对应每个Track，ClientMediaSession中应建立ClientMediaSubsession。当建立RTP Session时，应分别为所拥有的Track发送SETUP请求连接，在获取回应后，分别为所有的track建立RTP socket，然后请求PLAY，然后开始传输数据。事实是这样吗？只能分析代码了。
testProgs中的OpenRTSP是典型的RTSPClient示例，所以分析它吧。
main()函数在playCommon.cpp文件中。main()的流程比较简单，跟服务端差别不大：建立任务计划对象－－建立环境对象－－处理用户输入的参数(RTSP地址)－－创建RTSPClient实例－－发出第一个RTSP请求（可能是OPTIONS也可能是DESCRIBE）－－进入Loop。
RTSP的tcp连接是在发送第一个RTSP请求时才建立的，在RTSPClient的那几个发请求的函数sendXXXXXXCommand()中最终都调用sendRequest()，sendRequest()中会跟据情况建立起TCP连接。在建立连接时马上向任务计划中加入处理从这个TCP接收数据的socket handler：RTSPClient::incomingDataHandler()。
下面就是发送RTSP请求，OPTIONS就不必看了，从请求DESCRIBE开始：
参数responseHandler是调用者提供的回调函数，用于在处理完请求的回应后再调用之。并且在这个回调函数中会发出下一个请求－－所有的请求都是这样依次发出的。使用回调函数的原因主要是因为socket的发送与接收不是同步进行的。类RequestRecord就代表一个请求,它不但保存了RTSP请求相关的信息，而且保存了请求完成后的回调函数－－就是responseHandler。有些请求发出时还没建立tcp连接，不能立即发送，则加入fRequestsAwaitingConnection队列；有些发出后要等待Server端的回应，就加入fRequestsAwaitingResponse队列，当收到回应后再从队列中把它取出。
由于RTSPClient::sendRequest()太复杂，就不列其代码了，其无非是建立起RTSP请求字符串然后用TCP socket发送之。
现在看一下收到DESCRIBE的回应后如何处理它。理论上是跟据媒体信息建立起MediaSession了，看看是不是这样：
此函数被删掉很多枝叶，所以发现与原版不同请不要惊掉大牙。
的确在DESCRIBE回应后建立起了MediaSession，而且我们发现Client端的MediaSession不叫ClientMediaSesson，SubSession亦不是。我现在很想看看MediaSession与MediaSubsession的建立过程:
我可以告诉你，MediaSession的构造函数没什么可看的，那么就来看initializeWithSDP()：
内容太多，不必看了，我大体说说吧：就是处理SDP，跟据每一行来初始化一些变量。当遇到"m="行时，就建立一个MediaSubsession，然后再处理这一行之下，下一个"m="行之上的行们，用这些参数初始化MediaSubsession的变量。循环往复，直到尽头。然而这其中并没有建立RTP socket。我们发现在continueAfterDESCRIBE()中，创建MediaSession之后又调用了subsession->initiate(simpleRTPoffsetArg)，那么socket是不是在它里面创建的呢？look:
是的，在其中创建了RTP/RTCP socket并创建了RTPSource，创建RTPSource在函数createSourceObjects()中，看一下：
可以看到，这个函数里主要是跟据前面分析出的媒体和传输信息建立合适的Source。
socket建立了，Source也创建了，下一步应该是连接Sink，形成一个流。到此为止还未看到Sink的影子，应该是在下一步SETUP中建立，我们看到在continueAfterDESCRIBE()的最后调用了setupStreams（），那么就来探索一下setupStreams():
仔细看看注释，应很容易了解此函数。