[asterisk-bugs] [Asterisk 0016021]: sippeers loaded with realtime are treated as type=friends, no matter what type is in the db
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Oct 6 12:58:56 CDT 2009
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16021
======================================================================
Reported By: Guggemand
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 16021
Category: Resources/res_realtime
Reproducibility: always
Severity: minor
Priority: normal
Status: new
Asterisk Version: 1.6.1.6
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-10-05 12:28 CDT
Last Modified: 2009-10-06 12:58 CDT
======================================================================
Summary: sippeers loaded with realtime are treated as
type=friends, no matter what type is in the db
Description:
When using realtime sippeers the peers show up in both
sip show peer <name> load
sip show user <name> load
They are also matched by this code in chan_sip.c, even though they have
type=peer
/* First find devices based on username (avoid all type=peer's) */
peer = find_peer(of, NULL, TRUE, FINDUSERS, FALSE);
======================================================================
----------------------------------------------------------------------
(0111920) lmadsen (administrator) - 2009-10-06 12:58
https://issues.asterisk.org/view.php?id=16021#c111920
----------------------------------------------------------------------
Some additional information from IRC (thanks seanbright!)
12:23 < Gugge> as far as i can tell realtime in 1.6.1 doesnt load sipusers
anymore, and loads entries from sippeers as both users
and peers, ignoring the type column in the table. Anyone
wanna help me debug why? :)
12:27 <@kpfleming> did you read UPGRADE.txt?
12:27 <@kpfleming> in 1.6.1, 'type=user' is gone
12:30 -!- nandersson [n=nanderss at 72.Red-88-28-236.staticIP.rima-tde.net]
has quit ["Leaving"]
12:32 < Gugge> i read about that somewhere .. but using type=peer in a
static sip.conf avoids the peer lookup in chan_sip.conf
12:32 < Gugge> /* First find devices based on username (avoid all
type=peer's) */
12:32 < Gugge> using realtime nomatter what i type in the type column it
matches there
12:45 < Gugge> kpfleming, would you say its by design that a realtime peer
is matched based on username only, or should i fill a
bugreport?
12:45 <@kpfleming> i do not know enough to say for sure
12:45 < Gugge> if its by design ill just remove the username matching from
my source
12:45 <@kpfleming> i'd suggest raising this question on the asterisk-dev
list
12:45 < Gugge> ill try, thankyou
12:49 <@jsmith> kpfleming: I thought that was just in memory... not in the
config files
12:49 <@kpfleming> maybe i'm misunderstanding then
12:49 <@kpfleming> i think you may be right, actually
12:50 <@kpfleming> both type=peer and type=user are stored in the same
structures
12:50 <@kpfleming> so then this sounds like a bug
12:50 < Gugge> i guess i could try another backend than mysql too
12:50 <@jsmith> "kill the user" was for killing the user structure in
memory, not killing the "user" device type in sip.conf
12:51 <@kpfleming> the backend type should not matter
12:52 < Gugge> it just seems like all entries in the sippeers table is
loaded as frineds
12:52 < Gugge> friends
12:52 < Gugge> no matter if type is set or not on them
12:53 <@kpfleming> yes, i'd say that is a bug, and you should look through
the issue tracker to see if it's been reported already
12:54 < Gugge> will do
Issue History
Date Modified Username Field Change
======================================================================
2009-10-06 12:58 lmadsen Note Added: 0111920
======================================================================
More information about the asterisk-bugs
mailing list