Download This File                   Download All Documents                        Go to Home Page

Chapter 3

 The OMNIBOX suite components (Downloads update 06/24/03 )

·         The OMNIBOX:          This executable is the one that does the main telephony function that’s why it sometimes take the name of the suite.

·         The OmniMonitor: OmniBox is interfaceless, the monitoring of the traffic and switch controls is done through this program that is connected to the rest of the suite through UDP sockets

·         The KeepAppUp: Polls every 10 seconds for a specified application window and it doesn’t find it there it spawns the program again with a specified command line. 

·         The UDPrelay: Allows monitoring to happen through an IP WAN. 

·         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

(Red means "user settable", blue is "internal use only", black is "obsolete") 

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. A  UDPRelay 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.
• Centralized Accounts
  • 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

 Guarantees that the uniqueness of the CDR’s primary key

Dia_Tones

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.

 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.

 Dia_Boards

 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 10^th 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.

Nailed Up Circuits

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

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) 

Dia_V_Boards

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. 

 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. 

If the field is empty (<NULL>), the name defaults to R4_dtmf_io.

 Download This File                   Download All Documents                        Go to Home Page