[cisco-voip] Migration strategy

秀王 kiwi.voice at gmail.com
Wed Mar 18 11:22:06 EDT 2015


hi guys, thanks! gonna try them in the lab first to figure out if i can put
the device profile in the production partition.

On Wed, Mar 18, 2015 at 8:58 PM, Rob Dawson <rdawson at force3.com> wrote:

>    This is the way I handle scenarios like this as well – create a
> temporary partition for the DNs, etc. and use BAT to bulk edit them when it
> is time to move to production. Having the profiles exposed shouldn’t cause
> any issues as long as the DNs are hidden.
>
>
>
> Rob
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Ryan Huff
> *Sent:* Wednesday, March 18, 2015 8:06 AM
> *To:* kiwi.voice at gmail.com
> *Cc:* cisco-voip at puck.nether.net
>
> *Subject:* Re: [cisco-voip] Migration strategy
>
>
>
> Any elements that you are going to pre-stage that are a part of the dial
> plan (translations, route patterns, DNs, transformations ...etc) wilk all
> need to be isolated from your currently migrated phones.
>
> So the DNs on your device profiles would likely need to be in an isolated
> partition, but the device profile itself probably doesn't need to be in an
> isolated device pool.
>
> If you do this, remember to use a CLLI or some unique descriptor in the
> description field of all your pre-staged elements, it will make it very
> easy for BAT to find things later on.
>
> Thanks,
>
> Ryan
>
>
>
> -------- Original Message --------
> From: 秀王 <kiwi.voice at gmail.com>
> Sent: Tuesday, March 17, 2015 11:32 PM
> To: Ryan Huff <ryanhuff at outlook.com>
> Subject: Re: [cisco-voip] Migration strategy
> CC: cisco-voip at puck.nether.net
>
> Hi Ryan,
>
>
>
> let's say my phones are on a temp partition not reachable by other CSS. My
> UDP (user device profile) are on a valid partition shared by others ( Ie.
> P_Internal) but they are not logged in anywhere.
>
> Will this confused the CUCM? Or i shall place the UDP on temp partition as
> well. If so, can BAT assist me in migrating from TEMP partition to actual
> partition (P_Internal)?
>
> Cheers,
>
> Ki Wi
>
>
>
> On Wed, Mar 18, 2015 at 9:26 AM, Ryan Huff <ryanhuff at outlook.com> wrote:
>
> I'm not, sure I completely understand your questions but I'll attempt to
> answer based on my understanding.
>
> Yes, you can pre-config devices and users in CCM prior to migration. If
> they are Cisco IP phones, you'll need the MAC address and model of the
> phone at a minimum.
>
> If they are non Cisco IP phones, you'll need to pre configure 3rd party
> sip devices (which is a different license requirement than a Cisco IP
> phone).
>
> Place the preconfigured dial plan that isnt migrated yet (on CCM), in a
> temp. partition that the already migrated phones cannot access. As you
> migrate, change that partition using BAT, to the correct partition for the
> portion of phones you migrated.
>
> Thanks,
>
> Ryan
>
>
>
> -------- Original Message --------
> From: 秀王 <kiwi.voice at gmail.com>
> Sent: Tuesday, March 17, 2015 09:15 PM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] Migration strategy
>
> Currently the client have avaya and cisco linked together using SIP.
>
> Cisco UCM cluster have users in the production environment.
>
> I'm are going to cutover more sites from avaya to cisco. Is it possible to
> preconfigure the users, extension number (let's say 87XXX range), phones
> and the user device profiles in advance?
>
>
>
> I'm thinking that if I preconfigure those information, the cucm will think
> that those extension number (87XXX) are local and unregistered.
>
> Is there a way to make CUCM thinks that in order to reach 87XXX range, it
> will still reach out to Avaya using the SIP trunk? Is there any setting in
> the route pattern can do that?
>
> I thinking that CUCM will always find a more "exact" match locally instead
> of through other source like translation pattern or route pattern.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150318/4e7c73f3/attachment.html>


More information about the cisco-voip mailing list