Cela dépend beaucoup du PBX utilisé - j'ai travaillé avec les serveurs Avaya et CallMedia. Ces deux sociétés ont fourni un petit client de bureau et une DLL qui peut être référencée depuis le code.
Le plus gros problème consiste à informer la page Web lorsque l'application de la barre d'état système reçoit un événement. Lancer un navigateur peut être lent et ne constitue pas une bonne expérience pour le traitement des appels. Mieux vaut garder un navigateur ouvert et recevoir des événements ..
L'entreprise où je travaillais utilisé une technologie assez désuet de sorte qu'ils avaient:
PBX
- (XML) - Client PBX System Tray - (COM) - Notre propre application de bureau - (COM) - Un ActiveXControl intégré dans la page - (Javascript) - Le cadre du site qui a géré l'événement le cas échéant
Comme vous pouvez le voir, il était assez long et alambiquée - Une approche plus élégante serait d'avoir une application silverlight/similaire intégrée sur la page qui reçoit des événements de la barre d'état client (via un service web ou similaire?)
Vous devez également répondre à la question suivante: a) plusieurs pages sont ouvertes - tous les événements sont-ils traités? et b) l'échange de PBX à une date ultérieure ne devrait pas nécessiter une réécriture complète. En quittant cette entreprise, nous implémentions un mécanisme dans lequel notre application recevait les messages du PBX directement via XML. Silverlight contrôle sur toutes/toutes les pages Web enregistrées avec notre application de bureau via 2-Way WCF. Nous avons ensuite eu notre application de bureau envoyer les événements appropriés à la page appropriée.
Autres choses à prendre en compte: Allez-vous gérer le canal mixte? Peut-on gérer un e-mail bloquant un événement d'appel entrant? Si c'est le cas, vous avez besoin d'une sorte de communication bidirectionnelle pour dire "Rejeter l'appel ...". Vous devez également faire attention à l'état dans lequel se trouve le poste de l'agent. Si vous passez à l'état "disponible" avant de terminer l'enregistrement des données, vous pouvez éventuellement naviguer avant de tout enregistrer. En outre, d'après mon expérience, les agents sont vraiment heureux d'appuyer sur les boutons du poste plutôt que sur votre application - vous devez donc gérer les changements d'état inattendus. Envisagez également de transférer des appels - la plupart des PBX modernes permettent qu'un transfert d'appel se produise de telle sorte qu'un identifiant soit associé à l'appel - donc s'il s'agit d'un transfert interne, l'écran des destinataires peut afficher toutes les notes d'appel/etc.
Je peux fournir plus d'informations si vous pouvez clarifier ce que PBX/etc.vous utilisez et quels événements vous avez besoin pour gérer
Events Je vous recommande gérer au minimum: sonnerie, Appel répondu, Appel TOMBÉ Transféré Appel
et vous devriez être en mesure d'augmenter: Décroché, Lieu d'appel, Abandon de l'appel, Appel de transfert (transferts chauds et froids, le cas échéant avec des données si elle est interne)
Bien sûr, cela peut être surpuissant pour votre solution :)J'ai oublié d'ajouter que notre solution traitait aussi la connexion des agents sur le poste lorsqu'ils se connectaient à l'application web - Cela a donné une très bonne expérience utilisateur mais nécessitait de gérer toutes les variables d'ouverture de session/fermeture de session. ainsi que la maintenance d'une table de consultation de l'utilisateur-> extension #
Merci pour cette réponse. Le problème est que nous voulons soutenir les systèmes PBX de nos clients, quels qu'ils soient. Peut-être une meilleure façon de le faire est de demander "Quels systèmes téléphoniques fournissent une application qui peut ouvrir une page Web lorsqu'un appel est reçu?" – rjmunro
Pour autant que je sache, il n'y a pas de moyen de PBX croisé cohérent pour y parvenir. De nombreux systèmes ne transmettent pas de messages TAPI/TSAPI au PC client (certains ne passent même pas au poste de client en utilisant leur propre mécanisme interne). En tant que tel, il n'y a pas d'événements génériques à intercepter. Vous devez également demander ce qui se passe si le client utilise Skype/Software VOIP. Si vous trouvez une réponse, je serais intéressé de savoir comment vous l'avez fait, mais je pense que vous serez confronté à une solution très compliquée si vous pouvez en faire fonctionner. – Basic
Bien sûr, vous POUVEZ écrire une application de barre d'état générique qui peut gérer plusieurs PBX et ajouter un support pour chaque PBX en mode modulaire - vous obtiendrez alors un ensemble standard d'événements dans votre application et vous pouvez commencer petit et étendre comme Champs obligatoires. Un autre problème avec votre approche est la gestion des événements qui ne correspondent pas à une interface commune - Ainsi, certains PBX enverront un "Appel Rendu", d'autres enverront un "Appel Offert", etc ... Certains incluent Caller Id, certains aussi avoir IVR/temps dans les informations de la file d'attente intégré. Vous pouvez probablement retirer les données que vous voulez, mais encore une fois, il peut être désordonné – Basic