Ticket #1962 (closed defect: fixed)
Premature STUN socket destruction when there's an error during STUN server resolution
|Reported by:||ming||Owned by:||bennylp|
|Backport to 1.x milestone:||Backported:||no|
Sample stack trace:
(1) resolve_stun_entry() -> pj_stun_sock_start() -> get_mapped_addr() -> sess_fail() -> test_stun_on_status() -> (2) resolve_stun_entry()
The problem is caused if get_mapped_addr() fail, then test_stun_on_status() will destroy the (failed) STUN socket, and calls resolve_stun_entry no (2), which will then try another STUN candidate. However, after returning, the resolve_stun_entry no (1) will destroy the STUN socket again, incorrectly, for the new candidate being tried.
Thanks to Dusan Klinec for the report and the patch.