sniffer voice installation and operations guide release...

Sniffer Voice

Installation andOperations Guide

Release 2.1

COPYRIGHT

Copyright © 2002 Networks Associates Technology, Inc. All Rights Reserved. No part of thispublication may be reproduced, transmitted, transcribed, stored in a retrieval system, ortranslated into any language in any form or by any means without the written permission ofNetworks Associates Technology, Inc., or its suppliers or affiliate companies. To obtain thispermission, write to the attention of the Network Associates legal department at: 3965 FreedomCircle, Santa Clara, California 95054, or call (972) 308-9960.

TRADEMARK ATTRIBUTIONS

ActiveSecurity, ActiveHelp, ActiveShield, Antivirus Anyware (and design), Bomb Shelter, Building aWorld of Trust, Certified Network Expert, CipherLink, Clean-Up, Cleanup Wizard, Cloaking, CNX,CNX Certification Certified Network Expert (and design), Compass 7, CyberCop, CyberMedia,CyberMedia Uninstaller, Data Security Letter (and design), N Design (logo), Design (rabbit with hat),Discover (and design), Disk Minder, Distributed Sniffer System, Distributed Sniffer System (inKatakana), Dr Solomon’s, Dr Solomon’s (label), Enterprise Secure Cast, EZ Setup, First Aid,ForceField, Gauntlet, GMT, GroupShield, Guard Dog, HelpDesk, Homeguard, Hunter, IC Expert,ISDN Tel/Scope, LAN Administration Architecture (and design), LANGuru, LANGuru (in Katakana),LANWords, Leading Help Desk Technology, LM 1, M (and design), Magic Solutions, MagicUniversity, MagicSpy, MagicTree, MagicWin, MagicWord, McAfee, McAfee (in Katakana), McAfee(and design), McAfee Associates, MoneyMagic, More Power To You, Multimedia Cloaking, NetCrypto,NetOctopus, NetRoom, NetScan, Net Shield, NetShield, NetStalker, Net Tools, Net Tools (inKatakana), Network Associates, Network General, Network Uptime!, NetXRay, Notesguard, Nuts &Bolts, Oil Change, PC Medic, PC Medic 97, PCNotary, PGP, PGP (Pretty Good Privacy), PocketScope,Pop-Up, PowerTelnet, Pretty Good Privacy, PrimeSupport, RecoverKey, RecoverKey-International,ReportMagic, Registry Wizard, RingFence, Router PM, Safe & Sound, SalesMagic, SecureCast, ServiceLevel Manager, ServiceMagic, Site Meter, Smart Desk, Sniffer, Sniffer (in Hangul), SniffMaster,SniffMaster (in Hangul), Sniffmaster (in Katakana), SniffNet, Stalker, Stalker (stylized), StatisticalInformation Retrieval (SIR), SupportMagic, Switch PM, TeleSniffer, TIS, TMach, TMeg, TotalNetwork Security, Total Network Visibility, Total Service Desk, Total Virus Defense, T-POD, T-POD(stylized), Trusted Mach, Trusted Mail, UnInstaller, Virex, Virex-PC, Virus Forum, ViruScan,VirusScan, VShield, WebScan, WebShield, WebSniffer, WebStalker, WebWall, Who’s Watching yourNetwork, Wingauge, ZAC 2000, and Zip Manager are registered trademarks of NetworkAssociates, Inc. and/or its affiliates in the US and/or other countries. All other registered andunregistered trademarks in this document are the sole property of their respective owners.

LICENSE AGREEMENT

NOTICE TO ALL USERS: FOR THE SPECIFIC TERMS OF YOUR LICENSE TO USE THESOFTWARE THAT THIS DOCUMENTATION DESCRIBES, CONSULT THE LICENSE.TXTOR OTHER LICENSE DOCUMENT THAT ACCOMPANIES YOUR SOFTWARE, EITHER ASA TEXT FILE OR AS PART OF THE SOFTWARE PACKAGING. IF YOU DO NOT AGREE TOALL OF THE TERMS SET FORTH THEREIN, DO NOT INSTALL THE SOFTWARE. IFAPPLICABLE, YOU MAY RETURN THE PRODUCT TO THE PLACE OF PURCHASE FOR AFULL REFUND.

Part Number: NAI-406-0011-2 Release 2.1, May, 2002

THIRD PARTY LICENSE AGREEMENTS

The Vovida Software License, Version 1.0

Copyright (c) 2000 Vovida Networks, Inc. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permittedprovided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. The names "VOCAL", "Vovida Open Communication Application Library", and "Vovida Open Communication Application Library (VOCAL)" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].

4. Products derived from this software may not be called "VOCAL", nor may "VOCAL" appear in their name, without prior written permission of Vovida Networks, Inc.

THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIEDWARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE ANDNON-INFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL VOVIDA NETWORKS,INC. OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT DAMAGES IN EXCESS OF$1,000, NOR FOR ANY INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, ORCONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OFSUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESSINTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHERIN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OROTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IFADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This software consists of voluntary contributions made by Vovida Networks, Inc. and manyindividuals on behalf of Vovida Networks, Inc. For more information on Vovida Networks,Inc., please see <http://www.vovida.org/>.

Table of Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixAbout This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Contacting Network Associates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

Getting Help with Web Site Downloads . . . . . . . . . . . . . . . . . . . . . . .x

Virus Scan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

Sniffer University Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

International Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Installing Sniffer Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Installing Sniffer Voice on a Sniffer Portable PC . . . . . . . . . . . . . . . . . . . . . . 1-2

Uninstalling Sniffer Voice from a Sniffer Portable PC . . . . . . . . . . . . . . . . . . 1-4

Installing Sniffer Voice on Sniffer Distributed Systems . . . . . . . . . . . . . . . . 1-5

Installation Overview for Sniffer Voice on Sniffer Distributed . . . . . . . 1-5

Installing Sniffer Voice on the SniffView Console . . . . . . . . . . . . . . . . 1-6

Installing on PCs with Multiple Supported Sniffer Installations . 1-8

Installing Sniffer Voice on Agents Remotely from SniffView . . . . . . . . 1-9

Installing Sniffer Voice on Agents Locally . . . . . . . . . . . . . . . . . . . . . . 1-11

Uninstalling Sniffer Voice from Sniffer Distributed Systems . . . . . . . . . . . 1-16

Uninstalling Sniffer Voice from Agents Remotely Using SniffView . 1-16

Uninstalling Sniffer Voice from Agents Locally . . . . . . . . . . . . . . . . . 1-19

Uninstalling Sniffer Voice from the SniffView Console . . . . . . . . . . . 1-22

Upgrading Sniffer Installations with Sniffer Voice Already Installed . . . . . 1-23

Symptoms of an Improper Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24

Fixing Upgrade Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24

Chapter 2. Introducing Sniffer Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Sniffer Voice Protocol Decodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Installation and Operations Guide v

Table of Contents

Basic Components of a VoIP Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Sniffer Voice Expert Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Sniffer Voice Protocol Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

How Sniffer Voice Protocol Filters Work . . . . . . . . . . . . . . . . . . . . . . . . 2-7

Chapter 3. Expert Detail Displays for Sniffer Voice . . . . . . . . . . . . . . . 3-1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Sniffer Voice Expert Detail Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

About the Asterisk in the Expert Summary Pane . . . . . . . . . . . . . . . . . 3-2

Network Objects for Sniffer Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Application Layer Expert Detail Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

H.323 Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

SCCP Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9

SIP Call Flow Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14

Session Layer Expert Detail Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19

H.225 Signal Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19

H.245 Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

RAS Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27

RTCP Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32

RTP Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36

SCCP Call Setup Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40

SIP Call Setup Detail Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44

Chapter 4. Expert Alarms for Sniffer Voice . . . . . . . . . . . . . . . . . . . . . . 4-1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Sniffer Voice Expert Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Expert Alarms for Sniffer Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Application Layer Expert Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

H323 - High Call Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

H323 - Too Many Incomplete Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

SCCP - High Call Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

SCCP - Too Many Incomplete Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

SIP - High Call Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

SIP - Too Many Incomplete Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

Session Layer Expert Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

vi Sniffer Voice

Table of Contents

H225 - Abnormal Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

H245 - Open Logical Channel Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8

H245 - Terminal Capability Set Reject . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9

RAS - Admission Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10

RAS - Bandwidth Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11

RAS - Gatekeeper Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11

RAS - Location Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

RAS - Registration Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

RTCP - Report High Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

RTP - High Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15

RTP - Too Many Dropped Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16

RTP - Too Many Out of Sequence Frames . . . . . . . . . . . . . . . . . . . . . . 4-17

SCCP - Register Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18

SCCP - Station Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18

SIP - Client Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18

SIP - Global Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20

SIP - Server Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20

SIP - Server Slow Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21

Appendix A. Network Associates Support Services . . . . . . . . . . . . . . A-1Adding Value To Your Network Associates Product . . . . . . . . . . . . . . . . . . .A-1

PrimeSupport Options for Corporate Customers . . . . . . . . . . . . . . . . .A-1

PrimeSupport Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-2

PrimeSupport Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-2

PrimeSupport Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-3

Ordering Corporate PrimeSupport . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-4

Network Associates Consulting and Training . . . . . . . . . . . . . . . . . . . . . . . .A-6

Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-6

Sniffer Product Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-7

Network Consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-7

Total Education Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-8

Installation and Operations Guide vii

Table of Contents

viii Sniffer Voice

Preface

About This ManualThis manual provides information specific to installing, configuring, and operating Sniffer Voice. Sniffer Voice is a special add-on module for Sniffer Portable or Sniffer Distributed that provides decodes and Expert analysis for Voice over IP (VoIP) protocols. The manual covers the following major topics:

• Installing Sniffer Voice on top of your existing Sniffer Portable or Sniffer Distributed installation.

• Introduction to Sniffer Voice, the protocols it decodes, and the new features offered by the Expert analyzer for Sniffer Voice.

• Understanding Sniffer Voice’s Expert displays for VoIP protocols.

• Understanding Sniffer Voice’s Expert alarms for VoIP protocols.

NOTE: This manual does not describe standard Sniffer Portable or Sniffer Distributed features. For description of standard Sniffer Portable features, see the Sniffer Pro Getting Started Guide and the Sniffer Portable online help. For description of Sniffer Distributed features, see the Sniffer Distributed Getting Started Guide.

Contacting Network Associates

Customer ServiceFor questions, comments, or requests concerning the software or hardware you purchased, your registration status, or similar issues, contact the Network Associates Customer Service department. The department hours of operation are 8:00 AM to 8:00 PM Central time, Monday through Friday.

Table i. Contact Information for Corporate-licensed Customers

Phone (800) SNIFFER (800- 764-3337)

E-Mail [email protected]

Web http://www.nai.com

Installation and Operations Guide ix

http://www.nai.com

Preface

Technical SupportNetwork Associates is dedicated to customer satisfaction. We provide answers to technical support issues on the following World Wide Web site: http://www.support.nai.com

If the automated web services do not have the answers you need, corporate-licensed customers can call 1-800-SNIFFER (1-800-764-3337) Monday through Friday between 8:00 AM and 8:00 PM Central time to contact Network Associates.

To provide the answers you need quickly and efficiently, the Network Associates technical support staff needs some information about your computer and software. Please have this information ready before you call:

• Sniffer product name and version number

• Computer brand and model

• Additional hardware or peripherals connected to your computer

• Operating system and version number(s)

• Network type and version, if applicable

• Contents of your AUTOEXEC.BAT, CONFIG.SYS, and system LOGIN script

• Specific steps to reproduce the problem

Getting Help with Web Site DownloadsTo get help with navigating or downloading files from the Network Associates Web sites or FTP sites, call Corporate Customer Support at 1-972-308-9960.

Virus Scan InformationSniffer Technologies scans all Sniffer Appliances and servers with McAfee Virus Scan as part of our manufacturing process. All products are shipped to customers virus-free.

Mail Network Associates Customer Service13465 Midway Rd.Dallas, Texas 75244USA

Table i. Contact Information for Corporate-licensed Customers

x Sniffer Voice

http://www.nai.com/asp_set/services/technical_support/tech_intro.asp

Preface

Sniffer products are typically installed within the corporate infrastructure where known viruses have been eliminated, therefore there is little value in installing anti-virus software on Sniffer units. Installing such software is not supported and may adversely affect system performance.

Sniffer Technologies continues to test released software with updates and patches to Microsoft software. A list of supported versions is available through Tech Support. We encourage our customers to periodically update their units with the latest supported Microsoft patches.

Sniffer University TrainingSince 1991, over 70,000 customers have completed Sniffer University training. Our customers typically are Network Administrators, Field Technicians, Network Managers, and Technical Support personnel for medium to large size companies that proactively manage and troubleshoot expanding networks.

Customers find our education to be of great value in enhancing and updating their skills as well as providing an opportunity for achieving a Sniffer-specific certification through the Sniffer Certified Professional Program (SCPP).

We provide complete course and registration information regarding Sniffer University worldwide training and certification on our World Wide Web site: http://www.sniffer.com/education/default.asp

International Contact InformationTo contact Network Associates outside the United States, use the addresses, phone and fax numbers listed in Table ii.

Table ii. International Offices (1 of 4)

Location Name Address Phone and Fax

Australia Network Associates Australia

Level 1, 500 Pacific HighwaySt. Leonards, NSWSydney, Australia 2065

Phone:61-2-8425-4200Fax:61-2-9439-5166

Austria Network Associates Austria

Pulvermuehlstrasse 17Linz, AustriaPostal Code A-4040

Phone:43-732-757-244Fax:43-732-757-244-20

Installation and Operations Guide xi

http://www.sniffer.com/education/default.asp

http://www.sniffer.com/education/default.asp

Preface

Belgium Network AssociatesBelgique

BDC Heyzel Esplanade, boîte 431020 BruxellesBelgique

Phone:0032-2 478.10.29Fax:0032-2 478.66.21

Brazil Network Associatesdo Brasil

Rua Geraldo Flausino Gomez 78Cj. - 51 Brooklin Novo - São PauloSP - 04575-060 - Brasil

Phone:(55 11) 5505 1009Fax:(55 11) 5505 1006

Canada Network AssociatesCanada

139 Main Street, Suite 201Unionville, OntarioCanada L3R 2G6

Phone:(905) 479-4189Fax:(905) 479-4540

China Network AssociatesPeople’s Republic of China

New Century Office Tower, Room 1557No. 6 Southern Road Capitol GymBeijingPeople’s Republic of China 100044

Phone:8610-6849-2650Fax:8610-6849-2069

Denmark Network Associates Denmark

Lautruphoej 1-32750 BallerupDanmark

Phone:45 70 277 277Fax:45 44 209 910

Finland NA Network Associates Oy

Mikonkatu 9, 5. krs.00100 HelsinkiFinland

Phone:358 9 5270 70Fax:358 9 5270 7100

France Network AssociatesFrance S.A.

50 Rue de Londres75008 ParisFrance

Phone:33 1 44 908 737Fax:33 1 45 227 554

Germany Network AssociatesDeutschland GmbH

Ohmstraße 1D-85716 UnterschleißheimDeutschland

Phone:49 (0)89/3707-0Fax:49 (0)89/3707-1199

Hong Kong Network Associates Hong Kong

19th Floor, Matheson Centre3 Matheson WayCauseway BayHong Kong 63225

Phone:852-2832-9525Fax:852-2832-9530



xii Sniffer Voice

Preface

Italy Network Associates Srl Centro Direzionale SummitPalazzo D/1Via Brescia, 2820063 - Cernusco sul Naviglio (MI)Italy

Phone:39 02 92 65 01Fax:39 02 92 14 16 44

Japan Network Associates Japan, Inc.

Shibuya Mark City West 20F1-12-1 Dougenzaka, Shibuya-kuTokyo 150-0043, Japan

Phone:81 3 5428 1100Fax:81 3 5428 1480

Latin America Network Associates Latin America

1200 S. Pine Island Road, Suite 375Plantation, Florida 33324 United States

Phone:(954) 452-1731Fax:(954) 236-8031

Mexico Network Associatesde Mexico

Andres Bello No. 10, 4 Piso4th FloorCol. PolancoMexico City, Mexico D.F. 11560

Phone:(525) 282-9180Fax:(525) 282-9183

The Netherlands

Network AssociatesInternational B.V.

Gatwickstraat 251043 GL AmsterdamThe Netherlands

Phone:31 20 586 6100Fax:31 20 586 6101

Portugal Network AssociatesPortugal

Av. da Liberdade, 1141269-046 LisboaPortugal

Phone:351 1 340 4543Fax:351 1 340 4575

South Africa Net Tools Network AssociatesSouth Africa

Hawthorne HouseSt. Andrews Business ParkMeadowbrook LaneBryanston, JohannesburgSouth Africa 2021

Phone:27 11 700-8200Fax:27 11 706-1569

South East Asia

Network AssociatesSouth East Asia

78 Shenton Way#29-02Singapore 079120

Phone:65-222-7555Fax:65-220-7255

Spain Network AssociatesSpain

Orense 4, 4a Planta.Edificio Trieste28020 Madrid, Spain

Phone:34 9141 88 500Fax:34 9155 61 404



Installation and Operations Guide xiii

Preface

Sweden Network Associates Sweden

Datavägen 3ABox 596S-175 26 JärfällaSweden

Phone:46 (0) 8 580 88 400Fax:46 (0) 8 580 88 405

Switzerland Network Associates AG

Baeulerwisenstrasse 38152 GlattbruggSwitzerland

Phone:0041 1 808 99 66Fax:0041 1 808 99 77

Taiwan Network AssociatesTaiwan

Suite 6, 11F, No. 188, Sec. 5Nan King E. Rd.Taipei, Taiwan, Republic of China

Phone:886-2-27-474-8800Fax:886-2-27-635-5864

United Kingdom

Network AssociatesInternational Ltd.

227 Bath RoadSlough, BerkshireSL1 5PPUnited Kingdom

Phone:44 (0)1753 217 500Fax:44 (0)1753 217 520



xiv Sniffer Voice

1Installing Sniffer Voice 1

OverviewThis chapter describes how to install the Sniffer Voice module on top of an existing Sniffer Portable or Sniffer Distributed installation. The chapter includes the following major sections:

• System Requirements on page 1–1

• Installing Sniffer Voice on a Sniffer Portable PC on page 1–2

• Uninstalling Sniffer Voice from a Sniffer Portable PC on page 1–4

• Installing Sniffer Voice on Sniffer Distributed Systems on page 1–5

• Uninstalling Sniffer Voice from Sniffer Distributed Systems on page 1–16

• Upgrading Sniffer Installations with Sniffer Voice Already Installed on page 1–23

System RequirementsSniffer Voice must be installed on top of an existing Sniffer Portable or Sniffer Distributed installation. Table 1–1 lists the versions of Sniffer Pro and Sniffer Distributed which support Sniffer Voice 2.1.

NOTE: The target system for Sniffer Voice must meet the system requirements for its base Sniffer installation. For example, if you are installing Sniffer Voice on top of an existing Sniffer Portable 4.7 installation, the target machine must meet the system requirements for Sniffer Portable 4.7 (as described in the Sniffer Pro Installation Guide).

Table 1–1. Sniffer Voice Support for Sniffer Portable and Sniffer Distributed

Target Environment Releases Supporting Sniffer Voice 2.1

Sniffer Portable Release 4.7

Sniffer Distributed Release 4.1 R2Release 4.2

Installation and Operations Guide 1-1

Installing Sniffer Voice

Installing Sniffer Voice on a Sniffer Portable PCThe Sniffer Voice CD includes the software you need to get started using Sniffer Voice on a Sniffer Portable system. The following procedure explains how to install the Sniffer Voice software on a Sniffer Portable PC.

� IMPORTANT: To install the Sniffer Voice software on a Windows NT system, you must have system administrator privileges.

To install the Sniffer Voice software on a Sniffer Portable PC:

1. Remove any previous version of Sniffer Voice currently installed on the target machine (see Uninstalling Sniffer Voice from a Sniffer Portable PC on page 1–4).

2. Make sure that the target machine is running a supported version of Sniffer Portable. Sniffer Voice 2.1 can be installed on Sniffer Portable machines running Release 4.70.xx. You can determine the version of your Sniffer Portable installation by selecting the Help > About Sniffer command. If an earlier version of Sniffer Portable is installed, you must:

a. Uninstall the existing version of Sniffer Portable.

b. Install Sniffer Portable 4.70.xx according to the instructions found in the Sniffer Pro Installation Guide.

3. Insert the Sniffer Voice CD in the CD-ROM drive.

The main menu of the Sniffer Voice CD appears automatically (Figure 1–1). You can use this menu to install the product, browse the product documentation, and so on.

NOTE: If the main menu of the Sniffer Voice CD does not appear automatically, you can start it manually as follows:

a. Open Windows Explorer.

b. Navigate to the drive where the Sniffer Voice CD is located.

c. Double-click the autorun.exe entry.

1-2 Sniffer Voice


Figure 1–1. Sniffer Voice CD Main Menu

4. Select the Install Product option from the main menu and follow the on-screen instructions until the Sniffer Voice software is installed successfully.

