Fun fact, you can name a sip trunk and an mgcp gateway the same name and it will break mgcp configuration, as the internal lookup for the device config file looks for a config file for the trunk first, will not find it, and then return an error.
On Thu, May 28, 2020 at 2:50 PM Johnson, Tim <[email protected]> wrote: > That bothers me too. I think the only option where that makes sense is for > RGs and RLs because they cannot share the same name. > > > > > > *From:* cisco-voip <[email protected]> *On Behalf Of *Anthony > Holloway > *Sent:* Thursday, May 28, 2020 3:42 PM > *To:* Matthew Loraditch <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5 > > > > Can anyone give a use case where appending or prepending the object type > identifier on the name is helpful? E.g., why put -css on a css at all? > > > > On Thu, May 28, 2020 at 2:19 PM Matthew Loraditch < > [email protected]> wrote: > > > 1. PT-, CSS-, etc > 2. FQDN > 3. My setups are always distributed. Certainly could have central if > it’s one site. > 4. Usually always > 5. SIP, SIP, SIP > 6. Unfortunately no, drives my OCD crazy. I hate lower/mixed case > naming of devices with a passion. I’m also born of a Windows world where > case never mattered. > > > > > > > > *Matthew Loraditch*** > > *Sr. Network Engineer* > > p: *443.541.1518* <443.541.1518> > > w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/> > > | > > e: *[email protected]* <[email protected]> > > [image: Helion Technologies] <http://www.heliontechnologies.com/> > > [image: Facebook] <https://facebook.com/heliontech> > > [image: Twitter] <https://twitter.com/heliontech> > > [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies> > > *From:* Pawlowski, Adam <[email protected]> > *Sent:* Thursday, May 28, 2020 3:08 PM > *To:* James B <[email protected]>; Anthony Holloway < > [email protected]>; Matthew Loraditch < > [email protected]> > *Cc:* [email protected] > *Subject:* RE: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5 > > > > [EXTERNAL] > > > > Sure I can fire this up > > > > 1. part_ , like part_local, part_ld, part_ld_privacy , etc. > 2. FQDN, but, make sure your DNS/NTP/etc works with resiliency. > 3. Depends on if you’re distributed, using hardware conf, transcoder > cause you have some people on some sort of twizzler based connection using > g729, etc > 4. Yes, unless you have something on the other side that can’t handle > these requests coming from the whole group, or again a distributed system. > 5. SIP. MGCP is nice in a set it and forget it way, but if you want to > use the gateway to do anything else like custom intercepts, redirection, > hairpinning, it won’t help you. There are some features that don’t work > when you go to SIP but whatever. > 6. Why would you give anything an upper case hostname > > > > *From:* cisco-voip <[email protected]> *On Behalf Of *James > B > *Sent:* Thursday, May 28, 2020 2:28 PM > *To:* Anthony Holloway <[email protected]>; Matthew > Loraditch <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5 > > > > I was thinking of the community configuration approach Anthony suggested > and was thinking of the debates we’d have if we did that: > > > > 1. Do you use “_PT”, “PT_”, or just the site name? Same for “CSS”, > “LOC”, and the ever-debated “RGN” or “REG”?. > 2. FQDN or IP addresses? > 3. Do all the media resources go into a single MRG or not? > 4. Do we click “Run on all Nodes” for route lists and trunks or not? > 5. MGCP, SIP, or H323 (if using PRIs)? > 6. Can UCCX have upper-case hostnames or not? > > > > The debates would take us so long, version 14.0 would be out, and then > we’d have to debate about whether a “.0” versoin is stable or not or should > we wait for “.5”? Still, could be fun! > > > > > > > > *From: *Anthony Holloway <[email protected]> > *Sent: *28 May 2020 19:15 > *To: *Matthew Loraditch <[email protected]> > *Cc: *[email protected] > *Subject: *Re: [cisco-voip] Migration from CUCM/UCXN/UCCX 8.5 to 12.5 > > > > Keep in mind that PCD network migrations, while awesome for CUCM, do not > work for other products. > > > > Typically with a project like this, you'll likely have a different > approach for each app, and not a one size fits all solution. > > > > With the app upgrades, you will also have to change OVA sizes (or want to > in some cases), and at that point, it might be better to install fresh, and > use tools like COBRAS, BAT, AXL, ADMIN API, stare & compare, etc. to get > data exported/imported from old to new. > > > > Or like Kent said, tell yourself it's a toshiba system, and treat it like > a greenfield. > > > > On Thu, May 28, 2020 at 11:26 AM Matthew Loraditch < > [email protected]> wrote: > > Here’s a fun one. We have taken over support of these ancient servers > hosted on Esxi 4.1 on UCS-C200-M2s! > > > > Exact Versions are: > > 8.5 SU2 for CUCM/UCXN > > 8.5 FCS for UCCX > > > > Each is a pair of servers. > > > > Have new M5s and flex licensing… need to get to 12.5.. 8.5 docs are dead > for CUCM/UCXN and 8 and 9 docs are dead for UCCX. ISOs I may need are not > available publicly. > > > > Also fun wrinkle the new host are across the WAN and for many logistical > reasons are staying there. The migration to the new hosts will have to be > via DRS or maybe PCD somehow? Not sure if the bandwidth available to get > data across will be fast enough to finish in the allotted time period. My > plan was a change freeze window and copy/restore the backups and then > activate the new servers and move the subnet to the new location. > > > > As best I can tell I need to get UCCX to SU4 of 8.5.1 then I can go to > 10.6 SU3 and then to 12x (with the fun of two CAD upgrades and then a > migration to Finesse!) > > > > For CUCM/UCXN I need to go to 8.6 anything and then I can go to 11.5 and > then to 12x > > > > I think my plan is to do the upgrades to the interim versions on the old > hosts then migrate to the new and then finish the upgrades. The old hosts > will need ESXi upgrades to an interim version. > > > > Anyone have thoughts on what they would do here? This is partially > depending on TAC being able to provide me the ISOs I will need, but I > presume there is an archive. > > > > In theory some sort of PCD migration is also an option, but I’ve never > done one and not sure how it could handle the subnet situation that will > have to exist. > > > > Welcome to my fun life! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Matthew Loraditch*** > > *Sr. Network Engineer* > > p: *443.541.1518* <443.541.1518> > > w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/> > > | > > e: *[email protected]* <[email protected]> > > [image: Helion Technologies] <http://www.heliontechnologies.com/> > > [image: Facebook] <https://facebook.com/heliontech> > > [image: Twitter] <https://twitter.com/heliontech> > > [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies> > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > > > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
