Is your feature request related to a problem? Please describe.
Currently, when receiving a 423 response to a REGISTER request, uac_registrant immediately re-sends the REGISTER request without changing the Expires value, thus creating a lot of useless network traffic and CPU load,
Describe the solution you'd like
I'd like uac_registrant to follow RFC3261 in terms of retrying the REGISTER with the expires parameter of the Contact uri set to the value received in the Min-Expires header of the 423 response, provided that said value is indeed higher than the expires value taken from the configuration database. If it is not, or if the Min-Expiresheader is absent in the 423 response, uac_registrant should treat that as a failure of the registrar.
Moreover, since the very purpose of the 423 is to reduce the load of the registrar, I'd like uac_registrant to store the received Min-Expires value and use it for subsequent updates of the registration rather than the one from the configuration database, to avoid ending up sending two REGISTER requests for each update, one to get the 423 and the other one to actually extend the registration.
Implementation
- Component: uac_registrant
- Type: extension of the default behavior
- Name:
Describe alternatives you've considered
I could not find any useful workaround - it is usually impossible to find out in advance what is the minimum expiration time the registrar tolerates, so you can only learn it the hard way.
Additional context
Is your feature request related to a problem? Please describe.
Currently, when receiving a 423 response to a REGISTER request, uac_registrant immediately re-sends the REGISTER request without changing the Expires value, thus creating a lot of useless network traffic and CPU load,
Describe the solution you'd like
I'd like uac_registrant to follow RFC3261 in terms of retrying the REGISTER with the
expiresparameter of the Contact uri set to the value received in theMin-Expiresheader of the 423 response, provided that said value is indeed higher than theexpiresvalue taken from the configuration database. If it is not, or if theMin-Expiresheader is absent in the 423 response, uac_registrant should treat that as a failure of the registrar.Moreover, since the very purpose of the 423 is to reduce the load of the registrar, I'd like uac_registrant to store the received
Min-Expiresvalue and use it for subsequent updates of the registration rather than the one from the configuration database, to avoid ending up sending two REGISTER requests for each update, one to get the 423 and the other one to actually extend the registration.Implementation
Describe alternatives you've considered
I could not find any useful workaround - it is usually impossible to find out in advance what is the minimum expiration time the registrar tolerates, so you can only learn it the hard way.
Additional context