If AA is that critical you could always standup a CUC server that only handles AA as a backup. There wouldn’t be a license impact with PLM/Smart Licensing as you don’t need any users.
> On May 4, 2020, at 15:13, Lelio Fulgenzi <le...@uoguelph.ca> wrote: > > > All valid questions. No offense taken. Unless of course, you complain about > me primarily using the @ macro plus route filters in all my route patterns. > Then, them’s fighting words. 😉 > > The great thing about CUE was that it covered all scenarios with one > solution. Every other scenario will need at least another fall-back meaning > two solutions. I did this in my head a while back, never got it down on paper. > > While I can appreciate the idea of a UNTCNXN cluster (is that the right > acronym Anthony?), I’m not sold that there will never be a scenario where the > second node will always work during whatever maintenance we’re planning. I’ve > read document after document after scenario after scenario and have found we > always seem to fit in that one exception to the rule for whatever reason. > > I’m not saying that we won’t eventually move to a CUXN cluster (we’re not > there yet) – but I was hoping to have a bit more time to delve into a proper > design of both what the cluster can and can’t give us and what options we > have for fall-back. > > Let’s say, for whatever reason, a database corruption is replicated across > the cluster. Then what? What do I do? I have to restore services from backup, > rebuild the cluster, etc. All the while, having an unreliable AA going around > because SRSV is trying to connect? (again, I don’t know the ins and outs of > SRSV and CNXN clusters). > > Having CUE available let me sleep at night and gave me a quick get out of > jail free card I could use for almost any maintenance requirement, including > those outside my control. > > > > From: Charles Goldsmith <w...@woka.us> > Sent: Monday, May 4, 2020 1:53 PM > To: Lelio Fulgenzi <le...@uoguelph.ca> > Cc: Eric Pedersen <peders...@bennettjones.com>; voyp list, cisco-voip > (cisco-voip@puck.nether.net) <cisco-voip@puck.nether.net> > Subject: Re: [cisco-voip] Cisco moth-balling CUE - Is Connection SRSV the > answer? > > CAUTION: This email originated from outside of the University of Guelph. Do > not click links or open attachments unless you recognize the sender and know > the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca > > Lelio, just curious why you would have scheduled downtime for the entire CUC > cluster? I can appreciate downtime for a node for maintenance, but even > during an upgrade, your cluster should be up, one node or the other. > > If it's more DC / network outage, why not have the 2nd node of your CUC > cluster where ever you have your CUE for "backup". > > No offense intended on your design, just wanting to know and possibly learn > if it's something I'm overlooking. > > Thanks > > > On Mon, May 4, 2020 at 12:48 PM Lelio Fulgenzi <le...@uoguelph.ca> wrote: > > Ok. Thanks. This might work. > > What I’m hoping to be able to do is to manually redirect calls from > Connection to SRSV (for AA and voicemail) and still allow calls to be > transferred accordingly to phones registered to CUCM, not SRST. > > This was easily done with CUE, since it would register to both CUCM and SRST. > > If SRSV has similar functionality, we’re golden. > > Sent from my iPhone > > > On May 4, 2020, at 1:43 PM, Eric Pedersen <peders...@bennettjones.com> wrote: > > > CAUTION: This email originated from outside of the University of Guelph. Do > not click links or open attachments unless you recognize the sender and know > the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca > > Yes, from what I remember it can operate while CUCM and CUCX are both up. > > From: cisco-voip <cisco-voip-boun...@puck.nether.net> On Behalf Of Lelio > Fulgenzi > Sent: Monday, May 4, 2020 9:37 AM > To: voyp list, cisco-voip (cisco-voip@puck.nether.net) > <cisco-voip@puck.nether.net> > Subject: Re: [cisco-voip] Cisco moth-balling CUE - Is Connection SRSV the > answer? > > Do you know if SRSV can operate while CUCM is up? > > The great thing about CUE, is that it operated while CUCM was up. Completely > independent of Unity Connection. > > This means, I could schedule downtime for Connection and have an almost fully > operational AA working. > > From: Eric Pedersen <peders...@bennettjones.com> > Sent: Monday, May 4, 2020 11:35 AM > To: Lelio Fulgenzi <le...@uoguelph.ca>; voyp list, cisco-voip > (cisco-voip@puck.nether.net) <cisco-voip@puck.nether.net> > Subject: RE: Cisco moth-balling CUE - Is Connection SRSV the answer? > > CAUTION: This email originated from outside of the University of Guelph. Do > not click links or open attachments unless you recognize the sender and know > the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca > > I used SRSV a while ago for one of our remote sites. I found it much simpler > to get up and running than CUE and you can use your centralized Exchange. > IIRC you can send your voicemail pilot back to the gateway SRSV is registered > to so all calls go to it. But it's been a really long time… > > From: cisco-voip <cisco-voip-boun...@puck.nether.net> On Behalf Of Lelio > Fulgenzi > Sent: Sunday, May 3, 2020 11:38 AM > To: voyp list, cisco-voip (cisco-voip@puck.nether.net) > <cisco-voip@puck.nether.net> > Subject: [cisco-voip] Cisco moth-balling CUE - Is Connection SRSV the answer? > > > Looks like Cisco is moth-balling CUE. I liked that product. I’ll miss it. > > It looks like Connection SRSV is the answer. Although I’m not sure it will > offer everything we used (and planned to use) CUE for. For example, our > voicemail ports forwarded to CUE which was always registered to CUCM. This > way, calls would continue to work. It’s looking like SRSV will only work if > the router is in SRST mode and all phones are registered to SRST. > > Has anyone successfully deployed SRSV? How about using it during voicemail > maintenance? > > Lelio > > > > Bennett Jones is committed to mitigating the spread of COVID-19. We have > transitioned to a remote work environment and continue to provide complete > and uninterrupted service to our clients. Visit our COVID-19 Resource Centre > (https://www.bennettjones.com/COVID-19) for timely legal updates. > > The contents of this message may contain confidential and/or privileged > subject matter. If this message has been received in error, please contact > the sender and delete all copies. Like other forms of communication, e-mail > communications may be vulnerable to interception by unauthorized parties. If > you do not wish us to communicate with you by e-mail, please notify us at > your earliest convenience. In the absence of such notification, your consent > is assumed. Should you choose to allow us to communicate by e-mail, we will > not take any additional security measures (such as encryption) unless > specifically requested. > > If you no longer wish to receive commercial messages, you can unsubscribe by > accessing this link: http://www.bennettjones.com/unsubscribe > > > Bennett Jones is committed to mitigating the spread of COVID-19. We have > transitioned to a remote work environment and continue to provide complete > and uninterrupted service to our clients. Visit our COVID-19 Resource Centre > (https://www.bennettjones.com/COVID-19) for timely legal updates. > > The contents of this message may contain confidential and/or privileged > subject matter. If this message has been received in error, please contact > the sender and delete all copies. Like other forms of communication, e-mail > communications may be vulnerable to interception by unauthorized parties. If > you do not wish us to communicate with you by e-mail, please notify us at > your earliest convenience. In the absence of such notification, your consent > is assumed. Should you choose to allow us to communicate by e-mail, we will > not take any additional security measures (such as encryption) unless > specifically requested. > > If you no longer wish to receive commercial messages, you can unsubscribe by > accessing this link: http://www.bennettjones.com/unsubscribe > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
