On C9 we have scenario of recovering where sfumanager can lose track of a barbell and a new barbell will be set up. For this to happen, there is 1 leg that is going to be removed but in 1 region there will be a barbell leaked until the end of the conference.
For the barbell leg leaked, the barbell is o going to be deactivated by timeout and all ssrc inbound context will be decommissioned, when that happens and we have already a new barbell to replace this broken one, the decommission process can remove the participant endpoint id from the user map. To mitigate this issue, this commit allow us to configure an interval where the user mapping is going to be send over barbells periodically to recovery the problem caused by decommission the old ssrc context.
This is just a safety mechanism as in C9 setting up barbell is super complex with split ownership on the 2 regions involved, for the Symphony use case this setting shouldn't be necessary
On C9 we have scenario of recovering where sfumanager can lose track of a barbell and a new barbell will be set up. For this to happen, there is 1 leg that is going to be removed but in 1 region there will be a barbell leaked until the end of the conference.
For the barbell leg leaked, the barbell is o going to be deactivated by timeout and all ssrc inbound context will be decommissioned, when that happens and we have already a new barbell to replace this broken one, the decommission process can remove the participant endpoint id from the user map. To mitigate this issue, this commit allow us to configure an interval where the user mapping is going to be send over barbells periodically to recovery the problem caused by decommission the old ssrc context.
This is just a safety mechanism as in C9 setting up barbell is super complex with split ownership on the 2 regions involved, for the Symphony use case this setting shouldn't be necessary