Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

replacing TABs collector with something reliable

replacing TABs collector with something reliable

replacing TABs collector with something reliable

Hi there,

I am writing software to replace a setup of Fidelio (hotel management software) at a large international conference center. There is a Sopho is3030 setup, which links to the Fidelio system for recording of FDCR data (so we can charge guests for their phone calls). The Fidelio collector gets its information through a serial cable connected to a new Windows 2000 server, which runs TABs and the OM command interface.

Obviously, I will need to write a new collector for my software. I could write something that emulates the Fidelio software (i.e. that would collect the information through the serial link to the Windows 2000 server), but I'd rather bypass that box entirely and get the FDCR data directly from the PBX.

Here's why. We used to have an old DOS machine in the place of the Windows 2000 server, which gave us essentially zero problems with the collection of FDCR data over a period of 10 years. Last spring, the machine was upgraded to Windows 2000. The upgrade cost quite a lot, was done by Philips, and the collection of FDCR has been unreliable ever since. The TABs collector will just stop, loose lots of data, die after an automatic windows update, etc. Philips has looked at it several times, and while the situation is slightly better now, the bottom line is that this software is flakey. We want to get rid of this Windows server (we're pretty much an all-Linux server shop otherwise).

We figured out that we could replace the OM command interface by simply telnetting to the IP address of the PBX, and issuing hex OB (ascii 11) to start an OM session. So that part of the reason for the Windows server is gone.

The remaining bit is the TABs collector. From what I can tell, it communicates with the PBX through TCP/IP. It somehow retrieves new call records, and it also tells the PBX that it is alive (because closing down TABs leads to an error on the operator's Sopho console).

Essentially, I want to write a reliable version of the TABs collector. All I need is enough information about how TABs and the PBX communicate to do it. Unfortunately we don't have a test Sopho system to experiment with.

I have contacted Philips directly, but all they were willing to give me was some information about the structure of the data records, which is useful but not quite enough. Essentially they sent a few pages from a technical manual, describing the STANDARD and ACCOUNTING records. There was no information on how to get to these records :(

If I succeed, I am going to release the software (which will run on Linux - possibly with a small web interface) as Free Software, under the GPL. This means I can not sign any NDA's.

Any ideas, pointers, thoughts are most welcome. I'm particularly interested in any technical documentation about the TABs software and the collection of FDCR data.

I think it's about time we get some decent Free Software to interface with Sopho PBX'es!

Thanks in advance,

RE: replacing TABs collector with something reliable


If you can telnet to the system than it ought to be possible to give some commands.
I don't know much about this stuff but perhaps just enough to get you going.
First of all there are 2 types of costing records.
The older type is called Toll Ticketing and the newer version is called Full Detailed Call Record. You mentioned this version in your text.
To find out what you've got, telnet to the PBX and execure a few commands.
i.e. difrod:; (don't forget the : and the ;  ).
This results in the name of the so called output device.
Could be something like FDCRxx or LBU0x.
The characteristics of this device can be found using:
didevc:<name of the device>.
i.e. didevc:FDCR01; (again don't forget the ; )
To get some info about the calles in progress and already stored in the FDCR file use:
It could also be usefull to know the type of PBX.
Use diexid:;
of diexid:,2;
Date and time is also important on a PBX.

Because your using a telnet session the result is unformated.
i.e. didati:; should result in:
 2005-04-20 +3+ 14:09
   3     iS3090_License


    3      LBU03           0


Know it's not enough but perhaps you can get started with this.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close