GNOME Bugzilla – Bug 797266
webrtcbin: allow specifying ICE network addresses
Last modified: 2018-10-12 05:54:53 UTC
Created attachment 373878 [details] [review] ICE network devices and IPv6 We allow specifying a list of network devices that the ICE agent will use to gather ICE candidates. This needs to be given as an array of strings in the "ice-devices" property. Also, we make it possible to enable/disable IPv6 addresses with "enable-ipv6". Right now, "enable-ipv6" needs to be set before setting "ice-devices" which I really don't like much. But I didn't know how to do it unless we add a change_state, etc. I haven't been able to run the UT since it's complaining about not finding the nice elements. I'm using gst-uninstalled and I can see them with gst-inspect, but I believe tests overwrite GST_PLUGIN_PATH. I'll check again tomorrow.
The reason for this patch is that I have a lot of network devices (docker, etc.) and this was not allowing the ICE negotiation to succeed. Being able to specify only the devices I wanted solved my issues.
Finally got UT working (thanks Matthew!).
Created attachment 373883 [details] [review] ICE network devices and IPv6 refactor This new patch allows "enable-ipv6" to be set in any order. However, the introduction of "enable-ipv6" forces us to handle all the network interfaces by us. The problem I was having is that some interface were not registered as up and running, and that made ICE not happy. Now, since we handle all the interfaces, we can decide which ones to ignore. For example, the patch ignores interfaces that are not up and running and the loopback interface. Also, adding the "ice-devices" makes ICE connection setup faster.
Created attachment 373884 [details] [review] ICE network devices and IPv6 (init ice_devices) Initializes ice_devices to an empty array.
Created attachment 373888 [details] [review] ICE network addresses I have simplified this. Instead of doing the networking traversing in the element, we now have to do it outside (in the app). So, now we simply need to pass the list of addresses we want to use in the "ice-addresses" property. If none is specified, the default will be used. Also, the IPv6 handling is now done in the application as well, no need for the element to know anything about it.
Review of attachment 373884 [details] [review]: This isn't something that I'm super keen on. candidate filtering can be done outside webrtcbin if needed. If there's some information that the ice candidates themselves don't have have we can expose the necessary information from libnice. Also, I don't think getifaddrs()/struct ifaddr is available on Windows and the GPtrArray API is not the best.
(In reply to Matthew Waters (ystreet00) from comment #6) > Review of attachment 373884 [details] [review] [review]: > > This isn't something that I'm super keen on. candidate filtering can be > done outside webrtcbin if needed. If there's some information that the ice > candidates themselves don't have have we can expose the necessary > information from libnice. > > Also, I don't think getifaddrs()/struct ifaddr is available on Windows and > the GPtrArray API is not the best. Please, take a look at patch from comment 5. I changed my initial approach since I got to the same conclusions you mentioned in comment 6.
Part of the original comment still stands: "This isn't something that I'm super keen on. candidate filtering can be done outside webrtcbin if needed. If there's some information that the ice candidates themselves don't have have we can expose the necessary information from libnice."
(In reply to Matthew Waters (ystreet00) from comment #8) > Part of the original comment still stands: "This isn't something that I'm > super keen on. candidate filtering can be done outside webrtcbin if needed. > If there's some information that the ice candidates themselves don't have > have we can expose the necessary information from libnice." I see. Does the candidate numbering affect at all? That is, if you get candidate:1 1 UDP 2013266431 10.10.131.127 58037 typ host candidate:2 1 TCP 1015022335 10.9.0.3 9 typ host tcptype active candidate:3 1 TCP 1010828031 10.4.8.7 37152 typ host tcptype passive And you only want the two last ones, is it ok to send? candidate:2 1 TCP 1015022335 10.9.0.3 9 typ host tcptype active candidate:3 1 TCP 1010828031 10.4.8.7 37152 typ host tcptype passive without candidate:1? Or would the application need to take care of this? Initially I was doing the filtering in the application, but I felt I had to correct these numbers (which felt bad) so I looked into a way to tell libnice what addresses I wanted. This is an example of only 3 candidates, but in my machine I've seen 24 and I only needed 3 of those.
(In reply to Aleix Conchillo Flaqué from comment #9) > I see. Does the candidate numbering affect at all? That is, if you get > > candidate:1 1 UDP 2013266431 10.10.131.127 58037 typ host > candidate:2 1 TCP 1015022335 10.9.0.3 9 typ host tcptype active > candidate:3 1 TCP 1010828031 10.4.8.7 37152 typ host tcptype passive > > And you only want the two last ones, is it ok to send? > > candidate:2 1 TCP 1015022335 10.9.0.3 9 typ host tcptype active > candidate:3 1 TCP 1010828031 10.4.8.7 37152 typ host tcptype passive > > without candidate:1? This seems to work, but is it allowed? Or would I need to recreate those numbers in the right order?
(In reply to Aleix Conchillo Flaqué from comment #10) > (In reply to Aleix Conchillo Flaqué from comment #9) > > > I see. Does the candidate numbering affect at all? That is, if you get > > > > candidate:1 1 UDP 2013266431 10.10.131.127 58037 typ host > > candidate:2 1 TCP 1015022335 10.9.0.3 9 typ host tcptype active > > candidate:3 1 TCP 1010828031 10.4.8.7 37152 typ host tcptype passive > > > > And you only want the two last ones, is it ok to send? > > > > candidate:2 1 TCP 1015022335 10.9.0.3 9 typ host tcptype active > > candidate:3 1 TCP 1010828031 10.4.8.7 37152 typ host tcptype passive > > > > without candidate:1? > > This seems to work, but is it allowed? Or would I need to recreate those > numbers in the right order? According to the RFC, this is a just an identifier (not an ordering), the foundation: https://tools.ietf.org/id/draft-ietf-mmusic-ice-sip-sdp-14.html#rfc.section.5.1 https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-00#page-23 So, if I understand correctly, I can just filter the address and keep sending the same thing. Can you confirm? If so, we can just close this bug.
(In reply to Aleix Conchillo Flaqué from comment #11) > (In reply to Aleix Conchillo Flaqué from comment #10) > > (In reply to Aleix Conchillo Flaqué from comment #9) > > > > > I see. Does the candidate numbering affect at all? That is, if you get > > > > > > candidate:1 1 UDP 2013266431 10.10.131.127 58037 typ host > > > candidate:2 1 TCP 1015022335 10.9.0.3 9 typ host tcptype active > > > candidate:3 1 TCP 1010828031 10.4.8.7 37152 typ host tcptype passive > > > > > > And you only want the two last ones, is it ok to send? > > > > > > candidate:2 1 TCP 1015022335 10.9.0.3 9 typ host tcptype active > > > candidate:3 1 TCP 1010828031 10.4.8.7 37152 typ host tcptype passive > > > > > > without candidate:1? > > > > This seems to work, but is it allowed? Or would I need to recreate those > > numbers in the right order? > > According to the RFC, this is a just an identifier (not an ordering), the > foundation: > > https://tools.ietf.org/id/draft-ietf-mmusic-ice-sip-sdp-14.html#rfc.section. > 5.1 > https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-00#page-23 > > So, if I understand correctly, I can just filter the address and keep > sending the same thing. > > Can you confirm? If so, we can just close this bug. Correct. If there's something that's not exposed from the candidate string, we can look into adding something for that.