New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 1873 link

Starred by 19 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

ICE gathering state does not get changed at the right time

Reported by jmil...@aliax.net, Jun 3 2013

Issue description

What steps will reproduce the problem?
1. Create a new RTCPeerconnection instance
2. Add a local stream to RTCPeerconnection 
3. Execute createOffer and setLocalDescription

What is the expected result?

During setLocalDescription execution, and before firing onSuccess callback, ice gathering state should be changed from 'new' to 'gathering'.

Such behavior is defined in steps 4 and 5 of the spec if the RTCSessionDescription argument is applied successfully:

http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCPeerConnection-setLocalDescription-void-RTCSessionDescription-description-VoidFunction-successCallback-RTCPeerConnectionErrorCallback-failureCallback


What do you see instead?

ice gathering state value is 'new' by the time onSuccess callback is fired


What version of the product are you using? On what operating system?

Version 29.0.1521.3 dev
GNU Linux (Debian)

Please provide any additional information below.

Attached a .html file to reproduce it. Steps are:

1- Start()
2- Call()

Interesting logs are displayed in red in the browser console (console.error)


 
reoffer.html
4.4 KB View Download

Comment 1 by jmil...@aliax.net, Jun 3 2013

It can also be seen when using "https://apprtc.appspot.com", accessing "chrome://webrtc-internals/" in chrome.

There can be seen, that before queuing setLocalDescription's onSuccessCallback, signaling state change is made, but not ice gathering state, which should, according to the spec.

Comment 2 by juberti@google.com, Jun 4 2013

Labels: Area-PeerConnection
Owner: juberti@webrtc.org
Status: Available

Comment 3 by jmil...@aliax.net, Jun 4 2013

This behavior is very desirable for those signaling mechanisms which need to send the ICE candidates within the SDP. On setLocalDescription's onSuccessCallback, if the ice gathering state is not complete, the Offer/Answer sending is postponed until the last candidate is gathered or immediately sent if the description didn't cause an ICE restart.

There is no other way AFAIK, among the createOffer/createAnwser or setLocalDescription callbacks, to know if setLocaDescription caused an ICE restart. 

Thanks
Project Member

Comment 4 by braveyao@webrtc.org, Jun 5 2013

Cc: braveyao@webrtc.org vikasmarwaha@webrtc.org

Comment 5 by juberti@google.com, Jun 5 2013

Thanks for the explanation. I will look into what's needed to fix this.

Comment 6 by jmil...@aliax.net, Jun 9 2013

Thanks a lot Justin.

Here some additional log from 'chrome://webrtc-internals' while running 'https://apprtc.appspot.com':

"
6/9/2013 5:06:37 PM	setLocalDescription
6/9/2013 5:06:37 PM	signalingStateChange -> SignalingStateHaveLocalOffer
6/9/2013 5:06:37 PM	setLocalDescriptionOnSuccess
6/9/2013 5:06:37 PM	iceGatheringStateChange -> ICEGatheringStateGathering
"

Ice Gathering State is changed after firing setLocalDescription onSuccess callback, and not before, making impossible to know whether the local description has fired an ICE update or not on the onSuccess callback.

Comment 7 by vrk@webrtc.org, Oct 16 2014

Labels: IceBox EngTriaged
Summary: ICE gathering state does not get changed at the right time (was: SetLocalDescription implementation is not complete)
Project Member

Comment 8 by tnakamura@webrtc.org, Nov 4 2015

Cc: -vikasmarwaha@webrtc.org
This bug hasn't been modified for more than a year. Is this still a valid open issue?
Project Member

Comment 9 by pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 10 by anatolid@webrtc.org, Dec 14 2016

Cc: juberti@webrtc.org
Owner: ----
I'm still seeing the issue above, are there any updates?
Project Member

Comment 12 by sheriffbot@chromium.org, Oct 31

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.


Project Member

Comment 13 by qingsi@webrtc.org, Oct 31

Cc: qingsi@webrtc.org zstein@webrtc.org jeroe...@webrtc.org
We may want to review this bug now that we are working on improving the logging of DTLS/ICE state transitions.

Sign in to add a comment