Removing ice candidates from local offer

[Seb M]

We run WebRTC for a Video-Chat plattform using MCUs to connect 4-8 publishers to 20+ subscribers.

For our setup, the ICE-candidates using the local adresses (e.g. 192.168.*) will usually never establish a connection, but they usually have the highest priority. For faster connections we would therefore like to remove those candidates or change the priority. This seems possible for chrome (by modifying the local SDP before setting it) but is there any way this can be done in firefox? Modifying the local SDP seems to have no effect.

Also, is this even a good idea or are the expected performance gains insignificant?

[jos...@onsip.com]

I've run into this problem as well, and eventually found the relevant Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=784514

See also:

• https://stackoverflow.com/questions/22973723/modifying-sdp-constraints-for-webrtc-in-firefox
  
• http://comments.gmane.org/gmane.comp.mozilla.devel.media/483

[Jeremy Noring]

You might want to see if your MCU supports trickle-ICE; as you add candidates to WebRTC, it slows down the overall connection time unless you're using trickle ICE.  I'm not sure the status of trickle-ICE in firefox, but it's fully supported in chrome. 

[Matthew Fredrickson]

I hope I'm not misunderstanding the question, but from my experience, Chrome doesn't usually bundle ICE candidates with the offer when you execute createOffer() - typically they are trickled out afterwards.  However, Firefox usually does include some ICE candidates in the created offer.

In our case though, we have had no problem with simply dropping the transmission/reception of local candidates and connecting just with srflx or relay candidates.

If you are worried about delays in candidate generation it seems like there is almost delay in generated local candidates.

If you are worried about delays in connection establishment, trickle ICE for each candidate set (local+remote from each type, local, srflx, relay) should be happening in parallel.

I'm guessing if you're seeing exceptional delays in connection establishment though, there's something else going either related to your MCU application or due to how you're generating/setting/using the sessionDescriptions.

Anyways, hope that helps a bit.

Matthew Fredrickson

Respoke.io

[Alexandre GOUAILLARD]

On Fri, Dec 12, 2014 at 11:38 PM, Matthew Fredrickson <cre...@digium.com> wrote:

I hope I'm not misunderstanding the question, but from my experience, Chrome doesn't usually bundle ICE candidates with the offer when you execute createOffer() - typically they are trickled out afterwards.  However, Firefox usually does include some ICE candidates in the created offer.

you can do both trickle ice and full ice. The ice candidates are being added to the local description as they are created.

in both case, start by:

- creating the offer

- setting local description

to trigger ICE gathering.

then depending on your choice

trickle ice:

- send the original offer right away

- send the ice candidates separately as they become available

full ice:

- wait for the null ice candidate (sign that the gathering is complete)

- get the new offer

- send the offer (which now has all the candidate in it).

in both case, nothing prevent you from either, blocking the 'host' candidates if using trickle ice, or pruning them from the offer if using full ICE.

In the case of full ICE, that fasten the process since each of the candidate are tested sequentially by order of priority. In the case of trickle ice, it does not really matter, the first successful candidate is used.

In our case though, we have had no problem with simply dropping the transmission/reception of local candidates and connecting just with srflx or relay candidates.

If you are worried about delays in candidate generation it seems like there is almost delay in generated local candidates.

If you are worried about delays in connection establishment, trickle ICE for each candidate set (local+remote from each type, local, srflx, relay) should be happening in parallel.

I'm guessing if you're seeing exceptional delays in connection establishment though, there's something else going either related to your MCU application or due to how you're generating/setting/using the sessionDescriptions.

Anyways, hope that helps a bit.

Matthew Fredrickson

Respoke.io

On Tuesday, December 9, 2014 10:27:11 AM UTC-6, Seb M wrote:

We run WebRTC for a Video-Chat plattform using MCUs to connect 4-8 publishers to 20+ subscribers.

For our setup, the ICE-candidates using the local adresses (e.g. 192.168.*) will usually never establish a connection, but they usually have the highest priority. For faster connections we would therefore like to remove those candidates or change the priority. This seems possible for chrome (by modifying the local SDP before setting it) but is there any way this can be done in firefox? Modifying the local SDP seems to have no effect.

Also, is this even a good idea or are the expected performance gains insignificant?

--

---
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.
For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

•