Using Rendezvous as a queue system for questions ?

I want to organise webinars where I present content first en then I take questions from the audience one by one if needed.  Audience is 40 people watching the stream.   Can I send them all the RDV link and tell them to use it when they have a question.   

My idea :  

1. They would appear as incoming connections, and I would take them one by one into the broadcast and have a talk with them.  Then they disconnect, and we can have the next one.  

2. Would NOT taking (accept) all connections straight away save me the bandwidth during the wait ?

3. What happens if number 8 uses the link (max of 7), what kind of message do they get ? Can I instruct them to wait in this case for the queue to get empty? 

4. I guess I need to have shots ready that can handle the different incoming sources.   I could have one for the actual live and one for the next speaker where we already configure the source ? 

Anyone else did this ?   Any suggestions ? 

If RDV does not work, I will use a dedicated video chat queue tool on a separate machine and just capture that of course

Thanks for your help.  Kristof.   

7replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Keep in mind that the bandwidth of the participants can have an impact. You may need some way to ensure each guest has enough bandwidth. Bandwidth should only be used for guests in the call so you may be able to keep that part under control assuming guests otherwise have the bandwidth. Each new guest would require a new Shot so that might make it awkward unless you can manage that. 

    You may want to do a trial run with some friends/business associates to test how accepting and then removing guests works.

    Reply Like
  • Thanks for the info.  Indeed bandwidth is my fear in this use case.  Can you confirm that the bandwidth is not used until I accept a RDV connection ?   And yes, managing the new shots as we progress the cue seems a risk. 

    A trial run is a must for sure.   Also the sound is not trivial I noticed.  A feedback loop needs to be avoided. 

    Do you know what happens when the max is reached. What error is shown to number 8 trying to use the link ? 

    Reply Like
  • Kristof Danckaert Working on getting those details 

    Reply Like
  • Kristof Danckaert  and CraigS

    I believe the bandwidth is not consumed until a guest is accepted. So that would meet the requirements of this request. However, what would be REALLY cool is a text chat function, to allow a producer to converse with a prospective Rendezvous participant to understand the details of what they will talk about.

    Imagine "talk radio" - but a video version - where the switchboard operator asks the guest what they will talk about - and puts it on a dashboard for the on-air host.

    GK

    Reply Like
  • Greg Kuhnert said:
    what would be REALLY cool is a text chat function, to allow a producer to converse with a prospective Rendezvous participant to understand the details of what they will talk about.

     That would be innovative. Do make that feature request and explain why. Not only communicating with current guests but those "waiting in the queue."

    Reply Like
  • CraigS - The other benefit here, is that you could then easily publish a rendezvous link publicly, and filter who goes to air based on text chat.

    I think its  a good idea - but perhaps one to keep on the back burner... I personally think some of the existing functionality needs to be matured and stabilised before adding new items into the mix.

    GK

    Reply Like
  • Greg Kuhnert You could submit it noting that reliability takes precedence. The developers do keep back burner feature lists.

    Reply Like
reply to topic
Like Follow
  • 7 mths agoLast active
  • 7Replies
  • 270Views
  • 3 Following