5. When installation has completed, you are instructed to reboot your computer. Reboot your computer before using Sniffer Voice.

At this point, the Sniffer Voice software is installed correctly on the Sniffer Portable PC. Turn to Chapter 2, Introducing Sniffer Voice to learn about Sniffer Voice’s features and capabilities.



Uninstalling Sniffer Voice from a Sniffer Portable PC

This section describes how to uninstall Sniffer Voice from a Sniffer Portable PC.

� IMPORTANT: Whenever you upgrade a Sniffer Portable installation that includes Sniffer Voice, you must first uninstall Sniffer Voice before uninstalling Sniffer Portable. Then, you can install the new version of Sniffer Portable, followed by a supported version of Sniffer Voice.

To uninstall the Sniffer Voice module:

1. Exit all instances of the Sniffer Pro application.

2. Go to Start > Settings > Control Panel.

3. Start the Add/Remove Programs control panel by double-clicking its entry.

The Add/Remove Programs control panel starts.

4. Select the Sniffer Voice 2.1 for Sniffer Portable entry and click the Add/Remove button.

5. When the uninstallation is complete, the system prompts you to restart the machine. Restart the machine.

As an alternative to Step 3 through Step 6, you can also select the Start > Programs > Sniffer Pro > About Sniffer Voice 2.1 for Sniffer Pro 4.7 menu item. Selecting this option displays the About Sniffer Voice dialog box (Figure 1–16). You can click the Uninstall button in this dialog box to uninstall the Sniffer Voice software.

Figure 1–2. Using the About Sniffer Voice Dialog Box to Uninstall

Click this button to uninstall the Sniffer Voice software.

1-4 Sniffer Voice


Installing Sniffer Voice on Sniffer Distributed Systems

The Sniffer Voice CD includes the software you need to get started using Sniffer Voice on a Sniffer Distributed system. This section describes how to install the Sniffer Voice software on a Sniffer Distributed system. It describes the following major topics:

• Installation Overview for Sniffer Voice on Sniffer Distributed on page 1–5

• Installing Sniffer Voice on the SniffView Console on page 1–6

• Installing Sniffer Voice on Agents Remotely from SniffView on page 1–9

• Installing Sniffer Voice on Agents Locally on page 1–11

� IMPORTANT: To install the Sniffer Voice software on a Windows NT system, you must have system administrator privileges.

Installation Overview for Sniffer Voice on Sniffer Distributed

Sniffer Distributed systems consist of two main components:

• Sniffer Distributed Agents have special software installed on them allowing them to monitor and capture data on the network.

• SniffView Consoles communicate with Sniffer Distributed Agents to collect the results of their analysis. From a single SniffView Console, you can view multiple connected Agents.

Sniffer Voice must be installed on both the SniffView Console and any Sniffer Distributed Agents which you want to perform VoIP analysis. You perform the installation process in two steps:

1. Install the Sniffer Voice software on the SniffView Console.

2. Use the SniffView Console to install Sniffer Voice remotely on Agents.

Figure 1–3 illustrates this process.

NOTE: You can also install Sniffer Voice locally on an Agent. However, it is usually simpler to install remotely since you can update multiple Agents simultaneously with Sniffer Voice software.



Figure 1–3. Two-Step Installation Process for Sniffer Voice on Sniffer Distributed

Installing Sniffer Voice on the SniffView ConsoleThis section describes how to install the Sniffer Voice software on a supported SniffView console.

To install the Sniffer Voice software on a SniffView console:

1. Make sure that the target machine is running a supported version of the SniffView Console software. Sniffer Voice 2.1 can be installed on SniffView Consoles running either Release 4.1 R2 or Release 4.20.xx. You can determine the version of your SniffView Console installation by selecting the Help > About Sniffer Distributed SniffView command from the SniffView window. If an earlier version of the SniffView Console is installed, you must:

a. Uninstall Sniffer Voice if it exists on the Console.

b. Uninstall the existing version of the SniffView Console.

c. Install a supported version of the SniffView Console.

d. Use the rest of this procedure to install Sniffer Voice.

2. Exit any open instances of the SniffView Console.

3. Insert the Sniffer Voice CD in the SniffView Console PC’s CD-ROM drive.

1. Install Sniffer Voice on the 2. Use SniffView to InstallSniffView Console Sniffer Voice on Agents

Sniffer Voice CD

SniffView Console

Network Connections

1-6 Sniffer Voice









NOTE: If the target PC includes multiple supported Sniffer installations, the installation program gives you the option of installing into any combination of them. See Installing on PCs with Multiple Supported Sniffer Installations on page 1–8 for details.

5. When installation has completed, you are instructed to reboot the computer. Reboot the computer before either connecting to Agents or using SniffView to install Sniffer Voice on Agents.



Installing on PCs with Multiple Supported Sniffer InstallationsThere are several situations where the target SniffView Console PC may include multiple supported Sniffer installations, such as:

• Sniffer Distributed Console 4.1 R2 with Sniffer Pro 4.7

• Sniffer Distributed Console 4.2 with Sniffer Pro 4.7

• Sniffer Distributed Console 4.1 R2 with Sniffer Distributed Console 4.2

The installation program automatically detects all supported Sniffer installations on the target PC and provides you with the option of installing into any combination of the detected supported installations. Figure 1–5 shows one example of this type of installation.

Figure 1–5. Installing on PCs with Multiple Sniffer Installations

The installation program automatically detects all supported Sniffer installations and gives you the option of which ones you would like to install Sniffer Voice into.

1-8 Sniffer Voice


Installing Sniffer Voice on Agents Remotely from SniffViewThis section describes how to use the SniffView Console to install Sniffer Voice on Sniffer Distributed Agents. To install Sniffer Voice on Agents remotely, you must have already installed Sniffer Voice on the SniffView Console you will use to update Agents.

Sniffer Distributed Agents can be installed to run either as a service or as an application. The remote installation procedure is the same regardless of whether the Agent is installed as a service or as an application.

To install Sniffer Voice remotely on Agent(s):

1. Make sure that the target machine is running a supported version of the Sniffer Distributed Agent software. Sniffer Voice 2.1 can be installed on Sniffer Distributed Agents running either Release 4.1 R2 or Release 4.20.xx. You can determine the version of your Sniffer Distributed Agent installation by selecting the Help > About Sniffer command from a connected Agent. If an earlier version of the Sniffer Distributed Agent software is installed, you must:

a. Uninstall Sniffer Voice if it exists on the Agent.

b. Uninstall the existing version of the Sniffer Distributed Agent software.

c. Install a supported version of the Sniffer Distributed Agent software.


2. Start the SniffView application.

3. Disconnect any active SniffView connections to the Server(s) to be updated.

4. Select the Agent on which you would like to install the Sniffer Voice software in the Agent list (SniffView’s right pane). Alternatively, you can select a group of Agents to install from the Groups list (SniffView’s left pane).

NOTE: You can determine whether an Agent already has Sniffer Voice installed by examining its Version field in the Agent list. Agents with Sniffer Voice installed will include an SV 2.x entry next to the entry for its Agent software. For example, an Agent with a Version field reading 4.1048 SV 2.1 already has Sniffer Voice 2.1 installed.



5. Select the Remote Install Sniffer Voice command from the Agents menu. If you are installing Sniffer Voice on a Group of Agents, select the Remote Install Sniffer Voice command from the Group menu.

NOTE: The Remote Install Sniffer Voice command only appears if the Sniffer Voice software has already been installed on the SniffView Console.

6. Click Yes on the confirmation prompt.

NOTE: If the target Agent is currently logged in as an Administrator, you will be prompted to enter a valid user name and password before the installation proceeds. The default user name for a turnkey Agent is Administrator with no password.

The Remote Install Sniffer Voice dialog box appears and shows the progress of the installation (Figure 1–6). This dialog box also informs you of the success or failure of the installation on each Agent selected for installation. When installation has completed, the Cancel button changes to a Close button in this dialog box.

Figure 1–6. The Remote Install Sniffer Voice Dialog Box

7. Click Close on the Remote Install Sniffer Voice dialog box.

8. You are asked whether you would like to save the Status Log. Click Yes or No depending on your decision.

9. You are returned to SniffView. Agents updated with Sniffer Voice software appear with a distinctive SV 2.x entry in their Version field (Figure 1–7).

1-10 Sniffer Voice


NOTE: Release 4.2 SniffView Consoles without Sniffer Voice installed still use the Version field to indicate whether listed Agents have Sniffer Voice installed.

10. If the target Agent was logged in as an Administrator during the installation, you must reboot the SniffView Console PC before continuing.

Figure 1–7. SniffView Window with Sniffer Voice-Installed Agents

Installing Sniffer Voice on Agents LocallyThis section describes how to install Sniffer Voice on Agents locally. To install Sniffer Voice on Agents locally, you must have the Sniffer Voice product CD.

Sniffer Distributed Agents can be installed to run either as a service or as an application. Separate procedures are provided for local installations on both configurations below.

The “SV 2.x” field indicates that this Agent has Sniffer Voice installed. Note that Release 4.2 SniffView Consoles do not need Sniffer Voice installed to provide this information.



Installing Locally on an Agent Installed as a Service

To install Sniffer Voice locally on an Agent configured to run as a service:




c. Install a supported version of the Sniffer Distributed Agent software as a service.


2. Stop the DSAgentSrv service on the Agent PC.

a. Go to Start > Settings > Control Panel.

b. Start the Services control panel by double-clicking its entry.

The Services control panel appears.

c. Select the DSAgentSrv entry in the Services control panel and click the Stop button (Figure 1–8).

d. Click the Close button on the Services control panel.

Figure 1–8. Stopping the DSAgentSrv Service

3. Close the Probe Viewer application on the Agent if it is running.

1-12 Sniffer Voice


4. Insert the Sniffer Voice CD in the Agent’s CD-ROM drive.








6. When installation completes, you are prompted to restart the Agent. Click Yes to restart the Agent.

You can verify that the Sniffer Voice application is installed by navigating to the Start > Programs > Distributed SnifferPro menu. If this menu includes an entry for About Sniffer Voice 2.1 for Sniffer Distributed



Agent, the Sniffer Voice software has been successfully installed (Figure 1–11).

Figure 1–10. The “About Sniffer Voice...” Entry

Installing Locally on an Agent Installed as an Application

To install Sniffer Voice locally on an Agent configured to run as an application:




c. Install a supported version of the Sniffer Distributed Agent software as an application.


2. Exit the Agent application on the target PC.

3. Insert the Sniffer Voice CD in the CD-ROM drive.

4. Go to Start > Run.

5. Enter <drive letter>:\setup and click OK.

<drive letter> is the physical drive letter of the CD-ROM drive.

6. Follow the on-screen instructions until the Sniffer Voice software is installed successfully.

1-14 Sniffer Voice


7. When installation completes, you are prompted to restart the Agent. Click Yes to restart the Agent.

You can verify that the Sniffer Voice application is installed by navigating to the Start > Programs > Distributed SnifferPro menu. If this menu includes an entry for About Sniffer Voice 2.1 for Sniffer Distributed Agent, the Sniffer Voice software has been successfully installed (Figure 1–11).

Figure 1–11. The “About Sniffer Voice...” Entry



Uninstalling Sniffer Voice from Sniffer Distributed Systems

This section describes how to uninstall from a Sniffer Distributed System. As with the installation procedure, uninstallation consists of two separate steps:

1. Uninstall the Sniffer Voice software from Agents, either remotely (using SniffView) or locally.

2. Uninstall the Sniffer Voice software from the SniffView Console.

This section provides uninstallation instructions for the following situations:

• Uninstalling Sniffer Voice from Agents Remotely Using SniffView on page 1–16

• Uninstalling Sniffer Voice from Agents Locally on page 1–19

• Uninstalling Sniffer Voice from the SniffView Console on page 1–22

� IMPORTANT: Whenever you upgrade a Sniffer Distributed Console or Agent that already has Sniffer Voice installed, you must first uninstall Sniffer Voice before uninstalling the Sniffer Console\Agent software. Then, you can install the new version of the Sniffer Console\Agent software, followed by a supported version of Sniffer Voice.

Uninstalling Sniffer Voice from Agents Remotely Using SniffView

This section describes how to use the SniffView Console to uninstall Sniffer Voice from Sniffer Distributed Agents remotely.

Sniffer Distributed Agents can be installed to run either as a service or as an application. The remote uninstallation procedure is the same regardless of whether the Agent is installed as a service or as an application.

To use SniffView to uninstall Sniffer Voice from Agents remotely:

1. Start the SniffView application.

2. Disconnect any active SniffView connections to the Server(s) from which Sniffer Voice will be uninstalled.

1-16 Sniffer Voice


3. Select the Agent from which you would like to uninstall the Sniffer Voice software in the Agent list (SniffView’s right pane). Alternatively, you can select a group of Agents to uninstall from the Groups list (SniffView’s left pane).

NOTE: You can determine whether an Agent has Sniffer Voice installed by examining its Version field in the Agent list. Agents with Sniffer Voice installed will include an SV 2.x entry next to the entry for its Agent software. For example, an Agent with a Version field reading 4.1048 SV 2.1 has Sniffer Voice 2.1 installed.

4. Select the Remote Uninstall Sniffer Voice command from the Agents menu. If you are uninstalling Sniffer Voice from a Group of Agents, select the Remote Uninstall Sniffer Voice command from the Group menu.

NOTE: The Remote Uninstall Sniffer Voice command only appears if the Sniffer Voice software has already been installed on the selected Agent.

5. Click Yes on the confirmation prompt.

NOTE: If the target Agent is currently logged in as an Administrator, you will be prompted to enter a valid user name and password before the uninstallation proceeds. The default user name for a turnkey Agent is Administrator with no password.

The Remote Uninstall Sniffer Voice dialog box appears and shows the progress of the uninstallation (Figure 1–6). This dialog box also informs you of the success or failure of the uninstallation from each Agent selected for uninstallation. When uninstallation has completed, the Cancel button changes to a Close button in this dialog box.



Figure 1–12. The Remote Uninstall Sniffer Voice Dialog Box

6. Click Close on the Remote Uninstall Sniffer Voice dialog box.

7. You are asked whether you would like to save the Status Log. Click Yes or No depending on your decision.

8. You are returned to SniffView. Agents without Sniffer Voice software appear without the distinctive SV 2.x entry in their Version field (Figure 1–7).

NOTE: Release 4.2 SniffView Consoles without Sniffer Voice installed still use the Version field to indicate whether listed Agents have Sniffer Voice installed.

9. If the target Agent was logged in as an Administrator during the uninstallation, you must reboot the SniffView Console PC before continuing.

1-18 Sniffer Voice


Figure 1–13. SniffView Window Showing Agents without Sniffer Voice

Uninstalling Sniffer Voice from Agents LocallyThis section describes how to perform a local uninstallation of the Sniffer Voice software from an Agent. There are separate procedures depending on whether the target Agent is installed as a service or as an application.

Uninstalling Locally from an Agent Installed as a Service

To uninstall Sniffer Voice locally on an Agent installed as a service:

1. Stop the DSAgentSrv service on the Agent PC.

a. Go to Start > Settings > Control Panel.

b. Start the Services control panel by double-clicking its entry.

The Services control panel appears.

c. Select the DSAgentSrv entry in the Services control panel and click the Stop button (Figure 1–14).

d. Click the Close button on the Services control panel.

The absence of the “SV 2.x” field indicates that this Agent does not have Sniffer Voice installed. Note that Release 4.2 SniffView Consoles do not need Sniffer Voice installed to provide this information.



Figure 1–14. Stopping the DSAgentSrv Service

2. Close the Probe Viewer application on the Agent if it is running.




5. Select the Sniffer Voice 2.1 for Sniffer Distributed Agent entry and click the Add/Remove button.


As an alternative to Step 3 through Step 6, you can also select the Start > Programs > Distributed SnifferPro > About Sniffer Voice 2.1 for Sniffer Distributed Agent menu item. Selecting this option displays the About Sniffer Voice dialog box (Figure 1–16). You can click the Uninstall button in this dialog box to uninstall the Sniffer Voice software.



1-20 Sniffer Voice


Uninstalling Locally from an Agent Installed as an Application

To uninstall Sniffer Voice locally on an Agent installed as an application:

1. Exit the Agent application.




4. Select the Sniffer Voice 2.1 for Sniffer Distributed Agent entry and click the Add/Remove button.


As an alternative to this procedure, you can also select the Start > Programs > Distributed SnifferPro > About Sniffer Voice 2.1 for Sniffer Distributed Agent menu item. Selecting this option displays the About Sniffer Voice dialog box (Figure 1–16). You can click the Uninstall button in this dialog box to uninstall the Sniffer Voice software.





Uninstalling Sniffer Voice from the SniffView ConsoleUse the following procedure to uninstall Sniffer Voice from the SniffView Console.

To uninstall Sniffer Voice from the SniffView Console:

1. Exit the SniffView Console application.




4. Select the entry corresponding to the version of Sniffer Voice 2.1 you want to remove and click the Add/Remove button.

NOTE: If the target PC includes multiple Sniffer Voice installations, the Add/Remove Programs control panel will include separate entries for each installation (for example, Sniffer Voice 2.1 for Sniffer Distributed Console 4.1 R2, Sniffer Voice 2.1 for Sniffer Distributed Console 4.2, or Sniffer Voice 2.1 for Sniffer Pro 4.7). Be sure to select the entry corresponding to the installation you want to remove.


As an alternative to this procedure, you can also select the Start > Programs > Distributed SnifferPro > About Sniffer Voice 2.1 for Console 4.x menu item.

NOTE: If Sniffer Voice is installed in both Sniffer Distributed Console 4.1 R2 and Sniffer Distributed Console 4.2 on the same machine, there will be separate entries in the Distributed SnifferPro program group for each installation (for example, About Sniffer Voice 2.1 for Console 4.2 and About Sniffer Voice 2.1 for Console 4.1 R2). Be sure to select the entry corresponding to the installation you want to remove.

Selecting this option displays the About Sniffer Voice dialog box (Figure 1–17). You can click the Uninstall button in this dialog box to uninstall the Sniffer Voice software from the Console.

1-22 Sniffer Voice



Upgrading Sniffer Installations with Sniffer Voice Already Installed

Sniffer Voice is a special add-on module installed on top of an existing base Sniffer Portable or Sniffer Distributed installation. There are several common situations where you will need to upgrade your existing base Sniffer Portable\Distributed release to either a new release or a patch release. For example:

• Upgrading Sniffer Portable 4.5 with Sniffer Voice 2.0 to Sniffer Portable 4.7.

• Upgrading Sniffer Portable 4.7 with Sniffer Voice 2.1 to a patch release.

• Upgrading Sniffer Distributed 4.1R2 (Agent and Console) with Sniffer Voice 2.1 to Sniffer Distributed 4.2.

• Upgrading Sniffer Distributed 4.1R2 (Agent and Console) with Sniffer Voice 2.1 to a patch release.

• Upgrading Sniffer Distributed 4.2 (Agent and Console) with Sniffer Voice 2.1 to a patch release.

In each of these scenarios, you must uninstall Sniffer Voice before uninstalling the base Sniffer Portable\Distributed installation. The entire upgrade sequence is as follows:

1. Uninstall Sniffer Voice.

2. Uninstall the old version of Sniffer Portable\Distributed.

3. Install the new version of Sniffer Portable\Distributed.

4. Install Sniffer Voice.




Symptoms of an Improper UpgradeIf you do not follow the upgrade sequence from the previous section, you may experience some or all of the following problems:

• Loss of patch release functionality

• Reversion of protocol interpreter and Expert functionality from Sniffer Pro 4.7 to Sniffer Pro 4.5.

• Unstable Sniffer performance.

These problems will only occur if Sniffer Voice is not uninstalled before the base version of Sniffer Portable\Distributed is uninstalled. See Fixing Upgrade Problems, below, for information on remedying these problems.

Fixing Upgrade ProblemsIf you are experiencing any of the symptoms listed in the previous section or suspect that you may have uninstalled your base Sniffer installation without first uninstalling Sniffer Voice, you can remedy the problem by performing the following procedure:

1. Uninstall Sniffer Voice.

2. Uninstall the base product if it exists (for example, Sniffer Portable 4.7).

3. Delete the Sniffer directory and all of its constituent files and subdirectories. The location of this directory will vary somewhat depending on the product, operating system, and installation location. In general, the Sniffer directory will be found at one of the following paths:

Sniffer Portable:• \Program Files\NAI\SnifferNT\*.*

• \Program Files\NAI\Sniffer\*.*

Sniffer Distributed (both Agent and Console):• \Program Files\NAI\DSProAgentNT\*.*

• \Program Files\NAI\DSProConsoleNT\*.*

� IMPORTANT: See Why You Should Delete the Sniffer Directory, below, for more details on why deleting these files is necessary.

4. Reinstall the base Sniffer product.

5. Reinstall Sniffer Voice.

1-24 Sniffer Voice


Why You Should Delete the Sniffer Directory

