Freeswith and dobuango RTCP option RTCP-MUX Problems

This article is from csdn lidp http://blog.csdn.net/perfectpdl. please refer to this Article. Thank you.

I have created a freeswitch kernel research and exchange group, 45211986. Welcome to join. In addition, we provide the SIP-based communication server and client solution,

Develop the SIP/IMS video client and support access to sipSwitch, IMS core network, supported
Voice, video, and instant messaging functions. The video formats support h263, h264, and MPEG4 soft encoding solutions. The hardware coding/decoding interface is provided for interconnection and servers. If you are interested, contact me.

in VoIP communication, RTP is used for media data transmission, and RTCP is used for media transmission information feedback. The feedback aims to allow the receiver to adjust itself based on the feedback content, such as packet loss statistics, when the packet loss rate reaches a certain percentage, the party receiving the RTCP statistics will adjust its bit rate and frame rate to reduce bandwidth usage, for example, using RTCP to notify key frame requests (similar to the info method ), there are a lot of related extensions, there is a RTCP-MUX extension, recently tested QoS in doubango, found freeswitch to doubango RTCP feedback, network layer reports ICMP inaccessible, the client does not receive RTCP feedback, the reason for the failure of QoS is that RTCP-MUX is a ghost. doubango supports this extension, but freeswitch does not, the purpose of this extension is to send
RTCP packets on the RTP Port. Generally, the port of the RTCP packet is RTCP port + 1. If this extension is supported, indicates that the receiving end receives RTCP packets on the RTP Port, instead of RTP + 1. so handle this problem The method is to disable the extension on the client. Otherwise, the QoS capability is invalid.