<div dir="ltr"><font face="monospace">I'm seeing strange behaviour using mid_registrar with AOR throttling...</font><div><font face="monospace"><br></font></div><div><font face="monospace">On initial registration, I do a mid_registrar_save():</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">        mid_registrar_save("location","mp0v","sip:$tU@midreg",,"vipx");<br></font><div><font face="monospace"><br></font></div><div><font face="monospace">Return value from save is "1" (success) and then I successfully forward the REGISTER to the FreePBX/Asterisk main registrar (so far so good!).</font></div></div><div><font face="monospace"><br></font></div><div><font face="monospace">Asterisk returns a "200 OK" to OpenSIPS which has the registration expiry value set in both the "Expires" header and in the "Contact" header...</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">        SIP/2.0 200 OK<br></font><font face="monospace">        Expires: 600<br>        Contact: <sip:xxxx%40midreg@xxx.xxx.xxx.xxx:5060>;expires=600<br><br></font></div><div><font face="monospace">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...</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">        SIP/2.0 200 OK<br>        Expires: 600<br>        Contact: <sip:350203@192.168.50.7:50614;ob>;expires=300</font><br></div><div><font face="monospace"><br></font></div><div><font face="monospace">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. </font></div><div><font face="monospace"><br></font></div><div><font face="monospace">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.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">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?</font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div></div>