[SR-Users] Deleting extra location attribute(location_attrs table) when contact is expired

Daniel-Constantin Mierla miconda at gmail.com
Wed Jul 31 12:01:38 CEST 2019


OK, thanks for testing and feedback. I will backport if it is the case
before the next release from branch 5.2.

Cheers,
Daniel

On 31.07.19 05:34, Pintu Lohar wrote:
> I tested it works well. 
> Thanks Daniel .
>
> Regards 
> Pintu..
>
> On Wed, Jul 31, 2019, 12:09 AM Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Just in case you pulled git master branch before this message, do
>     it again, because the push of the commit to github failed before
>     and I noticed a bit later than sending the previous email.
>
>     Cheers,
>     Daniel
>
>     On 30.07.19 17:00, Daniel-Constantin Mierla wrote:
>>
>>     Can you give another try with latest master? I pushed a patch to
>>     use a static record, getting the one for all contacts in db
>>     seemed redundant there.
>>
>>     Cheers,
>>     Daniel
>>
>>     On 30.07.19 04:54, Pintu Lohar wrote:
>>>
>>>     On Mon, Jul 29, 2019 at 7:16 PM Pintu Lohar
>>>     <pintulohargcetts at gmail.com <mailto:pintulohargcetts at gmail.com>>
>>>     wrote:
>>>     [Removed Attachment here due to size limit and resent]
>>>
>>>         Took the master branch , Have noticed same problem , but
>>>         noticed "failed to get a record" and 
>>>         not executing uldb_delete_attrs_ruid() , however location
>>>         recored is removed not the location_attr record. 
>>>
>>>         Tried to check the log:
>>>
>>>         5(54869) INFO: usrloc [udomain.c:996]:
>>>         udomain_contact_expired_cb(): calling contact expired
>>>         records - cycle [1]
>>>
>>>         5(54869) ERROR: usrloc [udomain.c:1017]:
>>>         udomain_contact_expired_cb(): failed to get a record
>>>
>>>         5(54869) INFO: usrloc [udomain.c:989]:
>>>         udomain_contact_expired_cb(): no rows to be contact expired
>>>
>>>         5(54869) INFO: usrloc [udomain.c:989]:
>>>         udomain_contact_expired_cb(): no rows to be contact expired
>>>
>>>         5(54869) INFO: usrloc [udomain.c:989]:
>>>         udomain_contact_expired_cb(): no rows to be contact expired
>>>
>>>         5(54869) INFO: usrloc [udomain.c:989]:
>>>         udomain_contact_expired_cb(): no rows to be contact expired
>>>
>>>         5(54869) INFO: usrloc [udomain.c:989]:
>>>         udomain_contact_expired_cb(): no rows to be contact expired
>>>
>>>         5(54869) INFO: usrloc [udomain.c:989]:
>>>         udomain_contact_expired_cb(): no rows to be contact expired
>>>
>>>         5(54869) INFO: usrloc [udomain.c:989]:
>>>         udomain_contact_expired_cb(): no rows to be contact expired
>>>
>>>         5(54869) INFO: usrloc [udomain.c:996]:
>>>         udomain_contact_expired_cb(): calling contact expired
>>>         records - cycle [1] .  
>>>
>>>         5(54869) ERROR: usrloc [udomain.c:1017]:
>>>         udomain_contact_expired_cb(): failed to get a record 
>>>
>>>
>>>
>>>
>>>         Am I missing something? 
>>>
>>>        
>>>
>>>         Thanks. 
>>>         Pintu 
>>>
>>>         On Mon, Jul 29, 2019 at 6:08 PM Pintu Lohar
>>>         <pintulohargcetts at gmail.com
>>>         <mailto:pintulohargcetts at gmail.com>> wrote:
>>>
>>>             Wow so fast. I will try the master branch and share it
>>>             with you the result soon.
>>>
>>>             Thanks indeed.
>>>
>>>             Thanks & Regards 
>>>             Pintu 
>>>
>>>             On Mon, Jul 29, 2019, 5:59 PM Daniel-Constantin Mierla
>>>             <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>>
>>>                 Hello,
>>>
>>>                 I pushed some changes to the master branch trying to
>>>                 get to a solution without introducing a new column
>>>                 to store expires value for attrs records, but for
>>>                 the next version might be better to just add that
>>>                 column and delete using it.
>>>
>>>                 Try the master branch and see if it works.
>>>
>>>                 You can also run a rtimer with a delete on condition
>>>                 for last modified value, as you already said previously.
>>>
>>>                 Cheers,
>>>                 Daniel
>>>
>>>                 On 29.07.19 10:16, Pintu Lohar wrote:
>>>>                 Hi Daniel,
>>>>
>>>>                 It's about the contract expired and deleted from
>>>>                 "location" but not deleted from location_attr table
>>>>                 when expired contact is found. My settings are below 
>>>>
>>>>                 1. modparam("usrloc", "timer_interval", 120)
>>>>                 2. modparam("tm|usrloc", "xavp_contact", "ulattrs")
>>>>                 3. Usrloc is set to DB_ONLY Mode.  
>>>>                 4. //// route block when the extra location attr
>>>>                 before saving . 
>>>>                 # Handle SIP registrations
>>>>                 route[REGISTRAR] {
>>>>                 if (!is_method("REGISTER")) return;
>>>>
>>>>                 if(isflagset(FLT_NATS)) {
>>>>                 setbflag(FLB_NATB);
>>>>                 #!ifdef WITH_NATSIPPING
>>>>                 # do SIP NAT pinging
>>>>                 setbflag(FLB_NATSIPPING);
>>>>                 #!endif
>>>>                 }
>>>>                 *$xavp(ulattrs=>did)=$hdr(P-Asserted-Identity); #
>>>>                 this adds to location_attr table.. *
>>>>                 if (!save("location")) {
>>>>                 sl_reply_error();
>>>>                 }
>>>>
>>>>
>>>>
>>>>                 Like if Client Registered , and went
>>>>                 offline/crashed,(expiry i.e 3600, proto=TLS) then
>>>>                 contact is expired after 1 hour then it's removed
>>>>                 from location table but the attribute set which is
>>>>                 added for location_attr(for same ruid) is not
>>>>                 deleted from db.
>>>>                 Thanks & Regards
>>>>                 Pintu 
>>>>
>>>>
>>>>                 -----------
>>>>
>>>>                 On Mon, Jul 29, 2019 at 4:32 PM Daniel-Constantin
>>>>                 Mierla <miconda at gmail.com
>>>>                 <mailto:miconda at gmail.com>> wrote:
>>>>
>>>>                     Hello,
>>>>
>>>>                     is the contact expired and not updated, or is
>>>>                     about attributes set for a REGISTER request
>>>>                     that should be deleted with the next REGISTER
>>>>                     updating the expires for same contact?
>>>>
>>>>                     Cheers,
>>>>                     Daniel
>>>>
>>>>                     On 29.07.19 08:44, Pintu Lohar wrote:
>>>>>
>>>>>                     Hi All, 
>>>>>
>>>>>
>>>>>                     Regarding modparam("tm|usrloc",
>>>>>                     "xavp_contact", "ulattrs") 
>>>>>
>>>>>
>>>>>                     #ref
>>>>>https://www.kamailio.org/docs/modules/devel/modules/usrloc.html#usrloc.p.xavp_contact
>>>>>                     .
>>>>>
>>>>>                     There is some requirement where we need to
>>>>>                     save some extra location attributes
>>>>>                     to location_attrs
>>>>>                     <https://kamailio.org/docs/db-tables/kamailio-db-4.3.x.html#gen-db-location-attrs> tables 
>>>>>                     $xavp(ulattrs=>deviceIdentify)= "Some str
>>>>>                     values"  and calling save(“location”) , It
>>>>>                     works well and saved  location attribute table
>>>>>                     but  But when contact expired callback is
>>>>>                     received, udomain_contact_expired_db() does
>>>>>                     not it delete the extra location attribute
>>>>>                     from database but deleting the record from
>>>>>                     location table only ? 
>>>>>
>>>>>                     If not, is there any recommended approach to
>>>>>                     delete the extra location attributes from the
>>>>>                     database? or am I missing something to set?
>>>>>
>>>>>
>>>>>                     Alternate I was thinking could be running
>>>>>                     timer from Kamailio config and check
>>>>>                     last_modified time and delete those(based on
>>>>>                     our UAC expiry setting), is it the right approach.
>>>>>
>>>>>                     Kamailio Version: 5.2.0.
>>>>>
>>>>>                     Thanks for your valuable suggestion in advance.
>>>>>
>>>>>                     Regards 
>>>>>
>>>>>                     Pintu Lohar
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                     _______________________________________________
>>>>>                     Kamailio (SER) - Users Mailing List
>>>>>                     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>>>>                     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>                     -- 
>>>>                     Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>>>                     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>>>
>>>                 -- 
>>>                 Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>>                 www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>>
>>     -- 
>>     Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>
>     -- 
>     Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190731/99c5ca09/attachment.html>


More information about the sr-users mailing list