Details
-
Type: extRequest
-
Status: Closed
-
Priority: Major
-
Resolution: Done
-
Fix Version/s: 2021
-
Component/s: FIWARE-TECH-HELP
-
Labels:None
-
HD-Chapter:Data
-
HD-Enabler:Kurento
Description
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.
*****************************
Here is the context:
We have an app sitting in front of kurento, where we record two media
sources a webcam and a screen share session.
We make one pipeline with two webrtc and recorder endpoints.
We have our own coturn server.
Problem with firefox:
We cant record the screen, using a listener on our webrtcendpoint in our
node.js app to listen for media source changes it never changes to
CONNECTED and after checking about:webrtc it tells you that it couldn't
achieve a connection between all the stun/turn servers we have at the ice
servers inside the config obj, same for all ice candidates it will show
that the connection failed and it can try again.
Problem with chrome:
It works most of the time but recently we found out that it fails to record
the webcam. We wont get any errors on kurento logs, we wont get any errors
on the client console or chrome://webrtc-internals.
We realized that it cant be a problem with the way a pipeline its created
because we create the pipeline as soon as we get the request to start a
webcam recording session, after that if everything its created and
connected properly we create a webrtc endpoint and then a recorder endpoint
for the screen share too, both mediasources have a MediaStateChanged
listener, which will let you know that the screen its working but not the
webcam, we know it wont work some times but we dont know exactly why yet.
We have a few questions:
if we have two connections in the same network is it necessary to use ICE?
if we already have a connection between endpoints for one media source and
they now the ip direction of each other, can we use the same connection for
our other mediasource? if yes it would be great to know
Besides kurento logs and chrome/firefox webrtc logs, is there any other
place we could look into to find more answers on why is this failing?
is there any way to check health of the ICE candidates so we can know if we
need to retry a connection to avoid one empty mediasource of the two we
want?
thanks
*****************************
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.
_______________________________________________
Fiware-creatifi-coaching mailing list
Fiware-creatifi-coaching@lists.fiware.org
https://lists.fiware.org/listinfo/fiware-creatifi-coaching
[Created via e-mail received from: Andrea Maestrini <amaestrini@create-net.org>]
Issue Links
- relates to
-
HELC-1421 FIWARE.Request.Coach.CreatiFI.firefox and chrome, ice candidates questions related to kurento
- Closed
Activity
Transition | Time In Source Status | Execution Times | Last Executer | Last Execution Date | |||||
---|---|---|---|---|---|---|---|---|---|
|
6d 19h 52m | 1 | NaevaTeC Development Team | 20/Jun/16 11:58 AM | |||||
|
23h 3m | 1 | NaevaTeC Development Team | 21/Jun/16 11:02 AM | |||||
|
7d 1h 8m | 2 | NaevaTeC Development Team | 28/Jun/16 12:10 PM | |||||
|
9s | 2 | NaevaTeC Development Team | 28/Jun/16 12:10 PM |
Fix Version/s | 2021 [ 12600 ] |
Resolution | Done [ 10000 ] | |
Status | Answered [ 10104 ] | Closed [ 6 ] |
Status | In Progress [ 3 ] | Answered [ 10104 ] |
Status | Closed [ 6 ] | In Progress [ 3 ] |
Resolution | Done [ 10000 ] |
Summary | [Fiware-creatifi-coaching] [CreatiFI Benelux Hub] firefox and chrome, ice candidates questions related to kurento | FIWARE.Request.Tech.Data.Stream-oriented.firefox and chrome, ice candidates questions related to kurento |
HD-Node | Unknown [ 10852 ] |
Resolution | Done [ 10000 ] | |
Status | Answered [ 10104 ] | Closed [ 6 ] |
Status | In Progress [ 3 ] | Answered [ 10104 ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Comment |
[ For your problem with Firefox, I'll recommend you use the signal MediaFlowOUT instead of MediaStateChange. The second one is related to RTCP packages and it could not fired with Firefox. About the Chrome problem. It seems weird. If your STUN/TURN servers are working well, you shouldn't have that kind of problem. It could be that you are doing a wrong manage of candidates and you have a kind of race condition which mixes the candidates of both connections. About your questions, I have answered inline: bq. if we have two connections in the same network is it necessary to use ICE? bq. Yes, you need to negotiate each connection. bq. if we already have a connection between endpoints for one media source and bq. they now the ip direction of each other, can we use the same connection for bq. our other mediasource? if yes it would be great to know No, you can't. Besides kurento logs and chrome/firefox webrtc logs, is there any other place we could look into to find more answers on why is this failing? No, there isn't. is there any way to check health of the ICE candidates so we can know if we need to retry a connection to avoid one empty mediasource of the two we want? You don't need to do that. You could check if you are receiving srflx/relay candidates. If you don't receive that kind of candidates, your connection won't work whether it is behind a NAT. In order to know if your connections are working you should return the media to the browser. In this way, you would know if your connection is working. If you can't see the media, probably you are doing wrong the negotiating of connections. Besides, I recommend you upgrade your KMS to the last version (6.5.0). ] |
Assignee | Luis López Fernández [ llopez ] |
HD-Chapter | Unknown [ 10845 ] | Data [ 10838 ] |
HD-Enabler | Unknown [ 10910 ] | Kurento [ 10873 ] |
HD-Enabler | Unknown [ 10910 ] | |
HD-Chapter | Unknown [ 10845 ] | |
HD-Node | Unknown [ 10852 ] |
We didn't receive any further communication from reporter. Hence, we close the issue.