1

Attachement 1. VoIP Lab: Cisco CallManager Express, Theoretical

Background

Contents

Part One: Equipment and Protocols 71

Cisco CallManager Express 71

Cisco 2600XM Series Multiservice Access Router 71

Cisco IP Phones 72

Cisco Catalyst 3550 and 2950 LAN Switches 73

Ethereal Network Protocol Analyzer 74

Agilent Advisor LAN 75

Iperf Network Performance Measurement Tool 75

RTP 76

RTCP 77

H.323 77

SIP 79

G.711 and G.729 80

Voice Activity Detection 82

Cisco IOS Dial-Peer Matters to be Considered 83

Part Two: Quality of Service 89

Lack of Bandwidth 89

Cure for Lack of Bandwidth 90

Delay 92

Jitter 93

Packet Drops 94

Differentiated Service Code Point 95

Weighted Random Early Detection 96

Low Latency Queuing 96

2

Part One: Equipment and Protocols

Cisco CallManager Express

The Cisco CallManager Express (CCME) is a call-processing system of Cisco Systems,

Inc. The platform for CCME can be any Cisco router from the Cisco 1700 to the Cisco

3800 series modular Integrated Services Routers (ISR). CCME is a software product,

integrated into the Cisco routers' Internetwork Operating System (IOS), thus providing

the CCME call processing features on top of the ordinary router services.

CCME provides a wide range of IP telephony services for small and medium-sized

businesses up to 240 users. The functionalities depend on the CCME release, and the

present version in the EVTEK lab (October 2005) is a CCME3.2, integrated into Cisco

2600XM series Multiservice Access Router housing an IOS release 12.3 IPVOICE with

a CCME feature license. This version of the CCME is able to take care of the call

processing and management functions of up to 36 IP telephones with simultaneous

calls, thus being an ideal and cost-effective solution for a small business application.

Additional service modules, like such as a call attendant and voice mail services in the

Cisco Unity Express were available too, but they are not included in EVTEK laboratory

equipment composition.

CCME can be fully configured through all the user interface options that the Cisco

router IOS offers. In addition, the CCME has its own web-based graphical user interface

(GUI). Unfortunately the CCME GUI facilities do not cover all the configuration

options needed in this laboratory exercise, and therefore the laboratory work

instructions are given in the IOS command-line interface format only.

Cisco 2600XM Series Multiservice Access Router

the CCME is inbuilt in a certain version of the Cisco router IOS and the platform in the

EVTEK laboratories for this purpose is a Cisco 2600XM series Multiservice Access

Router. This router model is a usual model in the EVTEK laboratory environment used

3

for example for the CCNP Network Academy courses. There is one 2600MX router

with a CCME IOS included per equipment rack in the laboratory, one for each student

lab work team.

This CCME VoIP laboratory work is built for the use of two Cisco routers; one router is

used as CCME and the other as a POTS gateway. The Gateway router is otherwise an

ordinary 2600XM series router in the laboratory, but including an ordinary IOS without

CCME functions. The Gateway router contains a network module (NM-1V), which

again contains a POTS module (VIC-2FXS) with two analog telephone line interfaces.

The first analog port with a RJ-11 connector is located on the right (port number 0), and

the second port is located on the left (port number 1), as seen at the front of the module.

This router thus provides students with POTS-VoIP gateway functionalities for the

laboratory exercises and there is one router with an FXS module included per

equipment rack in the laboratory.

Cisco IP Phones

There are three types of Cisco IP phones in use in the laboratories. The most common

one is Cisco 7905G, and the two other models are Cisco 7912G and Cisco 7960. Cisco

IP phones communicate with a CCME using the Cisco proprietary Skinny Client

Control Protocol (SCCP). However, the study of this protocol is beyond the scope of

this laboratory exercise. These Cisco IP phones support also XML applications through

the LCD.

Cisco IP phones receive their power supply from an additional power supply unit, or

from Catalyst 3550 switch over the Ethernet wiring. The Taiga laboratory Catalyst 3550

switches do not have this optional power supply feature installed.

Cisco IP phones retrieve their configuration file from CCME TFTP server during phone

registration at start-up, or at reset or restart. The reset practically corresponds to a cold

boot, causing a phone to reregister with the CCME. Cisco IP phones require a firmware

that must match with a CCME software release for full functionality. A new firmware

4

stored at the router Flash memory can be automatically downloaded to the IP phone

during the phone registration with the CCME.

The allocated IP address and other configuration details can be inspected on the IP

phone's own LCD. To verify the allocated IP address, do the following: with the models

7905G and 7912G, first press the "Globe"-button, then press 3, then press 3 again, and

finally press 6. With a model 7960, press Settings -> Scroll down to 3. Network

configuration -> Press Select -> Scroll down to 6. IP address, or alternatively, press

Settings, press 3, and press 6.

The Cisco 7905G IP phone includes one extension line and one FastEthernet LAN

interface. The Cisco 7912G IP phone model is used in the production network of the

institute, but might be used also in the laboratory. This model includes two extension

lines and an internal three-port LAN switch with a second FastEthernet interface, which

enables a series connection of a PC with this IP phone. The Cisco 7960 IP phone offers

a variety of features, including communication up to six extension lines, and a speed

dial, together with various user-defined software options. It also includes a three-port

LAN switch.

Cisco Catalyst 3550 and 2950 LAN Switches

The Cisco Catalyst 3550 or 2950 switch is a nodal point in a test network,

interconnecting the routers, PCs and IP phone. The Catalyst 3550 switch may include a

Cisco Power over Ethernet (PoE) functionality enabling a 48 VDC power supply to

Cisco IP phones over the Ethernet line, but unfortunately that feature is not included in

the switches in the Taiga laboratory, as opposed to the switches in the IP laboratory.

