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.par...@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 > ith...@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 <le...@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