When fixing upgrade problems using the procedure in the previous section, it is absolutely necessary to delete the Sniffer directory after uninstalling Sniffer Voice 2.0. However, it is also recommended for Sniffer Voice 2.1 installations.

The reason for this is that when Sniffer Voice is installed into the base Sniffer Portable\Distributed product, some existing Sniffer files are backed up and then replaced by Sniffer Voice files. The exact set of files backed up and replaced is determined by the target version of Sniffer Portable\Distributed.

If a new version of Sniffer Portable\Distributed is installed without first uninstalling Sniffer Voice, the Sniffer Voice files will be replaced, thereby disabling Sniffer Voice functionality. Furthermore, if Sniffer Voice is then uninstalled, the files which were backed up from the previous version of Sniffer Portable\Distributed will be restored into the newer version of Sniffer, causing a potentially dangerous mixture of files. This is why it is a good idea to delete the Sniffer directory and start with a clean slate before installing both the base Sniffer product as well as Sniffer Voice.



1-26 Sniffer Voice

2Introducing Sniffer Voice 2

OverviewThis chapter provides an overview of the new features found in Sniffer Voice, including:

• A description of the protocols decoded by Sniffer Voice, including a summary of their place and purpose in a Voice over IP (VoIP) networking environment.

• A description of the basic components of the VoIP networking environment.

• An overview of the enhancements to the Expert analyzer added by Sniffer Voice. Detailed descriptions of Expert enhancements for Sniffer Voice are found in Chapter 3, Expert Detail Displays for Sniffer Voice, and Chapter 4, Expert Alarms for Sniffer Voice.

• A description of how to set the protocol filters for VoIP protocols included as part of Sniffer Voice.

Sniffer Voice Protocol DecodesSniffer Voice provides complete decodes of the following VoIP protocols:

• H.323 (Version 2.0), including:

– H.225 Call Signalling (Version 2.0)

– H.245 Media Control (Version 3.0)

– H.225 RAS (Version 2.0)

• RTP (Version 2.0)

• RTCP (Version 2.0)

• SIP (Version 2.0)

• Cisco’s Skinny Client Control Protocol (SCCP, Version 3.1.1)

• MGCP (Version 1.0)

• SAP/SDP

In addition, Sniffer Voice provides Expert analysis for all of these protocols, except MGCP and SAP/SDP. See the release notes accompanying your product shipment for the versions of each VoIP protocol decoded by Sniffer Voice.


Introducing Sniffer Voice

Figure 2–1 shows how these protocols relate to one another in a model of the network. Following the figure, each protocol is described briefly.

Figure 2–1. VoIP Protocols Decoded by Sniffer Voice

H.225 Call Signalling

The H.225 Call Signalling protocol is part of the H.323 protocol suite. It is used to establish, maintain, and tear down calls between H.323 endpoints. H.225 is based heavily on the standard ISDN D-channel signalling protocol Q.931.

H.225 RAS

The Registration, Administration, and Status protocol (RAS) is part of H.225. H.323 endpoints use RAS prior to setting up a call to exchange registration, status, and administration information with the gatekeeper.

H.245 Media Control

The H.245 protocol is part of the H.323 protocol suite. Voice over IP endpoints use H.245 to exchange end-to-end control messages. These control messages are used for opening and closing logical channels, exchanging capability information, exchanging flow control messages, and so on.

Reliable Transport (for example, TCP)

Unreliable Transport (for example, UDP)

RTP

RTCP RAS(H.225)

H.225H.245Call

Signalling

SIPCiscoSCCP

Audio-Visual ApplicationsTerminal Control and Management

NOTE: Protocols in shaded boxes belong to the H.323 protocol family.

2-2 Sniffer Voice


RTP

The Real-Time Transport Protocol (RTP) provides end-to-end delivery services for time-sensitive data, such as interactive audio and video. It is commonly used for delivery by many application layer multimedia protocols, including H.323, SIP, and Cisco’s Skinny Client Control Protocol (SCCP).

RTCP

The Real-Time Transport Control Protocol (RTCP) is used to monitor and report statistics on the status and quality of an ongoing RTP transaction between two or more endpoints. Each of the endpoints in an RTP transaction periodically issues RTCP report packets providing various statistics measuring the quality of the RTP data stream it is receiving.

Cisco SCCP

Cisco’s Skinny Client Control Protocol (SCCP) allows simple IP telephony devices to operate without implementing the entire H.323 specification. Instead, they can operate as SCCP “skinny” clients and communicate with H.323 proxies (which implement the entire H.323 specification and are called Call Managers in SCCP) to interact with H.323-compliant devices.

SIP

The Session Initiation Protocol (SIP) is a signalling protocol used to set up, modify, and terminate internet telephony session, multimedia conferences, and so on. In the SIP call environment, SIP performs call setup, call connection, and call control services.

MGCP

The Media Gateway Control Protocol (MGCP) provides a means of controlling telephony gateways from external call control elements known as call agents within MGCP. MGCP is essentially a master/slave protocol in which call agents issue commands to gateways and gateways respond to these commands.

SAP/SDP

The Session Announcement Protocol and the Session Description Protocol (SAP/SDP) are alternatives to H.323 developed by the IETF for multimedia applications (along with SIP). SAP is used to distribute multicast session descriptions to large groups of recipients. SDP provides session description services for SIP, SAP, and Real Time Streaming Protocol (RTSP) transactions.



Basic Components of a VoIP NetworkThis section describes the basic components of a Voice over IP network. Familiarity with these concepts will help you get the most out of the features offered by Sniffer Voice.

H.323 VoIP networks include the following basic components:

• VoIP Terminal — In H.323, any device that implements the H.323 specification and can place or receive calls is considered a H.323 terminal. Examples of H.323 terminals include IP telephones and PCs equipped with software that allows them to place and receive calls.

• VoIP Gateway — The VoIP Gateway’s job in an H.323 VoIP network is the same as that of a gateway in other networks — it lets different types of networks communicate. A typical H.323 gateway connects VoIP calls on a local network to the wider public-switched telephone network (PSTN).

• Multipoint Control Unit — In H.323, the MCU is used to administer multipoint calls (conference calls). Each terminal connecting to a multipoint call connects to the MCU. The MCU takes care of administering the conference call’s parameters.

• VoIP Gatekeeper — In H.323, the VoIP gatekeeper controls a zone — a logical grouping of H.323 terminals, gateways, and MCUs. The gatekeeper also performs the Registration, Administration, and Status (RAS) functions described in H.225 RAS on page 2–2.

NOTE: Each of these VoIP components is a logical component. There is no requirement that each component reside on a separate physical machine. In many VoIP implementations, a single physical machine will perform more than one of these tasks.

SCCP allows “skinny” clients to function in an H.323 call environment. Because of this, SCCP adds the following additional components:

• Skinny Client — A simple IP telephony device implementing a subset of the H.323 specification to save on memory and processor power. Examples of Skinny Clients include the IP-Phone manufactured by Cisco Systems.

• Call Manager — SCCP skinny clients communicate with the Call Manager to interact with other H.323-compliant devices. The Call Manager acts as an H.323 proxy, performing the call establishment, maintenance, and clearing services for calls between skinny clients and H.323 terminals.

2-4 Sniffer Voice


Sniffer Voice Expert EnhancementsSniffer Voice provides several new additions to the Expert analyzer, including:

• New network objects at the Expert Application and Session layers for Voice over IP connections using H.323 (including H.225, H.245, RTP, RTCP, and RAS), SIP, and Cisco’s Skinny Client Control Protocol (SCCP). In addition, the Expert indicates active calls in the Application layer Summary display by marking them with an asterisk (*) in the Protocol column.

During Expert analysis, Sniffer Pro constructs a database of network objects from the traffic it sees. The Expert protocol interpreters learn all about the network stations, routing nodes, subnetworks, and connections related to the frames in the capture buffer. This information is presented in the Expert display.

Chapter 3, Expert Detail Displays for Sniffer Voice describes the Expert Detail displays for all new network objects created as part of Sniffer Voice.

• New Expert symptoms and diagnoses specifically for VoIP protocols.

Using the information in its database of network objects, The Expert analyzer detects and alerts you to potential problems that may exist on the network. These problems are categorized as being either symptoms or diagnoses:

– A symptom indicates that a threshold has been exceeded and may indicate a problem on your network.

– A diagnosis can be several symptoms analyzed together, high rates of recurrence of specific symptoms, or single instances of particular network events that cause the Expert to conclude that the network has a real problem. A Diagnosis should be investigated immediately.

Chapter 4, Expert Alarms for Sniffer Voice describes each of the new Expert symptoms and diagnoses generated as part of Sniffer Voice.

NOTE: Since it is beyond the scope of this document to describe the Expert analyzer in detail, this manual assumes that you are already generally familiar with the Expert analyzer. See the Sniffer Pro Getting Started Guide and online help files for detailed information on working with Expert analyzer displays.



Sniffer Voice Protocol FiltersSniffer Voice 2.1 provides protocol filters for all VoIP protocols decoded by Sniffer Voice (see Sniffer Voice Protocol Decodes on page 2–1 for a list of these protocols).

You set Sniffer Voice protocol filters on the Advanced tab of the Define Filter dialog box. Access this dialog box by selecting the Define Filter command from the Monitor, Capture or Display menu. Depending on which menu you select the command from, your filter will be a Monitor filter, a Capture filter, or a Display filter.

The protocol filters for Sniffer Voice are found under the IP > TCP and IP > UDP entries in the Available Protocols list. Figure 2–2 shows the Advanced tab of the Define Filter dialog box with protocol filters set up to include H.225 and H.245 traffic.

Figure 2–2. Setting Protocol Filters for VoIP Protocols

TIP: In high-utilization network environments where more than ten percent of network traffic is non-VoIP, you can maximize the effectiveness of Sniffer Voice by configuring capture filters so that only VoIP frames are captured. In doing so, you will decrease both the number of unwanted frames in your capture buffer, as well as the amount of real-time processing devoted to unwanted frames.

Protocol filters for VoIP protocols are found under the IP > TCP and IP > UDP entries in the Available Protocols list on the Advanced tab of the Define Filter dialog box.

Here, you can see protocol filters set to include both H.225 and H.245 traffic.

2-6 Sniffer Voice


NOTE: Because capture filters require a certain amount of processing overhead, you may want to use an Expert filter instead when non-VoIP traffic comprises less than 10% of your total traffic.

How Sniffer Voice Protocol Filters WorkSniffer Voice identifies and filters VoIP protocols using special heuristics. This section provides an overview of these heuristics, giving you insight into how these protocol filters work and how you might use them most effectively in your own voice networking environment.

In some cases, protocols are always seen on a specific TCP or UDP port, enabling easy identification. In other cases, the heuristics are more complicated, involving multiple individual identifications that by themselves are not conclusive but become more meaningful in combination.

The heuristics used for each protocol are listed and described below.

H.225 Call Signalling

Sniffer Voice identifies and filters H.225 Call Signalling traffic by looking for traffic seen transmitted over TCP port 1720.

H.225 RAS

Sniffer Voice identifies and filters RAS traffic by looking for traffic seen transmitted over UDP port 1718 or 1719.

H.245 Media Control

Sniffer Voice identifies and filters H.245 Media Control traffic using heuristics. TCP port numbers for H.245 are dynamically allocated based on exchanges of H.225 messages. Sniffer Voice learns these port numbers by extracting them from H.225 Connect and Alerting messages. Each time Sniffer Voice learns a port number used for H.245, it adds it to a list of known H.245 port numbers.

Sniffer Voice uses this list of H.245 port numbers to conclusively identify a frame as H.245. First, Sniffer Voice uses the following tests on a frame to identify it as possibly being H.245:

• The length of the frame’s data field must be greater than 4 bytes and less than 1000 bytes.

• The first byte of the frame must be 0x03.



• The second byte of the frame must not be 0xC0.

• The third and fourth bytes of the frame must not be 0x0100.

• The H.245 Message Type field of the frame must be greater than or equal to zero and less than or equal to three.

If a given frame passes each of these tests, Sniffer Voice compares its source and destination TCP port numbers to the list of known H.245 port numbers extracted from H.225 messages. If there is a match, Sniffer Voice concludes that the frame is an H.245 frame.

RTP

Sniffer Voice identifies and filters RTP traffic using heuristics. RTP is carried over UDP on dynamically assigned ports. For Sniffer Voice to identify and filter an RTP frame, the frame must pass the following tests:

• The length of the frame must be greater than or equal to 12 bytes and less than or equal to 1000 bytes.

• The value of the Payload Type field must be less than 35 or between 96 and 127, inclusive.

• The value of the Version field must be 2.

• The length of the frame must meet certain conditions depending on the value of the Payload Type field, as follows:

– For the following Payload Types, the length of the frame does not matter:

PCMU_AUDIO (0)AUDIO_1016 (1)G721_AUDIO (2)GSM_AUDIO (3)G723_AUDIO (4)DV148KZ_AUDIO (5)DV1416KZ_AUDIO (6)LPC_AUDIO (7)PCMA_AUDIO (8)G722_AUDIO (9)L16_STEREO_AUDIO (10)L16_MONO_AUDIO (11)TPS0_AUDIO (12)VSC_AUDIO (13)G728_AUDIO (15)UNASSIGNED_MIN_AUD (16)G729_AUDIO (18)UNASSIGNED_MAX_AUD (22)RGB8_VIDEO (23)HDCC_VIDEO (24)

2-8 Sniffer Voice


CUSM_VIDEO (27)NV_VIDEO (28)PICW_VIDEO (29)CPV_VIDEO (30)MP2T_VIDEO (33)

– For the following Payload Types, the length of the frame must be greater than or equal to 16 bytes:

MPA_AUDIO (14)MPV_VIDEO (32)H263_VIDEO (34)

– For the following Payload Types, the length of the frame must be greater than or equal to 20 bytes:

CELB_VIDEO (25)JPEG_VIDEO (26)

– For the following Payload Type, the length of the frame must be greater than or equal to 25 bytes:

H261_VIDEO (31)

– For dynamic Payload Types from 96-127, inclusive, the length of the frame must be greater than 12 and less than 200 bytes.

RTCP

Sniffer Voice identifies and filters RTCP traffic using heuristics. RTCP is carried over UDP on dynamically assigned ports. For Sniffer Voice to identify and filter an RTCP frame, the frame must pass the following tests:

• The length of the frame must be greater than 20 bytes and less than 1000 bytes.

• The value of the Version field must be 2.

• For the first packet positively identified as RTCP, the value of the Packet Type field must be either 200 (Sender Report) or 201 (Receiver Report). In addition, the remaining data in the frame (data received after the Packet Type field) must be greater than 12 bytes.

For packets received after the first packet:

– The Packet Type field must be set to a valid RTCP value:

• 200 — Sender Report

• 201 — Receiver Report

• 202 — SDES

• 203 — BYE

• 204 — Application-defined

– The value of the Version field must be 2.



Cisco SCCP

All Cisco SCCP frames begin with a characteristic prefix structure. Sniffer Voice identifies and filters Cisco SCCP traffic by looking for this unique prefix structure in frames transmitted over TCP ports 2000, 2001, or 2002.

SIP

Sniffer Voice identifies and filters SIP traffic by looking for traffic seen transmitted over port 5060 on either TCP or UDP.

MGCP

Sniffer Voice identifies and filters MGCP traffic by looking for traffic seen transmitted over UDP port 2427 or 2727.

Megaco

Sniffer Voice identifies and filters Megaco traffic by looking for traffic seen transmitted over UDP port 2944, 2945, or 55555.

2-10 Sniffer Voice

3Expert Detail Displays for Sniffer Voice 3

OverviewThis chapter describes the Expert Detail displays provided by Sniffer Voice for VoIP protocols. Each Detail display is described in its own section.

Sniffer Voice Expert Detail DisplaysSniffer Voice provides Expert analysis for the H.323, SCCP, SIP, H.225, H.245, RAS, RTP, and RTCP protocols. In the Expert’s model of the network, these protocols all occur at the Application and Session layers. Figure 3–1 illustrates the network objects the Expert creates for VoIP protocols, as well as the Expert layer at which they occur.

Figure 3–1. Sniffer Voice Network Objects by Expert Layer

You view Detail displays for Sniffer Voice network objects in the same way you do for all other protocols:

1. Display either the Expert window (for analysis during capture) or the Expert tab in the Decode window (for post-capture analysis).

2. Select the Expert layer at which you want to view Detail displays by clicking in the Objects column at the desired layer in the Overview pane (see Figure 3–2). As shown in Figure 3–1, all Expert Detail displays for Sniffer Voice are found at the Application and Session layer.

The adjacent Summary pane automatically updates to show all network objects at the selected layer.

Application

Session

SIP Call FlowH.323 Call Flow SCCP Call Flow

SIP Call SetupRTCPH.225 H.245 SCCP Call SetupRAS RTP(Voice)


Expert Detail Displays for Sniffer Voice

3. Highlight one of the objects in the Summary pane by clicking on it. The Detail pane automatically updates to show detailed statistics for the object selected in the Summary pane.

For example, Figure 3–2 shows an H.323 object selected at the Expert Application layer (a call between two stations using the H.323 protocol suite). The Detail pane shows detailed statistics for the selected object.

Figure 3–2. The Expert Window Panes

About the Asterisk in the Expert Summary PaneThe Expert’s Summary pane lists each of the network objects detected by the Expert at the selected layer. Each detected object is listed with a set of counters and statistics. For Sniffer Voice, you may occasionally notice an asterisk next to an object’s entry in the Protocol column. This asterisk

Expert Summary Pane

Expert Overview Pane

Protocol Statistics Pane

Hierarchical Pane

Expert Detail Pane

This chapter describes the information in this pane for different types of Sniffer Voice objects selected in the Summary pane (H.323, SCPP, SIP, RTP, and so on).

3-2 Sniffer Voice


means that the indicated call is still active. In this case, “active” can mean the call is in any of the following states:

• The call is being set up.

• The call is proceeding.

• The call is being torn down.

Network Objects for Sniffer VoiceTable 3–1 lists the new network objects created by the Expert for Sniffer Voice, along with the layer at which they are found. Each of the network objects listed in Table 3–1 has a corresponding Detail display that you can view by selecting the object’s entry in the Summary pane. See the indicated sections for descriptions of the Detail display for each network object created by Sniffer Voice.

NOTE: This section does not describe the Detail displays for standard protocols analyzed by the Expert analyzer (for example, TCP, UDP, and so on). As with all protocols analyzed by the Expert, however, you can always view detailed context-sensitive information on Expert analyzer displays by clicking in the pane on which you would like to receive more information and typing F1. In response, a context-sensitive Expert Explain file will appear, describing the fields in which you are interested.

Table 3–1. Expert Detail Displays for Sniffer Voice

Expert Layer Network Object/Protocol Description

Application H.323 Call Flow page 3–4

Application SCCP Call Flow page 3–9

Application SIP Call Flow page 3–14

Session H.225 Signal page 3–19

Session H.245 page 3–23

Session RAS page 3–27

Session RTCP page 3–32

Session RTP page 3–36

Session SCCP Session page 3–40

Session SIP Call Setup page 3–44



Application Layer Expert Detail DisplaysAt the Application layer, the Sniffer Voice Expert creates network objects for connections between stations using the following protocols:

• H.323

• SIP

• Cisco’s Skinny Client Control Protocol (SCCP)

The Expert Detail display for each of these protocols is described below.

H.323 Detail DisplayThe Expert creates H.323 objects at the Application layer based on H.225 Call Signalling, H.245 Media Control, RTP, and RTCP objects at the Session layer. H.323 objects provide a means of tracking statistics related to the overall flow of an H.323 call, including all of its underlying transactions using other protocols.

H.323 is an umbrella term for a family of protocols providing real-time multimedia transport over IP networks. In the H.323 call environment, H.225 performs call setup, call connection, and call control services, while H.245 performs media control, including logical channel control and the exchange of terminal capabilities. Finally, RTP provides voice and video data transmission, while RTCP provides quality of service monitoring for RTP.

The Expert creates separate Session layer objects for each of the protocols underlying an H.323 call – H.225, H.245, RTP, RTCP, and RAS – but creates a single umbrella H.323 object at the Application layer to maintain overall statistics for a call. Because of this, each H.323 Application layer object will have multiple associated objects at the Session layer (for example, RTP, RTCP, H.225, and H.245 objects). You can see this relationship most easily in the Hierarchical pane at the left of the Detail pane. Figure 3–3 provides an example of an Application layer H.323 object, including the Hierarchical pane with its subsidiary Session layer objects.

3-4 Sniffer Voice


Figure 3–3. Detail Display for an H.323 Network Object

The Detail pane for an H.323 object at the Application layer provides the following counters and statistics:

H.225/H.245 Table

The H.225/H.245 table provides the addresses for both sides of this H.323 call, the unique call number for the call, and the conference ID for the call. The following information is provided for both sides of the H.323 call:

• Network Address – The network address indicated in H.225 messages for each side of this H.323 call, if known.

• Call Number – The call number indicated in H.225 messages for each side of this H.323 call, if known.

• User Info – The user info indicated in H.225 messages for each side of this H.323 call, if known.

