Damon Estep
2007-Jan-03 22:50 UTC
[asterisk-users] asterisk sip peer/user matching methods for authentication backwards?
Take an example where there is two sip users defined in sip.conf as follows; [peer1] Host=192.168.1.1 ... [peer2] Host=dynamic Secret=password ... [Peer3] Config not relevant ... The intention is to accept calls from peer1 without authentication (ip address authentication only), but require authentication from peer2 If by chance a SIP invite comes "From" peer2@192.168.1.1 (where the name peer2 on the calling server coincidentally matches a defined sip user on the called asterisk server) "To" peer3@asterisk_hostname, Asterisk will attempt to authenticate the caller "peer2" rather than accepting the call based on the fact that it came from a trusted Ip address defined for peer1. Since peer1 is trusted it is not sending credentials and will have its invite rejected with a 407 "proxy authentication required" when it fails to authenticate as "peer2". This logic seems backwards to me, the IP address should be matched first, and if there is no statically defined user with that IP address the username should be matched next. This would insure that all calls from the trusted IP address are accepted regardless of whether there is coincidently a SIP user with a matching name defined on the target asterisk server. So rather than looking for a match in this order; 1. name portion of "From" URI in the invite ("host" in the URI host@domain.com). 2. ip address statically assigne for a user it should look in this order; 1. statically defined sip user ip addresses 2. name portion of the "From" URI Can anyone shed any light on this, or suggest a workaround so 407's are not sent if the invite "from" header happens to have the same name portion of the URI as a defined sip user on the target asterisk server ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070103/d8119861/attachment.htm
Possibly Parallel Threads
- asterisk sip peer/user matching methods forauthentication backwards?
- asterisk sip peer/user matching methodsforauthentication backwards?
- 0-client_t: null client [Invalid argument] & high CPU usage (Gluster 3.12)
- 0-client_t: null client [Invalid argument] & high CPU usage (Gluster 3.12)
- 0-client_t: null client [Invalid argument] & high CPU usage (Gluster 3.12)