On Tue, Jan 12, 2010 at 5:33 AM, Rob Owens <row...@ptd.net> wrote: > Actually, I have managed to get multiple Ekiga instances on my LAN to > work. I used avahi for this, per the advice of somebody on this list. > Although I only tested communication within the LAN. I did not test > simultaneous internet-based calls. > > I've also had multiple Ekiga accounts registered on a single client.
Right, but the point that I'm trying to make is that there is a fundamental difference between multiple accounts in Ekiga, and multiple instances of Ekiga on a machine. When you attempt to run multiple instances of Ekiga on a single machine (this includes the standard LTSP scenario), they are not aware of each other, except to notice that their port is not available. In the latter scenario, Ekiga is aware of these multiple SIP accounts and can manage them and their ports. Similarly, there is a fundamental difference between multiple instances of Ekiga on a LAN, and multiple instances on a machine, because whoever is doing NAT can recognize multiple IP addresses using the same port and manage that with port rewriting. Where port rewriting is not an option, a SIP proxy, such as siproxd can help with this by managing the LAN ports pre-NAT. The easiest way I can see to manage this is to try running Ekiga as a local app. Hopefully this will change the nature of the problem from being multiple instances of Ekiga on a single host, to multiple instances of Ekiga on a single LAN, which should be fundamentally different as summarized above. Failing that, you may have to manually manage your SIP ports. > Is there any fancy iptable rule or other script that can say "oh, you > want port 5060, well that one's taken so I'll give you 5061 instead and > forward all your traffic there"? If not, then I'm back to changing > ports manually and hoping the Ekiga devs implement the above feature. iptables can do all sorts of great things with packets, but to my knowledge has nothing to say about the actual binding of services to ports and interfaces. This relates to why we can manage competing SIP clients on a LAN, even where they have no awareness of each other; it becomes a very different problem on a single host where we lose the leverage of all our great networking tools, which is what iptables is. db ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
