WebRTC mid possibly changing during renegotiations
Hi,
I'm not 100% sure this is an issue in GStreamer, but the SDPs involved all include "webrtctransceiver0" in the a=ssrc attribute, for which a basic google search always brought back to GStreamer. Not sure if it's a red herring, but I thought it might be useful to open an issue here, in case it was correct.
Looking at some unexpected behaviours we got on the Janus demo server, I spotted some sessions that were apparently originated by a GStreamer WebRTC session. In these sessions, a renegotiation changed the mid for an existing m-line. I'm providing the SDPs I found in the logs as a reference:
SDP 1
v=0
o=- 1954319540657563253 0 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:5c7Y9dPSAZdw4drcaT7eG0C2BDTp4aJU
a=ice-pwd:U+g24U2b725LRWdeye+f1KtaEDNuc7zh
a=rtcp-mux
a=rtcp-rsize
a=sendrecv
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=framerate:30
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=ssrc-group:FID 2472748437 3517723633
a=ssrc:2472748437 msid:user2357849229@host-41a61239 webrtctransceiver0
a=ssrc:2472748437 cname:user2357849229@host-41a61239
a=ssrc:3517723633 msid:user2357849229@host-41a61239 webrtctransceiver0
a=ssrc:3517723633 cname:user2357849229@host-41a61239
a=mid:video0
a=fingerprint:sha-256 7F:74:DE:35:3A:CE:81:06:B2:2A:6B:6C:58:20:D8:65:79:0F:67:95:51:47:D2:1A:06:17:EE:FC:25:6F:AD:46
SDP 2
v=0
o=- 1672347319836072 1 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=ice-ufrag:5c7Y9dPSAZdw4drcaT7eG0C2BDTp4aJU
a=ice-pwd:U+g24U2b725LRWdeye+f1KtaEDNuc7zh
a=mid:0
a=rtcp-mux
a=setup:active
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 ccm fir
a=framerate:30
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=ssrc-group:FID 2472748437 1876537764
a=ssrc:2472748437 msid:user2357849229@host-41a61239 webrtctransceiver0
a=ssrc:2472748437 cname:user2357849229@host-41a61239
a=ssrc:1876537764 msid:user2357849229@host-41a61239 webrtctransceiver0
a=ssrc:1876537764 cname:user2357849229@host-41a61239
a=recvonly
a=fingerprint:sha-256 7F:74:DE:35:3A:CE:81:06:B2:2A:6B:6C:58:20:D8:65:79:0F:67:95:51:47:D2:1A:06:17:EE:FC:25:6F:AD:46
A quick diff shows how the second SDP (renegotiation) removes the video source (sendrecv --> recvonly). For some reason, this results in the mid changing (video0 --> 0), and apparently, the rtx SSRC changes too (not sure why).
From what I've read, JSEP explicitly forbids changing mid for an m-line once it's assigned. I've patched Janus to reject attempts to change mid in a pull request, but I thought I'd open an issue here too, just in case the client was indeed GStreamer based, and in case it's webrtcbin that's causing this behaviour under some specific circumstances. Unfortunately I don't have other details to provide, since I derived this information from logs and don't have access to the client itself, but if there's more help I can give please do let me know.
Of course, if you're sure GStreamer can't act this way and that the problem is in a different application, please do feel free to close this issue.