JVC AV IPTEL IMP Service Manual

Avaya IP Telephony Implementation Guide

Communication Manager 2.1 Avaya Labs

ABSTRACT

This application note gives implementation guidelines for the Avaya MultiVantage™ Communications Applications. Configurations and recommendations are given for various Avaya Media Servers and Gateways, as well as Avaya 4600 Series IP Telephones. This document also provides information on virtual local area networks (VLANs), and guidelines for configuring Avaya and Cisco networking equipment in VoIP applications.

The intent of this document is to provide training on IP telephony, and to give guidelines for implementing Avaya solutions. It is intended to supplement the product documentation, not replace it.

This document covers the Avaya Communication Manager 2.0 and 2.1, and the Avaya 4600 Series IP Telephone 1.8 and 2.0, with limited information regarding previous and future versions.

External posting: www1.avaya.com/enterprise/resourcelibrary/applicationnotes/eclips_general.html.

Application Note

August 2004 COMPAS ID 95180

Avaya IP Telephony Implementation Guide

All information in this document is subject to change without notice. Although the information is believed to be accurate, it is provided without guarantee of complete accuracy and without warranty of any kind. It is the user’s responsibility to verify and test all information in this document. Avaya shall not be liable for any adverse outcomes resulting from the application of this document; the user accepts full responsibility.

The instructions and tests in this document regarding Cisco products and features are best-effort attempts at summarizing and testing the information and advertised features that are openly available at www.cisco.com. Although all reasonable efforts have been made to provide accurate information regarding Cisco products and features, Avaya makes no claim of complete accuracy and shall not be liable for adverse outcomes resulting from discrepancies. It is the user’s responsibility to verify and test all information in this document related to Cisco products, and the user accepts full responsibility for all resulting outcomes.

Avaya and the Avaya Logo are trademarks of Avaya Inc. or Avaya ECS Ltd., a wholly owned subsidiary of Avaya Inc. and may be registered in the US and other jurisdictions. All trademarks identified by ® and ™ are registered trademarks or trademarks, respectively, of Avaya Inc. All other registered trademarks or trademarks are property of their respective owners.

SM Avaya IP Telephony Implementation Guide

Foreword

Several benefits are motivating companies to transmit voice communications over packet networks originally designed for data.

Cost saving is one factor. By eliminating a separate circuit-switched voice network, businesses avoid the expenses of buying, maintaining and administering two networks. They may also reduce toll charges by sending long distance voice traffic over the enterprise network, rather than the public switched telephone network.

Another benefit is the potential to more tightly integrate data and voice applications. Because they use open programming standards, Avaya ECLIPS products make it easier for developers to create, and for companies to implement, applications that combine the power of voice and data in such areas as customer relationship management (CRM) and unified communications. A converged multi-service network can make such applications available to every employee.

These benefits do not come free, however. Voice and data communications place distinctly different demands on the network. Voice and video are real-time communications that require immediate transmission. Data does not. Performance characteristics that work fine for data can produce entirely unsatisfactory results for voice or video. So networks that transmit all three must be managed to meet the disparate requirements of data and vo ice /video.

Network managers are implementing a range of techniques to help ensure their converged networks meet performance standards for all three payloads: voice, video and data. These techniques include the strategic placement of VLANs, and the use of Class of Service (CoS) packet marking and Quality of Service (QoS) network mechanisms.

For an overview of IP telephony issues and networking requirements, see the “Avaya IP Voice Quality Network Requirements” white paper at www1.avaya.com/enterprise/resourcelibrary/applicationnotes.

Professional consulting services are available through The Avaya Business Communication Solutions and Integration group. One essential function of this professional serv ices g roup is to prov ide pre- deployment network assessments to Avaya customers. This assessment helps to prepare a customer’s network for IP telephony, and also gives critical network information to Avaya support groups that will later assist with implementation and troubleshooting. Arrange for this essential service through an Avaya account team.

SM Avaya IP Telephony Implementation Guide

Avaya IP Telephony Implementation Guide

Table of Contents

1 Introduction to VoIP and Avaya Products.............................................................................................7

1.1 Servers, Gateways, Stations, and Trunks Defined......................................................................7

Servers ........................................................................................................................................7

Gateways.....................................................................................................................................7

Stations........................................................................................................................................7

Trunks.........................................................................................................................................8

1.2 Avaya Server-Gateway and Trunk Architectures.......................................................................8

Traditional DEFINITY System ...............................................................................................8

IP-enabled DEFINITY System...................................................................................................9

S8700 Multi-Connect................................................................................................................10

S8500 Media Server..................................................................................................................10

S8700 IP-Connect.....................................................................................................................11

S8300/G700/G350....................................................................................................................11

S8700 Multi-Connect with remote G700/350 gateways...........................................................12

S8700 IP-Connect with remote G700/350 gateways................................................................13

S8100/G600..............................................................................................................................13

Trunks.......................................................................................................................................14

1.3 VoIP Protocols and Ports..........................................................................................................15

2 IP Network Guidelines........................................................................................................................16

2.1 General Guidelines....................................................................................................................16

Ethernet Switches......................................................................................................................16

Speed/Duplex............................................................................................................................17

2.2 Bandwidth Considerations........................................................................................................18

Calculation................................................................................................................................18

Ethernet Overhead ....................................................................................................................19

WAN Overhead ........................................................................................................................19

L3 Fragmentation (MTU).........................................................................................................19

L2 Fragmentation......................................................................................................................20

2.3 CoS and QoS.............................................................................................................................20

General......................................................................................................................................20

CoS............................................................................................................................................20

802.1p/Q ...................................................................................................................................21

Rules for 802.1p/Q Tagging .....................................................................................................21