Otherwise the both switch types have similar features regarding the Quality of Service

configuration and traffic monitoring facilities, although Layer 2 Quality of Service

issues are not included in this lab exercise yet.

The switches include a monitor session functionality for LAN traffic monitoring. In

order to monitor the VoIP traffic sent from CCME to the IP phone, do the following

5

switch settings, observing that the monitor session source interface is the switch

FastEthernet interface, where the CCME is connected (rx setting monitors CCME

transmit traffic), and the destination interface is the switch FastEthernet

interface, where your PC (with the Agilent Advisor LAN and Ethereal Network

Analyzer software) in connected. The session number must be the same in both

commands, source and destination. The source interface direction options are rx, tx

and both, and the default is both. Please note that the Catalyst switch FastEthernet

interface numbering starts from fa0/1.

Switch(config)#monitor session 1 source interface Fa0/# rx Switch(config)#monitor session 1 destination interface Fa0/#

You can now utilize for example the Ethereal and Agilent network analyzer programs in

this laboratory exercise. Please note that monitor session destination setting disables the

normal use of this switch FastEthernet interface. The PC connected to a monitor session

destination port has no other network connectivity any longer. The monitor session

source command has no effect on the traffic on that switch port. The switch

management interface Vlan1 needs an IP address, so that the switch can be used as a

ping source or destination.

Ethereal Network Protocol Analyzer

The laboratory PC equipment includes an open Ethereal Network Protocol Analyzer

program. This can be used e.g. to analyze a VoIP IP stream from en Ethernet data link

layer up to RTP datagram content level.

To start capturing the traffic, click: Capture -> Start or Continue without saving -> OK.

Use display filters one at a time to see only the desired packets; click: Expressions ->

choose one protocol H.225/SIP/RTP/RTCP -> Relation Is present -> Apply. You may

change the display filter several times without any effect on the captured packets in an

analyzer buffer memory.

6

Another useful feature of Ethereal is the RTP statistics analysis. One can view RTP

stream quality parameters, such as jitter and packet drops. To use this feature, first stop

capturing, then click: Statistics -> RTP -> Stream analysis. For a graphical view, choose

menu option Statistics -> IO Graph.

Agilent Advisor LAN

The laboratory PC equipment also include Agilent Advisor LAN program. This is a

licensed LAN protocol analyzer from Fluke. This can be utilized for example in

analyzing a VoIP call, or ping bandwidth consumption.

Start monitoring by clicking an icon of green traffic lights, and stop monitoring by

clicking an icon of red traffic lights. In order to monitor the LAN traffic bandwidth

consumption, used protocols and the like, use "Protocol Vital Statistics" feature (a heart

symbol in the tool bar options).

The Agilent also includes an RTP statistics analysis feature, which is a licensed one, but

should be enabled in the lab PCs. Click RTP stats icon on the toolbar, then choose either

Interarrival jitter or Packet loss display. This is a real-time measurement and the user

may set alarm thresholds for these above mentioned parameters as well.

Iperf Network Performance Measurement Tool

Iperf is a freeware included in the lab PCs and is an alternative to ping for generating

test traffic in order to overload the serial interface in the lab exercises. Iperf works as a

client-server model, a client used for generating the traffic and a server for receiving

and analyzing the received data. The user may set several parameters for testing, for

example test packet or datagram payload size, the desired payload data bandwidth and

the like. Iperf will then indicate the real throughput from client to server.

Downloads and further information are available at the Distributed Applications

Support Team’s Internet site [19]. User interface is a text-based command prompt

7

feature, and separate user instructions are available at the above mentioned web site or

from the teacher.

A sample command for a client transmitting the test signal is as follows: -c for client, ip

address for a distant server, -b for the application layer bandwidth (remember the

additional bandwidth for all the headers), -u for UDP, -l for payload packet in bytes, -i

for the periodic display report interval in seconds, and -t for the measurement period in

seconds.

C:\...\iperf_folder_name\ iperf -c 10.0.3.5 -b 150k -u -l 1470 -i 1 -t 20

This is sample command string for a server to receive the test signal:

C:\...\iperf_folder_name\ iperf -s -u

RTP

The Real Time Transport Protocol (RTP, RFC 1889) transports the encoded voice

information. The RTP datagrams are transmitted on top of User Datagram Protocol

(UDP, RFC 768). The RTP is a connection-oriented protocol including sequence and

timestamp information for receiver to determine the correct order of the datagram flow

together with the interarrival jitter. RTP header includes also synchronization source

identifier for the receiver to distinguish between different RTP flows. The VoIP RTP

uses a dynamic UDP port allocation flow by flow, the UDP port number ranging from

16384 to 32767 (even ports only). [1,182,194]

Payload type in the RTP header indicates the used codec: 8 for G.711alaw and 18 for

G.729 [24,12]. In the OSI reference model the RTP represents part of the transport

layer, for example H.323 and SIP represent the session layer, a codec represents the

presentation layer and the human voice represents the application layer [7,337]. RTP is

a best-effort protocol; it does not guarantee any Quality of Service [21,284].

8

The RTP header is 8 bytes long, but with the underlying UDP and IP headers, they

make 40 bytes (8 for RTP, 12 for UDP and 20 for IP). This set can be compressed down

to 2 or 4 bytes using the RTP header compression (cRTP, RFC 2508), and to 4 bytes

when UDP checksums are used. The compression and decompression must be done on

a link-by-link basis in the IP level, because IP headers are also compressed. The

disadvantage of the cRTP is the heavy burden on the router CPU.

RTCP

The Real Time Transport Control Protocol (RTCP, RFC 1889) carries RTP stream

control information. The RTCP is also transported over the UDP, the ports ranging from

16385 to 32767 (odd ports only), but always the RTP port number +1 of the same call.

