Alcatel-Lucent OpenTouch Suite for Mid sized and...

Alcatel-Lucent OpenTouch Suite for Mid sized and Large Enterprises

Standard Offer

Chapter 03 System Services

April 2014 Offer - Ed.02

Ref.: ENT_MLE_015989

ENT_MLE_015989 - Ed 02_2014-10-13 Chapter 03: System Services

2/66 Alcatel-Lucent Enterprise Communication Solutions April 2014 Offer

Copyright Alcatel-Lucent Enterprise 2000-2014. All rights reserved

Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent Enterprise.

Notice:

While reasonable effort is made to ensure that the information in this document is complete and accurate at the time of printing, we cannot assume responsibility for any errors. Changes and/or corrections to the information contained in this document may be incorporated into future issues.

This document introduces the Alcatel-Lucent OpenTouch and OmniPCX Enterprise Communication Server, their products and features. All documents associated to this introduction cover most of the aspects for designing offers based on current manufacturers and business partner agreements. They include introductory explanations to position the offer in relation to client needs. References to in-depth documentation are indicated to direct you to product descriptions or product sites.

Who Should Use this Document?

As an introductory offer, this document can be used by Alcatel-Lucent Enterprise vendors, clients, partners and associates involved with the implementation of Alcatel-Lucent systems.



Table of contents

1. Architectural reliability ............................................................................................................ 6

1.1 Communication server redundancy (duplication).......................................................................... 6 1.1.1 IP rack server (Common hardware) and Appliance server ................................................................................. 6 1.1.2 Communication server changeover .................................................................................................................... 7 1.1.3 Database consistency ......................................................................................................................................... 7

1.2 Communication server survivability for OpenTouch Conversation users ........................................ 8

1.3 Secure call processing with the passive communication server ..................................................... 9

1.4 Secure call processing for Conversation users with the passive communication server ................ 10

1.5 Backup signaling for IP media gateways ..................................................................................... 12

1.6 IP Touch sets survivability .......................................................................................................... 12

1.7 Business continuity of IP Touch in case of IP failure .................................................................... 13

1.8 Business continuity for out of service Digital/Analog devices ...................................................... 13

1.9 Fallback when SIP Voice Messaging is not reachable ................................................................... 13

1.10 Dual LAN attachment ................................................................................................................. 13

1.11 Uninterruptible power supply .................................................................................................... 14

2. Time and date management .................................................................................................. 15

2.1 System time clock ...................................................................................................................... 15

2.2 NTP service on OmniPCX Enterprise components ....................................................................... 15 2.2.1 NTP services ...................................................................................................................................................... 15 2.2.2 Synchronization method .................................................................................................................................. 16 2.2.3 NTP and current Alcatel-Lucent OmniPCX Enterprise Communication Server time setting services............... 16

3. Additional IP services ............................................................................................................. 17

3.1 Fax machines ............................................................................................................................. 17

3.2 Modem and data transparency .................................................................................................. 17 3.2.1 Modem transparency ....................................................................................................................................... 17 3.2.2 Data transparency ............................................................................................................................................ 17

3.3 Framing ..................................................................................................................................... 18

3.4 Trivial File Transport Protocol (TFTP) .......................................................................................... 18

3.5 Dynamic Host Control Protocol (DHCP) server ............................................................................ 18

3.6 Automatic VLAN Assignment (AVA) ............................................................................................ 20 3.6.1 Different VLAN assignment methods ............................................................................................................... 20 3.6.2 Automatic VLAN Assignment (AVA) through 802.1 AB/ LLDP MED.................................................................. 21 3.6.3 Automatic VLAN Assignment (AVA) through DHCP .......................................................................................... 21

3.7 VoIP supervision ........................................................................................................................ 22

4. General call routing ............................................................................................................... 24

4.1 Class of Service (CoS) ................................................................................................................. 24

4.2 Routing table ............................................................................................................................. 25 4.2.1 Time and Class of Service (COS) tables ............................................................................................................. 25



4.2.2 Routing in the network ..................................................................................................................................... 26 4.2.3 Night service ..................................................................................................................................................... 26

4.3 Call restriction for alarms and emergencies ................................................................................ 26

4.4 Priority calls – Multi-Level Precedence and Pre-emption (MLPP) ................................................. 26

5. Business Telephony routing for branch offices ........................................................................ 28

6. Integrated accounting ........................................................................................................... 30

6.1 Call accounting (metering) options ............................................................................................. 30

6.2 Embedded call accounting processes .......................................................................................... 31

6.3 Configuring the application ........................................................................................................ 32

6.4 User counters view .................................................................................................................... 32

6.5 Real time records printing .......................................................................................................... 32 6.5.1 Ethernet ............................................................................................................................................................ 32 6.5.2 V24 support ...................................................................................................................................................... 32

6.6 Printing traffic analysis records (optional) .................................................................................. 34

6.7 Printing financial reports (optional) ............................................................................................ 34

7. OmniPCX RECORD Suite ......................................................................................................... 36

8. Integrated voice guide services .............................................................................................. 38

8.1 Integrated voice guides .............................................................................................................. 38

8.2 Voice Guides ............................................................................................................................. 39 8.2.1 Chained voice guides ........................................................................................................................................ 40 8.2.2 Voice messages ................................................................................................................................................. 40 8.2.3 Message examples............................................................................................................................................ 40 8.2.4 Main characteristics ......................................................................................................................................... 41 8.2.5 Customized voice messages ............................................................................................................................. 42

8.3 Internal Music-on-hold .............................................................................................................. 42

8.4 External Music-on-hold .............................................................................................................. 42 8.4.1 Distinctive features ........................................................................................................................................... 42 8.4.2 Connection ....................................................................................................................................................... 42

9. IP Telephony domains and related features ........................................................................... 43

9.1 Call Admission Control (CAC) and codec selection ....................................................................... 43

9.2 Defense mechanisms ................................................................................................................. 44

9.3 Time zone management............................................................................................................. 44

9.4 Multi-country ............................................................................................................................ 45

9.5 Calling line identification (CLI) per IP Domain ............................................................................. 46

9.6 Restriction ................................................................................................................................. 46

10. SIP and web services .......................................................................................................... 47

10.1 Marketing SIP ............................................................................................................................ 47

10.2 SIP basics ................................................................................................................................... 48



10.3 SIP and OpenTouch .................................................................................................................... 48

11. Session Initiation Protocol (SIP) networking ........................................................................ 50

11.1 Session Initiation Protocol (SIP) networking ............................................................................... 50

11.2 Alcatel-Lucent and SIP ............................................................................................................... 50 11.2.1 SIP and Alcatel-Lucent OmniPCX Enterprise Communication Server ........................................................... 50

11.3 Supported SIP standards ............................................................................................................ 50

11.4 Integration of SIP end-points in the Alcatel-Lucent OmniPCX Enterprise Communication server network ............................................................................................................................................... 51

11.4.1 Integration of SIP end-points in the PCX network ........................................................................................ 51 11.4.2 SIP end-point configuration and registration ............................................................................................... 52 11.4.3 SIP end-point deployment on a large scale .................................................................................................. 53 11.4.4 Telephony services available for SIP end-points .......................................................................................... 54 11.4.5 Basic SIP call via the PCX SIP proxy ............................................................................................................... 56 11.4.6 Media considerations for SIP within the PCX ............................................................................................... 57 11.4.7 Calls made to TDM trunks ............................................................................................................................ 58 11.4.8 Voice mail account ....................................................................................................................................... 59 11.4.9 Authentication verification .......................................................................................................................... 59 11.4.10 Keep-alive dialog .......................................................................................................................................... 59 11.4.11 SIP services offered by an integrated SIP set ............................................................................................... 60

11.5 SIP trunking ............................................................................................................................... 60 11.5.1 Public SIP trunking ........................................................................................................................................ 60 11.5.2 Domain name resolution .............................................................................................................................. 61 11.5.3 Architecture example ................................................................................................................................... 62 11.5.4 Supported telephony features ..................................................................................................................... 62

11.6 Unknown SIP sets ...................................................................................................................... 65

11.7 SIP communication operations at Communication server changeover ......................................... 65

11.8 SIP limitations ........................................................................................................................... 66



1. Architectural reliability The network requirements of each client are defined by the balance between service continuity, network needs, and cost. The resulting choice is inevitably linked to the return on investment (ROI) that can only be defined by the client.

As the system reliability and availability increase in importance, the requirements for additional hardware increase. This section describes some of the available options and features.

1.1 Communication server redundancy (duplication) The Alcatel-Lucent OmniPCX Enterprise Communication Server provides a unique and secure backup mechanism when mission critical applications require high resiliency. Communication Server redundancy (duplication) allows a switch over from one communication server to its mirrored communication server through an IP link.

In this type of configuration, two Communication Servers coexist in the same system. One server is active, and is the primary Communication Server. The other server is constantly in a standby watchdog mode. If the primary server fails, the standby automatically takes over.

Note: To avoid possible communication server performance distortion, the CPU hardware must be identical for both the main and standby communication servers.

1.1.1 IP rack server (Common hardware) and Appliance server

During normal operation, a polling dialog is established and maintained between the main and standby communication servers. Interruption of this dialog indicates to the standby machine that the main communication server not available. The standby communication server then takes over as the main communication server.

Primary and secondary Communications Servers can be located in two geographical sites and can be in different IP sub networks thanks to dual IP addresses.

All the following applications are able to address the dual IP addresses:

Network Management Center OmniVista 8770



Voice mail applications

Alcatel-Lucent OmniTouch Contact Center - Standard Edition solution except CCOutbound solution

Alcatel-Lucent OmniTouch – IVR (CC-IVR)

XML Web Services (My Phone WS, My Messaging WS, My Management WS, My Assistant WS, IP Touch XML Services)

Note: To avoid possible desynchronization between databases, it is recommended to secure the IP link between primary and secondary Communication Servers.

1.1.2 Communication server changeover

When the changeover takes place, active calls are maintained and calls in the process of being set up are interrupted.

The data involved in the updates includes:

Status of the different elements (including boards and terminals)

Configuration information

Accounting tickets (call detail records)

CCD data

Note: A manual change over command is also available in maintenance mode.

In case of ABC network configuration (multiple Communication Servers interconnected through ABC-F2 TDM or IP links), active networked communications are maintained when the changeover takes place.

1.1.3 Database consistency

The standby Communication Server is updated continuously and is ready to act as the primary server at any time. ALL data, including databases, applications, and communication-handling software, is run in parallel on both servers. This operation ensures a reliable, secure switch over from one server to the other.

When the standby Communication Server is unreachable, the main Communication Server stores for a limited period of time the history of MAO (administration) commands used to update is database. Two situations can occur:

If the standby Communication Server becomes operational before the expiration of the storage duration, the main Communication Server sends MAO commands to the standby Communication Server which automatically updates its database. As a result, the two databases become consistent.

If the standby Communication Server is still unreachable after the expiration of the storage duration, the main Communication Server stops storing MAO commands and deletes them. When the standby Communication Server becomes reachable, the two databases must be consistent via a database cloning operation (or master copy operation).

Automatic database synchronization is available for Communication Servers located on CS-2 boards (Common Hardware), Appliance Servers and Blade Centers. This operating mode is identical in a double main configuration.

Information handled by MAO commands are:

Agent login/logout (Alcatel-Lucent OmniTouch Contact Center - Standard Edition)

Configuration of set parameters (secret code, language, user name, keys, etc.). This applies to digital and cordless sets



Set status (in or out of service)

Interphony service

Hotel/Hospital application data

Configuration of attendant parameters (and attendant groups)

Configuration of entity parameters

Configuration of Call Distribution Tables (CDT)

1.2 Communication server survivability for OpenTouch Conversation users

The Communication Server Duplication service can be deployed in an OpenTouch configuration to improve the reliability of system operations.

An Alcatel-Lucent Communication Server hosted on an Appliance Server (or a CS-2 (Common Hardware board)) is used as stand-by Communication Server. It takes over when the OpenTouch is not reachable or out of service.

Communication Server Duplication offers the same level of service in both Connection and Conversation configuration, such as:

Real-time duplication of telephony data, provided by the Communication Server hosted on the OpenTouch, including traffic observation, accounting records and Contact Center data

Note: Data relating to CCA, OmniVista 8770, Alcatel-Lucent OmniTouch Unified Communications, and OmniTouch Fax Server are not duplicated.

Detection of OpenTouch Server loss and switchover

Continuity of telephony services when a switchover occurs (e.g. established communications are maintained), except for:

o ABC communications on hybrid logical links (e.g. ABC link through IP)

o Communications with SIP devices or established via a SIP trunk group

A switchover can occur when the OpenTouch server activity is interrupted, due for example to a power failure or network problem. The dialog established between the OpenTouch server and Stand-by Communication Server is lost, and the stand-by Communication Server becomes the Main Communication Server.

The Stand-by Communication Server and OpenTouch server can be located:

In the same IP sub-network. Continuity of telephony services is ensured, when the OpenTouch server is out of service (e.g. power failure)



In different IP sub-networks (spatial redundancy). Continuity of telephony services is ensured, when the OpenTouch server is either not reachable (e.g. IP link failure) or out of service

1.3 Secure call processing with the passive communication server The Passive Communication Server (PCS) provides call handling services to a media gateway or group of media gateways if the Alcatel-Lucent OmniPCX Enterprise Communication Server is unavailable.

If the IP links to the site which hosts the Communication servers are broken or the Communication servers are out of service, call processing continues at a local level.

PCS use in SIP environment:

The PCS can rescue SIP phones and SIP trunk groups (SIP trunking), provided the SIP devices (external gateways/SIP proxies, SIP phones) can handle primary and secondary DNS server addresses (to access the main and backup Communication Servers), and a proxy server address (to



access the PCS). The Domain Name (DN) resolution is performed with DNS A (DNS SRV is not supported).

SIP registrations on the main Communication Server are not duplicated on the PCS. When the PCS becomes active (Communication Servers are down), the SIP sets must register on the PCS to be in service.

The Alcatel-Lucent OmniTouch 8450 Fax Software solution does not support backup SIP proxy.

In normal conditions:

The Communication servers control the calls within the network

The IP Phones and/or Media Gateways within a region are defined for the PCS

Automatic or manual synchronization of the region is carried out on a general or individual PCS basis

If Communication Server loss occurs:

Telephony services are restarted locally

Centralized services such as voice mail are no longer available

All standalone features defined inside active call processing are maintained by the PCS including OmniTouch Contact Centers.

CDRs (Call Detail Record) are recorded in the PCS

When the IP link to the OmniPCX Enterprise is back IN SERVICE, the PCS switches to standby mode either after a timer or at a configured time (typically the PCS is configured to switch at night to avoid telephone disruption).

When the PCS switches to standby mode:

IP phones and media gateway reboot and are under the OmniPCX Enterprise control

Accounting tickets (CDRs) are transmitted to the OmniVista 8770

The PCS is defined with the same provisioning level as the Communication Server. It can be hosted on a Common Hardware CPU, Appliance Server, or Blade Server.

Note: Because of the differences in the Database structures, IP Crystal Servers cannot be used in a PCS configuration. A PCS cannot be duplicated.

1.4 Secure call processing for Conversation users with the passive communication server

The Passive Communication Server (or PCS) is a feature of the Alcatel-Lucent OmniPCX Enterprise Communication Server. It offers a SIP survivability level of service for OpenTouch™ Conversation users.

In an OpenTouch configuration, the PCS provides the continuity of telephony services and the Contact Center in case of:

Loss of the OpenTouch host:

o If the Communication Server Duplication service is not used, the PCS secures call handling when it is deployed on the main site for all Media Gateways

o Additional PCSs can be deployed per Branch Offices (in other words per Media Gateway)



Breakdown of IP network links:

o WAN/LAN out of service

o IP links lost between central site and Media Gateways

If the OpenTouch server crashes (configuration without Communication Server duplication), a phone reset takes place. After this reset, only telephony and the Contact Center CCD/CCS remain operational.

The CCA, CC-IVR, OmniVista 8770 Server, Alcatel-Lucent OmniTouch Unified Communications, XML Web Services, and OmniTouch Fax Server are no longer available.

The telephony service remains operational for a period of thirty days. It is recommended to repair the OpenTouch server as soon as possible.

Note: Other PCSs can be deployed in Branch Offices (typical OmniPCX Enterprise deployment).



1.5 Backup signaling for IP media gateways Note 1: This feature is only available for Connection Users.

If the IP link between the communication server and a common hardware IP media gateway is lost, a backup signaling link is used to re-establish the signaling path over the PSTN. This service is designed to ensure continued telephone service at remote sites.

During the backup connection, users can make and receive calls over the local PSTN network connection (see the next section for more details), and VoIP calls between the remote and all the other sites can be redirected via the public network.

The communication server monitors the links to each media gateway using a polling dialog. An interruption of this dialog informs the communication server that a failure has occurred. The communication server then attempts to reach the remote media gateway over the PSTN (via GD internal modems). During this time, the remote media gateway restarts.

Return to normal

In backup mode, the media gateway periodically polls the IP network.

When the IP network connection is re-established, the media gateway switches the communication server signaling back to the normal link.

All calls are maintained while normal IP network signaling is re-established.

In addition, when the IP network is unavailable, voice inter-site communications can be established via the public network. Dialed internal numbers are translated automatically into public numbers.

This mechanism can also be used when the Call Admission Control of the remote site is reached.

Note 2:

Because a minimum of telephone services are offered for inter-site communications, it is not recommended to use this “private to public overflow” permanently.

Within the Alcatel-Lucent OmniPCX Enterprise Communication Server architecture, it is possible to mix both features, PCS and "Backup Signaling Link of Media Gateways", if they do not back up the same sites.

1.6 IP Touch sets survivability Dynamic IP address allocation of IP Touch sets (Alcatel-Lucent 8 Series sets), located in remote sites, can be done with a central DHCP server. During its first initialization, the IP Phone stores all the IP addresses (its address, TFTP server address, default gateway address, and subnet mask address) given by the DHCP Server. When an IP Phone cannot reach a DHCP server (for example, IP WAN network outage), the IP Phone initialization is still possible and it can establish its telephony signaling link with the Communication Server via the media gateway and the backup signaling link on PSTN.

The signaling link between a remote IP Touch and the Communication Server is direct. This means that, even if the remote Media Gateway is out of order, the IP Touch can communicate with other devices.

Note: Static IP addressing from the IP phone is always available. This feature is compatible with the IP Touch Security feature providing encryption and firmware integrity.

When there is no PCS and no backup signaling link, SIP survivability may apply to Alcatel-Lucent 8 series phone Extended Edition. When the Communication Server is not reachable via the IP network, the set operates as a SIP set via the SIP proxy.

Calls are established by the SIP proxy server through the PSTN.



Rescued phones must be situated in domains where there is a router implementing SIP proxy features. They must have been initialized in the Alcatel-Lucent proprietary mode at least once and sent SIP binaries and parameters to the Communication Server.

1.7 Business continuity of IP Touch in case of IP failure IP Touch can maintain an active communication even when the connection with the Communication Server fails. The communication is maintained until either the user or the remote party puts the phone down.

When the Communication Server is lost, the phone is frozen, except for the audio management: the user can still put the loudspeaker on, mute/un-mute the conversation, or switch voice channels (handset, hands-free, headset). In addition, an error message is displayed on the phone screen.

After call completion (hanging-up of called or calling party), the IP Touch restarts and registers automatically to: either a PCS (in NOE mode), or an AudioCodes SIP survival gateway (in SIP or SIP TLS mode).

1.8 Business continuity for out of service Digital/Analog devices To avoid losing communication, an automatic immediate call forwarding to a call forwarding number or associated call overflow number is offered when the digital or analog caller devices is out of service.

1.9 Fallback when SIP Voice Messaging is not reachable To avoid losing communication, the calling device rings when it is forwarded (any kind of call forwarding) to an out of order or unreachable SIP Voicemail (e.g. OT Messaging).

1.10 Dual LAN attachment The servers, hosting Alcatel-Lucent OmniPCX Enterprise Communication Server or OpenTouch™ packages, provide two Ethernet ports to prevent network related problems. If one of these two ports fails, traffic is automatically routed to the second port so that there is no service interruption.

Only one Ethernet port is active at a given time. Dual Ethernet does not support:

Load balancing

Split of data stream per application

Dual Ethernet is not compatible with encryption. When encryption is used, one Ethernet port is connected to the encryption device. The other Ethernet port is not used.



1.11 Uninterruptible power supply

An external UPS provides a battery backed up supply to keep equipment operating when there is a power cut and effective protection against damaging surges.

UPSs are designed for USB compatibility and include power management software.

As a battery pack, an external UPS may be used to provide power redundancy. In case of a prolonged power failure, the external UPS sends an alarm to the OpenTouch server, which initiates a shutdown of the different Virtual Machines and then the host, correctly.

This provides sufficient time to stop the system properly without risking any loss of data.

Note: Only the UPS recommended by Alcatel-Lucent for the OmniPCX Enterprise are supported.



2. Time and date management Most applications need to retrieve or record reliable time information: the messaging application must provide date-related data for all types of messages.

For company critical applications such as call centers, messaging systems, or accounting systems, access to time-sensitive information from a reliable or universal time source is mandatory.

Most company applications, whether related to voice or not, must share timer information provided by a reliable time source.

Today, the various application components of an information system are usually synchronized on an independent time source:

The system clock of the server hosting the application provides the time used by the application.

The communication server is synchronized according to the operating time source (when available) or PBX internal clock.

Alcatel-Lucent OmniPCX Enterprise Communication Server system administration determines the date and time used by any feature requesting such data. An internal clock is configured and can be updated via ISDN or NTP.

Inasmuch as a customer may need different time zones for the same system, different time zones can be configured according to IP domains (see: module Topology - Distributed Architecture with Centralized Call Control - Multi-Time Zone).

2.1 System time clock The OpenTouch™ server hosts a Network Time Protocol (NTP) server. This server synchronizes system time with a specified external clock.

Each Virtual machine is automatically configured by the installation wizard to synchronize with the host's NTP server.

2.2 NTP service on OmniPCX Enterprise components Time sources can slowly shift and eventually present substantial differences. This leads to inconsistency when gathering information extracted from various related applications.

The NTP protocol was designed to address this issue and provide reliable timing information for synchronizing a large set of clients over the Internet.

The Alcatel-Lucent OmniPCX Enterprise Communication Server, as an open platform for voice applications, supports NTP protocol.

2.2.1 NTP services

An Alcatel-Lucent OmniPCX Enterprise Communication Server node can be an NTP client, which allows it to obtain time information from one or many NTP server(s).

NTP implementation on Alcatel-Lucent OmniPCX Enterprise Communication Server is based on NTP distribution v4 and is compatible with NTP v2 and NTP v3 implementation.

The supported services are:

Activation/deactivation of NTP daemon

Display of the NTP server chain, in order to know the primary time source

Creation/deletion/addition of an NTP server

Broadcast server mode



Authentication mode

The authentication mode supported on Alcatel-Lucent OmniPCX Enterprise Communication Server is based on the private key method (also known as symmetric key method). Both server and client must own the same keys. These keys must be included in a file protected against unauthorized access.

2.2.2 Synchronization method

As soon as the NTP daemon is activated, information is exchanged between the Alcatel-Lucent OmniPCX Enterprise Communication Server node and the NTP server, which permits an estimation of time differences between the server and the Alcatel-Lucent OmniPCX Enterprise Communication Server node to be made. If the time difference is greater than 128 ms, the Alcatel-Lucent OmniPCX Enterprise Communication Server internal clock is adjusted to the server time.

When running, the NTP Daemon rejects packets with a time difference greater than 128ms. If the time difference remains greater than 128 ms for over 900 seconds, the server time is adjusted.

Approximately 2,000 seconds are required to solve a one-second time difference between the server and the Alcatel-Lucent OmniPCX Enterprise Communication Server node.

2.2.3 NTP and current Alcatel-Lucent OmniPCX Enterprise Communication Server time setting services

Date and time setting on the Alcatel-Lucent OmniPCX Enterprise Communication Server can be executed via:

System commands

The attendant console

The information provided on T2 ISDN access (when this service is provided by the public operator)

When time/date modifications are made, the system clock is updated (step adjustment). The date and time is updated on the extension display.

When the NTP service is activated, the other time setting services become obsolete.

Restriction

NTP “Broadcast” service is not supported (restriction on NTP 4.1.1 current distribution).



3. Additional IP services

3.1 Fax machines Alcatel-Lucent OmniPCX Enterprise Communication Server is compliant in SIP and H.323 with ITU-T.38 D Annex recommendations.

Fax relay converts Group 3 fax protocol (T.30 and T.4 standards) into Fax over IP protocol.

External fax calls to (or from) H.323 or SIP terminals use the standard T.38 protocol over the IP trunk

Fax calls between IP Media Gateways (whether in the same node or not) are performed using the standard T.38 protocol

Types of FAX that are supported are Group 3, Super Group 3 (V34 FAX).

Modulations Supported and bit rates supported:

V27: 2400 bits/s – 4800 bits/s

V29: 7200 bits/s – 9600 bits/s (TBC for Common hardware)

3.2 Modem and data transparency

3.2.1 Modem transparency

Modem transparency service allows the support of legacy modem transmission over a LAN through an IP media gateway.

Constraints:

Packet loss rate on the IP network should be 0%

Transmission delay should not be greater than 10ms (round trip delay).

Note: Such constraints on the IP network should be found on a “perfect switched LAN network” and may not be currently available on a wide area network (WAN).

Modems must be compatible with the V92 standard

Calling modem and called party (modems or trunk) must belong to the same node (local service)

Fax transmissions must be sent transparently

Voice communications are in G711 mode within the IP domain where modem transparency is activated

3.2.2 Data transparency

Data transparency allows support of video transmission across the IP network over the S0 interface.



The constraints on the LAN are the same as for modem transparency

Data transparency is available for video transmission, both in local and network context

3.3 Framing Framing is the transmission period of voice packets in the IP network. The framing used can be chosen to optimize the voice quality and bandwidth used. Possible values are shown in the table below.

Algorithm Voice rate (KBPS) Framing (ms) Bandwidth at IP level (KBPS)

G711 64 10 96

20 80

30 74.6

G729A 8 10 40

20 24

30 18.6

40 16

G723 6.3 30 17

3.4 Trivial File Transport Protocol (TFTP) Alcatel-Lucent has implemented specific system mechanisms to simplify management and maintenance of its solutions. The Trivial File Transport Protocol (TFTP) standard automatically downloads software files to the IP Touch phones and IP media gateways. This facilitates software upgrades and changes.

The TFTP Server function downloads a configuration file (lanpbx.cfg) and the IP device software (IP phones and boards) into flash memory in a binary file format. At each device start (e.g., when phones are added to the installation), the local processor automatically updates with the latest software version, when required.

3.5 Dynamic Host Control Protocol (DHCP) server The integrated Dynamic Host Control Protocol (DHCP) Server automatically assigns the necessary IP parameters when the IP telephone is installed without requiring system administrator involvement. The IP telephone receives the network sub-mask and router default IP addresses from the DHCP Server. The DHCP Server also supplies the TFTP address, which allows the IP Touch telephone to receive the downloaded software file.

The DHCP server also provides the media gateways and other IP devices connected to the network with similar IP parameters. The communication server’s PC DHCP server is intended for small sites where physical integration is a benefit. It is not intended for large enterprises where one or more external DHCP servers may already be implemented.

The customer can use an existing standard DHCP server or IP Touch telephones can be programmed with the IP parameters, when not in use.

DHCP requests:



The DHCP server can be hosted on:

An existing PC server

The communication server (embedded DHCP server)

The TFTP server used to download the configuration file (lanpbx.cfg) can be hosted on an external server. However, the TFTP server embedded in the communication server is commonly used. This entails that, in a duplicated configuration in dual IP subnetworks configuration, there are two different possible IP addresses for the TFTP server.

The DHCP server embedded in the communication server is designed to deal with this situation: only the main communication server answers to DHCP requests and it sends its own main IP address as TFTP server IP address.

If an external DHCP server is used, there are two solutions to deal with duplicated configurations in dual IP subnetworks:

An external TFTP is used to download the configuration file.

Two TFTP addresses are configured on the DHCP server. This second solution is supported by Alcatel-Lucent IP Touch 8 series phone sets. The two TFTP IP addresses must be configured in DHCP option 43 (already used for AVA).

If a DHCP server supports several IP subnets, each subnet must be equipped with a DHCP relay server to transfer requests to the DHCP server.



3.6 Automatic VLAN Assignment (AVA) Reorganization is common practice in larger companies. Employees in large enterprises often move from one geographical location to another due to organizational changes.

In addition to furniture and PC desktop relocation for each move, each telephone set must also be moved. This requires TDM PBX reconfiguration, and incurs costly expenses. Multiplied by thousands of moves per year, moving telephones has become a significant responsibility for telecom managers in large enterprises.

IP phones can be moved from one location to another without requiring special expertise because IP phones are plug-and-play.

However, local area networks have become largely segmented using VLANs (virtual LANs). Changing VLAN (or an IP subnetwork) requires reconfiguring the IP address. Using a DHCP server can easily solve this.

For security and traffic reasons, it is normally recommended that IP phones and PCs be placed in different VLANs. Therefore, major LAN switch vendors require that the IP phones use 802.1Q VLAN tagging to indicate to the switch in which voice VLAN the phone is located. The voice VLAN often depends on the geographical location where the IP phone is connected. When the IP phone is moved, the voice VLAN may change. Manually introducing the new voice VLAN location is not the ideal solution.

Some vendors have opted for IP phones locating the new voice VLAN from the LAN switch, using proprietary location protocols. This is not a standard implementation, and may lead to being tied to one vendor.

Note: In the Alcatel-Lucent networking infrastructure, the switch identifies that the device is an IP phone (through the MAC address, for example) and transparently places it in the correct VLAN without requiring action from the IP phone.

Automatic VLAN Assignment (AVA), based on standard procedures, enables IP phones to locate their voice VLAN ID on the network. With AVA, Alcatel-Lucent OmniPCX Enterprise Communication Server IP telephones can run on any vendor’s networking infrastructure.

3.6.1 Different VLAN assignment methods

Automatic VLAN assignment

To simplify the VLAN management, Alcatel-Lucent has implemented a mechanism to affect automatically the voice VLAN to IP Phones: Automatic VLAN Assignment. This mechanism is based on double DHCP request

Dynamic VLAN

Most IP terminals support 802.1q tagging, meaning that all traffic originating from the IP phone is tagged with and 802.1q header allowing voice traffic to be separated from other traffic types and placed into dedicated and isolated IP broadcast domains. Many Ethernet switches can identify traffic with MAC addresses or other unique characteristics. Alcatel-Lucent IP phones can be identified by their MAC mask (00:80:9F:xx:xx:xx) and automatically isolated from other LAN traffic.

VLAN tagging on IP Touch

If the Switch cannot use Dynamic VLAN, the IP phone must explicitly tag and use IEEE 802.1q (DHCP, TFTP, signaling and voice are tagged). The explicit tag is managed from the IP Phone.

The VLAN number can be assigned to Alcatel-Lucent 8/9 series sets in three different ways:

Statically on the set

Dynamically through 802.1 AB/ LLDP MED

Dynamically through DHCP



If different values are received or configured on the set, the following priority rules apply.

If the set initializes in dynamic mode, the following priority rules applies:

1 AVA through LLDP

2 AVA through DHCP

3 VLAN configured statically on the set

If the set initializes in static mode, the following priority rule applies:

1 VLAN configured statically on the set

2 AVA through LLDP

3.6.2 Automatic VLAN Assignment (AVA) through 802.1 AB/ LLDP MED

AVA through 802.1 AB/ LLDP MED can assign the VLAN number as soon as the Alcatel-Lucent 8/9 series set connects to the switch, before IP initialization.

AVA through LLDP is available whether the set initializes in static or dynamic mode.

If needed (for example due to compatibility issues with the switch), AVA through LLDP can be deactivated on the set.

AVA through LLDP is not available for the PC connected on the VLAN port of the set.

3.6.3 Automatic VLAN Assignment (AVA) through DHCP

The DHCP protocol allows to receive both voice VLAN ID and IP configuration (AVA uses the “vendor specific information” DHCP option 43).

Therefore, AVA can be supported on the OmniPCX Enterprise embedded DHCP server but also on any external DHCP server.

The AVA process is as follows:

When the IP phone is connected, it requests a VLAN ID through a DHCP request.

The DHCP server responds to the IP phone DHCP request. Based on the value of the "data" VLAN ID received (ipaddr field completed by the virtual router), the DHCP server sends the IP phone the "voice" VLAN ID associated with the "data" VLAN ID received.

o With an Alcatel-Lucent OmniPCX Enterprise Communication Server DHCP server, the IP address sent is identical for all VLAN ID requests. This address is configured specifically for this purpose in sub network parameters

o With an external DHCP server, the IP address sent is one of the addresses available in the configured range

The IP phone sends another DHCP request to complete IP configuration (this request is tagged, the VLAN ID received previously is used).



3.6.3.1 Prerequisites

AVA compatibility

AVA is compatible with switches supporting untagged and 802.1Q tagged frames on the same port and with routers supporting DHCP relay.

Network design restrictions

When non Alcatel-Lucent switches are used, there must be at least one source IP network per assigned voice VLAN. The VLAN request (using DHCP frames) comes from an IP sub network and only one VLAN can be configured and assigned per IP range.

DHCP compatibility

Alcatel-Lucent has validated some of the most common DHCP servers on the market, such as: WIN 2003, ISC DHCP server, used by all the UNIX/LINUX DHCP servers, and the Alcatel-Lucent Vital QIP DHCP server.

3.7 VoIP supervision VoIP management is integrated into Alcatel-Lucent OmniPCX Enterprise Communication Server management allowing configuration, alarms, accounting, and performance management.



It is important to regularly monitor the data network to prevent or troubleshoot VoIP quality problems. Such monitoring may be performed using external tools (sniffers, etc.). However, the Alcatel-Lucent OmniPCX Enterprise Communication Server has embedded mechanisms that generate VoIP tickets (CDR: Call Detail Record) to measure the voice quality of each call. These tickets contain IP network performance indicators, and concern the transport of time-sensitive RTP packets (packet loss – including consecutive loss of several packets, delay, jitter, etc.).

They are delivered in real-time and can be sent to an external machine for further supervision quality. See the AAPP program for more information.

Note: See the document on the OmniVista 8770 management platform for more information



4. General call routing The Alcatel-Lucent OmniPCX Enterprise Communication Server uses advanced routing algorithms to distribute incoming calls according to the varying needs of a standalone or network configuration. Call distribution is based on entity and routing tables and is ideally suited to direct inward dialing (DID) call distribution.

The general call distribution algorithm is described in the following diagram:

Incoming DID calls

Incoming DID (direct inward dialed) calls can be routed to one of the following entities: a directory number representing an attendant group, an attendant station (may or may not belong to the same group), a logical entity, a designated phone, or a hunting group. A time-based routing table is associated with the attendant group or station and with the entity. This enables call management according to vector user availability. If a phone/hunting group is not answered or is busy, the call is overflowed to a logical entity.

Incoming NDID calls

NDID (non-direct inward dialed) calls can be routed to a trunk or to a trunk group associated with a directory number representing an attendant group, an attendant station (may or may not belong to the same group), a logical entity, a designated set, or a hunting group. A trunk group may be also routed directly to a logical entity.

4.1 Class of Service (CoS) All attendant groups, devices, and entities are assigned a traffic routing class of service (COS) category. Different call flow management scenarios and priorities may be defined based on the class of traffic routing COS. The various traffic routing classes of services are:

Attendant group class of traffic

o Attendant group directory number

o Non-dialing trunks (public/private) group callback

o Attendant group transfer

Individual attendant traffic COS



o Attendant directory number

o Non-dialing trunks (public/private)

o Chained calls

o Charging callbacks

o Busy phone on-hook for transfer with announcement

o Attendant callback

o Attendant transfer

o Trunk callback on mishandling

Entity traffic COS

o Entity call (internal/DID)

o Non-dialing trunk groups/trunks (public/private)

o General attendant call

o Entity callback

o Unanswered DID call

o Wrong DID number (entity 0)

o Trunk callback on mishandling

4.2 Routing table In the following table, the four horizontal entries (Day, Fwd1, Fwd2, and Night) define the routing vector destination according to the system status. Vertical entries from top to bottom (Group 1-3, Attendant 4-5, Night phone 1) indicate the available vector destinations resulting from call overflow (busy/no answer, attendant out-of-service). The lowest vertical entry field (Night set 1) is the final possible vector destination. If previous routing attempts fail, this is how the call is routed.

4.2.1 Time and Class of Service (COS) tables

Each routing table is associated with a time and a class of service (COS) table. The routing tables are:

A weekly table enabling the system status to be changed automatically (maximum of four changes a day) or enabling the attendant group/station to perform status changes.

A time dependent class of service table granting/restricting access to external lines. The first figures of the dialed number are either authorized or unauthorized for a specific class of service.



4.2.2 Routing in the network

A group of attendants belongs to a node. Several attendant groups can co-exist simultaneously on the network. An entity can be distributed over several nodes. The node handling the incoming trunks or trunk groups (source node) performs the routing. A status change for a network entity is automatically sent to all concerned nodes.

4.2.3 Night service

An attendant, attendant group, and entity can have either a common night service phone or their own night service anywhere in the network.

4.3 Call restriction for alarms and emergencies In the event of a crisis, some businesses and organizations find it important to be able to restrain certain employees from making outside calls. For example, during a pollution alert in a chemical plant, managers may want to prevent employees from making calls to prevent premature or incorrect news leaks. For these types of situations, Alcatel-Lucent offers call restriction features.

Call restriction features allow the gradual restriction of telephone calls between the Alcatel-Lucent OmniPCX Enterprise Communication Server and the outside world, at times of heightened sensitivity and confidentiality. Each network of OmniPCX systems maintains its own alarm level that can be increased dynamically via the physical alarm equipment, via an attendant console, or via the management interface. Only calls with an alarm class of service greater than or equal to the general alarm level can be established.

There are two types of call restriction, exclusive of each other: Ivory Tower Tap and minimize.

Ivory Tower Tap

Disconnects external calls in-progress

Blocks new outgoing external calls

Rejects incoming external calls

These actions completely isolate calls, a state referred to as: Ivory Tower Tap.

Minimize

Blocks new outgoing external calls

Minimize is a functional sub-set of Ivory Tower Tap.

The type of call restriction is determined by management at system installation.

Call restriction management

The alarm level can be managed from the:

Alarm equipment, by dialing the call restriction prefix

Attendant console

OmniVista 8770 management platform

System limits

Total number of alarm levels is 11 (0 – 10 inclusive).

Total number of call restriction classes of service: 11 (0 – 10 inclusive).

4.4 Priority calls – Multi-Level Precedence and Pre-emption (MLPP) In a crisis situation, selected calls must get through, whatever the situation (busy lines or not enough idle resources available). In such cases, the voice communication system provides two types of functionality:



Voice call priority

Seizure of resources already in use by others

These two features are part of the Multi-Level Precedence and Pre-emption (MLPP) service.

The MLPP service provides prioritized call handling service in two different ways:

Precedence involves assigning a priority to a call.

Pre-emption involves seizing resources already in use by a lower precedence call user if there is a shortage of idle resources.

Implicit and explicit priority

The priority assigned to a call is always the calling party’s priority.

By default, the implicit priority is used without any activation at the time of call setup.

Dialing the explicit priority prefix before dialing the called party’s number activates the explicit priority.

Pre-emption

Priority calls with an activation level equal to 3 pre-empt communications that are already under way (established or not) according to the rules and in the following order of preference:

Calls with activation = 0 by selecting the one with the lowest level of priority

Calls with activation = 1 or 3 by selecting the one with the lowest level of priority, if the call priority level is greater than that of this call

Pre-emption is applied in call progression and on busy telephones.

Standard compliance

The MLPP implementation is compliant with the I 253.3 CCITT standard.

Product limits

Feature available for Connection Users

Number of priority levels for each user: 16



5. Business Telephony routing for branch offices The Business Contact Standard Edition is a packaged solution offering an intelligent business call routing for branch offices, using standard telephony, upstream of a contact center. Relying on the OmniPCX Enterprise, the Business Contact Standard Edition was created for service companies organized in branches, wishing to personalize contact with their customers and offer a consistent welcome approach across their entire organization. Customers are sent straight through to their preferred advisor or routed to the next best available profile. Irrespective of where the customer call comes from, it will always reach the appropriate advisor, rather than going through a contact center or an IVR.

According to Gartner, direct contact with the right person can radically reduce abandoned calls estimated to be up to 20% and accounting for 4 million € loss per year in financial organizations.

By always connecting the customer to the appropriate advisor, irrespective of where the customer is calling from, the Business Contact application drastically reduces lost calls and improves the quality of business calls and advisor activity through call tracking. This more human contact has a positive impact and creates long-lasting customer-advisor relationships.

With the powerful Business Contact Engine, further customization is possible from Alcatel-Lucent Professional Services (upon request), to adapt to the customer organizational and business structure, job profiles, opening hours, and more. The Business Contact Standard Edition is easy and fast to deploy; it includes predefined routing strategies for fifty Business Contact users.

Key features

Business Contact Unified engine with built-in predefined strategies:

– Can be configured to adapt to job profiles

– Provides an integrated calendar for branch office opening hours management

– Is adaptable to organization structure (branch offices)

Complements the OmniPCX Enterprise business telephony services

Centralized performance is measured through call detail records

Personaladvisor busy*

Contact center

Customer

Visit Card

Direct call

Availablespecialists

Voicemail

Route to…

Attendant

Preferredassistants

routing towards a job profile

routing towards an assistant

Two choice menu or Final route (e.g. Contact Center…)

1

2

3

Branch

Office

* Busy / No answer / OOS

Customer calls his personaladvisor which responds if available.If he is unavailable, then route to

any one in the branch office according to business rules & skills

1

2

3



Existing strategies can easily be replicated on new business units or branches

High availability (optional)

Customizations to meet specific needs (optional)

Benefits

Ensures a unified welcome across a distributed business organization

Is easy to manage and use

Fits perfectly in your existing (Alcatel-Lucent) IP architectures

Improves customer satisfaction by drastically reducing lost calls

Helps to measure efficiently the performance of advisors

Prerequisites

Hardware (not included)

Quad core processor 2,0 GHz, 4 GB of RAM, 80 GB of hard disk space

Red Hat Enterprise Linux certified platform

Only 32-bit and 64-bit editions of RHEL are supported

Licenses

Red Hat Enterprise Linux R4 u8 or R6

Latest supported OmniPCX Enterprise release

Required OmniPCX Enterprise elements (not included)

– 1x RSI Routing Services Interface Server

– 1x TSAPI server

Limits and restrictions

No CTI monitoring of the Business Contact Standard Edition users: no screen pop-up or CTI integration is available in R1.0

Please refer to the Technical Datasheet posted on the Enterprise Business Portal for more details on the application prerequisites, limits and restrictions.

https://businessportal.alcatel-lucent.com/alugesdp/content?ID=Q00055168



6. Integrated accounting

6.1 Call accounting (metering) options Decreasing telecommunication costs and providing better service to customers are constant concerns for every company. This is just as true for telephone usage as for any other expense; telephone costs must be controlled and efficiency measured. The OmniVista 8770 offers a way to analyze the telecommunication costs as well as billing for the different cost centers or users, for all companies operating on one or several sites.

The telephone application generates an accounting call “record” or “ticket” for any call (whether outgoing or incoming, private or public). The accounting call record contains information on the corresponding call (duration, date, services used, number called/dialed, network topology, etc.) The integrated accounting application collects records for various processing operations to be applied according to user requirements. Processing operations are performed by:

Internal applications: for example, “Financial Reports” or “Hotel/Hospital Management.” (detailed elsewhere in this document)

External applications: for example, an accounting program, using a dedicated database (OmniVista 8770, detailed elsewhere in this document), or other remote interface.

The Alcatel-Lucent OmniPCX Office Communication Server integrated accounting application offers the following main features:

External accounting

Call Record details

Traffic analysis

Financial reporting



Application configuration enables the user to:

1 View user counters (on some types of user sets and attendant stations).

2 Produce real-time output either to a V24 port (optional) or an Ethernet connection (optional).

3 Print out traffic analysis records (optional).

4 Print out financial reports (optional).

6.2 Embedded call accounting processes To optimize, control, and manage telecommunications expenses the Alcatel-Lucent OmniPCX Enterprise Communication Server monitors and stores a call accounting log for all calls. The data is stored by a call accounting proxy function that can be accessed and processed with an external Alcatel-Lucent management application or a third party call accounting application.

The Alcatel-Lucent OmniPCX Enterprise Communication Server generates a ticket or Call Detail Record (CDR) for each call. This ticket is generated from:

Information from the network operator/carrier

A carrier cost simulation generated from:

o The number dialed

o Call duration



o The date and time of the call carrier

o Tariffs tables

Tickets (Call Detail Records) are processed by:

o Financial Report, an Alcatel-Lucent OmniPCX Enterprise Communication Server internal application

o Real-time output to a printer

o Real-time output on Ethernet, which allows an external application integrating telephone costs to be created

6.3 Configuring the application The cost of a call may be calculated either by using the number of charge units transmitted by the carrier or by the internal configuration of accounting, based on call duration and destination.

6.4 User counters view The attendant or the user (subscriber) may view the OmniPCX Enterprise Communication Server internal counters.

Three counters are assigned to each user:

Total number of charge units/cost since the last reset

Number of charge units/cost of the last call

Number of outgoing calls since the last reset

The unit used by counters for cost or charge units is configured in system management. It is the same for all sets in the installation.

The attendant can view all user counters and reset individual counters or all counters. Users with a set with a display (Alcatel 4034, 4023, 4012, and 4035) can view their own counters:

Total charge units/cost since last reset

Number of charge units/cost of the last call and date of the last reset (only on Alcatel 4034, 4023, 4035 sets)

The user accesses this feature via a prefix.

6.5 Real time records printing Records are printed out by a printer connected to the serial port of the Communication Server or output via an Ethernet connection.

A filter can be used to limit the number of records printed, according to:

Call type: incoming, outgoing, private, public, priority, data, etc.

User type: justified (charged), not charged

6.5.1 Ethernet

Selecting record output via Ethernet means that records cannot be sent or received via a V24 link.

This transmission support has a buffer capacity for 2,500 records and requires a client application which is compliant with the OmniPCX Enterprise Communication Server protocol. The transmitted records contain all available information.

6.5.2 V24 support

If the records are printed for users not charged, the following information is masked:



Justified (charged) user number

The number of the set that transferred the call to the correct user

Number dialed

User name

The record contains less data than on an Ethernet link and is printed as a text file in one of two formats:

Reduced format (1 line)

Extended format (2 lines)

The information contained in these two formats is:

Fields Extended format Reduced format

Justified (charged) user directory number X X

Justified (charged) user name X

Project number (business account code) or PIN (1) X

Call end date X

Justified (charged) cost center X X

External carrier used for the call X

Trunk group number X

Trunk node number X

Justified (charged) user node number X

Call type (voice, data) X X

Directory number of the set that transferred the call

X X

Trunk number X

Number sent/received (2) X X

Call end time X X

Call duration X X

Number of charge units or call cost X X

Project (business account) number (0 if not applicable)

X X

Call type (personal/professional) X X

Internal PCX services used during the call (3) X

Call type (incoming, outgoing, private, etc.) X X



Notes:

(1) – (2) Masking

The PIN may be masked for personal calls. The final digits of transmitted numbers may be masked. The number of digits masked may be configured according to call type: personal calls, business (project) calls, normal calls.

(3) The internal services that may be used include VPN, ISVPN, ARS, speed dialing, remote charge, text messages, etc.

6.6 Printing traffic analysis records (optional) One or more user types or specific call types may be analyzed via a real-time printout of records for the concerned calls. Printout is via a printer connected to the V24 port of the PCX. Filtering may be configured and modified by the attendant or via system management. Filtering is performed according to the following criteria:

By user (10 users maximum)

By number of charge units or cost threshold

By duration threshold

By trunk group (2 maximum)

By dialing (prefix or number transmitted) (10 maximum)

By cost center (2 maximum)

By project (business account) number (10 maximum)

The above criteria may be combined to refine analysis.

At the end of the call, the record data is sent to the printer. Records are identical to those output in real time on a V24 port. The user may select one of two formats, reduced or extended.

Storage buffer

If the output support is not available, messages are stored in a buffer with a maximum capacity of 500 messages. When this capacity is exceeded, the OmniPCX Enterprise generates an incident report; subsequent messages are lost .

6.7 Printing financial reports (optional) Financial reports use the accounting records contained in the SQL database on the OmniPCX hard drive to provide cost distribution for a specified period by:

User

Cost center

Trunk and trunk group

Project (Business account) number

Only calls with a non-zero number of charge units are considered in the financial report.

Output on a V24 port of the OmniPCX is automatically triggered at the end of the selected period of analysis. The period of analysis may be configured on the attendant station or in system management.

Generating a financial report deletes data stored previously in the database (used only to print these reports).

Records used by external accounting applications are maintained.

This feature cannot be used in an OmniPCX Enterprise Hospitality configuration.



A time period is determined by configuring a start and end date. The time period that follows is automatically determined by the previous period. If the date is the same, the number of months between the two dates is used to calculate the new time period. Otherwise, the number of days in the previous period is used to determine the dates for the new period.

Current period New period

01/01/2014-02/01/2014 02/01/2014-03/01/2015

01/01/2014-01/10/2014 01/10/2014-01/19/2014

Financial reports are divided into four sections:

1. User counters

For each user, the counters are:

Number of calls

Total call cost

Cost per area (five areas may be specified in system management, each representing one or more public translator areas)

Personal call costs

Note: If the records of users not charged are saved in the database to generate financial reports, the number of the justified (charged) users is masked when the report is saved or printed.

2. Trunk counters

For each trunk, the counters are:

Number of calls

Total call cost

Total cost per trunk group

3. Project (business account) counters

For each project (business account) number, the counters are:

Number of calls

Total call cost

Total call duration

4. Global counters

For the entire installation (system):

Number of calls

Total cost

Cost for area 1

Cost for area 2

Cost for area 3

Cost for area 4

Cost for area 5

Personal call costs



7. OmniPCX RECORD Suite The Alcatel-Lucent OmniPCX RECORD Suite offers small and medium-sized businesses a complete tracking solution for customer interactions through unique call recording, screen capture and coaching capabilities. Flexible, simple to install and user-friendly, it seamlessly integrates into both new and existing OpenTouch™ Server environments.

Key features

Modular offer

– RECORD: rich recording facilities of inbound and outbound calls in multiple audio formats (MP3, GSM6.10, WAV)

– SCREEN CAPTURE: complete user desktop activity capture

– SILENT MONITOR: remote and discrete monitoring

– QUALITY MONITOR: evaluation of recorded employees and instant coaching sessions

Architecture

– Call recording in SIP (declared as SIP SEPLOS), VoIP, analog, digital and mixed environments

– Web-enabled architecture that makes it easy to locate and use recordings

– Multiple language web interface

– Centralization of recordings from independent satellite sites to a central server

– Support of multi-node environments

– High availability (Warm standby)

– Support of virtualization

– Open integrations through the Application Programming Interface (API)

Compliance

– Records encryption

– Login authentication via Radius server

– Compliance with Thales encryption

– In line with Payment Cards Industry (PCI) requirements for call recording systems

Benefits

Fulfills every need with a modular offer made up of four modules (Record, Capture, Silent Monitor and Quality Monitor)

Accelerates resolution of customer issues

http://qapub.ind.alcatel.com/?product=MultimediaServices&page=overview



Minimizes risk of disputes through complete tracking of customer interactions

Boosts customer satisfaction and loyalty

Enhances staff productivity thanks to monitoring and coaching

Improves quality assessment based on actual customer-employee interaction recordings

Transparently integrates with Alcatel-Lucent Communication Servers

Minimal hardware requirement (single server)

More details

Please refer to the Technical Datasheet posted on the Enterprise Business Portal for more details on the application prerequisites, limits and restrictions. Technical requirements are described into details in the "OmniPCX RECORD - Hardware & Software Specification.pdf” document available on the Enterprise Business Portal (under Customer support/Technical Support/Software Download/OmniPCX Record Suite folder). Please refer to the Services Applications Compatibility Matrix available on the Alcatel-Lucent Enterprise Business Portal for all questions about software compatibility.

https://businessportal.alcatel-lucent.com/alugesdp/content?ID=Q00041758



8. Integrated voice guide services

8.1 Integrated voice guides The Alcatel-Lucent OmniPCX Enterprise Communication Server includes recordings of human voice guides to provide users with information on the various options available to them during a telephone call. Voice guides give verbal information about the current status of the phone and offer direct access to appropriate features. These step-by-step instructions are available on any phone, ensuring easy use of all features and helping to avoid errors. Voice guides operate as dialing tones: the user can start dialing at any time.

Voice guides are available in all languages as a standard feature (with a female or male voice, depending on customer choice). They can be broadcasted to internal and external users alike.

Customization of voice guides, as well as creation of specific voice guides is made available to the customer as a standard feature. You may record your own voice guides, either using the scripts of the standard recordings and/or providing any additional relevant information. Recordings can take place in a professional studio, but you can greatly reduce your costs by using the Alcatel-Lucent Audio Station application to record your own messages with a high professional sound quality or using an Alcatel-Lucent phone. Customized files are easily integrated to the system to reflect your company image.

A standard (free of rights) music-on-hold file is included on the voice guide CD-ROM delivered with the Alcatel-Lucent OmniPCX Enterprise Communication Server. You may use this file, customize it with voice messages, or play the music file of your choice, unless you prefer to connect another device to the server.

The voice guide feature also includes: wake up calls, off-hook messages and greetings.

Pre-recorded standard messages are available to greet incoming calls. According to configuration, when the Alcatel-Lucent OmniPCX Enterprise takes an incoming call, a pre-programmed message is played before the caller is diverted to a directory number.

Greeting messages are stored in the system (maximum 254 messages)

Messages are selected according to user requirements

The chosen greetings can apply to individual phones or to all extension phones, or can be dependent on the recipient’s status



For more information on specific greeting use, see the automated attendant section in the document on attendants.

8.2 Voice Guides An economic and effective method of avoiding client dissatisfaction in any business environment is the possibility to interact instantly with a caller.

The Alcatel-Lucent OmniPCX Enterprise Communication Server voice guides services are available to increase and maintain communication.

From outside the enterprise, voice guides can be used to encourage the caller to:

Stay on line or call back later

Refine their search within an enterprise

Offer an interactive action

Within the enterprise, the system voice guides offer appropriate information for users’ analog, digital and DECT telephones or external users (via AA or DISA). Voice prompts offer the following types of information on:

Context-sensitive feature codes (suffixes and prefixes)

Telephone status

An activated service

A voice guide offers relevant information at specific times. The voice guide is made up of one or more voice messages, which are relevant messages recorded in different languages.

The voice message services that can be offered via the Alcatel-Lucent OmniPCX Enterprise Communication Server include:

Static: cannot be modified by the user:

Generic: compatible with generic numbering plans and offered in at least 6 different languages for all countries.

Note 2: A static message file contains one or more messages.

Standard: adapted to a country with special requirements and/or a numbering plan differing from the generic numbering plan.

Specific: to an area or company.

Dynamic: modifiable, recorded by users and/or managers via a phone set or the Alcatel-Lucent Audio Station (AAS) application.

Note 3: A dynamic message file only contains one message.

External: music-on-hold (in most cases) played by a device external to the OmniPCX.



8.2.1 Chained voice guides

Some voice guides are composed of several messages. These are referred to as "chained" voice guides. There are three different types of chained voice guide:

1 Variable chained voice guides: composed of several messages (8 maximum), of which at least one varies.

Example 1: When programming an appointment reminder, the user programs the time at which he wants to be called on his set. The set then confirms "Your request for an appointment at XX hour(s) YY minute(s) has been recorded (where "XX" and "YY" are variables).

2 Static chained voice guides: composed of several non-variable messages played in a pre-configured order (sequence).

3 Composite chained voice guides: composed of an internal message (static or dynamic) followed by an external voice message.

Example 2: The message: "Welcome to Alcatel-Lucent, please hold the line, we're trying to connect you" is played before real-time broadcast of a radio station.

8.2.2 Voice messages

Voice messages:

Provide high quality creation and playback of the spoken word using binary information contained in the memory module

Are delivered in different languages on a CD-ROM along with a user-friendly software transfer tool

Feature dialing codes (prefixes and suffixes) that are implemented using a standard or customized dialing (numbering) plan. The voice messages installed on the Communication Server by the transfer tool adhere to the country or company dialing plan

are stored after installation on the Communication Server hard disk, downloaded to the media gateway memory, and played on the telephone by the media gateway

Voice messages can consist of one simple message or a combination of several messages (e.g., a combination of a greeting message and a short musical excerpt).

8.2.3 Message examples

Thank you - Your request has been recorded; you may now hang up.

Please dial your password or personal code.

The number you have dialed is not authorized; for more information, please ask the system manager. Thank you.

Please dial the phone number you require.

Your calls will be forwarded. You can still make a call. To cancel call forwarding, please dial....

You have a voice mail message.

You can forward to a party’s voice mail by dialing 7.

You may cancel automatic callback by dialing 6.



You may request automatic callback by dialing 5.

You may request barge-in by dialing 4 or automatic callback by dialing 5.

You may request automatic callback by dialing 5 or camp-on by dialing 6.

You may request barge-in by dialing 4, automatic callback by dialing 5, or camp-on by dialing 6.

You may request barge-in by dialing 4.

Please dial the project account code.

Please enter the required time of day (alarm or appointment reminder call).

You may camp-on by dialing 6.

The person you have called is unavailable; please call back later. Thank you.

While your extension is in the do not disturb mode, you can still make a call. To cancel do not disturb, please dial...

This is your reminder call (alarm or appointment reminder).

The extension you have called is protected against barge-in.

Please do not hang up; your party is being paged (paging).

You may page the person you have called by dialing 7.

Your party is being paged; you may hang up (paging).

8.2.4 Main characteristics

Characteristics include:

Voice guide and display languages can be selected by the user on Alcatel-Lucent phones from those available in the installation

Modification of the user language automatically synchronizes voice prompts and display as well as the Alcatel-Lucent 4645 e-VA voice mail

The use of voice guides is optional and can be assigned by each user individually

Depending on the type of broadcast selected by management, the user will hear the voice guide from the start or while it is being played. If playback is set from the start of the voice guide, each time a user requests this guide and a broadcast channel is free, the message is played from the start

If the user requests a guide that is not playing and all guide broadcast channels are busy, the user hears the backup tone for the guide requested

Voice guides cover different features (all described in other documents):

Telephone services

Access restrictions

DISA

Hotel, hospital

CCD



Integrated voice mail

Integrated automated attendant

8.2.5 Customized voice messages

Alcatel-Lucent offers the ability to manage voice guides professionally on site according to individual customers' needs. Customized voice guides can be recorded on or off site and easily integrated into the OmniPCX using the Alcatel-Lucent Audio Station (AAS), an adjunct system that offers professional quality results:

Input can be digital, CD-audio, or CD-ROM

Original recording can be done by a professional studio

8.3 Internal Music-on-hold This internal component plays messages and music to callers on hold.

Characteristics include:

The message is recorded in the voice guide module

The content of the announcement can be customized

A default Alcatel-Lucent music-on-hold recording is included on the voice guide CD-ROM

A centralized configuration in a large network can require specific music on hold (MOH) for each branch office (e.g. for small bank agencies).

As with other resources, most of these MOHs are stored in central sites and can be used by remote IP Phones hosted in branch offices without a Media Gateway.

MOH features are stored in the GPA, GA or GD boards. Each board supports one memory with the capacity for dynamic guides of 16 minutes (GPA2) or 8 minutes (GD/GA).

The duration can be extended in large multi-site configurations where it is possible to configure several thousand branches per Communication Server with a specific MOH for each branch.

System optimization can be increased for the following durations per board:

GPA2: 64 minutes (16’ in dynamic memory + 48’ in static memory)

GD/GA: 40 minutes (shared with voice guides)

8.4 External Music-on-hold Messages and music for callers on hold can be played from an external device (tape recorder, radio, CD player, etc.)

8.4.1 Distinctive features

Distinctive features include:

Customization of the recorded message

Variation of the duration of the announcement according to the capability of the external device

8.4.2 Connection

A standard telephone pair connects the external device to an analog board or to the AFU daughterboard socket on the GD (Gateway Driver) board.



9. IP Telephony domains and related features The Alcatel-Lucent OmniPCX Enterprise Communication Server offers several features:

Enabling to cope with inherent bandwidth constraints on the WAN between remote sites

Offering defense mechanisms in case of IP link breakdown between a remote site and the central site where the Communication Server is located

Enabling to take into account the geographical location of a remote site

These features are based on IP telephony domains, which can be used to partition a node according to the IP address of IP devices.

An IP domain corresponds to one or several ranges of IP addresses. An IP telephony domain also contains non-IP devices connected to the media gateways belonging to this domain.

Typically, an IP telephony domain corresponds to a remote site.

Note: The IP telephony domain feature is a "local" concept. In other words, IP domains are local to each Communication Server. An IP domain cannot be defined across two or more IP communication servers.

9.1 Call Admission Control (CAC) and codec selection The original key role of IP telephony domains is to prevent voice congestion in the WAN by limiting the number of calls on the WAN and by imposing the use of compression.

IP telephony domains can take into account the available bandwidth by limiting the number of inter-domains communications, whereas there is no limit on intra-domain communications. The limitation of inter-domain communication is "Call Admission Control" (CAC). CAC applies to all IP communications, whether they involve a media gateway, IP phone, H.323 terminal, or SIP terminal.



IP telephony domains allow the possibility to apply different voice compression/digitalization algorithms for inter-domain and intra-domain communications. Typically, internal calls (i.e., limited to a single location) are based on the G.711 uncompressed PCM standard, but WAN calls outside the location use the G.723.1 or G.729/A compression algorithm.

CAC can take into account fax communications in the limitation of inter-domain communication: a distinction is made between the voice flow rates and fax flow rates. IP domains mixing IP phones and fax machines must be separated in two IP domains:

A primary IP domain (D1) including IP phones and IP boards not used for fax communications

A secondary IP domain (D2) including

o IP boards used for fax communications

o Other IP devices for which the CAC must apply in the same way as for fax machines

CAC allows to:

Define the total bandwidth available for fax and voice communications

Define the bandwidth for fax communications

Take into account the ratio between voice flow rate and fax flow rate in order to optimize the use of the available bandwidth

This is useful when voice communications use a compression algorithm (e.g. G.723/G.729) whereas fax communications use G.711. In this manner, CAC can limit the number of voice communications when fax communications are already established, in order to guarantee sufficient bandwidth for existing communications. In the same way, CAC can reject fax communications when the existing bandwidth is insufficient.

