[OpenSIPS-Users] OpenSIPS 3.1 - Mid_Registrar AOR throttling & FreePBX/Asterisk Expiry problem

[Mark Allen]

I'm seeing strange behaviour using mid_registrar with AOR throttling...

On initial registration, I do a mid_registrar_save():

        mid_registrar_save("location","mp0v","sip:$tU at midreg",,"vipx");

Return value from save is "1" (success) and then I successfully forward the
REGISTER to the FreePBX/Asterisk main registrar (so far so good!).

Asterisk returns a "200 OK" to OpenSIPS which has the registration expiry
value set in both the "Expires" header and in the "Contact" header...

        SIP/2.0 200 OK
        Expires: 600
        Contact: <sip:xxxx%40midreg at xxx.xxx.xxx.xxx:5060>;expires=600

Mid_Registrar forwards this on to the UAC after modifying the expiry value
for AOR throttling, but only the "expires" setting in the "Contact" header
gets modified...

        SIP/2.0 200 OK
        Expires: 600
        Contact: <sip:350203 at 192.168.50.7:50614;ob>;expires=300

This leads to the unpredictable behaviour I'm seeing. MicoSIP seems to
prefer to use the "Contact" header expiry value, and so works fine,
however, Blink and a test MizuTech softphone seem to prefer the "Expires"
header value, and so are not using the AOR throttling value.

In the above example, Mid_Registrar is expecting the UAC to REGISTER again
before 300 seconds have elapsed to maintain the registration, but Blink or
the MizuTech softphone believe they should renew their registration before
600 seconds. When Mid_Registrar does not get the expected registration at
around 300 seconds it assumes the connection is lost and de-registers on
Asterisk. Finally, the UAC renews the registration at around 600 seconds
meaning the UAC is effectively cycling between being available/unavailable.

I have written a workaround in our config file to remove the invalid value
before the "200 OK" gets forwarded to the UAC, but should mid_registrar be
changing the expiry value in both places?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210203/6ed45453/attachment.html>