Client

Indonesia Compliance

12. Philip Hongkong

Bluetooth Mono Headset

11. Aethra

10. Screen Service Broadcasting Technologies

9. Surya Jaya Teknotama

8. PT. Selat Lintas Utara

7. PT. Jalawave

6. PT. Anindotama perkasa

5. Comba Telecom

4. Nera

3. PT GLOBAL COMMUNICATION SOLUTION

2. PT. Alcorp Techno Partner

1. INTERVOICE

Omvia Messaging R7.3
Product Description

Appendices

Control

Version

1.3

Location

Intervoice Manchester

Originator

Bill Tobin

Creation Date

June 2005

Status

Draft

Approver

Bob Price

Approval Date

Abstract

Appendices This document contains the product description for the Omvia Messaging R7.3 application.

Distribution

Revision History

Version

Modified By

Date

Description

1.0

Bill Tobin

20/6/05

Draft issue

1.1

Bob Price

14/7/05

Updated sizing and configuration data

1.2

Bob Price

19/8/05

7.3 features updated

1.3

Bob Price

5/9/05

Comments from Jeff Epstein added

Appendices


1. Introduction

1.1 Omvia Messaging

Appendices Omvia Messaging R7.3 is an application that can be deployed on the Omvia platform and provides voice and fax messaging for up to one million mailboxes per node.

Appendices Subscribers of the messaging service use the features to access messages using a telephony user interface (TUI). Omvia Messaging R7.3 is supplied with a standard TUI, which enables deposit and retrieval of voice, fax and missed call/abandoned call alert messages. There are also various methods by which the application can notify a subscriber that messages are waiting in their mailbox.

Appendices Omvia Messaging R7.3 can be used in conjunction with Omvia SMSC, Omvia Call Notify and Omvia Celebrity Greetings.

Appendices Omvia Messaging R7.3 provides a number of features that are closely integrated with Intervoice’s Omvia SMSC application. These features include message waiting notification using short text messages when new voice or fax messages are available. To send text messages, Omvia Messaging interfaces directly the Omvia SMSC that is integrated into the platform, or an external SMSC using SMPP (version 3.3).

Appendices Omvia Messaging R7.3 can be used with the Omvia Call Notify application to deliver SMS notifications of missed calls. Omvia Celebrity Greetings can be used to enable subscribers to use a celebrity voice to greet callers to their mailbox.

Appendices Omvia Messaging R7.3, Omvia Call Notify and Omvia Celebrity Greetings can be deployed on the same node.

1.2 The Messaging Market

Appendices Customers now demand new features and functions, and there is space in the market for a cost-effective supplier such as Intervoice.

Appendices In 2004, a survey estimated that there were 1520 million global mobile users (Source: Snapshot Data 2004/OVUM).

Appendices The penetration of Voicemail within this market, varies from operator to operator, but averages at 30-50% of the subscriber base.

Appendices Intervoice’s Omvia Messaging is designed to operate as a core element within a network operator’s strategy for value added services. The service has been designed around the concept of call completion, where any phone or fax calls that cannot be answered are passed to an automated mailbox, and therefore completed. The application has been extended to increase the range of out bound call-completion services. These services enable the operator to offer call completion services to destinations that are not served by any form of call answering, either within, or outside, a network. These features will significantly increase call revenues, while also providing a new exciting range of end-user service packages.

Appendices The application is suitable for fixed and mobile networks. The features and facilities can be adjusted to fit the environment of the operator. The application has the capabilities to support the needs of business and mass-market customer groups. For the mass market, the system can be tailored to provide facilities with a ‘look and feel’ to support the segment(s) targeted. The features and facilities can be controlled through classes of service, which set and manage the expectations of the customer group, and set the price of the service package. Intervoice see this product as a springboard from which operators can broaden their product portfolio and capability, especially within the Internet and e-mail arenas, for targeting to other identified market segments other than the classic voice telephony market.

2. Omvia Messaging Telephony User Interfaces

Appendices Subscribers access the Omvia Messaging services through one of two supplied Telephony User Interfaces (TUIs). An Omvia Messaging subscriber is initially provided with:

· a mailbox number

· a default personal identification number (PIN) for security

· a ‘direct retrieval’ number, which enables the subscriber to retrieve messages from their mailbox using their normal telephone

· an ‘indirect access’ number, which enables the subscriber to retrieve or deposit messages using a telephone other than their normal telephone.

Appendices There are two types of TUI that can be used by Omvia Messaging R7.3:

· TUI 1 This is the Intervoice generic messaging user interface. The features supported depend on the CoS.

· TUI 2 This emulates one of the user interfaces provided by Octel Messaging Products. The features supported depend on the CoS.

Appendices The TUI user menu structures are shown below.

Figure 1: TUI 1 User Menu Structure

Appendices

Figure 2: TUI 2 User Menu Structure

3. Core Messaging Functionality

3.1 Message Types

Appendices Two types of messages, voice and fax, can be deposited in the subscriber’s mailbox if their handset or fax is unavailable. Another type of message is deposited in the mailbox when a caller has not left a message; this is a missed call/abandoned call alert, which generates a message containing the caller’s details. Any call that is not of sufficient length to be classed as a message deposit is classed as a abandoned call alert. The length of call that dictates these circumstances is configured in the administration interface.

Appendices Each type has sub-types:

Table 1: Message types and sub-types

Message type

Sub-types

Voice

New and urgent

New and non-urgent

Saved and urgent

Saved and non-urgent

Fax

New

Saved

Missed call/abandoned call alert

New

Saved

3.2 Mailboxes

Appendices Each subscriber has a mailbox with a unique number from which they can retrieve any voice, fax or abandoned call alert messages that have been deposited. The type of message allowed depends on the subscriber’s Class of Service (CoS).

Appendices The subscriber can customize various features of the mailbox, such as recording a personal greeting, but the service provider controls how the mailbox is set up. This enables the service provider to tailor mailboxes to create end-user packages that are targeted at various markets. Examples of features that can be set are:

· The maximum length of a message that can be deposited.

· The maximum number of messages that can be deposited.

· How a subscriber is notified that there is a message waiting in their mailbox. Notification methods can include SMS, outdial, pager, and so on.

· The maximum number of distribution lists possible.

· Which type of greeting is to be used for a particular service, such as the standard mailbox greeting, direct retrieval greeting, and so on.

3.2.1 Auto-Creation (Option)

Appendices The Intervoice Auto-Create feature is an enhanced system feature designed to minimise the administration costs of implementing a voicemail service in the network, and maximising the service opportunities to end-users.

Appendices An Operator/Service Provider can configure a node, CoS, and a mailbox number range to automatically create a mailbox if the system receives a call to a non-existent mailbox.

Appendices If the customer attempts to retrieve messages from this mailbox, they are welcomed and asked to personalise the mailbox as soon as possible after listening their messages.

3.3 Class of Service (CoS)

Appendices Each mailbox is assigned a CoS by the Service Provider’s supervisor. The Class of Service enables the supervisor to set different levels of functionality for different groups of subscribers. There are 999 possible service packages, all of which can be given a unique alphanumeric code for simple identification.

Appendices The settings for each CoS are stored and maintained on the Central Database Function (CDF) in the Omvia system. This means that any changes to a CoS are replicated to all nodes in the system.

Appendices Using Classes of Service, Service Providers build packages through the standard X-Windows management terminal or a Web browser. Intervoice expects that, following some basic training; most administration personnel should be able to create a CoS within three to four minutes.

3.4 Languages

Appendices Omvia Messaging supports different languages for:

· the playback of prompts (announcements, information, and so on), welcome messages and greetings

· the generation of SMS messages.

Appendices The administrator can configure the application to enable a subscriber to select a different language for the mailbox on first access.

Appendices Notifications sent by Omvia Messaging will be in the same language as the mailbox is configured.


Appendices

3.5 Welcome Message and Greetings

Appendices A welcome message is non-chargeable and introduces new subscribers to the service.

Appendices A subscriber can record a personal greeting, or select a celebrity/character voice for their mailbox if the CoS allows.

Appendices A Service Provider can record the following standard greetings:

· Standard normal greeting

· Standard outdial notification greeting.

· Standard direct retrieval greeting.

3.5.1 Welcome message

Appendices The Service Provider can record a welcome message in a number of different languages and sets the number of times it is played to the subscriber. This welcome message can be recorded in a subscriber’s mailbox or as a default welcome message for the system.

Appendices A welcome message is played immediately before any system broadcast.

Appendices The administrator can also configure the application to send a welcome message by SMS to the subscriber on first access of the mailbox. This is additional to the welcome message played to the subscriber.

3.5.2 Personal and standard greetings

Appendices If the CoS allows, a subscriber can record a personal greeting for their mailbox by using the telephone user interface. This replaces a standard greeting. This is played to a caller who is depositing a message in the subscriber’s mailbox.

Appendices Additionally, using the Celebrity Greetings application (Optional), a subscriber can select a greeting from a celebrity/character voice to be played to callers. This greeting replaces a standard or personal greeting.

Appendices The Service Provider creates a standard greeting by uploading a .wav file to the administration interface and specifying:

· The name for the greeting

· Whether the associated mailbox number is appended to the greeting

· The language for the greeting.

Appendices As a minimum, a Service Provider should record a default, in appropriate languages, for each of the following types of standard greeting:

· Standard normal greeting — Played to callers that want to deposit a message in the subscriber’s mailbox.

· Standard outdial notification greeting Played to the subscriber before a message is delivered to an outdial telephone, or before notification to an outdial telephone that informs the subscriber that there are messages in their mailbox.

· Standard direct retrieval greeting Played to a subscriber during direct retrieval of messages from their mailbox, that is, when the subscriber is retrieving messages from their mailbox using their own phone. This greeting is played after any welcome message.

Appendices If neither the subscriber nor the Service Provider has recorded any type of greeting, no greetings are played.

3.6 SMS notification of full mailbox

Appendices For each mailbox, there are limits set in the CoS for the number of messages and maximum recording time allowed. If these limits are reached, the mailbox cannot receive any more messages and the subscriber is sent an SMS message to inform them that the mailbox is full.

Note: SMS notification must be enabled for the mailbox.

3.7 Broadcast Messages

Note: The ability to broadcast SMS messages through Omvia Messaging is only available if Omvia Messaging is integrated with an Omvia SMSC, and is only available to an Operator, but not Service Providers.

Appendices Broadcast messages are sent from the system to the designated subscribers and played when the subscribers retrieve messages. Broadcast messages can be used to broadcast essential system information, or marketing and advertising material.

Appendices The Omvia Messaging application supports up to five separate system broadcast messages:

Appendices Broadcast Number 1 This can be considered a high priority message, and which may be defined for a group of mailboxes using Class of Service or Mailbox Range.

Appendices Broadcast Numbers 2 to 5 These are normal priority messages that can be defined using the List definition.

Appendices It is possible for a mailbox to be a potential recipient of none, some, or all of the broadcast messages.

Appendices When the point in the call flow is reached, where a broadcast message is to be played, the system first checks whether the mailbox should receive the high priority message. If so, then this message is played. If not (because the mailbox is not in the selected range, the broadcast has expired or the subscriber has already heard the message the prescribed number of times), then the normal priority broadcasts are considered.

Appendices The normal priority broadcasts are played one per call in a cyclic fashion as long as the subscriber is eligible to hear the broadcast. The next time messages are retrieved, the next appropriate broadcast is played. On the next call, the next one is selected and so on.

3.8 Security

Appendices A supervisor can set a personal identification number (PIN) that a subscriber must use to be able to retrieve messages from their mailbox. However, the supervisor can also disable the need for a PIN if the subscriber is using direct retrieval.

Note: The system can be configured to bar specific PINs, which cannot be used by subscribers or system supervisors.

Appendices If the mailbox is not configured to need a PIN, and if the CoS allows, subscribers can enable or disable the need to use a PIN.

Appendices The system allows a caller three attempts to give the correct PIN during a single call. After the third unsuccessful attempt the system plays a termination prompt, and clears the call.

Appendices A mailbox can be locked manually by the supervisor, or automatically by the system. The supervisor can configure the period that the mailbox is locked. There is no access to a locked mailbox, even if the correct PIN is specified. The supervisor can manually unlock a locked mailbox.

Appendices The number of digits in the PIN depends on the TUI that is being used. The subscriber can change their PIN after accessing the mailbox.

Appendices The supervisor can also change the PIN from the system console but is not able to display the existing PIN. Only the supervisor can change the length of a subscriber’s PIN.

3.8.1 Forced PIN change on first mailbox use

Appendices When a new mailbox is created, it is allocated a default PIN, which is defined in the CoS. The administrator can configure the application to force the subscriber to change their PIN when they first access their mailbox. For direct retrieval from the subscriber’s own telephone, the system plays a prompt and does not allow further access unless the PIN is changed.

Appendices If the subscriber specifies a barred PIN, this is rejected and the subscriber is requested to specify a different PIN.

Appendices For indirect retrieval from a telephone that is not the subscriber’s own, the system plays a prompt telling the subscriber to use their own telephone to change the PIN, and then the call is ended.

3.9 Order of Message Playback (FIFO/LIFO)

Appendices A subscriber can configure the order in which messages are retrieved and played back as either First In First Out (FIFO) or Last In First Out (LIFO) order. For TUI 2, the subscriber can also select to have either managed or automatic message playback; TUI 1 only supports automatic playback of messages.

Appendices Read and Unread message queues can be played back as either LIFO or FIFO.

Appendices The subscriber can also select to have the details of the message (time and date of deposit, caller’s number, and so on) played before the message itself. The details that are available depend on the TUI used.

3.10 Retention of Messages

Appendices A message that has been recorded in a mailbox is saved and replayed to the subscriber during message retrieval until either:

· the subscriber deletes it, or

· its retention period has expired, in which case the system automatically deletes the message.

Appendices The supervisor sets the retention period for each Class of Service. The retention period has three separate values; for unread messages, for read messages, and for messages the subscriber has saved. This means that a Class of Service could have unread messages deleted after 72 hours, read messages deleted after 12 hours, and saved messages deleted after 240 hours.

Appendices The retention period for saved messages is restarted by the subscriber reading a saved message and then saving it again.

Note: The message retention period in a Class of Service can be set to infinity for both read and unread messages, so that messages are not deleted automatically.

3.11 Distribution Lists

Appendices Subscribers can distribute to other mailboxes messages that have been left in their mailbox. Subscribers and supervisors can create, edit and delete distribution lists. Each subscriber can have up to 9 distribution lists, each list having a unique number and up to 99 mailbox numbers.

Appendices The ability to distribute messages from a mailbox is controlled through the CoS.

3.12 Creation and Deletion of Mailboxes

Appendices Mailboxes can be created by:

· A supervisor In this case, the supervisor may associate the mailbox with any CoS that has already been configured.

· Automatically In this case, if a call to a mailbox that does not exist is received, the mailbox is automatically created. A valid mailbox number is allocated to the appropriate Omvia Messaging node and CoS.

Appendices A supervisor can define different periods for the retention of mailboxes that have been personalised (such as, a personal greeting has been recorded, or a PIN has been set), and mailboxes that have not been personalised.

Appendices Automatically created mailboxes are deleted automatically if they have not been accessed for a predefined number of days.

Appendices Mailboxes which were originally created automatically but which have the Class of Service changed by the supervisor are not deleted automatically.

Appendices A supervisor can delete any mailbox, irrespective of how the mailbox was created. When a mailbox is deleted, its statistics are also deleted.

Note: The retention period in a Class of Service for personalized mailboxes can be set to infinity, so that mailboxes are not deleted automatically.

Appendices An administrator can configure the application to send a welcome message to the subscriber by SMS when the mailbox is created.

3.12.1 Mailbox Number Ranges

Appendices Ranges of mailbox numbers and their associated data are held on specific Omvia Messaging nodes. This is so Omvia Messaging can determine on which node each mailbox resides. This is useful when allocating mailboxes to nodes or migrating mailboxes between nodes.

Appendices Specifying the first significant digits of the range includes all numbers that begin with those digits. The following table gives examples of numbers that can be included in ranges with specific significant digits.

Table 2: Examples of mailbox number ranges

Significant digits

Examples of numbers included

0

Any number beginning with 01, 02, 03, and so on.

01

Any number beginning with 0161, 01625, 01744, and so on.

0161

0161 495 1000, 0161 435 4473, and so on.

Appendices Number ranges with fewer significant digits are called superset ranges. For example, 0 is a superset range of 01, and 01 is a superset range of 0161. Ranges below superset ranges are subset ranges.

Appendices If specific subset ranges are specified, the numbers contained within that range are not then considered part of the superset range. For example, if subset 0161 were defined, any mailboxes in this subset range would not be considered part of the range 01.

Appendices To set up a subset range on a different node to its superset range, the node to which the superset range is allocated must be available.

Appendices The mailbox number range and the Omvia Messaging node can be set up if one of the following conditions applies:

· a superset does not exist

· an existing superset is on the same node and is not under migration

· an existing superset is on a different node but there are no subscribers in the specified range

Appendices Also, a mailbox number range can only be migrated if the node containing the range is available to the application.

Appendices

Appendices

3.13 Timezones

Appendices Under certain circumstances, the Omvia Messaging application adjusts the time and date of voice and fax messages to take into account different timezones and associated daylight savings.

Appendices A timezone represents the number of hours in which a location is either in front of, or behind, Greenwich Mean Time, GMT (which is equivalent to Universal Co-ordinated Time, UTC).

Appendices Daylight saving represents any further hours added or removed to the timezone in accordance with local daylight saving for the current date.

Appendices The application is preset with all timezones with each having:

· a unique name;

· the number of hours difference (either positive or negative) of the timezone from GMT;

· the dates between which any further adjustments are needed for daylight saving and the associated adjustments (either positive or negative).

Appendices Each Class of Service, and all subscribers in that Class of Service, are associated with one of the named timezones. Each subscriber can select another timezone that suits his/her preference if required.

Appendices The application may convert the time and date of messages in each of the following cases:

· Voice or fax message playback

When either a voice or fax message is being played back to a subscriber, he/she can choose to hear the details of the message. These details include the time and date of the deposit of the message, and the time and date will have been converted (if required) to match the subscriber’s timezone and any adjustments for daylight saving.

· Recording a voice message for later delivery

If, when depositing a voice message, the subscriber specifies a later time and date when the message is to be delivered the application converts the delivery time of the message in accordance with the depositing subscriber’s timezone and any adjustments for daylight saving.

3.14 Operators and Service Providers

Appendices The relationships are:

· Operator = Wholesaler

· Service Provider = Retailer

Appendices Operators (Wholesalers) run Omvia Messaging as a service. However, they can also operate the service on behalf of multiple Service Providers (Retailers), who can then provide a customized, own-branded, service to other subscribers.

Appendices A Service Provider can only be associated with one Operator. Each Service Provider exclusively owns one or more Classes of Service, and each CoS has one or more subscribers.

Appendices

Figure 3: Wholesalers and retailers

3.15 Notification of Messages

Appendices A subscriber can be notified that there are voice and/or fax messages in their mailbox by the following methods:

· Outdial

· Outdial delivery

· Pager

· SMS

Appendices Notification is triggered by a new voice or fax message being deposited in the subscriber’s mailbox.

Note: Notification is not triggered by abandoned call alert messages; the details of this type of message are only attached when the subscriber is notified of the details of voice or fax messages.

Appendices Using the TUI, the user can enable notification and the type of notification. However, the subscriber can enable one type of outdial (Outdial or Outdial delivery), not both. The subscriber’s CoS defines the methods that are available. If more than one method is available, the CoS defines the order in which the methods are used.

Appendices The Operator or Service Provider can configure a list of barred telephone numbers to which outdials are not permitted.

3.15.1 Outdial

Appendices Omvia Messaging calls a configured number, which is usually the subscriber’s telephone. When the call is answered, a prompt announces the service, and that there are unread voice and/or fax messages in the mailbox, but not the number of messages.

Appendices The subscriber can configure a telephone number for this feature through the TUI.

3.15.2 Outdial delivery

Appendices Omvia Messaging calls a configured number, which is usually the subscriber’s telephone. When the call is answered, a prompt asks for a PIN. If a valid PIN is entered, the application announces the number of unread voice and/or fax messages in the mailbox, and then plays the messages. The controls available to the subscriber during this Direct Retrieval depend on the TUI used.

Appendices The subscriber can configure a telephone number for this feature through the TUI.

3.15.3 Pager

Appendices This is a user-configurable option, depending on which TUI is used. A subscriber can configure the mailbox to outdial to:

· A voice pager, on receipt of a voice message.

The subscriber can configure a pager number for this feature.

· A fax pager, on receipt of a fax message.

3.15.4 SMS

Note: This is only available on GSM or PCN networks.

Appendices The application sends an SMS message to a configured number, which is usually the subscriber’s telephone. The message contains details of the number of unread voice, fax or abandoned call alert messages in the mailbox.

Appendices Additionally, the system can be configured to send SMS messages when the subscriber first accesses their mailbox (welcome message), and as notification that the mailbox is full.

Appendices An administrator can configure the text and information in these SMS messages using templates in the administration interface. The administrator can also create groups containing templates of a similar type.

Appendices The Calling Line Identity (CLI) of the last message deposited will be sent as part of the notification message.

3.15.5 Combining notification types

Appendices The subscriber can enable notification by outdial, pager and SMS, but only one type of outdial (Outdial or Outdial delivery) can be used in the combination. The Operator or Service Provider configures in the CoS the order that the types of notification are attempted.

Appendices If the first type of notification is successful, the other types are not attempted. If the first type of notification fails, after a configured delay, the next type is attempted. When all types of notification have been attempted, after a configured time, the application attempts the types in the same order. The Operator or Service Provider configures the number of times that this process is retried.

Appendices All failed attempts raise an alarm on the Operators or Service Provider’s administration interface.

3.16 Generation of Call Data Records (CDRs)

Appendices The application generates a CDR (Call Data Record) in XML format, and contains various details of the call, such as outdial methods, from which TUI mode a mailbox was called, and so on. Additionally, depending on a customer’s requirements, the Application Data Transport Interface (ADTI) component of the Omvia Platform can be configured to define:

· the frequency and method used to store CDRs in a file.

· the method for transferring the file(s) to external servers.

Appendices The ADTI component can be configured to convert files from XML into another format (for example, CSV), but this would be considered to be customer-specific, and therefore beyond the scope of this current release.

3.17 Migration of Mailboxes

Appendices To equalize the load on a system, an Operator or Service Provider can configure the system to move a range of mailboxes between Omvia Messaging nodes; known as source and destination nodes.

Appendices During migration, the Operator or Service Provider cannot create, delete or modify any mailboxes in the range being migrated. No messages are lost during migration, but message notification is not processed until after migration. If either or both nodes lose communication with the CDF, the migration process completes, but the mailbox range is marked as being in migration until communication between the node(s) and the CDF is restored.

Appendices There are two phases in the migration process:

Appendices Phase 1 (Initial copy) — A new copy of each mailbox, including any personalisation, is created on the destination node. Auto-creation is disabled in the source node. When phase 1 is complete, an alarm is raised on the administration interface, and the system automatically enters phase 2.

Note: An Operator or Service Provider can abort a migration during this phase only. An alarm is raised on the administration interface when a migration is aborted. Any mailboxes already created on the destination node are deleted.

Appendices Phase 2 (Secondary transfer) — The mailbox statistics and messages are moved to the destination node, and the migrated mailboxes are deleted from the source node.

3.18 Roaming Bureau

Appendices If a subscriber is outside the Operator’s/Service Provider’s network, they can still access their mailbox on the Omvia Messaging system.

Appendices This function is only supported by some Operators/Service Providers, and the way Roaming Bureau operates is project-specific.

Appendices Mailboxes cannot be automatically created using Roaming Bureau.

3.19 Call Return

Appendices The subscriber can use the TUI to make an outgoing call.

Appendices On the system, this function uses the same ports on a TRM that are used for notification; these are known as outdial ports. The outdial ports must be allocated on each TRM for this function to work. For example, a single 30 port trunk could be split into 26 incoming ports and 4 outdial ports. Call Return is given priority over notification activities.

Appendices The subscriber is given three attempts to enter a valid, unbarred number. Any failure of a Call Return raises an alarm on the administration interface.

3.20 Blacklisted and Barred Numbers

Appendices Blacklisted numbers relate to regulatory requirements with respect to automatic outdialling equipment. A blacklist prevents calls being made to any telephone number at intervals less than a specified regulatory minimum. For example, it is possible to configure a number of mailboxes on the Omvia Messaging system to dial the same number; the blacklist prevents the system from making calls to the number more frequently than the regulations allow.

Appendices The Operator/Service Provider sets the interval between outdials.

Appendices Barred numbers cannot be entered into a mailbox, either from the administration interface or the telephone network. The Operator/Service Provider defines the barred numbers for the whole application.

Appendices Only the first digits need to be specified for a range of numbers to be barred. For example, specifying 123 prevents the use of any number beginning with these digits.

Appendices The attempted use of barred numbers raises an alarm on the administration interface.

3.21 Celebrity Greetings (optional)

Appendices This optional application enables subscribers to select a celebrity/character voice as a personal greeting for callers to their mailbox. This greeting then replaces the existing standard or personal greeting in the mailbox.

Appendices Wholesalers or retailers upload .wav files onto the Omvia Messaging R7.3 system and configure the application through the administration interface.

4. Omvia Messaging Applications

4.1 Omvia and Intervoice Value Added Services

Appendices The Intervoice Omvia platform is a multi-application platform that is capable of running a number of value added services concurrently. In addition to the Omvia Messaging, these services include:

· Omvia SMSC — Supports text messaging on GSM and 3G networks, delivery of messages through ESME, and message waiting notification.

· Omvia Call Notify Missed call notification service for non-voice mail subscribers.

· Omvia Celebrity Greetings Subscribers can select a greeting by a celebrity voice for callers to their mailbox.

· Omvia Payment A cashless prepaid charging service for messaging, secure m-commerce, wireless Internet, and multimedia portal applications for limiting liability.

· Omvia Portal A voice centric service for personalised information and dynamic live applications.

Appendices It is possible to deploy these applications on a common platform for the most efficient deployment of value added services in new networks. The applications can also be supplied standalone, where most cost effective deployment is required in larger networks. The Omvia Messaging can be used with the OMX and OMX applications to provide SMS connectivity.

4.2 Integration with Omvia SMSC

Appendices The success of voice messaging and call completion services largely depends on the ability of the network and the voice messaging system to notify subscribers that there are messages waiting for them. The use of SMS notification can be used in conjunction with other forms of message notification, such as outdial, pager and e-mail.

Appendices In many cellular fixed networks, message notification has developed into a sophisticated call-back service, where the system detects that the subscriber is available, and immediately notifies them and delivers the message(s). However, the availability of this type of notification depends on the network.

Appendices Omvia SMSC functionality can be used within the Omvia Messaging application to provide message notification as either an SMS message, or as a call-back function.

5. Omvia Messaging Implementation

Appendices The Omvia multi-application platform has been designed to meet the requirements of a high capacity, high volume public network service. For management and administration, Omvia and the applications and services that run on it, including Omvia Messaging, operate as an integrated system.

5.1 System Architecture

Appendices The architecture of the Omvia Messaging system is shown below.

Appendices

Figure 4: Omvia system architecture

Appendices The Messaging application runs on the administration processor (AP) or control processor (CP). In small systems, the CP and AP are located in the same physical hardware. The CP/AP connect to the customer’s network management center (NMC) by a local area network (LAN), and configuration and administration are controlled through X-terminals or Web browsers.

Appendices Telephony resource modules (TRMs) provide a highly responsive platform for the TUI. They connect to the telephony network by E1 or T1 trunks. The signalling protocol unit (SPU) handles the signalling between the system and the telephone network; channel associated signalling (CAS), common channel signalling (CAS) and signalling system number 7 (SS7) user part (UP). However, to support SS7, the system must contain an optional SS7 server. Telephony information is passed between the SPU(s) and TRM(s) for call control.

Appendices A notification processor (NP) hosts the Short Message Service Centre (Omvia SMSC), which is an optional feature that controls the SMS notification features of Omvia Messaging. In small configurations it is also possible to run the notification processor functions on the control processor (CP) element of the Omvia platform.

Appendices In multi-node systems, a central database function (CDF) is used to distribute common data to the CP(s) on each node. A CDF can be combined with one CP on an individual node, or it can be a separate node on the system, known as a central database node (CDN).

Appendices The system uses one or more RAIDs (redundant array of independent disks) to provide resilient storage for system data. Each RAID is connected to a CP.

5.2 Administration of Omvia Messaging

Appendices The Omvia Messaging administration interface has the following options:

Table 3: Administration of Omvia Messaging

Menu option

Sub-menu option

Action

Performance

Mail Performance Monitoring

This provides message waiting information.

Mail Traffic Management

This provides Traffic Management information.

Maintenance

Mail Alarm Surveillance

This provides a view of system alarms and their status.

Configuration

Mail Parameters

Messaging parameters:

· Messaging parameters (including the length of message that dictates if a call is classed as a message deposit or an abandoned call alert).

· auto-create parameters.

Notification parameters:

· interval parameters

· barred numbers

· message waiting intervals (optional)

· notification template groups

· notification templates.

Barred PIN numbers.

Mailbox

Create Mailbox

The administrator can create a new mailbox.

Modify Mailbox

The administrator can modify an existing mailbox.

Delete Mailbox

The administrator can delete an existing mailbox.

Voice/Fax Message Details

The administrator can view the details of the voice/fax message.

View Mailbox

The administrator can view the details of an existing mailbox.

CoS

Create CoS

The administrator can create a new Class of Service. This also includes a parameter to enable/disable the capture and retrieval of n details in the mailbox.

Modify CoS

The administrator can modify an existing Class of Service.

Delete CoS

The administrator can delete an existing Class of Service.

Copy CoS

The administrator can copy the Class of Service.

View CoS

The administrator can view an existing Class of Service.

Standard Greeting

Create Standard Greeting

The administrator can create a Standard Greeting.

View Standard Greetings

The administrator can view existing Standard Greetings.

Delete Standard Greeting

The administrator can delete an existing Standard Greeting.

System Broadcast

Modify Standard Broadcast

The administrator can modify Standard Broadcasts.

Delete Standard Broadcast

The administrator can delete Standard Broadcasts.

Welcome Message

Create Welcome Message

The administrator can create a new Welcome Message.

View Welcome Messages

The administrator can view existing Welcome Messages.

Delete Welcome Message

The administrator can delete an existing Welcome Message.

Utilities

Message Upload

The administrator can upload .wav files.

SMS

SMS Broadcast

The administrator can create an SMS text message

Routing Administration

View Routing

The administrator can view routing information for mailbox number ranges and nodes.

Create Routing

The administrator can create routing details for mailbox migration.

Modify Routing

The administrator can modify existing routing details for mailbox migration.

Delete Routing

The administrator can delete existing routing details for mailbox migration.

Monitor Migration

The administrator can monitor the progress of a mailbox migration.

Pause/Resume Migration

The administrator can pause and resume a mailbox migration that is in progress.

Abort Migration

The administrator can abort a mailbox migration that is in progress.

5.3 Alarms

Appendices The system provides integrated Omvia alarms for major system component failures, such as SPU, CDF, CP failures. Other problems, such as performance thresholds and mailbox problems are also assigned alarms. In addition to indicating the alarm condition through the standard Omvia alarm system, alarm messages are sent to a short list of MSISDNs by SMS. A Web page enables the service provider to specify the MSISDNs to which alarm SMSs are to be sent. This includes a test button, which enables the facility to be tested by sending a TEST message.

5.4 Call Detail Records (CDRs)

Appendices Omvia Messaging R7.3 produces a CDR for various types of transaction. A third-party billing and customer care system can access these CDRs to allow charging and customer care functions to be properly supported.

Appendices A CDR is generated for the following types of call:

· a mailbox is called in Retrieval mode

· a mailbox is called in Deposit mode

· an outdial notification call is made

· an outdial delivery notification is made

· a call return is made

· a fax delivery outdial is made.

Appendices Each CDR contains the following information:

· the customer ID

· the subscriber’s mailbox number

· the number of the TRM that handled the call

· the number of the port on the TRM that handled the call

· the time and date when the call began

· the time and date when the call ended

· the time and date when the call was answered

· the time and date when the call was terminated

· a number representing the type of call (voice, fax, abandoned call alert, and so on)

· the status of the call (such as, success, busy, mailbox empty, and so on)

· the number used for an outdial call

· the number of times a call return was made during the original call

· the number of times a call was made to a non-subscriber during the original call.

5.5 Statistics

The following statistics are collected as a snapshot.

· Number of Mailboxes

  • Number of Mailboxes in each Class of Service
  • Number of Mailboxes with Personal Greeting
  • Number of Mailboxes with PIN changed from default
  • Number of Voice Messages
  • Number of Abandoned Calls
  • Average Voice Message Length (seconds
  • Longest Voice Message (seconds)
  • Number of Fax Messages
  • Number of mailboxes not accessed
  • Number of mailboxes not accessed 11–15
  • Number of mailboxes not accessed 7–10
  • Number of mailboxes with tutorial count = 0

The following Daily Usage statistics are also collected

  • Number of incoming Direct Deposit calls
  • Total duration of incoming Direct Deposit calls (minutes)
  • Number of incoming Indirect Deposit calls
  • Total duration of incoming Indirect Deposit calls (minutes)
  • Number of incoming Direct Retrieval calls
  • Total duration of incoming Direct Retrieval calls (minutes)
  • Number of incoming Indirect Retrieval calls
  • Total duration of incoming Indirect Retrieval calls (minutes)
  • Number of Outdial Notification calls
  • Total duration of Outdial Notification calls (minutes)
  • Number of Pager Notification calls
  • Total duration of Pager Notification calls (minutes)
  • Number of Outdial Delivery calls
  • Total duration of Outdial Delivery calls (minutes)
  • Number of Non-Subscriber Outdial calls
  • Total duration of Non-Subscriber Outdial calls (minutes)

  • Number of Call Return calls
  • Total duration of Call Return calls (minutes)
  • Number of Fax Delivery calls
  • Total duration of Fax Delivery calls (minutes)
  • Number of Mailboxes Auto Created
  • Number of Mailboxes Auto Deleted
  • Number of Unread Messages Deleted

5.6 Redundancy

Appendices The high availability option provides tolerance to failure for the Servers in a node by providing a second server configured as a standby processor. The second server takes over the system operation in the event of a failure of the on-line system. The control processors share a common database on a redundant array of independent disks (RAID) storage, which is dual ported into each one.

Appendices Redundant data connections and routing devices are supplied to ensure no single point of failure for the data backbone.

Appendices An additional private Ethernet connection allows each server to monitor the ‘health’ of the other. The high availability option is only available on systems equipped with a RAID subsystem because of the need for separate SCSI links from each Control Processor to access the database and message storage.

Appendices Each Telephony, Resource and Web server is connected to both Control Processors so that whichever is active, each network or resource server can communicate with the correct Control Processor.

5.7 Modular Growth

Appendices The Omvia system allows for the appropriate processing capacity to be configured for each application. This is because Omvia is based on Sun SPARC scaleable architecture processing. The signalling paths can also be configured in a modular way by the addition of signalling links as required. Other system resources are deployed in an N+1 configuration to ensure availability of resources under single point of failure conditions.


Appendices

6. System Sizing for Omvia Messaging

This section will cover the system sizing and configuration of Omvia Messaging systems. The figures given below are based on an assumed average traffic figure per subscriber of 0.878 mErlang per subscriber. Actual voicemail traffic will vary from network to network. System sizing calculations will need to be carried out on a per network basis

6.1 Stand alone Configurations

Appendices Stand alone Messaging applications based on Voicemail and optionally Faxmail functionality can be deployed across a wide range of system sizes, supporting tens of thousands to tens of millions of mailboxes.

6.1.1 Omvia Lite

Appendices Voice Mail can be deployed on an Omvia Lite solution where all the processing is carried out on a single processor. The only additional components required are Media Servers to support circuit switched ports and the Signalling Processor Unit to support SS7 signalling. The table below shows related capacity and configuration.

Appendices

Appendices Configuration

Appendices 60 Port

Appendices 120 Port

Appendices 60 port HA

Appendices 120 port HA

Appendices CP

Appendices Netra 240 single

Appendices Netra 240 single

Appendices 2 x Netra 240 single

Appendices 2 x Netra 240 single

Appendices RAID

Appendices 36Gb

Appendices 36Gb

Appendices 36Gb

Appendices 36Gb

Appendices Media Servers

Appendices 1

Appendices 1

Appendices 2

Appendices 2

Appendices SPU

Appendices 1

Appendices 1

Appendices 2

Appendices 2

Appendices SS7 SDL’s

Appendices 4

Appendices 4

Appendices 8

Appendices 8

Appendices No of Subs@0.878mErlang/sub

Appendices 46K

Appendices 105K

Appendices 46K

Appendices 105K

Appendices Traffic Capacity

Appendices 40.8 Erlang

Appendices 92.63 Erlang

Appendices 40.8 Erlang

Appendices 92.63 Erlang

Appendices Typical Availability

Appendices 99.95%

Appendices 99.95%

Appendices 99.995%

Appendices 99.995%

Appendices

Appendices

Appendices

Appendices

Appendices

6.1.2 Single Node Omvia Messaging

Appendices

Appendices Voice Mail can be deployed on an Omvia solution where distributed processing is carried out on one or more processors. The only additional components required are Media Servers to support circuit switched ports and the Signalling Processor Unit to support SS7 signalling. The table below shows related capacity and configuration.

Non HA

Appendices Configuration

Appendices 240 Port

Appendices 480 Port

Appendices 720 port

Appendices 960 port

Appendices CP

Appendices Netra 240 Dual

Appendices Netra 240 Dual

Appendices Netra 240 Dual

Appendices Netra 440 Quad

Appendices RAID @ 10hours per 1K subs

Appendices 36Gb

Appendices 72Gb

Appendices 108Gb

Appendices 144Gb

Appendices Media Servers

Appendices 2

Appendices 4

Appendices 6

Appendices 8

Appendices SPU

Appendices 1

Appendices 1

Appendices 1

Appendices 1

Appendices SS7 SDL’s

Appendices 4

Appendices 4

Appendices 4

Appendices 4

Appendices No of Subs@0.878mErlang/sub

Appendices 227K

Appendices 480K

Appendices 739K

Appendices 1M

Appendices Traffic Capacity

Appendices 200 Erlang

Appendices 422 Erlang

Appendices 649 Erlang

Appendices 878 Erlang

Appendices Typical Availability

Appendices 99.95%

Appendices 99.95%

Appendices 99.95%

Appendices 99.95%

Appendices

HA

Appendices Configuration

Appendices 240 Port

Appendices 480 Port

Appendices 720 port

Appendices 960 port

Appendices CP

Appendices Netra 240 Dual

Appendices Netra 240 Dual

Appendices Netra 240 Dual

Appendices Netra 440 Quad

Appendices RAID @ 10hours per 1K subs

Appendices 36Gb

Appendices 72Gb

Appendices 108Gb

Appendices 144Gb

Appendices Media Servers

Appendices 3

Appendices 5

Appendices 7

Appendices 9

Appendices SPU

Appendices 2

Appendices 2

Appendices 2

Appendices 2

Appendices SS7 SDL’s

Appendices 8

Appendices 8

Appendices 8

Appendices 8

Appendices No of Subs@0.878mErlang/sub

Appendices 227K

Appendices 480K

Appendices 739K

Appendices 1M

Appendices Traffic Capacity

Appendices 200 Erlang

Appendices 422 Erlang

Appendices 649 Erlang

Appendices 878 Erlang

Appendices Typical Availability

Appendices 99.995%

Appendices 99.995%

Appendices 99.995%

Appendices 99.995%

Appendices

6.1.3 Multi-node Omvia Messaging

Appendices

Appendices Voice Mail can be deployed on multiple single nodes of Omvia Messaging. When deployed in this configuration an additional element known as the Central Data Node is required to store common data and provide communication mechanisms between the nodes, for distribution lists and mailbox migration. The table below shows related capacity and configuration.

Non-HA

Appendices

Appendices Configuration

Appendices 4 Nodes

Appendices 8 Nodes

Appendices 15 Nodes

Appendices 30 Nodes

Appendices Node Traffic Capacity

Appendices 878 Erl

Appendices 878 Erl

Appendices 878 Erl

Appendices 878 Erl

Appendices Node Storage Capacity

Appendices 144Gb

Appendices 144Gb

Appendices 144Gb

Appendices 144Gb

Appendices SS7 Links

Appendices 16

Appendices 32

Appendices 60

Appendices 120

Appendices

Appendices

Appendices

Appendices

Appendices

Appendices No of Subs@0.878mErlang/sub

Appendices 4M

Appendices 8M

Appendices 15M

Appendices 30M

Appendices Traffic Capacity

Appendices 3512 Erlang

Appendices 7024 Erlang

Appendices 13170 Erlang

Appendices 26340 Erlang

Appendices Typical Availability

Appendices 99.95%

Appendices 99.95%

Appendices 99.95%

Appendices 99.95%

HA

Appendices

Appendices Configuration

Appendices 4 Nodes

Appendices 8 Nodes

Appendices 15 Nodes

Appendices 30 Nodes

Appendices Node Traffic Capacity

Appendices 878 Erl

Appendices 878 Erl

Appendices 878 Erl

Appendices 878 Erl

Appendices Node Storage Capacity

Appendices 144Gb

Appendices 144Gb

Appendices 144Gb

Appendices 144Gb

Appendices SS7 Links

Appendices 16

Appendices 32

Appendices 60

Appendices 120

Appendices

Appendices

Appendices

Appendices

Appendices

Appendices No of Subs@0.878mErlang/sub

Appendices 4M

Appendices 8M

Appendices 15M

Appendices 30M

Appendices Traffic Capacity

Appendices 3512 Erlang

Appendices 7024 Erlang

Appendices 13170 Erlang

Appendices 26340 Erlang

Appendices Typical Availability

Appendices 99.995%

Appendices 99.995%

Appendices 99.995%

Appendices 99.995%

6.2 Multi-application Configurations

Appendices Configuration of Multi-application systems is complex, as the processing power required by each application has to be matched to node capacity. For further details of system sizing, please contact the Intervoice sales team.

Appendices The following applications may be deployed together on an Omvia solution.

· Voice and Fax Mail

· Voice and Fax Mail with Abandoned Call Alert

· SMSC

· Call Notify

· Celebrity Greetings

6.2.1 Omvia Lite

Appendices Multiple applications can be deployed on an Omvia Lite solution where all the processing is carried out on a single processor. The only additional components required are Media Servers to support circuit switched ports and the Signalling Processor Unit to support SS7 signalling.

6.2.2 Single Node Omvia Messaging

Appendices Multiple applications can be deployed on an Omvia solution where distributed processing is carried out on one or more processors. The only additional components required are Media Servers to support circuit switched ports and the Signalling Processor Unit to support SS7 signalling.

6.2.3 Multi-node Omvia Messaging

Appendices Multiple applications can be deployed on multiple single nodes of Omvia Messaging. When deployed in this configuration an additional element known as the Central Data Node is required to store common data and provide communication mechanisms between the nodes, for distribution lists and mailbox migration.


7. Network Configuration for Messaging

Appendices The network configuration for Omvia Messaging is briefly described below. Set-up of the network configuration may vary from network to network dependent on equipment type and operator preferences.

7.1 HLR Divert Destinations

Appendices Divert destinations are set in the Network HLR. These divert destinations are specified for a number of conditions encountered when trying to set up a call to a mobile subscriber.

7.1.1 Voicemail

Appendices The conditions which may result in a call being routed to a Voicemail system are as follows:

· Busy

· Ring No Answer

· Network Congestion

· Subscriber Out of service or switched off

7.1.2 Call Notify

Appendices For network subscribers who do not subscribe to a voicemail service an alternative service can be offered called Call Notify, which allows subscribers to be notified of missed calls. This service is only intended to be active when the subscriber’s handset cannot take calls. The reason for this being that, the handset usually has the capability to recognize and store information on missed calls.

Appendices The conditions which may result in a call being routed to a Call Notify are as follows:

· Network Congestion

· Subscriber Out of service or switched off

Appendices

7.2 Fallback destinations

Appendices

Appendices It is desirable, where an HA configuration of Voice Mail is deployed to have an alternate destination address for those calls. If calls to the primary destination fail, then the network can be configured to route those calls to an alternate destination. On an HA system two separate SS7 ISUP destination addresses are available.

7.3 Destination Hunt Groups

Appendices Within each destination it is desirable to control the way in which calls are allocated to system ports. Several configurations are possible, but the two most popular are Grow from port 1 and Cyclic. If Grow from port 1 is used traffic is concentrated on low numbered ports. In Cyclic each port available is used in turn. The preferred configuration for voice mail is cyclic. This minimizes the impact of port failures at the switch and the Omvia system.

7.4 Multi-node Configurations

Appendices Where Multiple Omvia Messaging nodes are deployed the destinations used from the HLR will need to be segmented by subscriber to divert calls to the specific node where the subscriber’s mailbox resides.


Appendices

Appendix A Abbreviations

Acronym

Definition

CDF

Central Database Function

CDN

Central Database Node

CDR

Call Data Record(s)

CLI

Calling Line Identity

DTMF

Dual Tone Multi Frequency

HLR

Home Location Register

IMSI

International Mobile Subscriber Identity

MSISDN

Mobile Subscriber Integrated Service Digital Network Number

PIN

Personal Identification Number

SMS

Short Messaging Service

TCP/IP

Transmission Control Protocol/Internet Protocol

TTS

Text To Speech

COS

Class of Service

GSM

General System Mobile standard for digital mobile services

IVR

Interactive Voice (or Video) Response

OMX

Omvia Media eXchange

PIN

Personal Identification Number

SMPP

Simple Message Passing Protocol

SMTP

Simple Mail Transfer Protocol

SMS

Short Message Service

SMSC

Short Message Service Centre

TUI

Telephony User Interface

VUI

Voice User Interface

vXML

Voice eXtensible Markup Language

XML

eXtensible Markup Language

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: