cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
387
Views
0
Helpful
2
Replies

Calling Seach Space / Partition routing with Call Park DN's

matthubach
Level 1
Level 1

I am having some issues with Calling Search Spaces.

Here is what I have done. I had a set of call park numbers:

5553X in PT-All-Lines
5554x in PT-All-Lines

However, we use a 10 digit dial plan. Because there is known issue with creating call park numbers that are 10 digits (must be 9 or less), I have to use something less than 10. No problem.

https://tools.cisco.com/bugsearch/bug/CSCuh26505/?reffering_site=dumpcr

So, because 5553X and 5554x were in the All-Lines PT, that overlapped with some other routing rules causing the inter-digit timeout. No Problem.

I moved the call park numbers  into their own PT.

5553X in PT-Call-Park
5554x in PT-Call-Park

I then created a Calling Search CSS-Call-Park that has the PT-Call-Park partition.

I then created a translation pattern 555[34]X in the PT-All-Lines partition, using CSS-Call-Park calling search space and am using "Urgent Priority" on the XLATE pattern. This is  where the problems begin.

My Phones CSS has access to PT-All-Lines. I generate a call, make an attempt to park the call, but get the message that there are no call park numbers available. For testing, I assigned a second DN to a phone, 55549 ( in that call park range) in the PT-Call-Park partition. When I dail 55549 from another phone, my phone rings. So it is obviously hitting the XLATE pattern and working without any interdigit timeout period.

So from here, I add the PT-Call-Park partition to my phones CSS. Well, that works. I can now park the call. However, this is not an ideal workaround for us. But, when I go to pick up the call, the call is parked on 55540, I dial 55540 and now it waits for the interdigit timeout to expire. It doesnt appear to be hitting the XLATE pattern (I do have the  PT-Call-Park as the first PT in the LINE CSS, so it def should be matching on the XLATE pattern.). Assuming its seeing an exact match with 55540 being an available number in a PT my phones CSS's has access to.

Regardless, am I misunderstanding how CSS's work? A bug? I had this same issue with an inbound CSS on a SIPT between 2 clusters. In that scenario, I was able to add the  PT-All-Lines to the CSS on the trunk.  I didnt like doing that, but Cisco did not have an answer. In this scenario, I  do not want to add the PT-Call-Park to my phones CSS. It doesnt really work anyway with the interdigit timeout kicking in.

Any ideas?

2 Replies 2

Weird situation. Currently do not have where to duplicate your setup. However If you post detailed ccm traces I can take a look at those and tell you what happens.

For anyone who comes across this post. I was trying to direct the call park process, to a call park DN through a translation pattern (needed urgent priority). However, when the softkey button is pressed from the phone, it looks in the "call park" area of the database and no routing/translating/etc ever happens during a call park. Just FYI. I ended  up using a different set up call park DN's to accommodate my customer.
 

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: