Supported Audio Codes

The goal of the calculations is to verify if the current infrastructure can support the combined load from existing data and telephony usage.

To make such calculations, it is necessary to identify where the main flows are and where it is most likely that congestion will occur. The following sections identifies a number of issues.

Server - Server signaling

When two or more Servers are used, the Servers communicate using the proprietary inter-Server signaling. For information on how to calculate for inter-Server traffic, see IP Network Structure> Inter-Server Modeling.

When the solution needs an even larger system, each system node must be interconnected with the SIP networking feature, or use ISDN QSIG (or H.323) networking.

Trunk Lines

To calculate the necessary trunk line needs, base the calculations on the assumption of 0.8 Erlang load per trunk.

Extensions

It is assumed that a typical user is loading the system with 0.2 Erlang of traffic, during Busy Hour, that is, the user is making 8 calls/hour and each call is in average 90 seconds long. If the business is very call intensive or each call have higher average holding times, extra consideration needs to be taken.

In business situations which have operations going on for 24 hours and 7 days a week, many models assume that a working day is 8 hours and that a week consists of 5 working days. In worst case this could give an error by the factor 4 for average calls/seconds.

Bandwidth Calculation

The simplest type of modeling uses the projected call volume where selected codec and bandwidth are required as input parameters. Modeling a whole network will require much computation with different input values and variables. However bandwidth modeling may be the most valuable way for calculation of critical links.

The bit rate stated for a codec is a net value, that is, this value does not include the overhead caused by packet headers. So the real bit rate of a voice stream encoded by these codecs is higher than the bit rate, see Table 10: Supported Audio Codecs on page 351.

Table 1. Supported Audio Codecs

CODEC

Bandwidth (kbit/s)

G.711 A-law, 64 kbit/s

80

G.711 µ-law, 64 kbit/s

80

Clear channel

80

Unknown codec

80 (default)

G.729 annex A and annex B

24

G.729 annex A

24

G.729 annex A

24

G.723.1

17

G.723.1 Annex C

17

To estimate the real bit rate, this value has to be combined with the header bandwidth, see Table 11: IP Layer Bandwidth on page 35 which states the bandwidth needed for different transport media.

Table 2. IP Layer Bandwidth

IP Layer Bandwidth

Inter-Packet Delay

10 ms

20 ms

30 ms

Codec

See Table 10: Supported Audio Codecs on page

-

-

-

kbit/s

RTP

(RFC 3550)

9.6

4.8

3.2

kbit/s

UDP

6.4

3.2

2.1

kbit/s

IP

16

8

5.4

kbit/s

---Total---

RTP+UDP+IP

32

16

10.7

kbit/s

- or -

cRTP (RFC 2058)

1.6

0.8

0.5

kbit/s

- or -

cRTP + UDP checksum

3.2

1.6

1.1

kbit/s

To calculate the total bandwidth consumption, it may be necessary to also include link layer bandwidth in the calculation.

In most cases the link layer can be omitted, but with low bandwidth codecs running on narrow band links it is necessary to include additional bandwidth to get a proper result.

Trunk bandwidth = Codec BW * A / An, where A = n*α* R hand A nis the allowed load on a given trunk. For values on A n see Default and Guiding Values.

Example: 2 Geographical locations, 160 VoIP clients are needed. G.711 is used (80kbit/s). Current Mean Traffic is 0.15 Erlang per user. Current Mean Hold Time = 67 seconds 2 locations with 80 terminals at each location=> each user needs 80 kbit/s to make a call. The IP trunk (network) needs (80x0.15x1.2x0.5x0.5) = 3.6 Erlang 3.6 Erlang requires 9 channel, thus 9*80 kbit/s = 720 kbit/s is needed. The PSTN trunk carries 7.2 Erlang, and needs 14 channels with GoS=1% (The Hold Time only gives an indication that the call attempts λ are 0.43 calls/s in average.)

It should be noted that the bandwidth calculation assumes a full duplex network end-to-end. On half duplex links the required bandwidth will be twice the value calculated here. Examples for half duplex networks are WLAN and Ethernet hubs.

The next calculation example describes a detailed calculation of the overhead caused by an Ethernet link.

Example: 20 users are using their phones 20 times per workday (8 hours) and each call has an average length of 1.5 minutes. This gives 20 x 20 x 1.5 / (8 x 60) = 1.25 Erlang. 1.25 Erlang of traffic is carried by 6 channels with a probability of 0.2% for lost or congested calls, according to the Erlang Loss Formula table.

The codec bandwidth is calculated from the sum of (MAC layer + IP header + UDP + RTP + Payload) / packets per second. A voice channel that uses G.711 as codec and is sent over an IP network in packets of 30 ms samples, requires 240 bytes payload, 40 bytes IP/UDP/RTP header and 18 bytes of Layer 2 header. This gives (240 + 40 + 18) x 8 bits/byte / 0.03 seconds = 79.47 kbps. If G.729 is used with the same packet, it requires 23.47 kbps.

6 channels would require 6 x 79.47 = 476.8 kbps if G.711 with a packet size of 30 ms is used as codec and 6 x 23.47 = 140.8 kbps if G.729 with the same packet size is used.

476.8 kbps gives that 20 users will add approximately 5% traffic load to a 10 Mbps connection. (Or 10% if the link is not full duplex)

The modeling gets very quickly complicated as parameters like Silence Suppression, Header Compression and Quality of Service are added. The recommendation is to start the deployment calculations from a simple view.