Download This File                   Download All Documents                 Go to Home Page

OMNIBOX Benefits and Features

OmniBox Products:

Basic Package:

• Benefit Description:

• Tandem Switching

• Software Answer Supervision at minimum cost

• Protocol conversion

• Call logging

• Real-time monitoring

• Call monitoring through analog lines

• Operator paging upon specified alarms

• Automatic channel exclusion after reaching failure count threshold.

• Hung trunk detection

• Features:

• Call progress analyzer

• Dynamic assigner of Voice resources

• Protocol support: Analog; T1 Robbed bit and PRI; E1 CAS and CCS, SS7/C7 (Optional)

• Two way trunks (Optional)

• Watchdog: Failing channel exclusion ; low traffic and completion rate alerting

• Traffic flow scheduler

• Dialed number router

• Prioritizer by provider and by Client

• Hung trunk detector

• Digit translator by route

• The OmniMonitor, graphic real-time monitoring over the Internet

• Test line state machine

• Local real-time SQL Server Call Detail Records

• Over the Internet real-time Call Detail Record replicator

IVR Platform

• Benefit Description:

• Handles PIN controlled access for Invoiced accounts.

• Handles real-time billing for prepaid accounts

• Handles full calling card operation

• Protection from hackers

• Features

• All Basic Package features

• PIN verification state machine

• Time controlled call state machine

• Multiple language support

• ANI black list

• System for Payphone detection and charge

• Real-time billing system

• Calling card generator

Call-Back Platform

• Benefit Description:

• Handles call-back service operations.

• Features

• All Basic Package features plus the IVR platform features

• Trigger call back-caller

Custom Functions

• Benefit Description:

• Customized long distance services

• IVR for Information services

• Predictive dialing (Telemarketing)

• Test traffic generation (Blasting)

• Features

• All Basic Package features plus the IVR platform features

• Traffic generator (OmniBlaster)

• State machine developing system

• #include custom programming service

OmniBox is flexible, it also allows to combine several products in the same box. Every inbound trunk group may have a different function, say the first three T’s (or E’s) are switching while the fourth is an IVR for prepaid cards and the fifth is handling a Call-Back service. Also protocols may be combined, for example, the first 23 channels are ISDN with NI2 protocol, the next 48 are T1 robbed bit, 16 analog lines, and the rest are E1’s with doing SS7 protocol.

It runs under WinNT/WIN 2000 and uses Dialogic Global Call Dialogic Technology that allows support for every protocol in every country in the world. 

The limit to the maximum number of channels that an OmniBox system can handle is…not an easy spec anymore, not since the boxes can be interconnected. Several technologies are available that can provide Virtual Circuits between boxes:

·        Amtelco XDS optical ring technology;

·        Intel Ethernet packet switching;

·        IML ATM technology.

Any of the above can handle thousands of Virtual Circuits, for example, one with 5 OmniBox’es with an Amtelco ring, can provide a system with 150 spans. You may still keep adding boxes, Amtelco claims that up to 40 have been successfully interconnected. So, an OmniBox System can work as a pretty big switch, like an EXCEL, NORTEL, ERICSON… you know…the “big ones”, for a lost less, allowing easy growth as you go up in the business.

OmniBox’es may be provided in rugged rack mount Advantech industrial computers that can harbor all the allowable dialogic boards, but it may also be installed in alternative platforms upon request.

OmniBox is a database driven application. For its operation, it uses a local Microsoft's SQL Server. OMNIBOX can deliver CDR's (Call Detail Record) in real time to a remote database server through Internet or any private IP network.  The CDR's have a flexible format that will adapt with ease to any billing system. #include also offers a billing and statistics package based on ACCESS and SQL Server that are likely to suit your needs. 

Basic Package

Switching

Omnibox can work behind a switch to provide Software Answer Supervision, Hung Trunk detection, Billing, Monitoring, etc. but it can also take over the switching tasks. OmniBox can do everything a switch does: dynamic routing, digits translation, priority routing, SS7...etc. Only that it's cheaper and a lot easier to manage.

If you are bypassing and/or doing a prepaid/invoiced operation using VoIP, your best deal is to use an OmniBox to do your switching, software answer supervision and IVR between, for example, your Cisco's 5300 and the PSTN network..

