amendments 2 preface3 1. introductionfiles.trunk.com.tw/康飛/management facility...vi table of...

nten

ts

AMENDMENTS ................................................................................................2

PREFACE...........................................................................................................3

1. INTRODUCTION ............................................................................................4

1.1. CONFIGURATIONS FOR EXTERNAL DEVICES ..................................................... 51.1.1. CPU3000 Platform ........................................................................................ 51.1.2. CCS Platform ................................................................................................. 81.1.3. External Devices .......................................................................................... 10

1.2. MANAGEMENT DEVICES ...................................................................................... 101.2.1. SysManager Maintenance PC - CPU3000 Platform ..................................... 131.2.2. OM Terminal - CCS Platform ...................................................................... 161.2.3. Backup Devices ............................................................................................ 161.2.4. Maintenance Mode - CPU3000 Platform only ............................................. 161.2.5. Dual Mode - CCS Platform only .................................................................. 171.2.6. Disk Emulator .............................................................................................. 181.2.7. SystemManager ............................................................................................ 181.2.8. Printer .......................................................................................................... 191.2.9. Remote Maintenance Device ....................................................................... 191.2.10. Operator Desks ........................................................................................... 20

1.3. DATE AND TIME MANAGEMENT ........................................................................ 21

2. FAULT MANAGEMENT ................................................................................24

2.1. ISPBX SOFTWARE STRUCTURE ........................................................................... 242.1.1. Operating System ........................................................................................ 252.1.2. Application Software .................................................................................... 25

2.2. SYSTEM ASSURANCE ............................................................................................. 262.3. SAS REPORTS .......................................................................................................... 282.4. ERROR CODE RELATED ITEMS ............................................................................ 31

2.4.1. Alarming ....................................................................................................... 312.4.2. Isolation ........................................................................................................ 312.4.3. Recovery ...................................................................................................... 312.4.4. Report Type ................................................................................................. 32

2.5. ALARM SIGNALLING .............................................................................................. 322.5.1. Major Alarm ................................................................................................. 332.5.2. Minor Alarm ................................................................................................. 332.5.3. Blocked Alarm ............................................................................................. 332.5.4. Silent Alarm .................................................................................................. 342.5.5. Changing the Alarm Level for a Resource or for an Alarm Code ................ 352.5.6. Clearing the Alarms ..................................................................................... 35

2.6. ALARM SIGNALLING DEVICES .............................................................................. 352.6.1. Alarm Unit ................................................................................................... 35

i

Tab

le o

f Co

ii

Table of C

ontents

2.6.2. V.28 Alarm Signals ........................................................................................372.7. SIMPLE ALARMING OVER IP (since Call@Net 2.8) ...............................................372.8. HISTORY BUFFERS ..................................................................................................402.9. PERIODIC AUTONOMOUS TEST .........................................................................402.10. MANUALLY CONTROLLED TEST .........................................................................412.11. OTHER TEST POSSIBILITIES ...................................................................................42

2.11.1. Test Telephone ............................................................................................422.11.2. Controlled Connection ................................................................................432.11.3. Directed Call ................................................................................................44

2.12. ROUTING OF ALARMS ...........................................................................................442.13. REDUCED RESOURCES AVAILABILITY ALARM ...................................................462.14. CPU SOFTWARE PROBLEMS - FREEZE FUNCTION ...........................................472.15. SYSTEM DUMP ........................................................................................................47

3. ACCOUNTING MANAGEMENT ..................................................................50

3.1. CALL CONTROL .....................................................................................................503.2. INTERNAL CALLS ...................................................................................................523.3. EXTERNAL CALLS ..................................................................................................53

3.3.1. Metering .......................................................................................................533.3.2. Toll Ticketing ...............................................................................................543.3.3. Charging on Diversion Initiator ....................................................................58

3.4. SystemManager .........................................................................................................593.5. FULL DETAILED CALL RECORDING ....................................................................59

3.5.1. FDCR Records .............................................................................................603.5.2. Projecting .....................................................................................................613.5.3. OM Commands ............................................................................................613.5.4. Hardware .....................................................................................................623.5.5. Layout of STANDARD Record ....................................................................623.5.6. Layout of ACCOUNTING Record ..............................................................683.5.7. FDCR for Enquiry and Transfer ...................................................................733.5.8. Interaction with other Facilities ....................................................................753.5.9. Toll-Ticketing on DPNSS Routes .................................................................763.5.10. DPNSS Remote Breakout Accounting (since Call@Net 2.6) ......................793.5.11. Cost Accounting For Transferred Calls (since Call@Net 2.8) .....................833.5.12. FDCR over IP (since Call@Net 2.8) ............................................................843.5.13. Generate Accounting Record For Free-Of-Charge Call

(since Call@Net 2.10) .................................................................................863.5.14. FDCR (TT) for IP-enabling (since Call@Net 2.11) ......................................863.5.15. Transfer FDCR for assisted incoming call to DPNSS ...................................863.5.16. Extra FCDR record for Twinning and Follow-me ........................................87

4. CONFIGURATION MANAGEMENT ............................................................92

nten

ts

4.1. INITIAL CONFIGURATION FILE ........................................................................... 924.2. JOURNAL FILE ........................................................................................................ 934.3. MEMORY IMAGE SNAPSHOT FILE ....................................................................... 954.4. INSTANTANEOUS CONFIGURATION FILE ........................................................ 964.5. DISPLAYING THE CONFIGURATION .................................................................. 974.6. SOFTWARE DOWNLOAD OF PERIPHERAL BOARDS ........................................ 98

4.6.1. Download Initiation ..................................................................................... 994.6.2. Download Execution ................................................................................. 1004.6.3. OM Commands ......................................................................................... 1004.6.4. Install New Software of Peripheral Boards ................................................ 1024.6.5. Install new software Variant ...................................................................... 102

4.7. TERMINAL DOWNLOADING ............................................................................. 103

5. PERFORMANCE MANAGEMENT ..............................................................105

5.1. TRAFFIC OBSERVATION AND MEASUREMENT ............................................... 1055.2. TRAFFIC OBSERVATION ..................................................................................... 1065.3. TRAFFIC MEASUREMENT .................................................................................... 107

5.3.1. Object List ................................................................................................. 1085.3.2. Output Destination .................................................................................... 1095.3.3. Manual Starting / Stopping the Traffic Measurement ................................. 1115.3.4. Timed Starting / Stopping the Traffic Measurement .................................. 1115.3.5. Traffic Measurement Status ....................................................................... 1115.3.6. Load Caused by Traffic Measurement ....................................................... 1115.3.7. Performance Manager Module on the SystemManager ............................. 112

5.4. OVERVIEW OF MEASUREMENTS ....................................................................... 1135.4.1. List of Objects and Entities ........................................................................ 1135.4.2. Measurement Methods .............................................................................. 1195.4.3. Definitions .................................................................................................. 1225.4.4. Measured Entities ...................................................................................... 125

5.5. GENERAL INTERPRETATION PROBLEMS ......................................................... 1375.5.1. Average Call Holding Time seems to be out of Proportion ...................... 1375.5.2. Deviation between Call Holding Times ..................................................... 1395.5.3. Multiples of Certain Figures in Traffic Measurement Output .................... 140

5.6. PROCESSOR LOAD - ADAPTIVE LOAD CONTROL .......................................... 1415.6.1. Real Load ................................................................................................... 1425.6.2. Load Sources ............................................................................................. 1425.6.3. Permission Units ........................................................................................ 1435.6.4. Minimum and Maximum Loading ............................................................... 1435.6.5. Allowing New Tasks .................................................................................. 1435.6.6. Guaranteed Loading ................................................................................... 1445.6.7. Display Processor Load ............................................................................. 145

iii

Tab

le o

f Co

iv

Table of C

ontents

5.6.8. Load Monitor ..............................................................................................1465.6.9. Changing parameters for the Adaptive Load Control ................................146

6. SECURITY MANAGEMENT ........................................................................148

6.1. FILE MANAGEMENT .............................................................................................1486.1.1. File Structure ..............................................................................................1486.1.2. Local Backup Device - all systems except iS3070/3090 .............................1496.1.3. Disk Emulator - all systems except CCS platform .....................................1496.1.4. Disk Maintainer - iS3070/3090 only ...........................................................1496.1.5. Commands .................................................................................................149

6.2. PROTECTION LEVELS ..........................................................................................1516.3. AUTHORITY CLASSES ..........................................................................................153

6.3.1. OM Device .................................................................................................1536.3.2. OM Command ...........................................................................................1546.3.3. Special Authority Classes ............................................................................1556.3.4. Command Files ..........................................................................................155

6.4. PASSWORDS ..........................................................................................................1566.5. RESTRICTION LEVELS ..........................................................................................158

6.5.1. Traffic Classes ............................................................................................1586.5.2. Facility Class Marks ....................................................................................159

6.6. TRAFFIC CLASS SWITCHING ...............................................................................1596.6.1. Day / Night Traffic Class Switching ............................................................1596.6.2. Changing (room) Traffic Class via an Extension (at Reception Desk) .......161

6.7. DAY / NIGHT CONDITION .................................................................................161

7. DIRECTORY MANAGEMENT .....................................................................162

7.1. INTRODUCTION ..................................................................................................1627.2. SUPERVISOR 50/50E/50S .......................................................................................162

7.2.1. Directory Management ..............................................................................1637.3. TELEPHONE MANAGEMENT SYSTEM / SystemManager ..................................163

7.3.1. Directory Management ..............................................................................164

8. FACILITY MANAGEMENT .........................................................................165

8.1. FACILITY CLASS MARK .........................................................................................1658.1.1. Assigning Facility Class Marks .....................................................................1668.1.2. Default Facility Class Marks ........................................................................166

8.2. PREFIX ....................................................................................................................1678.2.1. Assigning Prefixes .......................................................................................168

8.3. VOICE LOGGING ..................................................................................................1688.4. SILENT MONITOR ................................................................................................170

8.4.1. Introduction ................................................................................................170

nten

ts

8.4.2. Restrictions ................................................................................................ 1718.4.3. Tapping of an Active Tapping Party ........................................................... 172

9. REMOTE MAINTENANCE ..........................................................................174

9.1. INTRODUCTION ................................................................................................. 1749.2. REMOTE MAINTENANCE PORT ........................................................................ 175

9.2.1. BIM Remote Maintenance Port - iS3070/3090 CCS platform only ............ 1769.2.2. CPU Remote Maintenance Port - All Systems Except iS3070/3090 .......... 1769.2.3. Functionality of the Remote Maintenance Port ......................................... 1779.2.4. Modem ...................................................................................................... 179

9.3. CONNECTIONS FOR REMOTE MAINTENANCE ............................................. 1809.3.1. Connection Set-Up towards the ISPBX .................................................... 1809.3.2. Connection Set-Up from the ISPBX to the SystemManager ..................... 1819.3.3. Connection Break-Down .......................................................................... 182

9.4. FUNCTIONALITY OF THE SystemManager ........................................................ 1839.5. CHECKLIST ISPBX - SystemManager CONNECTION ........................................ 184

10. SYSTEMMANAGER .....................................................................................186

10.1. SSM SOFTWARE CONFIGURATION .................................................................. 18810.2. SSM SOFTWARE MODULES ................................................................................ 188

10.2.1. Basic Module .............................................................................................. 19110.2.2. Accounting Manager .................................................................................. 19110.2.3. Call Manager .............................................................................................. 19310.2.4. Patrol Manager ........................................................................................... 19810.2.5. Facility Manager ......................................................................................... 20010.2.6. Hotel Manager ........................................................................................... 20110.2.7. Access Manager ......................................................................................... 20510.2.8. Directory Distributor ................................................................................. 21110.2.9. Performance Manager ............................................................................... 21210.2.10.Peripheral Facility Manager ....................................................................... 21210.2.11.File Manager .............................................................................................. 21410.2.12.Fault Manager ............................................................................................ 21510.2.13.External Application Interface ................................................................... 216

10.3. MULTI SITE SystemManager ................................................................................. 21610.4. RELATING A ISPBX SERVICE TO AN SSM .......................................................... 21810.5. EXTERNAL MESSAGE WAITING DEVICE ........................................................... 21910.6. CHECKLIST iS3000 - SSM CONNECTION .......................................................... 21910.7. CHECKLIST PER SystemManager MODULE ........................................................ 223

11. SOFTWARE LICENSES ...............................................................................227

11.1. LICENSE STRING .................................................................................................. 233

v

Tab

le o

f Co

vi

Table of C

ontents

11.2. SYSTEM START ......................................................................................................23311.3. INSTALLATION OF THE LICENSE STRING ........................................................233

11.3.1. Installation in iS3000 ...................................................................................23311.3.2. Logical Device Name .................................................................................234

11.4. SOFTWARE ASPECTS ...........................................................................................234

12. COMPUTER TELEPHONY INTEGRATION ...............................................236

12.1. INTRODUCTION ..................................................................................................23612.1.1. Examples of Outbound and Inbound Call Centres .....................................23612.1.2. CSTA Subject .............................................................................................23812.1.3. CSTA Agent ................................................................................................23812.1.4. General Rules .............................................................................................239

12.2. CONFIGURATIONS WITH VARIOUS COMPUTER TYPES ................................24012.2.1. PC LAN Environment ................................................................................24012.2.2. IBM CallPath® Environment ......................................................................24012.2.3. Voice Processing Systems in Call Centre Environment .............................241

12.3. NETWORKING ASPECTS .....................................................................................24212.3.1. iSNet Private Networking ..........................................................................24212.3.2. CSTA Network Topologies .......................................................................24212.3.3. IP Addressing for CSTA ..............................................................................24412.3.4. DPNSS ........................................................................................................246

12.4. FUNCTIONALITY .................................................................................................24712.4.1. General .......................................................................................................24712.4.2. Description of Switching Function Services ...............................................24912.4.3. Call Event Reports ......................................................................................25412.4.4. Agent State Event Reports .........................................................................25512.4.5. Maintenance Event Reports .......................................................................25612.4.6. Feature Event Reports ...............................................................................25612.4.7. Monitoring Command Services ..................................................................257

12.5. APPLICATIONS .....................................................................................................25712.5.1. General Description ...................................................................................25712.5.2. Examples ....................................................................................................258

12.6. HARDWARE CONFIGURATION ASPECTS IN ISPBX .........................................26012.7. IMPLEMENTATION / PROJECTING ....................................................................261

12.7.1. OM Commands for computer-ISPBX Circuits ..........................................26112.7.2. Assigning a CSTA Agent Extension ............................................................262

12.8. CSTA INPUT/OUTPUT SERVICES ........................................................................26212.8.1. Conditions of use for the CSTA I/O services .............................................26312.8.2. Message call initiated by a computer application ........................................26312.8.3. Message call initiated by a terminal ............................................................26412.8.4. Interaction with other facilities ...................................................................264

nten

ts

12.8.5. Input/Output services ................................................................................ 26512.8.6. Call Related Messaging Service .................................................................. 266

12.9. TWINNING ON CSTA .......................................................................................... 26712.10. MULTIPLE RING GROUP ON CSTA ................................................................... 26912.11. UNIQUE LINE NUMBERS FOR CSTA ................................................................. 27012.12. PROVIDE REASON FOR DIVERTED/FALLBACK CALL IN CSTA INTERFACE . 27112.13. CSTA INITIATED DTMF ....................................................................................... 27312.14. BOUNDARIES, OPTIONS AND TIMERS ............................................................. 273

12.14.1.Boundaries ................................................................................................ 27312.14.2.Options ..................................................................................................... 27512.14.3.Timers ....................................................................................................... 27512.14.4.Customized Settings .................................................................................. 275

12.15. LICENSING ............................................................................................................ 27612.16. ALARMS ................................................................................................................. 27712.17. VALIDITY INFORMATION ................................................................................... 277

13. PRIVATE VIRTUAL ENHANCEMENTS .....................................................279

13.1. INTRODUCTION ................................................................................................. 27913.2. SECOND LINE OM COMMANDS ....................................................................... 27913.3. BOUNDARIES AND OPTIONS ............................................................................ 28013.4. Call@Net APPLICATION SERVER - SNMP ALARMING ..................................... 280

A . PROTOCOL FORMAT OF FDCR OVER IP ................................................281

A.1. FDCR OUTPUT FORMAT VERSION 0 ............................................................... 282A.2. FDCR OUTPUT FORMAT VERSION 1 ............................................................... 286A.3. FDCR OUTPUT FORMAT VERSION 2 ............................................................... 289

vii

Tab

le o

f Co

viii

Table of C

ontents

1

Release date : 01/Oct/2010

iS3000 Series (SIP@Net)Facility Implementation Manual

Management Facilities

2

AMENDMENTS

The items that follow are incorporated in the update of this manual from issue 0601 to 0704:



CHAPTER/SECTION DESCRIPTION

6.6.2. "Changing (room) Traffic Class via an Extension (at Reception Desk)"

Added (SIP@Net 4.1).

12.12. "PROVIDE REASON FOR DIVERTED/FALLBACK CALL IN CSTA INTERFACE"



2.7. "SIMPLE ALARMING OVER IP (since Call@Net 2.8)"

Protocol format is added.

3.5.16. "Extra FCDR record for Twinning and Follow-me"



12.13. "CSTA INITIATED DTMF"

Added (SIP@Net 4.3.A).

A . "PROTOCOL FORMAT OF FDCR OVER IP"

Protocol format is added.

3

PREFACE

This manual is valid for SIP@Net (previously known as Call@Net), running on all ISPBX models of the iS3000 Series. All of these systems will further be referred to as "ISPBX".

The information in this manual concerning the SystemManager is based on release 2.4.3. The differences (concerning the implementation) between release 2.4. and the previous release 2.3. are mainly determined by the hardware.

When a SysManager is used in combination with SIP@Net / Call@Net, please consult the SysManager documentation.

LICENSING AGREEMENT

The licensing agreement for an iS3000 determines which facilities are available. It is therefore possible that a facility described here will not work on a particular iS3000, even though it has been correctly configured. Check the relevant license agreement to determine what is available, make sure that the correct license file is loaded and that the licenses have been correctly activated. For more information refer to chapter 11. "SOFTWARE LICENSES".

NOTICE TO THE USER

Unless stated otherwise (in text and figures), the term :

- ALC-G represents the ALC-G, ALC-GP or ALC-G(R).- DTX-I represents the DTX-I or DTX-I(R).- PMC represents the PMC-HR, PMC-MC, PMC-G or PMC-SIC:

- PMC-HR represents the PMC-HR, PMC-G (with NCC-HR) or PMC-SIC (with NCC-HR) .

- PMC-MC represents the PMC-MC, PMC-G (with or without NCC-MC) or PMC-SIC (with or without NCC-MC) .

- DTU-PH represents the DTU-PH or DTU-G.- DTU-PU represents the DTU-PU or DTU-G.- CPU3000 represents the CPU3000 or CPU4000.

For more details of the CPU4000, see the Customer Engineer Manual “How to install the CPU4000 (including upgrade)“.

4

1. INTRODUCTION

As the iS3000 systems are getting bigger and bigger, it becomes crucial to manage them correctly. The system manager should be able to extract data from the system containing whole or part of the current system configuration and performance. If necessary, changes must be made to the configuration to adapt the system to the demands of the customer.

The configuration of the iS3000 system is stored in the memory of the system CPU. This processor also takes care of error handling and measuring of the iS3000 performance. Therefore, it is important for the system manager to be able to communicate with the ISPBX CPU to extract or change the contents of the CPU memory.

Several functions can be used for the management of the ISPBX database. Some of these functions reside inside the ISPBX CPU itself and can be used by the system manager (entering commands from an OM terminal). Other functions require a separate external device which must be connected to the ISPBX.

The system manager can use several tools to get an overview of the ISPBX (configuration and performance). These tools will be discussed in this manual.

Management functions require a management device. The ISPBX hardware to connect a device and the projecting aspects of the device will be discussed in the next section. In the remaining part of this manual the concerning devices will only be mentioned. Boundaries, options or timers can be important for some facilities. When necessary, the parameters of the boundaries, options or timers are mentioned together with an indication of whether it is network (NE) or local (LO) data. More information about these parameters can be found in the Second Line Maintenance Manual.

The boundaries, timer or options are assigned a value during the projecting of the ISPBX unit via the PEuu.POM file. Changing the value of one of these parameters can be done by projecting a new PEuu.POM.

Most of the options and timers can be changed in an operational system using the second line maintenance tool EXSUBC, sometimes activated by a hot start. Boundaries can almost never be changed in an operational system because a change in a boundary results in a new partition of the CPU memory.

For more information, see Facility Implementation Manual (Networking and Routing).

Most management devices are connected via a V.24 interface to the CPU of the ISPBX. The system manager can communicate with the ISPBX CPU using this interface and make necessary changes in the systems database.

5

The way the V.24 connection is made depends on the ISPBX model used.

1.1. CONFIGURATIONS FOR EXTERNAL DEVICES

External devices can be connected to the ISPBX. The way in which the external devices are connected to the ISPBX depends on the processor board used. The following configurations can be distinguished in this context:

• CPU3000 platformThe CPU3000 board is used as CPU in these configurations. The External Devices are directly connected to the CPU3000 board via V.24 interfaces or via an Ethernet interface. The CPU3000 board is used in the iS3010, iS3030 and iS3050 systems and in the S250/1000 systems.

• CCS platformThe CCS board is used as CPU in these configurations. A Backup and Interface Module (BIM) is connected via a CIE board to the CCS to support the connection of External devices. The External Devices are connected to the BIM via V.24 interfaces or via a second Ethernet interface. The CCS board is used in the iS3070 and iS3090 systems.

1.1.1. CPU3000 Platform

• V.24 interfaceSeveral external devices can be connected to the CPU3000 of the iS3000 series and S250/1000. The total number of V.24 interfaces on the VIC3000 is limited to 6 when no Ethernet is available. When the Ethernet connection is used, port 25 is not available anymore, leaving 5 free V.24 interfaces.

The V.24 interfaces are connected directly to the CPU via the daughter board VIC3000. The numbering of the V.24 interfaces of the VIC3000 starts at the top with number 20. The lowest socket of the VIC3000 has no function and has no number.Any application can be assigned to each V.24 port on the VIC3000 board, using the OM commands ASPORT and ASDEVC. The port characteristics of each port can be set (changed) using OM command CHPORT. Once these operations have been performed, a device can be assigned to each port using OM command ASDEVC. The devices are assigned a Logical Device Name (LDN) to identify them in the ISPBX system.

• V.28 interfaceIn addition, there is a V.28 interface for the alarm signalling.

• Solid State Disk

- upper port : V.28 interface providing alarm signals which can be used to trigger external alarm signals.

- port 20 to 25 : V.24 interfaces, free to program by ASPORT and ASDEVC.

6

The CPU3000 board contains two SIMM connectors for two Solid State Disks or Flash disks with a formatted capacity of 15 MBytes. SIMM1 is always present and contains the LBU and DBU devices. SIMM 2 is optional and contains when present the GBU device.The disk devices are assigned to the following CPU3000 ports:

• Ethernet InterfaceThe Ethernet interface is located on the CPU3000 board. It is physically shared with a V.24 interface. The Ethernet interface is only available when port 25 is set out of service (SETOUT) or not existing (SETNIN).

The Ethernet interface can be used as a carrier for the FTP protocol. This makes it possible to up- and download files to and from the LBU/DBU of the CPU3000.Use the OM command DITCPC to retrieve IP-configuration items of the ISPBX.For more details, see OM command STFTPS.

- port 29 : LBU device on SIMM1.- port 30 : DBU device on SIMM1.- port 26 : GBU device on SIMM2.

V.24 connection : SETINS : 11, 18, 25;Ethernet connection : SETOUT or SETNIN : 11, 18, 25;

7

Figure 1-1 CPU ports

005/100/400

CPU3000

External Alarm Signalling

20

21

22

24

25

23

Fixed Position for SMPC

VIC3000

Ethernet Connector

8

Figure 1-2 Layout of CPU3000 / VIC3000 board

Before an external device can be connected to a port, the port must be configured for that device. To avoid a deadlock situation, an exception is made for:

- the local SMPC, fixed on V.24 port 20.- the external V.28 alarm device, fixed on the upper port.

1.1.2. CCS Platform

The CCS platforms have a Backup and Interface Module (BIM) which offers communication ports for devices. The BIM is connected to the Communication Interface External (CIE) board by means of an Ethernet connection.

The maximum number of ports depends on the BIM(s) and on the number of connected

Mark

BP102

BB

BA

Ethernet connector(RJ45)

VIC 3000

BATTERY

FEPROM (LBU)DRAM

PROCESSOR

AM3000

BISTConnector

Port 20

Port 25

not used FAA

FAB

FAC

FAD

FBA

FBB

FBC

FBD

Port 24

Port 23

Port 21

Port 22

Alarms V.28

X12.4 101 103

(fixed for SMPC) S

I

M

M

1

S

I

M

M

2

9

CIE(s).

• V.24 InterfaceA device which is connected to a BIM communications port must be assigned to this port by commands on the BIM as well as by OM commands on the ISPBX. The port number 00 ... 31 of the BIM logically corresponds to the port number of the CIE board.The OM command ASPORT defines the type of protocol for the CIE port: the type of protocol must be set to "logical" for these types of systems. The OM command ASDEVC assigns a Logical Device Name (LDN) with the appropriate equipment type to a port of the CIE. Refer to the OM commands manual for further details concerning these OM commands and refer to the BIM manual for further instructions on port settings of the BIM.

Note: For reliability and performance reasons it is possible to connect more BIMs via extra CIE boards in the system. The maximum number of BIMs depends on the maximum number of CIE boards in the system (BOUND 175).

The BIM has the following port configuration:- port 00 physically connects to COM 1 and is fixed for the OM terminal (character

protocol)- ports 01...05 free to program by ASPORT and ASDEVC- ports 06...25 free to program by ASPORT and ASDEVC, depending on the

configuration of the BIM (i.e. the number of ports available on the BIM)- port 28 is fixed for alarm device- port 29 LBU/DBU device on the BIM- port 30 DBU/LBU device on the BIM- port 31 fixed for the BIM- port 32...41 switch points (S&S of the CIE)- port 42...54 sense points (S&S of the CIE).

• For more port configuration aspects see the BIM Manual. For details on switch and sense points see the Maintenance Manual.

WARNING: DO NOT TAKE PORTS 29, 30 AND 31 OUT OF SERVICE AS THIS DISABLES THE BASIC OPERATION OF THE BIM.

• ExampleA printer is connected to port 10 (of the BIM). This configuration requires the following OM settings:ASPORT:1014,10,10,2;ASDEVC:1014,10,10,PRTR,24;SETINS:1014,10,10;

10

• Ethernet InterfaceA second Ethernet interface card in the BIM offers the Ethernet interface for CSTA application PCs.Use the OM command DITCPC to retrieve IP-configuration items of the ISPBX.

1.1.3. External Devices

The following devices can be connected to the iS3000 series.

• SysManager Maintenance PC (SMPC). The connection can be remote or local. It is possible for one remote SMPC to be connected while a local SMPC is running.

• SystemManager (SSM). The connection can be remote (only if no other remote SMPC is connected) or local.

• Automatic Call Distribution PC (ACD-95-PC).• Full Detail Call Recording PC (FDCR-PC). It is only possible to connect one PC per node.• Integrated Announcement Server-Manager-PC (IAS-Manager-PC). Only one PC per IAS

board can be connected.• Printer. Several printers can be connected.• Alarm unit. Only one can be connected. In case of CPU3000 configuration, there is one

fixed connection for an external device (V.28). In case of CCS configuration, there is one connection allocated to the Alarm Box, via the CIE.

• CSTA application PCs.

1.2. MANAGEMENT DEVICES

This section deals with the projecting aspects for the devices that can be used for the different management functions. Most devices are assigned a logical device name to be identified in the ISPBX system. This logical device name is a string of maximum 6 characters. The maximum number of logical device names in a ISPBX system is limited by NEBOUND 097 (max number of devices in system).

Management devices are assigned using OM commands as listed below (for more information, see OM Commands Manual):

11

The table below gives a list of management devices together with the Logical Device Names and Device, Equipment type and Protocol type that are assigned with the OM commands listed above.

- ASPORT : Used to specify the type of protocol used in the device communication (parameter PROT-TYPE) and to specify whether it is a local or remote device (parameter CONNECTION-TYPE), for non logical protocols.

- CHPORT : Used to specify the communication speed used on the port (parameter BAUDRATE). This command is only used for CPU3000 systems and the character protocol. It is not valid for logical protocols (ports 26, 29 and 30). The default baudrate for the character protocol is 1200 baud. The BCS protocol makes use of automatic baudrate detection and uses 1200 baud as initial baudrate. Changing baudrate can only be done when the port is not INS.For CCS systems CHPORT can not be used. The communication speed has to be configured in the BIM.

- ASDEVC : Used to specify the logical device name (parameter LDN) and the type of device (parameter EQUIPMENT-TYPE).

12

DEVICE APPLICATION LDN EQUIPMENT TYPE

PROTOCOL TYPE

OM terminal (for CCS)

keyboard VDUxx0 20 2

display VDUxx1 21 2

SMPC *) (first-local)

keyboard VDUuu0 *) 20 1/2

display VDUuu1 *) 21 1/2

disk emulator PCuu *) 26 1/2

alarm signaller ALRMuu *) 27 1/2

Second SMPC (e.g. at a remote location)

keyboard VDUxx0 **) 20 1/2

display VDUxx1 **) 21 1/2

disk emulator RBUuu **) 26 1/2

remote alarming (not for CCS)

REMALM 27 1/2

SIMM1 (CPU3000 only)

local back-up LBUuu *) 7 2

dual back-up DBUuu *) 7 2

SIMM2 (CPU3000 only)

general back-up GBUuu **) 7 2

Call Manager Management Information System (MIS)

OM keyboard VDUxx0 16 0/2

OM display VDUxx1 17 0/2

event port ACDxxy 11 0/2

Printer printer/toll ticketing PRTR 24 0/2

13

Table 1-1 Assignment of Management Devices

1.2.1. SysManager Maintenance PC - CPU3000 Platform

The Maintenance PC used at CPU3000 platforms is the SysManager 410 Maintenance PC

SSM Switching services TMSyyy 29 1/2

Toll Ticketing TOL1 5 1/2

FDCR FDCR 25 1/2

Traffic Measurement TRAF 24 1/2

OM 1 keyboard VDUxx0 **) 20 1/2

OM 1 display VDUxx1 **) 21 1/2

OM 2 keyboard VDUyy0 **) 22 1/2

OM 2 display VDUyy1 **) 23 1/2

OM keyboard (DND No log)

VDUzz0 **) 14 1/2

OM display (DND No log)

VDUzz1 **) 15 1/2

Alarming (remote) REMAL(M/2) 27 1/2

Disk emulator PCxxDSKxx ***)

26 1/2

FDCR ASCII file e.g. FDCR 25 0 or 1/2

binary format (CCS) e.g. FDCR 32 2

binary format (CPU3000)

e.g. FDCR 24 0

Alarm Unit (CPU3000 only)

ALUNuu **) 28 1

BIM Fixed Alarming FXALxx 13 1/2

*) = not to be assigned; it is fixed by the system.

**) = free to choose, but VDU and ALUN are fixed.

***) = in combination with OM command ZIPFIL (see SysManager 410 Manual, version 4.5 and upwards).

DEVICE APPLICATION LDN EQUIPMENT TYPE

PROTOCOL TYPE

14

(SMPC). It is connected via a modem bypass cable to the first V.24 interface (port/circuit number 20) on the VIC3000 daughter board and via an Ethernet connection. It is possible to connect a second SMPC to one of the remaining V.24 interfaces. Each application in the SMPC is identified by a unique Logical Device Name (LDN).

The SMPC is a management device for displaying or changing the system configuration.

The SMPC communicates with the CPU3000 using a COM port and an Ethernet interface on the PC. The COM port can be for a single channel or a number of channels (when the BCS protocol is employed). With the BCS protocol it is possible to have up to four logical channels open to the ISPBX, on one physical COM port.

The four channels are used by the following SMPC applications:

- keyboard;- display;- disk emulator;- alarming.

The Ethernet connection is used for the following applications:

- BOOTP;- TFTP;- FTP;- Printf.

The SMPC comprises the following basic functions:

- Operational Maintenance (OM) using coded MML,- Load new software packages (CPU, PMC or PCT packages),- Load and retrieve project data files (MIS-file as well as PE and LL files),- Disk Emulation,- Alarming: observe the state of major, minor and circuit blocked alarms. The alarm states

are updated autonomously.- Authorisation (only remote),- Remote alarming.

The first SMPC is connected to port or circuit 20 on the VIC3000 daughter board of the CPU3000. The SMPC communicates with a speed of up to 57600 baud with the CPU3000. The SMPC is multi-tasking. The OM interface uses 'coded MML', which means that the output is formatted not as readable text but as codes to be interpreted by an application program such as SMPC, ACD or SSM.

15

The OM session is opened by ^K (CTRL-K) and closed by ^D (CTRL-D). The SMPC user enters characters on the SMPC. The SMPC detects the end of a command line when a semicolon is entered and sends the command to the CPU. The CPU interprets the command and the related parameters.

Because there is no log-on password session on a SMPC, the execution of commands from such a terminal must be restricted. The authority classes, passwords and restriction levels (terminal type 0) are used for the system security. For more information, refer to chapter 6. "SECURITY MANAGEMENT".

Each SMPC that becomes active in a System uses 10 Long Data Blocks in the CPU. Each OM command executed by the CPU also uses 10 Long Data Blocks. The remaining number of long data blocks can be displayed on the SMPC with the second line maintenance command DIPOOL.

Batch jobs and toll ticketing records also use long data blocks. Each executed batch uses 10 long data blocks and each call submitted to toll ticketing (1 record) uses 1 long data block. If the remaining number of long data blocks is insufficient, a new task can be rejected. By default, there are 200 long data blocks available.

The guidance and parameters of the OM commands are stored in a separate MML version database on the SMPC. The MML files used to load this database are available on a separate diskette. Multiple MML files (up to 32) supporting more than one ISPBX release can be stored in the database.

For detailed information see the SMPC User Guide.

Table 1-2 Control Characters

CONTROL CHARACTER OUTPUT LINE INDICATING

^V a header line

^A a request for additonal information

^Y an error number

^U an informatory message

^C a 'congestion' message

^R a 'rejected' message

^X an 'executed' message

^N a MAIL message

^P a 'ready' indication

16

1.2.2. OM Terminal - CCS Platform

The default situation in systems on the CCS platform is a VT510 OM terminal connected to the BIM port 0 (= COM1). Other supported terminals are the VT420PC, VT320, P2776 or CIT224 terminal. A system alarm status line is available, but only on the first OM terminal.

1.2.3. Backup Devices

The CPU3000 and the CCS platform have the following three backup devices:

The CPU3000 supports also a fourth backup device namely the General BackUp (GBU) device. The GBU resides on SIMM2. SIMM2 is optional and is intended for general use.

1.2.4. Maintenance Mode - CPU3000 Platform only

The CPU3000 can be upgraded using the software and configuration files stored on the LBU. The CPU3000 supports also a specific upgrade concept that is called Maintenance Mode. This section introduces the LBU and DBU aspects of Maintenance Mode.

• Maintenance ModeThe basic principle of Maintenance Mode is the separation of the "new" software and configuration files on the DBU from the "original" software and configuration files on the LBU. In Maintenance Mode, the system uses the software and configuration files on the DBU. This gives the CPU3000 platform the possibility to fallback to its original configuration on the LBU when something goes wrong during the upgrade using the files on the DBU.Before Maintenance Mode is entered the new CPU software, the new firmware and the original or new configuration files has to be copied to the DBU. During Maintenance Mode Operational Maintenance can be performed. Once the new configuration is properly installed, it can be made definitive by stopping Maintenance Mode.

• OM commandsOM command STMAIN is used to enter Maintenance Mode. From then, all OM activity is performed using the files on the DBU. OM commands STMAIN, STLOAD, STPROJ, STCOLD and STWARM activate or restart an upgrade guarding timer. When the upgrade guarding timer expires, the system falls back to the original configuration even when the communication between the CPU3000 and the SMPC is lost.

- LBU : the Local BackUp device which is always required on each unit.- CBU : the Central BackUp device which is required in only one unit of multi unit

configurations. In single unit configurations the CBU and the LBU are the same.- DBU : the Dual BackUp device is required in case the CCS system runs in dual mode, or

the CPU3000 system runs in maintenance mode.

17

After the new software has successfully been installed, the new configuration is made definitive by means of OM command SPMAIN. The DBU and the LBU devices are swapped. The software and configuration files on the LBU are now regarded as original. Delete the configuration files on the DBU, delete the updated files on the DBU and move all other files from the DBU to the LBU.

1.2.5. Dual Mode - CCS Platform only

• Dual ModeA CCS system can be split in two separate units called clusters. Each cluster comprises two of the four CCS boards. It is possible to use one cluster as the 'operational' cluster to run the system and the other one, the 'stand-by' cluster, for upgrading purposes. This is called Dual Mode.In Dual Mode, the operational cluster uses the LBU and the stand-by cluster uses the DBU. In this case the new software and projecting files can be loaded into the CCS boards which are standby. Switching over takes as long as an operational start. After switching over, the other CCS boards are standby. When stopping the Dual Mode, these CCS boards are synchronised with the operational CCS boards.With Dual Mode, the system down time during upgrade is considerably reduced.NETIMER203 'Dual mode cluster guard time' guards the communication between the two clusters during Dual Mode.

• OM commandsOM command STDUAL is used to split one cluster of four synchronous CCSs into two clusters of two synchronous CCSs. The first cluster remains operational. The OM command automatically restarts the second cluster which becomes standby.

WARNING: AFTER THE SPLIT, THERE IS NO REDUNDANCY IN THE OPERATIONAL CPU SECTION. IF A CCS BOARD FAILS IN THE OPERATIONAL CLUSTER, THE SYSTEM GOES DOWN.

After the split, the DBU is no longer available for the operational cluster of CCS boards.After the software has been loaded on the DBU, the standby cluster can be made operational by means of OM command SWDUAL. With this command the operational cluster becomes standby and the standby cluster becomes operational. The system performs an operational start which interrupts the call processing. NETIMER 204 'Dual mode operational start time' guards the signal sending before an operational start can be done during Dual Mode.To go back to the 4,2 mode (all four slices synchronous operational), execute OM command SPDUAL on the operational cluster. Executing OM command SPDUAL does not influence call processing.

18

1.2.6. Disk Emulator

The Disk Emulator is a software program running on the SMPC and SSM. The Disk Emulator enables the CPU3000 and CCS platforms to access files on the SMPC and SSM. These files are located in the common or specific directory on the hard disk of the SMPC and SSM. For the CPU3000 and CCS platform, the Disk Emulator behaves exactly like the other backup devices as LBU and DBU. The Disk Emulator is addressed by its Logical Device Name, for instance SMPC. Files can be copied from the SMPC to the LBU and vice versa using the File management command CPYFIL.

The iS3000 files have a proprietary format. ASCII files on the SMPC or SSM have to be converted to or from iS3000 format using the iS3000 File Converter. The iS3000 file system support file versions. A V1 at the end of the filename expresses file version 1, a V2 expresses file version 2, etc.

1.2.7. SystemManager

The SystemManager is a telephone management system available in two types. One type operates under UNIX on a mini computer, the other type operates under ConcurrentTMPC-DOS on a PC. The UNIX version and the ConcurrentTMPC-DOS version can be connected to the BIM of iS3000 with CCS or to the CPU of all CPU3000 systems.

ConcurrentTMis a trademark of Digital Research Inc.

The management software establishes a protocol between the CPU and the computer. Via this link several facilities can be transferred between the ISPBX CPU and the computer. Toll ticketing, ISPBX facilities and performance management are examples of the functionality the SystemManager can offer.

The SystemManager acts towards the ISPBX as a number of different devices. Each of these devices is identified in the ISPBX system by a logical device name (max. 6 characters). For the different devices/functions that are located in the management system each device/function is assigned a specific logical channel and this channel is assigned its own logical device name. However the functions for all devices are transferred over the same physical link. The special protocol takes care that several logical channels are available in the same physical link.

The way the SystemManager is connected depends on the ISPBX type:

- Connection to a iS3000 with CCS.The PC-version SSM is connected by a modem bypass cable to the BIM.The UNIX-version SSM is connected by a special cable to the BIM.The default communication speed between the SSM and the BIM is 9600 Baud (local

19

connection) and 2400 Baud (remote connection).Refer to the BIM manual for details about the cables.

- Connection to all other ISPBXs.There are two ways of connecting the SSM to the CPU:- If only the Accounting Manager is used, the connection can be made to the printer

output of the CPU board. This CPU port is then adapted for local toll ticketing output and switched on by OM command STRTTT (start toll ticketing). The default baud rate is determined by PG2.

- If other management modules of the SSM are used, as well as the Accounting Manager, the connection is made to a CPU port which has been assigned to the SSM, either local or remote. The default Baud rates are 9600 (local connection) and 2400 (remote connection).

The first type of connection should be used in heavily loaded SSM configurations where it is necessary to use a dedicated toll ticketing line for call accounting. Apart from this rare occasion, the first type of connection has no specific advantages over the second. It is generally recommended to use the second technique.

1.2.8. Printer

The printer can be used as an output device on request by the system manager (to copy a file to the printer) or by the ISPBX CPU autonomously (output device for toll ticketing or performance management).

The printer is identified in the ISPBX system with a logical device name (max 6 characters). The name PRTRxx is often used for the device name but other names are also allowed.

The system manager cannot use the printer to ask its directories or retrieve files from it.

1.2.9. Remote Maintenance Device

The CPU can control a dial-up modem using a V.24 interface. The analogue side of the modem is connected to the PSTN network and is identified within that network by its subscriber number. By dialling this subscriber number, an engineer can gain access to the ISPBX using a modem-modem connection.

When the CPU can analyse the incoming protocol correctly, the maintenance engineer can send OM commands via this data connection. The ISPBX sends the screen information back to the remote engineer workstation via the data connection. This is called Remote Maintenance.

The CPU can also initiate a dial request in the modem using Hayes commands. A pre-defined PSTN number can then be dialled. In case of alarm, the alarm can be delivered to a remote

20

alarm logging device.

Because of the growing importance of remote maintenance a special chapter Remote Maintenance is available in this manual.

1.2.10. Operator Desks

An operator desk can also be used for management actions.

• SUPERVISOR 20The SUPERVISOR 20 is an analogue operator desk that is connected to an OIU (iS3070/3090 only) or AOC circuit. The operator desk is identified within the ISPBX system with a DNR. After pressing the AM-button the operator enters the OM mode and operator desk commands can be entered. System security is ensured by means of restriction levels for the operator desk without a key (terminal type 1) or the operator desk with a key inserted (terminal type 2).

• SuperVisor model 25The SuperVisor model 25 is an analogue/digital operator desk that can be connected to an OIU (iS3070/3090 only), an AOC, a DTX-I or a DLC-U or DOC in combination with a PNT1. The operator desk is identified within the ISPBX system with a DNR. The operator enters the OM mode by selecting 'AM' menu option; operator desk commands can be entered. System security is ensured by means of restriction levels for the operator desk without a key (terminal type 1) or the operator desk with a key inserted (terminal type 2).

• SUPERVISOR 30The SUPERVISOR 30 is a digital operator desk. This operator desk is connected to a DOC or via a twisted pair cable to a DLC-circuit. Refer to Facility Implementation Manual; Networking and Routing for the projecting of the operator desk. The operator desk is identified within the ISPBX system with a DNR. After entering the applicable screen the operator enters the OM mode and operator desk commands can be entered. System security is ensured by a key.

• SuperVisor model 35The SuperVisor model 35 is a digital desk that can be connected to a DTX-I or a DLC-U or DOC in combination with a PNT1. The operator desk is identified within the ISPBX system with a DNR. After pressing the AM-button the operator enters the OM mode and operator desk commands can be entered. System security is ensured by means of restriction levels for the operator desk without a key (terminal type 1) or the operator desk with a key inserted (terminal type 2).

• SUPERVISOR 50The SUPERVISOR 50 is a personal computer with the SUPERVISOR 50 software running. The computer is connected by a special cable to an OIU (iS3070/3090 only) or AOC circuit (via the voice box). A normal OM terminal has to be projected to the CPU circuits.The operator desk is identified within the ISPBX system with a DNR.

21

The Operational Maintenance functions can be used to transfer operator desk commands via the normal operator link (to the OIU/AOC). The operator can use the normal operator desk commands or menu driven commands. The menu commands are analysed and transferred to the ISPBX as operator desk commands. System security is ensured by means of restriction levels. The operator desk acts the same as a SUPERVISOR 20 with a key inserted (terminal type 2).The computer, in Host Setting mode, can be used as a normal OM terminal, using the second interface (the serial interface to the CPU board).When an operator position is in the OM mode and operator desk commands are being entered, such an operator position uses long data blocks.

• SuperVisor model 55The SuperVisor model 55 is an operator desk rather similar to the SUPERVISOR 50; a PC with hard disk, floppy disk drive, parallel port and COM1 & COM2 ports. (Unlike the SUPERVISOR 50E no multi-port card is used). It offers ISDN functions such as display of the Calling Line Identity (CLI).The SuperVisor model 55 communicates with the exchange (via a DTX-I board or DLC-U/PNT1 combination) using a "data only" PConnect card. This card provides the interface between the exchange and the PC. The SuperVisor model 55 connects to the S0 bus via this card. The card has two functions:- Communication of call status information between the PABX and the SuperVisor

model 55.- Directory distribution using the COM emulation mode. In this mode it emulates

COM1 of the PC and no additional LAM is needed.A SOPHO-SET P271 enhanced with voice box mode provides the voice channel during the day. In night mode, the SOPHO-SET P271 can be used to make normal telephone calls.

1.3. DATE AND TIME MANAGEMENT

The ISPBX date and time can be set using OM command SEDATI.

If the date does not match the Gregorian calender the command is aborted and the date and time are not changed. The CPU3000 system has a real time clock. When this system becomes operational, the correct date and time are already set.

Note: The date and time on feature phones are updated automatically every 24 hours and after the execution of SEDATI.

Synchronise to ISDN Date/Time (since Call@Net 2.9)

ISDN date/time synchronisation (IDTS) adjusts the date and time of the ISPBX to the time provided by PSTN service provider via ISDN trunks. The functionality allows automatic switch

22

over to daylight-savings-time.

IDTS functionality provides date and time information to operator consoles and feature phones, like ErgoLines and the latest DECT handsets.

Note: iS3000 date/time will be synchronised to ISDN date/time when the ISDN is compliant with ETSI EN 300 403-1, and only when the date-and-time provided by the ISDN includes minutes or minutes-and-seconds.Synchronisation for calls from the ISDN can only occur when the ISDN provides the optional date-and-time element in the incoming SETUP message.Synchronisation for calls to the ISDN can only occur when the ISDN provides the optional date-and-time element in the CONNECT message, and when in the DTX-I/DTU-PH signalling group, the auto-connect option is OFF.

iS3000 date/time is synchronised to the ISDN date/time indicated by the first incoming or outgoing ISDN trunk call at regular intervals of 15 minutes if the time difference is 10 seconds or more (assuming that the PSTN sends the seconds in the ISDN date/time information element).

When seconds are not sent by the PSTN, synchronisation is done only when :

- the local time is greater than ISDN date/time by 70 seconds, or- the ISDN date/time is greater than local time by 10 seconds.

The synchronisation is done by assuming the value of 30 seconds when seconds are not sent by PSTN.

To implement this IDTS functionality, NESYSOP 132 (Synchronise to ISDN date/time) must be TRUE and bundle option 'ISDN date/time synchronisation' in the OM command CHBNDC must be set. By default this bundle option is YES, because when ISDN date/time synchronisation is active, it is logical to let all the ISDN trunks available in the system contribute to the synchronisation mechanism. Only when a bundle connects to a PSTN, which is situated in a different time zone, this bundle should be excluded from the ISDN date/time synchronisation by setting the general bundle option to NO.

In case one of the units (in a multi unit network) is down or not reachable, the unit(s) will not switch over to the changed time at the moment of synchronisation. Date/time are updated later on due to regular 24 hour date/time synchronisation.

Note that date/time is not distributed in a DPNSS/QSIG network.

IDTS versus OM command SEDATI

23

When IDTS functionality is active, there are two (independent) sources from which the iS3000 date/time can be set :

- date/time can be synchronised to ISDN date/time without executing OM command SEDATI first : 'Monday' will be regarded as first 'day-of-the-week' (digit '1').

- when date/time is set, it can be changed either due to an ISDN date/time update or by means of executing OM command SEDATI.

System requirements

When upgrading from Call@Net <2.5, RCONV should be used.

The following DTU-PH / DTX-I firmware packages are required :

- DTU-PH : 140.31.01- DTX-I : 203.13.01

24

2. FAULT MANAGEMENT

A complete ISPBX system can consist of several units with a large number of internal extensions and a large number of trunk and tie lines. Such a system is very complex and holds a lot of hardware and software. To be able to manage all the hardware and software the ISPBX software is continuously testing all the hardware and software related to one ISPBX unit and reports only when failures are detected. The part of the ISPBX software that takes care of this fault management is called System ASsurance (SAS).

2.1. ISPBX SOFTWARE STRUCTURE

A ISPBX exchange is controlled by microprocessors and the related software. In the ISPBX unit, a number of software programs are available for different purposes. The software is built in a layered structure. This is illustrated in the figure below:

Figure 2-1 Software Parts in and between iS3000 Unit(s)

The PPU/PMC software is the part where the time critical operations related to the circuits are performed. Events coming from the circuits in the related PM are signalled by the PPU to the CPU. The CPU software relates these events to the status of the circuit and tells the PPU what to do to effect the status-change of the circuit. The PPU releases the CPU of all time-critical functions like scanning for status-changes of circuits.

The PPU and the CPU software communicate using IMP messages.

This link is bi-directional and messages from the PPU to the CPU (event changes of a circuit) are transferred in the opposite direction.

CP POM SAS

GOS

LOS

PPU

CIRCUIT

CP

Inter-Unit

POM SAS

GOSCPU SOFTWARE

LOS

PPU

CIRCUIT DEVICES

25

The CPU software controls the PPU. This CPU software is built in several layers, each layer performing separate functions.

2.1.1. Operating System

The lowest layer in the CPU software is the Local Operating System (LOS). This layer takes care of the user friendly interface to the external environment of the CPU. By 'user' is meant the higher layers of the CPU software.

First of all this layer takes care of the memory (RAM) management of the ISPBX CPU. Whenever the application software requests or wants to store information, it calls upon the LOS to perform the necessary memory actions. It also performs the timing functions and interrupts for the application software.

The LOS also takes care of transferring information between the CPU software and devices / PPU circuits / other ISPBX units / BIM / SMPC etc.

The next highest layer in the CPU software is the Global Operating System (GOS). This layer is the controlling part of the LOS. This layer takes care of routing the CPU messages to the correct destination.

The operating system (LOS and GOS) forms the basic building block for the real CPU applications.

2.1.2. Application Software

The application software is the part of the CPU software that takes care of the actual data processing. There are three application programs that run simultaneously.

- Call Processing (CP) is the most important application in the ISPBX. Call processing is the software program that takes care of the call set-up and clearing. This implies that a circuit that is used by the call processing software must be 'in service'.

- Project engineering and Operational Maintenance (POM). A system manager can use an OM device to make changes in the ISPBX database. The OM commands that are entered are checked for correct syntax and validity of the parameter values before making the requested changes in the ISPBX database. All operations related to these functions are performed in the software program Project engineering and Operational Maintenance (POM).

- System Assurance (SAS) is the third application program. It tests all hardware in the ISPBX unit and if failures are encountered that cannot be solved by SAS, an alarm report is generated to make the maintenance engineer notice the malfunctioning part.

26

2.2. SYSTEM ASSURANCE

All resources in the ISPBX unit are automatically tested in the Periodic Autonomous Test (PAT) for preventive testing.

The resources can also be tested on request of the system manager by means of an OM command. This test is called the MAnually controlled Test (MAT) and is used when exchanging a resource or when a resource is suspected to be faulty. In these tests other resources may be used to test a specific resource type. During the tests and also during normal operation of the ISPBX unit a number of sensors are used to detect problems in the operation of the unit.

Non-hardware related aspects are also guarded. These aspects are not tested but the sensors automatically detect a problem. This can mean that:

- Protocol failures are automatically sent to SAS;- SAS receives the alarms in other ISPBX units via inter-unit links;- The execution of a part of the CPU software is not possible.

The software program that guards the correct operation of the ISPBX unit is called System Assurance (SAS) and is also an application program in the CPU software. SAS registers which resources are to be tested, which additional resources must be included in the test and what the result of the test is.

A number of sensors are available in the CPU software. If a sensor detects a problem (during a test or autonomously) SAS is informed. It can then decide to further test specific resources, generate a report, generate an alarm or even perform a warm or cold start of the ISPBX unit.

Only when a resource is not being used, can it be tested by SAS, so SAS cannot release a call to test a certain resource.

When a circuit is in the 'in service' (INS) condition and has no owner, system assurance can claim the resource for test purposes. In this case a reduced test is performed to make sure the circuit is available for call processing as soon as possible. If system assurance detects a fault during the test, it denotes all resources involved in the test as suspicious. At a later stage further extensive testing is performed to locate the faulty resource to the lowest possible functional entity in the resource hierarchy. From then. SAS can change the service condition to the autonomously blocked condition (ABL) and the circuit cannot be used for call processing any more.

When a circuit is in the 'autonomously blocked' condition (ABL) system assurance claims the resource for test purposes. This situation can only be reached if an earlier test proved that the resource was faulty: SAS took the resource out of service. If the new test(s) prove that the

27

circuit is functioning correctly, the system changes the circuit condition back to the INS status and the resource is again available for call processing; this process is called recovery.

If the circuit is in the service condition 'out of service' (OUT) the test is performed more intensively. The circuit remains in the circuit condition OUT but a fault report can be generated.

In the service condition 'not installed' (NIN), the circuit cannot be accessed for testing any more.

Fault handling by SAS involves:

- Detecting the fault. During a test a failure is observed.- Locating the fault. Testing the separate resources involved in the failed test indicates which

resource is faulty. Most of the time faulty resources can be pinpointed to board and circuit number.

- Resetting the activities affected by the fault. If the faulty resource is involved in another process, all activities related to that process are cancelled.

- Isolating the fault. If the faulty resource is available for call processing, system assurance activates the operating system and the service condition of the resource is changed into a blocked situation. The faulty resource cannot be used by call processing any more. The faulty resource can be accessed by POM or SAS.If the faulty resource is the controlling part for other resources, these resources cannot be used any more.

- Reporting the fault. Depending on the type of fault, resource type and the number of occurrences of the fault, an alarm report is generated. This alarm report indicates:- Error code (functional group of faults),- Resource type,- External Hardware Address (EHWA) of the resource (if applicable),- Number of occurrences of the fault,- Date and time of the fault,- Qualifier (type of fault within this error code),- Additional information (two parameters).The error codes and qualifiers are listed in the Maintenance Manual. Using the error code, qualifier and the two additional information parameters, the (possible) cause of the alarm and the possible repair procedure can be found.

- Attempting recovery of the faulty resource. After isolating the faulty resource, the resource is re-initialised and re-tested. If this attempt is successful, the resource is returned to service, a report is generated and in some cases the alarm can be removed. If the re-attempt is unsuccessful, the resource remains in isolation.

Depending on the type of problem, the ISPBX may generate an audible and/or visible alarm.

28

This alarm can be routed to the operator positions and/or to the alarm box/Alarm Unit on the MDF or to a remote alarm signalling device or to the SMPC or to a V.28 connector. It is also possible to suppress the alarms.

If the occurred problem is severe enough, SAS can even force a hot, warm or cold start of the ISPBX unit.

In this chapter the facilities provided by System Assurance are discussed in more detail.

2.3. SAS REPORTS

A part of the ISPBX CPU memory is reserved for storing the reports that are generated by SAS when a problem is encountered or suspected. These reports can be read and analysed by the maintenance engineer. Depending on the type of problem the maintenance engineer can act accordingly and solve the problem.

If problems occur, two modules of system assurance are accessed for reporting the problem.

If an SAS test indicates that a hardware part did not function properly, SAS activates a special reporting module. This module is called the Resource Type Data Manager (RTDM). This module generates a report containing the alarm code, the type of alarm (qualifier), the resource type and the EHWA of the hardware that caused the problem and if necessary more additional information. A list of all resource types can be found in the Second Line Maintenance Manual.

Depending on the type of test problem the report is stored in a buffer in a specific queue in the ISPBX CPU memory.

In some situations problems arise which are not related to hardware parts. Other CPU software parts in the ISPBX unit inform SAS about a certain problem. This can be for instance, a software problem, an alarm in another unit in the network or a signal offered to one of the sensor points of the CIE. In these circumstances SAS accesses the Alarm Code Data Manager (ACDM) module for the generation of the report. This module generates a report containing the alarm code, the type of alarm (qualifier), the event that caused the problem and if necessary more additional information. A list of all alarm codes can be found in the Second Line Maintenance Manual.

Depending on the type of test problem the report is stored in a buffer in a specific queue in the ISPBX CPU memory.

Three categories of reports can be distinguished:

1. Reports that have not yet led to alarm signalling. These reports indicate potential problems

29

in the system. The information of those reports is meant for SAS internally, to support the fault location function.

2. Reports that have led to alarm signalling. These reports indicate a problem in a ISPBX unit that requires the attention of a maintenance engineer. For these reports the following distinction can be made:- Active alarm report. An active alarm report contains information about an erroneous

situation in the system; for instance a resource is isolated.- Alarm event of interest. An alarm event of interest contains information about a

significant event that has occurred in the ISPBX unit that does not have a direct relation to an erroneous situation; for instance operational restart done.

These type of alarm reports can also lead to alarm signalling: major, minor, silent or blocked alarm.

3. Reports indicating problems that appear to be solved. When an alarm condition is cleared, either due to corrective actions performed by the maintenance engineer or autonomously by SAS, the contents of the database is adjusted to reflect the new situation. The concerned (active) alarm reports will not be discarded but noted in this type of report. These reports are used to describe the history of the error status of the unit.

In the ISPBX database 19 different queues of buffers (history buffers) are available. The contents of these history buffers can be read with the OM command DIHIBU. The reports in these buffers cannot be deleted but a report can be shifted from one queue to another as a result of an SAS test. In Table 2-1 "History Buffers for System Assurance" the queues with the reference to the read command DIHIBU and the alarm category are indicated.

30

HISTORY BUFFER

DIHIBU NUMBER

DESCRIPTION REPORT CATEGORY

0 0 suspicion report with zero value

3

1 1 successor failed report with zero value

3

2 2 cancelled event of interest report

3

3 3 suspicion level exceeded report

3

4 4 expired alarm integration report

3

5 5 expired isolation integration report

3

6 6 solved alarm report 3

7 7 passive alarm report 3

8 8 suspicion report with non-zero value

1

9 9 alarm integration report 1

10 10 successor failed report with non-zero value

1

11 11 blocked alarm report 2

12 12 manually controlled test report

2

13 13 silent alarm report 2

14 silent alarm limited by amount report

2

15 silent alarm limited by time report

2

16 14 minor alarm report 2

17 15 major alarm report 2

99 99 project engineering alarm report

1

31

Table 2-1 History Buffers for System Assurance

2.4. ERROR CODE RELATED ITEMS

A list with alarm codes is included in the Maintenance Manual. Using the error code and the additional information the maintenance engineer can trace a problem and the solution to the problem.

For system assurance, each error code specifies the action to be taken by SAS to locate and signal an erroneous situation. Therefore some additional items are directly linked to the error code. These items are included in the Maintenance Manual and will be discussed in more detail in this part.

2.4.1. Alarming

This item specifies when to alarm a certain problem. The alarm signalling can be:

- Immediate (IMM). As soon as the problem arises, the related alarm is generated.- Time integrated (dN/dt). If a fault or event is detected in the system a number of times

within a certain period, it is alarmed. The alarm threshold occurrences and alarm threshold time are included in the Alarm Code Data Manager (non-resource event) or in the Resource Type Data Manager (resource faults).

2.4.2. Isolation

This item specifies when a faulty resource is isolated so that it cannot be used by call processing any more:

- Never (N). If a resource is found faulty, it is not isolated: call processing can still use it.- Immediate (IMM). If a resource is found faulty, it is isolated immediately and call processing

cannot use the resource any more.- Time integrated (dN/dt). Only if a resource is found faulty a number of times within a

certain period, it is isolated. The isolation threshold occurrences and isolation threshold time are included in the Resource Type Data Manager (resource faults).

Note: Isolation always leads to alarm signalling.

2.4.3. Recovery

When a faulty resource is isolated system assurance will try to correct the problem and make the resource available for call processing again. This recovery can be:

- Never (N). If a resource is isolated, SAS will not try to recover the faulty resource. The

32

maintenance engineer must correct the problem.- Immediate (IMM). When a resource is isolated, SAS will immediately try to recover the

faulty resource. Because the alarm signalling is always delayed, it is possible that NO alarm will be generated if the recovery was successfully recovered immediately.

- Postponed. If a resource is isolated, SAS will try to recover the resource after a certain delay. This delay time is resource type independent and can be projected by the timer NETIMER 130 (SAS postponed recovery time).

To guard against 'oscillation' of faulty resources, SAS will stop further recovery on resources when a fault occurs again within a short time after its recovery. The time period between recovery and making the resource available for call processing is defined with the 'timer' NEBOUND 136 (SAS resource probation interval). If the fault did not occur again within this period, the resource is made available for call processing.

2.4.4. Report Type

A report in one of the history buffers can be:

- Active alarm report (AAR). The alarm is cleared when the normal behaviour of the system part is restored (repaired, replaced, or service condition OUT).

- Event of interest report (EOIR). The alarm is reset by reading out the alarm and then clearing it with the OM command CLALRM.

2.5. ALARM SIGNALLING

Each resource type (part of the ISPBX hardware) or alarm code (informative event) is related to one of the alarm types Major, Minor, Blocked, Silent, Silent limited by amount or Silent limited by time. When a problem arises with a resource or alarm code, the related alarm type determines in which history buffer the report is noted and possibly which type of alarm is generated.

When the module Resource Type Data Manager (RTDM) or Alarm Code Data Manager (ACDM) generates a report, the SAS Alarm Handler is informed about the problem and the report is stored in one of the history buffers.

If the report enters one of the history buffers with report category 2, the alarm handler signals the related alarm by an LED or a buzzer alarm. The alarm signalling is delayed; there is a time interval between the time the report is noted in the history buffer with report type 2 and the moment the alarm is signalled. When the maintenance engineer has corrected the problem, the report is moved to one of the history buffers with report category 3.

In other less important situations (the report is stored in a history buffer with report category

33

1) the alarm is not generated but the alarm handler guards the alarm to see if the problem appears again or if the problem disappears. If the problem arises a number of times, SAS Alarm Handler moves the report to one of the history buffers with report category 2 and generates the alarm. If the problem disappears the report is moved to one of the history buffers with report category 3.

2.5.1. Major Alarm

When an essential resource fails, the operation of the ISPBX unit or system can be heavily affected. A major alarm is generated to indicate the fault requires immediate action. When a major alarm is generated this is signalled at a V.28 connector, on the local SMPC (if connected), the first OM terminal on the BIM, operator desk and/or on the alarm box/Alarm Unit (MDF) or on the remote maintenance system. It is also possible to suppress alarms.

The alarm report related to the resource that caused the major alarm can be read out on an OM terminal (local or remote) with the OM command DIMAJA.

From the operator desk it is also possible to read out the alarm information with operator desk command 6020. For the execution of this command: see OM Commands Manual (Operator Desk).

2.5.2. Minor Alarm

Resource failures less important than the major alarms may result in a minor alarm. This type of alarm still requires actions to be taken to solve the alarm. A minor alarm is also signalled at a V.28 connector, the first OM terminal on the BIM, on the local SMPC (if connected), on the operator desk and/or on the alarm box/Alarm Unit (MDF) or on the remote maintenance system. It is also possible to suppress alarms.

The alarm report related to the resource that caused the minor alarm can be read out on an OM terminal (local or remote) with the OM command DIMINA.


2.5.3. Blocked Alarm

Resource failures less important than the major or minor alarms may result in a blocked alarm. One or more resources are not available for call processing any more. A blocked alarm is also given if a network only allows restricted communication.

A blocked alarm is also signalled on the first OM terminal on the BIM, on the local SMPC (if

34

connected), on the operator desk and/or on the alarm box/Alarm Unit (MDF) or on the remote maintenance system. It is also possible to suppress alarms.

The alarm report related to the resource that caused the blocked alarm can be read out on an OM terminal (local or remote) with the OM command DIBLCK.


If resources are in the service condition 'OUT' a blocked alarm is generated.

If the ISPBX unit is in the installation mode a blocked alarm is generated.

2.5.4. Silent Alarm

Resource failures less important than the major, minor or blocked alarms may result in a silent alarm. One or more resources are not available for call processing any more.

A silent alarm is NOT signalled on the operator desk, on the alarm box/Alarm Unit (MDF) or on the remote maintenance system.

The alarm report related to the resource that caused the silent alarm can be read out on an OM terminal (local or remote) with the OM command DISILA.


For resources that operate in a pool it is not always necessary to generate a real alarm (major, minor, blocked) when one of the resources fails. Therefore the silent alarm can also be generated as silent alarm by time or silent alarm by amount.

• Silent alarm by timeIf a resource with the alarm level 'silent alarm by time' is entered in the silent alarm by time queue, a timer is started to measure the time the alarm stays in this queue. If a certain time limit is exceeded, the silent alarm is moved to the queue with minor alarms. This time limit (in hours!) is defined in the network boundary NEBOUND 048 (Threshold for silent alarm limited by time).A special scan timer is used to detect if the alarms in the 'silent alarms by time' queue have exceeded the boundary. This timer is defined by the network timer NETIMER 013 (SAS silent alarm timer). Each time this timer expires, SAS alarm handler scans through the silent alarm by time queue to see if the silent alarm(s) must be transferred to the minor

35

alarm queue.• Silent alarm by amount

A resource with the alarm level 'silent alarm by amount' is entered in the silent alarm by amount queue. If the total number of reports in this queue exceeds a certain threshold an additional alarm is generated and stored in the queue with minor or major alarms. This threshold is defined in the network boundary NEBOUND 049 (Threshold for silent alarm limited by amount).

2.5.5. Changing the Alarm Level for a Resource or for an Alarm Code

All resource types (hardware) and alarm codes in the ISPBX are related to one of the discussed alarm types. It is possible to change the default relations, using the second line maintenance command EXSUBC. For more details, consult the Maintenance Manual Part 2 (Alarm Codes).

2.5.6. Clearing the Alarms

When an alarm appears, the data about the alarm can be read out on an OM terminal or operator desk with the concerning OM or operator desk commands. In the Maintenance Manual the type of alarm, the cause of the alarm and the solution for the alarm are described. In some cases the alarm can be solved by some OM commands. In other cases faulty hardware must be exchanged (again using procedures described in the Maintenance Manual).

When the cause of the alarm is solved, the alarm should be removed. By solving the cause of the alarm, the alarm itself is also removed from the V.28 connector, operator desk or alarm box/Alarm Unit in a lot of cases. With certain types of alarm, the alarm is not removed even if the cause of the alarm is not present any more. By executing the OM command CLALRM the alarm can now be cleared. The operator desk command 6029 also clears the alarms.

For more information: see also the section concerning Error Codes Related Items.

2.6. ALARM SIGNALLING DEVICES

On the first OM terminal on the BIM and on the SMPC a system alarm status line is available: it indicates whether a major, minor and/or circuit blocked alarm is present in the system.

2.6.1. Alarm Unit

An optional Alarm Unit can be used for alarm signalling in all systems except the iS3070/3090. The Alarm Unit has the following features:

- 2 sensor point inputs;- visual and acoustical alarm indicators;- a Common Answering Night Service (CANS) relay;

36

- an emergency bypass switch;- a buzzer reset switch.

The Alarm Unit is connected via the MDF to a V.24 port on the CPU. Note that the upper port on the VIC3000 is not used for V.24 connections. The Alarm Unit must be connected to a V.24 D-connector by means of a Null-Modem (modem by-pass) cable.The Alarm Unit can be either mains powered or powered by a 48V external supply. This 48V supply for the Alarm Unit can either be connected to the ISPBX exchange (the 48V termination at the MDF should be used) or to a 48V emergency battery (optional).

A ISPBX can only handle one alarm unit.After power, up the Alarm Unit performs several hardware tests and software tests. After successfully completing these tests, the Alarm Unit is initialized. All alarms are switched off except for 'system down'. When communication with the CPU has been established, the 'system down' LED is switched off.

If one of the tests fails, an error state is entered. This is indicated by flashing LEDs.

• Alarm IndicationsThe Alarm Unit carries the following alarm indications:- Minor Alarm LED;- Major Alarm LED;- System Down LED;- Power ON LED;- Internal buzzer.The Minor alarm LED, the Major Alarm LED, and the System Down LED reflect the status of the ISPBX alarms. The System Down LED also lights if the communication with the CPU is lost; the Power On LED indicates the status of the Alarm Unit.The buzzer is used as an additional alarm indicator. It is switched on if the CPU has sent a buzzer-on message or if communication with the CPU is lost. The buzzer can be enabled and disabled by means of a DIL switch in the Alarm Unit.

• Relay Contacts Available for the UserThe following relay contacts are provided for use by the customer:- Minor alarm contact;- Major alarm contact;- System down contact;- Buzzer contact;- Common Answering Night Service (CANS) contact.The first three contacts are connected in parallel with the associated alarm LEDs. The buzzer contact is connected in parallel with the internal buzzer. The CANS contact is switched by an internal CANS relay (maximum contact load: 100mA at 48V DC). None of these contacts is connected to any internal voltages.

37

• Switches of the Alarm UnitThe two switches of the Alarm Unit have the following functions:- Emergency bypass switch: this switch can be used to initiate an emergency situation

whereby trunk lines are directly connected to predefined extensions. The switch is implemented as a push button that toggles the emergency state on or off. If the emergency bypass is activated the associated LED is lit, if the bypass is deactivated the bypass LED is off. The emergency bypass switch can be enabled or disabled by means of a DIL switch in the Alarm Unit.

- Buzzer reset switch: this switch can be used to reset the internal buzzer and the buzzer contact.

• Sensor Inputs on the Alarm UnitThe following Sensor Inputs are present on the Alarm Unit:- Sensor point 1;- Sensor point 2;- Buzzer reset sensor input;- Emergency Bypass sensor input.The external alarm inputs allow the connection of customer defined alarms. Alarm sensor input 1 is related to alarm code 021 and alarm sensor input 2 is related to alarm code 022. The buzzer reset input can be used to connect an external buzzer reset switch. The emergency bypass input can be used to connect an optional external emergency bypass switch. The emergency bypass sense input can be enabled or disabled by means of a DIL switch in the Alarm Unit.

Note: When the emergency bypass sensor input is not used, it must be disabled!

2.6.2. V.28 Alarm Signals

The topmost connector of the CPU of all systems except the iS3070/3090 gives the state of major, minor and circuit blocked alarm signals. The alarms can be presented separately or as an OR function at the topmost pin pair. The "OR" function means that the V.28 signal is activated when the system generates either a major, minor or circuit blocked alarm. This way of presenting these alarm states is very suited for driving a device, which automatically reads out the alarms and reports them to a remote service centre. Whether the alarms are presented separately or as an "OR" functions depends on system option LOSYSOP 67. The V.28 alarm device can be tested using OM command TSALRM.

2.7. SIMPLE ALARMING OVER IP (since Call@Net 2.8)

Simple Alarming over IP features simple alarming information over a TCP/IP interface. Simple alarming information is also available over a V.24 interface. Either one of the two interfaces, TCP/IP or V.24, is active. It is not possible to use simple alarming on both interfaces at the same time. When Simple Alarming over IP is not used, the existing (V.24) Simple Alarming

38

functionality is still available. Only during the time that Simple Alarming over IP is used, it is not possible to use the existing (V.24) Simple Alarming functionality.

The user of Simple Alarming over IP is a SysManager Maintenance PC, release 5.0 (SMPC 5.0). Users of Simple Alarming over IP can connect to Simple Alarming over IP through the Simple Alarming port. This port number is 2598 and is fixed. When connected, the current alarm status for each type of alarm (major, minor and blocked) is sent. Further alarm status updates are only sent when the alarm status changes.

The user of Simple Alarming over IP is described in a so-called Client Service Profile (CSP) which is created using OM command CHPROF. Such profile describes which IP address (and therefor which user) can connect to Simple Alarming over IP. When a user wants to connect to Simple Alarming over IP and no Client Service Profile is available for that user, the connection is refused. In that case an alarm is generated, when system option LOSYSOP 130 (ENABLE IP SERVICE ALARMS) is true. The maximum number of concurrent users is limited to four.

• DISCONNECTUsers of Simple Alarming over IP can disconnect from Simple Alarming over IP, by closing the TCP/IP link with Simple Alarming over IP. When disconnected, no more updates about the simple alarming information are received.The connection between each client and Simple Alarming over IP is guarded. When a client does not respond on a heartbeat message, the client is disconnected and an alarm is generated when system option LOSYSOP 130 (ENABLE IP SERVICE ALARMS) is true.The heartbeat to connected clients is sent every 20 seconds. The heartbeat is only sent during idle time of the client. Since the Simple Alarming over IP client does not initiate sending data by itself, only as a reply to a heartbeat, it can be stated that each 20 seconds a heartbeat is sent. When the client does not respond within 20 seconds on that heartbeat, the connection is considered to be broken and the connection is closed. The SMPC client disconnects from Simple Alarming over IP when nothing is received for 90 seconds.

• SECURITYThe users are described in so called Client Service Profiles. When the user is not described in a Client Service Profile, it is not possible for that user to connect to Simple Alarming over IP.

• COMPATIBILITYWhen Simple Alarming over IP is not used, the existing (V.24) Simple Alarming functionality is still available. Only during the time that Simple Alarming over IP is used, it is not possible to use the existing (V.24) Simple Alarming functionality.

PROTOCOL FORMAT

39

Simple Alarming is an interface to notify external applications of changes in the alarm status of SIP@Net. In general it is a one-way communication from server to client. However to allow the server to guard the connection with the client, the client must respond to heartbeat messages.

• Alarm informationThe following string of bytes is sent to notify a change in alarm status :

• HeartbeatThe following byte string is sent by the server to request an acknowledgement from the client :

• Heartbeat AcknowledgementThe client must acknowledge within 60 seconds after receiving the heartbeat, using the following byte string :

Note that if the client fails to acknowledge the heartbeat within 60 seconds, SIP@Net will

FIELD DESCRIPTION LENGTH VALUE / FORMATAlarm message length 1 H' 38Major alarm 1 H' 30 (='0') or H' 31 (='1')Minor alarm 1 H' 30 (='0') or H' 31 (='1')Blocked alarm 1 H' 30 (='0') or H' 31 (='1')System down alarm 1 H' 30 (='0') <spaces> 33Date and Time 16 yyyy-mm-dd HH:MM <spaces> 1CR/LF 2 H'0D H'0A <total> 57

FIELD DESCRIPTION LENGTH VALUE / FORMATHeartbeat 1 H' FF <total> 1

FIELD DESCRIPTION LENGTH VALUE / FORMATHeartbeat acknowledgement 1 H' 00 <total> 1

40

close the connection.

2.8. HISTORY BUFFERS

Beside the queues for silent, blocked, minor and major alarms the test results are also stored as reports in history buffers. These history buffers are specified queues in the ISPBX CPU memory where the logging of the different types of reports is performed. Different queues are used to store the reports depending on the situation generating problem,Table 2-1 "History Buffers for System Assurance". For a detailed description of the contents of the buffers: see Maintenance Manual. With the OM command DIHIBU the history buffers can be read.

The history buffers can hold a specified number of reports. The maximum number of reports that can be stored in the queue is projectable (any number between 64 and 128) by local boundary LOBOUND 028 (maximum number of history messages).

The memory space available for history messages is shared for history buffers 0 to 15. The boundary is not used for each individual report type, so for all types of alarm reports together, up to 'LOBOUND 28' messages can be stored.

History buffer 16 does not use any memory space: it is only an overall overview of report types 0 to 15.

History buffer 99 does not use any memory space: alarm reports are not written in the CPU memory but in the LE-file on the LBU/SMPC.

If the memory is completely filled with alarm messages, the next message overwrites the oldest message. The messages in history buffers 11, 12, 13, 14 and 15 (active alarms) are never overwritten. If a new message is generated and no old messages can be overwritten since all messages are in history buffers 11, 12, 13, 14 and 15, the new report is lost, but alarm code 11 'SAS buffer overflow' is generated. One message place is always reserved for this alarm.

When the system performs a cold start or a restart, the history buffers are cleared and the reason for the cold start or restart is noted in an alarm report. The type of this alarm is projectable as described before.

2.9. PERIODIC AUTONOMOUS TEST

The periodic autonomous test (PAT) is the autonomous testing of all resources in the ISPBX unit by the CPU software (SAS) from time to time. When a PCT is assigned (as a board with the OM command ASBRDS or as a single circuit on a board with the OM command ASPCTB) the parameter 'HW-testtype' indicates what type of test must performed on the circuit. The sequence of a test and all resources that must be used during a test is stored in the CPU software.

41

The test types (parameter HW-test type) can be:

- 4 : DLC test;- 35 : Loop back test;- 48 : DTU-CC test;- 49 : DTU-CA test;- 50 : DTU-PR test;- 64 : ESU test;- 80 : RST-SL 2/5 test;- 81 : RST-SL 2/6 test;- 82 : RST-IM test;- 83 : RST-OM test;- If the value 255 is assigned as HW-test type to a circuit, the circuit is not tested by SAS.

The frequency of testing depends on the loading of the system. Because the call processing is assigned the highest priority, most processor time will be dedicated to the data processing for this software part. If the maximum loading of the system is not yet reached, SAS can be assigned some processor time and can start testing some resources.

All resources are scanned by SAS in sequential order to see if the resource is to be tested and what kind of test has to be performed. When all resources of a certain resource type have been scanned (one cycle), the testing starts with a new cycle. With the OM command DIPATC the current cycle of the PAT test for a certain resource type can be displayed. A list of all resource types can be found in the OM Commands Manual. With the OM command CLPATC the cycle counters for all resource types can be reset.

All test requests are entered in a buffer. One request at a time is extracted from the buffer and executed. When the number of PAT requests in the buffers exceeds a certain threshold, new PAT requests are not accepted. When a number of requests are extracted from the buffer and the total number drops below the threshold new requests are accepted again. The threshold can be projected by the boundary NEBOUND 125 (threshold for start stop PATs).

With OM command CHPATM the PAT-mode can be changed to normal or installation mode. In the installation mode the PAT test has a higher priority and the resources are scanned with a higher frequency. This installation mode decreases the call processing of the ISPBX and should therefore only be used when installing and testing a new ISPBX unit. When system assurance is in the installation/factory test mode alarm code 16, qualifier 3 is generated to indicate the reduced performance for call processing.

2.10. MANUALLY CONTROLLED TEST

When a new board is to be installed in a ISPBX unit, it is advisable to project the board in the

42

correct position in the shelf (for a new board) and change the service condition of the board and circuits to OUT. Now the board and circuits are accessible for SAS and the board and circuits can be intensively tested. These tests can be forced by the system manager by OM commands. This test is called the Manually controlled test (MAT).

All resources that must be tested are included in a Test Request List. The circuit/board/PM (EHWA) is included in the test request list OM command INTEST. When this command is executed, the parameter 'rep-factor' indicates how many tests must be performed on the defined resource. This parameter can have a value of 1 to 9. If the value 0 is assigned, the testing is performed continuously until the test is stopped manually. With OM command DITEST, the status of the tests of the resources in the request list is displayed.

To delete a circuit/board/PM from the test request list, use the OM command DETEST.

If a manually controlled test indicates a failure of a resource in the test request list, the resource remains in the service condition OUT and an alarm message is included in history buffer 12.

If the manually controlled test proves the circuits and the board are functioning properly, the board and circuits can be transferred to the IN-SERVICE condition and the resources are operational.

The total number of manually controlled test requests that can be active simultaneously can be projected by the boundary NEBOUND 135 (maximum number of MAT requests).

Note: A resource in the service condition INS can also be included in the MAT test. If the manually controlled test indicates a failure of a resource in the test request list, the resource is transferred to the service condition ABL and an alarm report may be generated.

2.11. OTHER TEST POSSIBILITIES

2.11.1. Test Telephone

With a test telephone the extension user can dial up a specific trunk line and get a connection with that trunk without any number analysis. A Test Telephone is just a normal extension with the facility class mark 13 (Test Call Entitled).

The user dials the Test Prefix+EHWA ([UU]CCSBBCC[bb] where bb indicates a B-channel number, in the case of an ISDN trunk) of the trunk circuit. Now the user can check the correct operation of the signalling with the distant exchange by dialling directly on that trunk, without any checks on the dialled number.

For MFE and Socotel, the test telephone is initiated by dialling the Test Prefix+EHWA+pre-

43

digits+external number, where the pre-digits are 2 digits: the first digit is always 0 and the second digit represents the Socotel Call type.

For CSS1, the test telephone is initiated by dialling the Test Prefix+EHWA+CSS1 pre-digits+CSS1 post digits+external number.

When the system timer NETIMER 003 (number may be complete) expires the speech path is established.

Note: If the selection indicator of the ISDN bundle is set to "any channel", the test call does not work.If the selection indicator of the ISDN bundle is set to "exclusive" or "preferred" and the received SETUP ACK suggests another B-channel than the desired one, the test call is also released.

2.11.2. Controlled Connection

A controlled connection can be used to establish and release a one way (single path) or a both way (paired path) connection between two ports. It is also possible to make a one way connection between a Sender/Receiver Tone and a port.

The controlled connection is established by means of OM command CRCCSP or CRCCPP.

The controlled connection is released by means of command ERCOCO. The actual status of the controlled connection is displayed by means of command DICOCO; the following statuses are possible:

The service condition of the circuits which are involved, must be OUT. If a tone resource or a B-channel is involved, the circuit must be in service condition INS. When the controlled connection is established and is in the 'active' state a tone, digit or frequency (defined by OM command SECCTO or SECCDI) can be send over that connection; the result can be displayed using OM command DICCDI.

For ISDN ports, the controlled connection uses one or two B-channels of an ISDN port. Access to that port can be:

- SETUP : Controlled connection has been set up.- ACTIVE : Connection is established and active.- ERROR : Error is detected but connection is not erased.- KILL : Connection is erased.

44

A controlled connection is limited to a unit; a maximum of 5 controlled connections per unit may be set up concurrently.

2.11.3. Directed Call

The directed call facility is used to test the function of receiver/sender resources. A directed call is defined using OM command ASDICA; it is activated from the extension of the user.

The user goes off hook and dials the directed call facility code. He receives dial tone if the resources which are defined for the extension are idle.

The result of a directed call can be displayed using OM command DIDICA; the directed call is removed from the registration list by means of OM command DEDICA.

A directed call is limited to one unit.

2.12. ROUTING OF ALARMS

The alarms that occur in a ISPBX unit are normally also transferred to the other units in the fully integrated network. The system manager is able to define where the generated major, minor and blocked alarms must be signalled.

Several destinations are possible:

• Remote Alarm SignallingWhen a remote maintenance system is available, the CPU can route the alarms (via the BIM in the iS3070/3090 with CCS) through the PSTN (via modems) to the remote maintenance system.To route the alarms to the remote maintenance system option LOSYSOP 049 (signalling at distance present) must be true.If the alarm must be confirmed by the remote maintenance system the system option LOSYSOP 050 (signalling at distance manual confirmation) must be true. The time interval allowed for the alarm confirmation is defined by the timer NETIMER 097 (remote alarm confirmation time). If this timer expires without alarm confirmation, the alarm is rerouted to the operator or to the MDF as projected. To confirm the alarm sent to the remote

- not exclusive. This means that access is connected for normal operation, e.g. to the public exchange. The controlled connection uses the given B-channel. The other B-channels are available for normal call processing.

- exclusive. This means that access is connected to a test device. The system does not accept or make calls to any B-channel in this access.

45

maintenance system, the OM command CALSIG must be executed from a local or remote OM terminal.For more information about remote maintenance, see chapter 9. "REMOTE MAINTENANCE".

• Operator DeskThe major, minor and blocked alarms can also be signalled on the operator desk. The alarm can be confirmed and the buzzer turned off.

• MDF- For the iS3070/3090 with CCS.

The same functionality as mentioned above is offered, but the connection is made from the Communication Interface External (CIE) to the MDF.

- For all other systems.The alarms can also be routed from a CPU front connector to the MDF where the Alarm Unit is connected. If an alarm is generated a buzzer and/or LEDs on the Alarm Unit are switched on. An 'accept' button is also present on the Alarm Unit to switch the buzzer off.

• Operator Desk and MDFAlarms are routed to the operator desk and MDF as described above.

If the remote alarm signalling is active, the alarms are routed to the remote maintenance system. If this facility is not active or if the remote alarm signalling confirmation timer expires (if the confirmation was expected) the ISPBX system manager can define where the alarms should be routed to. The OM command REROUT is used to define the alarm routing as follows:

- 0 : Suppress all alarms (no alarm signalling).- 1 : MDF (alarms are routed to the alarm box/Alarm Unit).- 2 : Standard according to PE (alarms are routed to the destination indicated in local

boundary LOBOUND 099 (default alarm distribution). If this boundary holds the value:- 0 : the alarms are routed to the MDF;- 1 : the alarms are routed to the operator;- 2 : the alarms are routed to the operator (and if no operators are available the alarms

are rerouted to the MDF);- 3 : the alarms are routed to the operator and MDF.

- 3 : Isolate unit (if an alarm occurs in this unit, the alarm is not transferred to other units in the iS3000 iSNet).

- 4 : Standard operator and MDF: in the projecting, remote alarm signalling can be defined with LOSYSOP 049. If remote alarm signalling is wanted, route type 2 (standard according to PE) must be specified. If remote alarm signalling is not wanted at certain moments the alarms can be rerouted to the operator or to the MDF by specifying route type 4.

46

If the facility timing feature is not used, the alarms are signalled the moment they arise. The time period during which the alarms are signalled can be defined by facility timing. With the OM command ASFATI with facility class 1 the time period for the alarms can be defined.

2.13. REDUCED RESOURCES AVAILABILITY ALARM

For certain resources (mostly resources used in a pool) it can be very useful to generate an alarm only when the remaining number of resources available for call processing passes a lower threshold. 'Non available' are the resources in the service conditions out of service (OUT) or blocked (ABL). Resources in the NIN-status are not regarded in this type of alarming.

Although the ISDN B-channels are not real resources, they can also be subjected to the reduced resources availability alarming. An ISDN B-channel has no service condition. The B-channels are counted to be available or not available according to the service condition of the access they belong to:

For all resource types the lower threshold can be defined with the subcommand S92310 and can be executed with the second line maintenance command EXSUBC. There is no command to display the actual thresholds.

Command:

S92310: <INDEX>, 11 , <ALARM-LEVEL>;

When the lower threshold is passed (the number of non available resources is too high) the alarm Excessive Resource Availability Reduction (alarm code 69) is generated. The qualifier of

- INS : If the access has the circuit condition INS, the B-channels in the access are counted in the reduced resource availability alarm and said to be available.

- NIN : If the access has the circuit condition NIN, the B-channels in the access are not counted in the reduced resource availability alarm.

- OUT or ABL : If the access has the circuit condition OUT or ABL, the B-channels in the access are counted in the reduced resource availability alarm and are said to be not available. If this number of B-channels becomes too high alarm 69 is generated.

INDEX : resource type to set threshold for reduced resource availability alarm: see Second Line Maintenance Manual.

ALARM LEVEL : percentage of non available resources before alarm is generated. If this value is set to 255, the threshold for this resource is not used.

47

this alarm indicates the resource type and the additional information indicates the percentage of non available resources. For ISDN B-channels qualifier 98 is used; for Transcom lines qualifier 99 is used. The type of alarm that is generated is projectable by means of alarm code 69 - Reduced Resource Notice. The alarm will only disappear when enough resources are transferred back to the INS status and the threshold is exceeded again.

2.14. CPU SOFTWARE PROBLEMS - FREEZE FUNCTION

In some cases a part of the software may not be functioning properly. This may result in an operational start (warm or hot start) of the system. Especially during busy hours this creates a lot of problems. It is possible to freeze the faulty part of the software and the Local Operating System does not generate a warm start. During quiet hours the operational restart is performed by means of OM command STWARM thereby introducing less problems.

When a software problem has occurred and the freeze function is performed, an alarm is generated (alarm code 33, qualifier 3). For the alarm code 33 - Diagnostic Notice the generated alarm type can be projected. This alarm can only be cleared if the operational restart is forced by means of OM commands at a convenient moment. The system dump that is generated with the forced operational restart can be deleted from the system with the OM command ERSYSD as the cause of the dump is known.

In some situations an operational restart cannot be prevented even when the freeze facility is active. The software part that must be isolated is too important for other processes. The LOS now generates an operational restart to free the software part.

When a resource is involved in the freeze facility and the resource is not made free (continuously owned by a part of an application software module), this resource can be made available for call processing again by the OM command sequence FRCOUT -SETINS (you should only use FRCOUT when the ISPBX traffic is low, i.e. during quiet hours).

If the number of frozen processes is more than specified by NEBOUND 088, alarm code 034, qualifier 001 is generated. The counter is reset during any system start, as only then are frozen processes released again.

2.15. SYSTEM DUMP

A special part of the CPU memory is reserved for when the ISPBX detects a minor malfunction. In this memory part the CPU environment will be stored, the system dump. This environment contains the processes that were active the moment the malfunction occurred, e.g. active calls, calls during call set-up, system assurance actions, OM actions. When a system dump is present in the memory part, action is required to clear this memory part for the next dump:

48

- If system dump data is not needed OM command ERSYSD can be used to delete the system dump information in the central memory or;

- If system dump data is needed OM command DUSYSD can be used to save the dump data to a logical device (LBU, SMPC, SSM with disk emulator or PC). As soon as the dump is saved completely, it will be erased automatically from the memory.This action can also be performed automatically, in this case the save will be done to the LBU.

A system dump is generated in the central memory of a unit after one of the following situations:

- A freeze process.A software malfunction concerning one process only; this process is frozen to prevent affecting the rest of the system.

- An autonomous operational start, due to a software exception.The ISPBX detects a malfunction that can only be solved by an operational start (warm or hot) which is performed automatically.

- A manual operational start.Either by OM command or by activating the CIE sensor point (iS3070/3090 only).

- A trigger by the execution of OM command TRSYSD.When this situation occurs the ISPBX automatically generates a system dump.

For any of the situations described above, the maintenance engineer has to define (using OM command CHSYSD) whether the system dump has to be written to the LBU automatically or not.

When a dump is generated in one of the four situations and the writing type is not set to automatic then alarm code 33, qualifier 1 is generated. The dump must be erased or written manually. Only after a manual action is the memory part free for a new system dump. When a dump is generated in one of the four situations and the writing type is set to automatic, the ISPBX automatically starts writing the system dump to the LBU. For each dump a second parameter has to be defined whether all dump data or only a selected part of the dump data has to be written to the LBU:

- all data : a set of new files is created on the LBU with the system dump (DA, DB, DC, DD, DEuunn.DMP files); nn indicates the sequence number of the dump file. More than nine dump files can be present on the LBU.

- selected data : the data concerning the malfunctioning process is appended to the new DSuunn.DMP file. If the file does not exist, it is automatically created.

49

If the automatic writing is successful, the memory part is automatically released and is free again for a new dump; if not successful, for example an LBU device error or no memory space available (see note), alarm code 33, qualifier 2 is generated.

The ISPBX performs a retry after a time period determined by timer 56. After 10 retries a steady situation occurs and manual action is required to solve the problem. The timer is also used to measure the time interval after an operational start and the automatic writing of the system dump.

50

3. ACCOUNTING MANAGEMENT

The main advantage of using a sophisticated private telephone exchange like the ISPBX within a company is the fact that it will be fairly easy to make contact with any person in that company. Most of the facilities of the exchange, like follow-me, automatic ring back, call forwarding, etc. are intended to make it easier for the user to make contact with a desired party. Because of the time saving offered by the exchange and the related facilities, the ISPBX also introduces a great deal of cost saving. This cost saving however is hard to measure.

What can be measured by the ISPBX are the costs of the telephone calls made by the extension users in the ISPBX system to external parties via an analogue or digital route. Internal calls between two ISPBX extensions and calls coming in over a route are never subject to cost measurement. The methods for monitoring the financial aspects of calls are described in this chapter.

3.1. CALL CONTROL

The system manager can use some tools to control the type of calls being made.

• Number AnalysisWith the number analysis scheme the numbers that can be dialled by the different users in the ISPBX (extensions, operators etc.) can be defined. If a number is not included in the relevant analysis tree, the number cannot be dialled by that group of users.The most important OM commands for implementing this call control tool are :- CHAGCV : to assign a DNR to an analysis group;- ASTREE : to assign an analysis tree to a dial type and analysis group;- ASBLCK : to assign internal numbers and abbreviated numbers in an analysis tree;- ASINTN : to assign prefixes or numbers in an analysis tree;- CHDSTC : to assign an analysis tree to a destination for an outgoing call;- ASEXTN : to assign an external number to an analysis tree;- ASEXTP : to assign an external number with pre-digit to an analysis tree;- CHRTCI : to assign an analysis tree to a route for incoming calls;- MAKENU : to erase a number in an analysis tree.

• Traffic ClassAfter the user has dialled a number that is included in the applicable analysis tree, the call processing software must determine if the connection is allowed. The tool used is the traffic class. Each extension and route (trunk/tie lines) is assigned a certain traffic class in the range 0 (lowest) to 7 (highest). So the user that wants to make a call has a certain traffic class. The destination number (indicated by the analysis) has a required traffic class. The traffic class check must indicate that the traffic class of the calling party is the same or is higher than the required traffic class of the destination number.

51

The traffic class for extensions can have four different values: day, night, upgraded and downgraded traffic class.If a DNR is also assigned as night extension the DNR is assigned a new traffic class if the unit goes into the night condition. This traffic class is related to the various night extensions. If a DNR is assigned as a night extension, the night extension traffic class overrides all other traffic classes (night/upgraded/downgraded traffic classes).The traffic class for operators only has one value (day traffic class) which is used when the operator is present. This traffic class is used for the private calls of the operator and when the operator is accessed for transferring a call. The traffic class check is now between the required traffic class of the destination number and the traffic class of the operator.If a call is coming in via a route with Direct Dialling In, the calling party must also have a traffic class. The incoming route is assigned a traffic class which is used in all situations.Outgoing routes do not have a traffic class. The traffic class check is on the trunk access code and the external number that is dialled by the calling party. If the outgoing route option 'direct switch through' is true, no external analysis and thus no traffic class check on the external number is possible.The most important OM commands for implementing this call control tool are :- CHTRFC : to assign the (4) traffic classes to a DNR or the (1) traffic class to an

operator DNR;- CHRTCI : to assign a traffic class to a call via an incoming route with DDI;- CHTRNE : to assign a traffic class to a night extension;- ASINTN : to assign the required traffic class to a prefix or a number;- ASBLCK : to assign the required traffic class to internal or abbreviated numbers;- ASEXTN : to assign the required traffic class to external numbers.- ASEXTP : to assign an external number with pre-digit to an analysis tree;

• Compatibility ValueThe next tool is the compatibility value (CV). Extensions and routes (incoming/ outgoing) are assigned a CV. Operators are not assigned a CV; this step is skipped for operators. First the dialled number is correctly analysed. After the analysis, the traffic class check indicates that a connection to a specific circuit is allowed. Now the CV-CV allowance determines if both parties are compatible and can be connected. This allowance must be set by the system manager.The most important OM commands for implementing this call control tool are :- CHAGCV : to assign a compatibility value to a DNR;- CHRTCG : to assign a compatibility value to a route;- CHCVCA : to define the connection allowance between two CVs (CV-A and CV-B).

• Internal Basic Service CategoryBecause of the many different types of traffic which can pass through a ISPBX it is necessary to apply a compatibility test between the originating and destination terminals. This also applies to calls going over trunk connections, including DPNSS.The Internal Basic Service Category (IBSC) is used to describe the capabilities of a

52

terminal. Because various IBSCs might require the same characteristics, a reduction mapping is introduced, distinguishing only a number of Basic Service Profile Types (BSPT). IBSC values can be generated and sent by pure ISDN terminals, but other terminals must be provided with a BSPT (containing an IBSC) using OM command CHDNRS. The BSPT that is assigned to the terminal's DNR should be previously defined using OM command CRBSPT. The second line maintenance command CHBSPT can be used to change the definition of a BSPT set.For more information about the IBSC and BSPT: see Facility Implementation Manual; Networking and Routing.The most important OM commands for implementing this IBSC and BSPT are :- CHDNRS : to change the DNR service capabilities;- CRBSPT : to create the BSPT definition;- CHBSPT : to change the BSPT definition (second line maintenance command).

Note: The allowance to dial certain numbers or the protection from being dialled by other parties can also be affected by Facility Class Marks. These FCMs are assigned only to DNRs with the OM command ASFACM.

3.2. INTERNAL CALLS

In the ISPBX system (unit or network) it is not possible to automatically measure the costs of an internal call and allocate the costs to the call initiator. With SOPHO-SETs however it is possible to measure the call duration. With some SETs the timer must be started manually, with other SETs the timer is started automatically when the connection is established. After the connection has been broken the display shows the call duration in seconds.

The Traffic Observation and Traffic Measurement tools can be used to retrieve statistical data about the behaviour of all extensions or a specific group of extensions in a ISPBX unit.

This statistical data comprises:

- Average hold time;- Carried load in Erlang;- Number of times Camp on Busy is started;- Number of times Camp on Busy leads to ringing;- Average ring duration;- Number of times ringing is started;- Number of answered calls.

These tools can also be used to obtain figures about the use of the different facilities the ISPBX offers. For more information about these management tools: see chapter 5. "PERFORMANCE MANAGEMENT".

53

3.3. EXTERNAL CALLS

Incoming calls over a route cannot be subjected to cost allocation. The Traffic Observation and Traffic Measurement tools can be used to retrieve statistical data about incoming calls.

To be able to reach a party that is not located in the network formed by the ISPBX unit(s), the system can be connected to other PABXs (tie line) or to the public switched telephone network (trunk line). Any extension in the ISPBX system can be connected via a tie or trunk line to an external party either directly (direct dialling out) or with assistance (operator). Because the ISPBX network is actually regarded as a normal subscriber to another network (for instance PSTN) it is often charged for the use of such a trunk or tie line.

To be able to allocate these costs to the call initiator the ISPBX holds two mechanisms: metering and toll ticketing. When an extension makes an outgoing call and the facility toll ticketing or metering is activated (by the ISPBX or manually) the costs of this particular call are measured and can be charged, for instance, to the extension user personally or to the department he belongs to.

Again the statistical figures about the use of the trunk and tie lines (located in bundles and routes) can be obtained with the Traffic Observation and Traffic Measurement tools.

In the remaining part of this chapter the Toll Ticketing and Metering tools are described and the way the costs can be allocated to the call initiator in the ISPBX.

Note: In this chapter the different types of digital and analogue trunk and tie lines and the related aspects for metering and toll ticketing will not be discussed. The facilities will be described for an analogue trunk/tie line. For more information about the different types of trunk/tie lines and the relations with the facilities: see Facility Implementation Manual ; Networking and Routing.

3.3.1. Metering

Metering is a facility that can be used by the ISPBX to allocate the costs of an outgoing external call to the initiating party. Metering is done on the call initiator until release or transfer; after transfer the metering is done on the new party. No other devices are necessary or possible.

With metering, the costs of calls are measured with the number of metering pulses ('ticks') that are received over (usually) a trunk line to the public network. A metering pulse is a special tone (out of the speech band) that is sent over the trunk line towards the ISPBX when the trunk line is used for an outgoing call. To detect the tones a special circuit is used (metering circuit) that must be inserted between the physical line and the trunk circuit in the ISPBX. This metering circuit detects the metering pulses and sends them as a message to the PPU which

54

transfers them to the ISPBX CPU where these metering pulses are allocated to the calling extension.

To activate the metering facility two conditions must be fulfilled. The initiating party must have a metering mark and the trunk line which is seized must belong to a bundle with outgoing option 'metering' set to true. For all operators and all extensions with FCM 10 (metering) a buffer is reserved in the CPU memory where the received metering pulses are counted. With the OM command DIMERE the number of metering pulses can be read-out. This read operation can be destructive (buffer cleared after read operation) or nondestructive (new metering pulses just added to the buffer).

Parties with the metering mark are always metered when they make an outgoing call via a bundle with metering. The type of call, DDO or assisted, does not influence the metering.

Parties without the metering mark can also be metered but only with an assisted outgoing call. The operator must now not only dial the external number but also mark the call for metering. When the call is finished the total number of received metering pulses for this call is returned in the operator C-queue and can be read-out. This is called Taxmetering.

For more information about the Metering facility: see Facility Implementation Manual; Networking and Routing.

3.3.2. Toll Ticketing

Toll Ticketing is a facility that can be used by the ISPBX to allocate the costs of outgoing external calls to the initiating party. It is a more flexible facility than metering.

With toll ticketing the costs of a call is measured with the number of 'metering pulses that are received provided the opposite exchange sends the metering pulses over the trunk line. To receive the metering pulses a metering circuit is required.

On trunk lines that do not support the metering pulses, it is also possible to use the call duration as measurement for the toll ticketing.

For both the number of metering pulses and the call duration, a lower threshold can be specified. If, during a call, the threshold is not reached, the call is not charged to the call initiator.

Metering uses a semi-permanent buffer in the CPU memory to store the metering pulses related to a party with a metering mark.

Toll ticketing however uses a completely different mechanism. If an outgoing call is initiated that has to be toll ticketed, the CPU reserves a location in its memory where the information

55

related to that call is stored in a record format. When the call is finished the record is stored in a file on a device, which can both be defined by the system manager. The memory location can now be used for a new record.

A header is inserted in the file indicating the meaning of the fields in the toll ticketing record. The number of records before the header is repeated can be defined by the system manager with the OM command CHTTCR. In fact this is the number of lines (only for printing).

The CPU uses one Long Data Block for each record. A long data block is a part of the CPU memory which is only used for special purposes (not only toll ticketing records). With the OM command DIPOOL, the remaining number of long data blocks can be displayed. The ISPBX always reserves one long data block as general counter for congestion purposes. If there are no more free long data blocks no new toll ticketing requests can be accepted.

• Data BlocksWith toll ticketing (TT) active, information is gathered during the call about the call and stored in a memory block called a Long Data Block (LDB). LDBs are used for different applications but part of them is reserved for TT. These are called TT data blocks. The maximum number of TT data blocks is limited by boundary 139 (max. number of TT data blocks).When the call is finished it is copied into another type of data block, called Call Recording Data Block (CDB) and the LDB and/or MDB is immediately available for new TT info (a CDB is reserved together with the LDB or MDB).So the accounting information is kept into the CDBs until it is sent to an output device. Since the maximum number of CDBs is much higher than the maximum possible number of LDBs or MDBs, this way buffering of accounting info in the CPU is created.

If the option LOSYSOP 020 (block outgoing calls on toll ticketing data block congestion) is TRUE, a new initiated call that has to be toll ticketed will be rejected.

If LOSYSOP 020 is FALSE the new initiated call that has to be toll ticketed will be accepted. The CPU now uses a long data block of a call which is still in progress. The metering pulses in this long data block are stored in the general counter. Now the block is cleared and assigned to the new toll ticketing call. The old call is not toll ticketed any more.

The following information is registered in the created record per toll ticketing call:

- Cost centre number cost centre number (max. 12 digits)personal identification code (password facility) (max. 16 digits for PID)malicious call trace request (999999)spaces

56

Example of Body format

12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567

____________ _ ___ _ ____________ __ _ _ ____________________ _____&_&_ __&_ ______ ______ ___._&__

- Cost centre type (0 ... 7) 0 : not cost centre;1 : no validation of cost centre;2 : modulo-validation of cost centre;3 : table-validation of cost centre;4 : malicious call trace request;5 : personal identification code.6 : DPNSS charge reporting supplementary

service7 : charging diversion initiator

- Department number analysis group of initiator- Business/private indication (B/P) P : private call

B : business call- Extension (DNR/Calling Line Identity)initiator identification of outgoing call

(max. 12 digits) it can be suppressedcan also be external line (RRR.LLLL)

- IBSC IBSC of the initiator of the call- P/N P : preferred route selected

N : non-preferred route selected- Password indication (Y/N) Y : password call

C : call back call (password facility)N : normal outgoing call

- Number dialled external number (can be suppressed)malicious call trace prefix+internal numbermalicious call trace prefix+external number(DASS and ISDN signalling)

- Date and time YYMMDD (YY year; MM month; DD day)- Duration time interval of call (max. 999999 sec.)- Units number of received metering pulses (max. 65535

metering pulses)- Route+line number RRR.LLLL (RRR route ;LLLL line number)

57

Note : In case of 16 digit Cost Centres the start position 15 (etc.) is 19 (etc.)

The toll ticketing facility can be started in different situations:

- The outgoing call is made over a route with the outgoing option Toll Ticketing set;- The outgoing call is made by an extension with the FCM 26 (toll ticketing);- The outgoing call is made with a cost centre call;- The outgoing call is made with a password call;- The outgoing call is made via alternative routing;- With a malicious call trace request.

When the bundle option and the facility class marks are correctly set, the metering facility is immediately active.

When the route option, the facility class marks and the prefixes for cost centre dialling and password dialling are correctly set, the toll ticketing facility is not yet active. With the OM command CHTTOD, the device where the toll ticketing record is sent to, can be specified. This device can be, for instance, the local back-up. The toll ticketing record is always generated in the ISPBX (in an iS3000 iSNet) where the used trunk/tie line is connected and thus where the metering pulses arrive. So every unit in the iS3000 iSNet can generate a record and each unit can have its own device where the records are sent to. Therefore the CHTTOD command must be executed for every unit in the iS3000 iSNet.

After defining the device where the records are sent to, the toll ticketing facility can be started.

Start Length Description Example (12 digit PID) see note below1 12 Cost Centre

15 1 CCT 018 3 Department 00023 1 P/B B26 12 Caller ID 6021 extension 602139 2 IBSC 1444 1 P/N N48 1 PSW N51 20 Number Dialled 01131201234567 dials to external74 6 Date YYMMDD 011231 on 31 december 200181 4 Time HHMM 1359 at 13:5986 6 Call duration 000834 for 834 seconds93 6 units 000000

100 3 Route number 000104 4 Line number 1003

58

The OM command STRTTT is used to start the toll ticketing for all ISPBX units in the iS3000 iSNet and with this command the system manager must also specify the file name where the records are stored. Only the first part of the file name (no extension) has to be specified. Each unit now creates its own version (Uuu; where uu denotes the unit number) of this file.

By processing the resulting toll ticketing files the costs can be simply charged to, for instance, the initiating DNR, the cost centre number or the department.

• Buffering TT/FDCR recordsNormally the CPU sends TT/FDCR records to a V.24 port for further processing. It is also possible to buffer the records in the CPU temporarily. BOUND 293 'max. number of call records to be stored' defines the maximum number of stored call recording buffers (default value is 1000). The maximum value (65533) has about 6 hours storage capacity if the call rate of the system is 3 calls per second (never set this value to 0).An extra buffer possibility is offered by the BIM. When the toll tickets have to be kept in a file, the CPU needs to have a port number on the CIE to handle the toll tickets. A dummy port has to be assigned, preferably port 25. A dummy port can not be used for other purposes. 'TT to file' is only applicable if the Service Access Function 'toll' is activated on the BIM. With this function the BIM collects these files in intervals.In case 'TT to file' is selected the port characteristics (as mentioned under 'Port configuration') are not shown. 'Call Records Buffering' is always 'yes' and also the size (number of records) must be entered.

Note: If you want to store your TT/FDCR records to external you must configure your port on the CPU as TT device and NOT as printer. Use OM command: ASDEVC.

3.3.3. Charging on Diversion Initiator

Normally if a call is made to a party with an active diversion to an external party (follow-me or call forwarding), the costs of the call are booked to the calling party. But the calling party may not be aware of the diversion and should therefore not have to pay for it. Besides, if the caller is an external party (coming in via a trunk route), the costs can only be registered on the incoming trunk route. The ISPBX charges the direct diversion initiator for the external calls made by means of diversion from the diversion initiator's number.

Normally, toll ticketing is done if either the calling party or the trunk is marked for toll ticketing. If direct diversion to external is done, toll ticketing is always started. The toll ticketing mark of the calling party is ignored.

If the diversion is done from a group DNR (call forwarding on busy/empty group) the individual metering buffer of the group DNR is not updated, since no metering buffers are introduced for groups. If diversion is done from a party in another PABX and metering pulses are received

59

on the diversion call (to a trunk with metering), then these pulses will always be booked on the DPNSS route. Metering is set implicitly on DPNSS routes and cannot be reset.

If DPNSS parties are involved a number of restrictions occur. An example: party A (in PABX A) selects party B (in PABX B). This party B has an active delayed diversion to party B'. Party B' in its turn has an active direct diversion to the externally located party C. In this, case the charged party is party A, because the diversion initiator identity B' is not sent via DPNSS.

The display of call costs at a feature phone will be suppressed when the costs originate from a diversion to external call.

3.4. SystemManager

By sending the toll ticketing records to a computer, with the SystemManager software, the possibilities for processing and cost allocation can be expanded. The SystemManager is a computer connected to the ISPBX via a V.24 port. The toll ticketing records can be directly transferred via this link between the ISPBX CPU and the computer where they can be stored in a file.

The SystemManager Accounting Manager module offers the system manager the options of creating a complete company structure with headquarters, divisions, departments and offices. All extensions in the ISPBX can be assigned in this structure. When the SystemManager now receives a toll ticketing record related to an extension, it is directly related to the structure of the company. The total costs can be allocated to different parts of the company: to a headquarter, to a department, to an office or to the extension itself.

For more information: see chapter 10. "SystemManager".

3.5. FULL DETAILED CALL RECORDING

The Full Detailed Call Recording (FDCR) facility provides output records on all incoming, outgoing and internal calls.

- incoming call : a call which enters the iS3000 iSNet (FIN) network;- outgoing call : a call which exits the iS3000 iSNet (FIN) network;- internal call : a call inside the iS3000 iSNet (FIN) network.

These output records will be used by an external call logging device for Call Accounting and Performance statistics. This facility provides an external interface for complete recording of all incoming, outgoing and internal calls. The FDCR facility is relevant for system managers, since it provides call logging and system management information, which can be used for call charging, traffic observation etc. The full toll-ticketing functionality is included in the FDCR facility.

60

3.5.1. FDCR Records

• STANDARD RecordFor every call a STANDARD record is made, at call termination, in the unit:- of the terminating (connected) party, in case of internal calls;- of the terminating (called) party, in case of incoming calls;- where the call exits the iS3000 iSNet network, in case of outgoing calls.

Note: FDCR records will only be made for "real" calls.- When a facility is initiated (e.g. an extension user initiates Follow-Me or Do Not Disturb) no FDCR record will be produced.- Also in case of an internal call to a busy party, no FDCR record will be produced.

The STANDARD record contains party information, information about the answered/ not answered status and the answer delay (the alerting/ringing time) and the call duration, the time the call was in the conversation phase.

• ACCOUNTING RecordWhen toll-ticketing is active on the outgoing route, beside the STANDARD record an ACCOUNTING record is also made for outgoing calls.This ACCOUNTING record contains the toll-ticketing information.

• Open FDCR RecordFDCR records are opened in one of the following situations:- an extension is selected

A STANDARD record is opened in the unit of the selected extension.- a trunk is selected (seized)

A STANDARD record and (depending on the existing toll-ticketing options) an ACCOUNTING record are opened in the unit of the outgoing trunk.

- a call is queued (operator or COB queue)A STANDARD record is opened in the unit where the call is queued.

- an enquiry (or subsequent) call is set upA STANDARD record (and an ACCOUNTING record when the second party is a trunk with toll-ticketing) are opened in the unit of the selected port.

- a call is transferredA new STANDARD (and possible ACCOUNTING) record is opened for the "new" call.

- an add-on conference is startedIn an add-on conference configuration, for both opposite parties of the add-on initiator a STANDARD (and possible ACCOUNTING) record will be opened.

• Close FDCR RecordFDCR records are closed (transferred to the FDCR output file) when a call is:

61

- released : the FDCR record(s) are closed.- transferred : the FDCR record(s) of the "old call" are closed.- diverted : when a call is diverted to an operator queue (as result of assistance

diversion) and the operator answers the call, the FDCR record(s) of the original call are closed.

ACCOUNTING records will only be generated for external calls where toll-ticketing is active and only if the party released internal (e.g. the party that initiates transfer) is charged for the call. For example, when an operator assists in setting up an external call (with toll-ticketing), where the call set-up cost are not for the operator, only a STANDARD record is generated when the operator transfers the call. When the transferred party releases, a STANDARD and ACCOUNTING record are generated.

3.5.2. Projecting

For the Full Detailed Call Recording facility, the system option LOSYSOP060 (FDCR-instead-of-Toll-Ticketing) has to be projected:

- LOSYSOP060 set to "TRUE"When this option is set to "TRUE", the FDCR functionality is offered.NO toll-ticketing records will be output by the ISPBX. The toll-ticketing information is available in the ACCOUNTING record of FDCR. The call records will be output in FDCR format. This means that an FDCR output device (instead of a toll-ticketing output device) has to be defined. Only the option 'block-outgoing-calls-on-tt-data-block-congestion' (in case no ACCOUNTING record is left) and the toll-ticketing route/extension characteristics are valid.

- LOSYSOP060 set to "FALSE"When this option is set to "FALSE", the toll-ticketing function is fully supported and NO FDCR is offered.Only toll-ticketing records are made for outgoing trunks with toll-ticketing active. All corresponding toll-ticketing options/characteristics, e.g. 'block-outgoing-calls-on-tt-data-block-congestion', 'toll-ticketing thresholds on outgoing trunk routes', 'toll-ticketing route/extension characteristics' etc. are valid. Also a toll-ticketing device has to be assigned.

- If a party (A or B) has a secret number (CLIR/COLR) and NESYSOP076 is "TRUE", then the party identity is presented in the output of the FDCR.When NESYSOP076 is "FALSE", then in the FDCR output "000000" is presented.

3.5.3. OM Commands

The OM Commands for toll-ticketing (CHTTOD, DISPTT and STRTTT) are only relevant when LOSYSOP060 (FDCR instead of Toll Ticketing) is set to "FALSE".

OM command STOPTT is independent of LOSYSOP060.

62

The OM commands for FDCR (CHFROD, DIFROD, CHFRCR, STRTFR, DISPFR) are only relevant when LOSYSOP060 is set to "TRUE".

OM command STOPFR is independent of LOSYSOP060.

3.5.4. Hardware

• Toll-Ticketing offered by the ISPBXThe Toll-Ticketing records are offered in ASCII file format. The Toll-Ticketing output device can be a printer, a terminal or the SysManager.The Toll-Ticketing functionality is offered; NO FDCR records are made (thus no recording of internal and incoming calls offered).

• FDCR offered by the ISPBXThe FDCR records are offered in ASCII file or binary format. An external call logging application can be used as the FDCR (input) device.The external call logging device is connected to the ISPBX via a V.24 output channel on the BIM (iS3070/3090 with CCS) or CPU (all other models).The port to which the external call logging device is connected to must be projected with :- equipment type 25 : FDCR (ASCII format), or- equipment type 32 : FDCR (binary format), only for BCS protocol between the BIM

and the SysManager 410.In case direct output to a printer is required, equipment type 24 should be projected.

3.5.5. Layout of STANDARD Record

The STANDARD record contains the following information :

• Party Information- internal calls : the calling and the called party identification (NDNR).- incoming calls : the calling trunk identification (route and line number), the Calling Line

Identification (CLI) (in the case of an incoming ISDN or DASS trunk) and the called party identification (NDNR).

- outgoing calls : the calling party identification (NDNR), the called trunk identification (route and line number) and the Connected Line Identification (COL), if ISDN or DASS trunk is selected.

• Answer DelayInformation about the answered/not answered status and the answer delay (the alerting/ringing time).

• Call Duration TimeCall duration time, the time the call was in the conversation phase. This time may differ from the Call Duration Time field in the corresponding STANDARD record, e.g. call set up by operator but call set-up costs not for operator.

63

In the STANDARD record the connection time to the trunk is recorded.In the ACCOUNTING record the time the party is charged for is recorded.

In the STANDARD record (format version 0 & 1) the record information is available in the following fields :

64

Record Header "* <space>#"

Reference number <unit number><ref-number>(2+2 digits)

Type 1, meaning FDCR record type "STANDARD"

Date <yy><mm><dd>(6 digits)

Start time <hh><mm>(4 digits)

Party A identity <local id><far end id>(12+20 digits) :

a local party identity (a 12-digit string) representing the connected port inside the PABX, e.g. the route+line number of the connected DPNSS-line.

a far-end (connected) party identity (a 20-digit string) e.g. the NDNR of the far-end (in other PABX of the DPNSS network) connected extension, the CLI received via the connected DASS or ISDN trunk-line;

Party B identity See 'Party A identity'.

Route number 255, line number 0000 might be given : this is an exceptional erroneous situation.

Party A type the type of the connected party (1 digit):

1 = extension2 = operator assistance3 = PSTN / tie-line4 = DPNSS5 = Paging

Party B type See 'Party A type'

IBSC 2 digits

Facility Indicator not implemented : default = 0000 (no facilities) is given in the record

Answered status specifies whether the call was answered (1) or not (0) (1 digit)

Answer delay the answer delay (when the call was answered) or the ringing/alert time (when the call was not answered) in seconds (3 digits)

Answer delay type defines the type of answer delay (1 digit)

Record Release Reason

the reason why the record was released/closed (1 digit)

Call Duration the time (in seconds) the call was in the conversation phase (6 digits)

Record Terminator <CR><LF>

65

Table 3-1 STANDARD record information

In the STANDARD record (format version 2) the record information is available in the following fields :

66

Record Header "*<space>#"

Reference number <unit number><sequence-number>(2+2 digits)

Type 3, meaning FDCR record type "STANDARD version 2"

Party A type the type of the connected party (1 digit) :

1 = extension2 = operator assistance3 = PSTN / tie-line4 = DPNSS5 = Paging

Party B type See 'Party A type'

Date <yy><mm><dd>(2+2+2 digits)

Start time <hh><mm>(2+2 digits)

Party A identity <local id><far end id>(a 12+20 digit string) :a local party identity (a 12-digit string) representing the connected port inside the PABX, e.g. the route+line number of the connected DPNSS-line.a far-end (connected) party identity (a 20-digit string) e.g. the NDNR of the far-end (in other PABX of the DPNSS network) connected extension, the CLI received via the connected DASS or ISDN trunk-line;

Party B identity See 'Party A identity'.

Route number 255, line number 0000 might be given : this is an exceptional erroneous situation.

IBSC 2 digits

Facility Indicator not implemented : default = 0000 (no facilities) is given in the record

Answered status specifies whether the call was answered (1) or not answered (0) (1 digit)

Answer delay the answer delay (when the call was answered) or the ringing/alert time (when the call was not answered) in seconds (3 digits)

Answer delay type defines the type of answer delay (1 digit)

Record Release Reason

the reason why the record was released/closed (1 digit)

Call Duration the time (in seconds) the call was in the conversation phase (6 digits)

Record Terminator <CR><LF>

67

Table 3-2 STANDARD ASCII record format version 2

• Answer DelayThere are three answer delays of importance:- Answer delay time before an incoming trunk call is answered: answered by the

selected extension, or answered by the operator in case of assistance diversion.- Answer delay time between the start of ringing and answering the selected port.- Queuing time in the operator queue.

• Answer Delay TypeThere are four answer delay types :- 0 = Answer delay not relevant

This value indicates that the answer delay field is not of importance. For example, when a call is transferred in conversation the "new" call is already answered.

- 1 = Party AThis value indicates that the answer delay is specified for Party A. For example, when an incoming trunk call receives assistance because the dialled extension did not answer in time, the FDCR record is released when the operator answers this call. In this record only the answer delay of the incoming trunk (Party A) is specified. The dialled extension is still ringing (not answered).

- 2 = Party BThis value indicates that the answer delay is specified for Party B. For example, when a call is transferred in ringing and the ringing party answers, only the answer delay of the ringing party (Party B) is specified. The transferred party was already answered.

- 3 = Both partiesThis value indicates that the answer delay is equal for Party A and Party B. For example, when an incoming trunk selects an extension and the extension answers the call, the answer delay is the ringing time of the dialled extension as well as the answer delay of the incoming trunk.

• Release ReasonThe following release reasons exist :- 1 = Clear

The record is released with reason "Clear".- 2 = Answer (originating party)

When a call is diverted to the operator queue as result of assistance, and the original selected port answers, the call to the operator is cleared and the corresponding record is released with reason "Answer".

- 3 = DivertWhen a call is diverted to the operator queue as result of assistance, and the operator answers, the original call (e.g. from incoming trunk to (ringing) extension) is cleared

68

and the corresponding record is released with reason "Divert".- 4 = Transfer

When a call is transferred, the records corresponding with the "old" calls are released with reason "Transfer".

3.5.6. Layout of ACCOUNTING Record

In the ACCOUNTING record (format version 0 & 1) the record information is available in the following fields :

69


Reference number <unit-number><ref-number>(4 digits)the ref-number is the incremented ref-number of the corresponding STANDARD record.

Type 2, meaning FDCR record type "ACCOUNTING"

Destination maximum 20 digits of the dialled external number.

This field may be empty : see 3.5.9. "Toll-Ticketing on DPNSS Routes".

Password Indication

0 = normal outgoing call

1 = password call2 = call back call

P/B indication Private/Business Indication

0 = business call1 = private call

Pref. indication Preferred/Non-Preferred Route Indication

0 = Preferred1 = Non-Preferred

Cost centre Type 0 = not cost centre

1 = no validation of cost centre2 = modulo-validation of cost centre3 = table-validation of cost centre4 = malicious call trace request5 = personal identification code6 = DPNSS charge reporting supplementary service7 = charging diversion initiator

Cost centre version 0 : maximum 12 digits.version 1 : maximum 16 digits.

personal identification code (password facility)malicious call trace request: 999999

Department Analysis Group (3 digits)

Metering pulses the accumulated metering pulses (6 digits)

Call Duration Time the time (in seconds) the call was in the conversation phase for the charged party (specified in the corresponding STANDARD record) (6 digits)

70

Table 3-3 ACCOUNTING record information

In the ACCOUNTING record (format version 2) the record information is available in the following fields :

71


Reference number <unit-number><ref-number>(2+2 digits)the ref-number is the incremented ref-number of the corresponding STANDARD record.

Type 4, meaning FDCR record type "ACCOUNTING version 2"

<sp><sp> 2 spaces

Password Indication








1 = no validation of cost centre2 = modulo-validation of cost centre3 = table-validation of cost centre4 = malicious call trace request5 = personal identification code6 = DPNSS charge reporting supplementaryservice7 = charging diversion initiator

Cost centre maximum 16 digitspersonal identification code (password facility)malicious call trace request: 999999



Call Duration the time (in seconds) the call was in the conversation phase for the charged party (specified in the corresponding STANDARD record) (6 digits)

Destination maximum 32 digits of the dialled external number.

72

Table 3-4 ACCOUNTING ASCII record format version 2

An example of the STANDARD and ACCOUNTING record (version 0) made when an extension user makes an outgoing call is given below.

This field may be empty : see 3.5.9. "Toll-Ticketing on DPNSS Routes"or can have a different format : see 3.5.10. "DPNSS Remote Breakout Accounting (since Call@Net 2.6)"

Record terminator <CR><LF>

FDCR STANDARD RECORD<record field type> <record field value> <explanation><record header> "* #"<ref no> "0116" unit 1, ref number 16<type> "1" standard record<date> "<yy><mm><dd>" date the FDCR record is made<start time> "<hh><mm>" time the trunk is seized<party-a id>local id "1540" NDNR of extension Afar-end id " " empty, 20 spaces<party-b id>local id "1500060" route 150; line 0060far-end id " " empty, 20 spaces<party-a type> "1" extension<party-b type> "3" PSTN line<ibsc> "00"<fac indicator> "0000" no facilities<answered status> "1" answered<answer delay> "010" 10 sec<answer delay type> "2" answer delay of trunk<record rel reason> "4" transfer<call duration> "000150" 150 sec. from answer received

on trunk until transfer

FDCR ACCOUNTING RECORD<record field type> <record field value> <explanation><record header> "* #"<ref no> "0117" unit 1, ref number 17<type> "2" accounting record<destination> "003135893314 " destination digits

73

3.5.7. FDCR for Enquiry and Transfer

To know what type of records are made in case of FDCR for enquiry and transfer, it is important to know what the nature of the call is.

There are three possibilities when a call is initiated by party A and the destination is party B :

1. Party A is external (public network). Party B is an extension (PBX).This is an incoming call.

2. Party A and B are extensions.This is an internal call.

3. Party A is an extension (PBX). Party B is external (public network).This is an outgoing call.

For an incoming and an internal call, a STANDARD record is made. In case of an outgoing call, both a STANDARD and an ACCOUNTING record are produced.

Enquiry

An enquiry may be initiated as follows:

• Party A goes into enquiry by putting party B on hold and dials party C;• Party B goes into enquiry by putting party A on hold and dials party C.

Party C may be an internal or an external party. The FDCR records that will be made are given in the table below (SR = STANDARD Record; AR = ACCOUNTING Record).

<password ind> "0" no password used<p/b> "0" business call<pref ind> "0" preferred route<cost-centre type> "0" no cost-centre dialled<cost-centre> " " empty, 12 spaces<department> "003" department number 3<metering pulses> "000120" call costs, 120 metering units<call duration> "000150" 150 sec. from answer received

on trunk until transfer

FDCR ACCOUNTING RECORD<record field type> <record field value> <explanation>

74

Table 3-5 FDCR records made, in case of enquiry

In case the party, dialled in enquiry, is an external party (C), the initiating party (A or B) will be charged for it. There is one exception for this rule: if the operator (or night extension) goes into enquiry and option 4 (Call Setup to Individual Metering) is "TRUE", it is assumed that assistance is provided and the assisted party will be charged.

Transfer

Party A and B are in conversation. A or B goes into enquiry and calls party C. If the initiator of enquiry goes on hook, the call is transferred to the remaining party and to party C.

The rule for charging transferred calls is that the party that made the external connection is charged. There is one exception for this rule: if the operator (or night extension) gives assistance to an internal party, the internal party is charged.

The table below shows the records which are made (SR = STANDARD Record; AR = ACCOUNTING Record).

Table 3-6 FDCR records made, in case of transfer

From the table it can be seen that in case of an internal call, the party that initiated the transfer to the external party C, will be charged for the transferred call.

In case of CSTA, a next call may be initiated by pressing the enquiry button or it is the CSTA application that initiates the consultation call command to a monitored party. If the enquiry

A goes into enquiry B goes into enquiry

C is internal C is external C is internal C is external

Incoming call - - SR SR + AR

Internal call SR SR + AR SR SR + AR

Outgoing call SR SR + AR - -

A transfers C B transfers C

C is internal C is external C is internal C is external

Incoming call - - SR SR + AR

Internal call SR SR + AR SR SR + AR

Outgoing call SR SR + AR - -

75

button is used, the rules mentioned above apply. In the other case, the party that receives the consultation command is charged.

3.5.8. Interaction with other Facilities

When a call is set up with a certain facility, it is indicated in the STANDARD record.

- DPNSS Charge ReportingThe DPNSS Charge Reporting facility is used to transport the charging information via a DPNSS connection.

- DPNSS diversionWhen the diversion primary (selected party) and the diversion destination are located in different PABX's (a DPNSS diversion), for the call to the diversion primary also a STANDARD record is made.

- Diversion (Follow-Me/Call-Forwarding)Only one FDCR record (STANDARD+ACCOUNTING in the case of diversion to a trunk with toll-ticketing) will be made for this call, where the called party identity is the diversion destination and the answer delay is the total answer delay (the time the caller received ring-tone).

- Add-on-conferenceFor both opposite parties of the add-on-conference initiator a STANDARD record is made. In the STANDARD record the add-on party and add-on initiator form the party identities.

- GroupsWhen a call is set up to a group DNR the group DNR is noted in the STANDARD record. When the call is answered, the identity of the answering group member is noted in the STANDARD record as well.When a call is presented at a line position, the identity of the corresponding group member is noted in the STANDARD record.If a group member transfers a call to its private park position, the FDCR record will not be closed (transferred), the call is just (temporarily) parked.If a group member transfers a call to a common park position, the FDCR record is closed. In the new FDCR record the group DNR is noted.When the call is answered by a group member, the identity of the group member is noted in the STANDARD record as well (a call to the common park position is handled as a call to the group DNR).

- Call pickupWhen a call is answered using call pickup, the connected party address is the address of the answering extension, the answer delay is the real answer delay (the time the caller received ring-tone).

- Executive/Secretary

76

When executive line positions are assigned to executives, the identity of the corresponding executive is noted in the STANDARD record when a call is presented at the executive line position.If the call is answered by another executive or by a secretary, the identity of the answering extension replaces the identity which was noted in the STANDARD record.

- ACD and announcementIf a call is diverted as result of an ACD call forwarding function (Call Forwarding when Empty, when Night, when Overflow), the called party identity is the diversion destination and the answer delay is the total answer delay (the time the caller received ring-tone and/or announcement).When an announcement is being given, the call is in the alerting phase and is thus still NOT answered.

- Existing metering/taxmetering facilityThe existing metering/taxmetering facility is not changed. When a call returns to the operator, as result of taxmetering, NO FDCR record will be made.

3.5.9. Toll-Ticketing on DPNSS Routes

DPNSS toll-ticketing is implemented like the toll-ticketing facility for "normal" trunks (e.g. analogue, ISDN, etc.), but is part of the FDCR facility. In the FDCR facility for every call a STANDARD record is produced.

For external trunk calls an ACCOUNTING record is produced, when toll-ticketing is active on the outgoing route.

For DPNSS calls in all PABX's through which the call is routed, thus also in DPNSS transit PABX's (not necessarily a ISPBX), a STANDARD record is produced in each ISPBX

Calls via DPNSS to the PSTN (via an ISPBX supporting the DPNSS supplementary service 'Charge reporting') are logged in the ISPBX of the calling party and an ACCOUNTING record is produced, containing the dialled number.

ACCOUNTING records are created upon receipt of the NAM (Number Acknowledge Message). These records are only created when the route option 'toll-ticketing on route' is set "TRUE" for the DPNSS route involved.

This means that for internal DPNSS calls ACCOUNTING records can be made. This is valid for calls via a DPNSS route only : so calls within the DPNSS network and not within the same ISPBX.

The dialled number represents the number transmitted over the DPNSS line and not the number dialled by the caller. The route/line number gives the information to determine the

77

costs. In case number conversion or least cost routing is applied, the result of the number conversion and the finally applied route are shown in the FDCR record.

The dialled number is stored during initial call set-up and not updated. Suppose A is the call originator, B is the first destination via DPNSS and C, connected to the PSTN, is the second destination. Suppose A dials B and B dials C in enquiry and transfers A to C. After termination (release) of the transferred call an FDCR record will be made: originator is A, dialled destination is B, x metering pulses. The FDCR output of the ISPBX of extension B is required to determine destination C which was dialled by B. As the route/line number is also displayed in the FDCR records, it is possible for an external application to relate the two records to the same call (beware of double cost calculators!). Note that no ACCOUNTING records are made in transit ISPBXs.

ACCOUNTING records will be made when the party that initiates the call has the toll-ticketing characteristics (FCM 26) or the DPNSS route has the toll-tickleting route mark.

But when the route mark is not set and the extension without toll-ticketing transfers an outgoing DPNSS call to an extension (in the same node) with toll-ticketing, the ACCOUNTING record is created AFTER transfer. The dialled destination field of the ACCOUNTING record is left empty, as it is not known at that moment.

An ACCOUNTING record or a Toll Ticketing Record is produced in ISPBX A (see figure below) if the following two points are "TRUE":

- the option 'Toll Ticketing on route' (General option) has been assigned to the DPNSS route in ISPBX A or Facility Class Mark 'Toll Ticketing' is assigned to the subscriber in ISPBX A;

- the bundle in which trunk B is situated, has the option 'metering available on bundle' set to 'ON'.

The DPNSS Charge Reporting supplementary service is used to transport the charge units from the gateway PABX to the originating PABX.

78

Figure 3-1 DPNSS Routes

The records made, and the record information which is transferred over the DPNSS link is given in the following overview.

PBX A

• STANDARD Record- party information (extension-A, trunk-B, DPNSS-line a)- answer delay and call duration time

• ACCOUNTING Record- toll ticketing information (CC-type+number, P/B indication, charge units, etc.)

The external number is the number of the destination that has been transmitted over the DPNSS link.

PBX B when "Accounting DPNSS transit calls" call type is OFF.

• STANDARD Record- party information (DPNSS-line b, DPNSS-line c)- answer delay and call duration time

PBX B when "Accounting DPNSS transit calls" call type is ON(since SSW 810.22).

• STANDARD Record- party information (DPNSS-line b, extension-A, DPNSS-line c, trunk-B)- answer delay and call duration time

• ACCOUNTING Record- toll ticketing information (CC-type+number, P/B indication, charge units, etc.No

metering pulses).The external number is the number of the destination that has been transmitted over the DPNSS link.

DPNSS DPNSS

FDCR 1

PBX BPBX A PBX C PSTN

Originating PBX Gateway PBX

a b dcExtension

ATrunk

B

FDCR 2 FDCR 3

79

PBX C

• STANDARD Record- party information (extension-A, DPNSS-line d, trunk-B)- answer delay and call duration time

• ACCOUNTING Record- toll ticketing information (external number (converted digits), CC-type+number, P/B

indication, charge units, etc.)

Notes on transit calls

In the transit PBX we can have two situations: the FDCR call type "Accounting DPNSS transit calls" can be ON or OFF.

• In case the "Accounting DPNSS transit calls" call type is OFF, in the transit PBX only a STANDARD record is made. The party information only contains the DPNSS route and line numbers. When a transfer takes place no new record is made in a DPNSS transit PBX. The call duration time specifies the time the DPNSS transit connection was established.

• In case the "Accounting DPNSS transit calls" call type is ON, both a STANDARD and ACCOUNTING record is made. The latter one only when the general route option "toll ticketing on route" is on for the outgoing route in the transit PBX. In this case the STANDARD record contains the party information (including originator and destination information), the answer delay and call duration time. The ACCOUNTING record contains, when applicable, the toll ticketing information, except for the metering information.

3.5.10. DPNSS Remote Breakout Accounting (since Call@Net 2.6)

When an outgoing call is made from PBX A and a remote breakout to PSTN occurs in PBX C, then if TT is active on the respective outgoing DPNSS and trunk routes, FDCR Accounting Records are created at the originating PBX A and gateway PBX C. As decribed in 3.5.9. "Toll-Ticketing on DPNSS Routes"however, there are inconsistencies in the call accounting information in the two records. While the call duration field in the FDCR Accounting Record of PBX C represents the duration the call is connected to public network on PBX C, the call duration field in the FDCR Accounting Record of PBX A represents the connect time of the DPNSS trunk. Also, while the destination digits in the FDCR Accounting Record of PBX C stores the digits sent out on the outgoing trunk by PBX C after possible digit conversion, the destination digits in the FDCR Accounting Record of PBX A stores the digits sent out on the DPNSS route by PBX A. At PBX A, it is not known where the remote breakout occurs. This can be an unwanted situation as the tariff can be different depending on the breakout point, and therefore requires the call recording details at the originating PBX to manually be made consistent for call accounting.

80

In addition, when toll ticketing is active on a DPNSS route, irrespective of whether a call made is an internal network call or a DDO (remote breakout) call, besides the Standard Record an Accounting Record is created too. This results in an unnecessary extra load on the CRM in case internal network calls are not even charged.

DPNSS Remote Breakout Accounting (since Call@Net 2.6) solves these issues by making the cost accounting information for remote breakout calls consistent at both the originating and gateway DPNSS PBXs. NESYSOP127 (Remote Breakout Accounting) is used to control the inclusion of the corrected information into the FDCR Accounting Records at the originating PBX.

FDCR call type 9 (Filter accounting CCIS/iSNet (DPNSS) internal calls) in OM command CHFRCR provides for the optional filtering out of DPNSS accounting records generated for internal DPNSS calls. With this 'filter setting', in a DPNSS network with TT active on the outgoing route, for DDO calls both standard and accounting records are generated. While for internal network calls with the 'filter setting' ON, only a standard record is generated.

This 'filter setting' filters out the accounting records generated for all internal network calls :

- tieline calls (FDCR call type 4)- toll-ticketing (FDCR call type 7)- iSNet (DPNSS) transit calls (FDCR call type 8)

Keep in mind that for internal network calls, accounting records are generated (as described above) when the filter setting is OFF and DRBA is active.

The contents of the modified fields in FDCR accounting records when DRBA is active is detailed as follows :

- Irrespective of the type of call made (viz. internal or breakout), the destination field in the FDCR accounting record is always prefixed with 9 digits: 6 digits for the cluster ID and 3 digits for the route number (although by means of the CHFRCR, FDCR call type 9, accounting records can be suppressed for internal network calls).

- When the cluster ID is shorter than 6 digits, it is suffixed with trailing '*'; and when the route number is shorter than 3 digits, it is prefixed with leading '0'.

- However, if for any reason either the cluster ID or route number is not available, they are both replaced by 6 '*' (cluster ID) or 3 '*' (route number) in the FDCR record.

- When the destination digits are not available however, they are replaced by all blanks in the FDCR record.

- In case of an internal DPNSS call with the filter setting OFF, the cluster ID field is that of the PBX at which the record is generated, while the route number is replaced by '***'.

- In case of an transit call the record in the transit PBX consists of a destination field

81

containing the digits sent out by the transit PBX, prefixed with nine '#'.

Figure 3-2 DPNSS Remote Breakout Accounting

When DRBA is active the contents of the table as described in Table 3-4 "ACCOUNTING ASCII record format version 2"is different for the the 'destination' and 'call duration' field as follows :

DPNSS DPNSS

FDCR 1

PBX BPBX A PBX C PSTN

Originating PBX Gateway PBX

a b dcExtension

ATrunk

B

FDCR 2 FDCR 3

82

Record Header "**<space>#"

Reference number <unit-number><ref-number>(2+2 digits)the ref-number is the incremented ref-number of the corresponding STANDARD record.

Type 4, meaning FDCR record type "ACCOUNTING version 2"

<sp><sp> 2 spaces

Password Indication








1 = no validation of cost centre2 = modulo-validation of cost centre3 = table-validation of cost centre4 = malicious call trace request5 = personal identification code6 = DPNSS charge reporting supplementary service7 = charging diversion initiator

Cost centre maximum 16 digitspersonal identification code (password facility)malicious call trace request: 999999



Call Duration the time (in seconds) the call was connected to the PSTN (6 digits).However at the originating PBX, the duration can additionally include the DPNSS connect time, if the information has not been received.

Destination maximum 32 digits of the dialled external number in the format : <cluster id><route><destination digits>

83

Table 3-7 ACCOUNTING ASCII record format version 2

3.5.11. Cost Accounting For Transferred Calls (since Call@Net 2.8)

Since SSW 810.22 the default system behaviour when handling the transfer of an external call is to continue cost charging for the external call on account of the party that initiated the call transfer. The standard exception to this rule is when the enquiry initiator is an operator or a night extension : see also section 3.5.15. "Transfer FDCR for assisted incoming call to DPNSS".

In addition to this another exception is now made (since Call@Net 2.8) for normal extension users that mainly have a mediating role (for example a secretary or a hotel desk clerk) in which they often set-up external calls on behalf of another party. Facility Class Mark 69 (Cost of Call on Assisted User) allows cost charging on the transferred-to party. Thus it is possible to revert to the cost accounting behaviour of SSW 810.21 and before, on a per extension basis.

When the mediating party has FCM 69 the requesting party is accounted for the external call after transfer.

Note: In case the requesting party is an external party and the mediating party calls another external party, then after transfer, the mediating party is still charged for the complete call even if FCM 69 is assigned to the mediating party. This is because the requesting party is external and can not be charged for the call.

Two separate FDCR(SR+AR)/TT records are available indicating the before and after transfer scenario as follows :

• Mediating Party

- Cluster id Contains the cluster ID (6 digits) of the gateway PBX. However at the originating PBX, both the cluster ID and route number can contain 9 '*' instead, if either information is not received. In the transit PBX 9 '#' are given.

- Route number Contains the route number (3 digits) of the outgoing trunk. However at the originating PBX, both the cluster ID and route number can contain 9 '*' instead, if either information is not received. In the transit PBX 9 '#' are given.

- Destination digits Contains the destination digits (32-9 digits) at the gateway PBX after possible digit conversion. However at the originating PBX it can contain all blanks instead, if the information has not been received. In the transit PBX the digits sent out by the DPNSS trunk are given.

Record terminator <CR><LF>

84

For the first part of call, conversation between mediating party and the external party one FDCR(SR+AR)/TT is generated. Duration will be the duration of conversation between the mediating party and the external party.- in case of FDCR the PARTY A field contains the mediating party DNR.- in case of TT the EXT field contains the mediating party DNR.

• Requesting PartyFor the second part of the call, conversation between the requesting party and the external party one FDCR(SR+AR)/TT is generated, after the call is transferred by the mediating party. Duration will be the duration of conversation between the requesting party and the external party.- in case of FDCR the PARTY A field contains the requesting party DNR.- in case of TT the EXT field contains the requesting party DNR.

In case the mediating party does not have FCM 69, only one FDCR(SR+AR)/TT record is made and the mediating party is accounted for the call.

At present the functionality is supported in FIN and DPNSS networks but not in QSIG.

Interactions

Cost transfer is only applicable when no transfer has been done earlier. For example party A calls internal party B and transfers to external party C (now B and C are talking). If B now transfers to internal party D, still the rest of the call is charged to either A or B, depending on whether party A has FCM 69 assigned or not.

3.5.12. FDCR over IP (since Call@Net 2.8)

FDCR over IP features 'real-time' FDCR information over a TCP/IP interface. FDCR information is also available over a V.24 interface. Either one of the two interfaces (TCP/IP or V.24) is active. It is not possible to use FDCR on both interfaces at the same time.

The users of FDCR over IP (Management@Net 1.0.) can connect to FDCR over IP through the FDCR port. This port number is 2599 and is fixed. When connected, FDCR information can be received. When FDCR information is sent, it is sent to the user as soon as it is connected.

The user of FDCR over IP is described in a so-called Client Service Profile (CSP) which is created using OM command CHPROF. Such profile describes which IP address (and therefor which user) can connect to FDCR over IP. When a user wants to connect to FDCR over IP and no Client Service Profile is available for that user, the connection is refused. In that case an alarm is generated, when system option LOSYSOP 130 (ENABLE IP SERVICE ALARMS) is true. The maximum number of concurrent users is limited to one.

85

• ACTIVATIONTo activate FDCR over IP, first FDCR must be started, using OM command STRTFR. System option LOSYSOP 60 (FDCR INSTEAD OF TOLL TICKETING) must be TRUE, else FDCR over IP can not be started. When LOSYSOP 60 is changed, it has no immediate effect. Only when the FDCR is started, the changed option will have effect.For FDCR over IP, the FDCR IP device has to be assigned, using OM command ASDEVC (equipment type 33). The FDCR IP device is assigned to the same port (SHELF, BRD, CRT) as the V.24 FDCR device.When (new) FDCR information is present, this information is sent to the connected user. The user must acknowledge each received FDCR record.The FDCR record is prefixed by the record number (00 .. 99). This prefixed record number is not packed; the rest of the FDCR message is packed (just like with V.24). This record number is returned with the FDCR acknowledge, so the corresponding FDCR record can be removed.

• DE-ACTIVATIONTo deactivate FDCR over IP, FDCR must be stopped. When FDCR over IP is stopped, no more FDCR records are sent to the connected user.The user of FDCR over IP can disconnect from FDCR over IP, by closing the TCP/IP link with FDCR over IP. When disconnected, no more FDCR information is received.The connection between the client and FDCR over IP is guarded. When the client does not respond on a heartbeat message, the client is disconnected and an alarm is generated when system option LOSYSOP 130 (ENABLE IP SERVICE ALARMS) is true. The heartbeat to the connected client is sent when the client is idle for 60 seconds. When the client does not respond within 60 seconds on that heartbeat, the connection is considered to be broken and the connection is closed. The Management@Net client disconnects from FDCR over IP when nothing is received for 90 seconds.

• SECURITYThe users are described in so called Client Service Profiles. When the user is not described in a Client Service Profile, it is not possible for that user to connect to FDCR over IP.

• COMPATIBILITYWhen FDCR over IP is not used, the existing (V.24) FDCR functionality is still available. Only during the time that FDCR over IP is used, it is not possible to use the existing (V.24) FDCR functionality.

Details of the “FDCR over IP” format is given in Appendix A . "PROTOCOL FORMAT OF FDCR OVER IP"

86

3.5.13. Generate Accounting Record For Free-Of-Charge Call (since Call@Net 2.10)

Since Call@Net 2.10 it is possible to generate an Accounting Record for a 'Free-Of-Charge' call. This can be achieved by setting LOSYSOP 134 to TRUE. When this option is set to FALSE, only a standard record is generated for a 'Free-Of-Charge' call.

3.5.14. FDCR (TT) for IP-enabling (since Call@Net 2.11)

FDCR

If an ErgoLine@Net is involved in a call then the following FDCR records are generated:

1. The records as usual for a call from/to an extension.2. If outgoing calls (FDCR-CALL-TYPE 2) are recorded then a standard record is generated

for the media connection via the IP-gateway with:- IBSC: 14 (SOPHO speech)- Facility indicator: 0000;- Party A type: PSTN, Local id: [IP-gateway route].0003.

3. If the route of the IP-gateway has the general route characteristic "toll ticketing" and toll ticketing calls (FDCR-CALL-TYPE 7) are recorded then a standard record is generated as described above and an accounting record is generated with as destination digit string: The H.323 number used to reach the ErgoLine@Net over the IP network.

Toll Ticketing

For an ErgoLine@Net toll tickets are generated as usual for extensions. Apart from this, if toll ticketing is active and the route of the IP-gateway has the general route characteristic "toll ticketing" then a toll ticket is generated for the media connection via the IP-gateway:

- Cost centre type: 0- Business indication- Ext.: [IP-gateway route].0003- IBSC: 14 (SOPHO speech)- Number dialled: The H.323 number used to reach the ErgoLine@Net over the IP

network- Route/line number of the trunk to the IP gateway.

3.5.15. Transfer FDCR for assisted incoming call to DPNSS

In SSW 805, in case of an incoming call to the operator and then transferred via a DPNSS tie-line to a DPNSS destination, 3 records are generated, for :

87

1. incoming trunk call to operator2. operator to (DPNSS) destination call3. incoming trunk call to (DPNSS) destination call

The third record contains calling party information if this has been passed to the destination. In SSW 810 this third record is not present : there is no record anymore in which e.g. can be read who has been calling. The reason of the change is, that on that third record no costs can be accounted on.

In Call@Net 2.8, FCM 69 (Cost call on assisted user) has been introduced. However this FCM 69 can not be assigned to an operator.

However, since Call@Net 3.5 system option LOSYSOP 167 (Transfer FDCR for assisted incoming call to DPNSS) is introduced. When this option is TRUE then on transfer of an incoming call by the operator to DPNSS, the second record is split into an operator - tie-line record and PSTN - tie-line record, so 3 records are generated : this is then similar to the SSW 805 behaviour.

3.5.16. Extra FCDR record for Twinning and Follow-me

When a call is made to an extension that has twinning or follow-me relation to an external party, the FDCR registration is generated for the twinning originator or follow-me initiator (called party) to the external party when the external party answered the call (charging on diversion initiator). No registration is generated from the caller to the answered party.

Since SIP@Net 4.3 the feature "Extra FCDR record for twinning and follow-me" is introduced. This feature generates (beside the existing FDCR record) an extra FDCR record with the required party info in situations of twinning and follow-me. See examples below.The status of the extra FDCR record is "not answered" and the release reason of the extra FDCR record is "divert or answered by original party".

The feature is activated by setting the system option LOSYSOP 184 "Extra FCDR record for twinning and follow-me" to “TRUE”. In that case an extra FDCR record will be created :

- with the calling party and dialled party immediately when the call is diverted by the (fixed) follow-me facility.

- with the calling party and the dialled party (or the not answered party).

Otherwise no change is made in the existing FDCR functionality.

Twinning with internal party

88

• Records made in case Extension B answers the call :1st Standard RecordParty-a = Extension AParty-b = Extension B Status : Answered2nd Standard Record : extra !Party-a = Extension AParty-b = Extension C Status : Not answeredReason : Answer by original party

• Records made in case Extension C answers the call :1st Standard RecordParty-a = Extension AParty-b = Extension C Status : Answered2nd Standard Record : extra !Party-a = Extension AParty-b = Extension B Status : Not answeredReason : Divert

Twinning with external party

89

• Records made in case Extension B answers the call1st Standard RecordParty-a = Extension AParty-b = Extension B Status : Answered2nd Standard Record : (existed)Party-a = Extension BParty-b = Route/line numberStatus : Not answered+ Accounting RecordDestination : Extension CType : Charg. div initiator

• Records made in case Extension C answers the call :1st Standard RecordParty-a = Extension BParty-b = Route/line numberStatus : Answered+ Accounting RecordDestination : Extension CType : Charg. div initiator2nd Standard Record : extra !Party-a = Extension AParty-b = Extension B Status : Not answered

90

Reason : Divert

Follow Me to internal party

• Records made in case Extension C answers the call :1st Standard RecordParty-a = Extension AParty-b = Extension CStatus : Answered2nd Standard Record : extra !Party-a = Extension AParty-b = Extension B Status : Not answeredReason : Divert

Follow Me to external party

• Records made in case Extension C answers the call :1st Standard RecordParty-a = Extension BParty-b = Route/line numberStatus : Answered+ Accounting Record : Destination : Extension C

91

Type : Charg. div initiator2nd Standard Record : extra !Party-a = Extension AParty-b = Extension B Status : Not answeredReason : Divert

92

4. CONFIGURATION MANAGEMENT

4.1. INITIAL CONFIGURATION FILE

When a new ISPBX system is to be installed the software programs needed for the operating system, call processing, operational maintenance and system assurance must be available on the LBU. The LBU is either located on the BIM for the iS3070/3090 with CCS or on-board the CPU3000 for other systems.

In the software programs there is no information about the configuration of the unit(s) itself. The configuration information is stored in the configuration PE and LL files or in the Memory Image Snapshot file (MIS-file). The MIS-file will not be available in the initial situation. A unit must be operational before this file can be generated.

For a unit to become operational, the configuration files, PEuu.POM and LLuu.POM, must be available on the BIM/LBU of the unit(s). In these files the total configuration of all units is laid down in subcommands (readable format) that are subsequently executed when the CPU of the ISPBX unit(s) is activated (initial start).

After a restart, the CPU starts with a booting program stored in FEPROMs. First the CONFIG.POM file is loaded, indicating the unit number to the CPU. The PL.POM file is then loaded. This file tells the CPU which software programs are needed and the CPU starts loading the files mentioned.

When the software programs are loaded, the CPU searches for a LMuu01.POM (MIS)file. When available, the CPU loads the youngest version of this file. In case of an initial start, the MIS-file is not available. Then the PEuu.POM and LLuu.POM files are loaded and the subcommands executed.

At first, the subcommands in the PEuu.POM file are executed. The boundaries, timers and options are stored in this file and when executed these parameters are used to create the necessary partitions in the CPU memory for the configuration database. Once the partitions are created, they cannot be expanded anymore. When a boundary has to be changed, this must be done by a new PE file.

When the partitions are created, the necessary information can be stored in them. This information is stored in the LLuu.POM-file. When the configuration database is filled, the CPU starts testing all hardware in the unit and setting all hardware into service. The ISPBX unit is then fully operational. Any errors during the projecting are logged in history buffer 99.

During projecting (execution of the subcommands in the LLuu.POM-file), the CPU indicates on the screen of an OM terminal or SMPC which line number is being executed and when

93

projecting ends. This way the maintenance engineer knows when projecting is completed.

The configuration files, used for projecting a ISPBX unit during an initial start, are prepared off-line using the Project Generators PG1 and PG2. The customer's requirements (size and configuration) and the country dependent aspects can be entered in these project generators. After completion of these sessions the PEuu.POM and LLuu.POM files are automatically generated and can be converted to ISPBX format and loaded into the ISPBX unit(s).

Another part of the project generator generates the Office Data Manual (ODM). This manual is a (graphical) paper output of the configuration of a ISPBX unit. For more information about the project generation: see the PG1 User Manual and PG2 User Manual.

4.2. JOURNAL FILE

During the operational phase of a system the configuration can be changed by means of OM commands. To keep the Office Data Manual up-to-date, these changes must also be administered in this manual to make sure that the current situation is available.

The OM commands entered are analysed and the parameters validated by the CPU software (POM). They are divided into subcommands that are executed by the unit(s) they are intended for. The subcommands that introduce a change of the configuration database are also stored in the journal file. In case of malfunction or serious problems, the initial configuration files can be loaded into the CPU and executed. After that, all subcommands in the journal file are executed and the ISPBX returns to the current state.

Most OM commands have an effect on the configuration database in the memory of the CPU of the ISPBX unit(s). The OM commands that are administered in the journal file are indicated in the OM commands manual with a #-sign. These OM commands use subcommands that change the configuration database.

Display commands are used to read-out certain parts of the configuration database and do not effect a change in this database.

Two types of OM commands that introduce a change in the configuration of a network can be distinguished.

- OM commands that change the configuration in only one unit (local data) of the iSNet. These (sub)commands are entered in the journal file with an indication of the unit number.An example of such a command is the status change of a circuit from INS to NIN. This is only important to a particular unit. If a user in another unit tries to establish a contact with that particular circuit via an Inter-Unit link, the receiving unit checks its database and sends back a message that the particular circuit cannot be used.

94

- OM commands that change the configuration in all units (network data) of the iSNet. These (sub)commands are entered in the journal file with an indication that all units are affected.An example of such a command is the moving of a DNR from one unit to another. Every unit in the network must know where a DNR can be reached. If a user in another unit requests a connection to that DNR, the originating unit makes contact with the unit where the DNR is located (Inter Unit-link). This destination unit holds the hardware address of the DNR and the speech path can be established (if allowed).

One journal file (JOURNL.POM) is present per iSNet. This file is located on the CPU/BIM of the unit that holds the Central Back-Up (CBU).

If an OM terminal is used, connected to another unit in the iS3000 iSNet, the entered OM commands are analysed by the POM-software of that unit. The subcommands that must be entered in the journal file however are transferred via the Inter Unit-link (primary or alternative routing) to the unit holding the CBU. Here the subcommands are administered in the journal file.

If the CBU cannot be reached via primary or alternative routing, the command is rejected with an error message.

The backup can be locked using the OM command BMLOCK. After this command is used to set the backup lock, no changes can be made in the configuration of the total system. OM commands that change the configuration are rejected with an error message. The command BMLOCK must also be used to clear the backup lock.

The journal updating can be switched off with the OM command SWJUPD. After this command is used to switch the journal updating off, OM commands that change the configuration of the unit(s) are not available any more. These commands are indicated in the OM commands manual with the sign '#!'.

If the CBU can be reached and the OM command entered changes network or local data, the OM command is accepted and the subcommands are written to the journal file. If, in a particular unit in the iS3000 iSNet, the change cannot be made (unit unobtainable due to inter-unit communication failure) the command is still accepted but with the message that the unit cannot be reached. As soon as the inter-unit communication is possible again, the unit makes contact with the unit with the CBU and starts unit updating.For more information about the journal processing, see Maintenance Manual.

UNIT UPDATING

A unit will check if it is up-to-date in the following circumstances:

95

- After a unit performs a restart;- After a unit re-establishes inter-unit communication with another unit in the iS3000 iSNet;- Before starting the validation of an OM command if an OM terminal connected to that unit

is used;- Before executing a data changing subcommand if an OM terminal connected to that unit

is used;- On manual request using the OM command UPDATE.

The unit uses several parameters to determine if it is up-to-date. These parameters are administered both in each unit and in the journal file. By comparing the parameters, each unit can determine which subcommands must be executed to become up-to-date. The subcommands that are not yet executed and that are related to the relevant unit (journal file entry holds unit number) or that change network data are sent over the inter-unit link to the unit where they can be executed.

When a unit is busy updating and another OM command is entered related to that unit, the engineer receives the message UNIT UPDATING and the command is rejected. When the unit is up-to-date again the message UNIT UPDATING COMPLETED is displayed on the OM terminal.

4.3. MEMORY IMAGE SNAPSHOT FILE

Because the journal processing (executing all subcommands that are entered in the journal file) uses quite a lot of time, it is advisable to keep the journal file as short as possible. At regular time intervals the system manager should generate a Memory Image Snapshot file (MIS-file) by executing the OM command GEBUMI (after setting the backup lock with the OM command BMLOCK). With this command a copy is made of the current unit configuration in the CPU memory in the LBU. The memory partitions filled with the configuration data are copied (per unit) to an LMuu01.POM file on the LBU of the different units (uu indicates the unit number). At the same time the journal file is cleared. New OM commands can be stored in the empty journal file.

For safety reasons it is advisable to copy the MIS-file to an external device (for instance to a disk of a PC using Disk maintainer). This copy is called the fire copy.

If the ISPBX unit executes a cold start (manually or automatically) the CPU first loads the software files into its memory. This process is described with the initial configuration. When the software modules are loaded, the CPU searches for the configuration. If a MIS-file is available, the youngest version of this file will be loaded even if the original PEuu.POM and LLuu.POM files are present on the BIM/LBU. Because this file is just copied into the CPU memory without further processing, the partitions are not changed. When the youngest LMuu01.POM file is loaded into the CPU memory the same configuration database, as existed

96

the moment the MIS-file was generated, is restored. The remaining subcommands in the journal file must then be executed (unit updating) to restore a situation similar to the one that existed before the occurrence of a problem.

All MIS-files are given a Snapshot Identification Number (SIN). The SIN is used as follows:

Both the MIS-file and the journal file are assigned a Snapshot Identification Number. When a MIS-file is loaded, the journal processing is only possible if the journal file has the same SIN number as the MIS-file. By using the DIRECT command to display the user information the SIN numbers of both files can be read out:

DIRECT : LBUuu : LMuu01.POM , u ;

DIRECT : CBU : JOURNL. POM , u ;

When the OM command GEBUMI is executed, the SIN numbers of both the MIS-file and the journal file are increased one level. This MIS-file and the journal file belong together.

It is also possible to clear the journal file manually. When the OM command CHJOUR is executed an additional parameter must be entered which indicates the SIN number. With this command the journal file is cleared and, at the same time, both the MIS-file and the journal file are assigned a new SIN number so that they correspond again. Because the subcommands in the journal file are lost, it is possible that the current situation is not the same as the LBU/BIM situation (MIS-file + empty journal) any more.

The journal file might be deleted from the LBU/BIM by accident, for example when using the DELFIL command. It must then be re-stored on the CBU. On the CBU however the file JOURNL.SAV is present. This is an empty journal file. This file must be copied to the same device (CBU) but under the new name JOURNL.POM, using the CPYFIL command. With the CHJOUR command the journal file and the new MIS-file are assigned the same SIN number. This is because the current configuration is not the same anymore compares to the youngest MIS-file concatenated with the subcommands in the 'old' journal file. A new MIS-file must be generated to store the instantaneous configuration. For the creation of a new, empty, journal file it is also possible to use the Disk maintainer.

Note: The MIS-file LMuu01.POM is stored in a non-readable format.

In case of a system upgrade, the MIS file can not be used. Upgrading has to be done using the retrieve files.

4.4. INSTANTANEOUS CONFIGURATION FILE

When a system is operational for a while and a lot of changes have been made to the

97

configuration of the unit(s) is it possible to generate a readable file containing the instantaneous configuration.

By executing the OM command RTRIEV the configuration database in the CPU memory is converted into subcommands and stored in the files PRuu.POM (equivalent to the PEuu.POM file) and ORuu.POM (equivalent to the LLuu.POM file). These files can be transferred to a PC or SMPC and converted to the PC format. By examining the subcommands and the related parameters it is possible to analyse the current situation. It is also possible to note the changes in the original Office Data Manual.

By generating these instantaneous configuration files it is also possible to change boundaries in the configuration database. In the PRuu.POM file the concerning boundary can be adapted with a normal word processing program. The files are renamed to PEuu.POM and LLuu.POM, converted to ISPBX format and transferred to the BIM (iS3070/3090 with CCS) or CPU (all other systems). The change is validated after a restart.

Note: If the restart is forced by a cold start, the MIS-file must be deleted from the BIM/CPU. The MIS-file has a higher priority than the configuration files and if the MIS-file is present, this file is loaded during the cold start and NOT the new PE-and LL-files.If the restart is forced by the OM command RESTRT, the MIS-file is ignored and the PEuu.POM and LLuu.POM files are executed.

4.5. DISPLAYING THE CONFIGURATION

Most parts of the configuration database can be read-out by using the appropriate display command. If the Office Data Manual is not up-to-date any more or not available, OM-commands are available to display the configuration of the ISPBX system.

With the OM command DIBRDS, the data concerning the board that is projected in a certain position in the shelf can be displayed.

For PM-boards this means that the board type, the hardware test type, the signalling group and the type of circuits on the board are displayed.

For CM or SM boards of iS3070/3090 and for CPU or CSN-BC boards of other systems, only the board type is displayed. These boards do not have a signalling group.

With the OM command DICONF the way a certain resource (circuit, board or shelf) is controlled can be displayed. The output is a graphical output on the screen of the OM terminal. It indicates the way the specified resource is controlled via the control sides of the ISPBX unit together with the directly related resources. The actual status of the resources is also indicated.

98

With the OM command DISHLF the layout of all positions in a shelf are displayed and in the next line an 'x' indicates in which position a board is projected.

With the OM command FIPCTT the type of resource can be entered. The ISPBX searches its configuration and displays the EHWA of all resources of that particular resource type.

The various PM and PPH projecting data can be displayed with the OM commands DIPMPD and DIPPHD.

4.6. SOFTWARE DOWNLOAD OF PERIPHERAL BOARDS

With the introduction of Flash-EPROMs (FEPROM) on a number of peripheral boards, it is possible to change the software on these boards, without the necessity of PROM replacement. Software downloading is not possible for all types of boards, see table below for a list of the boards supporting downloading.

The system download is executed by the system when a board (under certain conditions) is found erased (FEPROM empty). The system engineer can execute the download actions using OM commands.

A set of files (FEPROM files) must be present on the LBU of all units in an iSNet. The system maintains the relation between the board (sub-)type and the software package file (FEPROM files) which will be downloaded. This relation is defined during the software installation procedure and kept in the system memory.

Data compression/de-compression is used to minimize the download time.

The FEPROM/RAM file names are Fcpppv.vll or Fccppv.vll, in which :'F' : all FEPROM/RAM file names start with an 'F'.'c' or 'cc' : indicates the type of board:

14 or 15 = PMC-HR/MC/LU18 = PMC-G22 = DTX-I / DTX-I (R) note 132 = DLC-U33 = DLX-U34 = DLX-L43 = DCC46 = DCC-851 = DTU-VC52 = ALC-G6x = CPU3000 without AM3000 note 282 = PM Observer

99

4.6.1. Download Initiation

The download function is initiated in the following situations:

- when at activation of the board, the board is found empty (during a cold start, warm start or SETINS command);

- when the system engineer initiates the download function by erasing the software package on the board (OM command DEPACK) and setting the board into service.

The board replies 'empty' if the contents of the FEPROM have been erased. The board may also reply 'data corrupted', indicating that the contents of the FEPROM are invalid and should therefore be erased first. If this happens during a cold start or warm start, the board is erased by the system, otherwise alarm 067, qualifier 10 is generated.

In the case of a hot start, the board is not downloaded; the board will go into error and alarm 067, qualifier 11 is generated.

9x = CCS and CPU3000 with AM3000 note 2A0 = SNSA1 = CIEB0 = Primary boot CPU3000 note 3B6 = Boot program CPU3000 without AM3000 note 4B9 = Boot program CPU3000 with AM3000 note 4E3 = ErgoLine D330E4 = ErgoLine D340E5 = ErgoLine D325

'ppp' or 'pp' : indicates the package-identity.'v.v' : indicates the version.'ll' : indicates the level update.

Notes 1 F220xx for DTX-I and F221xx for DTX-I(R)2 Package downloading is not under CPU control. Package-ids are

only displayed with OM command DIEXID.3 Primary boot program downloading is not supported in the field.4 OM command STLOBP has to be followed for this package.

Examples :F22010.105 : DTX-I package 201.01.05FA0000.304 : SNS package 000.03.04F98102.041 : CCS package 810.20.A (41 is the hex value for 'A')

100

4.6.2. Download Execution

The execution of the download includes the following:

• Software InstallationThe software installation is executed by OM command INSTPK, or by projecting.

• Software Package ValidationWhen a download takes place, the system validates the file attributes of the FEPROM file. If validation fails, the download is not executed and alarm 051, qualifier 40 is generated.

• Single DownloadSingle (or immediate) download means that the download action is executed after the request is made. When the validation is correct, the download process reads the FEPROM file and sends the data to the board.The maximum number of concurrent single downloads is limited by system parameter LOBOUND 189. When this maximum number is reached, the execution of new download requests is postponed.The single download occurs when a download request is issued in an operational system (the system is not in the starting up phase).

• Parallel DownloadParallel download is downloading the same software to several boards. The FEPROM file is read once and the data is sent to all boards. Parallel download occurs when boards are downloaded during a system start, cold or warm start.When the download is finished, all boards are taken into service.The download is executed in two phases. First all PMCs are downloaded and after that the DTXs and DLCs are selected.The maximum number of PMCs concurrently busy with a parallel download action is defined by LOBOUND 190.

4.6.3. OM Commands

The following OM commands are used : DEPACK (to delete the package of a given board), DIPACK (to display the projected and loaded package-id of a given board), CHBDST (to change the board sub-type), ASBRDS / DIBRDS (to assign or display the board sub-type) and INSTPK (to make the relation to the new software package).

• Software InstallationThe board subtype is assigned to the system by OM command ASBRDS and it can be changed by OM command CHBDST. The board subtype is used when a number of software packages are available for one board type. The system maintains the relationship between the board type, board sub-type and the software package which will be downloaded. This relation is defined during the software installation procedure by OM command INSTPK, or by projecting. To select the Flash-EPROM (FEPROM) file of the

101

concerned board, the board type and board subtype are used by the download process. The software package is present in a (FEPROM) file on the LBU of the system. The command is also used to delete the relations.There are six possible ways to use this command:- all boards with sub-type null are related to the package;- all boards with the mentioned sub-type are related to the package;- all boards with references to the 'old-package' and with sub-type null are replaced by

the 'new-package';- all boards with references to the 'old-package' and with the mentioned sub-type are

replaced by the 'new-package';- all related boards with references to the 'old-package' and with sub-type null are

deleted;- all related boards with references to the 'old-package' and with the mentioned sub-

type are deleted.A system timer is started (NETIMER 152); this timer defines how long the CPU waits for a response to the download command.

• Delete Software PackageThe software package can be deleted from the FEPROMs using OM command DEPACK:- if the board is a PCT board, the board must be out of service and the concerned PM

must be in service;- if the board is a PMC, the board must be out of service but the system must be able

to communicate with the PMC.If one of those pre-conditions is not fulfilled the OM command is rejected.A system timer is started (NETIMER 153); this timer defines how long the CPU waits for a response to the delete command.

• Display Software PackageThe software package present in the FEPROMs on the board can be displayed using the OM command DIPACK. The displayed data includes the software package-id of the projected package and the software package-id projected in the system per board type and board sub-type.

• Display hardware identification'Identification of 12nc(s) and SB numbers of boards' gives the possibility to display the 12nc(s) or SB numbers of some boards, by means of the OM command DIEQID.With DIEQID, it is possible to retrieve the identification of the following boards: ALC-G, DCC, DLX-U, DLX-L, CIE and CPU3000.The function is always present but it can only retrieve the identification from a piece of hardware when the equipment queried is able to generate its identity and is 'in service'.When an attempt is done to get information from a board that does not support identity retrieval, then:- An error message is produced, if the identity request concernes a single board,- The boards that are not supporting this function are skipped, if the identity request

102

concernes a range of items.

Note: The information is retrieved from the board themselves and not from the CPU memory.

4.6.4. Install New Software of Peripheral Boards

A new software release of one type of board can be installed by a modification kit. The modification kit contains the new package file (Fxxxxx.xxx).

To install the new package execute the following actions:

1. Copy the new package file to the LBU.2. Execute OM command INSTPK.

This command replaces all references to the 'old package' by the 'new package'; the command just updates the CPU database, no download is executed yet.

3. Execute OM command SETOUT, to put the board out of service.4. Execute OM command DEPACK, to delete the 'old package', when present.5. Execute OM command SETINS, to set the board in service; now the new package is

loaded.

4.6.5. Install new software Variant

In some situations it is recommended to install the new software in a few boards only, to test the software before installing it in the rest of the system.

For example, the DTX-I package '201' supports the 1TR6 protocol. Later a new DTX-I package '202' is released for the QSIG protocol in the application 'ISDN-trunk/tie line'. It might be possible that a user wants both packages installed in the system and that only some boards should be reprogramed. In this case, execute the following actions:

1. Copy the package file to the LBU.2. Execute OM command INSTPK: <new-pack>, ,1;

This command defines a new relation for the DTX board type and board sub-type (01), referring to the new package. The command just updates the CPU database, no download is executed yet.

3. Execute OM command CHBDST to define the DTX board with the new sub-type.4. Execute OM command SETOUT, to put the board out of service.5. Execute OM command DEPACK, to delete the 'old package', when present.6. Execute OM command SETINS, to set the board in service; now the new package is

loaded.

103

4.7. TERMINAL DOWNLOADING

Terminal downloading enables a maintenance-engineer to download new software into the terminals of a certain type without replacing any hardware. Terminal downloading can be done from a centralised location, for example a remote maintenance centre. The whole process consists of removing the present software package and replacing it with another (new) package.

The download function is initiated with the OM command STDOTE.

If one download is started, no other downloads can be executed because one download is permitted at the time.

Only idle terminals, loaded with a package that is not similar to the provided software package, or no software package, are downloaded. The firmware package of the terminals that have to be downloaded must be on the LBU (in all units).

Since terminal downloading is a CPU time consuming action, it is recommended to do this downloading preferable outside working hours. Downloading of terminals is done in parallel. During downloading the terminal is 'non-operational'.

Downloading is supported for the ErgoLine D325, D330 and D340 with terminal firmware package 2.01 onwards.

Downloading of those terminals is possible when connected to a DTX-I, DLX-U or DLX-L with PNT-L. Some boards need a new firmware package to support the specific feature; see table below.

Table 4-1 Firmware Packages of Boards

Note: On a DTX-I board, it is not possible to download to Ergoline terminals if the board is assigned for trunks while some circuits are assigned as extension.The board should be assigned as an extension board and after that some circuits may be assigned as trunk. In that case downloading to the terminal is possible.

BOARD FIRMWARE PACKAGE

PMC F1141.05.01 / F1151.05.01

DTX-I F2203.11.01

DLX-U F3300.04.01

DLX-L with PNT-L F3400.03.01

104

The PPU in a PM2500 shelf does not support terminal downloading.

After a download action of the terminals, the maintenance engineer can check whether the download was successful or not using OM command DIDOTE. OM command DIEQID can be used to check which package is present in the terminal.

105

5. PERFORMANCE MANAGEMENT

For the system manager it is very useful to know how the ISPBX is performing. This is important to find out if the number of resources is enough for the offered traffic to the ISPBX. Performance management can also be used to determine if there are enough trunk and tie lines to the PSTN and/or other PABXs. To gather this statistical data two facilities are offered by the ISPBX, traffic observation and traffic measurement. These facilities and their possibilities will be discussed here.

A second point of interest is the performance of the ISPBX CPU. The main function of the CPU is call processing. Nevertheless system assurance and operational maintenance must also be assigned some processor time for the maintenance of the ISPBX system. The guarding of the CPU activities will also be discussed in this chapter.

5.1. TRAFFIC OBSERVATION AND MEASUREMENT

Traffic measurement results give the system manager the possibility to retrieve data from the CPU of a ISPBX unit concerning the traffic handled by the system. This data can be retrieved by observing a specific group of resources (circuits) within the system. These resources are called OBJECTS. These objects can be divided into:

Data about Network or CircuitsObject 0 = Exchange and Tie Line Bundle data;Object 1 = Exchange and Tie Line Route dataObject 2 = Inter Unit Bundle data;Object 3 = Inter Unit Route data;Object 6 = Paging Route data (real or virtual paging);Object 7 = Data about the Add-on Circuits;Object 8 = Data about the RKT-SDT circuits;Object 9 = Data about the SKT-RDT circuits;Object 10 = Data about the Incoming MFC Circuits;Object 11 = Data about the Outgoing MFC Circuits;Object 12 = Data about the RS-Socotel Circuits;Object 13 = Data about the Convertors;Object 16 = Data about Switching Network Channels;Object 18 = Inter Unit Traffic Dispersion data.Object 21 = Hatches.

Data about UsersObject 4 = Data about All Extensions in a Unit;Object 5 = Data about Extension Groups;

106

In the traffic measurement two types of data are retrieved: static data and dynamic data.

Static data informs the user about the amount of resources in a specific state. For example the number of operators with the status OUT, ABL, NIN and the total number of operators. Static data is the data that is controlled by the system assurance or operational maintenance software. With this software the service condition of the resources in the system can be controlled. Static data can comprise:

- Number of resources in OUT;- Number of resources in ABL;- Number of resources in NIN;- Total number of resources in a pool.

Dynamic data informs the user about the traffic that the system handles and if there are enough resources to handle this traffic. Dynamic data can comprise (depending on the type of resource):

- Number of busy resources;- Number of ringing resources;- Number of congested resources;- Number of camp on busy situations on resources.- Number of calls in queue of resource;

The traffic measurement information (static and dynamic) can be generated in different forms: as traffic observation or as traffic measurement. Both forms will be described in the following parts of this chapter.

5.2. TRAFFIC OBSERVATION

Traffic observation can be used to observe the instantaneous situation of the dynamic and static information of all resources of the specified type on the display of a VDU.

Object 19 = Dialled Facilities data.

Data about OperatorsObject 14 = Operator data;Object 15 = Operator Queue data (queue determined by the call type and the

assistance group).

Data about CallsObject 17 = Call data.

107

When executing OM command DITRAF, the system asks for additional parameters. After entering these parameters, the system starts continuously scanning the specified resources. For this command the mentioned resources numbered 0 to 17 can be used. The resource types 18 and 19 can only be used in traffic measurement.

The DITRAF-command first displays the static data of a resource type (if applicable): the number of circuits in service condition OUT, ABL or NIN and the total number of circuits in the pool. This information is gathered only once after executing the DITRAF command. This data informs the system manager about the number of resources out of a pool that can actually be used by call processing.

The static data is followed by the dynamic data: the number of busy, ringing, congested circuits or the number of camp on busy cases. This dynamic data is continuously displayed. Each time the call processing status of a circuit changes, the dynamic information is updated.

The static data is repeated after a number of lines of dynamic data. This enables the user to see static data together with the dynamic data.

This DITRAF command can only be stopped with the CTRL-X combination. This action cannot be performed in a batch job. If this command is executed in a batch job the dynamic data will be displayed once after which the execution of the command will be stopped.

5.3. TRAFFIC MEASUREMENT

Traffic measurement is a method of observing a group of resources to obtain average values for the traffic handled by the system. Some examples: the carried load (Erlangs), average holding time of a resource, the number of seizures of a trunk line. For this kind of information the scanning should be performed during a certain period.

The resources or object-groups are identified by the corresponding numbers as discussed earlier.

Traffic measurement observes all resources that are mentioned in an object list (See below) during a certain period. The total period is divided into intervals of 15 minutes. During these intervals the event changes (dynamic data) for all circuits of a resource type are counted. Also during these intervals a scan for the static data is performed. The scan is performed at the beginning of each observation interval of 15 minutes and is performed only once per interval because this scan causes a large amount of loading on the system.

After an observation period, average traffic values are calculated which are related to the time of the interval (15 minutes). These average values for the last interval of 15 minutes can be read out with OM command DISPTO (figure type 0) or stored on a device. With OM

108

command DISPTO (figure type 1) it is also possible read out the cumulative averages for a measured object. These cumulative averages are calculated from the start of the measurement period up to the last quarter hour for that object.

5.3.1. Object List

The object-groups that are to be observed in the traffic measurement must be included in the object list. When assigning an object to an object list, most of the time the system manager must enter the unit number in which the defined resources must be observed. Therefore the object list is a list of all the resources in a unit that must be observed.

An object-group can be assigned to the object list with the OM-command ASTMOB. This command asks for additional information to be entered by the system manager.

The command DETMOB is used to delete one object-group from the object list. This command also asks for additional parameters.

The object list can also be deleted all together with the command ERTMLI. The object list in the specified unit is deleted.

To display the object list for a specific unit the command DITMOB can be used.

The objects that are specified in the object list are observed simultaneously.

When an object is assigned to the object list while traffic measurement is active, the observation of the newly added object will start at the beginning of the next 15 minutes. The cumulative output figures will be calculated over the number of quarter hours that the object has been in the list (so they will be correct), but no indication is given that the object has not been observed during the full observation period.

When an object is removed from the object list, no output for that object will be given from that moment on. Even when the figures are calculated, they will not be output when an object has been deleted.

Due to data storage reasons, it will not be possible to observe all objects at the same time. The following object groups can always be included in the object list:

4 = all extensions in unit7 = add-on circuits8 = RKT-SDT circuits9 = SKT-RDT circuits10 = incoming MFC circuits

109

Boundaries

- For the object groups 0 (exchange and tie line bundles), 1 (exchange and tie line routes), 2 (inter-unit bundles), 3 (inter-unit routes) and 6 (paging routes) together only a limited number of objects can be observed. The maximum number of observed objects is limited by the 'fixed' boundary BOUND 148 (maximum no of observed routes and bundles). This boundary is set to 50.

- For the object group 5 (groups) the maximum number of groups that can be included in the object list is limited by a 'fixed' boundary BOUND 147 (maximum no of observed groups). This boundary is set to 10.

- For the object group 13 (convertors) the maximum number of convertor types that can be observed is limited by the 'fixed' boundary BOUND 149 (maximum no of observed specific convertors). This boundary is set to 1. This means that when including object group 13 in the object list either all convertors in the unit or the convertors belonging to one specific convertor type can be specified.

- For the object group 15 (operator queues) the queues of only a limited number of assistance groups can be observed. The maximum number of observed assistance groups is limited by the network boundary NEBOUND 214 (maximum no of observed assistance groups). Due to load constraints it is advisable to limit the value of this boundary to 3.

- For the object group 19 (dialled facilities) all dialled facilities can be observed per unit but only for one specific analysis group.

5.3.2. Output Destination

Each unit performs the measurement of the objects that are included in the object list for that particular unit (defined when assigning an object-group to the object list). The traffic measurement data available at the end of each interval of 15 minutes can be directed to a file on a device within the iS3000 iSNet.

The DEVICE where the traffic measurement figures are sent, is defined with the command CHTMOD. With this command the logical device name, where the measurement figures are sent to, is related to the unit which generates these figures. A number of units can direct the output of the figures to the same device. With the same command the output device can also be deleted (omitting the output device when executing the command).

11 = outgoing MFC circuits12 = Socotel circuits14 = operators16 = switching network channels17 = calls18 = inter-unit traffic dispersion21 = hatches

110

With the command DITMOD the defined output devices for all units are displayed.

When a new device is assigned while traffic measurement is active, the device is not used until a new observation is started.

The FILE NAME where the traffic measurement figures are stored, is defined with the command CHTMOF. When executing this command, the system manager does not have to assign the file extension. The system generates a file for each unit with the defined file name with the extension ".Uuu" where uu denotes the unit number. This file is opened on the device related to that unit. With the same command the output file can also be deleted (omitting the file name when executing the command).

With the command DITMOF the defined output file name is displayed (same for all units except for file extension).

When a new file is defined while traffic measurement is active, the file will not be used until the next quarter hour data becomes available and the old quarter hour data has been output completely. In this way it is possible to process intermediate measurement results.

For future improvements, device type 9 (traffic measurement output device) is reserved within ISPBX. However, do not use device type 9 at this moment.

If an output device and an output file are defined for the unit that finishes an observation interval, the ISPBX unit writes the traffic figures for the last interval into that file.

It is also possible to display the traffic figures per object on the display of an OM terminal. With the OM command DISPTO the figures for a specific object-group can be read out. With the additional parameter 'figure type', the user can choose which traffic measurement figures are required:

- Last quarter hour figures (figure type 0).For the selected object the figures related to the last observation interval of 15 minutes are presented. The figures represent the average values for dynamic data and the values at the beginning of the interval for static data.

- Cumulative figures (figure type 1).For the selected object the figures related to the already finished intervals in the total traffic measurement observation time are presented. The figures represent the average cumulative values for the dynamic data. No static data is shown.

If the traffic measurement is in the first interval of 15 minutes, the figures are not available yet and the system will display 'no figures available yet' when executing the DISPTO command.

111

5.3.3. Manual Starting / Stopping the Traffic Measurement

A traffic measurement session can be started manually from an OM terminal by the OM command STRTTM. When executing this command, the number of observation intervals must be specified. This parameter has a minimum of 1 and a maximum of 254 intervals of 15 minutes.

The traffic measurement can be stopped, even if not all observation intervals have been finished, by the OM command STOPTM.

5.3.4. Timed Starting / Stopping the Traffic Measurement

The traffic measurement session(s) can also be started by defining a 'ON-TIME' (day-of-the-week, hour, minute) with the OM command ASTMTI. At this time the traffic measurement will start for the objects in the object list. When this command is executed, the number of observation intervals have to be defined for which the observation is being performed. A third parameter defines if the observation must be performed cyclically (weekly) or only once.

A timed start of the traffic measurement session can also be deleted by erasing the 'ON-TIME' from the timing list with the command DETMTI.

With the command DITMTI the list of programmed 'ON-TIMES' can be displayed.

The maximum number of measurement periods that can be defined is limited by NEBOUND 038 (maximum number of interval times). This boundary has a fixed value of 32 measurement periods.

5.3.5. Traffic Measurement Status

To display the status of the traffic measurement, the OM command DISPTM can be used. This command displays the measurement status (running or ended), the status of the output file (open or closed), the current observation interval and the total number of time intervals for the total traffic measurement session.

5.3.6. Load Caused by Traffic Measurement

The introduction of the Traffic Measurement facility will affect the ISPBX CPU load, especially on the 'non CCS platform' systems. The introduced load can be divided into:

• Traffic measurement OM commandsWhen executing an OM command related to traffic measurement, it will obviously be an extra load for the CPU. Loading due to OM commands however is controlled and approved by the 'load control' software of the ISPBX. Therefore the execution of OM

112

commands related to traffic measurement does not introduce unacceptable loading of the system as 'load control' guards this loading.

• Changing momentary counters for the objectsTraffic measurement is based upon counting events within objects. Any action leading to a status change of an object will update the required counters. This function is always active within the 'Resource Management' software. Therefore, keeping track of the counters is considered a part of the normal call control load and not quantified to the traffic measurement facility.

• Performing the switch count scanningSome resources have to be scanned to determine a state change of a resource. This scanning is controlled by a number of timers and the values of these timers determine the loading of the ISPBX CPU. This extra load only occurs for the actively measured objects and is only present during the measurement session.With an average object list and the scan timers (see section 5.4.1. "List of Objects and Entities") set to default values, the switch count scanning will take about 240 ms/minute (load of 0,4%). Changing the scan timers will influence the CPU load.

• Gathering and storing the interval figuresWhen a traffic measurement session is in progress, after each period of 15 minutes the various counters have to be gathered and stored to enable calculation of the interval figures.For an average object list, about 1,45 seconds will be used in each period of 15 minutes for gathering and storing the counters and calculating the interval figures.This load can be influenced by changing the traffic measurement object list.

• Writing the interval figures to the outputIf an output device and file name are specified, after each period of 15 minutes the traffic measurement data has to be output. Note that the speed of the output device has no influence on the required load although it does affect the throughput.An average observation list would require about 2,2 seconds each interval period for outputting the figures.The introduced load can be influenced by changing the object list.

As shown, traffic measurement will not overload the CPU in default conditions. A peak load is introduced however, when the interval data is handled (gathering, storing and outputting the interval figures).

5.3.7. Performance Manager Module on the SystemManager

Traffic measurement can be controlled from a terminal, without the need to know OM commands. For this, connect a SystemManager with Performance Manager module to the ISPBX (network). The user interface is menu-driven, and allows definition of object list, output destination and timing. Measurement status can be displayed and observation groups defined.

113

Measurement results can be transferred into a database and used for presentation of reports and trends, in graphical or tabular form. Traffic observation (DITRAF) and display of object figures (DISPTO) is not supported by the Performance Manager.

For more information, see the Advanced User Manual of the SystemManager.

5.4. OVERVIEW OF MEASUREMENTS

5.4.1. List of Objects and Entities

In the following part, a list of the dynamic and static data together with the measurement method for the dynamic data is given per resource type. The data below is the file output data.

• Object 0 - Exchange and Tie Line BundlesAdditional information: bundle, unit

• Object 1 - Exchange and Tie Line RoutesAdditional information: route

• Object 2 - Inter Unit BundlesAdditional information: inter-unit bundle, unit

Static data: - total number of lines in the bundle- number of lines in OUT- number of lines in ABL- number of lines in NIN- total number of B-channels- number of not usable B-channels

Dynamic data: - average holding time calculation- carried load (erlang) switch count scan- number of incoming seizures count during interval- number of outgoing seizures count during interval- number of times congestion is met count during interval

Static data: - total number of lines in the route- number of lines in OUT- number of lines in ABL- number of lines in NIN- total number of B-channels- number of not usable B-channels

Dynamic data: - number of times COB is started count during interval- number of times COB leads to seizure count during interval- number of times congestion is met count during interval

114

• Object 3 - Inter Unit RoutesAdditional information: inter-unit route, unit

• Object 4 - All Extensions in a UnitAdditional information: unit

• Object 5 - Extension GroupsAdditional information: group-DNR

Static data: - total number of lines in the inter-unit bundle- number of lines in OUT- number of lines in ABL- number of lines in NIN

Dynamic data: - average holding time calculation- carried load (erlang) switch count scan- number of times congestion is met count during interval

Static data: - total number of lines in the inter-unit route- number of lines in OUT- number of lines in ABL- number of lines in NIN

Dynamic data: - number of times congestion is met count during interval

Dynamic data: - average holding time calculation- carried load (erlang) switch count scan- number of times COB is started count during interval- number of times COB leads to ringing count during interval- number of times ringing is started count during interval- average ringing time calculation- number of times call has been answered count during interval

Static Data - number of present group members count at start of interval- number of absent group members count at start of interval

115

For observing a group of extensions that are not located in a real group arrangement, an observation group can be created. Such a group arrangement (group property 28) has no facilities as offered to other groups.

• Object 6 - Paging RoutesAdditional information: paging route

• Object 7 - Add-on circuitsAdditional information: unit

• Object 8 - RKT-SDTsAdditional information: unit

Dynamic Data - average holding time calculation- carried load (erlang) switch count scan- average length of the COB queue switch count scan- average time spent in COB queue calculation- number of times COB is started count during interval- number of times COB leads to ringing count during interval- number of times a busy member is met count during interval- number of times ringing is started count during interval- average ringing time calculation- number of times call has been answered count during interval

Static data: - total number of lines in the paging route- number of lines in OUT (real paging only)- number of lines in ABL (real paging only)- number of lines in NIN (real paging only)- number of codes (virtual paging only)

Dynamic data: - average holding time calculation- carried load (erlang) switch count scan- number of times COB is started count during interval- number of times COB leads to seizure count during interval- number of times congestion is met count during interval

Static data: - total number of add-on circuits- number of circuits in OUT- number of circuits in ABL- number of circuits in NIN


116

• Object 9 - SKT-RDTsAdditional information: unit

• Object 10 - Incoming MFC CircuitsAdditional information: unit

• Object 11 - Outgoing MFC CircuitsAdditional information: unit

• Object 12 - RS-Socotel CircuitsAdditional information: unit

Static data: - total number of RKT-SDTs- number of circuits in OUT- number of circuits in ABL- number of circuits in NIN


Static data: - total number of SKT-RDTs- number of circuits in OUT- number of circuits in ABL- number of circuits in NIN


Static data: - total number of RST-IMs- number of circuits in OUT- number of circuits in ABL- number of circuits in NIN


Static data: - total number of RST-OMs- number of circuits in OUT- number of circuits in ABL- number of circuits in NIN


117

• Object 13 ConvertorsAdditional information: convertor-type, unit

• Object 14 - Operators and Individual QueuesAdditional information: operator DNR, unit

The following individual queues (in brackets: the numbers given in the output file) can be distinguished:- M-individual (0);- C-series (7);- C-taxmetering (8);

Static data: - total number of RST-SLs- number of circuits in OUT- number of circuits in ABL- number of circuits in NIN


Static data: - total number of convertors- number of convertors in OUT- number of convertors in ABL- number of convertors in NIN


Static data: - total number of operator circuits- number of circuits in OUT- number of circuits in ABL- number of circuits in NIN

Dynamic data per operator for all individual and general queues:- average call handling time calculation- carried load (erlang) switch count scan

Dynamic data per operator and individual queue:- average queue length switch count scan- average queue time calculation- number of times a call has been queued count during interval- number of queued calls that were handled by the operator

count during interval

118

- C-through connection busy (9);- C-preferred (10);- C-through connection ringing (11);- WA (28);- UA (29).

• Object 15 - Operator General QueuesAdditional information: queue-type, assistance group, unit

The following general queues (in brackets: the numbers given in the file output) can be distinguished:- M-normal (1);- M-preferred (2);- C-DDI not answered (3);- C-DDI unsuccessful (4);- C-recall not on hook (5);- C-recall on hook (6);- A1, A2 ... A16 (12, 13 ... 27).

• Object 16 - Switching network channelsAdditional information: shelf, , circuit (PM-module)

• Object 17 - CallsAdditional information: unit

A distinction between various call types is made:0 = extension - extension call (ext - ext)1 = operator - extension call (ope - ext)2 = operator - trunk call (ope - trk)3 = operator - other call (ope - oth)4 = night extension - extension call (ne - ext)

Dynamic data per general queue:- average queue length switch count scan- average queue time calculation- number of times a call has been queued count during interval- number of queued calls that were handled by the operator


Dynamic data: - number of times congestion is met count during interval

Dynamic data: - average call duration calculation- number of established calls count during interval

119

5 = night extension - trunk call (ne - trk)6 = night extension - other call (ne - oth)7 = extension - trunk call (ext - trk)8 = trunk - extension call (trk - ext)9 = extension - paging call (ext - pag)10 =trunk - paging call (trk - pag)11 =trunk - trunk call (trk - trk)In multi-unit systems for all call types two figures will be available: one for intra-unit calls and one for inter-unit calls.

• Object 18 - Inter Unit Traffic DispersionAdditional information: unit

The inter-unit traffic dispersion will show how many inter-unit call attempts have been made from source unit x to (far) destination y via, or originating from, the unit that is being observed.

• Object 19 - Dialled FacilitiesAdditional information: analysis group, unit

The facility counters are split up into three groups indicating the type of caller: internal, external, assisted.

• Object 21 - Hatches

5.4.2. Measurement Methods

Several traffic measurement methods are used. Before explaining the meaning of the measured entities, first the measurement methods will be described. The following methods are used.

• Static CountingWith static counting, the value of a counter is read at the beginning of a measurement interval. A scan over the resources is performed to determine the service conditions and this information is stored. Although counters may have changed during the interval, the value it had at the beginning is reflected in the output figures for that quarter hour. An example of such a measurement is the number of RKT-SDT circuits in the service conditions OUT, ABL, NIN and the total number of circuits in the unit.

• Dynamic Counting

Dynamic data: - number of inter-unit call attempts count during interval

Dynamic data: - number of times the various facility codes are dialled in the system


120

With dynamic counting, a number of occurrences is counted during the quarter hour. At the end of the quarter hour the value of the counter is reflected in the figures for that quarter hour.Examples of such a measurement are the number of times Camp On Busy is started or the number of incoming calls.

• Busy Switch CountFor some resources the busy switch count method is used. With the busy switch count method it is possible to determine, over the observed period, the average number of resources in a specific state, for example, busy. The resources are scanned at predefined intervals. The number of resources which are in the specific state are counted and added to a total. This total is divided by the number of performed switch counts (scans). This results in an average value.Using the example shown in Figure 5-1 "Example of the Busy Switch Count Method".

An example of such a measurement is the carried load.

Figure 5-1 Example of the Busy Switch Count Method

The mathematical accuracy (perceptual error) of this method can be expressed with the following formula:

Provided that Ts < or equal 2 x t

Average = 1+5+8+6+1+4+5+3+2+1+4+5+5+3+1 = 3,615

Vs = 1,36 x Tssquare root (a x t)

121

This means that the more scans are made per period the more accurate the average value is determined. The scan interval (Ts) is defined by projected values for six resource groups.

WARNING: DO NOT CHANGE THESE PROJECTED VALUES WITHOUT WRITTEN APPROVAL FROM YOUR LOCAL SERVICE PROVIDER. THESE SETTINGS ARE OPTIMISED FOR PERFORMANCE VERSUS MEASUREMENT ACCURACY.

The timers for the six resource groups are:

Where Vs = perceptual errorTs = scan interval in secondsa = average number of resources in a specific state (for example: busy)t = average time in seconds that a resource is in a specific state

NETIMER 085 Traffic measurement extension scan time.Minimum 10 seconds; default 30 seconds.

NETIMER 086 Traffic measurement trunk scan time.Minimum 10 seconds; default 30 seconds.

NETIMER 087 Traffic measurement paging scan time.Minimum 10 seconds; default 30 seconds.

NETIMER 088 Traffic measurement operator scan time.Minimum 1 seconds; default 10 seconds.

NETIMER 089 Traffic measurement auxiliary scan time.Minimum 1 seconds; default 5 seconds.

NETIMER 090 traffic measurement call scan time.Minimum 10 seconds; default 30 seconds.

122

Table 5-1 Timers used for the Busy Switch Count Method

INDEX is the index of the timer which is used when the timer is to be read with the OM-command DIMDAT or changed with the OM-command EXSUBC.

• CalculationsSeveral entities are calculated. The input for these calculations are the dynamic counters and / or the average values determined with the busy switch count method.When an entity is calculated the formula used will be presented.When calculations are performed, be aware that figures are rounded off to two decimal places.

5.4.3. Definitions

• Definition of Park- and Line Positions with respect to Traffic MeasurementPark- and line positions are special locations related to extensions or groups.Behaviour of park-position:When a call is put on a park position this is seen as a release for the extension which puts the call on the park position. A call on the park position is not busy, moreover it is not seen by traffic measurement any more.Behaviour of line-position:When a call enters a line-position the extension which owns the line-position is in the ringing state. The extension which originated the call is in the busy state.

• Definition of the Busy StateFor a number of objects the Carried Load is determined using the busy switch count method. The definition of the busy state for these objects is given in Table 5-2 "Definition of Busy State".

NETIMER INDEX DEFAULT VALUE

NUMBER OF SCANS

USED IN OBJECT

Extension scan time 085 30 900 / 30=30 4, 5

Trunk scan time 086 30 900 / 30=30 0, 2

Paging scan time 087 30 900 / 30=30 6

Operator scan time 088 10 900 / 10=90 14, 15

Auxiliary scan time 089 5 900 / 5=180 7, 8, 9, 10, 11

12, 13

Call scan time 090 30 900 / 30=30 17

123

Table 5-2 Definition of Busy State

• Definition of a Seizure

OBJECT BUSY WHEN

0 Exchange and Tie Line Bundles

Outgoing/incoming call in progress. This means call in phase set-up,conversation or release. Not for inter-unit traffic.

2 Inter Unit Bundles See object 0. Now only for interunit traffic (iSNet traffic).

4 All Extensions in a Unit Handset is lifted or extension start ringing until call is released.

5 Extensions Groups Handset of group member is lifted or group member starts ringing until call is released.

Note: Calls to an individual member are also seen as busy time for the group.

6 Paging Routes Real paging: ISPBX is sending information to pager.

Virtual paging:Paging is activated by the operator until paging call is answered or released prematurely.

7 Add-on Circuits Break-in or three party conference is performed or ticker-tone or

call-waiting tone is given.

8 RKT-SDTs 1) Keytone extension dials.

2) Incoming keytone trunk receives keytones.

3) Rotary-dial extension goes off-hook until first digit dialled.

9 SKT-RDTs Outgoing trunk when sending keytones to opposite exchange.

10 Incoming MFC Circuits See 2) of object 8 but now for MFC signalling.

11 Outgoing MFC Circuits See object 9 but now for MFC signalling.

12 RS-Socotel Circuits See 2) of object 8 and object 9 but now for socotel (MFE) signalling.

13 Convertors Modem from modem pool is used.

14 Operators Operator is busy with call handling. All call phases are seen as busy. Operator is not busy when a call is in a queue or when operator performs OM.

21 Hatches

124

For a number of objects the Seizures are counted. The definition of a seizure for these objects is given in Table 5-3 "Definition of Seizure".

Table 5-3 Definition of Seizure

• Definition of the Conversation StateIn object 17, Calls are measured. For a call the conversation state is defined as that phase

OBJECT SEIZURE WHEN

0 Exchange and Tie Line Bundles

Number of times a line is selected not neccessarily resulting in a successful call (collision, number unobtainable etc).

2 Inter Unit Bundles See object 0.

4 All Extensions in a Unit Calling parties: going off-hook.

Called parties: when ringing starts (not neccessarily answering).

5 Extensions Groups See object 4. No distinction between individual or group calls.

6 Paging Routes Number of times paging is started.

7 Add-on Circuits Number of times break-in or three party conference is performed or ticker-tone or call-waiting tone is started.

8 RKT-SDTs 1) Keytone extension initiates a new call.

2) Incoming call arrives over keytone trunk.

9 SKT-RDTs Outgoing call is initiated over keytone trunk.

10 Incoming MFC Circuits See 2) of object 8 but now for MFC signalling.

11 Outgoing MFC Circuits See object 9 but now for MFC signalling.

12 RS-Socotel Circuits See 2) of object 8 and object 9 but now for socotel (MFE) signalling.

13 Convertors Number of times a modem from the modempool is used.

14 Operators 1) A call in a queue is answered.

2) A new call is initiated (PA or PB).

Note: When the operator has a party on hold then PA or PB is no seizure, this is an ongoing call.

18 Inter Unit Traffic Dispersion

See Object 0.

21 Hatches

125

of a call during which a speech connection is present. The following additional situations can be distinguished:- For an extension-trunk call the conversation state can be reached before the actual

speech connection is established. In this case the local exchange has already switched through while the destination exchange has not yet answered;

- Party on hold (by operator or in enquiry) is considered to be in conversation state;- When break in (by operator or extension) on a call is performed only one call is in the

conversation state, the call which has been broken in to;- When an operator performs busy override followed by pressing the L-button (listening

in) then only one call is in the conversation state, the call which has been broken in to;- When an operator performs listening in after normal call setup then two calls are in

the conversation state;- During an add-on situation two calls are in the conversation state;- In a multi-party conference as many calls are in the conversation state as conference

members are present.• Definition of the Ringing State

In object 4 and 5 Ringing is measured. Ringing is the state in which an extension is actually ringing. So only the called party can be in the ringing state. When a call is present on a line-position the extension which owns the line-position is in the ringing state. Calls on COB are not in the ringing state. Calls to an S0-bus without extensions or with incompatible extensions will be released after approximately 4 seconds of ringing.

5.4.4. Measured Entities

Specific objects can be measured. Specific resources can be measured per object. For example when the object 'Exchange and Tie Line Bundles' is measured, a group of trunk lines assigned to a bundle can be specified by the bundle number. When the object 'Individual Operators' is measured, a specific resource can be specified by the operator DNR. For such resources, specific entities are measured. See Table 5-4 "Measured Entities".

126

ENTITY MEASUREMENT METHOD

USED IN OBJECT

Absent / Present group members

Static counting 5

Average COB time Calculation 5

Answered Dynamic counting 4, 5

Average call duration Conversation switch count and Calculation

17

Average holding time Calculation 0, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14

Average number of COBs COB switch count 5

Average queue length Busy switch count 14, 15

Average queue time Calculation 14, 15

Average ringing time Ringing switch count and Calculation

4, 5

Call types Dynamic counting 17

Carried load Busy switch count 0, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14

Circuits in OUT / ABL / NIN Static counting 0, 1, 2, 3, 6, 7, 8, 9, 10, 11, 12, 13

COB to ringing Dynamic counting 4, 5

COB to seizure Dynamic counting 1, 6

COB started Dynamic counting 1, 4, 5, 6

Congestion Dynamic counting 0, 1, 2, 3, 6, 7, 8, 9, 10, 11, 12, 13, 16

Destination unit Dynamic counting 18

Established calls Dynamic counting 17

Handled calls Dynamic counting 14, 15

Incoming seizures Dynamic counting 0

Internal, External, Assisted Dynamic counting 19

Not usable B-channels Static counting 0, 1

Outgoing seizures Dynamic counting 0

127

Table 5-4 Measured Entities

The rest of this section gives details about the measured entities as specified in Table 5-4 "Measured Entities" in alphabetical order.

• Absent / Present Group MembersAt the start of an interval the number of absent / present group members is counted.

• Average COB TimeOnly for object 'Extension Groups' (5).The average COB time is calculated as follows:

• AnsweredNumber of times a ringing extension goes off-hook or call pick-up is done.

• Average Call DurationFirst the average number of extensions in conversation state is determined:

Than the average call duration is calculated as follows:

Note: The 'Average holding time' measures all phases of the call and can not be compared with this entity.

• Average Number of COBsOnly for object 'Extension Groups' (5).The Average number of COBs includes COBs on the specified group and on the individual

Queued calls Dynamic counting 14, 15

Ringing started Dynamic counting 4, 5

Total B-channels Static counting 0, 1

Total circuits Static counting 0, 1, 2, 3, 6, 7, 8, 9, 10, 11, 12, 13

Unsuccessful bids Dynamic counting 5

ENTITY MEASUREMENT METHOD

USED IN OBJECT

128

group members.The average number of COBs is calculated as follows:

• Average Holding TimeFor operators, the term 'Average call handling time' is used; the calculation is the same as below. Being based on seizures, the holding time covers all phases of the call (setup, conversation and release). The average holding time is calculated as follows:

Note: For object 17 (calls), the 'Average call duration' measures only the conversation phase and can not be compared with this entity.

• Average Queue LengthThe average queue length is calculated as follows:

• Average Queue TimeThe average queue time is calculated as follows:

• Average Ringing TimeFirst the average number of extensions in ringing state is determined:

Than the average call duration is calculated as follows:

• Call TypesThis object is meant to measure the kind of traffic in a unit (intra-unit) and between units (inter-unit). The counters are incremented when the call enters the conversation phase.Figure 5-2 "Example of Calls in a Three Unit Network" and Table 5-5 "Example of Call Types in a Three Unit Network" provide some examples of measured call types.

Average no of COBs =

Switch count resources in COB Number of

scans

129

Figure 5-2 Example of Calls in a Three Unit Network

Note: The dotted line is the case 5 from Table 5-5 "Example of Call Types in a Three Unit Network".

130

Table 5-5 Example of Call Types in a Three Unit Network

Note: The abbreviations in Table 5-5 "Example of Call Types in a Three Unit Network"are taken from the Performance Manager module of the System Manager.

As explanation situation number 6 from Figure 5-2 "Example of Calls in a Three Unit Network"will be described.Phase 1: Trunk 2 calls operator 2 and a speech connection is created.Phase 2: Operator 2 calls extension 1.Phase 3: Operator 2 connects trunk 2 and extension 1.As a result the following counters are incremented:Within unit 2:- The intra-unit operator-trunk counter because of the trunk 2 to operator 2 call;- The inter-unit operator-extension counter because of the operator 2 to extension 1

call;- The inter-unit trunk-to-extension counter because of the connection between trunk

2 and extension 1.

NUMBER MEASURED CALL TYPE

UNIT 1 UNIT 2 UNIT 3

INTRA INTER INTRA INTER INTRA INTER

1 e1->t1 e>t

2 e2->t1 e->t e->t

3 o2->e2 e-o

4 t1->o2 o-t o-t

5 t2-<o2->e2 o-t, e-o

==>t2->e2 t->e

6 t2->o2->e1 e-o o-t e-o

==>t2->e1 t->e t->e

7 t1->o2->e1 t->e o-t, e-o o-t, e-o

==>t1->e1

8 t1->e3 t->e t->e t->e

9 t1->t2 t-t t-t

- = Traffic in both directions

->= Traffic in one direction

==>= Connection by operator assistance

131

Within unit 1:- The inter-unit operator-extension counter because of the operator 2 to extension 1

call;- The inter-unit trunk-to-extension counter because of the connection between trunk

2 and extension 1.• Carried Load

The carried load is based on the busy switch count method and calculated as follows:

• Circuits in OUT / ABL / NINCircuits in OUT reflects the number of resources with the specific status OUT. Circuits in ABL reflects the number of resources with the specific status ABL. Circuits in NIN reflects the number of resources with a state which is unequal to INS, OUT or ABL (NIN = Total-INS-OUT-ABL).

• COB to RingingOnly for objects: 'All Extensions in a Unit' (4) and 'Extension Groups' (5).The number of times COB leads to ringing is counted. The counters 'COB started' and 'COB to ringing' need not necessarily be equal during one measurement interval. This because of two possible reasons:- The party on COB releases the call before the call is answered.- COB might have been started in a previous period and led to the start of ring in the

current interval.• COB to Seizure

Only for objects 'Exchange and Tie Line Routes' (1) and 'Paging Routes' (6).Incremented when the COB leads to a seizure of a trunk line or paging line.A fault is introduced when after a successfully ended COB (so counter is incremented) the outgoing seizure collides with an incoming seizure, and no line is available in the route for outgoing traffic.

• COB StartedAs described in Table 5-6 "Counting of COB Started", the counter of 'COB started' is incremented for a number of reasons.

Carried load = Switch count resources in busy stateNumber of scans

132

Table 5-6 Counting of COB Started

ATF-COB = Automatic Trunk Find, a feature where the PABX will keep searching for a free trunk line to another exchange if there are no free trunk lines left at that moment. When ATF is enabled the caller will be set on 'Camp On Busy' until a free line is found. For the object 'Exchange and Tie Line Routes' (1) a fault is introduced when COB is ended successfully but the outgoing seizure collides with an incoming seizure (upon which the incoming seizure will be given the line). If no line is available in the route then again COB is started and the counter will be incremented.

• CongestionAs described in Table 5-7 "Counting of Congestion", congestion can occur for a number of objects.Figure 5-3 "Congestion on Routes and Bundles"shows the mechanism of route and bundle selection with possible congestion. Congestion occurs on an outgoing bundle when no line is available in that bundle. Congestion occurs on an outgoing route when no bundle is available in that route.Although the call may succeed, the congestion count can be incremented a number of times for various bundles / routes (overflow).

OBJECT COB STARTED IS COUNTED WHEN

1 - Exchange and Tie Line Routes

No free line available in an outgoing route and the facility

ATF-COB is activated.

4 - All Extensions in a Unit COB is started on a busy extension.

5 - Extensions Groups COB is started on a busy group or groupmember.

6 - Paging Routes Real paging: No free line in paging route and COB started.

Virtual paging: No COB for virtual paging.

133

Table 5-7 Counting of Congestion

OBJECT CONGESTION WHEN

0 - Exchange and Tie Line Bundles Congestion occurs on an outgoing bundle when no line is available in that bundle.

1 - Exchange and Tie Line Routes Congestion occurs on an outgoing route when no bundle is available in that route.

2 - Inter Unit Bundles See object 0 and 1 but now only one route is possible instead of

3 - Inter Unit Routes more routes.

6 - Paging Routes Real paging : No free line in paging route and COB-queue fully filled.

Virtual paging : No free virtual paging codes.

7 - Add-on Circuits No free resource of the specific type available.

8 - RKT-SDTs

9 - SKT-RDTs

10 - Incoming MFC Circuits

11 - Outgoing MFC Circuits

12 - RS-Socotel Circuits

13 - Convertors

16 - Switching Network Channels No free SNC to a PM available (counted per PM).

21 - Hatches

134

Figure 5-3 Congestion on Routes and Bundles

• Destination UnitEach unit has a set of counters which count the inter-unit traffic dispersion. A counter is present for each possible combination of source and destination unit. Such a counter will be indicated as 'counter(source,destination)'. For example, the counter which counts inter-unit traffic from source unit 1 to destination unit 3 is written as 'counter(1,3)'. The counters are incremented when an inter-unit seizure is done.As explanation, the following situation will be described (see Figure 5-4 "Example of Inter-unit Calls in a Three Unit Network"):When an inter-unit call is made from unit 2 via unit 3 to unit 4, seizures are done and therefore the following counters are incremented:- In unit 2 the counter(2,4) is incremented;- In unit 3 the counter(2,4) is incremented;- In unit 4 nothing is incremented.

135

Figure 5-4 Example of Inter-unit Calls in a Three Unit Network

With DISPTO:18; the inter-unit dispersion of this unit is read. An additional parameter must be given, the source unit. The following counters are displayed:counter(source,destination unit 1)counter(source,destination unit 2)..counter(source,destination unit 14)So if the command DISPTO:18; with source unit 2 is given in unit 3 the counters have the following meaning:Destination unit 1: the number of calls from unit 2 to unit 1 via unit 3Destination unit 2: not applicableDestination unit 3: the number of calls from unit 2 to unit 3Destination unit 4: the number of calls from unit 2 to unit 4 via unit 3..Destination unit 14: the number of calls from unit 2 to unit 14 via unit 3

• Established CallsThis entity counts the number of calls that entered the conversation phase. For a definition of the conversation state, see section 5.4.2. "Measurement Methods".

• Handled CallsThe number of handled calls reflects the number of queued calls retrieved from the queues by the operator. When an operator retrieves a call from a queue, but for some reason (congestion) it is not possible to bring the call to the conversation phase then the call will be re-queued; the number handled calls is incremented in this case.

• Incoming SeizuresNumber of times a line is selected, for incoming traffic, not necessarily leading to a successful call (collision, number unobtainable etc). This includes tie-line traffic and trunk-line traffic.

• Internal, External, AssistedIn object 19, Dialled Facilities are measured. Every time a 'final number result' is found in the number analysis service, the counter for the particular category is incremented. This means that even when a user is not allowed to dial a certain facility, dialling that facility by the user is still counted. If a user is not 'follow me entitled', for example, dialling the 'follow

136

me' facility by that user is counted although 'follow me' is not activated. The following categories are counted:- Internal

Counts the number of times internal parties select a facility;(activate follow me, internal party calls another party)

- ExternalCounts the number of times incoming parties select a facility;(DDI to paging, DDI to internal number)

- AssistedCounts the number of times operators select a facility.(busy override, taxmetering, normal calls from the operator)

• Not Usable B-channelsFor ISDN: All B-channels with status, as seen by DISERV, 'not usable'. The B-channel has status 'not usable' when the access has a status unequal to INS.For non-ISDN: All circuits with status not INS.

• Outgoing SeizuresNumber of times a line is selected, for outgoing traffic. This includes tie-line traffic and trunk-line traffic.When ATF-COB has been started and this COB leads to a successful line seizure then the number of outgoing seizures will not be incremented.When a 'renew outgoing seizure' is given over a trunk line (D-button) the 'outgoing seizures' count will not be incremented.When an outgoing seizure collides with an incoming seizure then the incoming seizure will actually get the line, but the number of outgoing seizures has been incremented with one.

• Queued CallsThe number of queued calls is incremented when a call is signalled at the operator console. In the next exceptional situation a fault occurs. When an operator retrieves a call from a queue, but for some reason (congestion) it is not possible to bring the call to the conversation phase then the call will be re-queued; the number of queued calls is incremented in this case.

• Ringing StartedNumber of times ringing has started is counted.

• Total B-channelsThis entity reflects the total number of lines to other exchanges (not inter-unit). For ISDN a basic access counts for two B-channels and a primary rate counts for 30 B-channels. A non-ISDN DPNSS, ATU etc circuit are counted as one B-channel.

• Total CircuitsThe maximum number of resources of a specific type which CAN be projected. This value is extracted from system boundaries.

• Unsuccessful BidsOnly for object 'Extension Groups' (5).

137

In the following cases an unsuccessful bid is counted:- Call to group member DNR while member is busy and member-COB-queue is full;- Call to group member DNR while member is busy and no COB is started;- Call to group DNR while all members are busy and group-COB-queue is full;- Call to group DNR while all members are busy and no COB is started.So when a member is called individually, and the member is busy and no COB is started then 'unsuccessful bids' is incremented.

5.5. GENERAL INTERPRETATION PROBLEMS

In the following sections some general interpretation problems will be discussed.

5.5.1. Average Call Holding Time seems to be out of Proportion

The first thing to realise is that the call holding time can be far more than 900 sec (1 quarter hour). Think of a data call! This time is of course not related to the measurement interval of 900 seconds. The average holding time of extensions is calculated by means of the following formula:

Figure 5-5

Where:

Note: This formula is not valid for the special case that no new seizures are made during the measured quarter hour. In this case a division by zero would take place.To prevent this, the number of seizures is set to one.

Consider the following example where the average call holding time seems to be out of proportion, see Figure 5-6 "Example of Call Holding Times longer than a Quarter Hour".

Suppose an average number of 4 calls: then the carried load is 8 Erlang and 4 seizures are detected in each measured quarter hour. Because the system is in an operational environment

Carried load = the average number of extensions in the busy state during the measured quarter hour in Erlang (when two extensions are in conversation, the system measures 2 Erlang).

Number of seizures

= total number of seizures from extensions counted during measured quarter hour (when call is made between two extensions, two seizures are counted).

138

it is allowed to make some assumptions:

- The calls are divided over time in such way that at each moment in time four calls are established. So a situation with five calls established will not occur;

- The seizures are pair wise equally divided over the time. So a pair of seizures occurs every 900/2=450 seconds.

As can be seen from the illustration and as can be calculated with the formula, the average call holding time is 1800 seconds.

Figure 5-6 Example of Call Holding Times longer than a Quarter Hour

When all four intervals are summed together the average call holding time can be calculated as follows:

Four periods = 4 x 900 seconds = 3600 seconds

Carried load = 8 Erlang

Number of seizures = 16

Figure 5-7

139

5.5.2. Deviation between Call Holding Times

Both the average value of holding times from the last quarter hour as well as the total average value of holding times from all previous quarter hours can be the output of traffic measurement (DISPTO). The deviation between the average value of holding times from every quarter hour during an hour and the total average holding time during this hour can be explained with the following example of 3 calls during 2 periods of a quarter hour, see Figure 5-8 "Example of Call Holding Time Sampling".

Figure 5-8 Example of Call Holding Time Sampling

• Period 1:

Figure 5-9

• Period 2:

Figure 5-10

• Period 1 and Period 2:

140

Figure 5-11

When the average of the call holding time is taken from Period 1 and Period 2, (328,5+423)2=375,75 seconds is found, a difference of 15,75 (375,75-360) seconds. In other cases this difference may even be larger.

5.5.3. Multiples of Certain Figures in Traffic Measurement Output

The occurrence of multiples of certain figures (e.g. 27 s or 9 s) in the output of traffic measurement can easily be explained by the fact that traffic measurement scans at discrete moments. Therefore it is impossible for traffic measurement to generate continuous output. This will be explained in more detail in the following text. Suppose we would like to determine the figures of extensions. The timer involved is Traffic Measurement Extension Scan Time (NETIMER 085) which is default 30 seconds.

Figure 5-12 Example Scan Inaccuracy

As can be seen from Figure 5-12 "Example Scan Inaccuracy", call 1, call 2 and call 3 all are scanned only once. For traffic measurement these three calls are equal. The call holding time given by traffic measurement should be 30 seconds for all these three calls, but because of rounding off intermediate results traffic measurement will give 27 seconds instead of 30 seconds. In an operational system both long and short calls will occur in the same amount and thus the average will be accurate. When only a small number of calls are made or in systems with a average holding time lower than 30 seconds, this figure is not necessarily accurate.

When, for a specific system, it is considered not accurate enough that call 1 and call 2 and call 3 are measured all as the same call, the timer of 30 seconds can be set to a lower value. In this case multiples of the new timer value will still appear in the output!

141

Calculation examples:

First the case of Figure 5-12 "Example Scan Inaccuracy".

Figure 5-13

If one scan resulted in two busy resources or if two scans resulted both in one busy resource and one seizure:

Figure 5-14

5.6. PROCESSOR LOAD - ADAPTIVE LOAD CONTROL

The three application programs in the CPU software (CP, SAS, POM) introduce a load for the main processor of the ISPBX unit. Each part of the application is assigned some processor time. The assigning of the processor time is performed by a part of the CPU operating system, the Adaptive Load Control. Each application that wants to perform a certain task must apply for processor time to that load control. This module guards the dynamic behaviour of the processor and will allow tasks in sequence of priority and the requested processor time for the job. If no processor time is available the task-request is disregarded and must wait until other tasks have finished.

As the ISPBX is a dedicated call processing computer the highest priority is assigned to call processing. Most processor time is reserved for call processing purposes to make sure the

142

ISPBX is able to handle as many telephone calls (traffic) as possible.

The two remaining applications system assurance and project engineering - operational maintenance are assigned lower priorities, processor time is assigned only when call processing does not occupy the main processor.

5.6.1. Real Load

The adaptive load control continuously registers the real load of the CPU of a ISPBX unit. This real load is the loading of the processor in terms of percentage of the total available processor time. If the processor is fully occupied and no processor time is available any more, the real load is 100 %.

By means of the second line command DILOAD the instantaneous real load of the main processor is continuously displayed on an OM terminal connected to that ISPBX unit. Each time the dynamic loading of the processor changes, the new figure is displayed. This command can only be stopped by the CTRL-X sequence and therefore this command cannot be executed in a batch-job.

5.6.2. Load Sources

Two different types of tasks can be distinguished, primary tasks are tasks that can be directly identified, secondary tasks are tasks that are started by other tasks. In the CPU a number of tasks can be active simultaneously and also per task-type a number of tasks can be active.

The different primary type of tasks that can introduce processor load are:

The different secondary type of tasks that can introduce processor load are:

0 = SAS-URG : urgent actions performed by system assurance.1 = SAS-FHL : fault handling and location actions performed by system

assurance.2 = SAS-TST : preventive test actions performed by system assurance.3 = OM-URG : urgent commands performed by operational maintenance.4 = OM-MNT : maintenance actions performed by operational maintenance.5 = OM-MAT : manual tests performed by operational maintenance.6 = CP-CAL : call processing actions.7 = CP-RM : registration and management actions performed by call

processing.

8 = SAS-GEN : general actions performed by system assurance.

143

5.6.3. Permission Units

Each task belonging to a certain task-type causes a certain amount of loading for the CPU. An estimate for the loading by each task is expressed in Permission Units. Each task is related to a number of permission units. This relation cannot be changed.

The adaptive load control is continuously registering the permission units of the different task-types and the total number of permission units for the CPU of a ISPBX unit. At the beginning of a task, adaptive load control is called to allow the task.

When a task is allowed, the number of permission units is added to the total of the system for the related task-type.

When the task finishes the related number of permission units is removed.

The total number of permission units for the different task types and their total number are continuously registered and controlled by the adaptive load control. If the total number of permission units in the CPU reaches a projectable maximum, the task can be rejected. Adaptive load control uses the permission units as a kind of priority indication for the task. If the processor gets rather busy, adaptive load control restricts less important sources, which have a low number of permission units. More important work (for instance call processing) is still allowed with the high number of permission units. This way the adaptive load control balances the load divided over different sources.

5.6.4. Minimum and Maximum Loading

Using the command CHLDCT the minimum load (LD-min) and maximum load (LD-max) can be changed. This command is discussed in more detail in the Second Line Maintenance Manual.

The value that is entered with this command is a percentage of the total processor load.

5.6.5. Allowing New Tasks

When a new task calls the adaptive load control for execution allowance, the adaptive load control checks both the real load and the number of permission units in the processor:

- If the real load is less than the minimum loading (LD-min; default=70 %) the task is allowed; areas 1, 4 and 7 in Figure 5-15 "Allowing New Tasks".

- If the total number of permission units is less than the minimum loading (LD-min) the task

9 = OM-GEN : general actions performed by operational maintenance.10 = GOS-RM : resource management actions performed by global operating

system.

144

is allowed; areas 1, 2 and 3 in Figure 5-15 "Allowing New Tasks".

If both the real load and the total number of permission units reach the maximum loading (LD-max; default=90 %) new tasks are not accepted any more, area 9 in Figure 5-15 "Allowing New Tasks". Sometimes a new task is initiated by a task already in progress. In this case the new task cannot be rejected.

In the areas 5, 6 and 8 of Figure 5-15 "Allowing New Tasks" another mechanism is used to determine if the task is allowed. This mechanism is called the guaranteed loading.

Figure 5-15 Allowing New Tasks

5.6.6. Guaranteed Loading

The guaranteed loading can be projected per task type. If both the real load and the total number of permission units rise above the minimum load (LD-min) this guaranteed load is used to determine if the task belonging to that specific task type is allowed. If a task calls the adaptive load control and the system load is somewhere in the areas 5, 6 or 8 the adaptive load control looks at the guaranteed number of permission units for that specific task-type. If the real number of permission units for that task is above the guaranteed load, the new task is rejected. If the guaranteed load is not yet reached, the new task is allowed.

By default the following guaranteed loading levels for the separate task types are assigned:

145

5.6.7. Display Processor Load

The real instantaneous load for the processor can be displayed using the OM command DILOAD. The percentage that is displayed gives the total loading of the processor. No distinction between the different load sources is made visible.

The OM command DIOVLD is a more powerful command.

The layout of the command is as follows:

DIOVLD: <DATA-INDICATOR>[ ,<UNIT>];

The value of the parameter <DATA-INDICATOR>indicates the following:

The response on the command looks like:

- SAS-URG : urgent actions performed by system assurance 20%- SAS-FHL : fault handing and location actions performed by system

assurance10%

- SAS-TST : preventive test actions performed by system assurance 5%- OM-URG : urgent commands performed by operational maintenance 20%- OM-MNT : maintenance actions performed by operational maintenance 10%- OM-MAT : manual tests performed by operational maintenance 5%- CP-CAL : call processing actions 90%- CP-RM : registration and management actions performed by call

processing10%

- SAS-GEN : general actions performed by system assurance 10%- OM-GEN : general actions performed by operational maintenance 10%- GOS-RM : resource management actions performed by GOS 10%

0 = display the processor load in terms of permission units continuously.The display of information must be stopped with CTRL-X;

1 = display the number of tasks running continuously.The display of information must be stopped with CTRL-X;

2 = display the projected guaranteed processor load for the different tasks in %;3 = display the projected maximum processor load (LD-max) in %;4 = display the projected minimum processor load (LD-min) in %;5 = display the projected maximum number of tasks that are allowed per task type in

numbers;6 = display the projected time out values per task type in minutes.

146

5.6.8. Load Monitor

The load in a unit can be monitored during a certain time interval. This process writes the display information to a file. Only one load monitoring process can run in a unit. The load monitor must be started and stopped by OM commands.

With the OM command STALDM the monitoring process can be started. In the parameters the output file, the on-time and off-time and the interval between outputs can be defined. The command is actually the same as the DIOVLD command mentioned earlier. The real difference is that the display information is redirected to a file and that the process is executed during a certain time interval. In addition there is a 13th column showing the actual load percentage.

During the execution of the monitoring process the load monitor can be stopped with the OM command CANLDM.

The status of the monitoring process can be displayed with the OM command DISLDM.

5.6.9. Changing parameters for the Adaptive Load Control

The adaptive load control uses a number of parameters to determine the allowance for the execution of a new task. These parameters can be changed (tuned) by the system manager by the second line command CHLDCT:

CHLDCT: <SOURCE>,<DATA-INDICATOR>,<DATA-VALUE>[ ,<UNIT>s/r];

The parameter <SOURCE>indicates the task-type for which the value is to be changed:

SAS SAS SAS OM OM OM CP CP SAS OM GOS UNITURG FHL TST URG MNT MAT CAL RM GEN GEN RM TOTxx xx xx xx xx xx xx xx xx xx xx xx

0 = SAS urgent actions;1 = SAS fault handling;2 = SAS preventive tests;3 = OM urgent actions;4 = OM maintenance;5 = OM manual tests;6 = CP call processing;7 = CP registration and measurements;8 = SAS general;

147

The parameter <DATA-INDICATOR>indicates which value for the task type must be changed:

0 = maximum simultaneous tasks allowed in numbers;

1 = minimum simultaneous tasks allowed in numbers;

2 = guaranteed load in %;

3= maximum load in %;

4 = minimum load in %;

5 = time out values in minutes.

The parameter <DATA-VALUE>indicates the new value for the task type.

9 = OM general;10 = GOS resource management;11 = Unit total;12 = Sampling.

148

6. SECURITY MANAGEMENT

In the ISPBX several mechanisms can be used to ensure system security.

This chapter starts with file management in the ISPBX since all system and user information is stored in files. A good understanding of file management is important to make sure no unauthorised persons can gain access to secured files. The protection levels are the most important mechanism for this part of system security.

The whole configuration of the hardware and software relations in the ISPBX system can be changed by OM commands. Therefore, the security against the unauthorised use of commands is very important. The authority classes are the most important mechanism to prevent OM commands from being entered when they might cause damage to the system configuration.

A number of OM commands require a password to be entered before the command is executed. Password mechanism is also part of the security management.

6.1. FILE MANAGEMENT

6.1.1. File Structure

All information in the ISPBX is stored in files. A file is identified by:

- Logical device name (maximum 6 characters);- File name (maximum 6 characters);- Extension (maximum 3 characters). Extensions for CPU system files are fixed;- Generation (one digit between 1 and 9). Only the last 4 generations of the same file are

stored. If a new generation is created and 4 generations of the same file name and extension are already present on the device, the oldest generation is deleted. After generation number 9 is reached, the next file with the same file name and extension will be assigned generation number 1.

When a file is created or operated on, the ISPBX may add additional information to the file entry:

- Protection levels of the file (NARD). For each file, the protection levels for New, Append, Read and Delete can be assigned a level (from 1 to 7).

- Date and time of the creation of the file;- Date and time of the last modification of the file;- 12 NC number of the file (if the file is part of a software package);- Default and current authority class (if the file represents an OM command file);

149

- Current authority class index of the file (if the file represents an OM command file).- SIN number of the file (for a MIS- or JOURNL.POM file);- Reference name: it can happen that OM (sub)commands or SAS files do not contain any

software but refer to other files (reference name) that contains the concerned software program.

- Type and subtype of the file. (For more information, see OM commands Manual)- Description field. A short description of the file (in 40 characters maximum) can be

available.

6.1.2. Local Backup Device - all systems except iS3070/3090

The Local Backup Device (LBU) is a storage device within the iS3000 used to store the CPU package and the MIS-file. The LBU comprises FEPROMs on the CPU board.

6.1.3. Disk Emulator - all systems except CCS platform

The disk emulator is a software program running on the SMPC or SystemManager. The SMPC/SSM communicates with the CPU of the ISPBX. The system manager can order the ISPBX CPU to use the SMPC/SSM as a storage device. In this configuration the processor of the SMPC/SSM serves as the controller and the disk drive as the storage medium.

The BIM (CCS platform) implicitly performs the disk emulator function.

6.1.4. Disk Maintainer - iS3070/3090 only

Disk Maintainer functionality is incorporated in the BIM for CCS systems

6.1.5. Commands

To manage the files on the backup devices (LBU, CBU, DBU), the system manager must enter the appropriate OM commands from the OM device. The CPU analyses the commands and gains access to the specified device. In this part, the OM commands are described that can be used irrespective of the specified device.

• DIRECTThe DIRECT command is used to display the files that are present on the backup devices, and to display all additional information on the files.If the DIRECT command is used with directory type SYSTEM (also default when no directory type is used) the output displays the following information (if assigned):- Volume name;- File name, extension and generation number;- NARD of the file;

150

- Date and time of creation of the file;- Date and time of the last modification of the file;- Type and subtype of the file;- 12 NC of the file.If the DIRECT command is used with directory type USER (see OM commands Manual) the output displays the following information (if assigned):- Volume name;- File name and extension;- SIN number of the file (only for LMuu01.POM & JOURNL.POM files);- Reference name;- Authority class index of the file;- Default and current authority class.If the DIRECT command is used with directory type DESCRIPTION (see OM commands Manual) the output displays the following information:- Volume name;- File name and extension;- Description field.Wildcards can be used in the file name and extension. The * sign replaces a whole file name or extension. The % sign replaces one character in the file name or extension. A number of % signs may be used. If the generation of the file is omitted, all generations (at most 4) of the file are displayed.

• TYPFILThe TYPFIL command can be used to display the contents of a readable file.With this command no wildcards may be used in either file name or extension. If the generation of the file is omitted, the last generation is taken into account.For this operation the READ protection level of the OM device must be at least the same as the READ protection level of the file. For more information, see section 6.2. "PROTECTION LEVELS".

• DELFILThe DELFIL command can be used to delete a file.With this command no wildcard may be used in either file name or extension.Only the youngest (indicated with generation sign "/" ) or oldest (indicated with generation sign 'Ø') generation of the file can be deleted.For this operation the DELETE protection level of the OM device must be at least the same as the DELETE protection level of the file. For more information, see section 6.2. "PROTECTION LEVELS".

• PURFILThe PURFIL command can be used to delete all file generations except the youngest one.With this command no wildcard may be used in either file name or extension. The generation of the file must be omitted. The display of the OM device shows which files are deleted.

151

For this operation the DELETE protection level of the OM device must be at least the same as the DELETE protection level of all the files that are to be deleted. For more information, see section 6.2. "PROTECTION LEVELS".

• CPYFILThe CPYFIL command can be used to copy a file to the same or to another device with the same or another file name and extension. When this command is executed, the characteristics of the old file are also copied to the new file. Only the creation date and time and modification date and time parameters are adapted.With this command no wildcard may be used in either file name or extension. If the generation of the file is omitted, the last generation is taken into account.A file has to be read in order to be copied. Therefore the READ protection level of the OM device must be at least the same as the READ protection level of the file.If the same file name and extension already exist on the destination device a new generation of the file is created. The NEW protection level of the OM device must be at least the same as the NEW protection level of the file. For more information, see section 6.2. "PROTECTION LEVELS".

• CREFILA file can be created with the CREFIL command. This command is usually used to make a batch job containing some OM commands that are executed at a specific date and time. Each line that holds an OM command must start with the prompt '<' that must be entered by the system manager. If the OM command requests additional information this additional information must also be included into this command file, but without the prompt '<'. This also applies for passwords. The passwords are included in the command file in readable form which endangers system security. The only option that can be used to secure the passwords is to assign a high protection level for the reading of the file. Only a system manager with a high protection level on his OM device is then able to read this file.If the CREFIL command is executed with a new file name or extension, the new file is assigned the same protection levels as the current protection levels of the OM device used.If the CREFIL command is executed with an existing file name and extension (new generation), the new file is assigned the same characteristics as the old file. Only the creation date and time and modification date and time parameters are adapted. Also the protection levels of the 'new' file are copied from the 'old' file. In this case the NEW protection level of the OM device must be at least the same as the NEW protection level of the file. For more information, see section 6.2. "PROTECTION LEVELS".

6.2. PROTECTION LEVELS

When the system manager wants to operate on the backuup unit of an OM device, the protection levels of the file are used. These protection levels are identified with the letters

152

NARD. Each file and each OM device are assigned 4 protection levels. When the system manager wants to perform an operation on a file, the applicable protection level of the device must have at least the same value as the corresponding protection level of the file to allow the operation. The letters N, A, R and D are used for the following protection levels:

• NEWWhen the system manager wants to copy a file from an origin device to a destination device, the CPYFIL command is used. If the file already exists on the destination device a new generation of the file must be created. In this case the protection level of the OM device for the NEW operation must at least have the same value as the NEW protection level of the origin file.If the file does not exist on the destination device, the device protection level for the NEW operation is not checked.When the system manager tries to execute the command CREFIL with a file that already exists (a new generation must be created), the protection level of the OM device for the NEW operation must at least have the same value as the NEW protection level of the existing file.

• APPENDThis protection level is not used for system manager applications.

• READWhen the system manager wants to display the contents of a readable file on the display of the OM device the TYPFIL command is used. The protection level of the OM device for the READ operation must at least have the same value as the READ protection level of the file.When the system manager wants to copy a file with the OM command CPYFIL, the original file must also be read. The protection level of the OM device for the READ operation must at least have the same value as the READ protection level of the original file.

• DELETEWhen the system manager wants to delete a file from the OM device the DELFIL command is used. The protection level of the OM device for the DELETE operation must at least have the same value as the DELETE protection level of the file. Only the youngest or oldest version can be deleted with this command. Therefore the generation specification is mandatory (/ means youngest generation; Ø means oldest generation).To execute the PURFIL command to delete all generations of a file except the youngest, the protection level check is also performed for ALL generations that must be deleted.

The protection levels of the OM device can be changed with the OM commands CHSEPR and CHDEPR.

With the command CHSEPR, the protection levels for new, append, read and delete can only

153

be changed for the current OM session, on the OM device in use. If the requested protection level is higher than the current value, the system asks for a password. A request for a lower value is not protected by a password. When a new OM session is started, the protection levels are set back to the default protection levels.

With the command CHDEPR, the default protection levels for new, append, read and delete can be changed for all following OM sessions on the defined OM device. If the requested protection level is higher than the current value, the system asks for a password. A request for a lower value is not protected by a password. When a new OM session is started on the defined device, the protection levels are set to the 'new' default protection levels. When this command is executed, the logical device name (VDUxx) must be defined. This means that the default protection levels for a device can be changed from any other OM device.

The protection levels for the session and the default protection levels for an OM device can be displayed with the DIAUPR command.

6.3. AUTHORITY CLASSES

6.3.1. OM Device

An Authority Class (AC) is a mark that is assigned to an OM device which tells the system which OM commands can be executed from this device. Each OM device has an authority classe (from 0 to 15) and each authority class has the status ALLOWED or NOT ALLOWED. The status for the authority class 14 is always ALLOWED and the status for the authority class 15 is always NOT ALLOWED.

Assigning the status Allowed or Not-allowed to an authority class for an OM device can be done with the OM commands CHSEAU and CHDEAU.

With the command CHSEAU the status of an authority class is only changed for the current OM session and for the OM device in use. When this command is executed, the system may ask for a password. When a new OM session is started, the status for all authority classes are set back to the default value.

With the command CHDEAU the default status of an authority class is changed for all following OM sessions on the defined OM device. When this command is executed, the system may ask for a password. When a new OM session is started on the defined device, the status of all authority classes are now set to the new default values. When this command is executed, the logical device name (VDUxx) must be defined. This means that the default status of an authority class for a device can be changed from any other OM device.

The allowed authority classes for the session and the default allowed authority classes for an

154

OM device can be displayed with the DIAUPR command.

6.3.2. OM Command

Each OM command that is to be executed requires one of the authority classes (0 to 15). If the system manager wants to execute this command the OM device used must have the same (allowed) authority class the OM command requires. If the device is not allowed this authority class, the command cannot be executed from this device. So by only assigning a limited set of allowed authority classes to an OM device, only a limited set of OM commands can be executed from that device; this mechanism can be used for system security.

Each OM command is assigned an Authority Class Index (ACI). This relation is fixed and cannot be changed. An OM command is present as a command file (with extension O) even when the command is in the CPU memory. In the system information of this command file, the ACI related to the command is stored. The ACI is related to the required authority class by a default or user defined relation, the ACI-AC relation.

By using the command DIRECT with directory type USER the ACI can be displayed. This command also displays the default and the current relation between the ACI and the required authority class.

If the command is in the CPU memory as overlay module, the required (current) authority class of a command can also be displayed with the command DIOVLM.

By default, the Authority Class Index is related to an authority class. So the execution of the command is allowed if the ACI-AC relation indicates an authority class that is also allowed for the used OM device.

It is also possible for the system manager to define his own set of ACI-AC relations. With the OM command CHACIV the relation between the ACI and the AC can be changed. This command is protected by a password. When this command is executed the default or current relation is overruled and the new relation becomes the current relation. The current (required) authority class is changed in the overlay (DIOVLM) (and, for an iS3070, in the command file on the SSBD (DIRECT)). When the default relation is overruled by a relation defined with the command CHACIV, the relation can now also be displayed using the DIACIV command. The DIACIV command cannot be used to display the default ACI-AC relation.

To be able to reserve a partition in the CPU memory where the ACI-AC relations of the OM commands are stored, the boundary NEBOUND 213 (max number of different OM commands in the system) is used. A table is created in the projecting where the relations are stored.

155

By default the ACI-AC relations are divided into functional groups of commands. For instance, all display commands are related to authority class 0. So when an OM device has authority class 0 ALLOWED, this device can be used to display all configuration data in the ISPBX.

6.3.3. Special Authority Classes

In the set of authority classes, there are two special authority classes:

• Authority class 14Authority class 14 is always allowed for all OM devices.The commands for changing the session or default protection levels or authority classes for an OM device are related to authority class 14 via the ACI 14 - Authority class 14 relation. It is not possible to change this relation. Therefore, it is always possible to enter the commands CHSEPR, CHDEPR, CHSEAU, CHDEAU from all OM devices.

• Authority class 15Authority class 15 is never allowed for an OM device. The status for authority class 15 cannot be changed to ALLOWED.An OM command uses a number of subcommands (after validation of the parameters). These subcommands are related to authority class 15 and are therefore never allowed to be executed from the OM device. The OM command allows the subcommands to be executed.

6.3.4. Command Files

When a command file is created using the CREFIL command, the protection levels and the authority classes from the OM device are included in the new created file. When the OM commands in this file are being executed (execution started with the SUBJOB command) the normal protection level and authority class checks are performed and if necessary an OM command is rejected. If a certain OM command requires additional information, this information must also be included in the command file. This also applies for passwords. The passwords are included in the command file in readable form which endangers system security. The only option that can be used to secure the passwords is to assign a high protection level for the reading of the file. Only a system manager with a high protection level on his OM device is then able to read this file.

The responses from the ISPBX system are logged in a file that can be specified.

To prevent the protection level and authority class check, a special command file can be created. First a normal command file, containing OM commands, is created with the OM command CREFIL. This normal command file is converted to a special command file using the OM command CHSJOB. CHSJOB must be executed for every file created. Now the authority classes 0 to 14 are assigned ALLOWED and the NARD levels '7777' are assigned to the special

156

command file. With the OM command EXSJOB the special command file is started as if it were a normal command file. During the execution of the special command file, no check on protection level or authority class will be performed.

The responses from the ISPBX system are logged in a file that can be specified.

Note: The difference between the normal command file and the special command file can only be displayed using the DIRECT command with the directory type USER. If a special command file is present on the destination device and a new file is created with the CREFIL command with the same name and extension, the new created file is also a special command file!

6.4. PASSWORDS

The execution of a number of vital OM commands can be protected by a password. These passwords are divided into password groups:

- Password group 0OM commands : CHDEAU : change default authority class for authority

classes 0 to 13 (1=allowed / 0= not allowed)

CHSEAU : change session authority class for authority classes 0 to 13 (1=allowed / 0= not allowed)

- Password group 1OM commands : CHDEPR : change default protection level for NEW (0

to 7)CHSEPR : change session protection level for NEW (0

to 7)- Password group 2

OM commands : CHDEPR : change default protection level for APPEND (0 to 7)

CHSEPR : change session protection level for APPEND (0 to 7)

- Password group 3OM commands : CHDEPR : change default protection level for READ (0

to 7)CHSEPR : change session protection level for READ (0

to 7)- Password group 4

OM commands : CHDEPR : change default protection level for DELETE (0 to 7)

157

With the OM command CHPASS, the password used for all commands belonging to a password group and the related parameter within that group can be defined. The system asks for the old password and the new password. If the old password is correct and the new password is identically entered twice, the password is changed. While the passwords are being entered, they are not displayed on the screen of the OM device. With the second line maintenance command FRCPSW, the password used for all commands belonging to a password group and the related parameter within that group can be defined. This command does not ask for the old password. If the new password is identically entered twice, the password is changed. While the passwords are being entered, they are not displayed on the screen of the OM device.

A password is a string of a maximum of 6 characters.

If a password for a certain password group and the related parameter within that group are not assigned, the system does not ask for a password and executes the command immediately. An existing password can also be deleted with the commands CHPASS and FRCPSW by

CHSEPR : change session protection level for DELETE (0 to 7)

- Password group 5OM commands : SETOUT : set out of service degradation level:

0 = not serious1 = serious2 = very serious

FRCOUT : force out of service; degradation level:0 = not serious1 = serious2 = very serious

SETNIN : set not installed; degradation level:0 = not serious1 = serious2 = very serious

UNIINS : set service condition of unit to installed; degradation level:2 = very serious

UNININ : set service condition of unit to not installed; degradation level:2 = very serious

- Password group 6OM commands : INIDSK : initialise disk or similar device

158

leaving the two occurrences of the parameter NEW PASSWORD empty.

Note: A password in the original LLuu.POM file or in the retrieve ORuu.POM file is not displayed in its correct form. The password is encrypted into a string of characters.

Three default passwords are used : RISKI, CONFID, and SYSTEM. For more information, see the OM Command Manual, about System Security.

6.5. RESTRICTION LEVELS

6.5.1. Traffic Classes

Changing the traffic class for an extension can be performed from an OM device with the command CHTRFC or from the operator console with operator desk commands. To be able to prevent the execution of this command by unauthorised persons, the traffic classes can be restricted. The traffic classes that can be assigned to an extension must be set to unrestricted, with the OM command CHTFCR. When this command is executed, the device type must be entered. This way the set of unrestricted traffic classes that can be assigned to an extension, can be defined for the different type of devices: OM devices, operator desks with or without a key, TMS devices etc.

When a person wants to assign a traffic class to an extension from a device which has a restriction level for that traffic class, the OM command is rejected!

Example:

The unrestricted traffic classes for an operator desk without a key are only 0, 1 and 2.

The unrestricted traffic classes for an operator desk with a key are only 0, 1, 2, 3 and 4.

The unrestricted traffic classes for an OM device are 0, 1, 2, 3, 4, 5, 6 and 7.

A normal operator (without a key) can only assign traffic classes 0, 1 and 2 to an extension with operator desk commands.

A chief operator (with a key) can assign traffic classes 0, 1, 2, 3 and 4 to an extension with operator desk commands.

The system manager can assign all traffic classes (0 to 7) to an extension with the OM command CHTRFC.

159

6.5.2. Facility Class Marks

A number of facilities that are available for extensions are only possible if that extension has the appropriate facility class marks. Assigning the facility class marks to an extension can be done from an OM device with the command ASFACM or from the operator console with operator desk commands. To be able to prevent the execution of this command by unauthorised persons, the facility class marks can be restricted. The facility class marks that can be assigned to an extension must be set to unrestricted with the OM command CHFCMR. When this command is executed, the device type must be entered. This way the set of unrestricted facility class marks, that can be assigned to an extension, can be defined for the different device types: OM devices, operator desks with or without a key, TMS devices etc.

When a person wants to assign a facility class mark to an extension from a device which has a restriction for that facility class mark, the OM command is rejected!

6.6. TRAFFIC CLASS SWITCHING

An extension in a ISPBX system has 4 traffic classes, Day traffic class, Night traffic class, Upgraded traffic class and Downgraded traffic class. This section describes the switch from day to night traffic class and vice versa. The Facility Implementation Manual (Voice Facilities) describes traffic classes up- and downgrading in the section about password dialling.

6.6.1. Day / Night Traffic Class Switching

Each extension has two normal traffic classes, a DAY traffic class and a NIGHT traffic class. If the ISPBX unit is in the day condition the extension can dial any number (internal, external or prefix) provided the DAY traffic class is sufficient. If the ISPBX unit is in the night condition the extension can dial any number (internal, external or prefix) provided the NIGHT traffic class is sufficient. Usually the night traffic class will be of a lower level thereby restricting the (external) destinations that can be dialled during the night condition.

The ISPBX unit can change from day to night and from night to day traffic class using three different mechanisms:

• Operator Present / AbsentIf the local system option LOSYSOP 017 (facility clock operates on traffic service class) is false the ISPBX unit uses the night traffic class after the last operator in the unit has gone absent (e.g. removes the headset on operator desk). As soon as one operator is present again, the unit switches to day traffic class. The facility timing does not effect the day/night

160

condition of the unit as the option is false.

Note: Using operator availability lists and assistance groups, the operators in all units of the iS3000 iSNet can be related. If all operators in one ISPBX unit go absent, the unit does not have to switch to the night condition but can remain in the day condition. The operator assistance calls are then rerouted to operators in other units belonging to the same operator availability list. The system uses the night traffic class if the last operator belonging to a specific availability list goes absent. For more information, see Facility Implementation Manual (Networking and Routing).

• Facility TimingIf the local system option LOSYSOP 017 (facility clock operates on traffic service class) is true the ISPBX unit switches between day and night traffic class using facility timing. With the OM command ASFATI the facility timing ON-TIME and the OFF-TIME for a specific day-of-the-week are defined. This switching can be performed only once or periodically (cyclic).The unit uses the day traffic class when the ON-TIME is passed. It uses the night traffic class when the OFF-TIME is passed.If the facility timing was defined as ONCE the facility timing relation is erased but the NIGHT traffic classes remain valid. If the facility timing was defined as CYCLIC the facility timing relation must be erased manually with the DEFATI command.As long as the facility timing is not defined with the ASFATI command or when the relation is erased with the DEFATI command, the unit uses the day traffic class.The status of the facility timing can be displayed with the command DIFATI.The present/absent condition of the operators does not effect the switching between day and night traffic classes of the extensions. It only affects the rerouting of operator assistance calls to the night extensions (INE, SCNE, MCNE).

• Test TelephoneUsing a test telephone (any extension with FCM 13 - test call entitled) the system manager can switch between the day and the night traffic classes of the ISPBX extensions.If the system manager dials (from the test telephone) a prefix with res. id. 72 (upgraded traffic class) the system uses the DAY traffic class.If the system manager dials (from the test telephone) a prefix with res. id. 73 (downgraded traffic class) the system uses the NIGHT traffic class.If the system manager used one of these facilities to force either of the traffic classes, the system manager can return to the normal day / night traffic class switching (operator or facility timing) by dialling a prefix with res. id. 74 (no traffic class selected).Note that after dialling the prefixes 72, 73 or 74, two additional digits must be dialled to indicate the unit number ('00' means: all units).This facility only affects the switching between the traffic classes. The operator present /

161

absent conditions determine the day / night condition of the system and the rerouting of operator assistance calls to the night extensions.

6.6.2. Changing (room) Traffic Class via an Extension (at Reception Desk)

Since SIP@Net 4.1 it is possible to change the traffic class of a telephone (for example in a hotel-room) from an extension at the reception desk. The iS3000 behaviour is similar to the already existing SSM Bar/Unbar service. The extension at the reception desk must have FCM 13 “Test call entitled”.

• Upgrade to Day traffic classTo upgrade the traffic class of a DNR : dial the prefix with RESULT-ID 161 “Upgrade day night traffic class” followed by the DNR.Both the day and night traffic class of the DNR will be set to the projected default DAY traffic class defined by NEBOUND 005.

• Downgrade to Night traffic classTo downgrade the traffic class of a DNR : dial the prefix with RESULT-ID 162 “Downgrade day night traffic class” followed by the DNR.Both the day and night traffic class of the DNR will be set to the projected default NIGHT traffic class defined by NEBOUND 004.

Note that the UP and DOWN traffic classes of the extension are not affected. Changing of the traffic-class is performed by executing OM command CHTRFC which is being journalled.

6.7. DAY / NIGHT CONDITION

The day / night condition of a ISPBX system determines where the calls for assistance are routed.

In the day condition one or more operators are present and the assistance calls are routed to the operator.

In the night condition the operators are absent and the assistance calls are routed to the night extensions.

The traffic class switching is a separate facility that is independent from day or night conditions.

The switching between the day/night conditions can only be performed with operator presence/absence.

The operator presence/absence can also be used for the traffic class switching. The traffic class switching can also be performed with other mechanisms as described above.

162

7. DIRECTORY MANAGEMENT

7.1. INTRODUCTION

In an ISPBX system (iS3000 iSNet of up to 10 ISPBX units; integrated networking via DPNSS to other PABXs) a large number of extensions can be supported as the internal numbering scheme supports DNRs of 6 digits (a network DNR is a maximum of 12 digits). In such a large system a good administration of each DNR with the related persons name is important to be able to trace via which DNR someone can be contacted. Usually this is accomplished by distributing a paper booklet where the names are alphabetically arranged. With each name the related telephone number is mentioned where this person can be contacted. It is very difficult to keep this list up-to-date. Every time a person moves to another DNR the list should be updated.

A list consisting of all the names of the persons in a company together with the related telephone number and if necessary additional information is called a directory.

The ISPBX peripherals SuperVisor 50, SuperVisor model 55(E/S), the Telephone Management System and SystemManager, provide some tools to make it easier to manage the directory of the ISPBX extensions.

7.2. SUPERVISOR 50/50E/50S

This operator post, based on a personal computer operating under Concurrent PC DOS, offers the possibility to manage the ISPBX directory. This computer is connected via a voice box to an OIU or AOC circuit in the ISPBX. The voice box offers the operator a handset or a headset. The control signals are transferred between the ISPBX and the computer and the speech path is established between the ISPBX and the voice box, via the link to the OIU/AOC-circuit. The operator position (computer) can give commands to the ISPBX or receive notices (calls) from the ISPBX via the control signals. The operation of the SuperVisor is much the same as the normal analogue operator position. The operator can connect two parties via two connection sides A and B. So the SuperVisor is actually a normal analogue operator position but with additional facilities, for instance directory management.

Three different types of directories are supported by the:

- Internal directory : containing the internal parties in the ISPBX system;- External directory : containing the parties in other PABXs or the PSTN. These

parties can be reached by a single key press;- Guest directory : containing temporary parties located in the ISPBX system

e.g. guests in a hotel.

163

Within each directory a number of facilities are offered:

- To enter a party: a fill-in screen is provided where the name, the first and second number, the branch (internal directory only) and additional information can be entered.

- To change the information related to a party: the related fill-in screen is displayed where the required changes can be made;

- To search for a persons name and find the related telephone number;- To search for a telephone number and find the related name;- To search for a branch and find all persons working in that branch;- To zoom-in on the additional information of a party as entered in the fill-in screen;- To dial the first or second number of the selected party.

When a call is answered by the operator, the computer automatically searches for the persons name.

The directory entries in the SuperVisor can be assigned to an hierarchical company structure, comprising headquarters, divisions, departments and offices.

7.2.1. Directory Management

The directory information in an operational system can be adapted by a person who is allowed to make changes in the SuperVisor database. At that moment the new information is available for the operator. The directory change is marked with a time stamp. If a number of SuperVisor operator positions are connected to the ISPBX system, it is not necessary to make the directory change manually in each SuperVisor. By defining one SuperVisor as Master and the rest as Slaves, the change need only be made in the Master; see note. The Slave SuperVisor's make contact with the Master and by examining the time stamp of the changes, the updates can be downloaded to the Slave.

Note: If the Master and Slaves are SuperVisor 50Es, directory changes can be made on the Slave. The Slave contacts the Master and uploads the directory changes. After that the Master takes care of downloading the directory changes to the other Slaves. Directory Updating for SuperVisor 50E systems is real-time.

7.3. TELEPHONE MANAGEMENT SYSTEM / SystemManager

A Telephone Management System or a SystemManager is a computer system that is connected to the ISPBX system via the CPU (CPU platform) or BIM (CCS platform). Both processors (CPU of ISPBX and the processor of the management system) can communicate with each other via this link and thus the management system can offer additional facilities for the ISPBX extension users or system managers.

164

In the Account Manager software module of the TMS or SystemManager, the structure of the company with headquarters, divisions, departments and offices can be defined. The ISPBX DNRs are assigned to a specific place in this organisation structure. This structure can be used to allocate costs, made for external calls, not only to the individual DNRs but also to offices, departments etc.

When defining a ISPBX extension DNR in the management system (in any of the internal, external or guest directories) the same fill-in screen as provided by the SuperVisor computer is used. Name, first and second number, branch (internal directory only) and additional information can be entered.

The terminal of the TMS or SystemManager can also be used as operator post offering the same options as a SuperVisor.

In this situation a normal ISPBX extension is used as operator extension. This number must be entered when logging in on the management system. When the operator now initiates a call, the computer sends a message to the ISPBX indicating originating and destination number. The ISPBX now calls the 'operator' DNR and when answered the ISPBX establishes a speech connection with the party the operator selected.

When a party (internal or external) calls the TMS 'operator' DNR the ISPBX sends a message to the management system. This system now displays a header line on the terminal with the calling number. The computer automatically searches for the related name and, when found, displays it in the header line. The ISPBX must know that this DNR is related to the management system. Therefore the DNR that is assigned as 'operator' extension must be assigned FCM 28 (external service display).

7.3.1. Directory Management

The directory information in an operational system can be adapted by a person who is allowed to make changes in the TMS (SystemManager) database. At that moment the new information is available for all TMS software modules. The directory change is marked with a time stamp.

A SystemManager operating under UNIX also has a Directory Distributor module. With this module the system acts as the Master computer and all SuperVisor's as Slaves. Directory changes can be distributed from Slaves to the Master and from the Master to all Slaves.

For more information: see chapter 10. "SystemManager".

165

8. FACILITY MANAGEMENT

The ISPBX supports a wide range of facilities that can be offered to each extension in the ISPBX system. In this manual the user aspects of the facilities and the implementation aspects are not discussed. For these aspects refer to the System Manual and other Facility Implementation Manuals.

In general, only a limited group of extensions will use a specific facility or even be allowed to use a certain facility. Therefore the system manager should have a good overview of which extension users are allowed to use a certain facility.

In this manual the 'facility class marks' and 'prefixes' methods are described which can be used to allow or restrict the use of a certain facility.

With regard to the compatibility value check it is assumed that the connection between the involved CVs is allowed. This mechanism can also be used to allow or restrict the use of a certain facility which involves a connection between two circuits and therefore between two CVs.

With regard to the traffic class check it is assumed that the dialling of certain numbers or codes is allowed for the related user. The mechanism can also be used to allow or restrict the use of a certain facility which involves the dialling of a number or a code.

The number analysis is performed in the analysis tree related to the analysis group the extension belongs to. By creating a multi-user system with a number of analysis groups, the activation of facilities (dialling of prefixes or numbers) can be managed by the system manager.

8.1. FACILITY CLASS MARK

A Facility Class Mark (FCM) is a mark that is assigned to a DNR. When a DNR is involved in a call (originator or destination), the call processing software examines the related facility class marks to see if the access by or to this DNR / facility is allowed.

• ExampleIf a call arrives over a trunk line with DDI and the received number indicates a destination DNR with FCM 09 (indialling barred), call processing will not allow the connection.

With most facilities, the facility class mark is not the only aspect related to the facility. By looking to the facility class mark, call processing determines what kind of facility is required. In another part of the configuration database in the CPU memory the other aspects related to the facility are used to complete the facility.

• Example

166

If an extension with FCM 17 (hot-line) goes off-hook, call processing is notified. When call processing examines the facility class marks, the hot-line facility is encountered. In another part of the CPU configuration database the destination for the hot-line (predefined by the system manager) is determined and the connection to that destination established. The extension user does not have to dial a number.

A large number of facilities must be activated by the user first, usually by dialling a certain code from his extension. The facility class mark now determines if the extension is allowed to activate this facility.

• ExampleIf an extension goes off-hook and dials a prefix with res. id. 27 (activate follow-me), the call processing software examines the facility class marks for that extension. If this extension does not have FCM 07 (follow-me entitled) the activation of the follow-me facility is not allowed.

8.1.1. Assigning Facility Class Marks

The facility class marks that are given in the OM-commands manual can be assigned to a DNR by using the OM-command ASFACM. This command is only accepted when the entered facility class mark is unrestricted for the device the command is entered from. For more information: see chapter 6. "SECURITY MANAGEMENT".

If a facility class mark can be directly assigned to a DNR it can also be directly erased with the OM-command ERFACM.

The facility class marks that are marked with 'RO' (Read Only) cannot be assigned/erased with ASFACM/ERFACM. Other OM-commands must be executed to mark a DNR with that facility class mark. If for instance the OM-command CHHOTL is executed for an originator DNR, this DNR is automatically assigned FCM 17 (hotline). These Read-Only facility class marks cannot be erased with ERFACM. Again the OM-commands that are specially related to that facility must be used to erase the facility class mark.

All facility class marks related to DNRs can be displayed with the OM-command DIFACM.

In the system manager module of the TMS / SystemManager system or in the SUPERVISOR 50, the facility class marks can be assigned from a menu. The external device analyses the command and transfers it to the ISPBX using appropriate commands.

8.1.2. Default Facility Class Marks

In the CPU memory, a part is reserved for default facility class marks. When a (new) DNR or a range of DNRs is created for the first time in the ISPBX system, the default facility class marks

167

are automatically assigned to the DNR(s). The facility class marks that can be added to or deleted from the set of defaults are marked with a 'D' in the OM commands manual. Read Only facility class marks cannot be entered as a default facility class mark. The OM-command used: CHDFCM.

To display the set of default facility class marks: DIDFCM.

8.2. PREFIX

A number of facilities must be requested by the extension user before they are activated. The user must dial a code or prefix from an extension. The number analyses now reaches a number complete situation resulting in a facility request. The ISPBX CPU activates the facility for the extension.

• ExampleIf a follow-me or a fixed follow-me is active, the user can dial a prefix with res. id. 32 (cancel follow-me) e.g. #21. The ISPBX analyses the number (#21) and determines what kind of facility is required. The active folio- me is cancelled.

For a number of facilities the dialled code is not the only aspect related to that facility. After the number analysis indicates what type of facility is required, another part of the configuration database in the CPU memory is accessed to retrieve the other aspects related to the facility.

• ExampleIf a user dials a prefix (e.g. **) with res. id. 23 (common pool abbreviated dialling) the ISPBX reaches a number complete situation. All pre-defined abbreviated numbers are stored in a abbreviated dialling list. If the user now dials the digits '10' the ISPBX searches in the abbreviated dialling list if the entry **10 is defined. If the number exists, the expanded number is retrieved and the connection to this number established.

If a facility prefix is assigned in an analysis tree, all users are allowed to dial the prefix. To restrict the use of some facilities, the facility is not automatically activated if the prefix is dialled. Only users with the allowance mark (facility class mark) can activate the facility.

• ExampleIf an extension user dials another DNR and this DNR is busy, he can break into the connection by post dialling the digit with res. id. 58 (break in), e.g. the digit 1. If call processing detects the break in request, the facility class marks of the originator of the request are examined. Only if FCM 02 is assigned is the break in request actually carried out. Note that it is possible that the call is protected from break-in.

168

8.2.1. Assigning Prefixes

All prefixes used for facilities are assigned with the ASINTN command with two exceptions. The prefixes for abbreviated dialling (common pool with res. id. 23 and individual with res. id. 24) are assigned with the ASBLCK command.

Depending on the activation request by the user, the prefix must be assigned in the applicable analysis tree.

If the request is initiated with initial dialling or enquiry dialling the analysis trees belonging to the dial type 0 or 1 for the applicable analysis group are used.

If the request is initiated when a connection setup has already been performed (successfully or unsuccessfully) but the extension user wants an additional facility, the analysis tree for post dialling (dial type 3) is used. The time interval that is allowed between the (unsuccessful) connection setup and the first post dialling digit (e.g. automatic ring back, break in) is determined by the system timer NETIMER 004 (post dialling time) If the facility is especially intended for operators, the operator dialling tree (dial type 2) is used.

Note: The external numbers are assigned in the DDO-tree with the ASEXTN or ASEXTP command. These numbers are automatically assigned res. id. 22.The internal numbers (DNRs) are assigned in the applicable tree(s) with the ASBLCK command. These numbers must be assigned the result id 10.

8.3. VOICE LOGGING

Voice Logging is a facility that logs telephone calls in the ISPBX. The logged party is named 'VL-Subject' and the log is sent to the 'VL-Destination'. The VL-Subject and the VL-Destination are both DNRs of the same ISPBX or the same multi unit configuration (no group DNR and no operator DNR (see note)).

Note: Since Call@Net 2.6 it is possible to log operator calls as well. So the VL-Subject can also be an operator DNR.

Example

Party A is the VL-Subject and party D is the VL-Destination. Party A calls party B or party B calls party A. In that case the conversation of parties A and B is sent to party D for logging. Parties A and B are not aware of the fact that they are being logged, no signalling is sent to parties A and B.

Voice logging is realised by using the Add-On circuits on the PMC boards. Each PMC has 10 Add-On circuits. The Add-On circuits are also used for three party calls and for the break-in

169

facility. In case all available Add-On circuits are in use and a voice logging request is received, it will not be executed.

Voice logging supports the following :

• Extension with one connected partyThe extensions voice log contains both the voice of the extension user and connected party.

• Extension with one connected party and one on holdThe extensions voice log contains both the voice of the extension user and connected party.The voice log will not contain the voice of the party on-hold.

• Extension break-in on extensionThe extensions voice log contains the voices of the extension user, the user of the extension broken-into, as well as the voice of the third party.

• Extension involved in add-on conferenceThe extensions voice log contains the voice of the extension user, as well as the voices of the second and third party.

Since Call@Net 2.6 the 'Extension' in above call situations can also be an operator.

For operators, in addition the following is supported :

• Operator Listening-in on partiesThe operators voice log contains the voice of the operator, as well as the voices of the second and third party.

Each time a VL-subject becomes involved in a call, the voice logging facility will start a voice logging call towards the VL-destination.

In case the VL-subject is an extension the voice logging call starts when the extension initiates a call, or when it is being called.

In case the VL-subject is an operator the voice logging call starts when the operator initiates a call, or answers a call from a queue.

Note that the voice logging call does not start already when a call arrives in an operator queue.

The Voice Logging facility is licensed : license 48. Voice logging is initiated by OM command CHVLRE. This command establishes the relation between the VL-Subject and the VL-Destination. The command is password protected. OM command DIVLRE which displays the established VL-Subject/VL-Destination relations, is not password protected. For further information, see the chapter 'Voice Logging' in the OM Commands manual.

170

When voice logging destinations may not be dialled directly, the voice logging destinations must be protected by assigning compatibility values.

Any diversion set on a voice logging destination is not executed.

To prevent lost Voice Logging calls, FCM 30 (auto COB on destination) must be assigned to a voice logging destination.

The 'maximum number of voice logging relations' is defined by LOBOUND 358.

Signallling group 321D (ALC Voice Logging) must be used in case Voice Logging recording devices (connected to an ALC) are used that do not support the answer and/or release signal. Those type of devices start recording when an in-band signal is received and stop recording when, during a certain period, no signal is received. This signalling group 321D is available in PMC package 410.07.01/510.07.01.

8.4. SILENT MONITOR

8.4.1. Introduction

In the Voice Logging functionality the relation between the tapped user (the voice logging subject) and the tapping user (the voice logging destination, i.e. the recorder) is entered via an OM command. As soon as the tapped user starts a new call, a connection is built to the tapping user. Upon answer, speech paths of the tapped and tapped opposite parties are offered to the tapping party, via an Add-On Circuit/Break-In Circuit (AOC/BIC) on the PMC.

In the Silent Monitor (listen in) functionality (since Call@Net 2.10) the connection with the tapping party is not built automatically but established by an authorised tapping party. This tapping party (having FCM 73 - Listen in call entitled) dials the prefix (result id 154, listen in call) followed by the number (DNR or NDNR) of the internal party that has to be tapped. Note that the listen in function can not be initiated via CSTA, since it does not support facility dialling.

It is possible to initiate listen in calls between extensions in the FIN / DPNSS / iSNet QSIG network, assuming that both the originating node (tapping party) and destination node (tapped party) are running Call@Net 2.10 or higher.

Since Call@Net 2.11, simultaneous listen in calls to the same tapped party is possible. Upto 16 simultaneous listen in calls to the same tapped party can be made. This can be either 16 tapping parties or 1 voice logging destination and 15 tapping parties.

171

No audible indication is given to the tapped party that the call is tapped. All facilities like add-on, break-in and enquiry are still available to the tapped extension and tapped opposite party.

Listen in is only executed when (N)DNR is dialled after the prefix. Any other result is handled as if the Listen in prefix was not dialled. When for example after the Listen in prefix, the digits corresponding to :

- the 'Operator General' are dialled, the call ends in the operator M queue.- the 'Trunk Access Code' are dialled, the call is handled as a normal trunk call.

After establishment, the Voice Logging protocol is used for the actual listen in of the tapped and tapped opposite party. Therefore the Voice Logging license (number 48) must be available in the unit of the tapped party.

Parties can not be protected against listen in.

8.4.2. Restrictions

1. Starting listen in is only allowed from initial dialling (not from enquiry).2. The number of Add-On/Break-In circuits available in the system limits the total number of

calls that can be tapped.Speech paths of the tapped and tapped opposite are not offered when there is congestion on resources, for example the number of free Add-On/Break-In circuits.

3. A listen in call doesn't receive signalling information like calling line identity and called party info.

4. A group DNR can not be a tapped party.5. If the tapped party is a CSTA initiated 'consultation call initiator' then the tapped party will

not notify 'break-in' on the opposite party.6. It is not possible to have Voice Logging and Listen in simultaneously active on the same

tapped extension.

Tapping Party : an extension with FCM 73, or an incoming inter unit, DPNSS or iSNet QSIG call, marked as a listen in call, set-up by an extension with FCM 73. An operator can not be a tapping party; it can be a tapped party/tapped opposite party.

Tapped Party : an extension or operator identified with its (N)DNR of which a call is tapped.

Tapped Opposite : an extension, operator or trunk connected with the tapped party.

172

8.4.3. Tapping of an Active Tapping Party

An active tapping extension can not be subjected to voice logging or listen in, but it is possible to listen in/voice logging to a party that is listening-in over DPNSS or iSNet QSIG network. The following figure illustrates the various configurations in which an already active tapping party can be tapped by another tapping party.

Figure 8-1 Tapping of an Active Tapping Party

A B

D

C

Scenario 2

E

A B

D

C

Scenario 3

A B

D

C

Scenario 1

DPNSS /iSNet QSIG

DPNSS /iSNet QSIG

DPNSS /iSNet QSIG

DPNSS /iSNet QSIG

173

• Scenario 1If parties A and B are involved in conversation, and party C which is within the same PBX as party A, is having a “listen in call” to the tapped party A, then party D can not initiate a listen in call to the tapping party C. Also not over DPNSS / iSNet QSIG.

• Scenario 2If parties A and B are involved in conversation, and party C is having a “listen in call”, to the tapped party A over DPNSS / iSNet QSIG network, then there can be another tapping party D, which can initiate a listen in call to the tapping party C.

• Scenario 3There can be another tapping party E, which can initiate a “listen in call” to the already tapping party D.

174

9. REMOTE MAINTENANCE

9.1. INTRODUCTION

Remote maintenance is a facility that can be used by a maintenance engineer for all ISPBX management functions. The engineer can use a management device that is not physically located at the same premises as the ISPBX system. The management device is connected to the iS3000 iSNet of ISPBX units using a modem-modem connection through the Public Switched Telephone Network (PSTN). Via this connection the remote maintenance actions can be performed.

The port of the iS3000 iSNet where the modem is connected, is called the Remote Maintenance Port. This remote maintenance port will act as the controlling 'device' at the iS3000 iSNet-side for the remote maintenance function(s).

With an incoming call this port makes sure the connection to the ISPBX system is allowed, so it is used at the ISPBX side for system security. If the connection is allowed, this port determines what kind of remote management device is active and invokes the necessary actions towards the ISPBX system. A call back from the remote maintenance port to the management device can also be implemented for system security.

In this configuration the management device serves as the controlling station, the remote maintenance port as the slave with regard to the connection between the ISPBX and the remote maintenance device. The management device controls the connection set-up but the actual connection can be established by a call back procedure.

The alarms that are generated by the ISPBX are autonomously delivered to a remote alarm logging system. The remote maintenance port detects the alarm, retrieves the alarm number of the alarm logging system and establishes the connection via a dial-up modem-modem connection. The identification of the ISPBX system and the alarm(s) are transferred to the remote logging device in a message. In the alarm logging system, a number of management devices are also located for solving the problems that were reported by the remote alarm signalling of a number of ISPBX systems.

Because the remote maintenance port, the alarm logging system and the management devices are connected to the PSTN via a modem, they all are identified by a PSTN subscriber number. By dialling a subscriber number, the connection required for remote maintenance actions/remote alarm signalling can be established. Both the remote maintenance device and the remote maintenance port can be the initiator for this connection set-up.

175

9.2. REMOTE MAINTENANCE PORT

The remote maintenance port is the port in the ISPBX system which is used for the remote maintenance actions and the remote signalling of alarms. This port controls the modem and the communication with the ISPBX CPU for the maintenance actions.

The remote maintenance port offers the following functionality with regard to remote maintenance:

- The remote maintenance port performs the system security functions for incoming calls using a configuration file. After a correct identification sequence (or call back facility) the remote maintenance port opens the communication with the ISPBX for a remote device, for instance a remote SMPC or Multi-Site System Manager (MS-SSM);

- The remote maintenance port detects alarms in the ISPBX or even a 'system down' situation of a ISPBX via the CIE relay contacts (iS3070/3090) or MDF. The remote maintenance port knows from the configuration file which subscriber number to dial and transfers the alarm to the alarm logging system;

- For iS3070/3090 systems the remote maintenance port can force a warm or cold start, via a connection to the CIE sensor points, on request of the remote engineer.The warm start is forced by activating CIE sensor point 8.The cold start is forced by activating CIE sensor point 6. The system option LOSYSOP 033 (no reload via sensor point 6) must be 'yes' to make sure the cold start is possible. If this option is 'no', the cold start is NOT performed when sensor point 6 is activated.

If real remote alarm signalling is active, the ISPBX redirects an alarm to the remote maintenance port. The remote maintenance port will accept the alarm and deliver it to the alarm logging device in the remote maintenance centre.

The remote maintenance port in the ISPBX system is one of the following:

- For the iS3070/3090 on CCS platform, the BIM, used to interface with the Multi-Site SystemManager system. This issue is discussed in the following sections. Chapter 10 gives more information about the Multi-Site SystemManager system.For detailed information of the (Multi-Site) SystemManager system, reference is made to the SystemManager documentation.

- For all systems except the iS3070/3090, a port on the CPU.

An example of a remote maintenance configuration either via the PSTN or private network is illustrated below.

176

Figure 9-1 Example of Remote Maintenance Configuration

9.2.1. BIM Remote Maintenance Port - iS3070/3090 CCS platform only

Refer to the BIM User Guide for details of how to connect the modem and other peripherals to the BIM.

9.2.2. CPU Remote Maintenance Port - All Systems Except iS3070/3090

The modem connected to the CPU is the actual remote maintenance port. The modem is controlled by the CPU.

The CPU can transmit data to the PSTN line or receive data from this line via a V.24 interface. The V.24 interface settings are:

- asynchronous;- 8 bits/character;- 1 stop bit;- no parity;- full duplex.

The control signals are transferred between the modem and the CPU via a V.24 interface. Because the modem must work unattended, the modem must have an automatic calling unit to dial the PSTN subscriber numbers. The CPU uses the Hayes commands via the CT103 and CT104 (RxD and TxD) lines in the V.24 interface to send commands to the modem and to receive messages from the modem.

After the connection between the remote maintenance port and the SSM is established, a special protocol, the BCS protocol, is used to determine which device is active in the SSM (for instance OM terminal).

MULTI SITESOPHO

SystemManager

SOPHO ISPBX

MODEMMODEM

PSTNBIM/CPU

177

The BCS protocol supports a number of logical channels (both ways) on one physical connection, so a number of devices can be used simultaneously.

The BCS protocol is also used for the remote alarm signalling. After the connection set-up between the CPU and the SSM, the two systems communicate using the protocol and the CPU sends the iS3000 alarm information to the SSM or SMPC.

9.2.3. Functionality of the Remote Maintenance Port

When a connection is established, the Remote Maintenance Port will offer a number of functions for remote maintenance.

• Remote Alarm SignallingThe remote alarm signalling interface receives messages from the ISPBX CPU containing information about the state-changes in the alarms in the ISPBX. The remote maintenance port will now set-up a connection to the SystemManager to report the problems. If the connection is established, the SSM is only allowed to use the remote alarm signalling functions. For a real maintenance session (OM terminal), an SSM user must set up the connection by a connect or a dial back command.To establish the connection to the SSM, the Remote Maintenance Port dials the subscriber number 0 (alarm number) of the SSM. If the call is not successful the Remote Maintenance Port will retry the connection a number of times with a time-interval. If the call is still not successful the Remote Maintenance Port dials subscriber number 1 (fall back number); if not successful it will retry the connection to subscriber number 1 a number of times with a time-interval. These items are projectable in the configuration file. Finally, if the connection set-up is still not successful, the alarm is rerouted to the MDF (alarm box or Alarm Unit) or the operator position, depending on the routing of the alarms. This re-routing will be performed to the unit where the remote maintenance port is connected.To make the remote alarm signalling facility possible (via Remote Maintenance Port), the alarm-routing must be set to 'standard' with the OM command REROUT. By executing this command with other route-types, remote alarm signalling will not be executed.To tell the system the alarms must be routed to the Remote Maintenance Port, the remote alarm signalling must be turned on. This is done by setting the system option LOSYSOP 049 (signalling at distance present).If the remote alarm signalling function of the ISPBX is activated, the system option LOSYSOP 050 (signalling at distance manual confirmation) determines if a call with alarm information from the Remote Maintenance Port to the remote management system must be confirmed. If this option is set, the timer NETIMER 097 (remote alarm confirmation time) determines the time interval within which a remote alarm signalling call from the ISPBX to the alarm logging system must be confirmed. If this timer expires without confirmation, the alarm is rerouted to the operator position or the MDF, depending on the routing of the alarms.

178

In the case of the SystemManager, this LOSYSOP 050 must be set to no, since no confirmation will be given by the SystemManager when an alarm has been signalled.With the OM command CALSIG the alarm(s) that are sent to the remote alarm signalling device can be confirmed. This command can be entered on a normal OM terminal or SMPC connected to the iS3000 iSNet or the SystemManager.Remote alarm logging device must be projected on a port of the CIE (CCS) or on a circuit of the CPU3000 using OM command ASDEVC. The logical device name must be REMALM and equipment type 27 (alarm signaller). Only one such device can be assigned in an iS3000 iSNet.

Note: Two remote alarm signallers can be assigned. First the device REMALM is used.In case this device is not reachable, the device REMAL2 is used.

To prevent temporary alarms for resources which are erroneous but can immediately be recovered successfully, delayed alarm signalling is introduced. Delayed alarm signalling delays alarming until the resource is definitely found to be erroneous.The time, date and alarm will be logged in the log file that is stored on the BIM (iS3070/3090 on CCS platform) or CPU (all systems except iS3070/3090).

• Autonomous Alarm Signalling (CCS only)This type of alarm signalling only applies to a 'system down' alarm. When the ISPBX goes 'down', this is detected by the Remote Maintenance Port. The Remote Maintenance Port will now set-up a call to the SSM with the information 'system down' and the identification string of the system which is stored in the configuration file. After completion of the autonomous alarm signalling the Remote Maintenance Port will send a break request to the SSM.For establishing the connection to the SSM, the Remote Maintenance Port dials the subscriber number 0 (alarm number) of the SSM. If the call is not successful the Remote Maintenance Port will retry the connection a number of times with a time-interval. If the call is still not successful the Remote Maintenance Port dials subscriber number 1 (fall back number); if not successful it will retry the connection to subscriber number 1 a number of times with a time-interval. These items are projectable in the configuration file. Finally, if the connection set-up is still not successful, the alarm is rerouted to the MDF (alarm box or Alarm Unit) or the operator position, depending on the routing of the alarms. This re-routing will be performed to the unit where the remote maintenance port is connected.The date and time and the alarm message will be logged in the log file that is stored on the BIM.

• Logging Functions- CCS System

The Remote Maintenance Port will store all remote maintenance sessions in the file RMAINT.LOG on the BIM. If the file does not exist, the Remote Maintenance Port will create it autonomously. New logging information will be appended to the file. Old log

179

files should be deleted regularly.- CPU3000 System

All relevant actions on the remote port can be logged. Before logging can be started (OM command STRTRL) the output device must be specified (OM command CHRLOD). The filename is not fixed, but can be defined by the user. The system always appends the unit number to the file name. For example when the filename is RMAINT, unit 11, the filename becomes RMAINT.U11.Note that when a printer is assigned as output device, this has to be another one as the one possibly assigned for toll-ticketing.

The information in the log file can be retrieved by using normal OM commands. The contents can be read by using the TYPFIL command if the terminal has the correct protection levels. The protection levels of the file will be '7777'.The following situations will be logged:- Start of remote maintenance sessions (connect or dial back);- End of remote maintenance session (break of connection);- Illegal attempts to start a remote maintenance session;- Alarm messages sent by the remote alarm signalling facility of the ISPBX;- Alarm messages sent by the autonomous alarm signalling function of the Remote

Maintenance Port.Each entry will contain the following information:- Reason for logging (connect, dial back, disconnect, illegal attempt, alarm);- User and group identification;- ISPBX system identification;- Time stamp (year, month, day, hours, minutes);- Alarm status in the case of an alarm message (major, minor, silent, system down).

• ConfigurationFor CPU3000 systems OM command CHREMC is used to configure the remote maintenance port. No separate file is created.For CCS systems, the configuration files (RMAIN0.pdt) are stored on the BIM, so it is always possible for the remote maintenance port to gain access to this file as long as the Remote Maintenance Port are operational. The file contains all projectable information for the remote maintenance functions. The file protection (NARD 7777) ensures that unauthorised access is inhibited.

9.2.4. Modem

The physical connection through the PSTN between the Remote Maintenance Port and the SystemManager is established by means of two modems. A special condition must be fulfilled for the modem at the location of the ISPBX network. Normally nobody will be available at the ISPBX system where the remote maintenance actions have to be performed. Because of this and the requirement for the call back facility, the Remote Maintenance Port must be able to

180

control the modem. The modem must contain an Automatic Calling Unit that can be used by the Remote Maintenance Port to set up a call to a pre-defined destination.

The subscriber number of the SystemManager is stored :

- in the configuration file on the BIM (CCS system). The modem configuration data can be set or changed by creating a (new) configuration file.

- in the MIS file (CPU3000 system), since this modem data is done via OM (CHREMC).

When a call has to be initiated by the remote maintenance port, the Remote Maintenance Port retrieves the required subscriber number, transfers this number to the modem and the modem dials the number. This procedure is followed for remote alarm signalling or the initiation of a call back for a remote maintenance session.

Whenever a call has to be initiated by the remote maintenance port this number will be dialled. This number will also be the alarm number that is dialled for the remote alarm signalling.

The Remote Maintenance Port uses Hayes commands to control the modem

9.3. CONNECTIONS FOR REMOTE MAINTENANCE

9.3.1. Connection Set-Up towards the ISPBX

The SystemManager user can initiate a connection request to a particular ISPBX system by dialling its PSTN subscriber number. When an incoming call is detected by the ISPBX modem, this will be signalled to the Remote Maintenance Port. The Remote Maintenance Port port will answer the incoming call and the connection is established.

The Remote Maintenance Port will now wait for a message from the SystemManager. This message may be:

• Connect Command Followed by a PasswordThis command is very useful if the SystemManager user is not located on a pre-defined position (subscriber number) in the PSTN. The SystemManager user number is not stored in the configuration file so the call back facility is not possible. Because of the direct connection, the password is the only tool for system security. The password is scrambled before it is transmitted.If the connect command is allowed and the password is correct (both parameters are projectable in the configuration file), the Remote Maintenance Port enables the SystemManager user to use the remote maintenance functions. An entry in the log-file with a time stamp denotes the remote maintenance session.If one of the parameters is incorrect an illegal attempt counter is incremented and a note is put in the log-file together with a time stamp. If the number of successively illegal

181

connect attempts exceeds a configured maximum (projectable in the configuration file), an alarm is generated.

• Dial back or Dial back Command Followed by a PasswordThis command is only possible if the SystemManager is located at a pre-defined position (subscriber number) in the PSTN. This pre-defined subscriber number (1...9) is stored in the configuration file. Both the password and the dial back facility are used for system security. The password is scrambled before it is transmitted.If the dial back command is allowed and the password is correct (both parameters are projectable in the configuration file), the SystemManager breaks the connection and after some seconds the connection to the SystemManager will be set-up by the Remote Maintenance Port. An entry in the log-file together with a time stamp denotes the remote maintenance session.If one of the parameters is incorrect an illegal attempt counter is incremented and a note is put in the log-file together with a time stamp. If the number of successively illegal connect attempts exceeds a configured maximum (projectable in the configuration file) an alarm is generated.

• Abort Dial-back Command Followed by a PasswordIf the 'abort dial-back' command is allowed and the password is correct (both parameters are projectable in the configuration file), the Remote Maintenance Port will stop the dial-back command that is being executed. If no dial-back command is being executed, an error status is returned to the SystemManager.This is not used by the SystemManager.

• Give System Identification CommandThe Remote Maintenance Port returns the identification string (stored in the configuration file) and the coding key used to code the password, before it is transmitted to the SystemManager.

9.3.2. Connection Set-Up from the ISPBX to the SystemManager

The connection set-up from the ISPBX to the SystemManager will be initiated in the following situations:

• Remote Alarm SignallingUpon request of the ISPBX CPU, the connection set-up can be initiated by the Remote Maintenance Port for transferring a message to the remote alarm logging device if a major, minor or blocked alarm is generated (or cleared) in the ISPBX.If the ISPBX system goes down, this will be signalled via the CIE and MDF to the Remote Maintenance Port (not for CPU3000 system). The Remote Maintenance Port now autonomously sets up a call to the SystemManager. The alarm subscriber number is stored in the configuration file.After the connection to the SystemManager is established, the Remote Maintenance Port

182

only enables the alarm signalling functions. The SystemManager will retrieve the alarm from the Remote Maintenance Port using a special protocol. After that the alarm buffers are read.For a real maintenance session, the SystemManager must send a connect command to the remote maintenance port.If the call set-up (after the fall back number is tried) for remote alarm signalling fails, the remote alarm signalling software is informed. The alarms will be rerouted to the operator position and/or to the MDF (alarm box/Alarm Unit) depending on the projected routing of alarms. An entry with time stamp will be put in the log-file.For more information about the routing of alarms: see chapter 2. "FAULT MANAGEMENT".

• Dial-back CommandWhen the Remote Maintenance Port receives a dial-back command from the engineer workstation, the SystemManager breaks the connection and the Remote Maintenance Port tries to set up a call to the pre-defined subscriber number of the SystemManager.If the connection is established successfully the Remote Maintenance Port enables the remote work-station to use all facilities necessary for remote maintenance.If the connection is not successful the Remote Maintenance Port will try to establish the connection a number of times, separated by a time interval (both parameters are projectable in the configuration file).

9.3.3. Connection Break-Down

The normal procedure for breaking a connection between the remote system and the ISPBX is done by sending a break request. Either the SystemManager or the Remote Maintenance Port may send this request. The opposite party can prevent the connection being broken by returning an error status within 10 seconds. If no error status is received on a break request, the connection is broken.

The connection will also be broken by the Remote Maintenance Port in the following situations:

- Loss of data carrier;- Line is dead (no BCS protocol polling for more than 5 minutes);- Modem cable is removed;- The Remote Maintenance Port performs a hardware reset. The hardware reset is not

performed when the maintenance session is busy.

The break of the connection will be recorded in the log-file.

183

9.4. FUNCTIONALITY OF THE SystemManager

The SystemManager will establish a special communication protocol with the Remote Maintenance Port when the connection for alarm signalling is established.

The Fault Manager of the SystemManager has basically 3 functions:

• Fault CollectionWhen the Fault Manager is active the system starts collecting and storing alarm status reports. The detection and clearing of system-down, major or minor alarms can be sent to the Fault Manager autonomously by the ISPBX system.The status-change of major, minor or silent alarms can be collected by the fault manager by polling the related ISPBX systems. The Fault Manager now calls the ISPBX system and after a logging-in procedure (system security) the Fault Manager asks for the alarm reports by means of OM-procedures. This is very useful for systems that cannot autonomously sent the alarm reports.The operator of the fault manager can also enter an alarm report manually.When an alarm report is entered in the database, the alarm status is set to 'NEW' in the fault manager. When the alarm is solved, the alarm status is set to 'cleared'. In the user information field, the solution to the problem can be entered so that it is available for all maintenance engineers.For every unit in the iS3000 iSNet of ISPBX units, a fault counter is present. Each time a alarm is detected, the fault counter is incremented.

• Fault AnnouncementWhen a new fault is detected this will be signalled to a Fault Announcement destination; this destination may be a printer or another application.This other application can be very useful in case the fault manager is unattended, for instance, during the weekends.Another possibility is to use the real-time fault monitoring option. The moment a fault is announced, it is displayed in the real-time fault monitoring display.

• Fault InspectionThis function offers the possibility to retrieve information from the collected reports in the fault database. This information can be displayed in different layouts as will be described in the following sections.

In the following sections the facilities of the Fault Manager are discussed in more detail.

• Display Actual Fault InformationThe Fault Manager collects all 'NEW' alarms of all related ISPBX systems and displays them on the screen of the terminal. The fault manager operator will be able to zoom in on a particular ISPBX and on a particular alarm in that ISPBX. The fault status can be changed from 'NEW' to 'cleared' if the operator is allowed to perform that action. The user

184

information can also be changed.• Display Fault History

The Fault Manager collects ALL alarm reports (also for cleared alarms) of one or of all related ISPBX systems and displays them on the screen of the terminal. The fault manager operator will be able to zoom in on a particular ISPBX and on a particular alarm report in that ISPBX. The fault status can be changed from 'actual' to 'cleared' if the operator is allowed to perform that action. The fault can also be deleted from the database. The user information can also be changed here.

• Display Fault CountersThis option gives an overview of the total number of received alarm reports per ISPBX system ('active' and 'cleared'). The remote maintenance system operator can reset the counters if allowed.

• Enter Fault InformationThe SystemManager user can enter a fault manually for a given ISPBX. After selection of the ISPBX from a list, all related data for that ISPBX must be entered manually.

• Poll Fault BufferThe SystemManager user can select a ISPBX from a list. Now the Fault manager starts polling this ISPBX for faults.

• Remote Maintenance System Manager DataIn the Fault Manager, some information must be entered which is used by the system for customising the Fault Manager module for the related ISPBXs.The Fault Manager project data comprises the following items:- Polling interval for:

ISPBX without autonomous fault indication;ISPBX with autonomous fault indication.

- Maximum number of retries to be performed for a connection set-up to a ISPBX.- Fault announcement:

reason of fault announcement;destination of fault announcement.

- Maximum number of alarms in the fault database.- Number of oldest alarms to be deleted when the fault database is full.

9.5. CHECKLIST ISPBX - SystemManager CONNECTION

To enable remote maintenance of the ISPBX system using the SystemManager, the configuration of the Remote Maintenance Port in the ISPBX must be equal to the settings in the ISPBX database of the SystemManager.

The Remote Maintenance Port requirements are the following:

- For the BIM (iS3070/3090 on CCS platform). The remote management interface (using the BCS protocol) must be enabled, not the local OM interface (by OM command

185

ASPORT).For the CPU (all systems except iS3070/3090). The remote management interface (using the BCS protocol) must be enabled, not the local OM interface (by OM command ASPORT).

- The password defined in the configuration file must be the same as the password defined in the ISPBX database of the SystemManager.

- The system identification defined in the configuration file must be the same as the ISPBX identifier defined in the ISPBX database of the SystemManager.

- If the authorisation mechanism is set to 'Call-back' in the ISPBX database of the SystemManager, the Remote Maintenance Port must allow the 'dial-back' command as connection set-up command.

- If the authorisation mechanism is set to 'Direct' in the ISPBX database of the SystemManager, the Remote Maintenance Port must allow the 'connect' command as connection set-up command.

- If alarms should be signalled autonomously by the ISPBX, the system option 'Signalling at distance present' (LOSYSOP 049) must be set to 'YES' and the route type (REROUT command) must be 'Standard' (according to PE parameters). In addition, the system option 'Signalling at distance confirmation' (LOSYSOP 050) must be set to 'NO', since no confirmation will be given by the SystemManager when an alarm has been signalled.

- The alarm number for the SystemManager in the configuration file should be the telephone number of a SystemManager channel. This channel must be defined in the channel configuration of the SystemManager.

- The dial-back number for the SystemManager corresponding to the remote station identification in RMAIN0.CNF must be the telephone number of a SystemManager channel. This channel should be defined in the channel configuration of the SystemManager.

- The modem protocol (V.25bis/Hayes) and speed are determined by the kind of modem connected to the Remote Maintenance Port.

186

10. SystemManager

Note: For the SysManager, please see the text in the Preface of this manual.

The SystemManager (SSM) is a separate computer system connected to the iS3000 system via one or more V.24 links. Via these links the computer system can communicate with the CPU of the iS3000 and a number of management functions can be transferred between the iS3000 and the SSM.

Several facilities, available for ISPBX extensions are also supported. If one or more SUPERVISOR 50(E)s or SuperVisor model 55s are used, the SSM can co-operate with them as well, for example the use of a common name directory database.

The serial port of the computer system is connected via the BIM (CCS systems) or to the VIC3000 (CPU3000 systems) as illustrated below.

Figure 10-1 SSM connected to ISPBX

There are two ways of connecting the SSM to the CPU of a ISPBX:

- If only the Accounting Manager application of the SSM is used, the connection can be made to the printer output of the CPU board. This CPU port is then adapted for local toll ticketing output (serial output). The default baud rate is 19200.

HOST

TT*VIC3000

SOPHO ISPBX

SSM

BIM

Printer

System Console

User

CPU3000

CCS

ALC

User

BCS

TT*

BCS

* An extra separate link in case of a lot of TT/FDCR info

187

- If other management modules of the SSM are used, as well as the Accounting Manager, the connection (using BCS protocol) is made to a CPU port which has been assigned to the SSM, either local or remote. The default baud rates are 19200 (local) and 2400 (remote).

In case of heavily loaded iS3000 configurations it is necessary to use a dedicated toll ticketing line for call accounting. As this is seldom the case, the first method of connection has no advantages over the second method, it is recommended that the second method is always used.

The SSM software is divided into modules that can be ordered separately. Each module has a special function. Some services that are related to the installed modules can be invoked by dialling the related TMS-prefixes (projectable) from an iS3000 extension. Other services must be requested from the SSM workstation.

The basic configuration of the SSM is formed by a hardware platform (PC), an Operating system (CDOS or UNIX/UnixWare) and a Basic Module.

The Basic Module contains the following functions:

- A database with three directories (internal, external, guest);- An extension database with the organisational structure;- The management and access control facilities of the system itself.

There are four protocol types between the SSM and the local ISPBX:

In this chapter, the installation of the SSM to the ISPBX is discussed, to help the ISPBX engineer to connect the SSM to a ISPBX.

- BCS : BCS server protocol used by the Accounting Manager (for Toll Tickets) and the switching services used by the Call Manager, Hotel Manager, Patrol Manager, Access Manager and Peripheral Facility Manager, operational maintenance and disk emulation; default 9600 bps.

- FM : File Manager protocol used for file transfers; default 9600 bps.- TT : Toll Ticket protocol used by the Accounting Manager; default 2400 bps. For

heavily loaded SSM configurations it may be necessary to use a dedicated TT line for Call Accounting. This line should be connected to the Toll Ticket outlet of the ISPBX.

- OM : Operational Maintenance protocol: in general this protocol is used by all modules which use OM; default 9600 bps.A second dedicated OM line may be installed for the Performance Manager and Do Not Disturb.

188

10.1. SSM SOFTWARE CONFIGURATION

The software for a SSM is able to communicate with different ISPBX exchanges and with different software packages in the exchange. Therefore it is necessary to customise the SSM software for the correct ISPBX exchange with the correct software package. It is recommended that only the system manager is allowed to customise the SSM.

All exchange related data is stored in files on the hard disk in the SSM. By processing these files the software is customised to communicate with the ISPBX.

The SSM offers an editor program; with this editor program the configuration files can be modified. The information stored in these configuration files must be converted to the SSM format before the software can use the correct parameters.

When converting the files all information that is preceded by a ';' is ignored. There are different conversion tools available.

When the SSM software is activated, the software automatically loads the files with the exchange related data.

10.2. SSM SOFTWARE MODULES

When installing the software modules in a SSM, a serial number must be assigned to the system. The serial number indicates which software modules can be active in the system. So when installing a new module, a new serial number must be entered to indicate that the new module can be activated.

Each service that can be supported by the SSM is identified within the system by a service number. The service number is the number that will be used by the ISPBX to request the required facility from the SSM or vice versa. This service number is called a 'window'.

Table 10-1 "Services (and Numbers) between ISPBX and SSM" gives the relation between the SSM service and the service number (window). The table also gives the services that are transferred over the same physical link from the ISPBX to the SSM and vice versa (equipment type 29: TMS server).

189

Table 10-1 Services (and Numbers) between ISPBX and SSM

The Toll Ticketing records are also transferred over the same physical link from the ISPBX to the SSM (equipment type 5: TMS Toll Ticketing device).

SSM SERVICE PABX SERVICE SERVICE FROM ... TO ...NUMBER/WINDOW

DECIMAL HEX

Access manager 135 87 ISPBX to SSM

Automatic directory dialling

4 4 SSM to ISPBX

Automatically entered messages

131 83 ISPBX to SSM

Automatic name and number display

129 81 ISPBX to SSM

Bar/unbar (since 805.29 renamed to 'Change PBX data')

5 5 SSM to ISPBX

Message waiting with announcement

6 6 SSM to ISPBX

Message waiting no announcement

3 3 SSM to ISPBX

Peripheral facility manager-to-user

7 7 SSM to ISPBX

Peripheral facility manager request

133 85 ISPBX to SSM

Peripheral facility manager user-to-PFM

134 86 ISPBX to SSM

Port protection call back 8 8 SSM to ISPBX

Room status 130 82 ISPBX to SSM

Security patrol manager 132 84 ISPBX to SSM

Security patrol manager alarm

6 6 SSM to ISPBX

Wake-up 2 2 SSM to ISPBX

190

The TMS services are separated over two files:

- In file TMSSVC.PDT the windows H'2' to H'8', excluding H'7', can be activated;- In file PABXSVC.PDT the windows H'81' to H'87', including H'7', can be activated.

Note: Note: For the message waiting services with or without announcement (windows H'6' or H'3') only one service can be active. In the matrix, the other service must be preceded by a ';' to indicate that this service must be disabled.If window H'3' is used for message waiting services without announcement, H'6' can still be used for the Security patrol manager alarm.When the window H'7' (PFM-to-user) is installed with a certain window size, the window H'86' (user-to-PFM) must also be installed together with the same window size.

Messages related to a specific service are transferred between the ISPBX and the SSM in a window. Such a window can be accessed by more 'users' simultaneously. The maximum number of users per window can be limited by both the ISPBX system and by the SSM. The actual number of users that can gain access to a window is the lowest of the maxima defined in the ISPBX and the SSM.

In the ISPBX unit the window size can be assigned using OM command ASTMSW: assign TMS window size, for example:

From SSM to ISPBX:

From ISPBX to SSM:

ASTMSW:2,2,1; WAKE-UP (2)ASTMSW:3,1,1; MWNA (3)ASTMSW:4,1,1; ADD (4)ASTMSW:5,3,1; CHANGE PBX DATA (5)ASTMSW:6,1,1; MWWA/SPMALARM (6)ASTMSW:7,2,1; PERIPHERAL FAC (7)ASTMSW:8,2,1; PORT PROTECTION CALL

BACK(8)

ASTMSW:81,2,1; ANND (129)ASTMSW:82,1,1; ROOMSTATUS (130)ASTMSW:83,1,1; AEM (131)ASTMSW:84,1,1; SPM (132)ASTMSW:85,2,1; PERIPHERAL FAC (133)ASTMSW:86,2,1; PERIPHERAL FAC (134)ASTMSW:87,2,1; ACCESS MANAGER (135)

191

The size should be equal to the one defined in the SSM.

The ISPBX boundary, NEBOUND 076 (maximum number of TMS slots), limits the maximum number of users (in all windows together) that can be active simultaneously over a server link.

After executing OM command ASTMSW, command CHTMSL (change TMS logical device name) must be executed for the windows 81...88, because different services can be sent to different devices.

Note: For the 'Change PBX data' the window size must be limited to '3'.For the 'Attendant Name and Number Display' the window size must be '2'.

10.2.1. Basic Module

The Basic Module is activated using the serial number of the SSM. Over the same physical link (between the BIM/CPU and a port of the SSM), several services can be offered. Therefore, a protocol is used between the CPU and the port of the SSM.

The basic module also supports the Name Directories and all operations on the directories like searching for internal, external and guest parties, changing and entering extension data (name and branch), entering and changing organisation data (headquarters, divisions, departments, offices and extensions) etc. These facilities are similar to the facilities offered by the SUPERVISOR 50(E).

it is possible to enter a message for a selected party (internal or guest). If a message is present for an extension or guest party, this will be indicated on the applicable screen of the basic module by a '!'. The SSM user can zoom-in on the message and read its contents. The message can be a Manually Entered Message (MEM) or for systems with the call manager module it can be an Automatically Entered Message (AEM).

When the Directory Distributor module is present, the messages can be distributed to the various SUPERVISOR 50(E)/SuperVisor model 55 workstations and vice versa.

The 'Automatically Entered Message' is only supported for systems with the call manager module.

All modules, except the Basic Module, are optional; all modules are activated using a serial number.

10.2.2. Accounting Manager

The Accounting Manager allows storage of toll ticketing records that are sent by the ISPBX to the SSM. The tickets are directly related to the organisation structure as defined in the basic

192

module. A ticket is always accepted by and stored in the SSM. If the initiating extension (generating the ticket) is assigned in the extension list, also the extension cost counters can be supported.

• ISPBXUsually the tickets are sent to the SSM-toll ticketing device via the server link. The device must be defined in the ISPBX on the BIM (iS3070/3090 on CCS platform) or on a circuit of the CPU (all other systems) with the command ASDEVC with equipment type 24 (TMS-toll ticketing device). In the BCS protocol over this link, a separate logical channel is reserved for the messages related to the Accounting Manager.It is also possible to transfer the toll tickets to the SSM without the use of the BCS protocol. In the ISPBX, a printer (logical device name) is assigned and the toll tickets are sent to the 'printer'. This printer port is connected to a dedicated serial port in the SSM. This port must be assigned as toll ticketing port. On the SSM a separate process is started and, via a dedicated serial port, the toll tickets can be received.The toll ticketing records are generated when a ISPBX extension makes an outgoing call. The record is generated in the ISPBX CPU memory and after finishing the call, the record is sent to a device that has been specified with the CHTTOD command. Here the logical device name of the TMS-toll ticketing device (device type 5) is specified. If the toll tickets are sent without the use of the BCS protocol, here the printer is specified. The toll ticketing is started with the command STRTTT. From this moment onwards the records are sent via the port, where the device is assigned, to the SSM. A call is submitted to toll ticketing when, for instance, the external call is made via a route with the general option 'toll ticketing' set.

• SSMThe ISPBX CPU sends the toll ticketing records in ISPBX format. The SSM must be able to analyse this format in order to understand the different fields in the format. To be able to customise the toll ticketing facility, the format of the toll ticketing records is stored in the SSM.The SSM receives the toll ticketing records from the ISPBX. The records are related to the call initiating extension and thereby to a project code, department, office or hotel room. It stores these records on the hard disk. At any moment the SSM can provide several options for presenting the cost analysis of the toll ticketing records. The call costs can be generated in various ways; per extension, project code, organisation structure etc. The Full Detailed Call Recording (FDCR) facility provides output reports on all incoming, outgoing and internal calls. These output reports are used by the SSM for Call Accounting and Performance statistics.For detailed FDCR information,3. "ACCOUNTING MANAGEMENT".The management of the organisation (headquarters, divisions, departments, offices and extensions), project codes and call tariffs is provided in the basic and accounting module which allows the structure to be adapted to correspond with the reporting organisation

193

of the customer.For hotel facilities, the call reports can be generated as bills for a hotel guest.

10.2.3. Call Manager

The Call Manager module provides the following:

• Automatic Directory DiallingThe Call Manager module provides the Automatic Directory Dialling option (same as SUPERVISOR 50) for the directories created by the Basic Module, internal, external or guest directories.The SSM user can speak via a normal ISPBX extension that is 'controlled' by the SSM as well. This extension will be regarded as a kind of ISPBX operator extension. When logging-on to the SSM, the extension that is to be used as the SSM user extension must be entered in the log-in screen.The SSM will send a message to the ISPBX via the server link (in service window H'4') to establish the connection. The extension of the SSM user will start ringing and after answering, the connection to the selected destination will be established. The extension DNR which is used as SSM user number does not have to be projected as operator; to the ISPBX it is a normal extension.

• Automatically Entered MessagesAutomatically Entered Messages (AEMs) are messages sent to the operator by a telephone user, who dials a code corresponding to the message required. The AEM is translated into text displayed to the operator.From any extension in the ISPBX system that is able to dial the TMS-prefix, a user is able to enter (the number of) a message into the SSM.After dialling the prefix a message number with a specified length must be entered. This number is transferred by the ISPBX to the SSM (in service window H'83'). Within the SSM the received message number is translated into a real message and stored under the initiator DNR. The SSM user can see that the message is present and read the message (it is indicated on the applicable screen of the basic module by a '!'. This option is offered on all SSM-workstations. When another party dials the SSM user and the SSM user selects the DNR where the message is waiting, the SSM user can provide information about the situation of the requested DNR.To implement this facility in the ISPBX, the correct prefix must be assigned in the analysis

- Automatic Directory Dialling (ADD);- Automatically Entered Messages (AEM);- Manually Entered Messages (MEM);- Attendant Name and Number Display (ANND);

194

tree for all extensions that are allowed to enter a message.

• ExampleThe prefix *313 is assigned (OM command ASINTN) in the initial dialling tree with res. id. 82 (TMS dialled) and number length 2 (the parameter field 'destination' is left empty when executing this command). This means that after the prefix (*313) 2 digits (00...99) can be used for the message; message number 00 is used to delete an AEM.The last digit of the prefix indicates the service request from the ISPBX to the SSM. The position of the service digit is told to the ISPBX by means of the OM command ASTMSD. In the example above, the fourth digit indicates the service and with the command ASTMSD the value 4 is entered.The last digit of the prefix corresponds to the last digit of the hexadecimal notation of the service window. The window for automatically entered messages is H'83' so the digit 3 at the end of the prefix indicates to the ISPBX that a message request is initiated by the user. The ISPBX now automatically uses window H'83' to transfer the message number to the SSM.The messages are defined in a file in the SSM. The first message in this file is automatically assigned the message number 00; the second message number 01 etc. When a ISPBX extension initiates a request to enter a message the entered message number is compared with the numbers in the file. If the number does not exist, this will be signalled to the ISPBX and NU-tone will be sent to the initiator. If the number does exist, the received number is translated into the defined message and registered in the message field for the initiating extension (extension must be defined in the SSM). In the screens provided by the Basic Module a '*' indicates that a message is present in the message field for that extension. The SSM user can read the message.With SSM release 2.2 the automatic entry of messages is enhanced. With the simple form of message entry the ISPBX user dials the SSM dialled prefix followed by the message number (as described above). In the SSM the message number is converted into a real text message and stored for the ISPBX party. With the enhanced form of message entry the ISPBX user must dial the same sequence (prefix and message number) but now followed by some additional digits. After dialling the total sequence, the ISPBX initiates the facility towards the SSM. The prefix, the message number, date, time and the additional digits are transferred to the SSM. The SSM checks to see if the entered information is correct and corresponds with the format indicated in the entered message number. If the check indicates that the user has dialled correctly, the user receives confirmation tone, otherwise NU-tone is returned to the calling party. At the same time the SSM enters the dialled additional digits into the defined message text and the complete message is stored for the ISPBX user.

• ExampleIn the SSM the following message is defined:

195

Message number 11: back on __/__ __:__ ;The ISPBX user dials the TMS dialled prefix *323 followed by the message number (11) and 8 extra digits (31081245). These digits will be entered in the defined places in the message. The SSM stores the message 'back on 31/08 12:45' for the extension user. The operator is able to display the message in the applicable menu. In addition to the simple message entry (only message number can be dialled) the following 5 extra message types can be defined:- A 'd' indicates that the four underscore characters (__:__) represent a date field in

ddmm format, the message will be removed when it has expired.- A 't' indicates that the four underscore characters (__:__) represent a time field in

hhmm format, the message will be removed when it has expired.- A 'D' indicates that the eight underscore characters (__/__ __:__) represent a date and

time field in ddmm hhmm format, the message will be removed when it has expired.- A space indicates that the number of underscore characters (__) must match the

number of additional information digits.- A number between 1 and 9 indicates the number of days after which a message of this

type is removed from the name directory.AEMs can be combined with a Do Not Disturb (DND) action. The action which is performed for each message is defined in the SSM:- a '#' as the first character of a message causes DND to be activated;- a '-' causes DND to be deactivated;- a space does not affect the DND status.A separate prefix (separate due to the number length difference) *323 is to be assigned in the applicable tree for the ISPBX party. When the command ASINTN is executed the parameter 'number length' must now indicate the total length (in the example 10) of the used message number (in the example 2) plus the number of additional digits (in the example 8). To correctly initiate the facility the prefix must end with the digit '3' (for using window H'83') and must have the correct length (with regard to the TMS-digit position 4).In a file in the SSM the message number must be specified with the correct format (text and place where the additional digits must be included in the message). As the ISPBX also sends the dialled prefix towards the SSM for validation, this prefix must be defined in the SSM file together with the indication of the type of the required message entry facility (date, time, number). So the prefix assigned in the ISPBX must be the same as the prefix assigned in the SSM, in the example *323.

• Manually Entered MessagesManually Entered Messages (MEMs) are messages sent to a telephone user by the SSM user or SUPERVISOR 50E/SuperVisor model 55 operator who enters the text message from the keyboard.The Manually Entered Messages result in a Message Waiting Indication, which can be:- Message Waiting No Announcement (MWNA);

196

- Message Waiting With Announcement (MWWA).

• Message Waiting IndicationIf a message is present for an extension, the Call Manager module is able to initiate a message waiting indication. A request is sent to the ISPBX (in service window H'3' or H'6') to dial the extension and notify the extension user that a message is waiting. This indication can be initiated for Manually Entered Messages that are entered at the SSM terminal to internal or guest parties.An Automatically Entered Message from an internal party cannot result in a message waiting indication.For a message waiting indication two services are available, with announcement (window H'6') or without announcement (window H'3'). Only one of these facilities must be assigned 'active'. If both facilities are assigned 'NOT active', only the message indication in the Name Directory screen is implemented. The extension is not notified about the message.

• Message Waiting No AnnouncementIf this service is activated in the SSM, the presence of a message for an extension user is signalled in the name directory screens.The ISPBX extension user for which the message is intended, receives an indication (ring burst or LED indication) of the message waiting situation. He can dial the SSM terminal number and by entering the name directory screen the SSM terminal user can pass on the message. The message can only be deleted from the SSM (or from the SUPERVISOR 50(E)/SuperVisor model 55) when the Directory Distributor module is installed. This message waiting indication is a service that is present in the ISPBX. The SSM only activates/deactivates the ISPBX facility.When the SSM activates the message waiting facility for a ISPBX extension, the message waiting type as defined in the boundary NEBOUND 145 (define TMS message waiting type) is used.The first message waiting indication is given directly when the extension is free. After that, within the maximum time interval defined by NETIMER 036, a second indication is given. The third is given after expiry again, etc.If the extension is a SOPHO-SET the message waiting indication can be given (depending on the type of SOPHO-SET) on the display or by a function key LED, when programmed for message waiting indication.If the extension is an analogue extension a ring burst indicates the message waiting situation. The ring burst is the same for all message waiting types. The duration of the ring burst is defined in the boundary NEBOUND 018 (message waiting softring time). The value of this boundary is the duration of the ring burst in units of 100 ms. With PPU 134 (upwards) this is called the softring and is defined by audio function 106 (service B ring current).

197

After initiation of the ISPBX facility the first message waiting request is initiated for that extension within a time interval defined by NETIMER 036 (message waiting trigger time). The first message waiting indication (a ring burst) is given directly when the extension is free. If the message waiting request is not successful, timer 036 is re-started and a new message waiting request is initiated after expiry of the timer. This process continues until the message waiting request results in a ring burst on the extension. If the option LOSYSOP 027 (queuing of message waiting requests) is true a message that is entered via the SSM is placed in a queue. The first message waiting request is initiated for that extension. After successfully carrying out this request (resulting in ring burst) a timer of 15 minutes is started. After expiry of that timer the new message waiting request is initiated by the ISPBX for that extension. If the request is not successful, the request is re-initiated in intervals defined by timer 36 until the request results in a ring burst on the extension. Now the 15 minute timer is re-started. This process continues until the message is deleted in the name directory screen. The SSM sends a message to the ISPBX to tell that the message waiting facility can be turned off.

• Message Waiting With AnnouncementWhen this service is active, the SSM initiates a connect request towards the ISPBX. The ISPBX extension will start ringing to indicate the presence of the message. After answering, the ISPBX extension can be connected to another DNR or to a specified tone source.The SSM can be customised to send a tone number or the number of a destination-DNR to the ISPBX. Within the ISPBX, the received tone-number can be related to a tone source or a ISPBX destination DNR.The SSM sends a port number to the ISPBX; the SSM supports port numbers 00 to 99. The ISPBX however supports tone numbers 000 to 255 but only the numbers 60 to 99 can be used. In the ISPBX, such a tone number can be related to a tone source or to a destination-DNR with the OM command CHTMST. An announcement device can be connected to such a destination-DNR.The DNR can also be routed to the SSM user. The SSM user can read the message and pass it on to the extension.When the ISPBX receives a message waiting indication request from the SSM, it tries to establish a path between the extension for which the message is present and the specified destination, either tone source or DNR.The port number that is sent can be specified in a SSM file. In this file the port number can be related to the language of the extension. If a message waiting indication must be generated for an extension, the tone related to the language of the extension is sent to the ISPBX. Now different announcement devices can be connected to the ISPBX.Also a general tone number (indicated by**) can be specified.To specify the transmission of a tone, the language indication in the SSM file must be followed by a 'P' to indicate that a port number must be sent. The tone number in the

198

range 60 to 79 must be entered after the indication 'P'.The SSM sends a destination-DNR to the ISPBX. The SSM can also be customised to send a second DNR; this DNR can be the DNR of an announcement device or a SSM user.The DNR that is sent by the TMS-device can be specified in a SSM file; in this file the DNR number can again be related to the language of the extension. To specify the transmission of a DNR, the language indication in the file must be followed by a 'E' to indicate that an extension number must be sent. The extension number must be entered after the indication 'E'.

Note: If Message Waiting No Announcement is selected, ALL lines in the file must be preceded by a ';'.

• Attendant Name and Number DisplayIf a call is made to a SSM-user the number and name of the caller are displayed on the SSM screen (except in the screens of the Facility Manager module). For the calling name facility, it is necessary to enter one's telephone number in the log-in screen (USER1 field). If this extension is assigned FCM 28 (external service display) in the ISPBX, every time a call is made to that DNR, the ISPBX sends a message to the SSM. In this message the ISPBX tells the SSM the calling number and the SSM searches for a calling name in its directory. The SSM will generate a message in the top row of the current screen telling the SSM user who is calling. The service window H'81' is used by the ISPBX to transfer the message to the SSM. The window size must be 2.If the called number differs from the original called number (in the case of call diversion) the original number is displayed as well. The caller can be an internal extension, who makes an internal call. In that case both the extension number and the name of the caller are displayed. If the name is not in the name directory, 'name not found' is displayed. If the caller is an external party, making an incoming call, only 'external extension' is displayed.

Note: The displayed name is the first name, belonging to the extension number.Because of this, every name should have a unique extension number.The called party can never be an operator because the operator cannot have a facility class mark assigned.

10.2.4. Patrol Manager

The Patrol Manager offers the possibility to control a security guard round. In the SSM the type of round can be specified. The guard who makes this patrol round has an identification number of a maximum of 3 digits. This identification number can be defined in the SSM.

When the guard starts his round, the security round has to be started in the SSM. During the security round the guard must dial the SSM from a number of extensions within certain time intervals. This sequence is patrol round dependent and can be defined in the screens provided

199

by the Patrol Manager. When calling the SSM the guard must enter his identification number and a code of 2 digits. These numbers are transferred from the ISPBX to the SSM. The 2-digit code indicates something of interest observed by the guard (for example, that a window is open). When something appears to be wrong with the security round, the SSM generates an alarm. The system will log all actions during the round.

To implement the Patrol Manager facility, the correct prefix must be assigned in the initial dialling tree for the extensions that must be used to dial the SSM during the security round.

• ExampleThe prefix *314 is assigned (OM command ASINTN) in the initial dialling tree with res. id. 82 (TMS dialled) and number length 5 (the parameter field 'destination' is left empty when executing this command). This means that after the prefix (*314) 5 digits can be used for the guard identity (3 digits) and the reporting code (2 digits).The last digit of the prefix indicates the service request from the ISPBX to the SSM. The position of the service digit is entered in the ISPBX by means of the OM command ASTMSD. In the example above, the fourth digit indicates the service and with the command ASTMSD the value 4 is entered.The last digit of the prefix corresponds to the last digit of the hexadecimal notation of the service window. The window for the patrol manager is H'84' so the digit 4 at the end of the prefix indicates to the ISPBX that a guard reporting request is initiated by the user. The ISPBX now automatically uses window H'84' to transfer the guard identity and the reporting code (5 digits) to the SSM.If the call applies to a non-active round the SSM will signal this to the ISPBX and the initiator receives NU-tone. For an active round, the tone will depend on the validation of the guard identity and the dialled code.The digits following the total prefix (*314) always indicate the identity number of the guard performing the round. The identity number is transferred to SSM for validation. The 2 digits following the guard identity always indicate the reporting message entered by the guard. This code is also transferred to the SSM.These codes have a fixed or pre-defined meaning:

11 : normal; fixed12 : alarm - window; can be adapted as for 16-2913 : alarm - door; can be adapted as for 16-2914 : alarm - heating; can be adapted as for 16-2915 : alarm - light; can be adapted as for 16-2916 to 29 : alarm - extra status;55 : delayed; fixed99 : alarm. fixed

200

Alarm text for codes 16 to 29 can be entered in an SSM file. If the entered alarm code indicates a normal situation (code 11), a signal is sent to the ISPBX and the calling party will receive confirmation tone. For all other codes (except code 55), the SSM generates an internal alarm and an alarm report is printed out.If the print-out is successfully initiated, the calling party will hear confirmation tone.If the print-out is not successful, the ISPBX extension will stay in the call-processing state. This state is guarded by BOUND 078 (TMS guarding time). If this 'timer' expires NU-tone will be sent to the extension.If the service window H'6' (security patrol manager alarm) is active, an alarm generated by the SSM can be sent to the ISPBX and invoke a certain action in the ISPBX system. In the screen Patrol Manager/Alarm Data three different situations can be defined:- The time interval between two calls is exceeded (time-out of stretch).

If this option is activated a time-out results in a call set-up in the ISPBX between an alarm extension and a port.

- The guard entered the code '99' (alarm status reported).If this option is activated, an alarm status entered by the guard results in a call set-up in the ISPBX between an alarm extension and a port.

- The guard entered the code in the range '12' to '29' (extra status reported).If this option is activated a code in the range '12' to '29' entered by the guard, results in a call set-up in the ISPBX between an alarm extension and a port.

For each of the three situations an alarm extension and a port number can be defined in the SSM. If one of the three options is active and an alarm appears for it, SSM sends a connect request to the ISPBX to connect the alarm extension to the port number. The ISPBX will try to establish a speech condition between the alarm extension and the DNR/tone source related to the received port number.

10.2.5. Facility Manager

The Facility Manager provides the user several methods for managing the ISPBX database from the SSM-workstation:

- A normal (transparent) OM terminal is available.- Menu driven OM is also possible for OM actions related to:

- Facility Marks and Traffic Classes;- DNR - Line Circuit Relations;- Group Arrangements;- Executive - Secretary;- Call forwarding;- Hot-lines;

201

- Abbreviated Numbers.

Note: Because the menu driven option uses the ISPBX OM commands, it is important that the OM commands in the SSM match the software package in the ISPBX. Therefore the PABX package must be correct in the PABX database maintenance.

- Creating batch jobs containing the OM commands that have to be executed. These batch jobs can be executed at a suitable time by means of the OM command SUBJOB in the ISPBX or by a DO-file creation in the SSM.

The OM commands are not transferred between the SSM and the ISPBX by the protocol in the server link. For the Facility Manager, a separate port of the SSM is used.

The protocol used over this special link is defined in the SSM. The port on the CPU where the port of the SSM is connected (by a modem bypass cable) must be configured as a normal OM terminal. Although this terminal is situated in the SSM, it is regarded a normal OM terminal, so protection levels, authority classes and restriction levels and faclity class mark restrictions also apply to this terminal.

In the Hotel Manager application, the SSM itself can change the traffic class of an extension in order to bar or unbar the DNR for external calls when the hotel room is not occupied. This barring/unbarring is not performed via the OM link. This action is performed via the normal server link (window H'5').

10.2.6. Hotel Manager

The Hotel Manager provides the facilities for the hotel management to change the room status to 'free' or 'occupied' by checking guests in or out. This is invoked from the SSM user station. At the same time the traffic class of the guest extension is changed in order to bar or unbar the use of the extension for external calls. Also the wake-up service for hotel guests is performed by this module.

Note: Bar/unbar only affects the extensions day/night traffic class and not the upgraded/downgraded traffic class.

• Room statusWhen a guest is checked-in, the day and night traffic classes of this ISPBX extension are set by the SSM to the value of the boundary NEBOUND 005 (default day traffic class for extensions). This value can only be changed by means of the Second Line Maintenance tool EXSUBC with subcommand S92100. After changing the value for this boundary, the new 'default day traffic class' is immediately active. It is not necessary to re-project the ISPBX unit or perform a hot start. When a new check-in procedure is performed, the 'new' default day traffic class is copied to the actual day and night traffic classes for the extension.

202

When a guest is checked-out, the day and night traffic classes of the ISPBX extension are all set by the SSM to the value of the boundary NEBOUND 004 (default night traffic class for extensions). This value can only be changed by means of the Second Line Maintenance tool EXSUBC with subcommand S92100. After changing the value for this boundary, the new 'default night traffic class' is immediately active. It is not necessary to re-project the ISPBX unit or perform a hotstart. When a new checkout procedure is performed, the 'new' default night traffic class is copied to the actual day and night traffic classes for the extension.Using the traffic classes for the trunk access codes, the dialling of a trunk access code can be allowed when the room is occupied (default day traffic class) and inhibited when the room is in the 'free' status (default night traffic class). The changing of the traffic classes is performed via the normal server link and not via the OM link as used by the Facility Manager module. To allow the SSM to change PBX data, the restriction for the SSM must be set to unrestricted. This can be accomplished with the OM commands CHTFCR (for traffic classes) and CHFCMR (for FCMs) with terminal type 3 (TMS).The room status ('clean', 'dirty', 'maid in' etc.) can also be changed from the extension in that room. By dialling a number from the extension, the status of the room can be changed in the SSM. The dialled number is transferred from the ISPBX to the SSM via the server link. If it is a valid number, the SSM changes the status of the room accordingly and the caller receives confirmation tone.The numbers that must be dialled by an extension in the ISPBX are stored in an SSM file; in this file the code to be dialled from any extension in the ISPBX system is related to an event number and a description of the action within the SSM.An example of such a file can be:; dialled code, event no; description; ------------------------------------*31222, 8; maid in*31233, 9; maid out*31211, 12; clean on inspection*31202, 10; cleaning team in*31203, 11; cleaning team out*31244, 13; dirty on inspection*31288, 16; out of order*31299, 17; in orderIn the example the prefix for dialling the SSM is *312. This prefix is assigned in the ISPBX in the initial dialling tree for the extensions in the hotel rooms. This prefix is assigned with the ASINTN command with res. id. 82. Dialling this prefix must be possible with a low traffic class. This prefix must be able to be dialled in a room with the status 'free' (extension has low traffic class) so the traffic class of the prefix must be assigned a low value.The last digit of the prefix indicates the service request from the ISPBX to the SSM. The position of the service digit is entered in the ISPBX by the OM command ASTMSD. In the

203

example above, the fourth digit indicates the service and with the command ASTMSD the value 4 is entered.The last digit of the prefix corresponds to the last digit of the hexadecimal notation of the service window. The window for the room status is H'82' so the digit 2 at the end of the prefix indicates to the ISPBX that a room status request is initiated by the user. The ISPBX now automatically uses window H'82' to transfer the room status to the SSM.After the prefix, two extra digits must be dialled for the room status report. When executing the ASINTN command the number length parameter must be assigned the value 2.When a user dials an event number as described in the SSM, the total number (also the prefix) is transferred to the SSM. If the number is correct and accepted, this will be signalled to the ISPBX and confirmation tone is sent to the initiator. If the extension is not defined in the SSM or the dialled number is not valid, NU-tone will be sent.Depending on the change of the room status, this can result in a bar/unbar request.

• Wake-Up RequestsIt is possible to enter a wake-up request for a hotel guest for a specific date and time.When the SSM detects the date and time for a wake-up, it generates a wake-up request towards the ISPBX in service window H'2'.The SSM can be customised to send a tone number or a destination-DNR to the ISPBX. Within the ISPBX the received tone number can be related to a tone source or to a DNR.

Note: After a hotel guest has entered a wake-up request, the guest can cancel the request, if necessary.

The SSM sends a tone (port) number to the ISPBXThe SSM supports the tone numbers 00 to 99. The ISPBX however supports the tone numbers 000 to 255 but only the numbers 60 to 99 can be used. In the ISPBX such a tone number can be related to a tone source or to a destination-DNR with the OM command ASTMST. To such a destination-DNR, an announcement device can be connected.When the ISPBX receives a wake-up request from the SSM, it tries to establish a path between the extension for which the wake-up is present and the specified destination, either tone source or DNR. The tone that is sent by the SSM device can be specified in an SSM file.In this file, the port number can be related to the language of the extension. If a wake-up must be generated for an extension, the port related to the language of the extension is sent to the ISPBX. Now different announcement devices can be connected to the ISPBX which are used for a specific tone. Also a general tone can be specified.To specify the transmission of a tone, the language indication in the file must be followed by a 'P' to indicate that a port number must be sent. The port number in the range 60 to 79 must be entered after the indication 'P'.

204

The SSM sends a destination-DNR to the ISPBXThe destination DNR can be the DNR where an announcement device is connected. This destination-DNR that is specified in an SSM file. In this file the DNR number can again be related to the language of the extension. To specify the transmission of a DNR, the language indication in the file must be followed by a 'E' to indicate that an extension number must be sent. The extension number must be entered after the indication 'E'.With SSM release 2.2 (with the Call Manager) the wake-up requests can be entered by the ISPBX user. The ISPBX user must dial the TMS dialled prefix followed by 4 additional digits. These digits indicate the time the wake-up must be performed. The time must be entered in the format hhmm. After dialling the total sequence, the ISPBX initiates the facility towards the SSM. The prefix and additional digits are transferred to the SSM; the SSM checks to see if the prefix is correct and if the additional digits correspond with the format. If the additional digits are 9999 a wake-up request is sent as soon as possible (within two minutes). If the prefix indicates that it concerns a wake-up request, the SSM expects 4 additional digits indicating the wake-up time. Both the prefix and the time are validated by the SSM. The SSM returns a message to the ISPBX. The user receives confirmation tone, otherwise NU-tone is returned to the calling party. At the same time, the SSM initiates an active wake-up request for the ISPBX user at the dialled time.Sending the wake-upAt the requested time the SSM sends a message to the ISPBX to ring the extension. The time that the extension is allowed to ring without being answered is guard ed by NETIMER 011 (ARB ringing time). If the extension is answered within the time then the tone or announcement is given and a 'successful' message is sent to the ISPBX. If the extension is not answered then a 'failure' message is returned to the SSM. The SSM can reschedule the wake-up request to be tried again after a short time delay (the time delay is defined in the SSM). The number of times that the SSM reschedules the wake-up can be defined in the SSM. The SSM records the wake-up result in a history file whether it was successful or not.It is possible to define a time in the SSM within which the extension should answer. This time should be chosen the same or longer than NETIMER 011.

• ExampleThe ISPBX user dials the TMS dialled prefix *333 followed by 4 extra digits (1200). These digits will be used for executing the wake-up for the extension the next time the SSM clock reaches the time 12:00.A separate prefix (separate due to the number length difference) *333 must have been assigned in the applicable tree for the ISPBX party. When the command ASINTN is executed, the 'number length' parameter must now indicate the number length of the additional digits (4).The wake-up request uses part of the Automatic Entered Message facility of the SSM.Therefore this facility also uses window H'83' and the prefix must end with the digit '3'.The prefix must also have the correct length (with regard to the TMS-digit position 4)

205

In the SSM, the validation is performed both on the entered prefix and on the entered time. The wake-up prefix together with the wake-up indication of the type of facility must be defined in an SSM file. So the prefix assigned in the ISPBX must be the same as the prefix assigned in the SSM file; in the example *333.

10.2.7. Access Manager

The Access Manager must be activated in the SSM; it provides the following services:

The messages related to the service request from the ISPBX towards the SSM are transferred in service window H'87'. In the case of a call back facility, the SSM initiates a service request towards the ISPBX. This is carried out in service window H'8'. The Access Manager module is assigned the highest priority in the SSM, while the ISPBX extension user is waiting on line for the execution of the request. If the SSM confirms the request, the service is effected in the ISPBX.

The ISPBX facilities 'password dialling' and 'port protection' are related to passwords. The default password is assigned to the extension in the SSM but the extension user must change this default password.

The user has to enter the password which is transferred by the ISPBX to the SSM together with the related DNR. The SSM validates the password and sends the result to the ISPBX. If

- Password Dialling:. Change passwords res. id: 104. Enable up/downgrading traffic class res. id: 105. Disable up/downgrading traffic class res. id: 106. Upgrade traffic class res. id: 107. Downgrade traffic class res. id: 108. Password DDO from own extension res. id: 109. Password DDO from other extension res. id: 110

- Data port Protection:. Access port direct res. id: 113. Access port call back res. id: 114. Cancel call back res. id: 115

- Cost Centre and Personal Identification Dialling. res. id: 112

206

the password is correctly entered, the ISPBX extension can use the requested facility.

Note: When using SOPHO-SETs of the P- and S-range (release 2 and higher) and K-range (connected to a KTLC-A01), and when PPU package 144 is used, passwords entered when using password dialling are not displayed.The password is not suppressed in the case of cost centre dialling or cost centre dialling with modulo validation.

If the password is wrong, the ISPBX blocks the service for the extension and a failed attempt counter is incremented in the SSM. If the counter reaches a projectable maximum, the result can be, No action, Block all password facilities for the extension or Generate an alarm in the SSM. Which action is to be taken is defined in the SSM.

The SSM user must clear the failed attempt counter. If the counter has not yet reached the maximum and the extension user enters his password correctly, the counter is reset to 0.

The maximum number of failed attempts is defined in the SSM and can be changed by the SSM user.

There are two categories of passwords:

- Passwords related to a ISPBX user-DNR, used for password dialling. Only one password can be assigned per DNR. The DNR-password relations can be added/changed/deleted by the system manager in the SSM.The following items can be defined:- DNR of ISPBX user;- Password (6 to 12 digits); here only the default password can be assigned. The default

password is stored in the SSM. Before the extension can use the password facilities, the user has to change the password by dialling the change password prefix. A changed password is not displayed on the SSM terminal any more;

- Indicator to allow the ISPBX services 'upgrading/downgrading';- Indicator to allow the ISPBX service 'Password DDO';- Maximum number of failed attempts. If the failed attempts counter has reached the

maximum number of failed attempts, the defined action is invoked. The counter must be cleared by the SSM user. The action to be taken and maximum number of failed attempts is stored in the SSM. The maximum number of failed attempts can be changed by the SSM user;

- Additional information.- Passwords related to a ISPBX data port, used for port protection.

The following items can be defined per data port:- DNR of data port;- Password (6 to 12 digits); this password can only be changed by the SSM user;

207

- Indicator to allow the ISPBX services 'access port direct' or 'access port call back';- Call back address in the case of ISPBX service 'access port call back';- Two time-access-windows to allow the use of a data port just a part of the day. The

time-access windows can be defined;- Maximum number of failed attempts. If the failed attempts counter has reached the

maximum number of failed attempts, the defined action is invoked. The counter must be cleared by the SSM user. The action to be taken and maximum number of failed attempts is stored in the SSM. The maximum number of failed attempts can be changed by the SSM user;

- Additional information.

Services that indicate a request by ISPBX towards SSM:

• Change Password RequestWhen a ISPBX extension user dials the change password prefix with res. id. 104 (change password), the ISPBX returns the 'nter password' tone - Tone Number 26. The user must now enter the old password followed by the new password (twice).The user DNR and the passwords are transferred to the SSM.If the validation is correct, the new password is stored in the SSM.When assigning the prefix in the ISPBX, the parameter 'number length' indicates the length of the password to be entered (6 - 12 digits).This service can only be initiated from the user's own DNR.

• Enable / Disable Upgrading and Downgrading RequestA ISPBX extension has a day, night, upgraded and downgraded traffic class. In the normal situation the day-night traffic classes are used, depending for instance, on the presence of operators in the ISPBX system. An extension can define if the upgraded-downgraded traffic classes must be used instead.After dialling the prefix with res. id. 105 (enable up/downgrading) followed by a password, the SSM validates the allowance of the ISPBX extension to initiate this request. If the validation is successful, the ISPBX system uses the upgraded or downgraded traffic class for the extension. The ISPBX has remembered which traffic class was last used (upgraded or downgraded) and switches back to the same traffic class. The extension can also select the traffic class to be used, the upgraded or the downgraded traffic class (see below). The first time the extension uses this facility, the user must use the upgrade/downgrade facility before the DNR is assigned another traffic class.After dialling the prefix with res. id. 106 (disable up/downgrading) followed by a password, the ISPBX uses the day-night traffic classes again (after validation).The four traffic classes can be entered in the ISPBX system by the system manager with the OM command CHTRFC.When assigning the prefixes in the ISPBX, the parameter 'number length' indicates the length of the password to be entered (6 - 12 digits).

208

This service can only be initiated from the user's own DNR.• Upgrading and Downgrading Request

After enabling the upgraded-downgraded traffic classes (see above) the extension is assigned either the upgraded traffic class or the downgraded traffic class as was last used for that extension. The user can define which of the traffic classes must be used, upgraded or downgraded by using the upgrading or downgrading request. The first time the user accesses the enable upgrading facility the upgrading or downgrading request must be used before a new traffic class is assigned to the DNR.When a user dials the prefix with res. id. 107 (upgrade traffic class), the ISPBX sends the 'enter password' tone. The user must now enter the password. The ISPBX initiates the service together with the DNR and the password.If the validation is successful and the user is allowed to initiate this facility, the SSM tells the ISPBX to use the upgraded traffic class for that extension.When a user dials the prefix with res. id. 108 (downgrade traffic class), the ISPBX sends the 'enter password' tone. The user must now enter the password. The ISPBX initiates the service together with the DNR and the password. If the validation is successful and the user is allowed to initiate this facility, the SSM tells the ISPBX to use the downgraded traffic class for that extension.When assigning the prefixes in the ISPBX, the parameter 'number length' indicates the length of the password to be entered (6 - 12 digits).This service can only be initiated from the user's own DNR.

• Password DDO from Own Extension RequestWithout upgrading the traffic class, the ISPBX extension user can use his upgraded traffic class for a DDO call from his own extension. The upgraded traffic class is valid only for the duration of the call.After dialling the prefix with res. id. 109 (password DDO from own), the ISPBX sends the 'enter password' tone. The user must now enter the password. The ISPBX initiates the service together with the DNR and the password.If the validation is successful and the user is allowed to initiate this kind of DDO call, the SSM sends a message to the ISPBX. Now the initiating party receives dial tone and any number (internal or external) can be dialled with the upgraded traffic class.When assigning the prefix in the ISPBX, the parameter 'number length' indicates the length of the password to be entered (6 - 12 digits).This kind of outgoing call is always registered in a toll ticketing record, provided that toll ticketing is active.

Note: Although the term 'Password DDO' suggests that only external calls can be made, it is also possible to make internal calls using a password.

• Password DDO from Other Extension RequestIf the user's own extension is assigned a password in the SSM, the ISPBX user can access the upgraded traffic class for a DDO call from any other extension in the FIN.

209

The upgraded traffic class is valid only for the duration of the call.After dialling the prefix with res. id. 110 (password DDO from other), the ISPBX sends the 'enter password' tone (tone number 26). The user must now enter the password. After this password, the ISPBX sends internal dial tone. Now the user must dial his own DNR.The ISPBX initiates the service and the DNR and the password are transferred to the SSM. The SSM validates the relation between password and own DNR.If no relation is found the user will hear NU-tone.If this relation is found and the user is allowed to initiate this service, the system sends a message to the ISPBX. Now the initiating party receives dial tone and any number can be dialled with the upgraded traffic class of his own extension.When assigning the prefix in the ISPBX, the parameter 'number length' indicates the length of the password to be entered (6 - 12 digits).This kind of outgoing call is always registered in a toll ticketing record, provided that toll ticketing is active; the call will be charged and metered to the user's own DNR.

• Access Port DirectTo prevent the unauthorised access of a data port by internal or in-calling parties, the data port (DNR) is assigned FCM 38 (direct access protected). A data party can be connected to the defined data port by dialling the prefix with res. id. 113 (access port direct).After dialling this prefix 'enter password' tone is offered and the user must enter the password related to the data port. After this password, the ISPBX sends internal dial tone. The user must enter the DNR of the dataport.The ISPBX initiates the service request to the SSM and sends the DNR and password. In the SSM, the password entered is validated to correspond with the required destination data port (internal) and if the validation is correct, a message is sent to the ISPBX. The connection between the two (data)parties is now allowed and established in the ISPBX. If the validation is not correct, a message is sent to the ISPBX, which results in NU-tone to the originating party.When assigning the prefix in the ISPBX, the parameter 'number length' indicates the length of the password to be entered (6 - 12 digits).

Note: Access port direct operates on normal extension DNRs and group DNRs.• Access Port Call Back Request

To prevent the unauthorised access of a data port by internal or in-calling parties, the data port is assigned FCM 38 (direct access protected). A data party can be connected to the defined data port by dialling the prefix with res. id. 114 (access port call back).After dialling this prefix 'enter password' tone is offered and the user must enter the password related to the data port. After this password, the ISPBX sends internal dial tone. The user must enter the DNR of the dataport.The ISPBX initiates the service request to the SSM and sends the DNR and password. In the SSM the entered password is validated to the destination dataport (internal) and if the

210

validation is correct, a message is sent back to the ISPBX.The initiating party receives confirmation tone and goes on-hook.Within one minute the SSM initiates a call (via window H'8') by first dialling the destination data port. After answering, the connection to the specified call back number is established. If this call is not successful, the call back is re-initiated a projectable number of times with projectable time-intervals.When assigning the prefix in the ISPBX, the parameter 'number length' indicates the length of the password to be entered (6 - 12 digits).In the case of an initiated 'call back' call, this call can be cancelled by dialling the prefix with res. id. 115 (cancel call back) followed by the password of the destination data port and the DNR.

Note: Access port call back operates on normal extension DNRs and group DNRs.• Cost Centre Call or Personal Identification Code Call Request

When a ISPBX extension dials the prefix with res. id. 112 (cost centre validate) the ISPBX does not send 'enter password' tone.The user must enter the cost centre number. The DNR of the calling party and the cost centre number are transferred to the SSM. Here the DNR-cost centre number relation is validated.First a check is performed if the entered number is a personal identification (PID) code. If it is, a message is returned to the ISPBX containing a new traffic class. The extension can now initiate an external call (not internal calls) with this new traffic class.This traffic class can be defined in the PID menu in the SSM. It is possible to perform a budget check on the PID code. After completion of the PID call, the traffic class is set back to the one it had before the call was made.If the entered number is not a PID, the entered number is checked to see if it is cost centre number. If it is and the calling party is in credit, the SSM sends a message to the ISPBX and the user can initiate an external call (not internal calls) on the account of the cost centre number.When assigning the prefix in the ISPBX, the parameter 'number-length' indicates the length of the cost centre numbers/personal identification codes to be entered (6 - 12 digits).The cost centre call and the PID call are always registered in a toll ticketing record, provided toll ticketing is active.

Note: The check between the DNR and the cost centre number can be disabled in the PID-menu in the SSM. If this check is disabled, only the DNR-PID check is performed.

• Malicious Call TraceWith the 'malicious call trace' facility it is possible to ascertain the (internal or external) origin of malicious, nuisance or obscene calls. For that purpose a user of the ISPBX may be given the possibility to request the identification of the call originator. The user that wants to execute the request for identification of an calling party enters the enquiry state

211

and dials the prefix with res. id. 60 (malicious call trace). After a successful request all data concerning the request of the malicious call trace is stored in the toll ticketing record under cost centre number '999999'. This implies that toll ticketing must be active.

10.2.8. Directory Distributor

The Directory Distributor module is only used when SUPERVISOR 50/50E or SuperVisor model 55 operator positions are being used. This module is used to distribute databases, changes in the databases and messages in a ISPBX configuration to SuperVisors. In this way changes in directories, organisation/extension data and messages are known to every operator as soon as possible.

In such a distributed database system there is one Master and a number of Slaves. The Master may be a SSM or SuperVisor. A Slave can be a SUPERVISOR 50 (referred to as Old Slave) or SUPERVISOR 50E or Supervisor model 55 (referred to as New Slave). In this section the SSM is Master and the SuperVisors are Slaves.

• Database DistributionThe Master distributes changes made in the directories, message database, the organisation database and extension database. Both automatically and manually entered messages will be distributed (to new slaves only). Changes made on the Slaves in the directories, message database and extension database are transferred to the Master which distributes these changes to all other Slaves.

Note: When the Call Manager or External Application Interface has been installed, automatically entered messages from an extension are possible.

• Distribution InitiativeThe initiative for directory distribution will be at the Master (to New Slaves) or at the Slaves as follows:- The Master will distribute changes to its database to all 'New Slaves' as soon as these

changes occur. Distribution will take place after a projectable time interval to avoid that the Master calls each 'New Slave' for every (small) change.

- The 'New Slave' will call the Master as soon as changes occur. Transfer will take place after a projectable time interval to avoid that the 'New Slave' calls the Master for every (small) change.

- The 'Old Slaves' will call the Master at regular intervals (e.g. during the night) to get the latest database changes. The Master will not call the 'Old Slaves'.

• ConnectionsSlaves can be connected to the Master in the following ways:- via switched connections:

Slaves which are connected to the Master via switched connections are organised into groups. A group consists of one or more Slaves. Each group of Slaves is served by two

212

LAM ports. One port is used by all Slaves in the group to dial-in to the Master and the other port is used by the Master to dial-out to each Slave in the group. The extension number of the LAM port used by a Slave to dial-in to the Master determines the group to which the Slave belongs.

- via a direct connection:Each Slave is directly connected to the Master. This configuration is considered as a single-member group and requires one port.

- via a "hot-line" connection:Each Slave is connected to a LAM port, which has a hot line connection to another LAM port to which the Master is connected. This configuration is considered as a single-member group and requires one port.

10.2.9. Performance Manager

The ISPBX traffic measurement facility allows the traffic figures of the resources in the ISPBX to be available (every 15 minutes). The traffic measurement facility can be initiated by the OM command STRTTM in the ISPBX or by the Performance Manager via the OM connection. For more information about this ISPBX facility: see chapter 5. "PERFORMANCE MANAGEMENT".

In the SSM, the module which takes care of processing the traffic measurement figures is called Performance Manager. When this option is chosen from the main menu, the definition screen for the Performance Manager is displayed. In this definition screen the SSM user has to specify which type of ISPBX the traffic figures are related to. Also the unit number has to be specified.

10.2.10. Peripheral Facility Manager

The Peripheral Facility Manager module can be used to program the function keys of the various types of SOPHO-SETs. Each extension is identified in the Peripheral Facility Manager by its DNR.

In the SSM, two lists of function key data can be prepared:

- Group list: contains function key data for a group of extensions;- Individual list: contains additional function key data for an individual extension.

The function key data can be downloaded into an extension. This downloading can be initiated by the extension user or by the SSM and can involve one list only (group or individual) or both lists. To program a number of extensions with the same function key data, the extensions are assigned to the same group list number.

To make individual changes possible, the individual data can be defined for only one DNR.

213

First the group data is downloaded, followed by the individual data. In this way the individual data overwrites the group data.

Besides the function key data the SSM time and date can be downloaded to the extension (e.g. when changing to daylight saving time).

Note: If the time and date are to be downloaded, it indicates the SSM time and date NOT the PABX time and date.

• Downloading by the SSMThe SSM user can initiate a command to send function key data, the current date and time or both to one or more specified extension(s).The execution of the downloading can be specified to take place:- As soon as possible;- At a specified time.The function key data and/or time and date are transferred from the SSM to the extension(s) using end-to-end user messages. The information is transferred to the ISPBX CPU in service window H'7' in the TMS-server link. This processor transfers the information to the extension using the Terminal Message Protocol. For instance, in the case of SOPHO-SET S extensions this will be accomplished using the D-channel messages in the 2B + D basic access protocol. During this downloading, the SSM will control the session.

• Downloading by the ExtensionThe extension user dials a code which is sent by the ISPBX to the SSM. By entering additional information, the SSM is requested to download the function key data for that extension, the current date and time or both. The code holds a TMS-prefix plus two additional digits.ExampleThe prefix *315 is assigned (OM command ASINTN) in the initial dialling tree with res. id. 82 (TMS dialled) and number length 2 (the parameter-field 'destination' is left empty when executing this command). This means that after the prefix (*315) two digits must be used for the type of download request.The last digit of the prefix indicates the service request from the ISPBX to the SSM. The position of the service digit is entered in the ISPBX by means of the OM command ASTMSD. In the example above, the fourth digit indicates the service and with the command ASTMSD, the value 4 is entered.The last digit of the prefix corresponds to the last digit of the hexadecimal notation of the service window. The window for the PFM is H'85' so the digit 5 at the end of the prefix indicates to the ISPBX that a download request has been initiated by the user.The ISPBX now automatically uses window H'85' to transfer the request to the SSM.After the prefix, two extra digits must be dialled for the type of downloading. When

214

executing the ASINTN command the number length parameter must be assigned the value 2. The actual downloading is performed again in service window H'7' as described earlier.The first additional digit indicates what type of information is to be downloaded.If this digit has the value 0, it means that only the time and date are to be downloaded.If this digit has the value 1, it means that the group list, the individual list and the SSM date and time are to be downloaded.The second additional digit indicates when the information is to be downloaded.If this digit has the value 0, it means that the data must be downloaded immediately. If the SSM is not able to handle the request immediately, the initiator will hear a rejection tone. The request will not be put in a queue! If this digit has the value 1, it means that the data must be downloaded as soon as possible. The request is put in a queue and as soon as the job can be handled, the data is downloaded.If this digit has the value 2, it means that the data must be downloaded during non-office hours. The job will be executed at a pre-defined time. This time can be programmed by the SSM-user.

Note: A download session is guarded by NETIMER 092 (TMS download guarding time). If this timer expires, the ISPBX assumes that the download session has finished.The maximum number of download sessions that can be active at the same time is limited by NEBOUND 221 (max number of TFM sessions).

• Downloading by the ISPBXIf the DLC-circuit has been out of service or the extension has been without power for a period of time, the extension might have lost its data and must be downloaded again. The function code data in the ISPBX is automatically used for downloading.This function code data is stored in the ISPBX in a menu that is related to the DNR. If the function key data is stored in the SSM however, the downloading must be initiated by the extension or from the SSM-terminal.When a rollback on a DLC-port is performed (DLC-circuit is forced to a defined idle condition when it is owned by another process - usually performed by System Assurance) the ISPBX forces an SSM download towards the DLC-port. Using window H'86', the ISPBX sends a message to the SSM indicating the extension DNR. The SSM now downloads the function key data to the extension using window H'7' (if the extension is defined in the SSM).

Note: The windows H'7' and '86' must both be active and have the same window size for the correct implementation of this facility.

10.2.11. File Manager

The File Manager provides the same functionality as Disk Emulator. It can be used to manage

215

files on the CPU.

The SSM is connected via a separate V.24 link to the ISPBX as follows:

- The SSM is connected to a CPU port.- This port is configured as a disk emulator (equipment type 26).

The SSM can be used to store and retrieve ISPBX files. The information transfer is performed by the ISPBX CPU. A ISPBX OM terminal (or an OM terminal of the SSM Facility Manager module) can be used to request a file transfer (using the CPYFIL command) between the CPU and an external device (the File Manager in SSM).

10.2.12. Fault Manager

The Fault Manager option (when installed) is available in the PABX Management Menu.

This module is used for collecting and storing fault reports, announcing faults and presenting overviews. The Fault Manager can support one or more local or remote ISPBXs. The Fault Manager performs fault report collection, fault announcement and fault inspection.

• Fault Report CollectionThis function collects fault data from various sources and stores the data in a fault database. The sources can be a ISPBX, a terminal user or another application (internal or external). The fault data can be the appearance or disappearance of a fault. The ISPBX database contains information about ISPBXs for which fault management is required.For each ISPBX in the database it is indicated whether the collection of fault data is autonomous (Alarming=Yes) or uses polling (OM=All or Fault Manager).Autonomous means that the connection set up is initiated by the ISPBX and a fault indication message is transmitted to the Fault Manager.Polling means that the connection set up is initiated by the Fault Manager and the fault information is retrieved by OM command procedures.Polling is done for ISPBXs which are not able to indicate faults autonomously or find out whether alarm indications have been missed, for example, due to congestion.The polling interval is defined in the project data.

• Fault AnnouncementThis function activates a fault announcement to specified destinations under certain conditions. The condition under which a fault announcement will occur is defined in the project data and may be one or more of the following events:- New major alarm;- New minor alarm;- New silent alarm;- Major alarm cleared;

216

- Minor alarm cleared;- Silent alarm cleared.The destination of the announcement is defined in the project data and can be a system printer and/or external application (not yet available).

• Fault InspectionThis function offers the possibility to retrieve information from the collected fault data.Inspection is possible from the user terminal (using menus) or with an external application.

For more information on the Fault Manager: see chapter 9. "REMOTE MAINTENANCE".

10.2.13. External Application Interface

The External Application Interface allows the connection of another computer (host) to the SSM via a V.24 port. The communication protocol between the SSM and the host computer is determined in the SSM configuration data. It must be according to the port settings of the V.24 port of the host computer.

For telephone bills, the output (when checking out a hotel guest) can be directed to the host computer or to a printer. The format of the hotel bills that are transferred from the SSM to the host is defined in a file.

10.3. MULTI SITE SystemManager

When an SSM is ordered without any extra ISPBX licences, it can only be connected to one ISPBX. This is called a single site system. This is possible on PC and UNIX versions. By ordering and installing extra ISPBX licences, the SSM can be connected to more than one ISPBX;Figure 10-2 "Example of a Multi Site SystemManager Configuration".

This is called a Multi Site SSM; it is only possible on UNIX versions.

217

Figure 10-2 Example of a Multi Site SystemManager Configuration

A multi site system can perform the following functions:

- All services (depending on the modules installed) on the local ISPBX;- Fault Management (when installed) on local and remote ISPBX;- Operational Maintenance on the local and remote ISPBX (when the Facility Manager

module is installed);- Terminal emulation and file transfer with a remote SSM;- Accounting on local and remote ISPBX via a remote SSM.

A connection between the Multi Site SSM and the ISPBX's can be made:

- directly to the local ISPBX (only for short distances);- using modems, via the PSTN or (analogue) private network, to one or more remote

ISPBX's;

The 'Remote SSM Management' option in the SSM management menu is used to manage a remote SSM located at a remote ISPBX. This management consists of an access function (terminal emulation, remote SSM must be a UNIX system) and a file transfer function (remote SSM can be a PC or UNIX system).

MULTI SITE SOPHO SystemManager

MODEM MODEM

1

2

1

43

MODEMLOCALISPBX 1

MODEM MODEMMODEM

REMOTEISPBX 2

REMOTESystem

REMOTEISPBX 3

Connection type : 1 = Direct connection, all services2 = OM & Fault Management possible3 = OM, Fault Management possible4 = Terminal emulsion, file transfer on remote system & Cost transfer.

218

Data of the remote SSM is stored in the ISPBX interface database. Maintenance can be done using ISPBX management (ISPBX database maintenance).

The remote SSM can be accessed via:

- A switched line to the public or private telephone network with call-back security using a call-back modem at the remote SSM side;

- A switched line to the public or private telephone network with a normal modem (no call-back; no security).

Release 2.4.1. of the SSM supports a "basic multi-site for PC". This makes it possible to set up remote OM sessions via a LAM connection without authorization for direct V.24 terminal connections as well as by the BCS protocol.

The following ISPBX interface boards are supported for remote OM sessions:

- OM via a CPU interface using device "Terminal 1" (V.24).- OM via a CPU interface using device "LMS 2" (BCS).

For more information refer to the SSM Customer Engineer Manual (C-DOS).

For more information on Multi-Site SSM: see 9. "REMOTE MAINTENANCE".

10.4. RELATING A ISPBX SERVICE TO AN SSM

The services that are requested by a ISPBX from the SSM are transferred via the windows H'81'...'87'. An ISPBX system (iS3000 iSNet) can contain more than one SSM server (device type 6). One SSM server device can be projected per ISPBX unit. Therefore every ISPBX unit must be instructed that a service in window H'8x' must be transferred to that particular SSM server. This can be achieved by means of the ISPBX OM command CHTMSL.

Example

CHTMSL: 84, TMS02, 5;

CHTMSL: 82, TMS01, 5;

During a security patrol round, a guard dials the SSM from an extension in ISPBX unit 5. For unit 5, the SPM service (window H'84') must be transferred to the SSM server 2 (TMS02). Unit 5 knows where the SSM is connected from the device - hardware relation and the SPM message is transferred to the correct system via the inter-unit links.

For the room status service (window H'82') however, the message is transferred to the SSM

219

server 1 device (TMS01).

For the services that are not related to service windows (toll ticketing, performance management) the relation between a ISPBX unit and the SSM where the figures must be sent, is made with the OM commands CHTTOD, CHTMOD.

10.5. EXTERNAL MESSAGE WAITING DEVICE

It is also possible to connect an external message waiting device to a port of the SSM. In the SSM, it must be specified that the external message waiting device must be used. When the Message Waiting With Announcement (window H'6') and Message Waiting No Announcement (window H'3') are both disabled in the matrix, the message waiting indication is sent to the port. If the external message waiting device is active, it receives the message from the SSM and the corresponding lamp is activated.

The communication protocol between the port of the SSM and the external message waiting device is specified in the configuration data of the SSM. This must correspond to the specifications of the V.24 port of the external message waiting device.

The rhythm of the lamp signal used when the external message waiting device activates the message waiting situation for a ISPBX extension must be defined in a file. By default this file is empty and the rhythm must be set as required.

10.6. CHECKLIST iS3000 - SSM CONNECTION

• Hardware Settings- Physical connection: V.24 port on the BIM or VIC3000.

• OM Commands for Hardware Configuration- ASDEVC: Assign device.

The logical device name can be choosen freely: max. 6 characters24 = the equipment type for toll-ticketing, e.g.ASDEVC:11,18,21,TOL1,24;29 = the equipment type for services, e.g.ASDEVC:11,18,21,SSM1,29;

- SETINS: Set the device in serviceSETINS:11,18,21;Read out with:

- DIPORT: Display device characteristics.• OM Commands for Toll-Ticketing

- CHTRLV: Change Thresholds of Route Number.A call record (or TT file/report) will only be sent if the number of metering pulses or call duration exceeds the threshold, e.g.

220

CHTRLV:10,0,1;- DITRLV: Display Thresholds of Route.- CHTTOD: Change Toll-Ticketing-output Device.

Indicates to which device TT file should be sent, e.g.CHTTOD:TOL1;device-name: see OM command DICHARRead out with:

- DITTOD: Display Toll-Ticketing-output Device.- STRTTT: Start Toll-Ticketing, e.g.

STRTTT: FILETT;The file-name is not important for SSM

- STOPTT: Stop Toll-Ticketing.- DISPTT: Display Toll-Ticketing Status and Characteristics.

• OM Commands for Internal Number Scheme- ASINTN: Assign internal number scheme number.

Figure 10-3

Result-id is 82 TMS dialled for services:8282

82 room status (130)82 AEM (131)82 SPM (132)II80 (hex) + Service / WindowNumber at TMS side 128(dec)+service number

e.g.ASINTN:0,*392,0,82,,2; Room statusASINTN:0,*393,0,82,,2; AEM no.ASINTN:0,*323,0,82,,6; AEM no.TIMEASINTN:0,*333,0,82,,6; AEM no. DATEASINTN:0,*343,0,82,,6; AEM number xxxxASINTN:0,*353,0,82,,4; AEM Wake-upASINTN:0,*394,0,82,,5; SPMASINTN:0,*395,0,82,,2; PFM

I II Number of post dialling digitsI (maximum is 20, including prefix)ITMS-digit is equal to service number

..

221

The following result-id's (104 ... 115) are only used for the Access Manager, e.g.ASINTN:0,*47,0,104,,6; change passwordASINTN:0,*41,0,105,,6; enable up/downgradingASINTN:0,*42,0,106,,6; disable up/downgradingASINTN:0,*43,0,107,,6; upgrade traffic classASINTN:0,*44,0,108,,6; downgrade traffic classASINTN:0,*45,0,109,,6; password DDO from ownASINTN:0,*46,0,110,,6; password DDO from otherASINTN:0,*48,0,112,,6; cost centre validateASINTN:0,*51,0,113,,6; access port directASINTN:0,*52,0,114,,6; access port call backASINTN:0,*53,0,115,,6; cancel call back6= password length (or PID in the case of cost centre validation)

The number analysis scheme data can be read out with:- DINASD : Display Number Analysis Scheme Data.

In case you want to re-enter a prefix, first delete the old one by:- MAKENU : Make Number Unobtainable.- ASTMSD : Assign TMS digit position; see ASINTN number for result-id 82 e.g.

ASTMSD:4;Read out with:

- DITMSD : Display TMS digit position.- ASTMSW : Assign TMS window size; should be equal to window size defined in the

SSM. Sum of window sizes should not exceed system boundary 76.From SSM to ISPBX e.g.

From ISPBX to SSM e.g.

ASTMSW:2,2,1; Wake-up (2)ASTMSW:3,1,1; MWNA (3)ASTMSW:4,1,1; ADD (4)ASTMSW:5,3,1; Change PBX data (5)ASTMSW:6,1,1; MWWA/SPMALARM (6)ASTMSW:7,2,1; Peripheral Fac (7)ASTMSW:8,2,1; Port protection call back (8)

ASTMSW:81,2,1; ANND (129)ASTMSW:82,1,1; Room status (130)ASTMSW:83,1,1; AEM (131)ASTMSW:84,1,1; SPM (132)ASTMSW:85,2,1; Peripheral Fac (133)

222

• OM Commands for Traffic Class Restriction Level

• OM Commands for Facility Class Mark Restriction Level

• OM Commands for Tones

ASTMSW:86,2,1; Peripheral Fac (134)ASTMSW:87,2,1; Access manager (135)

Read out with:- DITMSW : Display TMS window size.- CHTMSL : Change TMS Logical Device Name (LDN); LDN should be equal to

LDN in ASDEVC. Different services can be sent to different devices/TMS us ing different Clx with their own LDN; only for windows 81 & 87, e.g.CHTMSL:81,TMSS1,1;CHTMSL:82,TMSS1,1;CHTMSL:83,TMSS1,1;CHTMSL:84,TMSS1,1;CHTMSL:85,TMSS1,1;CHTMSL:86,TMSS1,1;CHTMSL:87,TMSS1,1;

Read out with:- DITMSL : Display TMS Logical Device Name

- CHTFCR : Change Traffic Class Restriction Level.Important for change PBX data (bar/unbar) window 5 hotel managerterminal-type 3 is TMS e.g.CHTFCR:3,,0; (no restrictions for TMS)Read out with :

- DITFCR : Display Traffic Class Restriction Level.

- CHFCMR : Change Facility Class Mark Restriction.Important for change PBX data (DND, FCM 24) window 5 hotel managerterminal-type 3 is TMS e.g.CHFCMR:3,24,0; (no restrictions for TMS)Read out with :

- DIFCMR : Display Facility Class Mark Restriction.

223

• OM Commands for Facility Class Mark

• OM Commands for Remote Maintenance

10.7. CHECKLIST PER SystemManager MODULE

• Account ManagerLogical device name - ASDEVC with equipment type 24ISPBX sends toll ticketing record to logical device after the execution of OM commands CHTTOD and STRTTT.

• Automatic Directory DiallingService window: H'4'

• Automatically Entered MessagesService window: H'83'; window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)

- CHTMST : Change TMS Announcement Code Relation. The Announcement Source can be:- synchronous, specified via the DNR (=1),- a tone, specified by tone function number (=2),- a continuous announcer, specified by an EHWA (=3).The command will ask for additional parameters.E.g. CHTMST:70,2,1;The system requests <TONE-FUNCTION>. Enter e.g. '7' (7=NU-tone).Read out with:

- DITMST : Display TMS Tone Type Relation.

- ASFACM : Assign Facility Class Marks (FCM).When ANND is used, FCM 28 (external service display) must be set for SSM user.Read out with:

- DIFACM : Display Facility Class Marks.

- REROUT : Reroute Alarm Signalling.Standard according to PE:REROUT:2;System option LOSYSOP 049 (signalling at distance) must be true.

- CALSIG : Confim Signalling At Distance (SAD).Used to confirm alarms on a Remote Maintenance Centre.System option LOSYSOP 050 (signalling at distance manual confirmation) must be true for confirmation.

224

OM command ASINTN:prefix with last digit '3' -- example *313result id 82; number length 2 (message numbers 00 to 99 are allowed)Service digit -- example 4 (ASTMSD)

• Message Waiting No AnnouncementService window: H'3'; window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)Only activates the message waiting facility of the ISPBX for the related extension.

• Message Waiting With AnnouncementService window: H'6'; window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)SSM sends:- a destination DNR: ISPBX establishes connection between the two DNRs.- a tone type: relate tone type to destination DNR or tone source (CHTMST).

• Attendant Name and Number DisplayService window: H'8'; window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)Assign FACM 28 (external service display) to TMS operator DNR

• Patrol Manager DiallingService window: H'84'; window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)OM command ASINTN:prefix with last digit '4' -- example *314result id 82; number length 2 (reporting code 2 digits)Service digit -- example 4 (ASTMSD)

• Patrol Manager AlarmingService window: H'6'; window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)SSM sends tone type:Relate tone type to destination DNR or tone source (CHTMST)

• Room Status DiallingService window: H'82'; window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)OM command ASINTN:prefix with last digit '2' -- example *312result id 82; number length 2 (reporting code 2 digits)Service digit -- example 4 (ASTMSD)

• Change PBX dataService window: H'5'; window size must be assigned value 3 (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)

• Wake up request

225

Service window: H'2'; window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)SSM sends:- a destination DNR: ISPBX establishes connection between the two DNRs.- a tone type: relate tone type to destination DNR or tone source (CHTMST)

• Password DiallingService window: H'87'; window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)OM command ASINTN; prefix with result id:104: change password;105: enable up/downgrading;106: disable up/downgrading;107: upgrading;108: downgrading;109: outgoing call from own extension;110: outgoing call from other extension;112: cost centre or PID call;113: access port direct (call to extension with FCM 38 - direct access protected);114: access port call back (call to extension with FCM 38 - direct access protected);115: cancel call back.Service window: H'8' for protected port call back.

• Peripheral Facility Manager DownloadService window: H'85' for user download request.Window size (ASTMSW)Relate window to LDN TMS server - equipment type 29 (CHTMSL)OM command ASINTN:Prefix with last digit '5' -- example *315result id 82; number length 2:1 digit for type of information to be downloaded and1 digit for time when downloading must be performed.Service digit -- example 4 (ASTMSD)Service window H'7' and H'86' for download.Window size (ASTMSW)Relate window to LDN TMS server - device type 6 (CHTMSL)

• Facility ManagerThis service is not transferred via the server link. A special link is necessary, to a port in the ISPBX, configured for OM terminal. Configure CPU port for OM terminal with OM command ASDEVC with LDN VDUxx. The SSM is connected to the OM port of ISPBX via a second port. For the OM port, the same rules apply as for a normal OM terminal e.g. restriction levels and authority classes.

• File Manager

226

DISK EMULATOR - all systems except iS3070/3090 on CCS platformA special port of the SSM can be connected to a CPU port in the ISPBX configured for a PC with Disk emulator:OM command ASDEVC with LDN PCxx and equipment type 26.

Note: In the ISPBX, the OM port protection mechanism (authority classes, protection levels, restriction levels) must be set to values, that all necessary OM commands can be executed.

• Fault ManagerSee Facility Manager.

227

11. SOFTWARE LICENSES

The maximum system capacity and allowed functionality of the system are granted by software licenses. The software licenses are enabled using license files.

The following items can be licensed:

228

ITEM NUMBER

DESCRIPTION

1 Basic Service Profile IDentity (BSP-ID)

2 Internal Message Protocol (IMP)

3 Automatic Call Distribution (ACD) agents

5 Digital Private Network Signaling System (DPNSS)

6 Cost Accounting

7 System Management

8 Full Detailed Call Recording output (FDCR)

9 Least Cost Call Routing (LCCR)

10 Voice Mail Interface

11 iSNet Private Virtual Networking (PVN)

12 Integrated Password Dialling

13 Music On Hold from Integrated Announcement Server (IAS)

14 Dynamic Delay Messages

15 Operator Monitoring

17 iSLinks for CSTA on S0-bus

18 Active CSTA monitors

19 Desksharing

20 Calling Name and Number Display (CNND)

21 iSLinks for CSTA on Ethernet

22 Installation DNR-EHWA relation

23 CSTA I/O Services

24 CSTA I/O Registration (granularity of 1)

25 Free Numbering

26 Central Directory Dialling (CDD)

27 Completion of Call to Busy Subscriber (CCBS)

28 External Central Directory Dialling (ECDD)

29 iSNet iPVN

30 Project Application 1

229

31 Multi-Line for ErgoLine D340

32 Multi-Line for ErgoLine D340 and D330

33 Multi-Line for ErgoLine D340, D330 and D325

34 CSTA PBC application

35 CSTA EP application

36 CSTA EXTERN application

37 CSTA EXTERN application seat

38 CSTA CC210 application

39 CSTA CC210 application seat

40 CSTA PBC application seat

41 CSTA DMS application

42 CSTA DMS application seat

43 CSTA Dialer application 1)

44 CSTA Dialer application seat 1)

45 CSTA 3rd party TAPI application

46 CSTA 3rd party TAPI application seat

47 CSTA EP application seat

48 Voice Logging

49 CSTA voice log application

50 CSTA voice log application seat

51 CSTA CTI server application

52 CSTA CTI server application seat

56 iS3000 BCT synch lic 3)

57 QSIG Supplementary Service

58 iSNet on top of QSIG

59 ISG channels

60 CSTA Messenger application

61 CSTA Messenger application seat

62 CSTA CC200 application 1)

ITEM NUMBER

DESCRIPTION

230

Table 11-1 Licensed Items

The system capacity and functionality can be displayed by executing OM command DILICS; an example is given below.

Note: For the numbered licenses (BSP-IDs, ACD, iSLinks and active CSTA monitors) the information displayed is in fact the system boundary projected, possibly rounded to the next number in the license range.

63 CSTA CC200 application seat 1)

64 CSTA Desktop application 2)

65 CSTA Desktop application seat 2)

66 Software SMA user

67 CCIS

68 IP Dect

69 SIP Phone

70 Exchange UM Interface1) This license is removed since Call@Net 2.10.2) Up to Call@Net 2.9 the name of this license was : CSTA MRS application (seat).3) Up to SIP@Net 4.1 the name of this license was : Call@Net Application Service.

<DILICS:;Active licensesUNIT NR DESCRIPTION GRANTED TOTAL USED EXPIRY DATE02 001 : BSP-IDs Yes 510 182 2001-03-12LICENSES : PERMANENT TEMPORARY

500 10UNIT NR DESCRIPTION GRANTED TOTAL USED EXPIRY DATE02 002 : IMP Yes - - -02 003 : ACD agents Yes 23 4 2000-04-09LICENSES : PERMANENT TEMPORARY

20 3UNIT NR DESCRIPTION GRANTED TOTAL USED EXPIRY DATE02 005 : DPNSS Yes - - -02 006 : Cost accounting Yes - - -

ITEM NUMBER

DESCRIPTION

231

02 007 : System management Yes - - -02 008 : FDCR Yes - - -02 009 : LCCR Yes - - -02 010 : Voice Mail Interf. Yes - - -02 011 : iSNet PVN Yes - - -02 012 : IPD Yes 201 0 2000-04-09LICENSES : PERMANENT TEMPORARY

200 1UNIT NR DESCRIPTION GRANTED TOTAL USED EXPIRY DATE02 013 : MOH from IAS - - - -02 014 : Dynamic delay msg. Yes - - -02 015 : Oper. monitoring Yes - - -02 017 : S0-bus Link CSTA Yes 20 0 2000-04-09LICENSES : PERMANENT TEMPORARY

18 2UNIT NR DESCRIPTION GRANTED TOTAL USED EXPIRY DATE02 018 : Act. CSTA monitors Yes 210 0 2000-04-09LICENSES : PERMANENT TEMPORARY

200 10UNIT NR DESCRIPTION GRANTED TOTAL USED EXPIRY DATE02 019 : Deskshar. BSP-ID Yes 220 0 2000-04-09LICENSES : PERMANENT TEMPORARY

200 20UNIT NR DESCRIPTION GRANTED TOTAL USED EXPIRY DATE02 020 : CNND Yes - - -02 021 : Ethernet link CSTA Yes 17 0 2000-04-09LICENSES : PERMANENT TEMPORARY

15 2UNIT NR DESCRIPTION GRANTED TOTAL USED EXPIRY DATE02 022 : Install DNR-EHWA Yes - - 1999-05-1202 023 : CSTA IO services Yes - - -02 024 : CSTA IO registrat. Yes 210 0 2000-04-09LICENSES : PERMANENT TEMPORARY

200 10UNIT NR DESCRIPTION GRANTED TOTAL USED EXPIRY DATE02 025 : Free Numbering Yes - - -02 026 : CDD Yes - - -02 027 : CCBS Yes - - -02 028 : ECDD No - - -02 029 : iPVN Yes - - -

232

02 030 : Project Appl. 1 No - - -02 031 : MultiLine D340 Yes - - -

NOT LICENSED DNR-BSPT1500-95

02 032 : MultiLine D340/330 Yes - - -02 033 : MultL D340/330/325 Yes - - -02 034 : CSTA PBC appl. Yes - - -02 035 : CSTA EP appl. Yes - - -02 036 : CSTA EXTERN appl Yes - - -02 037 : CSTA EXTERN seat Yes - - -02 038 : CSTA CC210 appl. Yes 2 1 -02 039 : CSTA CC210 seat Yes 3 3 -SESSION RESERVED USED1 3 102 040 : CSTA PBC seat No - - -02 041 : CSTA DMS appl. No - - -02 042 : CSTA DMS seat No - - -02 045 : CSTA 3P TAPI appl. Yes 2 2 -02 046 : CSTA 3P TAPI seat Yes 80 70 -SESSION RESERVED USED1 0 202 50 1002 047 : CSTA EP seat Yes 10 0 -02 048 : Voice Logging No - - -02 049 : CSTA Voice log appl. Yes 10 0 -02 050 : CSTA Voice log seat Yes 10 0 -02 051 : CSTA CTI server appl. Yes 10 0 -02 052 : CSTA CTI server seat Yes 10 0 -02 056 : iS3000 BCT sync.lic Yes - - -02 057 : QSIG Suppl. Services Yes - - -02 058 : QSIG iSNet Yes - - -02 059 : ISG channels Yes 100 38 -02 060 : CSTA Messenger appl. Yes 10 0 -02 061 : CSTA Messenger seat Yes 10 0 -02 064 : CSTA Desktop appl. Yes 10 0 -02 065 : CSTA Desktop seat Yes 10 0 -02 066 : Software SMA user Yes 50 19 -02 067 : CCIS over IP Yes - - -02 068 : IP Dect Yes - - -02 069 : SIP Phone Yes 50 12 -

233

11.1. LICENSE STRING

The License string can be seen as a software key. It contains information about the granted licenses. This License string is generated in the factory with a specific set of licenses ordered by the customer.

The License string contains coded information on maximum system capacity and allowed functionality. It is stored in a file (LICSuu.LIC) that has to be loaded in the system.

11.2. SYSTEM START

The presence and the contents of the License string and of the Fingerprint (the identification of a product instance) are checked at system start-up and afterwards at regular time intervals. If the result of the check is not correct, the system will start-up without any license activated. This means that the system becomes operational with the minimum configuration: 32 extensions, granted SystemManager and all the functions that are not restricted by a license mechanism.

When an error is detected in the license registration, the system produces an alarm that might lead to the degradation of functions. The alarms can only be erased when the correct license file is re-inserted.

When a new or replacement License string is installed, it is activated using the OM command ACLICS.

If the License string is correct, then the licensed facilities are available.

11.3. INSTALLATION OF THE LICENSE STRING

The License string must be loaded in the system. In the case of a multi-unit network, a License string must be attached to every unit in the system.

When a new license is requested by a client, it has to be ordered at the factory, which sends a new License file. The file must then be loaded in the client's system.

11.3.1. Installation in iS3000

To enter a new License string in an iS3000 unit, when the License file is available:

02 070 : Exchange UM Interface Yes - - -

EXECUTED<

234

1. Store the LICSuu.LIC file on the LBU,2. Activate the License string using the OM command ACLICS,

A user confirmation is required. The iS3000 stays operational and the new function is available.

3. Make a MIS-file,4. In case of multi-unit network, repeat the procedure for the other units of the system.

To enter a new License string in an iS3000 unit when the License string is only available as a written document:

1. Write the License string in a file, using a text editor,2. Convert the text file into an iS3000 file format, using the S2500CONVERT tool,3. Load the generated file into the iS3000,4. Store the file on the LBU,5. Activate the License string using the OM command ACLICS,

A user confirmation is required. The iS3000 stays operational and the new function is available.

6. Make a MIS-file,7. In case of multi-unit network, repeat steps 4 to 6 for the other units of the system.

If the signature check is not correct, a rejection code is returned after the ACLICS command.

If the License file does not belong to the system, another rejection code is returned.

11.3.2. Logical Device Name

The License string is available in the file called LICSuu.LIC, where uu stands for the unit number. This file is store on the LBU and can also be copied in a MIS-file.

It is possible to display the contents of the License string using the OM command DILICS.

It is possible to make a new license operational using the OM command ACLICS.

11.4. SOFTWARE ASPECTS

If a facility is accessed that is not licensed, an alarm is generated with the license number involved. The facility does not progress further.

It is possible to project the system with all facilities, but only the licensed facilities will work. The system can therefore be configured in any possible way, but when it becomes operational, only the actual licenses are granted.

If the licenses need to be changed in a system, the activation of these licenses can be done in

235

a running system: no system restarts are required.

• ExamplesIf you wish to assign the 257th BSP-ID on a system where only 256 are permitted, the OM command is accepted and executed, but it is not possible to call the last assigned BSP-ID.If 17 ACD agent extensions are assigned and only 16 are permitted, the 17th ACD agent is not selected when a call to the ACD group is made. Furthermore, no statistical information for this agent is sent to the CallManager Management Information System (MIS).If the IMP license is not granted, it is still possible to configure a unit in a multi-unit network, but inter-unit calls will be blocked.

236

12. COMPUTER TELEPHONY INTEGRATION

12.1. INTRODUCTION

Computer Telephony Integration (CTI) is a means to provide integration between telecommunications and computer equipment. The ISPBX offers an interface to support CTI. This interface is called CSTA (Computer Supported Telecommunications Applications) and is specified according to the ECMA-179 and ECMA-180 (European Computer Manufacturers Association) agreements (i.e. phase I). The interface on the ISPBX consists of one or more physical interface channels, which can be spread over an iSNet Private Networking network.

The ISPBX offers the CSTA interface. Via the CSTA interface a computer is able to do call monitoring and manipulation in the ISPBX. This means that an application that is running in the computer equipment determines the use of the interface.

In the various applications, two main groups are distinguished:

- Outbound call centres (like telemarketing)- Inbound call centres (teleshopping, telebanking etc.).

A simplified system structure for CSTA is illustrated in the figure below. This structure is used for outbound and inbound call centres. The computer has a CSTA interface to the ISPBX system. It controls also a terminal which is located on the desktop of the CSTA Subject. A CSTA Subject is a person who's telephone set is monitored by the application program running on the computer. Calls for his extension can be manipulated by the application program.

Figure 12-1 Simplified System Configuration for CSTA Applications

12.1.1. Examples of Outbound and Inbound Call Centres

In the following an example of an Outbound Call Centre and an example of an Inbound Call Centre is given.

237

Note that these applications are offered by the computer. The computer determines the type and capability of the application. The ISPBX offers only the interface to the computer.

• Example of an Outbound Call Centre for Telemarketing.An Outbound Call Centre can use a configuration as illustrated in the figure above. Generally the Host system selects a number of external subscribers which must be called for telemarketing. For the selected subscribers a data base (with name and if possible more information) is present in the computer. The computer calls a subscriber. As soon as the subscriber answers the call, the computer does the following:- Puts the call through to the CSTA Subject. (Preferably the CSTA Subject has a headset,

so that he has his hands free).- The computer displays the information of the subscriber on the display on the CSTA

Subject's desktop.As all the available information is displayed on his screen, the CSTA Subject immediately knows the data of the subscriber/client. The CSTA Subject does not have to waste his time with setting up the call, waiting until the subscriber answered the call and retrieving all information.As soon as the call is terminated the CSTA Subject handles the acquired data and in the mean time the computer tries to set up the next call.

• Example of an Inbound Call Centre (Teleshopping, Telebanking etc).An Inbound Call Centre is a configuration which can be useful for e.g. teleshopping, telebanking applications.Figure 12-2 "Simplified System Configuration for Inbound CSTA Applications" gives an example of the configuration.The implementation of an application can be as follows. If a call comes in, the call reception desk receives the call. The secretary at this reception desk asks the client's reference or bank number and enters this number into the terminal. The computer displays all the client information on the terminal of a CSTA Subject and prompts the CSTA Subject that a call is waiting. When the CSTA Subject is ready to receive the call, the CSTA Subject indicates this to the computer via its terminal. The computer sends a CSTA message to the ISPBX and the call is transferred. The CSTA Subject has the required client information and can serve the client in a very efficient way.As soon as the reception desk has transferred the call (blind or not blind), the reception desk is free to receive the next call. (A 'blind' call transfer means that the call is transferred but the destination extension is still ringing. 'Not blind' transfer means that the call is transferred and the destination extension has answered the call.)Note that the Call Reception desk can be the operator or an Interactive Voice Response System.

238

Figure 12-2 Simplified System Configuration for Inbound CSTA Applications

12.1.2. CSTA Subject

A CSTA Subject is an extension or group which is monitored by the computer. As soon as the computer starts monitoring an extension, this extension becomes a CSTA Subject.

When the computer stops monitoring, the CSTA subject is a normal extension again.

If an extension is a CSTA Subject, the ISPBX sends Call Events to the computer to inform the computer about the status of the extension. Also the computer can do call handling services on that extension. Note that monitoring is explicitly initiated by the computer and not by the ISPBX.

12.1.3. CSTA Agent

A CSTA Agent is a CSTA Subject who has logged on via the so called logon prefix. This means that the extension of the CSTA Agent first must have been defined as a CSTA Subject. Then the CSTA Agent dials the logon prefix at his/her extension. Now for this agent, the computer can use the CSTA Answer-Call service. When the Agent dials the logoff prefix, he/she remains a CSTA Subject.

The CSTA Agent uses the facilities of the computer via his or her telephone extension together with a terminal which is connected to the computer.

A CSTA Agent can have an extension (Business Telephone) with a headset. This allows

239

handsfree operation. When an Agent has a Business Telephone, he can use the auto-answer mode.

• CSTA Answer-Call ServiceWhen a call is delivered to a CSTA Agent, no ringing is started on the telephone terminal.Instead, via monitoring, the computer is notified about the arrived call. The CSTA application program prompts the agent about the arrived call on its computer terminal (which is connected to and controlled by the computer). Via its computer terminal the Agent can order an "Answer-Call" service after which the call is connected through to the extension of the agent. The extension must be in the Auto-answer mode, which means that it answers the call as soon as the computer has connected through the call to the extension.Because of the Auto-answer mode and the headset, the agent receives the call immediately at his/her headset after the computer has started Answer Call.Be sure to use a Business telephone with software version 3.02 or successor like ErgoLine when the answer-Call Service is to be used in combination with a headset.

12.1.4. General Rules

The following gives a number of general rules which are applicable to the CSTA implementation in the ISPBX:

- CSTA Call setup and manipulation by the computer is only accepted if the indicated party is a CSTA Subject.

- CSTA monitored extensions (CSTA Subjects) can also initiate and receive calls in the normal way by going off-hook.

- Monitoring can be performed on any extension or on any group DNR, but not on operators or trunk lines.In this document, monitoring is referred to extensions and although not specifically mentioned, it can be groups as well. For example ACD groups.

- Multiple computers can monitor the same extension (or group) at the same time, with a maximum of 10 monitors for 1 extension.

- One computer can monitor an extension (or group) one or more times, at the same time via one link. Although this is possible it is advised to avoid this situation.

- Any computer is entitled to manipulate a CSTA call provided that it monitors one of the involved extensions. As a result multiple computers can manipulate a CSTA call. Multiple computer manipulation will be handled one at a time.

- Even if all preconditions are fulfilled, certain CSTA Call handling operations may fail as result of specific projecting aspects. (Call barring, class of service, compatibility, congestion on resources, etc.)

- Mixed mode restrictions. Mixed mode means that a call setup/manipulation/clearance is done by means of an extension and the computer.

240

Mixed mode is only possible in case a connection is set up between two parties (no call diversion, add-on, conferencing etc.).Examples:- A call which has been added in a three party conference by means of the extension,

cannot be cleared by means of the computer.- If an extension goes in enquiry (activated from this extension), the computer can no

longer manipulate the call (but it can manipulate the individual connections).- Which services are offered and how they can be used, depends on the ISPBX's system

software.Table 12-1 "CSTA functions"gives you an overview of the various maintenance releases and their offered functionality.

12.2. CONFIGURATIONS WITH VARIOUS COMPUTER TYPES

The CSTA applications focus primarily at the call centre or office environment. Agents' or employees' desks generally comprise a telephone extension (analogue or digital) and a computer screen (terminal or PC).

The PC acts as a terminal to an computer system or act as a "client" in a LAN environment. In the following sections a number of configuration examples are illustrated.

12.2.1. PC LAN Environment

This type of architecture is the environment of e.g. Novell Telephony Server. An example of configuration is illustrated in the figure below.

Figure 12-3 Typical CSTA Configuration in a LAN Environment

12.2.2. IBM CallPath® Environment

In the IBM environment, IBMs Callpath® Services Architecture is supported. IBM uses an ECMA PC based CSTA Gateway ("SwitchServer/2") to "translate" the ISPBX specific protocol

241

elements to the CallPath software interfaces (APIs). This SwitchServer/2 contains two software parts: the switch independent code (generic part of the CallPath product) and the switch dependent code (dedicated for the ISPBX). For more information consult the IBM documentation (Reference Manuals). The configuration is illustrated in the figure below.

Figure 12-4 Typical CSTA Configuration in an IBM Callpath Environment

® Callpath is a registered trade mark of IBM.

12.2.3. Voice Processing Systems in Call Centre Environment

In a call centre environment, Interactive Voice Processing Systems can be useful. They can be used for various purposes, e.g.:

- To determine to which service the caller wants to be connected ("Auto Attendant functionality").

- To identify the caller, before connecting the call to an agent.- To carry out simple tasks, for which no human agents are required (provide and acquire

information).- To carry out standard transaction processing tasks (e.g. receive an order).

Generally they are connected to both the ISPBX (via line circuits) and to the computer (to exchange commands and information). The configuration is illustrated in the figure below.

242

Figure 12-5 Typical CSTA Configuration with Voice Processing System

12.3. NETWORKING ASPECTS

The networking aspects and functionality of CSTA are different for the following two types of networks:

- iSNet Private Networking. This type of network offers fully integrated networking.- DPNSS Networking.

12.3.1. iSNet Private Networking

iSNet Private Networking offers a fully integrated network to the customer. The Network is transparent for all services and functions. It comprises a number of iS3070/3090 units which are connected together by means of IMP links. Note that all units in the network must run with the same software version.

12.3.2. CSTA Network Topologies

In the following text these terms are used:

- CSTA session : Logical connection (at CSTA application level) between a computer and a PABX.

- Physical link : The physical connection between a computer and the PABX. This is either an ISDN B-channel or an Ethernet connection.

Each ISPBX unit in the network can handle up to 15 CSTA sessions: 5 over ISDN and 10 over Ethernet links. The exact numbers depend on boundary 276 (maximum number of CSTA links per unit), license 17 (number of ISDN iSLinks) and license 21 (number of Ethernet iSLinks). A combination of ISDN and Ethernet iSLink is possible.

243

The CSTA session boundary and iSLink licenses relation is:

- ISDN iSLink (license 17) licenses in use + Ethernet iSLink (license 21) licenses in use < or equal total number of CSTA sessions (boundary 276).

The diagram below depicts the possible network connections and configurations that support CSTA.

Figure 12-6 Configuration for CSTA

• CSTA Sessions over ISDNThe diagram below depicts that a ISDN link supports only one CSTA session. An iS3000 system may support up to 5 such sessions.

Figure 12-7 ISDN iSLink Sessions

• CSTA Sessions over Ethernet in CCS SystemsThe diagram below shows that a TCP session may span several Ethernet links. One TCP session however supports one CSTA session. An iS3000 system supports up to 10 such sessions.

CIE-2 CIE-2CIE DLC-U DLX-LDTX-I

BIM1.6

BIM2.x

BIM1.6

PNT-1 PNT-L

10 Mbit ETHERNET

CSTA APPLICATIONS

CCS SYSTEMSCPU3000SYSTEMS

CCS & CPU3000 SYSTEMS

ISDN ISDN

iS3000 CSTA PC

CSTA ServiceProcess

CSTA Application

ISDN link

D-channel

CSTA session

244

Figure 12-8 Ethernet iSLink Sessions in CCS Systems

• CSTA Sessions over Ethernet in CPU3000 SystemsThe diagram below shows a TCP session that spans one Ethernet link. One TCP session supports one CSTA session. An iS3000 system supports up to 10 such sessions.

Figure 12-9 Ethernet iSLink Sessions in CPU3000 Systems

12.3.3. IP Addressing for CSTA

For CSTA applications the following IP addressing rules apply:

1. The CSTA PC must define a route(using the route command) to every cie-net it wants to connect toThe (Windows/NT) command to add a route to cie-net-1 would be:"route -p add <cie-net-1>.0 mask 255.255.255.0 <srv-net>.a 1"

2. Each CIE, BIM, CSTA-PC, CPU3000 that takes part in CSTA applications must have their own (i.e. unique) IP address.

Note: Although version 1 CIE's (CIE-1) have the same MAC-address (i.e. Ethernet address) when in the same board position in different units, their respective BIMs have to assign them a

CSTA PC

CSTA ServiceProcess

CSTA Application

TCP session

CIE CSTA PC

CSTA ServiceProcess

CSTA Application

TCP session

CSTA session

BIM

Ethernet linkEthernet link Ethernet linkEthernet link

IP-address IP-address

CPU3000 CSTA PC

CSTA ServiceProcess

CSTA Application

TCP session

IP-address IP-address

Ethernet link

CSTA PC

CSTA ServiceProcess

CSTA Application

TCP session

CSTA session

245

different IP-address. To this end, choose a different subnet (i.e. cie-net-x and cie-net-y) using "instnet" or "bootpsetup" on UNIX and NT BIM's respectively.

The diagram below depicts an example IP addressing scheme that adheres to the above stated rules.

Figure 12-10 Example of an IP Addressing Scheme

The scheme above implements the following rules:

1. Define a sub-net for each BIM/CIE combination called cie-net-x;2. Name each BIM gateway interface BIM-x;3. Name each CIE "CIE-x-y" where y depends upon the CIE's board position;4. Y starts with 1 for the first valid board position for example 7;5. Each CIE's host number = <cie-net-x>.y;6. Number the BIM interface that participates in the cie-net with <cie-net-x>.11;

host number =11host-address = <cie-net-4>.11

BIM-4

cie-net-4 = 192.168.4BIM

<srv-net>.d

CSTA-2

BIM-3

cie-net-3 = 192.168.3BIM

<srv-net>.c

BIM-2

cie-net-2 = 192.168.2BIM

<srv-net>.b

host number =11host-address = <cie-net-1>.11

BIM-1CIE-1-3CIE-1-3

iS3070/iS3090

BIMcie-net-1 = 192.168.1 <srv-net>.a

CSTA-1

8 th iS30x0 on

CPU3000host name = iS3000-8

host number = <srv-net>.g

<srv-net>.e

<srv-net>.f

CIE-2-3

iS3070/iS3090

CIE-3-2

iS3070/iS3090

CIE-4-1

iS3070/iS3090

multi-unit network (IMP)

LAN

246

7. Define suitable and sensible CSTA-PC, CPU3000 and BIM-x host names and host numbers and use host-names were possible.

Note: It is possible (exceptional situation) to have a second BIM/CIE combination connected to a unit. If so, a separate sub-net has to be defined for this BIM/CIE combination.

12.3.4. DPNSS

In DPNSS networks the typical CSTA functions are not supported, since the ISPBX monitoring function is not passed over DPNSS.

However, in DPNSS networks call information (such as call progress information and calling line identity) is forwarded with a call. The DPNSS services provide information to generate the required monitor events. So monitoring on behalf of CSTA is only possible by using DPNSS information.

• ExampleThis example shows how CSTA services can be used in a DPNSS network;Figure 12-11 "Typical CSTA Configuration with Voice Processing System".

Figure 12-11 Typical CSTA Configuration with Voice Processing System

In this example, the DPNSS network consists of two ISPBXs. Incoming calls from the PSTN routed to Voice Processing System (VPS) can be monitored by the computer. At receipt of the call, the computer can setup a consultation call from the VPS to an extension in the other ISPBX. The DPNSS signalling protocol provides call progress information to the VPS. By monitoring the VPS, the computer knows when and by whom the consultation call is answered. Then the call can be transferred via the CSTA Transfer Call service. Along with the transfer of the voice call, the computer can also transfer the data that has been acquired by the VPS to a terminal next to the extension in the other ISPBX. After transferring the call, CSTA looses control over the call because there are no CSTA

247

Subjects left in the call.

Whenever it is required to monitor or manipulate extensions in the other ISPBX directly, the computer should be connected to the other ISPBX also.

12.4. FUNCTIONALITY

12.4.1. General

The functionality of the CSTA interface is communicated at level 7 according to the OSI layered structure model. By means of this interface a set of functions is offered to be used by the application programs for information exchange and call manipulation. There are three main groups distinguished in the services which are offered at layer 7.

Note: Not all services which are defined by ECMA-179 are supported. Consult the PICS document which is available at the development centre at BCS in Hilversum, the Netherlands.The Call Event Reports cover the ECMA agreements.

• Switching Function ServicesThe following services can be sent from the computer to the ISPBX:- Alternate Call- Answer Call- Clear Call- Clear Connection- Conference Call- Consultation Call- Divert Call- Hold Call- Make Call- Predictive Call- Reconnect Call- Retrieve Call- Transfer Call- Set feature- Query device

• Status Reporting ServicesThe ISPBX provides the status reporting services to the computer.The following 'Call Event Reports' can be sent from ISPBX to the computer:- Call Event Reports:

Call ClearedConnection Cleared

248

ConferencedDeliveredDivertedEstablishedFailedHeldNetwork ReachedOriginatedQueuedRetrievedService InitiatedTransferred

- Agent State Event Reports:Agent logged onAgent logged offAgent Not ReadyAgent ReadyAgent Work Not ReadyAgent Work Ready

- Maintenance Event Reports:Back In ServiceOut Of Service

- Feature event reports:Do Not DisturbForwardingMessage WaitingRequest Agent State

- Monitoring functions:Monitor StartMonitor Stop (also from ISPBX to computer)Change Monitor filter.

• Bidirectional ServicesSystem Status Services: these services are used to report a degradation of the offered CSTA functionality. System Status services can be bi-directional, i.e from ISPBX to computer and from computer to ISPBX.EXAMPLE:The ISPBX uses the System Status service in case of a communication problem between

249

two units in an iSNet Private Networking system.

Note: The parameters of the services are specified by the ECMA standards. They are not all supported by the CSTA functionality in the ISPBX. In a detailed interface description (PICS document), the parameters are specified. This interface description is agreed with suppliers of computer systems which can be connected to the ISPBX. For more information consult NEC Unified Solutions in Hilversum, the Netherlands.

12.4.2. Description of Switching Function Services

The switching function services are services generated by the computer, and sent to the ISPBX. The ISPBX replies to each command by means of a "result message". This indicates that the command is accepted or rejected. (Any change in status of the device is separately reported by means of a Call Event Report.) The following switching functions are supported by the ISPBX.

• Make CallThe Make Call Service attempts to establish a CSTA call between two devices. First the originator device is called. On answer, the destination device is called and connected to the originator.Interactions with other facilities and restrictions are:- The originator must be a CSTA Subject;- Any diversion on the originator is not executed. COB on the originator is prohibited.

Automatic COB at the destination is executed as normal, also when the initiator has projected automatic COB on initiator;

- Ringing time-out on initiator is handled as a normal call;- Facility dialling can not be activated using the make-call service. Exceptions are the

CSTA logon/logoff prefixes;- Do-Not-Disturb on the originator is overruled;- Post dialling facilities are not possible when a busy destination has been detected;- Allowed results after analysis of the destination are internal number, trunk access

code(+ number), operator m-code general/priority, paging prefixes (+ number) and finally network access code (+ number);

- A make-call for an extension with FCM 'direct access protected' is rejected.• Predictive Call

In contrast to the Make Call Service, first the destination is called. The (optional) allocation parameter of this command determines at which moment the destination is connected to the originator. Values can be 'call-delivered' (default) if the destination is alerting or queued (COB) on the destination, or 'call-established' if the destination has answered the call.Interactions with other facilities and restrictions are:- The originator must be a CSTA Subject;- The originator must answer the call in the normal way (lifting the handset) or via the

250

auto answer mode;- If the initiator is an extension, the same restrictions apply as mentioned under 'Make-

Call';- For a 'call-established' call, the 'CSTA-predictive-call ringing-time' will guard the time

the destination keeps ringing: on time-out the call is aborted;- If the originator side has been alerted yet, the CSTA connection-id issued and it is

possible to clear that connection via the Clear-connection service;- If a predictive call to a group is made, first the group is selected and then the member

within the group according to the selection mechanism assigned for that group.- If a predictive call with as originator a group is made and the option is 'call-delivered',

the same restrictions as for 'Make-Call' apply. In particular, announcements are not provided;

- If a predictive call with as originator a group is made and the option is 'call-established', facilities (such as: COB on group, announcements, diversions) at the originator side are executed.

• Consultation CallThe service places an existing active call at a device on hold and attempts to establish an enquiry call to the new destination.

• Answer CallThe Answer Call Service connects an alerting call to a CSTA Agent. Preferably the CSTA Agent is a device that supports "intercom enabled" mode e.g. Business Telephone.The CSTA Agent does not have to go off-hook to answer a call but the Answer Call Service of the computer connects the alerting call to the extension with "intercom enabled" mode.This function is only executed if the indicated party is logged on as CSTA agent or it is an ErgoLine terminal operating in the C-mode. When an ErgoLine terminal in C-mode is used NEBOUND 265 (Number of feature requests per unit) defines the number of ErgoLine terminals, which can be answered at the same time, using the service answer call. It is advised to set this NEBOUND 265 the same in all units of a FIN.

• Clear ConnectionThe Clear Connection Service releases the specified device (CSTA Subject) from the designated call. If the user is still off-hook after the service has been executed, he hears park tone. The remaining call topology is similar to the non-CSTA situation when a party clears.In case the command specifies a device in a Conference Call, a two party call remains.

• Clear CallThe Clear Call Service releases all the devices from the specified call, and eliminates the call itself. The call ceases to exist and the CSTA identifiers used for observation and manipulation are released.If the user is still off-hook after the service has been executed, he hears park tone.In case the command specifies a device in an EDP set-up Conference Call, all devices are released.

251

• Divert CallThe Divert Call Service diverts a call to a new destination in case the computer issues a Divert Call Request. The new destination may be any extension, operator, trunk or group that can be selected without CSTA. Only the old destination has to be a CSTA Subject.The connection to the old destination must be in the ringing, queued, failed or connected state.The Divert Call Service is rejected when the new destination has an active Call Forwarding or Follow-Me (these are iS3000 voice facilities).

• Alternate CallThis function performs the iS3000 'shuttle' facility. It places an existing active call on-hold and then retrieves a previously held call. (It switches between the two opposite parties.)This function is only allowed in case the enquiry call was set up via the Consultation Call service by the computer. This means that if the CSTA Subject had setup the enquiry call manually from his extension, the Alternate Call function is rejected.

• Reconnect CallThe Reconnect Call Service clears an existing connection and then retrieves a previously held connection at the same device.This function is only allowed in case the enquiry call was set up via the Consultation Call service. This implies that if the CSTA Subject had setup the enquiry call manually from his extension, the Reconnect Call function is not allowed.

• Hold CallThis service is to be used in case a device in an established connection wants to set the opposite party on hold. No new call can be initiated after the party is put on hold. Depending on the projecting in the ISPBX, the opposite party will get Music On Hold, announcement, tone or silence.The "Retrieve Call" service can be used to get reconnected to the party on hold. Another possibility is to manually press the enquiry key.

• Retrieve CallThis service retrieves a call previously set on hold. This service is to be used instead of the Reconnect Call service in those cases where the active call does not exist anymore.(This may happen in a Consultation Call situation where the computer has issued a Clear Connection request on the active connection of the consulting device. The remaining call topology includes a single held call only).This function is only allowed in case the enquiry call was set up via the Consultation Call service or the Hold Call service by the computer. This means that if the CSTA Subject had setup the enquiry call manually from his extension, the Retrieve Call function is rejected.

• Conference CallThe Conference Call Service is the CSTA service for an add-on call in the ISPBX. This means that the held connection (after consultation call) is added to an already existing connection.This function is only allowed in case the consultation call was set up via the Consultation

252

Call service by the computer. This implies that if the CSTA Subject had setup the enquiry call manually from his extension, the Conference Call function is rejected.

• Transfer CallThe Transfer Call Service transfers a held call to an active call at the same device. In other words: it merges two calls (one on-hold and one active) which where connected to one device. The device is withdrawn from both calls and released. If the device/user is still off-hook after the service has been executed, he hears park tone.This function is only allowed in case the enquiry call was set up via the Consultation Call service by the computer. This means that if the CSTA Subject had setup the enquiry call manually from his extension, the Transfer Call function is rejected.

• Set FeatureThe status of a device feature of the specified device can be changed. Only one device feature request may be requested for a device at the same time. NEBOUND 265 (Number of feature requests per unit) defines the number of the devices having a request pending at the same time.The Set Feature service enables the EDP to change the state of monitored devices (extensions and groups).The following features are supported :'Do Not Disturb':Activating the 'Do Not Disturb' via CSTA will activate (or deactivate) the permanent version of 'Do Not Disturb'.If a 'Do Not Disturb is set by an user (Temporary Do Not Disturb) or by means of OM (Semi-Permanent Do Not Disturb) then it can be deactivated via the CSTA interface.'Forward':The following call forwarding types are supported:- Immediate (follow me in iS3000)- No answer- No answer internal- No answer external- Busy- Busy internal- Busy externalNote that for CSTA the set feature information is stored in the Basic Service Profile, which belongs to the projected default IBSC.No traffic class check is done for the call forwarding destination.'Message Waiting':There are 3 message waiting types in ISPBX : type 0, 1 and 2.Activation via CSTA will activate (or deactivate) the message waiting type 0. The message waiting types 1 and 2 can not be deactivated via the CSTA interface.'Requested Agent State':Depending on the input data the following actions are executed by the ISPBX:

253

• Query Device:The Query device service enables the EDP to retreive feature(status) information concerning monitored devices.The following 'query device features' are supported by the ISPBX.- Device feature 'Gentlest'

The following 'Gentlest' queries are valid for Non-ACD group members:

The following 'Gentlest' queries are valid for ACD group members:

- Device feature 'Do Not Disturb'There are 3 types of Do Not Disturb in the ISPBX:

DEVICE FEATURES FOR 'AGENT STATE'Feature object for Non ACD group membersRequested state: Result in the ISPBX:'Loggedin' 'Redjected''Loggedout' 'Redjected''Ready' Member set to 'present''Not ready' Member is set to 'absent'Feature object for ACD group membersRequested state: Result in the ISPBX:'Loggedin' Agent status is set to 'Loggedin''Loggedout' Agent status is set to 'Loggedout''Ready' Group member is set to 'present''Not ready' Group member is set to 'absent'Feature object for ACD groupsRequested state: Result in the ISPBX:'Ready' ACD group is set to 'Day'Not ready' ACD group is set to 'Night'

ISPBX MEMBER STATUS AGENT STATE'Absent' 'Not Ready''Present' and 'Idle' 'Ready''Present' and 'Busy' 'Work nor Ready'

ISPBX ACD AGENT STATUS AGENT STATE'Logged off' 'Null''Absent' 'Not ready''Present' and 'Idle' 'Ready''Present' and 'Busy' 'Work not ready''Present and working after call' 'Work ready'

254

- Temporary Do Not Disturb- Semi Permament Do Not Disturb- Permanent Do Not DisturbQuery device will return whether one of the Do Not Disturb features is active at the moment the query is executed.

- Device feature 'Forward'The following call forwarding types are supported:- Immediate- No answer internal- No answer external- Busy internal- Busy externalA list of active call forwarding types is returned, based on the Basic Service Profile which belongs to the projected default IBSC.

- Device Feature is 'Message Waiting'There are 3 types of MessageWaiting in ISPBX:- Message Waiting type 0 : can be activated by the extension user, TMS and CSTA.- Message Waiting type 1 : can be activated by the extension user and TMS.- Message Waiting type 2 : can be activated by the extension user and TMSQuery device will return whether one of the Message Waiting features is active at the moment the query is done. Note that for CSTA the feature information is used from the Basic Service Profile which belongs to the projected default IBSC.

12.4.3. Call Event Reports

Each Call Event Report is a message that indicates a change in the state of one or more connections in the call (if monitored). A Call Event Report thus corresponds to a "call state transition" either initiated by the computer or by the telephone extension.

The following Call Event Reports are supported in the ISPBX:

• ConferencedThis event is generated when an add-on call is established. In the event a specification is provided which devices are now connected in a three party conversation call.

• Connection ClearedThe Connection Cleared event indicates a device has (been) disconnected from a call.The event report is NOT generated in case a call is conferences, transferred or diverted.

• DeliveredThe event indicates that a device has entered the alerting (ringing, alerting tone etc.) state without Camp On Busy.

• DivertedThis event is generated if a call has been diverted from a device to another device (e.g. call

255

forwarding or follow-me, or with the Deflect Call Service).The Diverted event is NOT generated in case of DDI fail situations if the external trunk line is routed to the operator (or night extension) without alerting the device e.g. congestion etc.

• EstablishedThis event is generated if a device answers the call. The call reaches the conversation phase.

• FailedThis event is generated if a call cannot be established. The cause for this can be that the extension is busy or that the number is unobtainable, congestion etc.

• HeldThis event indicates that a device puts a party on-hold. This can occur e.g. if a consultation call (or enquiry via the extension) is started.

• Network ReachedThis event indicates that an outgoing call has been set established via a trunk line. It indicates there may be a reduced level of event reporting provided for the involved party in the call. It will only be generated when an outgoing trunk call is setup e.g. to the PSTN.

• OriginatedThis event indicates, that a device (possibly with a call setup via the computer) has attempted to make a call. It is generated when the dial phase has been completed.

• QueuedThis event indicates the call is queued in some COB-, or operator queue.

• RetrievedThe event indicates that a held call has been retrieved. Together with the held-event, it is used in case of the iS3000 shuttle function.

• Service InitiatedThe event is generated in case dial tone (e.g. after off-hook/enquiry) is provided to monitored device. The event is also generated in case of a CSTA call setup by the computer (e.g. make call) and the CSTA Subject is prompted to answer the call.

• TransferredThe event indicates that a call has been transferred to another device and the initiating device is removed from the call (either by the Transfer Call function or a transfer due to release on the extension).

12.4.4. Agent State Event Reports

An Agent State Event Report is a message that indicates a change in the state of an agent. Within the ISPBX, an agent is a monitored ACD group or a monitored member of an ACD group. The agent state report always indicates the new state an agent enters, independently from any previous state.

256

The following event reports are supported:

• Agent logged onThe event indicates that the device is in the 'logged on' state.

• Agent logged offThe event indicates that the device is in the 'logged off' state.

• Agent not readyACD group switched to 'night' condition or ACD group member switched to (forced) absent.

• Agent readyACD group switched to 'day' condition or ACD group member switched to present.

• Agent work not readyACD group member is in the after call work period.

• Agent work readyThe after call work time of the ACD group member has ended and the member is able to receive new group calls.

12.4.5. Maintenance Event Reports

A Maintenance Event Report is a message that indicates a change in the service state of a monitored device.

The following maintenance event reports are supported:

• Back in serviceThe event indicates that the status of the device is INS (in service) in the ISPBX.

• Out of serviceThe event indicates that the status of the device is not INS in the ISPBX.

12.4.6. Feature Event Reports

A Feature Event Report is a message that indicates a change in the state of a monitored device.

The following feature event reports are supported:

• Do Not Disturb eventThe event indicates that for a specified device the "Do Not Disturb" function is set or removed.

• Forwarding eventThe event indicates that for a specified device one of the forwarding functions is set or removed.

257

12.4.7. Monitoring Command Services

The following services are used in the monitor function:

• Monitor StartWith this command, the computer can observe the status of devices (which are extensions, groups or a VPS).This command comprises also a filter function. By means of this filter function, the ISPBX sends only the information that the computer has asked. By default all events are sent.According to the ECMA-179 specification, events can be generated for a specific device (device-type monitoring) and for calls (call-type monitoring). In the ISPBX only device-type monitoring is supported.

• Monitor StopThe Monitor Stop service is bidirectional.The computer uses this command to cancel a previously issued Monitor Start.The ISPBX uses this command to inform the computer whenever, due to internal reasons, the ISPBX has stopped monitoring an extension. This may occur for example if a DNR is deleted or moved to another unit. Note that monitoring does not stop when the DNR is moved within the same unit.

• Change Monitor FilterChange Monitor Filter allows the computer to change the set of event reports that are provided by the ISPBX.

12.5. APPLICATIONS

12.5.1. General Description

The CSTA interface supports applications for Inbound Call Centres, Outbound Call Centres or a mix of the two, and the office environment.

CSTA applications can enhance the productivity and service level of ACD agents and can therefore be seen as an addition (not replacement!) to our ACD product offer.

The Inbound Call Centre applications provide the agent with:

- All relevant information of the caller.- All relevant information of the dialled service.

The Inbound applications do not export the call processing/routing functionality to an external computer system.

The Outbound Call Centre applications provide computer controlled call setup by:

258

- Giving the agent the functions to select a customer from the database in the computer environment and to initiate a call to that customer by hitting a key on his computer keyboard ("preview dialling") or,

- Giving the computer environment the functions to setup a call to a customer and to transfer the call to an agent if the customer picks up the phone ("predictive or turbo dialling").

The office environment applications provide a combination of the functions mentioned above, supporting any office employee (e.g. executives, secretaries, sales people, product managers) in his/her communication activities.

12.5.2. Examples

The following gives examples of CSTA applications for Inbound Call Centres and Outbound Call Centres.

Note: In the following examples functionality is assumed which can be offered by the computer. The computer determines the type of CSTA applications. The ISPBX does not offer the applications as mentioned in the examples. It only offers the CSTA interface to the computer.

• Inbound Call Centres (with or without ACD)Inbound Call Centres can be equipped with or without ACD (Automatic Call Distribution) equipment.CSTA applications enhance the productivity and service level of ACD agents. It does not replace the ACD functionality but it can be added to the ACD environment to improve efficiency of the ACD agent.By means of the CSTA computer the following information can be automatically displayed on the screen of the (ACD) agent:- The customer's information.- The service the customer dialled.The information on the screen can be combined with the applicable "form" (e.g. orderform or question list) to be filling in by the agent. This type of service is called "scripting".The customers identification is required to acquire the customer's information. This customers identification can be retrieved in the following ways:- Via ISDN (if applicable, using Calling Line IDentity);- Via Voice Processing Systems offering Interactive Voice Response Applications (IVR).

The customer enters its customers number via his/hers telephone keypad or via speech with speech recognition in the IVR system.

- Via human intervention.Before being transferred to an actual ACD service, the caller is connected to a person who asks the caller for his name or customers number.

259

- Via a "virtual DNR". This means that each customer dials a "personal" telephone number which includes the customers number.

- By means of a combination of these.If a call is transferred from one agent to another agent or supervisor, the customer's information is automatically transferred to the screen of the "new" agent or supervisor ("coordinated voice/data transfer"). This improves service and efficiency because the caller does not have to tell his "story" twice. The CSTA interface handles all events for transferring the information.It offers also powerful possibilities for "cross selling". After handling the customer demands, he is transferred to another agent who tries to sell him another product. In case the customer dials a generic helpdesk, and the customer requires specific information the call can be transferred to groups of specialists in the ACD environment.In the CSTA environment, very often the transfer of the call is initiated on the keyboard of the agent's workstation (not on his phone). Also answering a call is often carried out on the computer terminal. Agents use in this case a headset.A specific application of CSTA with a VPS (and if required ACD) is the "Automated Attendant" application. In this application there is one central telephone number for the company that covers various services (especially popular with the toll-free numbers).After the customer has dialled the number, the VPS system automatically asks which service he requires. The customer enters the number of the services at the keypad. If the VPS supports speech recognition, the customer can tell the number. The VPS transfers the number to the computer. Via the CSTA interface the CSTA application connects the customer to the relevant group or extension which handles this service.

• Outbound Call Centre EnvironmentIn the Outbound Call Centre environment the application Turbo-dialling or Power-dialling (in CSTA terminology Predictive Call) increases efficiency highly. In this application the CSTA application equipment sends a command to the ISPBX to setup a call to a certain destination (customer), without connecting an internal party (agent) to the call. The call is transferred to an agent if the destination answers the call or if the destination extension starts ringing. If no agent is available at the time, an announcement (or tones) can be given to the destination.The productivity of the Agents is increased because they do not have to dial the numbers manually. Also they don't have to wait until the destination answers and they don't waste time with unsuccessful callsIn most cases the called number (destination) information is transferred to the agents computer screen when (or just before) he gets the call.The timing of the setup of new calls depends on the average chance that a call is successful, the average duration of a call, the number of free agents and the status of current calls. Usually the CSTA application takes care of when to start new calls.Another option to support the Outbound Call centre environment is Preview Dialling. In

260

this case the agent gets the customer's information on his computer screen before the call is initiated. He can initiate the call by pushing a button on his keyboard.

• Other Outbound Call ApplicationsThe computer controlled call setup could be beneficial for almost every user that has a workstation on his desk and who makes a lot of phone calls. Simply select a name from a database and hit-a-key to start the call (also in hold situations!) It improves comfort and efficiency.

12.6. HARDWARE CONFIGURATION ASPECTS IN ISPBX

The computer environment must be connected to the iS3000 iSNet Private Networking network via 1TR6 or ETSI ISDN S0bus, or via TCP/IP Ethernet.

• Connection via ISDNThe ECMA CSTA protocol is implemented by using user-to-user messages via the D-channel of the S0bus. As there is a relation between the D-channel and the B-channels, one B-channel is occupied because of the use of the D-channel. The B-channel itself is not used to transfer messages.The following interface equipment must be used for the CSTA connection to the computer:- DTX-I.- DLC-U with PNT1 version 2.02. This combination allows a greater distance between

the computer and the ISPBX in comparison to an S0bus connection to a DTX-I. The connection between the DLC-U and the PNT1 is two wire, which can also be an advantage if the existing wiring is already 2 wire.

Note: The firmware packages on the DTX-I, DLC-U, PMC or PPU must be capable of handling CSTA. All packages which are associated with Call@Net are capable of handling CSTA.

• Connection via EthernetFor Ethernet, the ECMA CSTA protocol is implemented by TCP/IP messages. The following interface equipment of a CCS system must be used for the CSTA connection to the computer:- BIM : release 1.6 or higher with an additional Ethernet card.- CIE : the enhanced CIE board with the latest firmware package.In a CPU3000 system, the CPU3000 board with software package Call@Net or higher must be used.

The following guidelines must be taken into account when you are configuring the hardware of your ISPBX system:

261

- When using ISDN for CSTA iSLink do not connect high loading devices (such as SuperVisors or another CSTA link) to the same board.

- CSTA commands cannot be forwarded from one ISPBX unit to another ISPBX unit in a DPNSS network.

- CSTA commands are not forwarded if units in an iSNet Private Networking network have software incompatibility (not the same software package).

- When using ISDN for CSTA iSLink, If several computer links must be connected to the same system, it is strongly advised to not only connect them to different boards, but also connect them to different PMs.

- The computer environment may be connected to an iSNet Private Networking network by more than one physical link.

- There is no restriction to the location where the physical link is connected to the iSNet Private Networking network.

- Multi-unit CSTA (where a monitor is started in a unit different from the unit where the CSTA link is connected) is not supported when using CSTA Ethernet.

12.7. IMPLEMENTATION / PROJECTING

The implementation of CSTA in the ISPBX implies assigning the circuit(s) for computer-ISPBX link(s) and assigning the extensions for CSTA agents.

Ethernet connection doesn't require any OM command: only the BIM needs to be configured.

12.7.1. OM Commands for computer-ISPBX Circuits

The computer-CSTA link to the ISPBX is connected to a circuit on the DLC-U or DTX-I or their successors. The circuit is projected as follows:

• Assigning the circuitThe circuit is assigned by ASBRDS (including PCT assignment) or ASPCTB. The S0bus to which the computer is connected should be projected as LCT like a normal 1TR6 or ETSI extension. The circuit which is used for the CSTA connection does not require a specific circuit type or signalling group.- ASBRDS : To assign the DTX-I or DLC-U board to the ISPBX. Assign the board as a

normal LCT for 1TR6 or ETSI.- ASPCTB : If the circuit or board is already assigned to the system, and you want to

configure one circuit for the CSTA purpose, you must use the DEPCTB and the ASPCTB command.

• Assigning BSP-ID, CV, FCMProject the circuit as a normal extension. Assign a BSP-ID to the circuit by means of OM command CHDNRC. Use OM command ASFACM to assign the following FCMs to the DNR:

262

- 04 : data protection;- 38 : direct access protected.The IBSC/BSPT should be: 64Kbit/s unrestricted. This can be done by means of the following OM commands:- CHDNRC : Change DNR (BSP-ID) circuit relation. Assign a DNR+BSPT to the

circuit. The IBSC should be "0" (64kbit/s unrestricted).- CHDNRS : To change only the Service Capabilities. The BSPT should be '98' (any).No other properties should be assigned to the DNR.The BSP-ID of the other B-channel of the S0bus may NOT have Facility Class Mark 'B-channel overflow'.A not yet used CV value must be defined, which must prevent that he circuit is connected to any existing CV. The following OM commands are available:- CRCVAL : Create Compatibility Value.- CHAGCV : Change Analysis Group and Compatiblity Value for a DNR.

• Assigning CSTA Control PrefixWhen the computer needs attention of the ISPBX processor it 'dials' the CSTA Control Prefix. The prefix must be assigned with command:- ASINTN : use result-ID 137 = "CSTA Control Prefix".

12.7.2. Assigning a CSTA Agent Extension

CSTA agents have normal extensions of any type. To indicate that an extension is assigned as CSTA agent, the CSTA agent must dial the "logon" prefix for CSTA. This CSTA logon prefix is: logon prefix + digit 0 to indicate CSTA. To logoff the CSTA agent must dial the "logoff" prefix + digit 0 to indicate CSTA. These prefixes must be assigned with OM command:

- ASINTN : use result-ID 135 (logon) and 136 (logoff) in the initial dialling tree. For both result-IDs, the number length must be 1.

Note: It is advised to also project a voice DNR to the same S0bus. Use CHDNRC and CHDNRS to assign such a voice DNR with BSPT = 14 (=ISPBX speech).

12.8. CSTA INPUT/OUTPUT SERVICES

CSTA Input Output (I/O) services allow computer applications to provide users with enhanced capabilities, by exploiting the characteristics of telephony devices. I/O services allow input to be received and output to be sent from devices with telephony capacities. The equipment concerned can be:

• DECT terminals, supporting Low-Rate-Messaging-Service (LRMS);• Message servers (PCs with computing function) implementing CST applications employing

263

CSTA I/O services, which are running on an EDP environment.

Note: The terminals and EDP have to be connected to the same iSNet MAN (multi-unit system).

CSTA I/O services have been applied for the Low Rate Messaging Service facility. This facility includes the following:

• The Message server can send a message to a DECT terminal indicated by its DNR;

Note: This function is also known as "Paging over DECT".

• A DECT terminal, can send a message to a Message server;• A DECT terminal can send a message to another DECT terminal (this function is not

directly related to CSTA I/O services).

These facilities are described below.

12.8.1. Conditions of use for the CSTA I/O services

In order for a DECT terminal to receive message calls, a BSP-ID has to be assigned in addition to the BSP-ID for the voice calls. The extra BSP-ID has to contain BSPT 0, which stands for '64kbits unrestricted'.

In order to allow a message call while the DECT terminal is busy in voice conversation, the facility class mark 50 ('B channel overflow') has to be set for both BSP-IDs.

In case it is necessary to guarantee that a DECT terminal can receive a message call while in conversation, only one DECT terminal should be projected per pair of DCC-circuits.

When sending LRMS messages from terminal to terminal, the destination number has to be projected as internal in the analysis tree for alternative destination dialling.

12.8.2. Message call initiated by a computer application

When a Message server sends a message, the system handles the call according to the following process:

1. A 'Start Data Path' request is sent to the ISPBX with the device-id (DNR) of the concerned terminal;

2. The ISPBX checks the validity of the CSTA I/O license for the selected device;3. The ISPBX selects the BSP-ID which matches the BSPT 0, and sends a 'Set-up' signal to the

terminal;4. When the terminal proceeds with the call ('connect'), the data path is established (positive

264

'Start Data Path Result'). This data path can used by Message server and terminal to exchange data in a way transparent to the ISPBX;

5. The communication is then taking place, on a user-to-user basis: the Message server sends a 'Send Data' request, and the ISPBX accepts it with 'Send Data Result', which means that the path is available for the next message.

6. The terminal can respond to the message, signalling the arrival and storage of the message;

Note: This step is outside the scope of the ISPBX.

7. The Message server or the terminal can both end the call by sending a 'Stop Data Path' request for the computer, or by clearing the call for the DECT terminal.

12.8.3. Message call initiated by a terminal

Before a terminal can send a message to a Message server, its DNR must be registered by the computer application.

When the terminal which sends a message has not been registered before, the ISPBX analyses the message. If the result of the analysis shows that the message is directed to an internal number, the ISPBX sets an LRMS call to the identified DNR. If it is not an internal number, the call is cancelled. Only DECT to DECT communications are possible without previous registration of the calling party.

When the originating terminal has been registered by a computer application, the call is handled as follows:

1. A 'Start Data Path' request is sent to the ISPBX;2. When the result is positive, the system returns a connect message to the terminal,

establishing the Data path;3. The communication is enabled: terminal and computer application can exchange user-

data;4. The terminal or the Messages server can both end the call by sending a 'Stop Data Path'

request for the computer, or by clearing the call for the DECT terminal.

12.8.4. Interaction with other facilities

Diversion facilities are ignored when using the CSTA I/O function.

Interaction with the Desksharing facility:

• When a desksharing-DNR is activated or deactivated, a possible I/O registration for the DNR is aborted. It is necessary to register again in order to be able to use CSTA I/O services.

265

• The 'Called Line Identity' of a message is part of the message. It is therefore assumed that the terminal knows this identification. Nonetheless, when a desksharing-DNR is activated at the terminal, the actual DNR of the terminal differs from the identity stored in the terminal.

12.8.5. Input/Output services

• RegisterThis service registers the computing function as an I/O server for a specified device and for a specified application type. The CSTA Licence I/O and I/O Registration licenses are checked when registering.

• Register AbortThis service is used by the ISPBX to cancel an active I/O registration.

Note: Deleting a DNR or moving it to another unit results in an I/O Register Abort.Moving the DNR within the same unit does not result in an I/O Register Abort.Loss of inter-unit communication or network degradation may result in an I/O Register Abort.

• Register CancelThis service is used to cancel previous I/O registrations.

• Send DataThis service writes data to a specified data path.

• Start Data PathThis service starts a bi-directional (From the EDP or from one of the PBX's device) Data Path on the specified object.Pre-conditions:- Before a device can start a data path, the EDP has to request an I/O Registration first.

A 'Start data path' request from a device whose registration has become unlicensed is not possible. Such a request generates an alarm.

- When a Start Data Path is requested by the ISPBX for a terminal (device) then the 'Called number' is not sent to the computer application with the 'Start Data Path'

266

service. This information is exchanged as user-data with 'Send Data' service.

Note: Possible causes of failure of the service when received by the PBX:

- The DNR does not exist, or is a group DNR (Start Data path requests to group-DNRs are rejected).

- There is no CSTA I/O Services licence available.

- The related terminal does not support LRMS.

Note: When a 'Start data path' is requested by the ISPBX and the EDP does not respond within CSTA command guarding time, the ISPBX handles the timer expiry as a negative acknowledgment: a related message-call from a terminal is cleared.

• Stop Data PathThis service terminates an existing Data Path.

12.8.6. Call Related Messaging Service

On top of the functionality described in the previous subsections, Call related messaging services are possible.

• CSTA server dialled serviceIt is possible to request a message server to send a call related text message towards another terminal by dialling the CSTA server dialled prefix (res-id 145). This service can be used by all type of terminals. OM command CHCSDD is used to define the "CSTA server dialled" prefix.Before a terminal can send a message to a computer application, the DNR should be registered first by the computer application. At an "I/O Register" request from a computer application the ISPBX unit, to which the computer is connected, checks availability of the "CSTA I/O service licence" and checks if there is a "I/O registration" licence left.After dialling the "CSTA server dialled" prefix the user will, dependent of the projecting, hear password dial tone, when password digits are required or internal dial tone when additional digit information is required. When the terminal has given all digit information required for the requested action of the server a check is done whether the DNR of the originating terminal has been registered by a computer application. If so a Data Path will be started to that computer application with use of Start Data Path. At receipt of a positive acknowledgement of Start Data Path, a connect-message is sent to the terminal, establishing the data path.The following possibilities exist:- Call related text messaging services : A device, able to send call related user to user

267

messages, e.g. the TMP ErgoLine, can request a message server to send a (urgent) message to another device or other devices, after it has been 'registered' by the computing function.

- ACD Services :- Report changes within the state of ACD agents (e.g. logon, logoff, ready, not ready) from the telephone set of the agent or the supervisor towards the ACD-MIS.- Report changes within the state of ACD group (e.g. day, night) from the telephone set of the agent towards the ACD-MIS.- Report additional information about transactions towards the ACD-MIS.- Request from agent for consultation of supervisor to ACD-MIS.

• Call related text messaging towards devicesThe computing function, e.g. a message server, can send a call related text message to a terminal able to receive call related user to user messages (i.e. TMP ErgoLine, ETSI terminals, DECT portables), indicated by its connection id.The computer application sets up a call between party A and party B with use of standard CSTA switching services (i.e. make call or make predictive call). Party A can be a dummy party or an IAS-A circuit announcing some speech message like "message available in display". Party B is the terminal to which the text message must be sent. Only Party A has to be monitored by the application. It is also possible that the connection was already established.

1. When the connection is established the computer application sends a "Fast Data" request with connection-id of the party A terminal and data "PathDirectionFromRequest" to the ISPBX.

2. The ISPBX checks availability of the "CSTA I/O services" licence.3. The ISPBX interprets the connection-id and sends a user-to-user message towards party

B and a positive "Fast Data Result" towards the application without waiting for the ack of Party B.

4. The user-to-user ack message from party B is absorbed in the CSTA-FH. Either the computer application or terminal may stop by clearing the call.

12.9. TWINNING ON CSTA

Since Call@Net 3.3 twinning is fully supported on CSTA monitored extensions. Both the twinning originator and/or the twinning destination can be monitored by means of a CTI Application.

Twinning in combination with CSTA has the same functionality as the existed twinning facility, extended with some specific CSTA functionalities:

- When the twinning originator answers the call (to the twinning originator) the twinning destination stops with alerting and is cleared with the CSTA cleared information

268

"CallPickup".- When the twinning destination answers the call (to the twinning originator) the twinning

originator stops with alerting and is cleared with the CSTA diverted information "CallForwardNoAnswer".

- When party B in the CSTA command "make call (A,B)" or "make predictive call (A,B)" has twinning relation then twinning is also executed.

- When a call is made to the twinning originator, both twinning originator and twinning destination are alerting, the CSTA command "deflect call" can only be executed on the twinning originator, in this case the call to twinning originator is diverted to the new destination and the twinned call to destination is cleared.

- When a call is made to the twinning originator, both twinning originator and twinning destination are alerting, the CSTA command "answer call" can be executed on the twinning originator or the twinning destination.

- When a call is made to the twinning originator, both twinning originator and twinning destination are alerting, if the CSTA command "clear call" or "clear connection" is executed on the twinning destination then the twinning destination is cleared and the twinning originator remains alerting.

- When a call is made to the twinning originator, both twinning originator and twinning destination are alerting, if the CSTA command "clear call" or "clear connection" is executed on the twinning originator then both twinning originator and the twinning destination are cleared.

Figure 12-12 Twinning on CSTA

System option LOSYSOP160 'Twinning in combination with CSTA allowed' is introduced to allow this new functionality.

When this option is "FALSE" (default value), twinning is not executed if the twinning originator (extension B1) and/or the twinning destination (extension B2) is a monitored number.

269

When this option is "TRUE", twinning is fully supported on monitored numbers. Extension B1 and/or B2 can be monitored and support the full CSTA functionality, for exaple Deflect Call, Answer, Make Call (A,B), etc.

Advise : If the twinning destination is an internal party; monitor both the twinning originator and the twinning destination to allow correct handling and reporting of the CTI Application. The Contact Centre CC250 Release 6.0.2 fully supports the twinning functionality. It is strongly advised not to use the twinning functionality with an earlier release of the Contact Centre CC250 !

LIMITATIONS

• Deflect Call on the twinning Destination (extension B2) is not supported, as Diversion is overruled by the twinning feature (standard twinning functionality).

• The twinning destination can be an internal or external party (e.g. a GSM phone). External parties can not be monitored by means of a CTI Application.Bypass : Use Software SMA to reach the GSM phone, as Software SMA users are handled as internal parties and thus support the full CSTA functionality.

• If extension A has a twinning relation, twinning is not executed in case of a Make Call to extension A.

12.10. MULTIPLE RING GROUP ON CSTA

Since Call@Net 3.3 all or part of the Group Members of a Multiple Ring Group can be monitored by means of a CTI Application. All (or a part of the MRG) idle present group members, even if the group and (or) group members are CSTA monitored, start alerting when the group number is called.

When any member answers the call, other members stop with alerting and are cleared with CSTA cause CallPickup.

270

Figure 12-13 Multiple Ring Group on CSTA

System option LOSYSOP161 'Multiple Ring Group in combination with CSTA allowed' is introduced (default value off) to allow this new functionality and guard existing functionality.

When this option is "FALSE" (default value) : do not monitor MRG Group Members to allow full MRG functionality (e.g. maximum number of MRG Group Members allowed).

When this option is "TRUE", MRG functionality with small limitations : all or a part of the MRG Group Members can be monitored.

LIMITATIONS

• Advised is to limit the number of monitored MRG Group Members to 5, as the collision chance increases when more MRG Group Members are monitored.

• Limited CTI/CSTA functions are support for MRG-Groups, for example Monitor and Answer are supported.

12.11. UNIQUE LINE NUMBERS FOR CSTA

Assume the following situation :

271

An external call (trunk call) comes in via DPNSS and this call ends on a CSTA monitored extension, then in the CSTA events the external party is identified with the Route Number and the Line Number of the DPNSS line. This gives the CSTA application the possibility to distinguish the calls because the route/line number is unique.

When the DPNSS line is now replaced by (i)PVN then the CSTA events contain the Route Number of the PVN route and the Line Number is always fixed to “1”. This makes it difficult for CSTA applications to distinguish the external calls via PVN.

Therefore system option LOSYSOP 091(Unique Dynamic PVN Line Number) is introduced since Call@Net 3.4. The default value of this system option is ‘FALSE’, resulting in the existing behavior as described above.

When this system option is set to ‘TRUE’ the CSTA events for external calls via PVN will contain the Route Number of the PVN route and an unique Line Number that will be generated, in the range 10 ... value of BOUNDARY 269 (max number of PVN flows). Note that this is not a physical line because PVN routes do not contain lines.

A side effect of setting system option 91 to TRUE is that the FDCR records that are generated for PVN calls now also contain the dynamically generated Line Number. When the system option is set to FALSE the FDCR records will always contain Line Number 1 for the user channel, like before the implementation of this system option (since Call@Net 3.4).

12.12. PROVIDE REASON FOR DIVERTED/FALLBACK CALL IN CSTA INTERFACE

This feature (since SIP@Net 4.1) makes it possible to provide the reason for diverted/fallback call on the CSTA interface. This CSTA event cause is only added to the CSTA delivered event for the night service calls or diverted calls. The feature "Provide reason for diverted/fallback call in CSTA interface" can be activated by setting system option LOSYSOP 175 (Send cause for CSTA incoming calls) to TRUE.

When this option is true, for CSTA events reporting an incoming call (i.e. Delivered and Queued with resp. LocConState=alerting and queued) a CSTA cause may be included in the event. The cause may be included when a call arrives on a night extension or group reporting the cause of redirection to the night extension. Also the cause maybe included when a call arrives on an extension or group after diversion has been executed (e.g. follow-me or CFNA). For a routing-group in both the Delivered and Queued event the cause will be reported if relevant. No cause will be sent for 'normal' incoming calls (i.e. no diversion or night extension redirection).

272

DIVERSION REASON CSTA EVENT CAUSE

Call Forwarding on No Answer 8 - CSTA_CALL_FORWARD_NO_ANSWER

Call Forwarding on Busy 7 - CSTA_CALL_FORWARD_BUSY

Call Forwarding on Absent Group Member

6 - CSTA_CALL_FORWARD_ALWAYS

Call Forwarding on Empty Group

Call Forwarding on Group Overflow

Call Forwarding on Group in Night Service

Call Forwarding on Not Existing DNR

Call Forw. on Out Of Order Extension

Call Forw. on Not Reachable Extension

Exec-Secr Diversion

Follow Me

Forced Absent Diversion9 - CSTA_CALL_FORWARD

Other Immediate Diversion

FALL BACK REASON CSTA EVENT CAUSE

Number Busy

7 - CSTA_CALL_FORWARD_BUSYThrough Connection Busy

Indialling Barred and Busy

Indialling Barred and Free

8 - CSTA_CALL_FORWARD_NO_ANSWERThrough Connection Ringing

DDI on No Answer

Number Unobtainable13 - CSTA_DEST_NOT_OBTAINABLE

Dialling Barred

Don't Disturb14 - CSTA_DO_NOT_DISTURB

Indialling Barred and Don't Disturb

Congestion 30 - CSTA_RESOURCES_NOT_AVAILABLE

CV Incompatible15 - CSTA_INCOMPATIBLE_DESTINATION

Service Incompatible

273

12.13. CSTA INITIATED DTMF

The post dialling facility in SIP@Net normally is initiated by an extension.Since SIP@Net 4.3 A the post dialling facility using DTMF can also be initiated by a monitored device via CSTA interface.The way to send DTMF information is the same as the existing post dialling facility. For the SIP- terminal/SIP-trunk in an iS3000-classic / TDM-server (CCS/CPU3000/CPU4000) environment the SKT and ISG are used to generate DTMF according to RFC-2833.

Furthermore SIP@Net provides the possibility for the CSTA applications to send the DTMF digits string included the "," character. The "comma" character indicates the pause place, according to ECMA specification ECMA-269).

When a pause place character is detected a pause time is started, the next digit will be sent when the pause time is expired.

Timer NETIMER 244 “Post Dialling Digit Pause Time” is introduced for the pause time.This timer can be projected : default value is 2 seconds.

Note that this function is not (yet) available on the iS3000 SIP Server platform.

12.14. BOUNDARIES, OPTIONS AND TIMERS

For detailed information on boundaries, options and timers, please refer to the Second Line Maintenance Manual.

12.14.1. Boundaries

LOBOUND 276 : Maximum number of CSTA iSLinks links per unit.This boundary defines the maximum number of CSTA EDP links (iSLinks) that can be connected to this unit. It is restricted by the licence number 17 (S0-bus link CSTA) and number 21 (Ethernet link CSTA). (See 12.15. "LICENSING").

LOBOUND 277 : Maximum number of CSTA monitored BSP-IDs.This boundary defines the maximum number of BSP-IDs in this unit that can be monitored by the CSTA EDP links connected to this or any other unit. It is restricted by license number 18 (Active CSTA monitors).

LOBOUND 278 : Maximum number of CSTA monitored global BSP-IDs.

274

In a multi-unit system the standard setting for the boundaries in various units correspond to the maximum value of the CSTA licences used for the various units.

This boundary defines the maximum number of BSP-IDs in the iS3000 iSNet Private Network which can be monitored by all the CSTA EDP links connected to this unit.The actual maximum is also restricted by licensing (12.15. "LICENSING"). The maximum value of this boundary is equal to LOBOUND 277.

LOBOUND 279 : Maximum number of CSTA calls per unit.This boundary defines the maximum number of calls in this unit involving CSTA monitored local BSPs. Note that this boundary must be set equal in all units.Note that the value of this boundary must not be higher than : (max. number of control blocks (BOUND 202) - 150) / 4.

LOBOUND 324 : Maximum number of sockets per unit.This boundary defines the total number of TCP/IP related sockets that is made available for the CPU3000. It also defines the general constraints for IP-related applications like CSTA over Ethernet. All IP-related applications within the system together never can use more sockets than is defined here. For CPU3000 platform only.

LOBOUND 325 : Maximum number of sockets per task.This system limited boundary defines the general constraints for TCP/IP-related applications. Individual pSOS tasks like e.g. the TCP/IP relay task used for Ethernet iSLink can never use more sockets than is defined here. It therefore is also a boundary on the number of logical connections that can be made over 1 physical Ethernet iSLink. For CPU3000 platform only.

LOBOUND 326 : Maximum number of local Data Path.This boundary defines the maximum number of data paths to the BSPs in that unit.

LOBOUND 327 : Maximum number of global data paths.This boundary defines the maximum number of data paths to BSPs in the multi unit network from CSTA sessions active in that unit.

LOBOUND 328 : Maximum number of local CSTA I/O registrations.This boundary defines the maximum number of BSPs in a unit that can be registered by CSTA from the own or any other unit.

LOBOUND 329 : Maximum number of global CSTA I/O registrations.This boundary defines the maximum number of BSPs that can be registered by CSTA sessions active in that unit.

275

Since Call@Net 2.9 :

- boundaries 278, 327 and 329 are obsolete.- except for the previous mentioned boundaries also the double amount of control blocks

(boundary 202), signal packets (boundary 203) and short data blocks (boundary 204) are used, when the number of CSTA resources are extended.

12.14.2. Options

12.14.3. Timers

12.14.4. Customized Settings

The standard settings assume a "balanced" system. For example, a two unit system with units U1 and U2, where EDP E1 is connected to U1 and EDP E2 is connected to U2. It is assumed that E1 will monitor as many devices in U2 as E2 in U1.

In a balanced system, LOBOUND 277 and LOBOUND 278 can be set equal.

In unbalanced situations, the settings for the boundaries depend on the specific system configuration. As an (unrealistic) example, consider the system configuration shown in the following figure.

LOSYSOP 160 : 'Twinning in combination with CSTA allowed (since Call@Net 3.3)LOSYSOP 161 : Multiple Ring Group in combination with CSTA allowed (since Call@Net

3.3)LOSYSOP 091 : Unique Dynamic PVN Line Number (since Call@Net 3.4)LOSYSOP 175 : Send cause for CSTA incoming calls (since SIP@Net 4.1)

NETIMER 199 : CSTA predictive call ringing time.This parameter defines the maximum ringing time of the destination in a predictive CSTA call with allocation state "established". Within this time the destination has to answer the call else the predictive call side will be released.

276

Figure 12-14 Unbalanced System

Suppose EDP 1 and EDP 2 start monitors on devices in Unit C only. In that case, LOBOUND 277 in Unit C shall be the sum of the values for LOBOUND 278 (corresponding with licence 18) in Unit A and Unit B (with a maximum of 300).

12.15. LICENSING

The following applies to the CSTA licenses listed below :

- the CSTA Application is a numeric license, indicating the number of sessions of that application, and

- the Application Seat is a numeric license, indicating the number of users of that appliaction.(a seat is defined as a device having one monitor, one IO-registration or both).

• CSTA PBC Application (number 34) and Application Seat (number 40)

• CSTA EP Application (number 35) and Application Seat (number 47)

• CSTA EXTERN Application (number 36) and Application Seat (number 37)

• CSTA CC210 Application (number 38) and Application Seat (number 39)

• CSTA DMS Application (DECT Messaging) (number 41) and Application Seat (number 42)

• CSTA Dialer Application (number 43) and Application Seat (number 44)Note that these two licenses are removed since Call@Net 2.10

• CSTA 3rd party TAPI Application (number 45) and Application Seat (number 46)

• CSTA Voice log Application (number 49) and Application Seat (number 50)

• CSTA CTI server Application (number 51) and Application Seat (number 52)

277

• CSTA Messenger Application (number 60) and Application Seat (number 61)

• CSTA CC200 Application (number 62) and Application Seat (number 63)Note that these two licenses are removed since Call@Net 2.10

• CSTA Desktop Application (number 64) and Application Seat (number 65)Note that these two licenses are renamed since Call@Net 2.10 (was CSTA MRS application (seat)).

Be aware of the fact that the existing CSTA link related resource licenses (listed below) are only required by vendors directly connecting to the CSTA link and not using CSTA-DLL 7.0 or one of its successors.

Only the number of application sessions and the number of devices (seats) handled by those applications are visible.

- iSLink for CSTA on S0-bus (number 17)- Active CSTA monitors (number 18)- iSLink for CSTA on Ethernet (number 21)- CSTA I/O Services (number 23)- CSTA I/O Registration (number 24)

12.16. ALARMS

There are a number of CSTA specific alarms: alarm code group 61, qualifier 63, 64, 75 and 83.

12.17. VALIDITY INFORMATION

The following table gives an overview of the various CSTA functions.

278

Table 12-1 CSTA functions

SERVICE / EVENT FOR EXTENSIONS FOR GROUPS

Switching Function Services

Alternate Call supported not applicable

Answer Call supported not applicable

Clear Call supported supported

Clear Connection supported supported

Conference Call supported not applicable

Consultation Call supported not applicable

Divert Call supported supported

Make Call supported supported

Predictive Call supported supported

Reconnect Call supported not applicable

Retrieve Call supported not applicable

Set Feature supported supported

Query Device supported supported

Transfer Call supported not applicable

Monitoring Functions

Change Monitor filter supported supported

Monitor Start supported supported

Monitor Stop supported supported

I/O Services supported not applicable

Call Event supported supported

Agent State Event supported supported

Maintenance Event supported not applicable

279

13. PRIVATE VIRTUAL ENHANCEMENTS

13.1. INTRODUCTION

Private Virtual Enhancements (PVE) is an entity within the PBX that provides iS3000 functionality as a TCP/IP service to a server called "Call@Net Application Server". This Call@Net Application Server is a PC, running the MyOffice@Net or Management@Net software.

For operational usage of the PVE functionality, LOSYSOP 121 must be set to "TRUE".

Furthermore allowance license 56 (Call@Net Application Service / iS3000 BCT sync.lic) is required.

The PVE supports the following functionality :

- monitoring;- data retrieval;- facility activation / deactivation.

This functionality is DNR based and accessible through the TCP/IP link.

The following items can be monitored :

- DNR status;- call status;- group member status;- ACD group status / statistics;- message waiting.

The following data can be retrieved :

- name;- ACD group member(s) : group configuration with respect to its members;- group DNR : of which group is this DNR a member ?- SIP@Net Mobility Access (SMA) status (can be activated / deactivated)

Consult MyOffice@Net or Management@Net for more info.

13.2. SECOND LINE OM COMMANDS

For PVE, the following Second Line OM commands are available :

280

- DIPMON : Display PVE Monitor- STSRVC : Start Relay Service- SPSRVC : Stop Relay Service- DISRVC : Display Relay Service Status

For more details, consult the Second Line Maintenance Manual.

13.3. BOUNDARIES AND OPTIONS

The following boundaries are valid for PVE :

- LOBOUND365 : PVE Listen Port- LOBOUND367 : PVE max Extension Monitors- LOBOUND368 : PVE max Group Monitors- LOBOUND369 : PVE max Data Monitors- LOBOUND370 : PVE Manager ID- LOBOUND371 : PVE Server ID

The following options are added for PVE :

- LOSYSOP121 : PVE Active- LOSYSOP123 : PVE Short XML

For more details of the boundaries and options, consult the Second Line Maintenance Manual.

13.4. Call@Net APPLICATION SERVER - SNMP ALARMING

The SNMP Alarming functionality allows the Call@Net application server to subscribe with the ISPBX for Alarm Information. The ISPBX sends the alarm information to the Call@Net application server in the following cases :

- when Call@Net application server subscribes with the ISPBX for Alarm Information.- whenever a new major, minor, silent or blocked alarm is created in the ISPBX and the

Call@Net application server has subscribed with the ISPBX for alarm information.- whenever a major, minor, silent or blocked alarm is removed or solved in the ISPBX and

the Call@Net application server has subscribed with the ISPBX for alarm information.- whenever an alarm report moves from one queue to another, among major, minor, silent

and blocked queues and the Call@Net application server has subscribed with the ISPBX for alarm information.

The alarm information consists of the number of alarms in the queues and does not give individual alarm details.

281

A . PROTOCOL FORMAT OF FDCR OVER IP

"FDCR over IP" does not differ that much from "FDCR via V.24". FDCR/IP sends the same messages as FDCR/V24 : packed, except the record number.On protocol level the following rules apply :

1. A record from the CPU consists of a <message>, which is always preceded by 3 bytes (6 nibbles) : - 2 bytes <length> in network format : [MSB,LSB]

This is the total record length without the length-bytes itself.- 1 byte <record-number>

Suppose the size of the <message> is 54 bytes,+ 1 byte for the record-number, makes 55 bytes total : 55 decimal = 37 hexThe result will be : [ 00 37 <record-number> <message> ]

2. Each record from the CPU has to be answered by the application (4 bytes) :- 2 bytes <length>- 1 byte <type> = FDCR_ACK = 0x01- 1 byte <record-number>The result will be : [ 00 02 01 <record-number> ]

3. The CPU can send a heartbeat request (3 bytes) to guard the session :- 2 bytes <length>- 1 byte <type> = HEARTBEAT_REQ = 0xFFThe result will be : [ 00 01 FF ]

4. The heartbeat request has to be answered by the application (3 bytes) :- 2 bytes <length>- 1 byte <type> = HEARTBEAT_ACK = 0x00The result will be : [ 00 01 00 ]

Keep in mind that FDCR/IP is in fact FDCR/TCP. This means that a byte stream is realised between both endpoints of the TCP-session and that (as usual with TCP) no assumptions can be made about the extent (or place) of chopping of the messages.

The protocol format depends on the output format version selected : 0, 1 or 2.

- 0 = 12 digit Costcentre/PID and 20 digit destination field.- 1 = 16 digit Costcentre/PID and 20 digit destination field.- 2 = 16 digit Costcentre/PID and 32 digit destination field.

282

A.1. FDCR OUTPUT FORMAT VERSION 0

STANDARD RECORD

<length><rnh><hdr><un><rnd><rt><date><time><Id A><Id B><Atype><Btype><ibsc><fac><as><ad><adt><rr><cd>

ITEM DESCRIPTION SIZE (nibbles)

RANGE /// EXAMPLE

<length> record length excluding length bytes (hex.)

4 0000 ... FFFF e.g. 0037

<rnh> record number (hex.) 2 00 ... FF e.g. 12<hdr> header 3 AFB (in decimal: * #) e.g. AFB<un> unit number 2 01 ... 14 e.g. 01<rnd> record number (dec.) 2 00 ... 99 e.g. 18<rt> record type 1 1 = standard record<date> date (YYMMDD) 6 YY : 00 ... 99 (year)

MM : 01 ... 12 (month)DD : 01 ... 31 (day)e.g. 090805

<time> start time (HHMM) 4 HH : 00 ... 23 (hours)MM : 00 ... 59 (minutes)e.g. 1113

<id A> party A id 32 <local id (12)><far end id (20)> e.g.3000FFFFFFFFFFFFFFFFFFFFFFFFFFFF

<id B> party B id 32 <local id (12)><far end id (20)> e.g. 3003FFFFFFFFFFFFFFFFFFFFFFFFFFFF

<Atype> party A type 1 + 1 1 ... 5 e.g. 1F1 = extension2 = operator assistance3 = PSTN/tie-line4 = DPNSS5 = paging

<Btype> party B type 1 + 1 1 ... 5 e.g. 1F1 = extension2 = operator assistance3 = PSTN/tie-line4 = DPNSS5 = paging

283

Example of Standard Record (Output Format Version 0)Given the following record :

00 37 06 af b0 10 61 09 08 05 11 13 30 00 ff ff ff ff ff ff ffff ff ff ff ff ff ff 30 03 ff ff ff ff ff ff ff ff ff ff ff ffff ff 1f 1f 14 00 00 1f 00 1f 3f 1f 00 00 03The meaning is as follows :

<ibsc> ibsc 2 00 ... 14 e.g. 14<fac> facility indicator 4 0000 ... FFFF e.g. 0000

not implemented0000 = no facilities

<as> answered status 1 + 1 0 or 1 e.g. 1F0 = not answered1 = answered

<ad> answer delay 3 + 1 000 ... 999 e.g. 009Fanswer delay (when answered) or ringing/alert time (when not answered) in seconds

<adt> answer delay type 1 + 1 0 ... 3 e.g. 3F0 = not relevant1 = party-A2 = party-B3 = both parties

<rr> record release 1 + 1 1 ... 4 e.g. 1F1 = clear2 = answer by original party3 = divert4 = transfer

<cd> call duration 6 000000 ... 999999 e.g. 000003time in seconds the call was in conversation

message length : H'37 (which means 55 bytes)record number : 06header : afbunit number : 01


RANGE /// EXAMPLE

284

ACCOUNTING RECORD

<length><rnh><hdr><un><rnd><rt><dest><pw><pb><rpi><cct><cc> <dep><mp><cd >

record number : 06record type : 1 (= standard record)date : August 5th, 2009start time : 11:13party A id : 3000party B id : 3003party A type : extensionparty B type : extensionibsc : 14facility indicator : 0000 (= no facilities)answered status : 1 (= answered)answer delay : 001 (= 1 second)answer delay type : 3 (= both parties)record release : 1 (= clear)call duration : 000003 (= 3 seconds)


RANGE /// EXAMPLE

<length> record length excluding length bytes

4 0000 ... FFFF e.g. 0021

<rnh> record number (hex.) 2 00 ... FF e.g. 13<hdr> header 3 AFB (in decimal: * #) e.g. AFB<un> unit number 2 01 ... 14 e.g. 01<rnd> record number (dec.) 2 00 ... 99 e.g. 19<rt> record type 1 2 = accounting record<dest> destination 20 max. 20 digits of dialled external number

e.g. 003135891052FFFFFFFF<pw> password indication 1 + 1 0 ... 2 e.g. 0F

0 = normal outgoing call1 = password call2 = call back call

285

<pb> private/business indication

1 + 1 0 or 1 e.g. 0F0 = business call1 = private call

<rpi> route preference indication

1 + 1 0 or 1 e.g. 0F0 = preferred route1 = non preferred route

<cct> cost centre type 1 + 1 0 ... 7 e.g. 0F0 = no cost centre (cc)1 = no validation of cc2 = modulo-validation of cc3 = table-validation of cc4 = malicious call trace req.5 = personal identification code6 = DPNSS charge reporting supplementary service7 = charging diversion initiator

<cc> cost centre 12 max. 12 digits e.g. FFFFFFFFFFFFpersonal id code ormalicious call trace request : 999999

<dep> department 3 + 1 000 ... 255 e.g. 003F<mp> metering pulses 6 000000 ... 999999 e.g. 000045

accumulated metering pulses<cd> call duration 6 000000 ... 999999 e.g. 000003

time in seconds the call was in conversation


RANGE /// EXAMPLE

286


STANDARD RECORD

<length><rnh><hdr><un><rnd><rt><date><time><Id A><Id B><Atype><Btype><ibsc><fac><as><ad><adt><rr><cd>


RANGE /// EXAMPLE


4 0000 ... FFFF e.g. 0034

<rnh> record number (hex.) 2 00 ... FF e.g. 06<hdr> header 3 AFB (in decimal: * #) e.g. AFB<un> unit number 2 01 ... 14 e.g. 01<rnd> record number (dec.) 2 00 ... 99 e.g. 06<rt> record type 1 9 = standard record<date> date (YYMMDD) 6 YY : 00 ... 99 (year)

MM : 01 ... 12 (month)DD : 01 ... 31 (day)e.g. 090805



<id B> party B id 32 <local id (12)><far end id (20)> e.g. 3003FFFFFFFFFFFFFFFFFFFFFFFFFFFF

<Atype> party A type 1 1 ... 5 e.g. 11 = extension2 = operator assistance3 = PSTN/tie-line4 = DPNSS5 = paging

<Btype> party B type 1 1 ... 5 e.g. 11 = extension2 = operator assistance3 = PSTN/tie-line4 = DPNSS5 = paging

287

ACCOUNTING RECORD

<length><rnh><hdr><un><rnd><rt><dest><pw><pb><rpi><cct><cc> <dep><mp><cd >



<as> answered status 1 0 or 1 e.g. 10 = not answered1 = answered

<ad> answer delay 3 000 ... 999 e.g. 009answer delay (when answered) or ringing/alert time (when not answered) in seconds

<adt> answer delay type 1 0 ... 3 e.g. 30 = not relevant1 = party-A2 = party-B3 = both parties

<rr> record release 1 1 ... 4 e.g. 11 = clear2 = answer by original party3 = divert4 = transfer



RANGE /// EXAMPLE


4 0000 ... FFFF e.g. 0021

<rnh> record number (hex.) 2 00 ... FF e.g. 07<hdr> header 3 AFB (in decimal: * #) e.g. AFB<un> unit number 2 01 ... 14 e.g. 01


RANGE /// EXAMPLE

288

<rnd> record number (dec.) 2 00 ... 99 e.g. 07<rt> record type 1 A = accounting record<dest> destination 20 max. 20 digits of dialled external number

e.g. 003135891052FFFFFFFF<pw> password indication 1 0 ... 2 e.g. 0



1 0 or 1 e.g. 00 = business call1 = private call


1 0 or 1 e.g. 00 = preferred route1 = non preferred route

<cct> cost centre type 1 0 ... 7 e.g. 00 = no cost centre (cc)1 = no validation of cc2 = modulo-validation of cc3 = table-validation of cc4 = malicious call trace req.5 = personal identification code6 = DPNSS charge reporting supplementary service7 = charging diversion initiator

<cc> cost centre 16 max. 16 digits e.g. FFFFFFFFFFFFFFFFpersonal id code ormalicious call trace request : 999999

<dep> department 3 000 ... 255 e.g. 003<mp> metering pulses 6 000000 ... 999999 e.g. 000045

accumulated metering pulses<cd> call duration 6 + 1 000000 ... 999999 e.g. 000003F



RANGE /// EXAMPLE

289


STANDARD RECORD

<length><rnh><hdr><un><rnd><rt><Atype><Btype><date><time><Id A> <Id B><ibsc><fac><as><ad><adt><rr><cd>


RANGE /// EXAMPLE


4 0000 ... FFFF e.g. 0034

<rnh> record number (hex.) 2 00 ... FF e.g. 12<hdr> header 3 AFB (in decimal: * #) e.g. AFB<un> unit number 2 01 ... 14 e.g. 01<rnd> record number (dec.) 2 00 ... 99 e.g. 18<rt> record type 1 B = standard record<Atype> party A type 1 1 ... 5 e.g. 1

1 = extension2 = operator assistance3 = PSTN/tie-line4 = DPNSS5 = paging

<Btype> party B type 1 1 ... 5 e.g. 31 = extension2 = operator assistance3 = PSTN/tie-line4 = DPNSS5 = paging

<date> date (YYMMDD) 6 YY : 00 ... 99 (year)MM : 01 ... 12 (month)DD : 01 ... 31 (day)e.g. 090805



<id B> party B id 32 <local id (12)><far end id (20)> e.g. 1630960FFFFF43021FFFFFFFFFFFFFFF

290

ACCOUNTING RECORD

<length><rnh><hdr><un><rnd><rt><dum><pw><pb><rpi><cct><cc> <dep><mp><cd ><dest>



<as> answered status 1 0 or 1 e.g. 10 = not answered1 = answered

<ad> answer delay 3 000 ... 999 e.g. 011answer delay (when answered) or ringing/alert time (when not answered) in seconds

<adt> answer delay type 1 0 ... 3 e.g. 30 = not relevant1 = party-A2 = party-B3 = both parties

<rr> record release 1 1 ... 4 e.g. 11 = clear2 = answer by original party3 = divert4 = transfer



RANGE /// EXAMPLE


4 0000 ... FFFF e.g. 001B

<rnh> record number (hex.) 2 00 ... FF e.g. 13<hdr> header 3 AFB (in decimal: * #) e.g. AFB<un> unit number 2 01 ... 14 e.g. 01


RANGE /// EXAMPLE

291

<rnd> record number (dec.) 2 00 ... 99 e.g. 19<rt> record type 1 C = accounting record<dum> dummy byte 2 FF<pw> password indication 1 0 ... 2 e.g. 0



1 0 or 1 e.g. 00 = business call1 = private call


1 0 or 1 e.g. 00 = preferred route1 = non preferred route

<cct> cost centre type 1 0 ... 7 e.g. 00 = no cost centre (cc)1 = no validation of cc2 = modulo-validation of cc3 = table-validation of cc4 = malicious call trace req.5 = personal identification code6 = DPNSS charge reporting supplementary service7 = charging diversion initiator

<cc> cost centre 16 max. 16 digits e.g. FFFFFFFFFFFFFFFFpersonal id code ormalicious call trace request : 999999

<dep> department 3 000 ... 255 e.g. 003<mp> metering pulses 6 000000 ... 999999 e.g. 000045

accumulated metering pulses<cd> call duration 6 000000 ... 999999 e.g. 000003


<dest> destination 32 (max) max. 32 digits of dialled external number (trailing FF bytes are absent) e.g. 43021F


RANGE /// EXAMPLE

amendments 2 preface3 1. introductionfiles.trunk.com.tw/康飛/management facility...vi table of...

Documents