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,

Mohan

Hi,

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.

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,

Hi,

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.

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,

Mohan

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!

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.

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!

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.

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