[OpenSIPS-Users] mid_register and its possible bad actions with De-REGISTER

[Dmitry Ponomaryov]

Hi OpenSIPS Community, I would like to try to summarize this post as I 
have often been helped by posts in this maillists, maybe mine will help 
someone else too...

Problem:
Was that everything was built on the fact that the backend(main 
registrar) as Asterisk on chan_sip, was accepting registrations via 
mid_registrar with one SIP-number from the same client but from 
different devices, and in this case when the client has a landline and a 
mobile phone for example, mobile phone as it was said in the problem can 
very often re-register with what actually and fights OpenSIPS, when send 
the function callback to usrloc, from which comes the very de-register, 
so this de-register breaks in chan_sip peer, when under one SIP-number 
registered several devices.

Here, of course, we can approach with different workarounds, such as 
transferring registrations to OpenSIPS, switching from chan_sip to 
res_pjsip... and other types of solutions that will lead you to solving 
new problems, but how could you do without it ))

I've looked at quite a few PN question, video/forums/maillists, and in 
total I've managed for Linphone via usrloc/registrar/mid_registrar to 
send push notification, at least for now, on Android, via 
gorush/Firebase, and in total I thought my messages about disabling in 
modparam some callback functions are not important enough, which are 
probably available to OpenSIPS developers, that is, the problem can 
really be tried to solve in another way, well, or make changes in the 
issue at once in the code, which will be checked like code review from 
project developers : )

Cheers.

P.S thanks Johan for a short but revealing answer about PN.
 > or you don't support push notifications.


On 1/9/2024 10:15 AM, Dmitry Ponomaryov wrote:

> Hello Liviu, In my case, AoR throttling was used, before issue (1), do 
> you also think that this is how it should work? (looks like a 
> CRITICAL) > On the other hand, AoR throttling goes beyond this and 
> just makes sure there is always 1 AoR registered downstream. So on a 
> "contact replace" operation, no SIP signaling should reach the 
> Asterisk in that case. the point is that if different devices are 
> registered under the same AoR, one such De-REGISTER, on the final 
> Asterisk completely deletes the peer, although in some of the 
> locations there is still data and if not for the De-REGISTER, Asterisk 
> would have sent its INVITE, we would go through lookup and call all 
> the devices we need from location via some route, this is the problem 
> that we don’t always need De-REGISTER if there is more than one device 
> under the same AoR(when we don't just reduce REGISTER to the main 
> registrar, but use them as REGISTER from diff devices), which breaks 
> peers on Asterisk with De-REGISTER.
>
> but in total, it might be worth making such modparam module 
> mid_registrar to disable De-REGISTER from the OpenSIPS itself, let the 
> registrations themselves expire on the main registrar, and if there is 
> a new registration with a new ctid with ct-throttling schema, then we 
> will simply update peer again... or if someone needs this feature, 
> then let it be possible to choose an interface and not just, for 
> example: socket=1.1.1.1:5060 socket=2.2.2.2:5060 in this case 
> De-REGISTER will go with 1.1.1.1:5060 on main registrar, because it is 
> simply the first one listed socket in cfg. off course, your opinion is 
> needed here, you are developer of this module since 2016 ;) Best regards!
>
> (1): https://github.com/OpenSIPS/opensips/issues/3193
>
> On 1/8/24 14:40, Liviu Chircu wrote:
>> On 27.12.2023 11:38, Dmitry Ponomaryov wrote:
>>>
>>> All this to say, it might make sense to add the ability to disable 
>>> this De-REGISTER, because with a new registration, we will still 
>>> send it a registration with an updated contact before the main 
>>> registrar times out, and there will be no problems, that is, for 
>>> example, the following settings:
>>>
>>> modparam("mid_registrar", "outgoing_expires", 600) 
>>> modparam("mid_registrar", "default_expires", 300) 
>>
>> Hello Dmitry,
>>
>> From your scenario, it sounds like maybe you should enable AoR 
>> throttling, not just Ct throttling? Because in Ct throttling, each 
>> outgoing contact has a unique "ctid=" parameter, so it must be 
>> de-registered from the main registrar on each contact replace, since 
>> the replacement Contact has a new "ctid=", making it an entirely 
>> different SIP URI.
>>
>> On the other hand, AoR throttling goes beyond this and just makes 
>> sure there is always 1 AoR registered downstream.  So on a "contact 
>> replace" operation,  no SIP signaling should reach the Asterisk in 
>> that case.
>>
>> Best regards.