<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Joshua,</p>
On 2019/11/26 17:19, Joshua C. Colp wrote:<br>
<blockquote type="cite"
cite="mid:CAM0A2Z0-vgFohZwVHm0MNtfCd94uJCGfkNc4SziEcueVvx+wFw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Tue, Nov 26, 2019 at 11:14 AM Jaco Kroon <<a
href="mailto:jaco@uls.co.za" moz-do-not-send="true">jaco@uls.co.za</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Joshua,</p>
On 2019/11/25 16:59, Joshua C. Colp wrote:<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Mon, Nov 25, 2019 at 10:44 AM Jaco
Kroon <<a href="mailto:jaco@uls.co.za"
target="_blank" moz-do-not-send="true">jaco@uls.co.za</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi,</p>
<p>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.</p>
<p>I'm trying to wrap my head around PJSIP and
ICE.</p>
<p>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.</p>
<p>I'd prefer to not bind to [::] or 0.0.0.0 but
it seems this is unavoidable.</p>
<p>Can ICE be enabled on a per-transport basis
rather than on a per-endpoint basis?<br>
</p>
</div>
</blockquote>
</div>
<div><br>
</div>
No, such functionality does not exist. There is the
ability to globally blacklist IP addresses or
ranges[1] though.
<div><br>
</div>
<div>[1] <a
href="https://github.com/asterisk/asterisk/blob/master/configs/samples/rtp.conf.sample#L93"
target="_blank" moz-do-not-send="true">https://github.com/asterisk/asterisk/blob/master/configs/samples/rtp.conf.sample#L93</a><br
clear="all">
</div>
</div>
</blockquote>
<p>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.<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>It's strictly a blacklist currently, not a deny/allow
list.</div>
</div>
</div>
</blockquote>
<p>I'd like to make an attempt at this. I'm thinking make this in
addition to existing functionality, eg:</p>
<p>ice_acl = named<br>
ice_allow = ???<br>
ice_deny = ???<br>
<br>
Similar to other locations where ACLs are used.<br>
</p>
<p>Currently the overrides (ice_host_candidates) are done before the
blacklist mechanism. Otherwise I could have blacklisted ALL my
own addresses that's public, and added an RFC1819 address (for v4,
and for v6 I could've just remapped the link-local), and on
loopback and remapped that to desired public).</p>
<p>Idea is to just update the rtp_address_is_ice_blacklisted to also
check the ACL. If either the ACL or the current blacklist denies,
deny, else allow.</p>
<p>I don't care about STUN, but guessing I can do that at the same
time just for completeness sake.</p>
<p>Generate a warning during *load* time if both options is used.</p>
<p>I'll look at other modules that uses acl's to see how to
implement this.<br>
</p>
<blockquote type="cite"
cite="mid:CAM0A2Z0-vgFohZwVHm0MNtfCd94uJCGfkNc4SziEcueVvx+wFw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p> </p>
<p>Then also, I think I've asked this before, and it
wasn't possible, but maybe things have changed.</p>
<p>Is it possible to possible to vary endpoint parameters
based on the used transport? For example:</p>
<p>When using SIP/WSS ice_support = yes, else ice_support
= no (as but one example).</p>
<p>Another idea is to somehow manipulate different
transports into different endpoints, eg:</p>
<p>[user-rtc]<br>
type=endpoint<br>
ice_support=yes<br>
</p>
<p>[user-tls]<br>
type=endpoint<br>
... params for tls</p>
<p>Possibly point them all at the same AOR.</p>
<p>But the I need support from transport to either prefix
or suffix the username or the realm with a defined
string, eg:</p>
<p>[tls]<br>
type=transport<br>
username_sufix=-tls<br>
</p>
<p>To suite the above.</p>
<p>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.<br>
</p>
<p>Happy to write the patches, would just like to set the
direction correct first.</p>
</div>
</blockquote>
<div><br>
</div>
<div>Noone has written such functionality.</div>
</div>
</div>
</blockquote>
<p>Happy.</p>
<p>I'd like to take a crack at this. I think manipulating the
username might be simpler and affect far less code at the end.
Your opinion on this, and an indication of where to get started
would be greatly appreciated.<br>
</p>
<p>Kind Regards,<br>
Jaco</p>
</body>
</html>