Hi,

I've got a network of several H.323 gateways (IOS, currently running
CCME) and a central gatekeeper to which they all nicely register their
phone numbers, allowing me to do dynamic call routing even with a random
(non-hierarchical) dial plan the organization uses and needs to stay
with. The gatekeeper is also a gateway (registering to itself) and besides
running CCME it has the E1 egress point to the PSTN as a dialpeer.

Now this architecture is beeing merged to a central CCM 4.1 cluster
with all the former CCME gateways beeing turned into SRST gateways.
I plan to stay with the gatekeeper so if CCM fails altogether, the
phones will register to their respective SRST gateways, the gateways
will register the phone numbers to the gatekeeper and given that they
are still reachable, call routing will continue to work.

Sadly enough, CCM has a major flaw IMO: It doesn't register the numbers
it knows about to the gatekeeper. I've got the gatekeeper and trunk set
up perfectly, the CCM registers, but the GK doesn't know what numbers
are there. I've read docs up and down and assume that is the way it is -
no option to activate number registration anywhere (probably a scalability
issue).

Now the basic question is: How does the gatekeeper decide which unknown
(not registered) number is routed to which gateway? The tech support
proposes to use tech prefixes and the IOS GK feature "default-technology"
which essentially defines a default route for all unknown numbers towards
the gateway with a certain tech prefix. In the trivial setups shown in
these tech papers, this is sufficient.

My problem: It is not sufficient here, as I have *two* kinds of unknown
numbers, and they have to be routed to *different* gateways: The numbers
that should be routed to the PSTN (must be routed to the gateway that
also happens to be the gatekeeper) and the remaining numbers (must be
routed to the CCM). They are easy to differentiate from each other, the
PSTN directed ones all start with 0 (this is not the NANP), but I don't
find a way to tell this to the gatekeeper. I could direct them to another
zone easily, but they are not going to another GK, they are simply to
leave the IP world alltogether.

Now what I did for a partial solution:

1) The gateway with the PSTN dialpeer registers with another tech
prefix than the CCM. Say CCM registers with 1#* while the gateway
registers with 2#*
2) In every route pattern on the CCM that routes 0-starting numbers
towards the gatekeeper trunk, I prefix the called party number
with 2#
3) On the gateway, the dialpeer destination is changed from 0T to 2#0T

The good thing: This works. It routes exactly as intented.

The bad thing: The phones change the display of the called party number
from 0xxxxx to 2#0xxxxx which looks weird and disturbing. It is correct
and more of a cosmetic issue, but I can't deploy it this way. So is there
a way to do this without having the display change? Ideally there would
be a special tech-prefix option in the route pattern as is in the voip
dialpeer on IOS, but I only found the explicit prefix.

Long question, but I spent hours on it, either. Any comments are
welcome. This includes comments on whether a setup as described
(GK for dynamic routing to SRST gateways) is feasible or going
to work at all...

TIA,
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 <-

[ Post a follow-up to this message ]

To route certain prefixes to unregistered gateways, you need to use the
alias static command.  For example, if you would like to route 0* numbers
to one gateway, and 1* numbers to another your config would look like this
on the gatekeeper:

Alias static <gw ip> 1720 gkid HQGK gateway voip ras <gw ip> 1719
Alias static <gw ip> 1720 gkid HQGK gateway voip ras <gw ip> 1719
Gw-type-prefix 0* gw ipaddr <gw ip> 1720
Gw-type-prefix 1* gw ipaddr <gw ip> 1720


> Hi,
>
> I've got a network of several H.323 gateways (IOS, currently running
> CCME) and a central gatekeeper to which they all nicely register their
> phone numbers, allowing me to do dynamic call routing even with a random
> (non-hierarchical) dial plan the organization uses and needs to stay
> with. The gatekeeper is also a gateway (registering to itself) and besides
> running CCME it has the E1 egress point to the PSTN as a dialpeer.
>
> Now this architecture is beeing merged to a central CCM 4.1 cluster
> with all the former CCME gateways beeing turned into SRST gateways.
> I plan to stay with the gatekeeper so if CCM fails altogether, the
> phones will register to their respective SRST gateways, the gateways
> will register the phone numbers to the gatekeeper and given that they
> are still reachable, call routing will continue to work.
>
> Sadly enough, CCM has a major flaw IMO: It doesn't register the numbers
> it knows about to the gatekeeper. I've got the gatekeeper and trunk set
> up perfectly, the CCM registers, but the GK doesn't know what numbers
> are there. I've read docs up and down and assume that is the way it is -
> no option to activate number registration anywhere (probably a scalability
> issue).
>
> Now the basic question is: How does the gatekeeper decide which unknown
> (not registered) number is routed to which gateway? The tech support
> proposes to use tech prefixes and the IOS GK feature "default-technology"
> which essentially defines a default route for all unknown numbers towards
> the gateway with a certain tech prefix. In the trivial setups shown in
> these tech papers, this is sufficient.
>
> My problem: It is not sufficient here, as I have *two* kinds of unknown
> numbers, and they have to be routed to *different* gateways: The numbers
> that should be routed to the PSTN (must be routed to the gateway that
> also happens to be the gatekeeper) and the remaining numbers (must be
> routed to the CCM). They are easy to differentiate from each other, the
> PSTN directed ones all start with 0 (this is not the NANP), but I don't
> find a way to tell this to the gatekeeper. I could direct them to another
> zone easily, but they are not going to another GK, they are simply to
> leave the IP world alltogether.
>
> Now what I did for a partial solution:
>
> 1) The gateway with the PSTN dialpeer registers with another tech
>    prefix than the CCM. Say CCM registers with 1#* while the gateway
>    registers with 2#*
> 2) In every route pattern on the CCM that routes 0-starting numbers
>    towards the gatekeeper trunk, I prefix the called party number
>    with 2#
> 3) On the gateway, the dialpeer destination is changed from 0T to 2#0T
>
> The good thing: This works. It routes exactly as intented.
>
> The bad thing: The phones change the display of the called party number
> from 0xxxxx to 2#0xxxxx which looks weird and disturbing. It is correct
> and more of a cosmetic issue, but I can't deploy it this way. So is there
> a way to do this without having the display change? Ideally there would
> be a special tech-prefix option in the route pattern as is in the voip
> dialpeer on IOS, but I only found the explicit prefix.
>
> Long question, but I spent hours on it, either. Any comments are
> welcome. This includes comments on whether a setup as described
> (GK for dynamic routing to SRST gateways) is feasible or going
> to work at all...
>
> TIA,
> 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 <-
>  ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

