Accueil > Réalisations > Logiciels > Outils pour autocommutateurs Alcatel 4400 > Alca-Line, analyse du trafic téléphonique sur un Alcatel 4400 > Principe de décodage des fichiers de taxation

Principe de décodage des fichiers de taxation

jeudi 4 janvier 2007, par Paul Courbis

Les fichiers que nous vennons de récupérer sont stockés sous un format binaire. Vous trouverez ci-dessous la procédure à suivre pour les transformer en une version lisible et explotable...

Les fichiers de taxation sont en effet des fichiers compressés (avec le compress unix calssique) contenant des enregistrements de type texte dont la décomposition est donnée dans leur première ligne . Par exemple :

#TicketVersion,1,5,L,CalledNumber,6,31,L,ChargedNumber,32,51,L,....

Ce qui signifie :

  • ’#’ commence une ligne de description de format
  • le premier champ s’appelle « Ticket version »
  • il commence en colonne 1 et se termine en colonne 5
  • son type est L (les types possibles sont ’L’, champ texte, ’N’, champ texte, et ’R’, nombre entier)
  • le deuxième champ est « CalledNumber »
  • etc...

Cette définition peut changer d’une version de logiciel à l’autre, version qui est d’ailleurs systématiquement rappelée dans le champ « TicketVersion ». Dans les versions que j’ai utilisé pour mes tests (4.8, 4.9 et 5.1), les champs sont les suivants :

Version
Champ4.84.95.1Contenu
TicketVersion
Version du ticket de facturation
CalledNumber
Numéro appelé ou appelant (selon le sens)
ChargedNumber
Poste facturé
ChargedUserName
Nom du titulaire du poste
ChargedCostCenter
Centre de coût
ChargedCompany
-
ChargedPartyNode
-
Subaddress
-
CallingNumber
-
CallType
PublicNetworkOutgoingCall (0), PublicNetworkOutgoingCallThroughPrivateNetwork (1), PrivateNetworkCall (2), LocalCall (3), PublicNetworkIncomingCall (4), PublicNetworkIncomingCallThroughPrivateNetwork (5), Unspecified (6), PrivateNetworkOutgoingCallToPublicNetwork (7), PrivateNetworkOutgoingCallToPrivateNetwork (8), PublicNetworkIncomingCallToPrivateNetwork (9), PrivateNetworkIncomingCallToPrivateNetwork (10), PublicOrPrivateNetworkOutgoingCallThroughPrivateNetwor (11), PublicOrPrivateNetworkIncomingCallThroughPrivateNetwork (12), PrivateNetworkIncomingCall (13), LocalLocalNode (14)
CostType
-
EndDateTime
Date/heure de fin de l’appel
ChargeUnits
Unités téléphoniques facturées
CostInfo
-
Duration
Durée de l’appel
TrunkIdentity
-
TrunkGroupIdentity
-
TrunkNode
-
PersonalOrBusiness
-
AccessCode
-
SpecificChargeInfo
-
BearerCapability
-
HighLevelComp
-
DataVolume
-
UserToUserVolume
-
ExternFacilities
-
InternFacilities
-
CallReference
-
SegmentsRate1
-
SegmentsRate2
-
SegmentsRate3
-
ComType
-
X25IncomingFlowRate
-
X25OutgoingFlowRate
-
Carrier
-
InitialDialledNumber
-
WaitingDuration
-
EffectiveCallDuration
-
RedirectedCallIndicator
-
StartDateTime
Date/heure de début de l’appel
ActingExtensionNumber
-
CalledNumberNode
-
CallingNumberNode
-
InitialDialledNumberNode
-
ActingExtensionNumberNode
-
TransitTrunkGroupIdentity
-
NodeTimeOffset
-

A noter que d’une version à l’autre le type et la taille des champs peuvents changer !

Notre procédure d’import va fonctionner comme suit :

1/ Nous allons creer une base de données vide qui servira de container aux données

2/ Nous allons ensuite creer dans cette base les tables nécessaires au bon fonctionnement de l’application :

  • une table temporaire « spooledfiles » qui contiendra la liste des fichiers disponibles (ce qui permettra de charger uniquement les nouveaux fichiers à partir du répertoire spool) ;
  • une meta table (meta_columndesc décrivant la table de données (d’une version à l’autre le format est succeptible de changer, nous garderons donc la liste des descriptifs pour savoir si le format existe déjà et, si tel n’est pas le cas nous ajusteront dynamiquement une nouvelle table) ;
  • un début de table taxdata contenant le minimum d’informations nécessaires au fonctionnement du système : un identifiant unique de ticket et l’identifiant du fichier qui le contenait.

Nb : dans les évolutions possibles du système, il conviendra de gérer des notions de profil (qui peut faire quoi), de type d’analyses prédéfinies avec une exécution paramétrable, etc... Pour le moment notre objectif est simplement de charger ces fichiers de taxation dans un SGBDR, puis de fournir quelques exemples de traitements en SQL pur. L’interface clickodromesque viendra plus tard ;-). De ce fait seront crées :

  • des tables décrivant des traitements et leur évènements déclencheurs ;
  • des tables associées stockant les résultats des dits traitements.

3/ La procédure d’import va calculer la liste des fichiers à importer puis les chargera en adaptant si nécessaire la table de stockage (ajout/conversion de colonnes).

Remarque : de manière à permettre un travail plus efficace les données seront retravaillées comme suit :

  • les « leading spaces » et « trailing spaces » seront supprimés ;
  • les dates (StartDateTime et EndDateTime) seront converties en « timestamp ».

Lire la suite...

Un message, un commentaire ?

modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Les spams donneront systématiquement lieu à dépôt de plainte. Les messages comportant trop de fautes d'orthographe seront purement et simplement supprimés.
ipv6 ready ipv6 test
Suivre ce site :
Recommander cette page :
Bookmark and Share
Traduire :