Gatekeeper unknown destination routing through CUBE

Question

Hello,
I'm trying to join two H.323 networks together and I am after some help / advice.
One of the networks is managed and the other not and therefore external.
Both networks have an IP-IP Gateway running Gatekeeper and CUBE. The Video devices in each network are registered with the Gatekeeper running the Gatekeeper configuration in their respective networks.
The problem area is that the two Gatekeepers aren't and can't be peered with each other.
So for all intents and purposes have two identical video networks that need to talk to each other.
I have configured the CUBE on both routers.
So right now if I de-register video device A in Network A from Gatekeeper A. I can then dial the IP address of the CUBE B in Network B followed by the E.164 of video device B using IP+extension dialling and it works.
Its the same the other way around.
However what I want to achieve is the same thing but without de-registering video device A.
What I am trying to achieve is to have Video Device A dial <CUBE-B-IP-Address>##<Device-B-E.164>.
The signalling goes to Gatekeeper A which doesn't have an entry for it so chooses to send it out to the CUBE gateway. I don't mind if it does this as a video type forward or if it just says I don't know about it so fall back to your routing table so signalling goes point to point.
I have used the Polycom SE200 before and on them they have a feature whereby if it nor its peers knows about an E.164 it will revert to the routing table. Its basically a way to be able to route the calls to the Internet. I'm after similiar functionality on the IOS Gatekeeper.
Am I explaining the situation well enough? If anyone can help it would be appreciated!
Thanks and regards

Answer 1

RE: the original question, you should be able to dial (from Terminal A) the standard format of [extensionof Terminal B]@[IP of remote CUBE-B] to connect the call.  So long as your firewall is configured for h.323 inspection and re-writing, you should be able to connect and pin up the call.  Note that the call will not egress through CUBE-A -- it will go directly to the firewall and presumably NAT must be setup.  The call also won't resolve using the GK according to my knowledge.  This config will definitely work.
I believe that ## dialing is a Polycom proprietary method that Tandberg has also implemented in some products for compatability, but Polycom has also backed off from (they now support @ dialing).  You may need to re-educate your users.
If you want to use the GK and the CUBE, I believe you can setup a service prefix on the CUBE-A registered to the GK-A.  Calls using the prefix will be routed to the CUBE-A, and the CUBE-A can strip the prefix on egress dial-peer, and perform RAS with the CUBE-B to route the call.  This is more a "I think this will work" than a known config.  Your users would need to know the extension of the remote terminal, and you'd need some a priori setup on your CUBE/GK.  I'd be interested in your results if you have the capacity to test.
RE: joshuamarsh, you can configure the CUBE with a default address if the call arrives with the format [IP address of CUBE external interface].  See this article:
http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080b091e2.shtml
In the article I believe they suggest forwarding to an IVR, and I would second that recommendation.
However, users can also dial with the format [endpoint extension]@[external IP of CUBE] like above and make their way directly to an endpoint.  This can be made even easier with ENUM/e.164 detailed here:
http://www.ciscosystems.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080ad7b94.shtml