On Fri, Sep 26, 2008 at 12:54 PM, Stephen D. Strowes < stephen.strowes at nokia.com> wrote: > 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? > > I'm not sure which version are you using, but in recent pjsip this shouldn't happen, as pjsua-lib will wait until ice_strans initialization is complete before application can make any calls. If STUN resolution fails, the media transport initialization will fail too, and in pjsua this would cause it to quit. Cheers Benny > > Cheers, > -S. > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080926/11317de5/attachment-0001.html>
