asterisk users - Oct 2012 - username ignored when trying to auth incoming invites

Hello All,
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>"

I have the following sip.conf:

[node-a]
type=friend
disallow=all
allow=ulaw
context=incoming-context
host=XXX.XXX.XXX.XXX
transport=udp
username=test
secret=1234

[node-b]
type=friend
disallow=all
allow=ulaw
context=incoming-context
host=YYY.YYY.YYY.YYY
transport=udp
username=test
secret=1234



If I auth using "node-a" as the username when sending an invite from
that host, everything works.  If I auth with "test" as the username
from node-a, it fails with the error above.  It appears that peer name
is always being used for digest auth, rather than the contents of
username.   Is "username" the wrong place to specify this?

Thanks for your help!

Try defaultuser=test instead of username=test

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of John Wolthuis
Sent: Thursday, October 04, 2012 11:01 PM
To: asterisk-users at lists.digium.com
Subject: [asterisk-users] username ignored when trying to auth incoming
invites

Hello All,
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>"

I have the following sip.conf:

[node-a]
type=friend
disallow=all
allow=ulaw
context=incoming-context
host=XXX.XXX.XXX.XXX
transport=udp
username=test
secret=1234

[node-b]
type=friend
disallow=all
allow=ulaw
context=incoming-context
host=YYY.YYY.YYY.YYY
transport=udp
username=test
secret=1234



If I auth using "node-a" as the username when sending an invite from
that
host, everything works.  If I auth with "test" as the username from
node-a,
it fails with the error above.  It appears that peer name is always being
used for digest auth, rather than the contents of
username.   Is "username" the wrong place to specify this?

Thanks for your help!

--
_____________________________________________________________________
-- 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

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