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?
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 ?
Cédric
---------------------------------------------------------------
Rejoignez l'Association Asterisk France : http://www.asterisk-france.org
Envie de mettre des étoiles dans les yeux de vos clients : EasyPyro.ch
On a pas inventé l'électricité en cherchant à améliorer la bougie...
---------------------------------------------------------------
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).
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
Cédric
---------------------------------------------------------------
Rejoignez l'Association Asterisk France : http://www.asterisk-france.org
Envie de mettre des étoiles dans les yeux de vos clients : EasyPyro.ch
On a pas inventé l'électricité en cherchant à améliorer la bougie...
---------------------------------------------------------------
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 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.