Rich Adamson wrote:
Reading way between the lines and taking an educated guess, I'd suggest the reasoning behind Mark's architectual thoughts are likely to relate to providing peer-to-peer call completion capabilities, as opposed to forcing all * systems to pass through some service-provider's-voip- switch. If implemented correctly, you control how anonymous calls are handled/allowed via contexts, and not through simple password schemes. In all liklihood, the code is probably not totally implemented as yet to achieve the objective.
Mark's response to the bug entered explained the situation fairly well, and I have updated the IAX2 wiki page with a note about this issue.
Basically, the simple solutions are:
- use only RSA keys for authentication (can't be guessed)
- use IP-based access control for any "type=user" entries in iax.conf that would provide access to services that you don't want anonymous users to be able to "steal"
- as a last resort, provide a "guest" user entry in iax.conf (no secret specified), which goes to a limited context (possibly just Congestion)... Asterisk will always choose this no-secret-specified user entry first for any anonymous incoming IAX2 connections, without proposing any kind of secret match/challenge with the caller
I don't see a problem with having all these options. One, or a combination, should provide everything everyone needs.
I'm reviewing the current chan_iax2 code right now, and I'm going to write a new wiki page for "IAX2 Authentication" to document all this stuff more clearly so others don't have to figure it out the way I did :-)
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
