Ticket #1918 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years ago

Add API to update STUN servers and option to retry STUN for media on failure

Reported by: ming Owned by: bennylp
Priority: normal Milestone: release-2.5.1
Component: pjsua-lib Version: trunk
Keywords: Cc:
Backport to 1.x milestone: Backported: no

Description

Issue:

  1. Start PJSIP with STUN server A, STUN server B (both STUN servers are reachable)
  2. PJSIP will sue STUN server A
  3. STUN server A becomes unreachable, STUN servr B remains reachable
  4. User dials a call
  5. PJSIP tries to resolve call media with STUN server A, but fails. (PJLIB_UTIL_ESTUNNOTRESPOND)
  6. PJSIP does NOT try to fall back to STUN server B (issue)

The ticket will add an API pjsua_update_stun_servers() to update STUN servers list after startup (previously, it can only be specified prior to calling pjsua_init()). Then when call media fails due to pjstun_get_mapped_addr(), we add an option PJSUA_STUN_RETRY_ON_FAILURE in pjsua_acc_config.media_stun_use (by default it's disabled/no retry), which enables retrying other STUN servers when the above scenario happens.

Change History

comment:1 Changed 2 years ago by ming

  • Status changed from new to closed
  • Resolution set to fixed

In 5297:

Fixed #1918: Add API to update STUN servers and option to retry STUN for media on failure

comment:2 Changed 2 years ago by riza

In 5307:

Re #1918: Fixed continous looping when trying to resolve STUN server due to lock handling.
Also move the unusable server to the least prioritize to be chosen on the fallback process.

comment:3 Changed 2 years ago by nanang

In 5326:

Re #1918:

  • Fixed issue of cannot make/receive call after previous call initialization fails due to STUN error, reproducing steps:
    1. Configure an account with acc->cfg.media_stun_use set PJSUA_STUN_RETRY_ON_FAILURE.
    2. Start pjsua with STUN servers A and B configured. On startup, both STUN servers A and B are available, so PJSIP will use STUN server A
    3. Both STUN server A and B become unavailable
    4. Make an outgoing call.
    5. Pjsua first tries with STUN server A, fails
    6. Pjsua then retry with STUN server B, still fails
    7. PJSIP then aborts the call with error (which is desired!)
    8. Both STUN server A and B become available again
    9. User tries to dial or receive an incoming call, but cannot because the last STUN server status is stored and used in making/receiving call without retrying to resolve STUN server.
  • Fixed deadlock issues.
Note: See TracTickets for help on using tickets.