[Home]

Summary:ASTERISK-03979: sip show peer load doesn't really load from ARA
Reporter:drmac (drmac)Labels:
Date Opened:2005-04-25 00:50:57Date Closed:2011-06-07 14:10:44
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/DatabaseSupport
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:register a UA.
do "sip show peer <ua-name>"
change something in db, ex: context
now do "sip show peer <ua-name>", should show same as before.
now do "sip show peer <ua-name> load", should show new info as pulled from db, but it doesn't. it shows orig info.

basically what is happening here is that even though "sip_show_peer" is called with arg "load" the code still searches thru the internal &plist, finds the UA info and returns; without doing a db lookup.
Comments:By: drmac (drmac) 2005-04-25 01:03:21

asterisk*CLI> sip show peer 3045
asterisk*CLI>

 * Name       : 3045
 Secret       : <Set>
 MD5Secret    : <Not set>
 Context      : cytel-internal

<##snip>
<##call placed; ast_verbose's placed in pbx.c>

asterisk*CLI>
   -- exists: CONTEXT: cytel-internal      EXTEN: 92815699900

<##snip>
<##the point here is that everything is correct.>

<##now the context in the database was changed; this shows the "load" doesn't work properly cause its still showing the old info>

asterisk*CLI> sip show peer 3045 load
asterisk*CLI>

 * Name       : 3045
 Secret       : <Set>
 MD5Secret    : <Not set>
 Context      : cytel-internal

<##snip>
<##showing what is stored in db>

asterisk*CLI> realtime load sippeers name 3045
                  Column Name  Column Value                  
         --------------------  --------------------                        
                         name  3045                          
                      context  cytel-test                    

<##snip>

asterisk*CLI> sip prune realtime 3045
OK. Peer 3045 was removed from the cache.

asterisk*CLI> sip show peer 3045
Peer 3045 not found.

<##note here that the "load" only worked once the UA was pruned out>

asterisk*CLI> sip show peer 3045 load
asterisk*CLI>

 * Name       : 3045
 Secret       : <Set>
 MD5Secret    : <Not set>
 Context      : cytel-test

<##snip>
<##another call was placed>

asterisk*CLI>
   -- exists: CONTEXT: cytel-internal      EXTEN: 92815699900

<##pbx is still using the old context to make this call>
By: Olle Johansson (oej) 2005-04-26 02:53:06

What is your setting in regards to caching ARA peers?
By: drmac (drmac) 2005-04-26 08:35:06

rtcachefriends=yes
rtupdate=yes
rtautoclear=no
By: Olle Johansson (oej) 2005-04-26 09:08:17

So if you cache friends, they will be cached and that's what you see. YOu need to prune peers before doing sip show peer. Or do you want the "load" parameter to *force* loading?
By: drmac (drmac) 2005-04-26 10:02:03

Yea, I was expecting "load" to *force* an update of the peer information based on what is in the db.

Right now the only way to change peer info is to prune peer, change db, then powercycle UA to get new registration and therefore new info.

The command might be better named "sip peer <peer> reload" or "sip realtime reload peer <peer>"

The BIGGEST problem with this is what I show in my comment below: contexts are not being updated across peer reloads.

If peer A registers with context "mycontext", then you prune A, change A, "sip show peer A load", then make a call, the PBX code uses the original context instead of the new context pulled from ARA.
By: Olle Johansson (oej) 2005-04-26 12:32:50

That behaviour is also true for non-ARA objects - we do not reconfigure active objects.
By: drmac (drmac) 2005-04-26 14:45:10

OK. I'll accept that, but there is still a problem with reconfiguring an inactive object. When you prune a peer, it becomes inactive (rather, destroyed). When that peer re-registers, not all of its information is changed.
By: Kevin P. Fleming (kpfleming) 2005-04-27 00:12:34

I'll disagree with oej here: just having the peer regsitered does not make it 'active', unless there is actually a registration in process at that exact moment. When using non-ARA configs, if you change the peer's context in sip.conf and issue a reload, the peer's context does get changed in memory.

While I'll agree that 'sip peer <name> load' should not necessarily force a reload of that peer, I can see that it would be logical if it did so, unless the peer is involved in a call. Even without that change though, the poster is claiming that a peer that is manually pruned and reloaded does not get its new context, and I don't see how that can happen since the reload happens from the database.

Do you also have users defined here? Remember that an incoming INVITE will use a user in preference to a peer, if it exists.
By: drmac (drmac) 2005-04-27 10:00:26

