Default candidate selection in ice_strans.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Fyi, I'm using the pjsua text-based client for testing, not custom code.


On Fri, 2008-09-26 at 11:53 +0100, ext Benny Prijono wrote:
> looking at the code, the ice_strans will call the callback with error
> status when it's got no response from the STUN server, and I suppose
> the application should terminate or retry the initialization in this
> case, rather than continuing the operation. Also the application
> shouldn't use the ice_strans before the callback is called with
> initialization complete status.

Yes, a timeout will trigger the stun_on_status() callback, but this
function will only alter the set of candidates available if the srflx
candidate turns out to the the same as the host candidate, i.e., no NAT.
Otherwise, the srflx candidate remains unset in the list of candidates.

So if I run with stun, no turn, and host candidates allowed, the set of
candidates is initialised as:

0- 0.0.0.0
1- host addr

With the default_cand set to 0.

If no BIND SUCCESS is received, or the STUN server is down, or I'm
braindead and point at the wrong STUN server, then when I start up pjsua
and attempt to make a call to a REGISTERed used, then an ASSERT fails
elsewhere in the code when building an SDP description. It fails when
trying to copy a sockaddr which is neither type ipv4 or v6, I think:

pjsua-i686-pc-linux-gnu: ../src/pj/sock_common.c:376: pj_sockaddr_get_len: Assertion `a->addr.sa_family == PJ_AF_INET || a->addr.sa_family == PJ_AF_INET6' failed.
Aborted

Note that the line number might be out, owing to sprinkling some code
with my own logging statements to track down the problem; the failure
happens in pj_sockaddr_get_len() in sock_common.c; call stack at this
point is:

#0  0xb7f91410 in __kernel_vsyscall ()
#1  0xb7c78085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7c79a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7c7110e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0x08117b2d in pj_sockaddr_get_len ()
#5  0x08117d32 in pj_sockaddr_cp ()
#6  0x080b00ac in transport_get_info ()
#7  0x080b24d2 in transport_get_info ()
#8  0x08063624 in pjsua_media_channel_create_sdp ()
#9  0x08058f59 in pjsua_call_make_call ()
#10 0x0804e8a9 in console_app_main ()
#11 0x0805083b in app_main ()
#12 0x0804b3d0 in main ()


My thinking is that this is avoided if the srflx address is only
considered the default, or isn't added to the list, until after a BIND
has succeeded. Hence my suggestion that the default_cand should be set
within the stun_on_status() and turn_on_state() functions.

Unless I'm thinking about things incorrectly?


Cheers,
-S.






[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux