licode/erizo 中 rtcp 的转发与收敛

在每个mediaStream中 都保存着一个 std::shared_ptr<RtcpProcessor> rtcp_processor_ ，该结构的类图如下：

该RtcpProcessor类型在Stream的中的实例化未RtcpForwarder 类型，在构造函数中创建，在 MediaStream::setRemoteSdp 中更新里面的 sourceSsrc，所以必须在调用setRemoteSdp前，调用Stream的 setVideoSourceSSRC 和 setAudioSourceSSRC 以确保转发有效。

那么RtcpForward 如何起作用的呢？

首先， 在MediaStream::initializePipeline() 中会将 rtcp_processor_ 作为服务（service）传入，并创建具体的调用逻辑结构 RtcpProcessorHandler 。即，在Stream的中通过调用AddFront 将 RtcpProcessorHandler 加入 pipeline 中。

因为继承了Handler 所以他的处理类型是HandlerDir::BOTH，即双向的。在AddFront调用中，处理流入数据的越早调用越晚处理数据，所以 RtcpProcessorHandler 是最后处理的读入的rtp /rtcp 数据。

其次，RtcpProcessorHandler中通过getService的方式，将RtcpForwarder 映射到自己的 processor_ 成员中。

RtcpForward 具体作用

数据流入时，只是存起了senderReport的一些信息，其他的什么都没做，包括发布者的带宽、rtcp反馈都没处理。

数据流出时，会调用analyzeFeedback 去处理feedback类型的rtcp。未完待续。。。