On 17.01.2023 19:01, Daren FERREIRA wrote:
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'
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).
The mid-registrar will typically *store* 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).
Apparently, you are routing the REGISTER without setting a *$du *(notice
the *"adding next hop: ..."* debug log in send_unregister()
<https://github.com/OpenSIPS/opensips/blob/master/modules/mid_registrar/ulcb.c#L75>,
which is NOT printed), so the mid-registrar attempts to send the
De-REGISTER to *sip:myhost.mydomain.com*, 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.
Hopefully, you have some pointers to look out for now.
Best regards,
--
Liviu Chircu
www.twitter.com/liviuchircu |www.opensips-solutions.com
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
