6.1.2 ICE Issues

[Enzo Aquino]

Hey all,

We've recently updated to KMS 6.1.2 and are having issues with the ICE candidates not being properly configured. The initial offer is always generated from KMS, but only has HOST ICE candidates. As this is deployed to AWS, we're never getting audio through. Is there new configuration, or something new we need to do on the server side?

Below is configuration, installation data and sample sdp. Any help would be greatly appreciated.

Cheers,

Enzo Aquino

/etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini 

-------------------------------------------------------------------------

stunServerAddress=173.194.66.127

stunServerPort=19302

Output from kurento-media-server --version

----------------------------------------------------------

libdc1394 error: Failed to initialize libdc1394

libdc1394 error: Failed to initialize libdc1394

ALVAR 2.0.0 - A Library for Virtual and Augmented Reality

Copyright 2007-2012 VTT Technical Research Centre of Finland

Licensed under the GNU Lesser General Public License

Built on 2012-05-29 for Linux 2.6.32-41-generic x86_64

Version: 6.1.1

Found modules:

Module: 'backgroundextractor' version '6.1.1'

Module: 'chroma' version '6.1.1'

Module: 'core' version '6.1.2'

Module: 'crowddetector' version '6.1.1'

Module: 'elements' version '6.1.1'

Module: 'facesegmentator' version '6.1.1'

Module: 'filters' version '6.1.1'

Module: 'markerdetector' version '6.1.1'

Module: 'platedetector' version '6.1.1'

Module: 'plumberendpoint' version '6.1.1'

Module: 'pointerdetector' version '6.1.1'

Sample SDP offer

------------------------

v=0

o=- 3654479674 3654479674 IN IP4 0.0.0.0

s=Kurento Media Server

t=0 0

a=group:BUNDLE audio0 video0

m=audio 51690 RTP/SAVPF 96 0

c=IN IP4 10.229.86.162

a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=rtpmap:96 opus/48000/2

a=rtcp:51690 IN IP4 10.229.86.162

a=rtcp-mux

a=ssrc:1261894701 cname:user3918420244@host-f7cd6ba6

a=ice-ufrag:zhlQ

a=ice-pwd:vQcUEBWUotHE2tViWGk4NE

a=fingerprint:sha-256 B7:89:E2:B7:A4:9A:79:EC:EF:26:78:1F:F5:84:1D:D4:5D:C3:38:F9:A3:B6:F7:34:6B:3F:AB:E1:45:E6:BA:94

a=mid:audio0

a=candidate:1 1 UDP 2013266431 10.229.86.162 51690 typ host

a=candidate:1 2 UDP 2013266430 10.229.86.162 46706 typ host

m=video 51690 RTP/SAVPF 99

c=IN IP4 10.229.86.162

b=AS:500

a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=rtpmap:99 VP8/90000

a=rtcp:51690 IN IP4 10.229.86.162

a=rtcp-mux

a=rtcp-fb:99 nack

a=rtcp-fb:99 nack pli

a=rtcp-fb:99 goog-remb

a=rtcp-fb:99 ccm fir

a=ssrc:885076416 cname:user3918420244@host-f7cd6ba6

a=ice-ufrag:zhlQ

a=ice-pwd:vQcUEBWUotHE2tViWGk4NE

a=fingerprint:sha-256 B7:89:E2:B7:A4:9A:79:EC:EF:26:78:1F:F5:84:1D:D4:5D:C3:38:F9:A3:B6:F7:34:6B:3F:AB:E1:45:E6:BA:94

a=mid:video0

a=candidate:1 1 UDP 2013266431 10.229.86.162 51690 typ host

a=candidate:1 2 UDP 2013266430 10.229.86.162 46706 typ host

[Ivan Gracia]

That STUN server is not working. Please check it here. Also, please read this guide on debugging and reporting problems. You can get very valuable tips on how to debug your setup.

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.

[Enzo Aquino]

Thanks for the reply. So, I did realize I was using the ICE test page wrong, oops. 

However, that was just the last STUN address I tried. But, it is indeed not working. I've tested it again with 64.233.177.127:19302 which we use in production. This server works fine, according to the test page, I'll post the results below. I'm also sure that server is being used, due to the output from the kurento logs. Also, below.

ICE test results:

---------------------

Time	Component	Type	Foundation	Protocol	Address	Port	Priority
0.002	1	host	750939894	udp	10.1.88.10	63075	126 | 32542 | 255
0.002	2	host	750939894	udp	10.1.88.10	56138	126 | 32542 | 254
0.055	2	srflx	3487819802	udp	68.52.126.190	56138	100 | 32542 | 254
0.055	1	srflx	3487819802	udp	68.52.126.190	63075	100 | 32542 | 255
0.104	1	host	1648464390	tcp	10.1.88.10	0	90 | 32542 | 255
0.104	2	host	1648464390	tcp	10.1.88.10	0	90 | 32542 | 254
0.155	Done

kurento logs:

----------------

0:05:52.357108033  2995 0x7fc6dc01bd20 INFO    KurentoWebRtcEndpointImpl WebRtcEndpointImpl.cpp:281:WebRtcEndpointImpl: stun port 19302

0:05:52.357148268  2995 0x7fc6dc01bd20 INFO    KurentoWebRtcEndpointImpl WebRtcEndpointImpl.cpp:285:WebRtcEndpointImpl: stun address 64.233.177.127

[Ivan Gracia]

I take it UDP ports are open, right? Could you check the following?

• How you are connecting webrtc endpoints. Are you using a media profile?
• What constraints are you passing? This will clarify if you need audio and video, only audio or only video
• Does your SDP contain and audio block? That means both client and server SDPs
• Have you checked using one of the tutorials?
• What was your previous KMS version installed? The one you upgraded from
• Have your tried with different browsers?
• Can you briefly describe your pipeline, se we know what's the expected behaviour?

The more info you can provide, the easier it will be for us to debug this :-)

Cheers,

Ivan Gracia

[Enzo Aquino]

The UDP ports are indeed open.

The endpoints are connected directly to each other. WebRTC <--> WebRTC. We are not using a media profile.

In this instance, it's audio only, both directions. The clients can either be a browser or an android device (not a phone). The example I was showing earlier was browser to browser. From the client side, we're doing this: https://gist.github.com/enzoaquino/9498f374dba6caa48c22. The getUserMedia call is simply a wrapper that does a couple more things, but the local stream gets the following parameters: {audio: true, video: false}

The SDPs have audio blocks. Here's a gist with the exchange for each client: https://gist.github.com/enzoaquino/d244bb0e1f4f818d9b17

I haven't checked with a tutorial yet, I'll pull one of those down. But, we've had the problem with both fresh installs and upgraded instances.

The previous version was:

$ kurento-media-server --version

libdc1394 error: Failed to initialize libdc1394

Version: 6.1.0

Found modules:

Module: 'core' version '6.1.1'

Module: 'elements' version '6.1.0'

Module: 'filters' version '6.1.0'

This pipeline is simply WebRTC to WebRTC. We simply create the pipeline, each WebRTC endpoint and hook them directly together. There's more complicated stuff for other scenarios, but this is the simplest one that we're using.

Thanks again for the help.

You received this message because you are subscribed to a topic in the Google Groups "kurento" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kurento/RS1jDL4LU9Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kurento+u...@googlegroups.com.

[Ivan Gracia]

Thanks for the detailed report! Please find answers inline.

More things to check, in chrome://webrtc-internals you will see a lot of useful info regarding the IceConnectionState and negotiation. Have a look there! Have you used different browsers to make the test?

Ivan Gracia

On Thu, Oct 22, 2015 at 5:16 PM, Enzo Aquino <enzo....@gmail.com> wrote:

The UDP ports are indeed open.

The endpoints are connected directly to each other. WebRTC <--> WebRTC. We are not using a media profile.

I suggest you invoke connect with a media type (not profile, sorry: I always mix those two) in JavaScript

webrtc1.connect(webrtc2, 'AUDIO', function (err) { 
        // Whatever you want to do here
});

or in Java

webrtc1.connect(webrtc2, MediaType.AUDIO);

​

In this instance, it's audio only, both directions. The clients can either be a browser or an android device (not a phone). The example I was showing earlier was browser to browser. From the client side, we're doing this: https://gist.github.com/enzoaquino/9498f374dba6caa48c22. The getUserMedia call is simply a wrapper that does a couple more things, but the local stream gets the following parameters: {audio: true, video: false}

I don’t see the constraints object passed as param in your getUserMedia call. Is this a typo? This is related to the next answer

​

The SDPs have audio blocks. Here's a gist with the exchange for each client: https://gist.github.com/enzoaquino/d244bb0e1f4f818d9b17

SDP also has video blocks. I think this is not intended, right? If you are not passing constraints, then it will ask for both permissions, and you will be sending both audio and video. Sending only audio will save bandwidth.

 

I haven't checked with a tutorial yet, I'll pull one of those down. But, we've had the problem with both fresh installs and upgraded instances.

Please do so and post the results. I'd suggest the kurento-hello-world in any flavour.

 

The previous version was:

$ kurento-media-server --version

libdc1394 error: Failed to initialize libdc1394

Version: 6.1.0

Found modules:

Module: 'core' version '6.1.1'

Module: 'elements' version '6.1.0'

Module: 'filters' version '6.1.0'

That should be fine. It was just in case you upgraded from v5.

 

This pipeline is simply WebRTC to WebRTC. We simply create the pipeline, each WebRTC endpoint and hook them directly together. There's more complicated stuff for other scenarios, but this is the simplest one that we're using.

Ok, let's get this one solved first ;-)