|
Home > Archive > Voice over IP Cisco > December 2005 > CallManager Route Pattern/Filter Problem...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
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?
________________________________
<http://www.cbvcollections.com/cbvImages/ecardlogo.jpg>
Frank Wakelin
Senior Network/Security Analyst
100 - 814 Richards St.
Vancouver, BC
V6B 3A7
Telephone: (604) 661-7906
fwakelin@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use of the intended recipients (cisco-voip@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 (mailto:subs-cisco@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@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 (mailto:subs-cisco@cbvcollections.com) par retour de courriel et supprimer ce message et tout document joint de votre systeme. Merci
| |
| Mark Snow 2005-12-16, 8:45 pm |
| 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@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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?
_____
<http://www.cbvcollections.com/cbvImages/ecardlogo.jpg>
Frank Wakelin
Senior Network/Security Analyst
100 - 814 Richards St.
Vancouver, BC
V6B 3A7
Telephone: (604) 661-7906
fwakelin@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use of the
intended recipients (cisco-voip@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@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@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@cbvcollections.com> ) par retour de courriel et supprimer
ce message et tout document joint de votre systeme. Merci
| |
|
| 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@gmail.com]
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip@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@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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?
________________________________
<http://www.cbvcollections.com/cbvImages/ecardlogo.jpg>
Frank Wakelin
Senior Network/Security Analyst
100 - 814 Richards St.
Vancouver, BC
V6B 3A7
Telephone: (604) 661-7906
fwakelin@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use of the
intended recipients (cisco-voip@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@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@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@cbvcollections.com> ) par retour de courriel
et supprimer ce message et tout document joint de votre systeme. Merci
| |
| Lelio Fulgenzi 2005-12-16, 8:45 pm |
| There are a few spots that digit manipulation occurs that you should look at. The first, is the route pattern. Near the bottom you have the called party transformations. Here you can drop pre-At for example so you don't send the 9 to the PSTN. The second is the route list and the configuration of each route group within the route list. Again, take a look at the called party transformations. If you don't have route groups in the route list, I think you can have the trunks listed, but I'm not 100% sure.
That's the first two places I would look. If the two route patterns are using the same gateways, I don't think it would be your gateway configuration.
----- Original Message -----
From: cisco
To: cisco-voip@puck.nether.net
Sent: Friday, December 16, 2005 7:24 PM
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@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use of the intended recipients (cisco-voip@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) 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@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) par retour de courriel et supprimer ce message et tout document joint de votre systeme. Merci
------------------------------------------------------------------------------
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
| |
| Mark Snow 2005-12-17, 2:45 am |
| 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_se....asp?sku=ip0012
-Mark Snow
CCIE Voice # 14073
_____
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Friday, December 16, 2005 8:17 PM
To: Mark Snow; cisco-voip@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@gmail.com]
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip@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@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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?
_____
<http://www.cbvcollections.com/cbvImages/ecardlogo.jpg>
Frank Wakelin
Senior Network/Security Analyst
100 - 814 Richards St.
Vancouver, BC
V6B 3A7
Telephone: (604) 661-7906
fwakelin@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use of the
intended recipients (cisco-voip@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@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@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@cbvcollections.com> ) par retour de courriel et supprimer
ce message et tout document joint de votre systeme. Merci
| |
| Brian Henry 2005-12-17, 2:45 am |
| >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@. 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@puck.nether.net on behalf of Mark Snow
Sent: Fri 12/16/2005 11:41 PM
To: 'Cisco'; cisco-voip@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_se....asp?sku=ip0012
-Mark Snow
CCIE Voice # 14073
________________________________
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Friday, December 16, 2005 8:17 PM
To: Mark Snow; cisco-voip@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@gmail.com]
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip@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@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use of the intended recipients (cisco-voip@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@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@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@cbvcollections.com> ) par retour de courriel et supprimer ce message et tout document joint de votre systeme. Merci
| |
| Lelio Fulgenzi 2005-12-17, 2:45 am |
| You cannot do a debug isdn, but you can import the CCM trace files into the q931 debug tool and read the output that way. It's a pretty good tool and I've used it a few times. That's the standalone tool, not the one that is built into CallManager.
And our numbering plans are set to CallManager.
Frank - are you in Canada? What is your provider? Bell? I can provide with all of our 6608 parameters if that would help.
----- Original Message -----
From: Mark Snow
To: 'Cisco' ; cisco-voip@puck.nether.net
Sent: Friday, December 16, 2005 11:41 PM
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:
a.. Called Numbering Plan*: unknown
b.. 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_se....asp?sku=ip0012
-Mark Snow
CCIE Voice # 14073
------------------------------------------------------------------------------
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Friday, December 16, 2005 8:17 PM
To: Mark Snow; cisco-voip@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):
a.. Calling Line ID Presentation*: Restricted
b.. Calling Party Selection*: Originator
c.. Called party IE number type unknown*: cisco CallManager
d.. Calling party IE number type unknown*: National
e.. Called Numbering Plan*: cisco CallManager
f.. Calling Numbering Plan*: ISDN
g.. Number of digits to strip*: 0
h.. Caller ID DN:
i.. 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@gmail.com]
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip@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@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use of the intended recipients (cisco-voip@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) 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@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) par retour de courriel et supprimer ce message et tout document joint de votre systeme. Merci
------------------------------------------------------------------------------
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
| |
|
| Yes, I'm with Bell (West) in Vancouver. We have another CM cluster in
the east (Toronto) who is also with Bell. The cluster in Toronto is
using a different PRI protocol (DMS-100) then the Vancouver is using
(NI2).
Well it is late at night so I've been playing with the gateway configs
and trying your suggestion. After changing them to unknown - it worked!
Can you tell me why? Also what should the setting for "Called party IE
number type unknown*" be?
P.S. I will definitely look into your site/course offering!
________________________________
From: Lelio Fulgenzi [mailto:lelio@uoguelph.ca]
Sent: Friday, December 16, 2005 9:35 PM
To: Mark Snow; Cisco; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CallManager Route Pattern/Filter Problem...
You cannot do a debug isdn, but you can import the CCM trace files into
the q931 debug tool and read the output that way. It's a pretty good
tool and I've used it a few times. That's the standalone tool, not the
one that is built into CallManager.
And our numbering plans are set to CallManager.
Frank - are you in Canada? What is your provider? Bell? I can provide
with all of our 6608 parameters if that would help.
----- Original Message -----
From: Mark Snow <mailto:highspeedsnow@gmail.com>
To: 'Cisco' <mailto:subs-cisco@cbvcollections.com> ;
cisco-voip@puck.nether.net
Sent: Friday, December 16, 2005 11:41 PM
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_se....asp?sku=ip0012
-Mark Snow
CCIE Voice # 14073
________________________________
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Friday, December 16, 2005 8:17 PM
To: Mark Snow; cisco-voip@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@gmail.com]
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip@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@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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?
________________________________
<http://www.cbvcollections.com/cbvImages/ecardlogo.jpg>
Frank Wakelin
Senior Network/Security Analyst
100 - 814 Richards St.
Vancouver, BC
V6B 3A7
Telephone: (604) 661-7906
fwakelin@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use
of the intended recipients (cisco-voip@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@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@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@cbvcollections.com> ) par retour de courriel
et supprimer ce message et tout document joint de votre systeme. Merci
________________________________
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
| |
|
| Argh - one more thing. We have a satellite office that uses the same CM
cluster which experienced the same problem - with called numbering plan
on CallManager all calls matching route pattern 9.@ that included 1
played the carrier message (you must dial 1 first...).
I tried adjusting the called/calling party numbering plans to unknown as
I did the local 6608 gateways. Once the gateway was adjusted all
dialled numbers called that are matched 9.@ that include the "1" were
routed to the gateway, but then dropped. The main different there is
that the gateway is a 2691.
Thoughts - ideas?
________________________________
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 10:58 PM
To: Lelio Fulgenzi; Mark Snow; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...
Yes, I'm with Bell (West) in Vancouver. We have another CM cluster in
the east (Toronto) who is also with Bell. The cluster in Toronto is
using a different PRI protocol (DMS-100) then the Vancouver is using
(NI2).
Well it is late at night so I've been playing with the gateway configs
and trying your suggestion. After changing them to unknown - it worked!
Can you tell me why? Also what should the setting for "Called party IE
number type unknown*" be?
P.S. I will definitely look into your site/course offering!
________________________________
From: Lelio Fulgenzi [mailto:lelio@uoguelph.ca]
Sent: Friday, December 16, 2005 9:35 PM
To: Mark Snow; Cisco; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CallManager Route Pattern/Filter Problem...
You cannot do a debug isdn, but you can import the CCM trace files into
the q931 debug tool and read the output that way. It's a pretty good
tool and I've used it a few times. That's the standalone tool, not the
one that is built into CallManager.
And our numbering plans are set to CallManager.
Frank - are you in Canada? What is your provider? Bell? I can provide
with all of our 6608 parameters if that would help.
----- Original Message -----
From: Mark Snow <mailto:highspeedsnow@gmail.com>
To: 'Cisco' <mailto:subs-cisco@cbvcollections.com> ;
cisco-voip@puck.nether.net
Sent: Friday, December 16, 2005 11:41 PM
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_se....asp?sku=ip0012
-Mark Snow
CCIE Voice # 14073
________________________________
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Friday, December 16, 2005 8:17 PM
To: Mark Snow; cisco-voip@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@gmail.com]
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip@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@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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?
________________________________
<http://www.cbvcollections.com/cbvImages/ecardlogo.jpg>
Frank Wakelin
Senior Network/Security Analyst
100 - 814 Richards St.
Vancouver, BC
V6B 3A7
Telephone: (604) 661-7906
fwakelin@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use
of the intended recipients (cisco-voip@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@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@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@cbvcollections.com> ) par retour de courriel
et supprimer ce message et tout document joint de votre systeme. Merci
________________________________
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
| |
| Mark Snow 2005-12-17, 5:45 pm |
| The problem lies with the fact that some carriers do not want to see a 1 and
the Number Plan/Type ISDN/National - same goes with International calls -
some switches just puke if you send them both, however send them one or the
other and they are just fine.
Basically it is a programming problem in your local 5ESS - But the carrier
would never admit that ;)
_____
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Saturday, December 17, 2005 1:58 AM
To: Lelio Fulgenzi; Mark Snow; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...
Yes, I'm with Bell (West) in Vancouver. We have another CM cluster in the
east (Toronto) who is also with Bell. The cluster in Toronto is using a
different PRI protocol (DMS-100) then the Vancouver is using (NI2).
Well it is late at night so I've been playing with the gateway configs and
trying your suggestion. After changing them to unknown - it worked! Can
you tell me why? Also what should the setting for "Called party IE number
type unknown*" be?
P.S. I will definitely look into your site/course offering!
_____
From: Lelio Fulgenzi [mailto:lelio@uoguelph.ca]
Sent: Friday, December 16, 2005 9:35 PM
To: Mark Snow; Cisco; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CallManager Route Pattern/Filter Problem...
You cannot do a debug isdn, but you can import the CCM trace files into the
q931 debug tool and read the output that way. It's a pretty good tool and
I've used it a few times. That's the standalone tool, not the one that is
built into CallManager.
And our numbering plans are set to CallManager.
Frank - are you in Canada? What is your provider? Bell? I can provide with
all of our 6608 parameters if that would help.
----- Original Message -----
From: Mark Snow <mailto:highspeedsnow@gmail.com>
To: 'Cisco' <mailto:subs-cisco@cbvcollections.com> ;
cisco-voip@puck.nether.net
Sent: Friday, December 16, 2005 11:41 PM
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_se....asp?sku=ip0012
-Mark Snow
CCIE Voice # 14073
_____
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Friday, December 16, 2005 8:17 PM
To: Mark Snow; cisco-voip@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@gmail.com]
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip@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@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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?
_____
<http://www.cbvcollections.com/cbvImages/ecardlogo.jpg>
Frank Wakelin
Senior Network/Security Analyst
100 - 814 Richards St.
Vancouver, BC
V6B 3A7
Telephone: (604) 661-7906
fwakelin@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use of the
intended recipients (cisco-voip@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@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@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@cbvcollections.com> ) par retour de courriel et supprimer
ce message et tout document joint de votre systeme. Merci
_____
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
| |
| Mark Snow 2005-12-17, 5:45 pm |
| That sattelilte most likely uses a different telco POP and the telly's
switch wants to see both - switch the Plan/Type back to ISDN/National or
CallManager/CallManager but for that GW only and you should be fine.
HTH
-Mark Snow
_____
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Saturday, December 17, 2005 3:23 AM
To: Lelio Fulgenzi; Mark Snow; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...
Argh - one more thing. We have a satellite office that uses the same CM
cluster which experienced the same problem - with called numbering plan on
CallManager all calls matching route pattern 9.@ that included 1 played the
carrier message (you must dial 1 first...).
I tried adjusting the called/calling party numbering plans to unknown as I
did the local 6608 gateways. Once the gateway was adjusted all dialled
numbers called that are matched 9.@ that include the "1" were routed to the
gateway, but then dropped. The main different there is that the gateway is
a 2691.
Thoughts - ideas?
_____
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 10:58 PM
To: Lelio Fulgenzi; Mark Snow; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...
Yes, I'm with Bell (West) in Vancouver. We have another CM cluster in the
east (Toronto) who is also with Bell. The cluster in Toronto is using a
different PRI protocol (DMS-100) then the Vancouver is using (NI2).
Well it is late at night so I've been playing with the gateway configs and
trying your suggestion. After changing them to unknown - it worked! Can
you tell me why? Also what should the setting for "Called party IE number
type unknown*" be?
P.S. I will definitely look into your site/course offering!
_____
From: Lelio Fulgenzi [mailto:lelio@uoguelph.ca]
Sent: Friday, December 16, 2005 9:35 PM
To: Mark Snow; Cisco; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CallManager Route Pattern/Filter Problem...
You cannot do a debug isdn, but you can import the CCM trace files into the
q931 debug tool and read the output that way. It's a pretty good tool and
I've used it a few times. That's the standalone tool, not the one that is
built into CallManager.
And our numbering plans are set to CallManager.
Frank - are you in Canada? What is your provider? Bell? I can provide with
all of our 6608 parameters if that would help.
----- Original Message -----
From: Mark Snow <mailto:highspeedsnow@gmail.com>
To: 'Cisco' <mailto:subs-cisco@cbvcollections.com> ;
cisco-voip@puck.nether.net
Sent: Friday, December 16, 2005 11:41 PM
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_se....asp?sku=ip0012
-Mark Snow
CCIE Voice # 14073
_____
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Friday, December 16, 2005 8:17 PM
To: Mark Snow; cisco-voip@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@gmail.com]
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip@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@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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?
_____
<http://www.cbvcollections.com/cbvImages/ecardlogo.jpg>
Frank Wakelin
Senior Network/Security Analyst
100 - 814 Richards St.
Vancouver, BC
V6B 3A7
Telephone: (604) 661-7906
fwakelin@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use of the
intended recipients (cisco-voip@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@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@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@cbvcollections.com> ) par retour de courriel et supprimer
ce message et tout document joint de votre systeme. Merci
_____
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
| |
|
| I forgot to write and thank the two of you (and the list) for your help.
All gateways in each site are now routing calls using the 9.@ route
patterns/filters. The satellite problem was due to a lack of calling
party ID, not called. Setting plan types to unknown for all gateways
worked just fine.
P.S. Mark - I'll definitely look into your course offerings...
________________________________
From: Mark Snow [mailto:highspeedsnow@gmail.com]
Sent: Saturday, December 17, 2005 5:44 AM
To: Cisco; 'Lelio Fulgenzi'; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...
That sattelilte most likely uses a different telco POP and the telly's
switch wants to see both - switch the Plan/Type back to ISDN/National or
CallManager/CallManager but for that GW only and you should be fine.
HTH
-Mark Snow
________________________________
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Saturday, December 17, 2005 3:23 AM
To: Lelio Fulgenzi; Mark Snow; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...
Argh - one more thing. We have a satellite office that uses the same CM
cluster which experienced the same problem - with called numbering plan
on CallManager all calls matching route pattern 9.@ that included 1
played the carrier message (you must dial 1 first...).
I tried adjusting the called/calling party numbering plans to unknown as
I did the local 6608 gateways. Once the gateway was adjusted all
dialled numbers called that are matched 9.@ that include the "1" were
routed to the gateway, but then dropped. The main different there is
that the gateway is a 2691.
Thoughts - ideas?
________________________________
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 10:58 PM
To: Lelio Fulgenzi; Mark Snow; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] CallManager Route Pattern/Filter Problem...
Yes, I'm with Bell (West) in Vancouver. We have another CM cluster in
the east (Toronto) who is also with Bell. The cluster in Toronto is
using a different PRI protocol (DMS-100) then the Vancouver is using
(NI2).
Well it is late at night so I've been playing with the gateway configs
and trying your suggestion. After changing them to unknown - it worked!
Can you tell me why? Also what should the setting for "Called party IE
number type unknown*" be?
P.S. I will definitely look into your site/course offering!
________________________________
From: Lelio Fulgenzi [mailto:lelio@uoguelph.ca]
Sent: Friday, December 16, 2005 9:35 PM
To: Mark Snow; Cisco; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CallManager Route Pattern/Filter Problem...
You cannot do a debug isdn, but you can import the CCM trace files into
the q931 debug tool and read the output that way. It's a pretty good
tool and I've used it a few times. That's the standalone tool, not the
one that is built into CallManager.
And our numbering plans are set to CallManager.
Frank - are you in Canada? What is your provider? Bell? I can provide
with all of our 6608 parameters if that would help.
----- Original Message -----
From: Mark Snow <mailto:highspeedsnow@gmail.com>
To: 'Cisco' <mailto:subs-cisco@cbvcollections.com> ;
cisco-voip@puck.nether.net
Sent: Friday, December 16, 2005 11:41 PM
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_se....asp?sku=ip0012
-Mark Snow
CCIE Voice # 14073
________________________________
From: cisco [mailto:subs-cisco@cbvcollections.com]
Sent: Friday, December 16, 2005 8:17 PM
To: Mark Snow; cisco-voip@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@gmail.com]
Sent: December 16, 2005 4:59 PM
To: Cisco; cisco-voip@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@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Cisco
Sent: Friday, December 16, 2005 7:24 PM
To: cisco-voip@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?
________________________________
<http://www.cbvcollections.com/cbvImages/ecardlogo.jpg>
Frank Wakelin
Senior Network/Security Analyst
100 - 814 Richards St.
Vancouver, BC
V6B 3A7
Telephone: (604) 661-7906
fwakelin@cbvcollections.com
Confidentiality Warning:
This message and any attachments are intended only for the use
of the intended recipients (cisco-voip@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@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@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@cbvcollections.com> ) par retour de courriel
et supprimer ce message et tout document joint de votre systeme. Merci
________________________________
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
|
|
|
|
|