chrome : Version 48.0.2564.109 (64-bit)

after aswer .... again candidates why? I don understand for what reason 

ok comment 2 is to remove. No candidates correctly. 
Anyway i have a suggestion in the design of RTCPeerConnection(in addition of bug above). 
For my opinion there are a lot of problems in design of class:
sdp flow might be handled internally. There is a confusion among candidates, sdp and security authorization.
The concept of offer/answer is correct for security acceptation of connection, but could be handle internally.
RTCPeerConnection.getCandidates() : returns the candidates by this client.
RTCPeerConnection.prototype.open(candidates,security,constraints) : send opening request to other client (sdp is passed internally )
where candidates is the known list provided by other client using a server data, security is a custom object where is defined the security params, constraints ... 
RTCPeerConnection.prototype.onAcceptConnection(evt)

where evt.security is a custom object passed by other client. 
      evt.connection is the peer connection
      evt.constraints define the type of connection. 
      return false or true for accepting or not 

similar api for datachannel and streams (onAcceptStream({scope,streamid}),onAcceptDataChannel(scope,streamid),onStream(),onDataChannel()) 

with actual api and design 
 - it is difficult to handle a workflow for acceptation of videos or datastreams,
 - offer/answer sdp handled by developer is useless workload
 - security management is weak for single datachannel/stream.   







 

    

[triage]: Hi Christian! If you have feedback on the WebRTC API I suggest you engage with the W3C working group: https://tools.ietf.org/wg/rtcweb/. You can also read the RFCs and mailing lists there, which contain detailed information on how the design choices were made and for what reason.

Do you have a concrete bug where the Chrome implementation deviates from the standard (https://www.w3.org/TR/webrtc/)? If so, please point out the relevant section of the standard and provide a small webpage that demonstrates the bug, and we'll be happy to take a look.

i developed a higher layer for solving all the problems with the current webrtc management. So i patched in my connector class.  I m sure in the next years this problem will be solved natively, creating a new heavy effort for all the browser providers for modifying it. 
It was just a advice for you as browser provider partecipating to w3c specifications. 

  

I have no time for reading all the specifications, it is not my role. The specs follows human logic. The renegotiation  is not related to "disconnected" status. It is not necessary to read specifications for understand it. Anyway i found a trick for solving it, but i m sure all developers will have the same observation finding it. In addition this bug gives the impossibility to understand when the connection is connected or not just using the RPCPeerConnection class. If you retain it is written in the specification ... no problem per me :)

Since it doesn't look like there is an implementation bug or feature request here, I'm going to close this issue.