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
Note: See TracTickets for help on using tickets.