I remember first reading about CUC cluster. If anyone called a port on the second server it automatically become master and all hell broke loose. ????
I’m sure they’ve fixed things by now.
Unfortunately, with us, we’re so swamped, we’re busy playing catchup rather than improving our design. ?
A cluster is definitely on the drawing board. But it’s going to have to wait since “things are working”. ?
From: Charles Goldsmith <w@woka.us>
Sent: Monday, May 4, 2020 4:28 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca>
Cc: 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 IThelp@uoguelph.ca<mailto:IThelp@uoguelph.ca>
The nice thing about CUC vs CUCM, is that while you still have a publisher for CUC, the sub can become master of the application (much like UCCX can, and yes, we still use that acronym a lot) :)
If something happens to your CUC server, you are rebuilding from the DRS. if you had a sub, you wouldn't have to, you can actually tell CUC to rebuild its database from the sub.
Too many companies rely on voicemail and/or call handlers, I cringe when I see a customers setup with a pub/sub setup on CUCM, but they let CUC only have the pub.
CUC is so resilient, that Cisco doesn't even advise you backup the sub. It's not like CUCM in that regard, the pub doesn't backup the sub. Backing up 1 is good enough for the cluster.
If you have another DC, or even another building with servers, do yourself a favor, put in a sub, verify the sip trunk works, etc, then shut down your pub during a maintenance window and verify fail over. After that, forget about it, it will just run nicely. Check your failover (on all of your apps) routinely.
No more worrying about CUE, SRSV or anything else.
Other than server resources (which aren't that bad), it doesn't cost anything. Unlike having something like a CUE module in a router.
Just my $0.03 worth (inflation)
On Mon, May 4, 2020 at 3:11 PM Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@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<mailto:w@woka.us>>
Sent: Monday, May 4, 2020 1:53 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>>
Cc: Eric Pedersen <PedersenE@bennettjones.com<mailto:PedersenE@bennettjones.com>>; voyp list, cisco-voip (cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) <cisco-voip@puck.nether.net<mailto: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 IThelp@uoguelph.ca<mailto:IThelp@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 <lelio@uoguelph.ca<mailto:lelio@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 <PedersenE@bennettjones.com<mailto:PedersenE@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 IThelp@uoguelph.ca<mailto:IThelp@uoguelph.ca>
Yes, from what I remember it can operate while CUCM and CUCX are both up.
From: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@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<mailto:cisco-voip@puck.nether.net>) <cisco-voip@puck.nether.net<mailto: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 <PedersenE@bennettjones.com<mailto:PedersenE@bennettjones.com>>
Sent: Monday, May 4, 2020 11:35 AM
To: Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>>; voyp list, cisco-voip (cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) <cisco-voip@puck.nether.net<mailto: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 IThelp@uoguelph.ca<mailto:IThelp@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-bounces@puck.nether.net<mailto:cisco-voip-bounces@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<mailto:cisco-voip@puck.nether.net>) <cisco-voip@puck.nether.net<mailto: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<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip