why candidates are not included in offer after a ice restart

[Caragea Silviu]

Hello,

Why the candidates are not included in the offer SDP after I'm asking for an ice restart ?

This seems to be by design but also the comment in source code might be wrong I think because when you create an offer you are the one asking for restart not the remote peer.

webrtcsessiondescriptionfactory.cc line inside method InternalCreateOffer

      // Include all local ICE candidates in the SessionDescription unless
      // the remote peer has requested an ICE restart.
 if (!request.options.transport_options[content.name].ice_restart) {

Because of this reason I have a problem with a FreeSwitch deployment where the call is closed by FS because the invite sent has no candidates inside (I'm using SIP)

Was curious what's wrong in sending the candidates inthe offer after restart as well.

Silviu

[Philipp Hancke]

2017-04-24 11:36 GMT+02:00 Caragea Silviu <silvi...@gmail.com>:

Hello,

Why the candidates are not included in the offer SDP after I'm asking for an ice restart ?

Because they have not been gathered, similar to how they are not included in the initial offer.

You'll have to wait for onicecandidate with the null/undefined candidate again and then send the offer from pc.localDescription.sdp, similar to what you (probably / hopefully) do in the initial offer.

See https://webrtchacks.com/trickle-ice/ for the full discussion about why trickle ice is better than not trickling.

This seems to be by design but also the comment in source code might be wrong I think because when you create an offer you are the one asking for restart not the remote peer.

webrtcsessiondescriptionfactory.cc line inside method InternalCreateOffer

      // Include all local ICE candidates in the SessionDescription unless
      // the remote peer has requested an ICE restart.
 if (!request.options.transport_options[content.name].ice_restart) {

Because of this reason I have a problem with a FreeSwitch deployment where the call is closed by FS because the invite sent has no candidates inside (I'm using SIP)

Was curious what's wrong in sending the candidates inthe offer after restart as well.

Silviu

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAJsc%3DotyfbydVzhHLWgxFnR_kN1LjUP1KN-J1UMk4ughiaaRGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Caragea Silviu]

I'm already waiting for candidates and they are generated and I receive them over onicecandidate . On initial offer they are in SDP as well. after ice restart are not there and I saw that are not included because of the conditions I sent in first email:

   // Include all local ICE candidates in the SessionDescription unless
      // the remote peer has requested an ICE restart.
 if (!request.options.transport_options[content.name].ice_restart) {

Which is true after a ice restart

Silviu

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiJoJGk-7T%3DgOJpdrxEtUTtyVu85pjKMZcmNju-Op7yExg%40mail.gmail.com.

[Taylor Brandstetter]

Are you doing this?

1. createOffer({iceRestart:true}).then(offer => setLocalDescription(offer));
2. Wait for ICE restart candidates to be gathered.
3. createOffer({iceRestart:false}).then(offer => signalOffer(offer));

This is working for me.

If in #4, you're passing in "true", that would be requesting a second ICE restart, which isn't what you want.

On Mon, Apr 24, 2017 at 6:05 AM, Caragea Silviu <silvi...@gmail.com> wrote:

I'm already waiting for candidates and they are generated and I receive them over onicecandidate . On initial offer they are in SDP as well. after ice restart are not there and I saw that are not included because of the conditions I sent in first email:

   // Include all local ICE candidates in the SessionDescription unless
      // the remote peer has requested an ICE restart.
 if (!request.options.transport_options[content.name].ice_restart) {

Which is true after a ice restart

Silviu

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAJsc%3Dou%3D2WzzcDscC9kEp%3DK5gYjRzvNPHFRqgkYFp8y1DNxSPg%40mail.gmail.com.

[Taylor Brandstetter]

(Meant to say "#3" if it wasn't obvious)

[Philipp Hancke]

2017-04-24 22:34 GMT+02:00 'Taylor Brandstetter' via discuss-webrtc <discuss...@googlegroups.com>:

Are you doing this?

1. createOffer({iceRestart:true}).then(offer => setLocalDescription(offer));
2. Wait for ICE restart candidates to be gathered.
3. createOffer({iceRestart:false}).then(offer => signalOffer(offer));

Why would you do this instead of

    3. signalOffer(pc.localDescription)

?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0bT_zxD8Ly12W-jTR8MZPDg-1CFmipMOV9gvYWnX5-k4g%40mail.gmail.com.

[Taylor Brandstetter]

Theoretically, something besides ICE candidates being gathered could have changed in between the two calls to createOffer, causing the new offer to be slightly different. It should also have a new "session version" on the "o=" line according to JSEP.

But practically speaking there shouldn't be a difference.

On Mon, Apr 24, 2017 at 1:39 PM, 'Philipp Hancke' via discuss-webrtc <discuss...@googlegroups.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKi%2BEE1XO_hDAygEuL-973jaAVE8pHCkbL77p2MB%2BC44zXA%40mail.gmail.com.

[Caragea Silviu]

Hello,

I'm using native API but I'm doing exactly what you are describing (and strange part is that for initial invite works fine). Only thing I see different is the fact that I'm using a webrtc version from 17/11/2016 which is a bit old. I'll update and recheck

Silviu

On Tue, Apr 25, 2017 at 12:10 AM, 'Taylor Brandstetter' via discuss-webrtc <discuss...@googlegroups.com> wrote:

Theoretically, something besides ICE candidates being gathered could have changed in between the two calls to createOffer, causing the new offer to be slightly different. It should also have a new "session version" on the "o=" line according to JSEP.

But practically speaking there shouldn't be a difference.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0YztSz0q6q_-2ia_0ytL12qeaGLQRo7oRY8d0eb5zqu-A%40mail.gmail.com.