WebRTC ICE Restart Issue

[Nat P]

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

[Nils Ohlmeier]

Hi Nat,

What you are describing is totally spec compliant behavior. According to the Bundle spec you can have the bundle group running on a disabled m-line. I don’t remember the exact reason, but probably something related to be backwards compatible with non-bundle clients as these would not establish an ICE connection for disabled m-lines.

I agree that it would be super helpful if there would be a version of bundled ICE which runs underneath everything independent of the m-lines in the SDP. But unfortunately that is not how this got initially designed. 

Best

  Nils