Software Answer Supervision

The signal that informs the client switch that the connection has been established and so, it may start charging the caller, is known as Hardware Answer Supervision. OMNIBOX can provide Answer Supervision when this signal is inexistent or unreliable.  For example, this is the case long distance carriers face when links terminate in analog trunks that don’t provide polarity reversal answer supervision

When enabled, OmniBox will ignore Hardware Answer Supervision signaling from the outbound channel and will deliver the correct Answer Supervision signal to the Client Switch by doing Call Progress Analysis. Only upon detection of voice, FAX or recordings, this is known as Software Answer Supervision. To accomplish this task, OmniBox must recognize SIT tones, busies and rings, but these may be quite different for different destinations. Detection of these call progress tones can be fine tuned for every group of channels, allowing pretty good accuracy.

When doing Software Answer Supervision, OmniBox learns a lot about every call and so it can report in real time, not just a yes or no completion status, but details like if it was voice or recording, or if it failed for busy, ring no answer, etc.

Dynamic Assignment of Voice Resources

To do call progress analysis OmniBox uses “Voice Resources”. These voice resources are implemented with special chips known as Digital Signal Processors or DSP’s, which are the most expensive components in the Dialogic boards. Voice resources are also needed to do functions like getting DTMF of MF digits, dialing, recording messages and playing back prompts. OMNIBOX has the intelligence for pooling these voice resources instead of doing a fixed assignments like most applications in the market. In other words, you won’t need to buy a voice resource per channel. A voice resource costs ~$108 while a digital channel will go for ~$46. If you need, say... 10 T's (10 inbound + 10 outbound) Doing a fixed assignment of 1 resource/ch, will be 20x24x(108+46) = $ 73920. The voice resources are used only while connections are getting established (~30 seconds) and not during the conversation (~5 minutes) so, the voice resource usage to channel usage is 1 to 10. Pooling resources in a very conservative way, this is using 72 voice resources for all the system will bring hardware costs down to: 64*108 + 20*24*46 = $29856.  This is not just a small saving, we are talking LESS THAN HALF!

OmniBox V4.30 and higher, can even do further savings. Dialogic offers cheaper boards with limited voice resources, these can't playback prompts or record messages, but they can do everything else. These resources are good enough for Software Answer supervision, protocol conversion, hung trunk detection, etc. New versions allow to use resources of both types in the same box being smart enough as to pick the right one for the job at hand..

Protocol Conversion

OmniBox supports:

SS7 (MTP+ISUP) in most of its many flavors ANSI, ITU, C7…;

ISDN PRI in most of its many flavors NI2, 4ESS, 5ESS, DMS, EURO ISDN…;

T1 Robbed bit with all its feature groups and start protocols.;

E1 MFR2 *;

Analog;

Since any of the protocols can be set on either inbound or outbound spans, you can use OmniBox to convert from anything to anything.

* Supported but not recommended. MFR2 does all its signaling in-band with preemptive tones. This requires that a voice resource be attached to each R2 channel full time impeding the voice resource pooling that saves so much money. Any other E1 protocol available would be a better choice.

Call Logging

You can use an OMNIBOX to generate CDR’s (Call Detail Record) for technical statistics or for billing purposes. These can be stored locally at the Database that resides in the same computer as the platform or these records could be replicated into the company’s master database in a different city or even country using an Internet connection. The most common option is not to store locally, that way the database at the OMNIBOX computer stays ‘light weight’, but to replicate into the database where the statistics and billing are processed. 

When the call is connected, it is partially logged, this means that all the information available is stored temporarily in a a table (Log_PartialCall). When the call is finished the time, prices and final result are added to the record and then is stored permanently or sent for replication. This means that if the power goes off or the OmniBox is unloaded for any reason, no call goes without its CDR. 

The CDR has the following fields:

CDR Replication over the Internet

The OMNIBOX replication uses a proprietary mechanism that works as follows.

·         CDR information goes in the PendingReplication table at the end of every call.

·         The Source Replicator application takes oldest record and sends it by UDP over the Internet

