How Janus VideoRoom plugin handles network interruptions

[Igor Khomenko]

Hi there, 

I have some issues with how Janus VideoRoom plugin handles network interruptions.

I use the 'id' parameter in 'join' request. It's something similar to unique User ID in room.

For example, UserA is in room. Then, he switches OFF the Internet connection. 
and after this he presses 'Stop' button to close active video session.

Then, he switches ON the Internet connection and tries to join the same room again.
And now he gets "User ID .... already exists" error.

So looks like Janus server still thinks that this user is in room (online).

After some more tests I realised that after 1 min of Internet inactivity everything starts work normal - UserA can join room again.

Are there any configs to proper setup such timeout?

[Igor Khomenko]

Ok I see here 60 seconds

https://github.com/meetecho/janus-gateway/blob/master/janus.c#L370
#define SESSION_TIMEOUT 60

Maybe it's better to move it to config? 

Any info why it's 60 by default?

[Lorenzo Miniero]

It's 60 because it made sense at the time, since it's coupled with the HTTP long polling timeout (which is 30 seconds in the demos). If you reduce that, in the code or via a configuration option, if you're using HTTP for Janus you'll have to cut the long polling timeout and make more frequent keepalives as well.

L.

[Igor Khomenko]

Thanks Lorenzo and this all sounds reasonable

what are your recommendations here, what's the best way to properly handle this case?

[uxmaster]

Since you provide unique ids by yourself, you can kick out the old lingering user with the same id and then let the new one in.

That's how I handle it.

[Igor Khomenko]

Good point, thanks uxmaster! going to give it a try 

[Igor Khomenko]

I made some tests and got some more thoughts

This proposed solution will work well for this particular case with network interruptions
On rejoin we can call listparticipants and then kick our old session.

But we have to understand that we are in a case of network interruptions.
Because it could be another situation, where the same user uses 2 browsers and actually can 'drop' his active session on browser1 when join on browser2 using this approach.
But it should not work this way.

I have 2 solutions to fix it:
1) have some flag in client application to understand that we rejoin some room after network interruptions.
If it's 'true' then we drop old user's session
2) Use 'display' parameter in 'join' request to identify end user's resource (particular browser). And then, on rejoin, If old_session.display == current_session.display then drop old session.
Otherwise - show an error "User xxx already exists". 

[uxmaster]

Why not include 2) in the id?