4K / Openscape 4000 CDR over Customer LAN?

[thepfy]

Good Evening,

Is it possible to output the 4000 V7 CDR over the Customer LAN, rather than the Atlantic LAN?

Currently we use the Atlantic LAN connected to 2 buffer boxes back to back (via serial) which then connects to our LAN.
Ideally, we would like to remove and just push via the customer LAN connection.

I am aware that there is the option to enable Collecting Agent then collect by SFTP. However, our supplier says that there are bugs in 4000 V7 which can lead to a build up of unwanted files which can lead to the server running out of disk space. Currently waiting for feedback on what patches are required. Does anyone know what patches are required?
The other option is to migrate to version 8.

Long story but we are changing call logger software. The new software support says it supports 4K but cannot tell us how to set it up (looking at one of their INI files they are looking at AM-Win V2.0 but can customise) but they are open to potentially creating a module to accept the current format.
We are using format table 1, which I believe is a standard configutation.

+==============================================================================+
| SELECTION GROUP : 1 |
+------------------------------------------------------------------------------+
| |
| OPERATING STATE : ON |
| |
| RESOP : Y |
| BASDEV : DEV1 BLBAS : 1 |
| RESDEV : NODEV BLRES : 0 |
| |
+==============================================================================+
| |
| SELECTION GROUP : 1 SELECTION TABLE : 1 |
| |
| FORMBAS : FORM01 TARIFF : NOCALC |
| FORMRES : NOFORM DESTCNT : A22 |
| |
| LEVEL0 : 0&&999 |
| LEVEL1 : 0&&254 |
| LEVEL2 : 0&&30 |
| CDRCD : 0&&999999 |
| |
| ATNDGR : 0&&15 |
| SERVICE : VOICE &FAX &DTE |
| |
| CDRULT : 0 CONNTL : 00 : 00 : 00 |
| COPIN : 0&&8 CARRIER : 0&&9 |
| |
| SELECTION FEATURES 1 : |
| |
| CTYPE : ALL PAYPARTY : ALL NSTAT : N |
| CDRAC : N SFSETUP : N CDBAD : N |
| CDRC : N CDRSTA : N THRGCON : N |
| SECTION : N TIE-LINE : N EXPENS : N |
| CONNTYP : INTERN &INCO &OUTG |
| RECTYP : ALL |
| |
| SELECTION FEATURES 2 : |
| |
| CDCHU : N CDRULTE : N CONNT : N |
| PCODE : N PPCF : N STATAB1 : N |
| STATAB2 : N DNOTBL1 : N DNOTBL2 : N |
| |
+==============================================================================+

<dis-ftbl:1;
DIS-FTBL:1;
H500: AMO FTBL STARTED
FORMAT NUMBER : 1


#@#@#@#@#@#@##@@@###@@#@@@@@@@#@@#@@@@@@@#@@#@@@@@@@@@@@@@@@@@@@@@#@@@@@#@@@@@@@
@@@@@@@@@@@@@@#@@#@@@@@@@@@@@@@@@@@@@@@#@@#@@@@@@@@@@@@@@@@@@@@@####@@@#@@@#@@@@
@#@@#@##@#@@#@@@@@@@@@@@#@@#@@@@@@@@@@@#@@#@@@@@@@@@@@##@@@@@@@@@@@#@@@@@#@#@@@@
@#@#@


VARIABLE FIELDS

FLDNAME FILLTYPE FILLER FLDALIGN COMPOS

STHOUR CHAR "0" RIGHT 000
STMIN CHAR "0" RIGHT 000
STSEC CHAR "0" RIGHT 000
STDAY CHAR "0" RIGHT 000
STMONTH CHAR "0" RIGHT 000
STYEAR CHAR "0" RIGHT 000
SELGRUNO CHAR "0" RIGHT 000
RECNO CHAR "0" RIGHT 000
SIGDATA CHAR " " RIGHT 000
RECPT CHAR "0" RIGHT 000
GLOBLV0 CHAR "0" RIGHT 000
GLOBSEQ CHAR "0" RIGHT 000
LEGLV0 CHAR "0" RIGHT 000
LEGSEQ CHAR "0" RIGHT 000
CALLILV0 CHAR "0" RIGHT 000
CALLIPTY CHAR " " LEFT 000
ROUTCN CHAR " " LEFT 000
CALLEPTY CHAR " " LEFT 000
PPLV0 CHAR "0" RIGHT 000
CHRGEE CHAR " " LEFT 000
DESTLV0 CHAR "0" RIGHT 000
DESTPTY CHAR " " LEFT 000
SERVICE CHAR " " LEFT 000
CONNTYPE CHAR " " LEFT 000
UNANS CHAR " " RIGHT 000
RINGDUR CHAR "0" RIGHT 000
QUEUEDUR CHAR "0" RIGHT 000
CONSECT CHAR "0" RIGHT 000
CAUSE CHAR "0" RIGHT 000
SUPLSERV CHAR " " LEFT 000
SWP CHAR " " LEFT 000
ATNDGRNO CHAR "0" RIGHT 000
TRNSFLV0 CHAR "0" RIGHT 000
TRNSFPTY CHAR " " LEFT 000
KEYLV0 CHAR "0" RIGHT 000
KEYPTY CHAR " " LEFT 000
MOBUCLV0 CHAR "0" RIGHT 000
MOBUCPTY CHAR " " LEFT 000
COPIN CHAR " " RIGHT 000
PIN CHAR " " LEFT 000
TKNOLIST CHAR " " LEFT 000
TKNOBCHA CHAR "0" RIGHT 000
INTNLIST CHAR " " LEFT 000
INTNBCHA CHAR "0" RIGHT 000
TRANSCNT CHAR "0" RIGHT 000


AMO-FTBL -111 SMDR/DMDR TABLE FORMATS

 

[Moriendi]

Quick answer : No.

The workaround is a buffer box, and you already have that. If it works, why change? Instead of buffer box back to back, you can also use a buffer box to a cable router, put ATLAN to router lAN port, put buffer box to another LAN port, put your company LAN to WAN port.

Format table 1 being standard configuration, it depends what country you're in. Different countries use different tables. But if you're changing provider to someone who hasn't much experience with 4K, and wants to create a new module to handle it, then buckle up, it's going to be a bumpy ride. CDRE output is intense, and everything is logged.

The build up of files in COL is not a bug. It's caused by the input FTBL configured on the 4K not being correctly specified in COL and it creates lots of error files, basically an error line for every record. Depending on how busy the site is, eventually the Assistant HD fills up (at least, that parttion does, somewhere under /var/col) and COL will stop collecting. The problem with COL is that it wants to input, transform, output and deliver, and if it doesn't understand the record, you get lots of .err files. But all you really want is SFTP collection, i.e, COL collects the file, and your call logger SFTPs it off the Assistant. That's possible, but COL will have a look at that file when it's transferred it from RMX and build these error files. The solution is to either delete the error files (hourly cron job) or use an FTBL which COL can understand. There are already several FTBLs available in COL but none of them are the one you specify above. Maybe your call logging company can use all of them or none of them.

Going to version 8 may have been mentioned because in that version COL allows straight SFTP transfer, no .err files. But you can use V7 fine, just use a cron to delete the err files, you don't need to keep them or even look at them.

Remember once you use COL, Assistant becomes much more important because you need that COL config. If the Assistant is reinstalled, you will break your call logging until COL is reconfigured, so take screen shots of the config and also from Backup Restore, make a logical export of the config.

 

[donb01]

I wouldn't go to V8 now. V7 is EOL/EOS at the end of 2019 and they are planning to roll everyone to V10 somewhere around the end of May when the upgrade is available. If you have a current support contract you will have extended support thru the end of your contract or 9/20/20, whichever comes first. If you try to go to V8 now (or maybe after 10/31) there is some kind of screwy process where you say you want to upgrade to V8 and the licenses get issued, but you do not install V8 or activate the licenses. Then when the V10 upgrade is ready you order that and the V10 licenses and then upgrade straight to V10.

I know this because I got the bulletin (that was actually issued a couple years ago) and currently have a request in for my vendor to verify that no hardware changes are necessary to go to V10. If you're already on V8 you're good for a while, and if you stay on V7 with no plans to upgrade all support ends 12/31 I think (from Unify anyway). If you buy a support contract before the end of the year I think you get support on V7 until 9/2020.


Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA