Designing and deploying

a VoIP network
When ITU meets IETF

Thomas(at)Kernen.Net
 A quick VoIP recap
 Directory Gatekeeper (DGK): Performs call routing search at
highest level (ex: country code distributes). Country codes
among other DGKs Forward LRQ (location request) to a
partner DGK if call doesn't terminate in local SP DGK
 Gatekeeper (GK): Performs call routing search at intermediate
level (ex: NPA-NXX). Distributes NPA among other GKs.
Provides GW resource management (Ressource Availabilty
Indicator, gw-priority, ....)
 Gateway (GW): Acts as interface between the PSTN and IP.
Normalizes numbers from PSTN before entering IP.
Normalizes numbers from the IP before entering the PSTN.
Contains the dial-peer configuration. Registers with the GK.
 Basic H.323 Call
Gatekeeper A Gatekeeper B
LRQ
LCF
ACF ACF

RRQ/RCF
IP Network RRQ/RCF

ARQ H.225 (Q.931) Setup ARQ

H.225 (Q.931) Alert and Connect
H.245
V RTP V
Gateway A Gateway B

Phone A Phone B
 Various Codec Bandwidth
Consumptions
Encoding/ Result
Compression Bit Rate
Standard G.711 PCM 64 kbps (DS0)
Transmission A-Law/u-Law
Rate for Voice
G.726 ADPCM 16, 24, 32, 40 kbps

G.727 E-ADPCM 16, 24, 32, 40 kbps

G.729 CS-ACELP 8 kbps

G.728 LD-CELP 16 kbps

G.723.1 CELP 6.3/5.3 kbps

Variable
Cisco Encoding Implementation
20 Byte packet every 20ms (50pps)
8kbps Data Rate
Note - This 8bkps for “Voice Payload” only!!

Add on 40 bytes of IP/UDP/RTP and you now have 24kbps!

RTP Header Compression will take this down to 11.2kbps

= 0010110101

Encode Decode

IP QoS WAN

= Sample
8 kHz (8,000 Samples/Sec)
Voice Quality of Service (QoS)
Requirements

Avoiding The 3 Main QoS Challenges

Loss
Delay
Delay Variation (Jitter)
 Loss and Delay Sources

• CODEC (Encode)
• Packetization
Voice Path • Output queuing
Loss • Access (up) link transmission
+
Delay • Backbone network transmission
+
Delay • Access (down) link transmission
Variation
• Input queuing
• Jitter buffer
• CODEC (Decode)
 Delay—How Much Is Too Much?
Cumulative Transmission Path Delay

CB Zone
Satellite Quality
High Quality Fax Relay, Broadcast

0 100 200 300 400 500 600 700 800

Time (msec)
Delay Target

ITU’s G.114 Recommendation = 0 – 150msec 1-way delay

 Fixed Delay Components
Propagation Delay
Serialization Delay—
Buffer to Serial Link
Processing Delay

 Propagation—six microseconds per kilometer

 Serialization
 Processing
Coding/compression/decompression/decoding

Packetization
Variable Delay Components
Queuing Queuing Queuing
Delay Delay Delay

Dejitter
Buffer

 Queuing delay
 Dejitter buffers

 Variable packet sizes

 Large Packets “Freeze Out”
Voice
Voice Packet Voice Packet Voice Packet
60 bytes 60 bytes 60 bytes
Every 20ms Every >214ms Every >214ms

Voice 1500 bytes of Data Voice ~214ms Serialization Delay

Voice 1500 bytes of Data Voice Voice 1500 bytes of Data Voice

10mbps Ethernet 10mbps Ethernet

56kb WAN

 Large packets can cause playback buffer

underrun, resulting in slight voice degradation
 Jitter or playback buffer can accommodate
some delay/delay variation
 RTP Controlling Dejitter Buffer
Sender Receiver
RouterA IP RouterB

V
Network V

20ms 20ms

C B A
10 30 50

20ms 20ms
RTP Timestamp From Router A
Interframe gap of 20ms
C B A
20ms 80ms 10 30 50

C B A RTP Timestamp From Router A

10 30 50 Delitter Buffer removes Variation

RTP Timestamp From Router A

Variable Interframe Gap (Jitter)
 Calculate Delay Budget - Worst Case
