Subscription request didn't create a track

General
1

We had a reported issue that only one specific user didn’t hear the audio of another user.
A subscription request for the audio mid was fired to Janus, but no track came back according to our logs for the affected user.

I looked at the Janus logs and saw this:

[Fri Aug 23 09:02:02 2024] [6621597623015734] Updating existing session
[Fri Aug 23 09:02:02 2024] [4767126316700817] Updating existing session → Affected User Subscription Handle
[Fri Aug 23 09:02:02 2024] [8851945734487655] Updating existing session
[Fri Aug 23 09:02:02 2024] [8240877931173922] Updating existing session
[Fri Aug 23 09:02:02 2024] [6621597623015734] Negotiation update, checking what changed…
[Fri Aug 23 09:02:02 2024] [8851945734487655] Negotiation update, checking what changed…
[Fri Aug 23 09:02:02 2024] [8240877931173922] Negotiation update, checking what changed…

Maybe it is a coincidence, but I do not see a “Negotiation update, checking what changed…” for the affected user handle subscription request. All other handles who heard the audio fine have such a corresponding line. Could you shed some light if that could be an issue and what does the “Checking what changed” mean in general?

Thank you in advance!

2

That’s something the core always prints when it sees a new SDP from the user after the connection was established, meaning there’s a renegotiation occurring (maybe LOG_INFO is too verbose, we should bring that down to LOG_VERB). If you don’t see it for some users, it means a renegotiation never happened for them. Considering you’re talking of subscriptions, it probably means that either the VideoRoom plugin never sent an updated offer to them (and so they never sent an answer back), or it did and the user didn’t send an SDP answer back.