[cisco-voip] CCM4.1, Gatekeeper and tech prefix routing

[Andre Beck]

Hi Vincent,

On Thu, Sep 22, 2005 at 11:30:16AM +0200, Vincent De Keyzer wrote:
> 
> I can't help you much more than by expressing my sympathy to you. What you
> are trying to do is on my roadmap, and I am happy to see that you will
> probably have fixed the problem by the time I need to address it... :)

For my special situation it seems fixed with the more flexible
reinterpretation of what a tech prefix can be - but that doesn't
necessarily fit and scale to any generic case. My big advantage #1
seems to be that the german dialplan uses the "traffic differentiation
digit" 0 as a prefix for anything to be routed to the PSTN and I can
just convince the GK that this is a tech prefix...
 
> This is a shame the CCM does not register its numbers to the GK. IMO it
> should! Have you spoken to Cisco about this? This sounds like a very common
> requirement.

I think I understand why they don't do it. It's a matter of scalability
and CCM can know about *vast* ranges of numbers. Even more relevant, it
knows about *patterns* that terminate on it - like e.g. a pattern 55XX
for park numbers. What should it do with this pattern? It cannot
register the pattern itself with the GK (AFAIK), it would need to register
all 100 numbers 5500 to 5599 individually. And there are other cases like
this one.
 
> I am trying to do something different although similar:
> * have two (equivalent) gateways to the PSTN
> * have many small gateways (connected to PBXs with BRI ports)
> * want to install 2 GKs

This is on my agenda, too - the customer is going to have a CCM cluster
and as of now, this is not really backed by the GK/gateway infrastructure
which turns out a very hot SPOF. I'd like to split the PSTN GW + GK box
(bearing one GK and two E1 PRI) into two of these boxes, with a GK and
one PRI each. The router is also a central V3PN hub (lots of GRE tunnels
over IPsec end there) and routes the central site's voice VLAN.
It basically *crys* for a friend ;)

> * PSTN GWs would register to both GKs (for redundancy)

Never done that, but I assume it's possible. I seem to remember that the
design guide speaks of such setups in length.

> * small GWs would route outgoing calls to one or the other GW based on what
> the GK says (the small GWs won't need to register to the GK)

RAS routing is independend of GK registration. But then, these small
gateways will probably serve terminals and their numbers should get
registered. So why not register any gateway with the GK? I even think
that you have to, at least for a clean architecture: If there is a GK,
any GW has to use it and register there, there should not be any non-RAS
H.323 links. On the other hand, in my setup direct H.323 dialpeers
between gateways still seem to operate as expected - before discovering
the ability to deal with the 0 prefix in RAS, I used to deploy a dialpeer
for that.
 
> So I am planning to use the GK only to provide control and redundancy on
> outgoing calls from the small GWs. In the light of your recent experience
> with IOS GK, do you think that this is feasible? I might need some advice
> from you on the day I will start on this.

If both gateways register to the GKs with the same tech prefixes, the
GK will choose one of them randomly. This will give you a kind of statistic
load balancing and HA in case of one GW failing. But it has drawbacks:

- It requires the gateways have identical capacity to the PSTN. If they
  differ in that (like one GW with an E1 and another with 4 BRI) you
  will face pinhole congestion of calls
- Distribution will not be ideal, so calls may still cluster on one
  GW and calls that get routed there might fail even when the other GW
  still has free PSTN capacity
 
I'm hopping this back onto the list because I'm interested in comments
about that (including misconceptions I may have built up) myself.

HTH,
Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-