Le 29/10/14 19:14, David Ponzone a écrit :
Pas longtemps, mais t’as un plan pour une carte E1 sérieuse à 100$ ?
Une carte à 100$ non. Mais on doit trouver des carte dual E1 a peu prés
sérieuse à 300E.
En revanche pour coder un truc pareil tu penses vraiment que c'est
facile ? j'avais
Le 31 oct. 2014 à 10:43, Raphael Mazelier r...@futomaki.net a écrit :
Le 29/10/14 19:14, David Ponzone a écrit :
Pas longtemps, mais t’as un plan pour une carte E1 sérieuse à 100$ ?
Une carte à 100$ non. Mais on doit trouver des carte dual E1 a peu prés
sérieuse à 300E.
Avec Echo
Le 31/10/14 11:52, David Ponzone a écrit :
Avec Echo Cancellation ?
Si tu as des refs, je suis preneur.
Dans ce cas précis tu ne devrais pas avoir besoin car tu ne ferais que
recopier les trames reçus.
Non, je voulais pas dire pour le coder from-scratch, mais en se reposant sur un
Sinon le RNIS à papa y'a toujours l'option de prendre un Patapsco en
intercalé TNR/PABX.
La au moins aucuns risques de pourrir les accès, avec une vue complète
sur tout ce qui se passe en temps réels.
Mais coté prix ca risque de faire mal...
Pareil avec un analyseur de protocol genre GLCom.
Non, je voulais pas dire pour le coder from-scratch, mais en se reposant sur
un softswitch sérieux existant, donc FreeSWITCH par exemple.
Ah oui mais la tu introduis un élément en coupure, je pense que tu seras
obligé d'answer le call et de l'abouter. Sur des cas simples ca doit pouvoir
Avec un Liberator tu veux dire ?
Ca va aller chercher dans les 2000€ pour 2 E1 je pense.
On s’éloigne un peu du modèle de départ, si ça coute plus cher que le PABX du
client :)
Le 31 oct. 2014 à 12:18, Sebastien Lesimple slesim...@laposte.net a écrit :
Sinon le RNIS à papa y'a toujours
Le 31/10/2014 12:49, David Ponzone a écrit :
Avec un Liberator tu veux dire ?
Ca va aller chercher dans les 2000€ pour 2 E1 je pense.
C'est plus aussi cher que c'était.
Un S chargé a mort avec conversion 1PRI/16BRI, licences field upgrade
NT/TN sur tous les ports, 5 ans de fast replace livré
Le 31/10/2014 10:43, Raphael Mazelier a écrit :
Le 29/10/14 19:14, David Ponzone a écrit :
Pas longtemps, mais t’as un plan pour une carte E1 sérieuse à 100$ ?
Une carte à 100$ non. Mais on doit trouver des carte dual E1 a peu prés
sérieuse à 300E.
En revanche pour coder un truc
On 31.10.2014 14:19, Tristan Mahé wrote:
Je ne connais AUCUN boitier blackbox en MITM qui n'engendre aucune
coupure en cas de pépin ( même ceux qu'on te vends qui assurent la
continuité hardware du cable, ton timing pête en failover ).
ce genre de chose semble correspondre au besoin
C’est de l’écoute en haute-impédance avec un câble en Y sur le patch-panel.
J’ai vu d’autres modèles comme ça, c’est effectivement élégant, mais celui-là
est peut-être un peu surdimensionné pour faire les stats d’un E1 :)
Il faudrait un modèle mono-E1 comme ça, sans les fonctions de cross-connect
David Ponzone a écrit :
t'as un plan pour une carte E1 sérieuse à 100$ ?
Raphael Mazelier a écrit :
Une carte à 100$ non.
Bah pour ce genre de chose good old chinaroby c'est suffisant, pas besoin
d'octasic DSP ou autres trucs sophistiqués.
Bonjour à tous
Désolée pour le mauvais tag en objet je rectifie.
Je recherche
une solution gratuite ou pas trop chère permettant de
monitorer et de remonter des alertes lorsque les seuils de
consommation selon des destinations sont dépassés.
cela sur tout type de pbx.
merci pour
C’est pas le mauvais objet. C’est la mauvaise liste.
Il faudrait plutôt demander ça sur fr.reseaux.telecoms.pabx
Ceci dit, ça n’existe pas en gratuit à ma connaissance.
En payant, ça existe en version plus ou moins universelle (si le PABX le
supporte) chez différents éditeurs (Cieme, Axinite,
CDRtool fais ce genre de choses si je me rappelle correctement en
opensource...
C'est pas l'idéal, mais ça peut répondre à la demande...
Le 29/10/2014 10:12, David Ponzone a écrit :
C’est pas le mauvais objet. C’est la mauvaise liste.
Il faudrait plutôt demander ça sur fr.reseaux.telecoms.pabx
CDRtool prend, il me semble, des CDR format OpenSER.
Avec un PABX propriétaire, on n’a généralement pas accès aux CDR bruts, et il
faut passer par l’interface de sortie au fil de l’eau des CDR, en V24 (pour les
PABX du paléolithique) ou ethernet (pour les temps modernes).
De toute façon, si le
Sinon tu as http://www.cdr-stats.org/ mais il va falloir mettre la main
dedans pour que ça soit clean...
Le 29/10/2014 10:44, David Ponzone a écrit :
CDRtool prend, il me semble, des CDR format OpenSER.
Avec un PABX propriétaire, on n’a généralement pas accès aux CDR bruts, et il
faut passer
Même problème pour CDR-stats (que je connaissais pas d’ailleurs, merci, ça a
l’air très sympa).
Ca tape dans une base MongoDB que FreeSWITCH ou Asterisk vont remplir en live.
Ca prend pas du fil de l’eau propriétaire
Alcatel/Aastra/Panasonic/Siemens/Avaya/…
Je pense que la sortie au fil de l’eau
Bon alors y'a une petite boite en Espagne qui s'appelle Jusan et qui à
une gamme de produits qui fait ca.
Tax-Line, www.jusan.es et c'est pas cher du tout!
Tsss... encore un Geek qui veut prendre un missile atomique pour écraser
une mouche quand la tapette a mouche fait très bien l'affaire
Coordonnées a contacter:
Sébastien COUVET | Export Manager |cou...@jusan.es mailto:cou...@jusan.es
JUSAN, S.A | Tel:+3491 456 01 10 | Fax:+34 91 553 14 11
http://www.jusan.es http://www.jusan.es/
Le 29/10/2014 11:41, Sebastien Lesimple a écrit :
Bon alors y'a une petite boite en Espagne qui
Ma version locale prends un peu tous les types de cdr en fait, heavy
fork non redistribué par contre.
Si il te faut du plugplay, solutions proprios obligatoires...
Si tu veux maitriser l'outil, comme dit, il faut mettre les mains dedans ;)
Le 29/10/2014 11:22, David Ponzone a écrit :
Même
Et tu analyses ton trafic au niveau protocolaire avec ces outils là?
Le 29/10/2014 11:53, Tristan Mahé a écrit :
Ma version locale prends un peu tous les types de cdr en fait, heavy
fork non redistribué par contre.
Si il te faut du plugplay, solutions proprios obligatoires...
Si tu veux
Un outil CDR n'est pas un outil protocole ( à part les hangup causes ).
Pour ce besoin il y as d'autres outils...
Philosohie
Le 29/10/2014 12:05, Sebastien Lesimple a écrit :
Et tu analyses ton trafic au niveau protocolaire avec ces outils là?
Le 29/10/2014 11:53, Tristan Mahé a écrit :
Un outil CDR n'est pas un outil protocole ( à part les hangup causes ).
Pour ce besoin il y as d'autres outils...
Philosophie UNIX quand tu nous tiens ;)
PS: Désolé pour le doublon, hit send before finishing :)
Le 29/10/2014 12:05, Sebastien Lesimple a écrit :
Et tu analyses ton trafic au
C’est pas un problème de type de CDR. Le problème est que sur un PABX
propriétaire, tu ne pourras pas aller récupérer le fichier des CDR en live (en
pull) par
Ils ne savent que te pousser (en push) les CDR au fil de l'eau par l’interface
V24 ou ethernet.
En Ethernet, ils t’envoient ça sur une
Si tu considères une connection ssh pour du tail de log comme une
ouverture de connection TCP permanente ( c'est exactement ça ), oui.
Je n'aime pas ce design car ta box deviens spof pour ton analyse
taxation si ton autocom ne sait pas faire pause/resume, ou si ton démon
n'as pas moyen de savoir
on en a déjà parlé a maintes reprises.
Tu as une erreur dans ton design.
Si tu veux faire un outil qui fasse ca proprement, il ne faut pas
s’occuper de l'autocom, ni du mec qui fait la maintenance (ou pas).
Inseres toi entre l'autocom et la TNR, analyses le protocole et génères
tes propres
Il y a peut-être quelques PABX propriétaire qui autorisent le SSH, mais ce
n’est pas la méthode dont je parle.
Ils ont un port TCP qui écoute les connexions entrantes et ils diffusent les
CDR en mode texte au client qui vient se connecter .
En mode bourin.
Il semblerait que certains PABX
Le 29/10/14 12:42, David Ponzone a écrit :
Il y a peut-être quelques PABX propriétaire qui autorisent le SSH, mais ce
n’est pas la méthode dont je parle.
Ils ont un port TCP qui écoute les connexions entrantes et ils diffusent les
CDR en mode texte au client qui vient se connecter .
En mode
Le 29/10/2014 12:48, Raphael Mazelier a écrit :
Le 29/10/14 12:42, David Ponzone a écrit :
Il y a peut-être quelques PABX propriétaire qui autorisent le SSH,
mais ce n’est pas la méthode dont je parle.
Ils ont un port TCP qui écoute les connexions entrantes et ils
diffusent les CDR en
Le 29 oct. 2014 à 12:40, Sebastien Lesimple slesim...@laposte.net a écrit :
on en a déjà parlé a maintes reprises.
Tu as une erreur dans ton design.
Si tu veux faire un outil qui fasse ca proprement, il ne faut pas s’occuper
de l'autocom, ni du mec qui fait la maintenance (ou pas).
Le 29/10/2014 13:08, Tristan Mahé a écrit :
Le 29/10/2014 12:48, Raphael Mazelier a écrit :
Le 29/10/14 12:42, David Ponzone a écrit :
Il y a peut-être quelques PABX propriétaire qui autorisent le SSH,
mais ce n’est pas la méthode dont je parle.
Ils ont un port TCP qui écoute les connexions
j'ai pense a utiliser Nagios mais les plugin pour la voip restent limites
peut etre qu'avec splunk on peut developper ce genre de sonde
En date de : Mer 29.10.14, Tristan Mahé t.m...@b-and-c.net a écrit :
Objet: Re: [FRnOG] [TECH]- Monitoring
En date de : Mer 29.10.14, Tristan Mahé t.m...@b-and-c.net a écrit :
Objet: Re: [FRnOG] [TECH]- Monitoring Conso Telecom
À: David Ponzone david.ponz...@gmail.com
Cc: fatiha boudj fbo...@yahoo.fr, frnog@frnog.org
Date: Mercredi 29 octobre 2014, 13h24
Sebastien Lesimple a écrit :
Si tu veux faire un outil qui fasse ca proprement, il ne faut pas s'occuper
de l'autocom, ni du mec qui
fait la maintenance (ou pas). Inseres toi entre l'autocom et la TNR, analyses
le protocole et génères
tes propres CDR. Si ta box se plante soit tu la shunte
Pas longtemps, mais t’as un plan pour une carte E1 sérieuse à 100$ ?
Le 29 oct. 2014 à 18:08, Michel Py mic...@arneill-py.sacramento.ca.us a écrit
:
Sebastien Lesimple a écrit :
Si tu veux faire un outil qui fasse ca proprement, il ne faut pas s'occuper
de l'autocom, ni du mec qui
fait la
35 matches
Mail list logo
