cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2419
Views
0
Helpful
8
Replies

SRST - internal DNs cannot call each other

kc.iefbr14
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

Steven Holl
Cisco Employee
Cisco Employee

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

View solution in original post

8 Replies 8

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

CUCM uses only 3-digit extensions.  Attached is SRST gateway config.

Justin Brenton
Level 4
Level 4

Please post the config of your voice gateway.

Thanks,

Justin

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

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.?

Steven Holl
Cisco Employee
Cisco Employee

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

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.

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: