How To...
Index:
Administrative
Routing
Trunk
group definition
Hardware
Number
Translation
Contents
- Open the OmniBoxSetup.mdb GUI. The SW_General
Seup form shows up.
- Hit the Group Definitions button and the SW_Group
definitions form shows up.
- Select the In Entry tab.
- Using the navigation button (>*) at the bottom of
the form, go to a new record, a clean slate shows up will defaults and
suggested values. To learn more about the fields in this form follow this LINK.
- Now, assuming that you accept the defaults and
suggested values, you still must select a Default Account from the drop down
List and a name for the Trunk.
- If you need to add a new account check "Add
a New Account".
- Now define the channels that will belong to this
trunk group by entering the ChMin (Start channel number) and the ChCnt
(channel count) from that channel. If the channels are not contiguous, but
formed by several groups, create a record for each.
- If you are finished defining groups hit Check, if
your group definition renders "Database is consistent" this is, no
overlapping groups or undefined channels, then you're done, if not, hit
"Open Group Definition Entry Form" button, and proceed as
in "Make a Database Consistent"
Accounts are defined in Balances and related
tables: Companies; AuthorizationCodes and dbo_LegBRateLookup.
These belong to the administrative kind that may reside both in the switch and
in a remote billing server (See Double
database Feature). If a fast and solid ODBC connection can be established
between the OmniBox Switch and its Billing Server, the administrative tables
could be centralized, meaning that the tables attached in OmniBoxSetup.mdb
are actually the same as the ones attached int OmniBoxBilling.mdb,
in which case, any one of the procedures below will be enough to add a new
account to the system. In absence of such a connection, then you must do both of
them or, if SQL replication is setup for these tables (SQL publisher and Switch
subscriber) you need to do only the Server side.
OmniBox Switch side (using OmniBoxSetup.mdb)
- If you are adding a default account to an inbound
Domain, you may use the subform at the bottom of the In Entry tab in
the SW_Group Definitions Form. If you are just adding an account you
may open the Rep_Balances form by hitting the Edit Accounts button by
the DefaultAcc combo Box.
- Using the navigation button (>*) at the bottom of
the form, go to a new record, a clean slate shows up will defaults and
suggested values. To learn more about the fields in this form follow this LINK.
- You must, at least, fill the Account number and
the CompanyID the account belongs to. The rest of the fields depend
very much on the application.
- If the Company associated with the account is not in
the Companies table, you may double click on the Company ID
combo Box and the Companies
entry form will show up with a new record clean slate.
- You must enter, at least, the Company name and the
Type (C for Client, P for Provider or D for dealer)
Billing Server Side (Using OmniBoxBilling.mdb)
- Open OmniBoxBilling.mdb GUI.The Administrative
Center form shows up
- Hit the Accounts and Rates button in the Entry
Forms section. The Rate Entry form shows up.
- Use the navigation buttons to find the ClientType
that the new account belongs to. If a new client type must be defined, you
may append a new record in any of the existing one but entering the new
client type number, next time you navigate, you'll find the new Client
Type.
- You must, at least, fill the Account number and
the CompanyID the account belongs to. The rest of the fields depend
very much on the application. To learn more about the fields in this form,
follow this LINK.
- If the Company associated with the account is not in
the Companies table, you may hit the New Client Company button
under the Client Type text box and the Companies entry form
will show up with a new record clean slate.
- You must enter, at least, the Company name and the
Type (C for Client or D for dealer)
- Open the OmniBoxSetup.mdb GUI. The SW_General
Setup form shows up.
- Hit the Group Definitions button and the SW_Group
definitions form shows up.
- The Out Entry tab is selected by default.
- Using the navigation button (>*) at the bottom of
the form, go to a new record, a clean slate shows up will defaults and
suggested values. To learn more about the fields in this form, follow this LINK.
- Now, assuming that you accept the defaults and
suggested values, you still must select a Provider from the drop down
List and a Range Name.
- If you need to add a new Provider Company double
click on Provider and the Companies entry form will show up with a
new record clean slate.
- Now define the channels that will belong to this
trunk group by entering the ChMin (Start channel number) and the ChCnt
(channel count) from that channel. If the channels are not contiguous, but
formed by several groups, create a record for each.
- If you are finished defining groups hit Check, if
your group definition renders "Database is consistent" this is, no
overlapping groups or undefined channels, then you're done, if not, hit
"Open Group Definition Entry Form" button, and proceed as
in "Make a Database Consistent"
- In order to have a call routed to this new Range,
you need at least one route to point to this Range. If there are only a few
routes, you may readily append these using the SW Route Table subform
at the bottom of the form if not, hit the "Create new routes for this Range"
to open the Route Setup form and proceed as described in "Add a
new set of routes". Information on the RouteTable fields can be
found HERE.
To change a rate, you do not edit a record in the LegBRateLookup
table, you add a new one with a new activation date. Remember that records
this table are no to be edited nor deleted, the activation date specifies when it goes into effect.
- Open OmniBoxBilling.mdb GUI.The Administrative
Center form shows up
- Hit the Accounts and Rates button in the Entry
Forms section. The Rate Entry form shows up.
- Use the navigation buttons to find the ClientType
that in which a rate need to be modified.
- Append a new record to the LegBRateLookup Subform,
enter the right values for all the fields (check the field
descriptions). The default activation date will be today at midnight.
To change a cost (your provider's rate for you), you do
not edit a record in the LegCostLookup table, you add a new one with a
new activation date. Remember that records this
table are no to be edited nor deleted, the activation date specifies when it goes into effect.
- Open OmniBoxBilling.mdb GUI.The Administrative
Center form shows up
- Hit the Costs Entry Form button in the Entry
Forms section. The Cost Rates Entry form shows up.
- Use the navigation buttons to find the Provider
whose rate need to be modified.
- Append a new record to the LegBCostLookup Subform,
enter the right values for all the fields (check the field
descriptions). The default activation date will be today at midnight.
Trunk groups properties are defined in the tables dia_InCh,
dia_OutCh and the channels belonging
to them in dia_GroupDefs.
Database Consistency means:
- that the channels defined into trunk groups
must add up exactly to the total amount of channels declared in the dia_Boards
table
- that there are no gaps or overlaps in trunk group
definitions
- that every channel referenced in dia_GroupDefs
is defined in dia_InCh if defined as inbound.or the dia_OutCh
is defined as outbound.
If you hit Commit DB Changes, with an inconsistent
database, you may crash the switch and it won't load until the database is
consistent. Tools are provided to help attain consistency, in the
OmniBoxSetup.mdb, every form or subform where the records of the dia_GroupDefs
table are listed there's a button that reads "Check". This button will
display a message box with "Database is Consistent" if all the above
conditions are met, if the first condition is not met, the message box
will display a message describing the violation, for example
"There are 98 channels defined in trunk groups but
just 96 define in the hardware setup"
If gaps or overlaps are detected a list of their
approximate locations is displayed. A channel number may be displayed in the
list even with no apparent overlap or gap, then it may be pointing to an
undefined group ID. This is not likely to happen since normally an undefined ID
is not present in the drop down lists of the GroupID field combo box, but
it may happen still happen, for instance if you delete a group or make direct
table entries..
A new destination is characterized in the OmniBox
system by its route index. You need a new Route Index when its associated
destination needs to be routed distinctly or if rates are different. If none of
these distinctions exists there is no need to define a new destination. To add a
new destination, you must first append one or more records to the IdxLookup
table that will link the RouteIdx with the dialed prefix. For this you
may use the IdxLookup Entry Form that can be opened from the Administrative
Center in the OmniBoxBilling.mdb. If accounts
are centralized, if is easier to do this from the OmniBoxSetup.mdb in the
switch side. You hit the Routing Setup button on the SW_General Setup
Form and the Routing Setup form opens. It is quite likely that you
can express in a single record all possible prefixes to that destination by
using the wild cards that are accepted in
the Prefix field, if not, you may append the all the records needed to
cover all prefix possibilities.
Not all destinations described in the IdxLookup
table need to have a real route, for that, you must assign, at least, one range
in which to terminate these calls. The RouteTable
is where these assignments are specified, you must append a record for each
possible terminating range specifying a priority and repeat this for each RoutingSet..
Also, each range may have its particular digit translation rule that must be
described in the ReplaceWith
field.
The Routing Setup form provide some means to check
prefix definitions as well as route assignments.and its digit translations.
These are the Test a Number button, that will search IdxLookup for
the specified numner using the same stored procedures as the OmniBox and the Test
Routing button that will show all the digit translations for the assigned
routes in the RouteTable,
International
calls can go through the strangest and longest routes, several satellite hops,
VoIP, cellular networks, you name it!. This is why some circuits may experience
long Post Dial Delays (PDD's). Up to 15 seconds of PDD may be consider
tolerable, but beyond that, callers may become anxious and hang up. In these
cases you may consider a bogus ring-back. You may set an outbound channel to do
bogus ring-back by setting the SoftwareAnsSup
field in table dia_OutCh to 4 or 3. Option 3 will play the
ring until answer or call failure (dead air, busy, SIT, etc) whereas 4 will stop
playing the ring upon detection of a real ring-back pattern. Some of these
ring-back patterns can be very unfamiliar to your callers in which case, Option 3
would be appropriate.
There's
a catch in using bogus ring-backs. After four rings, a caller may start
considering hanging up for thinking that there's nobody home. That may happen in
20 to 24 seconds You may want to delay the bogus ring to the limit of the estimated
caller's dead air patience (15-20 seconds). This can
be set using parameter 9 in the R4_xxx.cdp file. More
on this in Chapter 8.
Some
times, there are strange tones, dtmf's and noise at the beginning of the
connection that may trigger a voice detection. Parameter $32 in the cdp file can
be used to skip the crap and start the analysis after the initial silence have
started, but in the case of long PDD's, you will want to delay more than just to
skip crap. Frame relays and VoIP gateways use compression techniques like
syllabic companding and adaptative gain encoding to decrease the dynamic range
of the sound signal. This can account for the following behavior: During prolonged
periods of silence, background noise slowly comes up and small interference
spikes become likely to trigger a false voice detection in a Dialogic
board. The bigger the compression the more pronounced the effect. To avoid false
voice detections when long post dial delays (PDD) are involved, avoid setting
dead air timeout over 20 seconds (parameter $2 > 2000 (tens of ms)), instead,
try increasing parameter $32 to the largest possible value which is the minimum
observed PDD. Dead air timeout should be set only a little greater than the
difference between the minimum and maximum of the observed PDD.
There's
still another problem, every so often, you find switches that are set to
drop calls if answer supervision is not returned in 45 seconds following a
carrier policy. With a PDD over
35 seconds this setting leaves a called party with only 10 seconds (2 rings) to
get to his phone giving little chance for call completion. There's a way to set routes to
return a bogus answer supervision signal back to the demanding switch on the 45th
second after seizure in case ringing has been already detected. This prevents the call from being dropped (See
ChargeOnNoAnswer in the the RouteTable). A few seconds more of
charge in a call is no big deal, but if no one answers, you may
be charging for a non completed call. When you apply this solution, you must do some
statistics to evaluate if it is actually solving a problem or creating a bigger
one.
Every so often in the cyber world, upon encountering
some kind of abnormal behavior beyond comprehension, users have grown accustomed
to go for that universal savior ... the reset button of every piece of
equipment involved. Like most computers, the OmniBox has a reset button
too and you even have the Power Off option, but before you go to
extremes, you have quite few milder reset choices. Suppose you have group (or
even all) of channels showing weird behavior...below we offer you a list of
"resets"
sorted from mildest to strongest.
- A group (or even all of them) of channels behaving
weird...try Exclude-Include
maybe it does the trick.
- if above fails, try doing Commit
Db Changes.
- restart OmniBox. Hit the Quit button on the
OmniBox window or use the Unload App in
the monitor; the KeepAppUp will
start it again.
- Oh...but the app is frozen!... then use the Task
Manager to end OmniBox.exe process
- OmniBox is up again but behaving the same ...
- Quit
the KeepAppUp for OmniBox (Its usually minimized, the Icon says Keep OmniBox
Up),
- kill OmniBox.exe with the task manager
- (also close all OmniTBird instances if there are
any opened)
- and the
use Dialogic
Configuration Manager (DCM) to Stop/Restart the Dialogic service.
- Then
hit the Keep OmniBox Up icon on the Desktop, this will start OmniBox in about
have a minute.
- Still the same... maybe the operating system got
tangled. Shutdown and restart Windows.
- Still there!... sometimes a Dialogic boards go into
a strange state that disappears with a power off, so shutdown, power off,
wait 20 seconds Power on...pray a little.
- NOTHING? Call 911 or even better, call #include
There's is also IP socket issues like when you see no
activity on the monitor or there is activity but but OmniBox won't respond to
commands, you can try hitting Reset Socket on the OmniBox window.
Sometimes the IP port used gets corrupted and faster than resetting the computer
is changing the Engine Port in the sys_Parameter table and hitting Reset
Socket.
There maybe cases were the above sequence is not
advisable, for instance, if a span is not responding and the CPU goes 100%
(sometimes this happens when T1's, using AMI D4 misbehaves, getting
flooded with alarms),
don't bother with 1,2.. etc., go straight to step 5.
When crisis hits, though panic drives your hand toward
the reset button, doing some thinking can't hurt, it may even solve the issue
faster and with less consequences. For instance reading the lasts alarms or the
event log or trying to remember any recent changes, no matter how small, may
render some clues of what might be wrong before you hit reset.
Some changes can trigger the OmniBox license protection
mechanism. For example, changes in the IP address or enabling channels or
functions not covered by your license can cause OmniBox to stop working and
failing to start. When this happens an event will be written to the log reading: "License Violation contact #include", you
do just that!
This problem is a tough one for Software Answer Supervision, because there's no way to identify a CO
recording from that of an Answering machine, yet you may charge for
the second but not for the first In the US, CO messages are preceded
by SIT tones, these tones return an "Operator Intercept" and
the message won't trigger Answer Supervision. Unfortunately, in the rest of
the world it doesn't go that smooth and you get plain messages that trigger
voice detection and so, Answer Supervision. There's a solution to this! The PAMD delay
feature.
It works like this: you can tell a
recording from human voice by what is called "the envelope" of the
sound waveform. When there's a "salutation" (Hello...) followed by a
silence and then the beginning of the conversation (Oh!! long time no hear
!...and so on), this is clearly a human voice, but when you get "The
number you have dialed is no longer in service, verify...", there's no
salutation, so, it is a recording. This way you can tell a recording from a
voice. If you enable the "PAMD delay" feature then, when a
recording is detected, it will wait for the specified time and analyze again,
if this time it gets a busy, a silence or even SIT tones, it will be
considered an Operator Intercept and no Answer Supervision will be issued. If,
on the contrary, it detects voice again. then it can assume it is an IVR or an
Answering machine and so, it can start charging. Even
in the worst case scenario, where after the message there are no busies, SIT or
dial tones nor silence and say...the message repeat endlessly or in different
languages, just delaying the answer supervision signal gives a chance for the
caller to hang up before connecting.
Here's what you need to do:
Open the corresponding CDP file
and look for the following in the Tone Definition section:
******************************
* TID # 109 SIT *
PAMD_FULL = 1, QUICK = 2, ACCU = 3
******************************
$109 SIT : 1800 25 0 0
%01 PAMD equates: 1 0 0 0
%02 Enable TID Alarms: 0
****************
set %01 PAMD equates to 1 or 3 (recommended
is 1). Now find parameter $10 and set it to the a value a little above the
maximum possible length of the CO messages. Say for instance the maximum
message is 6 seconds, 7 seconds (must be set as 7000ms) will be fine.
*****************
$10 PAMD delay (0
disables feature) (ms) : 7000
/* If Recording is detected, wait for above delays and
analyze again*/
/* This is used to detected CO message not preceded by SIT
tones but that */
/* have busies, SIT's or silence after the message*/
The PAMD feature
requires that recording detection be enabled (See above in ToneDef.cdp %01
PAMD equates = 1 or 3). If there's an specific message from the CO that is not
preceded by SIT tones, which is way too frequent, you may use PAMD to detect
the recording and interpret it as an operator intercept if after the specified
delay in milliseconds there's dead air, busy or even post-message SIT tones.
For a 6 second message, the following $10 setting may do the trick:
$10
PAMD delay (ms) : 7000