[cisco-voip] Best Practice for UC deployments

Brent Pollock hashtagvoip at gmail.com
Fri Mar 22 09:45:53 EDT 2013


As a side note: deployment for many of the new Cisco UC components suggest
using DNS SRV records for integration. Mostly suggested for load balancing,
though this could be accomplished using dedicated load balancer using IP,
there would still be another component included in failure scenario.

Sent from my iPhone

On Mar 19, 2013, at 6:07 PM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:

I think the key thing here is to understand the impact on the telephone
system if DNS services go away and to plan accordingly. DNS is already
providing a critical component of the campus IT service infrastructure, but
tying a DNS failure to a phone system failure likely wont compute on many
levels. If there aren't several layers if redundancy built in to your DNS
solution, this may be the time/reason to suggest it. Minimally, the
management team that owns the service(s) must be aware if the new
dependency. This is most important when planning extended outages in the
DNS service for patching/upgrades/hardware maintenance.

That being said, still not 100% sure on exactly how a DNS outage will
affect service.

We enabled it because of our hope to implement SIP technologies soon which
rely heavily on DNS. However, we were sure to continue using IP addresses
where possible, e.g. server names.

Lelio

Sent from my iPhone...

"There's no place like 127.0.0.1"

On Mar 19, 2013, at 9:51 AM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

The Cisco Voice products have come along way in the last few years and can
do some pretty amazing things. I would think something as basic as DNS
would be trivial for these products.

Perhaps the best practice to remove the DNS dependency is a bit dated.  But
how are we ever going to know how well it performs at large scale and under
heavy load if everyone is adhering to the best practice?  If the product
officially supports it, and Cisco will support your solution, then I say
use it.

On the flip side, this wouldn't be the first documented best practice item
that has gone untouched for years, in which customers are going against the
grain.

E.g.,  In UCCX the default maximum number of executed steps is 1,000, and
we are told to never touch this value.  However, in my experience, this
number is increased in production environments quite often, and thus the
best practice is intentionally ignored.

"The customer should not change the “max number of executed steps”
parameter unless instructed by TAC."
*Source: UCCX 9.0(1) Best
Practices<http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_9_0/reference/guide/UCCX_Best_Practices.pdf>
*

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
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/20130322/bed15ab5/attachment.html>


More information about the cisco-voip mailing list