• Conference ID – The conference ID indicated in H.225 messages for each side of this H.323 call, if known.

The Hierarchical pane shows the network objects underlying this H.323 object at the Application layer. Each object can be cascaded open or closed to “drill down” into lower layer objects (for example, UDP objects at the Connection layer, IP objects at the Station layer, and so on).

This section describes the counters in the Detail pane.



RTP Table

The RTP table provides statistics on RTP transactions associated with this H.323 call. H.323 uses the session layer services of RTP for the actual transmission of voice and video data.

NOTE: If this H.323 Call Flow object has more than one associated RTP object at the Session layer, the information in the RTP table is based on the first detected RTP (Voice) object associated with the H.323 Call Flow object (and not an RTP (Video) object). You can see the Session layer RTP objects associated with the H.323 Call Flow object by examining the entries in the Hierarchical pane.

The following RTP statistics are provided for both Net Station 1 and Net Station 2:

• Network Address – The network address for this side of the H.323 call.

• Port Number – The port on which each side of the H.323 call’s RTP data is seen. RTP is typically carried on top of UDP.

• Payload Type – The type of payload indicated for the RTP data stream on each side of the H.323 call (for example, different types of audio and video traffic – PCMU audio, G.711, G.729, and so on).

• Frames – The number of RTP frames sent by this side of the H.323 call.

• Bytes – The number of bytes in the RTP frames sent by this side of the H.323 call.

• Dropped Frames – The number of RTP frames dropped by this side of the H.323 call.

• Out of Sequence – The number of out of sequence RTP frames sent by this side of the H.323 call. The Expert identifies out of sequence frames by examining the sequence number included in each RTP frame. Since RTP does not guarantee sequential delivery, out of sequence frames can occur, especially during periods of variable network congestion.

3-6 Sniffer Voice


• Current/Max Jitter – The current and maximum jitter values for data sent by each side of the H.323 call. Essentially, jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and the Expert captures the same packets x and y at a spacing of 80 milliseconds, the Expert calculates jitter for this pair of packets as 30 milliseconds (the difference in packet spacing from the sending station to the Expert). The exact calculation performed by the Expert is somewhat more complicated than this since packets are continuously arriving. The Expert maintains an ongoing calculation of jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T Recommendation H.225 for complete details of the equation used).

Using the timestamps in captured RTP packets, the Expert maintains an ongoing measurement of jitter for each detected RTP session on the network.

RTCP Table

The RTCP table provides jitter statistics extracted from the RTCP Report messages associated with this H.323 call.

NOTE: If this H.323 Call Flow object has more than one associated RTCP object at the Session layer, the information in the RTCP table is based on the first detected RTCP object associated with the H.323 Call Flow object. You can see the Session layer RTCP objects associated with the H.323 Call Flow object by examining the entries in the Hierarchical pane.

H.323 uses the session layer services of RTCP to monitor the quality of service on an RTP connection. Each side of an RTP connection periodically issues an RTCP report including various quality of service statistics for the RTP connection. The Expert captures these RTCP reports and reports the value for the interarrival jitter field indicated in these reports here.

Essentially, interarrival jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and Station B receives the same packets x and y at a spacing of 80 milliseconds, interarrival jitter for this pair of packets is 30 milliseconds (the difference in packet spacing from sender to receiver). The exact calculation performed by an RTP endpoint is somewhat more complicated than this since packets are continuously arriving. Each RTP endpoint maintains an ongoing calculation of interarrival jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T



Recommendation H.225 for complete details). Whenever an RTCP Report packet is issued, the RTP endpoint includes its current value for interarrival jitter.

NOTE: The value in the RTCP table for jitter will be different than that indicated in the RTP table. This is because the value for jitter in the RTP table is calculated at the location of the Sniffer Pro (by comparing RTP timestamps to the Sniffer Pro’s capture timestamps), whereas the value in the RTCP table is calculated by the endpoints of the RTP connection. Because of the difference in physical distance, the value will be somewhat different.

• Station 1 Receiver Rpt – The last value for interarrival jitter reported in an RTCP Receiver Report sent by Net Station 1 on this connection.


• Station 1 Sender Rpt – The last value for interarrival jitter reported in an RTCP Sender Report sent by Net Station 1 on this connection.


The identification of the stations as either 1 or 2 is provided in the Summary pane for this H.323 object. Examine the Summary pane (Figure 3–3 on page 3–5) to see which station is Net Station 1 and which is Net Station 2.

Call Flow Pane

The Call Flow pane shows the exchange of H.323 messages between the parties on this call over time. Each H.225 and H.245 request is shown in the pane (for example, masterSlaveDetermination, openLogicalChannel, and so on) along with the corresponding responses over time. The Delta Time field lists the amount of time that passes between each request and the next request or response. The Relative Time field provides the cumulative total of the time used by this call, updated at each new request or response. In addition, the Call Flow pane indicates when the first underlying RTP and RTCP packets were seen for this call.

Alarms Listbox

The Alarms listbox contains the alarms generated by the Expert for this object. You can double-click on each alarm to see more detailed alarm information (including a link to the Expert Explain file for the alarm).

3-8 Sniffer Voice


Object Information

The final grid includes the total number of diagnoses and symptoms generated for this object, the time the first frame for this object was observed, and the time the last frame for this object was observed.

SCCP Detail DisplayThe Expert creates SCCP objects at the Application layer based on SCCP, RTP, and RTCP objects at the Session layer. SCCP objects provide a means of tracking statistics related to the overall flow of a SCCP call, including all of its underlying transactions using other protocols. The Expert creates unique objects for a single SCCP call by extracting the Calling Party Name and Called Party Name fields from SCCP Call Information messages.

The Skinny Client Control Protocol (SCCP) allows simple IP telephony devices to operate without implementing the entire H.323 specification. Instead, they can operate as SCCP “skinny” clients and communicate with H.323 proxies (which implement the entire H.323 specification and are called Call Managers in SCCP) to interact with H.323-compliant devices.

Because SCCP clients operate in the H.323 environment, they use the same underlying H.323 services as a normal H.323 end station. For example, SCCP clients typically use RTP for voice and video data transmission and RTCP for quality of service monitoring for RTP.

The Expert creates separate Session layer objects for each of the protocols underlying an SCCP call – H.225, H.245, RTP, and RTCP – but creates a single umbrella SCCP object at the Application layer to maintain overall statistics for an individual call. Because of this, each SCCP Application layer object will have multiple associated objects at the Session layer (for example, RTP, RTCP, and SCCP Call Setup objects). You can see this relationship most easily in the Hierarchical pane at the left of the Detail pane. Figure 3–4 provides an example of an Application layer SCCP object, including the Hierarchical pane with its subsidiary Session layer objects.



Figure 3–4. Detail Display for an SCCP Network Object at the Application Layer

SCCP objects at the Application layer are also known as SCCP Call Flow objects. This is because the Detail display at the Application layer provides statistics describing the overall flow of a single SCCP call, as well as any underlying RTP and RTCP statistics. In addition, the Expert also creates objects for SCCP connections at the Session layer. At the Session layer, SCCP objects are also known as SCCP Call Setup objects. They provide statistics detailing the exchange of different SCCP packet types used to set up SCCP calls. A SCCP Call Flow object will usually have a corresponding SCCP Call Setup object at the Session layer (as shown in Figure 3–4). See SCCP Call Setup Detail Display on page 3–40 for details on SCCP objects at the Session layer.

The Detail pane for an SCCP object at the Application layer provides the following counters and statistics:

Call Identity Table

The Call Identity table provides the network addresses for both sides of this SCCP call (Caller Party and Called Party), as well as the TCP port

The Hierarchical pane shows the network objects underlying this SCCP object at the Application layer. Each object can be cascaded open or closed to “drill down” into lower layer objects (for example, UDP objects at the Connection layer, IP objects at the Station layer, and so on).


3-10 Sniffer Voice


number used on either side of the call. In addition, the name of the station on either side of the call is provided.

• Network Address – The network address for each side of this SCCP call.

• SCCP Port – The TCP port numbers used for communications between the SCCP terminal and the Call Manager. The port number is provided for both sides of the call.

• Terminal Name – The name assigned to each side of this SCCP call.

• Terminal Number — The terminal number for each side of this SCCP call.

RTP Table

The RTP table provides statistics on RTP transactions associated with this SCCP call. SCCP uses the session layer services of RTP for the actual transmission of voice and video data.

NOTE: If this SCCP object has more than one associated RTP object at the Session layer, the information in the RTP table is based on the first detected RTP (Voice) object associated with the SCCP object (and not an RTP (Video) object). You can see the Session layer RTP objects associated with the SCCP object by examining the entries in the Hierarchical pane.


• Network Address – The network address for this side of the SCCP call.

• Port Number – The port on which each side of the SCCP call’s RTP data is seen. RTP is typically carried on top of UDP.

• Payload Type – The type of payload indicated for the RTP data stream on each side of the SCCP call (for example, different types of audio and video traffic – PCMU Audio and so on).

• Frames – The number of RTP frames sent by this side of the SCCP call.

• Bytes – The number of bytes in the RTP frames sent by this side of the SCCP call.

• Dropped Frames – The number of RTP frames dropped by this side of the SCCP call.



• Out of Sequence – The number of out of sequence RTP frames sent by this side of the SCCP call. The Expert identifies out of sequence frames by examining the sequence number included in each RTP frame. Since RTP does not guarantee sequential delivery, out of sequence frames can occur, especially during periods of variable network congestion.

• Current/Max Jitter – The current and maximum jitter values for data sent by each side of the SCCP call. Essentially, jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and the Expert captures the same packets x and y at a spacing of 80 milliseconds, the Expert calculates jitter for this pair of packets as 30 milliseconds (the difference in packet spacing from the sending station to the Expert). The exact calculation performed by the Expert is somewhat more complicated than this since packets are continuously arriving. The Expert maintains an ongoing calculation of jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T Recommendation H.225 for complete details of the equation used).


RTCP Table

The RTCP table provides jitter statistics extracted from the RTCP Report messages associated with this SCCP call.

NOTE: If this SCCP object has more than one associated RTCP object at the Session layer, the information in the RTCP table is based on the first detected RTCP object associated with the SCCP object. You can see the Session layer RTCP objects associated with the SCCP object by examining the entries in the Hierarchical pane.

SCCP uses the session layer services of RTCP to monitor the quality of service on an RTP connection. Each side of an RTP connection periodically issues an RTCP report including various quality of service statistics for the RTP connection. The Expert captures these RTCP reports and reports the value for the interarrival jitter field indicated in these reports here.

NOTE: If the Expert has not seen any RTCP reports for this SCCP connection, the RTCP table will not appear in the Detail display.

3-12 Sniffer Voice


Essentially, interarrival jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and Station B receives the same packets x and y at a spacing of 80 milliseconds, interarrival jitter for this pair of packets is 30 milliseconds (the difference in packet spacing from sender to receiver). The exact calculation performed by an RTP endpoint is somewhat more complicated than this since packets are continuously arriving. Each RTP endpoint maintains an ongoing calculation of interarrival jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T Recommendation H.225 for complete details). Whenever an RTCP Report packet is issued, the RTP endpoint includes its current value for interarrival jitter.






The identification of the stations as either 1 or 2 is provided in the Object Summary pane for this SCCP object. Display the Object view at the Application layer to see which station is Net Station 1 and which is Net Station 2.

Call Flow Pane

The Call Flow pane shows the exchange of SCCP messages between the parties on this call over time. Each SCCP message is shown in the pane (for example, StationOffHook, StationDisplayText, and so on) along with the corresponding responses over time. The Delta Time field lists the amount of time that passes between each request and the next request or response. The Relative Time field provides a cumulative total of the time used by



this call, updated at each new request or response. In addition, the Call Flow pane indicates when the first underlying RTP and RTCP packets were seen for this call.

Alarms Listbox


Object Information


SIP Call Flow Detail DisplayThe Expert creates SIP objects at the Application layer based on SIP, RTP, and RTCP objects at the Session layer. SIP objects provide a means of tracking statistics related to the overall flow of a SIP call, including all of its underlying transactions using other protocols.

The Session Initiation Protocol (SIP) is an Application layer protocol used for internet telephony, multimedia conferences, and so on. In the SIP call environment, SIP performs call setup, call connection, and call control services. In addition, SIP uses the Session layer services of RTP (for voice and video data transmission) and RTCP (for Qualify of Service monitoring). SIP calls typically use UDP as a transport, but may also use TCP.

Because SIP relies on the services of multiple Session layer protocols, a single SIP object at the Application layer in the Expert will typically have multiple associated objects at the Session layer – SIP Call Setup objects, RTP objects, and RTCP objects. You can see this relationship most easily in the Hierarchical pane at the left of the Detail pane. Figure 3–5 provides an example of an Application layer SIP object, including the Hierarchical pane with its subsidiary Session layer objects.

3-14 Sniffer Voice


Figure 3–5. Detail Display for a SIP Network Object at the Application Layer

SIP objects at the Application layer are also known as SIP Call Flow objects. This is because the Detail display at the Application layer provides statistics describing the overall flow of a single SIP call, as well as any underlying RTP and RTCP statistics. In addition, the Expert also creates objects for SIP connections at the Session layer. At the Session layer, SIP objects are known as SIP Call Setup objects. They provide statistics detailing the exchange of different SIP packet types used to set up SIP calls. A SIP Call Flow object will usually have at least one corresponding SIP Call Setup object at the Session layer (as shown in Figure 3–5), and possibly more (if, for example, a proxy server is involved). See SIP Call Setup Detail Display on page 3–44 for details on SIP objects at the Session layer.

The Detail pane for a SIP Call Flow object at the Application layer provides the following counters and statistics:

The Hierarchical pane shows the network objects underlying this SIP object at the Application layer. Each object can be cascaded open or closed to “drill down” into lower layer objects (for example, UDP objects at the Connection layer, IP objects at the Station layer, and so on).




SIP Info Table

The SIP Info table provides the URLs for both sides of this SIP call, as well as the unique call identifier for the call.

• Calling Party – The URL for the calling party on this SIP call.

• Called Party – The URL for the called part on this SIP call.

NOTE: Note that the Calling and Called Party URLs are also provided in the Net Station 1 and Net Station 2 columns in the Summary pane.

• Call ID – The unique SIP call identifier for this call.

RTP Table

The RTP table provides statistics on RTP transactions associated with this SIP call. SIP uses the session layer services of RTP for the actual transmission of voice and video data.

NOTE: If this SIP object has more than one associated RTP object at the Session layer, the information in the RTP table is based on the first detected RTP (Voice) object associated with the SIP object (and not an RTP (Video) object). You can see the Session layer RTP objects associated with the SIP object by examining the entries in the Hierarchical pane.


• Network Address – The network address for this side of the SIP call.

• Port Number – The port on which each side of the SIP call’s RTP data is seen. RTP is typically carried on top of UDP.

• Payload Type – The type of payload indicated for the RTP data stream on each side of the SIP call (for example, different types of audio and video traffic).

• Frames – The number of RTP frames sent by this side of the SIP call.

• Bytes – The number of bytes in the RTP frames sent by this side of the SIP call.

• Dropped Frames – The number of RTP frames dropped by this side of the SIP call.

3-16 Sniffer Voice


• Out of Sequence – The number of out of sequence RTP frames sent by this side of the SIP call. The Expert identifies out of sequence frames by examining the sequence number included in each RTP frame. Since RTP does not guarantee sequential delivery, out of sequence frames can occur, especially during periods of variable network congestion.

• Current/Max Jitter – The current and maximum jitter values for data sent by each side of the SIP call. Essentially, jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and the Expert captures the same packets x and y at a spacing of 80 milliseconds, the Expert calculates jitter for this pair of packets as 30 milliseconds (the difference in packet spacing from the sending station to the Expert). The exact calculation performed by the Expert is somewhat more complicated than this since packets are continuously arriving. The Expert maintains an ongoing calculation of jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T Recommendation H.225 for complete details of the equation used).


RTCP Table

The RTCP table provides jitter statistics extracted from the RTCP Report messages associated with this SIP call.

NOTE: If this SIP object has more than one associated RTCP object at the Session layer, the information in the RTCP table is based on the first detected RTCP object associated with the SIP object. You can see the Session layer RTCP objects associated with the SIP object by examining the entries in the Hierarchical pane.

SIP uses the session layer services of RTCP to monitor the quality of service on an RTP connection. Each side of an RTP connection periodically issues an RTCP report including various quality of service statistics for the RTP connection. The Expert captures these RTCP reports and reports the value for the interarrival jitter field indicated in these reports here.

Essentially, interarrival jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and Station B receives the same packets x and y at a spacing of 80 milliseconds, interarrival jitter for this pair of packets is 30 milliseconds (the difference



in packet spacing from sender to receiver). The exact calculation performed by an RTP endpoint is somewhat more complicated than this since packets are continuously arriving. Each RTP endpoint maintains an ongoing calculation of interarrival jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T Recommendation H.225 for complete details). Whenever an RTCP Report packet is issued, the RTP endpoint includes its current value for interarrival jitter.






The identification of the stations as either 1 or 2 is provided in the Summary pane for this SIP object. Examine the Summary pane (Figure 3–5 on page 3–15) to see which station is Net Station 1 and which is Net Station 2.

Call Flow Pane

The Call Flow pane shows the exchange of SIP messages between the parties on this call over time. Each SIP request is shown in the pane (for example, INVITE, ACK, BYE, and so on) along with the SIP status codes returned to the request over time. The Delta Time field lists the amount of time that passes between each request and the next response. The Relative Time field provides a cumulative total of the time used by this call, updated at each new request or response. In addition, the Call Flow pane indicates when the first underlying RTP and RTCP packets were seen for this call.

3-18 Sniffer Voice


Alarms Listbox


Object Information


Session Layer Expert Detail DisplaysAt the Session layer, the Sniffer Voice Expert creates network objects for connections between stations using the following protocols:

• H.225 Signal

• H.245

• RAS (H.225)

• RTCP

• RTP (Voice)

• SCCP Call Setup

• SIP Call Setup

The Expert Detail display for each of these protocols is described below.

H.225 Signal Detail DisplayThe Expert creates H.225 Signal objects at the Session layer based on H.225 transactions seen transmitted over TCP port 1720. H.225 Signal objects are connections between two stations using the H.225 call signalling protocol.

The H.225 Call Signalling protocol is part of the H.323 protocol suite. It is used to establish, maintain, and tear down calls between H.323 endpoints. H.225 is based heavily on the standard ISDN D-channel signalling protocol Q.931 – many of the message types are very similar, if not identical. Figure 3–6 shows the Expert window with a Session layer H.225 Call Signalling object selected in the Summary pane.



Figure 3–6. Detail Display for an H.225 Signal Network Object at the Session Layer

The Detail pane for an H.225 Signal object at the Session layer provides the following counters and statistics:

Message Table

The Message table provides counts of the various H.225 signalling messages seen for this connection. As you can see from the messages counted, there is a strong similarity to Q.931.

• Setup – The number of H.225 Setup messages seen on this connection. Setup messages are sent by calling parties to indicate their desire to set up an H.323 connection with the called party.

• Setup Ack – The number of H.225 Setup Ack messages seen on this connection. Setup Ack messages can be sent by called parties in response to Setup messages, but are not required in H.225.

• Alerting – The number of H.225 Alerting messages seen on this connection. Called parties send Alerting messages to indicate that called user alerting has started (in other words, “the telephone is ringing”).


3-20 Sniffer Voice


• Call Proceeding – The number of H.225 Call Proceeding messages seen on this connection. Call Proceeding messages are sent by called parties to indicate that the call establishment procedure has begun and that no further call establishment messages will be accepted.

• Connect – The number of H.225 Connect messages seen on this connection. Connect messages are sent by called parties to indicate that the requested call has been accepted.

• Progress – The number of H.225 Progress messages seen on this connection. Progress messages are sent either by H.323 gateways to indicate the progress of a call, or by H.323 entities before sending the Connect message.

• Facility – The number of H.225 Facility messages seen on this connection. Facility messages are sent by a called party to indicate that an incoming call must go through a gatekeeper.

• Release Complete – The number of H.225 Release Complete messages seen on this connection. Release Complete messages are sent to indicate the release of a call.

Time/Reason Table

The Time/Reason table provides statistics describing how long it took to establish this call and, if the call is complete, the reason the call was disconnected.

• Call Setup Time – The amount of time that elapsed between the first Setup message for this call and the eventual Alerting message. This statistic gives you an idea of how long it took to set up the call.

• Call Establishment Time – The amount of time that elapsed between the first Alerting message for this call and the eventual Connect message. This statistic gives you an idea of how long it took to establish the call.

• Total Connection Time – The amount of time that elapsed between the first Connect message for this call and the eventual Release Complete message. If the Release Complete message has not yet been seen, this field is blank.

• Disconnect Reason – The value of the ReleaseCompleteReason field in the Release Complete message for this call, if included.

Caller Identity Table

The Caller Identity table provides the addresses for both sides of this H.323 call, the unique call number for the call, and the conference ID for the call, as extracted from the H.225 signalling messages for the call. The