DSCP ........................................................................................................................................23

QoS on an Ethernet Switch.......................................................................................................24

QoS on a Router........................................................................................................................24

QoS Guidelines.........................................................................................................................25

Traffic Shaping on Frame Relay Links.....................................................................................26

SM Avaya IP Telephony Implementation Guide

3 Guidelines for Avaya Servers and Gateways ......................................................................................27

3.1 S8700/8500 Servers..................................................................................................................27

S8700/8500 Speed/Duplex........................................................................................................27

S8700/8500 802.1p/Q and DSCP Tagging...............................................................................28

3.2 S8300 Server.............................................................................................................................28

3.3 S8100 Server (IP600)................................................................................................................29

S8100 Speed/Duplex.................................................................................................................29

S8100 802.1p/Q and DSCP Tagging........................................................................................29

3.4 G700 Media Gateway...............................................................................................................29

P330 L2 Switch.........................................................................................................................30

Media Gateway Processor (MGP)............................................................................................30

SAT Media-Gateway Form.......................................................................................................31

G700 802.1p/Q and DSCP Tagging..........................................................................................31

G700 in Octaplane Stack vs. Standalone..................................................................................32

3.5 G350 Media Gateway...............................................................................................................32

3.6 G600/650, MCC1, and SCC1 Gateways...................................................................................33

C-LAN Capacity and Recommendations..................................................................................33

C-LAN and MedPro Protocols and Ports..................................................................................34

C-LAN and MedPro Network Placement.................................................................................34

C-LAN and MedPro Speed/Duplex..........................................................................................34

C-LAN and MedPro 802.1p/Q and DSCP Tagging..................................................................35

Extreme Measures for MedPro and Other IP Boards on Cisco Switches.................................35

IP Server Interface (IPSI) Board...............................................................................................35

3.7 General IP-Telephony-Related Configurations (SAT Forms)..................................................36

ethernet-options.........................................................................................................................36

node-names ip...........................................................................................................................36

ip-interface................................................................................................................................36

data-module...............................................................................................................................37

ip-codec-set...............................................................................................................................37

ip-network-region.....................................................................................................................37

ip-network-map.........................................................................................................................39

station........................................................................................................................................40

trunk-group and signaling-group ..............................................................................................40

system-parameters ip-options ...................................................................................................41

SAT Troubleshooting Commands ............................................................................................42

4 Guidelines for Avaya 4600 Series IP Telephones...............................................................................43

4.1 Basics........................................................................................................................................43

4606/12/24 Speed/Duplex.........................................................................................................43

30A Base Switch.......................................................................................................................43

Legacy Models vs. Current Mode ls..........................................................................................44

DHCP Option 176.....................................................................................................................44

DHCP Lease Duration ..............................................................................................................45

SM Avaya IP Telephony Implementation Guide

Boot-up Sequence.....................................................................................................................46

Call Sequence............................................................................................................................47

Keepalive Mechanisms.............................................................................................................47

4.2 Connecting a PC to the Phone ..................................................................................................48

IP Phone and Attached PC on Same VLAN.............................................................................49

IP Phone and Attached PC on Different VLANs......................................................................50

4.3 Gatekeeper Lists and DHCP Option 176..................................................................................51

Main Site...................................................................................................................................52

Branch Site................................................................................................................................52

Two Methods of Receiving the Gatekeeper List ......................................................................53

Verifying the Gatekeeper Lists.................................................................................................54

Appendix A: VLAN Primer........................................................................................................................55

Appendix B: Cisco Auto-Discovery...........................................................................................................60

Appendix C: RTP Header Compression.....................................................................................................62

Appendix D: Access List Guidelines..........................................................................................................64

Appendix E: Common IP Commands.........................................................................................................66

Appendix F: Sample QoS Configurations..................................................................................................68

Appendix G: IP Trunk Bypass – TDM Fallback Q&A...............................................................................70

References...................................................................................................................................................73

SM Avaya IP Telephony Implementation Guide

1 Introducti on to VoIP and Avaya Products

This section provides a foundation to build upon for the rest of this document. Voice over IP (VoIP) terminology and Avaya products and architectures are introduced here.

1.1 Servers, Gateways, Stations, and Trunks Defined

Servers

Most of the intelligence in a voice system is in the call server. From servicing a simple call to making complex decisions associated with large contact centers, the call server is the primary component of an IP telephony system. Avaya Communication Manager is the call processing software that runs on Avaya server platforms.

The following are some common terms for a call server. Some are generic and some are specified by a protocol, but all are generally used throughout the industry.

- Call Server – generic term

- Call Controller – generic term

- Gatekeeper – H.323 term

- Media Gateway Controller – H.248 term

Gateways

A gateway terminates and converts various media types, such as analog, TDM, and IP. A gateway is required so that, for example, an IP phone can communicate with an analog phone on the same telephony system, as well as with an external caller across a TDM trunk.

The following are some common terms for a gateway, and they are generally used throughout the industry.

- Gateway – generic and H.323 term

- Media Gateway – H.248 term

- Port Network – Avaya term

A gateway requires a call server to function, and some common Avaya server-gateway architectures are illustrated later.

Stations

There are several technical terms for what most would call a phone, and some that are generally used throughout the industry are listed below.

- Endpoint – H.323 general term that includes IP phones and other endpoints

- Terminal – H.323 specific term to mean primarily IP phones (also an Avaya term)

- Station – Avaya term, and possibly a generic term

- Set – Avaya term, and possibly a generic term

Avaya gateways have port boards or media modules that terminate various types of stations.

SM Avaya IP Telephony Implementation Guide

Trunks

Trunks connect independent telephony systems together, such as PBX to PBX, or PBX to public switch, or public switch to public switch. In traditional telephony there are various types of circuit-switched trunks, using various protocols to signal across these trunks. IP telephony introduces another trunk type – the IP trunk. Like circuit-switched trunks IP trunks connect independent telephony systems together, but the medium is an IP network and the upper-layer protocol suite is H.323.

Avaya gateways have port boards or media modules that terminate various types of trunks, including IP trunks.

1.2 Avaya Server-Gateway and Trunk Architectures

The following figures illustrate some common Avaya server-gateway architectures in succession, from established to most recent technologies. Also included in the diagrams are the protocols used to communicate between the various devices.

Traditional DEFINITY System

Adjunct Location

Analog

EPN

MCC

CCMS and bearer over TDM or ATM

CCMS from pr ocessor

to port boards across

backplane

SCCDCP

Medium/Large Enterprise - Main Location

PPN

Procr

EPN

TDM busTDM bus

MCC

Center St age

or ATM PNC

MCC

EPN

DCP

Analog

Figure 1: Traditional DEFINITY System architecture

- The single- (SCC1) and multi-carrier cabinets (MCC1) are called port networks (Avaya term) or

media gateways (VoIP term). They house port boards, which, among other things, terminate stations and trunks. (These port boards are not the focus of this document.)

- The DEFINITY® call servers are the processor boards inserted into the processor port network

(PPN).

- The other cabinets, without processors, are called expansion port networks (EPN) and are controlled

by the DEFINITY servers in the PPN.

- The port networks are connected together via a port network connectivity (PNC) solution, which can

be TDM-based (Center Stage PNC) or ATM-based (ATM PNC). Both bearer (audio) and port network control are carried across the PNC solutions.

- Control Channel Message Set (CCMS) is the Avaya proprietary protocol used by the DEFINITY

servers to control the port networks (cabinets and port boards).

SM Avaya IP Telephony Implementation Guide

IP-enabled DEFINITY System

Adjunct Location Medium/Large Enterprise - Main Location

IP IP

RTP

audio

Enterprise

IP Network

DCP

Analog

IP Net

DCP

Analog

RTP

H.225

C-LAN

MedPro

MCC

EPN

CCMS and bearer over TDM or ATM

CCMS from processor

to port boards across

backplane

EPN

SCC

PPN

Procr

MCC

Center Stage

or ATM PNC

H.225 - RAS &

Q.931 signaling

C-LAN

MedPro

TDM busTDM bus

MCC

EPN

Figure 2: IP-enabled DEFINITY System

- IP-enabled DEFINITY System is the same architecture as before, but with IP port boards added.

- The Control-LAN (C-LAN) board is the call servers’ interface into the IP network for call signaling.

H.225, which is a component of H.323, is the protocol used for call signaling. H.225 itself has two components: RAS for endpoint registration, and Q.931 for call signaling.

- The IP Media Processor (MedPro) board is the IP termination point for audio. It performs the

conversion between TDM and IP. The audio payload is encapsulated in RTP, then UDP, then IP.

SM Avaya IP Telephony Implementation Guide

S8700 Multi-Connect

Adjunct Location Medium/Large Enterprise - Main Location

IP Net

DCP

Analog

RTP

H.225

C-LAN

MedPro

MCC

CCMS over

TCP/IP

CCMS and bearer over TDM or ATM

s8700 s8700

L2 switch L2 switch

IPSI

SCC

Center St age

or ATM PNC

IPSI

MCC

H.225 - RAS &

Q.931 signaling

Control

IP Network

IPSI

C-LAN

MedPro

TDM busTDM bus

MCC

IP IP

RTP

audio

Enterprise

IP Network

DCP

Analog

Figure 3: S8700 Multi-Connec t

- S8700 Multi-Connect is the same underlying DEFINITY architecture, except that the processor

boards are replaced with much more powerful Avaya S8700 Media Servers.

- Port networks get IP Server Interface (IPSI) boards to communicate with the S8700 call servers.

- CCMS exchanges between the call servers and port networks now take place over the control IP

network.

- Not all port networks require IPSI boards, because Center Stage PNC and ATM PNC are still present

to connect the port networks.

S8500 Media Server

Figure 4: Avaya S8500 Media Ser ver

The Avaya S8500 Media Server is the simplex equivalent of the S8700 server pair. The S8500 gives the same call processing capability without the redundancy and added reliability of duplicated servers. The S8500 can be substituted in any configuration in this section where the S8700 servers are shown. Such a substitution would necessitates the removal of a duplicated IPSI board, where applicable.

SM Avaya IP Telephony Implementation Guide

S8700 IP-Connect

IPSI

C-LAN

MedPro

G650

IPSI

C-LAN

MedPro

G650

S8300/G700/G350

Medium/Large Enterprise

s8700 s8700

Enterprise

IP Network

CCMS over

TCP/IP

H.225

Analog

RTP

audio

DCP

Figure 5: S8700 IP-Connect

C-LAN

MedPro

G650

IPSI

- With S8700 IP-Connect the

traditional port networks – MCC1 and SCC1 – are replaced with new, 19-inch rack-mountable Avaya G600 or G650 Media Gateways.

- All G600/650s require IPSI

boards; no more Center Stage or ATM PNC.

- Everything is done on the

enterprise IP network; no more control IP network.

- G600/650 media gateways still

use C-LAN and MedPro boards, as well as the other traditional port boards used in the MCC1 and SCC1.

- The Avaya G700 and G350 Media Gateways are based on the

H.248 protocol.

- The G700 is tailored for medium size offices, and the G350 is

tailored for small offices. (Refer to current product offerings for exact specifications.)

- Both gateways have built-in Ethernet switches. The G700

supports IP routing and IP WAN connectivity with an expansion module, and the G350 supports them natively.

- The G700 is built on the Avaya P330 Stackable Switching

System, with similar CLI. The G350 is built on a new IP platform, also with similar CLI.

- Both gateways use compact media modules instead of

traditional port boards.

- The VoIP media module serves the same function as the

MedPro board.

- There are other media modules equivalent to traditional port

boards (analog, DCP, DS1).

- The Avaya S8300 Media Server in internal call controller (ICC)

mode is the call server.

- The S8300 is a Linux platform, similar to the S8700, but in a

compact form factor that fits into either gateway.

- The S8300 is not front-ended by C-LANs; it terminates the call

signaling natively.

Small/Mediu m Enterprise

H.225

g700 with

IP IP

H.248 media

gateway control

Ent IP Net

IP IP

DCP

RTP

Analog

s8300 ICC VoIP mod

g700 with

VoIP mod

g350 with

VoIP mod

g700 with

VoIP mod

DCP mod

Analog mod

T1/E1 mod

Figure 6: S8300/G700/G35 0

architecture

SM Avaya IP Telephony Implementation Guide

S8700 Multi-Connect with remote G700/350 gateways

backup H.225

IP Net

Remote Office

backup

H.248

RTP

Analog

L2 switch L2 switch

CCMS

IPSI

SCC

CCMS and bearer over TDM or ATM

Medium/Large Enterprise

s8700 s8700

IPSI

MCC

Center Stage or ATM PNC

H.225 - RAS &

Q.931 sig naling

Control

IP Network

IPSI

C-LAN

MedPro

C-LAN

MCC

IP IP

H.225

RTP

audio

Enterprise

IP Network

IP IP

DCP

Figure 7: S8700 Multi-Connec t with rem ote G700/ 350s

- Remote gateways and stations are controlled by the S8700 servers via the C-LAN boards.

- The remote S8300 is in local survivable processor (LSP) mode to take over as call server if

connectivity to the S8700s is lost.

g700 with

s8300 LSP

VoIP mod

g700 with

VoIP mod

g350 with

VoIP mod

g700 with

VoIP mod DCP mod

Analog mod

T1/E1 mod

SM Avaya IP Telephony Implementation Guide

S8700 IP-Connect with remote G700/350 gateways

Medium/Large Enterprise

s8700 s8700

IPSI

C-LAN

MedPro

G650

C-LAN

MedPro

G650

CCMS over

TCP/IP

IPSI

Analog

Enterprise

IP Network

H.225

DCP

RTP

audio

IPSI

C-LAN

MedPro

G650

H.225

IP IP

DCP

backup H.225

IP Net

Remote Office

backup

H.248

RTP

Analog

Figure 8: S8700 IP-Connect with remote G700/350s

- Remote gateways and stations are controlled by the S8700 servers via the C-LAN boards.

- The remote S8300 is in local survivable processor (LSP) mode to take over as call server if

connectivity to the S8700s is lost.

S8100/G600

g700 with

s8300 LSP

VoIP mod

g700 with

VoIP mod

g350 with

VoIP mod

g700 with

VoIP mod

DCP mod

Analog mod

T1/E1 mod

Small/Medium Enterprise

H.225

Analog

Enterprise

IP Network

DCP

RTP

audio

CCMS from S8100

to port boards

across backplane

S8100 can control

multiple G600s

connected together

S8100 C-LAN

MedPro

G600

Admin

Figure 9: S8100/G600

SM Avaya IP Telephony Implementation Guide

- The Avaya S8100 Media

Server is a PC board that fits into the G600 gateway.

- Multiple G600s can be

connected together and controlled by the same S8100 server.

- The S8100 server is a

Windows 2000 Server platform.

- The upgrade path for the

S8100/G600 is S8500 IPConnect using G650 gateways. There is no S8100/G650 combination.

Trunks

QSIG

H.323 (Q.931)

I P

Call

Manager

DCP

S8300 / G700

Q.931

PRI

DCP

Q.931

PRI

PSTN

Public Switch

SS7

Public Switch

I P

Loop Start

Analog

H.225

Vendor X PBX

H.225

I P

Inband

S8700

G650

QSIG or DCS

Inband

QSIG

Q.931

PRI

QSIG or DCS H.323 (Q.931)

I P

Q.931

PRI

DEFINITY Sy s tem

Figure 10: Trunks

This figure illustrates a broad picture to put trunks into context.

- PSTN trunks use the Signaling System 7 (SS7) signaling protocol. This protocol is not relevant to

private, enterprise telephony systems.

- Private systems, such as the S8700 IP-Connect and DEFINITY servers in this illustration, commonly

connect to public switches using ISDN PRI trunks with Q.931 signaling.

- Two private systems commonly connect to one another using T1 trunks with inband signaling, or

ISDN PRI trunks with Q.931 signaling. This is illustrated in the trunks connecting the DEFINITY server to the S8700 IP-Connect, and to the Vendor X PBX.

- QSIG is a standard, feature-rich signaling protocol for private systems, and it “rides on top of” Q.931

as illustrated between the DEFINITY server and Vendor X PBX. DCS is The Avaya proprietary equivalent to QSIG, which also rides on top of Q.931 as illustrated between the S8700 IP-Connect and DEFINITY server.

- Gatekeepers, such as the S8700, S8300, and Cisco Call Manager in this illustration, can connect to

one another using IP trunks. The medium is IP and the signaling protocol is H.323, but Q.931 is still the fundamental component of H.323 that does the call signaling. And, as with ISDN PRI trunks, QSIG or DCS can be overlaid on top of Q.931.

QSIG is the standard signaling protocol that provides the feature-richness expected in enterprises. Generally speaking, traditional telephony systems support a broad range of QSIG features, while pure IP telephony systems support a very limited range. Due to the history and leadership of Avaya in traditional telephony, all Avaya call servers – whether traditional, IP-enabled, or pure IP – support virtually the same broad range of QSIG features.

SM Avaya IP Telephony Implementation Guide

1.3 VoIP Protocols and Ports

The following figure illustrates the protocol stacks relevant to VoIP. The contents of the upper-layer protocol messages are important to those who develop VoIP applications. However, those who implement these applications are typically not concerned with decoding the upper-layer messages. Instead, they are concerned primarily with the transport mechanism – TCP and UDP ports – so that they can verify and filter these message exchanges.

H.245

CODEC

negotiation

TCP 1720 (gatekeeper)

Q.931 Signaling

L2 - Ethernet, PPP, frame relay, ATM, ...

H.323

H.225

RAS

Registration

UDP 1719

(gatekeeper)

L3 - IP

Audio CODEC

G.711, G.729

RTP

RTCP

UDP pseudo-

random port

H.248

Media Gateway

Control

TCP 2945

(MG controller)

CCMS

Port Network

Control

TCP 5010

(port network)

Figure 11: VoIP protocol stacks

- H.323 is the prevalent VoIP protocol suite. It is used for signaling from gatekeeper to terminals

(stations), and gatekeeper to gatekeeper (trunks).

- H.225 is the endpoint registration (RAS) and call signaling (Q.931) component of H.323.

- H.225 call signaling messages are transported via TCP with port 1720 on the gatekeeper side.

- H.225 registration messages (commonly referred to simply as RAS message) are sent via

UDP with port 1719 on the gatekeeper side.

- H.245 is the multimedia control component of H.323.

- Audio is digitally encoded prior to transmission and decoded after transmission using a coder/decoder

(codec).

- G.711 is the fundamental codec based on traditional pulse-code modulation (PCM), and it is

generally recommended for LAN transport.

- G.729 is a compressed codec, and it is generally recommended for transport over limited-

bandwidth WAN links.

- Encoded audio is encapsulated in RTP (real-time protocol), then UDP, then IP.

- RTP has fields such as Sequence Number and Timestamp that are designed for the transport and

management of real-time applications.

- On Avaya solutions the UDP ports used to transport RTP streams are configured on the call

server.

- Most protocol analyzers can identify RTP packets, making it easy to verify that audio streams are

being sent between endpoints.

- H.248 is a protocol for media gateway control. It is transported via TCP with port 2945 on the media

gateway controller side.

- CCMS is an Avaya proprietary protocol for port network control (same as media gateway control). It

is transported via TCP with port 5010 on the port network (IPSI board) side.

SM Avaya IP Telephony Implementation Guide

2 IP Network Guidelines

This section gives general guidelines and addresses several issues related to IP networks (LAN/WAN) and device configurations.

2.1 General Guidelines

Because of the time-sensitive nature of VoIP applications, VoIP should be implemented on an entirely switched network. Ethernet collisions – a major contributor to delay and jitter – are virtually eliminated on switched networks. Additionally, VoIP endpoints should be placed on separate subnets or VLANs (separated from other non-VoIP hosts), with preferably no more than 500 hosts per VLAN. This provides for a cleaner design where VoIP hosts are not subjected to broadcasts from other hosts, and where troubleshooting is simplified. This also provides a routed boundary between the VoIP segments and the rest of the enterprise network, where restrictions can be placed to prevent unwanted traffic from crossing the boundary. When a PC is attached to an IP telephone, even if they are on separate VLANs, all traffic (including broadcasts) to/from the PC and to/from the phone traverse the same uplink to the Ethernet switch. In such a case the uplink should be a 100M link, and the recommended subnet/VLAN size is no larger than 250 hosts.

Sometimes customers are unable to follow these guidelines, and Avaya solutions can be made to work in some less-than-ideal circumstances. If IP telephones share a subnet with other non-VoIP hosts, they should be placed on a subnet of manageable size (24-bit subnet mask or larger; 254 hosts or less) with as low a broadcast rate as possible. If the broadcast level is high, keep in mind that 100M links are less likely to be overwhelmed by broadcast traffic than 10M links.

On the subject of broadcasts, Avaya media servers and gateways and IP telephones utilize very low amounts of broadcast traffic to operate. Therefore, a subnet/VLAN with only these Avaya hosts has a very low level of broadcasts. There are two cases where Avaya hosts can be subjected to high levels of broadcasts: 1) Avaya hosts and other broadcast-intensive hosts share a subnet/VLAN; and 2) broadcastintensive PCs are attached to Avaya IP phones. Case 1 is one of the reasons for the recommendation to use separate voice subnets/VLANs. Case 2 is unavoidable, and the result is that broadcasts used by the PC must pass through the phone, even if the phone and PC are on different VLANs. For this reason Avaya IP phones are designed to be very resilient against broadcasts, with lab tests showing the phones operating satisfactorily even with 1000+ broadcasts per second. Nevertheless, high-broadcast environments are very strongly

discouraged for IP telephony.

Ethernet Switches

The following recommendations apply to Ethernet switches to optimize operation with Avaya IP telephones and other Avaya VoIP endpoints, such as IP boards. They are meant to provide the simplest configuration by removing unnecessary features.

- Enable spanning tree fast start feature or disable spanning tree at the port level – The spanning tree

protocol is a layer 2 (L2) protocol used to prevent loops when multiple L2 network devices are connected together. When a device is first connected (or re-connected) to a port running spanning tree, the port takes approximately 50 seconds to cycle through the Listening, Learning, and Forwarding states. This 50-second delay is not necessary and not desired on ports connected to IP hosts. Enable a fast start feature on these ports to put them into the Forwarding state almost immediately. Avaya P550 calls this fast-start and Cisco calls it portfast. If this feature is not available, disabling spanning tree on the port is an option that should be considered. Do not

disable

spanning tree on an entire switch or VLAN.

SM Avaya IP Telephony Implementation Guide

- Disable Cisco features – Cisco features that are not required by Avaya endpoints are auxiliaryvlan

(except for IP phones in a dual-VLAN setting as described in appendices A and B), channeling, cdp, inlinepower, and any Cisco proprietary feature in general

. Explicitly disable these features on ports connected to Avaya devices, as they are non-standard mechanisms relevant only to Cisco devices and can sometimes interfere with Avaya devices. The CatOS command set port host <mod/port> automatically disables channeling and trunking, and enables portfast. Execute this command first, and then manually disablec cdp, inlinepower, and auxiliaryvlan. For dual-VLAN implementations see Appendices A and B for more information and updates regarding trunking and auxiliaryvlan.

- Properly configure 802.1Q trunking on Cisco switches – When trunking is required on a Cisco CatOS

switch connected to an Avaya IP telephone, enable it for 802.1Q encapsulation in the nonegotiate mode (set trunk <mod/port> nonegotiate dot1q). This causes the port to become a plain 802.1Q trunk port with no Cisco auto-negotiation features. When trunking is not required, explicitly disable it, as the default is to auto-negotiate trunking.

Speed/Duplex

One major issue with Ethernet connectivity is proper configuration of speed and duplex. There is a significant amount of misunderstanding in the industry as a whole regarding the auto-negotiation standard. The following table is provided as a quick reference for how speed and duplex settings are determined and typically configured. It is imperative that the speed and duplex settings be configured properly.

Device1

Configuration

auto-negotiate

100/full 100/full 100/full stable. Typical configuration for server connections and

10/half

100/half

Device2

Configuration

auto-negotiate

100/half

10/half

100/full

10/half

100/half

Result

100/full expected and often achieved, but not always stable. Suitable for user PC connections, but not suitable for server connections or uplinks bet we en network devices. Suitable for a single VoIP call, such as with a softphone or single IP telephone. Not suitable for multiple VoIP calls, such as through a MedPro board.

100/half stable. Device1 senses the speed and matches accordingly. Device1 senses no duplex neg otiation, so it goe s to half duplex. 10/half stable. Device1 senses the speed and matches accordingly. Device1 senses no duplex neg otiation, so it goe s to half duplex.

Device1 goes to 100/half, resulting in a duplex mismatch – undesirable. Device1 senses the speed and matches accordingly. Device1 senses no duplex neg otiation, so it goe s to half duplex.

uplinks between network devices. Stable at respective speed and duplex. Some enterprises do this on user ports as a matter of policy for various reasons.

Table 1: Speed/duplex matrix

Layer 1 (L1) errors such as runts, CRC errors, FCS errors, and alignment errors often accompany a duplex mismatch. If these errors exist and continue to increment, there is probably a duplex mismatch or cabling problem or some other physical layer problem. The show port <mod/port> command on Catalyst switches gives this information. The Avaya P550 commands are show port status <mod/port>, show port counters <mod/port>, and show ethernet counters <mod/port>. The Avaya P330 switch command is show rmon statistics <mod/port>.

SM Avaya IP Telephony Implementation Guide

2.2 Bandwidth Considerations

Calculation

Many VoIP bandwidth calculation tools are available, as well as pre-calculated tables. Rather than presenting a table, the following information is provided to help the administrator make an informed bandwidth calculation. The per-call rates for G.711 and G.729 are provided under the “Ethernet Overhead” and “WAN Overhead” headings below, and all calculations are for the recommended voice packet size of 20ms.

- Voice payload and codec selection

– The G.711 codec payload rate is 64000bps. Since the audio is encapsulated in 10-ms frames, and there are 100 of these frames in a second (100 * 10ms = 1s), each frame contains 640 bits (64000 / 100) or 80 bytes of voice payload. The G.729 codec payload rate is

8000bps, which equates to 80 bits or 10 bytes per 10-ms frame.

Voice Payload 1 frame – 10ms 2 frames – 20ms 3 frames – 30ms 4 frames – 40ms

G.711 80 B 160 B 240 B 320 B G.729 10 B 20 B 30 B 40 B

Table 2: Voice payload vs. number of frames

- Packet size and packet rate

– Because the voice payload rate must remain constant, the number of voice frames per packet (packet size) determines the packet rate. As the number of frames per packet increases, the number of packets per second decreases to maintain a steady rate of 100 voice frames per second (64000bps or 8000bps).

Packet Rate 1 frame/packet

10ms

G.711 100pps 50pps 33pps 25pps G.729 100pps 50pps 33pps 25pps

Table 3: Packet rate vs. packet size

2 frames/packet

20ms

3 frames/packet

30ms

4 frames/packet

40ms

- IP, UDP, RTP overhead – Each voice packet inherits a fixed overhead of 40 bytes.

20 B

UDP

8 B

Figure 12: IP/UDP/RTP overhead

RTP 12 B

Voice Payload

Variable

To this point the calculation is simple. Add up the voice payload and overhead per packet, and multiply by the number of packets per second. Here are the calculations for a G.711 and a G.729 call, both using 20-ms packets. (Remember that there are 8 bits per byte.)

G.711: (160 voice payload + 40 overhead)B/packet * 8b/B * 50packets/s = 80kbps

G.729: (20 voice payload + 40 overhead)B/packet * 8b/B * 50packets/s = 24kbps

The calculations above do not include the L2 encapsulation overhead. L2 overhead must be added to the bandwidth calculation, and this varies with the protocol being used (Ethernet, PPP, HDLC, ATM, Frame Relay, etc).

SM Avaya IP Telephony Implementation Guide

header

20 B

UDP

8 B

RTP

12 B

Figure 13: L2 overhead

Voice Payload

Variable

trailer

Ethernet Overhead

Ethernet has a header of 14 bytes and a trailer of 4 bytes. It also has a 7-byte preamble and a 1-byte start of frame delimiter (SFD), which some bandwidth calculation tools do not take into

G.711 20-ms call over Ethernet = 90.4kbps G.711 30-ms call over Ethernet = 81.6kbps

G.729 20-ms call over Ethernet = 34.4kbps G.729 30-ms call over Ethernet = 25.6kbps

consideration. Nevertheless, the preamble and SFD consume bandwidth on the LAN, so the total Ethernet overhead is 26 bytes. When transmitting 20-ms voice packets, the Ethernet overhead equates to 10.4kbps (26 * 8 * 50), which must be added to the 80kbps for G.711 or 24kbps for G.729. For full-duplex operation the totals are 90.4kbps for G.711 and

34.4kbps for G.729. For half-duplex operation these figures are at least doubled, but effectively the load

is higher due to the added overhead of collisions.

WAN Overhead

The WAN overhead is calculated just like the Ethernet overhead, by determining the size of the L2 encapsulation and figuring it into the calculation. L2 headers and trailers vary in size with the protocol being used, but they are typically much smaller than the Ethernet header and trailer. For example, the PPP overhead is only 7 bytes. However, to allow for a high margin of error, assume a 14-byte total L2 encapsulation size, which would add an overhead of 5.6kbps (14 * 8 * 50), assuming 20-ms voice

packets. This would result in approximately 86kbps

G.729 20-ms call over PPP = 26.8kbps G.729 30-ms call over PPP = 20.5kbps

G.729 20-ms call over 14-B L2 = 29.6kbps G.729 30-ms call over 14-B L2 = 22.4kbps

for G.711 and 30kbps for G.729 over a WAN link. Significant bandwidth savings are realized by using a compressed codec (G.729 recommended) across a WAN link. Note that in today’s data networks most, if

not all, WAN links are full duplex.

L3 Fragmentation (MTU)

Related to bandwidth, there are two other factors that must be considered for operation across WAN links, and they both involve fragmentation. The first factor, maximum transmission unit (MTU), involves fragmenting the layer 3 (L3) payload. The MTU is the total size of the L3 packet (IP header + IP payload), which is 200 bytes for G.711 and 60 bytes for G.729 (assuming 20-ms voice packets). If the MTU on an interface is set below these values the IP payload (UDP + RTP + voice payload) must be fragmented into multiple IP packets, each packet incurring the 20-byte IP overhead. For example, suppose the MTU on an interface is set to 100 bytes, which is an extremely low value. The 20-ms G.711 IP packet is 200 bytes, consisting of a 20-byte IP header and a 180-byte IP payload. The 180-byte payload must be divided into three fragments of 80 bytes, 80 bytes, and 20 bytes. Each fragment incurs a 20-byte IP header to make the packets 100 bytes, 100 bytes, and 40 bytes. A single 200-byte IP packet must be fragmented into three separate IP packets to meet the 100-byte MTU. In addition, the L2 overhead also increases because each L3 packet requires L2 encapsulation.

MTU should not be an issue for VoIP because most interfaces have a default MTU of 1500 bytes. However, it is possible to intentionally set the MTU to low levels. Even if the MTU is not set to a level that would fragment VoIP packets, the principle of fragmenting the L3 payload and incurring additional L3 and L2 overhead applies universally. Changing the MTU requires a thorough understanding of the

SM Avaya IP Telephony Implementation Guide

traffic traversing the network. A low MTU value, relative to any given IP packet size, always increases L3 and L2 overhead as illustrated with the VoIP example. Because of this inefficiency, it is generally not advisable to lower the MTU.

L2 Fragmentation

The second factor involves fragmenting the L2 payload, or the entire IP packet. This process of fragmenting a single IP packet into multiple L2 frames incurs additional L2 overhead, but no additional IP overhead. For example, the fixed cell size for ATM is 53 octets (bytes), with 5 octets for ATM overhead and 48 octets for payload. Without header compression there is no way to get a voice packet to fit inside one ATM cell. Therefore, the L3 packet (not just the IP payload, but the entire IP packet) is fragmented and carried inside multiple ATM cells. A 200-byte G.711 IP packet would require five ATM cells (25 octets of ATM overhead), whereas a 60-byte G.729 IP packet would only require two ATM cells (10 octets of ATM overhead). Refer to Appendix C for information regarding RTP header compression.

Keep in mind, however, that the same precautions apply to RTP header compression as to QoS (see the next section on CoS and QoS). The router could pay a significant processor penalty if the compression is done in software.

Inter-LATA (typically interstate) Frame Relay is also affected by this ATM phenomenon. This is because most carriers (ATT, Worldcom, Sprint) convert Frame Relay to ATM for the long haul, between the local central offices. This is done through a process called frame-relay-to-ATM network interworking and service interworking (FRF.5 and FRF.8). In this process the Frame Relay header is translated to an ATM header, and the Frame Relay payload is transferred to an ATM cell. Since the Frame Relay payload can be a variable size but the ATM payload is a fixed size, a single Frame Relay frame can be converted to multiple ATM cells for the long haul. Therefo re, it is b enef ic ial to lim it the siz e of the voice pa ck et even when the WAN link is Frame Relay.

2.3 CoS and QoS

General

