[OpenSIPS-Users] Question on mid_registrar de-registrations

[Daren FERREIRA]

Great!

Thank you for your tips.
With the debug, I think I found the culprit:

Jan 17 17:26:16 opensips[2810991]: DBG:usrloc:run_ul_callbacks: contact=0x7f90c91662b0, callback type 128/208, id 1 entered
Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:mid_reg_aor_event: AOR callback (128): contact=‘4413 at myhost.mydomain.com'
Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:build_unregister_hdrs: building contact from uri 'sip:4413%40myhost.mydomain.com at 192.168.10.11:5060'
Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:build_unregister_hdrs: extra hdrs: 'Contact: <sip:4413%40myhost.mydomain.com at 192.168.10.11:5060>;expires=0#015#012'
Jan 17 17:26:16 opensips[2810991]: DBG:tm:t_uac: next_hop=<sip:myhost.mydomain.com>
Jan 17 17:26:16 opensips[2810991]: DBG:core:mk_proxy: doing DNS lookup...
Jan 17 17:26:16 opensips[2810991]: DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!

If I well understand, OpenSIPS tries to generate the de-register, and first, determine the destination of the de-register (from AOR ?)
It considers it knows not enough about the protocol and port to use to generate the de-register and try to fill these informations from DNS.
This logically fails because there is no SRV nor NAPTR records for the FQDN extracted (from AOR).

On UL database we have:

  "AOR": "4413 at myhost.mydomain.com",
  "Contacts": [
    {
      "Contact": "sip:4413 at 10.124.112.93:8851;rinstance=B470D0A1",
      "ContactID": "4067622841722148511",
      "Expires": "expired",
      "Q": "",
      "Callid": "9838BED5A44A0EC828005D9103086185EB431CDB",
      "Cseq": 106,
      "User-agent": "Clientt/4.6 (build 1377598; Android 11; arm64-v8a)",
      "Received": "sip:37.166.229.129:54630",
      "State": "CS_SYNC",
      "Flags": 0,
      "Cflags": "NAT",
      "Socket": "udp:192.168.10.11:5060",
      "Methods": 5183
    }
  ]

I didn’t find how to, either define the default port and protocol, or to add it to the UL database at mid_registrar_save.

Should I generate a custom AOR containing something like sip:$domain:5060 at every mid_registrar_save ?

Thank you very much for your help.

Best regards




> Le 17 janv. 2023 à 16:57, Liviu Chircu <liviu at opensips.org> a écrit :
> 
> On 17.01.2023 17:09, Daren FERREIRA wrote:
>> 
>> 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?
>> 
> You understood it perfectly.  My suggestion would be to skim through the code of mid_reg_aor_event() <https://github.com/OpenSIPS/opensips/blob/master/modules/mid_registrar/ulcb.c#L249> internal callback (it's pretty straight-forward), to get an idea of the DEBUG logging it can do, as well as "OK" code paths and "NOT OK" code paths.
> 
> Once you know what to look for, try to put OpenSIPS in debug mode ("opensips-cli -x mi log_level 4") and follow with the DEBUG logs when the AoR is deleted by the timer process.  Let's see what it prints!  Of course, you should put it back to normal logging ASAP afterwards.
> 
> Best regards,
> 
> -- 
> Liviu Chircu
> www.twitter.com/liviuchircu <http://www.twitter.com/liviuchircu> | www.opensips-solutions.com <http://www.opensips-solutions.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230117/a3f612d3/attachment-0001.html>