[Live-devel] RTCP Sender Report Flooding

[PROMONET Michel]

            Hi Ross,

Thanks for your support.

Actually I try to have some support from a commercial linux in order to see I it's possible to fix this very old problem...

Regards,

            Michel.

[@@ THALES GROUP INTERNAL @@]

De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson
Envoyé : mercredi 3 juillet 2013 02:45
À : LIVE555 Streaming Media - development & use
Objet : Re: [Live-devel] RTCP Sender Report Flooding

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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130703/f2f82926/attachment-0001.html>