[Live-devel] RTCP Sender Report Flooding

PROMONET Michel michel.promonet at thalesgroup.com
Tue Jul 2 11:40:28 PDT 2013


            Hi Ross,

Thanks again for your support.

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.

However we notice that RTCPInstance constructor has an argument to say to use SSM, but the RTCPInstance have a reference to the GroupSock that know if it was created for SSM.
Setting this flag according to how groupsock was created seems to solve the problem.

For instance in testH264VideoStreamer.cpp seems to make a confusion.

00057   Groupsock<http://www.live555.com/liveMedia/doxygen/html/classGroupsock.html> rtpGroupsock(*env<http://www.live555.com/liveMedia/doxygen/html/MPEG2TransportStreamIndexer_8cpp.html#dfa09dd3866fd8ba8ab69586f9437d19>, destinationAddress, rtpPort, ttl);

00058   rtpGroupsock.multicastSendOnly<http://www.live555.com/liveMedia/doxygen/html/classGroupsock.html#f1d8b7124167e2a5fc12ba3a0039346a>(); // we're a SSM source

00059   Groupsock<http://www.live555.com/liveMedia/doxygen/html/classGroupsock.html> rtcpGroupsock(*env<http://www.live555.com/liveMedia/doxygen/html/MPEG2TransportStreamIndexer_8cpp.html#dfa09dd3866fd8ba8ab69586f9437d19>, destinationAddress, rtcpPort, ttl);

00060   rtcpGroupsock.multicastSendOnly<http://www.live555.com/liveMedia/doxygen/html/classGroupsock.html#f1d8b7124167e2a5fc12ba3a0039346a>(); // we're a SSM source

00061

00062   // Create a 'H264 Video RTP' sink from the RTP 'groupsock':

00063   OutPacketBuffer::maxSize<http://www.live555.com/liveMedia/doxygen/html/classOutPacketBuffer.html#27f745b288df55bbfb39a7564fe40596> = 100000;

00064   videoSink<http://www.live555.com/liveMedia/doxygen/html/testDVVideoStreamer_8cpp.html#d0d95ae4c5a49da3e034e3bb23adea20> = H264VideoRTPSink::createNew<http://www.live555.com/liveMedia/doxygen/html/classH264VideoRTPSink.html#25c497ea6eccc5de3a22677acbcee140>(*env<http://www.live555.com/liveMedia/doxygen/html/MPEG2TransportStreamIndexer_8cpp.html#dfa09dd3866fd8ba8ab69586f9437d19>, &rtpGroupsock, 96);

00065

00066   // Create (and start) a 'RTCP instance' for this RTP sink:

00067   const unsigned estimatedSessionBandwidth = 500; // in kbps; for RTCP b/w share

00068   const unsigned maxCNAMElen = 100;

00069   unsigned char CNAME[maxCNAMElen+1];

00070   gethostname((char*)CNAME, maxCNAMElen);

00071   CNAME[maxCNAMElen] = '\0'; // just in case

00072   RTCPInstance<http://www.live555.com/liveMedia/doxygen/html/classRTCPInstance.html>* rtcp

00073   = RTCPInstance::createNew<http://www.live555.com/liveMedia/doxygen/html/classRTCPInstance.html#baf83bbbca227116e81dac5a9bf0ce3c>(*env<http://www.live555.com/liveMedia/doxygen/html/MPEG2TransportStreamIndexer_8cpp.html#dfa09dd3866fd8ba8ab69586f9437d19>, &rtcpGroupsock,

00074                             estimatedSessionBandwidth, CNAME,

00075                             videoSink<http://www.live555.com/liveMedia/doxygen/html/testDVVideoStreamer_8cpp.html#d0d95ae4c5a49da3e034e3bb23adea20>, NULL<http://www.live555.com/liveMedia/doxygen/html/UsageEnvironment_8hh.html#070d2ce7b6bb7e5c05602aa8c308d0c4> /* we're a server */,

00076                             True<http://www.live555.com/liveMedia/doxygen/html/Boolean_8hh.html#4ef9178d6bd8f7ce58133fa8c3805842> /* we're a SSM source */);
The RTCPIntance is create with SSM flag set but it use the ASM GroupSock, isn't it ?

Don't you think it could be more robust to remove the SSM argument in RTCPInstance constructor and get it from RTCPgs->isSSM() ?

Thanks & Regards,

            Michel.

[@@ THALES GROUP INTERNAL @@]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130702/0485be59/attachment.html>


More information about the live-devel mailing list