Which candidate from kurento is use for ReceiveCandidate in client? - webrtc

I usec# IceLink for develop webrtc,When I sent json "operation":"gatherCandidates" to kurento
The Kurento answer many candidate to me like this::
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:1 1 UDP 2013266431 fe80::5054:ff:fef2:132e 58277 typ host","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:2 1 TCP 1019217151 fe80::5054:ff:fef2:132e 9 typ host tcptype active","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:3 1 TCP 1015022847 fe80::5054:ff:fef2:132e 49390 typ host tcptype passive","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:4 1 UDP 2013266431 202.44.12.183 55877 typ host","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:5 1 TCP 1019216383 202.44.12.183 9 typ host tcptype active","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:6 1 TCP 1015022079 202.44.12.183 54635 typ host tcptype passive","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:1 2 UDP 2013266430 fe80::5054:ff:fef2:132e 55435 typ host","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:2 2 TCP 1019217150 fe80::5054:ff:fef2:132e 9 typ host tcptype active","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:3 2 TCP 1015022846 fe80::5054:ff:fef2:132e 49448 typ host tcptype passive","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:2 2 TCP 1019217150 fe80::5054:ff:fef2:132e 9 typ host tcptype active","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:4 2 UDP 2013266430 202.44.12.183 52003 typ host","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
{"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:6 2 TCP 1015022078 202.44.12.183 44986 typ host tcptype passive","sdpMLineIndex":0,"sdpMid":"audio0"},"source":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","tags":[],"timestamp":"1475555352","type":"OnIceCandidate"},"object":"5f0f76e9-270d-46e4-b93f-a04f0f98591b_kurento.MediaPipeline/b5af38f9-2696-4352-9965-f9af01caf055_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
.
.
.
{"id":6,"jsonrpc":"2.0","result":{"sessionId":"5b12b64d-192a-4545-9812-16223ef3820f","value":null}}
It has both of TCP and UDP.
My Question is
1.which candidate to use for ReceiveCandidate in client. TCP or UDP if use TCP it's use typ host tcptype active or passive?
2.Or my client recieve all candidate from kurento?
thankyou fr advance,


During the WebRTC connection establishment, each peer sends a set of ICE candidates to the remote peer. Those candidates can be UDP, TCP, srflx (STUN), host or relay (TURN). When the remote peer receives the candidates, it starts probing those IPs and ports to see if a connection can be established. That's why each peer sends a number of them, so the remote peer has more chances of finding a valid candidate.
If you want to know which candidate pair is being used, you can subscribe to NewCandidatePairSelectedEvent from your WebRTC.

Related

Istio and the HTTP Host header

