Appliance Based Gatekeeper

[spkv]

Does anyone have any experience with the new Tandberg Gatekeeper?

We are having problems with a server based Gatekeeper and would like to move to an appliance based Gatekeeper. I would think about the ViaIP ECS but we already have MCU's and don't need a Gateway.
Beside's Tandberg and ViaIP, I can not think of another Appliance based Gatekeeper.

I realize the Tandberg GK'er is pretty new, but there Gateway and MCU worked very well when they were new so I have some high expecatations.

[Glen Sykes]

The Via IP ECS is still server based, it's just embedded.

The other appliance based GK that I would highly recommend is the Cisco GK, which in my opinion is the best GK solution available right now.

With the Cisco GK you can (all from one device)

Operate in a Heirachy
Support multiple zones
Simplified NAT traversal
Centralised H.323 stream distribution
Embedded NAT (GK can be deployed on network edge)
AAA via RADIUS
GK redundancy via HSRP / VRRP

With other gatekeepers, a lot of these features are available as a costed upgrade, with the Cisco GK they are part of the package.

The size / power of the GK is determined by the router platform it is hosted on.

[trapehzoid]

The Via IP ECS is still server based, it's just embedded.

The other appliance based GK that I would highly recommend is the Cisco GK, which in my opinion is the best GK solution available right now.

With the Cisco GK you can (all from one device)

Operate in a Heirachy
Support multiple zones
Simplified NAT traversal
Centralised H.323 stream distribution
Embedded NAT (GK can be deployed on network edge)
AAA via RADIUS
GK redundancy via HSRP / VRRP

With other gatekeepers, a lot of these features are available as a costed upgrade, with the Cisco GK they are part of the package.

The size / power of the GK is determined by the router platform it is hosted on.


Well 'costed' given you have the proper SW load. There are at least two different H323 loads for your router.. plus they are not free.

I don't know what you mean by 'Centralised H.323 stream distribution', but if you mean proxy mode.. you can keep it. Too feature limiting.

I like the Cisco GK for its maintainability.. but I like ECS for its functionality.

[spkv]

MCM might work for me. My concern with it is ease of use.

Our administrators have no Cisco experience. With most Gatekeeper's it is neccessary to manually unregister a site and let them re-register. I can't technically give an explanation why we have to do this but I know with Path Navigator, ECS and MXM this must be done.

In your experience, do you ever have to unregister endpoints? If so how difficult is it?

[Glen Sykes]

Well 'costed' given you have the proper SW load. There are at least two different H323 loads for your router.. plus they are not free.

I don't know what you mean by 'Centralised H.323 stream distribution', but if you mean proxy mode.. you can keep it. Too feature limiting.

I like the Cisco GK for its maintainability.. but I like ECS for its functionality.


Proxy mode sucks, true, however IP to IP gateway does not. It is a completely transparent way of centralising H.323 traffic, and is not the same as the proxy, and not to put too fine a point on it.... kicks arse. It 'proxies' streams whether they are outbound to a remote zone, inbound to a neighbour zone on the same GK or even traffic between terminals in the same zone. It also scales far better as multiple IPIPGW's can be used to load balance and increase the number of supported 'proxy' sessions far beyond the current maximum of any server based GK.

Compare ECS100 Pro, with radius support and firewall traversal for 20 users options against the appropriate router with MCM and the license for a new GK (software version 12.3(4) or higher) and you'll be surprised at the difference in cost. When you get into support for 100 concurrent sessions, the difference is huge.

Don't get me wrong, ECS is a fantastic GK, and has its place (it's LDAP integration is excellent), but MCM get's a lot of undue stick due to the badly implemented proxy, which has now been superceded by the far better and much less well known IP to IP gateway.

Spkv, ease of use for setting an MCM up is an issue, as in certain configs it can be quite intimidating. However troubleshooting is fairly straighforward once you know how. It's the lack of GUI that puts most people off. I've never had to unregister an endpoint from MCM unless I've made config changes, in which case it's a 3 step procedure.

Hope this helps,

Glen

[trapehzoid]

My only 'real' beef for a simple GK is how it looses all registrations if it gets cycled. ECS holds registrations over reboots.

Plus.. I've never really gotten a good handle on setting up it's debugging.

[Andrew_B]

We are running an open source gatekeeper under Red Hat. It work ok for what we need it to to (basic e.164 -> IP address translation) but there is a problem. We use Tandberg equipment and it registers just fine initially. But if we turn off the Tandberg unit it doesn't unregister. So if that codec trys to register again with a different IP address the gatekeeper won't allow that because it thinks it's already in use. Please help. Another solution or some sort of fix.


Andrew

[Kevin]

if we turn off the Tandberg unit it doesn't unregister. So if that codec trys to register again with a different IP address the gatekeeper won't allow that because it thinks it's already in use. Please help. Another solution or some sort of fix.

Andrew - Are you using GNU gatekeeper? If so it may help if you set TimeToLive. From the GNU gatekeepers docs:

TimeToLive=300
Default: -1

An endpoint's registration with a gatekeeper may have a limited life span. The gatekeeper specifies the registration duration of an endpoint by including a timeToLive field in the RCF message. After the specified time, the registration has expired. The endpoint shall periodically send an RRQ having the keepAlive bit set prior to the expiration time. Such a message may include a minimum amount of information as described in H.225.0. This is called a lightweight RRQ.

This configuration setting specifies the time-to-live timer in seconds until the registration expires. Note the endpoint may request a shorter timeToLive in the RRQ message to the gatekeeper. To avoid an overload of RRQ messages, the gatekeeper automatically adjusts this timer to 60 seconds if you give a lesser value!

After the expiration time, the gatekeeper will subsequently send two IRQ messages to query if the endpoint is still alive. If the endpoint responds with an IRR, the registration will be extended. Otherwise the gatekeeper will send a URQ with reason ttlExpired to the endpoint. The endpoint must then re-register with the gatekeeper using a full RRQ message.

To disable this feature, set it to -1.