Which ICE candidate am I using and why?
[Questions in bold below]
I have Kurento Media Server 5.1.3 installed in a datacenter behind a firewall running Ubuntu 14.04 OS. It has two network cards:
- 222.222.222.222 (eth0 - private IP)
- 111.111.111.111 (eth1 - Public IP)
Below is the SDP (setRemoteDescription) when my browser is connected to Kurento Media Server
type: answer, sdp: v=0
o=- 5487318114793304426 0 IN IP4 0.0.0.0
s=Kurento Media Server
c=IN IP4 0.0.0.0
t=0 0
a=group:BUNDLE audio video
m=audio 59068 RTP/SAVPF 111 0
c=IN IP4 111.111.111.111
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtcp:59068 IN IP4 111.111.111.111
a=rtcp-mux
a=ssrc:669011897 cname:user39019747@host-6e83e4c2
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=mid:audio
b=AS:20
a=ice-ufrag:YMdK
a=ice-pwd:LyLifK5UeqzPwM91DDj37e
a=fingerprint:sha-256 FF:0F:81:8C:41:4E:B4:B6:C6:D8:36:F3:D6:5F:09:FD:5F:AF:13:B3:9D:FC:12:66:AC:F3:56:D6:5B:0A:73:5D
a=candidate:1 1 UDP 2013266431 111.111.111.111 55239 typ host
a=candidate:2 1 UDP 2013266431 222.222.222.222 59068 typ host
a=candidate:4 1 UDP 1677721855 111.111.111.111 59068 typ srflx raddr 222.222.222.222 rport 59068
m=video 59068 RTP/SAVPF 100
c=IN IP4 111.111.111.111
b=AS:100
a=rtpmap:100 VP8/90000
a=sendrecv
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp:59068 IN IP4 111.111.111.111
a=rtcp-mux
a=ssrc:138242433 cname:user39019747@host-6e83e4c2
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=mid:video
a=ice-ufrag:YMdK
a=ice-pwd:LyLifK5UeqzPwM91DDj37e
a=fingerprint:sha-256 FF:0F:81:8C:41:4E:B4:B6:C6:D8:36:F3:D6:5F:09:FD:5F:AF:13:B3:9D:FC:12:66:AC:F3:56:D6:5B:0A:73:5D
a=candidate:1 1 UDP 2013266431 111.111.111.111 55239 typ host
a=candidate:2 1 UDP 2013266431 222.222.222.222 59068 typ host
a=candidate:4 1 UDP 1677721855 111.111.111.111 59068 typ srflx raddr 222.222.222.222 rport 59068
I'm not sure, but it looks like I'm using the following candidate:
a=candidate:4 1 UDP 1677721855 111.111.111.111 59068 typ srflx raddr 222.222.222.222 rport 59068
I'm right?
But given the fact that IP 222.222.222.222 is an internal IP, why does it appear as an ICE candidate?
Why doesn't it pick "a = candidate: 1 1 UDP 2013266431 111.111.111.111 55239 host host"? as this IP is public.
When using tools like "nload" to check traffic, eth0 has no traffic and may notice that eth1 has received a lot of traffic (video and audio streaming)
What it is? a = candidate: 4 1 UDP 1677721855 111.111.111.111 59068 typ srflx raddr 222.222.222.222 rport 59068 "mean?
source to share
The WebRTC client tries all ICE candidates until it finds one that works. There is a priority queue for ICE candidates, to which all potential addresses are added. WebRTC tries them one at a time, and once it finds one that works, it uses that media candidate. WebRTC doesn't know which address is your public and which is your private, it just tries candidates until it succeeds, or all of them fail.
ICE is designed to create connections when there are NAT problems.
source to share
If you're experiencing delays and you're managing client software, you can dictate the order in which candidates are selected. Some even start directly [World Class Social Networking] with TURN addresses before returning to another, if possible. If the mileage is in order from top to bottom, there is always a risk.
And if you have multiple private interfaces due to VPNs or virtual networks, it gets even slower.
source to share