Hello again ;) I just found a workaround. This would be OpenSIPS to save the challenge informations it used on the upstream REGISTER, in order to be able to replay them on de-register.
Since the upstream accept « stale » informations as permitted by RFC, the de-register would be successful. According to my understanding, there is actually no ways to do so for now. What do you think about this? Maybe you have a better idea. Thank you Best regards > Le 18 janv. 2023 à 14:30, Daren FERREIRA <darenc...@hotmail.com> a écrit : > > Hello Liviu, > > I just tested using $du, it solved the de-register not to be sent, but > another issue is coming, the de-register challenge… > > 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… > > 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). > > I’m afraid there is no simple solution to this issue. Don’t you think so? > Maybe you have an idea ? > > > > Thank you > > Best regards > >> Le 17 janv. 2023 à 18:37, Liviu Chircu <li...@opensips.org> a écrit : >> >> 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> >>> <mailto: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 <http://www.twitter.com/liviuchircu> | >> www.opensips-solutions.com <http://www.opensips-solutions.com/> > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
