Planning and calculating bandwidth

The bandwidth required depends on the data streams active at the same time on each network connection. Agent and call counts alone are not enough: telephony, control messages, speech services and files may take different paths. Plan sending and receiving separately.

This guide distinguishes payload that can be calculated from the product code from additional protocol overhead and values that must be measured in your installation. It does not specify a fixed minimum bandwidth per agent.

Identify connections

The Server is not automatically the path for all audio data. Count only streams that actually cross the connection you are sizing. See also Ports and connections.

General calculation

For a transfer of D bytes in T seconds:

Payload rate in bit/s = D × 8 / T
Payload rate in Mbit/s = D × 8 / T / 1,000,000

For ongoing operation, add the rates of all simultaneously active streams. Then account for measured protocol overhead, load peaks and your operating reserve. The examples use decimal units: 1 kbit/s = 1,000 bit/s and 1 MB = 1,000,000 bytes.

Telephony and SIP media

The SIP endpoint enables codecs including G.722, PCMA, PCMU, iLBC, Speex and GSM with different priorities. The actual selection is negotiated with the other endpoint. Codec priority therefore does not determine a fixed bandwidth for all calls. The clock rate in a codec name, such as G722/16000, is also not a data rate in bit/s.

For an audio stream with a constant packet interval:

Packets per second = 1,000 / packet interval in ms
Rate per direction = codec payload rate
                     + additional bytes per packet × 8 × packets per second

Determine the codec, packet interval and additional bytes from the actual connection. Include network, security and tunnel protocols as well as additional control packets at the measurement point under consideration. Do not assume a flat saving from pauses in speech: silence detection is an endpoint parameter, not a guaranteed reduction.

Example using assumed measurements: a 64 kbit/s payload, a 20 ms packet interval and 40 additional bytes per packet give 64,000 + 40 × 8 × 50 = 80,000 bit/s per direction. Ten such streams crossing the connection simultaneously give 0.8 Mbit/s per direction, before other traffic and reserve. These are example assumptions, not fixed values for every myContactCenter connection.

For consultation calls, conferences, monitoring and translation, count the additional media streams actually active. Do not multiply every call by a fixed number of lines without checking the paths.

When an audio stream ends, the SIP code logs the codec, destination, packets and bytes sent and received, and loss and round-trip values. The byte counters are not a guaranteed measurement of every byte on your WAN link. To determine the full network load, also measure the relevant network path.

PCM audio and speech services

The conference bridge calculates its PCM data volume from the clock rate, channel count and bytes per sample. Speech recognition uses these values for its PCM input stream:

PCM bytes per second = sample rate × channel count × bits per sample / 8
PCM bit/s = sample rate × channel count × bits per sample

The SIP endpoint sets its channel count to 1; other audio processing may use a different format. Check the actual bridge and file parameters. The PCM calculation describes the payload passed to the speech client. It does not guarantee the complete Internet data rate of the SDK used: protocol overhead, buffering and additional input or output streams must be considered separately.

Agent, Administration and wallboards

Product messages are serialized. The message header occupies 7 bytes; payloads of 1,000 bytes or less are sent uncompressed by this serializer, while larger payloads are compressed. A constant size per message is therefore not useful.

Message payload rate = messages per second
                       × average actual transmitted message size
                       × 8

Serialization logs include the size after serialization or compression, already including the message header. Do not add the 7 bytes again. Transport protocols and any retransmissions add to the network load.

Measure login and reconnection separately from normal operation. A large list or many agents logging in simultaneously creates a different demand from state changes alone. For wallboards, volume and peaks depend on the design, data sources and updates. The code does not define a general minimum bandwidth per workstation for these functions.

Files and recordings

For files, use the general calculation with the desired transfer time. 10 MB in 5 seconds requires a calculated payload rate of 16 Mbit/s. Simultaneous transfers add up.

For PCM-WAV, calculate the audio volume from format and duration as above; container data adds to it. The MP3 conversion helper defaults to 64 kbit/s, forces mono and sets a target sample rate of 16,000 Hz. When this exact conversion is used, one minute at 64 kbit/s gives about 0.48 MB of audio payload. This does not mean that all recordings already exist as MP3 files with these settings.

For email attachments, use the size of the transmitted message, not just the original file. If an attachment is sent using Base64, encoding increases the payload by approximately a factor of 4/3; line breaks and message headers add to it. Plan database queries, reports and backups according to their actual volume.

Verify the plan

1. Map the network paths and record the expected simultaneous use of each function.
2. Calculate audio and file payloads. Measure variable message and database volumes for the intended usage profile.
3. Check each direction on each connection. Avoid counting streams twice or counting data that remains local.
4. Test peaks: login, conferences, file retrieval and other enabled functions at the same time.
5. Plan a reserve based on measured peaks. For telephony, also check delay, jitter and packet loss; sufficient average bandwidth alone does not ensure voice quality.