net-net® ems 4000 decomposed sbc essentials · pdf filenet-net® ems 4000 decomposed...

Net-Net® EMS 4000Decomposed SBC Essentials

Release Version 6.0

Acme Packet, Inc.71 Third AvenueBurlington, MA 01803 USAt 781-328-4400f 781-425-5077http://www.acmepacket.com

Last Updated: July 16, 2008Document Number: 400-0096-60 Rev. 1.0.0

http://www.acmepacket.com

Notices©2002—2008 Acme Packet, Inc., Burlington, Massachusetts. All rights reserved. Acme Packet®, Session Aware Networking®, Net-Net®, and related marks are registered trademarks of Acme Packet, Inc. All other brand names are trademarks, registered trademarks, or service marks of their respective companies or organizations.

Patents Pending, Acme Packet, Inc.

The Acme Packet Documentation Set and the Net-Net systems described therein are the property of Acme Packet, Inc. This documentation is provided for informational use only, and the information contained within the documentation is subject to change without notice.

Acme Packet, Inc. shall not be liable for any loss of profits, loss of use, loss of data, interruption of business, nor for indirect, special, incidental, consequential, or exemplary damages of any kind, arising in any way in connection with the Acme Packet software or hardware, third party software or hardware, or the documentation. Some jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so the above exclusions may not apply. These limitations are independent from all other provisions and shall apply notwithstanding the failure of any remedy provided herein.

Copying or reproducing the information contained within this documentation without the express written permission of Acme Packet, Inc., 71 Third Avenue, Burlington, MA 01803, USA is prohibited. No part may be reproduced or retransmitted.

Acme Packet Net-Net products are protected by one or more of the following patents: United States: 7072303, 7028092, 7002973, 7133923, 7031311, 7142532, 7151781. France: 1342348, 1289225, 1280297, 1341345, 1347621. Germany: 1342348, 1289225, 1280297, 1341345, 1347621. United Kingdom: 1342348, 1289225, 1280297, 1341345, 1347621. Other patents are pending.

Contents

About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii

Who is Acme Packet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii

Technical Assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .viii

Customer Questions, Comments, or Suggestions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Contact Us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

1 Net-Net Border Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

BGF Media Stream Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

vBG Network interface Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Termination ID Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Basic Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Congestion State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Service Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Media Hairpinning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Configuring the Net-Net BG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Configuring the Net-Net BG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Configuring a vBG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Configuring Session Controller List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Configuring Media Hairpinning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

H.248 Package Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Hosted NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

RTCP NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Re-Latching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Source Address Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

RTCP-XR XNQ Block Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Configuring RTCP-XR XNQ Block Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Configuring Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Version 6.0 Net-Net EMS Decomposed SBC Essentials Guide iii

Net-Net BG Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

QoS Collection Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Mid-Call VQ-QoS Statistic Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Statistics Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

CSV File Rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

End of Call Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Hanging Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Configuring Hanging Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Backwards and Forwards Octet Strings for ds/dscp Parameters . . . . . . . . . . . . . . . . . . . . . . .36

Configuring Octet Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

Failover ServiceChange Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

System ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Configuring System ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

2 Net-Net Session Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

About the Net-Net SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

Groups and Contexts and Call Allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Configuring the Net-Net SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Configuring the Session Controller Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Configuring Controlled Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

Hosted NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

LDAP-Based Registrar and Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Configuring the LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Enabling Registrar Functionality on the Net-Net SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

Setting the Registrar’s LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53

Configuring LDAP Registrar Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

Query for Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

Calling Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

Routing Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

Session Controller VQ-QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

Configuring VQ-QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

Configuring Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

iv Net-Net EMS Decomposed SBC Essentials Guide Version 6.0

3 Connectivity Failure Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

Network Interface Health Score Decrement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

ARP Gateway Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

Bidirectional Forwarding Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

BFD Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

BFD Timer Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

BFD Session Failure Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

Configuring BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

R-Factor Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

Configuring R-Factor Alarm Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

4 Historical Data Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

Configuring HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Configuring Push Receivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

Configuring Collection Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

Configuring HDR for an HA Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

HDR Trap for Data Push Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Configuring HDR Data Push Success Trap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

5 Registration Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Accessing the Registration Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Working with SIP Registration Caches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

Working with the H.323 Registration Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

Working with MGCP Registration Caches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

6 Creating a Baseline Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

System Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

Realm Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

SIP Signaling Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102

Session Routing and Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102

Version 6.0 Net-Net EMS Decomposed SBC Essentials Guide v

ToS Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102

vi Net-Net EMS Decomposed SBC Essentials Guide Version 6.0

About This Guide

OverviewThe Net-Net™ 4000 decomposed SBC is a high performance, high capacity decomposed session border controller that optimally delivers interactive communications—voice, video, and multimedia sessions—across wireline, wireless, and cable IP network borders. The Net-Net 4000 can be configured as a Border Gateway (BG) or as a Session Controller (SC). With its compact, single unit, 1U, design, the Net-Net system provides exceptional functionality in a tightly integrated system.

Audience This guide is written for network administrators and architects. It provides information about the Net-Net BG and SC applications. Supporting configurations are available in the Net-Net EMS 5.1 4000 Configuration Guide.

For information about Net-Net system training, contact your Acme Packet sales representative directly or email [email protected]

Who is Acme Packet?

Acme Packet enables service providers to deliver trusted, first class interactive communications-voice, video and multimedia sessions-across IP network borders. Our Net-Net family of session border controllers satisfy critical security, service assurance and regulatory requirements in wireline, cable and wireless networks. Our deployments support multiple applications-from VoIP trunking to hosted enterprise and residential services; multiple protocols-SIP, H.323, MGCP/NCS and H.248; and multiple border points-interconnect, access network and data center.

Established in August 2000 by networking industry veterans, Acme Packet is public company that is traded on NASDAQ, headquartered in Burlington, MA.

Version 6.0 Acme Packet, Inc. Technical Publications vii

ABOUT THIS GUIDE

Technical AssistanceIf you need technical assistance with Acme Packet products, you can obtain it on-line by going to https://support.acmepacket.com. With your customer identification number and password, you can access Acme Packet’s on-line resources 24 hours a day. If you do not have the information required to access the site, send an email to [email protected] requesting a login.

In the event that you are experiencing a critical service outage and require live assistance, you can contact the Acme Packet Technical Assistance Center emergency hotline:

• From the United States, Canada, and Mexico call: 1 866 226 3758

• From all other locations, call: +1 781 756 6920

Please note that a valid support/service contract with Acme Packet is required to obtain technical assistance.

Customer Questions, Comments, or Suggestions

Acme Packet is committed to providing our customers with reliable documentation. If you have any questions, comments, or suggestions regarding our documentation, please contact your Acme Packet customer support representative directly or email [email protected].

Contact Us Acme Packet 71 Third Avenue Burlington, MA 01803 USA t 781 328 4400 f 781 425 5077 http://www.acmepacket.com

viii Net-Net EMS Decomposed SBC Essentials Guide Version 6.0



1 Net-Net Border Gateway

IntroductionThe decomposed Net-Net SBC can be configured as a BGF logical device as used in the ETSI/TISPAN IMS architecture. A single Net-Net 4000 is configured as a border gateway (BG). This fills a single logical role, whereas the integrated SBC model spans several logical roles. When the Net-Net 4000 is configured to act in the BGF role, it is responsible for controlling media streams as they enter and exit the network. A session controller controls a BG’s media operations using H.248 v.2 ETSI/TISPAN Ia profile with long text over a UDP interface.

The BG performs the following tasks on media traffic (RTP and RTCP):

• VLAN tagging

• DSCP Marking

• Resource allocation and reservation

• Media supervision

• QoS Statistics Collection & Reporting

• DoS protection

• Fault management

• Bandwidth Policing

• Media Latching for HNT

The diagram below shows how endpoints first send their call signaling information to the session controller. Based on signaling commands from an endpoint, the SC directs the BG to perform the appropriate action on the media stream thus acting as a gateway to the network.

Version 6.0 Acme Packet, Inc. Technical Publications 9

NET-NET BORDER GATEWAY

BGF Media Stream Control

The communication between an SC and BG can be decoupled from the signaling events that make up a basic SIP call. The Acme Packet BG gets its directives directly from an SC; there is no call signaling routing logic that occurs on the BG. Different SCs may use different sequences of H.248 control messages to achieve the same results.

The events and their order described in the following call scenario do not necessarily describe the prototype or typical model. They depict only one version of the sequence of events that could happen. One aspect of the BG's functionality that remains constant is that it is essentially controlled by the SC, and does exactly what the SC instructs it to do. The BG does not make any application-based decisions on its own.

The Net-Net BG supports multiple Virtual Border Gateways (VBG), which are logical instances of a BG. A vBG has one H.248 control association identified by a unique IP address and port combination, known as an MID. Control interfaces associate a vBG to an SC and use the Net-Net 4000’s front-panel, media interfaces.

When the BG is initialized, each vBG contacts its configured, primary SC, in the order listed in the configuration. The BG attempts to create an H.248 control association between itself and the SC it contacts. Once this control association has been established, the SC can send media control messages to its corresponding vBG.

vBG Network interface Association

Each vBG steers media through realms (and network interfaces implicitly) as listed in the associated-realms parameter. A vBG can be configured to control an exclusive list of realms or all configured realms. We recommend that you configure each vBG with the most restrictive list of associated realms as possible. This is useful if you do not want a particular vBG to have access to certain interfaces, due to topology. When a Net-Net BG's interface fails, or when a next-hop device becomes unreachable, the vBG notifies its controlling SC of the event. You may want to consider this behavior so that SCs are excluded from receiving non-relevant failure messages (i.e., service change commands).

Logical Interfaces Assigned to Specific vBGs

One vBG may be assigned to one or more logical interface, and one logical interface may be assigned to one or more vBG. The SC is thus responsible for adding a termination on the vBG that controls the required logical interfaces for that call. When an SC tries to add a termination on a vBG on an interface that is not assigned correctly, the BG returns a 430 error code (unknown termination ID) to the SC.

In the following example,

• Logical interface 1 is assigned to VBG-N, any failures on this interface will be reported to SC3 only

• Logical interface 2 is assigned to VBG 1 and VBG2, any failures of this interface will be reported to SC1 and SC2 only

• Logical interface M is assigned to all vBGs, any failures of this interface will be reported to all SCs.

10 Net-Net EMS Decomposed SBC Essentials Guide Version 6.0


• Each vBG can create a call on the logical interfaces that it exclusively touches.

Termination ID Structure

The Termination ID structure is supported as follows:

<prefix>/<group>/<interface>/<id>

Where:

• <prefix>—Is a prefix string always set to IP.

• <group>—3 digit number that identifies the group of the interface and id. The group can range from 0-255, per the Ia Profile.

• <interface>—Alphanumeric identifier the refers to a configured realm on a Net-Net BG.

• <id>—Specific, non-zero, 32 bit termination identifier which is a unique ID for each termination on the Net-Net BG.

A few other H.248 specific terms are:

• Termination—The source or destination of a stream.

• Context—An association between a collection of terminations. A context represents a call on the SC.

• MID— message Identifier (MID) of a message is set to a provisioned name (e.g., domain address/domain name/device name) of the entity transmitting the message (i.e., the SC or vBG).

• Mode—The direction of a flow between two terminations within the Net-Net BG. Valid modes are send only, receive only, send receive, and inactive.

Please refer to ITU-T H.248 for additional details.



Basic Call The following example walks through the communication between the SC and BG for setting up and tearing down a basic SIP call. The Net-Net BG supports multiple media streams per context/termination. The diagram below shows the relationship between BG, SC, and the types of traffic in a typical scenario.

The following diagram illustrates the call flow that is described next.

ADD Request from SC to BG

The SC receives a SIP Invite with an SDP offer from the caller and determines the egress realm (from the vBG’s point of view) for this call. The SC then sends an H.248 message to a vBG telling it to create a new context with two terminations. One termination should be on the ingress network (realm) of the call, and one termination should be on the egress network (realm) of the call. The SC specifies the realms where the two contexts are created and the type of flow in each direction that should be created. The SC also includes the caller's remote IP address and port, used as the source address of the flow on the ingress side of the call.

In this H.248 action (which include 2 H.248 ADD commands), the SC requests a Context ID and Termination ID for each of the two terminations. The SC also requests the IP addresses and ports on both sides of the BG where RTP/RTCP traffic will flow into and out of.



ADD Reply from BG to SC

The BG replies to the SC with two termination IDs and one context ID. One of the two termination IDs describes the ingress termination, and the other termination ID describes the egress termination. The BG also replies with the local IP addresses and ports on both the egress and ingress networks (realms) where media will flow in to and out of.

After the SC receives the successful ADD REPLYs from the BG, it can forward the SIP INVITE to its destination in the egress realm. The SIP INVITE can now contain the BG's egress realm IP address and port to successfully receive the media stream.

At this point, the BG has been provisioned with an IP address and port on the caller and network sides. Media can freely flow between two realms.

MODIFY Request From SC to BG

The Modify message sent from the SC to the BG is often used to modify the remote descriptor of the egress termination, as specified by the called party, in response to the SIP Invite. The Modify message can be used for several purposes, including:

• Provide the SDP media details for the flow through the BG, as noted in the endpoint's SDP answer

• Set the Mode of the flows (to open/close gates)

• Set up media policing

• Set ToS

• Update any source/destination IP based filtering

• Send a codec change

MODIFY Reply from BG to SC

The BG sends a reply to the modify message acknowledging that it received and implemented the modify message.

SUBTRACT Request from SC to BG

When signaling indicates that the call has completed and should be torn down, the SC instructs the BG to remove all terminations in the context. It can also request a statistics returned from the BG. QoS monitoring must be enabled on the Net-Net BG if you want to collect statistics.

SUBTRACT Reply from the BG to the SC

The BG replies with end-of-call statistics to the SC after removing this call's terminations and context. The subtract reply functions as the subtract acknowledgement.

Congestion State A congestion situation occurs when the Net-Net BG's CPU usage exceeds a given amount. When this happens, the BG notifies the corresponding SC of a congestion condition whenever it receives an H.248 context-creating ADD command. By setting the BG’s congestion action parameter to none, the SC is responsible for managing the congestion situation and must adaptively throttle the rate at which it sets up sessions on the BG.

The congestion threshold is defined on the Net-Net BG as a percentage of CPU load. A second critical congestion level is also defined as a CPU load even higher than the congestion state where the BG only admits emergency calls. The critical congestion level is ostensibly configured higher than the congestion level.



Net-Net BG Smoothing The Net-Net BG can manage a congestion state internally with the congestion action parameter set to smoothing. Smoothing means that the Net-Net BG uses an algorithm to determine how to react in such a case.

When the Net-Net BG enters a congestion state, and the SC tries to create a call, the BG will reject the call with a 510 error code and notify the SC of an mg-overload event (if the ocp package is enabled). In addition, the BG will begin to drop calls using the following algorithm.

Drop Rate Current CPU load Congestion threshold–100 Congestion threshold–( )

----------------------------------------------------------------------------------------------------⎝ ⎠⎛ ⎞=

In a critical congestion state, the Net-Net BG only allows emergency calls and drops all other calls. An emergency call is identified by the inclusion of an emergency token as sent by the SC.

Service Faults There are four common fault situations that can occur on the Net-Net BG:

• Loss of H.248 Control Association between the Net-Net BG and SC

• SC goes out of service

• Net-Net BG goes out of service (or operational state is set to disabled)

• Net-Net BG failover from the active to the standby

• Media interface/network failure

On all of these cases, the Net-Net BG sends a Service Change message to the BG to attempt recovery procedures.

Net-Net BG Failover When an Acme Packet BG is configured for high availability, a switchover between redundant Net-Net BGs does not affect established sessions. Media state is maintained across the two redundant systems. All contexts are migrated over to the newly in-service Net-Net BG such that the switchover is transparent to the network. The Net-Net BG that assumes the active role and sends Restart / 902 Warm Boot service change command to its associated SC.

SC Failure / Loss of Control Association

In normal operation, the Acme Packet BG exchanges control messages with an SC. If no operations are pending, the SC sends empty audit value commands to the Net-Net BG that act as heartbeat messages. Initially, the SC provisions the Net-Net BG with an inactivity timer. The SC sends the empty audit messages, and the BG receives them. If the Net-Net BG doesn’t receive a message from the SC within the inactivity timer period, the BG sends an event notification to the SC and looks for another SC. You can configure timers that test for a loss of control association condition between the BG and SC.

When the vBG loses a control association with its SC, the vBG tries to recontact with the SC by sending a Disconnected/900 Service Change command. If the SC fails to respond, then the Net-Net BG attempts to contact the next-configured SC with a Failover / 909 Service Change command. The vBG continues through the list of SCs until an SC replies. After the vBG exhausts the list of configured SCs, it returns to the original SC and sends a Disconnected/900 Service Change command.



Media Interface Failure and Recovery on a BG

When the Net-Net BG detects a failure on an interface, the Net-Net BG sends a ServiceChange Forced message on a wildcarded termination ID to all SCs that can control the failed interface. If the Net-Net BG then receives an ADD command for a termination on the failed interface, the BG returns an Error Code 503 to the SC. The the failed interface goes back in service, the Net-Net BG sends a Restart / Service Restored message for that interface.

Media Hairpinning There are several cases in which the Net-Net BG takes action when media needs to be hairpinned through it.

Case 1 In the following case, the SC sets up a single context to interconnect two endpoints. The media will flow from the endpoints’ access realm(s) through the BG.

Case 2 When the SC is not able to set up a single context, as in case 1, it sets up two contexts, one per endpoint. If the local IP address of IP2 is the same as the remote IP address of P4 (IP2 and IP4 are on the same VLAN and physical interface), then the media will remain hairpinned within the BG.



Case 3 When the SC is not able to set-up a single context, as shown in case-1, then the SC will set-up two contexts, one per endpoint. If the local IP address of IP2 is not the remote IP address of IP4, or IP2 and IP4 are on different VLANs, even though both addresses are owned by the BG), then the media will flow from the Net-Net BG onto the external network and then back into the Net-Net BG.



Configuring the Net-Net BGConfiguring the Net-Net BG requires a baseline configuration for creating media flows, and BG-specific configuration. The BG license and all other supporting licenses must be installed on this system.

A baseline configuration requires that you have the following configuration elements defined and logically configured:

• System configuration

• Physical interface

• Network interface

• Realm configuration

• Steering pool

• Media manager

In addition, you must create and configure the BGF configuration, and one or more VBG configuration elements.

Configuring the Net-Net BG

To configure the Net-Net BG:

1. Click the Net-Net 4000 you are configuring in the Net-Net EMS navigation tree.

The SD System window appears in the Net-Net EMS display pane.

2. Click the Border Gateway tab.

3. Click the Border Gateway sub-tab.

4. State—Click this checkbox to globally enable the Net-Net BG.

5. Log level—Optional. Choose a system log level for this task.



6. Congestion threshold (%)—Enter the CPU load percentage that triggers a congested state. Valid values are from 1 - 100%.

7. Congestion measurement interval (secs)—Enter the interval in seconds at which the Net-Net BG is monitored at in congestion state. Valid values are from 1 - 60 seconds.

8. Congestion action—Choose smoothing from the drop-down list to take action by dropping incoming calls when the Net-Net BG enters a congested state. Or retain the default value NONE for the Net-Net BG to take no action when it enters a congested state.

9. Critical congestion threshold (%)—Enter the CPU load percentage that triggers a critical congested state. Valid values are 1 - 100%.

10. Critical congestion measurement interval (secs)—Enter the interval in seconds at which the Net-Net BG is monitored at in critical congestion state. Valid values are 1 - 60 seconds.

11. Options—Optional. Click Add. The Option dialog box appears.

12. Option—Optional. Enter the option name and click OK to close the dialog box.

13. Click Apply.



Configuring a vBG To configure a vBG:




3. Click the Virtual Border Gateway sub-tab. The Virtual border gateway table appears.

4. Click Add. The Add Virtual border gateway dialog box appears.

5. VBG identifier (MID)—Enter the MID that this vBG uses when sending H.248 messages to an SC.

You can enter a device name, a domain name, or an IP address. Including the port value for the domain name and IP address is optional.

• devicename. For example, vbgdevice

• <vGB’s domain name> or <vGB’s domain name>:vBG’s port number. For example, <myvbg>:1024

• [vGB’s IP address] or [vGB’s IP address]:vBG’s port number. For example, [111.22.33.4]:1024

Acme Packet recommends that you set the mid to the corresponding values of the real IP address and port, i.e., [1.1.1.1]:2944

6. State—Click the checkbox to activate this vBG.

7. SC realm—Choose the realm/interface where the control association between this vBG and the SC exists from the drop-down list.



8. Local IP address—Enter the IP address of this vBG. The IP address and port number combination must be unique to specify a vBG.

9. Port—Enter the port of this vBG. The well-known H.248 port number is 2944. The IP address and port number combination must be unique to specify a vBG.

10. Transport protocol—The set value is UDP. You cannot edit this parameter.

11. Encoding—The set value is text to set the H.248 message encoding type to uncompressed (long) format. You cannot edit this parameter.



14. Associated realms—Click Add. The Add Associate realm dialog box appears.

15. Associated realm—Choose a realm through which this vBG can setup flows in from the drop-down list.

16. Click OK to close the dialog box. The realm appears in the Associated realms list.

17. Repeat steps 12 through 14 to list additional realms.

18. Configure the session controller list. See the following section for details.



Configuring Session Controller List

You must provision all SCs that this vBG can communicate with. The order in which you configure them is relevant. The first-configured SC should be the primary SC that this vBG is meant to communicate with. Each additional SC represents the next-in-place SC that this vBG attempts to reach during an SC failure situation.

To configure a vBG’s SC list:

1. Session controller—Click Add. The Add Session controller dialog box appears.

2. IP address—Enter the IP address of this SC.

3. Port—Enter the port of this SC.

4. Click OK to close the dialog box. The new entry appears in the Session controller list.

5. Repeat steps 1 through 4 to configure additional SCs.

6. Click Apply.

Configuring the Realm The only resource managed on the Net-Net BG is the steering pool, which is assigned to a realm. The network interface ports allocated are derived from the assigned realm.

To configure the realm:

1. Click Realms in the Net-Net EMS navigation tree.

The Realm window appears.

2. Scroll to the Manage media between endpoints area.

3. Within this realm serviced by this Net-Net system only—Click the checkbox to enable media management.

4. Click Apply.



Configuring Media Hairpinning

This section shows you how to configure your Net-Net BG for media hairpinning across VLANs and physical interfaces.

To configure the hairpin identifier for a realm:



2. Select the realm on which you want to configure media management and click Edit. The Edit Realm window appears.

3. Hairpin ID—Enter the identifier for hairpin media flows for this realm. The range of values is 0 to 65534. The default value of 0 disables the hairpinning of media across VLANs and physical interfaces.

4. Click Apply.

H.248 Package Support

In addition to pure media control, the Net-Net BG also supports several other features.

Bandwidth Policing The Acme Packet BG can provide constant bit rate (CBR) bandwidth policing for call admission control into a network. CBR support is based on the "Sustainable Data Rate" parameter from the H.248 Traffic Management package.

The SC informs the BG of bandwidth allowed for a call, and the BG will impose bandwidth limiting for that call's media traffic as it exits the Net-Net BG.

Differentiated Services The Acme Packet BG can add DiffServ markings (RFC 2474) onto IP packets exiting into an egress network. The SC informs the BG of a value to insert into IP packets' TOS octets as the packets exits the BG. Diffserv markings are added on a call-by-call basis. This support is based upon the H.248 Differentiated Services package.

If the SC does not specify a value for the ds/dscp property, then the BG will use the TOS bits from the ingress interface or the egress interface. This behavior deviates from the H.248 Differentiated Services package standard which implies a default value of 0x00.

DiffServ markings are configured in the media policy configuration element. For information about configuring DiffServ markings, refer to the “Realm-Based Packet Marking” section in the Realms and Nested Realms chapter in the Net-Net 4000 ACLI Configuration Guide, Release version 5.1.



Media Flow Timers The Acme Packet BG supports three media flow timers which are used to guard against unused or timed-out flows through the Acme Packet BG. The three flow timers are:

1. Initial flow—This flow timer controls how long the Acme Packet BG can wait between the time the flow is created and the first packet is received. The default value is 300 seconds.

2. Subsequent flow—This flow timer controls the maximum length of time that can elapse between two subsequent IP packets before the NAT flow times out and is removed. The default value is 300 seconds.

3. Maximum duration—This flow timer controls the maximum time a NAT flow can exist. Once this time limit has been exceeded, the flow is removed from the BG. The default value is 86400 seconds.

When one of the timers expires, the BG sends a service change command to the SC for the appropriate ContextID and TerminationID. The service change reason accompanying this message is a “910 Media Capability Failure” with method=forced. The SC should reply to the BG to remove the flow. If none of the media flow timers are configured, then this service change command is never sent.

Configuring Media Flow Timers

To configure media flow timers:


The SBC System window appears in the Net-Net EMS display pane.

