Thanks for the reply, I think I sorted things out. > Is there some reason you need them to be different?
I have a remote sip system which sends traffic load balanced via two redundant gateways. The remote system can't send a different auth name based on which gateway its going out over. This means the incoming invite could match node-a or node-b, but would be sending the same username/password to the auth challenge, thus my desire to be able to set a common username for both sip.conf entries. Looking at chan_sip.c, I found a workaround. There is a sip.conf parameter called match_auth_username, which I set to true. When the initial invite comes in, it matches the [node-a] or [node-b] entry by host ip address and then issues a 401 challenge back. When the authentication invite comes back, match_auth_username causes asterisk to try and find a user entry that matches the auth username. If I have a matching entry, asterisk performs auth using its entry name and secret. So for the following example, if I pass test/1234 as my credentials, the second invite will match [test] and properly authenticate, regardless of whether it initially matched node-a or node-b. [general] match_auth_username=yes ... [node-a] type=peer disallow=all allow=ulaw host=XXX.XXX.XXX.XXX transport=udp secret=1234 [node-b] type=peer disallow=all allow=ulaw host=YYY.YYY.YYY.YYY transport=udp secret=1234 [test] type=user disallow=all allow=ulaw transport=udp secret=1234 context=incoming-call I'd much prefer the second invite to match against the initial sip.conf entry and be able to set an incoming auth username for that case, but this works well enough for my purposes. Cheers On Fri, Oct 5, 2012 at 5:18 AM, Joshua Colp <jc...@digium.com> wrote: > John Wolthuis wrote: >> >> Hello All, > > > Hola, > > >> I am trying to debug an odd issue. I have two UACs that are sending >> INVITEs to my asterisk 1.8 server. I want to start authenticating >> these incoming invite requests with digest auth. The UACs are not >> registered and I am using host ip to match them with a sip.conf peer. >> The issue I am seeing is that an incoming invite matches a specific >> peer (by host ip), but refuses to use the "username" parameter value >> for digest auth, it will only use the peer name. I see the following >> error: >> >> "chan_sip.c: username mismatch, have<node-a>, digest has<test>" > > > The "username" configuration option isn't for what you are trying to use it > for. The peer name is used in all cases. The various options (defaultuser, > authuser) control outgoing session details. > > Is there some reason you need them to be different? > > Cheers, > > -- > Joshua Colp > Digium, Inc. | Senior Software Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: www.digium.com & www.asterisk.org > > > -- > _____________________________________________________________________ > -- 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 -- _____________________________________________________________________ -- 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