I use friends for everything. I'll try and get some more debug info on "proving" that the contexts are not updated when you "register->prune->change->register"
By: Kevin P. Fleming (kpfleming) 2005-04-27 11:53:25

If you are using type=friend, then there is a corresponding 'user' entry for the SIP endpoint placing the call, and the context in the peer entry makes no difference. Pruning/reloading the peer entry won't affect calls that the phone makes, you'd have to prune/reload the _user_ entry.
By: Kevin P. Fleming (kpfleming) 2005-04-29 10:44:15

Have you been able to confirm the peer/user behavior? Without those details, we'll have to close this bug as "not an issue".
By: drmac (drmac) 2005-04-29 11:57:53

You can't prune just a "user" entry or just a "peer" entry. The command is "sip prune realtime <username>".

*ahh*..interesting. OK. I just did "sip prune realtime sales" (sales is the username).

Then did "sip show peer sales". Nothing found. But then did "sip show user sales" and it is still there.

So it seems that the prune needs to be changed to delete from both internal lists in chan_sip.

or it needs to be changed to "sip prune peer <name>" and "sip prune user <name>"
By: Kevin P. Fleming (kpfleming) 2005-04-29 12:08:00

OK, that makes sense. I'll take a look.
By: Kevin P. Fleming (kpfleming) 2005-04-29 15:54:21

OK, I've updated 'sip prune realtime' in CVS HEAD (rewritten it, actually). It now supports both users and peers (individually or together), as well as regex-filtering so you can prune entire groups of objects at once.

Please retest this problem once you have upgraded, and if it's still present you can reopen the bug.
By: drmac (drmac) 2005-04-29 18:46:25

what about adding a "both" option: (or "friend")

sip prune realtime [peer|user|friend] [<name>|all|like <pattern>]

having a "both" (or "friend) would deffinatly help in my case as everyone is a friend.

that way some people don't forget about the user if they are used to doing peers and vice versa.

Also, is the "realtime" part necessary? The function already checks to see if it is a realtime peer/user. The word could just be removed. Nothing else needs to change. The error that is printed if the peer/user is not realtime still shows.(just trying to shorten the command).

edited on: 04-29-05 18:46
By: Kevin P. Fleming (kpfleming) 2005-04-29 19:02:37

No, I'm not going to remove 'realtime' from the command name, it makes sense for it to be there.

If you look at the syntax that I committed, you'll see that 'user' and 'peer' are optional. If you actually try it (<G>), you'll see that if you don't specify either one, it does both. It's very easy to prune just a user, just a peer, or the matching halves of a 'friend'.
By: drmac (drmac) 2005-05-02 09:36:53

If I don't define "peer" or "user", "sip prune realtime 3044" is not checking both lists. It seems that it is checking one list, not finding it, then stopping instead of continuing on to the next list.

asterisk*CLI> sip show peer 3044
asterisk*CLI>

 * Name       : 3044
 Secret       : <Not set>
 MD5Secret    : <Set>
 Context      : cytel-internal
 <snip>

asterisk*CLI> sip show user 3044
User 3044 not found.

asterisk*CLI> sip prune realtime 3044
User '3044' not found.

asterisk*CLI> sip show peer 3044 (this should say "Peer 3044 not found" because I just pruned.)

 * Name       : 3044
 Secret       : <Not set>
 MD5Secret    : <Set>
 Context      : cytel-internal
 <snip>
By: drmac (drmac) 2005-05-02 09:38:17

hmmm...something's not right. I'm not getting the "i pruned" message.

asterisk*CLI> sip prune realtime peer 3044
asterisk*CLI> sip show peer 3044
asterisk*CLI>

 * Name       : 3044
 Secret       : <Not set>
 MD5Secret    : <Set>
 Context      : cytel-internal
<snip>
By: Kevin P. Fleming (kpfleming) 2005-05-02 23:17:13

There was no feedback for single-item prune operations; I've corrected that.

I've retested the pruning operation here after simplifying the argument parsing code; please try it again on your system to verify what is happening. After pruning, use 'sip show peers 3044' to show whether the entry is in the list, rather than 'sip show peer' which has the potential to cause a reload from realtime (although that should not be happening, it is possible).

Also please confirm that there is _no_ activity coming from this peer during the time you are doing this; any SIP traffic received from the peer could easily cause it to be reloaded from the realtime database after you manually prune it.
By: Kevin P. Fleming (kpfleming) 2005-05-15 01:19:37

No additional input for 2 weeks, if there is a problem please open a new bug.