Further details of RTP and RTCP

See: Chapters 28 and 29 of Douglas E. Comer and David L. Stevens, “Internetworking with TCP/IP, Volume III: Client Server Programming and Applications, Linux/POSIX Version”, pp. 467-513 [Comer 2001].

Note that an important aspect of RTCP is the rate of sending reports.

“It is RECOMMENDED that the fraction of the session bandwidth added for RTCP be fixed at 5%.” [RFC 3550]
“It is also RECOMMENDED that 1/4 of the RTCP bandwidth be dedicated to participants that are sending data so that in sessions with a large number of receivers but a small number of senders, newly joining participants will more quickly receive the CNAME for the sending sites.” [RFC 3550]
Senders can be divided into two groups “… the RECOMMENDED default values for these two parameters would be 1.25% [active senders] and 3.75% [inactive senders] …”.[RFC 3551]

⇒ inactive senders ≅ receivers should generate at a rate of ~3.75% of the session traffic of course: receivers on receive-only links can not generate any reports

Slide Notes

[Comer 2001] Douglas Comer and David L. Stevens, Internetworking with TCP/IP. Vol. III. Client-server programming and applications, Linux/POSIX sockets version. Upper Saddle River, N.J: Prentice Hall, 2001, ISBN: 978-0-13-032071-1.

[RFC 3550] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, ‘RTP: A Transport Protocol for Real-Time Applications’, Internet Request for Comments, vol. RFC 3550 (INTERNET STANDARD), Jul. 2003 [Online]. Available: http://www.rfc-editor.org/rfc/rfc3550.txt Links to an external site.

[RFC 3551] H. Schulzrinne and S. Casner, ‘RTP Profile for Audio and Video Conferences with Minimal Control’, Internet Request for Comments, vol. RFC 3551 (INTERNET STANDARD), Jul. 2003 [Online]. Available: http://www.rfc-editor.org/rfc/rfc3551.txt Links to an external site.

Transcript

[slide108] Now, one of the things that changed, as we'll see, is using this data from RTCP, they said the recommended fraction of the session bandwidth for RTCP should be limited to 5%. So of all the bandwidth we have, we're going to give 5% of it to the control traffic, we are going to take a quarter of that and dedicate it to participants who are going to be able to send information in, saying I've joined the session. And then we'll divide the senders into two different groups, those who are active and those who are not, and we'll give 1.25% to the active senders, and will give 3.75% to the inactive receivers, mostly listening sender who don't frequently send things, but there might be large numbers of them. So the inactive senders will approximately generate traffic at a rate of about 3.75% of total session bandwidth. Why do they need to send packets? They're not sending any audio, why do they still need to send RTCP packets? Because we have to know if they're receiving things and they need to give us feedback information otherwise they might not be receiving anything, we might have a problem and we would never detect it. So even the receivers have to send some control information back.