CUCM v 8 TAPS

[ryan_oconnell]

It’s been over 3 years since I last used TAPS for deployment of phones, I’m struggling to remember whether or not the phones imported into the CUCM database with Dummy Mac’s become part of your dial-plan from the moment they are put in with the Dummy Mac’s or are they only dial able after someone goes through the TAPS process. Hopefully it’s the latter, I’m dealing with a messy move and I’m hoping I can put all the phones into the CUCM database first and then the number’s become routable only after the TAPS process. Meaning I don't want calls being routed to the DUMMY Phones "unregistered cfwd" setting

Ryan

[phooghen · Accepted solution]

As soon as you use BAT to upload the DNs with a dummy MAC address, those DNs become part of the dial plan (and are dialable).

The new phones will auto register with CUCM (auto registration DN range).

Then each user will auto dial (PLAR) the TAPS CTI RP and will get their new DN.

[ryan_oconnell]

Thanks Phooghen for your prompt reply, I do have a follow-up question.

First some background:

I  have a CUCM cluster tied into a Legacy Nortel PBX using non-QSIG PRI  trunks. The Nortel Option 61c is using CDP codes to direct 4 digit  numbers accross the trunk. We are moving droves of users from the Nortel  PBX to CUCM in no particular order. We don't have the flexibility of  porting contiguous banks of DN's over the trunk and the users will be  migrated in smaller groups as the new facility becomes available.

What I would like to do  is have all the new phones setup before users are moved over. That  being said, there will be a transition period where numbers need to continue to be passed from CUCM over the trunk to the Nortel system.

What  I like about TAPS is it allows me to pre-configure all the phones and  provides a simple Migration for the user. When the user has to move to  the new system they simply dial into the IVR and the phone gets  configured. The second part of this would be their old Nortel phone will  need to be removed and a CDP route setup to their 4 digit number so  that people still on the nortel PBX can route calls over trunk to their  new phones

So if the numbers for the dummy MAC phones  become routeable as soon as they are added to the database. I should be  able you use the CFWD "Unregistered" to go to a route Pattern pointing  out the Nortel trunk. After everyone is transitioned to the CUCM I could  then run a BAT Update Lines, to change teh "CFWD Unregistered" to point  to Voicemail instead.

This should work right?

Ryan

[phooghen]

Ryan,

The CFWD Unregistered is the way to go.

You can also on top of it configure a Route pattern to summarize all Nortel DNs like 4XXX to point to the Nortel trunk.

Pierre.

[iptuser55]

Ryan

Following on another way is

VNR

Ask your Nortel guy to check if VNR is set up on the Nortel if not ask them to set it up and check what packages you need. VNR is similar to a blanket Route Pattern in CUCM 4xxx . In Nortel you have to set up CDP for each DN which is on the CUCM you cna not do a 4xxx type set up however with VNR you set up a Route to CUCM so that if a DN does not exist on the Nortel then send it across to the CUCM. When you migrate  a  user from Nortel to CUCM you now only have to delete the DN in Nortel - the call will by default be sent to the CUCM via VNR

Use of Partitions

When you use TAPS to add the DN/ Phone then you  could add the DN in a dummy Partition can then change the parttion when  you do the cut over. Create Partitions called  15th_Feb_cut_over, 22nd_Partition_cut_over and so on for each cut over week. Add the DN`s and assign the correct cut over partition to each DN.

When you carry out a mirgation then run BAT and do a query based upon the Partition of the cut over and then "swap" over to your correct partition.

This way is easier then the CFNotReg as you would have to identify each DN  and manually  change the setting but if you do the partition method then the majority or all of the DN`s can be captured via the "15th_Feb_cut_over partition and then run a single BAT to change their partition to your correct one

Obviously this relies on you knowing what user is being migrated and on what weekend at the time of doing the TAP`s work

[ryan_oconnell]

Hello iptuser55,

VNR

Great feedback, I have used VNR in the past for Nortel migrations, I already check with them and unfortunatly they do not have the packages installed to support VNR, these are very old PBX's I'm stuck with CDP.

Use Of Partitions

Agreed this is another alternative, but I'm not sure I agree with this method being "Way" eaiser. Again its been a while since I used TAPS, but he way I see it is that I have to BAT the phone in initially for use with TAPS with the correct DN's and applicable line settings setting the "CFNotReg" flag to be the "DN" of each phone to me is just another column in the BAT spreadsheet. (well at least I hope it is, I haven't actually checked to see if this field can be set in the spreedsheet yet). This method I only have to import all the phones one time, and when the whole migration is complete i can then do 1 batch update to change the CFNotReg field back to Voicemail.

Am I missing something?

Cheers Ryan

[iptuser55]

Ryan

If depends on the approach - Big Bang or Staged

Pre- work Need to  make sure the CF CSS is  correct for routing to the Nortel

Big Bang

Just run a BAT and change the CFNR to VoiceMail -

Staged

Upload the Phones as before allocate the different partition migrations

• Using CFNR - My thinking is that if you BAT change the CFNR setting then you need to know the DN`s of every CFNR you wish to change and run a BAT  against each one DN 1234, DN 3412 DN 1237 etc .

• Change of Partition- On the weekend of Migration -Run BAT  search for Partition 15th_Feb_cut_over and swap out for "Internal_Partition"

Weekend 2

Repeat as above except search for 22nd-Feb_Cut_Over

We use this method as not all our users have voice mail , some forward to hunt groups , other users etc and we have staged migrations

it all to do with the customers own set up - both work just as well, its just how you do the migration