[1.1.x] New janus.js track handling doesn't work with receive-only audio

[Frenzie]

What version of Janus is this happening on? 1.1.1 0a6bd68926dae0a115e05c9e0ceddd428938396a

Have you tested a more recent version of Janus too? No, there have been only two commits since that don't touch anything of relevance. ;-)

Was this working before? It worked prior to #3003. Any janus.js from before then still works.

Additional context In the AudioBridge, a traditional media object like so:

let media = {
  'audioSend': false,
  'audioRecv': true,
  'video': false,
  'data': false
};

Is automatically converted to a new track object like:

'tracks': [
  { type: 'audio', recv: true },
]

This seems correct. Just in case I also tried:

'tracks': [
  { type: 'audio', capture: false, recv: true },
]

Either way, this results in the following error:

Ooops: 465 Missing mandatory lines (o=, s= or m=) [janus.js:1559:13]

On the server:

[Fri Dec  9 11:19:44 2022] Creating new handle in session 730031257305990: 7113399644781510; 0x7f4f340020a0 0x7f4f34009ab0
[Fri Dec  9 11:19:45 2022] [ERR] [sdp-utils.c:janus_sdp_parse:667] Missing mandatory lines (o=, s= or m=)
[Fri Dec  9 11:19:45 2022] [ERR] [sdp.c:janus_sdp_preparse:42]   Error parsing SDP? Missing mandatory lines (o=, s= or m=)

This is purely a problem in janus.js; any older version still works.

[lminiero]

Thanks for spotting this! I seem to remember testing recvonly from offers (so not as generated in an answer) but it looks like I'm wrong. I'll have a look to see if I can spot he cause, and in case propose a solution.

[lminiero]

The commit above seems to fix it for me: please do let me know if it doesn't for you, or if you notice any refression we should address.

[Frenzie]

At first glance there seems to be some subtly different behavior, with onremotetrack triggering one time more than it used to? I'm not sure atm how big a problem that is, but presumably not quite being backwards compatible with 1.0.x is mostly unintentional.

[lminiero]

I don't see this happening: or to be more precise, it was twice even before this fix, at least on Chrome. I see a first onremotetrack with the new track that has a muted=true status, and a second onremotetrack when the onunmute event fires on the track, which is how the callback is supposed to work.

[Frenzie]

Yes, it was twice, now I see it thrice. But I'll take another look at it on Monday.

[lminiero]

Mh I don't see that, I modified the AudioBridge demo to only receive and twice was what I got. If you have more info or feedback to share on please let us know.

[Frenzie]

It looks like an onmute now always triggers an onremotetrack with on=false which it previously didn't. Probably a result from the bugfix in #3051. So I probably just didn't realize the 1.0.x behavior was actually a bug. :-)