[asterisk-dev] Kill the user, kill the user!

[Luigi Rizzo]

On Fri, Dec 07, 2007 at 11:25:54AM -0800, John Todd wrote:
...
> I will concur with Luigi's comments.
> 
> I frequently have situations where I need to match based _only_ on IP 
> address/port (or IP address range, even more of a headache) and I 
> also need to match on user credentials for any hosts not in those 
> ranges.  Think of this situation, which for me is quite common:
> 
>   1) I have a VoIP provider who sends me calls, but doesn't understand 
> authentication.  They have a /24 from which INVITEs originate to 
> ranges of DIDs on my Asterisk system.
> 
>   2) I have a dumb VoIP device that sits at the house of the CEO that 
> doesn't understand authentication.  I know the /24 of his 
> DHCP-allocated network range, but can't anticipate what address the 
> INVITEs will come from.
> 
>   3) I have a set of users who roam with their smartphones and can 
> appear anywhere on the Internet.  These users require passwords for 
> authentication to my system to receive/make calls on their discreet 
> extensions.
> 
> Is this easily possible with the new methodology?  Because it's been 
> a constant headache in the past with getting the configuration right 
> for situations like this.

"easily" has two aspects.
one is the amount of code needed to implement this flexibility,
the other one is the processing cost.

The code complexity is very limited: it suffices to have a library
of 'match' functions, and define for each peer which one(s) to
invoke to check for a match, and the corresponding return values
in case of success. E.g.

	[ceo_phone]
		match = match_by_ip(1.2.3/24) -> 100

	[user_foo]
		match = match_by_auth(foobar) -> 100
		match = match_by_from(foobar) -> 1

then after a full scan of peers you can make a selection.

While trivial to implement, this is expensive at runtime (though
basically the same as the current method, which has O(n) cost too).

If you limit the set of match functions, you can in principle organize
the peers in such a way that lookup is efficient, e.g. using some additional
indexing data structures specifically designed for the lookup, e.g.
hash tables to support lookup on the From/Auth, tries to support
lookups on the IP/port, and so on.

This all can be done transparently i.e. pay the extra cost only for
those peers who request matching on some 'unoptimized' criterion.

I think the above is the complete design for an efficient and flexible
peer matching scheme. I am not sure i or someone else are willnig to
implement this in our spare time - most of the fun is in the design,
and i already had my share :)

	cheers
	luigi

I suspect this is not the kind of code one writes 'for fun' - it is
really a pure 
> JT
> 
> _______________________________________________
> --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