Dear WebRTC Community,
I am currently working on a WebRTC project and have encountered a specific issue related to ICE restarts in Chrome that I'm seeking help with.
Issue Description: I have implemented a WebRTC-based SFU that uses an "ice-lite" version of the ICE protocol (no ice-trickle support, nor full-ice). After correctly parsing and accepting my initial offer that uses the bundle option, which includes multiple (> 2) m-lines, Chrome is issuing a ’negotiationneeded’ event (which is followed by an ICE-Restart) every time the first active m-line port value is set to 0, even when the ICE candidates have not changed. I have already ensured that the inactive m-line is correctly marked as such in the SDP. I would expect that the previously negotiated candidate would continue to work even when one m-line port value is set to 0. The ‘expected’ behaviour is seen when the zeroed m-line is not the first active one.
Details: For example, if my initial offer includes 7 m-lines. Chrome, in the answer, includes c= and a=candidate in the first m-line:
...
c=IN IP4 192.168.1.42
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1167073038 1 udp 2122260223 192.168.1.42 57130 typ host generation 0 network-id 1 network-cost 10
a=candidate:190998267 1 udp 2122194687 10.236.171.49 60910 typ host generation 0 network-id 2 network-cost 50
a=ice-ufrag:s0+R
a=ice-pwd:3xSf2Vikm5UPRSiTHgNsAGX/
a=ice-options:trickle
...
But for the rest of m-lines, it just repeat the ufrag and pwd attributes, with a generic c=:
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:s0+R
a=ice-pwd:3xSf2Vikm5UPRSiTHgNsAGX/
a=ice-options:trickle
...
Now, if for some reason the first m-line port value is set to 0 (disabling the stream), Chrome fires an event to perform an ICE-Restart. The generated offer is peculiar, because it doesn’t contain any candidate, and the ICE credentials are renewed for the active m-lines only, while the disabled m-lines carries a totally new, and unrelated, credentials (ufrag and pwd).
I would expect that disabling an m-line (without actually changing candidates or networking interface) wouldn’t trigger the need of an ICE renegotiation, as candidates (IP/ports) are not changed. There is a way to disable, or change, this behaviour (maybe implementing some additional ICE options to advertise in the SDP)? In other words, there is a way to decouple the m-lines from the ICE procedure when bundling m-lines together (e.g, having a candidate that is valid until there is a valid bundled m-line)?
Thank you in advance for your time and assistance. Your expertise is highly valued, and I look forward to any insights or suggestions you can provide.
Best regards