<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Great!<div><br></div><div>Thank you for your tips.</div><div>With the debug, I think I found the culprit:</div><div><br></div><div><div>Jan 17 17:26:16 opensips[2810991]: DBG:usrloc:run_ul_callbacks: contact=0x7f90c91662b0, callback type 128/208, id 1 entered</div><div>Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:mid_reg_aor_event: AOR callback (128): contact=‘4413@myhost.mydomain.com'</div><div>Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:build_unregister_hdrs: building contact from uri 'sip:4413%40myhost.mydomain.com@192.168.10.11:5060'</div><div>Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:build_unregister_hdrs: extra hdrs: 'Contact: <sip:4413%40myhost.mydomain.com@192.168.10.11:5060>;expires=0#015#012'</div><div>Jan 17 17:26:16 opensips[2810991]: DBG:tm:t_uac: next_hop=<sip:myhost.mydomain.com></div><div>Jan 17 17:26:16 opensips[2810991]: DBG:core:mk_proxy: doing DNS lookup...</div><div>Jan 17 17:26:16 opensips[2810991]: DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!</div></div><div><br></div><div>If I well understand, OpenSIPS tries to generate the de-register, and first, determine the destination of the de-register (from AOR ?)</div><div>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.</div><div>This logically fails because there is no SRV nor NAPTR records for the FQDN extracted (from AOR).</div><div><br></div><div>On UL database we have:</div><div><br></div><div><div>  "AOR": "4413@myhost.mydomain.com",</div><div>  "Contacts": [</div><div>    {</div><div>      "Contact": "sip:4413@10.124.112.93:8851;rinstance=B470D0A1",</div><div>      "ContactID": "4067622841722148511",</div><div>      "Expires": "expired",</div><div>      "Q": "",</div><div>      "Callid": "9838BED5A44A0EC828005D9103086185EB431CDB",</div><div>      "Cseq": 106,</div><div>      "User-agent": "Clientt/4.6 (build 1377598; Android 11; arm64-v8a)",</div><div>      "Received": "sip:37.166.229.129:54630",</div><div>      "State": "CS_SYNC",</div><div>      "Flags": 0,</div><div>      "Cflags": "NAT",</div><div>      "Socket": "udp:192.168.10.11:5060",</div><div>      "Methods": 5183</div><div>    }</div><div>  ]</div></div><div><br></div><div>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.</div><div><br></div><div>Should I generate a custom AOR containing something like sip:$domain:5060 at every mid_registrar_save ?</div><div><br></div><div>Thank you very much for your help.</div><div><br></div><div>Best regards</div><div><br></div><div><br></div><div><br></div><div><div><br><blockquote type="cite"><div>Le 17 janv. 2023 à 16:57, Liviu Chircu <liviu@opensips.org> a écrit :</div><br class="Apple-interchange-newline"><div>

  
  <div>
    <div class="moz-cite-prefix">On 17.01.2023 17:09, Daren FERREIRA
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:DM6PR04MB6474BD76D075C253DF136B02B0C69@DM6PR04MB6474.namprd04.prod.outlook.com">
      <div><br>
      </div>
      <div>My understanding was opensips should do the cleaning, as
        mentioned on the documentation.</div>
      <div><br>
      </div>
      <div><i>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. </i></div>
      <div><br>
      </div>
      <div>Have I misunderstood?</div>
      <div>If not, what can explain the un-register to never been sent
        by OpenSIPS?</div>
      <div><br>
      </div>
    </blockquote><p><font face="monospace">You understood it perfectly.  My
        suggestion would be to skim through the code of <a moz-do-not-send="true" href="https://github.com/OpenSIPS/opensips/blob/master/modules/mid_registrar/ulcb.c#L249">mid_reg_aor_event()</a>
        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.</font></p><p><font face="monospace">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.<br>
      </font></p><p><font face="monospace">Best regards,</font><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Liviu Chircu
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/liviuchircu">www.twitter.com/liviuchircu</a> | <a class="moz-txt-link-abbreviated" href="http://www.opensips-solutions.com/">www.opensips-solutions.com</a></pre>
  </div>

</div></blockquote></div><br></div></body></html>