following information is provided for both the calling party and the called party:

• Network Address – The network address indicated in H.225 messages for each side of this H.323 call, if known.

• Call Number – The call number indicated in H.225 messages for each side of this H.323 call.

• User Info – The user info indicated in H.225 messages for each side of this H.323 call.

• Conference ID – The conference ID indicated in H.225 messages for each side of this H.323 call.

Application Listbox

The Application Listbox lists the next higher-layer (that is, the Application layer) objects associated with this object. The upper layer object for an H.225 Call Signalling object will typically be an H.323 object. You can double-click on each listed object to drill into the higher layers of the Expert.

Alarms Listbox


Object Information


3-22 Sniffer Voice


H.245 Detail DisplayThe Expert creates H.245 objects at the Session layer based on H.245 transactions seen transmitted over TCP. TCP port numbers for H.245 are dynamically allocated based on exchanges of H.225 messages. The Expert learns the TCP ports on which to listen for H.245 messages by extracting the port numbers from associated H.225 messages.

The H.245 protocol is part of the H.323 protocol suite. Voice over IP endpoints use H.245 to exchange end-to-end control messages. These control messages are used for opening and closing logical channels, exchanging capability information, exchanging flow control messages, and so on. Figure 3–7 shows the Expert window with a Session layer H.245 object selected in the Summary pane.

Figure 3–7. Detail Display for an H.245 Network Object at the Session Layer

The Detail pane for an H.245 object at the Session layer provides the following counters and statistics:

Messages Table

H.245 media control messages can be broadly grouped into four types – requests, responses, commands, and indications. The Messages Table




indicates the number of each type of message seen on this connection, as follows:

• Request – The number of H.245 requests seen on this connection. Requests are messages that result in actions by the requestee. They require a response from the requestee.

• Response – The number of H.245 responses seen on this connection. Responses are sent in response to H.245 requests.

• Command – The number of H.245 commands seen on this connection. Commands are like requests but do no require any explicit response.

• Indication – The number of H.245 indications seen on this connection. Indications are messages that contain information but do not require any action or response upon receipt.

Sub Messages Table

The Sub Messages table indicates the exact number of each type of H.245 message seen for this connection, as follows:

• Master/Slave Determination – Master/Slave Determination messages are sent between H.245 endpoints to determine which is the slave and which is the master.

• Master/Slave Determination Ack – Master/Slave Determination Ack messages are sent by H.245 endpoints in response to Master/Slave Determination messages. They confirm which terminal is performing which role (master or slave).

• Master/Slave Determination Reject – Master/Slave Determination Reject messages are sent to reject Master/Slave Determination messages.

• Master/Slave Determination Release – Master/Slave Determination Release messages are sent to release a master/slave negotiation when a timeout occurs.

• Capability Set – Terminal Capability Set messages are sent between H.245 endpoints to indicate a terminal’s sending and receiving capabilities, as well as the version of H.245 in use.

• Capability Set Ack – Terminal Capability Set Ack messages are sent by H.245 endpoints to indicate receipt of a Terminal Capability Set message.

• Capability Set Reject – Terminal Capability Set Reject messages are sent by H.245 endpoints to reject a Terminal Capability Set message. If any of these messages are seen, an H245 – Terminal Capability Set Reject Expert alarm will also be generated in the Expert window. The alarm display will indicate the reason for the rejection (see H245 - Terminal Capability Set Reject on page 4–9 for details on this alarm).

3-24 Sniffer Voice


• Capability Set Release – Terminal Capability Set Release messages are sent to release a capability set negotiation in case of a timeout.

• Open Logical Channel – Open Logical Channel messages are sent to attempt to open logical channels between H.323 entities.

• Open Logical Channel Ack – Open Logical Channel Ack messages are sent to confirm acceptance of the logical channel connection request.

• Open Logical Channel Reject – Open Logical Channel Reject messages are sent to reject the logical channel opening proposed in an Open Logical Channel message. If any of these messages are seen, an H245 – Open Logical Channel Reject Expert alarm will also be generated in the Expert window. The alarm display will indicate the reason for the rejection (see H245 - Open Logical Channel Reject on page 4–8 for details on this alarm).

• Open Logical Channel Confirm – Open Logical Channel Confirm message are sent during bi-directional signal to indicate that the reverse channel is open and ready for transmission.

• Close Logical Channel – Close Logical Channel messages are sent to request the closure of an open logical channel connection.

• Close Logical Channel Ack – Close Logical Channel Ack messages are sent to confirm the closure of a logical channel connection.

• Round Trip Delay Request – Round Trip Delay Request messages are sent to request the round trip delay between two communicating terminals. These messages allow H.245 users to determine whether a peer H.245 entity is still alive.

• Round Trip Delay Response – Round Trip Delay Response messages are sent in response to Round Trip Delay Requests. They indicate the round trip delay between two communicating terminals.

• Flow Control – Flow Control commands are sent to exchange encryption capabilities and to command the transmission of an initialization vector. Initialization vectors are used in shared-key encryption schemes.

• End Session – End Session commands are sent to indicate the end of an H.245 session.

• Function Not Understood – Function Not Understood (FNU) messages are sent in response to requests, responses, and commands not understood by the station sending the FNU message.

NOTE: Function Not Understood was named Function Not Supported in version 1 of H.245. It was renamed to Function Not Understood to allow the addition of a more powerful Function Not Supported command in later versions and still preserve backward compatibility with version



1. The major difference is that FNS requires the return of an offending request, response, or command in its entirety, whereas FNU does not.

• Function Not Supported – Function Not Supported messages are sent in response to requests, responses, and commands not understood by the station sending the FNS message. The offending request, response, or command is returned to the sending station in its entirety.

Application Listbox

The Application Listbox lists the next higher-layer (that is, the Application layer) objects associated with this object. The upper layer object for an H.245 object will typically be an H.323 object. You can double-click on each listed object to drill into the higher layers of the Expert.

Alarms Listbox


Object Information


3-26 Sniffer Voice


RAS Detail DisplayThe Expert creates RAS objects at the Session layer based on RAS transactions seen transmitted over UDP ports 1718 and 1719. RAS objects are connections between two stations using the RAS protocol

The Registration, Administration, and Status protocol (RAS) is part of the H.225 protocol and a member of the broader H.323 protocol suite. Before a call is set up, voice over IP endpoints use RAS to exchange registration, administration, and status messages with a gatekeeper. Figure 3–8 shows the Expert window with a Session layer RAS object selected in the Summary pane.

Figure 3–8. Detail Display for a RAS Network Object at the Session Layer

The Detail pane for a RAS object at the Session layer provides the following counters and statistics:

Gatekeeper Info Table

The Gatekeeper Info table provides statistics identifying the gatekeeper on this connection, as well as the conference ID. The following statistics are provided:




• Gatekeeper Net Address – The network address of the gatekeeper on this RAS connection.

• Gatekeeper ID – The unique gatekeeper identifier for the gatekeeper on this RAS connection. RAS messages from a gatekeeper include this identifier.

• Conference ID – The unique conference ID included in a RAS request from the client side of this connection.

• Bandwidth Request (100 bps) – The amount of bandwidth (in hundreds of bits) requested from the gatekeeper for this bidirectional call. RAS Admission Request packets carry this information in the bandWidth field. The value refers only to the bit rate for audio and video – it excludes headers and overhead.

Messages Table

The Messages table provides counts of the various RAS message types seen on this connection. Individual counts are provided for each of the following RAS message types:

• Gatekeeper Request – H.225 terminals send RAS Gatekeeper Request messages (GRQs) to request permission to register with any gatekeeper receiving the message.

• Gatekeeper Confirm – Gatekeepers accept GRQs with a Gatekeeper Confirm (GCF) message.

• Gatekeeper Reject – Gatekeepers deny GRQs with a Gatekeeper Reject (GRJ) message. RAS GRJ messages are an indication that the H.225 terminal should look for another gatekeeper with which to register. Each time the Expert sees a GRJ, it also generates the RAS – Gatekeeper Reject Expert alarm (see RAS - Gatekeeper Reject on page 4–11 for details on this alarm).

• Registration Request – H.225 terminals send RAS Registration Request messages (RRQs) to gatekeepers to request permission to register.

• Registration Confirm – Gatekeepers accept RRQs with a Registration Confirm (RCF) message. If a terminal receives an RCF, it uses the responding gatekeeper for its calls.

• Registration Reject – Gatekeepers deny RRQs with a Registration Reject (RRJ) message. RAS RRJ messages are an indication that the H.225 terminal must find another gatekeeper with which to register. Each time the Expert sees an RRJ, it also generates the RAS – Registration Reject Expert alarm (see RAS - Registration Reject on page 4–12 for details on this alarm).

3-28 Sniffer Voice


• Unregistration Request – Both H.225 terminals and gatekeepers send RAS Unregistration Request (URQ) messages to request that the association between the terminal and the gatekeeper be ended.

• Unregistration Confirm – Stations accept URQs with the Unregistration Confirm (UCF) message, ending the association between the two stations.

• Unregistration Reject – Stations reject URQs with the Unregistration Reject (URJ) message.

• Admission Request – H.225 terminals send RAS Admission Request messages (ARQs) to request access to a packet-based network from the gatekeeper.

• Admission Confirm – Gatekeepers accept ARQs with an Admission Confirm (ACF) message.

• Admission Reject – Gatekeepers deny ARQs with an Admission Reject (ARJ) message. Each time the Expert sees an ARJ, it also generates the RAS – Admission Reject Expert alarm. The alarm display includes the reason the admission request was rejected (see RAS - Admission Reject on page 4–10 for details on this alarm).

• Bandwidth Request – H.225 terminals and gatekeepers send RAS Bandwidth Request messages (BRQ) to request changes in allocated bandwidth from one another.

• Bandwidth Confirm – H.225 terminals and gatekeepers accept BRQs with RAS Bandwidth Confirm (BCF) messages.

• Bandwidth Reject – H.225 terminals and gatekeepers deny BRQs with a Bandwidth Reject (BRJ) message. Each time the Expert sees a BRJ, it also generates the RAS – Bandwidth Reject Expert alarm. The alarm display includes the reason the bandwidth request was rejected (see RAS - Bandwidth Reject on page 4–11 for details on this alarm).

• Disengage Request – H.225 terminals and gatekeepers send RAS Disengage Requests (DRQ) to disengage from one another. Disengage “request” is perhaps a misnomer since a DRQ sent from an endpoint to a gatekeeper indicates that the endpoint is being dropped. Similarly, a DRQ sent from the gatekeeper to the endpoint forces a call to be dropped (and cannot be refused).

• Disengage Confirm – H.225 terminals and gatekeepers accept DRQs with RAS Disengage Confirm (DCF) messages.

• Disengage Reject – Gatekeepers receiving DRQs from an unregistered endpoint return the RAS Disengage Reject message to the sending station.



• Location Request – H.225 terminals send RAS Location Request messages (LRQs) to request address translation services from the gatekeeper.

• Location Confirm – Gatekeepers accept LRQs with RAS Location Confirm (LCF) messages.

• Location Reject – Gatekeepers deny LRQs with a Location Reject (LRJ) message. Each time the Expert sees an LRJ, it also generates the RAS – Location Reject Expert alarm. The alarm display includes the reason the location request was rejected (see RAS - Location Reject on page 4–12 for details on this alarm).

• Info Request – Gatekeepers send RAS Info Request (IRQ) messages to H.225 terminals to request status information.

• Info Request Response – H.225 terminals send RAS Info Request Response (IRR) messages both in response to IRQ messages and, if so configured, at the regular interval specified in an Admission Confirm message received earlier.

• Non Standard Message – RAS non-standard messages are those carrying information not defined in the H.225 specification. Non-standard messages still have a standard format, allowing the addition of proprietary extensions.

• Unknown Message Response – This message is sent whenever an H.323 station receives a RAS message that it does not understand.

• Request in Progress – H.323 entities send RAS Request in Progress (RIP) messages when they receive a request to which a response cannot be generated within the timeout period. The RIP message indicates the amount of time the entity thinks it will need to satisfy the request.

• Resources Available Indicate – Gateways send RAS Resource Availability Indication (RAI) messages to inform a gatekeeper of its current call capacity for each H-series protocol (H.225, H.245, RTP, RTCP, and so on).

• Resources Available Confirm – Gatekeepers respond to RAI messages with RAS Resources Available Confirm (RAC) messages indicating receipt of the RAI message.

• Info Request Ack – Gatekeepers send RAS Info Request Ack (IACK) messages to positively acknowledge unsolicited IRRs sent from H.225 terminals with the needResponse field set to true.

3-30 Sniffer Voice


• Info Request Nak – Gatekeepers send RAS Info Request Nak (INAK) messages to negatively acknowledge unsolicited IRRs sent from H.225 terminals with the needResponse field set to true. The INAK includes a nakReason field indicating the reason why the IRR was negatively acknowledged.

Application Listbox

The Application Listbox lists the next higher-layer (that is, the Application layer) objects associated with this object. There are no upper layer objects associated with a RAS object.

Alarms Listbox


Object Information




RTCP Detail DisplayThe Expert creates RTCP objects at the Session layer both based on H.245, SIP, or SCCP transactions seen transmitted over UDP and using proprietary heuristics. UDP port numbers for RTCP are dynamically allocated based on exchanges of H.245, SIP, or SCCP messages (depending on the upper layer protocol using RTP/RTCP’s services). The Expert learns the UDP ports on which to listen for RTCP messages by extracting the port numbers from associated messages.

The Real-Time Transport Control Protocol (RTCP) is used to monitor and report statistics on the quality of an ongoing RTP transaction between two or more endpoints. Each of the endpoints in an RTP transaction periodically issues RTCP report packets providing various statistics measuring the quality of the RTP data stream it is receiving. The Expert captures and decodes these packets, reporting the enclosed statistics in this display. Figure 3–9 shows the Expert window with a Session layer RTCP object selected in the Summary pane.

Figure 3–9. Detail Display for an RTCP Network Object at the Session Layer

The Detail pane for an RTCP object at the Session layer provides the following counters and statistics:


3-32 Sniffer Voice


RTCP Sender Info Table

The RTCP Sender Info table provides identifying information for the endpoints of an RTP connection extracted from Source Description (SDES) RTCP packets. The only required field in an RTCP SDES packet is the CNAME field. The other fields are optional. Because of this, some of the fields in this table may be empty if your network’s implementation does not use some of the optional SDES fields.

• Net Address – The network address for each side of the connection.

• CName – The value for CNAME (canonical name) indicated in an RTCP SDES packet. Because SSRCs can change, CNAMEs are used to bind an SSRC identifier to an unchanging source identifier.

• User Name – The value for NAME indicated in an RTCP SDES packet. This field is intended to carry a description of the sending equipment.

• eMail – The value for EMAIL indicated in an RTCP SDES packet. This field is intended to carry the email address of the person responsible for the sending equipment.

• Phone – The value for PHONE indicated in an RTCP SDES packet. This field is intended to carry the telephone number of the person responsible for the sending equipment.

• Loc – The value for LOC indicated in an RTCP SDES packet. This field is intended to indicate the geographical location of the sending equipment.

• Tool – The value for TOOL indicated in an RTCP SDES packet. This field is intended to carry the application or tool name of the sending equipment.

• Note – The value for NOTE indicated in an RTCP SDES packet. This field is intended to carry either a notice for or the status of the sending equipment.

RTCP Source Table

The RTCP Source table provides information extracted from RTCP report packets sent from each station on this connection. The following fields are provided for each side of the connection:


• NTP Timestamp – The value of the NTP timestamp field in the last RTCP report packet sent from this station. The NTP timestamp indicates the time when the report packet was sent.



• RTP Timestamp – The value of the RTP timestamp field in the last RTCP report packet sent from this station. The RTP timestamp corresponds to the value of the NTP timestamp, but in the same units as the RTP timestamps found in data packets. This correspondence allows stations whose NTP timestamps are synchronized to perform intra and inter-media synchronization.

• Packet Count – The value of the sender’s packet count field in the last RTCP report packet sent from this station. This value indicates the total number of RTP data packets sent by the sender from transmission start until the time this RTCP report packet was sent. If the sender changes its SSRC identifier, this value is reset to zero.

• Octet Count – The number of bytes in the packets indicated in the sender’s packet count field in the last RTCP report packet sent from this station.

• # of BYE Packets – The number of RTCP BYE packets seen by the Expert for each side of this connection. RTCP BYE packets indicate the end of participation in a connection.

RTCP Report Table

The RTCP Report table provides statistics from RTCP Sender and Receiver Report packets. The following statistics are broken out by the different types of reports from which they were extracted – Station 1 Receiver Reports, Station 1 Sender Reports, Station 2 Receiver Reports, and Station 2 Sender Reports (from left to right).

• Net Address – The network address from which the indicated type of RTCP report was sent.

• SSRC – The last Synchronization Source identifier seen in the indicated RTCP report for this side of the connection. The SSRC is a unique 32-bit identifier for the source of a stream of RTP packets.

• Fraction Lost – The fraction of RTP data packets from the SSRC indicated in this report packet lost since the previous Sender or Receiver Report packet was sent.

• Lost Frames – The total number of RTP data packets from the SSRC indicated in this report packet lost since the beginning of reception. This value is the number of packets expected minus the number of packets actually received. The number of packets received includes late-arriving and duplicate packets. Because of this, late-arriving packets are not counted as lost and the indicated value can be negative if there are duplicates.

• Ext High Seq Rcv – The highest sequence number received in an RTP data packet from the SSRC indicated in this report packet.

3-34 Sniffer Voice


• Jitter (payload units) – The value indicated for interarrival jitter in the indicated RTCP report packet. Interarrival jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and Station B receives the same packets x and y at a spacing of 80 milliseconds, interarrival jitter for this pair of packets is 30 milliseconds (the difference in packet spacing from sender to receiver). The exact calculation performed by an RTP endpoint is somewhat more complicated than this since packets are continuously arriving. Each RTP endpoint maintains an ongoing calculation of interarrival jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T Recommendation H.225 for complete details). Whenever an RTCP Report packet is issued, the RTP endpoint includes its current value for interarrival jitter.

• Last SR Timestamp –The value indicated for the last SR timestamp field in the indicated RTCP report packet. This field shows the time the last RTCP Sender Report was received by this station. The timestamp is expressed using the format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900.

• Delay SR – The value indicated for the delay since last SR timestamp field in the indicated RTCP report packet. This field shows the delay (expressed in units of 1/65536 seconds) between the time this station received the last Sender Report and when it sent this report. If this station did not receive a Sender Report for this SSRC before sending this report, the value for this field is zero.

• # of Reports – The number of each type of RTCP Report packets seen for this connection, broken out by endpoint.

Application Listbox

The Application Listbox lists the next higher-layer (that is, the Application layer) objects associated with this object. The upper layer object for an RTCP connection will be either an H.323, SIP Call Flow, or an SCCP object. You can double-click on each listed object to drill into the higher layers of the Expert.

Alarms Listbox




Object Information


RTP Detail DisplayThe Expert creates RTP objects at the Session layer both based on H.245, SIP, or SCCP transactions seen transmitted over UDP (or TCP, although RTP typically runs over UDP) and using proprietary heuristics. Port numbers for RTP are dynamically allocated based on exchanges of H.245, SIP, or SCCP messages (depending on the upper layer protocol using RTP’s services). The Expert learns the ports on which to listen for RTP messages by extracting the port numbers from associated messages.

The Real-Time Transport Protocol (RTP) provides end-to-end delivery services for time-sensitive data, such as interactive audio and video. It is commonly used for delivery by many application layer multimedia protocols, including H.323, SIP, and Cisco’s Skinny Client Control Protocol (SCCP).

NOTE: The Expert creates different RTP objects for voice transactions and video transactions. Although the statistics maintained are the same, you can easily determine whether the object was created for a voice or video transaction by examining its entry in the Hierarchical pane. Objects for voice transactions will read RTP (Voice). Similarly, objects for video transactions will read RTP (Video). Figure 3–10 show the entry for an RTP (Voice) object.

Figure 3–10 shows the Expert window with a Session layer RTP object selected in the Summary pane.

3-36 Sniffer Voice


Figure 3–10. Detail Display for an RTP Network Object at the Session Layer

The Detail pane for an RTP object at the Session layer provides the following counters and statistics:

RTP Statistics Table

The RTP Statistics table provides detailed information on this RTP connection. Each statistic listed below is provided for both sides of the connection – there is a separate column for each endpoint.


• Version – The version of RTP in use by each side of the connection.

• Payload Type – The type of payload indicated for the data on each side of this RTP connection. For example, 0 (PCMU Audio).

• Last Sequence Num – The last RTP sequence number seen for each side of the connection.

• RTP Timestamp (ms) – The timestamp seen in the last RTP packet from each side of the connection, expressed in milliseconds.




