[cisco-voip] Cisco moth-balling CUE - Is Connection SRSV the answer?

[Lelio Fulgenzi]

I was thinking about that. But, like I said, CUE covers _all_ scenarios.

I couldn’t make this work at a remote location without compute power and a CUCM subscriber.

Now, if CUCn supported SRST and would run on a UCS-E blade, I’d be happy.

From: UC Penguin <gentoo at ucpenguin.com>
Sent: Monday, May 4, 2020 4:40 PM
To: Lelio Fulgenzi <lelio at uoguelph.ca>
Cc: Charles Goldsmith <w at woka.us>; voyp list, cisco-voip (cisco-voip at puck.nether.net) <cisco-voip at 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 at uoguelph.ca<mailto:IThelp at uoguelph.ca>

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 <lelio at uoguelph.ca<mailto:lelio at 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 at woka.us<mailto:w at woka.us>>
Sent: Monday, May 4, 2020 1:53 PM
To: Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>>
Cc: Eric Pedersen <PedersenE at bennettjones.com<mailto:PedersenE at bennettjones.com>>; voyp list, cisco-voip (cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>) <cisco-voip at puck.nether.net<mailto:cisco-voip at 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 at uoguelph.ca<mailto:IThelp at 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 at uoguelph.ca<mailto:lelio at 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 at bennettjones.com<mailto:PedersenE at 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 at uoguelph.ca<mailto:IThelp at uoguelph.ca>

Yes, from what I remember it can operate while CUCM and CUCX are both up.

From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Monday, May 4, 2020 9:37 AM
To: voyp list, cisco-voip (cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>) <cisco-voip at puck.nether.net<mailto:cisco-voip at 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 at bennettjones.com<mailto:PedersenE at bennettjones.com>>
Sent: Monday, May 4, 2020 11:35 AM
To: Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>>; voyp list, cisco-voip (cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>) <cisco-voip at puck.nether.net<mailto:cisco-voip at 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 at uoguelph.ca<mailto:IThelp at 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 at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> On Behalf Of Lelio Fulgenzi
Sent: Sunday, May 3, 2020 11:38 AM
To: voyp list, cisco-voip (cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>) <cisco-voip at puck.nether.net<mailto:cisco-voip at 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 at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200504/7acc3e9a/attachment.htm>