Coder Queuing
Delay Delay Dejitter Buffer
25 ms 4 ms 50 ms
Site A Site B
Propagation
Delay—8 ms
(128kbps Frame Relay)
Serialization Delay
2 ms
Fixed Variable
Delay Delay
Coder Delay G.729 (5 msec look ahead) 5 msec
Coder Delay G.729 (10 msec per frame) 20 msec
Packetization Delay—Included in Coder Delay
Queuing Delay 128 kbps Trunk 4 msec
Serialization Delay 128 kbps Trunk 2 msec
Propagation Delay (Private Lines)
Network Delay (e.g.,Public Frame Relay Svc) Min 8 msec
Dejitter Buffer 50 msec
Total 89 msec
 Fragmentation and Interleaving
 Serialization delay for 64Kbps link with an
MTU of 1500 bytes
 (1500 bytes x 8bits/byte) / (64000 bits/sec) =
187.5ms
 Fragmentation size: design for 10ms fragments

 (0.01 sec x 64000 bps) / (8 bits/byte) = 80 bytes

It takes 10 ms to send an 80 byte packet or

fragment over a 64kbps link.
 Fixed Frame Serialization Delay
Matrix
Frame Size
1 64 128 256 512 1024 1500
Byte Bytes Bytes Bytes Bytes Bytes Bytes

56kbps 143us 9ms 18ms 36ms 72ms 144ms 214ms

64kbps 125us 8ms 16ms 32ms 64ms 128ms 187ms

Link
Speed 128kbps 62.5us 4ms 8ms 16ms 32ms 64ms 93ms

256kbps 31us 2ms 4ms 8ms 16ms 32ms 46ms

512kbps 15.5us 1ms 2ms 4ms 8ms 16ms 23ms

768kbps 10us 640us 1.28ms 2.56ms 5.12ms 10.24ms 15mss

1536kbs 5us 320us 640us 1.28ms 2.56ms 5.12ms 7.5ms

 Multilink PPP with
Fragmentation and Interleave
64 kbps Line

Real-Time MTU Elastic Traffic MTU

187ms Serialization Delay
for 1500 byte Frame at 64 kbps

64 kbps Line

Addendum to PPP Specification

Elastic MTU Elastic MTU Real-Time MTU Elastic MTU
Media Link Layer Overhead
Layer 2 Media Layer 2
Header Size
Ethernet 14 bytes

PPP/MLPPP 6 bytes

Frame Relay 6 bytes

ATM (AAL5) 5 bytes + waste

MLPPP over FR 14 bytes

MLPPP over ATM 5 bytes for every ATM cell

+ 20 bytes for MLPPP/AAL5
 RTP Header Compression
Overhead

Version IHL Type of Service Total Length

Identification Flags Fragment Offset
 20ms@8kb/s yields 20 byte
Time to Live Protocol Header Checksum payload
Source Address  IP header 20; UDP header 8; RTP
Destination Address header 12
Options Padding 2X payload!!!!!!!!

Source Port Destination Port  Header compression 40Bytes to

Length Checksum
2-4 much of the time
V=2 P X CC M PT
Timestamp
Sequence Number
 Hop-by-Hop on
Synchronization Source (SSRC) Identifier
slow links <512kbps
 CRTP—Compressed Real-time
protocol
RTP Header compression details
 Can save a lot of bandwidth (>50%) per flow.
 Works on serial links between 2 routers

 CPU intensive, might overkill the routers

 Limited to 256 sessions (128 calls) over FR

 Limited to 1000 sessions (500 calls) over

HDLC (checked in 12.2(8)T)
 Not recommend on links with data rates above
E1
 Silence suppression
 VAD (Voice Activity Detection) (Cisco)
 Codec built-in silence suppression
(G.729a/G.723.1b)
 Should not be taken into account for circuits
carrying less than 24/30 calls since based on
aggregate volume, not individual calls.
 Should not be taken into account when
engineering the network.
 IP Precedence/DSCP
 DSCP - Differentiated Services Code Point
(RFC 2474-2475)
 Set IP Precedence/DSCP higher for VoIP.
Usually set to 5/101000
 Set at source (gateway) if possible for less
hassle.
 Queuing mechanisms
(in Cisco’s world)
 FIFO, First In First Out
 Packets arrive and leave the queue in exactly the same order
 Simple configuration and fast operation
 No Priority servicing or bandwidth guarantees possible

 WFQ, Weighted Fair Queuing

 A hashing algorithm, places flows into separate queues where
weights are used to determine how many packets are serviced
at a time. You define weights by setting IP Precedence and
DSCP values.
 Simple configuration.
 No priority servicing or bandwidth guarantees possible.
 Queuing mechanisms (2)
 CQ, Custom Queuing
 Traffic is classified into multiple queues with configurable queue limits.
 Has been available for a few years and allows approximate bandwidth
allocation for different queues.
 No priority servicing possible. Bandwidth guarantees are approximate and
