基于live555实现流媒体代理服务器（3）

基于live555实现rtsp代理服务器总体业务逻辑流程，现在就可以梳理一下了，参见协议流程图：

注意几点即可：

1、在rtsp代理服务器收到describe消息的时候，通过streamId首先查询前向的rtsp url；然后通过rtsp代理客户端发送options、describe等消息，都是需要异步通信的，通过上一篇文章的介绍的异步通信方式即可；直到等到了前向的sdp，我们才能给后向回复带sdp的200 OK响应；

2、setup消息无需关系顺序，原流程无需修改，上面图片可能少画了一个setup消息，如果是音视频的话，应该有两个setup消息，一个audio、一个video；当然，也可能更多，3d视频的话，也许有两个video的setup等等；

3、在rtsp代理服务器收到play消息的时候，还需要再次进行异步阻塞等待，此时需要检查前面rtsp代理客户端发送的多个setup消息是否都收到了响应，如果少收到了一个响应，就意味着后向代理的流少一个通道；等待的方式还是异步递归阻塞；一般来说检查这个参数即可：

//判断是否所有媒体子会话都发送了setup消息，或建立了媒体通道
Boolean ProxyRTSPClient::StreamIsReady()
{
  if(!fSetupQueueTail) {
    return True;
  }

  return False;
}

4、还是关于上面第三条的问题，为什么需要等待所有的setup响应完成？其实，这里不等待的话，媒体代理也是可以完成的，但是如果后向play发送的比较快，而前向rtspclient响应的setup的200OK比较慢的话，就会出现丢失媒体子会话的问题，并不是总是会引起问题的。还有一个就是live555默认的业务逻辑，只要前向回复了至少一个setup响应，那么他就认为可以完成后向代理了；通常情况下，这是不对，你要么代理全部子流，要不不要代理，代理一部分是咋回事呢？看看英文的官方解释：

void ProxyRTSPClient::continueAfterS