·         The Destination Replicator Application receives the CDR and attempts storing it in the company’s database through a stored procedure called proc_CDR.

·         If the transactions is successful, an acknowledge message will be sent back to the Source Replicator.

·         Upon receiving acknowledge, the Source Replicator will erase the record from the Pending Replication table and go for the next if any. If there’s no acknowledge message before timing out or a Not Acknowledge is received, the record will be resent.

This method allows for long interruptions of the IP network, since the local database can store a huge count of records and the replication rates are many times faster than the normal rate at which CDR's are generated. Also, in the case of long interruptions, more than one Source Replicator can be used in case you need to speed up the update.

The stored procedure proc_CDR can store the call information received from the Source Replicator  in whatever format is required by a third party billing system. But, make no mistake, it is not that you need an expensive third party billing application, the OmniBilling provides a set of reports, forms and queries to do statistics, invoices and prepaid card number generation. These include cross-tab summaries, pie charts, attempts, completion rates and minutes v/s time graphics, billing and provider debt reports.

More on the subject.

Complete database Replication over the Internet

It is quite common that the office, where administration goes on, is at a different location from that of the switch site. When running a wholesale business, in other words selling bulk minutes to a number of destinations, the main data transfer between the OmniBox and the billing system is related to the CDR's. In a lesser scale, information for new clients or providers must be entered in the OmniBox database and in the OmniBilling database as well. In absence of other synchronization means, data must be entered or modified twice. 

Automatic data sync is very convenient for any type of operation, but it becomes a must in case it demands real-time billing, like, for instance, with calling cards or prepaid accounts. Customer service must have updated information on the account usage and also any credit or account closure needs to be immediately updated at the OmniBox database. Defense against hackers also requires real-time OmniBox to OmniBilling sync on attempt count, but also ANI blocking decisions made at the office must be immediately passed on to the OmniBox.

Microsoft SQL, standard editions (no desktop), provides sophisticated replication features that, in principle, can keep the necessary data sync among the Billing and OmniBox, but:

• Can no longer use the developers free license of the MS SQL server, in other words...money.

• Can no longer use the Desktop version under Windows workstation, you will need a server (more $).

• If the link to Internet is broken, the replication distribution may not restart on its own, requires close monitoring (still more $).

• SQL Publication, subscription, distributions ad security issues make take a professional to install and maintain (and more $).

• Avoiding loops could become tricky for tables, like Balances, that must  be both published as well as subscribed articles. Loop problems will multiply if there's more than one OmniBox or more than one OmniBilling.

To overcome these shortcomings, the Reversed and Extended Replication Schemes has been introduced after OmniBox V4.50 and V2.0 of the SQLReplic  and ReplSrc. This scheme allow to completely sync all the databases involved in an OmniBox system, it introduces multi-site capability and also replication priority. This last feature allows urgent matters, like balance updates, black list changes, etc. to be replicated before the the more numerous CDR's. 

Real-time monitoring

The OMNIBOX has no user interface, it publishes its status, activity and alarms over an IP network. Also listens to command messages addressed to it, so it be controlled remotely. There are performance and convenience advantages to this approach:

·         Since switching performance is not compromised by the user interfaces, it can be made as sophisticated as needed.

·         You may monitor activity and control the system from one or more remote sites in a LAN or WAN.

 From the Monitor you can:

·          Check the call progress in every channel, Results stay even after the call is finished.

·          It shows the current traffic and the seizure count of the last minute;

·          Include/ exclude any channel (Use Exclude/Include buttons and the text box between);

·          Commit the changes to the database parameters(Commit Db Changes under Actions Menu);

·          Check acknowledgement for all the above commands.

·          Monitor CDR replication.

·          See all the watchdog alarms that are issued

·           Broadcast and receive message to and from all connected Monitors

·           Schedule commands

·          Unload/reload the OMNIBOX executable.

Parameters that actually control the OMNIBOX, are stored in tables within an MS SQL Server database. The objects of this database, can also be remotely accessed through the same IP network. Changes apply only after sending a “Commit DB Changes” command from a Monitor.

Security features:

• ACCESS can be restricted to an access list

• Administrative privileges can also be limited to a list