2. Click the Media Control tab.

3. Maximum session duration—Enter the maximum total session time for any flow in seconds.

4. Maximum time for first packet arrival—Enter the length of time the Net-Net BG can wait between the time the flow is created and the first packet is received in seconds.

5. Maximum inter-packet arrival interval—Enter the maximum length of time that can elapse between two subsequent IP packets before the flow times out and is removed (in seconds).



6. Click Apply.



Hosted NAT TraversalWhen the SC discovers that an endpoint is behind a NAT, it sends the ipnat/latch signal to the Net-Net BG. This indicates that the SDP provided by the SC in the remote descriptor cannot be reliably used as the egress destination for media sent by the termination. Therefore, the Net-Net BG will have to latch onto the source IP address and port of incoming RTP packets.

If the SC sends ipnat/latch for a particular termination, any SDP sent in the H.248 remote descriptor is ignored. The Net-Net BG performs a 2-step latching processes in this event. It first learns the source address and port from which an endpoint's RTP is received, and then uses this address and port as the egress destination for the media sent by the termination.

If NAT traversal is disabled using the ipnat latch {latch=off} signal, then the SDP present in the remote descriptor determines the destination of where the termination sends media. If no remote SDP is specified, the termination will stop sending media on the streams for which no remote SDP is specified.

Hosted NAT traversal is not enabled on the Net-Net BG. If your deployment includes a Net-Net SC, this feature is enabled there.

RTCP NAT Traversal

When endpoints are behind a NAT, and their public port assignment is out of control of the calling application, there is no guarantee that the RTP and RTCP flows' ports will be contiguous. If NAT traversal is not enabled, the Net-Net BG uses one internal NAT entry for a unidirectional media flow. When an endpoint is behind a NAT, distinct NAT entries are required for both RTP and RTCP. You must enable RTCP for hosted NAT traversal parameter to force the Net-Net BG to allocate additional resources for this application. If NAT traversal is enabled, then the gm/rsb property is not supported.

To configured RTCP NAT traversal:




3. Scroll to the Policing area.

4. RTCP support for NAT traversal—Set this parameter to enabled for the Net-Net BG to use additional resources required for RTCP HNT traversal.

5. Click Apply.



Re-Latching Ipnat/latch is treated as a transitory signal. If the Net-Net BG receives a latch signal from the SC while not in a latching state, the bidirectional media flow is terminated until the Net-Net BG receives media from an endpoint and the latching process begins again. It is important to note that if re-latching (which again can be accomplished by sending ipnat/latch {napt=latch} or {napt=re-latch} in a new H.248 MODIFY request) is enabled, the BG stops the media flows until it learns a new address from latching.

Source Address Filtering

The Net-Net BG supports source address filtering, which in conjunction with ipnat/latch is used by Acme Packet to deploy restricted media latching. The Net-Net BG supports gm/saf and gm/spf properties, which it receives from an SC. When a source address filter is enabled and latching is enabled, the Net-Net BG applies source address filtering as specified by the SC.

Restricted Latching The first packet received by the Net-Net BG, which meets the filtering criteria is latched onto and only media from that source will be accepted by the termination. The Net-Net BG will then send media back to that address. The following table describes the Net-Net BG’s interaction between “gm”, the RemoteDescriptor, “ipnapt”, and BG configuration.

Remote Descriptor ipnapt/latch Signal“gm” source filtering properties

BG Configuration Result

Specified IP addressSpecified RTP port number

Not Included Not Included hnt-rtcp = disabled • Accept RTP/RTCP packets from any address:port

• Send RTP packets to address:port specified in RemoteDescriptor

• Send RTCP packets to address:(port+1) specified in RemoteDescriptor


Not Included gm/saf = ONgm/sam = specifiedgm/spr = specifiedNote: port range is not allowed

hnt-rtcp = disabled • Accept RTP/RTCP packets from the address:port specified by gm/sam and spr only

• Send RTP packets to address:port specified in RemoteDescriptor

• Send RTCP packets to address:(port+1) specified in RemoteDescriptor




napt = LATCH - hnt-rtcp = enabled • Accept RTP/RTCP packets only from the “latched” source address:port

• Send RTP packets to source address:port of the first RTP packet received for the flow

• Send RTCP packets to source address:port of the first RTCP packet received for the flow


napt = LATCH gm/saf = ONgm/sam = specifiedgm/spf and gm/spr = not allowed

hnt-rtcp = enabled • Accept RTP/RTCP packets only from the “latched” source address:port

• Send RTP packets to source address of the first RTP packet received for the flow that matches the criteria specified in gm/sam

• Send RTCP packets to source address of the first RTCP packet received for the flow that matches criteria specified in gm/sam

Remote Descriptor ipnapt/latch Signal“gm” source filtering properties

BG Configuration Result



RTCP-XR XNQ Block RemovalThis section describes how the Net-Net SBC can block the RTP Control Protocol Extended Report’s (RTCP-XR) eXtended Network Quality (XNQ) blocks. Mainly these are used in customer networks to measure QoS statistics; because of their importance to the network, they cannot be entirely removed.

However, there are situations in which the XNQ blocks should not be propagated into IP interconnect networks. You can configure the Net-Net BG to remove RTCP-XR XNQ blocks as needed.

Configuring RTCP-XR XNQ Block Removal

When an ingress realm is configured for xnq-potential and the egress realm is configured for xnq-remove, then XNQ blocks are removed from the RTCP stream.

To enable RTCP-XR XNQ block removal:



2. XNQ state—Choose the one of the following values from the drop-down list:

• xnq-unknown (default)—No XNQ block removal

• xnq-potential—The realm has the potential to generate XNQ blocks; flows ingressing this realm potentially have XNQ blocks

• xnq-remove—The realm must not be sent XNQ blocks; flows egressing this realm should have the XNQ block removed

3. Click Apply.



Configuring RedundancyYou can configure border gateway information on Net-Net SBC redundant pairs.

To configure a redundant pair:

1. Click the Net-Net 4000 HA pair you are configuring in the Net-Net EMS navigation tree.

The SD HA node window appears in the Net-Net EMS display pane.

2. Click the HA SC State tab.

3. Redundancy listening port—Enter the port number on which the Net-Net SBC listens for HA synchronization messages. The valid range of ports is 1025-65535. The default is 1813.

4. Max number of active redundancy transactions—Enter the maximum number of HA transactions to maintain on the active system in the HA node. The valid range is 0 to 999999999.

5. Timeout for transaction from standby to active—Enter the amount of time in milliseconds that the active Net-Net SBC checks to confirm that it is still the active system in the HA node. If the active system is still adequately healthy, this timer will simply reset itself. If for any reason the active has become the standby, it will start to checkpoint with the newly active system when this timer expires. The valid range is 0 to 999999999, and the default is 5000.

6. Timeout for subsequent requests—Enter amount of time in milliseconds that determines how frequently after synchronization the standby Net-Net SBC checkpoints with the active Net-Net SBC. The first interval occurs after initial synchronizations of the systems; this is the timeout for subsequent synchronization requests. The valid range is 0 to 999999999.

7. Click Apply.



Net-Net BG StatisticsThe Net-Net BG supports mid-call VQ-QoS reporting and the R-Factor statistic. Mid-call VQ-QoS reporting is used to generate and record a call's statistics periodically through that call. These statistics are written to a local file which is ultimately copied to an external server. The R-Factor statistic is a VQ statistic reflecting overall call quality.

QoS Collection Prerequisites

While QoS statistics are collected on a per-call basis, they are enabled on a per-realm basis. This means that for each realm where you want to collect statistics, you must set the qos-enable parameter to enabled. Refer to the About QoS Reporting section in the Admission Control and Quality of Service Reporting chapter in the Net-Net 4000 ACLI Configuration Guide, Release version 4.1 for more information.

Mid-Call VQ-QoS Statistic Collection

The Net-Net BG collects and generates several voice quality (VQ) measurements for each IP-IP active context. The mid-call statistics feature enables the Net-Net BG to collect and record this VQ-QoS data for discrete 30 second windows during a call. This feature is globally enabled per Net-Net BG.

The Net-Net BG saves mid-call statistics as a .CSV file locally on the BG. The CSV files are made available for transfer to an external server. End-of-call QoS statistics are reported via H.248 to the Net-Net SC, which then stores these statistics in CDR files.

Mid-call VQ-QoS statistic collection only produces the following statistics for both directions of the call:

• RTCP Packets Lost

• RTCP Average Jitter

• RTCP Average Latency

• RTCP Maximum Jitter

• RTCP Maximum Latency

• RTP Packets Lost

• RTP Average Jitter

• RTP Maximum Jitter

• Total number of Packets

• R-factor

Although VQ-QoS values are recorded for 30-second windows, you configure the period at which the newly-collected VQ-QoS data is written to the file from a pre-defined range of times.



Configuring Mid-Call VQ-QoS Statistics Collection

To configure mid-call VQ-QoS statistics collection:




3. Scroll to the Interim QoS statistics area.

4. Enable interim QoS statistics—Click this checkbox to enable VQ-QoS statistics, including the R-factor.

5. Poll interval—Choose one of the available time periods at which VQ-QoS statistics are written to the CSV file from the drop-down list.

6. Guard timer expiration traps—Click this checkbox to enable the traps that

7. Click Apply.

Statistics Output The Net-Net BG records mid-call VQ-QoS statistics every 30 seconds if the VQ-QoS feature is enabled. These statistics are written to a comma separated value (CSV) file at preset intervals configured in media manager. The Net-Net BG writes all VQ-QoS statistics to one file, encompassing all calls, spread out across all vBGs on a Net-Net BG.

For all IP contexts, the following information is written to a CSV file in the following order:

• To-URI (user portion)—Called-Station-Id (contains ‘To’ field value of SIP INVITE), if configured

• From-URI (user portion)—Calling-Station-Id (contains ‘From’ field value of SIP INVITE), if configured

• Acct-Session-Id—(Call-Id of SIP INVITE), if configured



• Direction—Direction of flow (calling)

• Timestamp—In yyyy-mm-dd hh:mm:ss.ff format. Timestamp is rounded to 30 second intervals.

• Acme-Calling-R-Factor

• Acme-Calling-RTCP-Packets-Lost

• Acme-Calling-RTCP-Avg-Jitter

• Acme-Calling-RTCP-Avg-Latency

• Acme-Calling-RTCP-MaxJitter

• Acme-Calling-RTCP-MaxLatency

• Acme-Calling-RTP-Packets-Lost

• Acme-Calling-RTP-Avg-Jitter

• Acme-Calling-RTP-MaxJitter

• Acme-Calling-Packets

• carriage return

• To-URI (user portion)—Called-Station-Id (contains ‘To’ field value of SIP INVITE), if configured

• From-URI (user portion)—Calling-Station-Id (contains ‘From’ field value of SIP INVITE), if configured

• Acct-Session-Id—(Call-Id of SIP INVITE), if configured

• Direction—Direction of flow (called)

• Timestamp—In yyyy-mm-dd hh:mm:ss.ff format. Timestamp is rounded to 30 second intervals.

• Acme-Called-R-Factor

• Acme-Called-RTCP-Packets-Lost

• Acme-Called-RTCP-Avg-Jitter

• Acme-Called-RTCP-Avg-Latency

• Acme-Called-RTCP-MaxJitter

• Acme-Called-RTCP-MaxLatency

• Acme-Called-RTP-Packets-Lost

• Acme-Called-RTP-Avg-Jitter

• Acme-Called-RTP-MaxJitter

• Acme-Called-Packets

The filename format of the statistics file is: QoS-<System-Target-Name>-<Timestamp>.csv

• <System-Target-Name>—This string is the system name configured as the target name in the boot parameters.

• <Timestamp>—the yyyy-mm-dd_hh-mm represents the generation time of this file.



CSV File Rotation CSV statistics files can be pushed off the Net-Net BG to an FTP server. Only closed .csv files are pushed off-machine. They can also be downloaded via an S/FTP client. Refer to the Configuring SIP Accounting section in the SIP Signaling Services chapter in the Net-Net 4000 ACLI Configuration Guide, Release version 4.1 for more information.

When using the Net-Net BG as an S/FTP server, you can configure how the CSV files are rotated in the accounting configuration. Read the configuration section below to learn about the relevant VQ-QoS log file details.

Note: The Net-Net BG rotates the files based on whichever event happens first: the file growing to the maximum size or the rotation time being reached.

Configuring CSV File Rotation

To configure the VQ-QoS file output configuration:



2. Click the Accounting tab.

3. File path—Enter the file path on the Net-Net BG where the VQ-QoS CSV files are written to. Leaving this parameter empty forces the CSV file to be written to the default location, /ramdrv/logs.

4. Maximum file size—Enter the maximum size a CSV can reach before it is closed and rotated. This value is entered in bytes.

5. Maximum files—Enter the maximum number of files to keep before deleting the oldest CSV VQ-QoS files.

6. File rotation time—Enter the time in minutes that VQ-QoS CSV files are rotated.

7. Click Apply.



End of Call Statistics

Cumulative statistics are returned by the Net-Net BG in a H.248 SUBCTRACT reply or in a routine audit.

The following statistics are based on the H.248 Network package:

• Duration (nt/dur): duration of time that the termination/stream existed in ms.

• Octets Sent (nt/os): number of RTP octets (64 bit integer) sent from the termination or stream since the termination existed. The octets represent the egress media flow counting based on the Layer 2 length.

• Octets Received (rtp/or): number of RTP octets (64 bit integer) received on the termination or stream since the termination existed. The octets represent the ingress media flow counting based on the Layer 2 length.

Note: The L2 length is derived from the IP header length and adding 14 (Destination Source/Address & EtherType) decimal to it for non-VLAN and 18 decimal to it for VLAN traffic.

The following statistics are based on the ITU-T RTP package:

• Packets Sent (nt/ps): number of packets sent from the termination or stream since the termination existed. (64 bit integer)

• Packets Received (rtp/pr): number of packets received on the termination or stream since the termination existed. (64 bit integer)

• Jitter (rtp/jit): the current value of the inter-arrival jitter on an RTP stream as defined in RFC 3550. (64 bit integer)

• Delay (rtp/delay): the current value of packet propagation delay expressed in timestamp units. This is the same as average latency. (64 bit integer)

The following statistics are based on the XNQ package:

• RTP Jitter (xnq/nvrange)

• RTP Packets lost (xnq/ncumpl)

• RTCP Packets Lost (xnq/fcumpl)

• RTCP Average Latency (xnq/rtdmax)

Hanging TerminationThe Net-Net BG supports the Hanging Termination Detection package, specified in ITU-T H.248.36, and can notify its session controller of this capability. The Net-Net BG can identify potential mismatches between the information in the record of Context and Termination identities between itself and the session controller. Upon mismatch detection, the Net-Net BG notifies the session controller, which subsequently subtracts the relevant TerminationID.

How It Works The Net-Net BG checks each incoming ADD and MODIFY command for an events descriptor with the hanging termination event. When it finds this event, the Net-Net BG then looks for a provisioned timerx value—the time between the last message exchanged and the generation of the hanging termination event. It then uses this value to start the hanging termination time, unless it subsequently finds a timerx parameter in the incoming message.

If the timer expires prior to the Net-Net BG receiving any messages for the termination, the Net-Net BG sends a NOTIFY message to the MGC. It re-initializes the timer once it sends the message. The Net-Net SBC restarts the timer with the timerx value if it receives a message for the termination before the timer expires.



Configuring Hanging Termination

To enable hanging termination support:

1. Click the Net-Net SBC you are configuring in the Net-Net EMS navigation tree.




4. Click a virtual border gateway in the table to choose it and click Edit. The Edit Virtual border gateway window appears.

5. Hanging termination timer (Timerx)—Enter the timerx value in seconds for when the Net-Net BG receives a hanging termination event without a timerx value of its own. This is also enabled on any termination for which the timerx value is received.

The range of values is 0 to 999999999. The default value of 0 disables this functionality.

6. Click Apply.



Backwards and Forwards Octet Strings for ds/dscp ParametersBy default, the Net-Net BG supports the ds/dscp parameter (DiffServ Code Point or TOS bits) by allowing either hexidecimal or decimal values. If the value is proceeded by 0x, then the Net-Net BG parses it as hexidecimal; if not, then it is parsed as a decimal value. In either case, the most significant digit is always on the left.

However, ETSI TI-SPAN has defined a package for ds/dscp stating that the parameter should be interpreted as an octet string. So, in addition to its default behavior, the Net-Net BG supports a vBG configuration options that allow two more ways for parsing to occur. These options are:

• hex-dscp—Enables the Net-Net BG to interpret the ds/dscp parameter in an H.248 message as a hexidecimal value, where the most significant nibble is on the left (i.e., the leftmost character of value) and the least significant on the right.

• reverse-hex-dscp—Enables the Net-Net BG to interpret the ds/dscp parameter in an H.248 message as a hexidecimal value, where the least significant nibble is on the left and the most significant is on the right(i.e., contained in the rightmost character of value).

If both of these options are set, then the reverse-hex-dscp overrides the hex-dscp option.

The two options account for the fact that the ETSI TI-SPAN definition leaves room for interpretation about whether the most significant hexidecimal digit (as well as the binary digits specified therein) should appear on the left or the right. As you can see, the options you configure to control ds/dscp treatment account for both big-endian and little-endian octet string interpretation of the definition.

Configuring Octet Strings

This section shows you how to configure the vBG configuration options that support backwards and forwards octet string for the ds/dscp parameter.

Note: If both of these options are set, reverse-hex-dscp overrides hex-dscp. If you do not set an option for ds/dscp treatment, the Net-Net BG resorts to its default behavior.

To configure octet string support:








5. Click Options. The Options window appears.

6. Click the one or both of the options in the Available options list to select them.

• hex-dscp—Enables the Net-Net BG to interpret the ds/dscp parameter in an H.248 message as a hexidecimal value, where the most significant nibble is on the left (i.e., the leftmost character of value) and the least significant on the right.

• reverse-hex-dscp—Enables the Net-Net BG to interpret the ds/dscp parameter in an H.248 message as a hexidecimal value, where the least significant nibble is on the left and the most significant is on the right(i.e., contained in the rightmost character of value).

If both of these options are set, reverse-hex-dscp overrides hex-dscp.



7. Click to move the option to the Selected options list. The option name appears along with a description in the lower part of the window.

8. Click OK.



Failover ServiceChange CommandDuring the process of transitioning from one state to another, the Net-Net BG communicates its service state. You can configure the ServiceChange method sent when a failover occurs between two Net-Net BGs deployed as an HA node.

Configuring Failover ServiceChange Method

You configure the ServiceChange method by setting an option in the vBG configuration. When you set this option, the Net-Net BG sends the Disconnected method instead of Restart.

To set the ServiceChange method to Disconnected:







6. Click send-disconnected-on-failover in the Available options list to select it.



7. Click to move the option to the Selected options list. The option name appears along with a description in the lower part of the window.

8. Click OK.



System ACLsYou can configure a system access control list (ACL) for your Net-Net BG that determines what traffic the Net-Net BG allows over its management interface (wancom0). By specifying who has access to the Net-Net BG via the management interface, you can provide DoS protection (not policing) for this interface.

Using a list of IP addresses and subnets that are allowable as packet sources, you can configure what traffic the Net-Net BG accepts and what it denies. All IP packets arriving on the management interface are subject to these rules; if it does not match your configuration for system ACL, then the Net-Net BG drops it.

Note, however, that all IP addresses configured in the SNMP community table are automatically permitted.

Configuring System ACLs

For each entry, you must define an IP source address and mask; you can specify either the individual source host or a unique source subnet.

If you do not configure this list, then there will be no ACL/DoS protection for the Net-Net BG’s management interface.

Adding an ACL for the Management Interface

To add an ACL for the management interface:


The Net-Net SBC system window appears in the Net-Net EMS display pane.

2. Click the SBC System tab.

3. For the Management interface access list, click Add. The Add Management interface access list dialog box appears.

4. IP address—Enter the IP address representing for the source network for which you want to allow traffic over the management interface.



5. Subnet mask—Enter the netmask portion of the source network for the traffic you want to allow

6. Click OK. The IP address and subnet mask appear in the Management interface access list.

7. Repeat steps 3 through 6 to add more IP addresses and subnet masks you want to allow as packet sources.

8. Click Apply.

Notes on Deleting System ACLs

If you delete a system ACL from your configuration, the Net-Net BG checks whether or not there are any active FTP or Telnet client was granted access when the entry was being removed. If such a client were active during ACL removal, the Net-Net BG would warn you about the condition and ask you to confirm the deletion. If you confirm the deletion, then the Net-Net BG’s session with the active client is suspended.

The following example shows you how the warning message and confirmation appear. For this example, and ACLI has been deleted, and the user is activating the configuration that reflects the change.

ACMEPACKET# activate-config

Object deleted will cause service disruption:

system-access-list: identifier=172.30.0.24

** WARNING: Removal of this system-ACL entry will result

in the lockout of a current FTP client

Changes could affect service, continue (y/n) y

Activate-Config received, processing.


2 Net-Net Session Controller

IntroductionThe Net-Net Session Controller (SC) is responsible for the signaling aspect of call control at the network edge. The Net-Net SC is paired with and controls one or more border gateways (BGs), which together handle both media and signaling VoIP traffic. Functionally, the SC handles call intelligence, while the BG the acts as the slave media gate.

The majority of all SIP functionality in the Net-Net SBC is maintained on the Net-Net SC. See the Net-Net EMS 4000 5.1 Configuration Guide’s, SIP Signaling Services chapter for details about SIP features and processing. Physically, two Net-Net 4000s take the place of one Net-Net 4000 in the decomposed SBC vs. integrated SBC models. Logically, all RTP and RTCP call traffic flow over the Net-Net BG while SIP traffic flows over the Net-Net SC.

In addition, the Acme Packet SC supports these features:

• LDAP-based call registration

• Mid-call QoS statistics report (generated by a BG)

• SIP session management

• SIP registration management

• CLI audit trail

• Historical Data Recording (HDR)

About the Net-Net SC

The Net-Net SC acts as a signaling front-end to configure a Net-Net BG for media control. The SC-BG pair act in concert to provide the same functionality as one SBC.

Initially, each BG registers to an SC. The BG and SC negotiate their connection, H.248 version, and thus establish their control association. The SC enables root level events on the BG. The SC also marks the registering BG in-service and enters a ready-state where it can accept calls and forward them to the network.

An inactivity timer is used as a heartbeat mechanism for every configured BG on an SC. If the SC loses a heartbeat, that BG is considered to be OOS, until subsequent heartbeat messages reappear. If no heartbeats are received by the SC, all currently UP SIP calls stay up. The inactivity timer interval is configured on the SC.


NET-NET SESSION CONTROLLER

The following diagram shows the logical SC and BG configurations. Only one instance of each of these configuration elements is configured on its respective system.

The control association between an SC and a BG requires complementary configurations on each system. You configure a Virtual Border Gateway (VBG) on the Net-Net BG to define the BG-side of the control association. The VBG configuration includes its unique MID, IP address & port, and the SC's IP address and port. You also need to configure the VBG SC configuration to define the IP address and port of the BG's corresponding SC.

On the Net-Net SC, you configure the controlled-gateways to define the SC-side of the control association. The controlled gateways configuration requires a MID which must match the BG that registers to it. Other important configurations are the heartbeat audit period, and the realms (network interfaces) that this controlled gateway can accept signaling traffic from.

Groups and Contexts and Call Allocations

You can limit the number of contexts and groups for each slave BG. This is important so that BG audits can be made without incurring high system demands on the BG as it responds to the SC. The Ia profile states that a maximum of 256 contexts can exist within one group. The Net-Net SC uses this as a default. Both the maximum number of contexts per group and maximum number of groups are configurable on a BG via the Net-Net SC and determine the maximum size of an audit reply.



Configuring the Net-Net SCThe SC license and all other supporting licenses must be installed on this system.

Note: A BG and an SC license can not be active at the same time on the same physical hardware.

Configuring the Session Controller Function

To configure the SCF:



2. Click the Session Controller tab.

3. Click the SC Function sub-tab.

4. State—Click the checkbox to globally enable the Net-Net SC.

5. SC identifier (MD)—Enter the mID that this SC uses when sending H.248 messages.


• devicename. For example, bgdevice.





6. Listening realm—Choose the realm where this SC listens for H.248 messages, such as those from registering BGs from the drop-down list.

7. IP transport type—You cannot change the IP transport type; currently UDP is the type supported.

8. Listening IP address—Enter the IP address of the SC application. This IP address must exist within the realm previously specified.

9. Listening port—Enter the port of this SC application. The default H.248 control association port is 2944.

10. Send compact H.248—This is automatically disabled.

11. Log level—Optional. Choose the system log level for this task from the drop-down list.



14. Click Apply.



Configuring Controlled Gateways

To configure a controlled gateway (vBG) on the Net-Net SC:

1. In the Session Controller tab, click the Controlled Gateways tab.

