start webrtc echo test again

[bendark]

hi @ all

i cant start the webrtc echo test again after answering  this question (This is a private echo test.  Speak a few words.  Did you hear audio? ) with no !!!

there is no problem with flash player echo test !!!




best regards

[Fred Dixon]

Hi Bendark,

Are you referring to your own BigBlueButton server?  If so

1.  What version did you install?

2.  Did it work before?

3.  Did you get any errors on install?

4.  Can you test the same browser on

  http://demo.bigbluebutton.org/

and let us know if it works.

Regards,... Fred

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

--

BigBlueButton Developer

http://bigbluebutton.org/

@bigbluebutton

[bendark]

hi fred

it doesnt work on http://demo.bigbluebutton.org/ , the same issue

it start when answering this question (This is a private echo test.  Speak a few words.  Did you hear audio? ) with yes again and again

but when i answer with no . it doesnt start anymore , only the flash player test start

i tested on http://mconf.org/   , its working as expected , no errors

i tested on https://test-install.blindsidenetworks.com -------> it doesnt work


i am testing from ubuntu 16.04 desktop , google chrome 55.0.2883.87 (64-bit)  and  firefox 50.1.0

i installed bbb 1.1beta , no install errors ,only this

“Failure to download extra data files” with ttf-mscorefonts-installer on Ubuntu 16.04

http://askubuntu.com/questions/766491/failure-to-download-extra-data-files-with-ttf-mscorefonts-installer-on-ubuntu



best regards

Am Sonntag, 15. Januar 2017 05:46:26 UTC+1 schrieb Fred Dixon:

Hi Bendark,

Are you referring to your own BigBlueButton server?  If so

1.  What version did you install?

2.  Did it work before?

3.  Did you get any errors on install?

4.  Can you test the same browser on

  http://demo.bigbluebutton.org/

and let us know if it works.

Regards,... Fred

On Sat, Jan 14, 2017 at 6:21 PM, 'bendark' via BigBlueButton-dev <bigblueb...@googlegroups.com> wrote:

hi @ all

i cant start the webrtc echo test again after answering  this question (This is a private echo test.  Speak a few words.  Did you hear audio? ) with no !!!

there is no problem with flash player echo test !!!




best regards

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

[Fred Dixon]

Hi,

> i cant start the webrtc echo test again after answering  this question (This is a private echo test.  Speak a few words.  Did you hear audio? ) with no !!!

This is how BigBlueButton is designed.  To understand why, a bit of background on what's actually happing when the user connects.

If the user is on FireFox or Chrome, then when the BigBlueButton client first loads it attempts to connect the user's audio via WebRTC (Plan A) and, if unsuccessful, then falls back to Flash audio (Plan B).  If the user is using a browser that doesn't support WebRTC, then the client goes directly to Plan B.

With WebRTC audio, your browser needs to make two network connections: a web socket connection via TCP/IP and real-time protocol (RTP) connection via UDP to FreeSWITCH.  If an error occurs in establishing either of these network connection, you will see one of the error messages in the client 

  http://docs.bigbluebutton.org/install/install.html#client-webrtc-error-codes

and the client will fall back to connecting with Flash.

However, if both network connections are successful, you'll the client will display the echo test.  Why?  Even with a successful network connection, we've found that there could still be firewall issues that prevent the RTP packets from transmitting or receiving, which results in either you can't hear others or other's can't hear you.  The echo test is a way to determine if there is any such issues exist.  Furthermore, in the echo test, the user's audio is being transmitting from their client to the BigBlueButton server (specifically to FreeSWITCH) and back again to their speaker.  It's a round trip of the packets, so the question "Can you hear yourself" is another way of determining the microphone is working, the packets are successfully transmitted/received, and the speakers are working.

If the user clicks 'Yes', then the client enters them into the conference.  At this point, we're pretty much 100% certain that audio is working -- (a) the microphone is picking up audio, (b) the audio is successfully transmitted via RTP, (c) the audio is successfully received via RTP, and (d) the audio comes out through the user's speaker and is hear.  The echo tests significantly reduces scenarios where a student enters the audio conference and -- if one of (a), (b), (c), or (d) is not working, encounters the problem during the live class and starts typing "Can anyone hear me?" or, if the user is the instructor, students start typing into the chat "We can't hear you".  We want to avoid these scenarios at all costs.

