Hi Craig, > You get three pieces of information from the user: > > a) the IP address in the ILS request > b) the port in the ILS request > c) the IP address that the ILS request comes from (from getpeername) that one is true, however quoting damien (and believing what he wrote on gm-devel this is done in 2 phases.. and unfortunatelly b) is stated only in the 2nd phase) > By definition, c) is always going to be a legal public address. If it is > a private address, then the ILS is being spoofed - throw the request away. fully logical. ;) > If c) is the same as a), or they are both public addresses, then there > is very good chance that the user has a public address, or has good NAT > software. Either way, don't bother doing a portscan - just accept the > info (you can do the portscan if you like - but I bet it will work 99% > of the time) sorry, but from the practical support on #gnomemeeting the 99% is *FAR* from realistic.. if it were like 70% you'd already be counting high, but most probably the real number is around 30-50% because people read very scarely the FAQ about ports.. However with those running on public IP it *USUALLY* is the problem that they forget UDP ports rather than TCP ports and thus the scan of tcp1720 wouldn't help very much (but that's nother story).. Anyway i would vote STRONGLY for doing it anyway. > If c) is different from a), and a) is private, then the user is behind a > NAT firewall and does not know it. Then, you need to detect if they can > actually receive a call. There is no way we can be sure, but if we check > port b) on address c) and there is a socket listening, we can give them > the benefit of the doubt and assume they are able to receive calls. this is technically challenging as this requires the registration to go into the 2nd phase before rejecting the request. Nevertheless, I'm with you that this is the valid solution. What i wonder is: can't we recode some ohphone/openmcu code to form a server which will just provide sanity checks and then disconnect with a message in the GM text-chat? As the text-chat runs through tcp1720 it should be perfectly working through NAT even when the h323-NAT is misconfiugred. And ohphone/openmcu should have enough code to just handshake valid protocols and thus calling like "h323:@config.seconix.com" could tell you "Check passed. You are configured correctly." or "Check failed. You didn't open UDP/RTP ports".. How this could be implemented with NetMeeting i currently lack a proposal though. Maybe some webpage or ticket system for the IP with a webpage for the incoming call IP could be held for the user. Or the ILS registration will use the ticketing system. To me this does sound not like the one solution, but like a means that users could need to fix their broken config.. -- Best regards, Kilian
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil