H.460.18 and NAT

Question

I'm going through the Whitepaper by RADVISION on NAT/Firewall traversal for H.323 endpoints. It is suggested there to use ITU-T H.460.18,17 and 19.

460.17 is very clear way for NAT traversal, but I'm not so clear about the 460.18. Both present a clear solution for Firewall, but how is 460.18 a solution for NAT traversal?

Regards,

Answer 1

The problem with H.460.17 is that virtually no H.323 equipment supports it.

H.460.18 works nicely, even across vendors. It lets the endpoint behind the firewall poke a whole and then uses that whole for both ways of communication. Its rather simple when you read though the standards document. But beware that it is patented by Tandberg, so you have to get a (free) license before you can implement it.

You can look at the GNU Gatekeeper to see the details how H.460.18 gets through the firewall.

Answer 2

H.460.18 works by opening pinholes when moving from one protocol/network connection to the next. H.323 works in the following classic way to connect a call:

• RAS is used over UDP to register to the gatekeeper
• Q.931 is used over TCP (usually) to initiate a call
• H.245 is used to negotiate media capabilities and open media channels
• RTP/RTCP is used to send actual media

Now, to be able to open up Q.931 and H.245, you need the endpoint to be listening on a TCP address for incoming connections. If the endpoint is behind a NAT - that will be impossible to achieve.

So H.460.18 adds special messages to get these TCP connections from the inside out (=reverse).

On RAS, when a new TCP connection needs to be opened for Q.931, a RAS SCI (ServiceControlIndication) message will be sent to the endpoint so that the endpoint will open up the TCP connection for Q.931 instead of just waiting to get an incoming connection.

On Q.931, when a new H.245 connection needs to be opened, it is initiated today already on Q.931; but now it will always be done from the endpoint behind the NAT to a public address.

To sum it up:

• H.460.17 uses a single connection outbound from the endpoint to the gatekeeper and then just tunnels everything on top of it.
• H.460.18 just opens up a new pinhole from one protocol to the next by having the endpoint behind a NAT do the connecting instead of doing the listening.