Attachement 1. VoIP Lab: Cisco CallManager Express, Theoretical Background

Transcription

1 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 SIP 79 G.711 and G 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 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 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 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 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 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 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 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 b 150k -u -l 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 to (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 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 to (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, ] 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 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 endto-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 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. CCME GATEWAY WAN FXS H.225 TCP Connection SETUP CALL PROCEEDING ALERTING CONNECT TCP Keepalives RELEASE COMPLETE RELEASE COMPLETE 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]

10 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-topeer 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, ] 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) -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 11 CCME GATEWAY WAN FXS INVITE 100 TRYING 180 RINGING 200 OK ACK MEDIA SESSION BYE 200 OK 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, ] 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

12 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 ,6 71,2 G ,3 68,0 G ,8 67,6 G ,2 66,0 G ,6 15,2 G ,4 12,0 G ,8 11,6 G ,2 10,0

13 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. Voice Level Speech Bursts VAD activation level Front and Speech Clipping Background Noise ~200 ms Delay VAD Operation Time Figure 3. VAD Front and Speech Clipping

14 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. Dialpeers 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 potsdial-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. CCME 2600XM / /24 WAN s0/0 s0/0 s0/0 fa0/ /24 GATEWAY 2600XM FXS 1/0/0 1/0/1 POTS 707 POTS 808 IP IP IP 301 IP 302 Figure 4. Lab network diagram

15 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-dialpeer 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. Voipdial-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, ]

16 16 CCME router configuration GATEWAY router configuration interface FastEthernet0/0 ip address secondary interface FastEthernet0/0 ip address dial-peer voice 700 voip destination-pattern 7.. session target ipv4: codec g711alaw dial-peer voice 800 voip destination-pattern 8.. session protocol sipv2 session target ipv4: ephone-dn 1 number 301 ephone-dn 2 number 302 ephone 1 mac-address 000C.851C.E87C type 7960 button 1:1 ephone 2 mac-address 000C.851C.E76B type 7960 button 1:1 voice-port 1/0/0 voice-port 1/0/1 dial-peer voice 301 voip destination-pattern 301 session target ipv4: codec g711alaw dial-peer voice 302 voip destination-pattern 302 session protocol sipv2 session target ipv4: dial-peer voice 707 pots destination-pattern 707 port 1/0/0 dial-peer voice 808 pots destination-pattern 808 port 1/0/1 Figure 5. Dial-peer configuration CCME Router GATEWAY Router CCME IOS Call Processing 2600XM Router Platform 2600XM Router Platform FXS POTS-module IP Dial-peer pots Dial-peer 707 pots Dial-peer 700 voip Dial-peer 301 voip Virtual port 50/0/1 Voice port 1/0/0 IP 301 POTS 707 IP Dial-peer pots Dial-peer 808 pots Dial-peer 800 voip Dial-peer 302 voip Virtual port 50/0/2 Voice port 1/0/1 POTS 808 IP 302 Figure 6. Lab dial-peer reference connections

17 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 voipdial-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 (dialpeer 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 , 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 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 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 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 ]. 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 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 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 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 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 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 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 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-byside, 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 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 => , (i.e. 3, 1 and 0). The binary value of corresponds to a decimal value of 26 10, thus DSCP 26 and AF31 mean the same. Another example will clarify this further: DSCP bits correspond to DSCP 34, which corresponds to AF41 ( => 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 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 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 policymaps 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] class-map match-all RTP match protocol rtp match access-group 101 class-map match-all WEB match protcol http Traffic classification, based on protocol and access-list. Traffic classification, based on protocol. policy-map VOIP class RTP priority 90 set dscp ef class WEB bandwidth 60 class class-default police random-detect dscp-based interface Serial0/0 service-policy output VOIP Traffic shaping (conditioning), 90 kbit/s. Traffic marking, Expedited Forwarding (DSCP 46). Traffic shaping, 60 kbit/s. System defined class-default for unclassified traffic. Policing unclassified traffic, max limit bit/s. WRED configuration for selecting the dropped packets within the class-default traffic flows. Applying the policy in interface output direction. access-list 101 permit ip any IP access-list for selecting the source hosts etc. 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

29 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]