02-07-2014 11:33 AM - edited 03-16-2019 09:39 PM
Dears,
We are moving from old telephony to IP Telephony, just we are in a design phase so need to worry for each and everything.
I want to know the below information as per the cisco standard,
02-07-2014 12:02 PM
You would need to get data from your actual system to determine how many PRIs you'll need. That's the best way to accurately size.
The SRND discusses how much BW for ICCS and DB replication is required and the formulas to calculate if not using the proposed scenario.
HTH
java
if this helps, please rate
www.cisco.com/go/pdihelpdesk
02-07-2014 12:09 PM
PRI Info:
For sizing you will need the Erlang-B calculator http://www.erlang.com/calculator/
WAN Design Info:
The round-trip time (RTT) must not exceed the currently supported limit of 80 ms for clustering over the WAN. To calculate the necessary bandwidth for CTI traffic, use the formula in the section on Local Failover Deployment Model. Note that this bandwidth is in addition to the Intra-Cluster Communication Signaling (ICCS) bandwidth calculated as described in the section on Local Failover Deployment Model, as well as any bandwidth required for audio (RTP traffic).
For clustering over the WAN to be successful, you must carefully plan, design, and implement various characteristics of the WAN itself. The Intra-Cluster Communication Signaling (ICCS) between Unified CM servers consists of many traffic types. The ICCS traffic types are classified as either priority or best-effort. Priority ICCS traffic is marked with IP Precedence 3 (DSCP 24 or PHB CS3). The following design guidelines apply to the indicated WAN characteristics:
•Delay
The maximum one-way delay between any two Unified CM servers should not exceed 40 msec, or 80 msec round-trip time. Measuring the delay is covered in Delay Testing. Propagation delay between two sites introduces 6 microseconds per kilometer without any other network delays being considered. This equates to a theoretical maximum distance of approximately 3000 km for 20 ms delay or approximately 1860 miles. These distances are provided only as relative guidelines and in reality will be shorter due to other delay incurred within the network.
•Jitter
Jitter is the varying delay that packets incur through the network due to processing, queue, buffer, congestion, or path variation delay. Jitter for the IP Precedence 3 ICCS traffic must be minimized using Quality of Service (QoS) features.
•Packet loss and errors
The network should be engineered to provide sufficient prioritized bandwidth for all ICCS traffic, especially the priority ICCS traffic. Standard QoS mechanisms must be implemented to avoid congestion and packet loss. If packets are lost due to line errors or other "real world" conditions, the ICCS packet will be retransmitted because it uses the TCP protocol for reliable transmission. The retransmission might result in a call being delayed during setup, disconnect (teardown), or other supplementary services during the call. Some packet loss conditions could result in a lost call, but this scenario should be no more likely than errors occurring on a T1 or E1, which affect calls via a trunk to the PSTN/ISDN.
•Bandwidth
Provision the correct amount of bandwidth between each server for the expected call volume, type of devices, and number of devices. This bandwidth is in addition to any other bandwidth for other applications sharing the network, including voice and video traffic between the sites. The bandwidth provisioned must have QoS enabled to provide the prioritization and scheduling for the different classes of traffic. The general rule of thumb for bandwidth is to over-provision and under-subscribe.
•Quality of Service
The network infrastructure relies on QoS engineering to provide consistent and predictable end-to-end levels of service for traffic. Neither QoS nor bandwidth alone is the solution; rather, QoS-enabled bandwidth must be engineered into the network infrastructure.
In general, intra-cluster communications means all traffic between servers. There is also a real-time protocol called Intra-Cluster Communication Signaling (ICCS), which provides the communications with the Cisco CallManager Service process that is at the heart of the call processing in each server or node within the cluster.
The intra-cluster traffic between the servers consists of the following:
•Database traffic from the IBM Informix Dynamic Server (IDS) database that provides the main configuration information. The IDS traffic may be re-prioritized in line with Cisco QoS recommendations to a higher priority data service (for example, IP Precedence 1 if required by the particular business needs). An example of this is extensive use of Extension Mobility, which relies on IDS database configuration.
•ICCS real-time traffic, which consists of signaling, call admission control, and other information regarding calls as they are initiated and completed.
HTH
Regards,
Yosh
02-07-2014 02:30 PM
thanks jaime and yosh
Accoding to the link what the below digit "3" stand for , I hope it is a 3 minutes
Consider two sites, Site 1 and Site 2, with Unified CM clustered over the WAN across these two sites
that are 80 ms round-trip time apart. Site 1 has one publisher, one combined TFTP and music on hold
(MoH) server, and two Unified CM subscriber servers. Site 2 has one TFTP/MoH server and two
Unified CM subscriber servers. Site 1 has 5000 phones, each having one DN; and Site 2 has 5000
phones, each having one DN. During the busy hour, 2500 phones in Site 1 call 2500 phones in Site 2,
each at 3 BHCA. During that same busy hour, 2500 phones in Site 2 also call 2500 phones in Site 1, each
at 3 BHCA. In this case:
Total BHCA during the busy hour = 2500*3 + 2500*3 = 15,000
Thanks
02-07-2014 02:34 PM
http://en.wikipedia.org/wiki/Busy-hour_call_attempts
HTH
java
if this helps, please rate
www.cisco.com/go/pdihelpdesk
02-08-2014 03:21 AM
On your PRI requirements, how many e1 channels were in use on the old solution. The key to sizing E1s is not just the total number of users but how many concurrent calls they make and receive. I have a customer with about 5,000 users and they make about 300 concurrent calls.
So look at the history on the old system , speak to the customer and get a realistic figure.
NB: Customer will tell you that they make 1000 concurrent calls..Just tell them that the cost of their solution will be multiplied by a thousand times and they will give you a realistic figure...my 2 cents
Please rate all useful posts
"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
02-08-2014 02:27 PM
Dear Aokanlawon,
Thanks for the reply as things cleared for me from PSTN end,
Need to go more deeper for site to site bandwidth calculation can you provide me a good explanation link considering a codec in mind for the calculation of WAN bandwidth, if i am not wrong all it depennds on codec when a question of WAN bandwith comes.
Thanks
02-09-2014 07:58 PM
Hi Adam,
For deployment over the wan, you must consider the bandwidth provisioning.
See this great guidance (Cisco Collaboration SRND)
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab09/netstruc.html#wp1165070
Three key for achieve good voice quality over the wan :
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide