Opened 6 years ago
Last modified 6 years ago
#2134 closed defect
STUN server resolution failure causes delay — at Version 1
Reported by: | ming | Owned by: | bennylp |
---|---|---|---|
Priority: | normal | Milestone: | release-2.9 |
Component: | pjsua-lib | Version: | trunk |
Keywords: | Cc: | ||
Backport to 1.x milestone: | Backported: | no |
Description (last modified by ming)
pjsua_core::resolve_stun_server .... Ignoring STUN resolution failure (by setting) pjsua_core::pjsua_resolve_stun_servers pjsua_core::resolve_stun_entry .... Trying STUN server IPv4 (1 of 1) stun_sock::pj_stun_sock_create stun_sock::pj_stun_sock_start srv_resolver::pj_dns_srv_resolve .... Starting async DNS A query_job resolver::pj_dns_resolver_start_query .... Picked up DNS A record from cache, ttl=616663478 stun_sock::dns_srv_resolver_cb /* called sync. since DNS record is cached*/ stun_sock::get_mapped_addr stun_session::pj_stun_session_create_req stun_session::pj_stun_session_send_msg .... Error sending STUN request: Network is unreachable stun_transaction::pj_stun_client_tsx_create .... STUN client transaction created stun_transaction::pj_stun_client_tsx_send_msg .... STUN sending message (transmit count=1) stun_transaction::tsx_transmit_msg .... STUN error sending message: Network is unreachable stun_session::pj_stun_msg_destroy_tdata stun_session::destroy_tdata .... tdata 0x1030f24a8 destroy request, force=0, tsx=0x1030f2630 stun_transaction::pj_stun_client_tsx_schedule_destroy .... STUN transaction 0x1030f2630 schedule destroy stun_sock::sess_fail .... Session failed because STUN Binding request failed: Network is unreachable pjsua_core::test_stun_on_status .... STUN resolution failed: Network is unreachable /* pjsua_resolve_stun_servers Loops for 64 sec before Timeout */ stun_sock::pj_stun_sock_destroy .... STUN sock 0x103022e28 request, ref_cnt=3 stun_session::pj_stun_session_destroy .... STUN session 0x102918228 destroy request, ref_cnt=3
The issue is caused when DNS resolution (pj_dns_srv_resolve() ) in pj_stun_sock_start() returns synchronously and the DNS resolution callback has been called. However, there is currently no mechanism to propagate the error from inside the callback to stun_sock, thus pj_stun_sock_start() will always return PJ_SUCCESS. This causes pjsua STUN server resolution to continue waiting until it times out.
(Note that this issue first appears because of ticket #1962, which directly returns without setting any error status after synchronous failure, to prevent double destruction.)
Thanks to Imad Khazali for the report and analysis.
Change History (1)
comment:1 Changed 6 years ago by ming
- Description modified (diff)
- Summary changed from STUN IPv4 resolution failure causes delay to STUN server resolution failure causes delay