• Monitoring capabilities of any given computer can be limited to specified trunk groups 

Call monitoring through analog lines

If the Dialogic analog boards  (D/41SC or D/160SC) are included in the system, the following features are can be enabled for one or more of the analog lines to further enhance monitoring capabilities:

1.        Listen into a specified channel

2.        Setup a call to a specified outbound channel

3.        Setup a call into a route

4.        Setup a call into an inbound trunk group (Domain)

These features allow the following tasks to be performed.

Tasks:

·         If you want to listen to calls to test voice quality or check what is going on, use feature 1

·         To check why calls are failing or short use feature 1

·         If you want to test a particular channel, use feature 2

·         If you want to make a phone call to actually talk to somebody, use feature 3.

·         If you need to test digit processing settings, use feature 4

Operator paging upon specified alarms

There is not such thing as a failure proof communication system. There is so much that can go wrong in a complex system that the best you can do is “be the first to know” and know it fast. That is what this Watchdog feature is all about. It will page everyone in a list when something behaves abnormal.

Any instance of the OmniMonitor can become a Watchdog. By using the underlying Internet Mail installation the Watchdog feature can page a list of recipients by sending a whole alarm message.

The email pages can be enabled/disabled by checking/un-checking the Enable Pager  menu item. When you enable the email paging service, you will be prompted for the recipient list with and input box. There you can enter the recipient list separated by semicolons, the same way you do with any email message. Any previously entered list will be shown as default. OmniBox provides ways of masking alarms so that pages are issued only upon specified scenarios.

Automatic channel exclusion after reaching failure count threshold

Most bypass operations terminate traffic in analog lines which can occasionally loose its dial tone o just go out of service in some fashion. OmniBox keeps track of the failures on every outbound channel and when the count of these in a row goes over a specified threshold, it can be set to do one of the following things:

1. Send an alarm to the OmniMonitor so it can page an operator to take care of the problem

2. Automatically exclude the channel corresponding to the failing line from the trunk group hunting, thus preserving the completion rate for the client. After a specified time it will be put back in service for recheck, if it fails 3 times in a row, it will be excluded again. This cycle will repeat until the line recovers.

3. Exclude the outbound channel but also balance this by excluding (setting it out of service) an inbound. When doing static routing, there’s usually a channel count correspondence between inbound and outbound trunks for a route. Balancing keeps this correspondence, thus avoiding completion rate loss due to “no outbound channel” situation.

Hung trunk detection

A typical problem when conveying traffic over the satellite or any other media where the carrier must pay for bandwidth, is that a phone may be left off hook keeping a false call for very long time that will, most likely, have to be credited. This unfortunate happening is known in the trade as a hung trunk.

To detect and terminate hung trunks, OmniBox will spin an independent thread that will check sequentially all outbound channels in use, when a call is found to have been connected for more than a specified time, the Hung Trunk Detector will start checking for silence, busies, rings or SIT tones in both outbound and the associated inbound.

Part of the OmniBox watchdog system works from within the main application. OMNIBOX can be set to disable outbound channels that have had more than a specified count of failures in a row. This helps improve completion rates. But since these interruptions could be temporary, it will try the channel again in 3 hours, if it fails 3 times in a row, it disables the channel again. This process repeats at a specified rate.

IVR Platform

OmniBox also offers a very complete IVR (Interactive Voice Response) platform to handle PIN verification and call placing prompts for:

• Calling Cards

• Subscription Prepaid accounts.

• Invoiced accounts

In case you wonder what’s the difference… Calling Cards are prepaid accounts, so OmniBox must report remaining balance and minutes of talk time to the dialed destination and when the call is one minute away from exhausting the balance, it must prompt a warning and eventually cut the call if the balance hits 0. Invoiced accounts, on the other hand, can be practically promptless, if the PIN matches the ANI, all the caller is going to hear is “enter the phone number” or if you prefer, a dial tone. Calling cards involves concepts like expiration dates, maintenance fees among others that subscription prepaid accounts don’t.

The IVR Platform  features

• Multi-Language.

• There’s no limit to its number, languages can be selected by account, number dialed of by prompt. For each valid language you must assign a number, 1, 2, 3… and references to these numbers are made in the client’s accounts.

