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

[Dmitry Ponomaryov]

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.