[cisco-voip] E-164-ID causing routing problems in gatekeeper.

[Dustin S. Fowler]

Bob,

I understand what you are asking, although I do not have the answers to the
question you are asking I do have a solution to you problems.

I have in other implementations started with 10 digit DNs. The enables the
ability to have specific DNs for are the DID phones. Then to have the dial
plan you currently desire, you could do some digit manipulation. 

For instance, if 7331 is dialed expand to 6077957331
If 13027331, translate 1302.... to 607795....

This is a cleaner install over all in my experience. You can even only
display the 4 last digits as far as the user is concerned.


Semper Fidelis,

Dustin Fowler
Senior Cisco Consultant

Email: dustin.s.fowler at gmail.com
"KEEPING YOUR BUSINESS HIGHLY AVAILABLE"



-----Original Message-----
From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Bob
Sent: Monday, July 21, 2008 9:14 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] E-164-ID causing routing problems in gatekeeper.

I know about no-reg on a per DN basis as I mentioned in my original post. If
registration of the individual DNs can't be stopped on a system wide basis,
why does the gatekeeper match the 4 digit DN that's registered against a
longer number - example: 17727331 matches 7331 as registered by a CME. This
seems to limit scalability, as the whole idea of having 1 + 3 digit locator
code is to point at a specific system (gateway). 

How do you deal with the issue of having the same 4 digit extension at
multiple sites that might be registered to the same gatekeeper, but have
vastly different publicly dialable numbers, as well as different locator
codes? For example, one site might have a bell number of 6079587331 , and a
private network locator of 13027331, while another site might have
7043577331 with a private network locator of 12997331. If you look at the
gatekeeper, it shows two copies of an E164 id as 7331, of course with
different gateway IPs. Dialing 17727331 from any site registered to the
gatekeeper results in the gatekeeper trying to route the call to either
13027331, or 12997331, rather than sending the call to the gateway
associated with 1772 (Prefix: 1772*). no-reg works, but it seems that's
really just covering up a problem. If someone adds a DN on a CME without
no-reg, that 4 digit number becomes problematic to dial.

My experience with this is primarily with Nortel. They handle things
differently. I'm trying to get past an "allergy to Cisco" that others where
I work seem to have in order to create a seamless network between the two.

-----Original Message-----
From: Jonathan Charles 
Sent: Monday, July 21, 2008 12:51 AM
To: Bob
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] E-164-ID causing routing problems in gatekeeper.

On the ephone-dn, do the following:

ephone-dn 1
 number 1414 secondary 2024561414 no-reg primary




Jonathan