[ Post a follow-up to this message ]

possibly gktmp?

Andre Beck wrote:

>Hi,
>
>I've got a network of several H.323 gateways (IOS, currently running
>CCME) and a central gatekeeper to which they all nicely register their
>phone numbers, allowing me to do dynamic call routing even with a random
>(non-hierarchical) dial plan the organization uses and needs to stay
>with. The gatekeeper is also a gateway (registering to itself) and besides
>running CCME it has the E1 egress point to the PSTN as a dialpeer.
>
>Now this architecture is beeing merged to a central CCM 4.1 cluster
>with all the former CCME gateways beeing turned into SRST gateways.
>I plan to stay with the gatekeeper so if CCM fails altogether, the
>phones will register to their respective SRST gateways, the gateways
>will register the phone numbers to the gatekeeper and given that they
>are still reachable, call routing will continue to work.
>
>Sadly enough, CCM has a major flaw IMO: It doesn't register the numbers
>it knows about to the gatekeeper. I've got the gatekeeper and trunk set
>up perfectly, the CCM registers, but the GK doesn't know what numbers
>are there. I've read docs up and down and assume that is the way it is -
>no option to activate number registration anywhere (probably a scalability
>issue).
>
>Now the basic question is: How does the gatekeeper decide which unknown
>(not registered) number is routed to which gateway? The tech support
>proposes to use tech prefixes and the IOS GK feature "default-technology"
>which essentially defines a default route for all unknown numbers towards
>the gateway with a certain tech prefix. In the trivial setups shown in
>these tech papers, this is sufficient.
>
>My problem: It is not sufficient here, as I have *two* kinds of unknown
>numbers, and they have to be routed to *different* gateways: The numbers
>that should be routed to the PSTN (must be routed to the gateway that
>also happens to be the gatekeeper) and the remaining numbers (must be
>routed to the CCM). They are easy to differentiate from each other, the
>PSTN directed ones all start with 0 (this is not the NANP), but I don't
>find a way to tell this to the gatekeeper. I could direct them to another
>zone easily, but they are not going to another GK, they are simply to
>leave the IP world alltogether.
>
>Now what I did for a partial solution:
>
>1) The gateway with the PSTN dialpeer registers with another tech
>   prefix than the CCM. Say CCM registers with 1#* while the gateway
>   registers with 2#*
>2) In every route pattern on the CCM that routes 0-starting numbers
>   towards the gatekeeper trunk, I prefix the called party number
>   with 2#
>3) On the gateway, the dialpeer destination is changed from 0T to 2#0T
>
>The good thing: This works. It routes exactly as intented.
>
>The bad thing: The phones change the display of the called party number
>from 0xxxxx to 2#0xxxxx which looks weird and disturbing. It is correct
>and more of a cosmetic issue, but I can't deploy it this way. So is there
>a way to do this without having the display change? Ideally there would
>be a special tech-prefix option in the route pattern as is in the voip
>dialpeer on IOS, but I only found the explicit prefix.
>
>Long question, but I spent hours on it, either. Any comments are
>welcome. This includes comments on whether a setup as described
>(GK for dynamic routing to SRST gateways) is feasible or going
>to work at all...
>
>TIA,
>Andre.
>
>

[ Post a follow-up to this message ]

Hi Andrew,

On Thu, Sep 22, 2005 at 07:29:08AM -0500, Andrew Dignan wrote:
> To route certain prefixes to unregistered gateways, you need to use the
> alias static command.  For example, if you would like to route 0* numbers
> to one gateway, and 1* numbers to another your config would look like this
> on the gatekeeper:
>
> Alias static <gw ip> 1720 gkid HQGK gateway voip ras <gw ip> 1719
> Alias static <gw ip> 1720 gkid HQGK gateway voip ras <gw ip> 1719
> Gw-type-prefix 0* gw ipaddr <gw ip> 1720
> Gw-type-prefix 1* gw ipaddr <gw ip> 1720

STRIKE.

Thanks a lot. It even is simpler than your case above, as my gateway
is registered. The central point of your statement is that a tech
prefix can be *anything*, it doesn't need to be separated by a # sign
to work. This is just used so the GK will not mix up tech prefixes
with zone prefixes. But the basic idea is that 0 *is* a valid tech
prefix and every number starting with 0 will be routed to the gateway
that has this tech prefix. In my case, I simply let the gateway register
with prefix 0 and I'm done. Beautiful.

Thanks a lot,
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 <-

[ Post a follow-up to this message ]

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 commo
n
> 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 wha
t
> 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 <-

[ Post a follow-up to this message ]