Chosen ICE candidate pair for WebRtcEndpoint

323 views
Skip to first unread message

Tom Houman

unread,
Aug 25, 2015, 2:27:04 PM8/25/15
to kurento
Looking through the documentation, it seems that it should be possible using kurento-client to get the chosen pair of ICE candidates for a WebRtcEndpoint, along with each candidate's details, such as IP, port, etc. However, I have not been able to find any way to query for this type of information. The only method I've found for getting stats on an endpoint is getStats(), which returns some good statistics, but no obvious link to the ICE candidates. See below for an example output of WebRtcEndpoint.getStats() for a connected endpoint.

If I want to get to the portNumber of local selected ICE candidate, the object hierarchy as described in core.kmd.json is:
RTCOutboundRTPStreamStats (transportId) -> RTCTransportStats (selectedCandidatePairId) -> RTCIceCandidatePairStats (localCandidateId) -> RTCIceCandidateAttributes -> portNumber

In the example output below, you can see that the RTCOutboundRTPStreamStats is mostly populated (inbound is 0 because it's an outgoing connection). However, the transportId that could be used to find the RTCTransportStats is a blank string.

Looking through the kurento-client-core that is in my node_modules, it appears to have all of the necessary classes to support what I've described, I just can't seem to find a way to make it work.

Has anyone else been able to use getStats() in a similar way? Is this a feature that's not yet implemented, or am I missing something?

I'm using the javascript client, pulled in using this line in my package.json:
"dependencies": {
  "kurento-client": "Kurento/kurento-client-js"
}

# kurento-media-server --version
Version: 6.0.0
Found modules:
Module: 'core' version '6.0.0'
Module: 'elements' version '6.0.0'
Module: 'filters' version '6.0.0'

Example result of WebRtcEndpoint.getStats('VIDEO'):

{
      "62ef3e93-0b47-41e6-8f7b-e6d339551597": {
        "__module__": "kurento",
        "__type__": "RTCInboundRTPStreamStats",
        "associateStatsId": "",
        "bytesReceived": 0,
        "codecId": "",
        "firCount": 0,
        "fractionLost": 0,
        "id": "62ef3e93-0b47-41e6-8f7b-e6d339551597",
        "isRemote": false,
        "jitter": 0,
        "mediaTrackId": "",
        "nackCount": 0,
        "packetsLost": 0,
        "packetsReceived": 0,
        "pliCount": 0,
        "remb": 0,
        "sliCount": 0,
        "ssrc": "1",
        "timestamp": 1440525380,
        "transportId": "",
        "type": "inboundrtp"
      },
      "a46de5f6-dcad-4c65-bb80-53dc49554033": {
        "__module__": "kurento",
        "__type__": "RTCOutboundRTPStreamStats",
        "associateStatsId": "",
        "bytesSent": 588177701,
        "codecId": "",
        "firCount": 0,
        "fractionLost": 0,
        "id": "a46de5f6-dcad-4c65-bb80-53dc49554033",
        "isRemote": false,
        "mediaTrackId": "",
        "nackCount": 338,
        "packetsLost": 455,
        "packetsSent": 459072,
        "pliCount": 0,
        "remb": 3210192,
        "roundTripTime": 0.0062103271484375,
        "sliCount": 0,
        "ssrc": "372923134",
        "targetBitrate": 2011204,
        "timestamp": 1440525380,
        "transportId": "",
        "type": "outboundrtp"
      }
}

Ivan Gracia

unread,
Sep 18, 2015, 7:20:24 AM9/18/15
to Kurento Public
Hi, 

Sorry for the delay. The object that the API returns is according to the draft, but we are only publishing RTP stats. Others like media tracks, codecs and so on haven't been implemented yet. Sorry for the confusion!

Cheers,

Ivan Gracia



--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Maria Fernandez Hernandez

unread,
Jun 8, 2017, 7:10:55 PM6/8/17
to kurento
Hi,

    we are in the same situation. We are listening to 'NewCandidatePairSelected' event, which has the information of the pair selected, but is there an event that has the final pair selected? Because this event we are currently listening is triggered more than once. Our most repeated scenario is the event being triggered once, and the pair used is normally the 1st candidate pair that is selected.

So, again, is there a way to know the final pair selected? Maybe saving all pairs selected and once the 'IceComponentStateChange' is triggered with 'READY' (which means that the candidates pair selection is final), relying on the priority?

Thank you!

Cheers,
Maria

Maria Fernandez Hernandez

unread,
Jun 8, 2017, 7:12:44 PM6/8/17
to kurento
I meant: Our most repeated scenario is the event being triggered twice, and the pair used is normally the 1st candidate pair that is selected.

Ghanshyam Agrawal

unread,
Jun 9, 2017, 8:48:23 PM6/9/17
to Kurento Public
On Fri, Jun 9, 2017 at 4:42 AM, Maria Fernandez Hernandez <mari...@gmail.com> wrote:
I meant: Our most repeated scenario is the event being triggered twice, and the pair used is normally the 1st candidate pair that is selected.

-- Your above assumption is wrong. I have seen multiple selected (based on if you have turn server or not and how many) 
and seen 2nd pair selected few times 
 

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.
To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/8fe236df-8784-4094-88c2-0e0ad3186649%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Thanks,
Ghanshyam Agrawal
Contact No : +919717167192

Maria Fernandez Hernandez

unread,
Jun 16, 2017, 2:18:26 PM6/16/17
to kurento

On Friday, June 9, 2017 at 5:48:23 PM UTC-7, Ghanshyam Agrawal wrote:

On Fri, Jun 9, 2017 at 4:42 AM, Maria Fernandez Hernandez <mari...@gmail.com> wrote:
I meant: Our most repeated scenario is the event being triggered twice, and the pair used is normally the 1st candidate pair that is selected.

-- Your above assumption is wrong. I have seen multiple selected (based on if you have turn server or not and how many) 
and seen 2nd pair selected few times 
 
^ Yes you are right. We've been testing this event and it's very confusing now. We are testing our TURN/STUN server, and while using TURN through TCP (we see the traffic coming/going to the turn server so we know it's using turn through tcp), we never receive an ICE candidate pair with that characteristics (type of canddiate "relay" and transport "TCP"). Does this mean we can't rely on that event (NewCandidatePairSelected)?

Also, we tried another approach, calling getICECandidatePairs() method on the webRTCEndpoint object, which should return the ICE candidate pair used by the ice library for each stream (https://doc-kurento.readthedocs.io/en/stable/_static/langdoc/jsdoc/kurento-client-js/node_modules_kurento-client-elements_lib_WebRtcEndpoint.js.html), once we know that the ice state is READY (this means CE concluded, candidate pair selection is now final). In this case we only receive one pair, but again the information we have in it doesn't match what we see on Wireshark... So... any suggestions on how can we get the characteristics of the connection being used? We want to know if stun/turn is being used and which protocol is being used.

Cheers,
Maria
Reply all
Reply to author
Forward
0 new messages