Controlling the bandwidth is possible for other devices (for example, OmniTouch 8600 MIC Desktop).

9.2 Defense mechanisms Defense mechanisms include:

The backup signaling link, which can set up a signaling link with the Communication Server through the Public network in case of IP link breakdown.

The Passive Communication Server, which acts as a Communication Server for one or several remote sites when the Communication Server is not reachable, either because of a Communication Server breakdown or an IP link breakdown.

IP phone survivability, with which IP phones in a remote site can still work (with limited services) when the IP link with the Communication Server is down or the Communication Server itself is down. In survivability mode, an IP phone uses the backup signaling link or connects to a Passive Communication Server or to a SIP proxy server: in the latter case, the IP phone switches to SIP mode.

9.3 Time zone management The Alcatel-Lucent OmniPCX Enterprise Communication Server system can set up local time zones for each IP domain. This enables sets to display the real time of the site. The date format may be either in the order day-month-year, or in the order year-month-day.

This data is updated by ISDN or NTP and changes automatically with Daylight Saving Times. It is displayed on mobile or fixed digital sets (whether IP or TDM) and attendant sets (for example, Alcatel-Lucent 4059 IP attendant console). It applies to all user time-related features such as wake-up and appointment calls, unanswered call time, deposit time for text messages, charging



(accounting tickets, according to the correct time zone), and is also updated in these features' corresponding voice guides. It is also compatible with DECT and MIPT roaming.

The Alcatel-Lucent OmniTouch 8440 Messaging Software records messages with the local date and time of the receiving set. The voice mail allows mailbox owners to select their present time zone from a Web interface. This operation guarantees that the voice mail announces the date and time of messages received by the mailbox owners according to their time zone.

Restrictions:

If an IP domain includes SIP or S0 sets:

SIP sets display their own date and time

S0 sets display the system date and time

9.4 Multi-country IP telephony domains can be used to associate specific countries to IP devices. In addition, the Alcatel-Lucent OmniPCX Enterprise Communication Server supports configurations where the remote sites are located in different countries.

The multi-country mode is used for:

Tones setup. The tone generation definition of the corresponding country is sent by the Communication Server to the Media Gateway at Media Gateway initialization. For IP Phones, the Communication Server sends the tone generation definition of the corresponding country to the set.

When a tone is sent to a device, the Communication Server checks the country declaration of this piece of equipment and sends the corresponding tone parameters in a specific tone message.

Call back service. An External Call Back Translation Table is used for incoming calls. It converts the number of the external caller presented by the public carrier. The number thus translated is the exact number a user/system must redial in case of callback.

The translated number is:

Displayed as caller number on digital sets with a display

When applicable, added to the list of unanswered ISDN calls on a digital set with a display

Used to call back the calling set

Stored in a call log

In case of multi-country configuration, a call can enter the system via a trunk group located in one country and be internally routed to the called set located in another country. Regardless of called set location, the calling number displayed must be the complete number to use to return the call, in other words:

The outgoing prefix must be the prefix used in the country of the called set

If the calling set is located in a foreign country, the international access prefix and the national code must been added

Common Hardware boards initialization as well as other pieces of equipment initialization (IP devices and devices linked to a Common Hardware board).

The multi-country mode affects:

Calls to a forwarded set not located in the same country as the caller. The calling number is built with the directory number of the forwarded set



Calls to a remote extension (for example, mobile phone) not located in the same country as the caller. The calling number is built with the directory number of the remote extension combined with additional parameters

9.5 Calling line identification (CLI) per IP Domain With IP telephony domains, you can define a specific installation number corresponding to a local number of the remote site. This number is mainly used as CLI number for outgoing calls from non-DID sets.

This is particularly useful for outgoing emergency calls. It prevents the emergency center from being misled by a CLI number which would not correspond to the real location of the calling party.

For emergency numbers, a specific CLI per IP domain, allows emergency services to call back the user (or any other individual in the same geographical location) that called them initially.

This feature is available for PSTN, H.323, and SIP interfaces.

9.6 Restriction It is not possible to mix trunk groups using two different laws (A or µ) on a same node. Therefore it is not possible to build a node containing sites in countries using different laws.

Multi-time zone and multi-country features are not supported with the OpenTouch Business Edition.



10. SIP and web services Alcatel-Lucent has chosen SIP as one of the corner stones of its standards-based developments for interactive communication solutions for businesses. SIP has been evaluated as the emerging standard for the future of real-time multi-media IP communications for the following reasons:

SIP evolved out of the Internet community and addresses the implementation of real-time communication services in IP networks:

o It belongs to the web protocol family: XML, HTML, MIME and others

o It is directed by the IETF standards body

SIP is at the center of carrier/service provider networks and is currently poised at the center of several major deployment projects

Completely endorsed by key industry application vendors

Standardization has progressed significantly and ongoing work is fueled by strong acceptance from the majority of the communication industry

It is the only protocol that provides “across-the-board” solutions according to three major application points:

o End-points (devices, stations, phone-sets, soft-clients)

o Trunking (private or public)

o Interactive media-based applications

Currently considered as the protocol for the future of Voice over IP, the implementation of any ubiquitous solution will occur over a period of time, and employ a systematic phased approach. The scope and breadth of the SIP protocol follows the industry standards process (IETF) and will progressively enlarge the level of services for each application as the market advances.

10.1 Marketing SIP Historically, the enterprise communication market has been dominated by two desktop device technologies that support and vehicle telephony services, these being digital and analog phones. Until the recent emergence of IP convergence in 2000-1, analog phones remained the only alternative technology to digital for the following reasons:

1 Extremely low prices due to economies of scale generated by the residential market

2 Provides a “minimum” of communication services

3 Vast choice of suppliers and availability

4 Independent of the communication infrastructure vendor: “freedom to choose”

5 Easy to deploy – connects to an analog port

The arrival of IP convergence technologies has raised the issue of how to address the same basic requirements for low-cost communication devices, but in an IP network. Although there are a number of alternatives using IP; soft phones, Wi-Fi, PDAs, there is still an opportunity to address physical, low-cost desktop devices using IP technologies. In this context, SIP has been identified as a technological enabler.

Consequently, Alcatel-Lucent has been at the forefront of pioneering and enabling SIP as an end-point technology, and has recognized early in the game, the potential to become the ubiquitous low-cost device preference expected of the market. However, the reality of deployment depends on a number of market pre-requisites that must be addressed before SIP becomes a true and viable solution:



The devices must deploy correctly minimum criteria within the SIP protocol: RFC3261, RFC3262, RFC3264, RFC3265, RFC3515.

The devices need to support a minimum of IP infra services and compatibility (including codecs, POE, DHCP, QoS tickets)

The communication system has to control the SIP endpoints across network topologies (including IP Domains, Call Admission Control, redundancy, survivability)

The level of telephony services provided to SIP phones is dependent on the capabilities of the set (for example, conferencing resources in set). Standard SIP Telephony features are still limited today. Careful assessment of end-users requirements must therefore be done before opting for SIP sets.

Manageability/serviceability tools must ensure smooth/economic deployment (including domain names, proxy addresses, VLAN assignments)

Finally and most importantly, economies of scale are triggered and allow true low-cost prices to be achieved: ISPs/ASPs (operators/carriers) must finally launch mass-market SIP

10.2 SIP basics SIP is an IP signaling protocol designed to establish, to maintain, and to end multimedia sessions between different parties. It operates on a client-server mode. It is based on the exchange of text messages with syntax like that of HyperText Transport Protocol (HTTP) messages. Elements of the SIP world are identified by SIP Uniform Resource Locators (URLs) such as e-mail addresses.

It is important to note that SIP does not provide an integrated communication system. SIP is only in charge of initiating a dialog between interlocutors and negotiating communication parameters, particularly concerning the media involved (audio, video). The Session Description Protocol (SDP) describes Media characteristics.

SIP uses the other standard communication protocols on IP: for example, for voice channels on IP, Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP). In turn, RTP uses G7xx audio codecs for voice coding and compression.

Unlike H.323, the SIP protocol can rely on the IP network transport protocol in datagram mode (User Datagram Protocol (UDP)) in addition to the IP network transport protocol in Transmission Control Protocol (TCP) connected mode.

UDP has the advantage of being an unconnected protocol that facilitates swift exchanges. It does not guarantee datagram reception and transmission sequence preservation. Thus, SIP carries out these functions, using retransmission, acknowledgment and sequencing mechanisms.

As such, SIP is a protocol that can be used to manage Voice over IP (VoIP) sessions over an IP network but with certain limitations for call handling.

10.3 SIP and OpenTouch In an OpenTouch system, SIP can be used for more than basic communication applications. SIP features for OpenTouch include:

Multimedia Routing application controls:

o Core Switching and handling

o Building rules for a user to route their calls to the endpoints or to another user

o User interaction for setting routing rules

User Session Manager for the administration of:

o Multiple device ownership

o Session handover between the devices



SIP Basic communication applications for basic and standard SIP endpoints. These include:

o Make, take, clear, reject and deflect calls

o CLIP/CLIR

o Multi-endpoints forking for user centricity, Multi-lines

o Hold/retrieve communication and consultation calls

o Attendant and unattended (blind) transfer

o Immediate/no response/ on busy/ on busy or no response call forwarding managed by the Telephone User Interface (TUI)

o Callbacks for calls on busy telephones or unanswered calls

o Lock and unlock of each endpoint

o Message Waiting Indicator (MWI)

o Get and deposit message in voice mail from internal or external calls

o Peer to peer video calls between endpoints that support audio/video connections



11. Session Initiation Protocol (SIP) networking

11.1 Session Initiation Protocol (SIP) networking This section describes Session Initiation Protocol (SIP) and how the Alcatel-Lucent OmniPCX Enterprise Communication Server accommodates this method of communications transport. The arrival of low-level SIP telephone sets and their increasing availability on the market offers the possibility of analog phone replacement.

11.2 Alcatel-Lucent and SIP

11.2.1 SIP and Alcatel-Lucent OmniPCX Enterprise Communication Server

The Alcatel-Lucent OmniPCX Enterprise Communication Server SIP implementation addresses the integration of SIP end-points with other devices controlled by the Alcatel-Lucent OmniPCX Enterprise Communication Server.

TDM sets and trunks

IP sets and trunks (including IP Touch, H.323 trunks)

This implementation prepares the communication application architecture, to provide SIP enabled applications to various sets and devices (whether SIP or not). This concerns notably:

The Alcatel-Lucent OmniTouch 8400 Instant Communications Suite

GVP IP (Genesys Voice Portal)

Microsoft Exchange 2007

Selected Alcatel-Lucent Application Partner Program (AAPP) products such as Thomson ST 2022 & 2030, Ascom i75 and Teledex

The Alcatel-Lucent OmniPCX Enterprise Communication Server comes with an embedded SIP Gateway.

The SIP Gateway consists of the gateway function, and a proxy and registration server:

The gateway deals with the inter-working functions between SIP and OmniPCX phones or trunks

The proxy deals with SIP routing and SIP end point (phones) location. The proxy looks up the internal database (for example, to find the IP address) in order to locate SIP end points

The registrar receives registration from SIP end points, and stores mapping of SIP phone numbers and associated IP addresses in an internal database. Authentication for the registration uses MD5

End points can use UDP or TCP transport.

The Alcatel-Lucent OmniPCX Enterprise Communication Server SIP proxy/gateway is embedded in the Communication Server, and thus benefits from the “high availability” feature provided by duplicate (redundant) servers (backup avoids reregistering of SIP end points after a failure).

11.3 Supported SIP standards The Alcatel-Lucent OmniPCX Enterprise Communication Server is based on the latest standards. In relation to SIP, the following RFCs are supported (they can be found on the IETF site at http://www.ietf.org):

1889: RTP: A Transport Protocol for Real-Time Applications

2327: SDP: Session Description Protocol

http://www.ietf.org/



2782: A DNS RR for specifying the location of services (DNS SRV)

2822: Internet Message Format

2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

2976: The SIP INFO method

3261: SIP: Session Initiation Protocol

3262: Reliability of Provisional Responses in SIP (PRACK)

3263: SIP: Locating SIP Servers

3264: An Offer / Answer model with SDP

3265: SIP-Specific Event Notification

3311: The Session Initiation Protocol (SIP) UPDATE Method

3323: Privacy Mechanism for the Session Initiation Protocol (SIP)

3324: short-term requirements for network asserted identity

3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks

3326: The Reason Header Field for the Session Initiation Protocol (SIP)

3458: Message Context for internet Mail

3515: The Session Initiation Protocol (SIP) refer method

3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signaling to the Session Initiation Protocol (SIP)

3725: Third Party Call Control (3pcc): flow I

3842: A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)

