Liberty Real-Time Communications 구성

Real-Time Communications 기능 구성은 server.xml 파일에 대한 업데이트로 구성됩니다.

이 태스크 정보

Real-Time Communications에 사용할 수 있는 애플리케이션을 실행하도록 Liberty 서버를 구성하려면 rtcomm-1.0 기능을 설정해야 합니다. 또한 여러 기타 구성 및 옵션이 Real-Time Communications를 사용하는 애플리케이션에 사용되도록 할 수 있습니다.

참고:  Rtcomm 기능은 현재 Liberty 집합체 또는 클러스터링을 지원하지 않습니다. 현재 rtcommTopicPath당 하나의 Liberty 인스턴스만 지원됩니다.

프로시저

  1. rtcomm-1.0 기능을 사용하려면 server.xml 파일의 featureManager 요소에 다음 요소 선언을 추가하십시오.
    <featureManager>
           <feature>rtcomm-1.0</feature>
    </featureManager>
    기본 설정을 수정하려면 Liberty 서버 구성에 Rtcomm 기능을 추가해야 합니다. 이를 수행하려면 WDT 도구를 사용하거나 server.xml 파일에 다음 구성 행을 수동으로 추가할 수 있습니다.
    <rtcomm/>
    기본 설정은 다음과 같습니다.
    • Rtcomm MQTT Broker 연결 세부사항: (host: localhost and port: 1883)
    • Rtcomm 루트 토픽 경로: /rtcomm/
    • SSL 사용 안함
    참고: 기본 설정이 작동하려면 MQTT Broker를 Liberty 서버와 동일한 시스템에 설치하고 사용해야 합니다.
    MQTT Broker의 기본 설정을 변경하려면 다음과 같이 server.xml 파일을 편집해야 합니다.
    <rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerportname>" />
  2. Rtcomm 토픽 경로를 구성하십시오. rtcommTopicPath는 다른 Rtcomm 토픽 이름과 함께 사용됩니다. 이 토픽 경로는 동일한 메시지 브로커를 사용하는 다른 개발자와의 충돌을 피하도록 고유 네임스페이스를 제공합니다. 이 경로를 설정하려면 다음 구성 행을 server.xml 파일에 추가하십시오.
    <rtcomm rtcommTopicPath="/rtcomm/"/>

    rtcomm 클라이언트 라이브러리에 구성한 이름 및 경로를 메시지 브로커 주소와 함께 초기화 시 전달해야 합니다. 서버는 토픽 이름을 작성하고 토픽 경로에 추가합니다.

    참고: rtcommTopicPath는 여러 Liberty 서버가 동일한 MQTT 브로커를 사용하도록 구성될 때마다 Liberty 서버마다 고유해야 하고 그렇지 않으면 동작을 예측할 수 없습니다.
  3. rtcommTopicPath의 앞에 오는 공유 등록 경로를 구성할 수 있습니다. 이 경로는 공유 등록 사용 시 메시지 브로커에 필요합니다. 이 경로를 설정하려면 다음 구성 행을 server.xml 파일에 추가하십시오.
    <rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/">

    호출 큐 사용 시 공유 등록을 구성해야 합니다. 호출 큐가 모든 큐 리스너에 메시지를 분배하려면 공유 등록이 필요합니다. 예를 들어, 여러 헬프데스크 에이전트가 모두 단일 큐에서 청취하고 있는 경우 공유 등록이 한 번에 하나의 에이전트에 호출을 분배하는 데 사용됩니다.

    참고: 공유 등록 지원은 MQTT 브로커에서 표준이 아닙니다. 이전 구성은 IBM® MessageSight에서 작동하도록 rtcomm-1.0 기능을 올바르게 설정하는 방법을 표시합니다. 공유 등록 구성에 대해서는 브로커의 제품 문서를 참조하십시오.
  4. 선택사항: Rtcomm 기능 사용 시 추가 옵션을 구성하십시오.
    Rtcomm 기능으로 백엔드 서비스 구성

    Rtcomm 기능은 다음을 포함하는 많은 백엔드 서비스를 지원합니다.

    • ICE(Interactive Connectivity Establishment) 서버 구성: 피어 미디어 세션에 대해 협상하여 Rtcomm WebRTC 클라이언트가 보내고 사용하는 URL을 지정합니다.
    • 호출 큐 지원: 공유 호출 큐를 지원하도록 Rtcomm을 구성할 수 있고 이 Rtcomm을 사용하면 사용자는 많은 에이전트가 특정 호출 큐에 등록하고 고객 호출에 응답할 수 있는 공유 호출 큐를 작성할 수 있습니다. 예를 들어, 특정 제품에 대한 고객 지원으로 전화할 수 있습니다. 많은 에이전트가 큐에 등록할 수 있지만 하나의 에이전트만 각 호출에 응답하도록 선택됩니다.
    • Rtcomm 게이트웨이: 오디오 및 비디오 스트림의 교환을 위해 Rtcomm WebRTC 엔드포인트에 SIP(Session Initiation Protocol)를 연결하는 기능을 추가합니다. Rtcomm 게이트웨이 구성에 대한 세부사항은 Rtcomm 게이트웨이 구성을 참조하십시오.
    • 대체 엔드포인트 라우팅: 사용자가 대체 엔드포인트를 통해 새 세션을 라우팅하도록 지정합니다.
    ICE(Interactive Connectivity Establishment) 서버 구성

    ICE는 인터넷 애플리케이션에 NAT(Network Address Translators)를 포함하는 컴퓨터 네트워크에 사용되는 기술입니다(예: VoIP(Voice over Internet Protocol), 피어 투 피어 통신, 비디오, 인스턴트 메시징, 기타 대화식 매체). 이와 같이 애플리케이션에서 NAT 순회는 종종 방화벽 뒤에 있는 사설 네트워크 설치에서 호스트와 관련된 통신을 용이하게 하는 중요한 컴포넌트입니다.

    노드 제어기는 다른 클라이언트에 대한 피어 투 피어 세션을 설정할 때 사용할 수 있는 ICE 서버에 대해 Rtcomm 클라이언트 노드에 알리는 방식으로 ICE 서버 구성을 제공합니다. WebRTC는 방화벽을 순회하기 위해 ICE 서버에 크게 의존하며, 프로덕션 배치에서 엔드포인트 연결 가능성을 최대화하기 위해 ICE에 대한 지원을 포함해야 합니다.

    ICE 서버 구성은 Rtcomm 기능과 연관된 커넥터 토픽 이름에 공개된 서비스 조회 요청을 통해 액세스됩니다. Rtcomm 서비스 조회에 대한 자세한 정보는 프로토콜 세부사항 GitHub lib.rtcomm.clientjs를 참조하십시오.

    ICE 서버의 다양한 유형을 구성하려면 server.xml 파일의 rtcomm 구성 행에 다음 특성을 추가하십시오.

    <rtcomm>
        		  <iceServerURL>stun:example1.hostname.com:8880</iceServerURL>
        		  <iceServerURL>stun:example2.hostname.com:8881</iceServerURL>
    </rtcomm>
    써드파티 호출 제어

    GitHub 저장소의 써드파티 호출 제어와 관련된 메시지 형식을 정의하는 프로토콜 세부사항을 모두 찾을 수 있습니다. lib.rtcomm.node-redlib.rtcomm.node 관련 개방형 소스 컴포넌트는 이러한 서비스와 상호작용하는 데 사용됩니다.

    호출 큐 지원

    호출 큐는 많은 사용자가 큐에 등록할 수 있고 다른 사용자가 큐를 호출할 수 있는 라운드 로빈 스타일 상호작용을 제공합니다. 등록된 사용자 중 한 명만 호출을 수신할 수 있습니다. 이 기능은 2단계에 이전에 표시된 대로 큐를 정의하고 공유 등록을 사용하여 사용할 수 있습니다.

    호출 큐를 구성하려면 rtcommTopicPath 앞에 오는 공유 등록 경로를 구성하십시오. 이 경로는 공유 등록 사용 시 메시지 브로커에 필요합니다. server.xml 파일에 다음 구성 행을 추가하여 지원되는 callQueues를 정의할 수 있습니다.
    <rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/">
        <callQueue description="refrigerator" callQueueID="callQueueID2" timeout="500s"></callQueue>
    </rtcomm>

    사용자는 필요한 만큼 많은 고유 호출 큐를 작성할 수 있습니다. 공유 등록 경로, rtcomm 토픽 경로 및 토픽 이름("$SharedSubscription/rtcomm//rtcomm/callQueue")이 구성된 경우 에이전트가 서버에서 호출 요청을 수신하기 위해 여기에 등록합니다.

    다음 구성 항목은 큐마다 사용 가능합니다.

    • 설명 구성: 이 호출 큐 인스턴스에 대한 언어적 설명을 지정합니다. 이 언어적 설명은 서비스 조회 응답으로 리턴되며 큐에 대해 클라이언트에 더 효율적으로 알리는 데 사용될 수 있습니다.
    • callQueueID 구성: 호출 큐 토픽 이름과 연관되어 있고, 호출자가 특정 큐에 호출하는 데 사용하는 대상 엔드포인트 ID인 엔드포인트 ID입니다.
    • 제한시간 구성: 큐에서 대기하는 호출을 종료하기 전까지 대기하는 시간(초)입니다.
    대체 엔드포인트 라우팅
    사용자가 대체 엔드포인트를 통해 새 세션을 라우팅하도록 지정합니다. 이 옵션을 사용하면 alternateEndpointRouting 토픽 이름(예: /rtcomm/alternateEndpointRouting)에 등록하고 적절한 엔드포인트로 새 세션을 라우팅할 수 있습니다. 이 기능을 사용하려면 다음 구성 행을 server.xml 파일에 추가하십시오.
    <rtcomm alternateEndpointRoutingEnabled="true"/>
    Rtcomm을 위한 SSL 구성
    환경이 Rtcomm 기능과 MQTT 브로커 사이에 SSL을 사용하도록 구성되어 있는지 확인하십시오.
    SSL 참조는 SSL 사용 MQTT 브로커에 연결하는 데 사용되는 SSL 구성의 ID입니다.
    참고: Rtcomm 기능이 SSL을 사용하려면 SSL 기능을 사용으로 설정해야 합니다. SSL 기능을 사용으로 설정하려면 다음 구성을 server.xml 파일에 추가하십시오.
    <rtcomm sslEnabled="true" sslRef="mySSLConfig" />

    sslRef 구성 속성에 대한 세부사항은 Liberty: SSL 구성 속성을 참조하십시오.


주제의 유형을 표시하는 아이콘 태스크 주제



시간소인 아이콘 마지막 업데이트 날짜: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_config_rtcomm
파일 이름: twlp_config_rtcomm.html