Auto-Attendant & Caller System Transfer with #

[Ammar Saood]

I have 2 CUCM clusters. one with 9.x and the other with 12.5. This is a slow migration scenario where customer wants to slowly move users from one cluster to the other while keeping the services running such as IVR, Hunt groups etc.

We have SIP trunk between both clusters. Users want to keep their 4digit (XXXX) extension same as they have in old cluster.  So I created prefix # for dialing the same extension between the clusters. Once user dials #.XXXX the call goes to the neighboring cluster after digit manipulation. So If the user have moved to the new building his phone rings.

Now customer has already used to dialing this way. prefix # if you want to dial users in the other cluster.

Now I have a problem in creating AutoAttendant feature in Unity Connection.

I want if the caller inputs 4-digit XXXX to invoke caller system transfer feature, it should go to Cluster2 and if he dials #XXXX it should go to Cluster1.

Once all users are migrated to 12.5 Cluster we will remove old cluster1 completely.

CUC is not accepting # or * as the first character. How to make CUC dial *7000, #4000 numbers ?

Kindly assist how can I achieve this scenario ?

[Nithin Eluvathingal]

scenario of two clusters, Is this a migration from 9.x to 12.X?

[Ammar Saood]

Hi Nithin,

Yes its migration scenario. Customer have 2 building/towers, and users are slowly moving to the new building which has 12.5 cluster.  They want to try its features such as MRA, jabber, etc. while keeping same extensions.

I want  to know how to have unity accept the *&# prefix in caller system transfer feature.

[Roger Kallberg]

I don't think that you can get CUC to accept these as dial-able characters.

[Nithin Eluvathingal]

Unity Restriction table allowed pattern are mentioned below.Try Adding  a pattern with # and  Blocked unchecked.  but *, I dont think  its  possible. 

Instead of # and * I would suggest to use 01 & 02.(select your pattern)

Pattern

Enter specific numbers or patterns of numbers that can be permitted or restricted. Include external and long-distance access codes. Use digits 0 through 9 and the following special characters: * to match zero or more digits. ? to match exactly one digit. Each ? serves as a placeholder for one digit. # to correspond to the # key on the phone. + to call from one country to other country

[Ammar Saood]

Thanks roger & Nithin,

Other option I am thinking of is to go to the operators extensions XXXX in the old cluster and forward all of their calls (Call forward all) to their extensions in the new cluster #.XXXXX.

In this way, when calls go to the hunt lists in old cluster, for all the users who have moved to the new cluster, I can have their calls forwarded to their new cluster. Its somewhat like SNR to ring their other phone in other cluster.

I hope it works.

Any idea what keyboard mapping does in unity ? would that help ?

[Nithin Eluvathingal]

Call Forward setting on line wont work if the lines are part of Hunt group. Call forwarding to work for Hunt group you need to do the Call forward settings  on Hunt Pilot.

[Roger Kallberg]

Does the user that has moved still have their extension in the old cluster? If they do you could do either one of these to get the call to extend to the new cluster.

• Setup call forward all to #XXXXX on each directory number 
• Or setup Mobile Connect (SNR) for each directory number to send the call to a remote destination number that is #<extension>. For this the reroute CSS on the RDP needs to have visibility of the partition used for the route pattern that sends calls to the new cluster

The easy way would be to use the first option as for it you can use a wild card match for the call forward destination, whereas for the SNR you would need to configure it specifically per extension.

If you don’t have the extensions present in the old cluster it’s even easier, for this you could create a specific partition that is just seen in the CSS that you uses for the inbound direction from CUC to CM. In this partition you create a translation pattern that matches on XXXXX and translates to #XXXXX, aka prefix a #, and sends it out via a CSS that sees the route pattern that sends calls to the new cluster. The important part is that this partition is not visible by others in the old cluster, only CUC sees it in the inbound direction. In the CSS used for CUC you also need to keep the partition(s) used to send calls to directory numbers in the old cluster. What should happen is that the routing logic in CM should have a better match for the numbers that are still present in the old cluster as they are specifically matched and then it should get a sort of last resort match on this wild card match TP. See it like a gateway of last resort sort of thing.

@Nithin Eluvathingal I think the OP meant to write Route List, not Hunt List. Can’t see how a hunt pilot would be of help in this.

[Nithin Eluvathingal]

@Roger Kallberg Based on "In this way, when calls go to the hunt lists in old cluster, for all the users who have moved to the new cluster, I can have their calls forwarded to their new cluster. Its somewhat like SNR to ring their other phone in other cluster." i assume he is planning to send the calls to an hunt pilot and use call forwarding settings on extension Which will fail.

@Ammar Saood SNR will be the best option for your  case.

[Roger Kallberg]

Absolutely, not saying that it would work, however I do think that the OP mistyped that part.

[Ammar Saood]

Hi Roger & Nithin,

Thank you for your valuable support. I found mix of 6 ways to do my scenario after unblocking the # pattern in the restriction table.

Unity Side - Getting # dialing to work.

1. Under Call handler--->Caller Input,  unlocking the # key & setting "call action" to ignore, and increasing the " wait for additional digits" to 2500ms. In this way you can use # in your dialing, giving enough time for users to dial another digits after #.

2. Under Call handler--->Caller Input, using "Digits to prepend" feature. I created a new call handler, and asked the user to select in the beginning, press 1 to old building & press 2 for new tower, If they press1, it goes to new call handler, and whatever extension they type, it gets prefixed with #, and call is routed to the old cluster.

using CUC to handle call forward between clusters.

3. Using 2 call handlers with supervise transfer of 3 rings, When caller inputs a key, the main call handler forwards the call to a secondary call handler (handler2) which has no greetings but to supervise transfer to an extension in Cluster1 XXXX. However, after 3 rings, it reaches its after greeting where it further sends a call to another call handler(handle3) with no greeting, which establishes a supervise transfer to #XXXX extension. so in these 2 call handlers, their post greeting action is to call one another which eventually calls both clusters one by one.

I have not tried this scenario with hunt pilots. however, with phone extensions it works fine. I have attached screenshot of the scenario.

CUCM side

4. Call forward all (CFA) for users who are not part of any Line group or incase above # dialing is not working.

For operators who are the members of line groups, we have 2 options,

5. Using the SNR feature by creating RDP for each migrated user with destination #.XXXX in order to ring the other phone at the same time.

6. Hunt Pilot forward feature, since hunt group overrides the device call forward settings, I can create a timer of 15sec, if call is not answered by any LG member, it should be forwarded to hunt pilot of the other cluster & ring the members there.

Apart from timer, this is same as the system wide preference you have in Route list & Route Groups. If this device is down/busy, try the 2nd one. This option is not so practical, because its a system wide approach not a per user approach.

I believe the practical approach is option 1, 4 & 5.

[Ammar Saood]

Hi Roger & Nithin,

 Thank you for your valuable support. I found mix of 6 ways to do my scenario after unblocking the # pattern in the restriction table.

Unity Side - Getting # dialing to work.

1. 1. Under Call handler--->Caller Input,  unlocking the # key & setting "call action" to ignore, and increasing the " wait for additional digits" to 2500ms. In this way you can use # in your dialing, giving enough time for users to dial another digits after #.
2. 2. Under Call handler--->Caller Input, using "Digits to prepend" feature. I created a new call handler, and asked the user to select in the beginning, press 1 to old building & press 2 for new tower, If they press1, it goes to new call handler, and whatever extension they type, it gets prefixed with #, and call is routed to the old cluster.

using CUC to handle call forward between clusters.

1. Using 2 call handlers with supervise transfer of 3 rings, When caller inputs a key, the main call handler forwards the call to a secondary call handler (handler2) which has no greetings but to supervise transfer to an extension in Cluster1 XXXX. However, after 3 rings, it reaches its after greeting where it further sends a call to another call handler(handle3) with no greeting, which establishes a supervise transfer to #XXXX extension. so in these 2 call handlers, their post greeting action is to call one another which eventually calls both clusters one by one.

I have not tried this scenario with hunt pilots. however, extensions work fine.   

CUCM side

1. 4. Call forward all (CFA) for users who are not part of any Line group or incase above # dialing is not working.

 For operators who are the members of line groups, we have 2 options,

1. Using the SNR feature by creating RDP for each migrated user with destination #.XXXX in order to ring the other phone at the same time.
2. 6. Hunt Pilot forward feature, since hunt group overrides the device call forward settings, I can create a timer of 15sec, if call is not answered by any LG member, it should be forwarded to hunt pilot of the other cluster & ring the members there.

Apart from timer, this is same as the system wide preference you have in Route list & Route Groups. If this device is down/busy, try the 2nd one. This option is not so practical, because its a system wide approach not a per user approach.

I believe the practical approach is option 1, 4 & 5.