Mailing List Archive

I didn't go through your email in detail, but, just in case, it might help.

I remember when I tried to do digit manipulation, I found that the manipulation was always dropped before as it went to the next level. Or something like that. Then, when I read the help pages, it spelled it out, something like, this takes precedence over this.

For example, on the route list detail:

The settings on this page override the settings of the same name on the Route Pattern/Route Pilot page. These settings are used for calls routed through this member of the current Route List only.

If you want the prefix digits to be seen by the TSP, then I think you have to put them on the final egress, i.e. trunk.

It's been a while though.



-----Original Message-----
From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Gary Parker
Sent: Friday, May 21, 2021 8:56 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Adding area code to local calls and digit manipulation at route list/route pattern level

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca


Afternoon all, I’ve got a problem I’ve been struggling with for a few days now. It’s bound to be something simple I’ve forgotten from my CCNA Voice days (a long time ago!).

I’m running CUCM 12.5 SU4 with GBNP 1.1(31) and 2921 voice gateways operating as CUBE with IOS 15.5(3)M2 in the UK

Background:
I’m in the process of migrating our outbound PSTN dialling from our Virgin Media Business PRI circuits to SIP trunks provided by Gamma. The problem I’ve encountered is with local rate calls with no area code. Our PRIs will happily route outbound six digit dialled numbers but the SIP trunks will not. I suspect this is a common problem, and will only become more common in the UK as Ofcom removes the obligation on TSPs to provide local dialling:

https://www.ispreview.co.uk/index.php/2021/04/ofcom-will-stop-requiring-uk-phone-providers-to-offer-local-dialling.html

Problem:
I though this would be a relatively simple task of adding Prefix Digits (Outgoing Calls) of my area code (01509) to all calls matching the LOCAL route filter using a Route Pattern. At first glance, Dialled Number Analyzer shows that Dialled Digits of eg. 9112233 gets transformed to Called Party Number of 01509112233

• Results Summary
• Calling Party Information
• Dialed Digits = 9112233
• Match Result = RouteThisPattern
• Matched Pattern Information
• Called Party Number = 01509112233
• Time Zone = Etc/GMT
• End Device = Lboro_SIP_Test
• Call Classification = OffNet
• InterDigit Timeout = NO
• Device Override = Disabled
• Outside Dial Tone = NO
• Call Flow
• Alternate Matches

However calls via the SIP TSP fail with a 404 as the dialled number is still “123456” when I look at debug on the voice gateway.

Looking more closely at the DNA output it appears that the post-transform Called Number at the Route Pattern level isn’t being passed to the Route List:


• Call Flow
• Route Pattern :Pattern= 9.@
• Positional Match List =
• DialPlan = United Kingdom Numbering Plan
• Route Filter
• Require Forced Authorization Code = No
• Authorization Level = 0
• Require Client Matter Code = No
• Call Classification = OffNet
• PreTransform Calling Party Number = 445566
• PreTransform Called Party Number = 9112233
• Calling Party Transformations
• External Phone Number Mask = YES
• Calling Party Mask = XXXXXXXXXX
• Prefix =
• CallingLineId Presentation = Allowed
• CallingName Presentation = Allowed
• Calling Party Number =
• ConnectedParty Transformations
• ConnectedLineId Presentation = Default
• ConnectedName Presentation = Default
• Called Party Transformations
• Called Party Mask =
• Discard Digits Instruction = PreDot
• Prefix = 01509
Correct here -> • Called Number = 01509112233
• Route List :Route List Name= Lboro_SIP_Test
• RouteGroup :RouteGroup Name= LBORO_SIP_Gamma-TEST-RG
• PreTransform Calling Party Number = 445566
Incorrect here -> • PreTransform Called Party Number = 9112233



Why are the transformations I make at the Route List level being dropped when the call gets to the Route Group? I understand that Route List/Group transformations override Route Pattern transformations, but I’m not doing any transformations at the Route List/Group level beside Discard Digits, GBNP: PreDot. This is necessary as, again, although PreDot is applied at the Route Pattern level the ‘9’ is back again when we get to the Route Group.

FYI, I’m using "Use Calling Party's External Phone Number Mask” to correctly apply the area code to CallingPartyNumber in outgoing calls, but that’s not reflected in DNA. External calling party number is always 01509XXXXXX

---
/-Gary Parker----------------------------------f--\
| Unified Communications Service Manager |
n Loughborough University, IT Services |
| tel:+441509635635 sip:gary@lboro.ac.uk o
| https://www.osx.ninja/pubkey.txt |
\r----------------------------------------------d-/

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

My question was about:
• Calling Party Mask = XXXXXXXXXX

You said further down that you were sending 01509XXXXXX but it wasn't
being reflected in DNA. It seems to me that it may be getting overwritten
someplace downstream. I don't think DNA would have just inserted XXXXXXXXXX
by itself.

Can you confirm from the SIP trace (either Real Time from RTMT or 'debug
ccsip messages' on the CUBE) that you are actually sending the right
01509XXXXXX information?

Dave Wolgast
Geneseo, NY


On Fri, May 21, 2021 at 8:59 AM Gary Parker <G.J.Parker@lboro.ac.uk> wrote:

> Afternoon all, I’ve got a problem I’ve been struggling with for a few days
> now. It’s bound to be something simple I’ve forgotten from my CCNA Voice
> days (a long time ago!).
>
> I’m running CUCM 12.5 SU4 with GBNP 1.1(31) and 2921 voice gateways
> operating as CUBE with IOS 15.5(3)M2 in the UK
>
> Background:
> I’m in the process of migrating our outbound PSTN dialling from our Virgin
> Media Business PRI circuits to SIP trunks provided by Gamma. The problem
> I’ve encountered is with local rate calls with no area code. Our PRIs will
> happily route outbound six digit dialled numbers but the SIP trunks will
> not. I suspect this is a common problem, and will only become more common
> in the UK as Ofcom removes the obligation on TSPs to provide local dialling:
>
>
> https://www.ispreview.co.uk/index.php/2021/04/ofcom-will-stop-requiring-uk-phone-providers-to-offer-local-dialling.html
>
> Problem:
> I though this would be a relatively simple task of adding Prefix Digits
> (Outgoing Calls) of my area code (01509) to all calls matching the LOCAL
> route filter using a Route Pattern. At first glance, Dialled Number
> Analyzer shows that Dialled Digits of eg. 9112233 gets transformed to
> Called Party Number of 01509112233
>
> • Results Summary
> • Calling Party Information
> • Dialed Digits = 9112233
> • Match Result = RouteThisPattern
> • Matched Pattern Information
> • Called Party Number = 01509112233
> • Time Zone = Etc/GMT
> • End Device = Lboro_SIP_Test
> • Call Classification = OffNet
> • InterDigit Timeout = NO
> • Device Override = Disabled
> • Outside Dial Tone = NO
> • Call Flow
> • Alternate Matches
>
> However calls via the SIP TSP fail with a 404 as the dialled number is
> still “123456” when I look at debug on the voice gateway.
>
> Looking more closely at the DNA output it appears that the post-transform
> Called Number at the Route Pattern level isn’t being passed to the Route
> List:
>
>
> • Call Flow
> • Route Pattern :Pattern= 9.@
> • Positional Match List =
> • DialPlan = United Kingdom Numbering Plan
> • Route Filter
> • Require Forced Authorization Code = No
> • Authorization Level = 0
> • Require Client Matter Code = No
> • Call Classification = OffNet
> • PreTransform Calling Party Number = 445566
> • PreTransform Called Party Number = 9112233
> • Calling Party Transformations
> • External Phone Number Mask = YES
> • Calling Party Mask = XXXXXXXXXX
> • Prefix =
> • CallingLineId Presentation = Allowed
> • CallingName Presentation = Allowed
> • Calling Party Number =
> • ConnectedParty Transformations
> • ConnectedLineId Presentation = Default
> • ConnectedName Presentation = Default
> • Called Party Transformations
> • Called Party Mask =
> • Discard Digits Instruction = PreDot
> • Prefix = 01509
> Correct here -> • Called Number = 01509112233
> • Route List :Route List Name= Lboro_SIP_Test
> • RouteGroup :RouteGroup Name=
> LBORO_SIP_Gamma-TEST-RG
> • PreTransform Calling Party Number =
> 445566
> Incorrect here -> • PreTransform Called Party Number =
> 9112233
>
>
>
> Why are the transformations I make at the Route List level being dropped
> when the call gets to the Route Group? I understand that Route List/Group
> transformations override Route Pattern transformations, but I’m not doing
> any transformations at the Route List/Group level beside Discard Digits,
> GBNP: PreDot. This is necessary as, again, although PreDot is applied at
> the Route Pattern level the ‘9’ is back again when we get to the Route
> Group.
>
> FYI, I’m using "Use Calling Party's External Phone Number Mask” to
> correctly apply the area code to CallingPartyNumber in outgoing calls, but
> that’s not reflected in DNA. External calling party number is always
> 01509XXXXXX
>
> ---
> /-Gary Parker----------------------------------f--\
> | Unified Communications Service Manager |
> n Loughborough University, IT Services |
> | tel:+441509635635 sip:gary@lboro.ac.uk o
> | https://www.osx.ninja/pubkey.txt |
> \r----------------------------------------------d-/
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

algue tem sala pra disca numeros pra ganha dinheiro?

Em sex., 21 de mai. de 2021 às 15:59, Dave Wolgast <dwolgast@gmail.com>
escreveu:

> My question was about:
> • Calling Party Mask = XXXXXXXXXX
>
> You said further down that you were sending 01509XXXXXX but it wasn't
> being reflected in DNA. It seems to me that it may be getting overwritten
> someplace downstream. I don't think DNA would have just inserted XXXXXXXXXX
> by itself.
>
> Can you confirm from the SIP trace (either Real Time from RTMT or 'debug
> ccsip messages' on the CUBE) that you are actually sending the right
> 01509XXXXXX information?
>
> Dave Wolgast
> Geneseo, NY
>
>
> On Fri, May 21, 2021 at 8:59 AM Gary Parker <G.J.Parker@lboro.ac.uk>
> wrote:
>
>> Afternoon all, I’ve got a problem I’ve been struggling with for a few
>> days now. It’s bound to be something simple I’ve forgotten from my CCNA
>> Voice days (a long time ago!).
>>
>> I’m running CUCM 12.5 SU4 with GBNP 1.1(31) and 2921 voice gateways
>> operating as CUBE with IOS 15.5(3)M2 in the UK
>>
>> Background:
>> I’m in the process of migrating our outbound PSTN dialling from our
>> Virgin Media Business PRI circuits to SIP trunks provided by Gamma. The
>> problem I’ve encountered is with local rate calls with no area code. Our
>> PRIs will happily route outbound six digit dialled numbers but the SIP
>> trunks will not. I suspect this is a common problem, and will only become
>> more common in the UK as Ofcom removes the obligation on TSPs to provide
>> local dialling:
>>
>>
>> https://www.ispreview.co.uk/index.php/2021/04/ofcom-will-stop-requiring-uk-phone-providers-to-offer-local-dialling.html
>>
>> Problem:
>> I though this would be a relatively simple task of adding Prefix Digits
>> (Outgoing Calls) of my area code (01509) to all calls matching the LOCAL
>> route filter using a Route Pattern. At first glance, Dialled Number
>> Analyzer shows that Dialled Digits of eg. 9112233 gets transformed to
>> Called Party Number of 01509112233
>>
>> • Results Summary
>> • Calling Party Information
>> • Dialed Digits = 9112233
>> • Match Result = RouteThisPattern
>> • Matched Pattern Information
>> • Called Party Number = 01509112233
>> • Time Zone = Etc/GMT
>> • End Device = Lboro_SIP_Test
>> • Call Classification = OffNet
>> • InterDigit Timeout = NO
>> • Device Override = Disabled
>> • Outside Dial Tone = NO
>> • Call Flow
>> • Alternate Matches
>>
>> However calls via the SIP TSP fail with a 404 as the dialled number is
>> still “123456” when I look at debug on the voice gateway.
>>
>> Looking more closely at the DNA output it appears that the post-transform
>> Called Number at the Route Pattern level isn’t being passed to the Route
>> List:
>>
>>
>> • Call Flow
>> • Route Pattern :Pattern= 9.@
>> • Positional Match List =
>> • DialPlan = United Kingdom Numbering Plan
>> • Route Filter
>> • Require Forced Authorization Code = No
>> • Authorization Level = 0
>> • Require Client Matter Code = No
>> • Call Classification = OffNet
>> • PreTransform Calling Party Number = 445566
>> • PreTransform Called Party Number = 9112233
>> • Calling Party Transformations
>> • External Phone Number Mask = YES
>> • Calling Party Mask = XXXXXXXXXX
>> • Prefix =
>> • CallingLineId Presentation = Allowed
>> • CallingName Presentation = Allowed
>> • Calling Party Number =
>> • ConnectedParty Transformations
>> • ConnectedLineId Presentation = Default
>> • ConnectedName Presentation = Default
>> • Called Party Transformations
>> • Called Party Mask =
>> • Discard Digits Instruction = PreDot
>> • Prefix = 01509
>> Correct here -> • Called Number = 01509112233
>> • Route List :Route List Name= Lboro_SIP_Test
>> • RouteGroup :RouteGroup Name=
>> LBORO_SIP_Gamma-TEST-RG
>> • PreTransform Calling Party Number =
>> 445566
>> Incorrect here -> • PreTransform Called Party Number =
>> 9112233
>>
>>
>>
>> Why are the transformations I make at the Route List level being dropped
>> when the call gets to the Route Group? I understand that Route List/Group
>> transformations override Route Pattern transformations, but I’m not doing
>> any transformations at the Route List/Group level beside Discard Digits,
>> GBNP: PreDot. This is necessary as, again, although PreDot is applied at
>> the Route Pattern level the ‘9’ is back again when we get to the Route
>> Group.
>>
>> FYI, I’m using "Use Calling Party's External Phone Number Mask” to
>> correctly apply the area code to CallingPartyNumber in outgoing calls, but
>> that’s not reflected in DNA. External calling party number is always
>> 01509XXXXXX
>>
>> ---
>> /-Gary Parker----------------------------------f--\
>> | Unified Communications Service Manager |
>> n Loughborough University, IT Services |
>> | tel:+441509635635 sip:gary@lboro.ac.uk o
>> | https://www.osx.ninja/pubkey.txt |
>> \r----------------------------------------------d-/
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

We had an issue with one of our clusters where we were not sending the
proper ELIN from CER to the ITSP, so the PSAP was receiving the incorrect
information. Turns out that CER was modifying the ANI to the proper ELIN,
but we had a Calling Party Transformation CSS setup on the SIP trunk for
Outgoing Calls in CUCM. That caused the Original DN not the CER modified
ANI to alway be sent to the ITSP. Our Transformation pattern \+1.XXXXXXXXXX
was causing the original DN to be sent out under invite from CUCM. WE
needed to make changes in CUCM or CUBE accordingly. I removed our
CSS_CPN_Lumos drop-down from the Calling Party Transformation CSS on the
SIP Trunk. Then checked, Use Device Pool Calling Party Transformation CSS.
Then reset the trunk and wait for it to register. Then our test 911 calls
showed the correct ELIN and not the original DN.

++ So we had 3 options to correct this issue:

**change the directory number so that it doesn't match the pattern
**Remove the transformation from the trunk
**Delete the pattern \+1.XXXXXXXXXX

We removed the transformation from the trunk.

Transformation patterns configured on the device selected to route the call
(or on that device’s device pool) take precedence over calling and called
party transformations configured in the route pattern and/or route list. If
a transformation calling search space (CSS) is configured on the device
selected to route the call (or on that device’s device pool),
then transformations configured in the route pattern or route list are
considered only if no match is found using the
respective transformation CSS. The input to the transformation CSS always
is the untransformed number before applying route pattern or route
list transformations. Refer to
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/dialplan.html#63188

On Fri, May 21, 2021 at 3:04 PM Raffi Rodrigo <raffireis@gmail.com> wrote:

> algue tem sala pra disca numeros pra ganha dinheiro?
>
> Em sex., 21 de mai. de 2021 às 15:59, Dave Wolgast <dwolgast@gmail.com>
> escreveu:
>
>> My question was about:
>> • Calling Party Mask = XXXXXXXXXX
>>
>> You said further down that you were sending 01509XXXXXX but it wasn't
>> being reflected in DNA. It seems to me that it may be getting overwritten
>> someplace downstream. I don't think DNA would have just inserted XXXXXXXXXX
>> by itself.
>>
>> Can you confirm from the SIP trace (either Real Time from RTMT or 'debug
>> ccsip messages' on the CUBE) that you are actually sending the right
>> 01509XXXXXX information?
>>
>> Dave Wolgast
>> Geneseo, NY
>>
>>
>> On Fri, May 21, 2021 at 8:59 AM Gary Parker <G.J.Parker@lboro.ac.uk>
>> wrote:
>>
>>> Afternoon all, I’ve got a problem I’ve been struggling with for a few
>>> days now. It’s bound to be something simple I’ve forgotten from my CCNA
>>> Voice days (a long time ago!).
>>>
>>> I’m running CUCM 12.5 SU4 with GBNP 1.1(31) and 2921 voice gateways
>>> operating as CUBE with IOS 15.5(3)M2 in the UK
>>>
>>> Background:
>>> I’m in the process of migrating our outbound PSTN dialling from our
>>> Virgin Media Business PRI circuits to SIP trunks provided by Gamma. The
>>> problem I’ve encountered is with local rate calls with no area code. Our
>>> PRIs will happily route outbound six digit dialled numbers but the SIP
>>> trunks will not. I suspect this is a common problem, and will only become
>>> more common in the UK as Ofcom removes the obligation on TSPs to provide
>>> local dialling:
>>>
>>>
>>> https://www.ispreview.co.uk/index.php/2021/04/ofcom-will-stop-requiring-uk-phone-providers-to-offer-local-dialling.html
>>>
>>> Problem:
>>> I though this would be a relatively simple task of adding Prefix Digits
>>> (Outgoing Calls) of my area code (01509) to all calls matching the LOCAL
>>> route filter using a Route Pattern. At first glance, Dialled Number
>>> Analyzer shows that Dialled Digits of eg. 9112233 gets transformed to
>>> Called Party Number of 01509112233
>>>
>>> • Results Summary
>>> • Calling Party Information
>>> • Dialed Digits = 9112233
>>> • Match Result = RouteThisPattern
>>> • Matched Pattern Information
>>> • Called Party Number = 01509112233
>>> • Time Zone = Etc/GMT
>>> • End Device = Lboro_SIP_Test
>>> • Call Classification = OffNet
>>> • InterDigit Timeout = NO
>>> • Device Override = Disabled
>>> • Outside Dial Tone = NO
>>> • Call Flow
>>> • Alternate Matches
>>>
>>> However calls via the SIP TSP fail with a 404 as the dialled number is
>>> still “123456” when I look at debug on the voice gateway.
>>>
>>> Looking more closely at the DNA output it appears that the
>>> post-transform Called Number at the Route Pattern level isn’t being passed
>>> to the Route List:
>>>
>>>
>>> • Call Flow
>>> • Route Pattern :Pattern= 9.@
>>> • Positional Match List =
>>> • DialPlan = United Kingdom Numbering Plan
>>> • Route Filter
>>> • Require Forced Authorization Code = No
>>> • Authorization Level = 0
>>> • Require Client Matter Code = No
>>> • Call Classification = OffNet
>>> • PreTransform Calling Party Number = 445566
>>> • PreTransform Called Party Number = 9112233
>>> • Calling Party Transformations
>>> • External Phone Number Mask = YES
>>> • Calling Party Mask = XXXXXXXXXX
>>> • Prefix =
>>> • CallingLineId Presentation = Allowed
>>> • CallingName Presentation = Allowed
>>> • Calling Party Number =
>>> • ConnectedParty Transformations
>>> • ConnectedLineId Presentation = Default
>>> • ConnectedName Presentation = Default
>>> • Called Party Transformations
>>> • Called Party Mask =
>>> • Discard Digits Instruction = PreDot
>>> • Prefix = 01509
>>> Correct here -> • Called Number = 01509112233
>>> • Route List :Route List Name= Lboro_SIP_Test
>>> • RouteGroup :RouteGroup Name=
>>> LBORO_SIP_Gamma-TEST-RG
>>> • PreTransform Calling Party Number =
>>> 445566
>>> Incorrect here -> • PreTransform Called Party Number =
>>> 9112233
>>>
>>>
>>>
>>> Why are the transformations I make at the Route List level being dropped
>>> when the call gets to the Route Group? I understand that Route List/Group
>>> transformations override Route Pattern transformations, but I’m not doing
>>> any transformations at the Route List/Group level beside Discard Digits,
>>> GBNP: PreDot. This is necessary as, again, although PreDot is applied at
>>> the Route Pattern level the ‘9’ is back again when we get to the Route
>>> Group.
>>>
>>> FYI, I’m using "Use Calling Party's External Phone Number Mask” to
>>> correctly apply the area code to CallingPartyNumber in outgoing calls, but
>>> that’s not reflected in DNA. External calling party number is always
>>> 01509XXXXXX
>>>
>>> ---
>>> /-Gary Parker----------------------------------f--\
>>> | Unified Communications Service Manager |
>>> n Loughborough University, IT Services |
>>> | tel:+441509635635 sip:gary@lboro.ac.uk o
>>> | https://www.osx.ninja/pubkey.txt |
>>> \r----------------------------------------------d-/
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

Thanks Lelio, that was the problem. As per https://www.ciscopress.com/articles/article.asp?p=1745737&seqNum=8

"
The three levels of digit manipulation are not cumulative. Only one level of digit manipulation will be applied. The hierarchy for these digit manipulations are as follows:

• Digit manipulation settings on the route pattern take effect only when the route list details do not have any defined digit manipulations. A transformation CSS applied at the gateway/trunk or device pool will also cause the digit manipulations applied at the route pattern level to be skipped.
• If the transformation CSS at the gateway or trunk matches, but the route list details have configured digit manipulations, the manipulations configured at the route list details are used. Route pattern digit manipulations are ignored.
• If any manipulation matches through a gateway or trunk transformation CSS, all other digit manipulations are ignored.
"

I had assumed (wrongly) that changes were applied in order from route pattern, through route list/group and gateway/trunk, and were additive.

My reading of the above suggests that a transformation at Route List level overrides both Route Pattern *and* gateway/trunk transformations. Which is odd to me as, from a call flow perspective, the Route List sits in between Route Pattern and gateway/trunk.

Anyway, I set up a new route pattern, route list and route group specifically for these local calls that matched my LOCAL route filter and am applying the transformation successfully at the route group.

One other wrinkle that turned up while applying this was that the dot and @ position indication seems to be lost when transforming at the route group level. While I could successfully apply GBNP:PreDot as a digit strip option at Route Pattern level, trying to do the same at Route List/Group removes *all* digits. As a consequence I’m instead using a Called Party Transform Mask to get the last six digits of the dialled string and prefixing that with the appropriate area code.

It’s working, but it feels inelegant.

Gary


> On 21 May 2021, at 19:39, Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>
> I didn't go through your email in detail, but, just in case, it might help.
>
> I remember when I tried to do digit manipulation, I found that the manipulation was always dropped before as it went to the next level. Or something like that. Then, when I read the help pages, it spelled it out, something like, this takes precedence over this.
>
> For example, on the route list detail:
>
> The settings on this page override the settings of the same name on the Route Pattern/Route Pilot page. These settings are used for calls routed through this member of the current Route List only.
>
> If you want the prefix digits to be seen by the TSP, then I think you have to put them on the final egress, i.e. trunk.
>
> It's been a while though.

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

That’s great to hear you solved your problem !

Sent from my iPhone

> On May 24, 2021, at 7:33 AM, Gary Parker <G.J.Parker@lboro.ac.uk> wrote:
>
> ?CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca
>
>
> Thanks Lelio, that was the problem. As per https://www.ciscopress.com/articles/article.asp?p=1745737&seqNum=8
>
> "
> The three levels of digit manipulation are not cumulative. Only one level of digit manipulation will be applied. The hierarchy for these digit manipulations are as follows:
>
> • Digit manipulation settings on the route pattern take effect only when the route list details do not have any defined digit manipulations. A transformation CSS applied at the gateway/trunk or device pool will also cause the digit manipulations applied at the route pattern level to be skipped.
> • If the transformation CSS at the gateway or trunk matches, but the route list details have configured digit manipulations, the manipulations configured at the route list details are used. Route pattern digit manipulations are ignored.
> • If any manipulation matches through a gateway or trunk transformation CSS, all other digit manipulations are ignored.
> "
>
> I had assumed (wrongly) that changes were applied in order from route pattern, through route list/group and gateway/trunk, and were additive.
>
> My reading of the above suggests that a transformation at Route List level overrides both Route Pattern *and* gateway/trunk transformations. Which is odd to me as, from a call flow perspective, the Route List sits in between Route Pattern and gateway/trunk.
>
> Anyway, I set up a new route pattern, route list and route group specifically for these local calls that matched my LOCAL route filter and am applying the transformation successfully at the route group.
>
> One other wrinkle that turned up while applying this was that the dot and @ position indication seems to be lost when transforming at the route group level. While I could successfully apply GBNP:PreDot as a digit strip option at Route Pattern level, trying to do the same at Route List/Group removes *all* digits. As a consequence I’m instead using a Called Party Transform Mask to get the last six digits of the dialled string and prefixing that with the appropriate area code.
>
> It’s working, but it feels inelegant.
>
> Gary
>
>
>> On 21 May 2021, at 19:39, Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>>
>> I didn't go through your email in detail, but, just in case, it might help.
>>
>> I remember when I tried to do digit manipulation, I found that the manipulation was always dropped before as it went to the next level. Or something like that. Then, when I read the help pages, it spelled it out, something like, this takes precedence over this.
>>
>> For example, on the route list detail:
>>
>> The settings on this page override the settings of the same name on the Route Pattern/Route Pilot page. These settings are used for calls routed through this member of the current Route List only.
>>
>> If you want the prefix digits to be seen by the TSP, then I think you have to put them on the final egress, i.e. trunk.
>>
>> It's been a while though.
>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip