[OpenSIPS-Users] Question on mid_registrar de-registrations

Daren FERREIRA darencrew at hotmail.com
Tue Jan 17 15:09:49 UTC 2023

Hi Liviu,

Thank you for your reply.

I don’t expect an unregister from one device to trigger a de-register for the two, that would be illogic.
It would make sense only if the device is the last registered one. 

In our case, captures would be useless. That would only show no de-REGISTER is sent by OpenSIPS.

Please, let me try to best describe the case and my understanding.

We are in mode==2.
You have several devices registering (2).
The devices register with an expire < 3600 (in our case, around 600).
Opensips registers with a default_expires (3600 by default) (that’s expected, that’s a way to throttle and reduce backend load).

The devices are disconnected from internet, so their registry is not renewed, and expires (from client side view).
OpenSIPS doesn’t send any de-register even if all endpoints registry have expired.

My understanding was opensips should do the cleaning, as mentioned on the documentation.

A common occurence is for some SIP User Agents to lose their network connection (especially when dealing with mobile devices), hence they do not properly de-register from the mid-registrar. In this case, in order to avoid stale registrations on the main registrar (which contains SIP contacts with greatly extended lifetimes!), the mid-registrar will appropriately generate De-REGISTER requests and remove these contacts from the main registrar's location service as soon as it considers them to have expired. 

Have I misunderstood?
If not, what can explain the un-register to never been sent by OpenSIPS?

Thank you

Best regards

> Le 17 janv. 2023 à 15:13, Liviu Chircu <liviu at opensips.org> a écrit :
> On 12.01.2023 17:26, Daren FERREIRA wrote:
>> If I well understood, if a client is registered with a 500 seconds expiry, the server side is set to outgoing_expires, and, if the register is not renewed by the client, opensips should de-register.
>> In my case, the de-registers that should be triggered are never triggered.
>> I found no parameters relative to this in mid_registrar module, but, looking at the source code, it seems it depends on usrloc module.
>> On usrloc module, it seems that contact_refresh_timer is in charge of treating events, like expires, so I tried to enable it, without success.
>> Even after client expiry + timer_interval, the client is not de-registered on server side.
>> Is there anything I may have missed?
> Hi Daren,
> I notice you are using "mode == 2", which means De-REGISTERs will only be generated when the AoR gets deleted.  For example, if you have 2 SIP UAs registering to the same AoR and you are trying to kill one of them in an attempt to see a De-REGISTER being auto-generated downstream, that will never happen!  This is because the remaining Contact is enough to maintain "liveness" of the AoR to the downstream registrar.
> Let me know if this is the case - if not, we can continue digging.  Ideally, a SIP trace (.pcap or .txt) for the entire flow  would be helpful (you can email it to me personally, if privacy is an issue).
> Best regards,
> -- 
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230117/7acc2815/attachment.html>

More information about the Users mailing list