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

Issue 617388 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

WebRTC - network-id on onIceCandidate since Chrome 51,

Reported by pascal.b...@gmail.com, Jun 4 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36

Steps to reproduce the problem:
I am working in ALE International (formerly Alcatel-Lucent Enterprise).
In OpenTouch solution, we propose anonymous clients to connect/join meeting with "OTC Web" which allows to join audio with WebTRC (audio codec G722).

Architecture for WebRTC: browser (Chrome or Firefox) -> Internet -> SBC -> Opentouch Server (on DMZ)
1. No problem with Chrome 50
2. Since Chrome 51 : ICEConnectionStateFailed

What is the expected behavior?
Acts like Chrome < 51 or give me the RFC (didn't find it) which describes this network-id.
I need this to open a support request to our SBC provider.

What went wrong?
WebRTC negotiation failed with
ICEConnectionStateFailed

I noticed by comparing SDP negotiation side by side that since Chrome 51, on onIceCandidate:

sdpMid: audio, sdpMLineIndex: 0, candidate: candidate:3266345979 1 udp 2122255103 2001::5ef5:79fd:10f8:12b1:a756:9f61 63052 typ host generation 0 ufrag cN4WNsfYhohiix0O network-id 1

there is a "network-id X" at the end of ALL onIceCandidate.

Not reproduced by downgrading to Chrome 50.  This is also not on Firefox.

Is it a RFC ?
I found a ref here for Chromium: Issue 1815473002: Add 16-bit network id to the candidate signaling. (Closed) https://codereview.webrtc.org/1815473002/#ps80001

Regards,
Pascal

Did this work before? N/A 

Chrome version: 51.0.2704.79  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0
 
Forget to mention it: it is also reproduced with Chrome 51 on Mac by Validation team@work
Components: Blink>WebRTC>Network Blink>WebRTC
Labels: Te-NeedsFurtherTriage
Cc: pthatcher@chromium.org jansson@chromium.org
Owner: honghaiz@chromium.org
Status: Assigned (was: Unconfirmed)
Assigning to the author of https://codereview.webrtc.org/1815473002
Status: WontFix (was: Assigned)
There is an IETF draft for it:

https://tools.ietf.org/html/draft-thatcher-ice-network-cost-00

But it has not been accepted yet by the ICE Working Group.


But if you're parsing the candidate line correctly, there shouldn't be any problem with seeing "network-id 1", just like there shouldn't be a problem with "ufrag XXX" or "generation 0".  If you don't understand one of these extra attributes, just ignore it.  
Ok thanks, I'll transfer this to Audiocodes (provider of our SBC)...
I'm also facing same problem.
did you resolve this?
Hi,

@work, I transferred the question/infos to Audiocodes and they provide us a new SBC to test:
Version F7.00A.067.003

After deploying it in our test Lab all went well with Chrome. 

Sign in to add a comment