Configuration de Liberty Real-Time Communications
La configuration de la fonction Real-Time Communications consiste à mettre à jour du fichier server.xml.
Pourquoi et quand exécuter cette tâche
Pour configurer un serveur Liberty pour l'exécution d'une application activée pour Real-Time Communications, vous devez activer la fonction rtcomm-1.0. Vous pouvez également activer plusieurs autres configurations et options pour travailler avec une application qui utilise la fonction Real-Time Communications.
Procédure
- Pour activer la fonction rtcomm-1.0, ajoutez la déclaration d'élément suivante dans l'élément featureManager de votre fichier
server.xml :
<featureManager> <feature>rtcomm-1.0</feature> </featureManager>
Si vous souhaitez modifier les réglages par défaut, vous devez ajouter la fonction Rtcomm à la configuration du serveur Liberty. Pour ce faire, vous pouvez utiliser l'outil WDT ou bien ajouter manuellement la ligne de configuration suivante au fichier server.xml :
Les paramètres par défaut incluent :<rtcomm/>
- Détails de connexion de courtier MQTT Rtcomm : (hôte : localhost et port 1883)
- Chemin de sujet principal Rtcomm : /rtcomm/
- SSL est désactivé
Remarque : Pour que les paramètres par défaut soient appliqués, un courtier MQTT doit être installé et activé sur la même machine que le serveur Liberty.Si vous souhaitez modifier les paramètres par défaut du courtier MQTT, vous devez éditer le fichier server.xml comme suit :<rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerportname>" />
- Configurez le chemin de sujet Rtcomm. Le chemin rtcommTopicPath
est utilisé avec d'autres noms de sujet Rtcomm. ce chemin de sujet fournit un espace de nom unique afin d'éviter
les collisions avec d'autres développeurs utilisant le même courtier de messages. Pour définir ce chemin,
ajoutez la ligne de configuration suivante au fichier server.xml :
<rtcomm rtcommTopicPath="/rtcomm/"/>
Vous devez transmettre le nom et le chemin que vous avez configurés dans la bibliothèque client rtcomm lors de l'initialisation avec l'adresse du courtier de messages. Le serveur crée le nom de sujet et l'ajoute au chemin du sujet.
Remarque : Le chemin rtcommTopicPath doit être unique pour chaque serveur Liberty quand il existe plusieurs serveurs Liberty configurés pour utiliser le même courtier MQTT, ou bien vous n'aurez pas de moyen de prévoir le comportement. - Vous pouvez configurer le chemin d'abonnement partagé qui est ajouté en préfixe
au chemin rtcommTopicPath. Ce chemin est requis par les courtiers de messages en cas d'utilisation d'abonnements partagés. Pour définir ce chemin,
ajoutez la ligne de configuration suivante au fichier server.xml :
<rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/">
Des abonnements partagés doivent être configurés en cas d'utilisation de files d'attente d'appels. Ces files d'attente sur basées sur les abonnements partagés pour distribuer les messages à l'ensemble des programmes d'écoute de file d'attente. Si, par exemple, plusieurs agents de centre d'assistance sont tous en train d'écouter sur une même file d'attente, les abonnements partagés sont utilisés pour distribuer les appels à un agent à la fois.
Remarque : La prise en charge des abonnements partagés n'est pas la règle chez les courtiers MQTT. La configuration précédente montre comment configurer correctement la fonction rtcomm-1.0 pour une utilisation avec IBM® MessageSight. Reportez-vous à la documentation de votre courtier concernant la configuration des abonnements partagés. - Facultatif : Configurez d'autres options lors de l'utilisation de la fonction Rtcomm.
- Configuration de services de back end avec la fonction Rtcomm
La fonction Rtcomm prend en charge plusieurs services back end, dont notamment :
- Configuration de serveur ICE (Interactive Connectivity Establishment) : Spécifie la ou les URL envoyées et utilisées par des clients Rtcomm WebRTC lors de la négociation de sessions de supports homologues.
- Prise en charge des files d'attente d'appels : Rtcomm peut être configuré pour prendre en charge les files d'attente d'appels partagées, et permet à l'utilisateur de créer une file d'attente d'appels partagée, de nombreux agents pouvant s'abonner à une file d'attente spécifique et répondre aux appels client. Par exemple, vous pouvez appeler un service clients pour un produit spécifique. De nombreux agents peuvent s'abonner à la file d'attente, mais seul un agent est sélectionné pour répondre à chaque appel.
- Passerelle Rtcomm : Ajoute la possibilité de connecter des noeuds finaux SIP avec des noeuds finaux Rtcomm WebRTC pour l'échange de flux audio et vidéo. Pour plus de détails sur la configuration d'une passerelle Rtcomm, voir Configuration d'une passerelle Rtcomm.
- Routage de noeud final alternatif : Spécifie que l'utilisateur souhaite router les nouvelles sessions via un noeud final de remplacement.
- Configuration de serveur ICE (Interactive Connectivity Establishment)
ICE est une technique utilisée dans la mise en réseau d'ordinateurs qui implique des NAT (Network Address Translator, convertisseur d'adresses réseau) dans des applications Internet, tels que le protocole VoIP (voix sur IP), les communications d'égal à égal, la vidéo, la messagerie instantanée et autres multimédias interactifs. Dans ce type d'application, la traversée NAT est une composante importante pour faciliter les communications qui impliquent des hôtes sur des installations de réseau privé, souvent situés derrière des pare-feux.
Le contrôleur de noeud fournit la configuration de serveur ICE comme moyen de notifier les noeuds client Rtcomm des serveurs ICE qu'ils peuvent utiliser lors de la configuration de sessions d'égal à égal avec un autre client. WebRTC repose largement sur des serveurs ICE pour traverser des pare-feux, et quand il s'agit de déploiements de production, il est essentiel d'inclure la prise en charge d'ICE afin de garantir la probabilité la plus élevée possible de connexion aux noeuds finaux.
La configuration de serveur ICE est accessible via une demande de requête de service qui est publiée dans le nom de sujet de connecteur associé à une fonction Rtcomm. Pour plus d'informations sur la requête de service Rtcomm, voir les détails de protocole, GitHub lib.rtcomm.clientjs.
Pour configurer différents types de serveurs ICE, ajoutez la propriété suivante à la ligne de configuration rtcomm configuration de votre fichier server.xml :
<rtcomm> <iceServerURL>stun:example1.hostname.com:8880</iceServerURL> <iceServerURL>stun:example2.hostname.com:8881</iceServerURL> </rtcomm>
- Contrôle d'appel de tiers
Vous pouvez trouver tous les détails de protocole qui définissent les formats de message liés au contrôle d'appels tiers dans le référentiel GitHub. Les composants open source liés à lib.rtcomm.node-red et lib.rtcomm.node sont utilisés pour interagir avec ces services.
- Prise en charge de file d'attente d'appels
Les files d'attente d'appels fournissent une interaction de type round-robin (tourniquet) où de nombreux utilisateurs peuvent s'abonner à une file d'attente et un autre utilisateur peut appeler la file. Un seul des utilisateurs abonnés recevra l'appel. Cette fonction est activée en définissant des files d'attente et en activant les abonnements partagés comme montré précédemment à l'étape deux.
Pour configurer des files d'attente d'appels, configurez le chemin d'abonnement partagé qui est ajouté en préfixe au chemin rtcommTopicPath. Ce chemin est requis par les courtiers de messages en cas d'utilisation d'abonnements partagés. Vous pouvez définir les files callQueues prises en charge en ajoutant les lignes de configuration suivantes au fichier server.xml :<rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/"> <callQueue description="refrigerator" callQueueID="callQueueID2" timeout="500s"></callQueue> </rtcomm>
L'utilisateur peut créer autant de files d'attente d'appels uniques que nécessaire. Si configuré, le chemin d'abonnement partagé + le chemin de la rubrique rtcomm + le nom de la rubrique ("$SharedSubscription/rtcomm//rtcomm/callQueue") est souscrit par les agents pour recevoir des demandes d'appel du serveur.
Les éléments de configuration suivants sont disponibles pour chaque file d'attente :
- Description de configuration : Fournit une description verbale de cette instance de file d'attente d'appels. Cette description verbale est renvoyée dans les réponses aux requêtes de service et peut être utilisée pour mieux informer le client sur la file d'attente.
- callQueueID de configuration : ID noeud final associé au nom de sujet de file d'attente d'appels, c'est-à-dire ID noeud final de destination qu'un appelant utilise pour placer un appel dans une file d'attente spécifique.
- Délai d'attente de configuration : Nombre de secondes écoulées avant l'abandon d'un appel dans une file d'attente.
- Routage de noeud final alternatif
- Spécifie que l'utilisateur souhaite router les nouvelles sessions via un noeud final de remplacement. L'utilisation de cette option permet de s'abonner au nom de sujet alternateEndpointRouting,
par exemple /rtcomm/alternateEndpointRouting, et de router les nouvelles sessions
vers le noeud final approprié. Pour activer cette fonction, ajoutez la ligne de configuration suivante
au fichier server.xml :
<rtcomm alternateEndpointRoutingEnabled="true"/>
- Configuration SSL pour Rtcomm
- Assurez-vous que l'environnement est configuré pour l'utilisation de SSL entre la fonction Rtcomm et le courtier MQTT.
- La référence SSL reference correspond à l'ID de la configuration SSL utilisée pour la connexion au courtier MQTT activé pour SSL.
Remarque : Pour que la fonction Rtcomm utilise SSL, la fonction SSL doit être activée. Pour activer la fonction SSL, ajoutez la configuration suivante au fichier server.xml.<rtcomm sslEnabled="true" sslRef="mySSLConfig" />
Pour plus de détails sur l'attribut de configuration sslRef, voir Liberty : Attributs de configuration SSL.

Nom du fichier : twlp_config_rtcomm.html