GNOME Bugzilla – Bug 567828
rtpmanager and RTCP BYE packet
Last modified: 2009-01-23 11:16:58 UTC
rtpmanager should not schedule RTCP BYE packets as any other RTCP report. RTCP BYE is used to indicate peer we are going to leave session, it's also used to solve SSRC collisions, delaying its sending can disturb a media stream processing for a long.
The algorithm in section 6.3.7 of RFC3550 is executed. Why do you think we should do it differently?
RTCP messages are scheduled to limit bandwidth usage. When sending a BYE we are indicating no more RTP will be sent for the indicated SSRC. On a SSRC collision beetween two peers A and B: If B sends a BYE 5 seconds after finding the collision due to scheduling of RTCP packets the peer A will still wait for data during 5 seconds while we already stopped streaming using 'old' SSRC. Sending BYE packets as soon as possible is a fair way to indicate peer it can free some resources or discard som data. #6.3.7 indicates BYE can be sent immediatly if the group size estimate members is less than 50.
ok, sending faster (immediatly) for group sizes < 50 would be doable, we just need to tweak the next timeout and trigger a reconsidder.
If group size could be configurable it will also be a good thing for distributed infrastructures for large applications (handling hundreds of RTP streams on a LAN for RTP mixers/conferences for ex. ). This later point differs from RFC but is interesting in some particular cases (reducing network Bandwidth, infrastructure latency).
Created attachment 126517 [details] [review] possible patch something like this would do the trick.
commit ccdc28fc6dc1eb5250b6414427927c84d2026fe9 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Jan 23 12:13:00 2009 +0100 Send BYE packets immediatly for small sessions When the number of participants is less than 50, the RFC allows for sending the BYE packet immediatly instead of using the regular BYE timeout. Fixes #567828.