<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Joshua,</p>
On 2019/11/25 16:59, Joshua C. Colp wrote:<br>
<blockquote type="cite"
cite="mid:CAM0A2Z3xr0hpPtRzEjsEC3soZcc=_k-WPuuFJFqLTUEYmuXpiA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Mon, Nov 25, 2019 at 10:44 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,</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"
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>
<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.<br>
</p>
Kind Regards,<br>
Jaco<br>
</body>
</html>