Dear accelerator,
your issue has been taken by FIWARE expert
BR

Comment by amaestrini@create-net.org :

Dear FIWARE coach,
we forward you an update from the applicant related to the issue, we are
not able to solve.
Please let us know if you need direct contact with the submitter.
Thanks.

********************************

I want to add some update to this:

I see that the ICE candidates get to a FAILED state. Can we know why this
happens? Can we know why it happens only some times?

I am attaching a log if that is helpful:

{"level":"debug","message":"webcam
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:44.898Z"}
{"level":"debug","message":"webcam
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:44.898Z"}
{"level":"debug","message":"webcam
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:44.899Z"}
{"level":"debug","message":"webcam
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:44.899Z"}

{"status":"ok","hasErrors":false,"warning":[],"error":[],"hasWarnings":false,"payload":[

],"level":"debug","message":"","timesta
mp":"2016-06-10T06:39:45.024Z"}

{"level":"debug","message":"screen
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:45.110Z"}
{"level":"debug","message":"screen
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:45.110Z"}
{"level":"debug","message":"screen
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:45.110Z"}
{"level":"debug","message":"screen
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:45.111Z"}
{"level":"debug","message":"screen
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:49.028Z"}
{"level":"debug","message":"screen
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:49.029Z"}
{"level":"debug","message":"webcam
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:52.083Z"}
{"level":"debug","message":"webcam
OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:52.084Z"}

********************************

On Thu, Jun 9, 2016 at 4:58 PM, Andrea Maestrini <amaestrini@create-net.org>
wrote:

> Dear FIWARE coach,
> we forward you a support request received from a CreatiFI applicant we are
> not able to solve.
> Please let us know if you need direct contact with the submitter.
> Thanks.
>
> *********************************
>
> We are using kurento to stream and save videos of users webcams and
> screens. We have this working but it is not always working. Sometimes we
> get a failure but we do not have indication in the client that the
> connection failed. Sometimes we have the screen record but the webcam
> fails, sometimes the reverse, sometimes both fail.
>
> We have a nodejs app in front of our kurento server managing the
> connection. We listen to OnIceComponentStateChanged and MediaStateChanged
> of the WebRtcEndpoint. Sometimes I see in my logs that the
> OnIceComponentStateChanged goes GATHERING, CONNECTING and then nothing past
> this and does not get to READY.
>
> Question is - how can we detect that the connection cannot happen and
> properly notify in the client?
>
> In my client I use the kurento utils and with
> WebRtcPeer.WebRtcPeerSendonly I pass an error function but I do not see
> this being called.
>
> thanks
> Paul
>
> *********************************
>

Since January 1st, old domains won't be supported and messages sent to any domain different to @lists.fiware.org will be lost.
Please, send your messages using the new domain (Fiware-creatifi-coaching@lists.fiware.org) instead of the old one.

Dear accelerator,
following the FIWARE reply.
Moreover the FIWARE expert needs a contact to fix asap the issue

***********************
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.

***********************

Comment by amaestrini@create-net.org :

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

BR

On Fri, Jun 10, 2016 at 11:24 AM, Andrea Maestrini <
amaestrini@create-net.org> wrote:

> Dear FIWARE coach,
> we forward you an update from the applicant related to the issue, we are
> not able to solve.
> Please let us know if you need direct contact with the submitter.
> Thanks.
>
> ********************************
>
> I want to add some update to this:
>
> I see that the ICE candidates get to a FAILED state. Can we know why this
> happens? Can we know why it happens only some times?
>
> I am attaching a log if that is helpful:
>
>

>

>

>

>

>

> {"level":"debug","message":"webcam
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:44.898Z"}
> {"level":"debug","message":"webcam
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:44.898Z"}
> {"level":"debug","message":"webcam
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:44.899Z"}
> {"level":"debug","message":"webcam
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:44.899Z"}
>

> {"status":"ok","hasErrors":false,"warning":[],"error":[],"hasWarnings":false,"payload":[

],"level":"debug","message":"","timesta
> mp":"2016-06-10T06:39:45.024Z"}

>

> {"level":"debug","message":"screen
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:45.110Z"}
> {"level":"debug","message":"screen
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:45.110Z"}
> {"level":"debug","message":"screen
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:45.110Z"}
> {"level":"debug","message":"screen
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:45.111Z"}
> {"level":"debug","message":"screen
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:49.028Z"}
> {"level":"debug","message":"screen
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:49.029Z"}
> {"level":"debug","message":"webcam
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:52.083Z"}
> {"level":"debug","message":"webcam
> OnIceComponentStateChanged

,1959ec40-7e64-4b6f-8823-9c2c00c3e3b0","timestamp":"2016-06-10T06:39:52.084Z"}
>

>

>
> ********************************
>
>
> On Thu, Jun 9, 2016 at 4:58 PM, Andrea Maestrini <
> amaestrini@create-net.org> wrote:
>
>> Dear FIWARE coach,
>> we forward you a support request received from a CreatiFI applicant we
>> are not able to solve.
>> Please let us know if you need direct contact with the submitter.
>> Thanks.
>>
>> *********************************
>>
>> We are using kurento to stream and save videos of users webcams and
>> screens. We have this working but it is not always working. Sometimes we
>> get a failure but we do not have indication in the client that the
>> connection failed. Sometimes we have the screen record but the webcam
>> fails, sometimes the reverse, sometimes both fail.
>>
>> We have a nodejs app in front of our kurento server managing the
>> connection. We listen to OnIceComponentStateChanged and MediaStateChanged
>> of the WebRtcEndpoint. Sometimes I see in my logs that the
>> OnIceComponentStateChanged goes GATHERING, CONNECTING and then nothing past
>> this and does not get to READY.
>>
>> Question is - how can we detect that the connection cannot happen and
>> properly notify in the client?
>>
>> In my client I use the kurento utils and with
>> WebRtcPeer.WebRtcPeerSendonly I pass an error function but I do not see
>> this being called.
>>
>> thanks
>> Paul
>>
>> *********************************
>>
>
>

Since January 1st, old domains won't be supported and messages sent to any domain different to @lists.fiware.org will be lost.
Please, send your messages using the new domain (Fiware-creatifi-coaching@lists.fiware.org) instead of the old one.

Dear applicant,
can you check with the company if they need other support and if the replyed to the Kurento owner?
BR