SRST - internal DNs cannot call each other

Answered Question
Jul 28th, 2010

During a recent SRST event, internal DNs were unable to call each other.  All other dialing (in and out over PRI) was working, but phones registered to the 2821 could not call each other ?!  All DNs are three digits - 1xx.  Received a fast-busy immediately upon dialing "1".  No COR is being used anywhere.

Any ideas why the registered phones could not call each other?

I have this problem too.
0 votes
Correct Answer by Steven Holl about 6 years 4 months ago

Change that 'destination-pattern .' to 'destination-pattern .T'  You never want to have 'destination-pattern .' for any scenarios where you have non-enbloc dialing.

'destination-pattern .' WILL get matched after the first digit and route the call.  You can use 'debug voip ccapi inout' to observe this.  By adding the T, it says that even though 'destination-pattern .' is a match, wait 10 seconds for other digits before committing to the dial-peer match decision.

Like I mentioned in a previous post, this is yet another reason why people use a trunk access code of 9 to dial PSTN calls.  Then you don't have POTS and DN extension overlap.  If you understand dialplan design well, you can get by without a trunk access code, but in my expeience most people that implement a dialplan without trunk access codes cause unwanted overlap and end up causing call loops, sending calls in the wrong directions, etc.

-Steve

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Thomas Dillingham Wed, 08/04/2010 - 15:22

There are a few things that would cause this, lets start with this:

Are your extensions 3 digits on CUCM, or, is there a translation pattern that allows you to dial 3 digits, while the extensions are actually more or less than 3 digits?

Thomas Dillingham

Cisco TAC - MS Voice

TwD

Thomas Dillingham Wed, 08/04/2010 - 16:59

Current Config, based on your attachments include:

dial-peer voice 9920 pots
description incoming PRI SRST
translation-profile incoming SRST-PRI-in
destination-pattern .
direct-inward-dial
port 0/0/0:23

Ok,

Your destination pattern is a single "dot" ".".  This would mean that when an end user goes off hook and attempts to dial anything that does not match the other patterns, it will match on this pattern, even though this dial peer is set up for incomming calls, it could be matching as an outbound dial peer for the phones.

You may try to change the destination-pattern to a more specific pattern; a pattern that would match the DID numbers that are coming into the gateway from the PSTN on the PRI.

i.e.

dial-peer voice 9920 pots
  description incoming PRI SRST
  translation-profile incoming SRST-PRI-in
  destination-pattern 33721..  !! << this will depend on how many digits you receive and your DID range etc...
  direct-inward-dial
  port 0/0/0:23

If you try this, test this, if does not work, then I can provide a list of debugs to collect.

TwD

kc.iefbr14 Wed, 08/04/2010 - 17:44

But all DID numbers are working correctly.  It's just the SRST DNs that - and believe me, I may very well be missing something here, especially since I just spent 90 minutes in the dentist chair . . .  - are unable to be dialed.  And every single DN on every phone that registers via SRST has its own dynamic dial peer, correct?  In that case, I should be able to dial the DN of an SRST-registered phone from another SRST-registered phone since it's a much more specific match than the "destination-pattern ."  And again, the fast-busy occurs immediately upon dialing the "1" - - it would seem that at the very least, if I were matching the dial-peer you point out, It would let me complete the dial string, whatever that may turn out to be once all digits are dialed, before rendering its verdict.?

Correct Answer
Steven Holl Thu, 08/05/2010 - 08:14

Change that 'destination-pattern .' to 'destination-pattern .T'  You never want to have 'destination-pattern .' for any scenarios where you have non-enbloc dialing.

'destination-pattern .' WILL get matched after the first digit and route the call.  You can use 'debug voip ccapi inout' to observe this.  By adding the T, it says that even though 'destination-pattern .' is a match, wait 10 seconds for other digits before committing to the dial-peer match decision.

Like I mentioned in a previous post, this is yet another reason why people use a trunk access code of 9 to dial PSTN calls.  Then you don't have POTS and DN extension overlap.  If you understand dialplan design well, you can get by without a trunk access code, but in my expeience most people that implement a dialplan without trunk access codes cause unwanted overlap and end up causing call loops, sending calls in the wrong directions, etc.

-Steve

Tracy Larson Mon, 08/09/2010 - 09:39

under your call-manager-fallback config you might need this.

ip source-address xxx.xxx.xxx.xxx (routers ip) port 2000       This enables teh router to receive messages from cisco ip phones through the specified ip addresses and ports.

edit: oops just saw your config file and that is already in there.

kc.iefbr14 Tue, 08/17/2010 - 07:13

Finally got a chance to simulate a failover for two phones - the destination-pattern .T was the solution.  Thanks for the reply!

Actions

This Discussion