Opened 7 months ago

#2134 new defect

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.

Change History (0)

Note: See TracTickets for help on using tickets.