Le 29/01/2013 22:48, SD76 a écrit :
Bonjour,
Bonsoir,
Pour quel(s) raison(s) est-il préférable de compiler les sources
plutôt de d'utiliser un gestionnaire de paquet?
Autant les mainteneurs des paquets font un super boulot autant tu n'as
pas la maitrise de la version et des patchs qui sont dans cette version.
-Pour un POC ça ne pose aucun problème, j'aurais même tendance à dire
que c'est la bonne méthode par contre en production et surtout en centre
d'appel il y a intérêt à savoir que l'usage de telle fonction avec telle
autre en simultané provoque un deadlock du chan_sip (au hasard) dans la
version x.y sans le patch zzz par exemple.
Et ça, ce n'est pas pas dans l'apt-cache show asterisk mais dans la
validation de la version déployée.
-Les gestionnaires de paquets en mettent partout dans le fs certes en
respectant la nomenclature de l'arborescence mais du coup c'est pas
simple pour installer une xème version en parallèle et faire une mise en
production ou un rollback par changement d'un lien symbolique.
-Faire tourner le service avec un autre compte que root c'est bien, les
API permettent l'exécution de commandes systèmes et asterisk peut
parfois se permettre un petit segfault (et dans ces cas là, il faut
mieux que ce soit le système qui inflige la correction que le contraire)
-Pour passer un patch c'est juste l'application du patch et/ou la
modification des sources + trois lignes de commandes pour mettre en service.
-Un apt-get upgrade hasardeux peut avoir des conséquences "inattendus",
dans le meilleurs des cas, un simple contournement du problème dans le
dialplan fera le job, dans le pire des cas, le comportement des API de
type AMI ou AGI auront un comportement différents et les softs de CTI
auront un comportement aléatoire.
En fait on pourrait faire le parallèle avec un hébergeur qui customize
sa suite Apache/PHP ou encore MySQL pour que ça tienne la charge et une
PME qui utilise les paquets standards avec le 1er CMS qui rend le
service, les deux font le job mais pas à la même échelle. Il n'y a pas
*la* solution mais des solutions adaptées aux besoins.
Je vais me permettre un *gros* raccourci qui n'engage que moi (aïe! pas
taper !!!): pour une TPE lambda => centrex/cloud xyz (mais pas avec des
Thomson !!!), pour une TPE++, POC, Démo... => le paquet asterisk et pour
le reste => faut faire autrement.
La question d'origine comportait les mots "PME", "centre d'appel
multicanal", ça doit donc faire partie "du reste".
Merci.
De rien ;-)
Jérôme.
Le 29 janvier 2013 16:57, Jérôme BEAREL <jbea...@astelcom.fr
<mailto:jbea...@astelcom.fr>> a écrit :
Bonjour,
Pour reprendre les différents post, voici un petit retour
d'expérience:
Concernant les supports des constructeurs, les terminaux SIP sont
souvent utilisés "à toutes les sauces" sur des environnements très
variés même si Asterisk reste une référence dans le domaine: les
constructeurs ont un support qui est généralement très "light"
hors de leurs solutions "full propriétaire".
Pas la peine de leur faire une demande par téléphone, c'est
toujours par e-mail et sans trop de réactivité.
Nous, on c'est fait une raison et on ne les appelle plus, mare de
faire le debug à leur place. S'ils faisaient du libre encore, on
pourrait participer mais là quand même... ;-)
Dans ces conditions, reste la qualification des matériels "by
yourself" ;-)
C'est ce qu'on a fait avec Aastra, Cisco SMB (ex Linksys), Cisco
(en cours), Snom, Polycom (plus kirk en DECT) et Panasonic
Possibilité d'avoir des conditions NFR chez Cisco, Snom et Polycom
(Kirk) si il y a une relation de type revendeur avec le
constructeur. Pas chez les autres à ma connaissance.
Au final on tourne avec des terminaux Aastra et des "pieuvres"
Polycom dans 99% des cas, du Panasonic en poste DECT monoborne
d'appoint.
Le choix est fait pour les raisons suivantes: rapport qualité/prix
(stable, robuste pour un prix correct), fonctionnalité et
ergonomie utilisateur, design et enfin possibilité de
développement simple d'application par échange de XML sur HTTP.
Pour les pieuvres, c'est un peu différents c'est la qualité
acoustique qui a été privilégiée.
Juste un bémol sur le plexiglas de l'écran des Aastra qui ne
supporte pas bien les utilisateurs énervés qui raccrochent le
combiné en "loupant" l'emplacement de celui-ci. Ca fait rapidement
une belle étoile.
Concernant le choix Asterisk/Freeswitch, il y a pas mal de
discussion sur le sujet qui tournent souvent à la polémique.
Asterisk ayant une antériorité plus grande, on trouve plus de
solutions et/ou logiciels autour d'Asterisk.
Les deux produits fonctionnent plutôt bien, l'historique veut que
nous ayons plus d'expérience sur Asterisk et nous n'allons pas
casser tous nos systèmes juste pour le fun "de passer sur une
autre solution qui aujourd'hui ne nous apporterait pas de
fonctionnalités techniques et/ou métiers supplémentaires".
Dans tous les cas, je déconseille le mode "[apt, whatever] install
asterisk" qui est parfait pour un POC mais pas pour la production.
Une installation bien pensée et faite en installant depuis les
sources fonctionne. Privilégier une LTS ou une version qui a été
éprouvée en validation.
Attention aux aspects IP de "VoIP", c'est pas toujours trivial
mais avec de la méthode c'est faisable dans quasi tous les cas (si
tant est que le LAN soit propre...).
Actuellement on a env. 70 serveurs en production sans compter les
installations faites de droite et de gauche pour des besoins
ponctuels. Certain de ces serveurs gèrent plusieurs milions
d'appels par an. Donc oui on a "plus que tenté" l'expérience et ça
fonctionne.
En fonction de la criticité de la solution, il faudra voir pour la
redondance et le mode de connexion vers l'opérateur (T2/IP, Carte
PCI dans le serveur / Gateway externe ...).
Concernant la partie centrex, c'est un choix de "stratégie", pour
une petite structure ou une structure à forte répartition
géographique ça peu être valable, pour un centre d'appel j'ai des
doutes ou alors un "centrex privé".
Et si on parlait cloud, saas ... ok je sors ;-)
Concernant la partie centre d'appel, Asterisk ne fournie en
standard que l'ACD pour les appels entrants. Pour la partie
sortant, il faudra faire une peu de dev et/ou utiliser des
solutions logicielles complémentaires.
Idem sur sur la partie multicanal, j'imagine que c'est pour gérer
les interactions des agents avec téléphone, fax, e-mail, réseau
sociaux... Là encore il faut du soft.
Un centre d'appel ca ce pilote, re-idem, il faudra aussi envisager
les aspects "supervision" et "statistique".
Actuellement, des éditeurs de solution centre d'appels embarque un
asterisk "boite noir" pour assurer la fonction "media gateway" du
centre d'appel et qui se connecte sur la téléphonie existante de
l'entreprise.
Dans tous les cas, Asterisk est un bon produit riche en
fonctionnalités et avec de bonnes API mais ce n'est que le socle
technique.
Bonne journée,
Jérôme.
Le 24/01/2013 11:15, fatiha boudj a écrit :
Bonjour
Je recherche des retours d'experience en PME .
Existe-t-il des societes qui ont tenté la telephonie du monde
libre de type "asterix" avec une solution centre d'appel
multicanal ?
merci pour vos retour
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