3891/3892: The Session Initiation Protocol (SIP) 'Replaces' Header/ Referred-By Mechanism

4028: Session Timers in the Session Initiation Protocol

4244: Extension to the Session Initiation Protocol (SIP) for Request History Information

4497: Inter-working between SIP and QSIG

4733: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

11.4 Integration of SIP end-points in the Alcatel-Lucent OmniPCX Enterprise Communication server network

11.4.1 Integration of SIP end-points in the PCX network

By implementing a complete SIP gateway/server solution, the Alcatel-Lucent OmniPCX Enterprise Communication Server enables SIP end-points to be integrated into the PCX environment.

SIP end-points (that is, devices), connected to the Alcatel-Lucent OmniPCX Enterprise Communication Server, operate as integrated SIP sets and can:

Fully communicate with devices controlled by the Alcatel-Lucent OmniPCX Enterprise Communication Server (for example, TDM and IP sets)

Benefit from a large range of business telephony features available on the Alcatel-Lucent OmniPCX Enterprise Communication Server (using the appropriate prefix/suffix on the SIP set)

Be monitored by CSTA services and provide call events and call control processes (for example, make call, release call)



11.4.1.1 Compatible SIP end-points

The following products can operate as integrated SIP end-points with an OmniPCX Enterprise:

Alcatel-Lucent IP Touch 8002/8012 sets (as well as 4008/4018 sets) operating in SIP mode and communicating via the SIP interface of the OmniPCX Enterprise.

Alcatel-Lucent IP Touch 8082 sets operating in SIP mode for hospitality deployment. This device can be deployed in Suite room, offering both SIP telephony and Web Hotel Services.

Partner SIP entry-level sets.

After careful examination and evaluation of potential suppliers, Alcatel-Lucent has chosen Thomson and Ascom as strategic partners in the field of professional SIP sets, whose product line is currently residential oriented, but evolves and matures in time to become a reliable and deployable enterprise IP device. The following sets were approved:

o Thomson ST 2022/2030 sets

o Teledex SIP sets (dedicated to the hospitality market segment)

Before deciding a SIP versus low-end, end-to-end (proprietary) technology, it is important to understand not only the end-user feature requirement, but the evolution of the network and IP foundation technologies that might be deployed in an overall enterprise communication strategy.

For example:

POE compliance/options: 802.3af

Codec support: G711, G.723 & G.729

DTMF in-band support

Encryption protocols: AES

Authentication protocols: 802.1x

Wideband telephony: 200 – 7KHz voice

XML services

Dual subnet redundancy servers

Etc.

11.4.2 SIP end-point configuration and registration

Unlike sets that are stimuli terminals completely controlled by the system, SIP sets are “intelligent” end-points that require item (local) management. Generally, the SIP sets include integrated Web server management tools. These tools are required to manage SIP sets on an individual basis.

To operate as integrated SIP sets and benefit from advanced telephony features, so far reserved for standard internal Alcatel-Lucent devices, SIP devices must follow a process including:

The SIP device declaration in the Alcatel-Lucent OmniPCX Enterprise Communication Server database. This operation automatically triggers the SIP device registration in the SIP dictionary (within the Alcatel-Lucent OmniPCX Enterprise Communication Server).

The SIP device commissioning.

o For partner SIP entry-level sets (Thomson ST 2022/2030), the SIP parameters configuration can be fully performed in the set itself or downloaded from the SIP Manager application embedded in the OmniVista 8770

o For Alcatel-Lucent IP Touch 4008/4018 phone Extended Edition sets, the SIP parameters configuration includes:

– SIP mode activation, either from the set itself or a configuration file downloaded from a server



– SIP configuration, using configuration files downloaded from a server

These configuration files are built with the SIP Manager application embedded in the OmniVista 8770.

The SIP device registration (after device reboot) in the registrar server of the Alcatel-Lucent OmniPCX Enterprise Communication Server. By registering, the PCX database links the IP address of a SIP device to a directory number, and provides:

o A SIP address in the form: sip:<directory-number>@<omnipcx-adress>" where <omnipcx-address> is the name of the domain or an IP@ of the PCX

o A user name and first name in the PCX phone book

o A Class of Service (COS) for barring/restriction and accounting

o A voice mailbox including waiting messages notification

Example:

A SIP user called “Bob” has the following SIP address:

[email protected]

sip.company.com is called the domain, and must be the same as the SIP proxy domain

5000 is the user address in the domain. This number must allow other devices managed by Alcatel-Lucent OmniPCX Enterprise Communication Server to establish a call.

Additional identities can be added to the address using the system management tool, for example, a name like [email protected]. This identity can also be used for calling the device/user.

First, Bob is registered on his SIP set (by the administrator or by user-programming according to the set capabilities). The address is sip:[email protected].

The SIP set can be reached at IP address 192.168.3.2.

And, due to previous configuration, Bob has directory number 5000 in the Communication Server.

11.4.3 SIP end-point deployment on a large scale

The SIP Manager application, embedded in the OmniVista 8770, provides a graphical user interface enabling SIP devices' commissioning and SIP devices' daily maintenance. This application allows a fast deployment of a large quantity of SIP devices.



The SIP Manager application operates in association with a dedicated server named Device Management (or DM).

The SIP Manager application enables notably:

To configure SIP users and SIP devices

To assign one or several SIP devices to a SIP user

To make configuration data accessible to SIP devices for their commissioning. Configuration data is registered on the server and downloaded by SIP devices via TFTP, HTTP, or HTTPS.

The SIP Manager is open to deploy partner SIP entry-level sets (Thomson ST 2022/2030)

11.4.4 Telephony services available for SIP end-points

The following telephony services are provided when SIP sets communicate with the Alcatel-Lucent OmniPCX Enterprise Communication Server.

Important:

These are interconnected services supported by the Alcatel-Lucent OmniPCX Enterprise Communication Server gateway, and not services provided by the call handling feature for SIP sets. Therefore, these services can only be provided if the involved SIP set can support them. Presentation of the service on the set is also independent of the Alcatel-Lucent OmniPCX Enterprise Communication Server (display, etc.).

For example, certain SIP sets use their own resources to set up a conference (for example, the OmniPCX conference bridge is not used when the user of the SIP set initiates a conference using its own conference bridge).

11.4.4.1 Telephony services access

Accessing the Alcatel-Lucent OmniPCX Enterprise Communication Server telephony services is provided by dialing the corresponding prefixes on the SIP set.

For Alcatel-Lucent 8002/8012 phone Extended Edition sets registered as SIP sets on the Alcatel-Lucent OmniPCX Enterprise Communication Server, programmable keys are automatically associated to specific telephony services.

A set of paper labels is offered for quick and easy identification of

OmniVista

8770 NMS

(SIP Manager)

8002/8012

SIP Phones



associated keys.

11.4.4.2 Telephony services display

The SIP devices can display a high level of information relating to telephony services. When a telephony service is activated on the SIP set, the Communication Server returns a SIP message to the SIP device providing its status for this telephony service. This level of services is supported by the partner SIP entry-level sets (Thomson ST 2022/2030).

Example: If an appointment is programmed, the SIP set can display the following message: Appointment at 12:00

Information displayed in the SIP message applies to the following telephony services:

Call forwarding activation

Do not disturb activation

Remote extension deactivation (OmniPCX Integrated Cellular Client service)

Hunting group

Appointment or wake-up programmed

Lock activation

11.4.4.3 Basic telephony services

Automatic answer

Basic incoming and outgoing calls

Broker call

Callback request (using call log)

Call diversion on ringing

Camp-on

Consultation call

DTMF transparency

Registration with or without authentication

Speed dialing

Transfer (attended and unattended)

11.4.4.4 Advanced telephony services

Appointment reminder and wake-up call

Barge-in

Call announce

Call by name (depending on the SIP set capabilities)

Call forwarding (unconditional, on busy, on no answer)

Call hold

Call park

Do Not Disturb (DND)

Multiline

Night call forwarding



11.4.4.5 Team work

Conferences (three-party, casual, mastered and meet-me conferences)

Pick-up or hunting group

Supervision

11.4.4.6 Complementary services

Accounting

CLIP/CLIR (secret identity)

InfoCenter facilities

Hospitality

Multi-tenancy

Twin sets

Voice mail access and notification

11.4.5 Basic SIP call via the PCX SIP proxy

11.4.5.1 SIP to SIP call

Referring to our common example:

A SIP user called “Bob” has the following SIP address:

[email protected]

sip.company.com is called the domain, and must be the same as the SIP proxy domain

5000 is the user address in the domain. This number must allow other devices managed by Alcatel-Lucent OmniPCX Enterprise Communication Server to establish a call.

If another integrated SIP set dials 5000, the call is routed by the set to its "outbound" proxy, which is the Alcatel-Lucent OmniPCX Enterprise Communication Server SIP proxy.

The SIP proxy locates the called SIP set and forwards the message accordingly.

11.4.5.2 Calls from other Alcatel-Lucent OmniPCX Enterprise Communication Server devices to SIP end-points

Users of IP Touch sets must dial a directory number to call the SIP device. The Alcatel-Lucent OmniPCX Enterprise Communication Server translates the telephone number to a SIP address to reach the called SIP terminal.

To call an integrated SIP set with a directory number 5000, an Alcatel-Lucent OmniPCX Enterprise Communication Server user dials 5000. The SIP gateway then sends sip:[email protected] to the SIP proxy.

IP Touch sets that have an alphanumeric keyboard/keypad can also use the call by name service (phone book name) to call integrated SIP sets, since names of integrated SIP sets can be in the OmniPCX phone book.



11.4.5.3 Calls from SIP end-points to other devices on the Alcatel-Lucent OmniPCX Enterprise Communication Server

Integrated SIP sets can call other devices by dialing sip: <directory number>@ <omnipcx-address>, where the directory number can be a set number or a public number. Some SIP sets provide speed dialing features, and their users only need to dial directory numbers.

Names of integrated SIP sets can be recorded in the OmniPCX phone book. These names can be exported to the Alcatel-Lucent OmniVista 8770 LDAP directory. Therefore, SIP terminals with an LDAP client can use the Alcatel-Lucent OmniPCX Enterprise Communication Server “call by name” (“dial by name”) service if they can automatically append a default domain name (for example, “@sip.mycompany.com”) to the directory number retrieved from the OmniVista 8770 LDAP directory.

11.4.6 Media considerations for SIP within the PCX

11.4.6.1 Type of media

Three situations can be identified:

1 Communications between integrated SIP sets controlled by the same proxy

Any type of media can be used according to the SIP device type. For example: softphones equipped with the adequate peripheral equipment (including camera and handsets) can start and participate in video conferencing.

2 Communications between integrated SIP sets to/from other Alcatel-Lucent OmniPCX Enterprise Communication Server devices

Voice media is supported, including the protocols G711 A/µ, G723.1 or G729A.

This is also true for communications between integrated SIP sets and other SIP clients.

3 Communications to fax machines. Fax T.38 Annex D is supported over IP.

11.4.6.2 RTP flow

Media over IP is transported in Real-time Transport Protocol (RTP) packets. RTP flows are direct between any SIP device and other IP devices of the Alcatel-Lucent OmniPCX Enterprise Communication Server, such as IP Phones and media gateways or an IP voice messaging system (A4645).

Direct RTP means that RTP flows are not transiting through the system (typically, an IP board) controlled by the Alcatel-Lucent OmniPCX Enterprise Communication Server. The quality of the voice is therefore better, and the required number of IP boards is less important.



Scenario 1: Communication between integrated SIP set and non-SIP (Alcatel-Lucent User) set

Scenario 2: Communication between integrated SIP set and unknown SIP set

Scenario 3: Communication between non-SIP (Alcatel-Lucent User) set and unknown SIP set

Definition: An ”unknown SIP set” is a SIP set that has not been integrated to the Alcatel-Lucent OmniPCX Enterprise Communication Server.

11.4.7 Calls made to TDM trunks

An integrated SIP set has an Alcatel-Lucent OmniPCX Enterprise Communication Server user profile, with a specific class of service containing the barring/restriction feature.

Call accounting is performed for calls originating from integrated SIP sets that are directed towards TDM trunks.

Example: User Bob (directory number 5000) dials a PSTN number. User Bob's integrated SIP set is declared in the Alcatel-Lucent OmniPCX Enterprise Communication Server database. If digest authentication is enabled, the requesting message is challenged. A new request with security credentials is sent towards the SIP proxy. The embedded proxy routes the request to the SIP gateway. The Alcatel-Lucent OmniPCX Enterprise Communication Server processes the call according to user Bob's public network class of service. Proper billing information is collected.



11.4.8 Voice mail account

SIP integrated users can have an account on voice messaging systems supported by the Alcatel-Lucent OmniPCX Enterprise Communication Server:

Alcatel-Lucent 4645 Voice Messaging System

Alcatel-Lucent OpenTouch Message Center

Alcatel-Lucent OpenTouch Multimedia Services

Integrated SIP sets can be forwarded to the OmniPCX voice messaging system. They receive a message waiting indication. Navigation in a voice mail account from an integrated SIP set is performed via touch tone signals.

For Alcatel 4008/4018 and 8002/8012 sets operating in SIP mode, voice mail access is carried out by the Message key. The Message LED flashes when a new message is received.

11.4.9 Authentication verification

The SIP proxy can identify the integrated SIP set from the information received through the exchanged messages (invite).

Within a corporate network, SIP authentication (verification) is not required as both the set and the proxy are managed and controlled by system administration, which ensures an adequate level of security.

Nevertheless, authentication can be set up between the set and the proxy.

The SIP proxy performs HTTP Digest Authentication on call initiation or on mid-call messages: this means that any SIP session between the SIP set and the proxy is authenticated.

With HTTP Digest Authentication, user login and password are encrypted (MD5 process). This is based on shared keys authentication.

11.4.10 Keep-alive dialog

A keep-alive dialog can be established between the Alcatel-Lucent OmniPCX Enterprise Communication Server and SIP sets. The keep-alive dialog, initiated by the SIP set, allows the Alcatel-Lucent OmniPCX Enterprise Communication Server to check whether the SIP set is in service.

Periodically, the SIP set sends an OPTION message to the Communication Server to indicate it is operational.



The keep-alive dialog is useful:

To optimize overflow mechanisms

To maintain session in infrastructure (router, SBC, FW) NAT tables

To optimize GSM-WIFI switching in the MCE dual-mode solution (Alcatel-Lucent OmniTouch 8622 My Cellular Extension)

11.4.11 SIP services offered by an integrated SIP set

From a technical point of view:

1. Native SIP sets or a SIP application on a PC (e.g. SIP softphone)

2. Small FXS gateways, SIP router OmniAccess, SIP router Teldat (Spanish market), SIP AudioCodes MP-1xx series connecting analog devices, with one directory number per analog port.

For example, the same OmniPCX SIP Proxy sees a gateway with two analog accesses as two different SIP devices (with two registrars). These gateways must be able to register.

The Alcatel-Lucent Application Partner Program has tested SIP AudioCodes MP-1xx, SIP router OmniAccess and SIP router Teldat successfully. Therefore, connectivity of a SIP analog FXS gateway can be supported on the Alcatel-Lucent OmniPCX Enterprise Communication Server.

Other gateways (T2/T1 to SIP gateways), which are seen as hunting groups, are not able to benefit from the integrated SIP set services (see SIP trunking).

11.5 SIP trunking The aim of SIP trunking is to allow connections to a SIP operator with the same service level as ISDN. This includes the possibility of different types of access, compatibility with existing services, and integration with the management tools for configuration, observation and call metering.

Several SIP trunks groups can be created:

One main trunk group is created for the external SIP extensions and Alcatel-Lucent OmniTouch 8400 Instant Communications Suite

Separate trunk groups are created for external gateways

SIP trunk capacity is an example of the evolution speed in SIP technology. Current capacities can fulfill requirements for large-size installations, including installations with numerous remote sites.

If an installation including several remote sites, it is possible to configure a local SIP connection to the PSTN for each remote site. This, for example, enables accounting tickets to include the SIP trunk group number and to adapt call costs to each site.

The configuration of mini-SIP trunk groups instead of standard SIP trunk groups allows the possibility to limit the number of trunks per trunk group, so that the total number of trunks remains lower than the maximum authorized, even in case of many trunk groups.

11.5.1 Public SIP trunking

The communication server performs SIP trunk group signaling.

When the Alcatel-Lucent OmniPCX Enterprise Communication Server is connected to the PSTN via a SIP carrier:

SIP signaling exchanges are between the Communication Server and the SIP carrier gateway.

Voice flows are exchanged between Alcatel-Lucent IP phones or IP Media Gateway and the carrier Trunking gateway.



TLS/SRTP protocols can be deployed to protect SIP communication with external/ public SIP Gateways. TLS protects SIP signaling and the SRTP protocol (there are two keys: one key is used to encrypt sent voice flow and another key is used to encrypt received flows) protects voice flows. This means that end-to-end encryption, between carrier and all OmniPCX Enterprise devices (IP Phone, Media Gateway, Communication Server, …) can be offered.

Note: end-to-end ABC subnetwork encryption is not yet possible.

The SBC is the access point to the carrier infrastructure

A Session Border Controller (SBC) is a gateway that typically resides at the boundary of an IP network. This device is used to control the signaling and media streams. SBCs are put into the signaling and/or media path between calling and called party.

The call barring class of service, connection class of service and entity are taken into account.

Call Detail Records (CDR) are generated as for legacy trunk groups, and the Call duration mode is used for accounting purposes.

Call Admission control (CAC) is configured in the Alcatel-Lucent OmniPCX Enterprise Communication Server to control the number of calls through the PSTN trunking gateway and so controls admissible calls between SIP endpoints using the IP domain feature. CAC is used for:

SIP sets

Analog sets or FAX device behind SIP gateways (declared as SIP users)

Note: CAC is not applied to SIP video flows. The bandwidth must be calculated to avoid deterioration in voice quality.

11.5.2 Domain name resolution

In order to route outgoing requests towards an external gateway, the domain name of the external gateway or of the outbound proxy must be resolved. This is done with DNS.

The Alcatel-Lucent OmniPCX Enterprise Communication Server supports two types of name resolution: DNS A and DNS SRV:

DNS A resolution enables the resolution of a name into one single IP address

DNS SRV resolution enables the resolution of a domain name into one or several domain names, which are in turn resolved into IP addresses using DNS A requests. Each record in a DNS SRV answer has a priority order, indicating the order in which requests must be sent. A request must first be sent to the IP address corresponding to the highest priority level. If no answer is obtained from this address, the request must then be sent to the IP address corresponding to the record with second highest level, and so forth,



The DNS SRV implementation on the PCX complies with RFC 2782.

The type of resolution (DNS A or DNS SRV) to be used is selected for each external SIP gateway in its configuration parameters. Two DNS server addresses may be configured for each SIP gateway.

Note: Network Authority PoinTeR (NAPTR) is not implemented on the PCX. The protocol used (TCP or UDP) for SIP messages is the protocol selected in gateway configuration parameters.

11.5.3 Architecture example

In this example some branch offices are equipped with a single analog SIP gateway for both analog sets and FAX devices. The result is Direct RTP for SIP voice and direct T.38 for Fax communications.

11.5.4 Supported telephony features

The tables in this section indicate the telephony features supported by the Alcatel-Lucent OmniPCX Enterprise Communication Server with their current limitations.

In the following tables:

User side indicates if the service is available to a user on the OmniPCX side when communicating with/through a SIP trunk

SIP public trunk side indicates that a service activated on the OmniPCX involves the SIP network to perform the service. If yes, then the service can also be activated on the carrier side.

SIP-related Features User side

SIP public trunk side (NGN involved)

SIP private trunk side

Comments

Basic call Outgoing with number and name display

Yes Yes Yes Block dialing for OG

Canonical form for public numbering

<sip:+33390677517@my_domain>

RFC 3261

Basic Call Incoming with DDI with number and

Yes Yes Yes Canonical form for public numbering






Comments

name display <sip:+33390677517@my_domain>

Range of DDI numbers/users must be provisioned at the NGN side

RFC 3261

Calling line/name identification presentation (CLIP/CNIP)

Yes Yes Yes Provided there is compliance with RFC 3323, 3324 & 3325 is ensured and the Alcatel-Lucent OmniPCX Enterprise Communication Server is considered as a trusted element

Calling line identification restriction (CLIR)

Yes Yes Yes Provided there is compliance with RFC 3323, 3324 & 3325 is ensured and the Alcatel-Lucent OmniPCX Enterprise Communication Server is considered as a trusted element

Connected line/name identification presentation (COLP)

Yes Yes Yes

Connected line/name identification restriction (COLR)

Yes Yes Yes

Call forwarding unconditional (CFU) and on busy/No answer (CFB/CFNR)

Yes No Yes User side: Performed by joining both half calls within Alcatel-Lucent OmniPCX Enterprise Communication Server. RTP optimized.

Private trunk: provided there is compliance with RFC 3261 (302 Moved Temporarily message)

Call hold (CH) Yes Yes Yes Using SIP-related RFC: RFC 3264

Consultation/ Broker/Conference

Yes Yes Yes Using basic SIP features such as invite, call hold, and conference (that is conference relying on the Alcatel-Lucent OmniPCX Enterprise Communication Server, not using SIP conference packages)

Attended Transfer/Early Attended transfer

Yes No Yes User side: Performed by joining both half calls within Alcatel-Lucent OmniPCX Enterprise Communication Server. RTP optimized.

Private trunk: Provided there is compliance






Comments

with RFC 3515 (SIP Refer method)

DTMF overdialing Yes Yes Yes Provided there is compliance with RFC 2833

Fax support Yes Yes Yes T38 ITU-T annex D with G711 fallback

G711 transparent

Same integration with user and system call handling features than for ISDN trunks

Yes No

Features like DDI, differentiated ringing, parking, call overflow to attendant, charging, call overflow to ISDN

SIP related Features SIP public trunk side


Comments

Authentication for Outgoing calls/Incoming calls

Yes Yes Provided there is compliance with RFC 2617 & RFC 1321

Dynamic registration of OmniPCX SIP gateway to Carrier SIP proxy (with or without authentication)

Yes Range of DDI numbers/users must be provisioned statically at the NGN side

Alternate SIP proxy through ARS

Yes Alcatel-Lucent OmniPCX Enterprise Communication Server side

SIP keep alives to SIP proxy Yes

Message Waiting Indication No Yes Provided there is compliance with RFC 3842

Several SIP trunks Yes Yes Alcatel-Lucent OmniPCX Enterprise Communication Server side

Call Admission Control SIP Yes Yes « IP domain CAC » takes into account SIP sets inside IP domains

Multi-codec support Yes Re-negotiation of codecs in case of communication evolutions to select the best quality codec and avoid audio transcoding

Tel URI Yes RFC 3966 – To support tel URI for incoming calls in addition to sip URI: IMS business trunking conformance



SIP related Features SIP public trunk side


Comments

Registration on Outbound proxy discovery

Yes Allows OXE to register to a second carrier proxy as soon as the first one is no more active : better availability for public SIP trunk without losing calls

P-early media Yes RFC 5009 - P-early media is for policing early media (Ring Back Tone). Avoid user to stay without audio in ringing phase in some cases.

Authentication nonce caching Yes SIP authentication procedure optimization to avoid challenging systematically all SIP messages

SIP Trunking and G722 compatibility

Yes G722 Wide Band Audio on SIP trunk . Available for G722 capable sets not IPMG / OXE MS

Law A-mu transcoding with SIP Trunking

Yes

Avoid deploying additional CS node to offer an A-Mu law conversion. Both codecs can be sent by the same carrier to the same OXE

These SIP devices typically have no directory number in the system and are not registered on the Alcatel-Lucent OmniPCX Enterprise Communication Server SIP proxy.

11.6 Unknown SIP sets Unknown SIP devices (that are not integrated SIP sets) cannot be reached directly from non-SIP devices, as their SIP identity is not known within the Alcatel-Lucent OmniPCX Enterprise Communication Server. These devices can only be reached through external SIP gateways (see previous chapter).

It is also possible to configure the system to stop incoming SIP calls from unknown SIP devices to Alcatel-Lucent OmniPCX Enterprise Communication Server sets.

11.7 SIP communication operations at Communication server changeover

SIP communications are maintained when a Communication Server changeover occurs. Depending on the call origin and its state:

Initiating calls (that is, SIP calls being set up) are interrupted, but incoming calls from an external trunking gateway (SIP trunking provided by the carrier) are routed to the relevant entity

Ongoing calls (that is, established SIP calls) are maintained with a few exceptions, for example, calls established to an internal voice mail, which are released



When the state of a SIP communication changes, the main Communication Server systematically updates the standby Communication Server with the relevant information.

Generally speaking, the SIP communications processing at Communication Server switchover is similar to that of typical telephone communications. The standard restrictions also apply to SIP communications.

11.8 SIP limitations A SIP set cannot be:

An agent of a Contact Center

An attendant set

An alarm set

Military features such as MLPP and Call Restriction do not support SIP.

The Multi-tenancy feature does not support SIP.

Signaling and voice flows exchanged between SIP sets and the Communication Server cannot be secured (encryption is disabled).

END OF DOCUMENT

Alcatel-Lucent OpenTouch Suite for Mid sized and...

Documents

Transcript of Alcatel-Lucent OpenTouch Suite for Mid sized and...