Pots dial-peer digit stripping.

Unanswered Question


I'm aware that pots dial-peers strip the qualified digits from a destination pattern. For example, a pots dial-peer with 'destination-pattern 9T' would strip the leading 9 automatically. Therefore, if I were to call 912345, the result call would be to 12345.

So far so good.

I recently need to match only a particular dial-peer for a given caller so I implemented a translation profile on the ephone-dn for the call that translated the called number from 12345 to CC12345. Note that 'CC' are defined as valid dtmf digits; DTMF being from 0-9,*,#, A-D, Flash. I then created an outbound pots dial-peer with destination-pattern CCT so as to match this call. The dial-peer matched just fine, the only problem was that the 'CC' was not stripped! I had to apply another translation profile on this outbound pots dial-peer so as to strip 'CC'.

My question therefore is why do pots dial-peers strip normal numbers '0-9' but not 'A-D'?



P.S. I'm aware that the above can be accomplished in other ways such as cor-list. My question is soley in relation to digit stripping on pots dial-peers.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Steven DiStefano Sat, 02/13/2010 - 13:57
User Badges:
  • Blue, 1500 points or more

Your right, it should stip A,B,C,D:

Router(config-dial-peer)# destination-pattern string [T]

Matches dialed digits to a telephony device.

The string argument is a series of digits that specify the E.164 or private dialing plan telephone number.
Valid entries are the numbers 0 through 9 and the letters A through D.

You can also enter the following special characters:
• The asterisk (*) or pound sign (#) on standard touch-tone dial pads can be used anywhere in the pattern.
• The period (.) acts as a wildcard character.
When the timer (T) character is included at the end of the destination pattern, the router collects dialed digits until the interdigit timer expires (10 seconds,
by default) or until you dial the termination character (the default is #). The timer character must be a capital T.

What does your look like?


Here's what it looks like:

ephone-dn  11  dual-line
number 101
pickup-group 1
call-forward noan 299 timeout 30
corlist incoming call-paulaccess
corlist outgoing call-paul
translation-profile incoming Paul_Outgoing

dial-peer voice 1096 pots
corlist outgoing call-paulfxo
permission term
description Dial Peer for Paul to external (FXO)
translation-profile outgoing Paulfxo_Outgoing
destination-pattern CDT
port 0/1/1

voice translation-rule 41
rule 1 /^9\(...+\)$/ /CD\1/

voice translation-profile Paul_Outgoing
translate called 41

So, Paul_Outgoing is applied to incoming calls from the ephone and it prepends 'CD' to the called number. This should then match dial-peer 1096 and get routed out to the PSTN over the FXO port. All this works fine. The problem is that The call is routed out to the PSTN with CD. In other words, CD is not automatically stripped as one would expect. I have to manually strip this in ' translation-profile outgoing Paulfxo_Outgoing' which is applied to the dial-peer 1096 and contains the following:

voice translation-rule 40
rule 1 // /1234567/

voice translation-rule 50
rule 1 /^C.\(.+\)$/ /\1/

voice translation-profile Paulfxo_Outgoing
translate calling 40
translate called 50

As can be seen in the above, I 'manually' strip 'CD' using translation-rule 40.

Just for reference, attached please find debug voip ccapi inout from the same system with translation-rule 40 removed. You'll see the call is routed out with CD still prepended and it ultimately fails.

Let me know if you require further info.



Steven DiStefano Mon, 02/15/2010 - 10:24
User Badges:
  • Blue, 1500 points or more
try this rule .....
voice translation-pattern-rule 41
rule 1 /^9\(.*\)/  /CD\1/


I suspect this was my mistake after all. It seems to be working after all without the need for a translation profile. For some reason, the phone line from the telco was saying ‘the number you called does not exist’ when I place a call so I thought the number was being dialled incorrectly. Turns out it seems to be doing it for all calls...

You can therefore ignore this issue for now. I’ll let you know should I get to re-test and find things are different.



Steven DiStefano Mon, 02/22/2010 - 19:46
User Badges:
  • Blue, 1500 points or more

OK, Thanks.  I think i misunderstood your question too,:-)
as far as I could find, there is no automatic stripping, should have translation rule for any stripping.

Hi Steve,

Pots (not voip) dial-peers do indeed strip any leading digits from a destination-pattern automatically; there's no need for a translation profile in this case. See: http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml#topic10. In this example, the dial-peer is configured with destination-patter 9T. The user dials 95551212 and the result call out to the PSTN is 5551212. You'll note that the '9' is automatically stripped...


This Discussion