The point of describing the above is to see there is a *lot* that happens under the hood that is invisible to the user (just as there is a lot that happens when you make a cell phone call -- it almost always works, but it's pretty complex).  So the echo test is pretty important for ensuing the WebRTC connection is fully working.  

HOWEVER, if the user clicks 'No', then the BigBlueButton client assumes that something didn't work with WebRTC -- in other words, one or more of (a), (b), (c), or (d) failed and it's really hard to figure out which one.  At this point, the client falls back to Plan B and uses Flash.

While Flash is not as good audio as WebRTC, it's still pretty good and gives the user more options to troubleshoot, such as selecting a different microphone.  In the past, the browser's implementation of WebRTC didn't give a uniform API to letting the user select the microphone -- it always picks the default microphone given by the operating system.  As an aside, that's why the Setting Up Audio video shows how the user can changed their default microphone in Mac OS X and Windows, see

  https://www.youtube.com/watch?v=4Y__UsUrRx0

With Flash audio, the user can choose a different microphone which might solve (a), the media packets go through a different network connection (TCP/IP vs. UDP) which might solve (b) or (c), and the user can test their speaker -- which is still the default speaker, but it might help the user realize the problem resides with (d).

So, what you encountered with clicking 'No' is the the logic built into the BigBlueButton client to *not* attempt WebRTC audio again during the user's session.  

Why?  If the user clicked 'No', then the client must assume that something in (a), (b), (c), or (d) failed and it's likely not going to magically work again later into their session.  When the user clicks 'No', the client uses Flash-based audio and stays there for the remainder of the session.  That is, if the user later clicks the headset icon to leave the audio bridge and then clicks the headset icon to rejoin, the client will immediately join via Flash and *not* attempt WebRTC again.

If the user really wants to try WebRTC audio again, such as they switched their laptop from wireless to wired connections, they can click the refresh button on their browser and reload the BigBlueButton client anew.  On reload the client will again attempt to connect the user via WebRTC first again (and hopefully work!).

It looks like Mconf is trying WebRTC audio again when the user clicks the headset icon to leave and rejoin the audio.  We're probably not going to change BigBlueButton to try that approach as we believe that if either (a), (b), (c), or (d) was broken for the initial WebRTC attempt and won't fix itself.  Also, if WebRTC didn't work and Flash does, then taking them back to the echo test each time they attempt to rejoin the audio is going to slow down the leaving/rejoining of audio.  

So, the above is another way of saying if one of the audio paths works (WebRTC or Flash), the BigBlueButton stays with that audio for the remainder of the session.

> “Failure to download extra data files” with ttf-mscorefonts-installer on Ubuntu 16.04

Thanks for pointing this out -- as you see from the stackoverflow link, it's a known bug in 16.04.  We're hoping that the debian upstream version 3.6 of ttf-mscorefonts-installer gets into the official Ubuntu repositories for 16.04.

Regards,... Fred

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

[bendark]

hi fred

thanks for this explanation

but its not correct , because you are asking people TO try the flash echo test again and again and and again if it doesn't work , but webrtc echo test you want to try it only one time!!! sorry i cant understand your logic but its your decision!!!!!
 


best regards

[Fred Dixon]

Hi,

Your right, if they say 'No' to the first echo test (WebRTC), the client falls back to Flash.  If they say 'No' to the second echo test, it goes back to the setup microphone window for Flash.  The idea is that the user can choose a different microphone and try the echo test again.

Of course, if none of the microphones work, the echo test will not succeed (they will not hear themselves).  BigBlueButton really needs the user to click 'Yes' (I can hear myself) before joining with a microphone.  If they don't click 'Yes', they can eventually click 'Cancel' and then click the headset icon again to join the audio as Listen Only.

We could look at modifying this sequence so that if the WebRTC network connections succeeded, but the user clicked 'No' for WebRTC audio test and then 'Cancel' for Flash audio check, the client could retry the webRTC audio check when clicking the headset again (we'll call this the 'special case').  It will introduce more steps (as the user will get the echo test twice again if WebRTC fails).  This also assumes that in the four areas the audio could not work, the user has taken action to fix them. 

  (a) the default microphone is picking up audio,  <-- the user can change this in the OS settings

  (b) the audio is successfully transmitted via RTP, <-- the user can change their network connection (i.e. move from wireless to wired or, for example, turn on/off a VPN if they are using one)

  (c) the audio is successfully received via RTP, and <-- same as (b)

  (d) the audio comes out through the user's default speaker <-- the user can change this in the OS settings

Our recommendation that if the user is going to change (a) or (d), they refresh the client -- which starts the audio connection with WebRTC first.  

Why refresh?  Part of the reason is Flash reads the current list of microphones for (a) from the OS when the client loads, and that list is made available to the BigBlueButton client when it attempts to use Flash.  Unfortunately, the newly connected microphone won't appear in the list until the client reloads and Flash reads the list of microphone new.  

Still, it might make sense to try WebRTC again in the special case.  Most of the above is invisible to the user as the default choice for WebRTC audio works and, in most cases, the fallback to Flash will work as it uses the same port as the BigBlueButton client. 

Regards,... Fred

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

[bendark]

hi fred

i think you understood me very well, it s a special case , and i think that all deserve a second chance ,the webrtc and bbb-users with special cases need also a second chance

the webrtc reconnect branche still there

https://github.com/mconf/bigbluebutton/tree/webrtc-reconnect


best regards

[Fred Dixon]

Hi Bendark,

We'll take a closer look at this for a future release of BigBlueButton, but we likely won't do it as part of BigBlueButton 1.1-beta (which we are working towards getting into a Release Candidate).

We've opened an issue to track this

   https://github.com/bigbluebutton/bigbluebutton/issues/3568

Regards,... Fred

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.