Repository navigation
pjsua: --rereg-delay is ignored for accounts given on the command line #5305
Description
Summary
The pjsua sample app's --rereg-delay option has no effect on accounts given on the command line. It is parsed into the account's reg_retry_interval:
pjproject/pjsip-apps/src/pjsua/pjsua_app_config.c
Lines 1048 to 1050 in a67b8e8
| case OPT_REG_RETRY_INTERVAL: | |
| cur_acc->reg_retry_interval = (unsigned)pj_strtoul(pj_cstr(&tmp, pj_optarg)); | |
| break; |
but the "Add accounts" loop in app_init() runs after option parsing and overwrites it with a hardcoded 300 on every such account, next to a hardcoded reg_first_retry_interval = 60:
pjproject/pjsip-apps/src/pjsua/pjsua_app.c
Lines 2186 to 2190 in a67b8e8
| /* Add accounts */ | |
| for (i=0; i<app_config.acc_cnt; ++i) { | |
| app_config.acc_cfg[i].rtp_cfg = app_config.rtp_cfg; | |
| app_config.acc_cfg[i].reg_retry_interval = 300; | |
| app_config.acc_cfg[i].reg_first_retry_interval = 60; |
Because the value always ends up at the default, write_account_settings() never writes the option back either. Accounts added at run time (+a, acc add) start from pjsua_acc_config_default() and are not overridden, so they get the library defaults (300 and 0) instead of 300 and 60.
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.
Steps to reproduce
Run pjsua against a TCP registrar port with nothing listening on it:
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
Expected: after the first retry, registration is retried about every 30 s (±10 s from reg_retry_random_interval). Actual: the next retry comes after about 300 s, whatever --rereg-delay says. The first retry comes after about 60 s because of the hardcoded reg_first_retry_interval = 60, which is a separate default and not what this issue is about.
History
Both assignments came in with 1.x r3804 (#1383, the update of the transport adapter sample), which mentions neither, and reached 2.0 with the 1.x backport. --rereg-delay is older (#1044). I found nothing suggesting that overriding the option was intended.
Fix
#5306 drops the reg_retry_interval override, so the parsed value survives, and says in --help that --rereg-delay=0 disables auto re-registration. The reg_first_retry_interval = 60 default is left as it is.
Suggested labels
component: applications, type: bug.
Version and context
master a67b8e81b. macOS 26 on arm64, default configure; the code path is platform-independent.
Log
Level 4, the two retries from the run above:
15:11:29.071 pjsua_acc.c ..SIP registration failed, status=503 (Connection refused)
15:11:29.071 pjsua_acc.c ..Scheduling re-registration retry for acc 1 in 68 seconds..
15:12:37.320 pjsua_acc.c ..SIP registration failed, status=503 (Connection refused)
15:12:37.320 pjsua_acc.c ..Scheduling re-registration retry for acc 1 in 308 seconds..
Activity