The two RTCP packet types are Sender report, containing transmission and reception

information for active senders, and Receiver report, containing information for listeners,

who are not active senders. The information content can be sender and receiver

identification, synchronization (stream identification), but the most interesting is the

VoIP call RTP flow quality information: lost packets, jitter and delay information.

[24,14-20]

H.323

H.323 has been the dominant VoIP network gateway control protocol, but the use of

alternative protocols, such as MGCP and Session Initiation Protocol (SIP) has been

emerging in recent years. H.323 has been characteristic in service providers' networks

because of its versatile and proven functionality. Main strengths of H.323 are in the

logical channel establishment architecture; H.323 makes a clear distinction between

different media types; H.323 has conference control features and a wide interoperability

with various telecommunication protocols and server functions. [24,158-159]

The major role of H.323 with its subsets H.225 and H.245 in a VoIP network is to offer

call setup and tear down services. These can be categorized to a call admission request

9

and control (with a gatekeeper) (H.225 UDP), call setup messaging (H.225 TCP and

Q.931), capabilities exchange (H.245 TCP), and opening logical channel (H.245 TCP)

[7,340-41]. The messaging syntax notation is ASN.1. [25,159]

H.323 VoIP architecture is a family of several protocols and functions. The most

important groups are Registration, Admission, and Status Protocol (RAS) for the

communication between an H.323 gateway and a gatekeeper. Most interesting in this

lab exercise is H.225, which is used to establish a connection between two H.323 end

points, such as CCME and the Gateway routers. H.245 is a signaling to exchange end-

to-end control messages for the H.323 endpoints, for example voice codec capability

and other call parameter exchange and negotiation. H.225 standard defines ITU-T's

Q.931 protocol used for example in ISDN networks for call signaling. In addition,

H.323 is fully compatible with Signaling System 7 (SS7). [2,30-31;23,34-35]

H.225 signaling is carried over a TCP connection using port 1720. H.225 includes

several possible call setup and control messages, but the most important and interesting

for us in this lab exercise are the following ones, illustrated in Figure 1.

Figure 1. IP phone originated H.323 call flow

H.323 is a connection oriented peer-to-peer protocol. If the H.225 TCP connection

between CCME and Gateway routers fails, the on-going calls will also fail. [9,288, 558]

CALL PROCEEDING

H.225 TCP Connection

ALERTING

SETUP

CONNECT

RELEASE COMPLETE

RELEASE COMPLETE

TCP Keepalives

WAN

CCME GATEWAY

FXSFXS

10

SIP

Session Initiation Protocol (SIP) is a relatively new VoIP call control protocol, defined

by IETF in March 1999 (RFC 2543), and updated in June 2002 (SIPv2, RFC 3261). SIP

is evolving and quickly catching up H.323 features, but is still lacking especially the

fabulous VoIP wholesale services of H.323 for service providers. SIP is also a peer-to-

peer protocol, meaning that the main components of a SIP network, so called agents

have high intelligence features. [2,37-38]

The origin of Session Description Protocol (SDP, RFC 2327) was in multicast sessions,

but it is commonly used in SIP to carry connection, that is session establishment

messages. SDP messages are carried by Session Announcement Protocol (SAP)

messages. [22,163-171]

The main two SIP components are clients and servers, or more precisely described as

SIP User Agent Client and User Agent Server. The client is always the one initiating a

connection to the server. Thus any such device can be a client, or a server, even

simultaneously. Other SIP components include SIP Proxy Server providing user agent

registration services, SIP Redirect Server providing the SIP client with the next hop

information to reach the destination, and SIP Registrar Server where the clients register

using there unique SIP address.

SIP messages are transferred in Hyper Text Transfer Protocol (HTTP) format, which is

one of its strengths. HTTP a simple protocol and is routed practically everywhere. SIP

messages follow the Simple Mail Transport Protocol (SMTP) e-mail-format-type

address notation and are transmitted in addition to UDP and TCP, using ports 5060 and

5061, or encapsulated in the Transmission Layer Security protocol (TLS). SIP agents

can be addressed using DNS services as well, which makes it ideal in Internet and

Intranet environments. A simple SIP call flow is illustrated in Figure 2.

11

Figure 2. IP phone originated SIP Call flow

The message 180 Ringing is optional and can be preceded by a hop-by-hop specific

message 100 Trying. [22,17-18,108-109]

Cisco IOS gateways support H.323, SIP and MGCP (Media Gateway Control Protocol,

which is beyond the scope of this lab). H.323 support is enabled by default in dial-peers,

which is why SIP support must be enabled case by case.

G.711 and G.729

Cisco 7960 and 7912G IP phones support two voice codecs, G.711 and G.729, whereas

Cisco IOS dial-peers and voice-ports support various other codecs. However, testing

them in our lab is not practical, because the 2600XM routers available do not have the

necessary hardware (DSP module) for additional transcoding. G.711 is a basic PCM

voice codec and other codecs, such as G.729 only compress the G.711 generated PCM

stream. PCM encoding takes less than a millisecond, but that additional compression by

another codec causes a small additional delay, depending on the DSP hardware and

load. Typically it is between 3 and 10 ms in Cisco equipment.

One DSP output corresponds to 10 ms of speech, but this small packet size is too

unpractical for transmission. Therefore a Cisco default VoIP packet payload contains

WAN

CCME GATEWAY

180 RINGING

INVITE

200 OK

ACK

BYE

200 OK

MEDIA SESSION

100 TRYING

FXSFXS

12

two DSP outputs per packet, for example 20 ms of speech per RTP segment, for

example 160 bytes per packet using G.711 codec (8000 samples/s x 8 bits/sample = 100

DSP outputs/s x 80 bytes/output x 8 bits/byte = 50 RTP datagrams/s x 160

bytes/datagram = 64 kbit/s) and 20 bytes per packet using G.729 codec (100 DSP

outputs/s x 10 bytes/output x 8 bits/byte = 50 RTP datagrams/s x 20 bytes/datagram =

8000 bits/s). Two DSP outputs per RTP datagram means 20 ms of speech per RTP

datagram. The Cisco IOS does not provide packet size adjustment. Instead, the length of

the sampled speed (the number of DSP outputs) per packet can be adjusted, for example

in increments of 10 ms of speech per packet.

The amount of DSP outputs per RTP datagram is one fundamental parameter for the

required VoIP bandwidth, not only the used codec. The more speech per packet, the

fewer packets are needed, and thus less overhead as well. RTP header adds 12 bytes per

datagram, the UTP adds 8 bytes per datagram, the IP adds 20 bytes per packet, the

Ethernet frame header and trailer add 14 bytes per frame, and the PPP header adds 6

bytes per frame. Table 1 illustrates the required bandwidth in some sample cases,

including also the RTP header compression.

Table 1. Bandwidth consumption, some samples with and without compression

Codec

Voice

packet

[ms]

Payload

BW

[kbit/s]

Payload

bytes /

packet

Number

of

packets

per

second

RTP/

UDP/

IP header

[bytes]

RTP

header

compr.

[bytes]

Ether

header

[bytes]

PPP

header

[bytes]

Total

BW

[kbit/s]

no

compr.

Total

BW

[kbit/s]

with

compr.

G.711 20 64 160 50 40 4 14 85,6 71,2

G.711 20 64 160 50 40 4 6 82,3 68,0

G.711 40 64 320 25 40 4 14 74,8 67,6

G.711 40 64 320 25 40 4 6 73,2 66,0

G.729 20 8 20 50 40 4 14 29,6 15,2

G.729 20 8 20 50 40 4 6 26,4 12,0

G.729 40 8 40 25 40 4 14 18,8 11,6

G.729 40 8 40 25 40 4 6 17,2 10,0

13

Voice Activity Detection

Voice Activity Detection (VAD), or silence suppression, helps saving the precious

WAN bandwidth by stopping sending RTP packets filled with silence or when the input

speech or noise level is below a certain point, which in Cisco routers is -78 dBm. VAD

functionality examines the input voice level and in case of absence of adequate

analogue voice signal, the DSP (or a voice port or a dial-peer) sends an "enter silent

period" notification message to the remote end. The remote end then generates white

noise, so called "comfort noise", instead of the missing RTP packets, until a new RTP

packet arrives again. 2600XM series routers IOS have no adjustments for VAD

parameters, but dial-peers have a configuration command to turn VAD on or off (no vad), and the default is on.

There is a small delay after the signal level goes down below the reference level, before

the VAD starts operating, so it does not harm the ends of the words or phrases of a

speaker. However, there are some inherent problems with the VAD: the VAD cannot

distinguish between a speech and a background noise. The second drawback is that the

voice level must first reach the reference level for the VAD to start sending the RTP

flow again, leading to a typical so-called front and speech clipping. The beginning of a

talk spurt can be truncated, causing the first syllable of speech to be lost. See Figure 3.

Figure 3. VAD Front and Speech Clipping

VoiceLevel

Time

Speech Bursts

VAD activation level

VAD Operation~200 ms

Delay

Front andSpeech Clipping

Background Noise

14

This clipping can be perceived easily, but is not so harmful after one gets used to it.

However this phenomenon may cut the front ends of VoIP modem or fax data packets,

clipping of their header information etc. [1,178;9,402]

Cisco IOS Dial-Peer Matters to be Considered

Matching with a Dial

Dial-peers are used for call routing, both for outgoing and incoming VoIP calls. Dial-

peers are part of a system dial-plan and any call establishment; either outgoing or

incoming dial must have a matching dial-peer for a successful call connection at a

gateway IP interface. Voip-dial-peers have connectivity with the IP network and pots-

dial-peers have connectivity with the traditional telephony network. The origin of an

outgoing call is sometimes called an A-subscriber (line number), thus meaning the same

as Caller ID line number. The incoming call is directed to a B-subscriber (line number),

thus meaning the same as Called ID line number.

According to the lab work instruction examples, the Cisco IP phones are assigned two

virtual phone line extensions: 301 and 302. The POTS analog phone lines are assigned

numbers 707 and 808. These line extension numbers are used together with the router IP

interface addresses to find a matching dial-peer for a call establishment. See Figure 4,

illustrating a simplified lab network configuration.

Figure 4. Lab network diagram

WAN10.0.4.1/24 10.0.4.2/24

s0/0 s0/0

IP

IP 302IP 301

IP

POTS 7071/0/11/0/0

FXSFXS

POTS 808

CCME2600XM

s0/0

fa0/0 10.0.4.0/24

2600XMGATEWAY

15

