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

[Charles Goldsmith]

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 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>
> *Sent:* Monday, May 4, 2020 1:53 PM
> *To:* Lelio Fulgenzi <lelio at uoguelph.ca>
> *Cc:* Eric Pedersen <PedersenE at bennettjones.com>; 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
>
>
>
> 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> 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>
> 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
>
>
>
> 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> *On Behalf Of *Lelio
> Fulgenzi
> *Sent:* Monday, May 4, 2020 9:37 AM
> *To:* 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?
>
>
>
> 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>
> *Sent:* Monday, May 4, 2020 11:35 AM
> *To:* Lelio Fulgenzi <lelio at uoguelph.ca>; voyp list, cisco-voip (
> cisco-voip at puck.nether.net) <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
>
>
>
> 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> *On Behalf Of *Lelio
> Fulgenzi
> *Sent:* Sunday, May 3, 2020 11:38 AM
> *To:* voyp list, cisco-voip (cisco-voip at puck.nether.net) <
> 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
> 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/ba31d084/attachment.htm>