·The
SQLReplic: Replicates call detail records asynchronously from remote
switches to a Central Data Server. UDP sockets are also used to transmit calls
to a Stored Procedure from the switch to the Central Data Server and to send
back acknowledgement (or not acknowledgements) of the transactions. The records
are buffered in the Log_PendingRepl
table when replication is acknowledged the records are deleted.

·The
LapLink, PC ANYWHERE or VNC: Allows remote control and file transfer to and from the switch
networks.

The OMNIBOX runs under Windows NT. Uses
Dialogic hardware, namely, D/240SC 2T1, D/480SC-2T1 and DTI480SC. (Dialogic has newer PCI Quad T1 boards
that may deceive you to think that a box can hold maybe 16 of these;
unfortunately Dialogic record for successful channels in a box is about 40
E1's)

The OMNIBOX is database driven and
connections to the database are done through ODBC to a Microsoft SQL Server.For increased reliability and flexibility, the main program is an
interfaceless application, monitoring and control is done remotely from an
independent process that may run in a different computer through an Internet
connection.

Database structure

The
tables that define OmniBox configuration and that keep all the non volatile
information of its work are the ones below:

System:

·Sys_Parameters*

·Tec_Consecutives *

·Dia_Tones*

·Dia_ExcludedCh*

·Dia_Boards*

·Dia_V_Boards*

Trunk
Group definition and properties

·Dia_InCh*

·Dia_OutCh*

·Dia_GroupDefs*

Routing

·RouteTable*

·IdxLookup

·Tec_BlockList

Digit Processing

·Tec_ExchCodes

Logging Tables

·Log_CDR

·Part_CDR*

·GroupInfo

Administration Tables

·AuthorizationCodes

·Balances

·Companies

·LegBCostLookup

·LegBRateLookup

·ANIBlackList

Special
Functions Tables

·SysStMachine*

·SysSequences*

·Prompts*

·tec_BurstDetails*

·NailedUpCircuits*

Special
function administrative

·Stm_SpeedDial

OmniBox is designed to be not a stand alone box, but to
be a system. This means not only that there may be more than one box working
together but that a server to handle the administrative functions may be
involved. There are tables that hold technical information, like how are the
channels grouped, communication protocols, call control parameters, etc that
have a meaning only within a particular OmniBox (marked with *); on the other
hand, there are tables that hold information that is valid for every box in a
system like accounts, rates, number to be blocked, etc. or universal information
as country and city codes For this reason OmniBox makes not one but two
ODBC connections, one to local tables and a second, to tables that maybe located
in an SQL server that could even be running in a different computer.

Also there are the Logging tables to be used by the
administration of the company running the OmniBox for its billing and statistics
that will reside in the administration server together with accounts and rates
info.

System Tables

System tables are those that hold
parameters related to physical boards or those that are valid for the whole
system.

System parameters are those that have Set_ID =
0. Some of these parameters are worth of a longer comment than the one in the Description
field.

Monitor
socket port number / Do Broadcast

Do
Broadcast: Unless this field is set to zero, OmniMonitor information will
be UDP broadcasted in its LAN by OmniBox. This could allow OmniMonitors
connected to this LAN to receive UDP packets directly from OmniBox. In
practice, this option has shown no especial advantages and since some
networks show conflicts with these broadcasted packets, #include is no
longer recommending its use.

Remote
Monitor IP

Even
if the OmniMonitor information is UDP broadcasted in the LAN, OmniBox
always sends a copy of this information to the same port number but to
this IP. AUDPRelay utility
may be set to run at this address and further relay from there.

Log
Bogus Calls

A
bogus call is one where no digits where received etc. In
normal circumstance all calls, even bogus ones, should be logged. However
when there are protocol problems, poor synchronization or other temporary
problems that may generate a surf of bogus calls, then you may choose not
to dump all this useless information into your database by setting this
parameter to 0.

Channel
Init Timeout

It
had been an observed behavior, when using SF framing, that spans lock up
taking most of the CPU when addressing any of its channels. If under a
lock up situation you try bringing up the OmniBox executable, the computer
will lock for a very long time when attempting to initializes all the
channels, thus forcing a reboot. To work around this problem, after V3.40,
a timeout has been set for the initialization of channels, if it goes
beyond this value in milliseconds, executable loading will be aborted
freeing the computer CPU so the operator can to stop and restart the
Dialogic Service..

Min
and Max Working set sizes.

If
the Omnibox computer has plenty of memory and there many channels, you may
want to avoid memory paging as much as possible by increasing the physical
memory available to the switch app over what the operating system is
assigning to it. It is possible that the OS doesn’t grant you the amount
of memory you are asking, but it will always be more that if you don’t
ask at all.

Priority
class

With
today’s computer speeds over 500 MHz and the RAM being over 500 MB, it
is unlikely that you need any more priority than NORMAL even for biggest
and busiest switches. But if any latency is detected, you may try
increasing this priority. High and real time priorities had caused socket
ports to stall occasionally, so use NORMAL whenever possible.

Log
Locally/DoPendingRepl

CDR’s
can be stored locally in the in the computer were OmniBox is running (1,0)
or in a remote server using the replication feature (0,1), you can have
them stored in both places(1,1) or even choose not to have CDR’s at all
(0,0).

MAX
Domains/Ranges

Omnibox,
under some circumstances, chooses to favor performance in the
resources/performance compromise. This is the case for the Domain and
Range objects. An object is created for every possible number you might
use, so if the maximum Domain ID in you switch is going to be, say, 15 you
need to create no more than 15 objects but 20 will suffice. If for any
reason you need ID’s above 20 you must increase this parameter. For this
change to taker effect, the switch must be restarted, commit DB changes will
not do.

Paging
Range

If
the switch has an outbound connection to a carrier, one of its channels may be used for
Watchdog paging, if this is the case you must enter here the Range ID
assigned to it.

Do
partial CDR logging

This
parameter enables the feature that makes a partial call log when a call is
started and completes the missing information (result code, call length,
cost and price) when the call finishes. This is uses somewhat more
resources but it is very convenient in the case the switch must be
unloaded or upon power loss, because started call can still be logged
after the incident and thus may be properly charged to clients.

Do
local DB routing.

In
its original design, OmniBox loaded all the routing and account
information into memory when program was stated, allowing this information
to reside in a remote server without compromising post-dial delay. This
approach resulted in OmniBox being a resource hog as the routes multiplied,
also hitting commit DB changes for any priority or route change proved
impractical. Optimizing indexes and querying the database on the fly
proved much better approach. You may still enjoy a centralized routing
table system by using SQL replication into any number of local tables.
Though non local routing is still supported it is no longer recommended.

DB
Version

Database
evolves as well a the actual C++ code of the switch does. This number
is read by the C++ code to know what version of the database its
dealing with and act accordingly.

Administrative
tables are mainly used at the server when billing, but if dealing with
prepaid accounts, then billing becomes a real-time function. In this
last case, some information in the administrative tables must be made
available to the switch and account balance and status must be updated
in every call. There are two ways of doing this: you copy the tables
from the server database (OmniBilling) to the switch database (OmniBox),
you may implement SQL replication to update the Switch tables updated
with the changes at the Server and the changes in balance and status at
the switch will be replicated using OmniBox
Replication; the second way is to ODBC link the server tables
directly from the switch using the Double
Database Feature, this way the Account information becomes Centralize,
no need to use replication to update accounts real-time, same tables .
To use this last variant you must have a fast and reliable network link.

Parameter
sets are used by the OmniBox code for different purposes. The user should deal
only with the System Parameters, those with Set_ID = 0, other sets like 1 and 2
are obsolete since V3.14, these parameters were used to define which of the
playback tones described in the dia_tones
table should be setup for detection too in all voice resources with the same ExtraPrm_Set
(check the ExtraPrmField field in the dia_V_Boards
table). This was not a good approach because playback tones are described
differently than tones to be detected Records in set 100, store
the parameters for the replication component of the suite, SrcRepl.exe and will
be covered in Chapter 5.

Tec_Consecutives

Describes the tones played by the
OmniBox.
When SoftwareAnsSup is set to 4, the switch will play a ring until a real
one is detected, this is useful when long post dial delays are encountered. The
Ring Back signal that to be played is described by the record with Tone_ID = 202 in
this Dia_Tones table. Also when OmniBox encounters a situation where
there's no outbound channel available; the dialed number is blocked or invalid;
or when a non connect results after dialing (busy, dead air, SIT tones or a
busy), it plays at some point a Busy Signal that is described by tone 203. In
the case of SIT tones the OmniBox will allow ten seconds to listen to a possible
message from the CO but after that, the outbound channel will be freed and
OmniBox will play the number of Busy tones specified in the MaxCadences
field. After a busy is detected, the outbound channel will be freed too and
OmniBox will play the mentioned busy cadence. The rest of the tones may be used
in different functions, mostly of the IVR sort.

If you are wondering, why define
tones for the whole box and not do it by the channel as you dofor tone
detection, that would be a good question. You have hit a limitation do to a
design tradeoff

. The reason for this has to do with the pooling of
resources. Instead of using a voice resource for every channel playing a ring or
a busy, it is more resource efficient to have a single voice resource for the
whole box playing a ring or a busy all the time and have any channel needing a
ring or busy listen to it.

Tone_ID

dflag

freq1

freq2

Db1

Db2

Duration

Toff

String

TermWithDig

MaxCadences

Description

200

0

1100

0

-6

0

300

0

0

0

FAX

201

1

350

440

-20

-20

3000

0

-1

0

Dial
Tone

202

0

425

0

-7

-7

100

400

0

10

Ringback
2s

203

1

480

620

-6

-6

50

50

0

60

Busy
Tone

204

0

1000

0

-3

0

20

0

-1

0

1KHz
tone 200 ms

205

0

200

0

-40

0

400

0

-1

0

Silence
4s

207

1

2500

2250

0

0

10

10

0

2

Off
hook tone

Dia_ExcludedCh

Every channel that is taken out of
commission is logged in the dia_ExcludedCh table together with “who”
and “when”.If
it weren’t for this, all channels had to be excluded again in case of a system
restart.

This
table links the Logical Channel ID with the physical Boards, protocols and
attached voice resources. The Logical channel ID is formed as follows:

Ch ID = Span Number x 100 + channel
number in the board. For example the 10th timeslot in the second T1
of a D/240 SC 2T1 with the rotary switch set to 0 would be 210.

The Protocol is a the name of
the cdp (Country Dependent Parameters) file that corresponds to a Global Call
protocol. The R4_dtmf_o and R4_mf_i are a protocols implemented by OmniBox based
on the Dialogic R4 API and not the Global Call API. The properties of a
channel can be found at three different levels: Nearest to the copper and
silicon, you may find the prm
files that must be set with the DCM (Dialogic Configuration Manager); at a
higher level, depending on the protocol, selected with DCM, a corresponding cdp
file will specify the settings related to that protocol and finally at the
highest level, in the fields in the dia_InCh and dia_OutCh tables
will describe the grouping, the functions, the associated accounts, hunting
patterns, etc

P_isdn_T1o, P_isdn_E1o, P_SS7_T1o,
etc. are also OmniBox implemented files that specify the parameters for the
voice resources to be temporarily attached to CCS (Common Channels Signaling)
spans for hung trunk or software answer supervision purposes, as well a call
setup parameters for ISDN or SS7 protocols.

Phy_L_R
and Phy_U_D stores the physical position left to right and up/down within the
board of the span.

A
resource can be either attached to a channel or free to be used by the resource
pool. For
example, analog channels waiting for calls, require a dedicated resource. For
these cases it is best to attach the resource to the channel. This is done, by referencing the first resource ID of the group in the dia_V_Boards
table. In the example below resource 1301 will be attached to channel 301, 1302
to 302 and so on for 4 channels.

Refers to a permanent route between
two clear channels. The idea is to convey whatever bit stream into the
inbound DS0 to the outbound one. This will find use mainly for data channels.
Originally nailed up circuits were dedicated private lines that were literally
nailed to the walls of the central offices. Here the “nails” are the records
in the table below. In the example channel 220 will be nailed to channel 222 and
since ChCount is 2, 221 is also nailed to 223. This means,
that contiguous channels can be nailed with a single record

Ch1

Ch2

ChCount

Description

220

222

2

Nailed Circuit group
1

All nailed channels must belong to
the same outbound group that must be named “Nailed” but may have any RangeID.
(See Chapter 4, dia_OutCh)

The
resource boards have only four channels. This way, a D/480 SC 2T1 with 48 voice
resources has 12 boards. In the example below, only 24 resources of these boards
are being used (boards from 7 to 12). The last four resources are attached to 4
channels starting from the 301 from an analog board D/41 ESC.The field Type is obsolete since OmniBox V4.30, for which the
types are determined automatically by OmniBox, that queries resource
boards for its features and determines if they have limited capabilities or if
they are full featured (See Chapter 9, Dialogic
board having resources with limited features). The ExtraPrm_Set
is also obsolete since V3.14, information on parameters for tone detection is read from
the tone descriptions in the cdp file of the owner channel or the default
one, if the owner channel doesn't have one.

Brd_Ch

Ch_Count

Type

Attached_To

ExtraPrm_Set

CallPfName

701

2

2

0

2

<NULL>

703

2

1

0

1

R4_dehli_o

801

4

1

0

1

R4_dehli_o

901

4

1

0

1

R4_dehli_o

1001

4

1

0

1

R4_dehli_o

1101

4

1

0

1

R4_dehli_o

1201

4

1

0

1

R4_dehli_o

1301

4

1

301

1

<NULL>

The CallPfName field is the
name of the cdp file where OmniBox is going load the default call perfect tone
descriptions and control parameters from.
Normally these parameters are read from the
same cdp file that describes a channel protocol (the one in Protocol field in
dia_Boards table) and the parameters are set to the voice resource upon dynamic
attachment but, for channels with protocols that
don't use cdp files, these settings are the ones in effect for call analysis
in hung trunk detection. Though ISDN channels are likely to have a cdp, it is
allowed not to have one, if the owner channels of a VOX resource were to be one
of these, then the parameters in effect would be the ones in these defaults. For
channels with protocols that require attached resources like the Analog or the
MFR2, the call control parameters of
these channels become those in this cdp file.