• SSRC – The first Synchronization Source identifier seen for each side of this RTP connection. The SSRC is a unique 32-bit identifier for the source of a stream of RTP packets. It is found in the RTP header for each packet and allows independence from a sender’s network address. For example, consider the case of a multimedia conference with both compressed audio and video to be sent via RTP from a single network address. In this case, the sending station would use separate SSRC identifiers for the audio and video stream so that the receiver can group the received packets according to their SSRC and apply the appropriate playback parameters.

NOTE: The RTP Detail screen only provides statistics for the first SSRC detected on an RTP connection between a given pair of stations. In the previous example of a multimedia conference between two stations with separate SSRC identifiers for audio and video streams, the Expert would only maintain statistics in the RTP Detail screen for the first SSRC detected between these two stations.

• CSRC – The last Contributing Source identifier seen for each side of the RTP connection. The CSRC is much like the SSRC, except it identifies the source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer. An RTP mixer receives RTP packets from one or more sources and combines the source packets into a new RTP packet to be forwarded. The forwarded packet includes a CSRC list in the header listing the SSRCs of all the sources that contributed to the combined packet.

• Frames Transmitted – The number of frames transmitted by each side of the RTP connection.

• Bytes Transmitted – The number of bytes transmitted by each side of the RTP connection.

RTP Connection Quality Table

The RTP Connection Quality table provides statistics indicating the quality of this RTP connection. The following statistics are provided for each direction of the connection (from Station 1 to Station 2 and from Station 2 to Station 1):

• Net Address – The network addresses and direction for which the remaining statistics in the column are provided (from Station 1 to Station 2 and from Station 2 to Station 1).

• Dropped Frames – The number of frames sent by each side of the connection that were dropped, expressed both as a percentage of total RTP frames sent by the station and as an absolute number.

3-38 Sniffer Voice


• Out of Sequence – The total number of out of sequence RTP frames sent by each side of the connection. RTP does not guarantee delivery of packets in the same order as they were sent. Instead, each RTP packet includes a sequence number so that a receiving station can reconstruct the sender’s sequence of packets, if necessary. The Expert examines the sequence numbers of all packets on a given RTP connection and counts the number of frames with non-consecutive sequence numbers.

• Current/Max Jitter (ms) – The interarrival jitter value calculated by the Expert for each side of the RTP connection. Both the current value and the maximum measured value for the connection are provided, separated by a forward slash (/).

Essentially, jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and the Expert captures the same packets x and y at a spacing of 80 milliseconds, the Expert calculates jitter for this pair of packets as 30 milliseconds (the difference in packet spacing from the sending station to the Expert). The exact calculation performed by the Expert is somewhat more complicated than this since packets are continuously arriving at the Sniffer Pro. The Expert maintains an ongoing calculation of jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T Recommendation H.225 for complete details of the equation used).

• Min/Max/Average Interval (ms) – The minimum, maximum, and average interval in milliseconds between RTP packets sent by each side of the connection. The Expert timestamps each RTP packet it receives and calculates the interval between arriving packets from each side of a connection. Then, it provides these statistics as follows:

– Min: The shortest interval between any two RTP packets seen from this side of the connection.

– Max: The longest interval between any two RTP packets seen from this side of the connection.

– Average: The average interval between all RTP packets seen from this side of the connection.

Application Listbox

The Application Listbox lists the next higher-layer (that is, the Application layer) objects associated with this object. The upper layer object for an RTP connection will be either an H.323, SIP Call Flow, or an SCCP object. You can double-click on each listed object to drill into the higher layers of the Expert.



Alarms Listbox


Object Information


SCCP Call Setup Detail DisplayThe Expert creates SCCP objects at the Session layer based on Skinny Client Control Protocol (SCCP) transactions seen taking place over TCP (the Expert uses proprietary heuristics to determine the port numbers). SCCP objects are connections between two stations (the SCCP “skinny” client and the Cisco Call Manager) using the SCCP protocol

The SCCP protocol allows simple IP telephony devices to operate without implementing the entire H.323 specification. Instead, they can operate as SCCP clients and communicate with H.323 proxies (which implement the entire H.323 specification and are called Call Managers in SCCP) to interact with H.323-compliant devices.

Although SCCP is an application layer protocol, the Expert creates Session layer objects for SCCP calls to provide statistics detailing the exchange of different SCCP packet types used to set up a call. Session layer objects created for SCCP are also known as SCCP Call Setup objects. Each SCCP Call Setup object will typically have a corresponding SCCP Call Flow object at the Application layer describing the overall flow of the SCCP call, as well as any underlying RTP and RTCP statistics. Figure 3–11 shows the Expert window with a Session layer SCCP object selected in the Summary pane.

3-40 Sniffer Voice


Figure 3–11. Detail Display for an SCCP Network Object at the Session Layer

The Detail pane for an SCCP Call Setup object at the Session layer provides the following counters and statistics:

SCCP Info Table

The SCCP Info table provides identifying information for both sides of this SCCP call — the SCCP client (or terminal) and the Call Manager. The following statistics are provided:

• Terminal Address – The network address of the SCCP terminal.

• Terminal Port – The TCP port used by the SCCP terminal for communications with the Call Manager.

• Terminal Name – The name assigned to this SCCP terminal.

• Terminal Number – The number assigned to this SCCP terminal.

• Call Manager Address – The network address of the Call Manager.

• Call Manager Port – The TCP port used by the Call Manager for communications with this SCCP terminal.




• RTP Receive Address – The network address and port number used for receiving RTP data at this SCCP terminal. In general, this will be the network address of the local SCCP terminal followed by the port number used for receiving RTP data. This data is extracted from the SCCP StationOpenReceiveChannel message.

• RTP Transmission Address – The destination network address and port number used for transmitting RTP data to the terminal at the other end of the call. In general, this will be the network address of the destination terminal. However, in the case of server-based conference calls, the address may refer to the MCU. This data is extracted from the SCCP StationStartMediaTransmission message.

SCCP Messages Table

The SCCP Messages provides counts of the number of various SCCP packet types seen for this SCCP call. Counts are provided for the following broad categories of SCCP messages:

• Registration/Management from Client – The number of SCCP Registration and Management messages seen sent from the client side of this SCCP connection. When an SCCP client first powers up, it registers with the Call Manager that will be its controller. The SCCP client can send the following Registration and Management messages to the Call Manager:

StationRegister, StationIpPort, StationMediaPortList, StationForwardStatReq, StationSpeedDialStatReq, StationLineStatReq, StationConfigStatReq, StationTimeDateReq, StationButtonTemplateReq, StationVersionReq, StationCapabilitiesRes, StationServerReq, StationAlarm, StationSoftKeyTemplateReq, StationSoftKeySetReq, StationRegisterAvailableLines, StationRegisterTokenReq, and StationUnregister.

• Registration/Management to Client – The number of SCCP Registration and Management messages seen sent to the client side of this SCCP connection from the Call Manager. The Call Manager can send the following Registration and Management messages to the SCCP client:

StationRegisterAck, StationRegisterReject, StationReset, StationForwardStat, StationSpeedDialStat, StationLineStat, StationConfigStat, StationDefineTimeDate, StationButtonTemplate, StationVersion, StationCapabilitiesReq, StationServerRes, StationSoftKeyTemplateRes, StationSoftKeySetRes, StationRegisterTokenAck, StationRegisterTokenReject, and StationUnregisterAck.

3-42 Sniffer Voice


• Call Control from Client – The number of SCCP Call Control messages seen sent from the client side of this connection to the Call Manager. The client can send the following SCCP Call Control messages:

StationKeyPadButton, StationEnblocCall, StationStimulus, StationOffHook, StationOffHookwithCallingPartyNumber, StationOnHook, StationHookFlash, StationDialedNumber, StationHeadsetStatus, and StationSoftKeyEvent.

• Call Control to Client – The number of SCCP Call Control messages seen sent to the client side of this connection from the Call Manager. The client can send the following SCCP Call Control messages:

StationStartTone, StationStopTone, StationSetRinger, StationSetLamp, StationSetHkFDetect, StationSetSpeakerMode, StationSetMicroMode, StationCallInfo, StationDisplayText, StationClearDisplay, StationEnunciatorCommand, StationSelectSoftKeys, StationCallState, StationDisplayPromptStatus, StationClearPromptStatus, StationDisplayNotify, StationClearNotify, StationActivateCallPlane, StationDeactivateCallPlane, and StationBackSpaceReq.

• Media Control – The number of SCCP Media Control messages seen on this SCCP connection. The Call Manager sends most Media Control messages. The exceptions to this rule are the StationMulticastMediaReceptionAck and the StationOpenReceiveChannelACK messages.

SCCP Media Control messages are as follows:

StationStartMediaTransmission, StationStopMediaTransmission, StationStartSessionTransmission, StationStopSessionTransmission, StationMulticastMediaReception, StationMulticastMediaReceptionAck, StationStopMulticastMediaReception, StationStartMulticastMediaTransmission, StationStopMulticastmediaTransmission, StationOpenReceiveChannel, StationOpenReceiveChannelAck, StationStartMediaReception, StationStopMediaReception, and StationCloseReceiveChannel.

• Call Statistics — The number of SCCP Call Statistics messages seen on this SCCP connection.

SCCP Call Statistics messages are as follows:

StationConnectionStatisticsRequest and StationConnectionStatisticsResponse.

• Keep Alive – The number of SCCP Station Keepalive messages seen on this SCCP connection.



Application Listbox

The Application Listbox lists the next higher-layer (that is, the Application layer) objects associated with this object. The only higher layer object associated with an SCCP Call Setup object is an SCCP Call Flow object. You can double-click on each listed object to drill into the higher layers of the Expert.

Alarms Listbox


Object Information


SIP Call Setup Detail DisplayThe Expert creates SIP Call Setup objects at the Session layer based on SIP transactions seen transmitted over port 5060 on either TCP or UDP. SIP Call Setup objects are connections between two stations using the SIP protocol

The Session Initiation Protocol (SIP) is an application layer protocol used for internet telephony, multimedia conferences, and so on. In the SIP call environment, SIP performs call setup, call connection, and call control services. SIP calls typically use UDP as a transport, but may also use TCP.

Although SIP is an application layer protocol, the Expert creates Session layer objects (such as this one) for SIP calls to provide statistics detailing the exchange of different SIP packet types used to set up a call. Session layer objects created for SIP are also known as SIP Call Setup objects. Each SIP Call Setup object will typically have a corresponding upper layer SIP Call Flow object at the Application layer describing the overall flow of the SIP call, as well as any underlying RTP and RTCP statistics. Figure 3–12 shows the Expert window with a Session layer SIP object selected in the Summary pane.

3-44 Sniffer Voice


Figure 3–12. Detail Display for a SIP Network Object at the Session Layer

The Detail pane for a SIP Call Setup object at the Session layer provides the following counters and statistics:

SIP Method Types Table

The SIP Method Types table provides statistics on the various SIP messages (methods) used to set up, maintain, and terminate this SIP call. Each method type is listed with the following statistics:

• Commands – The number of times this SIP packet type has been issued on this SIP call.

• Retransmissions – The number of times this SIP packet type was retransmitted. SIP packets are retransmitted when no response is received within a set amount of time. The Expert detects retransmissions by comparing sequence numbers in commands to those in responses. If a command is issued with the same sequence number but the Expert has not seen a corresponding response, it is counted as a retransmission.

• RTT – The round trip time for this SIP packet type. Round trip time is the amount of time it takes for a response to be returned from a SIP request.




• Last Response – The last SIP response code included in a response to this request on this connection.

• Status – The textual translation of the numerical SIP response code indicated in the Last Response column.

The actual SIP methods are as follows:

• Invite – SIP Invite messages are used to invite users to participate in a session (for example, a telephone call).

• Ack – SIP Ack messages are used to confirm that a client has received a final response to an Invite message.

• Options – SIP Options messages are used to query servers about their capabilities.

• Bye – SIP Bye messages are used to indicate that a user wants to release a call.

• Cancel – SIP Cancel message are used to cancel a previously sent request that has not yet been serviced.

• Register – SIP Register messages are used to register SIP client addresses with a server.

SIP URL Table

The SIP URL table provides statistics on this SIP call, including the called and calling party URLs, the unique call identifier, and the date. The exact statistics are as follows:

• From –The URL of the calling party on this SIP call.

• To – The URL of the called party on this SIP call.

• Call ID – The unique call identifier for this SIP call.

• Last Request – The code and textual description for the last SIP message seen on this call (for example, 100 ACK).

• Date – The date and time this call was first seen by the Expert.

• Call Status – The current status for this call (for example, In progress, Terminating, and so on).

Via Stations Table

The Via Stations table lists the SIP stations seen communicating through the two endpoints of this SIP call. For example, if one of the two endpoints on this call is a SIP server, multiple stations may have been seen communicating through it. Separate lists are provided for both endpoints of the SIP call (S1 and S2 – see the Summary pane to determine which station is S1 and which is S2). Each communicating station is listed with

3-46 Sniffer Voice


the version of SIP it is using, the transport it is using, and its network address. For example, SIP/2.0/UDP 166.30.210.161:54212.

Application Listbox

The Application Listbox lists the next higher-layer (that is, the Application layer) objects associated with this object. In most cases, these objects will be SIP Call Flow objects. You can double-click on each listed object to drill into the higher layers of the Expert.

Alarms Listbox


Object Information




3-48 Sniffer Voice

4Expert Alarms for Sniffer Voice4

OverviewThis chapter describes the Expert alarms Sniffer Voice can generate for various error conditions detected in a Voice over IP networking environment.

Sniffer Voice Expert AlarmsSniffer Voice includes many new Expert alarms for VoIP protocols. As with all Expert alarms, you can set severities and thresholds for each of the alarms in this section in the Tools\Options\Alarms tab. Note that not all alarms generated for Sniffer Voice have associated thresholds. Some alarms are simply generated when a particular type of error packet is seen.

Sniffer Voice provides Expert analysis for the H.323, SCCP, SIP, H.225, H.245, RAS, RTP, and RTCP protocols. In the Expert’s model of the network, these protocols all occur at the Application and Session layers. Accordingly, the Expert alarms for Sniffer Voice are all seen at the Expert Application and Session layers, too.

You view Expert alarms for Sniffer Voice protocols in the same way you do for all other protocols:

1. Display either the Expert window (for analysis during capture) or the Expert tab in the Decode window (for post-capture analysis).

2. Select the Expert layer at which you want to view Expert alarms by clicking in either the Symptoms or Diagnoses column at the desired layer in the Overview pane (see Figure 4–1). All Expert alarms for Sniffer Voice are found at the Application and Session layer.

The adjacent Summary pane automatically updates to show all alarms at the selected layer.

3. Highlight one of the alarms in the Summary pane by clicking on it. The Detail pane automatically updates to show information about the selected alarm, including a link to the context-sensitive Expert Explain file for that alarm.


Expert Alarms for Sniffer Voice

For example, Figure 4–1 shows a SIP — Server Slow Response symptom selected at the Expert Session layer. The Detail pane shows detailed statistics for the selected object.

Figure 4–1. The Expert Window Panes

Expert Alarms for Sniffer VoiceTable 4–1 lists the new Expert alarms generated by Sniffer Voice, along with the page number where you can find complete description of each alarm.

NOTE: This section does not describe the Expert alarms for standard protocols analyzed by the Expert analyzer (for example, TCP, UDP, and so on). As with all protocols analyzed by the Expert, however, you can always view detailed context-sensitive information on Expert analyzer

Expert Summary Pane

Currently shown listing all symptoms detected at the Session layer.

Expert Overview Pane

Notice that the Symptoms column is selected at the Session layer.

Protocol Statistics Pane

Hierarchical Pane

Expert Detail Pane

Provides detailed information on the alarm selected in the Summary pane (currently a SIP - Server Slow Response symptom), including a link to the alarm’s Expert Explain file.

4-2 Sniffer Voice


displays by clicking in the pane on which you would like to receive more information and typing F1. In response, a context-sensitive Expert Explain file will appear, describing the fields in which you are interested.

Table 4–1. Expert Alarms for Sniffer Voice

Expert Layer Alarm Description

Application H323 - High Call Volume page 4–4

Application H323 - Too Many Incomplete Calls page 4–5

Application SCCP - High Call Volume page 4–5

Application SCCP - Too Many Incomplete Calls page 4–6

Application SIP - High Call Volume page 4–6

Application SIP - Too Many Incomplete Calls page 4–7

Session H225 - Abnormal Disconnect page 4–8

Session H245 - Open Logical Channel Reject page 4–8

Session H245 - Terminal Capability Set Reject page 4–9

Session RAS - Admission Reject page 4–10

Session RAS - Bandwidth Reject page 4–11

Session RAS - Gatekeeper Reject page 4–11

Session RAS - Location Reject page 4–12

Session RAS - Registration Reject page 4–12

Session RTCP - Report High Jitter page 4–13

Session RTP - High Jitter Rate page 4–15

Session RTP - Too Many Dropped Frames page 4–16

Session RTP - Too Many Out of Sequence Frames

page 4–17

Session SCCP - Register Reject page 4–18

Session SCCP - Station Alarm page 4–18

Session SIP - Client Error page 4–18

Session SIP - Global Error page 4–20

Session SIP - Server Error page 4–20

Session SIP - Server Slow Response page 4–21



Application Layer Expert AlarmsThis section describes the Expert alarms for Sniffer Voice at the Application layer.

H323 - High Call VolumeThe Expert generates the H323 – High Call Volume alarm when the number of simultaneous H.323 calls on the network exceeds the Max concurrent calls threshold. This threshold is found under the [VOIP] H323 – High call volume alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

During capture, the Expert maintains a counter of the number of H.323 calls currently open. Each time a new H.323 call is opened, the Expert increments the counter. Each time a call is released (that is, the Expert sees the H.225 Release Complete message for the call), the counter is decremented. Every fifteen seconds, the Expert checks this counter to see if it exceeds the value specified in the Expert UI Object Properties dialog box for the Max concurrent calls threshold. If the number of open H.323 calls exceeds the threshold, the Expert generates the H323 – High Call Volume alarm.

NOTE: Be sure to set the Max concurrent calls threshold to a value that makes sense for your network. If the Expert is generating multiple instances of this alarm but your network is not experiencing any other difficulties, you may want to increase the value of the threshold so that the alarm is only generated when the call volume becomes problematic for your network.

4-4 Sniffer Voice


H323 - Too Many Incomplete CallsThe Expert generates the H323 – Too Many Incomplete Calls alarm when the number of incomplete H.323 calls observed by the Expert exceeds the Max incomplete calls threshold. This threshold is found under the [VOIP] H323 – Too many incomplete calls alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

The Expert considers an H.323 call to be incomplete if more than three minutes elapses after the last frame observed for the call and it doesn’t see a call termination message (H.225 Release Complete) for the call. The Expert keeps a counter of these incomplete calls. Every fifteen seconds, the Expert checks the incomplete calls counter to see if it exceeds the value specified in the Expert UI Object Properties dialog box for the Max incomplete calls threshold. If the number of incomplete H.323 calls exceeds the threshold, the Expert generates the H323 – Too Many Incomplete Calls alarm.

Possible cause:1. Incomplete calls can be caused by unexpected shutdowns of network

equipment (for example, because a device was turned off), abnormal channel disconnections, or other network problems.

SCCP - High Call VolumeThe Expert generates the SCCP – High Call Volume alarm when the number of simultaneous calls on the network using Cisco’s Skinny Client Control Protocol (SCCP) exceeds the Max concurrent calls threshold. This threshold is found under the [VOIP] SCCP – High call volume alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

During capture, the Expert maintains a counter of the number of SCCP calls currently open. Each time a new SCCP call is opened, the Expert increments the counter. Each time a call is released (that is, the Expert sees the SCCP StationStopMediaTransmission message for the call), the counter is decremented. Every fifteen seconds, the Expert checks this counter to see if it exceeds the value specified in the Expert UI Object Properties dialog box for the Max concurrent calls threshold. If the number of open SCCP calls exceeds the threshold, the Expert generates the SCCP – High Call Volume alarm.

NOTE: Be sure to set the Max concurrent calls threshold to a value that makes sense for your network. If the Expert is generating multiple



instances of this alarm but your network is not experiencing any other difficulties, you may want to increase the value of the threshold so that the alarm is only generated when the number of calls becomes problematic for your network.

SCCP - Too Many Incomplete CallsThe Expert generates the SCCP – Too Many Incomplete Calls alarm when the number of incomplete calls using Cisco’s Skinny Client Control Protocol (SCCP) observed by the Expert exceeds the Max incomplete calls threshold. This threshold is found under the [VOIP] SCCP – Too many incomplete calls alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

The Expert considers an SCCP call to be incomplete if more than three minutes elapses after the last frame observed for the call and it doesn’t see a call termination message (SCCP StationStopMediaTransmission) for the call. The Expert keeps a counter of these incomplete calls. Every fifteen seconds, the Expert checks the incomplete calls counter to see if it exceeds the value specified in the Expert UI Object Properties dialog box for the Max incomplete calls threshold. If the number of incomplete SCCP calls exceeds the threshold, the Expert generates the SCCP – Too Many Incomplete Calls alarm.