The analog phone lines connected to our Gateway router (dial-peer voice # pots) are not linked however with the VoIP dial-peer configurations of the Gateway

router (dial-peer voice # voip, called voip-dial-peer in general in this

document). Pots-dial-peers are local analog phone lines and voip-dial-peers are for

remote phone connections over an IP network, and any combination for a call

connection between these dial-peers is basically possible (except that our simple

configuration does not allow so-called hair-pinning from voip-dial-peer to voip-dial-

peer over the same IP interface). Please note that in this simple network configuration

you cannot make a call from the Gateway router extension 707 to a CCME IP phone

line 302, or between extensions 808 and 301.

Voip-dial-peers match the remote phone extension line number with a remote host IP

address. The session target IP address is used for directing the outgoing VoIP call to a

destination IP host, but has no importance in receiving a call. The destination-pattern of

a voip-dial-peer is used to match with a remote phone extension Called ID number for

outgoing calls. For incoming calls, the voip-dial-peer destination-pattern is matched

with remote Caller ID. Our lab system is small and the configuration otherwise quite

simple, but the voip-dial-peers have certain complexity, because of different voice

codecs (G.711 and G.729) and gateway protocols (H.323 and SIP) mixed.

When calling from a gateway router to the CCME, the gateway router must choose one

voip-dial-peer for this outgoing VoIP call. The selection is based on voip-dial-peer

destination-pattern configuration. In our example, when Called ID is 301

(CCME ephone-dn 1), the gateway router chooses voip-dial-peer 301, because the

destination-pattern matches with a dialled number. When Called ID is 302 (CCME

ephone-dn 2), the gateway router correspondingly chooses voip-dial-peer 302. Voip-

dial-peer 301 is defined as a H.323 dial-peer and voip-dial-peer 302 is defined as a SIP

dial-peer. When there are multiple dial-peers with their destination-patterns matching a

dialed string, Cisco IOS chooses the dial-peer with a longest match, unless manipulated

by e.g. a preference command. See Figure 5 and Figure 6. [7,179-244]

16

Figure 5. Dial-peer configuration

Figure 6. Lab dial-peer reference connections

CCME router configuration

interface FastEthernet0/0

ip address 10.0.4.1 255.255.255.0 secondary

dial-peer voice 700 voip

destination-pattern 7..

session target ipv4:10.0.4.2

codec g711alaw

dial-peer voice 800 voip

destination-pattern 8..

session protocol sipv2

session target ipv4:10.0.4.2

ephone-dn 1

number 301

ephone-dn 2

number 302

ephone 1

mac-address 000C.851C.E87C

type 7960

button 1:1

GATEWAY router configuration

interface FastEthernet0/0

ip address 10.0.4.2 255.255.255.0

voice-port 1/0/0

voice-port 1/0/1

dial-peer voice 301 voip

destination-pattern 301

session target ipv4:10.0.4.1

codec g711alaw

dial-peer voice 302 voip

destination-pattern 302

session protocol sipv2

session target ipv4:10.0.4.1

dial-peer voice 707 pots

destination-pattern 707

port 1/0/0

dial-peer voice 808 pots

destination-pattern 808

port 1/0/1ephone 2

mac-address 000C.851C.E76B

type 7960

button 1:1

IP 302

IP 301 POTS 707

POTS 808

GATEWAY RouterCCME Router

2600XMRouter

Platform

2600XMRouter

Platform

CCMEIOS Call

Processing

IP

IPDial-peer 302 voip

Dial-peer 301 voip

FXSPOTS-module

Dial-peer 800 voip

Dial-peer 700 voip

Dial-peer 20002 potsVirtual port 50/0/2

Dial-peer 200001potsVirtual port 50/0/1

Dial-peer 707 potsVoice port 1/0/0

Dial-peer 808 potsVoice port 1/0/1

17

The chosen voip-dial-peer has a session target IP address and a session protocol

parameters defined, which will be used in a call establishment. Then the receiving IP

interface with the session target IP address must have such a voip-dial-peer configured,

which matches with the caller ID and used codec. Other type of voip-dial-peers is

possible also, for example this lab work instruction has a voip-dial-peer with incoming called-number defined for receiving calls.

A dot in a destination-pattern string is a wild card digit, that is a destination-pattern 7..

matches then with all the three digit strings from 700 to 799. A default codec in a voip-

dial-peer is G.729. An IP address of a voip-dial-peer session target is pointing to a

destination IP interface, in other words to the other end of the voip call connection.

The CCME must use one of its voip-dial-peers to receive the incoming VoIP call from

the gateway router. In our simple network configuration, the CCME has only one H.323

voip-dial peer (dial-peer voice 700 voip) and one SIP voip-dial-peer (dial-peer voice 800 voip). The CCME tries to connect the incoming SIP call to its

voip-dial-peer 800 (session protocol sipv2), with the destination-pattern 8.. then allowing incoming calls from Caller ID extensions 800-899, remember that

these simple voip-dial-peers are used for both outgoing and incoming calls. Therefore

the CCME is able to receive SIP calls from A-subscribers with extension numbers from

800 to 899. Correspondingly, our CCME is able to receive H.323 calls from Caller ID

extensions 700 to 799 only. Our gateway router is able to receive SIP calls with the

voip-dial-peer 302 only, thus from extension 302 (destination-pattern 302 at the

voip-dial-peer 302) and H.323 calls from extension 301 only (destination-pattern 301 at the voip-dial-peer 301).

CCME Extension Lines

Ephone-dn # number represents a CCME line extension number, ephone #

representing a physical IP phone equipment. The voice-port represents a physical POTS

phone interface. Dial-peer voice pots ties a POTS phone line number

18

(destination-pattern string) and an FXS physical port (port 1/0/x) together. IOS

command show dial-peer voice [summary] shows configured dial peers on the

routers. In addition it will show the system-defined dial-peers on CCME for the

registered IP phones with the tag numbers starting from 20000 and session targets

starting from 50/0/1. The user cannot modify these system-defined parameters.

Digit Manipulation

In Task 2. of the lab exercise you will practice digit manipulation using also command

num-exp. You have to modify or create a new voip-dial-peer for more complicated

num-exp configurations than in the sample configuration, because there must always

exist a dial-peer with matching destination-pattern for the dialed digits, in spite of the

different sent Called ID digits. When a user starts dialing, CCME will not know which

dialed numbers are going to follow, therefore a matching destination-pattern is always

needed for any dial for all the dialed digits, or otherwise the CCME will not accept the

dial string.

Echo

Echo can be defined as a signal leaking from an analog phone line transmit path to a

receive path of the same line. The longer the delay back to the speaker's ear on the other

end of the conversation, the more annoying it is. A small echo is comfortable and even

desired, so one can hear oneself speaking, which is known as sidetone, but this is not

perceived as a disturbing echo. The usual source for an echo is the hybrid transformer,

sometimes called 2-to-4-wire balancing hybrid, where a mismatch degrades the echo

return loss. When the signal leaks to another line, the phenomenon is called a crosstalk.

This leak, echo or crosstalk is always caused on analog circuits. Digital circuits are not a

source of this problem. In VoIP systems, the source of echo is the POTS gateway.

[8,32-37]

Linear echo cancellation uses look-up tables to find traces of transmitted outgoing

signal in the received input one, and then compensates the perceived echo digitally.

19

VoIP systems suffer from jitter and severe jitter will hamper echo canceller's operation,

which is one reason for the need of an effective jitter timing recovery feature at a POTS

interface [25, s. 54-55]. Echo canceller circuits have their limits, in echo delay (time

window) and strength (audio level), which is called echo canceller coverage.

FXS interfaces have analog line ports that are sources for echo, which is caused by

impedance mismatch in 2-wire/4-wire balance hybrid. VoIP systems typically suffer

more from this echo than a PSTN system would, because of relatively greater delays

experienced in VoIP networks. A long delay makes the echo more discernible.

Therefore a proper echo cancellation is mandatory in analog voice ports in VoIP

systems. Logically this is a subject of a pots voice dial-peer of a gateway router.

Proper Quality of Service measures reducing jitter help in this way to cope with the

echo as well. Cisco POTS interfaces make the echo cancellation on its DSP, providing

the best feasible solution [1,175]. An irritating echo in our VoIP lab system can be a

consequence of an incorrect or unfeasible input gain and output attenuation parameter

adjustment on FXS analog voice-ports: too high output level together with too sensitive

input increases echo. The Cisco router IOS also has some echo canceller coefficient

adjustment parameters, which can be inspected by a student lab work group, with time

and interest. Unfortunately the instructions cannot be incorporated into this limited

technical note.

20

Part Two: Quality of Service

Lack of Bandwidth

The quality of real-time voice and video traffic depends not only on the end devices, but

also on the transmission path between the end points. The measures, in order to keep the

necessary level of quality of a voice or video connection, are called Quality of Service

(QoS). Congestion means a situation, where an equipment output interface has more

data to be sent than it can handle at that particular moment. Congestion thus means a

momentary lack of bandwidth, which may not be harmful for most of the network traffic

but may deteriorate the quality of real-time transmission, such as voice and video.

There are several components that affect the quality of a voice connection. These traffic

characteristics can be categorized into three main parameters: delay, jitter and packet

loss. All these symptoms are somehow caused by a lack of bandwidth on the line and

now you must understand that the available bandwidth for, say, a voice call is usually

not any fixed value during a call. The available bandwidth always depends on the other

traffic and momentary load of every single point along the voice path.

When a lack of bandwidth is a frequent problem, you can often hear the saying "just get

more bandwidth", but this is often not a proper cure for a lack of voice bandwidth. It is

because the IP traffic in modern networks tends to consume all the available bandwidth,

the more there is this precious bandwidth by nature, the more the file downloads or web

browsing consumes it. A few seconds’ delays or even some packet drops cannot be

noticed in web browsing, but can be disastrous for a voice call. Because of that burst

nature of the IP traffic, just increasing the network bandwidth may not increase an

available bandwidth for voice calls at all at certain moments. In addition, adding

bandwidth is a costly cure for congestion problems.

21

Cure for Lack of Bandwidth

Instead of increasing the overall network bandwidth, the administrator has other

possibilities for helping the voice packets getting through successfully. One method is

compression, which saves the used bandwidth, but does not give any priority for voice

packets yet. However it helps them getting through. The second tool is call admission

control, limiting the number of voice calls connected through a line preserving the

bandwidth for the previous calls connected. It is possible to reserve a certain amount of

bandwidth for voice calls over a line, but what happens when all that bandwidth is

already in use and a new call arrives without any call admission control? The new call

will be passed in with the result that all the existing calls on that shared line will suffer

thereafter from a lack of shared bandwidth. There are several methods for call

admission control: for example gatekeepers are often used for this.

The third tool is called queuing. By means of this tool an administrator is able to give a

priority to voice packets, letting them pass through a line before other traffic that has

time to wait for its turn, for example file transfer of web browsing. Queuing is called

congestion management, or scheduling, meaning how to supervise congestion

situations. This requires that the traffic must first be classified, in order to decide how to

treat the different packets during congestion. After traffic classification, the individual

packets of different classified traffic categories can be marked according to the classes

they belong to. Congestion management features are then able to treat the different

packets as needed. Sometimes it is better to do something before congestion happens,

and this is called congestion avoidance. These congestion management and avoidance

methods will be the main part of the practical studies in this lab exercise.

Several congestion management and avoidance methods have to be used together.

Intelligent queuing functionalities do not help when a jumbo-size data packet has just

arrived a tiny fraction of a second before a busy small voice packet. The voice packet

has to wait during the transmission of this entire data packet, unless the data packet or a

frame is cut in the smaller pieces (fragmented) before placing it in an output queue. The

22

small voice packet can then be interleaved between two small fractions of the data

packet.

Packet (or link) fragmentation and interleaving (LFI) is called also as a link efficiency

measure. Large jumbo size-packets are split into smaller pieces, and busy VoIP packets

can then be inserted in between. PPP multilink is a Cisco IOS feature able to fragment

and interleave layer 2 frames also in one single interface. LFI also has a drawback: it

does not save any bandwidth. Instead the LFI consumes it more because of the

increased number of frames. Thus the increased number of header bytes, but usually the

pros override the cons.

Other link efficiency methods are TCP header compression, reducing TCP/IP header

size from about 40 bytes down to 3 to 5 bytes. The RTP header compression reduces

RTP/UDP/IP header size from 40 bytes to 2 or 4 bytes. In these cases the "compression"

means actually refraining from sending identical information from packet to packet, for

example port numbers and IP-addresses and so forth.

Policing and shaping, also called traffic conditioning, mean methods that artificially

limit the available bandwidth. The consumed bandwidth is calculated as average

bandwidth consumption over a configured time interval. Policing is called a "hard"

method because it drops excess packets. It is usually used at an ingress point of a

network or an equipment, which means the amount of traffic let into the network.

Policing can be performed at ingress or egress ports. Shaping is called a "soft" method,

because is stores excess traffic to be sent later on, usually for avoiding the excess traffic

to be dropped somewhere else on the path to the destination. Shaping can be performed

at egress ports only, but can be combined together with other queuing reasons.

Shaping (and policing too) can be used to remark traffic as well. The idea is to mark the

priority, or a so-called dropping preference to be utilized in some other point on the path

to the destination. One such packet (or frame) dropping point can be another policing

interface, or for example Weighted Random Early Detection (WRED) configured

interface, where earlier remarked preference of a packet is used in selecting the dropped

23

packets in case of congestion. Instead of simply dropping an excess traffic violating the

bandwidth rules, an operator may remark the packet as an outlaw packet that will be

dropped first in case of congestion at some later point of the path to the destination.

Delay

Delay means the time a packet needs to pass the network from one end to another. A

long delay in speech conversation is annoying. The ITU-T G.114 standard recommends

no more than 150 ms end-to-end one-way delay (for degraded services, such as over

satellite links, the delay can be up to 400 ms). A delay caused at different points of a

voice call path can be fixed or variable.

Following factors cause fixed delay:

- A voice codec (time needed to encode and compress the voice samples) depends on

the selected codec type, but on the equipment performing the coding and compression

as well. Choosing a codec can control coding delay and the number of voice samples

placed in one single voice packet. A typical voice packet contains 160 samples, thus

taking 20 ms to be collected (8000 samples taken per second) and the compression

taking between 4 and 10 ms (depends on the type and load of a DSP).

- Serialization (placing a packet on a serial line) depends on the size of a layer 2 frame

and line speed (delay = packet size / line speed). The voice packet size affects the

serialization delay, but so does the line speed (remember that the line speed is not

always the same as a bandwidth, which can be set to a lower value). The serialization

delay of a jumbo-size data packet causes long queuing delay for a voice packet behind.

Packet fragmentation (and interleaving) is an effective cure for this.

- Propagation (transfer of bits through the serial line) depends on the length of a

connection and a medium used, typically about 0.7 times the speed of light on copper

wires (delay = length of wire / speed of electricity). Light propagates on fiber optic

cables faster than the signals on copper wires, but a shorter route is always preferred.

24

Variable delay is caused by:

- Queuing (a packet has to wait behind another packet for its turn to be transmitted)

depends on the number and size of packets in a queue ahead of the packet considered.

Queuing delay is one delay component most complicated to be administered. Queuing

methods and queue sizes can be controlled, but the longer the allowed queue where a

packet is placed, the longer a packet may have to wait for its turn to be transmitted. The

smaller the maximum size of the queue is, the smaller the maximum time for queuing is

as well. On the other hand, the greater will the chances then be that the packet could be

dropped because of a queue overflow.

- Forwarding and processing (a network device needs time to move the packet from

input port to output port or output queue), depends on the equipment load and packet

handling characteristics. There is not much to do for this; choosing faster equipment is

better.

- Shaping (controlling the consumed bandwidth at an equipment output port) depends

on the shaping configuration and the time a packet has to wait for its turn to be

transmitted. This is closely related with queuing as a congestion management, but in

this case for avoiding packet drops later on, although no congestion happened at the

point of shaping. It is important to understand this small difference between queuing

and shaping.

- De-jitter buffer play out (storing some voice packets at receive end in order to

minimize jitter) depends on the equipment characteristics, but can be an adjustable

parameter.

Jitter

Jitter means the uneven arrival of packets and depends on the variable delay

components on the end-to-end path. Cisco recommends no more than 30 ms of jitter for

25

real-time voice and video. All the methods affecting variable delay have an effect on

jitter as well, but a rule of thumb is that the smaller the maximum delay at any point of a

transmission path, the smaller the maximum jitter at that point as well. Remember that

small queue sizes can cause more frequent packet drops, and therefore the effective

queuing methods are essential. Jitter can be reduced by de-jitter buffering at receiving

end, but this increases the average overall delay.

Jitter and packet drops can be observed in this lab exercise using Ethereal RTP stream

statistics. See the subsection Ethereal Network Protocol Analyzer.

Packet Drops

Packet (or frame) drops may happen because of equipment malfunction, or bit errors on

the line, but the most important cause is a buffer (or queue) overflow at any point in the

end-to-end connection. Sometimes a packet has got a place in a queue, but has to wait

there for too long a time, because too many other packets have priority to get

transmitted first, or the other packets are just so large that sending them first takes too

long a time and the packet considered times out and is dropped. A packet drop caused

by buffer or queue overflow is called a tail-drop.

One more reason for packet drops is intentional policing. This should be avoided by

proper traffic shaping or queuing, because normally policing is done by another

organization (such as service provider) and those methods base packet drop decisions in

quite rough categories. The user does not usually notice a lost of one 20 ms voice

datagram [21,285].

There is no reason to resend lost packets of a voice call, because generally there is no

time to do this. It is too late to resend a lost packet when it is timed out, because the

next packets have already been sent and the lost packet left behind could not be used

any longer [21,281,285]. This depends on the de-jitter buffer as well. That is why UDP

is adequate for transporting RTP segments. Important is only the timely manner and

correct order of received voice packets.

26

Differentiated Service Code Point

RFC 2474 defines the 6-bit Differentiated Services Field (DS Field) in the IPv4 and

IPv6 ToS-byte headers. The three leftmost bits of the DSCP bits can be used for Class

of Service CS1 to CS7, or alternatively the six DSCP bits can be used to mark the IP

packet with a DSCP value 0 to 63. These CS and DSCP markings can be used side-by-

side, DSCP giving just more granularity. [20; 23,57]

DSCP 46 has a special position in this scenario. It is called an Expedited Forwarding

(EF) and is a recommended class for latency-sensitive traffic (FC 2598), such as real

time voice. DSCP 46 corresponds to ToS bits 101110. RFC 2597 defines Assured

Forwarding (AF) classes for various different classes of traffic, from AF11 to AF43,

which are called also dropping preferences. A lower preference packet will be dropped

before a higher preference packet in case of congestion.

AF numbering scheme is somewhat complicated, because the six DSCP bits are split

into three, e.g. AF31 corresponds to DSCP bits 011010 => 011 01 0, (i.e. 3, 1 and 0).

The binary value of 0110102 corresponds to a decimal value of 2610, thus DSCP 26 and

AF31 mean the same. Another example will clarify this further: DSCP bits 100010

correspond to DSCP 34, which corresponds to AF41 (100 01 0 => 4, 1 and 0). AF1x

thus corresponds to IP precedence or Class of Service 1, AF2x corresponds to IP

precedence 2 or Class of Service 2 and so forth.

There is a caveat in using DSCP; a malicious packet marking may exploit the

preferential queuing and dropping treatment assigned for latency-sensitive voice and

video, disturbing them severely. There is no method of authenticating DSCP marking,

thus the operator must rely only on its own marking. Therefore remarking the traffic at

an ingress point is often necessary.

27

Weighted Random Early Detection

Weighted Random Early Detection (WRED) is a method of congestion avoidance,

dropping packets selectively before congestion occurred. Selection is typically based on

the type of traffic, or DSCP value, that is on classification. Different types of traffic

flows are placed on their own queues. Typically, a critical real time traffic such as voice

or video RTP packets are given priority and will be dropped only after a severe router or

switch interface congestion. Packets of less time sensitive traffic, like web browsing,

will more likely be discarded. WRED is then an essential part of class based shaping

oriented traffic management.

Selective packet discard is a good method avoiding TCP global synchronization. This

problem occurs when TCP packets are dropped from several different TCP flows

simultaneously, because of common point of congestion. TCP sliding window control

drops then down the transmission releasing bandwidth on the congested link. This

sounds good, but these simultaneous TCP flows also start increasing the sliding window

at the same pace, causing soon another congestion, leading to packet drops from all the

TCP flows again. Selective discard of packets from one flow only at the time helps

equalizing the shared bandwidth between different flows, in addition to the better

treatment for sensitive traffic.

WRED is not examined in this lab exercise, because of the complexity of testing and

perceiving its functionality, but it is a powerful tool in traffic management. It is an

important part in Cisco's QoS architecture.

Low Latency Queuing

Cisco recommends Low Latency Queuing (LLQ) to guarantee short delays for voice

packets. Giving sovereign priority for voice packets over other network traffic during

congestion ensures the objective of small delay, and ensures also small jitter and

minimal packet drops. Cisco Express Forwarding (ip cef) in a router must be enabled

too for correct LLQ operation.

28

High priority traffic, such as RTP, is given its priority by classification, in Cisco IOS

class-map configurations. Packet (or traffic) marking and other packet (or traffic)

manipulation is realized by Cisco IOS policy-map configurations. Differentiated

Services Code Point (DSCP) is typically used in marking the packets. Cisco IOS policy-

maps are attached to an interface by an IOS service-policy. See the example below in

Figure 7. Traffic classification in a class-map could be based on DSCP values as well;

marking could be done at an ingress-point of a router, and shaping at an egress-point.

[20]

Figure 7. Low Latency Queuing with class-based traffic classification, marking, shaping and policing

Low Latency Queuing is specified by the use of the parameter priority in one of the

classes in a policy-map. This class receives the specified guaranteed priority bandwidth

class-map match-all RTP

match protocol rtp

match access-group 101

class-map match-all WEB

match protcol http

policy-map VOIP

class RTP

priority 90

set dscp ef

class WEB

bandwidth 60

class class-default

police 20000

random-detect dscp-based

interface Serial0/0

service-policy output VOIP

access-list 101 permit ip 10.0.3.0 0.0.0.255 any

Traffic shaping (conditioning), 90 kbit/s.

Traffic marking, Expedited Forwarding (DSCP 46).

Policing unclassified traffic, max limit 20 000 bit/s.

System defined ”class-default” for unclassified traffic.

IP access-list for selecting the source hosts etc.

Applying the policy in interface output direction.

WRED configuration for selecting the dropped packetswithin the class-default traffic flows.

Traffic shaping, 60 kbit/s.

Traffic classification, based on protocol.

Traffic classification, based on protocoland access-list.

29

during congestion and will be serviced before traffic of other classes. A simpler

parameter bandwidth in a class assigns a relative share of the total bandwidth of the link

only, not a guaranteed absolute bandwidth. Priority bandwidth can be assigned to one

class only, and this parameter priority also limits the bandwidth for this class to this

specified value in case of congestion. In other words, this configuration makes two

assignments at a time for the class concerned during congestion: it provides the class

with a guaranteed bandwidth, but on the other hand polices the maximum allowed

bandwidth to the same value. [8,66-68]