Repository navigation
pjsua: no probing connection for the Contact when a resolver may use DNS SRV - #5302
Conversation
nanangizz
left a comment
There was a problem hiding this comment.
The change itself looks right to me. Checking the endpoint's resolver is also more accurate than nameserver_count now that nameservers can change at runtime (#5298 detaches the resolver when they are cleared). A few things, mostly in the test; details inline.
One more, outside the diff: the pjsua2 copy of this doc, contactUseSrcPort in pjsip/include/pjsua2/account.hpp (lines 779-785), still says the feature is turned off only "when nameserver is configured". It should get the same wording as the pjsua.h change here.
| if (rc == 0) | ||
| rc = pjsua_ip_change_case(PJ_FALSE); | ||
| if (rc == 0) | ||
| rc = pjsua_contact_probe_case(); |
There was a problem hiding this comment.
This conflicts with master: #5298 added pjsua_keeps_option_case() and pjsua_restore_once_case() at this same spot and renamed restore_endpt() to restore_test_endpt(). Appending this case after pjsua_restore_once_case(PJ_TRUE) resolves it.
There was a problem hiding this comment.
Rebased, the case follows the restore ones now.
| PJ_LOG(3,(THIS_FILE, " Contact with an external resolver")); | ||
|
|
||
| if (pjsua_create() != PJ_SUCCESS) | ||
| return -3120; |
There was a problem hiding this comment.
-3120 to -3126 are already used earlier in this file (from line 1304 on), so a failure code wouldn't tell which test failed. -3180 and up look free on master (#5303 takes -3170 to -3177).
There was a problem hiding this comment.
Renumbered to -3180 .. -3187.
| pjsua_destroy(); | ||
| return -3121; | ||
| } | ||
| pjsip_endpt_set_ext_resolver(pjsua_get_pjsip_endpt(), &ext); |
There was a problem hiding this comment.
Minor: the return value isn't checked. If it fails, the case would probe as before and report a Contact mismatch instead of the real cause.
| pjsip_endpt_set_ext_resolver(pjsua_get_pjsip_endpt(), &ext); | ||
| pjsua_transport_config_default(&tcfg); | ||
| tcfg.port = 0; | ||
| if (pjsua_transport_create(PJSIP_TRANSPORT_TCP, &tcfg, &tp_id) != PJ_SUCCESS || |
There was a problem hiding this comment.
Nit: 83 columns.
| if (pjsua_transport_create(PJSIP_TRANSPORT_TCP, &tcfg, &tp_id) != PJ_SUCCESS || | |
| if (pjsua_transport_create(PJSIP_TRANSPORT_TCP, &tcfg, | |
| &tp_id) != PJ_SUCCESS || |
| tpmgr = pjsip_endpt_get_tpmgr(pjsua_get_pjsip_endpt()); | ||
| tp_cnt = pjsip_tpmgr_get_transport_count(tpmgr); | ||
| pool = pjsua_pool_create("probe", 512, 512); | ||
| if (pjsua_acc_create_uac_contact(pool, &contact, acc_id, &uri) != PJ_SUCCESS) { |
There was a problem hiding this comment.
Nit: 83 columns.
| if (pjsua_acc_create_uac_contact(pool, &contact, acc_id, &uri) != PJ_SUCCESS) { | |
| if (pjsua_acc_create_uac_contact(pool, &contact, acc_id, | |
| &uri) != PJ_SUCCESS) | |
| { |
4cd33ca to
c9fa394
Compare
|
Thanks. Rebased on master, with the case after |
A follow-up to #5293: using the DNS SRV failover with an external resolver showed this one.
With a TCP or TLS registrar, PJSUA takes the Contact address from a connection it opens to the host's A record on the default port. With DNS SRV the REGISTER goes to another server or port, so the connection is wasted and the Contact carries the port of an unrelated socket. The probe is already skipped with
pjsua_config.nameserver; now also with a DNS or external resolver set on the endpoint, which resolve SRV the same way. Seen on iOS with an external resolver and SRV targets on port 5065: a connection to the host on 5060 before every REGISTER on 5065.As with nameservers, the Contact then takes the listener's port, and PJSUA still registers once more with the port the registrar reports in
rport; only SIP outbound avoids that.Two getters for the external resolver are added. The test checks that the Contact takes the listener's port and no transport is created; it fails on the previous code.
Full pjsip-test passes on macOS and Linux with ASan/LSan.