Re: [GnomeMeeting-list] GM and STUN

[Damien Sandras <dsandras seconix com>]

Le jeudi 28 avril 2005 à 00:18 +0300, Jouni Lohikoski iki fi a écrit :
> On Tue, Apr 26, 2005 at 08:53:22PM +0200, Damien Sandras wrote:
> > Actually, if your type of NAT is symmetric :
> > - you need to forward all ports
> > If your type of NAT is not symmetric :
> > - you only need to forward port 1720 to be reachable
> 
> OK, so STUN is not helping there. (As I said, I should read the STUN
> rfc! I currenlty do not know what STUN actually does and what it doesn't
> and the GM FAQ was not helping there.)
> 

If you are behind NAT, STUN seems the way to go. As a general rule, you
always have to forward 1720. And if your NAT is symmetric, other port
ranges need to be forwarded. If the detected NAT is not symmetric, then
you are ready to make calls.

"Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs) (STUN) is a lightweight protocol that
allows applications to discover the presence and types of NATs and
firewalls between them and the public Internet.  It also provides the
ability for applications to determine the public Internet Protocol
(IP) addresses allocated to them by the NAT.  STUN works with many
existing NATs, and does not require any special behavior from them.
As a result, it allows a wide variety of applications to work through
existing NAT infrastructure."


> Isn't also UDP port 1270 reserved for h323hostcall?

No, only TCP.

> Does it have to be TCP port according to H.323 standard?
> 

I think UDP is allowed, but I know no endpoint supporting it.
That's a bit like SIP, I know very few endpoints able to do SIP
signalling over TCP.

> Forwarding port 1720/tcp is not often possible with normal users behind
> a NAT firewall, which they do not have control of. Nor is able to install
> gatekeeper somewhere with a public address.
> 

I know that. In that case, the only solution is to use SIP or Skype. 

> I am thinking, could this work, (?)
> if the initiation of a h323 call would also work through
> 1270/udp, then some STUN (or similar) server could tie even two
> NAT-firewalled clients together by 
> 1) keeping a book when they want to connect. 
> 2) in the connection time both clients would connect the STUN
> server and get eachothers public IP address and UDP port. 
> 3) Then they both would send a UDP packet to eachothers from the port 
> they are using for listening the h323hostcall, therefore opening the 
> channel through the NAT-firewall. Those UDP packets wouldn't reach their 
> destination normally now, because for a NAT-firewall they are incoming
> UDP packets which are not part of any known UDP-streams. i
> 4) But if the outgoing UDP packet was already sent, or after it has been
> sent, a NAT-firewall has reserved a UDP-channel and it would allow also
> incoming UDP packets which seem to be part of that stream, although they
> really are not in the start.
> 
> I would think this could work for UDP, but not for TCP because TCP needs
> correct sequence numbers in the TCP packets of a TCP-stream.
> 

Indeed, a different scheme is possible with SIP. It is not supported yet
by GnomeMeeting though. (Basically, when registering to the Proxy, the
external port on the gateway is registered, instead of 5060, that can be
done using STUN, or with a special configuration of the SIP proxy).

> The only problem I see, is that NAT-firewall would change the UDP source
> port when the UDP packet goes through the NAT. I wonder if there would
> be some magic how the destination client would know what UDP source port
> it will be, so it could send the h323hostcall-UDP-initiation UDP-packet
> with the same UDP destination port number.
> 
> But I know STUN currently does some magic, so maybe there is a solution
> for this also? There is no explanation in the GM FAQ about what exactly
> is STUN.

Google is your friend. But if you want to contribute to the FAQ, feel
free to send a patch. I'm not able to do everything alone ;)

> 
> It (port pimp = PP) would be kind of a gatekeeper, but after the connection 
> would be made, no data would flow through the gatekeeper but even straight 
> from one NAT-firewalled client to the other NAT-firewalled client (which
> is the most difficult case)
> 
> Message passing would go something like below.
> 
> TIME: anytime before 2005-05-27 21:32 :
> 
> client1 -> PP:some_well_known_TCP_port
> "I want to make a call to client2 at 2005-05-27 21:32, 
> my UDP port would be 1720/udp" 
> 
> client2 -> PP:some_well_known_TCP_port
> "any news?"
> 
> PP -> client2
> "yes, connection to client1:1720/udp at 2005-05-27 21:32" 
> 
> TIME: 2005-05-27 21:31 :
> 
> client1 -> PP:some_well_known_TCP_port
> "Was my connection request succesfull for client2 at 2005-05-27 21:32? 
> My port to be used is 1720/udp"
> 
> PP -> client1
> "Yes. connect to client2:1270/udp at 2005-05-27 21:31"
> 
> TIME: 2005-05-27 21:32 :
> 
> client2:1270/udp -> client1:1720/udp
> "Hello are you there?"
> (client2's NAT opens up UDP-stream ticket/slot between client2 and client1)
> (client1's NAT firewall blocks this packet because it is not known to be
> part of any UDP-stream)
> 
> client1:1270/udp -> client2:1720/udp
> "Hello, are you there?" 
> (client1's NAT opens up UDP-stream ticket/slot between client1 and client2)
> (client2's NAT thinks this packet is part of the UDP-stream it opened
> previously so it passes it cleanly to client2)
> 
> client2:1270/udp -> client1:1720/udp
> "Yes, I got it! Lets rock! Here follows my h323hostcall-handshake: ...."
> 
> // jouni
> 
> 
> _______________________________________________
> GnomeMeeting-list mailing list
> GnomeMeeting-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
-- 
 _      Damien Sandras
(o-     GnomeMeeting: http://www.gnomemeeting.org/
//\     FOSDEM 2005 : http://www.fosdem.org
v_/_    H.323 phone : callto:ils.seconix.com/dsandras seconix com