On Mon, Oct 6, 2008 at 2:47 PM, Guido Fischer <fischer_guido at yahoo.de>wrote: > Hi, > I have a question on the pjnath ice-implementation. > Cool. Questions like these don't come up very often here. :) I am trying to use pjsip with ice on a multihomed host. In my understanding > ICE should examin which network and host interface to use by executing > ice-connectivity-checks. Yep. > When testing pjsip/pjnath all packets where routed via the default route. > That's peculiar. > As far as I understand this implementation has only one STUN socket for > each Component(RTP/RTCP) and Dialog. This Socket is used by all candidates > for this component. Yep (excepting the TURN candidate of course, which has its own socket). > > When executing the ice-connecitvity-checks the socket is still bound to the > broadcast ip 0.0.0.0 and a specific port. Yes (except that 0.0.0.0 is not a broadcast address of course. It's INADDR_ANY). > This means all outgoing STUN-requests and traffic will be routed over the > default route rather then the candidates interface. Even if the the > nominated-pair tells us it uses host-ip IP1/interface IF1 it may send the > data over host-ip IP2/interface IF2 because of the default route? That's not exactly accurate. Although there is only one socket that is bound to INADDR_ANY (the 0.0.0.0 address), the OS should (and would) choose the appropriate interface to use depending on the remote candidate IP address and the IP routing that is configured in the system. For most practical uses of ICE, this approach would find the candidate/interface just like the one socket per candidate approach, with the benefit of reducing the number of connectivity checks, i.e. it will make the number of connectivity checks grows linearly with the additional candidates rather than exponentially as with when one socket per candidate approach is used. There is, though, one case where this approach will not find connectivity while the one socket per candidate approach will. It's when you have dual routes, and when the hop *after* the next router fails. We've discussed this very lengthy in MMUSIC list here: http://thread.gmane.org/gmane.ietf.mmusic/5099/focus=5232. > > Is there a perferable way to use the interface linked to the ip of the > candidate on a multihomed host? The connectivity checks should then use the > candidates interface/ip, not the default route. Using SO_BINDTODEVICE > respectively SO_DONOTROUTE would implicate the usage of one socket for each > candidate. > > First of all, it's not true that the one socket approach will not use the correct interface. Please see the MMUSIC discussions for the reference. Considering the benefit of that (the edge case where that approach works) compared to the drawback with the exponential increase of the number of connectivity checks to be done, I decided that one socket approach is better for most uses. One thing for sure, changing pjnath to use one socket per candidate will require significant modifications in ice_strans.c. Cheers Benny regards, > Guido > > _______________________________________________ > 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/20081007/629df0dd/attachment.html>
