<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;">Hello Liviu,<div><br></div><div>I just tested using $du, it solved the de-register not to be sent, but another issue is coming, the de-register challenge…</div><div><br></div><div>When generating the de-register, the upstream server refuse it and send a challenge OpenSIPS can’t reply because, as a mid-registrar, OpenSIPS doesn’t know the clients credentials…</div><div><br></div><div>The only way to achieve this would be the upstream and OpenSIPS to share a secret way to bypass auth only on generated de-register (an IP based bypass would be a huge breach as it would permit any proxified de/registers to be approved).</div><div><br></div><div>I’m afraid there is no simple solution to this issue. Don’t you think so? Maybe you have an idea ?</div><div><br></div><div><br></div><div><br></div><div>Thank you</div><div><br></div><div>Best regards<br><div><br><blockquote type="cite"><div>Le 17 janv. 2023 à 18:37, Liviu Chircu <liviu@opensips.org> a écrit :</div><br class="Apple-interchange-newline"><div>
<div>
<div class="moz-cite-prefix">On 17.01.2023 19:01, Daren FERREIRA
wrote:<br>
</div>
<blockquote type="cite" cite="mid:DM6PR04MB647480951BC19B17FF6EAFF6B0C69@DM6PR04MB6474.namprd04.prod.outlook.com">
<div>
<div>Jan 17 17:26:16 opensips[2810991]:
DBG:mid_registrar:build_unregister_hdrs: extra hdrs: 'Contact:
<a class="moz-txt-link-rfc2396E" href="mailto:sip:4413%40myhost.mydomain.com@192.168.10.11:5060"><sip:4413%40myhost.mydomain.com@192.168.10.11:5060></a>;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>
</blockquote><p><font face="monospace">The mid-registrar will typically <b>store</b>
the R-URI ($ru) + Destination-URI ($du) combination, after you
t_relay() the REGISTER towards the main registrar. This info
will be used in order to route a De-REGISTER in the exact same
way (same message R-URI, sent to the same box).</font></p><p><font face="monospace">Apparently, you are routing the REGISTER
without setting a <b>$du </b>(notice the <b>"adding next hop:
..."</b> debug log in <a moz-do-not-send="true" href="https://github.com/OpenSIPS/opensips/blob/master/modules/mid_registrar/ulcb.c#L75">send_unregister()</a>,
which is NOT printed), so the mid-registrar attempts to send the
De-REGISTER to <b>sip:myhost.mydomain.com</b>, which was
grabbed either from the R-URI (most likely) or To header of the
initial REGISTER. And, before sending the packet, of course it
needs to resolve the hostname to an IP address. If there are
any issues during this resolution... you must let me know of any
relevant logs, as I have no idea.<br>
</font></p><p><font face="monospace">Hopefully, you have some pointers to look
out for now.<br>
</font></p><p><font face="monospace">Best regards,<br>
</font></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>