Datachannel stats bug - bogus datachannel entry
Reported by
cristian...@gmail.com,
Apr 11 2016
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36 Steps to reproduce the problem: I m developing code for web rtc communication. It now works but: 1. i write code in which i add a datachannel in client 1 and confirm it in client 2 on callback ondatachannel. 2. session complete negotation and i can exchange messages 3. i go in chrome://webrtc-internals/ and check how many data channels are there 4. in client 1 i see correctly 1 datachannel_1 in status open in client 2 i see datachannel_1 in status open and a datachannel-1 in status connecting.This last datachannel is wrong. 5. I tried to see if using the external demo https://webrtc-chat-demo.herokuapp.com is the same , and it there is the same error in reports 2. 3. What is the expected behavior? no datachannel-1 in client 2 but just datachannel_1 for both clients What went wrong? Ipothesis:datachannel is add before of negotation , so it is sent to other client as datachannel-1 . Then after negotation is notified another datachannel_1 (i dont know why). Another strange behaviour (maybe connected): i tried to move addition of datachannel when negotation is completed but it doesnt work because session is not established (candidates are not gathered). Did this work before? N/A Chrome version: 48.0.2564.109 Channel: n/a OS Version: Ubuntu 14.10 Flash Version: Shockwave Flash 21.0 r0
,
Apr 11 2016
I can reproduce this on Chrome 51.0.2700.0 (Official Build) dev (64-bit) as well. I see both datachannel_-1 and datachannel_1 objects. hta: can you have a look? I guess the source code is close to what's described at https://pusher.com/tutorials/webrtc_chat
,
Apr 11 2016
Verified on the herokuapp that a dummy datachannel_-1 is added to stats on the initiator side.
,
Apr 11 2016
Harald, are you an appropriate owner for this bug?
,
Apr 11 2016
,
Apr 13 2016
,
Apr 13 2016
I can own it (for my team). It fits with our stats OKR.
,
Apr 14 2016
hi , a suggestion: There is for my opinion another side effect probably correlated. Consider that code descrived above for RTC working for creating a communication between 2 peers. If i remove the code line addDataChannel before to create offer , the communication is not working(negotation). In particular way no candidates are sent. Pratically it is necesary to add a data channal or a stream before to create a offer. This for my opinion is not right , before i could create a session and just in a following time to know what kind of data transfer(data channel or video) i need.
,
Apr 14 2016
Other bug found related. Before status: client 1 create a peer(RTCPeerConnection) 1-2 for client 2. client 2 create a peer 2-1 for client 1. The connection(datachannel_1) it works. Now i add client 3 that create a peer 3-1 and 3-2 to client 1 and 2. Client 1 create peer 1-3 and client 2... peer 2-3.All clients are interconnected and they can send data to others. All apparentely works but i see in log other side effects: client 1 (same behaviour for client 2) receives a new callback 'ondatachannel' in peer 1-2 before client 1 is creating peer 1-3. It seams be generated by client 3 when it creare peer 3-1. Pratically it seams ondatachannel is executed in the wrong peer (1-2) and it seams generated by peer 3-1.
,
Apr 14 2016
Changing the title to reflect the original bug with a more descriptive name. Please file new bugs for new strange observed behavior. When you file a bug for the behavior described in comment #9, please specify whether the clients are in the same tab, different tabs on the same browser, or in different browsers.
,
Nov 12 2016
This issue occurs because initially the DTLS role (which determines SCTP ID) is not known, so the SCTP ID is undefined (using -1). And that ID is used to form the ID of the stats entry, hence "datachannel_-1". The solution is to use something other than the SCTP id in order to identify data channels. We could generate a random ID as we do elsewhere, or use a monotonically increasing one; anything that guarantees a 1:1 mapping between stats entry and data channel object. Also, in response to comment #8: Unfortunately you do need to have an m= section in the offer to begin ICE. It's just a consequence of SDP semantics.
,
Nov 13 2017
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. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 18 2018
Ping for triaging.
,
Jan 18 2018
,
Jan 21
(2 days ago)
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. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ashej...@chromium.org
, Apr 11 2016