SIP - High Call VolumeThe Expert generates the SIP – High Call Volume alarm when the number of simultaneous SIP calls on the network exceeds the Max concurrent calls threshold. This threshold is found under the [VOIP] SIP – High call volume alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

During capture, the Expert maintains a counter of the number of SIP calls currently open. Each time a new SIP call is opened, the Expert increments the counter. Each time a call is released (that is, the Expert sees the SIP BYE message for the call), the counter is decremented. Every fifteen seconds, the Expert checks this counter to see if it exceeds the value specified in the Expert UI Object Properties dialog box for the Max concurrent calls

4-6 Sniffer Voice


threshold. If the number of open SIP calls exceeds the threshold, the Expert generates the SIP – High Call Volume alarm.

NOTE: Be sure to set the Max concurrent calls threshold to a value that makes sense for your network. If the Expert is generating multiple instances of this alarm but your network is not experiencing any other difficulties, you may want to increase the value of the threshold so that the alarm is only generated when the number of calls becomes problematic for your network.

SIP - Too Many Incomplete CallsThe Expert generates the SIP – Too Many Incomplete Calls alarm when the number of incomplete SIP calls observed by the Expert exceeds the Max incomplete calls threshold. This threshold is found under the [VOIP] SIP – Too many incomplete calls alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

The Expert considers a SIP call to be incomplete if more than three minutes elapses after the last frame observed for the call and it doesn’t see a call termination message (SIP BYE) for the call. The Expert keeps a counter of these incomplete calls. Every fifteen seconds, the Expert checks the incomplete calls counter to see if it exceeds the value specified in the Expert UI Object Properties dialog box for the Max incomplete calls threshold. If the number of incomplete SIP calls exceeds the threshold, the Expert generates the SIP – Too Many Incomplete Calls alarm.





Session Layer Expert AlarmsThis section describes the Expert alarms for Sniffer Voice at the Session layer.

H225 - Abnormal DisconnectThe Expert generates the [VOIP] H225 – Abnormal Disconnect alarm when it observes an H.225 Release Complete message with either the ReleaseCompleteReason or Cause information element set to one of the following:

• noBandwidth — Bandwidth taken away or ARQ denied

• gatekeeperResources — Gatekeeper exhausted

• gatewayResources — Switching equipment congestion

• adaptiveBusy — Call is dropping due to LAN crowding

H245 - Open Logical Channel RejectThe Expert generates the [VOIP] H245 – Open Logical Channel Reject alarm when it observes an H.245 Open Logical Channel Reject message.

One of the purposes of H.245 is to govern the opening and closing of logical channels and ensure that receiving stations have the capability to decode the data to be sent to them before they actually receive any data. H.245 Open Logical Channel messages include an indication of the type of data to be sent over the proposed logical channel (as well as the speed at which it will be sent). If a receiving station will be unable to receive and decode the proposed data properly, it sends an Open Logical Channel Reject message rejecting the request to open a logical channel.

The Open Logical Channel Reject message includes a cause field indicating the reason why the request was rejected. The possible values for the cause field are as follows:

• unspecified – No cause for rejection was specified.

• unsuitableReverseParameters – The requested reverse logical channel parameters for a bi-directional logical channel request were not appropriate.

• dataTypeNotSupported – The data type indicated in the Open Logical Channel message was not supported by the receiving station.

4-8 Sniffer Voice


• dataTypeNotAvailable – The receiving station is incapable of supporting the data type indicated in the Open Logical Channel message in combination with data types already in use on other open logical channels.

• unknownDataType – The receiving station did not understand the data type indicated in the Open Logical Channel message.

• dataTypeALCombinationNotSupported – The receiving station is incapable of supporting the data type indicated in the Open Logical Channel message in combination with the Adaptation Layer type indicated in the H223 Logical Channel Parameters field.

• multicastChannelNotAllowed – A multicast channel could not be opened.

• insuffientBandwdith – A channel could not be opened because permission to use the bandwidth requested in the Open Logical Channel message was not granted.

• separateStackEstablishmentFailed – It was not possible to run the data portion of a call on a separate stack.

• invalidSessionID – The slave attempted to set the Session ID when opening the logical channel to the master.

• masterSlaveConflict – The slave attempted to open a logical channel on which the master has identified a possible conflict.

• waitForCommunicationMode – There was an attempt to open the logical channel before the Multipoint Control Entity transmitted the Communication Mode Command.

• invalidDependentChannel – An invalid dependent channel was specified for the attempted logical channel.

• replacementForRejected – The type of logical channel attempted can not be opened with the replacementFor parameter.

H245 - Terminal Capability Set RejectThe Expert generates the [VOIP] H245 – Terminal Capability Set Reject alarm when it observes an H.245 Terminal Capability Set Reject message.

H.245-capable terminals exchange H.245 terminal capability messages to determine the different transmit and receive modes of which each is capable (for example, CIF H.263 video, G.723.1 audio, and so on). H.245 Terminal Capability Set messages include a capability table listing these transmit and receive modes. H.245-capable stations reject Terminal Capability Set messages by sending the Terminal Capability Set Reject message. The reject message includes a cause field indicating the reason for the rejection. The possible values for the cause field are as follows:



• undefinedTableEntryUsed – One of the capability descriptors in the Terminal Capability Set message referred to an undefined capability table entry.

• descriptorCapacityExceeded – The receiving station could not store all the information in the Terminal Capability Set message.

• tableEntryCapacityExceeded – Either the receiving station could not store more capability table entries than indicated in the highestEntryNumberProcessed field or could not store any entries at all.

RAS - Admission RejectThe Expert generates the [VOIP] RAS – Admission Reject alarm when it observes a RAS Admission Reject (ARJ) message.

In the H.323 protocol stack, the Registration, Admission, and Status (RAS) protocol provides H.225 terminal to gatekeeper signalling services. H.225 terminals send RAS Admission Request messages (ARQs) to request access to a packet-based network from the gatekeeper. In turn, gatekeepers respond to ARQs with either an Admission Confirm (ACF) message granting the request or an Admission Reject (ARJ) message denying the request.

The ARJ message includes a rejectReason field indicating the reason why the ARQ was denied. The possible values for the rejectReason field for an ARJ are as follows:

• Called Party not Registered (address cannot be translated)

• Invalid Permission (permission expired)

• Request Denied (no bandwidth available)

• Undefined Reason• Caller not Registered

• Route Call to Gatekeeper

• Invalid Endpoint Identifier• Resource Unavailable

• Security Denial

• QOS Control Not Supported

• Incomplete Address

4-10 Sniffer Voice


RAS - Bandwidth RejectThe Expert generates the [VOIP] RAS – Bandwidth Reject alarm when it observes a RAS Bandwidth Reject (BRJ) message.

In the H.323 protocol stack, the Registration, Admission, and Status (RAS) protocol provides H.225 terminal to gatekeeper signalling services. H.225 terminals and gatekeepers send RAS Bandwidth Request messages (BRQ) to request changes in allocated bandwidth from one another. When a terminal or gatekeeper receives a BRQ, it can respond with either a Bandwidth Confirm (BCF) message granting the request or a Bandwidth Reject (BRJ) message denying the request.

The BRJ message includes a rejectReason field indicating the reason why the BRQ was denied. The possible values for the rejectReason field for a BRJ are as follows:

• Not Bound (discovery permission aged out)

• Invalid Conference ID (possible revision)

• Invalid Permission (true permission violation)• Insufficient Resources

• Invalid Revision

• Undefined Reason

• Security Denial

RAS - Gatekeeper RejectThe Expert generates the [VOIP] RAS – Gatekeeper Reject alarm when it observes a RAS Gatekeeper Reject (GRJ) message.

In the H.323 protocol stack, the Registration, Admission, and Status (RAS) protocol provides H.225 terminal to gatekeeper signalling services. H.225 terminals send RAS Gatekeeper Request messages (GRQs) to request permission to register with any gatekeeper receiving the message. In turn, gatekeepers respond to GRQs with either a Gatekeeper Confirm (GCF) message granting the request or a Gatekeeper Reject (GRJ) message denying the request. RAS GRJ messages are an indication that the H.225 terminal should look for another gatekeeper with which to register.

The GRJ message includes a rejectReason field indicating the reason why the GRQ was denied. The possible values for the rejectReason field for a GRJ are as follows:

• Resource Unavailable

• Terminal Excluded (permission failure; not a resource failure)





• Security Denial

RAS - Location RejectThe Expert generates the [VOIP] RAS – Location Reject alarm when it observes a RAS Location Reject (LRJ) message.

In the H.323 protocol stack, the Registration, Admission, and Status (RAS) protocol provides H.225 terminal to gatekeeper signalling services. H.225 terminals send RAS Location Request messages (LRQs) to request address translation services from the gatekeeper. In turn, gatekeepers respond to LRQs with either a Location Confirm (LCF) message containing the transport address of the requested destination or a Location Reject (LRJ) message denying the request.

The LRJ message includes a rejectReason field indicating the reason why the LRQ was denied. The possible values for the rejectReason field for an LRJ are as follows:

• Not Registered (requesting terminal is not registered with gatekeeper)

• Invalid Permission (exclusion by an administrator or feature)

• Request Denied (location cannot be found)• Undefined Reason

• Security Denial

RAS - Registration RejectThe Expert generates the [VOIP] RAS – Registration Reject alarm when it observes a RAS Registration Reject (RRJ) message.

In the H.323 protocol stack, the Registration, Admission, and Status (RAS) protocol provides H.225 terminal to gatekeeper signalling services. H.225 terminals send RAS Registration Request messages (RRQs) to gatekeepers to request permission to register. In turn, gatekeepers respond to RRQs with either a Registration Confirm (RCF) message granting registration or a Registration Reject (RRJ) message denying registration. If the terminal receives an RCF, it uses the responding gatekeeper for its calls; if it receives an RRJ, it must find a different gatekeeper with which to register.

The RRJ message includes a rejectReason field indicating the reason why the RRQ was denied. The possible values for the rejectReason field for an RRJ are as follows:

• Discovery Required

4-12 Sniffer Voice



• Invalid Call Signal Address

• Invalid RAS Address (the supplied address is invalid)

• Duplicate Alias (the provided alias is registered to another terminal)• Invalid Terminal Type


• Transport not Supported

• Transport Quality of Service (QOS) not Supported (the endpoint's QOS is not supported)

• Resource Unavailable (gatekeeper resources are exhausted)

• Invalid Alias (the provided alias is not consistent with gatekeeper rules)

• Security Denial

RTCP - Report High JitterThe Expert generates the [VOIP] RTCP – Report High Jitter alarm when the interarrival jitter reported in either an RTCP Sender Report or Receiver Report packet exceeds the Max jitter threshold. This threshold is found under the [VOIP] RTCP – Report high jitter alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

The Real-Time Transport Control Protocol (RTCP) is used to monitor and report statistics on the quality of an ongoing RTP transaction between two or more endpoints. Each of the endpoints in an RTP transaction periodically issues RTCP report packets providing various statistics measuring the quality of the RTP data stream it is receiving. RTCP report packets (both Sender Reports and Receiver Reports) always include an interarrival jitter statistic.

Essentially, interarrival jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and Station B receives the same packets x and y at a spacing of 80 milliseconds, interarrival jitter for this pair of packets is 30 milliseconds (the difference in packet spacing from sender to receiver). The exact calculation performed by an RTP endpoint is somewhat more complicated than this since packets are continuously arriving. Each RTP endpoint maintains an ongoing calculation of interarrival jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T Recommendation H.225 for complete details). Whenever an RTCP Report



packet is issued, the RTP endpoint includes its current value for interarrival jitter.

The Expert captures all RTCP Report packets. If the value reported for interarrival jitter in one of these Report packets exceeds the Max jitter threshold (expressed in milliseconds), the Expert generates the RTCP – Report High Jitter alarm for the RTP session. The alarm display provides a breakdown of the individual jitter alarms for a given connection, indicating for which side of the connection different alarms have been generated, as well as the source of the last RTCP Report packet the Expert has seen for this RTP connection.

The alarm display provides the following information:

• Last Report Source – The source of the last RTCP Report packet for this RTP connection. In addition to the source's address, the type of report is also indicated (Sender Report or Receiver Report).

• Threshold – The value of the Max jitter threshold when this alarm was generated.

• Reported Jitter – The value indicated for interarrival jitter in the last received RTCP Report packet for this RTP connection.

• # of Net Station 1 Send Jitter Alarms – The number of jitter alarms indicated in Sender Reports issued by Net Station 1 on this RTP session.

• # of Net Station 1 Recv Jitter Alarms – The number of jitter alarms indicated in Receiver Reports issued by Net Station 1 on this RTP session.

• # of Net Station 2 Send Jitter Alarms – The number of jitter alarms indicated in Sender Reports issued by Net Station 2 on this RTP session.

• # of Net Station 2 Recv Jitter Alarms – The number of jitter alarms indicated in Receiver Reports issued by Net Station 2 on this RTP session.

4-14 Sniffer Voice


RTP - High JitterThe Expert generates the [VOIP] RTP –High Jitter alarm when the jitter measured by the Expert for an RTP session exceeds the Max jitter threshold. This threshold is found under the [VOIP] RTP – High jitter alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

Essentially, jitter measures the mean difference in interpacket spacing between a sending station and a receiving station. For example, if Station A sends packets x and y at a spacing of 50 milliseconds and the Expert captures the same packets x and y at a spacing of 80 milliseconds, the Expert calculates jitter for this pair of packets as 30 milliseconds (the difference in packet spacing from the sending station to the Expert). The exact calculation performed by the Expert is somewhat more complicated than this since packets are continuously arriving. The Expert maintains an ongoing calculation of jitter so that the value becomes a statistically smoothed mean for all packets received (see Annex A of ITU-T Recommendation H.225 for complete details of the equation used).

Using the timestamps in captured RTP packets, the Expert maintains an ongoing measurement of jitter for each detected RTP session on the network. If the measured value for jitter exceeds the Max jitter threshold (expressed in milliseconds), the Expert generates the RTP – High Jitter alarm for the offending RTP session.

NOTE: Because the RTP – High Jitter alarm is based on the difference in interpacket spacing between a sending station and the Expert, the frequency of these alarms will depend in part on how far physically the Sniffer Pro is from the sending station. This is also why the Expert generates the RTCP – Report High Jitter and the RTP – High Jitter alarms differently. The RTCP – Report High Jitter alarm is based on RTCP Report packets issued by the endpoints of an RTP connection. RTCP Report packets report the jitter seen between the endpoints of the RTP connection. In contrast, the RTP – High Jitter alarm is based on the jitter measured by the Expert between the sending station and itself – a distance shorter than that between the two endpoints of the RTP connection.

For example, suppose the Sniffer Pro is placed halfway between RTP Station A and RTP Station B. Theoretically, the jitter measured for an RTP session between these two stations will be less at the Sniffer Pro than at either of the endpoints (since the distance is less).




