dial-peer trouble

Unanswered Question
Aug 22nd, 2008

I currently have a 2821 gateway with dial-peers. Access code is 7 along with 10 digit dialing. The end user dials 77042895829. The CCM routes the call to the gateway. The router sends 10 digits, which includes the access code, but strips the last digit. See below for the 2 dial-peers that matches the digits along with the debug that shows the 10 digits that are being sent. Any help would greatly be appreciated!

dial-peer voice 31234 pots

destination-pattern [2-9].........

progress_ind setup enable 3

progress_ind alert enable 8

progress_ind progress enable 8

progress_ind connect enable 8

port 0/0/0:23

forward-digits all

dial-peer voice 99 pots

destination-pattern 7[2-9].........

progress_ind setup enable 3

progress_ind alert enable 8

progress_ind progress enable 8

progress_ind connect enable 8

port 0/0/0:23

forward-digits 10

Calling Party Number i = 0x0080, '29994'

Plan:Unknown, Type:Unknown

Called Party Number i = 0xA1, '7704289582'

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Adam Thompson Fri, 08/22/2008 - 12:23

How does this gateway communicate with CallManager? H.323? MGCP? etc...

I am assuming H.323 since you say the gateways dial-peers are directing the call routing.

The problem is that you are matching dial-peer 31234 and not dial-peer 99. Add the direct-inward-dial command to both dial-peers and that should take care of the issue.

Without the direct-inward-dial command, digit-by-digit analysis is being performed that is why you are hitting the 31234 dial-peer and not the 99 dial-peer when the user dials the 7 access code.

Please rate if helpful

bgrunewald Sat, 08/23/2008 - 15:51

How do you know it is matching dial peer 99?

If you have another POTS peer than can match 77 at the beginning (like 31234 for instance), it will grab the call but not forward enough digits.

Router dial peer matching is not "best match" like UCM, it is "first match". The peers are matched in the order they are physically listed in the configuration, not in the order of the tag numbers.

The only fix is to put the longest/most specific matches into the configuration first, so you get the expected behavior. Just one of the joys of Cisco IPT - each platform is developed by a different group, so consistency suffers.

Actions

This Discussion