The problem is the the visited GK might (and probably) control firewalls and other QoS and security devices. Therefore it needs to know what my terminal is doing, and may disagree with the replies of my home GK.
If the visited network is behind a firewall then the register-directly-with-home-gatekeeper model can be made to work without protocol changes. There are two cases to consider:
If the policy of the visited networks is to not allow roaming endpoints to connect to their home system then it doesn't matter whether this policy is enforced by the gatekeeper or firewall. Thus the register-directly- model is valid.
If the visited network would like to allow roaming endpoints to connect to their home gatekeeper in order to make calls then this can be handled by using IP masquerading techniques on the firewall. This doesn't require any changes to the protocol.
IP masquerading is implemented by application proxy or stateful inspection type firewalls and is a means of passing a complex protocol containing embedded addresses between two disconnected IP networks. NAT (network address translation) uses a similar technique. The basic mechanism is that since all traffic between an organisation and the internet passes through their firewall the firewall can intercept any packets it wants to and modify them as necessary (most firewalls are configured to block any packets which have not been intercepted and inspected).
A masquerading H.323 proxy (running on the firewall) contains gatekeeper like functionality which intercepts, decodes and validates H.323 packets passing through it. This proxy needs to keep a list of which roaming endpoints are within the network it is protecting so that it can pass call setups on to them from their home gatekeepers. The proxy is invisible to roaming endpoints within the firewall because it pretends to be the home agent they are communicating with.
Since the masquerading H.323 proxy has intercepted all traffic going out of the network it can impose QoS requirements on calls by roaming endpoints as easily as the administrative domain's gatekeeper can for local endpoints. Alternatively the lower layer QoS management could be used to do it.
I suppose you could claim that a masquerading H.323 proxy is the same as registering with the visited gatekeeper in terms of which messages flow where. It differs in two important ways: 1) it requires no changes to the format of messages and 2) the roaming user does not need to configure or discover the visited gatekeeper (particularly important if the visited network doesn't support multicast).
Also for security reasons my home GK may be restricted to receiving xRQs from the local zone and from specific GKs, and may reject xRQs sent from the open internet.
If my home gatekeeper is restricted to receiving xRQs from the local zone then why will it respond to those messages when they come from a foreign gatekeeper?
Surely a reasonable gatekeeper will only accept RAS messages from endpoints/gatekeepers which are either on a physical network which it trusts or which have provided some sort of strong authentication.
Regards,
Andy.
-- Andrew Draper - Principal Development Engineer - WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks. mailto:adraper@dev.madge.com phone:+44 1753 661329 pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F