• Direction – The direction of the connection on which the high jitter was observed (for example, [168.34.123.1] -> [168.34.123.2].

• Threshold – The value of the Max jitter threshold when this alarm was generated.

• RTP Jitter – The last value measured for jitter by the Expert for this RTP connection.

• # of Net Station 1 -> Net Station 2 Alarms – The number of High Jitter alarms generated for traffic from Net Station 1 to Net Station 2.

• # of Net Station 2 -> Net Station 1 Alarms – The number of High Jitter alarms generated for traffic from Net Station 2 to Net Station 1.

RTP - Too Many Dropped FramesThe Expert generates the [VOIP] RTP – Too Many Dropped Frames alarm when the percentage of dropped frames in either direction on an RTP connection during any single second exceeds the Percentage of dropped frames threshold. This threshold is found under the [VOIP] RTP – Too Many Dropped Frames alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

The Real-Time Transport Protocol (RTP) provides end-to-end delivery services for time-sensitive data, such as interactive audio and video. A high number of dropped frames on an RTP connection can indicate congestion and may negatively affect end-user performance of audio or video applications.


• Direction – The direction of the connection on which the high percentage of dropped frames was observed (for example, [168.34.123.1] -> [168.34.123.2].

• Threshold – The value of the Percentage of dropped frames threshold when this alarm was generated.

• Percentage of Drop Frame Count – The percentage of dropped frames measured by the Expert for this session. Because an alarm was generated, this value will be higher than the Threshold value.

• # of Net Station 1 -> Net Station 2 Alarms – The number of Too Many Dropped Frames alarms generated for traffic from Net Station 1 to Net Station 2.

4-16 Sniffer Voice


• # of Net Station 2 -> Net Station 1 Alarms – The number of Too Many Dropped Frames alarms generated for traffic from Net Station 2 to Net Station 1.

RTP - Too Many Out of Sequence FramesThe Expert generates the [VOIP] RTP – Too Many Out of Sequence Frames alarm when the number of out of sequence frames in either direction on an RTP connection exceeds the Max # of out of sequence frames threshold. This threshold is found under the [VOIP] RTP – Too Many Out of Sequence Frames alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

The Real-Time Transport Protocol (RTP) provides end-to-end delivery services for time-sensitive data, such as interactive audio and video. However, it does not guarantee delivery of packets in the same order as they were sent. Instead, each RTP packet includes a sequence number so that a receiving station can reconstruct the sender’s sequence of packets, if necessary. The Expert examines the sequence numbers of all packets on a given RTP connection. If it detects that the number of out of sequence RTP packets on a given connection (packets without consecutive sequence numbers) exceeds the Max # of out of sequence frames threshold, it generates this alarm.

Since RTP typically relies on UDP for its efficient transport, you may want to examine the underlying UDP packets to understand why RTP packets are being delivered out of sequence.


• Direction – The direction of the connection on which the offending out of sequence frames were observed (for example, [168.34.123.1] -> [168.34.123.2].

• Threshold – The value of the Max # of out of sequence frames threshold when this alarm was generated.

• Out of Seq. Frame Count – The number of out of sequence frames measured by the Expert for this session. Because an alarm was generated, this value will be higher than the Threshold value.

• # of Net Station 1 -> Net Station 2 Alarms – The number of Too Many Out of Sequence Frames alarms generated for traffic from Net Station 1 to Net Station 2.

• # of Net Station 2 -> Net Station 1 Alarms – The number of Too Many Out of Sequence Frames alarms generated for traffic from Net Station 2 to Net Station 1.



SCCP - Register RejectThe Expert generates the [VOIP] SCCP – Register Reject alarm when it observes a Skinny Client Control Protocol (SCCP) Station Register Reject message.

The SCCP protocol allows simple IP telephony devices to operate without implementing the entire H.323 specification. Instead, they can operate as SCCP “skinny” clients and communicate with H.323 proxies (called Call Managers in SCCP) to interact with H.323-compliant devices. When an SCCP skinny client comes online, it sends a registration message (StationRegister) to the Call Manager to announce its existence. The Call Manager can reject the client's registration attempt with a Station Register Reject message. When the Expert observes an SCCP Station Register Reject message, it generates this alarm.

Possible cause:1. The Station Register Reject message includes a short textual description

(up to 33 bytes) indicating both the reason the Call Manager rejected the registration attempt and the ID of the requesting station.

SCCP - Station AlarmThe Expert generates the [VOIP] SCCP – Station Alarm alarm when it observes a Skinny Client Control Protocol (SCCP) Station Alarm message.

The SCCP protocol allows simple IP telephony devices to operate without implementing the entire H.323 specification. Instead, they can operate as SCCP “skinny” clients and communicate with H.323 proxies (called Call Managers in SCCP) to interact with H.323-compliant devices. When a skinny client has an error condition to report to the Call Manager, it does so using the SCCP Station Alarm message. The Station Alarm message includes a text string of up to 80 characters indicating the nature of the error condition on the skinny client.

Possible cause:1. The Station Alarm message includes a short textual description (up to

80 characters) indicating the nature of the error condition being reported to the Call Manager.

SIP - Client ErrorThe Expert generates the [VOIP] SIP – Client Error alarm when it detects a failure response from a SIP server to a SIP client’s request with a 4xx error

4-18 Sniffer Voice


code. 4xx error codes indicate that the client should not retry the same request without modification.

The exact 4xx error code causing the alarm was one of the following:

• (400) Bad Request – The request was not understood because of bad syntax.

• (401) Unauthorized – The request requires authentication.

• (402) Payment Required – (Reserved for future use.)

• (403) Forbidden – The server understood the request but refuses to fulfill it, regardless of authentication.

• (404) Not Found – The server does not believe that the user exists in the domain specified in the Request-URI.

• (405) Method Not Allowed – The specified method is not allowed for the specified address.

• (406) Not Acceptable – The resource identified in the request can only generate responses unacceptable to the requester.

• (407) Proxy Authentication Required – The request requires prior authentication with a proxy.

• (408) Request Timeout – The server could not provide a response before the expiration indicated in the request.

• (409) Conflict – The request could not be processed because of a conflict with the requested resource.

• (410) Gone – The requested resource is no longer available on the server.

• (411) Length Required – The server requires a length field for the request.

• (413) Request Entity Too Large – The request entity is larger than the server will process.

• (414) Request-URI Too Large – The Request-URI is larger than the server will process.

• (415) Unsupported Media Type – The server is refusing the request because it is in a format not supported by the request resource.

• (420) Bad Extension – The server did not understand a protocol extension in the request.

• (480) Temporarily Not Available – The called party's end system was contacted but the called party is not currently available.

• (481) Call Leg/Transaction Does Not Exist – Either the server received a BYE request not matching any existing call leg or the server received a CANCEL request not matching any existing transaction.



• (482) Loop Detected – The request included a Via path containing itself (that is, a loop).

• (483) Too Many Hops – The request contained more hops than allowed by the Max-Forwards field in the request header.

• (484) Address Incomplete – The request contained an incomplete To address or Request-URI.

• (485) Ambiguous – The called party address indicated in the request was ambiguous.

• (486) Busy Here – The called party's end system was contacted but the called party is not currently accepting additional calls.

The alarm display indicates the exact error code that caused the alarm.

SIP - Global ErrorThe Expert generates the [VOIP] SIP – Global Error alarm when it detects a global failure response from a SIP server. Global failure responses include 6xx error codes. SIP servers send global failure responses to indicate that they have authoritative information that a particular user cannot be located or contacted.


• (600) Busy Everywhere – The called party's end system was contacted but the called party is busy and will not take the call now. This response is returned only if the client knows that no other endpoint will answer the request. Otherwise (486) Busy Here is returned (causing the Expert to generate the SIP – Client Error alarm).

• (603) Decline – The called party's machine was contacted successfully, but the user is explicitly declining participation.

• (604) Does Not Exist Anywhere – The server has definitive information that the called party does not exist anywhere.

• (606) Not Acceptable – The called party's machine was contacted successfully but some aspects of the session description were not acceptable (for example, the requested media or bandwidth).


SIP - Server ErrorThe Expert generates the [VOIP] SIP – Server Error alarm when it detects a server failure response from a SIP server. Server failure responses include 5xx error codes. SIP servers send server failure responses to

4-20 Sniffer Voice


indicate that they have experienced some sort of error. Client’s receiving SIP server failure responses typically reissue their requests to other SIP servers.


• (500) Internal Server Error – The server experienced an internal error that prevented it from servicing the request.

• (501) Not Implemented – The server can not fulfill the request because it does not provide the requisite functionality.

• (502) Bad Gateway – The server received an invalid response from a downstream server while attempting to service the request.

• (503) Service Unavailable – The server is unable to service the request due to temporary overloading or maintenance on the server.

• (504) Gateway Timeout – The server did not receive a timely response from a downstream server it accessed while attempting to service the request.

• (505) SIP Version not Supported – The server does not support the version of SIP indicated in the request.


SIP - Server Slow ResponseThe Expert generates the [VOIP] SIP – Server Slow Response alarm when the time it takes for a SIP server to respond to a client’s request exceeds the SIP Slow response time threshold. This threshold is found under the [VOIP] SIP – Server Slow Response alarm entry in the Alarms tab of the Expert UI Object Properties dialog box (accessed by selecting Expert Options from the Tools menu).

Because all responses to a SIP request must use the same values in the Call-ID, CSeq, To, and From fields, the Expert is able to match responses from a SIP server to the corresponding request from a SIP client. When the Expert sees a SIP request, it stores the timestamp when it captured the frame. Then, when the Expert sees a corresponding response from the SIP server, it calculates the delay between the last request from the client and the first response from the server. If the value for this delay is greater than the SIP Slow response time threshold (expressed in milliseconds), the Expert generates the SIP – Server Slow Response alarm.

The alarm display includes the following information:

• Threshold – The value of the SIP Slow response time threshold when this alarm was generated.



• Response Time – The response time measured by the Expert that caused this alarm to be generated. This value will be higher than the Threshold value.

• Command – The type of SIP client request to which the server was slow in responding. For example, INVITE.

• Response code – The numerical response code returned by the SIP server to the client's request. For description of all SIP response codes, see RFC 2543 describing the SIP protocol.

• Description – A short textual description of the response code returned by the SIP server to the client's request.

4-22 Sniffer Voice

ANetwork Associates Support Services A

Adding Value To Your Network Associates ProductChoosing Network Associates anti-virus, network management, and security software helps to ensure that the critical technology you rely on functions smoothly and effectively. Taking advantage of a Network Associates support plan extends the protection you get from your software by giving you access to the expertise you need to install, monitor, maintain and upgrade your system with the latest Network Associates technology. With a support plan tailored to your needs, you can keep your system or your network working dependably in your computing environment for months or years to come.

Corporate customers can choose from three levels of extended support under the Network Associate Corporate PrimeSupport program.

PrimeSupport Options for Corporate CustomersThe Corporate PrimeSupport consists of three support offerings:

• Connect

• Priority

• Enterprise

Each offering has a range of features that provide you with rapid, mission-critical access to our technical experts. In addition, you will receive access to our web-based KnowledgeCenter which gives you an extensive array of technical support information and download access to product upgrades or updates. To gain access to the KnowledgeCenter, simply use the grant number that was provided to you on the grant letter which was sent by US mail and by e-mail.

To register your product license with Network Associates, please visit:

http://www.nai.com/asp_set/support/introduction/default.asp

Your completed form will go to the Network Associates Customer Service Center.

Each PrimeSupport offering is described in more detail in the following sections.

Installation and Operations Guide A-1

Network Associates Support Services

PrimeSupport ConnectPrimeSupport Connect gives you telephone access to essential product assistance from experienced technical support staff members.

If you purchased your Network Associates product with a subscription license, you receive PrimeSupport Connect as part of the package for the first year of your subscription term.

If you purchased a perpetual license for your Network Associates product, you can purchase PrimeSupport Connect for an annual fee.

With PrimeSupport Connect you receive:

• In North America, unlimited toll-free telephone access to technical support from Monday through Friday, 8:00 A.M. to 8:00 P.M. Central Time

• In Europe, the Middle East, and Africa, unlimited telephone access to technical support, at standard long-distance or international rates, Monday through Friday, from 9:00 A.M. to 6:00 P.M. local time

• In the Asia-Pacific region, unlimited toll-free, telephone access to technical support, Monday through Friday, from 8:00 A.M. to 6:00 P.M. AEST

• In Latin America, unlimited telephone access to technical support, at standard long-distance or international rates, Monday through Friday, from 9:00 A.M. to 5:00 P.M. Central Time

• Unrestricted, 24-hour-per-day online access to technical solutions from Network Associates website

• Electronic incident and query submission

• Technical documents, including user's guides, FAQ lists, and release notes

• Data file updates and product upgrades via the Network Associates website

PrimeSupport PriorityPrimeSupport Priority gives you round-the-clock telephone access to essential product assistance from experienced Network Associates technical support staff members. If you purchased your Network Associates product with a subscription license, you receive PrimeSupport Priority as part of the package for the first year of your subscription term. If you purchased a perpetual license for your Network Associates product, you can purchase PrimeSupport Priority for an annual fee.

With PrimeSupport Priority you receive:

A-2 Sniffer Voice


• In North America, unlimited toll-free telephone access to technical support from Monday through Friday, 8:00 A.M. to 8:00 P.M. Central Time

• In Europe, the Middle East, and Africa, unlimited telephone access to technical support, at standard long-distance or international rates, Monday through Friday, from 9:00 A.M. to 6:00 P.M. local time

• In the Asia-Pacific region, unlimited toll-free, telephone access to technical support, Monday through Friday, from 8:00 A.M. to 6:00 P.M. AEST

• In Latin America, unlimited telephone access to technical support, at standard long-distance or international rates, Monday through Friday, from 9:00 A.M. to 5:00 P.M. Central Time

• Priority access to technical support staff members during regular business hours

• Responses within one hour for urgent issues that happen outside regular business hours, including those that happen during weekends and local holidays

• Unrestricted, 24-hour-per-day online access to technical solutions from a searchable knowledge base within the Network Associates website



• Data file updates and product upgrades via the Network Associates website

PrimeSupport EnterprisePrimeSupport Enterprise gives you round-the-clock, personalized, proactive support from an assigned technical support engineer. You'll enjoy a relationship with a support professional who is familiar with your Network Associates product deployment and support history, and who will call you at an interval you designate to verify that you have the knowledge you need to use and maintain Network Associates products.

By calling in advance, your PrimeSupport Enterprise engineer can help to prevent problems before they occur. If, however, an emergency arises, the PrimeSupport Enterprise plan gives you a committed response time that assures you that help is on the way. If you purchased your Network Associates product with a subscription license, you receive PrimeSupport Enterprise as part of the package for the first year of your subscription



term. If you purchased a perpetual license for your Network Associates product, you can purchase PrimeSupport Enterprise for an annual fee.

With PrimeSupport Enterprise you receive:

• Unlimited, toll-free telephone access to an assigned technical support engineer on a 24-hour-per-day, seven-day-per-week basis, including weekends and local holidays

NOTE: The availability of toll-free telephone support varies by region and is not available in some parts of Europe, the Middle East, Africa, and Latin America.

• Proactive support contacts from your assigned support engineer via telephone or e-mail, at intervals you designate

• Committed response times from your support engineer, who will respond to pages within half an hour, to voice mail within one hour, and to e-mail within four hours

• Assignable customer contacts, which allow you to designate five people in your organization who your support engineer can contact in your absence

• Optional beta site status, which gives you access to the absolute latest Network Associates products and technology

• Unrestricted, 24-hour-per-day online access to technical solutions from a searchable knowledge base within the Network Associates website



• Online data file updates and product upgrades

Ordering Corporate PrimeSupportTo order any PrimeSupport plan, contact your sales representative, or:

• In North America, call Network Associates at (972) 308-9960, Monday through Friday from 8:00 A.M. to 7:00 P.M. Central Time.

• In Europe, the Middle East, and Africa, contact your local Network Associates office. Contact information appears in the Preface of this guide.

A-4 Sniffer Voice


The PrimeSupport options described in the rest of this chapter are available only in North America. To find out more about PrimeSupport, Training and Consultancy options available outside North America, contact your regional sales office. Contact information appears in the Preface of this guide.

Table A–1. Corporate PrimeSupport Plans at a Glance

PlanFeature

Connect Plan Priority Plan Enterprise Plan

Technical support via website

Yes Yes Yes

Software updates Yes Yes Yes

Technical support via telephone

Monday – Friday

North America:8 A.M. – 8 P.M. CT

Europe, Middle East, Africa:9 A.M. – 6 P.M. local time

Asia-Pacific: 8 A.M. – 6 P.M. AEST

Latin America: 9 A.M. – 5 P.M. CT

Monday – Friday, after hours emergency access





Monday – Friday, after hours emergency access





Priority call handling

— Yes Yes

After-hours support — Yes Yes

Assigned support engineer

— — Yes

Proactive support — — Yes

Designated contacts

— — At least 5

Response charter Calls answered in 3 minutes, response in one business day

Within 1 hour for urgent issues after business hours

After hours pager: 30 minutes

Voicemail: 1 hourE-mail: 4 hours



* long distance charges may apply

Network Associates Consulting and TrainingThe Network Associates Total Service Solutions program provides you with expert consulting and comprehensive education that can help you maximize the security and performance of your network investments. The Total Service Solutions program includes Network Associates Professional Consulting and Total Education Services programs.

Professional ServicesNetwork Associates Professional Services is ready to assist you during all stages of your network growth, from planning and design, through implementation, and with ongoing management. Network Associates consultants provide an expert’s independent perspective that you can use as a supplemental resource to resolve your problems. You’ll get help integrating Network Associates products into your environment, along with troubleshooting assistance or help in establishing baselines for network performance. Network Associates consultants also develop and deliver custom solutions to help accomplish your project goals—from lengthy, large-scale implementations to brief problem-solving assignments.

Table A–2. Special Prime Support Contact Information

Country or Region Phone Number* Bulletin Board System

Germany +49 (0)69 21901 300 +49 89 894 28 999

France +33 (0)1 4993 9002 +33 (0)1 4522 7601

United Kingdom +44 (0)20 7512 6099 +44 1344-306890

Italy +31 (0)55 538 4228 +31 (0)20 586 6128

Netherlands +31 (0)55 538 4228 +31 (0)20 586 6128

Europe +31 (0)55 538 4228 +31 (0)20 688 5521

Latin America +55-11-3794-0125 +55-11-5506-9100

A-6 Sniffer Voice


Sniffer Product ServicesFor focused help with specific problem resolution or software implementation issues, Network Associates offers a Jumpstart Service that gives you the tools you need to manage your environment. This service can include the following:

• Installation and optimization. This service brings a Network Associates consultant onsite to install, configure, and optimize your new Network Associates product and give basic operational product knowledge to your team.

• Knowledge Transfer. This service brings a Network Associates consultant onsite to help prepare you to perform your new product implementation on your own and, in some cases, to install the product.

• Proposal Development. This service helps you to evaluate which processes, procedures, hardware and software you need before you roll out or upgrade Network Associates products, after which a Network Associates consultant prepares a custom proposal for your environment.

Network ConsultingNetwork Associates consultants provide expertise in protocol analysis and offer a vendor-independent perspective to recommend unbiased solutions for troubleshooting and optimizing your network. Consultants can also bring their broad understanding of network management best practices and industry relationships to speed problem escalation and resolution through vendor support.

You can order a custom consultation to help you plan, design, implement, and manage your network, which can enable you to assess the impact of rolling out new applications, network operating systems, or internetworking devices.

To learn more about the options available:

• Contact your regional sales representative.

• In North America, call Network Associates toll free at 1-800-SNIFFER x 5740 (direct line 408-346-5740), or fax to 810-963-4069, Monday through Friday from 8 A.M. to 5 P.M. Pacific Standard Time.

• Visit the Network Associates website at:

http://www.nai.com/asp_set/services/introduction/default.asp




Total Education ServicesNetwork Associates Total Education Services builds and enhances the skills of all network professionals through practical, hands-on instruction. The Total Education Services technology curriculum focuses on network fault and performance management and teaches problem-solving at all levels. Network Associates also offers modular product training so that you understand the features and functionality of your new software.

You can enroll in Total Education Services courses year-round at Network Associates educational centers, or you can learn from customized courses conducted at your location. All courses follow educational steps along a learning path that takes you to the highest levels of expertise. Network Associates is a founding member of the Certified Network Expert (CNX) consortium. To learn more about these programs:

• Contact your regional sales representative.

• Call Network Associates Total Education Services at (800) 395-3151 Ext. 2670 (for private course scheduling) or (888) 624-8724 (for public course scheduling).

• Visit the Network Associates website at:

http://www.nai.com/services/education/

A-8 Sniffer Voice


http://www.nai.com/services/education

Index

Aalarms

Expert Application layer 4-4Expert Session layer 4-8for Sniffer Voice Expert 4-2

asteriskin the Summary pane 3-2marker in Expert displays 2-5

CCall Manager (SCCP)

described 2-4Cisco SCCP

overview 2-3consulting services A-6contacting

Customer Service ixinternational NAI offices xiNAI Technical Support x

Customer Service ix

DDiagnosis in Expert analysis 2-5

Eeducational services, description of A-8Expert

diagnoses 2-5H.225 Signal Detail Display 3-19H.245 Detail Display 3-23H.323 Detail Display 3-4new features for Sniffer Voice 2-5object detail displays for Sniffer Voice

3-1RAS Detail Display 3-27RTCP Detail Display 3-32

RTP Detail Display 3-36SCCP Call Setup Detail Display 3-40SIP Call Flow Detail Display 3-14SIP Call Setup Detail Display 3-44Skinny Client Control Protocol (SCCP)

Detail Display 3-9Sniffer Voice alarms 4-1symptoms 2-5

HH.225 Call Signalling

overview 2-2H.225 RAS

overview 2-2H.225 Signal Detail Display 3-19

Alarms Listbox 3-22Application Listbox 3-22Caller Identity Table 3-21Message Table 3-20Object Information 3-22Time/Reason Table 3-21

H.245 Detail Display 3-23Alarms Listbox 3-26Application Listbox 3-26Messages Table 3-23Object Information 3-26Sub Messages Table 3-24

H.245 Media Controloverview 2-2

H.323 Detail Display 3-4Alarms Listbox 3-8Call Flow Pane 3-8H.225/H.245 Table 3-5Object Information 3-9RTCP Table 3-7RTP Table 3-6

H225 - Abnormal Disconnect alarm 4-8

Installation and Operations Guide Index-1

Index

H245 - Open Logical Channel Reject alarm 4-8H245 - Terminal Capability Set Reject alarm

4-9H323 - High Call Volume alarm 4-4H323 - Too Many Incomplete Calls alarm 4-5

Iinstalling

Sniffer Voice 1-2system requirements 1-1

MMGCP

overview 2-3Multipoint Control Unit (MCU)

described 2-4

NNAI Technical Support, contacting xNetwork Associates

consulting services A-6educational services A-8international offices xitraining A-6

network objectsfor Sniffer Voice 3-3

Ppatch releases

installation sequence 1-23PrimeSupport - corporate

at a glance A-5Connect Plan A-2Enterprise Plan A-3ordering A-4Priority Plan A-2

product trainingsee Sniffer University

Professional Consulting Services A-6

protocol decodesCisco SCCP 2-3H.225 Call Signalling 2-2H.225 RAS 2-2H.245 Media Control 2-2MGCP 2-3RTCP 2-3RTP 2-3SAP/SDP 2-3SIP 2-3Sniffer Voice overview 2-1

RRAS - Admission Reject alarm 4-10RAS - Bandwidth Reject alarm 4-11RAS - Gatekeeper Reject alarm 4-11RAS - Location Reject alarm 4-12RAS - Registration Reject alarm 4-12RAS Detail Display 3-27

Alarms Listbox 3-31Application Listbox 3-31Gatekeeper Info Table 3-27Messages Table 3-28Object Information 3-31

RTCPoverview 2-3

RTCP - Report High Jitter Rate alarm 4-13RTCP Detail Display 3-32

Alarms Listbox 3-35Application Listbox 3-35Object Information 3-36RTCP Report Table 3-34RTCP Sender Info Table 3-33

RTPoverview 2-3

RTP - High Jitter Rate alarm 4-15RTP - Too Many Drop Frames alarm 4-16RTP - Too Many Out of Sequence Frames

alarm 4-17RTP Detail Display 3-36

Index-2 Sniffer Voice

Index

Alarms Listbox 3-40Application Listbox 3-39Object Information 3-40RTP Connection Quality Table 3-38RTP Statistics Table 3-37

SSAP/SDP

overview 2-3SCCP - High Call Volume alarm 4-5SCCP - Register Reject alarm 4-18SCCP - Station Alarm alarm 4-18SCCP - Too Many Incomplete Calls alarm 4-6SCCP Call Setup Detail Display 3-40

Alarms Listbox 3-44Application Listbox 3-44Object Information 3-44SCCP Info Table 3-41SCCP Messages Table 3-42

SIPoverview 2-3

SIP - Authentication Fails alarm 4-18SIP - Client Error alarm 4-18SIP - Global Error alarm 4-20SIP - High Call Volume alarm 4-6SIP - Server Error alarm 4-20SIP - Server Slow Response alarm 4-21SIP - Too Many Incomplete Calls alarm 4-7SIP Call Flow Detail Display 3-14

Alarms Listbox 3-19Call Flow Pane 3-18Object Information 3-19RTCP Table 3-17RTP Table 3-16SIP Info Table 3-16

SIP Call Setup Detail Display 3-44Alarms Listbox 3-47Application Listbox 3-47Object Information 3-47SIP Packet Types Table 3-45

SIP URL Table 3-46Via Stations Table 3-46

Skinny Clientdescribed 2-4

Skinny Client Control Protocol (SCCP) Detail Display 3-9

Alarms Listbox 3-14Call Flow Pane 3-13Call Identity Table 3-10Object Information 3-14RTCP Table 3-12RTP Table 3-11

Sniffer University xiSniffer Voice

basic components of VoIP network 2-4Expert alarms 4-1Expert network objects 3-3Expert object detail displays 3-1installing 1-2new Expert features 2-5protocol decodes 2-1uninstalling 1-4

Solutionscontacting A-6

support - corporate PrimeSupportat a glance A-5Connect Plan A-2Enterprise Plan A-3ordering A-4Priority Plan A-2

Symptom in Expert analysis 2-5system requirements for Sniffer Voice 1-1

TTechnical Support xtechnical support - corporate PrimeSupport

at a glance A-5Connect Plan A-2Enterprise Plan A-3ordering A-4Priority Plan A-2

Installation and Operations Guide Index-3

Index

Total Education Servicesdescription of A-6

Total Service A-6training

see Sniffer Universitytraining for Network Associates products A-6troubleshooting

patch release installations 1-23upgrade sequences 1-23

Uuninstalling Sniffer Voice 1-4upgrading

new releases 1-23patch releases 1-23

VVoIP

basic components 2-4VoIP Gatekeeper

described 2-4VoIP Gateway

described 2-4VoIP Terminal

described 2-4

Index-4 Sniffer Voice

sniffer voice installation and operations guide release...

Documents