Tandberg Expressway - Clustering

[Glen Sykes]

It's been a while so a big Hi to anyone that remembers me!

Has anyone here deployed Expressway such that you have a single Border Controller with multiple Gatekeepers registered to it?

What issues did you find if any? How did you deal with the single point of failure? I'm interested to hear anything you have to offer on this subject, as I will be imminently deploying a large scale Expressway solution and it's always nice to know about any 'gotchas' before they 'get me' :D

Thanks in advance,

Glen

[DRI]

Hi Glen,

Having alternate BCs and GKs in a large scale Expressway solution is always good idea...especially with a 'single' BC with multiple GKs traversing to it.

I think a good example of a large scale Expressway solution and one in which you may be familiar with is the Soil Network (Oilcamp) that supports the oil and gas industry. Here's the link to their site:

http://www.oilcamp.com/portal/ProductsServices/SOILMeeting/tabid/68/Default.aspx

[Glen Sykes]

Cheers for the link! Useful to know, but I'm hoping from some technical detail really, such as failover configuration and call handover to alternate border controllers when a BC is busy etc.

Cheers,

Glen

[DRI]

Hi Glen,

Then you may find the Tandberg Infrastructure Deployment Guide helpful.

http://www.tandberg.com/collateral/documentation/White_Papers/TANDBERG%20Infrastructure%20Deployment%20Guide.pdf

Some of the info is dated (i.e. reference N/Q3 SW) but it's still a good reference when it comes to deploying an h.323 network and also discusses security and redundancy.

[Glen Sykes]

Cheers, It's well out of date though. This refers to redundant border controllers determined at a global level within the gatekeeper. In version 5, alternate border controllers may be configured per traversal zone, which is what I'm looking at doing here. It's the behaviour of the gatekeepers and border controllers in determining when the GK should use an alternate BC that I'm interested in.

For example, if I assign a pipe bandwidth limit to the primary border controller, and then a call is placed that would break that threshold, will the GK then look to an alternate BC to handle this call? There's no mention in the documentation specifically about the triggers on which the Gatekeeper will send an LRQ to its alternate BC's.

Cheers,

Glen

[DRI]

Cheers, It's well out of date though. This refers to redundant border controllers determined at a global level within the gatekeeper. In version 5, alternate border controllers may be configured per traversal zone, which is what I'm looking at doing here. It's the behaviour of the gatekeepers and border controllers in determining when the GK should use an alternate BC that I'm interested in.

For example, if I assign a pipe bandwidth limit to the primary border controller, and then a call is placed that would break that threshold, will the GK then look to an alternate BC to handle this call? There's no mention in the documentation specifically about the triggers on which the Gatekeeper will send an LRQ to its alternate BC's.

Cheers,

Glen

Hi,

With regards to the first paragraph above, I said it was dated :)

As far as the second paragraph, and to answer your question, I don't think so. But let's make sure we're on the same page so that I understand you correctly. Your talking about when you build a traversal on the GK to a BC and where you can enter 6 x BCs...correct? If so, then this works just like the GK's alternate GKs...meaning, if the GK loses connection with the primary, then the first alternate kicks in. So in the case of the traversal setup on the GK where you can enter 6 x BCs, the first entry is the primary BC and the others are alternates. Therefore, if the GK loses connection with the primary, then the first alternate will kick in and if it can't reach that alternate, it will go onto the next and so on and so on. This is why I also believe that all your alternates need to be configured the same as your primary with regards to bw controls, etc.

Are we on the same page?

[Glen Sykes]

We are indeed on the same page. The real question is, what are the criteria that triggers a Gatekeeper to use its secondary / tertiary gatekeepers?

If the only criteria it uses are that the 1st BC doesn't respond, then this idea won't work. If however, the Gatekeeper will go to its secondary / tertiary based on an LRJ from the primary BC, then this should work. It's just that I don't know what the behaviour of the gatekeeper is in this scenario.