We didn't had any further communication from the applicant. Hence, we assume the issued was solved. If it is not the case, let us know.

Dear Luis,
I will check with the applicant if he needs other support and in this case to be more reactive to send you feedback and I will came back to you
BR

Dear Luis,
only to be sure, did you fix with the applicant the issue?
BR

Paul Davis answered today. Following is the chain of mail updates.

That would be the MediaFlowInStateChange. Here is a link to the JSDoc.

Ivan Gracia

On Thu, Jun 16, 2016 at 5:20 PM, Paul Davies <paul.davies@uxpro.be> wrote:
We use the javascript client library on our node app - how does WebRtcEndpoint.isMediaFlowingIn map in javascript?

thanks

Paul
–

I've emailed the applicant. Silvio Cretti is CC'ed.

Dear,
following the applicant contact: paul.davies@uxpro.be
BR

Yes I forward to the applicant
BR

Errors are only produced when something is broken, so to speak. An unnegotiated connection, though it could be interpreted as an error, it is not defined as an error by the WebRTC standard. During the negotiation, a number of candidates defining an IP and port pair, are exchanged. If none of these candidates are valid (i.e. define a location that is reachable by the other peer), the connection will not be successful and arriving as to what you have defined as an error state (though it is not, as per the standard). The issue is that new candidates might be discovered, and thus there is no way to define when a negotiation is never going to be possible, or just that the right candidates haven't arrived yet.

In that sense, the recommendation is to wait for a graceful period of time, and then signal the client that the connection could not be established. Trials have shown that almost all connections take 25sec at most to be negotiated using trickle ICE (it's normally about 2-3 secs). On the server side, you can rely on two events to know the state of the connection:

• OnIceComponentStateChanged: This event informs only about changes in the ICE connection state. The transitions between states are covered in RFC5245. It could be said that it's network-only, as it only takes into account the state of the network connection, ignoring other higher level stuff, like DTLS handshake, RTCP flow, etc. This implies that, while the component state is CONNECTED, there might be no media flowing between the peers. This makes this event useful only to receive low-level information about the connection between peers. Even more, while other events might leave a graceful period of time before firing, this event fires immediately after the state change is detected. Possible values are:
  • DISCONNECTED: No activity scheduled
  • GATHERING: Gathering local candidates
  • CONNECTING: Establishing connectivity
  • CONNECTED: At least one working candidate pair
  • READY: ICE concluded, candidate pair selection is now final
  • FAILED: Connectivity checks have been completed, but media connection was not established
• MediaFlowOutStateChangeEvent: changes to FLOWING when there is media in the output of the media element. For instance, when a WebRTC endpoint starts receiving media, this event will be fired with FLOWING, as there will be media redia to be sent to other endpoint.
• MediaFlowInStateChangeEvent: changes to FLOWING when there is media being fed to this endpoint, by another endpoint.

You can use OnIceComponentStateChanged to get when the negotiation has completed, and MediaFlowInStateChangeEvent or MediaFlowOutStateChangeEvent to know when the endpoint is sending or receiving media. If after a certain amount of time, those events are not fires, you can assume that something has gone wrong, most likely that there hasn't been a valid candidate found. Then you can signal the clients and indicate that there has been an error in the connection process.

The kurento-utils-js library is a wrapper of the RTCPeerConnection. Some of the events raised by the peer connection are wrapped by the WebRtcPeer object from the library. For those that are not, you can access directly the wrapped object in this way

var pc = webrtcpeer.peerConnection;

Nevertheless, we have found some of those events to be unreliable, depending on the browser version (for instance, oniceconnectionstatechange wasn't fired in older versions of FF), thus we recommend setting that timeout on the server side, and checking the isMediaFlowingIn and isMediaFlowingOut properties of the WebRtcEndpoint.

Silvio Cretti Could you please forward this information to the applicant?

In order to make support more agile it is important to have a contact with the issue reporter. Can you please provide an email address. Thanks in advance

Dear,
you can forward the issue to Kurento expert
BR