there are a limited number of queues. Configuration is relatively difficult.

 PQ, Priority Queuing

 Traffic is classified into high, medium, normal and low priority traffic is
serviced first, then medium priority traffic, followed by normal and low
priority traffic.
 Has been available for a few years and provides priority servicing.
 Higher priority traffic can starve lower priority queues of bandwidth. No
bandwidth guarantees possible.
 Queuing mechanisms (3)
 CBWFQ, Class Based Weighted Fair Queuing
 MQC is used to classify traffic. Classified traffic is placed into reserved
bandwidth queues or a default unreserved queue.
 Similar to LLQ except there is no priority queue. Simple configuration and
ability to provide bandwidth guarantees. No priority servicing possible.

 PQ-WFQ, Priority queue-Weighted Fair Queuing (IP RTP Priority)

 Single interface command is used to provide priority servicing to all UDP
packets destined to even port numbers within a specific range.
 Simple, one command config. Provides priority servicing to RTP packets.
 All other traffic is treated with WFQ. RTCP traffic is not prioritized. No
guaranteed bandwidth capability.

 Note: MQC = Modular QoS CLI

 Queuing mechanisms (4)
 Low Latency Queueing (LLQ) = Priority Queue (PQ)+ Class
Based-Weighted Fair Queue (CB-WFQ).
 Allows a strict Priority Queue to handle a defined class of
packet to be prioritized over all other traffic.
 Simple config, ability to provide priority to multiple classes of
traffic and give upper bounds on priority bandwidth utilization.
Can also config bandwidth guaranteed classes and a default
class.
 All priority traffic is sent throught the same priority queue
which can introduce jitter.

Note: Cisco appears to be working on improving LLQ and this is

currently the #1 queuing mechanism according to SEs, TAC
and updated documentation.
 Traffic Engineering
 Busy Hour (BH) = Number of lines required to support the
worst hour of the day
 Grade of service (GOS) = Percentage of lines that will
experience a busy tone on the 1st attempt during the BH
 A GOS of 0.05 means 5 out of 100 callers might get a busy
tone
 Erlang B, most widely used traffic model to estimate the
number of lines required for a specific GOS and BH of traffic.
 Based on various traffic assumptions such as call queueing,
arrival rate, etc...
 1 trunk in use for 1 hour = 1 Erlang = 36 CCS of traffic
 1 Centrum Call Seconds (CCS) = 100 call seconds
 1 hour = 3600 seconds or 36 CCS = 1 Erlang
 Traffic Engineering (2)
 Step1: Obtain voice traffic data
 Sources of traffic information: CDRs (Call Detail
Record) or carrier bills, carrier studies, traffic reports
 Data needs to be adjusted for call processing since a
trunk in use = Dialing + Call setup + Ringing +
Talking + Releasing
 Other sources: Ring No Answer, Busy Signal, etc
 Add 10% to 16% to all call lengths/total time
estimates.
 Traffic Engineering (3)
 Step 2: Convert to Erlangs
 Adjusted total hours a month / business days *
% of traffic in busy hour
 Step 3: Calculate the number of voice lines
 Based on statistical model for the # of lines vs
the grade of service desired
 Step 4: Calculate the data network bandwidth
 (Codec + protocol overhead) * number of voice
lines = required bandwidth
 POP Sizing
 Calculate the number of gateways (GW) required to
handle anticipated call volume
 Use Busy Hour Call Attempts (BHCA) metric
 Calculate the number of (Directory) Gatekeepers
required to process the GW signaling
 GWs = max E1s per GW, BHCA, CPS (Calls per
Second)
 GKs = max CPS (check with vendor, not an obvious
figure to get, varies with each
chassis/configuration/software release/DSP rev)
 Tips & tricks
 Build GK redundancy by making sure all GWs
have multiple GKs to reach. HSRP can be very
useful in conjunction with multiple GW->GK
destinations.
 Make sure the GWs normalize the format of
the called numbers so the VoIP core deals with
a single call format (E.164 =
country+city+local).
 Inter provider VoIP services
What happens when you want to extend the
reach of your VoIP services by interconnecting
with other ITSP?
 Tandem coding (VoIP->PSTN->VoIP)

 Open Settlement Protocol

 Tandem Coding
In the case where a call is passed back from the VoIP
network to the PSTN and then resampled &
compressed the call has been sampled and
compressed twice and therefore the call quality will
degrade very rapidly.
Examples:
VoIP to GSM via the PSTN.
VoIP to the PSTN via another carrier with compression
gear.
Other VoIP carrier doesn’t want to “risk” interconnects
over VoIP (inter-ITSP QoS management issues)
 Open Settlement Protocol (OSP)
 Open Settlement Protocol (OSP), client-server protocol defined by the
