On Thu, Sep 25, 2008 at 7:36 AM, Stephen D. Strowes < stephen.strowes at nokia.com> wrote: > Hi, > > Regarding ICE strans in the PJNATH library. > > I'm curious as to whether I've misunderstood the 'default candidate' > selection process currently in ice_strans.c. > > At the moment, the default seems to be set while possibly still pending > full initialisation (e.g., if I set stun-srv, the default_cand is set to > indicate that this is the default candidate while STUN is still pending > a response; if a response never arrives, then the default candidate addr > is 0.0.0.0, and things may then fall over on attempting a call). > > Hi Stephen, 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. > Would it make more sense to only set the default candidate to the HOST > address on init, and then subsequently set the default candidate inside > the stun_on_status() and turn_on_status() functions, if a more > appropriate default becomes available? > > As I understand draft-ietf-mmusic-ice-19, the default should be the most > likely candidate to allow a peer to successfully transmit data inbound > (so, generally, relay == most likely, host == least likely, if we assume > the host has nominated a relay for good reason), which is somewhat at > odds with the preferred choice of (host == best, relay == worst). > > Are you sure? Looking at the code (at least the latest one), it looks like ice_strans does exactly that, that is to use TURN, STUN, and host as the order in selecting the default candidate. > But surely if a STUN bind hasn't succeeded, and/or a TURN relay hasn't > been allocated, then the -only- default which can be set is the host. > No? > > The intended use case is to wait until the initialization completes before using the ice_strans, and considering scenarios where resolution/allocation may fail hence causing ICE to not do the intended negotiations across the candidates, that's probably the best practice IMO. 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/0be1a04a/attachment-0001.html>
