Firefox throws an exception if you pass a max-bundle sdp to janus and use the answer as provided by janus

[JanFellner]

Steps to reproduce:

use firefox (any current version, 82.0b9 (64-bit))
initialize a PC with bundlePolicy "max-bundle" (sdpSemantics "unified-plan")
pass audio and video to the peercon.
create an offer (attached)
pass the offer to janus through a configure command
put the answer into the pc using setRemoteDescription

ff_max_bundle.txt
janusTransport.log

[fippo]

@lminiero I looked at this and it seems that Janus misinterprets Firefox bundle-only in the audio m-line, invents a mid "0" for the bundle group and then puts mid:(null) into the SDP.

The obvious workaround is to not use max-bundle yet but that might become more relevant with unified plan
Now whether Firefox is wise to set bundle-only on the second m-line already... (I am looking at you @nils-ohlmeier)

[nils-ohlmeier]

How about trying to add audio and video in the order of "audio first, followed by video"? My guess is the Janus might handle that "standard" scenario a little better.

Without looking it up I'm pretty sure that "mid:(null)" is not valid SDP. So Firefox is correct to complain about that.

@fippo if I remember it correctly with max-bundle the browser is required to request as much bundling as possible, which only works if everything besides the initial m-section gets bundled. So I think Firefox behavior is correct here.

[lminiero]

The order of media is irrelevant, Janus accepts it any way. The issue is that the port in the m-line is 0, which in Janus SDP parsing today means the m-line is disabled.

[fippo]

@nils-ohlmeier true, that is what JSEP says. Even though I would interpret "Only the first m= section will contain transport parameters; all streams other than the first will be marked as bundle-only" on media streams, i.e. audio+video, not rtp streams.

[lminiero]

The issue is that the port in the m-line is 0, which in Janus SDP parsing today means the m-line is disabled.

More precisely, we probably stop parsing the m-line earlier because of the port 0, and so don't get to the mid. This might explain why it's set to (null) in the attribute, and why the bundle group looks like this in the answer:

a=group:BUNDLE 0 audio

(audio is the default mid when we generate them ourselves). I'll work on a fix for that, but the end result will still be audio disabled even if the connection succeeds, because of the port being 0.

[lminiero]

@nils-ohlmeier I can confirm that the cause of the exception is the wrong mid in the group:bundle line, not the (null). Ensuring we only add there the mid values of accepted m-lines got Firefox to work, only for the first m-line though, since as expected Janus is treating the port 0 as a "disabled". I'll work on make it "smarter" and look for bundle-only too, in order to fix the management of max-bundles too.

[lminiero]

The commit above should fix it (it seems to work fine for me now). Thanks for the heads up on the issue!

[nils-ohlmeier]

Yeah unfortunately the IETF decided AFAIK that implementations which are aware of bundle need to handle port 0 differently from the old style non bundle implementations. I'm not a big fan o that either, but if one reads through the mailing list discussions about bundle I'm sure there is some sensible reasoning for that (assuming one finds bundling reasonable ;-) ).