On Sun, Jul 20, 2008 at 11:18 PM, Bob <bobsjunkmail at bellsouth.net> wrote:
> How do I go about preventing CMEs / Gateways that are registering to a 
> an
> H.323 gatekeeper from registering their DNs as E164 addresses? I know 
> about no-reg on a DN basis, but I'm trying to make it foolproof - as 
> in, there's nothing to forget when adding phones. Note that the full 
> blown Call Managers register as VOIP-GW, and don't register their
extensions.
>
> Dial plan is 1xxxxxxx. Tech prefix is whatever the distant site is, as 
> in, the remote site below that registers 1302. All sites register 
> whatever their "locator code - 1xxx - is as their tech prefix.
>
> The problem it's causing is this: when a call comes in from remote 
> site to the gatekeeper, if there's a 4 digit number registered as a 
> E164-ID that matches the last 4 digits of the dialed sting - example 
> 17724357 - the call will attempt to terminate on that gateway, 
> complete with the tech prefix, and being I've got a dial-peer pointing 
> to the gatekeeper as 1......., out it goes back to gatekeeper, which,
starts the loop again.
>
> I'm probably missing something with regard to default tech prefix, or 
> something along those lines, but this arrangement allows me to add 
> sites without messing with the gatekeepers, and it keeps the dial plan
consistent.
>
> BTW: The gateway at 10.47.18.120 where such prefixes as 1772 point to 
> hands off to a Nortel switch. The purpose of this is to allow Nortel / 
> Cisco interoperability. This works as it is programmed, except for the 
> exception listed above. If this is a completely screwed up way to 
> accomplish the desired end result, let me now what the right way is.
>
> I've changed the endpoint names and IP's to prevent the world from 
> figuring what company this is for, so if there's a mismatch between 
> the IP / names, it's after the extraction from the router.
>
>
> Thanks for any help on this.
>
>
>
>
> ********>Remote site - CME with phones
>
> interface GigabitEthernet0/0
>  description VOICE VLAN and CME/CUE
>  ip address 10.46.130.249 255.255.254.0  duplex auto  speed auto  
> media-type rj45  h323-gateway voip interface  h323-gateway voip id 
> bingNY ipaddr 10.47.18.120 1719  h323-gateway voip h323-id 
> DistTELRTR at abcd.com  h323-gateway voip tech-prefix 1302  h323-gateway 
> voip bind srcaddr 10.46.130.249
>
>
>
> dial-peer voice 1200 voip
>  description ***PPD Binghamton, NY***
>  translation-profile incoming EsnInMods  translation-profile outgoing 
> EsnOutMods  destination-pattern 1.......
>  session target ras
>  incoming called-number 1302....
>  dtmf-relay h245-alphanumeric
>  codec g711ulaw
>  fax-relay ecm disable
>  no vad
>
> **********>TDM Gateway / Gatekeeper
>
> interface FastEthernet0/0
>  description bingTELRTR ETHERNET CONNECTION  ip address 10.47.18.120 
> 255.255.255.240  duplex auto  speed auto  h323-gateway voip interface  
> h323-gateway voip id bingNY ipaddr 10.47.18.120 1719  h323-gateway 
> voip h323-id bingTELRTR  h323-gateway voip bind srcaddr 10.47.18.120
>
>
>
> sho gatekeeper endpoints
>                     GATEKEEPER ENDPOINT REGISTRATION
>                     ================================
> CallSignalAddr  Port  RASSignalAddr   Port  Zone Name         Type
Flags
> --------------- ----- --------------- ----- ---------         ----
-----
> 10.46.30.1     49305 10.46.30.1     49304 bingNY            VOIP-GW
>     H323-ID: DaytvilleMD_CM_1
>     Voice Capacity Max.=  Avail.=  Current.= 0
> 10.47.18.120   1720  10.47.18.120   49231 bingNY            H323-GW
>     H323-ID: bingTELRTR
>     Voice Capacity Max.= 46  Avail.= 46 Current.= 0
> 10.47.9.248    1720  10.47.9.248    53187 bingNY            H323-GW
>     E164-ID: 4357
>     H323-ID: bingTestCME at abcd.com
>     Voice Capacity Max.=  Avail.=  Current.= 1
> 10.46.130.249  1720  10.46.130.249  55837 bingNY            H323-GW
>     E164-ID: 6668
>     E164-ID: 6618
>     E164-ID: 6608
>     E164-ID: 6644
>
> **********A bunch more phones*******
>
>     E164-ID: 8009
>     E164-ID: 816600
>     H323-ID: DistTELRTR at abcd.com
>     Voice Capacity Max.=  Avail.=  Current.= 0
> 10.57.213.249  52661 10.57.213.249  62011 bingNY            VOIP-GW
>     H323-ID: Ist_bing_Trunk_1
>     Voice Capacity Max.=  Avail.=  Current.= 0
> 10.57.213.249  50389 10.57.213.249  62011 bingNY            VOIP-GW
>     H323-ID: Bru_bing_GK_1
>     Voice Capacity Max.=  Avail.=  Current.= 0 Total number of active 
> registrations = 6
>
>
>
> gatekeeper gw-type-prefix
> GATEWAY TYPE PREFIX TABLE
> =========================
> Prefix: 1685*
>   Statically-configured gateways (not necessarily currently registered):
>     10.47.18.120:1720
>   Zone bingNY master gateway list:
>     10.47.18.120:1720 bingTELRTR
>
> Prefix: 1768*
>   Statically-configured gateways (not necessarily currently registered):
>     10.47.18.120:1720
>   Zone bingNY master gateway list:
>     10.47.18.120:1720 bingTELRTR
>
> Prefix: 1462*
>   Statically-configured gateways (not necessarily currently registered):
>     10.47.18.120:1720
>   Zone bingNY master gateway list:
>     10.47.18.120:1720 bingTELRTR
>
> Prefix: 1772*
>   Statically-configured gateways (not necessarily currently registered):
>     10.47.18.120:1720
>   Zone bingNY master gateway list:
>     10.47.18.120:1720 bingTELRTR
>
> Prefix: 8*
>   Statically-configured gateways (not necessarily currently registered):
>     10.47.18.120:1720
>   Zone bingNY master gateway list:
>     10.47.18.120:1720 bingTELRTR
>
> Prefix: 1210*
>   Statically-configured gateways (not necessarily currently registered):
>     10.47.18.120:1720
>   Zone bingNY master gateway list:
>     10.47.18.120:1720 bingTELRTR
>
> Prefix: 1302*
>   Zone BingNY master gateway list:
>     10.46.130.249:1720 DistTELRTR
>
> Prefix: 1214*
>   Zone BingNY master gateway list:
>     10.46.30.1:49305 DaytvilleMD_CM_1
>
> Prefix: 1509*
>   Zone BingNY master gateway list:
>     10.57.213.249:52661 Ist_Bing_Trunk_1
>
> Prefix: 1401*
>   Zone BingNY master gateway list:
>     10.57.213.249:50389 Bru_Bing_GK_1
>
> Prefix: 1299*
>   Zone BingNY master gateway list:
>     10.47.9.248:1720 BingTestCME
>
> gatekeeper
>  zone local bingNY abcd.com 10.47.18.120  zone remote ScoUK 
> europe.abcd.local 10.67.2.254 1719  zone prefix ScoUK 14*  zone prefix 
> ScoUK 15*  zone prefix ScoUK 16*  zone prefix ScoUK 17*  zone prefix 
> ScoUK 18*  gw-type-prefix 1685* gw ipaddr 10.47.18.120 1720  
> gw-type-prefix 1768* gw ipaddr 10.47.18.120 1720  gw-type-prefix 1462* 
> gw ipaddr 10.47.18.120 1720  gw-type-prefix 1772* gw ipaddr 
> 10.47.18.120 1720  gw-type-prefix 8* gw ipaddr 10.47.18.120 1720  
> gw-type-prefix 1210* gw ipaddr 10.47.18.120 1720
>   no shutdown
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip