[laconicman]

--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 pjsip#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 (pjsip#1383, the update of the transport adapter sample), which doesn't mention it. --rereg-delay itself is older (pjsip#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.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.