call is not matching outgoing dialpeer help !

Unanswered Question
May 22nd, 2008
User Badges:

Hi, I can't understand why incoming dialpeer is matched but outgoing dialpeer is not ! Look at the config:

dial-peer voice 1 pots

description "Asterisk"

incoming called-number 932142200

no digit-strip



dial-peer voice 100 pots

description "sortida pri 1"

destination-pattern 932142200

port 0/1/0:15

Con somebody tell me why the result of the outgoing dialpeer is -1, not matching ? The digits are exatly the same ! Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Michael Owuor Thu, 05/22/2008 - 19:35
User Badges:
  • Cisco Employee,

Dial-peer 1 is a pots dial-peer, so try specifying a voice port to use for the call.



godzilla0 Fri, 05/23/2008 - 03:25
User Badges:

Doing the same configuration on a AS5400 gw, I don't need to specify the incoming voice port.

In fact the calls are getting in and matching the incoming dialpeer. Any comments ?

Michael Owuor Fri, 05/23/2008 - 03:40
User Badges:
  • Cisco Employee,

Is it possible that the calls are matching on the default dial-peer and not the one you are expecting? One way to confirm is to collect the output of 'debug voip ccapi inout' while recreating it.



godzilla0 Fri, 05/23/2008 - 04:15
User Badges:

Doing the same configuration on a AS5400 gw, I don't need to specify the incoming voice port.

In fact the calls are getting in and matching the incoming dialpeer. Any comments ?

godzilla0 Fri, 05/23/2008 - 04:35
User Badges:

Sorry I repeated the same twice. There are no more dialpeers, just these two for a basic testing. It's possible that the call is not matching the second dialpeer beacause a PRI misconfiguration ?

Michael Owuor Fri, 05/23/2008 - 05:29
User Badges:
  • Cisco Employee,

Its not outside the realm of possibility, however, for outbound call legs, dial-peer matching and selection is done first before the call is placed, so a problem with the PRI configuration would manifest itself after the dial-peer has been matched.

Lets take a step back and make sure we are clear about the goal and the problem. I understand the problem to be that you have configured two pots dial-peers, one for inbound (dial-peer 1), and another for outbound (dial-peer 100), and that the configuration is not working.

Is this understanding correct? If not, please help clarify.

What is the evidence that it is not working? Are you getting a busy tone, disconnect, or other? How did you confirm that the inbound leg is working through dial-peer 1?

Based on a casual review of the configuration you posted, I think we can safely conclude that:

1. dial-peer 1 will *not* be used for the inbound leg because this dial-peer does not have a port specified. Without one, it is not a candidate to be used for any inbound or outbound call.

2. dial-peer 100 will *not* be used for the inbound leg of the call because the matching criteria is a destination-pattern statement to 932142200. When inbound call legs are matched, the destination-pattern statement uses the calling number to match the incoming call leg to an inbound dial peer. 932142200 is the called number in this case.

So if neither dial-peers are matched for the inbound leg of the call, then the other possibility is the default dial-peer (dial-peer 0). As you know, this dial-peer does not appear in the configuration but is matched automatically when there is no incoming dial-peer that matches. See also

So if we conclude that dial-peer 0 is being used for the inbound leg of the call, we should then review the configuration to determine if there is a dial-peer that will match the outbound leg of the call.

Dial-peer 100 could match the outbound leg because when outbound call legs are matched, the destination-pattern statement uses the called number to match the outgoing call leg to an outbound dial peer. 932142200 is the called number in this case, so dial-peer 100 could match.

If dial-peer 100 is matched for the outgoing call leg, then keep in mind that the default behavior of an outgoing pots dial-peer is to strip the digits that were explicitly matched. The destination-pattern statement in this case would explicitly match 932142200, and therefore that entire number would be stripped and the PRI would send no digits in the outgoing Setup message. This may be the reason the call is failing.

Which digits are expected on the PRI associated with voice-port 0/1/0:15 when placing the call? For example, if all the 9 digits are expected, then use the command 'prefix 932142200' under dial-peer 100. Otherwise use the 'no digit-strip' or 'forward-digits' commands to achieve the same results.

One other question I have is does the inbound call leg come in on a different voice-port than 0/1/0:15? We just want to make sure that we are not send the call back to the same place that the call originated from without changing the called number, lest we create a loop.

I hope this helps get you closer to resolution.



godzilla0 Fri, 05/23/2008 - 06:45
User Badges:

The way I know it is with debugging. Dialpeer 1 is matched, result = 0. Then the outgoing call leg can't match the dialpeer 100 result -1.

I do it with "debug voice dialpeer all".

One thing I can't understand is that with an AS5400 that I administer, incoming dialpeers does not have the need for an incoming voiceport. So you are saying that on a Cisco 2800 router you need to specify the port for incoming calls ? I tryed to change the voice port to make sure that is not the incoming voice port what I'm configuring for outbound calls too. So It's the right port.

Michael Owuor Fri, 05/23/2008 - 12:55
User Badges:
  • Cisco Employee,


The multiservice gateways such as the AS5x00 series gateways indeed have different behavior because they may handle voice calls or modem calls.

Check out the 'Usage Guidelines' section of the 'incoming called-number' command here:

Have you had an opportunity to test the 2800 with the recommended configuration?



paolo bevilacqua Fri, 05/23/2008 - 13:07
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

To add to mowuor's good advice, at some point and silently, code has changed so that right now, port is not needed for a pure incoming DP, not even on the ISR routers.

godzilla0 Sun, 05/25/2008 - 23:47
User Badges:

What you mean with "the recommended config" ?

Is there some place where I can see pots and dialpeer configuration examples for this router series ?


This Discussion