[OpenSIPS-Devel] [opensips] issue about "usrloc expiring location record from different registrar after startup" (#601)

[jalung]

I'm not understanding why it is a problem if Opensips deletes expired usrloc records, wherever they may be. This may be an issue for you, but it is problematic sharing location table among multiple opensips instances on other levels. Most of all, lookups will not work properly because a user might have NAT open with another registrar. I'm not advocating any change in the code though, because there are ways around it, they are just complex. 

My suggestion is a bit unconventional and works around the problem, by not using the lookup function. Scenario: Registrations are not being forwarded and a user may register wherever they want using the same credentilas based on the max allowed contacts limit. Load balancing using DNSSRV. User is registered on four servers and receives a call.

..
save("location") #on all servers using DB-Only
.. 

call comes in: 

Query the location table for contacts, bflags and socket
Manually append the branches setting the $ruri or both $ruri and $du, while manually setting the branch flags and dialog variables for callee here or adding custom record route variable for the remote AOR's. 
 
Manually set the bflags for callee on the receiving remote server based on the custom rr header. Use dialog variables to remember them, then route it out, again no lookup().

For the answered branch, use dialog variables to set bflags again for caller to callee on each reinvite (video request for example during call).

On reboot, the DB will always be current based on the max contacts.

This is not a simple setup though and requires many constructs depending on who the message is from and the type of rtp proxy being used, what routes and flags to be set.  


---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/601#issuecomment-133110526
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20150820/5a2325e5/attachment-0001.htm>