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

[John Todd]

At 10:31 AM -0800 2007/12/7, Luigi Rizzo wrote:
>On Fri, Dec 07, 2007 at 11:05:57AM -0600, Tilghman Lesher wrote:
>>  On Thursday 06 December 2007 16:48:43 Patrick wrote:
>>  > On Thu, 2007-12-06 at 14:04 -0800, Ryan Mitchell wrote:
>>  > > To raise an issue that's come up a few times before, instead of
>>  > > checking user then ip/port, why not check ip/port first then user?
>>  >
>>  > How about making it configurable per peer?
>>
>>  That doesn't make any sense.  The whole purpose of this code is to FIND
>>  the peer.  By the time you know which peer, it's too late.
>
>i was about to make the same comment in my previous email,
>however there is perhaps a partially related per-peer setting,
>namely allow/disallow/assign different weights to each
>match criteria on a per-peer basis.
>
>E.g. for certain peers who have little privilege (e.g.
>cannot place external calls or cannot use toll services)
>you might decide to allow IP/port matching even if not
>authenticated; for other peers you could allow a match only
>basing on some more reliable credential. And so on.
>
>This requires a bit of thought but it is probably doable.
>
>cheers
>luigi

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.

JT