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=‘[email protected]' Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:build_unregister_hdrs: building contact from uri 'sip:4413%[email protected]:5060' Jan 17 17:26:16 opensips[2810991]: DBG:mid_registrar:build_unregister_hdrs: extra hdrs: 'Contact: <sip:4413%[email protected]: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": "[email protected]", "Contacts": [ { "Contact": "sip:[email protected]: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 <[email protected]> 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/>
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
