Configuración de una pasarela Rtcomm

La 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.

Acerca de esta tarea

La pasarela Rtcomm (GW) es útil cuando se requiere federar entre la red de Rtcomm y redes de distintos proveedores. La otra red puede ser una red de puntos finales WebRTC, que está utilizando un método diferente para la señalización, o también puede ser una red diferente de dispositivos de Voice over IP (VOIP) o, incluso, la red de teléfono pública conmutada (PSTN). Dicha federación es posible mientras que la otra red proporciona un elemento GW Edge que soporta el protocolo SIP adoptado ampliamente.

La pasarela Rtcomm soporta tanto Interactive Connectivity Establishment (ICE) para SIP (basado en RFC 5245), como el goteo ICE para SIP (basado en el borrador IETF). Este borrador todavía está marcado como un "trabajo en curso", de forma que esta implementación podría cambiar en el futuro de acuerdo con este progreso del borrador.

Procedimiento

  1. Añada la característica rtcommGateway-1.0 en el archivo server.xml para habilitar la prestación de pasarela Rtcomm.
    <featureManager>
    	  <feature>rtcommGateway-1.0</feature>
    </featureManager>
    La pasarela Rtcomm está configurada en la sección rtcomm. Esta configuración le permite definir lo siguiente:
    1. Indica a la GW dónde direccionar el mensaje SIP que se convierte de un mensaje de señalización Rtcomm entrante. Hay tres opciones:
      • No se ha configurado nada (predeterminado): La GW intenta resolver el destino basándose en la dirección IP que se ha proporcionado como el destino en el cliente WebRTC Rtcomm.
      • sipContainer=true: la GW envía el mensaje al puerto del contenedor de servlet de Liberty interno. Este mensaje se direcciona a una aplicación JSR 289 que está instalada en el servidor Liberty, de acuerdo con las reglas de direccionador de aplicaciones estándar. Si desea más detalles, consulte Aplicaciones SIP (Session Initiation Protocol) en Liberty.
      • ExternalPR=host:port: indica a la GW que direccione el mensaje SIP convertido a un destino externo de un proxy SIP o registrador.
    2. Defina el punto final SIP para mensajes SIP entrantes. Los mensajes que proceden del punto final SIP se convierten a en la señalización de Rtcomm y se entregan a través de la GW al punto final WebRTC, que se resuelve a partir de la cabecera requestURI del mensaje inicial SIP.
  2. Revise las consideraciones adicionales siguientes para implementar la pasarela Rtcomm.
    1. Envío de mensajes de Rtcomm WebRTC a SIP.
      • REGISTRAR: al enviar un mensaje de registro Rtcomm desde el cliente WebRTC que está utilizando el mensaje DOCUMENT, es posible utilizar una dirección de registro (AOR) SIP como el tema de cliente. Si se ha registrado un URI SIP de ese tipo, la GW lo convierte a una solicitud REGISTER SIP e intenta direccionarlo de acuerdo con las reglas definidas por la configuración. La cabecera de contacto se construye a partir de una dirección de punto final SIP de pasarela Rtcomm, tal como se ha configurado para el servidor Liberty, y el nombre de usuario como está establecido en la AOR.
      • El mensaje Rtcomm START_SESSION también se puede direccionar a una dirección SIP. En este caso, el campo START_SESSION toEndpointID se llena mediante un URI, que empieza con cualquiera de los prefijos de esquema 'sip', 'sips' o 'tel', el mensaje se convierte a SIP INVITE y se envía de acuerdo con las reglas configuradas. Todos los mensajes posteriores del diálogo se convierten a SIP de acuerdo con el escenario de señalización definido y la solicitud de comentarios (RFC) relevante. Esta regla se aplica a los escenarios de señalización de ICR (Interactive Connectivity Establishment) y de goteo ICE.
    2. Envío de mensajes de SIP a WebRTC Rtcomm.
      La GW soporta actualmente solo diálogos INVITE. Un SIP INVITE que se encuentra en uno de los puntos finales SIP de GW configurados se convierte a un mensaje Rtcomm START_SESSION y se envía al punto final WebRTC resuelto. El punto final WebRTC se resuelve de acuerdo con las reglas siguientes:
      • Busque la dirección SIP INVITE requestURI. Si el punto final se ha registrado como un tema de cliente mediante un mensaje Rtcomm DOCUMENT anterior, entonces este es el lugar dónde se direcciona el mensaje START_SESSION. Por ejemplo; si el punto final Rtcomm se ha registrado como "sip:bob@x.y.z.w" como un tema DOCUMENT, cualquier INVITE con "sip:bob@x.y.z.w requestURI" se convierte a START_SESSION y se direcciona a dicho tema MQTT.
      • Si el paso anterior no ha resuelto un destino, busque solo la parte de usuario en el SIP requestURI. Si el punto final se ha registrado, START_SESSION se direcciona a dicho tema. Por ejemplo; si el punto final Rtcomm se ha registrado como "bob", para cualquier <domain> de requestURI es bob@domain.
        Nota: Las solicitudes SIP no soportadas se devuelven con una respuesta de error 405.
    3. Transcodificación y funciones de servidor de soportes avanzadas.
      • La pasarela Rtcomm no soporta el manejo del plano de soportes y no realizará acciones como la transcodificación entre SIP VOIP y códecs de puntos finales WebRTC. Esto significa que en su uso básico, la GW solo permite la federación entre distintos puntos finales WebRTC, o puntos finales que utilizan códecs similares y protocolos de transmisión como, por ejemplo, el estándar WebRTC.
      • Para hacer un uso pleno de las prestaciones de la pasarela Rtcomm, es posible aumentar el servidor Liberty con una característica que proporciona las API para el conector del servidor de soportes basándose en el estándar JSR 309. Con esta característica, puede crear e instalar una aplicación en el servidor Liberty que utiliza un servidor de soportes para la transcodificación y la conversión de protocolo de transmisión, además de muchas otras características avanzadas como la grabación, reproducción de anuncios, combinación de transmisiones para conferencias A/V de varias partes y muchas más. Los detalles se pueden encontrar en la especificación de JSR 309.
      • Consulte WASdev para encontrar una aplicación de ejemplo que utiliza JSR 289 y 309 para conectarse a un softphone SIP y al punto final WebRTC Rtcomm utilizando un servidor de soportes como mediador y conversor para los soportes.
      • La aplicación está utilizando servlets SIP (JSR 289) con JSR 309 y media entre la red SIP y la red WebRTC Rtcomm. Esta aplicación solo requiere la configuración del direccionamiento interno en el archivo server.xml; por ejemplo:
        <rtcomm
        messageServerHost="<nombre_host_intermediario>"
        messageServerPort="<puerto_host_intermediario>"
                     <gateway sipContainer="true"></gateway>
        </rtcomm>
        Nota: Asegúrese de que los puertos SIP adonde se direccionan mensajes SIP entrantes son los de los puntos finales de contenedor de servlets SIP y no los del punto final GW. Consulte Administración de Session Initiation Protocol (SIP) en Liberty.

Ejemplo

En este ejemplo, los mensajes WebRTC entrantes se direccionan a un punto final SIP externo que podría ser un proxy o registrador, como 1.2.23.2:5063.
<rtcomm messageServerHost="<nombre_host_intermediario>"
messageServerPort="<puerto_host_intermediario>"
   <gateway sipContainer="false" externalPR="1.2.23.2:5063" allowFromSipEndpointRef="webrtc2, webrtc"></gateway>
</rtcomm>
Los mensajes SIP entrantes pueden estar en los puntos finales SIP "webrtc" y "webrtc2". En el ejemplo siguiente, "webrtc" utiliza los puertos predeterminados que son 5060 y localhost.
<sipEndpoint id="webrtc"></sipEndpoint>
<sipEndpoint id="webrtc2" sipTCPPort="5067" sipUDPPort="5067" sipTLSPort="5068" host="*"></sipEndpoint>

Icono que indica el tipo de tema Tema de tarea

Nombre de archivo: twlp_config_webrtc_gateway.html