I think we can maybe look into doing a pilot project for adding dial in support soon. The hard part of this tasks is the scale required especially since it requires to purchase resources out to another network (the PSTN or Telephone System).
For starters getting some data would help us scale the pilot property. If we can collect some data such as:
who is interested in this feature (and who would be willing to help beta test it)
where they are located and/or where (country) they are willing to call into
what kinda usage would they have (how many simultaneous calls)
This would be a great start to start looking into an implementation!
I’m one of the sysadmin in the Tor Project, and we’ve been using meet.coop’s BBB instance with great success for all sorts of things:
all hands, ad-hoc, or weekly team meetings
training sessions
“office hours”
“demo days”
hack week
It is working great! Sometimes we have people in South America that have trouble getting through on audio, but I’m not sure it’s due to BBB or the link… Hard to tell…
Now to answer your questions directly…
i’d say half a dozen to a dozen or so. Our largest meetings are between 30 to 50 people, I think, and I’d say we’d typically have 5-6 people in the largest meeting on phone. But who knows?
Absolutely, that would work great for us.
I have not tested SIPdroid itself. I have used the built-in SIP dialer that’s part of the stock Android “Phone” app (which, amazingly, is often missing from commercial Android deployments: it’s part of LineageOS and CalyxOS for example)… It works fine for my purposes.
I’d be happy to test a SIP endpoint if that’s useful. I use baresip on my desktop…
For business hosting, particularly in Canada, I recommend https://voip.ms, which has good service and pricing. I don’t think you’d need to setup Asterisk, to be honest: in theory freeswitch is a complete replacement and can do routing and all that stuff. I’d advise against it, actually: having two PBX systems to learn will make training your staff needlessly hard.
For me, the killer feature is to be able to bridge audio from my computer into BBB without firing up a web browser that eats all those precious computer resources and power. During office hours, I have a browser window open all day waiting for people to jump in for questions, and it’s sometimes spinning up my CPU fan, just doing nothing. If I could just sit there with my SIP client instead, it would be much more lightweight, and I could still attend.
This could also allow for some cool features like piping music on hold, which I’m currently doing with Pipewire hacks.
This is so important. If meet.coop is serving people in the global-South - or just any people who don’t have lots of credit or bandwidth on their phones - we need to be very careful about the amount of resource that our platform demands on the user’s device. This is basic Design Justice.
Do we in fact have a policy or stance on just what kinds of end-user devices we mean to support? (Defining bands of capability? like we define bands of ‘fair use’?) A spectrum, of course. But how many points are there on that spectrum? what are their respective priorities for our provisioning? and how different does the platform need to look, from each of these different device standpoints?
as an aside, people should look at this talk before digging too deep into FreeSwitch land. I’m not exactly sure (i skipped through a lot of the talk), but i suspect they might support other tools for SIP, for example they are testing Janus as an alternative backend which would replace both the current Kurento and Freeswitch backends, from what I understand. This may come in the upcoming 2.4, as experimental. See also this design document.
I’m happy to say we have been working on the pilot project for dial in participants to our Big Blue Button instance!
There are many things we would still need to figure operationally before this can be a permanent fixture, but its a challenge we will approach head on and this pilot project will give us some information to make those decision.
The metrics of this pilot project will help us understand the demand on the system and how to structure it to create a viable and sustainable model moving forward.
The First Phase of the pilot is now up and running! This phase consisted of:
Acquiring a Canadian phone number
Configuring ca.meet.coop to accept calls from the assigned number
Configure a SIP dial-in number for use with a SIP Client. I have tested with Linphone (F-Droid, Google Play)
The second phase is now up and running. This phase consisted of
Acquiring a European phone number
Configuring de.meet.coop to accept calls from the assigned number
Configure a SIP dial-in number for use with a SIP Client. I have tested with Linphone (F-Droid, Google Play)
How It Works
Conference PIN will be generated when you start a meeting on both CA and DE servers. It will be displayed at the top of the chat. You must provide this number along with the dial-in number to the individuals that wish to join the conference via the phone.
The two dial in options. Please use the correct numbers based on the geographic location
CA Server
SIP at 309817101@sip.ca.meet.coop
Dial-in to Canada (Ontario) at 807.788.MEET(807.788.6338)
DE Server
SIP at 309817102@sip.de.meet.coop
Dial-in to Spain (Barcelona) at (34)932208649
When you dial in you will be asked for the Conference PIN Number. Once entered you will be placed into the room.
During the call the following touch-tone options are available
0 - Mute/UnMute
This is a normal mute, just your outgoing audio. You can still hear what is going on.
* - Mute/UnMute
This Mute is for outgoing AND incoming audio. You will not hear anything, and no one will hear you.
Increase YOUR volume 3 Talk Volume Up 2 Talk Volume Zero 1 Talk Volume Down
Increase everyone else’s volume 6 Listen Volume Up 5 Listen Volume Zero 4 Listen Volume Down
Energy level is a threshold that dictates the level at which a person is determined to be speaking versus the background noise received. 9 Energy Up 8 Energy Zero 7 Energy Down
Things to keep in mind:
Conference PIN is randomly generated every time you start a new meeting. There is no way to predict what it will be until you create the meeting.
You must have at least ONE user in BBB with voice connected in the BBB client otherwise the PIN will not work.
If your room is set to “mute on join” users will need to press 0 (unmute) first to be able to talk.
As always please provide any feedback in this thread
Thank you for all your expertise anarcat! I pretty much agree with you on all the points!
VOIP.MS if a little-known gem in the sip industry and they are great. My biggest issue is how to expand this internationally. The international DIDs are limited to 2 channels. I’ve contacted them to see if there is a feasible solution to this problem
I agree, if we can figure out a way to keep all the sip stuff on the voip.ms platform, we can leverage it to do routing, such as leverage our international phone numbers to connect to any of our servers. But there is quite a bit of operational work that would need to get done!
Thank for this very interesting.
We are still in the process of moving to 2.3, i dont think 2.4 will be something that will be available in the near future. So with that, we spent the effort on free switch to get these features now
Guess we just have to port them when 2.4 comes along =)
thanks @Yurko for brining in your great expertise with SIP Dial-in! I’ve tried it a few weeks ago and it worked great. It is nice to see a different icon for users dialing in to distinguish them from web users.
I’m curious to hear from the user members who have asked for this. How does it work for you, @b5baxter@wolcen@mnoyes@anarcat ?
This is terrific @Yurko thanks so much for picking this up and running with it. Time to develop some user documentation. This calls for a thread under Product strategy category? Perhaps new sub-thread, Documentation/FAQ? Who’s to open this? @Yurko maybe, you’re currently the wizard of dial-in
Enter the conference pin number provided at the top of the room
Press 0 to mute/unmute
The closest thing to docs we have right now is this post above.
I will work on better documentation soon.
Currently it is only on the meet.coop ca server. (dail-in for the de server will be active within the next week, just waiting for the phone number to be provisioned)
As of last night the call in details are listed at the top of the room in the CA server. Will do the same for DE when its ready.
Yep, that’s my sense of things also. A lot may be down to ‘the last mile’ of the journey? Can we systematically engage with that (eg firm guidance on OK browser/OS combinations) or is it haphazard?
Thanks so much for doing this! So, my hope is that the dial-in number(s) will appear in the invite box. Will it require a separate sign-in/app for the SIP?
After a week of testing, last night we have just added the text CA server
We will add similar to the DE server as soon as the new number is provisioned
The sip option has two methods
Option one - Plain old telephone number that can be dialed with any phone (long distance charges apply see your carrier for details)
Option two - a sip URI that requires a sip phone like such as linphone.