Update qualifies when AOR configuration changes.

Prior to this change, qualifies would only update in the following
cases:
* A reload of res_pjsip.so was issued.
* A dynamic contact was re-registered after its AOR's qualify_frequency
  had been changed
This does not work well if you are using realtime for your AORs. You can
update your database to have a new qualify_frequency, but the permanent
contacts on that AOR will not have their qualifies updated. And the
dynamic contacts on that AOR will not have their qualifies updated until
the next registration, which could be a long time.

This change seeks to fix this problem by making it so that whenever AOR
configuration is applied, the contacts pertaining to that AOR have their
qualifies updated.

Additions from this patch:
* AOR sorcery objects now have an apply handler that calls into a newly
  added function in the OPTIONS code. This causes all contacts
  associated with that AOR to re-schedule qualifies.
* When it is time to qualify a contact, the OPTIONS code checks to see
  if the AOR can still be retrieved. If not, then qualification is
  canceled on the contact.

Alterations from this patch:
* The registrar code no longer updates contact's qualify_frequence and
  qualify_timeout. There is no point to this since those values already
  get updated when the AOR changes.
* Reloading res_pjsip.so no longer calls the OPTIONS initialization
  function. Reloading res_pjsip.so results in re-loading AORs, which
  results in re-scheduling qualifies.

Change-Id: I2e7c3316da28f389c45954f24c4e9389abac1121

1 files changed, 0 insertions, 1 deletions

diff --git a/res/res_pjsip.c b/res/res_pjsip.c
index b27bbb9bb..6cdd41699 100644
--- a/res/res_pjsip.c
+++ b/res/res_pjsip.c
@@ -4362,7 +4362,6 @@ AST_TEST_DEFINE(xml_sanitization_exceeds_buffer)
 static int reload_configuration_task(void *obj)
 {
 	ast_res_pjsip_reload_configuration();
-	ast_res_pjsip_init_options_handling(1);
 	ast_sip_initialize_dns();
 	return 0;
 }