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

Issue 665918 link

Starred by 2 users

Issue metadata

Status: Archived
Owner: ----
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Not able to flow the remote stream, ICEConnectionStateChecking then changed to ICEConnectionStateFailed

Reported by ajay.kr....@gmail.com, Nov 16 2016

Issue description

Chrome Version       : 54.0.2840.99 (Official Build) m (32-bit) and connecting  with chorme mobile 54.0.2840.68
URLs (if applicable) : https://
OS version               : Windows 7  connecting with Android 4.4.2
Network (such as Cable/DSL/Dial up etc): 
Audio/Video format (if applicable): 
Special chrome flags (if applicable):

Behavior in Safari (if known): Did not check
Behavior in Firefox (if known): Did not check

Video issue, Audio issue, both, neither?
not able to flow the  remote stream, ICEConnectionStateChecking then alter some time changed to ICEConnectionStateFailed

Flash or HTML5?  No


What steps will reproduce the problem?
not able to flow the  remote stream, ICEConnectionStateChecking then alter some time changed to ICEConnectionStateFailed



What is the expected result? Must  to flow the remote stream and , ice connection status is ICEConnectionStateChecking then alter some time it should change to ICEConnectionStateConnected

What is the actual result?
not able to flow the  remote stream, ICEConnectionStateChecking then after some time changed to ICEConnectionStateFailed


Any additional information (anything else which may help us debug the
issue)?
Webrtc internal logs files attached.

 
webrtc_internals_dump.txt
805 KB View Download
Components: Blink>WebRTC
Labels: M-54
Looping to WebRTC Team for triaging. Desktop team do not have the setup for connecting Win with Android.
 Issue 665913  has been merged into this issue.
Log txt file contains all the detailed internal logs generated at the time of call connection process. Please check that log and let me know what went wrong. 
Please note, using the same code/approach(without any change), calls get connected using the chrome web (desktop) browser at both the end,
 and also using  chrome (Desktop) at one end and chrome android tab(device) at other end.

I am testing it in below two approach, (Please note : I have two different mobile android devices)

1.	Connecting desktop web chrome  with   Mobile 1 android (v 5.1.1)   chrome (46.0.2490.76)  , calls always get connected.

2.	Connecting desktop web chrome with Mobile 2 android (v 4.4.2)  chrome (54.0.2840.64),  calls never get connected.

Attached the webrtc internal logs for 2nd approach.


Now, updated the mobile 1 chrome version from 46.0.2490.76 to 54.0.2840.85  and  able to connect in all the calls.

Issue in the mobile 2 approach.

Comment 6 by guidou@chromium.org, Nov 18 2016

Components: -Internals>Media -Blink>WebRTC Blink>WebRTC>Network
hi ,

Please help me in this issue.

Labels: Needs-Feedback
From the internals dump, it appears that no STUN or TURN ICE candidates were gathered. Without those candidates, it's likely the devices could only connect if they're on the same network.

Have you checked that your configured STUN/TURN servers are working? Using https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/, for example?
Project Member

Comment 9 by sheriffbot@chromium.org, Dec 30 2016

Status: Archived (was: Unconfirmed)
No feedback was received in the last 30 days from reporter "ajay.kr.singh11122@gmail.com", so archiving this. Please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
It is not resolved yet. issue still exists , I checked the my stun and turn server and they are working.
How would I repoen the bug?
Status: Unconfirmed (was: Archived)
I reopened the issue. But still, the most likely explanation is that the STUN transactions are timing out.

How did you verify that the STUN/TURN server are working? Can you attack a packet capture or native webrtc log file (https://webrtc.org/native-code/logging/)?
Project Member

Comment 13 by sheriffbot@chromium.org, Feb 3 2017

Status: Archived (was: Unconfirmed)
No feedback was received in the last 30 days from reporter "ajay.kr.singh11122@gmail.com", so archiving this. Please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment