On Tue, Nov 26, 2019 at 11:14 AM Jaco Kroon <[email protected]> wrote: > Hi Joshua, > On 2019/11/25 16:59, Joshua C. Colp wrote: > > On Mon, Nov 25, 2019 at 10:44 AM Jaco Kroon <[email protected]> wrote: > >> Hi, >> >> chan_pjsip has some issues w.r.t. RTP that's causing problems for me. My >> setup is rather unique, so I also get why few (if any) others have bumped >> into this before. >> >> I'm trying to wrap my head around PJSIP and ICE. >> >> I've got hosts with 200+ IP addresses. I need a way to restrict the >> advertised ICE addresses. I can guarantee 1 v4 and 1 v6 address. >> >> I'd prefer to not bind to [::] or 0.0.0.0 but it seems this is >> unavoidable. >> >> Can ICE be enabled on a per-transport basis rather than on a per-endpoint >> basis? >> > > No, such functionality does not exist. There is the ability to globally > blacklist IP addresses or ranges[1] though. > > [1] > https://github.com/asterisk/asterisk/blob/master/configs/samples/rtp.conf.sample#L93 > > Thanks for that. I think this should work for my most immediate needs, > assuming that I'm just missing something and that I can in fact blacklist > ::/128 and 0.0/0 and then allow a.b.c.d/32 and dead:beef::f00/128 for > example, which I'm not seeing. I'm thinking this is another possible > candidate for a named acl possibly? In my use case the V6 addresses on the > system are all in the same /64 and only one really should be used, and in > the V4 case it comes from two distinct /24s, again, of which only one > really should be used. >
It's strictly a blacklist currently, not a deny/allow list. > Then also, I think I've asked this before, and it wasn't possible, but > maybe things have changed. > > Is it possible to possible to vary endpoint parameters based on the used > transport? For example: > > When using SIP/WSS ice_support = yes, else ice_support = no (as but one > example). > > Another idea is to somehow manipulate different transports into different > endpoints, eg: > > [user-rtc] > type=endpoint > ice_support=yes > > [user-tls] > type=endpoint > ... params for tls > > Possibly point them all at the same AOR. > > But the I need support from transport to either prefix or suffix the > username or the realm with a defined string, eg: > > [tls] > type=transport > username_sufix=-tls > > To suite the above. > > The other alternative is to vary this client-side ... which is potentially > very error prone (but which I'll do to test the concept at least). For now > the urgent one for me to sort out is the ICE candidate selection. > > Happy to write the patches, would just like to set the direction correct > first. > Noone has written such functionality. -- Joshua C. Colp Senior Software Developer Sangoma Technologies Check us out at www.sangoma.com
-- _____________________________________________________________________ -- 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
