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 <jbearel@astelcom.fr mailto:jbearel@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/