Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Video / Audio stuck on connection problems

Avatar

Former Community Member

Hi,

We have reported that in the past but didn't came to a solution: http://forums.adobe.com/thread/892584  (issue no. 1)

The scenraio is as follows

1. room with 2 parties.

2. user 1 has temporary connection problems

3. user 2 stops hearing the first and also see the video of user1 has stuck

     user 2 can still see his video

4. on re-entering the room everything is fixed.

Our questions are:

1. Can this be recovered automatically once the user 1 connection problem is resoled ?

2. Is there something we can do to identify this case using the code ? (in response we will force the user to leave and enter the room)

     we do use the mic level to track the audio level, can we use it / something similar in the userDescriptor or webcam to track this ?

It happened to us again last night, can you please have a look at your logs and investigate this problem ?

I will send the relevant account and room details to your "lccs@adobe.com" email

Thanks in advance for your help,

Eyal.

1 Reply

Avatar

Employee

If one of your users disconnects it should receive a synchronization change event (on the ConnectSession / ConnectSessionContainer). You can add a listener and “know” that something is not right.

The other clients should also receive a retractItem on the UserManager (the user should disappear from the roaster) but if it’s a short disconnect/reconnect we may “buffer” that.

In theory if the first client got disconnected and stopped publishing it should have sent some events on the various streams, then when it got reconnected it should have started publishing again, possibly on a different stream (and the other clients should have received a new stream descriptor and resubscribed on the new streams).

What would be helpful hear is really the client logs. They should show exactly what is happening to your streams. Also, if as you mention in your original thread this problem is related to P2P connections, we would not have anything in our logs.

Again, client logs would also show if your clients are connected p2p or hub&spoke.

We have some API that allows you to collect all the LCCS “traces” (you set a “trace function” and it gets called every time LCCS logs something) and you could change you application to collect the debug messages and either show them to the client or send them to your own server when something “goes wrong”.