Network Design
Size a VoIP deployment and the links that carry it. Build call groups with a codec mix, take the concurrent calls straight from you or derive them from headcount with Erlang B, model local breakout or backhaul to a hosted core, and read the voice loading of every link against both its capacity and its priority-queue ceiling.
Free forever on a Standard account. No credit card.
A voice call is not its codec bitrate. G.711 is 64 kbps of audio, but around 87 kbps on the wire once RTP, UDP, IP and the Ethernet header are paid, and a G.729 call that looks like 8 kbps on the datasheet costs about 31 kbps on plain Ethernet and about 55 kbps once an IPsec tunnel is wrapped around it. Those headers are paid once per packet no matter how much audio is inside, which makes the packetisation interval the biggest single lever on VoIP bandwidth and the one most often left at whatever the handset shipped with.
The VoIP Bandwidth Planner sizes the deployment and the links together. You build call groups, each with a codec, a packetisation interval and the link it belongs to, and size each one either by typing the concurrent calls when the trunk size is already known, or by giving the users, the busy-hour call attempts and the average hold time and letting Erlang B return the channels needed at your target grade of service. Codecs mix freely: G.711 handsets at head office, G.729 across the branch WAN and Opus softphones can all sit in the same design.
Transport belongs to the link, not the deployment. Each link carries its own layer 2 framing, VLAN tags, MPLS labels or PPPoE, an optional GRE, IPsec or DMVPN tunnel, SRTP, IPv4 or IPv6, and cRTP where the medium allows it, so a head office on tagged Ethernet and a tunnelled branch are each sized on their own terms instead of averaged into a number that is wrong for both. Every figure is one direction, which is how a link is sized.
The 40 bytes of RTP, UDP and IP are paid once per packet regardless of the audio inside. A G.711 call is around 110 kbps at 10 ms packetisation and around 76 kbps at 40 ms for exactly the same speech. The planner exposes the interval, restricts it to the values legal for the chosen codec, and prices every codec at every interval in one matrix.
A link can be half empty and still wrong for voice. The priority queue that protects voice is conventionally capped near a third of the link so the other classes still get served, and voice can breach that ceiling long before capacity runs out. Utilisation and the priority-queue share are reported separately, and a link that passes one and fails the other is called out.
Layer 2 framing, tunnelling, SRTP, IP version and cRTP are properties of the link. Each call group is sized with the transport of the link it lands on, so the same G.729 group reads 31.2 kbps per call on plain Ethernet and 55.2 kbps through an IPsec tunnel, and the design shows both rather than an average of the two.
Local breakout means a call crosses its own site link and nothing else. Backhauled to a hosted PBX or a central SIP trunk it crosses the core link too, often transcoded on the way, so it costs a different amount on each leg. Pin a call to one link and you silently understate the core, the link that carries every site at once. Set the topology per group and both legs are counted.
Voice is symmetric, so on a 100/20 service the 20 Mbps upstream runs out first and the headline downstream number is irrelevant. Enter both directions and the planner sizes against whichever binds, says which one it used, and runs the priority-queue check against that direction.
Most platforms stream music on hold as G.711 whatever the call negotiated, and music has no silence for VAD to suppress. A G.729 branch with calls parked on hold costs more than the codec table suggests. Set the held share and those calls are priced at G.711 and kept out of the VAD reduction.
ESP padding depends on the payload. AES-CBC pads the ciphertext to a 16-byte block boundary, so the same tunnel adds different overhead to a 20-byte G.729 payload than to a 160-byte G.711 payload. The planner computes the ESP header, initialisation vector, padding and integrity check value for the cipher you pick, instead of quoting one flat figure.
Ethernet framing is quoted two ways and the difference is 8 kbps on a G.711 call. The published tables count the 18-byte header and frame check sequence only; real link occupancy also spends 20 bytes of preamble and inter-frame gap. The tool defaults to wire rate, offers header-only framing, and states which convention gives the 87.2 kbps figure you will check it against.
Silence suppression saves bandwidth statistically across many simultaneous calls and nothing at all on a single call. The voice activity factor is applied to the group aggregate only, withheld on groups too small for the averaging to hold, and the full-rate peak is always shown alongside. cRTP gets the same treatment: it is refused over Ethernet and inside tunnels, where it is not defined, with the reason stated.
Because the codec bitrate is only the audio. Every 20 ms, a G.711 call sends 160 bytes of audio wrapped in a 12-byte RTP header, an 8-byte UDP header and a 20-byte IP header, then an 18-byte Ethernet header and frame check sequence. That is 218 bytes fifty times a second, or 87.2 kbps. Count the preamble and inter-frame gap that the medium also spends and it is 95.2 kbps. The planner shows both and lets you pick which convention to report.
Wire rate, for sizing a link, because preamble, start-of-frame delimiter and inter-frame gap are real time on the medium even though a packet capture never shows them. Header only is offered so your figures reconcile against the widely published per-call tables, which count the header and frame check sequence alone. G.711 at 20 ms reads 95.2 kbps at wire rate and 87.2 kbps header only.
With Erlang B. You give the users, the busy-hour call attempts per user and the average hold time; the tool works out the offered traffic in Erlangs and returns the number of simultaneous calls needed to hold blocking at or below your target grade of service. It then reports the blocking actually achieved, so you can see how much margin the rounding to a whole number left you. If you already know your trunk size, enter the concurrent calls directly instead.
No, and the tool will not pretend it does. Silence suppression saves bandwidth statistically, averaged across many simultaneous calls, because at any instant only some of them carry speech. On one call the peak is still the full rate. The planner applies the voice activity factor to the group total only, never to the per-call figure, withholds it entirely on groups too small for the averaging to hold, and always shows the full-rate peak alongside.
Because cRTP is not defined there. It compresses the IP, UDP and RTP header hop by hop on point-to-point serial links, where both ends maintain compression state. It is also useless inside a tunnel, since the header it would compress is already encrypted or encapsulated. Rather than silently applying it and producing a flattering number, the tool refuses it in those cases and tells you why.
Because ESP pads. AES-CBC has to pad the ciphertext to a 16-byte block boundary, so the padding needed depends on the size of the packet going in. A 20-byte G.729 payload and a 160-byte G.711 payload land in different places relative to that boundary. Flat tables that quote a single IPsec byte figure are wrong for at least one of them, so the planner computes it from the actual payload for the cipher you choose.
Voice is protected by a priority queue, and that queue is conventionally capped near a third of the link so the other traffic classes still get served. Voice can exceed that ceiling while the link as a whole still looks comfortable. If you let it, everything else on the link starves. The planner checks utilisation and the priority-queue share separately and flags a link that passes one and fails the other, because that is exactly the failure a plain utilisation figure misses.
A great deal, and it is the most common way a VoIP sizing comes out wrong. With a hosted PBX or a central SIP trunk, a branch call crosses the branch link AND the head office link, and if the session border controller transcodes it the two legs cost different amounts. Set the group topology to centralised, pick the core link and the transcode codec, and both legs are counted. Leave it on local breakout and the head office link only sees its own handsets, which understates it by everything the branches send.
Both. Enter 100 downstream and 20 upstream, and the tool sizes against the 20, because voice is symmetric and the smaller direction runs out first. It will tell you which direction it used. Entering only the advertised downstream figure is one of the easiest ways to under-build a branch voice service by a factor of five.
Because music on hold is almost always streamed as G.711 regardless of what the call negotiated, and music is continuous so there is no silence for voice activity detection to suppress. On a G.729 branch a held call costs roughly three times a talking one. The tool prices the held share at G.711, keeps it out of any VAD reduction, and says so, because this is a real surprise that shows up after cutover rather than during design.
That is your call, which is why the default is zero. A tool that quietly inflates your numbers is worse than one that makes you choose. Set a per-link margin and the sized figure is shown next to the raw one, so it is always clear which part is measurement and which part is allowance.
No, and that is deliberate. This is a capacity tool: how much bandwidth the deployment needs and whether the links carry it. Voice quality scoring, MOS and the E-Model, DSCP marking and queueing design, delay and jitter budgets, and T.38 fax are all out of scope. Keeping the tool to one question means it never has to hedge on that question.
Every figure is one direction. A conversation consumes the per-call bandwidth in each direction independently, and links are sized on the constrained direction, so a one-direction figure is the one you plan with. If your link is asymmetric, size the smaller direction.
Free forever on a Standard account. No credit card.
