Re: [GnomeMeeting-list] GM and STUN

["Jouni Lohikoski iki fi" <jlohikos cc hut fi>]

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.)

Isn't also UDP port 1270 reserved for h323hostcall?
Does it have to be TCP port according to H.323 standard?

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 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.

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.

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