Right Sizing your Network for OCS R2
In order to understand bandwidth requirements for OCS it’s important to first model expected usage and right provisioning the network. You will also have to manage usage and grow in line with your business needs. Bottom line – Measure Well!!
Bandwidth Requirements
OCS uses both RTAudio narrowband and wideband. Narrowband is used for UC <=> PSTN calls and wideband for all other calls. Wideband has a richer sound to the call and more user friendly with a higher sampling at 16kHz. The payload increases to a little over double but the real information that is needed is the full payload rate with IP+UDP+RTP+SRTP to find out how much bandwidth is needed. Also important in sizing is to understand that these are one-way numbers and that silent suppression saves on bandwidth. If you aren’t talking then the bits are less. As well as the dynamic changes of the packetization. If there is packet loss Forward Error Correction (FEC) is turned on to essentially double the packets. But for understanding the bandwidth the below chart will help us get some fairly accurate data.
2 party calls
For calls going to and from San Francisco from New York. We use the following datapoints
50% of the time User A talks (from SF) and 50% of the time User B talks (from NY). The stream is 50kpbs but since it’s only half the time the average bandwidth is 25kbps. We can then extrapolate this to more users.
Total BW SF to NY = N x 25kbps (N is concurrent Calls)
Total BW NY to SF = N x 25kbps
Beyond 2 party calls
If we look at the SF Office as the datacenter with the OCS Pool and the NY Office available via WAN link. We can examine bandwidth further with 750 users in SF and 250 users in NY.
First we need to know what the Peak call concurrency is. In the below example it’s 5%. This gives us 25 calls and .9 Answered:unanswered calls to give us 22.5 answered calls. We have .55Mbps of audio in each direction with Video BW of 1.37Mbps.
Conferencing is also modeled below. Conferencing is very different then 2 party calling in that all traffic is directed to the MCU, only one speaker is typically speaking, some may or may not include video conferencing.
Recap
These are busy hour peak bandwidth numbers. 2 party calls are symmetric but conferencing calls are asymmetric. Video BW is always greater than audio bandwidth.
Any model you choose is dependent on assumptions. Consider your intra-office calling patterns. How many calls, conferences do I have in between sites? Also do we have potential outliers – Superintendent wants an all hands audio/video conference. This will obviously skew our bandwidth model.
Published Monday, April 13, 2009 10:59 AM by gkatz
.jpg)
No comments:
Post a Comment