Ticket #2134 (new defect)

Opened 5 months ago

STUN IPv4 resolution failure causes delay

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


pjsua_core::resolve_stun_server                                             .... Ignoring STUN resolution failure (by setting)
    pjsua_core::resolve_stun_entry                                          .... Trying STUN server IPv4 (1 of 1)
        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_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::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 by ticket #1962 which directly returns without setting any error status after failure, to prevent double destruction. However, setting a final error status is also not desirable since if IPv4 fails, we still need to try IPv6 resolution.

Thanks to Imad Khazali for the report and analysis.

Note: See TracTickets for help on using tickets.