• Prompts are stored in individual Windows WAV format files, this makes it easier to customize. The path to these files are specified in the database. Numbers and ordinals are stored in subdirectories named for instance dtWav0 for English and dtWav1 for Spanish, where 0 and 1 is the language reference number mentioned above..  

• PIN Verification state machine features:

• Multi PIN per account capability. An account may have multiple valid PIN’s, an office with several authorized employees a family with several members, etc.

• Direct ANI login. This  is especially useful in combination with this allows a registered client to call from any number of different phones without being prompted.

• Time controlled call state machine 

• Implements the real time billing feature

• Attempts a call, if it fails returns control to the caller.

• Implements the ## feature by which the caller can terminate a call without hanging up and make a new one without having to login again.

• If the called party terminates the call, returns the control to the caller

• ANI black list.

• Hackers are always out there for an easy profit on your operation. They have devised programs that will flood your system with calls until they get a valid PIN. As a defense against these predators, OmniBox will register every ANI that dials into the system and will keep an attempt count in a table called ANIBlackList, if you see an abnormal count, you can flag that ANI out, further attempts from that ANI will get a busy. You can even have this job done automatically by the SQL Server.

• Pay phone identification and handling

• If you have a toll free number for your operation, the fee for the use of a pay phone will be passed on to you, OmniBox can detect these calls and may pass the a specified proportion of these charges to the caller.

• Real-time billing system

• The only way to do prepaid accounts is by doing real-time billing, this means that the balance is read from the database upon login and it won’t be allowed to go negative. The caller will be warned when a minute is left and the call will be cut when the balance reaches zero. For a call to be proceed, the balance must be enough for one minute of talk time to the dialed destination. Simultaneous use of an account by more than one caller won’t be allowed if the balance is less than a specified limit

• Calling Card generator

• Generates a specified number of accounts with random but unique PIN's  of specified length. Accounts will also be generated with initial balance, expiration dates, life spans and other data that must also be specified.

Call-Back

Assume that a call from A to B is rated at $0.50/min but from B to A is only $0.25. You can profit from this by installing an OmniBox in B, whenever a client in A wants to call B, it dials a number that is given to him that will terminate in the mentioned OmniBox, there will be no answer, then the client hangs up so, there’s no charge, this is known as the trigger call. The trigger call has notified OmniBox that a client needs to make a call and which client is it, so it dials the client’s number in A, when the client answers, OmniBox will prompt for the number to dial in B, then it makes a local call in B at very low rate, say $0.05/min. The cost of the call is $0.30/min, if the rate offered to the client is, say, $0.40/minute, you make a profit of $0.10/min. Call-Back may also render profits on differences in long distance rates, special volume plans, private links… imagination is the limit.

For a Call-Back operation, you will need a DID or DNIS service, the best option being an ISDN PRI. You must also request a set of phone numbers to match your expected client count. When a trigger call is received in a channel belonging to the Call-Back inbound trunk group, the registered customer will be called back from that same channel A Call-Back account can be invoiced or prepaid but does not requires PIN verification. OmniBox dialog will allow any number of outbound calls in the same call back using the ## feature.

Custom Functions

Customized long distance services

To the standard PIN verification and Time controlled call state machines you may add dialogs and features like language selection, premium service option, record complaints, etc. This is done by attaching or “HOOKing” small state machines to the standard ones. This is the way to customized standard IVR functions by inserting "hooks" to user programs in standard state machines

IVR for Information services.

Totally new state machines can be created for applications that have nothing to do with long distance services. Interactive Voice Response applications are commonly used as auto attendants,  to automatically inform clients about account status and balances, to do opinion polls, password changes and  the sort. User programmed IVR's are inbound functions, they are triggered by an inbound call into a Domain with  a Function  that matches a user programmed state machine.. 

Predictive dialing (Telemarketing) &

Test traffic generation (Blasting)

Predictive Dialing and Blasting, contrary to IVR’s,  are outbound functions that will be executed by the OmniBlaster which is triggered from the a specially featured OmniMonitor (see below) by selecting (marking) channels and then hitting Start Blast.  

        Download This File                   Download All Documents                        Go to Home Page