Allow ICE restart

[ibc]

The client may request an offer to mediasoup and generate a response with iceRestart: true (as stated in RTCOfferAnswerOptions):

iceRestart of type boolean, defaulting to false

When the value of this dictionary member is true, the generated description will have ICE credentials that are different from the current credentials (as visible in the localDescription attribute's SDP). Applying the generated description will restart ICE.

When the value of this dictionary member is false, and the localDescription attribute has valid ICE credentials, the generated description will have the same ICE credentials as the current value from the localDescription attribute.

AFAIK the previous DTLS connection remains active, this is, no new DTLS handshake takes place. Also, nothing must be done in the ICE side of mediasoup since we are a ICE-Lite server.

This is, probably there is nothing to do regarding this issue. If the remote endpoint wishes to restart ICE, and assuming WebRTC SDP, it just needs to request a re-offer from mediasoup and call pc.createAnswer({ iceRestart: true }).

[ibc]

Humm, the problem is that iceRestart can we be just set into createOffer()...

[ibc]

RFC 5245 mandates ICE restart in offers... So we have a problem as we don't want to deal with SDP offers / re-offers from the client:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1339234

However, when it comes to just ICE restart, a pc.createOffer() in the browser (Firefox) should not change PTs in any existing m section, so we may let the browser create a "ICE restarted re-offer", send it to mediasoup, and mediasoup generate a SDP re-answer without even inspecting the re-offer. That should work, but we probably need a specific API for it such as:

pc.consumeIceRestart(offer)
  .then((answer) =>
  {
    // send the answer to the client.
  });

[ibc]

But then glare can happen...