The term “Class of Service” refers to mechanisms that tag traffic in such a way that the traffic can be differentiated and segregated into various classes. The term “Quality of Service” refers to what the network does to the tagged traffic to give higher priority to specific classes. If an endpoint tags its traffic with L2 802.1p priority 6 and L3 DSCP 46, for example, the Ethernet switch must be configured to give priority to value 6, and the router must be configured to give priority to DSCP 46. The fact that certain traffic is tagged with the intent to give it higher priority does not necessarily mean it receives higher priority. CoS tagging does no good without the supporting QoS mechanisms in the network devices.

CoS

802.1p/Q at the Ethernet layer (L2) and DSCP at the IP layer (L3) are two CoS mechanisms that Avaya products employ. These mechanisms are supported by the IP telephones and most IP port boards. In addition, the call server can flexibly assign the UDP port range for audio traffic transmitted from the MedPro board or VoIP module. Although TCP/UDP source and destination ports are not CoS mechanisms, they are inherently used to identify specific traffic and can be used much like CoS tags. Other non-CoS methods to identify specific traffic are to key in on source and destination IP addresses and specific protocols (ie, RTP).

SM Avaya IP Telephony Implementation Guide

802.1p/Q

The figure below shows the IEEE 802.1Q tag and its insertion point in the Ethernet and 802.3 frames. Note that in both cases the 802.1Q tag changes the size and format of the comprehensive Ethernet and

802.3 frames. Because of this, many intelligent switches (ones that examine the L2 header and perform some kind of check against the L2 frame) must be explicitly configured to accept 802.1Q tagged frames. Otherwise, these switches may reject the tagged frames. The Tag Protocol Identifier (TPID) field has hex value x8100 (802.1QTagType). This value alerts the switch or host that this is a tagged frame. If the switch or host does not understand 802.1Q tagging, the TPID field is mistaken for the Type or Length field, which results in an erroneous condition.

Figure 14: 802.1Q tag

The two other fields of importance are the Priority and Vlan ID (VID) fields. The Priority field is the “p” in 802.1p/Q and ranges in value from 0 to 7. (“802.1p/Q” is a common term used to indicate that the Priority field in the 802.1Q tag has significance. Prior to real-time applications 802.1Q was used primarily for VLAN trunking, and the Priority field was not important.) The VID field is used as it always has been – to indicate the VLAN to which the Ethernet frame belongs.

Rules for 802.1p/Q Tagging

There are two questions that determine when and how to tag:

1. Is tagging required to place the frame on a specific VLAN (VLAN tagging)?

2. Is tagging required to give the frame a priority level greater than 0 (priority tagging)?

Based on the answers to these questions, tagging should be enabled following these two rules.

1. Single-VLAN Ethernet switch port (default scenario).

SM Avaya IP Telephony Implementation Guide

- On a single-VLAN port there is no need to tag to specify a VLAN, because there is only one

VLAN.

- For priority tagging only, the IEEE 802.1Q standard specifies the use of VID 0. VID 0 means

that the frame belongs on the port’s primary VLAN, which IEEE calls the “port VLAN,” and Cisco calls the “native VLAN.” Some Ethernet switches do not properly interpret VID 0, in which case the port/native VID may need to be used, but this is not the standard method.

- For single devices, such as a call server or port board, a simpler alternative is to not

tag at all, but to configure the Ethernet switch port as a high-priority port instead. This treats all incoming traffic on that port as high-priority traffic, based on the configured level.

- For multiple devices on the same VLAN, such as an IP telephone with a PC attached, the high-

priority device (IP telephone) should tag with VID 0 and the desired priority. The low-priority device (PC) would not tag at all. No tag at all is the same as priority 0 (default).

2. Multi-VLAN Ethernet switch port.

- A multi-VLAN port has a single port/native VLAN and one or more additional tagged VLANs,

with each VLAN pertaining to a different IP subnet.

- In general, do not configure multiple VLANs on a port with only one device attached to it (unless

that device is another Ethernet switch across a trunk link).

- For the attached device that belongs on the port/native VLAN, follow the points given for rule 1

above. Clear frames (untagged frames) are forwarded on the port/native VLAN by default.

- An attached device that belongs on any of the tagged VLANs must tag with that VID and the

desired priority.

- The most common VoIP scenario for a multi-VLAN port is an IP telephone with a PC attached,

where the phone and PC are on different VLANs. In this case the PC would send clear frames, and the IP telephone should tag with the designated VID and desired priority.

As stated previously, an Ethernet switch must be capable of interpreting the 802.1Q tag, and many must be explicitly configured to receive it. The use of VID 0 is a special case, because it only specifies a priority and not a VLAN. Avaya switches accept VID 0 without any special configuration. However, some Ethernet switches do not properly interpret VID 0. And some switches require trunking to be enabled to accept VID 0, while others do not. The following table shows the results of some testing performed by Avaya Labs on Cisco switches.

Catalyst 6509 w/ CatOS 6.1(2)

Catalyst 4000 w/ CatOS 6.3(3)

Catalyst 3500XL w/ IOS 12.0(5)WC2 Conclusion Note the hardware platfor m and OS version and consult Cisco’s

Accepted VID 0 for the native VLAN when 802.1Q trunking was enabled on the port. Would not accept VID 0 for the native VLAN. Opened a case with Cisco TAC, and TAC engineer said it was a hardware problem in the 4000. Bug ID is CSCdr06231. Workaround is to enable 802.1Q trunking and tag with native VID instead of 0. Accepted VID 0 for the native VLAN when 802.1Q trunking was disabled on the port.

documentation, or call TAC.

Table 4: Sample VID 0 behaviors for Cisco switches

See Appendix A for more information on VLANs and tagging.

SM Avaya IP Telephony Implementation Guide

+ 51 hidden pages