8770 3.2.8 Am Accountvoipticketscollect 8al90709frad 1 FR

Omnivista 8770
Tickets de taxation et de statistiques VoIP

Version 3.2.8 - Octobre 2017
8AL90709FRAD Ed. 01
Mentions légales
Les informations de cette publication sont sujettes à modification sans préavis.
ALE International ne peut être tenu responsable des inexactitudes contenues dans cette publication.
Copyright © ALE International, 2017
Avertissement
Bien que des efforts aient été faits pour vérifier l'exhaustivité et l'exactitude des informations contenues
dans cette documentation, ce document est fourni « tel quel ». Pour obtenir des informations plus
précises sur l'intercompatibilité, les limites du produit, la politique logicielle et la liste des fonction,
veuillez vous référer aux documents précis publiés sur le site web Business Partner.
Dans l'intérêt du développement continu des produits, ALE International se réserve le droit d'apporter
des améliorations à ce document et aux produits qu'il décrit, à tout moment et sans préavis ni
obligation.
Le marquage CE indique que ce produit est conforme aux Directives du Conseil ssuivantes :
• 2014/53/EU pour équipement radio
• 2014/35/EU et 2014/30/EU pour les équipements autres que radio (y compris les équipements de
terminaux de télécommunication câblés)
• 2014/34/EU pour équipement ATEX
• 2011/65/UE (RoHS)
Sommaire
Tickets de taxation et de
statistiques VoIP
Chapitre 1
Overview
1.1 Introduction.......................................................................................................................................5
1.1.1 Accounting tickets generated by Communication ................................................................5
1.1.2 Tickets VoIP générés par les serveurs de communication...............................................6
1.1.3 Génération de ticket de serveur de communication............................................................ 7
1.2 Exigences de connectivité du serveur de communication................ 8
1.3 Exigences d'application externes............................................................................... 8
1.4 Exigences de licence............................................................................................................... 9
Chapitre 2
Configuration procedure
2.1 Prérequis............................................................................................................................................10
2.2 Configurez les paramètres OmniPCX Enterprise pour la
transmission de tickets VolP..........................................................................................10
2.3 Configuration des paramètres de stockage des tickets .................... 11
2.4 Sélection de serveurs de communication pour la collecte des
tickets....................................................................................................................................................12
2.5 Configuration du filtre pour la taxation externe.......................................... 13
2.5.1 Installation d'un filtre pour OmniPCX Enterprise................................................................. 13
2.5.2 Vérification de la licence et définition du filtre pour OXO Connect.............................14
2.6 Récupération des tickets ..................................................................................................17
2.6.1 Lancement d'une synchronisation manuelle......................................................................... 17
8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 3/64

Sommaire
Tickets de taxation et de
statistiques VoIP
Chapitre 3
Ticket formats
3.1 OmniPCX Enterprise Tickets..........................................................................................19

3.1.1 Définitions du format .DAT..............................................................................................................19
3.1.2 Exemple de ticket................................................................................................................................29
3.2 OXO Connect Tickets............................................................................................................ 30
3.2.1 Format des fichiers.............................................................................................................................30
3.2.2 Définitions des champs de tickets.............................................................................................. 30
3.2.3 Exemple de ticket................................................................................................................................39
3.3 Format de tickets IP pour OmniPCX Enterprise..........................................39
3.3.1 Format de tickets IP pour OmniPCX Enterprise.................................................................. 40
3.3.2 Définitions des champs de tickets IP........................................................................................ 43
3.3.3 Lecture de ticket binaire...................................................................................................................60

