We have a solution where we give end users a personalized URL. When a user hits on such a URL, she gets sent a html page that includes jitsi meet in an iframe. Often that works just fine.
In many cases, however, the user does not hear anything. We checked everything: microphones, sounds, et. On all sides everything was fine. But the user could not hear me.
However, if I give the user a single normal URL hitting the jitsi server directly, we have no audio problem. Has anybody seen this kind of issue before?
welcome to the community…!
I never tried your way but I think It would be more helpful for the community to help you if you could elaborate more with some console logs or jvb/prosody/jicofo logs whether you found something unusual or not. Or when you especially experienced the audio failing, was there any errors/warning in logs…something like that. Thanks
Bumping this issue up. We’re facing the same in production, mostly on phone browsers (including the latest version of Chrome).
We have not been able to collect logs yet on this because it’s intermittent and occurs occasionally on the customer side, but is this a known issue with iframes?
Audio works without an issue when hitting the direct URL.
When hitting the same URL via an iframe, the browser also does not show the “Allow microphone” option on the permission settings (top left). It’s as if the browser is not detecting that it’s required on the page.
@Fuji We’ll try to get logs, but it’s difficult as it’s happening intermittently. Is there any past instance of others facing this?
@Brand_Pinto Did your issue get resolved?
No, we have a docker-compose deployment using the stable-6173 release (since we’d deployed this a while back).
We have deployed that to be accessible on a different URL (let’s say abc.example.com)
Now we have a page on meet.example.com that creates an iframe to access abc.example.com.
When the user joins abc.example.com directly, everything works.
However, the audio access behaviour becomes inconsistent when they join via an iframe. Most of the time it works fine. However, phone browsers and very rarely desktop browsers seems to give this issue.
There were several issues fixed since then, so try the latest versions.
Thanks @damencho I’ll try upgrading to 7001.
Do you recall any fix that relates specifically to iframes? Just confirming since direct hits to the same deployment are working fine. I couldn’t find anything in the git logs and hence didn’t consider an upgrade to be a possible solution initially.
I don’t see the difference … but it was timing involved in some of those …