[Home]

Summary:ASTERISK-12902: Can't use type=friend anymore in sip.conf
Reporter:Leif Madsen (lmadsen)Labels:
Date Opened:2008-10-15 10:55:35Date Closed:2008-11-19 16:28:15.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13705.patch
Description:Seems I can't authenticate a user in sip.conf when using type=friend. A very simple definition in sip.conf:

[200]
type=friend
host=dynamic
context=forTesting

In the sip debug from the CLI I get:

No matching peer for '200' from '192.168.128.129:5060'


But if I change it to type=peer this works. Is this part of the "kill the user" work? If so, shouldn't type=friend still work for backwards compatibility?

Does this mean the type=user is also entirely gone? (haven't tested this part yet)
Comments:By: BJ Weschke (bweschke) 2008-10-15 16:30:48

The code looks like it is still there on trunk in chan_sip to recognize this. I'd need to load /trunk to try to reproduce, but doesn't make any initial sense as to why it wouldn't be working anymore.

               utype = ast_variable_retrieve(cfg, cat, "type");
               if (!utype) {
                       ast_log(LOG_WARNING, "Section '%s' lacks type\n", cat);
                       continue;
               } else {
                       int is_peer = 0;
                       if (!strcasecmp(utype, "user")) {
                               is_peer = 1;
                       } else if (!strcasecmp(utype, "friend")) {
                               is_peer = 1;
                       } else if (!strcasecmp(utype, "peer"))
                               is_peer = 2;
                       else {
                               ast_log(LOG_WARNING, "Unknown type '%s' for '%s' in %s\n", utype, cat, "sip.conf");
                               continue;
                       }
By: BJ Weschke (bweschke) 2008-10-15 16:35:20

try now blitzrage and let me know.
By: Mark Michelson (mmichelson) 2008-10-15 16:42:47

That message you printed, "No matching peer for '200' from '192.168.128.129:5060'" is dangerously close to a piece of code I changed in revision 148376 of trunk.

If you have the opportunity, could you revert the change from revision 148376 and see if the problem persists? You can use the below command to patch your working copy of trunk.

#svn diff -c -148376 | patch -p0;
By: Mark Michelson (mmichelson) 2008-10-15 16:48:58

Oh, and just for the record, I posted my comment at the same time bweschke posted his patch, so even though the note history makes it look like I ignored the patch submitted, that is certainly not the case :)
By: Leif Madsen (lmadsen) 2008-10-20 13:52:05

I confirm the patch resolves my issue!
By: Digium Subversion (svnbot) 2008-10-21 05:51:29

Repository: asterisk
Revision: 151327

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r151327 | bweschke | 2008-10-21 05:51:28 -0500 (Tue, 21 Oct 2008) | 7 lines

Fix configuration parsing so type=friend still identifies "friend" as a peer even though it is now a legacy configuration verb.

(closes issue ASTERISK-12902)
reported by: blitzrage
patched by: bweschke


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=151327
By: Olle Johansson (oej) 2008-10-21 05:59:39

Oops. Kevin and I started working on fixing this at SIPit and, well, this might not be what the original idea was. Oh well.
By: BJ Weschke (bweschke) 2008-10-21 06:07:08

oej when we started talking about this I was also in favor of putting up some kind of "this is deprecated" message when people use type=friend so, at some point, we can eliminate it. We might still want to do this?
By: Olle Johansson (oej) 2008-10-21 06:45:09

My idea was to keep all of that at this point and make sure that the inner workings was fine. Then start changing the configuration file and define new names in a coming release. Depending on the release policy an all that...

But the change you did is not the way the code is structured. We started working with find_peer, which is where the problem really is now. Kevin added some code I could not create myself and I need to fix the rest.
By: Tilghman Lesher (tilghman) 2008-10-22 13:22:25

Seems that this change has broken all of my SIP friends.  When I revert this change, all of my peers are once again able to authenticate.  So this fix is problematic in at least one way.
By: Tilghman Lesher (tilghman) 2008-10-22 13:26:10

My mistake.  Subsequent changes have fixed this in trunk.
By: Tilghman Lesher (tilghman) 2008-10-22 14:40:24

Spoke too soon.  It is still broken:

[Oct 22 14:47:14] NOTICE[5901] chan_sip.c: Registration from '<sip:103@192.168.69.64>' failed for '192.168.69.51' - No matching peer found

By: pj (pj) 2008-10-22 14:54:32

Corydon76, it seems, that you hit bug, that I also have,
look at bugreport ASTERISK-1355644
and try Asterisk SVN-trunk-r148373 (it seems, that commit 148376 broke peer matching in asterisk trunk).
By: Digium Subversion (svnbot) 2008-10-22 15:34:27

Repository: asterisk
Revision: 151642

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r151642 | bweschke | 2008-10-22 15:34:26 -0500 (Wed, 22 Oct 2008) | 3 lines

revert the changes in issue ASTERISK-12902 - it's being re-opened as while the results fixed the complaint in the issue, it introduced other more undesirable issues than what was already reported


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=151642
By: pj (pj) 2008-10-30 08:49:04

I have exactly oposite issue, asterisk doesn't authenticate, if I use type=peer, but it works, if I have type=friend.
I created bugreport ASTERISK-1371811 for this.
By: Olle Johansson (oej) 2008-11-18 06:57:26.000-0600

Is this problem now gone when you're testing with svn trunk?
By: Leif Madsen (lmadsen) 2008-11-19 16:27:32.000-0600

Does not appear to be an issue now. Will close this issue.
By: Leif Madsen (lmadsen) 2008-11-19 16:28:14.000-0600

Does not appear to be an issue in SVN trunk anymore. Closing this issue.