[asterisk-dev] *** SPAM *** Re: pjsip and RTP

Jaco Kroon jaco at uls.co.za
Wed Nov 27 05:16:11 CST 2019


Hi Joshua,

On 2019/11/26 17:19, Joshua C. Colp wrote:
> On Tue, Nov 26, 2019 at 11:14 AM Jaco Kroon <jaco at uls.co.za
> <mailto:jaco at uls.co.za>> wrote:
>
>     Hi Joshua,
>
>     On 2019/11/25 16:59, Joshua C. Colp wrote:
>>     On Mon, Nov 25, 2019 at 10:44 AM Jaco Kroon <jaco at uls.co.za
>>     <mailto:jaco at uls.co.za>> 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.

I'd like to make an attempt at this.  I'm thinking make this in addition
to existing functionality, eg:

ice_acl = named
ice_allow = ???
ice_deny = ???

Similar to other locations where ACLs are used.

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).

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.

I don't care about STUN, but guessing I can do that at the same time
just for completeness sake.

Generate a warning during *load* time if both options is used.

I'll look at other modules that uses acl's to see how to implement this.

>  
>
>     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.

Happy.

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.

Kind Regards,
Jaco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20191127/2f35d7f2/attachment.html>


More information about the asterisk-dev mailing list