Liberty-Echtzeitkommunikation konfigurieren

Das Feature für Echtzeitkommunikation wird durch Aktualisierungen der Datei server.xml konfiguriert.

Informationen zu diesem Vorgang

Wenn Sie einen Liberty-Server für die Ausführung einer Anwendung konfigurieren möchten, die für Echtzeitkommunikation aktiviert ist, müssen Sie das Feature rtcomm-1.0 festlegen. Außerdem können Sie viele andere Konfigurationen und Optionen für die Arbeit mit einer Anwendung, die Echtzeitkommunikation verwendet, aktivieren.

Anmerkung:  Das Feature Rtcomm unterstützt momentan weder Liberty-Verbünde noch -Clustering. Momentan wird nur eine einzelne Liberty-Instanz je rtcommTopicPath unterstützt.

Vorgehensweise

  1. Zum Aktivieren des Features rtcomm-1.0 fügen Sie die folgende Elementdeklaration im Element featureManager in Ihrer Datei server.xml hinzu:
    <featureManager>        <feature>rtcomm-1.0</feature>
    </featureManager> 
    Wenn Sie die Standardeinstellungen ändern möchten, müssen Sie das Feature Rtcomm der Liberty-Serverkonfiguration hinzufügen. Hierfür können Sie entweder WebSphere Developer Tools verwenden oder die folgende Konfigurationszeile manuell in der Datei server.xml hinzufügen:
    <rtcomm/>
    Zu den Standardeinstellungen gehören:
    • Rtcomm-Details der MQTT-Brokerverbindung: (Host: localhost und Port: 1883)
    • Rtcomm-Stammtopicpfad: /rtcomm/
    • SSL ist inaktiviert
    Anmerkung: Ein MQTT-Broker muss auf demselben System installiert und aktiviert sein wie der Liberty-Server, damit die Standardeinstellungen funktionieren.
    Wenn Sie die Standardeinstellungen für den MQTT-Broker ändern möchten, müssen Sie in der Datei server.xml die folgende Änderung vornehmen:
    <rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerportname>" />
  2. Konfigurieren Sie den Rtcomm-Topicpfad. rtcommTopicPath wird mit anderen Rtcomm-Topicnamen verwendet. Dieser Topicpfad gibt einen eindeutigen Namespace an, um Überschneidungen mit anderen Entwicklern, die denselben Nachrichtenbroker verwenden, zu verhindern. Um diesen Pfad festzulegen, fügen Sie die folgende Konfigurationszeile in der Datei server.xml hinzu:
    <rtcomm rtcommTopicPath="/rtcomm/"/>

    Sie müssen den Namen und den Pfad angeben, den Sie zusammen mit der Nachrichtenbrokeradresse in der rtcomm-Clientbibliothek konfiguriert haben. Der Server erstellt den Topicnamen und hängt ihn an den Topicpfad an.

    Anmerkung: Wenn mehrere Liberty-Server für die Verwendung desselben MQTT-Brokers konfiguriert sind, muss rtcommTopicPath für jeden Liberty-Server eindeutig sein, da das Verhalten sonst nicht vorhergesagt werden kann.
  3. Sie können den gemeinsam genutzten Subskriptionspfad, der rtcommTopicPath vorangestellt ist, konfigurieren. Nachrichtenbroker brauchen diesen Pfad, wenn sie gemeinsam genutzte Subskriptionen verwenden. Um diesen Pfad festzulegen, fügen Sie die folgende Konfigurationszeile in der Datei server.xml hinzu:
    <rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/">

    Gemeinsam genutzte Subskriptionen müssen konfiguriert werden, wenn Aufrufwarteschlangen verwendet werden. Aufrufwarteschlangen stützen sich auf gemeinsam genutzten Subskriptionen, um Nachrichten an alle Warteschlangenempfänger zu senden. Wenn beispielsweise mehrere Help-Desk-Agenten für eine einzelne Warteschlange empfangsbereit sind, werden gemeinsam genutzte Subskriptionen verwendet, um die Aufrufe jeweils an einen Agent zu verteilen.

    Anmerkung: Die Unterstützung gemeinsam genutzter Subskriptionen weicht vom MQTT-Brokerstandard ab. Die vorherige Konfiguration zeigt, wie das Feature rtcomm-1.0 ordnungsgemäß eingerichtet wird, damit es mit IBM® MessageSight funktioniert. Weitere Informationen zur Konfiguration gemeinsam genutzter Subskriptionen finden Sie in der Produktdokumentation zu Ihrem Broker.
  4. Optional: Konfigurieren Sie weitere Optionen, wenn Sie das Feature Rtcomm verwenden.
    Back-End-Services mit dem Feature Rtcomm konfigurieren

    Das Feature Rtcomm unterstützt beispielsweise die folgenden Back-End-Services:

    • ICE-Serverkonfiguration (Interactive Connectivity Establishment): Gibt URLs an, die an die Rtcomm-WebRTC-Clients gesendet werden und für das Verhandeln von Peer-Media-Sitzungen verwendet werden.
    • Aufrufwarteschlangenunterstützung: Rtcomm kann konfiguriert werden, um gemeinsam genutzte Aufrufwarteschlangen zu unterstützen, und der Benutzer kann eine gemeinsam genutzte Aufrufwarteschlange erstellen, wobei viele Agenten eine bestimmte Aufrufwarteschlange subskribieren und auf Kundenaufrufe antworten können. Beispielsweise können Sie den Kundendienst für ein bestimmtes Produkt anwählen. Viele Agenten können die Warteschlange subskribieren, aber es wird nur ein einziger Agent ausgewählt, um auf den jeweiligen Aufruf zu antworten.
    • Rtcomm-Gateway: Fügt die Funktion für das Verbinden von SIP- (Session Initiation Protocol) mit Rtcomm-WebRTC-Endpunkten zum Austausch von Audio- und Video-Streams hinzu. Weitere Details zur Konfiguration eines Rtcomm-Gateways finden Sie im Abschnitt Rtcomm-Gateway konfigurieren.
    • Routing an einen alternativen Endpunkt: Gibt an, dass der Benutzer neue Sitzungen an einen alternativen Endpunkt weiterleiten möchte.
    ICE-Serverkonfiguration

    ICE ist eine Technik, die bei der Vernetzung von Computern mit NATs (Network Address Translators) in Internetanwendungen, wie z. B. Voice over Internet Protocol (VoIP), Peer-to-Peer-Kommunikation, Video, Instant Messaging und anderen interaktiven Medien, verwendet wird. In solchen Anwendungen ist NAT-Traversierung eine wichtige Komponente, um Datenübertragungen zu erleichtern, die oft hinter Firewalls befindliche Hosts in privaten Netzinstallationen einbeziehen.

    Node Controller stellt ICE-Serverkonfiguration als einen Weg zur Verfügung, Rtcomm-Clientknoten zu benachrichtigen, welche ICE-Server sie für die Konfiguration von Peer-to-Peer-Sitzungen mit anderen Clients verwenden können. WebRTC hängt stark von ICE-Servern ab, um Firewalls umgehen zu können. Bei Implementierungen in Produktionsumgebungen ist es jedoch kritisch, Unterstützung für ICE einzuschließen, um die größtmögliche Wahrscheinlichkeit für die erfolgreiche Verbindung der Endpunkte sicherzustellen.

    Der Zugriff auf die ICE-Serverkonfiguration erfolgt über eine Serviceabfrageanforderung, die in dem mit einem Rtcomm-Feature verbundenen Verbindungstopicnamen hinzugefügt wird. Weitere Informationen zur Rtcomm-Serviceabfrage finden Sie in den Protokolldetails unter GitHub lib.rtcomm.clientjs.

    Um mehrere Typen von ICE-Servern zu konfigurieren, fügen Sie der Konfigurationszeile rtcomm in Ihrer Datei server.xml die folgende Eigenschaft hinzu:

    <rtcomm>
        		  <iceServerURL>stun:example1.hostname.com:8880</iceServerURL>
        		  <iceServerURL>stun:example2.hostname.com:8881</iceServerURL>
    </rtcomm>
    Third-Party-Aufrufsteuerung

    Im GitHub-Repository finden Sie alle Protokolldetails, die die zur Third-Party-Aufrufsteuerung gehörigen Nachrichtenformate definieren. Die zugehörigen Open-Source-Komponenten lib.rtcomm.node-red und lib.rtcomm.node werden für die Interaktion mit diesen Services verwendet.

    Unterstützung von Aufrufwarteschlangen

    Aufrufwarteschlangen interagieren im Stil eines Rundlauf-Verfahrens, wobei eine Warteschlange von vielen Benutzern subskribiert und von einem anderen Benutzer aufgerufen werden kann. Nur einer der subskribierten Benutzer empfängt den Aufruf. Dieses Feature wird, wie im vorherigen Schritt 2 gezeigt, durch die Definition von Warteschlangen und die Aktivierung gemeinsam genutzter Subskriptionen aktiviert.

    Um Aufrufwarteschlangen zu konfigurieren, konfigurieren Sie den gemeinsam genutzten Subskriptionspfad, der rtcommTopicPath vorangestellt ist. Nachrichtenbroker erfordern diesen Pfad, wenn sie gemeinsam genutzte Subskriptionen verwenden. Sie können die unterstützen callQueues (Aufrufwarteschlangen) definieren, indem Sie die folgenden Konfigurationszeilen in der Datei server.xml hinzufügen:
    <rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/">
        <callQueue description="refrigerator" callQueueID="callQueueID2" timeout="500s"></callQueue>
    </rtcomm>

    Der Benutzer kann so viele eindeutige Aufrufwarteschlangen erstellen wie nötig. Nach der Konfiguration wird der gemeinsam genutzte Subskriptionspfad, einschließlich Rtcomm-Topicpfad und Topicname ("$SharedSubscription/rtcomm//rtcomm/callQueue") von Agenten subskribiert, um Aufrufanforderungen vom Server zu erhalten.

    Die folgenden Konfigurationselemente sind für jede Warteschlange verfügbar:

    • Beschreibung konfigurieren: Gibt die Beschreibung dieser Instanz der Aufrufwarteschlange an. Diese Beschreibung wird in Serviceabfrageantworten zurückgegeben und kann verwendet werden, um den Client besser über die Warteschlange zu informieren.
    • Aufrufwarteschlangen-ID konfigurieren: Die dem Topicnamen der Aufrufwarteschlange zugeordnete Endpunkt-ID, die die Zielendpunkt-ID ist, die ein Aufrufender verwendet, um einen Aufruf an eine bestimmte Warteschlange abzusetzen.
    • Zeitlimit konfigurieren: Gibt an, wie lange (in Sekunden) gewartet wird, bis ein in einer Warteschlange wartender Aufruf beendet wird.
    Routing an einen alternativen Endpunkt
    Gibt an, dass der Benutzer neue Sitzungen an einen alternativen Endpunkt weiterleiten möchte. Durch Verwenden dieser Option können Sie den Topicnamen alternateEndpointRouting wie /rtcomm/alternateEndpointRouting subskribieren und neue Sitzungen an den ordnungsgemäßen Endpunkt weiterleiten. Um diese Funktion zu aktivieren, fügen Sie in der Datei server.xml die folgende Konfigurationszeile hinzu:
    <rtcomm alternateEndpointRoutingEnabled="true"/>
    SSL-Konfiguration für Rtcomm
    Stellen Sie sicher, dass die Umgebung für die Verwendung von SSL zwischen dem Feature Rtcomm und dem MQTT-Broker konfiguriert ist.
    Die SSL-Referenz ist die ID der SSL-Konfiguration, die verwendet wird, um eine Verbindung zum SSL-fähigen MQTT-Broker herzustellen.
    Anmerkung: Damit das Feature Rtcomm SSL verwenden kann, muss das Feature SSL aktiviert sein. Um das Feature SSL zu aktivieren, fügen Sie in der Datei server.xml die folgende Konfiguration hinzu.
    <rtcomm sslEnabled="true" sslRef="mySSLConfig" />

    Weitere Details zum Konfigurationsattribut sslRef finden Sie im Abschnitt Liberty: SSL-Konfigurationsattribute.


Symbol das den Typ des Artikels anzeigt. Taskartikel

Dateiname: twlp_config_rtcomm.html