Voir la version complète : Master.csv et indications incohérentes duration/billsecondes?
Ca fait 1 an que le sytème est en pilote et on passe en production mais la facturation se fait d'après les fichiers fournis par l'opérateur.
En essayant de rapprocher le fichier local de l'asterisk (Master.csv) et les données fournies par l'opérateur je me suis étonné des indications dans le fichier Master.csv et soit je comprend mal ce qui est indiqué, soit le fichier n'est pas utilisable. Le fichier non personnalisé donne les indications suivantes:
Heure de début: 17/05/2010 06:04
Heure de réponse: 17/05/2010 06:04
Heure de fin : 17/05/2010 06:05
Durée : 64
Billing : 43
Comment un call qui fait 1 sec. d'après les heures début et fin peut-il faire 64 sec. de durée et 43 sec. de facturation?
J'en ai des pages et des pages qui sont de ce style.
Comme le produit est quand même beaucoup utilisé, je ne pense pas que ce soit une erreur, mais sans doute que je ne comprends pas ce qu'il veut me dire dans le fichier.. :D
Asterisk 1.4.21.2 installé sur Debian
Je sors par un Gateway Cisco qui part lui sur une T2 et les deux sont reliés par un trunk SIP
Merci pour un petit coup de main.
ffossard
17/01/2011, 00h16
Est-ce que par hasard l'appelé n'aurait pas mis 21 secondes à répondre ?
Est-ce que par hasard l'appelé n'aurait pas mis 21 secondes à répondre ?
Si on regarde les chiffres, il aurait répondu dans la même seconde seconde et communiqué 1 seconde. Le status du call étant ANSWERED
De toute façon, ce qui me dérange le plus c'est qu'il y a eu selon les horaires dans le fichier 1 sec que si je facturais suivant le chiffre dans la colone facturâble, je facturerais 43 sec.
Et pour la facturation en cas de réponse imédiate le chiffre devrait être le même dans les 2 colones, non?
ffossard
17/01/2011, 02h02
Dans les chiffres que je vois, il n'y a pas les secondes, juste 6h et 4 minutes :heink:
Dans les chiffres que je vois, il n'y a pas les secondes, juste 6h et 4 minutes :heink:
Mon interpretation est donc fausse:
L'appel entre à 6h04
L'appelé décroche à 6h04
Il racroche à l'heure de fin à 6h05
???
ffossard
17/01/2011, 05h15
Mon interpretation est donc fausse:
L'appel entre à 6h04
L'appelé décroche à 6h04
Il racroche à l'heure de fin à 6h05
???
Je vois ça comme ça, on a pas le temps en secondes.
Avez-vous moyen de faire un test par vous-même, par exemple en laissant sonner précisément 15 secondes avant de décrocher, en restant 30 secondes au téléphone avant de raccrocher, puis en vérifiant ensuite le cdr.
Test fait à l'instant (15sec sonnerie et 15 sec de communication):
Appel entrant vers l'astérisk:
Appel entrant: 2011-01-17 06:43:41
Décroché: 2011-01-17 06:43:56
fin de l'appel : 2011-01-17 06:44:12
Durée : 31
Bill : 16
Appel sortant de l'astérisk:
Appel sortant: 2011-01-17 06:47:42
Décroché: 2011-01-17 06:47:59
Fin de l'appel : 2011-01-17 06:48:26
Durée: 44
Bill: 27
Comme les chiffres ne correspondent pas à la réalité, j'ai refait un second appel:
Appel sortant: 2011-01-17 06:51:21
Décroché: 2011-01-17 06:51:39
Fin de l'appel: 2011-01-17 06:52:13
Durée: 52
Bill: 34
J'ai essayé d'être précis, mais décider de quand est le début et fin à la montre, il peut y avoir 1 sec de décalage et donc sur l'entrant, je suis OK à mon avis. Sur le sortant par contre (et c'est celui qui est sensé être facturé...) il y a trop d'écart par rapport à la réalité.
Il faut dire que les 2 téléphones ne sont pas juste l'un à côté de l'autre et donc j'ai essayé de faire les décroché et racrocher depuis le téléphone sur l'astérisk et j'ai obtenu ce résultat:
Appel sortant: 2011-01-17 07:02:57
Décroché: 2011-01-17 07:03:14
Fin de l'appel : 2011-01-17 07:03:29
Durée: 32
Bill: 15
Donc, il prend en compte le temps que le poste téléphonique sur l'astérisk est décroché et non le temps de communication. Ce n'est donc pas utilisable pour la facturation car le client est sensé payer ce qu'il téléphone réellement et pas le temps ou son poste est décroché ou raccroché.
La conf du cdr est celle par défaut et les seuls parametres dans cdr.conf sont:
[csv]
usegmtime=yes ; log date/time in GMT. Default is "no"
loguniqueid=yes ; log uniqueid. Default is "no"
loguserfield=yes ; log user field. Default is "no"
Existe-t-il des paramettres à configurer pour avoir le temps réel de communication entre un poste interne et externe?
cedricscha
17/01/2011, 10h16
Ne fais-tu pas par hasard un answer dans ton dialplan ? cela pourrais etre cela ta cause de décallage.
Comment effectues-tu tes appels sortants ? avec un trunk, une carte Isdn ? un boitier patton ?
Ne fais-tu pas par hasard un answer dans ton dialplan ? cela pourrais etre cela ta cause de décallage.
Comment effectues-tu tes appels sortants ? avec un trunk, une carte Isdn ? un boitier patton ?
LEs appels sortant se font par un trunk SIP vers un Cisco2800 qui lui sort par une carte T2 sur une connexion T2 SFR
Pour ce qui est du dial plan, c'est ou que je dois regarder... ?
Le serveur a été mis en place par une personne qui nous a quitté et je reprend péniblement la main sur l'astérisk (jusqu'à présent full Cisco uniquement pour moi).
cedricscha
17/01/2011, 11h07
regarde ton extensions.conf, mais à mon avis, le problème viens de l'interco avec le cisco.
A mon avis le cisco décroche et recompose, ce qui pour l'astersik fais comme si le destinataire avais répondu.
mais a voir avec ton extension.conf
pour info, je suis en 1.6.1.20, avec du chan_ss7 vers un opérateur, et je suis à quelques pouillemes de % sur les réconcilliations mensuelles.
chaque appel peut avoir un delta de +/- 1 ou 2 secondes - ca le fait même en téléphonie classique (j'ai eu des écarts de 2 sec sur un ocb alcatel sur des scenarios compliqués)
si les écarts sont plus grands, effectivement, il y a autre chose. tu peux essayer de faire un ngrep -t sur l'@ip du poste emettant l'appel, ca te permettra de voir le timing de ton appel - et de comparer à ce qu'il y a dans master.csv
mais je doute qu'il y ait un bug la dessus - possible, peu probable !
J.
regarde ton extensions.conf, mais à mon avis, le problème viens de l'interco avec le cisco.
A mon avis le cisco décroche et recompose, ce qui pour l'astersik fais comme si le destinataire avais répondu.
mais a voir avec ton extension.conf
Je ne pense pas car:
La destination commence à sonner exactement quand la source de l'appel commence à sonner
Quand je racrocje la destination ou la source de l'appel, l'autrepose est racroché de suite.
Donc, pas de perte de temps ou de délais suplémentaire à un endroit. La durée des activités diverses est bien d'environ 30 sec.
Ce n'est que quand je mets du temps à racrocher le poste connecté directement à l'astérisk que les temps en sec. monte à plus de 30 sec. Donc l'astérisk prend bien en compte le temps que le combiné est décroché et non le temps que dure la communication entre les 2 postes.
Sans doute il existe un autre bill parametre pour me donner la bonne valeure mais je ne sais pas lequel.
Avec le nombre d'astérisk en service, un tel "bug" aurait été découvert depuis longtemps... ça fait de trop grosses différences pour que ce soit passé innaperçu.
pour info, je suis en 1.6.1.20, avec du chan_ss7 vers un opérateur, et je suis à quelques pouillemes de % sur les réconcilliations mensuelles.
chaque appel peut avoir un delta de +/- 1 ou 2 secondes - ca le fait même en téléphonie classique (j'ai eu des écarts de 2 sec sur un ocb alcatel sur des scenarios compliqués)
si les écarts sont plus grands, effectivement, il y a autre chose. tu peux essayer de faire un ngrep -t sur l'@ip du poste emettant l'appel, ca te permettra de voir le timing de ton appel - et de comparer à ce qu'il y a dans master.csv
mais je doute qu'il y ait un bug la dessus - possible, peu probable !
J.
Je ne pense pas non plus que ce soit un bug car il aurait été découvert depuis longtemps.... :D
Par contre, ce n'est peut être pas le bon chiffre dans la colonne qui est sensée me donner le temps en sec à facturer. Il faut personnaliser le Master.csv pour avoir les bon chiffres ou ça devrait être bon sans rien faire de spécial?
Pour le ngrep, je vais le faire ce soir car je dois m'absenter. Mais d'après les temps indiqué je ne pense pas me tromper en disant que dans la colonne ou j'attends la valeur à facturer j'ai bien le temps que le poste enregistré sur l'astérisk est décroché et non le temps que les deux extrémités sont en communication.
Suite au ngrep, j'ai constaté la chose suivante:
Action sur ma montre:
Appel d'un numéro à l'extérieur
laissé sonner 10 sec
pris l'appel pour 15 sec
laissé décrocher 30 sec
Dans le ngrep:
07:54:57 demande du numéro à appeler
07:55:13 décrocher
07:55:29 message Bad Event SIP/2.0 489 Bad event..Via: SIP/2.0/UDP
07:55:48 BYE
Dans le log Master.csv j'ai 51sec d'appel et 35sec à facturer
Il semble bien que le temps des 35sec de "à facturer", c'est bien le temps entre le décrocher et le racrcocher du téléphone et non le temps qu'il est en communication.
Sans doute l'astérisk ne comprend pas le message Bad Event mais j'utilise un PAP2-EU de Linksys pour le test et donc il s'agit quand même d'appareils vendus massivement dans le monde pour ce genre d'application.
De plus, je ne peux pas m'imaginer que vous faites des conf pour tous les différents type d'appareils connectés et donc une configuration standard devrait fonctionner.
Une idée?
le bad event est effectivement etrange... il se déclenche tout seul ?
si tu veux analyser plus en détail, tu peux rajouter dans le ngrep -O <fichier.pcap> et ouvrir fichier.pcap avec wireshark - qui analyse très bien le sip.
Oui, le bad event se déclanche lors de la fin de communication.
Je pense que l'asterisk ne comprend pas les infos de la passerelle Cisco qui essaye de lui dire que la communication est finie et donc il compte le temps jusqu'à ce que le poste interne de l'asterisk racroche et c'est pourquoi j'ai la différence du temps de communication.
Une solution? Des infos sur du déjà vécu?
pour bien comprendre, qui emet le bad event ? en toute logique, cela doit être en réponse à quelque chose... ou c'est spontané ? si c'est spontané, cela doit venir de timers qui claquent - refais le test avec une durée d'appel un peu plus longue
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. Tous droits réservés