I have a situation where I am not sure if I am doing something wrong or if the use case is not supported by Istio at all. This is my setup:
I have a VirtualService connected to a Gateway to make some API externally available, e.g. as api1.example.com. The VirtualService is connected to some Service that performs some request preprocessing (some conditional URL rewriting). Now comes the tricky part: the service should forward the request to some API management solution that is running on the same cluster, in a different namespace, and without Istio enabled. This works in general, but I have some additional requirement that troubles me. The API management needs to know to which endpoint the request was originally sent to (to apply the correct rules), so when I forward the request from my service to the API management pod then the HTTP Host header should still be api1.example.com. This is the point where it breaks, I only get 502 Bad Gateway errors.
Now this is the complete setup but I think you can boil it down to the following one (unfortunately, I currently don't have access to some cluster where I could create and test some minimal working example):
pod1 runs in namespace1 with Istio enabled
pod2 runs in namespace2 with Istio disabled and is exposed as service2
Now from pod1 the following works:
wget -qO- http://service2.namespace2.svc.cluster.local
But the following does not:
wget -qO- --header 'Host: api1.example.com' http://service2.namespace2.svc.cluster.local
Any help or hints are highly appreciated!
Some updates following questions that were raised:
Istio version is 1.4.6
When I do wget -qO- http://service2.namespace2.svc.cluster.local than pod2 receives the request and when I read the Host header then it is service2.namespace2.svc.cluster.local
When I do wget -qO- --header 'Host: api1.example.com' http://service2.namespace2.svc.cluster.local then the request does not arrive at pod2 at all
istioctl proxy-config listeners pod1 shows the following (the service in pod1 is running on port 1024, the one in pod2 is running on port 80)
ADDRESS PORT TYPE
100.96.4.131 1024 HTTP
100.96.4.131 15020 TCP
100.69.164.43 443 TCP
10.250.0.42 10250 TCP
10.250.0.47 10250 TCP
100.64.124.217 443 TCP
100.67.245.255 15011 TCP
10.250.0.46 10250 TCP
10.250.0.48 10250 TCP
10.250.0.9 10250 TCP
10.250.0.24 10250 TCP
10.250.0.50 10250 TCP
100.64.124.217 15032 TCP
100.64.0.1 443 TCP
10.250.0.108 10250 TCP
100.64.0.10 53 TCP
10.250.0.34 10250 TCP
10.250.0.8 10250 TCP
10.250.0.37 10250 TCP
100.64.124.217 15029 TCP
10.250.0.30 10250 TCP
10.250.0.36 10250 TCP
10.250.0.105 10250 TCP
100.64.124.217 15031 TCP
100.64.124.217 15030 TCP
10.250.0.92 10250 TCP
100.66.112.190 443 TCP
100.68.34.255 44134 TCP
100.64.124.217 15443 TCP
10.250.0.91 10250 TCP
10.250.0.97 10250 TCP
0.0.0.0 443 TCP
10.250.0.10 10250 TCP
10.250.0.45 10250 TCP
0.0.0.0 9943 TCP
100.64.132.219 9115 TCP
0.0.0.0 10249 TCP
100.70.99.95 443 TCP
100.65.54.197 26379 TCP
100.64.0.10 9153 TCP
0.0.0.0 9090 TCP
0.0.0.0 15014 TCP
100.71.44.89 6789 TCP
100.70.253.4 2020 TCP
0.0.0.0 9094 TCP
100.67.56.56 443 TCP
100.65.133.0 4314 TCP
0.0.0.0 4005 TCP
100.70.229.77 9411 TCP
0.0.0.0 9901 TCP
100.71.167.108 443 TCP
100.69.145.185 9093 TCP
100.70.32.142 443 TCP
100.66.233.175 42422 TCP
0.0.0.0 8080 TCP
100.69.114.203 6789 TCP
100.70.144.106 3300 TCP
0.0.0.0 20001 TCP
0.0.0.0 4004 TCP
0.0.0.0 9093 TCP
100.67.179.223 9000 TCP
100.70.18.125 3300 TCP
100.64.255.234 9090 TCP
100.66.197.157 9710 TCP
100.67.193.139 3300 TCP
100.69.114.203 3300 TCP
0.0.0.0 16909 TCP
0.0.0.0 3000 TCP
0.0.0.0 15004 TCP
100.68.54.218 9115 TCP
0.0.0.0 8060 TCP
0.0.0.0 8008 TCP
100.70.162.45 9115 TCP
0.0.0.0 15010 TCP
0.0.0.0 10054 TCP
100.65.13.208 5473 TCP
100.67.193.139 6789 TCP
100.71.44.89 3300 TCP
100.70.18.125 6789 TCP
100.67.56.56 8081 TCP
0.0.0.0 9411 TCP
0.0.0.0 2379 TCP
100.66.228.227 8081 TCP
0.0.0.0 9091 TCP
0.0.0.0 5556 TCP
100.64.124.217 15020 TCP
100.68.245.60 7000 TCP
0.0.0.0 9283 TCP
0.0.0.0 80 TCP
0.0.0.0 3100 TCP
100.66.228.227 8080 TCP
100.70.144.106 6789 TCP
0.0.0.0 1024 TCP
100.70.229.77 14268 TCP
0.0.0.0 15019 TCP
0.0.0.0 5558 TCP
100.70.229.77 14267 TCP
100.67.17.80 9100 TCP
0.0.0.0 15001 TCP
0.0.0.0 15006 TCP
100.96.1.142 443 TCP
0.0.0.0 15090 HTTP

In order to be able to communicate between istio injected service and service that is external (to istio service-mesh), You will need to use ServiceEntry object.
According to istio documentation:
ServiceEntry enables adding additional entries into Istio’s internal service registry, so that auto-discovered services in the mesh can access/route to these manually specified services. A service entry describes the properties of a service (DNS name, VIPs, ports, protocols, endpoints). These services could be external to the mesh (e.g., web APIs) or mesh-internal services that are not part of the platform’s service registry (e.g., a set of VMs talking to services in Kubernetes). In addition, the endpoints of a service entry can also be dynamically selected by using the workloadSelector field. These endpoints can be VM workloads declared using the WorkloadEntry object or Kubernetes pods. The ability to select both pods and VMs under a single service allows for migration of services from VMs to Kubernetes without having to change the existing DNS names associated with the services.
Like You mentioned:
pod1 that runs in namespace1 with Istio enabled
pod2 that runs in namespace2 with Istio disabled and is exposed as service2
In this scenario the service2 will require a ServiceEntry object that will add it to Istio service mesh registry. This will allow the service2 to be used as if it was within Istio. Note that istio features that require envoy proxy will not work for this service as it is not actually istio injected.
I suggest following this istio Accessing External Services guide.

What does raddr and rport represent in an ICE candidate?

Take this ICE candidate as an example
a=candidate:1853887674 1 udp 1518280447 47.61.61.61 36768 typ srflx raddr 192.168.0.196 rport 36768 generation 0.
What does the raddr and rport represent? Also, what if the typ is relay, would that have any effect on it?

raddr and rport are for debugging purpose. https://www.rfc-editor.org/rfc/rfc5245#appendix-B.3 explains the purpose.
For serverreflexive candidates, raddr/rport allow you figuring out which local port (host candidate) is associated with this candidate. For relay candidates it will do the same, but for a serverreflexive candidate.

As Philipp kindly pointed out, the documentation shows that raddr probably stands for relative address and rport stands for relative port, ie. the local ip address and local port. Also, if the type is "relay", it means the connection is being made through a TURN server.

PeerJS not working with turn servers

I am Working with peerJS,
In LAN all is OK, but if I use turn servers from cellphone connection the stream connection fails.
The mediaStream is passed in peerJS connection.on('stream', (stream)=>{..
but crashes just after this, the problem seems related to stun/turn negotiation, here the console logs:
.callConnection.on('stream')... <-- I receive the stream
...
PeerJS: Set remoteDescription: ANSWER for: PEER_ID
PeerJS: Added ICE candidate for: PEER_ID
PeerJS: iceConnectionState is disconnected, closing connections to PEER_ID
myHandler.Negotiation of connection to PEER_ID failed.
And then this error catched:
Error: Negotiation of connection to PEER_ID failed.
at RTCPeerConnection.pc.oniceconnectionstatechange [as onicechange]
and here fails
what could it be?
I am not sure if it matters, in the signaling negotiation LOGS I cannot see the configured TURN IP, I only see other IPs:
{"type":"CANDIDATE","src":"itEthicsoftIdeskUserUUU1","dst":"itEthicsoftIdeskDeviceDDDfa53da20-5cc8-83dc-e259-df0ef328fbb7","payload":{"candidate":{"candidate":"candidate:1028452565 1 udp 2113937151 10.98.5.173 42892 typ host generation 0 ufrag lewL network-cost 50","sdpMid":"audio","sdpMLineIndex":0},"type":"media","connectionId":"mc_yzox790yv9b"}}
{"type":"CANDIDATE","src":"itEthicsoftIdeskUserUUU1","dst":"itEthicsoftIdeskDeviceDDDfa53da20-5cc8-83dc-e259-df0ef328fbb7","payload":{"candidate":{"candidate":"candidate:842163049 1 udp 1677729535 37.162.11.125 44523 typ srflx raddr 10.98.5.173 rport 42892 generation 0 ufrag lewL network-cost 50","sdpMid":"audio","sdpMLineIndex":0},"type":"media","connectionId":"mc_yzox790yv9b"}}
Thanks in advance

What are these TCP ports opened by Apache Tomcat?

When I start Tomcat I see the following using netstat (filtered by tomcat PID):
TCP 0.0.0.0:5007 xxxx34793KZ:0 LISTENING
TCP 0.0.0.0:8081 xxxx34793KZ:0 LISTENING
TCP 0.0.0.0:8543 xxxx34793KZ:0 LISTENING
TCP 127.0.0.1:8005 xxxx34793KZ:0 LISTENING
TCP 127.0.0.1:29821 xxxx34793KZ:29822 ESTABLISHED
TCP 127.0.0.1:29822 xxxx34793KZ:29821 ESTABLISHED
TCP 127.0.0.1:29823 xxxx34793KZ:29824 ESTABLISHED
TCP 127.0.0.1:29824 xxxx34793KZ:29823 ESTABLISHED
TCP 127.0.0.1:29830 xxxx34793KZ:29831 ESTABLISHED
TCP 127.0.0.1:29831 xxxx34793KZ:29830 ESTABLISHED
TCP 127.0.0.1:29832 xxxx34793KZ:29833 ESTABLISHED
TCP 127.0.0.1:29833 xxxx34793KZ:29832 ESTABLISHED
TCP 127.0.0.1:29834 xxxx34793KZ:29835 ESTABLISHED
TCP 127.0.0.1:29835 xxxx34793KZ:29834 ESTABLISHED
TCP 127.0.0.1:29836 xxxx34793KZ:29837 ESTABLISHED
TCP 127.0.0.1:29837 xxxx34793KZ:29836 ESTABLISHED
TCP [::]:8081 xxxx34793KZ:0 LISTENING
TCP [::]:8543 xxxx34793KZ:0 LISTENING
Ports 29821-29824 and 29830-29837 are what I'm wondering about.
I have searched the web, tomcat documentation, tomcat source code and any mailing list I can think of (including Stackoverflow) and can find nothing on the purpose of these TCP ports. They come in pairs which implies to me that they are possibly configured to loopback. I'm stumped as to why Tomcat needs these.
Our application that runs on Tomcat gets installed into environments where IT Security is quite robust, so they want to know the reason for every port in use.
Any ideas?

Which ICE candidate am I using and why?

[Questions in bold below]
I have setup Kurento Media Server 5.1.3 in a datacenter behind a firewall running OS Ubuntu 14.04. It has two network cards:
222.222.222.222 (eth0 - Private IP)
111.111.111.111 (eth1 - Public IP)
Attached below is the SDP (setRemoteDescription) when my browser 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 am not sure, but it seems like I am using the following candidate:
a=candidate:4 1 UDP 1677721855 111.111.111.111 59068 typ srflx raddr 222.222.222.222 rport 59068
Am I right?
But given the fact that the IP 222.222.222.222 is an internal IP why does it appears in as ICE candidate?
Why doesn't it pick "a=candidate:1 1 UDP 2013266431 111.111.111.111 55239 typ host"? since this IP is publicly accessible.
When using tools like "nload" to check for traffic, eth0 doesn't have any traffic, and can noticed eth1 got a lot of traffic (video and audio stream)
What does this "a=candidate:4 1 UDP 1677721855 111.111.111.111 59068 typ srflx raddr 222.222.222.222 rport 59068" means?

The WebRTC client tries all ICE candidates until it finds one that works. There is a priority queue for the ICE candidates which all of the potential addresses are added to. WebRTC tries these one at a time, and once it finds one that works, it uses that candidate for media. WebRTC does not know which address is your public and which is your private, it simply tries candidates until one succeeds or all of them fail.
ICE is designed to create connections in the presence of NAT issues.

If you are experiencing delays, and you control the client software, you can dictate the order in which the candidates are picked. Some even start directly [A world class Social network] to the TURN addresses before negotiating back to other if possible. If the run in the order of top to bottom there is always a risk.
And if you have a few private interfaces due to VPN or Virtual Networks, it becomes even slower.

We have added an event in current development version (6.4.1-dev). That indicates the candidates that are in use on a webrtc connection. Maybe this can help you debugging your problems.