fix(pjsua): honour --rereg-delay for accounts given on the command line

[laconicman]

Fixes #5305.

--rereg-delay has no effect on accounts given on the command line. pjsua_app_config.c parses it into the account's reg_retry_interval, but the "Add accounts" loop in app_init() then sets reg_retry_interval = 300 on every such account, after option parsing. For the same reason write_account_settings() never writes the option back. Accounts added at run time (+a, acc add) start from pjsua_acc_config_default() and were never overridden.

I found this while writing a SIPp scenario for #5313. pjsua started before SIPp was listening on TCP, so the first REGISTER was refused and the retry came about a minute later, whatever --rereg-delay said. The option is listed in --help and written back by write_account_settings(), so a user has every reason to expect it to work.

The assignment arrived in 1.x r3804 (#1383, the update of the transport adapter sample), which doesn't mention it. --rereg-delay itself is older (#1044).

Two commits:

67453e8a — drop reg_retry_interval = 300. The parsed value now reaches pjsua_acc_add(), and the config dump writes it back. The reg_first_retry_interval = 60 next to it is left alone on purpose: no option sets it, so the first retry after a failure still comes after about 60 s, and --rereg-delay governs the retries after that. In my SIPp case that means the first retry is still a minute away, so this does not shorten it; I worked around it by registering at run time with +a.

2dcd7caa — say in --help that --rereg-delay=0 disables retries. That is what 0 means for reg_retry_interval in pjsua-lib, and the option could not produce 0 before. A non-numeric value parses as 0 and so disables retries too, as it would for --reg-use-proxy; I did not add validation.

Testing

pjsua on macOS against a closed TCP port, reading the "Scheduling re-registration retry for acc 1 in N seconds" log lines:

pjsua --null-audio --no-udp --id sip:test@127.0.0.1 --registrar 'sip:127.0.0.1:5999;transport=tcp' --realm '*' --username test --password test --rereg-delay=30

Build	--rereg-delay	Retries scheduled in (s)
master a67b8e81b	30	68, 308
this PR	30	54, 35
this PR	1	67, 7, 6, 1, 0, 4
this PR	0	none

The first retry is the app's 60 s (randomised by reg_retry_random_interval, 10 s), and the ones after it follow --rereg-delay. For an interval below reg_retry_random_interval, schedule_reregistration() currently draws the delay from 0–10 s, so --rereg-delay=1 and =9 behave alike. That is how the library schedules short intervals today and this PR does not touch it.

With --rereg-delay=30 the dc config dump now includes --rereg-delay 30; on master it has none. make builds without new warnings, and tests/pjsua scripts-run/100_simple.py passes.

[sauwming]

Note on the expected behaviour in the description ("--rereg-delay=1 gives retries within 0–10 s"): that comes from an existing bug in schedule_reregistration(), not from the intended randomisation:

pjproject/pjsip/src/pjsua-lib/pjsua_acc.c

Lines 5530 to 5531 in a67b8e8

	delay.sec = 0;
	delay.msec = (pj_rand() % (delay.sec * 1000 + rand_ms));

delay.sec is zeroed before it is used in the modulo, so any interval below reg_retry_random_interval gives 0–10 s regardless of the value (--rereg-delay=9 behaves the same as =1). This is a library issue and can be fixed separately, but this PR makes it reachable from pjsua.

[sauwming]

With this override gone, --rereg-delay=0 (or a non-numeric value, which pj_strtoul() parses as 0) now sets reg_retry_interval to 0, which disables auto re-registration entirely: after a 503/408 or a transport disconnect the account stays unregistered, with no error at startup. Previously this was masked by the hardcoded 300.

Could we either validate the value in OPT_REG_RETRY_INTERVAL (reject 0 / non-numeric), or document in the --rereg-delay help text that 0 disables re-registration?

[laconicman]

Good catch. A 0 now reaches reg_retry_interval, where pjsua.h documents it as disabling auto re-registration, and the option could not produce 0 before because the app overwrote it. I've added a line to the --rereg-delay usage text saying so (2dcd7ca). I left non-numeric values alone: pj_strtoul() returns 0 for them and --reg-use-proxy is parsed the same way. Happy to reject them if you'd prefer.

[laconicman]

Thank you for pointing out the jitter in your review. As you suggested it went separately: the issue is #5318 and the fix is #5319.

[sauwming]

Removing this changes the first retry after a failure from ~60 s (50–70 s with randomisation) to the library default of 0–10 s for every command-line account, which isn't needed to honour --rereg-delay. Since there's no option to set reg_first_retry_interval, users relying on the old behaviour can't get it back.

Suggest keeping this line and only dropping the reg_retry_interval override, unless the change in first-retry behaviour is intended (in which case it'd be worth mentioning in the description).

[laconicman]

Agreed, I've dropped that commit and left reg_first_retry_interval = 60 as it is: nothing sets it, and it isn't needed to honour the option. The description now says that --rereg-delay governs the retries after the first one, and that the first still comes after about 60 s.

[laconicman]

You're right that the description presented 0–10 s as expected behaviour. I've corrected it: it now says that schedule_reregistration() currently draws the delay from 0–10 s for any interval below reg_retry_random_interval, and that this PR doesn't change that.