On 28 July 2010 17:32, Tilghman Lesher <[email protected]> wrote: > On Wednesday 28 July 2010 06:49:01 Steve Davies wrote: > [snip] to avoid repetition below > > I don't see a 'type' argument to either of the above, so neither of these > would at all be used. That said, you're assuming that the deny and allow > determine who is allowed to be user2. That's incorrect. They permit what > packets will even reach user2, and a registration needs to occur for the host > address to become something other than 0.0.0.0 (which is the default, unless > you have a defaultip parameter). Hence, user2 won't match anything at all > until a registration packet comes in that passes your deny/allow ACL. >
Sorry, I missed the type=friend off both examples. Too busy cleaning up the example :( Perhaps it is better to describe what I want to achieve first... We want an primarily inbound IAX config that allows un-authenticated connections from a specified range of IP addresses. The remote party is required to use a username. I understood from the VoIP WiKi that if a username is provided by the caller in the NEW packet, and the permit/deny list allows the packet, that the following would be okay: [user2] type=user <--- type=friend should be ok too ? username=user2 secret= context=context2 host=dynamic <--- "don't care" placeholder. Is this bad? deny=0.0.0.0/0.0.0.0 allow=10.2.3.0/255.255.255.0 A channel is created called "IAX/10.2.3.1-xxx" in this example. What I am pretty sure I observed is that if I ALSO have the following configured: [user1] type=user username=user1 secret=a-secret context=context1 host=10.2.3.1 <--- Specifically an address from the permit range in [user2] When a call arrives from IP address 10.2.3.1 with a username of "user2", then [user2] is used for authentication, but the call proceeds using [user1] and a channel name of "IAX/user1-xxx" after authentication is complete. In the example above this meant password-free access to a password protected context. I appreciate this is an odd claim, and I will try to reproduce it using both 1.2 and 1.6 asterisk builds, in the meantime I was wondering if this was a known issue - Sounds like it isn't. PS. I think there is a 99% chance that I mis-interpreted the results, and this is not a real problem, but that 1% chance is why I am sending the email :) Thanks, Steve -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
