[FRnOG] Re: [FRNOG] [MISC]Unbound et resolveur DNS à la maison
Salut, Pratique pour bloquer des pubs, dns menteur ou autre par exemple Niveau ressource, c'est sans problème, tu peux même le mettre sur un pi qui a déjà d'autres services dessus par exemple. C'est rapide à mettre en place et à configurer Le 10 mars 2019 20:45:23 GMT+01:00, Carroussel Informatique a écrit : >Bonsoir la liste. > >Y a t'il un intérêt pour un particulier collé derrière une MachinBox, a > >utiliser Unbound (ou tout autre résolveur DNS), à part pour le "sport" >? > >Question subsidiaire : est ce que ce genre d'outil ne va pas mettre la >bécane à genoux ? > > >Merci et bonne soirée. > > >--- >Liste de diffusion du FRnOG >http://www.frnog.org/ -- Librement, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Conservation log appels opérateurs/presta Voip
Ce sont des pistes bien intéressantes !! Y a pas de firewall entre l'Infra voix de l'opé et le client 'Vais voir pour pousser un peu tout ça Merci à tous pour les retours, je vous tiendrai informé de l'évolution Le 3 mars 2019 21:54:20 GMT+01:00, Olivier Divel a écrit : >Comme dit plus il faudrait checker s'il n'y a pas une fonction RTP >direct >(ou tout autre nom de ce genre, ça dépend du matériel). > >Souvent les installateurs laissent ça par défaut et l'IPBX met en >relation >directement le poste et l'opérateur. > >Sinon s'il y a un firewall sur le chemin s'assurer que la plage RTP est >bien ouverte > >Après soucis que j'ai déjà vu avec un client qui a un OXE, c'est un >soucis >au niveau de la nego du RTP, les 2 équipements se mettaient d'accord >sauf >que l'OXE répondait Port Unreachable. >Ça a été une belle galère pour mettre ça en évidence. > >Dans tout les cas bon courage ! > >Le dim. 3 mars 2019 à 21:38, admin Obf a écrit : > >> Cpe déjà vérifié, le presta se contente de dire qu'il a tout vérifié >chez >> lui sans trouver ce qui ne va pas >> >> Le 3 mars 2019 21:19:42 GMT+01:00, David Ponzone > >> a écrit : >> >Ils ont pensé à une éventuelle responsabilité du CPE (sip alg à la >con) >> >? >> > >> > >> >David Ponzone >> > >> > >> > >> >> Le 3 mars 2019 à 21:05, admin Obf a écrit : >> >> >> >> Le one way permanent, ça serait si simple ici … ça ne le fait que >sur >> >certain appel en tout ou rien ^^' >> >> >> >> Là, l'opérateur a pris des traces à son niveau directement sur son >> >sbc et ainsi mettre en évidence qu'il ne recevait pas de son en >> >provenance de l'équipement client (sdp et cie OK, fait via tcpdump) >> >tandis que le presta se contente de dire qu'il envoie bien et que >c'est >> >l'opérateur qui reçoit pas >> >> Bref, un bon presta comme on les aime (: >> >> >> >> Le plus moche, c'est qu'effectivement le client est pris entre les >> >deux … >> >> Vu que c'est technique, il se repose sur son presta qui rejette la >> >balle sur l'opérateur et inversement … >> >> >> >> >> >> Le 3 mars 2019 20:15:52 GMT+01:00, David Ponzone >> > a écrit : >> >>> >> >>> Si c’est une situation de one-way permanente, et que les 2 ne >font >> >pas leurs meilleurs efforts pour comprendre, je plains le client. >> >>> C’est stupide de la part de l’opérateur et du presta, mais pour >le >> >vivre fréquemment, y a des prestas qui devraient changer de métier >> >(surtout un qui dit qu’il peut pas prendre de traces….). >> >>> >> >>>> Le 3 mars 2019 à 19:35, admin Obf a écrit : >> >>>> >> >>>> Effectivement … >> >>>> Erreur de ma part dans le précédent message >> >>>> il fallait lire : >> >>>> >> >>>> Je sens que l'opérateur va fermer l'incident et renvoyer son >client >> >vers le gestionnaire de l'équipement (le presta), même en cas de >> >nouvelles ouverture pour la même problématique >> >>>> >> >>>> >> >>>> >> >>>> Le 3 mars 2019 19:25:33 GMT+01:00, David Ponzone >> > a écrit : >> >>>>> Je comprends plus. >> >>>>> Il fait quoi le presta s’il n’est pas gestionnaire de >l’équipement >> >? >> >>>>> Ptet qu’il sert juste à rien, à part bloquer :) >> >>>>> >> >>>>>> Le 3 mars 2019 à 17:39, admin Obf a écrit >: >> >>>>>> >> >>>>>> Dans le cas en tête, l'opérateur a déjà tenté de prouvé qu'il >> >n'est >> >>>>> pas en cause avec l'aide de capture de trames (identique dans >les >> >deux >> >>>>> cas, on est sur du one way en provenance presta/client vers >> >opérateur), >> >>>>> mais le presta refuse de l'entendre et part du principe que vu >> >qu'il >> >>>>> n'a pas de trace ou de moyen d'en prendre, le défaut ne peut >venir >> >que >> >>>>> du coté opérateur et refuse tout dialogue, se limitant à >> >"passe-plat" >> >>>>> selon ces propres termes >> >>>>>> >> >>>>>> Ce qui provoque un blocage des deux cotés :/ >> >>>>>> Je sens que le presta va fermer l'incident et renvoyer
Re: [FRnOG] [MISC] Conservation log appels opérateurs/presta Voip
Cpe déjà vérifié, le presta se contente de dire qu'il a tout vérifié chez lui sans trouver ce qui ne va pas Le 3 mars 2019 21:19:42 GMT+01:00, David Ponzone a écrit : >Ils ont pensé à une éventuelle responsabilité du CPE (sip alg à la con) >? > > >David Ponzone > > > >> Le 3 mars 2019 à 21:05, admin Obf a écrit : >> >> Le one way permanent, ça serait si simple ici … ça ne le fait que sur >certain appel en tout ou rien ^^' >> >> Là, l'opérateur a pris des traces à son niveau directement sur son >sbc et ainsi mettre en évidence qu'il ne recevait pas de son en >provenance de l'équipement client (sdp et cie OK, fait via tcpdump) >tandis que le presta se contente de dire qu'il envoie bien et que c'est >l'opérateur qui reçoit pas >> Bref, un bon presta comme on les aime (: >> >> Le plus moche, c'est qu'effectivement le client est pris entre les >deux … >> Vu que c'est technique, il se repose sur son presta qui rejette la >balle sur l'opérateur et inversement … >> >> >> Le 3 mars 2019 20:15:52 GMT+01:00, David Ponzone > a écrit : >>> >>> Si c’est une situation de one-way permanente, et que les 2 ne font >pas leurs meilleurs efforts pour comprendre, je plains le client. >>> C’est stupide de la part de l’opérateur et du presta, mais pour le >vivre fréquemment, y a des prestas qui devraient changer de métier >(surtout un qui dit qu’il peut pas prendre de traces….). >>> >>>> Le 3 mars 2019 à 19:35, admin Obf a écrit : >>>> >>>> Effectivement … >>>> Erreur de ma part dans le précédent message >>>> il fallait lire : >>>> >>>> Je sens que l'opérateur va fermer l'incident et renvoyer son client >vers le gestionnaire de l'équipement (le presta), même en cas de >nouvelles ouverture pour la même problématique >>>> >>>> >>>> >>>> Le 3 mars 2019 19:25:33 GMT+01:00, David Ponzone > a écrit : >>>>> Je comprends plus. >>>>> Il fait quoi le presta s’il n’est pas gestionnaire de l’équipement >? >>>>> Ptet qu’il sert juste à rien, à part bloquer :) >>>>> >>>>>> Le 3 mars 2019 à 17:39, admin Obf a écrit : >>>>>> >>>>>> Dans le cas en tête, l'opérateur a déjà tenté de prouvé qu'il >n'est >>>>> pas en cause avec l'aide de capture de trames (identique dans les >deux >>>>> cas, on est sur du one way en provenance presta/client vers >opérateur), >>>>> mais le presta refuse de l'entendre et part du principe que vu >qu'il >>>>> n'a pas de trace ou de moyen d'en prendre, le défaut ne peut venir >que >>>>> du coté opérateur et refuse tout dialogue, se limitant à >"passe-plat" >>>>> selon ces propres termes >>>>>> >>>>>> Ce qui provoque un blocage des deux cotés :/ >>>>>> Je sens que le presta va fermer l'incident et renvoyer son client >>>>> vers le gestionnaire de l'équipement, même en cas de nouvelles >>>>> ouverture pour la même problématique >>>>>> >>>>>> Le 3 mars 2019 16:55:11 GMT+01:00, David Ponzone >>>>> a écrit : >>>>>> Le 3 mars 2019 à 13:08, admin Obf a écrit : >>>>>> >>>>>> Bien le bonjour @toutes et tous, >>>>>> >>>>>> Quelques questionnements me taraudent quant à la conservation des >>>>> logs par les différents acteurs dans le cadre de fourniture de >VoIP >>>>>> >>>>>> J'ai vu que l'opérateur se devait de conserver des logs (du >moins, en >>>>> France) ne serait-ce que pour des raisons légales (réquisition >>>>> judiciaire, etc.). >>>>>> >>>>>> Qu'en est-il des autres parties ? Le presta notamment sur un >trunk >>>>> SIP doit il aussi conserver des logs ? >>>>>> >>>>>> Je vois pas pourquoi le prestataire serait concerné. Il ne fait >que >>>>> configurer/maintenir un équipement qui appartient au client. >>>>>> Au pire, il a un devoir de conseil envers le client, qui est >>>>> probablement une "obligation" assez floue dans notre domaine. >>>>>> >>>>>> Pour moi, l’obligation de conserver les logs est sur les >opérateurs, >>>>> pour pouvoir répondre à la Police/Justice. >>>>>> >>>>>> Dans
Re: [FRnOG] [MISC] Conservation log appels opérateurs/presta Voip
Le one way permanent, ça serait si simple ici … ça ne le fait que sur certain appel en tout ou rien ^^' Là, l'opérateur a pris des traces à son niveau directement sur son sbc et ainsi mettre en évidence qu'il ne recevait pas de son en provenance de l'équipement client (sdp et cie OK, fait via tcpdump) tandis que le presta se contente de dire qu'il envoie bien et que c'est l'opérateur qui reçoit pas Bref, un bon presta comme on les aime (: Le plus moche, c'est qu'effectivement le client est pris entre les deux … Vu que c'est technique, il se repose sur son presta qui rejette la balle sur l'opérateur et inversement … Le 3 mars 2019 20:15:52 GMT+01:00, David Ponzone a écrit : >Si c’est une situation de one-way permanente, et que les 2 ne font pas >leurs meilleurs efforts pour comprendre, je plains le client. >C’est stupide de la part de l’opérateur et du presta, mais pour le >vivre fréquemment, y a des prestas qui devraient changer de métier >(surtout un qui dit qu’il peut pas prendre de traces….). > >> Le 3 mars 2019 à 19:35, admin Obf a écrit : >> >> Effectivement … >> Erreur de ma part dans le précédent message >> il fallait lire : >> >> Je sens que l'opérateur va fermer l'incident et renvoyer son client >vers le gestionnaire de l'équipement (le presta), même en cas de >nouvelles ouverture pour la même problématique >> >> >> >> Le 3 mars 2019 19:25:33 GMT+01:00, David Ponzone > a écrit : >>> Je comprends plus. >>> Il fait quoi le presta s’il n’est pas gestionnaire de l’équipement ? >>> Ptet qu’il sert juste à rien, à part bloquer :) >>> >>>> Le 3 mars 2019 à 17:39, admin Obf a écrit : >>>> >>>> Dans le cas en tête, l'opérateur a déjà tenté de prouvé qu'il n'est >>> pas en cause avec l'aide de capture de trames (identique dans les >deux >>> cas, on est sur du one way en provenance presta/client vers >opérateur), >>> mais le presta refuse de l'entendre et part du principe que vu qu'il >>> n'a pas de trace ou de moyen d'en prendre, le défaut ne peut venir >que >>> du coté opérateur et refuse tout dialogue, se limitant à >"passe-plat" >>> selon ces propres termes >>>> >>>> Ce qui provoque un blocage des deux cotés :/ >>>> Je sens que le presta va fermer l'incident et renvoyer son client >>> vers le gestionnaire de l'équipement, même en cas de nouvelles >>> ouverture pour la même problématique >>>> >>>> Le 3 mars 2019 16:55:11 GMT+01:00, David Ponzone >>> a écrit : >>>> Le 3 mars 2019 à 13:08, admin Obf a écrit : >>>> >>>> Bien le bonjour @toutes et tous, >>>> >>>> Quelques questionnements me taraudent quant à la conservation des >>> logs par les différents acteurs dans le cadre de fourniture de VoIP >>>> >>>> J'ai vu que l'opérateur se devait de conserver des logs (du moins, >en >>> France) ne serait-ce que pour des raisons légales (réquisition >>> judiciaire, etc.). >>>> >>>> Qu'en est-il des autres parties ? Le presta notamment sur un trunk >>> SIP doit il aussi conserver des logs ? >>>> >>>> Je vois pas pourquoi le prestataire serait concerné. Il ne fait que >>> configurer/maintenir un équipement qui appartient au client. >>>> Au pire, il a un devoir de conseil envers le client, qui est >>> probablement une "obligation" assez floue dans notre domaine. >>>> >>>> Pour moi, l’obligation de conserver les logs est sur les >opérateurs, >>> pour pouvoir répondre à la Police/Justice. >>>> >>>> Dans le cas de debug entre le presta et l'opérateur, le presta >>> (gestionnaire d'un oxo par exemple) peut-il se cacher derrière le >fait >>> d'avoir un système ne permettant pas de conserver ne serait-ce que >des >>> journaux d'appels et ainsi mettre la faute sur l'opérateur sans >avoir >>> de quoi le prouver ? (Cdr) >>>> >>>> Je cherche dans quelle situation de debug tu voudrais mettre la >faute >>> sur l’opérateur. >>>> Quand tu debug, c’est qu’à priori tu es dans une démarche >>> constructive avec l’opérateur pour régler un problème chez le >client. >>>> Mais ne t’inquiète pas, tout PBX moderne (OXO compris) permet de >>> conserver logs et CDR. >>>> Tu penses à quoi ? >>>> Si ton client a passé des appels pour 20k€ dans le mois, et que tu >>> espères pouvoir dire que c’est la faute de l’opérateur parce que tu >>> n’as pas les CDR pour prouver le contraire sur le PBX, j’ai peur que >tu >>> lances ton client dans une procédure difficile et perdue d’avance :) >>>> Liste de diffusion du FRnOG >>>> http://www.frnog.org/ <http://www.frnog.org/> >>>> >>>> -- >> >> -- >> Librement, >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > >--- >Liste de diffusion du FRnOG >http://www.frnog.org/ -- Librement, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Conservation log appels opérateurs/presta Voip
Effectivement … Erreur de ma part dans le précédent message il fallait lire : Je sens que l'opérateur va fermer l'incident et renvoyer son client vers le gestionnaire de l'équipement (le presta), même en cas de nouvelles ouverture pour la même problématique Le 3 mars 2019 19:25:33 GMT+01:00, David Ponzone a écrit : >Je comprends plus. >Il fait quoi le presta s’il n’est pas gestionnaire de l’équipement ? >Ptet qu’il sert juste à rien, à part bloquer :) > >> Le 3 mars 2019 à 17:39, admin Obf a écrit : >> >> Dans le cas en tête, l'opérateur a déjà tenté de prouvé qu'il n'est >pas en cause avec l'aide de capture de trames (identique dans les deux >cas, on est sur du one way en provenance presta/client vers opérateur), >mais le presta refuse de l'entendre et part du principe que vu qu'il >n'a pas de trace ou de moyen d'en prendre, le défaut ne peut venir que >du coté opérateur et refuse tout dialogue, se limitant à "passe-plat" >selon ces propres termes >> >> Ce qui provoque un blocage des deux cotés :/ >> Je sens que le presta va fermer l'incident et renvoyer son client >vers le gestionnaire de l'équipement, même en cas de nouvelles >ouverture pour la même problématique >> >> Le 3 mars 2019 16:55:11 GMT+01:00, David Ponzone > a écrit : >> Le 3 mars 2019 à 13:08, admin Obf a écrit : >> >> Bien le bonjour @toutes et tous, >> >> Quelques questionnements me taraudent quant à la conservation des >logs par les différents acteurs dans le cadre de fourniture de VoIP >> >> J'ai vu que l'opérateur se devait de conserver des logs (du moins, en >France) ne serait-ce que pour des raisons légales (réquisition >judiciaire, etc.). >> >> Qu'en est-il des autres parties ? Le presta notamment sur un trunk >SIP doit il aussi conserver des logs ? >> >> Je vois pas pourquoi le prestataire serait concerné. Il ne fait que >configurer/maintenir un équipement qui appartient au client. >> Au pire, il a un devoir de conseil envers le client, qui est >probablement une "obligation" assez floue dans notre domaine. >> >> Pour moi, l’obligation de conserver les logs est sur les opérateurs, >pour pouvoir répondre à la Police/Justice. >> >> Dans le cas de debug entre le presta et l'opérateur, le presta >(gestionnaire d'un oxo par exemple) peut-il se cacher derrière le fait >d'avoir un système ne permettant pas de conserver ne serait-ce que des >journaux d'appels et ainsi mettre la faute sur l'opérateur sans avoir >de quoi le prouver ? (Cdr) >> >> Je cherche dans quelle situation de debug tu voudrais mettre la faute >sur l’opérateur. >> Quand tu debug, c’est qu’à priori tu es dans une démarche >constructive avec l’opérateur pour régler un problème chez le client. >> Mais ne t’inquiète pas, tout PBX moderne (OXO compris) permet de >conserver logs et CDR. >> Tu penses à quoi ? >> Si ton client a passé des appels pour 20k€ dans le mois, et que tu >espères pouvoir dire que c’est la faute de l’opérateur parce que tu >n’as pas les CDR pour prouver le contraire sur le PBX, j’ai peur que tu >lances ton client dans une procédure difficile et perdue d’avance :) >> Liste de diffusion du FRnOG >> http://www.frnog.org/ <http://www.frnog.org/> >> >> -- -- Librement, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Conservation log appels opérateurs/presta Voip
Dans le cas en tête, l'opérateur a déjà tenté de prouvé qu'il n'est pas en cause avec l'aide de capture de trames (identique dans les deux cas, on est sur du one way en provenance presta/client vers opérateur), mais le presta refuse de l'entendre et part du principe que vu qu'il n'a pas de trace ou de moyen d'en prendre, le défaut ne peut venir que du coté opérateur et refuse tout dialogue, se limitant à "passe-plat" selon ces propres termes Ce qui provoque un blocage des deux cotés :/ Je sens que le presta va fermer l'incident et renvoyer son client vers le gestionnaire de l'équipement, même en cas de nouvelles ouverture pour la même problématique Le 3 mars 2019 16:55:11 GMT+01:00, David Ponzone a écrit : >> Le 3 mars 2019 à 13:08, admin Obf a écrit : >> >> Bien le bonjour @toutes et tous, >> >> Quelques questionnements me taraudent quant à la conservation des >logs par les différents acteurs dans le cadre de fourniture de VoIP >> >> J'ai vu que l'opérateur se devait de conserver des logs (du moins, en >France) ne serait-ce que pour des raisons légales (réquisition >judiciaire, etc.). >> >> Qu'en est-il des autres parties ? Le presta notamment sur un trunk >SIP doit il aussi conserver des logs ? > >Je vois pas pourquoi le prestataire serait concerné. Il ne fait que >configurer/maintenir un équipement qui appartient au client. >Au pire, il a un devoir de conseil envers le client, qui est >probablement une "obligation" assez floue dans notre domaine. > >Pour moi, l’obligation de conserver les logs est sur les opérateurs, >pour pouvoir répondre à la Police/Justice. > >> Dans le cas de debug entre le presta et l'opérateur, le presta >(gestionnaire d'un oxo par exemple) peut-il se cacher derrière le fait >d'avoir un système ne permettant pas de conserver ne serait-ce que des >journaux d'appels et ainsi mettre la faute sur l'opérateur sans avoir >de quoi le prouver ? (Cdr) > >Je cherche dans quelle situation de debug tu voudrais mettre la faute >sur l’opérateur. >Quand tu debug, c’est qu’à priori tu es dans une démarche constructive >avec l’opérateur pour régler un problème chez le client. >Mais ne t’inquiète pas, tout PBX moderne (OXO compris) permet de >conserver logs et CDR. >Tu penses à quoi ? >Si ton client a passé des appels pour 20k€ dans le mois, et que tu >espères pouvoir dire que c’est la faute de l’opérateur parce que tu >n’as pas les CDR pour prouver le contraire sur le PBX, j’ai peur que tu >lances ton client dans une procédure difficile et perdue d’avance :) > > >--- >Liste de diffusion du FRnOG >http://www.frnog.org/ -- --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Conservation log appels opérateurs/presta Voip
Bien le bonjour @toutes et tous, Quelques questionnements me taraudent quant à la conservation des logs par les différents acteurs dans le cadre de fourniture de VoIP J'ai vu que l'opérateur se devait de conserver des logs (du moins, en France) ne serait-ce que pour des raisons légales (réquisition judiciaire, etc.). Qu'en est-il des autres parties ? Le presta notamment sur un trunk SIP doit il aussi conserver des logs ? Dans le cas de debug entre le presta et l'opérateur, le presta (gestionnaire d'un oxo par exemple) peut-il se cacher derrière le fait d'avoir un système ne permettant pas de conserver ne serait-ce que des journaux d'appels et ainsi mettre la faute sur l'opérateur sans avoir de quoi le prouver ? (Cdr) -- Librement, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Avis sur bornes DECT Aastra RFP 35 et RFP 32
Hello les gens @job, on a un assez grand parc de mitel pour nos clients avec les combinés 612/632/622 et 650, je dois l'accorder que la gamme 612 n'est pas des plus fiables … La parti provisionnement via dhcp se fait à l'aise une fois qu'on a le coup de patte (sur du cisco) Le reste de la conf en sip se fait également plutôt bien également Pour la partie utilisation en tant que Ted, c.est en très grande partie satisfaisante (gestion de parc avec plusieurs dizaines de bornes ou encore via division par site (le fait qui certains utilisateurs puissent prendre directement leur combiné pour aller du site A vert B sans rien changer est assez pratique ) Niveau version, on est assez hétérogène, avec à la fois des version 1, version 4 ou encore 6 Le 27 novembre 2018 19:23:12 GMT+01:00, Olivier Lange a écrit : >Je suis d'accord avec toi. La partie Java est galère à gérer. Je >préfère >Snom, pour le coup. Et les clients aussi en terme de tarif. Par contre, >Snom pas GAP, mais j'aime pas le GAP, on perds des fonctionnalités, et >du >coup je rale quand mes commerciaux me vende du RF35P avec des gigaset >GP en >combiné... > >Mais sinon, mise à part la fragilité de la gamme 6x2d, et leurs prix, >les >bornes fonctionnent. > >Olivier > >Le mar. 27 nov. 2018 à 19:20, David Ponzone a >écrit : > >> Le seul truc qui énerve vraiment chez Mitel, c’est le provisioning. >> Pour prendre la main dessus par le web, faut lui envoyer ce qu’il >faut en >> DHCP (et je peux te dire que j’y ai passé des moments longs et >pénibles). >> Sinon, faut utiliser leurs outils Java à la con, ce qui me déplait >> fortement. >> Ensuite, tu configures par le web, mais y a pas tout, l’appli Java >reste >> plus complète. Je sais pas si l’invention de Java a été une bonne >chose ou >> pas pour notre monde. >> >> Donc bref, j’en mets que quand c’est derrière un IPBX Mitel, parce >que là, >> c’est automagic (ou presque). >> >> >> >> > Le 27 nov. 2018 à 19:00, Xavier ROCA a écrit : >> > >> > Olivier, on connait bien RTX depuis des années >> > Et l'on accroche pas avec les versions SNOM. >> > >> > David, j'ai bien dit AASTRA car c'est déjà sur site client et en >> quantité, et il veut avoir notre avis si on conserve ou pas... >> > Le client a les moyens donc voir pour un comportement Ecolo ou pas >:) >> > On a cela en labs, d'origine DeTeWe, juste après leur rachat par >AASTRA >> donc ce n'est pas du tout jeune. >> > Et depuis, on a pas pris le temps de suivre les évolutions en >mettant à >> jour et lancer des tests, faudrait aller dépoussiéré le truc :( >> > >> > Donc merci David pour ton retour, si ça juste fonctionne, on va >voire >> pour faire avec, on changera que si le minimum ni est pas. >> > En plus, il y a un parc de gigaset accroché la dessus, la aussi pas >fan >> mais effectivement Stéphane, le client peut voir cela comme du >consommable. >> > >> > Xavier >> > >> > >> > -Message d'origine- >> > De : Oliver varenne >> > Envoyé : mardi 27 novembre 2018 15:31 >> > À : David Ponzone >> > Cc : Kevin CHAILLY | Service Technique >; >> s...@genesix.org; frnog@frnog.org >> > Objet : RE: [FRnOG] [MISC] Avis sur bornes DECT Aastra RFP 35 et >RFP 32 >> > >> > je te propose de passer en privé pour en parler >> > >> > >> > >> > Cordialement, >> > >> > >> > >> > Olivier Varenne >> > Co-gérant, Commercial & Développeur >> > T +33 (0)4 27 04 40 00 | ipconnect.fr >> > >> >> -Message d'origine- >> >> De : David Ponzone Envoyé : mardi 27 >> >> novembre 2018 15:30 À : Oliver varenne Cc >: >> >> Kevin CHAILLY | Service Technique >; >> >> s...@genesix.org; frnog@frnog.org Objet : Re: [FRnOG] [MISC] Avis >sur >> >> bornes DECT Aastra RFP 35 et RFP 32 >> >> >> >> Rien de précis vraiment. >> >> Sauf peut-être que la gamme était trop réduite mais c’est SNOM qui >a >> >> choisi un seul modèle mono-cell je crois, et pas une seule >solution >> >> multi- cell. >> >> Je testerai à l’occase, si ça tient la route au niveau tarifaire >face >> >> à Spectra. >> >>> Le 27 nov. 2018 à 15:06, Oliver varenne >a >> >>> écrit >> >> : >> >>> >> >>> Exactement ils vendent à snom en OEM >> >>> >> >>> Quels echos as-tu eu ? >> >>> >> >>> De notre coté nous les vendons (sous la marque constructeur. On >aime >> >>> pas >> >> l'OEM) depuis 2012 et c'est vraiment un best seller chez nous. >> >>> >> >>> >> >>> Cordialement, >> >>> >> >>> >> >>> >> >>> Olivier Varenne >> >>> Co-gérant, Commercial & Développeur >> >>> T +33 (0)4 27 04 40 00 | ipconnect.fr >> >>> >> -Message d'origine- >> De : David Ponzone Envoyé : mardi 27 >> novembre 2018 15:06 À : Oliver varenne >Cc : >> Kevin CHAILLY | Service Technique >; >> s...@genesix.org; frnog@frnog.org Objet : Re: [FRnOG] [MISC] >Avis >> sur bornes DECT Aastra RFP 35 et RFP 32 >> >> C’est eux qui vendent à SNOM en OEM non ? >> J’ai pas eu que des bons échos mais bon, faut toujours se méfier >du >> bouche à oreille. >> >> > Le 27 nov. 2018 à 14:57,
