Summary:ASTERISK-08329: Authentication using contact user from registration instead of specified
Reporter:Jared Smith (jsmith)Labels:
Date Opened:2006-12-11 10:11:50.000-0600Date Closed:2011-06-07 14:07:46
Versions:Frequency of
Environment:Attachments:( 0) digest-sip-traffic.txt
Description:I'm trying to get two Asterisk boxes (both running the latest 1.4 branch) to talk nicely... I'll call one box Alice and one box Bob.

Alice registers to Bob.  The register statement in Alice's sip.conf looks like:

register => jaredsmith:jaredsmith@

Bob has a peer section that looks like this:


Alice is successfully able to register to Bob, but when Bob sends an invite to Alice (and Alice replies with a 407 Proxy Auth Required), the Proxy Authorization digest username comes along as 's':

INVITE sip:s@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK2cbe5d4d;rport
From: "Asterisk User 6000" <sip:jaredsmith@>;tag=as321b8852
To: <sip:s@>
Contact: <sip:jaredsmith@>
Call-ID: 53a61faf626da7b502ed076829be7bf1@
CSeq: 103 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Proxy-Authorization: Digest username="s", realm="asterisk", algorithm=MD5, uri="sip:s@", nonce="2c6d8877", response="da9ffe708f6889d4ea8eebfc0ba6b6a4", opaque=""
Date: Mon, 11 Dec 2006 15:25:49 GMT
Supported: replaces
Content-Type: application/sdp
Content-Length: 267

Now, that doesn't work because Alice's box complains that the:
[Dec 11 11:09:01] WARNING[15474]: chan_sip.c:8021 check_auth: username mismatch, have <jaredsmith>, digest has <s>

So, where does this "s" come from?

****** STEPS TO REPRODUCE ******

Setup two Asterisk boxes as explained above, and try to get a "user" section on Alice to accept calls from Bob.
Comments:By: Jared Smith (jsmith) 2006-12-11 10:14:56.000-0600

It has been pointed out that if I add "/jaredsmith" to the end of my register statement, that this will force the digest authname to be "jaredsmith", but it also forces the extension on Alice to be "jaredsmith" as well, which is just plain wrong.  The item after the slash on the register line should be just the extension, not the extension *AND* digest username.

By: Olle Johansson (oej) 2006-12-15 05:03:19.000-0600

All of this code involving username is messed up badly.

By: Joshua C. Colp (jcolp) 2006-12-18 20:20:08.000-0600

I agree oej. The user from the contact URI is overwriting the specified one in the configuration. Then when authentication has to take place it uses that instead and the MD5 hashes therefore do not match. Quite a mess.

By: Andrew Green (andrew2007) 2007-01-16 18:57:12.000-0600

A simple workaround for this bug is to add in "insecure=port,invite" to the context you are having trouble with.

Andrew Green

By: Jared Smith (jsmith) 2007-01-18 19:06:48.000-0600

Thanks for pointing out the workaround.  There are lots of ways to work around this particular problem.  My point in filing the bug was to hopefully get it fixed (correctly), not just find a workaround.

By: salvatoregiudice (salvatoregiudice) 2007-02-01 10:21:38.000-0600

work arround didn't work for me. I had to switch to IP auth.

By: Olle Johansson (oej) 2007-02-01 10:41:40.000-0600

Yes, if you register for a service you seldom authenticate incoming calls coming back. But regardless, in this case, I would use realm based auth. add

First, set the realm on the system that registers to the hostname and domain. THen add authentication for the domain in the server. THat way, we will have authentication to use and everything will work smoothly.

Case closed.

By: Olle Johansson (oej) 2007-02-11 12:25:04.000-0600

Since I did not get any comments on my latest comment, I'm closing this bug issue.

By: Leif Madsen (lmadsen) 2007-04-22 16:43:30

More information being added to this BUG.

By: Leif Madsen (lmadsen) 2007-04-22 16:48:13

OK, so I tried to use the domain suggestion by oej with no change in the way this was authenticating. Perhaps I'm using it wrong, but I'm adding the fromdomain to the peer and the domain to match it in the [general] section.

Even with this, I still get the same issue as previously, so I went around trying some other things. Here is the configuration I'm using in my Asterisk box:

register => asterisk_a:welcome@


The issue I'm finding is that when I start Asterisk, I get this:

*CLI>     -- Saved useragent "Asterisk PBX" for peer asterisk_b

*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status              
asterisk_b/s         D          5060     Unmonitored

But once I run a 'sip reload' I end up with:

*CLI> sip reload
*CLI>  Reloading SIP
 == Parsing '/etc/asterisk/sip.conf': Found
 == Parsing '/etc/asterisk/users.conf': Found
*CLI>   == Parsing '/etc/asterisk/sip_notify.conf': Found

*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status              
asterisk_b/asterisk_a    D          5060     Unmonitored

Once I do this SIP reload, then things work. There is definitely some kind of parsing bug here.

Perhaps someone can give me an example of how to do this with domains, but as far as I could tell, this simply doesn't work the way it should.

By: Olle Johansson (oej) 2007-04-27 09:15:21

You can't really have type=friend when you're setting up a connection between two asterisk servers. That's rule #1: Only use type=friend when you're setting up a connection to a PHONE.

By: Olle Johansson (oej) 2007-04-27 09:27:50

Jared says that there's a lot of information about type=friend being a NO  NO in the latest edition of your book, blitzrage. Please read that. :-)

By: Olle Johansson (oej) 2007-04-30 02:13:30

Configuration issue. Catch me on IRC or another IM to explain!