Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

SRST Call routing issue

Unanswered Question
Oct 6th, 2010
User Badges:


This issue is for Calls from an SRST site to central site CUCM.  Calls dialed with full national number from the SRST traverses the  WAN, into the central site, into the PSTN cloud then back to Central Site. The Call Manager version is 7.1 and the appropriate route lists configured on the SRST gateway to route calls first to  the local gateway and into the Central Site. The SRST router has two links - one to the WAN and another to the PSTN circuit.

I am unable to understand if this issue is at the Central Site or SRST site.

Please advise.

Thanks and Regards.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Jefferson Islan... Wed, 10/06/2010 - 04:04
User Badges:

Hi Mahankumarm, how are you?

Sorry, I'm not understand your environment. Could you explain with more details?

mohankumarm Wed, 10/06/2010 - 04:42
User Badges:

Hello Jefferson,

thanks for your response.

Let me explain how the call manager is set up in this network.

The Call Manager is located in a Central Site for about 200 endpoints on the Local network. There are about 4 branch sites located in other states which connect/register to the Call Manager at the Central Site throught an IOS router - which runs only SRST - and this router has WAN connections through a Service Provider and also PSTN connections through the service provider. All on-net calls is routed over the WAN.

the following route lists are created and applied to the gateway.

1.Interstate Outbound offnet calls are pointed to the local PSTN Gateway first for various calls classified as Standard, IDD,

This logic was replicated from another SRST router from another branch which is working ok.

Now the customer complains any outbound call from the branch (with a full national number) is routing incorrectly

Branch-> WAN -> To Central Site -> PSTN -> Central Site

where as the correct sequence should be

Branch-> WAN -> To Central Site

I am not sure why is the call going out to PSTN and then back to Central Site.

Thanks and Regards,


James Hawkins Wed, 10/06/2010 - 05:28
User Badges:
  • Blue, 1500 points or more


Is this happening when the WAN link is up or when it is down and the branch phones registered to the SRST gateway.

If it is when the WAN is up then your issue would probably be solved by using translation patterns to translate the full dialled PSTN numbers to the extensions.

For instance a phone could have the DID 020 8235 6666 and a four digit extension 6666.

If an on-net user dials 902082356666 (9 is the PSTN access code) it would match a route pattern and be sent to the PSTN which would send it back on another channel.

If you configure a translation pattern to convert 902082356666 to 6666 then the call will match the phone extension and not go out via the PSTN.

Obviously you would use wildcards in the translation patterns to match DID ranges rather than configuring specific translations for each extension.

mohankumarm Wed, 10/06/2010 - 05:41
User Badges:

Hi James,

Thanks very much indeed.

The issue is happening when the WAN link is up and the translation patterns have already been configured to match both 10 digit ( 2 digit area code + 8 digit number) and 8 digit (only subscriber number) numbers.

Where do you check the call routing information on Call Manager? is it on DNA with gateway option?

Thanks and Regards,

James Hawkins Wed, 10/06/2010 - 06:00
User Badges:
  • Blue, 1500 points or more


You should be able to check using DNA but with the phone option rather than the gateway option. If the WAN is up then the remote site SRST router should not have any effect on the call routing - it will just forward the call setup to CUCM and the call will be routed according to the CUCM dial plan.

I would suspect that maybe the calls are not hitting the translation patterns you have configured - DNA should allow you to check this.

Steven Holl Wed, 10/06/2010 - 07:14
User Badges:
  • Cisco Employee,

Perhaps the CSS for the calling device has the partition for local calls above the partition for internal dialing.  Since they are the same length, you need to make sure the partition for your internal extensions is matched before the match for the route pattern that points local calls out to the PSTN.  It's either that or a translation in a partition is getting hit before the internal IP extenion partition.

Like someone mentioned before, Dialed Number Analyzer should show this.  You could also pull a detailed CM trace and search for dd="5551234" where 5551234 is the number that is dialed.  You should see a pss around there, which is the list of partitions it will look in to get a match for the dialed number.  Couple that with the output of a route plan report, and you should be able to figure out what is occurring.

mohankumarm Thu, 10/07/2010 - 06:01
User Badges:

Hello Steven and James,

Many many thanks for your advise and i am still waiting to hear from our customer on this issue and will post as soon as i have feedback and once again thanks very much indeed for the troubleshooting tips.

Thanks and Regards,


Corey Caruso Thu, 10/07/2010 - 08:16
User Badges:

Hi everyone!  I have a quick question that relates to this post.  I have a my central CUCM site and remote H.323 gateways setup.  The issue now is when users dial the full 10 digits my calls route over the PSTN, not what I want.  So in order to get them to rotue within the WAN I assume the translation pattern takes care of this, as you have noted?  I did some testing and indeed can make a translation pattern work.  So my only question is what happens from my central site if the WAN link goes down?  Will the call then go out the PSTN?  I am afraid if I implement these translations and the WAN link goes down, the call will not connect, am I wrong in assuming this?

Thanks all!

Steven Holl Thu, 10/07/2010 - 08:39
User Badges:
  • Cisco Employee,

Yes a translation on CM to translate the PSTN number to the internal number is what you want to do to prevent PSTN hairpinning.

When you go into SRST mode, you are correct, the translation is lost.  That's fine, though, since you can't dial via VoIP (4-digit or whatever internal length you use) to the other site in this scenario anyway.  So they will dial like they do normally, and it should hit a POTS dial-peer and go out 10 digit to the PSTN and into your HQ site.

Now, just the opposite.  You may want an outbound translation on the SRST router to expand 4-digit internal HQ extensions to their 10-digit DIDs, if you want people to dial 4-digit when the WAN is down.  If so, you'd apply a translation profile to the outbound POTS dial-peer for this.

Corey Caruso Thu, 10/07/2010 - 09:16
User Badges:

Thanks Scott,

That is what I thought.  My concern is dialing from HQ if the WAN goes down.  The translation would still be accessible because I am able to hit the CM, the number would be translated to my 6 digits, and fail since the WAN link is down, am I over thinking this?

I see how if I am dialing translating to 6 digits from a remote site...with the WAN link down the remote site would not be able to translate and therefore hit a dial-peer to the PSTN.  I cannot seem to understand what happens when a user dials from HQ when the WAN goes down.....sorry to be a pain.

Thanka again for you help!

Steven Holl Thu, 10/07/2010 - 10:17
User Badges:
  • Cisco Employee,

You would need to have a translation pattern that expands the extension length to a PSTN number to be able to dial to the other site via the PSTN.  Having a CSS with a partition for the translation below the internal extension partition would allow for this to work.

James Hawkins Sat, 10/09/2010 - 07:19
User Badges:
  • Blue, 1500 points or more

Hi Corey,

One solution to your issue of central site users dialling phones at an SRST site during a WAN outage is to set the Call Forward Unregistered value on the directory numbers used by the SRST site phones to the full PSTN number including the outside line access code.

If the WAN goes down the remote phones unregister from CUCM and calls to them are forwarded using the values set for  Call Forward Unregistered


This Discussion