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

Daniel-Constantin Mierla miconda at gmail.com
Mon Jul 29 10:59:52 CEST 2019


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
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/20190729/3dcd38a3/attachment.html>


More information about the sr-users mailing list