ICE Restart flow detailed step

[Anil Wadghule]

Hi folks,

I am not able to find a proper flow for when to do ICE Restart.

Let's say there are two users named A & B in a Video room.

Can someone here put steps on which events one should do ICE Restart in the app?

Should we initiate ICE restart only when ICE state is connected or should we that on ICE disconnected or failed state? 

How an offer is sent, how the answer is received when setLocalDescription and setRemoteDescription are done. Also, does ICE negotiation happen?

I am not able to find more info on this on the internet. It would be great if someone writes detailed steps how this flow work.

--

Thank you,

Anil

[Naiyin]

Yes, again

All I see is people asking how to ice restart.

However, just nobody answers how to do it!!

That is super weird.

I've been researching this for months!

I just never seen how to do it.

Why this is so hard?!

[Anil Wadghule]

Yes... I have been finding it hard too.

I had to implement ICE restart feature with Janus WebRTC Gateway server, but I couldn't as I didn't find any normal ICE Restart example.

Thanks,

Anil

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ab8beaf2-3763-4c8d-8244-e42f20f0ec3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Best,

Anil

[Alin Radut]

Hello

The way I do it is to monitor the ICE status changes. If the state changes to disconnected on the initiator side (the party that initially sent the SDP offer), I will try to restart ICE by calling RTCPeerConnection.offer(for: constraints, completionHandler: ...).

Constraints will include, alongside the default mandatory constraints for my setup, the following:

constraints["IceRestart"] = "true"

This will then generate a new SDP offer and appropriate ICE candidates that can be dispatched to the other side which will, in turn, generate an SDP answer with new ICE candidates.

Not sure if it's the best way to do it, but it works for me.

Alin

[Paul Homlish]

This is what I am doing also and it works.  As you stated, it is hard to find documentation for how to do it, and even less for why it is needed and why doing it actually creates a connection when it failed the first time.  My question: why does ice fail and on retry it works using the exact same everything.

[Philipp Hancke]

the specification actually offers some guidance on when to do an ice restart:

  https://w3c.github.io/webrtc-pc/#dom-rtcofferoptions-icerestart

See also the discussion in https://github.com/w3c/webrtc-pc/pull/1910 and the linked issue.

As to why it succeeds when "it failed the first time" is hard to say without more detail. Debugging such issues typically requires at least a wireshark dump of the traffic on both ends.

Am Fr., 2. Nov. 2018 um 10:01 Uhr schrieb Paul Homlish <phom...@gmail.com>:

This is what I am doing also and it works.  As you stated, it is hard to find documentation for how to do it, and even less for why it is needed and why doing it actually creates a connection when it failed the first time.  My question: why does ice fail and on retry it works using the exact same everything.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/aeb7227b-e623-4d4f-a2d2-bd424ed5ce54%40googlegroups.com.