Depuis que FREE à réceptionné mon dossier d'inscription le 29/08/03, je n'
ai aucune information de leur part autre que le suivi de ma commande qui
semble bloquée depuis la date ci-dessus sur les étapes :
4 - votre ligne est en cours de construction (depuis le 01/09/03)
5 - votre Freebox est en cours d'envoi (depuis le 01/09/03)
Début octobre m'inquiétant de ne pas avoir d'autres informations de leur
part, j'ai adressé des courriels, toujours sans réponse a ce jour ?
J'ai éssayé de les contacter par téléphone à 3 reprises.
J'ai abandonné car 0,34 euro la minute, avec pour toute réponse une attente
de -20minutes avant d'être pris en charge, moi j'appelle cela une
escroquerie.
Free ne respectant pas ses engagements de délai (entre 10jours et 3 semaines
maximum), j'ai adressé le 07/10/2003 une nouvelle lettre recommandée pour
annuler mon inscription.
A ce jour (16/10/2003), soit 45 jours après mon inscription, toujours
aucune nouvelle de leur part ?
Devant le peu de sérieux et le manque de communication que démontre FREE
vis à vis de ses clients, Je souhaite à tous les Freenautes de ne jamais
tomber en panne avec leurs modems, car là a mon avis, il y aura galère.
OK tout cela me parait bien. La "valise", c'est bien juste un modem, un filtre et un téléphone dessus ?
Bingo, dans la mesure où les chipsets DSL sont interopérables depuis quelques années déjà, la malette de test IP/ADSL convient également aux tests SAV dégroupage.
En gros, l'idée était donc de se servir des ressources actuellement existantes (car cela ne sert à rien de réinventer la roue et de mettre en place des nouveaux process qui vont faire rien qu'à destabiliser les habitudes des équipes terrains de FT, car comment dire, y'a une relative inertie face aux changements radicaux dans cette honorable maison, C'est pas trop gentil ça, mais je suis conscient que l'on peut donner
cette impression. Pour le vécu "vrai", nous avons des "agents des lignes" qui se sont formés an quelques mois/1 ou 2 années à la micro communicante (ie connexion internet sur un PC ou Mac), installation adsl, configuration du PC client, et dépannage du tout. Bien entendu, nous ne sommes pas à 100% de compétence, mais ces techniciens sont aussi bien capables de dépanner la ligne "en haut du poteau", que la connexion simple sur lePC du client. De cette manière, dans pas mal de cas, un seul intervenant suffit. Donc à côté, nous avons une équipe de soutien technique (c'est la mienne et j'en suis fier) qui les aide, les forme (nous débutons la semaine prochaine un cycle annuel de formation/recyclage), et réalise les interventions plus complexes (LAN, VPN, etc ...), ainsi que la maintenance associée (y compris l'analyse approfondie du protocole RNIS, et un (petit) brin d'analyse IP et TCP sur le LAN du client). Des points auquels nous ne touchons pas (chacun son métier) : Linux en général. Les serveurs Windows en environnement RNIS.
donc
surtout ne pas chercher à remettre en cause ce qui commence à marcher, mais plus judicieux de chercher à se baser sur l'existant pour l'améliorer), à savoir la fameuse malette de test (une malette contenant un poste téléphonique FV, un Alcatel STH, un filtre maitre et une prise sur laquelle on branche une rallonge qu'on vient poser directement sur la règlette d'abonné au niveau du répartiteur, shuntant ainsi la paire d'abonné et "simulant" ainsi une liaison de boucle locale).
Si la tonalité téléphonique est obtenue, et si le téléphone sonne lorsqu'on compose le numéro de l'abonné, la construction est OK sur la partie basses-fréquences.
Si la synchro du STH s'établit, la continuité métallique est établie elle-aussi, reste plus qu'à déterminer si la construction est correcte. Pour cela, le technicien FT appelle la plateforme de supervision qu'on a montée [*] à partir des logs des DSLAMs Free, compose le ND de la ligne à qualifier, et une zolie voix (ça aussi, marque de fabrique maison, on aime bien mettre des voix sexy dans les robots de test, ça rend la procédure plus humaine) annonce si la ligne est synchronisée ou non (donc OK = cela arrive bien sur un DSLAM Free au bon endroit, NOK = cela arrive ailleurs que sur un DSLAM Free, ou cela n'arrive pas sur le bon plot de renvoi), avec le taux d'affaiblissement mesuré (ie comme la BL simulée ne fait que quelques dizaines de m, un taux d'affaiblissement faible signifie que tout est OK dans le plan de constitution, si ça dépasse les 20 dB, ça signifie que la paire physiquement mesurée ne correspond pas à celle qui est renvoyée sur le DSLAM, donc erreur de câblage).
Ledit test prend 2m30 tout compris. Amha, c'est trop pour être généralisé en production pour vérifier systématiquement les paires produites dont l'asymptote pour le taux de réussite est aux alentours de 98%, mais largement acceptable pour le SAV. Ceci étant dit, les erreurs de câblages étant mécaniquement plus nombreuses sur les répartiteurs multimodules (en raison du nombre de renvois, et donc de jarretières, jusqu'à 7) que sur les monomodules (à ce sujet, toi qui est un peu plus au fait de l'agencement local, sur Angers, c'est du quasiment du monomodule, non ?), a priori, sauf à tout câbler de travers, le recours au SVI restera marginal au regard du nombre de lignes à produire.
Oui bien sûr, c'est mono module chez nous.
Didier.
Selon Didier dans l'article <bnjt6l$bu0$1@news-reader2.wanadoo.fr> :
OK tout cela me parait bien. La "valise", c'est bien juste un modem, un
filtre et un téléphone dessus ?
Bingo, dans la mesure où les chipsets DSL sont interopérables depuis
quelques années déjà, la malette de test IP/ADSL convient également aux
tests SAV dégroupage.
En gros, l'idée était donc de se servir des ressources actuellement
existantes (car cela ne sert à rien de réinventer la roue et de mettre
en place des nouveaux process qui vont faire rien qu'à destabiliser les
habitudes des équipes terrains de FT, car comment dire, y'a une relative
inertie face aux changements radicaux dans cette honorable maison,
C'est pas trop gentil ça, mais je suis conscient que l'on peut donner
cette impression.
Pour le vécu "vrai", nous avons des "agents des lignes" qui se sont
formés an quelques mois/1 ou 2 années à la micro communicante (ie
connexion internet sur un PC ou Mac), installation adsl, configuration
du PC client, et dépannage du tout. Bien entendu, nous ne sommes pas à
100% de compétence, mais ces techniciens sont aussi bien capables de
dépanner la ligne "en haut du poteau", que la connexion simple sur lePC
du client. De cette manière, dans pas mal de cas, un seul intervenant
suffit.
Donc à côté, nous avons une équipe de soutien technique (c'est la mienne
et j'en suis fier) qui les aide, les forme (nous débutons la semaine
prochaine un cycle annuel de formation/recyclage), et réalise les
interventions plus complexes (LAN, VPN, etc ...), ainsi que la
maintenance associée (y compris l'analyse approfondie du protocole RNIS,
et un (petit) brin d'analyse IP et TCP sur le LAN du client).
Des points auquels nous ne touchons pas (chacun son métier) :
Linux en général.
Les serveurs Windows en environnement RNIS.
donc
surtout ne pas chercher à remettre en cause ce qui commence à marcher,
mais plus judicieux de chercher à se baser sur l'existant pour
l'améliorer), à savoir la fameuse malette de test (une malette contenant
un poste téléphonique FV, un Alcatel STH, un filtre maitre et une prise
sur laquelle on branche une rallonge qu'on vient poser directement sur
la règlette d'abonné au niveau du répartiteur, shuntant ainsi la paire
d'abonné et "simulant" ainsi une liaison de boucle locale).
Si la tonalité téléphonique est obtenue, et si le téléphone sonne
lorsqu'on compose le numéro de l'abonné, la construction est OK sur la
partie basses-fréquences.
Si la synchro du STH s'établit, la continuité métallique est établie
elle-aussi, reste plus qu'à déterminer si la construction est correcte.
Pour cela, le technicien FT appelle la plateforme de supervision qu'on a
montée [*] à partir des logs des DSLAMs Free, compose le ND de la ligne
à qualifier, et une zolie voix (ça aussi, marque de fabrique maison, on
aime bien mettre des voix sexy dans les robots de test, ça rend la
procédure plus humaine) annonce si la ligne est synchronisée ou non
(donc OK = cela arrive bien sur un DSLAM Free au bon endroit, NOK = cela
arrive ailleurs que sur un DSLAM Free, ou cela n'arrive pas sur le bon
plot de renvoi), avec le taux d'affaiblissement mesuré (ie comme la BL
simulée ne fait que quelques dizaines de m, un taux d'affaiblissement
faible signifie que tout est OK dans le plan de constitution, si ça
dépasse les 20 dB, ça signifie que la paire physiquement mesurée ne
correspond pas à celle qui est renvoyée sur le DSLAM, donc erreur de
câblage).
Ledit test prend 2m30 tout compris. Amha, c'est trop pour être
généralisé en production pour vérifier systématiquement les paires
produites dont l'asymptote pour le taux de réussite est aux alentours de
98%, mais largement acceptable pour le SAV. Ceci étant dit, les erreurs
de câblages étant mécaniquement plus nombreuses sur les répartiteurs
multimodules (en raison du nombre de renvois, et donc de jarretières,
jusqu'à 7) que sur les monomodules (à ce sujet, toi qui est un peu plus
au fait de l'agencement local, sur Angers, c'est du quasiment du
monomodule, non ?), a priori, sauf à tout câbler de travers, le recours
au SVI restera marginal au regard du nombre de lignes à produire.
OK tout cela me parait bien. La "valise", c'est bien juste un modem, un filtre et un téléphone dessus ?
Bingo, dans la mesure où les chipsets DSL sont interopérables depuis quelques années déjà, la malette de test IP/ADSL convient également aux tests SAV dégroupage.
En gros, l'idée était donc de se servir des ressources actuellement existantes (car cela ne sert à rien de réinventer la roue et de mettre en place des nouveaux process qui vont faire rien qu'à destabiliser les habitudes des équipes terrains de FT, car comment dire, y'a une relative inertie face aux changements radicaux dans cette honorable maison, C'est pas trop gentil ça, mais je suis conscient que l'on peut donner
cette impression. Pour le vécu "vrai", nous avons des "agents des lignes" qui se sont formés an quelques mois/1 ou 2 années à la micro communicante (ie connexion internet sur un PC ou Mac), installation adsl, configuration du PC client, et dépannage du tout. Bien entendu, nous ne sommes pas à 100% de compétence, mais ces techniciens sont aussi bien capables de dépanner la ligne "en haut du poteau", que la connexion simple sur lePC du client. De cette manière, dans pas mal de cas, un seul intervenant suffit. Donc à côté, nous avons une équipe de soutien technique (c'est la mienne et j'en suis fier) qui les aide, les forme (nous débutons la semaine prochaine un cycle annuel de formation/recyclage), et réalise les interventions plus complexes (LAN, VPN, etc ...), ainsi que la maintenance associée (y compris l'analyse approfondie du protocole RNIS, et un (petit) brin d'analyse IP et TCP sur le LAN du client). Des points auquels nous ne touchons pas (chacun son métier) : Linux en général. Les serveurs Windows en environnement RNIS.
donc
surtout ne pas chercher à remettre en cause ce qui commence à marcher, mais plus judicieux de chercher à se baser sur l'existant pour l'améliorer), à savoir la fameuse malette de test (une malette contenant un poste téléphonique FV, un Alcatel STH, un filtre maitre et une prise sur laquelle on branche une rallonge qu'on vient poser directement sur la règlette d'abonné au niveau du répartiteur, shuntant ainsi la paire d'abonné et "simulant" ainsi une liaison de boucle locale).
Si la tonalité téléphonique est obtenue, et si le téléphone sonne lorsqu'on compose le numéro de l'abonné, la construction est OK sur la partie basses-fréquences.
Si la synchro du STH s'établit, la continuité métallique est établie elle-aussi, reste plus qu'à déterminer si la construction est correcte. Pour cela, le technicien FT appelle la plateforme de supervision qu'on a montée [*] à partir des logs des DSLAMs Free, compose le ND de la ligne à qualifier, et une zolie voix (ça aussi, marque de fabrique maison, on aime bien mettre des voix sexy dans les robots de test, ça rend la procédure plus humaine) annonce si la ligne est synchronisée ou non (donc OK = cela arrive bien sur un DSLAM Free au bon endroit, NOK = cela arrive ailleurs que sur un DSLAM Free, ou cela n'arrive pas sur le bon plot de renvoi), avec le taux d'affaiblissement mesuré (ie comme la BL simulée ne fait que quelques dizaines de m, un taux d'affaiblissement faible signifie que tout est OK dans le plan de constitution, si ça dépasse les 20 dB, ça signifie que la paire physiquement mesurée ne correspond pas à celle qui est renvoyée sur le DSLAM, donc erreur de câblage).
Ledit test prend 2m30 tout compris. Amha, c'est trop pour être généralisé en production pour vérifier systématiquement les paires produites dont l'asymptote pour le taux de réussite est aux alentours de 98%, mais largement acceptable pour le SAV. Ceci étant dit, les erreurs de câblages étant mécaniquement plus nombreuses sur les répartiteurs multimodules (en raison du nombre de renvois, et donc de jarretières, jusqu'à 7) que sur les monomodules (à ce sujet, toi qui est un peu plus au fait de l'agencement local, sur Angers, c'est du quasiment du monomodule, non ?), a priori, sauf à tout câbler de travers, le recours au SVI restera marginal au regard du nombre de lignes à produire.