Chapitre
1 Overview
1.1 Introduction
Les rapports CDR (Call Detail Records) du serveur de communication comprennent plusieurs éléments
de données (numéro appelé, type d'appel, etc.) conçus pour permettre la facturation des coûts par une
application de comptabilité externe.
L'application OmniVista 8770 permet de :
• garantir la connexion à un système de serveur de communication de manière périodique ;
• récupérer les enregistrements CDR et les tickets VoIP par transfert FTP ;
• copier les fichiers qui contiennent les CDR et les tickets VoIP sur un disque disponible sur le
serveur OmniVista 8770 ;
• stocker ces fichiers sur un disque pour une période définie.
Les enregistrements de statistiques VoIP du serveur de communication contiennent plusieurs éléments
de données (codec utilisé, impact gigue, perte de paquets, délai, etc.) conçus pour identifier les causes
de problèmes potentiels avec des terminaux IP connectés à un serveur de communication susceptibles
de produire une qualité de service (QoS) médiocre.
Les tickets VoIP pour OXO Connect et OmniPCX Enterprise sont similaires en termes de contenu,
mais ils présentent des différences au niveau matériel et réseau.
Les données stockées dans le collecteur peuvent être utilisées par OmniVista 8770 pour consulter :
• le ticket de taxation du serveur de communication depuis l'application de taxation OmniVista 8770
• les tickets VoIP OXO Connect et OmniPCX Enterprise depuis l'application de taxation OmniVista
8770
Les données du collecteur peuvent être exportées vers des applications tierces pour fournir des
enregistrements de statistiques du serveur de communication à des fins d'analyse ou de comptabilité.
Dans ce document, le terme « serveur de communication » peut se référer :
• OmniPCX Enterprise serveur (à partir de R6.0 pour la comptabilité CDR et R8.0 pour les tickets
VoIP)
• au serveur OXO Connect.
• OmniPCX Office RCE serveur (à partir de R5.1)
1.1.1 Accounting tickets generated by Communication

1.1.1.1 Tickets collectés sur OmniPCX Enterprise
L'OmniPCX Enterprise génère et stocke plusieurs fichiers *.DAT contenant tous les CDR concernant la
même période horaire. Les filtres doivent être appliqués pour la taxation externe. Sur le serveur de
communication :
1. Toutes les heures, une compression de compte de commande est lancée automatiquement pour
générer un fichier compressé TAXAXXXX.DAT contenant un fichier au format texte avec le même
nom TAXAXXXX.DAT.
2. Le nom de ce fichier s'ajoute à ACCOUNT.LIS
3. ACCOUNT.LIS et .DAT sont stockés sous usr4\ACCOUNT
Note :
XXXX est un compteur utilisant des lettres

Chapitre 1 Overview
Les TAXAxxxx.dat sont stockés sur le serveur de communication pendant 94 jours

Sur OmniVista 8770, lorsqu'une requête de synchronisation est soumise :
1. La compression de compte de commande est forcée sur le serveur de communication
2. Le fichier ACCOUNT.lis est chargé
3. Le fichier d'information Last Polled File est lu depuis la déclaration du serveur de communication
4. Seul le fichier présent dans ACCOUNT.LIS et dont le compteur est postérieur au dernier fichier
sondé est récupéré via ftp
5. Le fichier d'information Last Polled File est mis à niveau
Note :
Si le processus de taxation est activé, les fichiers *.DAT sont directement chargés dans la base de données
OmniVista 8770
Si le collecteur est activé, les fichiers *.DAT sont décompressés dans le dossier du collecteur, dans un sous-
répertoire nommé Networknumber=X\SubnetwornodeNumber=YYY
1.1.1.2 Tickets collectés sur OXO Connect

OXO Connect fonctionne avec un buffer de tickets CDR. Sur le serveur de communication, vous devez
spécifier certains paramètres pour la taxation
Lorsqu'une requête de synchronisation est soumise par OmniVista 8770 :
1. Le buffer est chargé comme un fichier unique
2. Un fichier binaire est chargé et nommé ALZxxxx.ALZ
3. Un en-tête est ajouté à ce fichier avec un numéro de nœud et de version OXO Connect
4. Le fichier d'information Last Polled File est mis à niveau
5. Sur le serveur de communication, le contenu du buffer est redéfini
Note :
• Si des alarmes urgentes émanant d'OXO Connect sont récupérées par OmniVista 8770, une synchronisation
est forcée sur le serveur de communication.
• xxxx est un compteur utilisant un numéro
• Si le processus de taxation est activé, les fichiers *.ALZ files sont chargés directement dans la base de
données OmniVista 8770
• Si le collecteur est activé, le fichier *.ALZ est décompressé dans le dossier collecteur, dans un sous-
répertoire nommé Networknumber=X\SubnetwornodeNumber=YYY
1.1.1.3 Synchronisation manuelle

Dans certains cas, des données récentes peuvent être requises pour une analyse immédiate. Dans ce
cas, une synchronisation manuelle permet de collecter les données.
1.1.2 Tickets VoIP générés par les serveurs de communication

Les enregistrements de statistiques VoIP du serveur de communication contiennent plusieurs éléments
de données (codec utilisé, impact gigue, perte de paquets, délai, etc.) conçus pour identifier les causes
de problèmes potentiels avec des terminaux IP connectés à un serveur de communication susceptibles
de produire une qualité de service (QoS) médiocre.
Les tickets VoIP pour OXO Connect et OmniPCX Enterprise sont similaires en termes de contenu,
mais ils présentent des différences au niveau matériel et réseau.
Un ticket IP est généré à la fin de chaque communication impliquant l'un des équipements suivants :
• Téléphones IP (Poste de bureau 80x8, 80x8 Premium DeskPhone et postes 80x8s Premium
DeskPhone)
• Carte IP

Chapitre 1 Overview
• Softphone IP Desktop (IPDSP) (uniquement OmniPCX Enterprise)

• 4645 Voice mail (4645 VMS) (uniquement OmniPCX Enterprise)
Une communication entre deux postes IP Alcatel-Lucent peut être divisée en un ou plusieurs
segments, chaque segment générant deux tickets ses extrémités.
Par exemple, une communication entre un téléphone IP A et un téléphone IP B venant du même nœud
crée un segment avec deux tickets, un ticket généré par le téléphone IP A et un autre par le téléphone
IP B.
Des cas plus complexes sont possibles, tel un appel entre un téléphone IP et un téléphone UA entre
deux nœuds.
Exemples d'appels complexes :
• Il est possible de créer plus d'un segment
• Il est possible de créer un segment dédié à la signalisation (tonalité Ringback)
• Si l'un des utilisateurs IP n'est pas un terminal IP Alcatel-Lucent, aucun ticket n'est généré par cet
utilisateur et un seul ticket est alors généré (par le terminal IP Alcatel-Lucent) pour ce segment
spécifique
• Si les domaines sont gérés avec des restrictions de codec, davantage de segments IP peuvent être
créés (chemins intermédiaires via carte DSP) dans le cas des communications extra-domaine
Note :
• Les tickets générés pour une tonalité Ringback ne sont pas utiles et ne doivent pas être pris en compte pour
une analyse QoS.
• Les terminaux IP non-Alcatel-Lucent et les terminaux SIP ne génèrent pas de tickets IP. Par exemple, un
segment entre une carte GD et un terminal H323 génère uniquement un ticket à partir de la carte GD (le
terminal H323 ne génère pas de ticket IP)
• Les PBX peuvent également générer des tickets CDR (voir Tickets de taxation générés par les serveurs de
communication à la page 5) mais ces derniers n'ont aucun rapport avec les tickets IP. Aucune corrélation ne
peut être faite entre les deux types de tickets.
1.1.3 Génération de ticket de serveur de communication

Sur son disque, OmniPCX Enterprise génère plusieurs fichiers de tickets IP compressés avec
l'extension « .DAT », contenant tous les tickets IP concernant la même période horaire.
Sur OmniPCX Enterprise :
• Toutes les heures, le processus de compression de compte est lancé automatiquement
• Cette opération génère un fichier compressé IPXXXX.DAT contenant un fichier au format texte,
avec le même nom IPXXXX.DAT. L'algorithme de compression utilisé est l'algorithme LZW (ce
dernier peut être décompressé via winzip, gzip, etc.).
• Le nom de ce fichier est ajouté au fichier log IP.LIS
• Les fichiers IP.LIS et IPXXXX.DAT sont stockés sous \usr4\
Note :
• XXXX est un compteur utilisant des lettres. Les lettres sont incrémentées dans l'ordre ascendant
• Un fichier « IPxxxx.dat » est conservé sur OXE pendant 15 jours, par défaut
• Le fichier de tickets statistiques VolP compressé peut être généré plus fréquemment en exécutant la
commande de compression de compte sur OXE
• Les tickets IP générés sur un PCS (lorsqu'il est actif) sont nommés : IPXXXX<PCS_IP_@>.DAT où
<PCS_IP_@> est la valeur hexadécimale de l'adresse IP PCS
• Les fichiers de tickets IP de configuration de duplication générés sur le disque dur principal sont dupliqués sur
la CPU de secours. Le même principe s'applique au PCS lorsque ce dernier est en état d'inactivité.

Chapitre 1 Overview
1.2 Exigences de connectivité du serveur de communication

Le tableau suivant indique :
• Les exigences de version pour la collecte des tickets avec OmniVista 8770
• L'extension de fichier utilisée pour les fichiers collectés
• La connectivité et le protocole utilisés
Serveurs de com- Version prise en Fichiers collec- Connectivité IP Connectivité mo-

munication pris en charge tés dem
charge
OmniPCX Office Toutes versions à Binaires Oui

RCE partir de la R5.1
*.alz
OXO Connect Toutes versions à Binaires Oui

partir de la R2.0
*.alz
OmniPCX Enterpri- Toutes les ver- Texte Oui

se sions, à partir de
*.dat
R8.0
1.3 Exigences d'application externes

Les applications externes ont besoin de :
• Charger les fichiers de tickets IP (IP*.DAI ) à partir du répertoire collecteur
• Charger les fichiers tickets IP en tant que fichiers binaires
• Utiliser les données de tickets IP pour calculer la qualité QoS VoIP
L'application tierce pourrait interagir avec sa base de données pour répondre aux requêtes utilisateur :
1. L'utilisateur définit les critères de recherche spécifiques pour produire des valeurs de champs de
ticket. Les critères sont utilisés pour définir un filtre
2. L'application contacte la base de données et fournit le filtre à appliquer aux données.
3. La base de données renvoie un ensemble de résultats à l'application contenant les tickets
correspondant au filtre.
4. L'application affiche la liste de tickets dans la vue d'ensemble des tickets.
Il est possible de définir différents types de filtre :
• Champs liés à la connexion : adresse IP locale et distante, numéro de réseau, numéro de nœud,
numéro cristal, numéro de coupleur
• Champs liés à l'appel : référence d'appel local et distant, durée d'appel, type d'équipement
• Champs liés à la qualité : perte de paquets RTP, impact gigue, délai, etc.
• Filtre défini par l'utilisateur : l'utilisateur peut définir
• définir les champs,
• appliquer les limitations de valeur,
• appliquer un opérateur arithmétique.
En utilisant les données de tickets IP, l'application peut calculer de nouveaux champs QoS comme
MOS, la moyenne de gigue, le pourcentage de perte de paquets RTP, etc.

Chapitre 1 Overview
1.4 Exigences de licence

Des licences spécifiques sont requises pour OmniVista 8770 pour collecter efficacement les CDR et
les tickets VoIP.
Vous pouvez vérifier le statut de licence dans le menu d'aide de l'application OmniVista 8770 (chemin
d'accès : Help > About)
La liste des licences possibles est la suivante :
• Ticket Collector - licence utilisée pour accéder à la fonction des justificatifs de taxation. Sa valeur
représente le nombre maximum d'utilisateurs que le Ticket Collector peut gérer (à la fois pour les
CDR et pour les tickets VoIP)
• Accounting - licence utilisée pour accéder à l'application de taxation. Sa valeur représente le
nombre maximum d'utilisateurs que l'application de taxation peut gérer. Elle donne également
accès à la fonction CDR Ticket Collector.
• Performance - licence utilisée pour accéder à l'application d'observation des performances de la
voix sur IP pour OmniPCX Enterprise. Sa valeur représente le nombre maximum d'utilisateurs
OmniPCX Enterprise que l'application d'observation VoIP peut gérer. Elle donne également accès à
la fonction VoIP Ticket Collector d'OmniPCX Enterprise

Chapitre
2 Procédure de configuration
2.1 Prérequis
Pour configurer OmniVista 8770 pour la collecte de tickets :
• OmniVista 8770 et ses applications doivent être installés correctement et être opérationnels.
Pour plus d'informations, consultez le manuel d'installation OmniVista 8770 (voir : omnivista8770/fr/
th0120_installation/ft0000_0000_na/sf0000_0000_0000_na/dm09011b0281121eef.dita).
• Les serveurs de communication doivent être déclarés dans l'application OmniVista 8770
Configuration
Pour en savoir plus sur la déclaration des serveurs de communication , voir : Déclaration d'un
réseau de serveur de communication.
2.2 Configurez les paramètres OmniPCX Enterprise pour la

transmission de tickets VolP
Cela fait référence à une option système dans l'outil de gestion OmniPCX Enterprise, pour activer ou
pour désactiver la transmission de tickets IP.
1. Sélectionnez IP
2. Renseignez les attributs suivants :
Attributs Valeurs
IP Ticket Sélectionnez et cliquez sur Yes pour activer la transmission des tic-
kets.
Valeur par defaut : No
Max Nb. Days of Storage Entrez le nombre de jours de stockage des fichiers compressés, en-
tre 1 et 31.
Valeur par défaut : 15
3. Validez.
Vérifiez le paramètre de taxation suivant :
1. Sélectionnez Applications > Accounting
2. Renseignez les attributs suivants :
Attributs Valeurs
Files for External Ac- Sélectionnez et validez Yes pour activer la transmission des tickets
counting vers l'application externe.
Valeur par defaut : No
3. Validez.

Chapitre 2 Procédure de configuration
2.3 Configuration des paramètres de stockage des tickets

Vous pouvez modifier les deux paramètres de collecteur suivants :
• Chemin utilisé pour collecter les tickets
• Délai (nombre de jours) pendant lesquels les fichiers de données collectés sont stockés avant d'être
supprimés
Pour modifier le chemin de collecte :
1. Depuis l'application OmniVista 8770 Administration, sélectionnez nmc > OmniVista 8770 > name
of server > NmcArchive > Collector
2. Dans le champ Path, entrez le chemin utilisé pour collecter les tickets
3. Dans l'onglet Common, entrez la période pour la date de collecte à stocker dans le champ Clean-
up Delay
Pour Windows®
Si le chemin n'emmène pas vers un disque local mais vers un PC distant, vous devez définir un
utilisateur capable de voir ce disque et ajouter les droits d'accès suivants pour cet utilisateur :
• Agissez dans le cadre du système d’exploitation
• Augmentez le quota
• Remplacez un jeton processus
• Ouvrez une session localement
Sur OmniVista 8770 :
1. Dans l'application Administration, sélectionnez nmc > OmniVista 8770 > name of server >
Service > SyncLdapPbx

2. Dans l'onglet NT account, entrez le Username et le Password

Note :
Le format du nom d'utilisateur NT est :
• Ntdomain\userlogin pour un login défini dans un domaine
• Pcname\userlogin pour un login défini dans un groupe de travail
2.4 Sélection de serveurs de communication pour la collecte des tickets

Cette procédure est utilisée pour sélectionner
• les serveurs de communication pour lesquels vous souhaitez collecter les données de tickets ;
• le type de tickets que vous souhaitez récupérer et stocker.
Pour activer la collecte de tickets, effectuez les opérations suivantes :
1. Dans l'application Configuration, sélectionnez le serveur de communication
2. Cliquez sur l'onglet Data Collection.

3. Double-cliquez sur le champ d'attribut Record/Ticket Collection, puis sélectionnez l'une des
options suivantes :
• Accounting : pour stocker les fichiers de taxation uniquement
• VoIP : pour stocker les fichiers VoIP uniquement
• Accounting and VoIP : pour stocker à la fois les fichiers de taxation et VolP
Lors de la synchronisation, les fichiers seront stockés dans le répertoire 8770\data\collector.
Les fichiers de taxation sont nommés comme suit : TAXAxxxx.DAT (pour OmniPCX Enterprise),
taxaxxxxx.alz (pour OXO), taxaxxxxx.ofc (pour OXO Connect).
Les fichiers VoIP sont nommés comme suit : IPXXX.DAI (uniquement pour OmniPCX Enterprise).
2.5 Configuration du filtre pour la taxation externe

2.5.1 Installation d'un filtre pour OmniPCX Enterprise
Pour ajouter un nouveau filtre :
1. Dans l'application Configuration, sélectionnez le serveur de communication et effectuez un clic
droit : Configure
Sur le modèle d'objet du serveur de communication :
1. Sélectionnez l'entrée Application -> Accounting
2. Sélectionnez l'onglet All

3. Définissez le champ Files for external Accounting sur Yes

4. Le tableau des filtres doit être renseigné avec les types d'appels
2.5.2 Vérification de la licence et définition du filtre pour OXO Connect

Pour vérifier la licence pour la taxation des tickets :

1. Dans l'application de configuration, sélectionnez l'entrée serveur de communication. Effectuez un

clic droit et sélectionnez Configure /Online mode pour lancer OMC.
2. Sélectionnez Hardware and Limits ->Software Key Features
La fenêtre des caractéristiques logicielles clés s'affiche.
Dans l'onglet Network Management, vérifiez que les champs sont Enabled (activés) pour la
collecte des tickets
Pour vérifier ou modifier les filtres :
1. Depuis les sous-répertoires du serveur de communication, sélectionnez Counting -> Counting
La fenêtre Counting s'affiche.
2. Sélectionnez la case External Metering Activation

3. Validez et cliquez sur le bouton Fields pour afficher la fenêtre Accounting: Printed Proof Fields

4. Sélectionnez tous les éléments pour tous les champs que vous souhaitez collecter et cliquez sur
OK
5. Dans le menu principal, sélectionnez Network Management Control -> Centralized Management
La fenêtre de gestion centralisée s'affiche.
6. Sélectionnez Incoming&Outgoing calls pour Active call accounting

7. Cliquez sur OK

2.6 Récupération des tickets

Le planning des tâches dans OmniVista 8770 lance une synchronisation sur chaque serveur de
communication et récupère les tickets CDR et IP CDR. Par défaut, la tâche est programmée chaque
nuit à 1h45.
Pendant la synchronisation , le module « Ticket Collector » récupère, via ftp, les fichiers IP*.DAT (qui
contiennent des données de tickets IP) et les fichiers TAX*.DAT (qui contiennent les données de tickets
de taxation), et stocke ces fichiers dans le dossier collecteur OmniVista 8770 (ce dossier peut être un
répertoire local ou externe défini par un administrateur OmniVista 8770). Par défaut, le chemin du
dossier collecteur est \8770\data\collector.
Ces fichiers sont stockés pour une période définie dans la base de données OmniVista 8770. Ce délai
de nettoyage, ou « clean-up », (délai en jours avant la suppression des données collectées) peut être
changé par l'administrateur OmniVista 8770.
Les fichiers sont présentés sous une forme non compressée utilisable par une application externe. Les
fichiers *.DAT ne sont pas compressés (format propriétaire serveur de communication) et sont
sauvegardés dans le dossier collecteur sous l'extension .DAI, dans un sous-répertoire distinct, nommé
pour chaque serveur de communication comme suit :
« Networknumber=X\SubnetworknodeNumber=YYY »
2.6.1 Lancement d'une synchronisation manuelle

Une synchronisation manuelle peut être lancée pour une collecte de tickets spécifique.
Pour lancer la synchronisation manuelle :
1. Connectez-vous comme adminnmc et lancez l'application Configuration.
2. Sélectionnez le serveur de communication dans l'arborescence réseau.
3. Effectuez un clic droit et sélectionnez Synchronization -> Complete -> Global
La boîte de dialogue Create multiple tasks in the Scheduler... s'affiche.

4. Cliquez sur le bouton Now dans le champ Start Date

5. Cliquez sur Apply et Close pour lancer la synchronisation et fermer la boîte de dialogue.

Chapitre
3 Ticket formats
3.1 OmniPCX Enterprise Tickets

Cette section décrit le format de fichiers pour les tickets collectés à partir de OmniPCX Enterprise.
Mode de formatage d'un fichier .DAT et exemple de fichier .DAT
3.1.1 Définitions du format .DAT

Chaque fichier collecté a le même format afin de pouvoir l'ouvrir avec un éditeur de texte.
Il n'y a pas de séparateur de colonnes et chaque colonne a une taille spécifique.
Pour assurer une meilleure visibilité, certains champs sont justifiés à droite ou à gauche.
Exemple : le numéro appelé commence à la position 6, se termine à la position 35, est justifié à
gauche et contient au maximum 30 chiffres.
• Position : position du premier et du dernier caractère du champ dans la ligne
• Justifié : position du texte dans la ligne
• L : left (gauche)
• R : right (droite)
• N : non significatif
tableau 3.1 : Format de fichier des champs .DAT pour l'affichage de la mise en page
Nom de champ position taille (caractères) justifié
Ticket Version 1,5 5 L
CalledNumber 6,35 30 L
ChargedNumber 36,65 30 L
ChargedUserName 66,85 20 L
ChargedCostCenter 86,95 10 L
ChargedCompany 96,111 16 L
ChargedPartyNode 112,116 5 R
ChargedPartySubaddress 117,136 20 L
CallingNumber 137,166 30 L
CallType 167,168 2 R
CostType 169 1 R
EndDateTime 170,186 17 N

Chapitre 3 Ticket formats
ChargeUnits 187,191 5 R
CostInfo 192,201 10 R
Duration 202,211 10 R
TrunkIdentity 212,216 5 R
TrunkGroupIdentity 217,221 5 R
TrunkNode 222,226 5 R
Personal or Business 227 1 N
AccessCode 228,243 16 L
SpecificChargeInfo 244,250 7 N
BearerCapability 251 1 L
HighLevelComp 252,253 2 R
DataVolume 254,263 10 R
UserToUserVolume 264,268 5 R
ExternFacilities 269,308 40 N
InternFacilities 309,348 40 N
CallReference 349,358 10 R
SegmentsRate1 359,368 10 R
ComType 389 1 N
X25IncomingFlowRate 390,391 2 R
X25OutgoingFlowRate 392,393 2 R
Carrier 394,395 2 R
InitialDialledNumber 396,425 30 L
WaitingDuration 426,430 5 R

EffectiveCallDuration 431,440 10 R
RedirectedCallIndicator 441 1 R
StartDateTime 442,458 17 N
ActingExtensionNumber 459,488 30 L
CalledNumberNode 489,493 5 R
CallingNumberNode 494,498 5 R
InitialDialledNumberNode 499,503 5 R
ActingExtensionNumberNode 504,508 5 R
TransitTrunkGroupIdentity 509,513 5 R
NodeTimeOffset 514,519 5 R
TimeDlt 520,525 6 R
EndOfLine Unix EOL 0A (10 décimales) N
tableau 3.2 : Descriptions des champs pour OmniPCX Enterprise
Nom de Decription/Valeur Utilisation en fonction du type

champ d'appel
Local Transit Sortant Entrant

et ré- ABC
seau
Ticket Version ED5.2 X X X X
Called Num- Dépend du type d'appel X - X X

ber
Charged Dépend du type d'appel X X X X

Number
Charged User Dépend du numéro taxé - - X X

Name
Charged Cost Dépend du numéro taxé X - X X

Center
Charged Non utilisé - - - -

Company


champ d'appel

et ré- ABC
seau
Charged Par- Numéro de sous réseau 100* + numéro de X X X X

tyNode nœud
Dans des réseaux hétérogènes, ce champ
n'est pas renseigné si le protocole ne le per-
met pas
Charged Par- Utilisé uniquement pour les appels RNIS sor- - - X X

ty Subad- tant, sinon vide
dress
Calling Num- Transfert du numéro de l'appelé après le X - X X

ber transfert
CallType 0 : PublicNetworkOutgoingCall, X X X X
1 : PublicNetworkOutgoingCall ThroughPriva-
teNetwork,
2 : PrivateNetworkOutgoingCall,
3 : LocalNetworkCall,
4 : PublicNetworkIncomingCall,
5 : PublicNetworkIncomingCall ThroughPriva-
teNetwork,
6 : UnspecifiedCall,
7 : PrivateNetworkOutgoingCall ToPublicNet-
work,
8 : PrivateNetworkOutgoingCall ToPrivateNet-
work,
9 : PublicNetworkIncomingCall ToPrivateNet-
work,
10 : PrivateNetworkIncomingCall ToPrivate-
Network,
11 : PublicOrPrivateNetworkOutgoingCall
ThroughPrivateNet.
12 : PublicOrPrivateNetworkIncomingCall
ThroughPrivateNet.
13 : PrivateNetworkIncomingCall,
14 : LocalLocalCall,
15 : LocalTransitCall


champ d'appel

et ré- ABC
seau
Cost Type 0 : Unspecified – ABC-F trunkCall, - - X -

1 : AnalogTrunkCall,
2 : ISDNCircuitSwitchedCall,
3 : ISDNPacketCallX25-Bchannel,
4 : ISDNPacketCallX25-Dchannel,
5 : X25,
6 : DigitlNonISDN
End Date Ti- Date de fin de communication ou de transfert X X X X

me de communication
Aaaammjj hh:mm:ss
ChargeUnits Impulsions reçues du réseau public - - - X
CostInfo - - X X
Duration X X X X
Trunk Identity Numéro d'identification de faisceau (joncteur - - X X

privé ou interface de ligne privée)
Trunk Group Numéro de faisceau - X X X

Identity
TrunkNode Numéro de sous réseau 100* + numéro de - X X X

nœud
Personal or 0 : Personnel, - - X -
Business
1 : Professionnel,
2 : Normal,
3 : Invité
Access Code Code taxation affaire, PIN ou vide - - X -


champ d'appel

et ré- ABC
seau
Specific 0 : SIOPriorityTrunkGroup, - - X -
ChargeInfo
2 : BXGeneratedChargeUnits,
3 : AnalogWithoutChargeUnits,
4 : Transcom,
5 : AccurateDuration
6 : Transgroup
Bearer Capa- 0 : Non spécifié, - - X -

bility
1 : Illimité,
2 : Vocale,
3 : Audio3,
4 : Audio7,
5 : Audio15,
6 : Vidéo
High Level 0 : Non spécifié, - - X -

Comp
1 : Téléphonie,
2 : Fax Groupe 3,
3 : Mode mixte,
4 : Fax Groupe 4,
5 : Caractère Télétex,
6 : Vidéotex,
7 : Télex,
8 : MHS,
9 : Application OSI
10 : Son,
11 : Son Vidéotex,
12 : SlowScanVideo
13 : Application non standard
Data Volume Nombre d'octets transmis pendant une com- - - - -

munication RNIS


champ d'appel

et ré- ABC
seau
User To User Nombre d'octets transmis ou nombre de mini- - - X -

Volume messages (option système)
External Faci- 0 : CallingLineIdentificationPresentation, - - X -

lities
1 : ConnectedLineIdentification Presentation,
2 : CallingLineIdentificationRestriction,
3 : ConnectedLineIdentification Restriction,
4 : MaliciousCallIdentification,
5 : CallForwardingUnconditional
6 : CallForwardingOnBusy
7 : CallForwardingOnNoReply
8 : Transfer
9 : AdviceOfChargeAtSetup,
10 : AdviceOfChargeDuringCall,
11 : AdviceOfChargeAtEnd
12 : ClosedUserGroup
13 : CallWaiting,
14 : UserToUserSignalling,
15 : UserUserFacility,
21 : Mini-messaging,
22 : SubAddressing


champ d'appel

et ré- ABC
seau
Internal Faci- 5 : CallForwardingUnconditional, - - X -

lities
6 : CallForwardingOnBusy,
7 : CallForwardingOnNoReply,
8 : Transfer,
23 : BasicCall,
24 : OperatorFacility,
25 : Substitution,
26 : PriorityIncomingCall,
27 : Transit, 28 : PrivateOverflowToPublic,
29 : ReroutingPublicToPrivate,
30 : FaxServer,
31 : VoiceMail,
32 : CentralAbbreviatedNumberring,
34 : IntegratedServiceVPN,
35 : OverflowVPN,
36 : ARSService,
37 : Disa
Call Referen- Non utilisé - - - -

ce
Segments Non utilisé - - - -

Rate1

Rate2

Rate3
Com Type 0 : no specified - - X -

1: Voice
2: Data
3: FacilityActivation,
4: FacilityDeactivation


champ d'appel

et ré- ABC
seau
X25Incoming 0: Unspecified - - - -
FlowRate
1: 75
2: 150
3: 300
4: 600
5: 1200
6: 2400
7: 4800
8: 6900
9: 19 200
10: 48 000
11 :64 000
12: > 64 000
X25Outgoing 0: Unspecified - - - -
FlowRate
1: 75
2: 150
3: 300
4: 600
5: 1200
6: 2400
7: 4800
8: 6900
9: 19 200
10: 48 000
11 :64 000
12: > 64 000
Carrier 0 : pas d'opérateur ou non spécifié, numéro - - X -

de table ARS (1 à 10)
InitialDialled Numéro initial composé pour un appel entrant X X X X

Number ou numéro appelé lorsque le service ARS est
utilisé


champ d'appel

et ré- ABC
seau
Temps de ré- Pour les appels entrants : durée avant répon- - - - X

ponse se (en secondes)
Effective Call- Uniquement avec les appels entrants - - - X

Duration
Redirected Uniquement avec les appels entrants et ceux X - - X

CallIndicator du réseau ABC : le poste qui répond n'est pas
le numéro initialement composé.
StartDate Ti- Aaaammjj hh:mm:ss - - X X

me
Acting Exten- Nombre de postes physiques facturés. Il peut X - X -

sion Number s'agir d'un numéro local (cas de substitution),
d'un numéro public (Disa), d'un numéro de
faisceau (FSxxx, FPxxx, FCxxx) ou d'un nu-
méro de nœud (SNxxx)
Called Num- Numéro de sous réseau 100* + numéro de X - - -

ber Node nœud
Nœud de nu- Numéro de sous réseau 100* + numéro de X - - -

méro de l'ap- nœud
pelant
Nœud du nu- Numéro de sous réseau 100* + numéro de X X - -

méro initial nœud
composé
Acting Exten- Numéro de sous réseau 100* + numéro de X - X -

sion Number nœud
Node
Valeur 99999 si le nœud n'est pas connu ; va-
leur XXX99 si seul le sous-réseau est connu
Transit Trunk Numéro du faisceau entrant sur le nœud de - X - -

Group Identi- transit
ty
Node Tim Décalage de temps (en secondes) entre - - X X

eOffset 2 nœuds ; utilisé lorsque le justificatif supplé-
mentaire des détails d'appel est généré sur le
nœud de l'abonné ; non significatif sur le
nœud du faisceau.


champ d'appel

et ré- ABC
seau
TimeDlt Différence entre le fuseau horaire du faisceau X X X X

et celui du système
EndOfLine
3.1.2 Exemple de ticket

L'exemple suivant d'un TAXAXXXX.DAT a été obtenu avec la commande accview –tf.
Il restitue les détails d'un appel externe sortant :
• ext 300 a appelé 305 via une boucle E1 RNIS
====[/DHS3dyn/account/TAXATUCZ.DAT : Ticket number 1/1/1]=======================
(00) TicketVersion = ED5.2 (01) CalledNumber = 305
(02) ChargedNumber = 300 (03) ChargedUserName = IP_300 IP touch
(04) ChargedCostCenter = (05) ChargedCompany =
(06) ChargedPartyNode = 3 (07) Subaddress =
(08) CallingNumber =
(09) CallType = PublicNetworkOutgoingCall
(10) CostType = ISDNCircuitSwitchedCall (11) EndDateTime = 20090825 09:46:43
(12) ChargeUnits = 0 (13) CostInfo = 0
(14) Duration = 6 (15) TrunkIdentity = 1
(16) TrunkGroupIdentity = 0 (17) TrunkNode = 3
(18) PersonalOrBusiness = Normal (19) AccessCode =
(20) SpecificChargeInfo = (21) BearerCapability = Speech
(22) HighLevelComp = Telephony (23) DataVolume = 0
(24) UserToUserVolume = 0 (25) ExternFacilities =
CallingLineIdentificationPresentation
(26) InternFacilities = BasicCall (27) CallReference = 2
(28) SegmentsRate1 = 0 (29) SegmentsRate2 = 0
(30) SegmentsRate3 = 0 (31) ComType = Voice
(32) X25IncomingFlowRate = Unspecified (33) X25OutgoingFlowRate = Unspecified
(34) Carrier = 0 (35) InitialDialledNumber =
(36) WaitingDuration = 0 (37) EffectiveCallDuration = 0
(38) RedirectedCallIndicator = 0 (39) StartDateTime = 20090825 09:46:37
(40) ActingExtensionNumber = 300 (41) CalledNumberNode = 9999
(42) CallingNumberNode = 9999 (43) InitialDialledNumberNode = 9999
(44) ActingExtensionNumberNode = 3 (45) TransitTrunkGroupIdentity = 32767
(46) NodeTimeOffset = 0 (47) TimeDlt = 0

3.2 OXO Connect Tickets

3.2.1 Format des fichiers
Le format est différent des justificatifs au fil de l'eau, le collecteur utilise des tickets natifs.
Ce fichier peut être affiché avec un éditeur Hexa. La ligne d'en tête (en mode ASCII) comprend la
version OmniPCXOXO et les données Ticketsize, TicketNumber, Network, SubNetwork, NodeNumber.
• PabxRelease = 3EH30300FJAA ALZFR200/032.013
• #TicketSize=122
• #TicketNumber=4 (nombre de tickets dans le fichier)
• #NetworkNumber=0
• #SubNetworkNumber=0
• #NodeNumber=1
• #DataBegin” 0a”
3.2.2 Définitions des champs de tickets

Notez que le champ avec le caractère + (type d'utilisateur) est uniquement utilisé de manière isolée et
que le caractère * (numéro de nœud) est uniquement utilisé pour le réseau. Le mode Networking Mode
est défini lorsque le champ mode Accounting Ticket Mode est égal à 03

Champ octet taxa00018.alz infos
user type 1 00 subscriber

Décimal :
• 0 : l'utilisateur est un abonné
• 1 : interface analogique externe (faisceau analogique,
ligne privée analogique)
• 2 : accès de base public (T0) ou privé (dtl0)
• 3 : accès principal public (t2) ou privé (dtl2)
• 4 : groupe d'abonnés ou d'opérateurs
• 5 : accès T1
• 6 : joncteur IP
En fonction du type d'utilisateur « User type », le numéro
taxé « ChargedNumber » aura le préfixe suivant :
• 1 : => préfixe = ‘L’
• 2 : => préfixe = ‘N’
• 3 et 5 :=> préfixe = ‘P’
• 6 : => préfixe = ‘V’
user id 2 20 1 à 8 chiffres codés sur 8 octets

• USER TYPE = 0 : ‘0’..’9’,‘A’..’D’,’*’,’#’
• USER TYPE = 1 : ‘0’..’9’ (<=35)
• USER TYPE = 2 : ‘0’..’9’ (<=17)
• USER TYPE = 3 : ‘0’..’7’ (<=7)
• USER TYPE = 4 : ‘0’..’9’,‘A’..’D’,’*’,’#’
• USER TYPE = 5 : ‘0’..’7’ (<=7)
• USER TYPE = 6 : ‘0’..’9’ (<=35)
3 20
4 20
5 20
6 20
7 32 2
8 32 2
9 36 6

call type 10 00 Décimal :

• 0 = appel sortant
• 1 = appel entrant
• 2 : transfert d'un appel sortant
• 3 : transfert d'un appel entrant
• 4 : appel sortant en transit
• 5 : appel entrant en transit
• 6 : connexion d'un joncteur et d'une ligne privée sur le
transfert d'un appel entrant
• 7 : connexion d'un joncteur et d'une ligne privée sur le
transfert d'un appel sortant
• 8 : requête de centre
• 9 : annulation d'opération
• 10 : données sortantes
• 11 : données entrantes
• 12 : connexion sortante
• 13 : appel privé sortant
• 14 : appel privé entrant
• 15 : sortie 16 : intrusion
• 255 : non défini
trunk line type 11 03 Décimal :

• 1 : interface analogique externe (faisceau analogique,
ligne privée analogique)
• 2 : accès de base public (t2) privé (dtl2)
• 3 : accès principal public (t2) privé (dtl2)
• 4 : accès T1
• 5 : faisceau IP
trunk line ident. 12 30 TYPE TRUNK_LINE TYPE = 1 : ‘0’..’9’ (<=35)

TRUNK_LINE TYPE = 2 : ‘0’..’9’ (<=17)
TRUNK_LINE TYPE = 3 : ‘0’..’7’ (<=7)
TRUNK_LINE TYPE = 4 : ‘0’..’7’ (<=7)
TRUNK_LINE TYPE = 5 : ‘0’..’9’ (<=35)
13 20
14 30
day 15 15 Chaîne (format date) : Octet 1 : 1 <= JOUR <= 31
month 16 01 Octet 2 : 1 <= MOIS <= 12
year 17 04 Octet 3 : 0 <= ANNEE <= 99
second 18 18 Octet 4 : 0 <= SECONDES <= 59

minute 19 34 Octet 5 : 0 <= MINUTES <= 59
hour 20 0C Octet 6 : 0 <= HEURES <= 23
hour 21 00 Chaîne (format heure) : Octet 1 : 0 <= DUR_HEU-

RES <= 23
minute 22 00 Octet 2 : 0 <= DUR_MINUTES <= 59
second 23 0D Octet 3 : 0 <= DUR_SECONDES <= 59
pulses (Taxes) 24 00 0…65535
25 01
service 26 00 , 1, 255
0 : SERVICES CCBNT (service vocal, groupe fax
3, télétex, vidéotex)
1: SERVICES CCBT ( téléfax groupe 4, transmission de
données transparentes) 255 : non défini
comp. service 27 01 Binaire :

Bit 8 : inutilisé
Bit 7 : transit disa
Bit 6 : transfert
Bit 5 : renvois pbx
Bit 4 : inutilisé
Bit 3 : taxation en ligne
Bit 2 : renvoi externe
Bit 1 : signalisation utilisateur à utilisateur
dialled digits 28 0A Octet 1 : nombre de chiffres (0 à 26)

Octet 2 à octet 14 : chiffres 1 octet codifié sur 2 chiffres.
29 00
30 00
31 00
32 00
33 00
34 00

35 00
36 00
37 02 02
38 98 98
39 14 14
40 39 39
41 08 08
dial.mode 42 00 Décimal :
0 : numérotation manuelle
1 : code abrégé individuel
2 : mode de code abrégé
255 : mode de numérotation non défini
ring time 43 00 Décimal :

Octet 1 : 0 <= SECONDES <= 59
Octet 2 : 0 <= MINUTES <= 59
Durée de sonnerie pour les appels entrants.
44 00
cost 45 00 Octet 1 et octet 2 : partie entière

Octet 3 et octet 4 : partie fractionnaire (en 1/10000)
Le coût est donné en devise locale
46 00
47 00
48 00
account-code 49 00 Octet 1 : nombre de chiffres (0 à 16)
50 00 Octet 2 à octet 14 : chiffres

Même codage que « DIALLED DIGITS »
Si un code affaire est rempli dans le champ « PersonalOr-
Business » il est défini sur 1 (Affaire).
51 00

52 00
53 00
54 00
55 00
56 00
57 00
subscriber 58 20 Octet 1 à octet 16 nom de l'appelant (pour un appel sor-

tant) ou
name
nom de l'appelant (pour un appel entrant)
Le prénom ou nom est séparé par un espace.
59 20
60 20
61 70 P
62 6F o
63 73 s
64 74 t
65 65 e
66 32 2
67 32 2
68 26 6
69 4F O
70 58 X
71 4F O
72 52 R
73 32 2

init.user type 74 FF Décimal :

0 : l'utilisateur est un abonné
1 : interface analogique externe (faisceau analogique, li-
gne privée analogique)
2 : accès de base public (T0) ou privé (dtl0)
3 : accès principal public (t2) ou privé (dtl2)
4 : groupe d'abonnés ou d'opérateurs
5 : accès T1
6 : faisceau IP
init. User ident. 75 20 1 à 8 chiffres codés sur 8 octets

USER TYPE = 0 : ‘0’..’9’,‘A’..’D’,’*’,’#’
USER TYPE = 1 : ‘0’..’9’ (<=35)
USER TYPE = 2 : ‘0’..’9’ (<=17)
USER TYPE = 3 : ‘0’..’7’ (<=7)
USER TYPE = 4 : ‘0’..’9’,‘A’..’D’,’*’,’#’
USER TYPE = 5 : ‘0’..’7’ (<=7)
USER TYPE = 6 : ‘0’..’9’ (<=35) Cet élément d'info con-
tient :
• un champ vide dans le cas d'un appel sortant, ou les
mêmes informations que les appels entrants après un
transfert
• le nombre d'abonnés ou de groupes initialement
appelés dans le cas d'un appel entrant
• le numéro taxé de l'appel distant dans le cas d'un
break-out.
76 20
77 20
78 20
79 20
80 20
81 20
82 20

init. User ident. 83 20 Octet 1 : nombre de chiffres

(in Network) Octet 2 à octet 14 : chiffres 1 octet codé sur 2 chiffres
Cet élément d'information comprend :
comrend le numéro donné par la première traduction du
plan de numérotation (à partir du numéro initialement
composé par l'utilisateur) dans le cas d'un appel sortant,
ou a la même signification qu'un appel entrant après
transfert
le numéro privé ou public d'un abonné ou celui du groupe
appelé initialement, dans le cas d'un appel entrant
le numéro taxé de l'appel distant dans le cas d'un break-
out. L'identification de l'utilisateur en mode réseau peut
comprendre de 1 à 26 chiffres : c'est l'adresse réseau de
l'appelant ou de l'appelé, en fonction de la direction de
l'appel.
Octet 1 : nombre de chiffres

Octet 1 à octet 14 : chiffres 1 octet codé sur 2 chiffres.
Renseigné et complété avec des espaces uniquement en
mode réseau. Cet élément d'information comprend :
le numéro de l'appelant dans le cas d'un appel sortant,
le numéro privé ou public de l'abonné qui a répondu dans
le cas d'un appel entrant, le numéro facturé de l'appelant
distant dans le cas d'un break-out.
L'identification de l'utilisateur en mode réseau peut com-
prendre de 1 à 26 chiffres : c'est l'adresse réseau de l'ap-
pelant ou de l'appelé, en fonction de la direction de l'ap-
pel.
84 20
85 20
86 20
87 20
88 20
89 20
90 20
91 20
92 20

93 20
94 20
95 20
96 20
User Ident 97 20 Nombre de chiffres

(in Network)
98 20
99 20
100 20
101 20
102 20
103 20
104 20
105 20
106 20
107 20
108 20
109 20
110 20
Net. Comp.Ser. 111 00 Binaire :

Bit 8 : inutilisé
Bit 7 : inutilisé
Bit 6 : inutilisé
Bit 5: Forced on net
Bit 4 : Débordement
Bit 3 : ARS/LCR
Bit 2 : VPN(virtual private network)
Bit 1 : signalisation utilisateur à utilisateur (ISVPN)
node number 112 20 0…127], 255 est réservé à l'appel entrant non répondu.

carrier 113 20 Caractère (valeur ASCII)
acc. ticket mo- 114 01 Décimal :

de
1 : PREUVE ECRITE
2 : TICKET
3 : RÉSEAU
sent UUI coun- 115 00

ter
116 00
117 00
118 01
rec. UUI coun- 119 00

ter
120 00
121 00
122 00
3.2.3 Exemple de ticket

L'exemple suivant de fichier natif taxa00018.alz montre :
• un appel sortant du 226
• un appel entrant vers le 221
3.3 Format de tickets IP pour OmniPCX Enterprise

Le format du ticket IP est différent des justificatifs au fil de l'eau. Le collecteur utilise le ticket natif. Le
fichier de données Communication Server VoIP Statistics Tickets utilise un format TLV (Type-
Longueur-Valeur, où Type = 1 octet, Longueur = 2 octets, Valeur). Ce fichier peut être affiché avec un
éditeur Hexa.

Les informations sur les tickets IP et leur applicabilité sont fournies dans tableau : Identifiants de
paramètres du ticket IP, définitions et équipement concerné à la page 40
Note :
La dernière colonne montre des champs qui peuvent être utilisés par une application tierce (partenaire Alcatel-
Lucent). En utilisant le mécanisme TLV, l'équipement IP peut, avec quelques exceptions, décider d'utiliser ou non
un paramètre, soit parce qu'il n'est pas implémenté, soit parce qu'il n'est pas significatif.
3.3.1 Format de tickets IP pour OmniPCX Enterprise

Le tableau suivant contient les définitions de champs de données de l'équipement OmniPCX
Enterprise. La section tableau : Identifiants de paramètres du ticket IP, définitions et équipement
concerné à la page 40 explique les numéros d'identification et comment les informations peuvent être
utilisées.
tableau 3.3 : Identifiants de paramètres du ticket IP, définitions et équipement concerné
Équipement concerné
ID TLVID Lon- GA/GD INTIP Télépho- Softphone 4645 Valeur Utilisa-

(hexa) gueur ne IP VMS maximale tion
(octet) admis- tierce
sible (dé-
cimale)
1 01 4 X X X X X / X
2 02 2 X X X X X 0.99 X
3 03 1 X X X X X / X
4 04 1 X X X 0..128 X
5 05 1 X X X 0..52 X
6 06 2 X X X X X 1..4[0..2] X
7 07 1 X X X / X
8 08 4 à 16 X X X X X / X
9 09 4 à 16 X X X X X / X
10 0A 30 X X X X X / X
11 0B 30 X X X X / X
12 0C 2 X X X X X / X
13 0D 4 X X X X X / X
14 0E 4 X X X X X / X
15 0F 1 X X X X X 0..3 X


sible (dé-
cimale)
16 10 1 X X X 0..1
17 11 1 X X X 0..1 X
18 12 1 X X 80..84 X
19 13 1 X X X X X 20, 30, 40 X
20 14 1 X X X X X 20, 30, 40 X
21 15 1 X X X X X / X
22 16 4 X X X X X / X
23 17 4 X X X X / X
24 18 2 X X X X X / X
25 19 2 X X X X X /
26 1A 2 X X X X X / X
27 1B 5*2 X X X X X pas 65535 X
28 1C 5*2 X X X X X pas 65535 X
29 1D 1 X X X X X /
30 1E 10*2 X X X / X
31 1F 5*2 X X X / X
32 20 10*4 X X X X X / X
33 21 2 X X X X X /
34 22 4 X X /
35 23 4*2 X X /
36 24 2 X X /
37 25 10*4 X X X X X / X


sible (dé-
cimale)
38 26 2 X X X X X /
39 27 X X X /
40 28 2 X X X X X 0..255 X
41 29 1 X X X X 10,20,30 X
42 2A 2 X X X / X
43 2B 1 X X 0..1
44 2C 1 X X 0..1
45 2D 2 X X X X X / X
46 2E 1 X X X X X 0..1
47 2F 1 X X X X X 0..7
48 30 2 X X X X X 0..4094
49 31 1 X X X X X 0..63
55 37 1 X X X X X 0..1
60 3C 1 X X X X X /
61 3D 5*2 X / X
62 3E 5*2 X / X
80 50 1 0..1
81 51 1 /
82 52 1 /
83 53 1 0.1
84 54 1 /
85 55 4 /


sible (dé-
cimale)
86 56 4 /
87 57 4 /
89 59 2 /
90 5A 2 /
3.3.2 Définitions des champs de tickets IP

Dans les modules suivants :
• Les champs sont numérotés en fonction de leurs identifiants.
• Ils sont regroupés en différentes sections en fonction du type d'information qui peut être recueilli
3.3.2.1 Localisation de l'appel dans le temps :

Champ [1] : End of communication (fin de communication)
La date de fin de communication correspond au nombre de secondes (format linux) écoulé depuis
1970 à 00:00:00 GMT, auquel on ajoute le décalage horaire (selon le méridien et en tenant compte des
heures d'été ou d'hiver).
Ce champ est renseigné par la CPU à réception du ticket.
L'heure sur le ticket est l'heure locale du serveur de communication qui a généré le ticket. Tous les
serveurs de communication du réseau doivent être synchronisés sur la même heure. Si les serveurs de
communication impliqués dans l'appel ne sont pas configurés sur le même fuseau horaire, la différence
entre les différents fuseaux horaires doit être prise en compte pour déduire les tickets de la même
communication.
Ce champ peut être utilisé pour récupérer tous les tickets d'une même communication
L'heure de début peut être obtenue en soustrayant la durée de l'appel à l'aide du champ « Duration »
(champ [12]) :
“Date of beginning of communication” = “date of end of communication” –
“duration of communication”
= “field [1]” – “field [12]”
3.3.2.2 Localisation des terminaux du segment :

Champ [2] : Node Number (numéro de nœud)
Numéro de nœud permettant de trouver l'équipement IP (coupleur/téléphone IP)
Ce champ est renseigné par la CPU pendant la réception du message.
Champ [3] : Protocol Version (version du protocole)

Version du protocole utilisée entre le coupleur et la CPU pour le ticket

Valeurs réelles : jusqu'à la version 6 : 0 (certains équipements utilisent 1) / à partir de la version 7 : 2
Champ [4]: Crystal Number (numéro cristal)

Numéro de rack sur lequel le coupleur se trouve
Si le coupleur est une carte CPU comprenant le 4645 VMS, la valeur sera toujours 18 (0x12)
Champ [5] : Coupler Number (numéro de coupleur)

Numéro de coupleur (dispositif passerelle IP Media)
Si le coupleur est une carte CPU comprenant le 4645 VMS, la valeur sera toujours 0
Champ [6] : Equipment Type (type d'équipement)

Type d'équipement à partir duquel le ticket est généré
Format :
• Byte 1: Type:1=IPP|2=APC|3=CplOmEnt|4=CplOmOFF] :
• Byte 2: [Type:1=IPPv2|2=NOEIPP|0=4980|1=WSftIP|0=IntIP|1=GD|2=eVA] :
Byte 1 indique le type d'équipement
• 1=IPP : correspond à un téléphone IP
• 2=APC : correspond à une application PC
• 3=CplOmEnt : correspond à un coupleur OmniPCX Enterprise.
• 4=CplOmOFF : correspond à un coupleur OXO Connect.
Byte 2 fournit des informations complémentaires relatives au type d'équipement indiqué sur le
premier octet :
• Pour les téléphones IP (équipement type 1) :
• 2=NOEIPP : téléphones IP
• Pour les applications PC (équipement type 2) :
• 0=4980 : 4980 Softphone (PCMM2)
• 1=WSftIP : IP WebSoftPhone
• Pour les coupleurs OmniPCX Enterprise (équipement type 3) :
• 0=IntIP : carte INTIPA ou INTIPB
• 1=GD : carte GD ou GA
• 2=eVA : 4645 VMS
Champ [7] : Timeslot Number (nombre d'intervalles de temps)

Nombre d'intervalles de temps (canal) utilisé pour aider à trouver le DSP utilisé, par simple déduction.
3.3.2.3 Identification des terminaux du segment :

Champ [8] : Local IP Address (adresse IP locale)
Ce champ contient l'adresse IP source de l'équipement IP qui transmet le flux IP. Cet équipement peut
être un téléphone IP, une carte INTIP, une carte GD ou GA, etc. (voir les possibilités de types
d'équipement du champ [6] ). Pour chaque flux RTP, un socket rapide est créé. Le contenu comprend
les adresses IP source et destination.
Champ [9] : Distant IP Address (adresse IP distante)

Ce champ contient l'adresse IP de destination (réception) de l'équipement IP du flux IP. Cet

équipement peut être un téléphone IP, une carte INT-IP, une carte GD ou GA; etc. (voir les possibilités
de types d'équipements du champ [6] ).
3.3.2.4 Identification du poste de l'appelant ou de l'appelé :

Champ [10] : Local ID (identification locale)
Ce champ n'est pas toujours renseigné. Lorsque c'est possible, il contient le numéro d'annuaire du
poste local impliqué dans l'appel (information envoyée par la CPU).
Champ [11] : Distant ID (identifiant distant)

Ce champ n'est pas toujours renseigné. Lorsque c'est possible, il contient le numéro d'annuaire du
poste distant impliqué dans l'appel (information envoyée par la CPU).
Spécificité :
• Les tickets générés pour la tonalité de retour d'appel peuvent être identifiés en comparant
l'identifiant local et l'identifiant distant des 2 tickets symétriques : si l'identifiant local et l'identifiant
distant sont identiques sur les 2 tickets symétriques (tickets du même segment), nous pouvons en
déduire que c'est un segment utilisé par la tonalité de retour.
• Pour les tickets générés pour la tonalité de retour, il est possible de repérer le téléphone qui a émis
l'appel. En fait, sur les tickets générés des deux côtés, le champ « Local ID » sera égal au MCDU
de l'appelant et le champ « Distant ID » sera égal au MCDU de l'appelé.
3.3.2.5 Durée de la communication du segment IP (flux RTP)

Champ [12] : Call Duration (durée d'appel)
Ce champ montre la durée de l'appel en secondes pendant laquelle l'équipement a envoyé (et reçu)
des paquets sur
le réseau IP (segment IP). Le temps écoulé pendant la phase de sonnerie peut être compris dans cette
durée (voir le « cas utilisateur » présenté en annexe)
La valeur de la durée d'appel INTIP/GD est déterminée selon les critères suivants : 0 à 999 ms = 0 s,
1000 à 1999 ms = 1 s
3.3.2.6 Identification du segment

Champ [13] : Local SSRC (SSRC local)
Ce champ correspond à la valeur de l'identifiant source de synchronisation locale qui permet d'identifier
un segment de communication IP (un segment IP traité par un ticket IP). L'identifiant SSRC est une
valeur aléatoire généralement unique pour une session RTP définie.
Champ [14] : Distant SSRC (SSRC distant)

Ce champ correspond à la valeur de l'identifiant source de synchronisation distante, qui permet
d'identifier un segment de communication IP (un segment IP traité par un ticket IP). L'identifiant SSRC
est une valeur aléatoire généralement unique pour une session RTP définie.
3.3.2.7 Les paramètres VoIP pouvant avoir un impact sur la qualité vocale sont les suivants :
Champ [15] : Algo Compression Type (type d'algorithme de compression)
0=G711A|1=G711U|2=G723|3=G729
Ce champ contient le type d'algorithme de compression utilisé :
• 0 : G711 PCMA (64 kbit/s -> loi A : Europe)
• 1 : G711 PCMU (56 kbit/s -> loi μ : États-Unis)

• 2 : G723.1 (6,3 kbit/s)

• 3 : G729 A (8 kbit/s)
Les valeurs possibles par équipement sont les suivantes :
INTIP/GA/GD/IPP/IPT : 0,1,2,3
Carte CPU comprenant le 4645 VMS : 0,1
Cette valeur dépend de la gestion du codec
Remarque :
Au niveau du protocole H323, nous ne faisons pas de distinction entre les cas G723 5,3 kbit/s et 6,3 kbit/s. Au
niveau du Mao, nous avons également une valeur unique pour G723 et la CPU indique G723 6,3 kbit/s au
coupleur (passerelle H323).
De la même façon, la réception de l'indication G723 par la passerelle distante, le coupleur indique G723 6.3 kbit/s
à la CPU dans tous les cas. Le coupleur initialise toujours le DSP avec G723 6,3 kbit/s. Dans le cas de la
connexion à une passerelle CISCO configurée en 5,3 kbit/s, il faut noter que les trames reçues par INTIP sont
constituées de 20 octets (5,3 kbit/s) et celles envoyées par INTIP sont constituées de 24 octets (6,3 kbit/s)
(CDHva60191).
La qualité est affectée mais elle reste correcte. Dans ce cas, nous pouvons envoyer la valeur 4 au lieu de 2 (si
nous décidions de faire cela, un RA sera créé pour les cas concernés).
Champ [16] : VAD

Ce champ indique si la suppression de silence (détection d'activité vocale) est activée
• false : désactivé,
• true : activé.
La détection d'activité vocale (VAD) permet de réduire la bande passante utilisée. Lorsque la détection
VAD est demandée, le générateur de bruit de fond est systématiquement activé.
La détection VAD est activée via deux options système, l'une s'appliquant aux communications codées
en G711, l'autre aux communications codées en G723 et G729. Dans le cas d'un appel H.323, la VAD
implique une négociation entre appelant et appelé.
Ce paramètre peut être géré sur OmniPCX Enterprise (chemin : « System/ Other System Param./
Compression Parameters/ VAD on G711 and Voice Activity Detect (Comp Bds) »)
Champ [17] : Echo Canceler (annulateur d'écho)

Indique l'état dans lequel le poste se trouve : combiné, mains-libres ou haut-parleur
Les valeurs possibles selon le type de téléphone IP (IPP, IPT) sont les suivantes :
• Inactivité 0x50
• Combiné 0x51
• Haut-parleur 0x52
• Combiné raccroché 0x53
• Mains libres 0x54
• Annonce sur haut-parleur non applicable - Sonnerie non applicable
Champ [18] : Voice Mode (mode voix)
Indique l'état dans lequel le poste se trouve : combiné, mains-libres ou haut-parleur
Les valeurs possibles selon le type de téléphone IP (IPP, IPT) sont les suivantes :
• Inactivité 0x50
• Combiné 0x51
• Haut-parleur 0x52

• Combiné raccroché 0x53

• Mains libres 0x54
• Annonce sur haut-parleur non applicable
• Sonnerie non applicable
3.3.2.8 Les paramètres du flux de paquets RTP qui peuvent être utilisés pour calculer la QoS
VoIP sont les suivants :
Champ [19] : Requested Framing Duration (durée de tramage requise)
Le tramage correspond à la durée (en ms) de transmission d’un paquet voix RTP sur un réseau IP.
Par exemple, 20, 30, 40 ms, etc. (par exemple le 4645 VMS est toujours à 30 ms). Ce champ affiche la
vraie durée en ms d’une transmission de tramage sur un réseau IP. Ce tramage peut être différent de
la configuration du système après négociation avec l'équipement destinataire.
Cette information est présentée dans le ticket de manière à ce que nous puissions repérer le tramage
envoyé aux équipements qui n'a pas créé les statistiques de ticket IP (appel H323 etc.).
Note :
Une différence peut exister entre le tramage « demandé » donné par la CPU et le tramage réel parce qu'une
négociation peut se produire entre les équipements IP. Ce champ sera le tramage utilisé
La valeur du tramage est choisie séparément pour chaque algorithme en utilisant les paramètres suivants :
• Tramage G711 VOIP : valeurs possibles :
• 20 ms (valeur par défaut)
• 30ms
• Tramage G729 VOIP : valeurs possibles :
• 20 ms (valeur par défaut)
• 30ms
• 40ms
• Tramage G723 VOIP : non modifiable : 30 ms
Champ [20] : Received Framing (tramage reçu)
Ce champ correspond à la durée des paquets voix RTP reçus exprimée en ms.
Note :
Grâce à la détection VAD, les trames reçues du réseau peuvent avoir une taille plus petite en mode silence.
Exemple :
Tramage G711 et IP de 30 ms :
Trame normale en mode voix = 240 octets (30 ms de conversation). En mode silence = 160 octets ou 80 octets
(20 ms ou 10 ms de conversation) suivis d'une trame de 1 octet (SID).
(Dans le cas d'un coupleur INTIP en IP à IP 20 ms, nous pouvons avoir le cas de 81 octets = voix + SID dans la
même trame)
Champ [21] : Framing Change NB (nombre de changements de tramage)

Nombre de fois où le tramage IP de la communication a changé
Note :
Pour le champ 0x20, prenez le temps de vérifier si la détection VAD est activée et si elle ne l'est pas, augmentez
le champ à chaque fois que le paquet reçu change de taille.
Champ [22] : RTP Received Packets NB (nombre de paquets RTP reçus)

Nombre total de paquets RTP reçus par l'équipement IP pour cette communication, y compris les
paquets SID.

Alcatel-Lucent ne peut pas garantir que cette valeur représente le trafic réel échangé sur le réseau IP.
Champ [23] : Total RTP Packets Sent (total de paquets RTP envoyés)
Nombre total de paquets RTP envoyés par l'équipement IP pour cette communication y compris les
paquets SID.
Alcatel-Lucent ne peut pas garantir que cette valeur représente le trafic réel échangé sur le réseau IP.
Champ [24] : RTP Lost Packets NB (nombre de paquets RTP perdus)

Nombre total de paquets RTP perdus par l'équipement IP à réception de cette communication.
Il est possible de déduire l'élément QoS en calculant le pourcentage du nombre de paquets RTP
perdus :
% de paquets RTP perdus = [24] / [22] * 100
Si le % de paquets RTP perdus < 1 % => Bon niveau
Si 1 % > % de paquets RTP perdus < 2 % => Niveau acceptable
Si 2 % > % de paquets RTP perdus < 4 % => Niveau juste
Si % de paquets RTP perdus > 4 % => Niveau médiocre
Si la qualité QoS est médiocre, l'analyse des paquets RTP perdus se concentre sur un petit intervalle
de temps et vérifie le niveau BFI consécutif
Champ [25] : Total Silence (silence total)

Compteur CNG (Comfort Noise Generation)
En mode suppression de silence, le DSP arrête d'envoyer des paquets voix lorsque le niveau vocal
passe en deçà d'un certain niveau. Il envoie ensuite 1 trame SID avec des informations sur le bruit de
fond et n'envoie aucune autre trame jusqu'à ce que le niveau vocal dépasse le bruit de fond.
Le SID est utilisé pour la génération d'un bruit de confort à l'autre extrémité. Dans certains cas un
nombre de trames SID plus élevé que la normale peut être envoyé. Pour le cas de G729, il s'agit d'un
problème connu dû à la norme. Ce n'est pas nécessairement le nombre de secondes sans échange
mais plutôt la durée de bruit de confort générée par le DSP. Dans un environnement très bruyant, il est
possible d'avoir 0 seconde de CNG, même lorsque personne ne parle.
Champ [26] : NB SID Received Packets (nombre de paquets SID reçus)

Nombre de trames SID reçues pour cette communication.
Les SID (Silence Identification) sont les trames qui contiennent les informations relatives au bruit de
fond. Ces informations sont utilisées pour générer le bruit de fond au niveau du destinataire.
VAD doit être validé pour obtenir le paquet SID.
Champ [27] : Delay (délai)

[0-40]:0 | [40-80]:0 | [80-150]:0 | [150-250]:0 | [+250]:0 |
tableau : Limites de délai à la page 49 représente la distribution du temps de propagation aller-retour
(accumulation bidirectionnelle) sur cette communication.

tableau 3.4 : Limites de délai
Plage (ms) Niveau
0-40 Excellent
40-80 Bon
80-150 Acceptable
150-250 Moyen
250 et plus Médiocre
Lors de la conception des réseaux qui transportent la voix dans des paquets, des trames ou des
infrastructures cellulaires, il est important de comprendre et de prendre en compte le délai des
composants du réseau. Si vous prenez correctement en compte tous les retards possibles, vous vous
assurez que les performances réseau globales sont acceptables. La qualité voix globale est fonction
de plusieurs facteurs qui comprennent l'algorithme de compression, les erreurs et la perte de trames,
l'annulation d'écho et les délais. La télécommunication internationale
L'ITU (International Telecommunication Union) tient compte du délai de réseau des applications
vocales dans la recommandation G 114. Cette recommandation définit trois bandes de délai à sens
unique comme le montre le tableau suivant tableau : Recommandations de délais ITU à la page 49 :
tableau 3.5 : Recommandations de délais ITU
Plage (ms) Description
0-150 Acceptable pour la plupart des applications utilisateur
150-400 Acceptable, à condition que les administrateurs soient cons-

cients du temps de transmission et de l'impact que ce temps a
sur la qualité de transmission des applications utilisateur
Supérieur à 400 Inacceptable pour les besoins généraux de planification du ré-

seau. Cependant, il est reconnu que dans certains cas excep-
tionnels cette limite est dépassée
Le délai aller-retour est calculé à intervalles réguliers, à partir de l’échange de paquets RTCP.
Note :
Cette information est fournie par les paquets RTCP qui sont normalement envoyés toutes les six secondes. Ainsi,
une communication ayant une durée inférieure à 6 secondes ne reçoit aucun paquet RTCP et l'équipement IP ne
doit donc pas inclure le champ [27] dans le ticket.
Limites de délai :
0 à 40 : 0*125us - 320*125us (40 ms comprises)
40 à 80 : 321*125us - 640*125us (80 ms comprises)
etc.
Champ [28] : Max Delay (délai max)

Délai de trajet maximal mesuré dans le réseau lors de l'appel pour ce segment IP.

La mesure se fonde sur l'échange de paquets RTCP, avec une incertitude d’environ 10 ms.
Si le « délai max » est de 150 ms, cela signifie que la QoS est médiocre. Le champ [27] (délai) doit être
analysé pour savoir si le RTD a atteint 150 ms à plusieurs reprises. Si c'est le cas, l'existence d'un
problème réseau est possible.
Note :
Cette information est fournie par les paquets RTCP qui sont normalement envoyés toutes les six secondes. Ainsi,
une communication ayant une durée inférieure à 6 secondes ne reçoit aucun paquet RTCP et l'équipement IP ne
doit donc pas inclure le champ [28] dans le ticket.
Champ [29] : NB DTMF Detected (nombre de paquets DTMF détectés)

Les signaux DTMF peuvent être acheminés directement intrabande et donc dans le flux RTP.
Ce champ correspond au nombre de paquets DTMF détectés pendant la communication (pour une
passerelle => nombre de DTMF et à distance => nombre de paquets de type DTMF).
Note :
Le nombre de DTMF est uniquement mentionné pour expliquer un nombre anormalement élevé de BFI. En fait, les
DTMF créent les BFI.
Ce champ peut être utilisé pour d'autres tâches uniquement en complément du nombre de BFI.
3.3.2.9 Les paramètres VoIP qui peuvent être utilisés pour calculer la QoS VoIP sont les
suivants :
Champ [30] : Consecutive BFI (BFI consécutives)
[1] :0
[2] :0
[3] :0
[4] :0
[5] :0
[6] :0
[7] :0
[8] :0
[9] :0
[10+] :0
Ce tableau de dix valeurs représente les occurrences de BFI consécutives (interpolation de mauvaise
trame). Cela ne s'applique pas aux téléphones IP et 4645 VMS.
Les BFI peuvent être liées à deux types de problèmes :
• problèmes de gigue
• problèmes de pertes de paquets IP (trou dans le temps) qui n'introduisent pas de délais

Chaque BFI indique qu'à un moment donné le DSP n'a pas reçu de paquet et qu'il a extrapolé. Voir le
champ DSP_FRAMING_DURATION (champ [41]) pour l'unité utilisée.
En général, nous pouvons avoir des compteurs défectueux à cause de la non-synchronisation entre le
début et la fin du flux IP.
Pour débuter, nous ne devons démarrer nos compteurs qu'à réception du premier paquet IP (voir
remarque 1) mais rien n'est fait pour les arrêter.
Pour les BFI consécutives, nous ne devrions pas avoir de problèmes à la fin de la communication car
elles sont comptabilisés à réception du premier paquet voix après BFI, et nous n'aurons pas de paquet
voix à ce moment-là.
Niveau de BFI consécutives selon le codec utilisé
Limites pour le codec Limites pour le codec Limites pour le codec Niveau
G711 G723 G729
Sans BFI Sans BFI Sans BFI Bon
1 à 3 BFI 1 BFI 1 à 3 BFI Acceptable
4 à 6 BFI Non utilisé Non utilisé Moyen
7 à 10 BFI et plus 2 à 10 BFI et plus 4 à 10 BFI et plus Médiocre
Remarque :
Le premier paquet RTP du réseau IP doit d'abord être reçu pour que l'autre compteur puisse commencer.
Champ [31] : BFI Distribution (distribution de BFI)

Ce tableau de cinq valeurs représente la distribution des BFI. Il ne s'applique pas aux postes IP Touch
ni 4645 VMS.
Les durées de BFI et de voix sont mesurées à intervalles de 10 s. Le rapport entre la durée des BFI et
celle de la réception de la voix s’exprime en pourcentage.
On utilise la durée du message vocal et non pas l’intervalle (10 s) pour que la détection d'activité voix
(VAD) ne déforme pas le résultat.
[0%] : 0 égal à 0 %
[<0-1] : 0 supérieure à 0 % jusqu'à 1 %

[<3%+] : 0 supérieure à 3 %
Champ [32]: Jitter Depth (profondeur de gigue)

[0]:0 | [1]:0 | [2]:0 | [3]:0 | [4]:0 |
[5]:0 | [6]:0 | [7]:0 | [8]:0 | [9]:0 |
Ce tableau de dix valeurs affiche la distribution des tailles de gigue. Il est incrémenté chaque fois qu'un
paquet est envoyé au DSP (fréquence de tramage DSP).
Ce processus de mesure dépend du type d'équipement IP (correspondant local) impliqué dans l'appel :
Deux processus de mesure distincts sont utilisés selon les équipements impliqués :
• Un processus pour le INTIP/GD/GA avec une taille statique de buffer de gigue
• Un autre processus pour l'application 4980 et le téléphone IP, avec une taille dynamique de buffer
de gigue
Cela ne s'applique pas au 4645 VMS.
• Le tableau suivant montre une profondeur de gigue pour INTIP/GD/GA
Avec un buffer statique, le INTIP/GD/GA doit continuer à utiliser la distribution en profondeur de
gigue, sans quoi le client risque de penser qu'il y avait un problème de délai à un moment de la
conversation et non un problème de délai constant, du début à la fin de la conversation. Voir champ
[37] pour la distribution de gigue du réseau.
La taille par défaut du buffer de gigue des coupleurs INTIP et GD/GA est de 100 ms (elle était de
200 ms pour le LIOE). Le changement de taille peut être effectué lorsque le réseau n'a pas de
bonnes caractéristiques et que les clients se plaignent de la perte de syllabes ou de tremblements
dans la voix au cours de la conversation. Seul l'administrateur OXE peut modifier les paramètres
suivants :
• Pour un coupleur INTIP :
Comme décrit ci-dessous, il peut être changé et pris en compte dynamiquement en se
connectant à la carte INTIP :
• INTIP : mcc
• MCC : jitterdepth
• Taille max gigue (ms) : 64 <-- Entrez une valeur Hexa

• Taille max gigue voix 100 <-- le résultat est 100 ms

• 0000008C-03D7474F: Fin d'exécution de la commande
Si le coupleur est redémarré, la modification effectuée est perdue. Vous devez utiliser le fichier
« startintip » pour solliciter la modification pendant le démarrage du coupleur.
• Pour un coupleur GD/GA :
Il peut être changé en se connectant à la carte GD/GA :
• [root@eMGD admin]# monitor

• monitor_bg : aucun processus arrêté
• Commencer une surveillance avec /dev/rtf1 and /dev/rtf2
• MG : mcc
• MCC : jitterdepth
• Taille max gigue (ms) : 64 <-- Entrez une valeur Hexa
• Taille max gigue voix 100 <-- le résultat est 100 ms
• 0000006A-375C1BCA : Fin d'exécution de la commande
Si la GD/GA est réinitialisée, les paramètres par défaut sont appliqués à nouveau. 0
Les limites de valeur « profondeur de gigue » recommandées :100 - 100
• Pour les téléphones IP et l'application 4980, le tableau montre la taille du buffer de gigue qui
change dynamiquement.
En fait, la taille varie selon la gigue présente sur le réseau. S'il y a trop de gigue sur le réseau, la
taille du buffer de gigue sera augmentée (par étape d'un paquet RTP).Dans le cas contraire, elle
sera diminuée. Le tableau affiche la taille du buffer au moment où le DSP demande un paquet. Ce
résultat est un indice de la qualité générale du réseau.
L'unité est le tramage RTP. Cependant, pour avoir une correspondance entre la taille du buffer et le
gigue présent dans le réseau, nous devons utiliser la formule suivante :
Gigue = +/- (2*taille du buffer)+1) * (tramage RTP) /2 -> f(x) = +/- (2*x)+1) * (tramage RTP) /2
Pour un tramage RTP de 20 ms, on a donc :
... ...
taille du buffer : gigue :
0 f(0) = +/- 10 ms
1 f(1) = +/- 30 ms
2 f(2) = +/- 50 ms
... ...
Les niveaux de gigue élevés ne sont pas acceptables pour les applications fonctionnant en temps
réel. Il en résulte une distorsion du signal, qui exige l'introduction de délais supplémentaires
nécessaires au remontage de paquet. IP-Touch utilise un buffer dynamique allant jusqu'à
12 paquets.
Le calcul de la moyenne de gigue (gigue) pour cette branche d'appel (flux d'appel du segment) est
le suivant :
Pour x = 0 à 9, f(x) = (2x + 1) * (tramage RTP/2) tramage RTP = [champ ID n°19]

Gigue = (JitterDepth0* f(0)) + (JitterDepth1* f(1)) + … + (JitterDepth9* f(9)) ( ) JitterDepth0 +

JitterDepth1+ … + JitterDepth9
Avec JitterDepthx = nombre de mesures de la taille du buffer x (x = 0 à 9)

-> 4980 Softphone IP (PCMM2), semblable à IPPhone, à l'exception du G729 où l'unité utilisé est
de 10 ms
4645 VMS : à remplir seulement s'il y a eu une phase d'enregistrement -> insensible à un
éclatement de réseau, perte de paquets et de séquences uniquement.
3.3.2.10 Champs inutiles pour la QoS VoIP :

Champ [33] : ICMP
Nombre de trames ICMP de destination inatteignable reçues
Champ [34] : [Fax] Number of packets lost in V21 et T4 phase (nombre de paquets perdus en
phase V21 et T4)
Ce champ n'est pas traité pour le moment.
Champ [35] : [Fax] number of Underrun in T4 phase ([Fax] nombre de sous-charges en phase
T4)
Ce tableau de 4 compteurs montre le nombre d'erreurs de sous-charge pendant une phase T4. A la fin
de chaque phase T4 de communication par fax, si le nombre de sous-charge est dans l'un des
intervalles suivants [1..6], [6..11], [11..16] et [16..+infini], le compteur correspondant est incrémenté de
1. Si, par exemple, neuf erreurs de sous-charge sont notées durant la phase T4, le troisième compteur
est incrémenté de 1.
Champ [36] : [Fax] number of Underrun in V21 phase ([Fax] nombre de sous-charge en phase
V21)
Le compteur est incrémenté de 1 à chaque fois qu'une ou plusieurs sous-charges sont produites
pendant la phase V21.
3.3.2.11 Paramètre VoIP qui peut être utilisé pour calculer la QoS VoIP (uniquement pour
téléphone IP) :
Champ [37] : Network jitter distribution (distribution de gigue de réseau)
[0]:0 | [1]:0 | [2]:0 | [3]:0 | [4]:0 | [5]:0 | [6]:0 | [7]:0 | [8]:0 | [9]:
0
Le champ décrit la distribution de profondeur de gigue qui, dans le cas d'INTIP/GD/GA, indique la
distribution du délai dans le buffer de gigue provenant d'une variation dans le réseau.
Dans le cas du téléphone IP/4980, il donne plutôt la distribution du réseau.
Ce paramètre est supposé indiquer la distribution du réseau pour les équipements considérés, ce qui
donne la distribution du délai (voir le champ [32]).
Pour chaque DSP_FRAMING_DURATION (voir le champ [41]), le nombre de paquets reçus à partir du
réseau depuis la fois précédente est ajouté au tableau. Si 3 paquets ont été reçus, la colonne « 3 » est
incrémentée de 1.

3.3.2.12 Informations diverses :

Champ [38] : Software version (version logicielle)
Version logicielle du firmware fonctionnant sur le coupleur ou le téléphone IP
Exemple :
La version 2.05.0 sera codée « 0x02 0x05 »
La version 4.18.0 sera codée « 0x04 0x12 »
La version 13.02.1 sera codée « 0x0d 0x02 » (le « 1 » n'est pas indiqué)
4645 VMS : toujours codé comme « 0x01 0x00 »
Champ [39] :Tterminal MCDU<IPP,eVA<

Si le terminal qui a transmis le ticket est un poste IP (IPP ou IPT) ou 4645 VMS, ce champ indique le
numéro d'annuaire (MCDU) de ce poste IP.
Le serveur d'appel ajoute ce champ lorsque le ticket est reçu à la fin de la communication. récupère les
données concernant les équipements IP. Le OmniVista 8770 récupère les données concernant les
équipements IP. Il utilise IPP_MCDU pour trouver les tickets d'un terminal IP spécifique et
LOCAL_IP_ADDRESS pour les passerelles.
Champ [40] : Network Number (numéro de réseau)

Numéro de réseau local de l'équipement IP qui a transmis le ticket.
Ce champ est renseigné par la CPU pendant la réception du message.
3.3.2.13 Les paramètres du flux de paquets RTP qui peuvent être utilisés pour calculer la QoS
VoIP sont les suivants :
Champ [41] : DSP Framing Duration (durée de tramage DSP)
Fréquence (en millisecondes) utilisée avec le DSP pour donner et recevoir des trames.
Elle peut être différente du réseau de tramage et dépend de l'algorithme de compression et du DSP
utilisés.
INTIP/GA/GD (indépendant du tramage IP) :
• G711 = 20 ms
• G729 = 20 ms
• G723 = 30 ms
IPPhone (indépendant du tramage IP) :
• G711 = 10 ms
• G729 = 10 ms
• G723 = 30 ms
IP Softphone (indépendant du tramage IP) :
• G711 = 10 ms
• G729 = 10 ms
• G723 = 10 ms
Champ [42] : NB SID Transmitted (nombre de SID transmis)
Voir le champ [26].
Cette information est présente dans le ticket pour améliorer le calcul du trafic envoyé à l'équipement
qui ne crée pas de tickets IP statiques.

Champ [43] : Data transparency (transparence des données)

Communication G711 comme transparence de données (décision de la CPU).
Cette information est ajoutée par le coupleur.
Champ [44] : Modem Transparency (transparence de modem)

Communication G711 comme transparence de modem (permission de la CPU, décision du coupleur).
Cette information est ajoutée par le coupleur.
Champ [45] : Min Delay (délai minimum)

Délai réseau minimum calculé dans les deux sens pour ce segment IP.
3.3.2.14 Les champs de définition de réseau sont les suivants :

Champ [46] : use of 802.1Q (utilisation de 802.1Q)
Champ indiquant si l'équipement IP utilise ou non une priorité 802.1Q et un VLAN ID.
• true (1): utilisé
• false (0): non utilisé
Champ [47] : 802.1Q Priority (priorité 802.1Q)

Champ indiquant quelle priorité est utilisée par l'équipement IP si la valeur du champ [46] est « true »
(802.1Q est utilisé).
Champ [48] : VLAN id (identifiant de VLAN)

Virtual LAN-id, voir IEEE802.
Champ indiquant quel VLAN ID est utilisé ou marqué par l'équipement IP si la valeur du champ [46] est
« true » (802.1Q est utilisé).
Champ [49] : Diffserv

Valeur du DSCP (Differentiated Services CodePoint) MAO à utiliser pour le balisage des trames IP :
« precedence » ou « Differentiated Services CodePoint ».
La valeur occupe les 6 MSB dans le champ TOS de la trame IP. Les deux LSB sont CU (non utilisés
actuellement).
Les champs [50] à [54] ne sont pas utilisés
Champ [55] : Encryption (chiffrement)

Ce champ indique si l'appel est sécurisé ou non par un module IP Touch Security Module (comme
MSM) :
• true (1): chiffré
• false (0): non chiffré
Lorsque le chiffrement est incorrect, un délai supplémentaire ou une communication vide (bruit
uniquement) sont susceptibles d'être générés.
Les champs [56] à [59] ne sont pas utilisés
Champ [60] : Local Jetlag (décalage horaire local)

IPView et OmniVista 8770 utilisent les systèmes de données locaux (UNIX/NT) pour décoder la date
d'un ticket IP. Cette date est égale au nombre de secondes écoulées depuis le 1 janvier 1970 et codée
dans 4 octets. Exemple : ticket IP envoyé en Angleterre à 9 heures. Si nous décodons l'IPticket à
Londres, l'IPview indique 9 heures . Mais, si nous décodons ce même ticket à Colombo, l'IPView
indique 10 heures. Ainsi, une information (décalage horaire local) a été ajoutée au niveau du traitement
des appels sur TLV dans le ticket IP, ce qui permet de connaître le pays, la date (heure d'été ou
d'hiver) et la date locale du PABX qui a envoyé le ticket IP.
Cette information correspond au décalage horaire entre l'heure locale du PABX et l'heure GMT (+/-
12 heures).
3.3.2.15 Les paramètres VoIP qui peuvent être utilisés pour calculer la QoS VoIP sont les
suivants :
Champ [61] : bfi distribution over 200ms (distribution BFI sur 200 ms)
[<10%]:0 | [<20%]:0 | [<40%]:0 | [<60%]:0 | [>=60%]:0 |
Ce tableau montre la BFI ou la densité à des intervalles de 200 ms (BFI ou trame, les silences ne sont
pas pris en compte).
Cela s'applique uniquement aux téléphones IP (Poste bureau 80x8, 80x8 Premium DeskPhone et aux
postes 80x8s Premium DeskPhone).
Correspondances de valeurs :
0 < 10%
1 < 20%
2 < 40%
3 < 60%
4 >= 60%
Champ [62] : RTP consecutives lost (pertes RTP consécutives)

[1]:0 | [2]:0 | [3]: 0 | [4]:0 | [5et+]:0 |

Ce tableau de cinq valeurs indique si des pertes consécutives de paquets RTP ont eu lieu.
Cela s'applique uniquement aux téléphones IP (Poste bureau 80x8, 80x8 Premium DeskPhone et aux
postes 80x8s Premium DeskPhone).
Correspondances de valeurs :
0 1
1 2
2 3
3 4
4 >=5
3.3.2.16 Champs spécifiques pour le débogage

Les champs de débogage spécifiques à mettre en œuvre commencent sur 0x50 et une liste commune
de différents équipements est mise à jour quotidiennement.
Champ [80] : Transit
Ce paramètre indique si l'appel est ou non en transit sur la carte INT-IP. Le transit est configuré via le
paramètre Transit sur les cartes IP dans la section IP > IP Parameters. Cette fonction permet
d’optimiser les flux RTP entre passerelles et d’éviter les opérations de décompression/compression
avec un impact négatif sur la qualité de la voix.
Champ [81]: coder restart number (nombre de redémarrages du codeur)

Compteur incrémenté à chaque redémarrage du DSP.
Champ [82]: Number of Ethernet driver restart (nombre de redémarrages de pilote Ethernet)
Compteur incrémenté à chaque redémarrage de pilote Ethernet.

Champ [83] : Problem on HDLC driver (problème de pilote HDLC)

Champ indiquant un problème grave sur le pilote QMC. Chaque valeur saisie correspond à un
problème en particulier dont la liste sera donnée plus tard.
Champ [84] : Communication Type (type de communication)

Champ indiquant si la communication est de type passerelle h323 ou de type IP-Phone ou distant.
Champ [85] DSP: Estimated ERL (DSP : ERL estimé)

Le nouvel annulateur d'écho haute performance présent dans les cartes GIP4/MADA peut donner une
estimation du niveau d'écho.
Champ [86] : DSP - Estimated Delay (DSP - délai estimé)

Le nouvel annulateur d'écho haute performance présent dans les cartes GIP4/MADA peut donner une
estimation de la durée de l'écho
Champ [87] : DSP - Background noise (DSP - bruit de fond)

Le nouvel annulateur d'écho haute performance présent dans les cartes GIP4/MADA peut donner des
informations sur le bruit de fond. Cette information peut concerner le Rand D
Champ [89] : Buffer depth transparency (transparence de profondeur du buffer)
Une communication en G711 prise pour une transparence a besoin d'un buffer pour compenser la
variation de réseau. La profondeur du buffer peut être contrôlée par MAO. La mise en place d'une
valeur élevée peut permettre d'éviter certaines défaillances causées par la perte de paquets mais peut
également provoquer un dysfonctionnement dû au temps supplémentaire ajouté par le buffer.
Champ [90] : Transparency of number of dummy packets run (transparence du nombre de

paquets fictifs)
Une communication en G711 prise pour une transparence a besoin d'un buffer pour compenser la
variation de réseau. Si le buffer n'est pas assez grand pour combler l'effet de gigue, le DSP reçoit une
version fictive à la place d'un vrai paquet T_TRANS_PACKET_SILENCE 0x5a (90).
3.3.2.17 Exemple de ticket pour tickets IP

Vue de ticket - Exemple de l'outil « ipview »
Note :
Figure : IP Ticket Example à la page 60 montre les résultats des 60 premiers paramètres.

Figure 3.1 : IP Ticket Example
3.3.3 Lecture de ticket binaire

Le fichier de données de tickets VoIP (fichier non compressé *.DAI) utilise un format TLV (Type-
Longueur-Valeur) (Type = 1 octet, Longueur = 2 octet, Valeur). Ce fichier peut être affiché avec un
éditeur hexa :

Figure 3.2 : Binary IP Ticket Example
Pour en savoir plus sur les applications tierces et lire le fichier binaire, conctactez Alcatel-Lucent
3.3.3.1 Comment lire le fichier binaire

Les applications tierces doivent lire le fichier binaire (fichier « *.DAI » non compressé) comme indiqué
ci-dessous pour empêcher la mise à jour du format du ticket.

Champ
En-tête standard
Type
(1 octet)
Structure
TLV 1
Longueur
(2 octets)
...
Valeur
Structure
TLV n
Les trois premiers TLV sont toujours en ordre croissant, à partir du début du fichier binaire.
1. Processus de lecture du fichier du ticket
L'application tierce doit afficher :
• le premier type de TLV (premier octet), puis 2 octets indiquant la valeur de la longueur
(exemple : X octets) et enfin la valeur (sur les X octets suivants) ;
• le second type de TLV (qui suit la valeur mentionnée ci-dessus), puis 2 octets indiquant la valeur
de la longueur (exemple : X octets) et enfin la valeur (sur les X octets suivants) ;
• ... etc. (même principe pour le type de TLV suivant)
Le type de TLV indique le TLV ID (voir tableau 6.1.1). Les trois premiers « TLV ID » et leurs
longueurs respectives ne changent jamais (les premiers octets doivent être :
01 00 04 <valeur> 02 00 02 <valeur> 03 00 01 <valeur> ).
2. Type de TLV inconnu
Si un type de TLV est inconnu ou n'est pas pris en compte par le partenaire Alcatel-Lucent, il doit
être écarté lorsque l'application tierce procède à la lecture du fichier du ticket :
• Type de lecture TLV inconnu
• Valeur de longueur de lecture (X octets) du type de TLV inconnu sur les 2 octets suivants
• Allez jusqu'au type de TLV suivant par un saut de X octets
• Continuez le processus de lecture du fichier du ticket [ a) ]

Identifiant Valeur =
TLV inconnu X octets (décimal)
Valeur
Longueur
Type (1 octet) (2 octets) Type (1 octet)
Longueur = X octets
Jusqu'au prochain type

TLV en ignorant les X
octets suivants
Le respect de ces processus permet à l'application tierce de lire correctement les fichiers tickets,
même si une mise à jour est faite sur le fichier par la partie OXE (par exemple : nouveau champ (type
de TLV) ajouté, modification de la longueur d'un champ, etc.).
Une augmentation du champ de version du protocole indique une mise à jour majeure du ticket. A ce
moment, la valeur de la version du protocole est « 2 » (décimal). Dans le cas d'une augmentation de la
version du protocole (plus de 2), contactez Alcatel-Lucent pour connaître le changement effectué.
3.3.3.2 Comment effectuer le suivi d'une communication

L'heure sur le ticket est l'heure locale du serveur de communication qui a produit le ticket. Il faut
impérativement synchroniser l'ensemble du réseau du serveur de communication aux mêmes date et
heure pour retracer correctement une communication spécifique, à l'aide du champ de fin de
communication [1]. La synchronisation du serveur de communication peut s'effectuer via NTP (Network
Time Protocol) à partir d'une horloge de référence (serveur NTP).
Chaque ticket contient des informations permettant d'effectuer le suivi d'une communication de bout en
bout.
Ces informations comprennent :
• le SSRC local (identifie le segment IP),
• le SSRC distant (identifie le segment IP),
• la date de fin de communication (donnée par la CPU),
• la durée de la communication,
• l'identification locale (identifie l'appelant ou l'appelé),
• l'identification distante (identifie l'appelant ou l'appelé),
• l'IP locale (identifie les extrémités du segment IP),
• l'IP distante (identifie les extrémités du segment IP).
Note :
Date de communication = date de fin de communication – durée d'appel
Dans un contexte de corrélation, « communication » désigne un appel direct établi entre deux parties : lorsq'une
opération telle que la mise en attente ou la conférence est impliquée, elle est considérée comme une nouvelle
communication. Il n'est pas possible de corréler un appel complet qui comprend une opération comme la mise en
attente durant le même appel.
3.3.3.3 Algorithme de corrélation

Le processus suivant est utilisé pour trouver la corrélation entre les tickets d'une même
communication :
1. Regroupez tous les tickets compris dans la date de fin de communication.

2. Regroupez quelques tickets IP du même segment grâce aux champs de SSRC locaux et distants :
• Pour un ticket avec un SSRC local = X et un SSRC distant = Y, cherchez le ticket symétrique
dans lequel un SSRC local = Y et/ou un SSRC distant = X sur tous les réseaux des serveurs de
communication.
• Dressez la liste des tickets par paire (2 tickets pour un segment)
3. Regroupez tous les segments par date de fin de communication dans l'ordre croissant pour avoir
tous les possibles segments de la même communication.
4. Un ticket de tonalité de rappel peut être supprimé (parce qu'il n'est pas utile pour l'analyse
Qos) : les tickets créés pour la tonalité de rappel peuvent être identifiés en comparant l'identification
locale et l'identification distante sur les deux tickets symétriques. Si l'identification locale et
l'identification distante sont les mêmes sur les deux tickets symétriques et si la durée d'appel du
ticket est inférieure à 10 secondes, on peut en déduire que ce segment est utilisé pour la tonalité de
retour d'appel.
5. Corrélez les segments IP d'une même communication : - .
• Sélectionnez le premier segment IP (référence)
• Vérifiez que les segments IP qui ont la même date de fin de communication +/- 5 secondes (*) si
au moins l'un des champs ID local ou ID distant a le même ID local ou ID distant que le segment
IP de référence pour savoir si ces segments font partie du même appel.
Faites la même chose pour les segments IP suivants
Note :
Les segments qui sont déjà corrélés n'ont pas besoin de passer par cette étape.
6. Affichez le chemin IP entre les points de terminaison en utilisant l'IP local, l'IP distant(i.e.: IPN1 –
GDN1 – GDN2 – IPN2)
(*) Cette plage de temps est prise en compte à cause des délais de traitement (signalant un échange)
pouvant exister entre plusieurs nœuds (OXE) pour la création de tickets au niveau de chaque
utilisateur final.
3.3.3.4 Direction de l'appel

L'initiateur de l'appel ne peut être déterminé que pour un appel où le ticket IP est créé pour une tonalité
de retour d'appel. Sur les tickets avec « tonalité de retour d'appel » créés des deux côtés, le champ
d'« ID local » sera égal au MCDU de l'appelant et le champ d'« ID distant » sera égal au MCDU de
l'appelé.

8770 3.2.8 Am Accountvoipticketscollect 8al90709frad 1 FR

Transféré par

Droits d'auteur :

Formats disponibles

8770 3.2.8 Am Accountvoipticketscollect 8al90709frad 1 FR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

8770 3.2.8 Am Accountvoipticketscollect 8al90709frad 1 FR

Transféré par

Droits d'auteur :

Formats disponibles

Omnivista 8770

Tickets de taxation et de statistiques VoIP

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 3/64

3.1 OmniPCX Enterprise Tickets..........................................................................................19

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 4/64

1.1.1 Accounting tickets generated by Communication

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 5/64

Les TAXAxxxx.dat sont stockés sur le serveur de communication pendant 94 jours

1.1.1.2 Tickets collectés sur OXO Connect

1.1.1.3 Synchronisation manuelle

1.1.2 Tickets VoIP générés par les serveurs de communication

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 6/64

• Softphone IP Desktop (IPDSP) (uniquement OmniPCX Enterprise)

1.1.3 Génération de ticket de serveur de communication

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 7/64

1.2 Exigences de connectivité du serveur de communication

Serveurs de com- Version prise en Fichiers collec- Connectivité IP Connectivité mo-

OmniPCX Office Toutes versions à Binaires Oui

OXO Connect Toutes versions à Binaires Oui

OmniPCX Enterpri- Toutes les ver- Texte Oui

1.3 Exigences d'application externes

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 8/64

1.4 Exigences de licence

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 9/64

2.2 Configurez les paramètres OmniPCX Enterprise pour la

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 10/64

2.3 Configuration des paramètres de stockage des tickets

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 11/64

2. Dans l'onglet NT account, entrez le Username et le Password

2.4 Sélection de serveurs de communication pour la collecte des tickets

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 12/64

2.5 Configuration du filtre pour la taxation externe

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 13/64

3. Définissez le champ Files for external Accounting sur Yes

2.5.2 Vérification de la licence et définition du filtre pour OXO Connect

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 14/64

1. Dans l'application de configuration, sélectionnez l'entrée serveur de communication. Effectuez un

2. Sélectionnez la case External Metering Activation

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 15/64

6. Sélectionnez Incoming&Outgoing calls pour Active call accounting

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 16/64

2.6 Récupération des tickets

2.6.1 Lancement d'une synchronisation manuelle

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 17/64

4. Cliquez sur le bouton Now dans le champ Start Date

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 18/64

3.1 OmniPCX Enterprise Tickets

3.1.1 Définitions du format .DAT

Nom de champ position taille (caractères) justifié

Ticket Version 1,5 5 L

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 19/64

Nom de champ position taille (caractères) justifié

Personal or Business 227 1 N

8AL90709FRAD - Ed. 01 - Octobre 2017 - Tickets de taxation et de statistiques VoIP 20/64

Nom de champ position taille (caractères) justifié

EndOfLine Unix EOL 0A (10 décimales) N

tableau 3.2 : Descriptions des champs pour OmniPCX Enterprise

Nom de Decription/Valeur Utilisation en fonction du type

Local Transit Sortant Entrant