> We didn’t understood deeply what brings the RTCP sender report flooding, but > we has such a behavior using multicast stream that share the same multicast > port. > Wireshark analysis show that an RTCP sender report is forwarded between 2 > RTSP servers without ends. > > We tried to understand the comment in RTCP.cpp that decide to resend a packet > when SSM flag is set and packet comes from another host. > It could be again a consequence of the multicast problem in linux using ASM.
Yes, that's your problem. Because of a bug in the Linux kernel, you should not (if you are running Linux) have two different applications receiving multicast streams that have the same port number (even if the multicast IP addresses are different). > Don’t you think it could be more robust to remove the SSM argument in > RTCPInstance constructor and get it from RTCPgs->isSSM() ? No, that would be wrong, because the "isSSM()" function (which, I admit, has a misleading name) tells you whether the "groupsock" object was created to *receive* a SSM stream - i.e., whether it was given an IP source address, in addition to a multicast address. It doesn't tell you whether or not the groupsock was created to *send* a SSM stream. > For instance in testH264VideoStreamer.cpp seems to make a confusion. No, there's no 'confusion' here. > The RTCPIntance is create with SSM flag set but it use the ASM GroupSock, > isn’t it ? No it doesn't. The code explicitly choses an IP multicast address from the 'SSM' range, and sends it as a SSM stream. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
