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

[Mark Allen]

RFC 3261 says...

'The "expires" parameter of a Contact header field value indicates how long
the URI is valid.  The value of the parameter is a number indicating
seconds.  If this parameter is not provided, the value of the Expires
header field determines how long the URI is valid.'

...I know that Asterisk is returning a value in both fields, but the
mid_registrar seems to be only updating the *Contact* header's expiry value
in some cases. This means that the simple solution is to just remove the
*Expires* header value to avoid any conflict. The value in the *Contact*
header is now the single version of the truth for all apps to use as per
the RFC. I just use a reply route in opensips.cfg to remove the *Expires*
header from the 200OK when it arrives from Asterisk...

onreply_route[fix_expiry] {
    if ($rs == "200" && $rm == "REGISTER") {
        remove_hf("Expires");
    }
}



On Fri, 19 Mar 2021 at 19:48, Ricardo Martinez <rmartinez at redvoiss.net>
wrote:

> Do you have some tip to solve this issue ??.
> Did you use the .conf file or did you have to modify the sources ??
>
> Thanks
> Ricardo
>
> El vie., 19 de marzo de 2021 4:04 p. m., Mark Allen <mark at allenclan.co.uk>
> escribió:
>
>> Yes it was still happening the last time I checked. I got the script to
>> re-write the value to get around the problem
>>
>> On Fri, 19 Mar 2021, 18:15 Ricardo Martinez, <rmartinez at redvoiss.net>
>> wrote:
>>
>>> Hi Mark.
>>>
>>> Do you still have the same problem?.
>>>
>>> Did you manage to solve it?.
>>>
>>>
>>>
>>> Ricardo.-
>>>
>>>
>>>
>>> *De:* Users <users-bounces at lists.opensips.org> *En nombre de *Mark Allen
>>> *Enviado el:* miércoles, 3 de febrero de 2021 8:42
>>> *Para:* OpenSIPS users mailling list <users at lists.opensips.org>
>>> *Asunto:* [OpenSIPS-Users] OpenSIPS 3.1 - Mid_Registrar AOR throttling
>>> & FreePBX/Asterisk Expiry problem
>>>
>>>
>>>
>>> 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?
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> 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/20210319/e04510ee/attachment.html>