2. Click Add. The Add Controlled gateway dialog box appears.

3. Border gateway ID (MID)—Enter the mID of the vBG that will connect to this controlled gateway. ThmID is used to identify the authorized agent communicating via H.248 messages.


• devicename. For example, bgdevice



4. Click OK to close the dialog box.

5. In the Controlled gateways table, click the border gateway and click Edit. The Edit Controlled gateway dialog box appears.

6. State—Click this checkbox to activate this controlled gateway instance.

7. H.248.14 keep alive interval (sec)—Enter the period in seconds at which inactivity timer (heartbeat) messages are to be exchanged between the BG and this SC.

8. Assigned realms—Click Add. The Add Assigned realm dialog box appears.

9. Realm—Choose a configured signaling realm for which this SC and its corresponding BG can set up calls in from the drop-down list.

10. Click OK. The realm name appears in the Assigned realms list.





13. Click Apply.

Hosted NAT Traversal

The Net-Net SC supports hosted NAT traversal, symmetric latching, and restricted latching, and can instruct a Net-Net BG to appropriately create the ingress-side context between the BG and an caller. Refer to the following table for configuration information.

media-manager configurationipnapt/latch signal sent to BG

“gm” source filtering properties sent to BG

Remote Descriptor

symmetric-latching = disabledhnt-rtcp = disabled

Not Included Not Included • Specified IP address• Specified RTP port #

symmetric-latching = enabledhnt-rtcp = enabled

napt = LATCH Not Included • Specified IP address• Specified RTP port #

restricted-latching = enabled (peer-ip mode)

hnt-rtcp = enabled

napt = LATCH gm/saf = ONgm/sam = set to IP address of incoming SIP signalling message for that realmgm/spf & gm/spr = not used

• Specified IP address• Specified RTP port #



LDAP-Based Registrar and RoutingThe Net-Net SBC can perform internal SIP registrar functions by using LDAP lookups to authenticate SIP endpoints. In addition, the Net-Net SBC can perform call routing for VoIP traffic based on LDAP lookups. The Net-Net SC supports an LDAPv3 connection. Multiple LDAP servers can be provisioned. During normal operation a permanent connection is maintained between the Net-Net SBC and LDAP server.

Configuring the LDAP Server

The SC licenses and all other supporting licenses must be installed on this system. A BG and an SC license can not be active at the same time.

To configure the Net-Net SC’s LDAP server:




3. Click the LDAP sub-tab.

4. Click Add. The Add LDAP dialog box appears.

5. Name—Enter a name for this LDAP server configuration. This parameter is required.


7. Click the name of the LDAP server configuration in the LDAP table and click Edit. The Edit LDAP dialog box appears.

8. State—Click this checkbox to enable the LDAP server configuration.

9. Server IP address—Enter the IP address of this LDAP server.



10. Server port—Enter the well known LDAP port number, 389. Alternatively, set this to your deployment-specific LDAP server listening port.

11. Realm—Choose the configured realm on this Net-Net SC over which this LDAP server is reachable from the drop-down list.

12. Base domain name—Enter the base domain name to use when accessing resources on this LDAP server.

13. User domain name—Enter the user name to use when accessing resources on this LDAP server.

14. Authentication mode—Choose Simple from the drop-down list.

15. Password—Enter the password to use when accessing resources on this LDAP server.

16. Max. number of response entries—Enter the maximum number of entries the LDAP server should ever return to the Net-Net SC. The range is 0-999999999. Set this parameter to 0 to disable an entry size limit.

17. Request timeout (sec)—Enter the timeout value in seconds for communicating with this LDAP server. Set this parameter to 0 to disable the timeout limit.

18. Click Add for LDAP transactions. The Add LDAP transaction dialog box appears.



19. Transaction type—Choose registration-validation from the drop-down list to configure the query for registration validation stage of call registration.


21. Click the transaction type in the LDAP transactions table and click Edit. The Edit LDAP transaction dialog box appears.

22. Base prefix—Enter additional attributes to pass within the LDAP Base DN for this LDAP transaction.

23. Filter class—Enter the object class in which this LDAP filter transaction takes place.

24. Filter name—Enter the attribute of the search filter to use for this LDAP transaction.

25. Click Apply to close the dialog box.

26. Click Apply to close the Edit LDAP dialog box.



Enabling Registrar Functionality on the Net-Net SC

To enable registrar functionality on the Net-Net SC:



2. Click the SIP tab.

3. Click the SIP config sub-tab.

4. Click the Registrar tab.

5. Host name/IP address—Retain the default value of *.

6. Port—Enter 0.

7. Domain name—Enter *.

8. Click Apply.

9. Click the Options and tags tab.


11. options—Type options registrar=yes.

12. Click Apply.



Setting the Registrar’s LDAP Server

To set the registrar’s LDAP server:



2. Click the realm you want to edit in the Realm table and click Edit. The Edit Realm window appears.

3. Click the Services/Protocols tab. The Realm Services table appears.

4. Click the service name in the Realm Services table and click Edit. The Edit SIP service window appears.

5. Click the SIP interface tab.

6. Scroll to the LDAP server parameter.

7. LDAP server—Choose the configured LDAP configuration that this SIP interface will query for registrations from the drop-down list.

8. Click Apply to return to the Edit Realm window.

9. Click Apply to return to the Realm window.

Debugging The Net-Net SC maintains event logs for the LDAP application and message logs for each configured LDAP server. The event log is located in /ramdrv/log.ldap. The message logs are located in the same /ramdrv/ directory. Their naming format is as follows: ldap-<name of ldap config>.log.



Configuring LDAP Registrar BehaviorThe Net-Net SC divides LDAP-based call registration into four stages:

• Query for validation

• Registration

• Calling validation

• URI resolution

Query for Validation

Before a call can be accepted into the network, the calling endpoint must register with the registrar. As a preliminary step, the Net-Net SC, as registrar, validates if the call can register first. After the Net-Net SC learns that the caller can register, it proceeds to the next step, registration.

After an unregistered endpoint's REGISTER message arrives at the Net-Net SC, an LDAP lookup is performed on the callers's AoR (extracted from the To: field) and the caller's source (public) IP address. Both of these strings are used as LDAP search terms. This is the registration validation stage of the Net-Net SC - LDAP registration. The Net-Net SC performs the registration validation stage in three cases:

1. When the Net-Net SC receives a message with an unknown AoR

2. When the Net-Net SC receives a message with a known AoR but with a changed contact

3. When the Net-Net SC receives a message in which the call id of the call changes

The Net-Net SC receives a response from the LDAP server indicating whether the endpoint can register or not, and the SIP Contact URI to use. The Net-Net SC then updates its registration cache accordingly. For this stage you have to configure the registration validation application transaction in the LDAP transactions configuration element.

For all search filters configured in the ldap transactions configuration element, the ACLI parameters are shown below in an LDAP search filter header:

Filter: (&(objectClass=filter-class)(filter-name=value)

Registration Now that the endpoint's call is cleared for registration, the Net-Net SC registers the endpoint internally and informs the LDAP server that the registration is active (Registered). On a successful search, i.e. a valid register, the Net-Net SC adds or replaces the Contact-URI in the LDAP entry if the current one does not reflect what the LDAP server has recorded. When an LDAP query returns the correct contact-URI attribute, an additionally query is not necessary. For this stage you have to configure the registration application transaction in the LDAP transactions configuration element.



Configuring LDAP Registrar’s Registration

To configure the LDAP registrar’s registration stage:





4. Click the name of a LDAP server configuration in the LDAP table and click Edit. The Edit LDAP dialog box appears.


6. Transaction type—Choose registration from the drop-down list to configure the query for registration validation stage of call registration.










Calling Validation At this point in the scenario, the caller sends an INVITE message to initiate a call with a remote endpoint. When this INVITE reaches the Net-Net SC, a query is made to the LDAP database to see if the caller (based on Contact URI) and the caller’s registration status make for a valid call. If the query is validated as true, the Net-Net SC can let the call proceed by forwarding the INVITE into the network.

For this stage you have to configure the calling-validation application transaction in the LDAP transactions configuration element.

Configuring LDAP Registrar’s Calling Validation

To configure the LDAP registrar’s calling validation:









6. Transaction type—Choose calling-validation from the drop-down list to configure the query for registration validation stage of call registration.










URI Resolution After the call has been validated, specific information is required for the Net-Net SC to set up the call. Some deployments employ dummy addresses in their SIP headers that must be repopulated with valid addresses upon ingress into the network. For example, when a registered endpoint sends an INVITE into the network, three relevant headers might appear like this:

INVITE: abc

To: abc

From: xyz

The Net-Net SC inserts these headers as attributes into an LDAP search request, and concatenates the From: and To: headers to be inserted in the LDAP Distinguished name field as the cn.

cn=sip:abc-sip:xyz,ou=Calls,ou=value1,dc=value2,dc=com

The LDAP server replies with the network-usable Request (INVITE) and To: header values. The Net-Net SC then inserts these values into the Request and To headers as it sends the INVITE into the network.

Concatenating From and To URIs

Certain deployments extract a unique string from a SIP URI for LDAP-based routing queries. In the URI sip:[email protected], the aorUserNameOnly option uses:

• sip:1234 as the AOR for registrar functionality

• sip:1234 as the routing key.

This option enables the concatenation of the From: and To: URIs described at the beginning of this section.

To configure the aorUserNameOnly option:

1. In Superuser mode, type configure terminal and press <Enter>.

ACMEPACKET# configure terminal

2. Type session-router and press <Enter> to access the session-router path.

ACMEPACKET(configure)# session-router

3. Type sip-config and press <Enter>. The prompt changes to indicate you can configure individual parameters.

ACMEPACKET(session-router)# sip-config

ACMEPACKET(sip-config)

4. options—Type options aorUserNameOnly. If there are existing options and you wish to add this new option while retaining the previously configured options, precede the option value pair with a +.

5. Save your work using the ACLI done command.

Per-User CAC The primary and secondary border gateway available for the media portion of this call is returned in the Per-user CAC query. BGs are identified by their MID. If neither of the BGs are available, the call is rejected.

In addition to URI resolution, the Net-Net SC learns call admission control criteria from the LDAP server in the same message that returns URI resolution information. The LDAP server tells the Net-Net SC the following CAC constraints:

Current and maximum number of calls for this caller and called pair—The SC checks the current in-call count, and if it's less than the max-count limit, it allows the call. An LDAP modify is performed to increase the in-call count at the time of forwarding



the INVITE, not receiving the 200OK message. If the count has been maximized, the call is rejected. When a call ends, the Net-Net SC performs an LDAP modify to decrement the current call count, as expected.

Media constraints for this call—The media constraints include the available codecs, codecs’ packetization time, and the bandwidth caps on both the ingress and egress side of the media portion of the call. Codecs present in a call's SDP that are not present in the LDAP-based registrar's CAC response are removed from the SDP message before the INVITE is passed to the next hop. If no matching codecs are found between the call’s SDP offer, and the LDAP server’s response for CAC, the call is rejected. The Net-Net SC uses the WAN-side media bandwidth value for media policing as learned in this step.

For this stage you have to configure the "call-routing" application transaction in the LDAP transactions configuration element.

Configuring URI Resolution and Per-User CAC

To configure the LDAP registrar’s URI resolution and per-user CAC:







6. Transaction type—Choose call-routing from the drop-down list to configure the query for registration validation stage of call registration.










Routing Behavior The Net-Net SC employs LDAP lookups for call routing. In this final step, the Net-Net SC uses its standard routing procedures to find where to send the call’s INVITE (or other relevant message) next. LDAP-based call routing is invoked from the existing local policy attributes configuration element. In this configuration element, the next-hop parameter needs to point toward an LDAP configuration by configuring it in the form ldap:ldap-config-name.

When the Net-Net SC finds a matching local policy, it sends the Request and To URI received in the URI Resolution step to the LDAP server. The LDAP server responds with the URI that the Net-Net SC should insert into the message’s Contact header and the Net-Net SC likewise forwards the SIP message to this address.

For this stage, you have to configure the called-validation application transaction in the LDAP transactions configuration element and an appropriate local policy attribute.



Configuring the Registrar’s Routing

To configure the LDAP registrar’s routing:







6. Transaction type—Choose called-validation from the drop-down list to configure the query for registration validation stage of call registration.










Configuring Route (Local) Policy

To configure route (local) policy to use an LDAP server for routing:

1. Click Routes in the Net-Net EMS navigation tree.

The Routes table appears in the display pane.

2. Click a route in the table to choose it and click Edit. The Edit Routes window appears.

3. Click a route policy in the Route policies area and click Edit. The Edit Route policy dialog box appears.

4. In the Next hop area, choose the LDAP you configured from the Next hop drop-down list.

5. Click Apply. You return to the Route dialog box.

6. Click Apply. You return to the Routes Table window.



Session Controller VQ-QoSThe decomposed SBC platform uses interim VQ-QoS statistics correlation IDs to resolve a call's signaling traffic which travels across the Net-Net SBC with the corresponding media traffic which travels across the Net-Net BG. The Net-Net SBC can send up to three IDs to the Net-Net BG to be inserted in the VQ-QoS file. The relative configuration position determines the order in which these IDs are written to the CSV file in the Net-Net BG's VQ-QoS CSV file.

For this configuration:

• calling = user part of From URI

• called = user part of To URI

• session= acct-session-id attribute

Configuring VQ-QoS

To configure the interim statistic ID types on the Net-Net SC:



2. Click the Accounting tab.

3. QoS flow identifier—Click Add. The Add QoS flow identifier dialog box appears.

4. Choose calling from the drop-down list and click OK.

The calling type appears in the QoS flow identifier list.

5. Repeat steps 3 and 4 to choose called and then session from the drop-down list.

6. Click Apply.



Configuring RedundancyYou can configure session controller parameters on Net-Net SBC redundant pairs.

Note: Acme Packet strongly does not recommend that you change these parameters from their default for a normal HA node configuration.

1. Click the Net-Net 4000 HA pair you are configuring in the Net-Net EMS navigation tree.

The SD HA node window appears in the Net-Net EMS display pane.

2. Click the HA SC State tab.

3. Sync messages listening port—Enter the port number on which the Net-Net SBC listens for synchronization messages that support HA. The valid range of ports is 1025-65535. The default is 1996.

4. Max number of sync transaction to keep—Enter the maximum number of HA synchronized transactions to maintain on the active system in the HA node. The valid range is 0 to 999999999.

5. Timeout for checking transaction from standby to active—Enter the amount of time in milliseconds that the active Net-Net SBC checks to confirm that it is still the active system in the HA node. If the active system is still adequately healthy, this timer will simply reset itself. If for any reason the active has become the standby, it will start to checkpoint with the newly active system when this timer expires. The valid range is 0 to 999999999, and the default is 5000.

6. Timeout for subsequent sync requests—Enter amount of time in milliseconds that determines how frequently after synchronization the standby Net-Net SBC checkpoints with the active Net-Net SBC. The first interval occurs after initial synchronizations of the systems; this is the timeout for subsequent synchronization requests. The valid range is 0 to 999999999.

7. Click Apply.


3 Connectivity Failure Detection

IntroductionThe Net-Net BG supports three methods of determining external device reachability.

• Gateway Heartbeat

• Bidirectional Forwarding Detection

• ICMP Echo

Each method provides unique features and the ability to provide details about the network conditions that created a fault condition. Only one of the three reachability mechanisms can be configured on a network interface at one time.

Interface Failure Switchover BG’s Action Health Decrement Alarm SNMP Traps

GW Heartbeat yes Send Service Change on Network IF down

global per network IF yes network IF down

BFD no Send Service Change on all BFD Sessions on one IF down


ICMP Echo no Send Service Change on ICMP Heartbeat down on a Network IF


CONNECTIVITY FAILURE DETECTION

Network Interface Health Score DecrementWhen the connectivity failure detection mechanism on a network interface fails and enters a downed state, the Net-Net BG subtracts a configured value from the network interface’s health score. See the High Availability Nodes chapter in the Net-Net 4000 ACLI Configuration Guide for more information.

This health decrement value is configurable and used for the active failure detection mechanism on the network interface.

Configuring Health Score Decrement

To configure an interface’s health score decrement

1. Click Interfaces in the Net-Net EMS navigation pane.

The Physical interface table appears in the right pane.

2. Click a physical interface in the table and click Edit. The Edit Physical interface table appears.

3. Scroll to the Network interface table.

4. Click a network interface and click Edit. The Edit Network interface window appears.

5. Health score decrement - network interface failure—Enter the value that is subtracted from the Net-Net BG’s health score when the reachability mechanism on this network interface loses its heartbeat.

6. Click Apply.



ARP Gateway HeartbeatThe Net-Net BG can detect when network connections to gateways are lost and then, in response, failover to a valid physical interface (configured as a failover system). The Net-Net BG monitors its network connectivity to the next hop by sending periodic ARP requests; this is known as a heartbeat message. When the Net-Net BG sends an ARP request and the remote Ethernet interface replies with an ARP reply, the connection is considered up, and service proceeds normally.

Link Failure Detection If the Net-Net BG does not receive the expected ARP reply to its heartbeat ARP request within the specified timeout period, the gateway is considered unreachable and a "gateway unreachable" network-level alarm is generated. The Net-Net BG considers the link failed, sets its interface card to standby, and the configured health score amount is subtracted from the interface card that experienced the gateway link failure.

In the Net-Net EMS 4000 Configuration Guide, refer to Configuring Front Interface Link Detection and Gateway Polling (824) in the High Availability Nodes chapter to learn how to configure the gateway heartbeat feature.

Bidirectional Forwarding DetectionThe Net-Net BG supports Bidirectional Forwarding Detection (BFD), IETF Draft 05, as a means to detect faults in the bidirectional path between two forwarding engines and install failover gateways upon network path failures. The Net-Net BG implementation of BFD supports BFD version 1, non-authenticated, in asynchronous mode. BFD control messages are transported over UDP.

Overview The Net-Net BG constantly probes the list of BFD sessions configured on a network interface for liveliness using the BFD protocol. When the system starts up, the highest priority BFD session is installed as a network interface's default gateway. When the in-service, highest-priority BFD session becomes unreachable via BFD, the Net-Net BG installs the in-service BFD session with the highest priority as the default gateway for that interface. The Net-Net BG always attempts to reestablish all downed BFD sessions, so when they are reestablished, they can be used as failover sessions.

BFD Initialization A BFD session begins when the Net-Net BG starts sending control messages to a BFD peer in an initialization state. When bidirectional communication commences, as noted by a successful response message, the session is considered up. If an initial BFD message is received by the Net-Net BG before it gets a response to its first BFD message, the Net-Net BG considers the session up after finding a BFD session configuration for the peer that sourced the first-received BFD message. An operational BFD session thus appears as a ping-pong of messages between the two peers.



BFD Timer Negotiation

The BFD protocol uses transmit and receive timers to specify how quickly BFD control packets are sent to peers. At initialization time (always), and at any point during an established BFD session (optionally), transmit and receive timers can be negotiated between the two peers. A peer will never send control packets to the other peer faster than the receiver is willing to accept them.

During timer negotiation, the Net-Net BG compares its peer's desired receive timer to its own transmit timer, and chooses the longer of the two times for transmitting. Similarly the Net-Net BG sends a desired receive timer value. The BFD peer will compare the Net-Net BG's desired receive time to its own desired transmit time and choose the longer of the two intervals for transmitting BFD control packets.

BFD Session Failure Detection

Once the BFD session timers have been negotiated, the BFD peers exchange BFD control packets at the negotiated interval. As long as each BFD peer receives a BFD control packet within the specified detect period, the BFD session remains up.

The Net-Net BG calculates the BFD failure detect period by multiplying the receive interval by the detect multiplier. The default is 900 ms (3 detect multiplier x 300 ms). If a BFD peer does not receive a control packet within the detect interval, it considers that session down. Thus, the failure detection is dependent upon received packets, and is independent of when the receiver last transmitted a packet. The Net-Net BG attempts to reestablish downed BFD sessions by transmitting initial BFD messages at one-second intervals.

When the Net-Net BG first comes online, an initial 5 second guard timer is used for starting up the BFD sessions and setting a base state. After this, the detect period is used for determining BFD session faults.

BFD Session Failure Actions and Recovery

The Net-Net BG starts up and installs the highest priority (#1) BFD session as the gateway for a network interface. If that gateway fails via a failed BFD session, the #2 BFD session gets installed as the gateway for that network interface (assuming it is up and has a session priority > 0). The Net-Net BG always installs the highest priority in-service BFD session as a gateway, when a session goes out of service. Once a fail-over has occurred, the standby Net-Net BG will attempt to restart all BFD sessions in the down state, so they can become available standbys.

BFD Session Group Failure

A BFD session group is the collection of all BFD sessions configured on a network interface. If all members in a BFD session group fail, the Net-Net BG fails the full network interface. When only a portion of the BFD session group fails, the network interface remains operational.

When a full BFD session-group fails, the Net-Net BG notifies the Net-Net BG application of the network interface loss via a service change. If the health-score decrement value for that network interface is greater than 0, a network interface loss alarm is set, and the system fails over to redundant hardware, if possible.

There are two configurable responses the Net-Net BG can take when a BFD session group fails. These include:

• Set the network interface health decrement after a BFD session failure

• Force the failure of all configured ICMP heartbeat sessions on other network interfaces.



Configuring BFD BFD support is configured within a network interface configuration element. After first enabling BFD on a network interface, you then define the BFD sessions for that interface. BFD sessions are configured as a list of gateways defined by their IP address, time-out detect period, and priority.

Note: Make sure your #1 prioritized BFD session's IP address is the same as the default gateway in that network interface.

To configure the BFD:

1. Click Interfaces in the Net-Net EMS navigation pane.

The Physical interface table appears in the right pane.

2. Click a physical interface in the table and click Edit. The Edit Physical interface table appears.

3. Scroll to the Network interface table.

4. Click a network interface and click Edit. The Edit Network interface window appears.

5. Scroll to the Bi-directional forwarding detection heartbeat table.

6. Click Add. The Add bi-directional forwarding detection heartbeat dialog box appears.

7. Enable BFD state—Click this checkbox to enable BFD for this network interface.

8. Click OK to close the dialog box. The word enabled appears in the State column of the Bi-directional forwarding detection heartbeat table.

9. Click the word enabled in the table and click Edit. The Edit Bi-directional forwarding detection heartbeat window appears.

10. Click Add. The Add BFD session dialog box appears.



11. Destination IP address—Enter the IP address of the BFD peer to be used as this network interface’s default gateway.

12. Click OK to close the dialog box. The BFD session information appears in the table.

13. Click the BFD session information and click Edit. The Edit BFD session dialog box appears.

14. State—Click this checkbox to enable the BFD session.

15. Minimal transmission interval (ms)—Enter the minimum transmit interval (max rate) in ms at which the BG sends BFD control packet, pre-negotiation. The valid range is 0-999999999.

16. Minimal receive interval (ms)—Enter the minimum receive interval (max rate) in ms at which the BG can receive BFD control packet, pre-negotiation. The valid range is 0-999999999.

17. Detection multiplier—Enter the detect multiplier used for determining a downed BFD session. The valid range is 0-999999999.

18. Gateway session priority—Enter this BFD session’s install priority. 1 is primary, 2 is secondary, etc. You should configure the network interface’s gateway as the primary BFD session by convention.

19. Click Apply. The BFD session information appears in the BFD session table.

20. Repeat steps 12 through 20 to configure additional sessions. You should create your secondary (and tertiary) BFD session configurations.

21. Click Apply in the Edit Bi-directional forwarding detection heartbeat to close the window.

22. Click Apply to close the Edit Network interface window.



R-Factor Alarm ThresholdsThe Net-Net SC computes the R-factor statistic for every 30 second window in both the calling and called directions. The transmission rating factor R can lie in the range from 0 to 100, where R = 0 represents an extremely bad quality and R = 100 represents a very high quality. The E-model provides a statistical estimation of quality measures as defined by ITU-T G.107 and related specifications. Essentially, the R-Factor is based on a base number, minus several values representing call quality impacts/impairments, plus a value based on the user's expectation. The codec type and packetization time, used for R-factor computation is conveyed from the SC in the H.248 local descriptor SDP for a context's terminations.

Configuring R-Factor Alarm Threshold

To configure R-factor alarm threshold:



2. Click the Management tab.

3. Scroll to the Alarm threshold area.

4. Click Add. The Alarm threshold dialog box appears.

5. Alarm Type—Choose rfactor from the drop-down list.

6. Severity—Choose the level of severity from the drop-down list.

7. Value—Enter the value at which, if exceeded, an alarm is generated. This value is expressed as a percentage ranging from 1 to 99.

8. Click OK. The dialog box closes and the name of the threshold appears in the Alarm threshold list.

9. Click Apply.

10. Reboot the Net-Net 4000 to activate the configuration.


4 Historical Data Recording

IntroductionHistorical data recording (HDR) refers to a group of management features that allow you to configure the Net-Net 4000 to collect statistics about system operation and function, and then send those records to designated servers. System statistics, defined in detail below, are saved to a comma-separated value (CSV) file, which are then sent to the designated server(s).

Information types are grouped so that you can refer to a set of statistics by simply invoking their group name. Within each group, there are several metrics available.

How It Works In the system configuration, you can enable HDR by first turning on the system’s collection function, then choosing the records you want to capture, and finally setting up server(s) to which you want records sent.

The main collect configuration (found within the main system configuration) allows you to create global settings that:

• Turn the HDR function on and off

• Set the sample rate in seconds, or the time between sample individual collections

• Set the time in seconds in between individual pushes to designated servers (configured in the push receiver configuration accessed via the collect configuration)

• Set the time you want the collect to start and stop; time is entered in year, month, day, hours, minutes, and seconds

You also configure setting for each group of data you want to collect, and the push receiver (server) to which you want data sent.

About the CSV File When you enable HDR and configure one or more servers to which you want records sent, data is transmitted in a CSV file in standard format. There is one CSV file per record group type, and the first record for each file is a header containing the field name for each attribute in that file.

HISTORICAL DATA RECORDING

Collection Interval and Push

In your HDR configuration, you set parameters that govern:

• The groups for which the Net-Net 4000 collects records

• How frequently the Net-Net 4000 collects records

• How frequently the Net-Net 4000 sends records off-box

Factoring in the number of groups for which you collect records, you can calculate the number of records that will be sent per push. The number of files that are sent off-box equals the number of groups for which the Net-Net 4000 is collecting records; there is always one additional record for each group, a header file containing the field name for each attribute.

The number of records in a file, then, equals the push interval divided by the sample interval time multiplied by the number of groups, plus one. Take the case, for example, where you set a push interval time of 60 seconds and a sample interval time of 5 seconds, with a group of ten records. With these settings, the Net-Net 4000 would send 120 group records and 10 header records (for a total of 130 records) for each push.

Note that after each push, the Net-Net 4000 clears (deletes) all records. The Net-Net 4000 also clears files on system reboot, and after three consecutive push failures.

Optional Trap You can configure the system to send a trap confirming successful data pushes to designated network elements. This trap has a default level of MINOR. It contains the name of the node that successfully pushed the HDR file to an HDR server, a unique file name for the HDR file that was pushed, and the IP address of the push receiver (configured in the global collection configuration).

If you enable the trap without any configured HDR groups, the Net-Net SBC sends the trap for all HDR groups. Refer to the System Configuration chapter of the Net-Net Configuration Guide for a complete list of HDR group record types. If you configure specific groups, then the system sends the trap only for those groups.

Note: You should consider the system performance impact of enabling this trap before you do so.

74 Net-Net EMS Decomposed SBC Essentials Version 6.0


Group Record Types In the group-name parameter for the group-settings configuration, you can enter any one of the groups record type defined in the following table. You specify the collection object, and then all metrics for that groups are sent.

Collection Object Metrics Included

General system statistics (system) • CPU utilization• Memory utilization• Health score• Redundancy state• Current signaling sessions• Current signaling session rate (CPS)• CAM utilization media• CAM utilization ARP• I2C bus state• License capacity

Interface statistics (interface) • Interface index• Name/description• Type• MTU• Speed• Physical address• Administrative status• Operational state• In last change• In octets• In unicast packets• In non-unicast packets• In discards• Out errors• Out octets• Out unicast packets• Out non-unicast packets• Out discards• Errors

Combined session agent statistics (session-agent)

• Hostname• System name• Status• Inbound active sessions• Inbound session rate (CPS)• Outbound active sessions• Outbound session rate (CPS)• Inbound sessions admitted• Inbound sessions not admitted• Inbound concurrent sessions high• Inbound average session rate (CPS)• Outbound sessions admitted• Outbound sessions not admitted• Outbound concurrent sessions high• Outbound average session rate (CPS)• Max burst rate (in and out) (CPS)• Total seizures• Total answered sessions• Answer/seizure ratio• Average one-way signaling latency (ms)• Maximum one-way signaling latency (ms)



Session realm statistics (session-realm) • Realm name• Inbound active sessions• Inbound session rate (CPS)• Outbound active sessions• Outbound session rate (CPS)• Inbound sessions admitted• Inbound sessions not admitted• Inbound concurrent sessions high• Inbound average session rate (CPS)• Outbound sessions admitted• Outbound sessions not admitted• Outbound concurrent sessions high• Outbound average session rate (CPS)• Max burst rate (in and out) (CPS)• Total seizures• Total answered sessions• Answer/seizure ratio• Average one-way signaling latency (ms)• Maximum one-way signaling latency (ms)

Environmental voltage statistics (voltage)

• Voltage type• Description• Current voltage (mv)

Environmental fan statistics (fan) • Fan type• Description• Speed

Environmental temperature statistics (temperature)

• Type• Description• Value (Celsius)

SIP status statistics (sip-sessions) • Sessions• Subscriptions• Dialogs• Call ID map• Rejections• ReInvites• Media sessions• Media pending• Client transaction• Server transaction• Response contexts• Saved contexts• Sockets• Requests dropped• DNS transactions• DNS sockets• DNS results• Session rate• Load rate




SIP error/event statistics (sip-errors) • SDP offer errors• SDP answer errors• Drop media errors• Transaction errors• Media expiration events• Early media expirations• Early media drops• Expired sessions• Multiple OK drops• Multiple OK terminations• Media failure drops• Non-AXK 2XX drops• Invalid requests

SIP policy/routing (sip-policy) • Local policy lookups• Local policy hits• Local policy misses• Local policy drops• Agent group hits• Agent groups misses• No routes found• Missing dialog• Inbound SA constraints• Outbound SA constraints• Inbound REG SA constraints• Outbound REG SA constraints• Requests challenged• Challenge found• Challenge not found• Challenge dropped

SIP server transaction (sip-server) • All states• Initial• Trying• Proceeding• Cancelled• Established• Completed• Confirmed• Terminated

SIP client transactions (sip-client) • All states• Initial• Trying• Calling• Proceeding• Cancelled• EarlyMedia• Completed• SetMedia• Established• Terminated

SIP ACL status (sip-ACL-status) • Total entries• Trusted• Blocked

SIP ACL operations (sip-ACL-oper) • ACL requests• Bad messages• Promotions• Demotions




SIP session status (sip-status) • Sessions initial• Sessions early• Sessions established• Sessions terminated• Dialogs early• Dialogs confirmed• Dialogs terminated

MGCP task state (mgcp-state) • MGCP sessions• CA endpoints• GW endpoints• Media sessions• Client transactions• Server transactions• Pending MBCD• MGCP ALGs

MGCP transactions (mgcp-trans) • Requests received• Responses sent• Duplicates received• Requests sent• Responses received• Retransmissions sent

MGCP media events (mgcp-media-events)

• Calling SDP errors• Called SDP errors• Drop media errors• Transaction errors• Media expiration events• Early media expiration• Expiration media drops

MGCP ACL status (mgcp-ACL) • Total entries• Trusted• Blocked

ACL operation (mgcp-oper) • ACL requests• Bad messages• Promotions• Demotions

H.323 statistics (h323-stats) • Incoming calls• Outgoing calls• Connected calls• Incoming channels• Outgoing channels• Contexts• Queued messages• TPKT channels• UDP channels




Configuring HDR This section shows you how to configure HDR. You need to set up:

• Collection configuration to govern sample and push intervals, start and end times for collection

• Optional trap confirming successful data pushes to designated network elements (consider the system performance impact of enabling this trap)

• Setting to support this feature across an HA node

• Group settings configuration that tells the Ne-Net 4000 what groups of records to collect, when to start and stop collecting them, and how often to sample for that group

• Push receivers that take the records the Net-Net 4000 sends

All HDR parameters are RTC-supported, so you can save and activate your configuration for them to take effect.

Accessing the HDR Configuration Parameters

To access the HDR configuration parameters:


The SBC system window appears in the Net-Net EMS display pane.

2. Click the Collect tab.

From here you can configure global collection settings, HDR for HA nodes, the push receivers, and the collection groups.



Global Collection Settings

To configure global settings for HDR support:

1. Collection interval—Enter the time in minutes for how often you want the Net-Net 4000 to sample data records. Leaving this parameter set to 0 (default) turns off the feature. The maximum value for this parameter is 120 minutes (2 hours).

2. Push interval—Enter the time in minutes for how often you want the Net-Net 4000 to send collected records to push receiver(s). The default is 0 XX NEED MIN AND MAX.

3. Boot state—Click this checkbox to enable HDR.

4. Start date time—Click Now if you want the start date time to be now. Or click the button with the three dots to access a calendar. Choose the exact date and time (for your local timezone) when you want the Net-Net 4000 to start HDR collection; this time is either now or a time in the future.

5. End date time—Click Never if you want the collection to continue indefinitely. Or click the button with the three dots to access a calendar. Choose the exact date and time (for your local timezone) when you want the Net-Net 4000 to finish HDR collection; this time is either never or a time in the future.

The Calendar appears:

Scroll to select the month.Scroll to select the year.

Scroll to change the time.

Click to select a day.

5a. Choose the month, and the year, for the date by scrolling to the month and year you need.

5b. Choose the day by clicking the appropriate cell.

5c. Choose the time by scrolling up or down in the time textbox.

6. Click OK to close the Calendar.

If using HDR on an HA node, configure HDR support by following the instructions in HDR for an HA Node[73]. Otherwise go to Configuring Push Receivers[81].

7. Generate trap for successful pushes—Click the checkbox to enable the Net-Net SBC to send a trap confirming successful data pushes to HDR servers.



Configuring Push Receivers

You can configure multiple servers to receive the Net-Net 4000 records. If you configure more than one server, then the Net-Net 4000 sends data to all of the servers. If one server fails, the Net-Net 4000 generates an SNMP trap. When clearing data, if there are four servers configured and the Net-Net 4000 successfully pushes data to three of them, it will clear the data.

To configure servers to act as push receivers for HDR data:

1. Under the Push receiver table, click Add. The Add Push receiver dialog box appears.

2. Address—Enter the IP address or hostname of the push receiver (server) to which you want records sent.

3. User name—Enter the username that the Net-Net 4000 will use when it tries to send records to this push server using FTP. There is no default for this parameter.

4. Password—Click Edit. The Edit password dialog box appears.

5. New value—Enter the password (corresponding to the username) that the Net-Net 4000 will use when it tries to send records to this push server using FTP.

6. Configuration password—Enter the password used on the Net-Net 4000 to encrypt configuration information.

7. Confirm the configuration password.

8. Click OK. A message appears recommending that you verify the configuration.

9. Click OK to clear the message. A row of asterisks appears in the Password textbox.

10. Repository—Enter the directory on the push receiver where you want collected data placed. This path must match the HDR collection path specified during the installation of Net-Net EMS.

11. Click OK.



Configuring Collection Groups

You can configure multiple collection groups on your Net-Net 4000; the names of these groups appear in the Group Record Types (75) section above. Collection group settings are accessible through the collection configuration.

Note that the sample collection interval, start time, and end time you set here override the ones established in the global collection settings. The largest value you can enter for an group’s sample collection must be smaller than the global push interval value.

To configure collection group settings:

1. Under the Collection group table, click Add. The Add Collection group dialog box appears.

2. Groupname—Choose the group name corresponding to the records that you want to collect from the drop-down list. There are 21 possible groups for which the Net-Net 4000 can collect data, see Group Record Types (75) for details.

3. Collection interval—Enter the time in minutes for how often you want the Net-Net 4000 to sample data records for the specified group. The maximum value for this parameter is 120 minutes (2 hours) and the minimum is 1 minute. (Setting this parameter set to 0 turns off the feature for this group.

Consider the number of metrics being collected by the group you are configuring when setting the interval. If a collection group contains a large number of metrics being collected for a larger configuration, you want to set the interval value to a value that would get you meaningful data without effecting performance. For example, you would probably set the sampling interval for the session realm statistics collection group higher than you would the fan statistics group.

4. Boot state—Click the Boot state checkbox to enable HDR for this collection group.

5. Start date time—Click Now if you want the start date time to be now. Or click the button with the three dots to access a calendar. Choose the exact date and time (for your local timezone) when you want the Net-Net 4000 to start HDR collection; this time is either now or a time in the future.

6. End date time—Click Never if you want the collection to continue indefinitely. Or click the button with the three dots to access a calendar. Choose the exact date and time (for your local timezone) when you want the Net-Net 4000 to finish HDR collection; this time is either never or a time in the future.



The Calendar appears.

Scroll to select the month.Scroll to select the year.

Scroll to change the time.

Click to select a day.

6a. Choose the month, and the year, for the date by scrolling to the month and year you need.

6b. Choose the day by clicking the appropriate cell.

6c. Choose the time by scrolling up or down in the time textbox.

7. Click OK to close the calendar.

8. Click OK.

Configuring HDR for an HA Node

If you are using the HDR feature on an HA node (or redundant pair of Net-Net 4000s), you need to make sure that several parameters in the collection configuration are set appropriately.

To configure parameters for HDR support across an HA node:

1. Choose the Net-Net SBC HA node from the Net-Net EMS navigation pane.

The SBC HA node window appears.

2. Click the HA HDR collection tab.

3. Redundant state—Click the checkbox to enable HDR redundancy.



4. Redundant number of transmissions—Enter the maximum number of HA synchronized transactions to maintain on the active system in the HA node. The valid range is 0 to 999999999, and the default is 1000.

5. Redundant sync start time—Enter the amount of time in milliseconds that the active Net-Net 4000 checks to confirm that it is still the active system in the HA node. If the active system is still adequately healthy, this timer will simply reset itself. If for any reason the active has become the standby, it will start to checkpoint with the newly active system when this timer expires. The valid range is 0 to 999999999, and the default is 5000.

6. Redundant sync comp time—For Redundant sync comp time, enter amount of time in milliseconds that determines how frequently after synchronization the standby Net-Net 4000 checkpoints with the active Net-Net 4000. The first interval occurs after initial synchronizations of the systems; this is the timeout for subsequent synchronization requests. The valid range is 0 to 999999999, and the default is 1000.



HDR Trap for Data Push SuccessWhen you use historical data recording (HDR) on your Net-Net SBC, you can configure the system to send a trap confirming successful data pushes to designated network elements. This trap has a default level of MINOR. It contains the name of the node that successfully pushed the HDR file to an HDR server, a unique file name for the HDR file that was pushed, and the IP address of the push receiver (configured in the global collection configuration).

If you enable the trap without any configured HDR groups, the Net-Net SBC sends the trap for all HDR groups. Refer to the System Configuration chapter of the Net-Net Configuration Guide for a complete list of HDR group record types. If you configure specific groups, then the system sends the trap only for those groups.

Note: You should consider the system performance impact of enabling this trap before you do so.

Configuring HDR Data Push Success Trap

You enable the HDR data push success trap in the global collection settings, along with the sampling interval, push interval, and other settings.

To enable the HDR trap for data push success:


The Net-Net SBC system window appears in the display pane.

2. Click the Collect tab.

3. Generate trap for successful pushes—Click the checkbox to enable the Net-Net SBC to send a trap confirming successful data pushes to HDR servers.

4. Click Apply.


5 Registration Caching

IntroductionYou can use Net-Net EMS to access the registration cache for the SIP, H.323, and MGCP protocols to query and clear entries. You can run an endpoint audit to determine if endpoints are reachable and able to respond to signaling messages.

How It Works You can query and clear entries in each cache using predefined grouping methods among others. You can group cache entries by user (endpoint) or IP address range.

Accessing the Registration Cache

To access the registration cache:

1. In the Active configurations area, right click a Net-Net SBC.

A pop-up list of options appears.

REGISTRATION CACHING

2. Click Registration Cache to select it.

The Registration Cache window appears. You can view, audit, and clear registration cache information for SIP, MGCP, and H.323 protocols.

Working with SIP Registration Caches

To display the SIP registration caches:

1. In the Cache Type area, click SIP.

The SIP commands and registration cache table appear. From here you can show, clear, and audit.

IP Address Displays the Net-Net SBC’s SIP process registration cache for a specified IP address. The IP address value can be a single IP address, a wildcarded IP address value that has an asterisk (*) as its final character, or just the asterisk itself as the wildcard.

Note: This command is only available if you configure the reg-via-key option in the SIP interface prior to endpoint registration. The reg-via-key option keys all registered endpoints by IP address and username.

To display the SIP process registration cache for an IP address.

1. Action—Choose show from the Action drop-down list.



2. Type—Choose by-ip from the Type drop-down list.

3. Expression—Enter the IP address value or an IP address range in the form n.n.n.n/nn in the Expression textbox. You can use the asterisk as a wildcard.

4. Click Apply. The Apply button grays out while Net-Net EMS processes the command. A message is displayed in the Command status textbox once processing completes and the Cache table displays the results (if any).

You can view the known details of the cache table entries. See Viewing Registration Cache Details for step-by-step instructions.

Users Displays the Net-Net SBC’s SIP process registration cache for a specified phone number or for a user name. The <endpoint> portion of the command you enter depends on how the SIP endpoint is registered. For example, an endpoint might be registered as [email protected] or as [email protected]. The value preceding the at-sign (@) is what you enter for the <endpoint>.

The phone number can be a single number (such as 7815551234) or a single number wildcarded by placing an asterisk (*) (such as 7815551*) at the end of the phone number. The user name can be a single name (such as user), or a single name wildcarded by using an asterisk at the end of the user name (such as us*).

You can prefix the expression with sip: or sips: to specify whether the search for the endpoint should be over the secure connection (TLS) or not.


2. Type—Choose by-user from the Type drop-down list.

3. Expression—Enter the user name or phone number in the Expression textbox. You can use the asterisk as a wildcard.





Realm Displays the calls that have registered through a specified ingress realm. The output is sorted alphabetically by the realm name which will be shown first in the output.

To display the SIP process registration cache for a realm:




2. Type—Choose by-realm from the Type drop-down list

3. Expression—Enter the name of the realm whose registration cache information you want to view or use the asterisk as a wildcard.



Registrar Displays formation for calls that use a specific registrar.

To display the SIP process registration cache for a registrar:


2. Type—Choose by-register from the Type drop-down list

3. Expression—Enter the IP address of the registrar whose registration cache information you want to view or use the asterisk as a wildcard





Route Display information for calls by their Internet-routable IP address. This allows you to view the endpoints associated with public addresses.

To display the SIP process registration cache for a route:


2. Type—Choose by-route from the Type drop-down list

3. Expression—Enter the IP address whose registration cache information you want to view or use the asterisk as a wildcard



Command Status The Command status textbox displays the commands you issue. For example:



Viewing Registration Cache Details

You can right-click an entry in the Cache table or click a row to select it and then click Detail to access additional details. The Registration cache entry details window appears.



Clearing the SIP Registration Cache

To clear the SIP process registration cache:

1. Action—Choose clear from the Action drop-down list.

2. Type—Choose all or by-user from the Type drop-down list.

• all—Clears all SIP registrations in the cache

• by-user—Clears the Net-Net SBC’s SIP process registration cache of a particular phone number or user name

Note: You cannot wildcard values for commands to clear the SIP registration cache.

3. Expression—If clearing by user, enter a phone number or a user name.

4. Click Apply.

Auditing the SIP Registration Cache

To audit the SIP process registration cache:

1. Action—Choose audit from the Action drop-down list.

2. Type—Choose by-ip or by-user from the drop-down list.

• by-ip—Audits a specified IP address in the SIP registration cache.

• by-user —Audits a specific user by specifying the user name or phone number in the SIP registration cache.

Note: Note that you cannot wildcard values for commands to audit the SIP registration cache. Expired entries are automatically cleared.

3. Expression—Enter an IP address for or phone number or a user name.

4. Click Apply.



Working with the H.323 Registration Cache

To work with H.323 registration caches:

1. In the Cache Type area, click H323.

The H.323 commands and registration cache table appear. From here you can show, clear, and audit registration cache entries.

Displaying the H.323 Registration Cache

To display the H.323 cache entries:


2. Type—Choose by-alias from the Type drop-down list to display the H.323 registration cache for a particular alias.

3. Expression—Enter use a phone number or terminal identifier. You can wildcard the value by using an asterisk (*) as the final character in the terminalAlias string.





Clearing the H.323 Registration Cache

To clear the H.323 process registration cache:


2. Type—Choose all or by-alias from the Type drop-down list.

3. Expression—If by-alias, enter a phone number or terminal identifier.

Note: You cannot wildcard values to clear the H.323 registration cache.

4. Click Apply.

Auditing the H.323 Registration Cache

To audit the H.323 process registration cache:


2. Type—Choose by-alias from the drop-down list.

3. Expression—Enter enter a phone number or terminal identifier.

4. Click Apply.

Working with MGCP Registration Caches

To work with MGCP registration caches:

1. In the Cache Type area, click MGCP.

The MGCP commands and registration cache table appear. From here you can show, clear, and audit registration cache entries.

Displaying the MGCP Registration Cache

To display the MGCP registration cache entries:


2. Type—Choose by-endpoint from the Type drop-down list.

3. Expression—Enter one of the following arguments:

• realm_id:local_name@host

• realm_id:host

• local_name@host

• host

In these arguments, values are defined as follows:

• realm_id—Name of a realm named in the MGCP configured; only complete realm names are accepted; entry must end with a colon (:)

• local_name—Local name of the endpoint; must end with the at-sign (@)



• host—Can be an FQDN, IP address, or IP address enclosed in square brackets ([]); wildcarded by using an asterisk (*) at the end to refer to multiple hosts; using the square brackets for in IP address value is optional



Command Status The Command status textbox displays the commands you issue. For example:



Clearing the MGCP Registration Cache

To clear the MGCP process registration cache:


2. Type—Choose all or by-endpoint from the Type drop-down list.

• all—Clears all MGCP registrations in the registration cache.

• by-endpoint—Clears the MGCP registration cache of a particular endpoint. You enter this command with one of the following arguments:

realm_id:local_name@host

realm_id:host

In these arguments, values are defined as follows:

• realm_id—Name of a realm named in the MGCP configured; only complete realm names are accepted; entry must end with a colon (:)

• local_name—Local name of the endpoint; must end with the at-sign (@)

• host—Can be an FQDN, IP address, or IP address enclosed in square brackets ([]); wildcarded by using an asterisk (*) at the end to refer to multiple hosts; using the square brackets for in IP address value is optional

3. Expression—If clearing by endpoint, enter the endpoint information.

4. Click Apply.

Auditing the MGCP Registration Cache

To audit the MGCP process registration cache:

When you audit the MGCP registration cache, the Net-Net SBC sends an audit endpoint message (AUEP) to the MGCP endpoint to determine leachability, and a reply is expected from the endpoint.

MGCP audit messages are only sent to the endpoints in private realms. Requests sent to public realms are rejected and error messages are returned.


2. Type—Choose by-endpoint from the drop-down list.

3. Expression—Enter the endpoint information.

4. Click Apply.


6 Creating a Baseline Configuration

IntroductionIn addition to the configuration steps contained in the earlier chapters, you need to create a baseline configuration that establishes required logical functions on the Net-Net BG and SC. This section explains necessary configurations.

All configurations listed here are explained fully in the Net-Net EMS 5.1 4000 Configuration Guide. Please refer to that document for all necessary explanations and procedures.

Getting Started Refer to the Getting Started chapter to learn how to configure the following aspects of the system.

• Bootparameters

• Network Time

• Net-Net BG and SC software licensing

• RADIUS Authentication

System Configuration

Refer to the System Configuration chapter to learn how to configure the following aspects of the system.

• General System Information

• Physical Interfaces

• Network Interfaces

• System Alarm levels

• Syslog and Process log servers and logging facilities

• Media Manager

Realm Configuration

Refer to the Realms and Nested Realms chapter to learn how to configure the following aspects of the system.

• Realms

• Steering s

• QoS Measurement (see also Admission Control and Quality of Service chapter)


CREATING A BASELINE CONFIGURATION

SIP Signaling Services

Refer to the SIP Signaling Services chapter to learn how to configure the following aspects of the system.

• Basic SIP Functionality

• SIP Interface

• Home Realm

• SIP HNAT Traversal

• SIP Header and Parameter Manipulation

• all other SIP functionality

Session Routing and Load Balancing

Refer to the Session Routing and Load Balancing section to learn how to configure the following aspects of the system.

• Session Agents

• Local Policy

• SIP Routing

ToS Marking You can configure the Net-Net BG to set ToS values for traffic exiting the system. You can also configure the SC the tell the Net-Net BG how to mark outbound traffic. Until the SC configures the Net-Net BG for ToS marking, the Net-Net BG will perform ToS marking according to configuration. Once the SC sends ds/dscp properties, the Net-Net BG will use them and not revert to internal configurations.

102 Net-Net EMS 4000 Decomposed SBC Essentials Guide Version 6.0

net-net® ems 4000 decomposed sbc essentials · pdf filenet-net® ems 4000 decomposed...

Documents