Download This File                   Download All Documents                        Go to Home Page

How To...

 

Index:

Administrative

Routing

Trunk group definition

Call Analysis tuning

Hardware

Number Translation

 

 

Contents

Add a New Inbound Domain

  1. Open the OmniBoxSetup.mdb GUI. The SW_General Seup form shows up.
  2. Hit the Group Definitions button and the SW_Group definitions form shows up.
  3. Select the In Entry tab.
  4. 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.
  5. 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.
  6. If you need to add a new account check "Add a New Account".
  7. 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.
  8. 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"    

Add a New Account

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)

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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)

  1. Open OmniBoxBilling.mdb GUI.The Administrative Center form shows up
  2. Hit the Accounts and Rates button in the Entry Forms section. The Rate Entry form shows up.
  3. 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. 
  4. 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.
  5. 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.
  6. You must enter, at least, the Company name and the Type (C for Client or D for dealer) 

Add a New Outbound Range

  1. Open the OmniBoxSetup.mdb GUI. The SW_General Setup form shows up.
  2. Hit the Group Definitions button and the SW_Group definitions form shows up.
  3. The Out Entry tab is selected by default.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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"  
  9. 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.

Change a Rate

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.

  1. Open OmniBoxBilling.mdb GUI.The Administrative Center form shows up
  2. Hit the Accounts and Rates button in the Entry Forms section. The Rate Entry form shows up.
  3. Use the navigation buttons to find the ClientType that in which a rate need to be modified.
  4. 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.

Change a Cost

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.

  1. Open OmniBoxBilling.mdb GUI.The Administrative Center form shows up
  2. Hit the Costs Entry Form button in the Entry Forms section. The Cost Rates Entry form shows up.
  3. Use the navigation buttons to find the Provider whose rate need to be modified.
  4. 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.

Make a Database Consistent

Trunk groups properties are defined in the tables dia_InCh, dia_OutCh and the channels belonging to them in dia_GroupDefs. Database Consistency means:

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..

Add a New Destination

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,   

How to Deal with Long Post Dial Delays

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.

RESET!

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.

  1. A group (or even all of them) of channels behaving weird...try Exclude-Include maybe it does the trick.
  2. if above fails, try doing Commit Db Changes.
  3. restart OmniBox. Hit the Quit button on the OmniBox window or use the Unload App in the monitor; the KeepAppUp will start it again.
  4. Oh...but the app is frozen!... then use the Task Manager to end OmniBox.exe process
  5. OmniBox is up again but behaving the same ...
  6. Still the same... maybe the operating system got tangled. Shutdown and restart Windows.
  7. 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.
  8. 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!

 

Deal with CO messages without SIT tones

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

 

 

SORRY not written yet, but expect it soon!

 Download This File                   Download All Documents                        Go to Home Page