GNOME Bugzilla – Bug 150543
Why is allowing connection to port 80 so hidden?
Last modified: 2004-12-22 21:47:04 UTC
When I start gnomemeeting I get the following message: Error while starting the listener --------------------------------- You will not be able to receive incoming calls. Please check that no other program is already running on the port used by GnomeMeeting First of all, that isnt very descriptive at all.. why not mention the port number on there? Second, why not allow a prompt to allow connections to port 80? -- Thats what skype does and although its technical merits arent as high as gnomemeeting (working through proxy), many (most?) people choose it over gnomemeeting. This is atleast from my experience. I'm still unable to hear my friend's voice in gnomemeeting while its a matter of double clicking his name in skype. Hope I havent insulted anyone, just stating my personal experience with gnomemeeting and maybe some useful ideas. Thank you in advance, Roman Gaufman PS, I have infact found in gconf-editor the ability to use port 80 was unable to get it working however.
Hello, Allowing GnomeMeeting to listen on port 80 won't permit you to go through NAT more easily. This is due to NAT and the use of RTP. Skype has no problems with NAT because it can use another user to proxy the calls, which GnomeMeeting can not do. You should read the FAQ to learn more about what's required at the firewall level to make gnomemeeting work behind NAT. In the end, if you prefer using proprietary software, using a proprietary and non-standard protocol, possibly including spyware and other malicious software, that is your choice. I also doubt there are so many linux skype users.
I clearly marked it as enhancement....
The only enhancement I could do is improve the error message. What are you suggesting else?
Well, you might be surprised by the number of how many people use skype on linux. And it makes a difference between being useable and not. I will read the faq, but if skype uses another user to route the connection, thats quite clever, maybe gnomemeeting should do that? Otherwise its just impossible to use in many situation where NAT configuration is out of your hands. So this isnt a matter of wanting to use proprietary software bombarded with skyware, its simply a need to use voice over ip in situations with gnomemeeting's requirements arent met.
I just want to point another issue with allowing using port 80 for incoming calls. Listening in ports <1024 is reserved to the superuser, thus you wouldn't be able to run gnomemeeting as a normal user or you would have to setuid it root (something thankfully not permited by Gtk+). Btw, I also recomend you to read the FAQ to learn more about the issues to have a H323 tele-conference passing through a firewall.
GnomeMeeting is respecting standard industry protocols like H.323 (and SIP in the future). Those protocols are not peer-2-peer, so you can not use another user for proxying. You could use a central proxy, but I don't have the money required to pay a server and its bandwidth to achieve that purpose. GnomeMeeting has many different ways to go through NAT, it is just a matter of reading the documentation. I'm also happy to learn many people are using Skype on Linux, that probably means I will be able to take long holidays soon.
Well, I followed the instructions on the "Getting it to work behind a firewall" FAQ and by opening ports I was able to make a successful connection with some people. However I still cannot talk to my friend: He can hear me, but I cant hear him (his alsa is definitely properly set up, and he disabled the firewall altogether on his router). So I dont know what to tell you, and I cant seem to track what could be wrong. I'm just not getting any traffic from him. (he uses a speedtouch router.) -- anything you can suggest? SKype however works out of box, without touching firewall, so no idea what could be wrong there. I do understand that skype probably has some non standard protocol, not to mention a powerful server to handle the load, but cant anything be made? -- like a new opensource "non standard" protocol that can just connect p2p? on the edonkey p2p network for instance you can have a single home-ran server that supports >500,000 users and 2 users behind NAT can connect to each other through the server somehow.
Oh, incase "he disabled firewall" is unclear, he set his ip to be a "defserver" which just blindly forwards all traffic to his IP address.
You probably forgot to FORWARD a few ports or to enable IP translation in the gnomemeeting preferences (NAT section). Doing a P2P protocol would be possible, but what companies are using is H.323 or SIP, nothing else.
Notice that with gnomemeeting CVS, if at least one of the 2 participants is on a public IP, or correctly configured (IP translation or any other mean that would make it working like if he had a public ip), then no configuration is required for the natted party.
I most certainly didnt forget ip translation -- it made no difference. I could still hear him, but he couldnt hear me :( and forward a few ports? -- defserver forwards ALL ports. And I ran the iptables script so unless it forwards the wrong ports I also had all needed ports forwarded.
In the first report you told me "He can hear me, but I can't hear him", now you tell me "I could hear him, but he couldn't hear me". A bit confusing and the problem is different in both cases. Have both of you successfully ran the configuration assistant and heard your own voice with a delay of 4 seconds?
Oh, I have? -- my mistake. I always was able to hear him, he was never able to hear me. So ignore what I said above, thought one thing, wrote another. Happens when doing too many things at once :) Yes, alsa was configured fine, talking to the mic, both of us could hear our voices back, so sound configurations are definitely in perfect working order. And I have made successful connections where both parties could hear eachother. But never got it working with my friend. He can never hear me.
Could you hear yourself with a delay of a few seconds or instantly? the problem seems to be on your friends' side. Perhaps he has not enabled IP translation in the preferences.
About ip translation. No, we tried it with mine or his disabled in turn, and we tried both disabled or enabled -- nothing helped. We spent a few hours trying to get it to work. And there was a few seconds delay, hense it wasnt just the microsphone volume. And I have made successful connections where I could hear and could be heard. I think maybe his Alcatel Speedtouch Pro router cant accept H.323 traffic?
IP translation should be enabled for both of you. Perhaps his Alcatel Speedtouch Pro supports H.323 V1, in that case he should disable ip translation, port forwarding, h245 tunneling and fast start. Something is misconfigured on his side. The mailing list would be much more efficient than this bug report for helping him.
ok, I'll let him know. Well, thanks a bunch for all your help. And keep up the great work on gnomemeeting. I do agree, the standards it uses are definitely more important than writing a hack to allow it to be used in some situations. Unfortunately those "some situations" are quite common for the average user, hope there'll be some new open p2p protocol sometime soon :(
Believe me that all the possible ways that exist to help to go through NAT with H.323 are implemented in GnomeMeeting...
which btw. means that you can either use passive NAT detection or STUN if your NAT does support that. btw. somewhat i'd assume that your friend has a "defserver" meaning all *TCP* traffic is forwarded. If he's still not hearing you ok, then he should check for UDP traffic being lost. That does explain why the connection is up (using TCP), but no audio transmitted (using UDP). You can hear him ok, because his traffic aparently is able to leave his network. But on his side, your traffic is hitting his NAT box and is not being passed on to his workstation. So whatever makes this happen is causing his misconfiguration. And for STUN/passive NAT detection.. We have some server at voxgratia.org which does do the trick like with "proxying through some p2p user" for getting past your NAT. You just can't receive calls with that technique yet. So depending on your NAT (in a general sense) you are able to use GM 1.1 (and 1.2 too) with all sorts of NAT without needing to touch the NAT for being able to call people. Yet for being called you still need some sort of port-forwarding. Please also note the current discussion at IETF is about making SIP-capable NAT widely available. So this current situation of NAT-problems is only of limited scope and will be solved in the near future by NAT-vendors obsoleting all the need to manually tune things.