On Fri, Apr 3, 2020 at 3:20 PM Jaco Kroon <j...@uls.co.za> wrote: > Hi All, > > Following up on some work I've been busy with ( > https://gerrit.asterisk.org/c/asterisk/+/13362) a few potential issues > came to the fore on which I need some input on what the "correct" behaviour > should be. > > Note that none of this affect me directly (currently). > > For the purposes of this discussion, let's assume a host with two IPv4 > addresses, and two IPv6 addresses (globals, ignore link-local and > scope-restricted for now): > > eth0: 192.168.0.1/24 and dead::beaf/64 > eth1: 192.168.1.1/24 and foo::ba/64 > > v4 routing has default pointing out on eth0 via 192.168.0.2, and a > rule-based from 192.168.1.1 via 192.168.1.2. > > v6 has "high pref" route out via eth0 on LL%eth0, and "medium pref" out > via eth1 on LL%eth1. This may well require things like rp_filter to be > switched off, so I'm going to assume you're networking is fine. > > When calculating ICE candidates, it's generally for a specific socket, > which can be bound to a specific address (IPv4, or IPv6, or ANY - as far as > I understand). > > 1. In the case where the socket is NOT bound to any, does it make sense > to include ANY OTHER addresses as ICE candidates? Specifically, let's say > socket is bound to 192.168.0.1:10000 - does it really make sense to > advertise 192.168.1.1:10000 as ICE candidate? Not to mention the v6 > addresses? > > 2. In the case of STUN (srflx) requests being included, as I understand > the raddr should be the address FROM where the STUN request was sent. > > 3. raddr should be one of the candidates presented. > > So currently the code has two ACLs, one for ICE addressess candidates. I > actually require this. And one for the STUN *source* address, which is the > address to which the rtp socket is bound (ANY in the case of PJSIP). > > So we will send STUN in the case that: > > 1. STUN is configured; > 2. The RTP bound socket is NOT blacklisted for STUN purposes; > 3. We haven't got PJ_ICE_MAX_CAND candidates yet (default value is 32, so > unlikely). > 4. The socket is bound to IPv4 or then ANY ([::] or 0.0). > > *First issue: include non-bound addresses as candidates*: > > If socket is bound to 192.168.0.1:10000 then the kernel will drop all > frames to 192.168.1.1:10000, unless there is a DNAT rule in place to > forward these packets, or a SNAT rule created a matching CONNTRACK entry on > egress of our first RTP frame. If you're using these kind of stunts on an > asterisk host I officially declare you braver than me. > > I'm arguing in a case where the RTP socket is NOT bound to ANY we should > only advertise the bound address on ICE (v4 or v6). > > If the RTP socket is bound to v4 ANY (0.0.0.0) we should only advertise v4 > addresses. This is current behaviour. > > If the RTP socket is bound to v6 ANY ([::]) we should advertise all > addresses. >
Only candidates which have a possibility of succeeding should be included, so if it's bound to something explicitly then only candidates relevant to that should be included. > *Second+Third issue:* > > This gets really tricky. Assuming the above four conditions (it should be > noted we won't sent STUN for a v6 socket bound anywhere other than ANY > ([::]), so we've already decided we need to send STUN. > > My opinion, based on a potentially wrong understanding of the reading I've > done: > > 1. If RTP is bound to ANY (v4 or v6), we should: > 1.1 Force-include the v4 address from which ast_ouraddrfor as an ICE > candidate (even if it's ICE blacklisted); and > 1.2 Use same for base address (raddr). > > 2. If RTP is bound to a specific v4 address, we should: > 2.1 Force-include the address as an ICE candidate (even if it's ICE > blacklisted); and > 2.2 Use same for base address (raddr). > > I need to check if it's possible to include the srflx (STUN) address > before the "forced" address or not, but I can investigate that if need be. > > Current behaviour is to iterate the list of selected candidate addresses > and use the first IPv4 address found for base address (raddr). > > This unfortunately is a behavioural change. One option would be to bind > this to a configuration option. Or two, one for the change in base address > (raddr) selection, and one for forcing selected raddr as a candidate. But > then, what should the defaults be? > > I would greatly appreciate any input on these thoughts as to what the > correct thing to do is. > I think behind options, with defaults matching existing behavior today. I say this because it has existed this way for.... many many years... so unless people have experienced issues and never investigated/reported, I think opting for that is fine. -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