ETSI TIPHON standards organization. Designed to offer billing and
accounting record consolidation for voice calls that traverse ITSP
boundaries. It also allows service providers to exchange traffic with each
other without establishing multiple bilateral peering agreements by using a
3rd party clearinghouse to enable extending the reach of their network.

 3rd party clearinghouse with an OSP server will allow services such as
route selection, call authorization, call accounting, and inter-carrier
settlements, including all the complex rating and routing tables necessary
for efficient and cost-effective interconnections. The OSP based
clearinghouses provide the least cost and the best route-selection
algorithms based on the a wide variety of parameters.
 How it works
 Step 1: customer places call via the PSTN to a VoIP Gateway, which
authenticates the customer by communicating with a RADIUS server
 Step 2: The originating VoIP gateway attempts to locate the termination
point within it's own network by communicating with a gatekeeper using
H.323 RAS. If there's no appropriate route, the gatekeeper tells the
gateway to search for a termination point elsewhere.
 Step 3: The gateway contacts an OSP server at the 3rd party clearinghouse.
The gateway establishes an SSL connection to the OSP server and sends an
authorization request to the clearinghouse. The authorization request
contains pertinent information about the call, including the destination
number, the device ID, and the customer ID of the gateway.
 Step 4: The OSP server processes the information and, assuming the
gateway is authorized, returns routing details for the possible terminating
gateways that can satisfy the request of the originating gateway.
 How it works (2)
 Step 5: The Clearinghouse creates an authorization
token, signs it with the certificate and private key,
and then replies to the originating gateway with a
token and up to 3 selected routes. The originating
gateway uses the IP address supplied by the
clearinghouse to setup the call.
 Step 6: The originating gateway sends the token it
received from the settlement server in the setup
message to the terminating gateway.
 Step 7: The terminating gateway accepts the call after
validating the token and completes the call setup.
 Voice Speech Quality (VSQ)
 MOS: ITU P.800 & P.830, scale from 1 (bad) to 5 (excellent),
based on human perception (subjective), most widely used by
VoIP vendors when comparing codec quality, the oldest
model.
 PSQM (Perceptual Speech Quality Measurement), ITU P.861,
compares input and output speech (automated), developed by
KPN Research
 PAMS (Perceptual Analysis Measurement System),
Developed by British Telecom, “Objectively” predict results
of subjective speech quality tests
 PESQ (Perceptual Evaluation of Speech Quality) ITU P.862,
latest standard (January 2001), currently the most accurate
model for automated voice quality perception, improves over
PSQM and PAMS
 Sources of potential VSQ problems
 Delay jitter: variance in delay (zero, little or excessive delay)
 Encoding and decoding of voice (PCM/ADPCM/low bit-rate
codecs/CLEP)
 Time-Clipping (Front end clipping) introduced by Voice
Activity Detectors (VAD)
 Temporal signal loss and dropouts introduced by packet less
 Environmental noise, including background noise
 Signal attenuation and gain/attenuation variances
 Level clipping
 Transmission channel errors
Echo: What makes it a problem?
When all of the following conditions are true,
echo is perceived as annoying:
 An analog leakage path between analog
Tx and Rx paths
 Sufficient delay in echo return
 Sufficient echo amplitude
 How the packet voice impact on
echo perception ?
PSTN WAN PSTN

Large delay, Low delay,

no echo sources potential echo sources

 Bits don’t leak - Echo is not introduced on digital links

 The packet segment of the voice connection introduces a significant delay
(typically 30 ms in each direction).
 The introduction of delay causes echoes (from analog tail circuits) that are
normally indistinguishable from side tone to become perceptible.
 Because the delay introduced by packet voice is unavoidable, the voice
gateways must prevent the echo.
 Identify and Isolate the echo
problem
 Identify the echo problem. Which side hears
echo? Calls to which numbers hear echo ?
 Isolate the problem as much as possible and try
to find a scenario where the echo is
reproducible.
Whenever I hear echo, the problem is at the
OTHER end !!
 Basic security
 GWs/GKs w/ACLs with source ip (yes, can be
spoofed) appears to be the #1 source of protection
against un-authorized calls.
 Run your VoIP network isolated from any public
network using your prefered flavor (physical
seperation, VLAN, MPLS, etc..)
 VoIP packets are _not_ encrypted, if this is an issue
used IPSec! Beware that software crypto will add
delay and jitter, use hardware crypto for better
performance (should add predictable delay and jitter)
 Note: CRTP doesn't work with IPSec, remember this
when designing the bandwidth budget.
Questions?