PeerConnection's localDescription doesn't include ICE candidates, normal?

Hi.

I’m making some experiments with this native module and sip.js on iOS, trying to make them play nice with each other. sip.js seems to rely on PeerConnection’s localDescription value having the ICE candidates in there after the ICE process is complete, so that the SIP Invite/Answer contents already cary the candidates accurante information. This does not seem to happen with this module (as opossed to what happens on a browser environment), the localDescription value seems to not be updated with the ICE process results.

Also tried just with this module’s github simple example (without sip.js in the mix) and the same behaviour is observed. To note that if after the ICE process is complete I make another createOffer the sdp returned does have the ICE candidates in it.

Someone knows if this is normal behaviour, or care to make any relevant comment?

Thanks,
André

Why do you expect the SDP to have ICE candidates if the ICE process is not complete?

Hi @saghul.

Maybe I didn’t explain correctly.

I don’t expect that, what I expected was that localDescription had the ICE candidates after the process is finished, which is what doesn’t happen (and it happens in the browser). To see the candidantes in there I have to make a second createOffer + setLocalDescription run.

Ah, I see. TBH I’m not sure what the correct behavior should be here, maybe we should confirm with the specs.

Where do you think this can be mentioned? Searched around a bit already.

Tell me one thing if you know, this react-native module shares webrtc stack with the browsers or is a different implementation?

@saghul I think I found something related with this here: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity

The pendingLocalDescription contains not just the offer or answer under consideration, but any local ICE candidates which have already been gathered since the offer or answer was created. Similarly, pendingRemoteDescription includes any remote ICE candidates which have been provided by calls to RTCPeerConnection.addIceCandidate() .

Looks related, but we don’t implement pendingLocalDescription so…

In general, waiting to create the local description until ICE is done gathering will work on all environments, so I’d just do that.

That’s kinda of a hack but it works.