[cisco-voip] CallManager Route Pattern/Filter Problem...

Fri Dec 16 23:48:34 EST 2005

>From my experience and I do believe from a few other places that I read.  If you are going to use Route Filters with a 9.@ or 9 at . then you can drop the pre@, this is a given.  As far as your dial plan you can usually make it CallManager because it knows what it should be from its own tables, like ISDN, National, etc..
If you stick with 9.1XX... then that is when you might have to do the unknown to let your provider determine what plan it is.

Brian

________________________________

From: cisco-voip-bounces at puck.nether.net on behalf of Mark Snow
Sent: Fri 12/16/2005 11:41 PM
To: 'Cisco'; cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...

Lelio is correct, make sure that digit manipulation is not occurring at the Route Pattern, OR within the Route Groups inside the Route Lists.

If those are not stripping anything but PreDot then try this:

Try changing:

*	Called Numbering Plan*: unknown 
*	Calling Numbering Plan*: unknown 

Then test your calls - see if they work - you will have to do a reset on the 6608 gateway first, so make sure that there are no calls going on at the time.

Also, since you are running a 6608 blade on a 6500 Cat, you cannot do the 'debug isdn q931' command I asked about previously.

LMK if that helps ...

And hey, if you do want to become a Voice Expert soon, check out my class sometime:

http://www.ipexpert.com/products_services/product.asp?sku=ip0012

-Mark Snow

CCIE Voice # 14073

________________________________

From: Cisco [mailto:subs-cisco at cbvcollections.com] 
Sent: Friday, December 16, 2005 8:17 PM
To: Mark Snow; cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...

Well I'm far from the telephony expert I want to be (at this point - give me a few months) but it would appear that you may be on to something.  I took a look at the gateway configurations within CallManager.  Each of the gateways within the PSTN group (Product : Cisco Catalyst 6000 T1 VoIP Gateway - Device Protocol: Digital Access PRI) have the same configuration.  The following settings are currently used from the Call Routing Information (Outbound):

*	Calling Line ID Presentation*: Restricted 
*	Calling Party Selection*: Originator 
*	Called party IE number type unknown*: Cisco CallManager 
*	Calling party IE number type unknown*: National 
*	Called Numbering Plan*: Cisco CallManager 
*	Calling Numbering Plan*: ISDN 
*	Number of digits to strip*: 0 
*	Caller ID DN: 
*	SMDI Base Port*: 

Do you think the underlined (above) is causing the issue?  Is this something I can change (to "Cisco CallManager") or do I need to involve our provider?

________________________________

From: Mark Snow [mailto:highspeedsnow at gmail.com] 
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...

Is it a PRI that the call is going out of on an IOS GW?

If so, have you done a 'debug isdn q931' to ensure that in fact the CCM is dropping the 1?

-Mark Snow

CCIE Voice # 14073

________________________________

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] CallManager Route Pattern/Filter Problem...

I'm trying to use route filters (area code == 204 OR etc.) with a "9.@" pattern instead of the more difficult to manage 9.1204XXXXXXX to route long distance calls.  

The pattern/filter work fine, the problem is that when the number is matched using 9.@ pattern (verified with the Cisco the dialled number analyser), by the time it reaches the local provider somehow the "1" is dropped and the caller is presented with a message "you must dial 1 to access a long distance number" from the local provider.  If I change the pattern back to 9.1XXXXXXXXXX then the number is dialled as expected.

I've used the dialled number analyser to ensure that no transformations are taking place at any point along the route to the PEST gateway.  According to the analyser the dialled number that is sent to the PEST gateway in either case is the same.  However, one works and the other does not.

I should also note that the 9.@ pattern with a filter of (local area code == 604 OR etc.) for local 10 digit dialling works just fine as either 9.@ or 9.XXXXXXXXXX.  Both are routed as expected.

Ideas?

________________________________

Frank Wakelin
Senior Network/Security Analyst

100 - 814 Richards St.
Vancouver, BC
V6B 3A7

Telephone: (604) 661-7906
fwakelin at cbvcollections.com

Confidentiality Warning:
This message and any attachments are intended only for the use of the intended recipients (cisco-voip at puck.nether.net), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender (Cisco <mailto:subs-cisco at cbvcollections.com> ) immediately by return e-mail, and delete this message and any attachments from your system. Thank you. 

Information Confidentielle:
Le present message, ainsi que tout fichier qui y est joint, est envoye a l'intention exclusive de son ou de ses destinataires (cisco-voip at puck.nether.net); il est de nature confidentielle et peut constituer une information privilegiee. Nous avertissons toute personne autre que le destinataire prevu que tout examen, reacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'etes pas le destinataire prevu, veuillez en aviser immediatement l'expediteur (Cisco <mailto:subs-cisco at cbvcollections.com> ) par retour de courriel et supprimer ce message et tout document joint de votre systeme. Merci

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20051216/712c6a5b/attachment-0001.html