[OpenSIPS-Users] Question on mid_registrar de-registrations

[Daren FERREIRA]

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 <darencrew at 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 <liviu at 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 at 192.168.10.11:5060> <mailto:sip:4413%40myhost.mydomain.com at 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 at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230118/578f8319/attachment-0001.html>