Meetings created with meetingId yy6vwndol0ras8lpskeyjjsryzhgznwwnlok4cmm can't be joined

[Ithanil]

Get yourself some popcorn.

Describe the bug

A CREATE call with the abovementioned meetingId=yy6vwndol0ras8lpskeyjjsryzhgznwwnlok4cmm and without a specified voiceBridge (or external voice bridge disabled) will lead to a meeting with voiceBridge=99999 (which shouldn't be an issue in itself?) and an internal meeting ID of e.g. -1730718410132, which is only the timestamp part and does not match the internalMeetingID determined by the BBB server. This is a problem, because e.g. further requests like a JOIN call towards that meeting will fail:

Steps to reproduce the behavior:

1. Prepare a Scalelite with at least one BBB Server added (can be 2.7 or 3.0, doesn't matter).
2. Prepare an API-Mate window with the secret of SL and use as meetingId (and name, but doesn't matter) the value yy6vwndol0ras8lpskeyjjsryzhgznwwnlok4cmm. Make sure the field voiceBridge is empty.
3. Execute the create call, observe the fields voiceBridge and internalMeetingID in the response.
4. Execute the join call, observe the error message from the screenshot above.

Expected behavior

The meeting should be created with sane voiceBridge and internalMeetingID values. It should be possible to join the meeting without issues.

Additional context

I think the problem is caused here:

scalelite/app/models/meeting.rb

Line 203 in 3880dcd

def self.allocate_voice_bridge(meeting_id, voice_bridge = nil)

Although I do not yet fully understand what exactly is going wrong, removing

scalelite/app/models/meeting.rb

Line 209 in 3880dcd

seed = Digest::SHA256.digest(meeting_id).unpack('QQ').inject { |val, n| (val << 64) | n }

and creating the prng without pre-determined seed like prng = Random.new() resolves mitigates the issue.

EDIT / Update

The same problem also appears if one either hard-codes the voiceBridge to be 99999 or uses API-Mate directly against a BBB-Server and enters 99999 as voiceBridge. So it turns out this problem is not originally caused by Scalelite. I will still leave this issue open, because I think the fixed seed here doesn't help with alleviating that bug and I fail to understand the benefit it provides.

New proposed workaround
If one would want to keep the seeding as is, the following could be a workaround until the issue is fixed in all supported BBB versions:
After line

scalelite/app/models/meeting.rb

Line 226 in 3880dcd

tries += 1

, add:

next if voice_bridge == max_voice_bridge

with max_voice_bridge = "9" * voice_bridge_len defined at the beginning of the method.

EDIT: According to newer insights the parameter should rahter be called test_voice_bridge and should be configurable.

[kepstin]

Interesting - Can you please open an issue against BigBlueButton (or link one if you have already opened it) for the problem where meetings fail to start if the voice bridge number is all "9"s?

The purpose for seeding the RNG based on the meeting ID is to make the voice bridge number (relatively) stable for meetings - i.e. multiple instances of the same meeting will tend to have the same voice bridge number. This is convenient for when the BigBlueButton servers are configured for dial-in support.

[Ithanil]

Interesting - Can you please open an issue against BigBlueButton (or link one if you have already opened it) for the problem where meetings fail to start if the voice bridge number is all "9"s?

The purpose for seeding the RNG based on the meeting ID is to make the voice bridge number (relatively) stable for meetings - i.e. multiple instances of the same meeting will tend to have the same voice bridge number. This is convenient for when the BigBlueButton servers are configured for dial-in support.

Thanks for your comment! We are using dial-in support, but basically understood the voice bridge numbers as completely (pseudo-)random / unpredictable so far.

I am going to open an issue later in the evening, but have to move right now (it's already late here).
I strongly suspect the only affected voice bridge is the number set for testVoiceBridge in /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties (or corresponding override file). Per default it is:

# Test voiceBridge number
testVoiceBridge=99999

[kepstin]

We are using dial-in support, but basically understood the voice bridge numbers as completely (pseudo-)random / unpredictable so far.

This is mostly dependent on the external integration you are using. In order to get the same conference number, it has to re-use the same meeting ID for a series of meetings. If it's creating a new meeting ID each time, then it can't make use of this feature. (Re-using the same meeting ID also makes retrieving recordings more efficient, so it's recommended when possible)

I strongly suspect the only affected voice bridge is the number set for testVoiceBridge in /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties (or corresponding override file).

It would make sense to add a configuration option to scalelite for this, then - provide the test voice bridge number as a configuration option, and have the voice bridge number generation automatically generate a new number in case of conflicts. It could even be set to match BigBlueButton's default by default.

[Ithanil]

It would make sense to add a configuration option to scalelite for this, then - provide the test voice bridge number as a configuration option, and have the voice bridge number generation automatically generate a new number in case of conflicts. It could even be set to match BigBlueButton's default by default.

Yeah, that's basically what I recommended as a workaround in my issue above. Just that the problem has actually nothing to do with a maxVoiceBridge and thus the parameter should be named properly + made configurable.

Nevertheless, I feel like this is still an issue with BBB. The API reference explicitly states

Voice conference number for the FreeSWITCH voice conference associated with this meeting. This must be a 5-digit number in the range 10000 to 99999.

and does not mention a special testVoiceBridge number as an exception. Thus, the BBB server does not behave as expected, even if the configuration is left at default.
I will open an issue for BBB and let you guys decide what to do with this. ;-)