Configuración de comunicaciones en tiempo real de Liberty
La configuración de la característica de comunicaciones en tiempo real consta de actualizaciones en el archivo server.xml.
Acerca de esta tarea
Para configurar un servidor Liberty para ejecutar una aplicación que está habilitada para las comunicaciones en tiempo real, debe establecer la característica rtcomm-1.0. También puede habilitar otras configuraciones y opciones distintas para que funcionen con una aplicación que utiliza las comunicaciones en tiempo real.
Procedimiento
- Para habilitar la característica rtcomm-1.0,
añada la declaración de elemento siguiente dentro del elemento
featureManager en el archivo
server.xml:
<featureManager> <feature>rtcomm-1.0</feature> </featureManager>
Si desea modificar los valores predeterminados, tendrá que añadir la característica Rtcomm a la configuración del servidor Liberty. Para ello, puede utilizar la herramienta WDT o añadir manualmente la línea de configuración siguiente al archivo server.xml:
Los valores predeterminados incluyen:<rtcomm/>
- Detalles de conexión de intermediario MQTT Rtcomm: (host: localhost y puerto: 1883)
- Vía de acceso a temas raíces Rtcomm: /rtcomm/
- SSL está inhabilitado
Nota: Para que funcionen los valores predeterminados, debe estar instalado y habilitado un intermediario MQTT en la misma máquina que el servidor Liberty.Si desea cambiar los valores predeterminados para el intermediario MQTT, tendrá que editar el archivo server.xml con lo siguiente:<rtcomm messageServerHost="<nombre_host_intermediario>" messageServerPort="<nombre_puerto_intermediario>" />
- Configure la vía de acceso a temas Rtcomm. rtcommTopicPath
se utiliza con otros nombres de tema Rtcomm. Esta vía de acceso a
temas proporciona un espacio de nombre exclusivo para evitar
conflictos con otros desarrolladores que utilizan el mismo
intermediario de mensajes. Para establecer esta vía de acceso, añada
la línea de configuración siguiente al archivo
server.xml:
<rtcomm rtcommTopicPath="/rtcomm/"/>
Debe pasar el nombre y la vía de acceso que ha configurado en la biblioteca de cliente rtcomm en la inicialización junto con la dirección del intermediario de mensajes. El servidor crea el nombre de tema y lo añade a la vía de acceso a temas.
Nota: rtcommTopicPath debe ser exclusivo para cada servidor Liberty, siempre que se hayan configurado varios servidores Liberty para utilizar el mismo intermediario MQTT, de lo contrario, no hay ninguna forma de predecir el comportamiento. - Puede configurar la vía de acceso de suscripción compartida que
se añade como prefijo a rtcommTopicPath. Los
intermediarios de mensajes requieren esta vía de acceso cuando
utilizan suscripciones compartidas. Para establecer esta vía de
acceso, añada la línea de configuración siguiente al archivo
server.xml:
<rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/">
Las suscripciones compartidas se deben configurar al utilizar colas de llamadas. Las colas de llamadas se basan en suscripciones para distribuir mensajes en todos los escuchas de cola. Por ejemplo, si varios agentes del centro de atención al cliente están todos escuchando en una sola cola, las suscripciones compartidas se utilizan para distribuir llamadas a un agente a la vez.
Nota: El soporte de suscripción compartida no es un estándar en intermediarios MQTT. La configuración anterior muestra cómo se configura correctamente la característica rtcomm-1.0 para que funcione con IBM® MessageSight. Consulte la documentación del producto del intermediario con respecto a la configuración de suscripciones compartidas. - Opcional: configure más opciones al utilizar la
característica Rtcomm.
- Configuración de servicios de fondo con la característica Rtcomm
La característica Rtcomm soporta un número de servicios de fondo que incluyen lo siguiente:
- Configuración del servidor ICE (Interactive Connectivity Establishment): especifica los URL que se envían a y que son utilizados por los clientes WebRTC de Rtcomm al negociar sesiones de medios de igual.
- Soporte de cola de llamadas: Rtcomm se puede configurar para soportar colas de llamadas compartidas y permite al usuario crear una cola de llamadas compartida, donde muchos agentes se pueden suscribir a una cola de llamadas específica y responder a llamadas de cliente. Por ejemplo, puede llamar al centro de servicio de atención al cliente para un producto específico. Muchos agentes se pueden suscribir a la cola, pero solo se elige un agente para responder a cada llamada.
- Pasarela Rtcomm: añade la prestación para conectar SIP (Session Initiation Protocol) con puntos finales WebRTC Rtcomm para el intercambio de secuencias de audio y vídeo. Si desea más detalles sobre cómo configurar una pasarela Rtcomm, consulte Configuración de una pasarela Rtcomm.
- Direccionamiento de punto final alternativo: especifica que el usuario desea direccionar sesiones nuevas a través de un punto final alternativo.
- Configuración del servidor ICE (Interactive Connectivity Establishment)
ICE es una técnica que se utiliza en redes de sistemas que implican NAT (Network Address Translators) en aplicaciones de Internet como, por ejemplo, Voice over Internet Protocol (VoIP), comunicaciones de igual a igual, vídeo, mensajería instantánea y otros soportes interactivos. En dichas aplicaciones, el cruce NAT es un componente importante para facilitar comunicaciones que implican hosts en instalaciones de red privada, a menudo, se encuentran detrás de cortafuegos.
El controlador de nodos proporciona configuración de servidor ICE como una forma para notificar a los nodos de cliente Rtcomm que pueden utilizar los servidores ICE al configurar sesiones de igual a igual con otro cliente. WebRTC se basa en gran medida en servidores ICE para atravesar cortafuegos, si está en entornos de producción, es básico incluir soporte para ICE para asegurarse la probabilidad más alta posible para conectarse a puntos finales.
Se accede a la configuración de servidor ICE a través de una solicitud de consulta de servicio que se publica en el nombre de tema de conector asociado a una característica Rtcomm. Si desea más información sobre la consulta de servicio Rtcomm, consulte los detalles del protocolo, GitHub lib.rtcomm.clientjs.
Para configurar distintos tipos de servidores ICE, añada la propiedad siguiente a la línea de configuración rtcomm en el archivo server.xml:
<rtcomm> <iceServerURL>stun:example1.hostname.com:8880</iceServerURL> <iceServerURL>stun:example2.hostname.com:8881</iceServerURL> </rtcomm>
- Control de llamada por terceros
Puede encontrar todos los detalles de protocolo que definen los formatos de mensaje que están relacionados con el control de llamada por terceros en el repositorio GitHub. Los componentes de código abierto relacionados lib.rtcomm.node-red y lib.rtcomm.node se utilizan para interactuar con estos servicios.
- Soporte de cola de llamadas
Las colas de llamadas proporcionan una interacción de estilo de turno rotativo, donde muchos usuarios se pueden suscribir a una cola y otro usuario puede llamar a la cola. Solo uno de los usuarios suscritos recibirá la llamada. Esta característica se habilita definiendo colas y habilitando las suscripciones compartidas, tal como se ha mostrado anteriormente en el paso dos.
Para poder configurar colas de llamadas, configure la suscripción compartida que se añade como prefijo a rtcommTopicPath. Los intermediarios de mensajes requieren esta vía de acceso cuando utilizan suscripciones compartidas. Puede definir las callQueues que están soportadas añadiendo las líneas de configuración siguientes al archivo server.xml:<rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/"> <callQueue description="refrigerator" callQueueID="callQueueID2" timeout="500s"></callQueue> </rtcomm>
El usuario puede crear tantas colas de llamadas exclusivas como necesiten. Cuando está configurado, la vía de acceso de la suscripción compartida más la vía de acceso del temartcomm más el nombre del tema ("$SharedSubscription/rtcomm//rtcomm/callQueue") está suscrita a través de agentes para recibir solicitudes de llamada del servidor.
Los elementos de configuración siguientes están disponibles para cada cola:
- Configurar description: especifica la descripción verbal de esta instancia de cola de llamadas. Esta descripción verbal se devuelve en respuestas de consulta de servicio y se puede utilizar para informar mejor al cliente sobre la cola.
- Configurar callQueueID: el ID de punto final que está asociado al nombre de tema de la cola de llamadas y que es el ID de punto final de destino que utiliza un interlocutor para llamar en una cola específica.
- Configurar timeout: el número de segundos para esperar antes de terminar una llamada que está esperando en una cola.
- Direccionamiento de punto final alternativo
- Especifica que el usuario desea direccionar sesiones nuevas a
través de un punto final alternativo. Utilizando esta opción, puede
suscribirse al nombre del tema
alternateEndpointRouting como, por ejemplo,
/rtcomm/alternateEndpointRouting y podrá direccionar
sesiones nuevas al punto final adecuado. Para habilitar esta
prestación, añada la línea de configuración siguiente al archivo
server.xml:
<rtcomm alternateEndpointRoutingEnabled="true"/>
- Configuración de SSL para Rtcomm
- Asegúrese de que el entorno se ha configurado para utilizar SSL entre la característica Rtcomm y el intermediario MQTT.
- La referencia de SSL es el ID de la configuración de SSL que se utiliza para conectarse al intermediario MQTT habilitado para SSL.
Nota: Para que la característica Rtcomm utilice SSL, la característica SSL debe estar habilitada. Para habilitar la característica SSL, añada la configuración siguiente al archivo server.xml.<rtcomm sslEnabled="true" sslRef="mySSLConfig" />
Si desea más detalles sobre el atributo de configuración sslRef, consulte Liberty: atributos de configuración SSL.

Nombre de archivo: twlp_config_rtcomm.html