Summary:ASTERISK-01421: [patch] SIP BYE isn't authorized due to wrong username being sent
Reporter:slepp (slepp)Labels:
Date Opened:2004-04-17 03:57:24Date Closed:2008-01-15 14:53:12.000-0600
Versions:Frequency of
Environment:Attachments:( 0) sip_1_335.txt
Description:Not sure if this is because I don't know how it is supposed to work or not, but this is the problem. When sending a SIP BYE message to a peer with a username that isn't the same as it's peer name, and it was an incoming SIP call, it cannot send a SIP BYE properly with authentication. It sends the peer name, not the username for authorization.

It works fine when p->peername is set to p->username in build_reply_digest. This is in relation to CVS 1.0 stable.


Comments:By: slepp (slepp) 2004-04-17 04:07:21

In the sip debug, the incoming call should match the peer sphone-out. When asterisk tries to hang up the call, it sends the username 'sphone-out', instead of the real username for the peer, 17806691185.

By: Brian West (bkw918) 2004-04-18 02:12:09

Try setting username= and see what it does.


By: Olle Johansson (oej) 2004-04-18 04:16:45

I've seen this as well. The username stuff is really messy in chan_sip. I guess that what you want is really an authentication id, something that's different from peername and SIP address-of-record.

By: slepp (slepp) 2004-04-18 06:14:07

bkw, you didn't check the patch, did you. :> Here's the sip.conf entry:

type            = peer
accountcode     = sphone-out
context         = from-vonage
secret          = mypass
username        = 17806691185
fromuser        = 17806691185
fromdomain      = sip.vonage.net
host            = sphone.vopr.vonage.net
port            = 5061
nat             = no
callerid        = "NetMonks" <780-669-1185>
canreinvite     = no
disallow        = all
allow           = g729
allow           = ulaw

It's all set the way it should be. Username was set before. The chan_sip code uses p->peername, not p->username when it sends the digest reply. So, it wasn't a configuration issue.

By: Brian West (bkw918) 2004-04-18 11:16:36

just double checking :P

By: Olle Johansson (oej) 2004-04-24 16:45:13

Slepp: It's late and I'm trying to understand. You're using asterisk as a SIP client with register=> somewhere, right?

I am a bit afraid of starting to user p->username, it's a bit shaky and keeps changing...

We really need an auth_user or clean up the username usage. Anyone that can tell me what it is thought to be used for originally?

By: slepp (slepp) 2004-04-24 21:17:19

I have a register => line, but I don't believe this is affecting it any. The registration is fine. It's when it creates the reply_digest for a SIP response to say a 401 or 407 error (Proxy Authentication Required), it uses the 'peername', when in reality, it should be using the username specified (or fromuser or something). I would have to set the peer name to be 17806691185 in this specific case to make it do what it should be. Instead, it's sending my peer name (sphone-out) as my username. Part of this reason may be that the SIP peer is actually a set of more than one server, but somehow asterisk matches it to the sphone-out peer entry..

The thing it does is this (as is shown in the SIP debug):

Digest username="sphone-out", nonce="", etc. etc.
It should show:
Digest username="17806691185", which is the name used in the 'register' statement and in the 'username' field of the configuration. When the build_reply_digest is set to use the p->username instead of p->peername, it works 100% and I haven't had a single problem with it on any SIP device I have (7940, SIP software phones, FWD).

By: Olle Johansson (oej) 2004-04-25 03:08:13

I needed to find out what you have in there. The matching is a bit interesting in this case.

Check debug output and see if it matches peer on IP address.

The IP address matching we have in there scares me a bit.

By: slepp (slepp) 2004-04-25 04:04:39

The matching is working, basically. It SHOULD match that as the incoming peer, but, it doesn't send the username. That's the problem. It sends the peer name for the entry. If it didn't match on the IP, or some other trinket, then I have no idea where it would get sphone-out from anyway. This is a simple problem, the rest of the code seems to be doing what it should in this case. It finds that the incoming call is coming from the peer sphone-out, BUT, it sends p->peername, not p->username, as the username. And, the other end goes 'I don't know who you are, go away'.. That's about it.

By: Mark Spencer (markster) 2004-04-26 08:19:37

Fixed in CVS head.  I'm reluctant to change it in CVS stable.

By: slepp (slepp) 2004-05-02 05:02:55

I saw the change was reverted from CVS today. The right answer is to have username= set, which I do.. That's the weird part. I have username set, but it still sends username=peername to the other end, no matter what I set the username to. It's clear in the code that it uses peername explicitly at all times, and doesn't even look for a username.. Is this right?

By: Brian West (bkw918) 2004-05-02 12:17:26

See if the fix just applied takes care of this.


By: Mark Spencer (markster) 2004-05-02 12:22:33

It looks like it pulls the peername from the username of the associated "friend" section (be sure you're using a friend section).  See create_addr function:

    strncpy(r->peername, p->username, sizeof(r->peername)-1);

The issue here I guess is that this is an *incoming* call and you want us still to  authenticate with the username that we would use to authenticate to it if we had originated the call.

So, I've add yet-another-field to accomodate yet-another-piece-of-crap SIP complication.  So, this time it *should* work by using the username as the "authname" on an incoming call.  Please confirm, asap

By: slepp (slepp) 2004-05-02 18:56:17

Tested with authname, it works as expected. For both incoming and outbound calls.

By: Digium Subversion (svnbot) 2008-01-15 14:53:06.000-0600

Repository: asterisk
Revision: 2852

U   trunk/channels/chan_sip.c

r2852 | markster | 2008-01-15 14:53:06 -0600 (Tue, 15 Jan 2008) | 2 lines

Revert earlier changes.  The right answer for bug ASTERISK-1421 should be using username=



By: Digium Subversion (svnbot) 2008-01-15 14:53:12.000-0600

Repository: asterisk
Revision: 2859

U   trunk/channels/chan_sip.c

r2859 | markster | 2008-01-15 14:53:12 -0600 (Tue, 15 Jan 2008) | 2 lines

Add new "authname" field so we can authenticate BYE properly on incoming calls (bug ASTERISK-1421)