Configuration d'une passerelle Rtcomm

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

Pourquoi et quand exécuter cette tâche

La passerelle Rtcomm (GW) est utile lorsque vous avez besoin de fédération entre le réseau Rtcomm et les réseaux de différents fournisseurs. L'autre réseau peut être un réseau de noeuds finaux WebRTC qui utilise une méthode de notification différente, ou il peut s'agir également d'un autre réseau d'unités voix sur IP (VOIP), ou même d'un réseau téléphonique public commuté (PSTN). Une fédération de ce type est possible tant que l'autre réseau fournit un élément de passerelle Rtcomm de résultat qui prend en charge le protocole SIP couramment adopté.

La passerelle Rtcomm prend en charge la technique d'établissement d'une connectivité interactive (Interactive Connectivity Establishment, ICE) pour SIP (basé sur RFC 5245) et trickle ICE (envoi au compte-goutte) pour SIP (basé sur l'IETF provisoire). Ce brouillon est encore marqué comme "travail en cours", et cette implémentation peut encore changer en fonction de la progression du travail.

Procédure

  1. Ajoutez la fonction rtcommGateway-1.0 dans le fichier server.xml pour activer la fonction Passerelle Rtcomm.
    <featureManager>
    	  <feature>rtcommGateway-1.0</feature>
    </featureManager>
    La passerelle Rtcomm est configurée à la section rtcomm. Cette configuration permet de définir les éléments suivants :
    1. Indique à la passerelle Rtcomm où diriger le message SIP converti à partir d'un message de notification Rtcomm entrant. Vous disposez de trois options :
      • Rien n'est configuré (par défaut) : la passerelle Rtcomm tente de résoudre la destination en fonction de l'adresse SIP fournie comme cible sur le client Rtcomm WebRTC.
      • sipContainer=true : la passerelle Rtcomm envoie le message à port de conteneur du servlet SIP Liberty interne. Le message est routé vers une application JSR 289 installée sur le serveur Liberty, en fonction des règles de routeur d'application standard. Pour plus de détails, voir Applications SIP (Session Initiation Protocol) dans Liberty.
      • ExternalPR=host:port : indique à la passerelle Rtcomm de router le message SIP converti vers une destination externe d'un proxy ou d'un registre SIP.
    2. Définissez le noeud final SIP pour les messages SIP entrants. Les messages entrant sur le noeud final SIP sont convertis en notification Rtcomm et distribués par la passerelle Rtcomm au noeud final WebRTC, lequel est résolu à partir de l'en-tête requestURI du message SIP initial.
  2. Passez en revue les considérations supplémentaires suivantes pour l'implémentation de la passerelle Rtcomm.
    1. Envoi de messages depuis Rtcomm WebRTC vers SIP.
      • REGISTER : Lors de l'envoie d'un message de registre Rtcomm depuis un client WebRTC qui utilise le message DOCUMENT, il est possible d'utiliser une adresse SIP d'enregistrement (AOR) comme sujet client. Si un URI SIP de ce type est enregistré, la passerelle Rtcomm le convertit en demande REGISTER SIP et tente de router la demande en fonction des règles définies par la configuration. L'en-tête Contact est construit à partir d'une adresse de noeud final SIP de passerelle Rtcomm, comme configuré pour le serveur Liberty, et le nom d'utilisateur tel que défini dans l'adresse SIP d'enregistrement.
      • Le message Rtcomm START_SESSION peut également être dirigé vers une adresse SIP. Dans ce cas, la zone START_SESSION toEndpointID est renseignée par un URI, qui commence par l'un des préfixes de schéma 'sip', 'sips' ou 'tel', puis le message est converti en SIP INVITE et envoyé conformément aux règles configurées. Tous les messages suivants de la boîte de dialogue sont convertis en SIP en fonction du scénario de notification défini dans la demande RFC (Request For Comments) pertinente. Cette règle s'applique aux scénarios de notification ICE et trickle ICE.
    2. Envoi de messages depuis SIP vers Rtcomm WebRTC.
      La passerelle Rtcomm prend en charge uniquement les boîtes de dialogue INVITE. Une invite SIP INVITE entrant dans l'un des noeuds finaux GW SIP configurés est convertie en message Rtcomm START_SESSION et envoyé au noeud final WebRTC résolu. Le noeud final WebRTC est résolu en fonction des règles suivantes :
      • Recherchez l'adresse SIP INVITE requestURI. Si le noeud final a été enregistré en tant que sujet client par un message Rtcomm DOCUMENT précédent, c'est vers ce noeud que le message START_SESSION est dirigé. Si, par exemple, le noeud final Rtcomm a été enregistré en tant que "sip:bob@x.y.z.w" comme sujet DOCUMENT, alors toute INVITE avec "sip:bob@x.y.z.w requestURI" est convertie en START_SESSION et dirigée vers ce sujet MQTT.
      • Si l'étape précédente n'a pas résolu un destination, recherchez uniquement la partie utilisateur dans l'URI requestURI SIP. Si le noeud final a été enregistré, la START_SESSION est dirigée vers ce sujet. Par exemple, si le noeud final Rtcomm a été enregistré en tant que "bob", alors pour tout <domain> de l'URI requestURI sera bob@domain.
        Remarque : Les demandes SIP non prises en charge sont renvoyées avec une réponse d'erreur 405.
    3. Transcodage et fonctionnalité de serveur multimédia
      • La passerelle Rtcomm ne prend pas en charge la gestion de plans multimédia et n'effectuera pas d'actions de type transcodage entre codecs de noeuds finaux SIP VOIP et WebRTC. En d'autres termes, pour une utilisation de base, la passerelle Rtcomm autorise uniquement la fédération entre différents noeuds finaux WebRTC ou des noeuds finaux utilisant des codecs et des protocoles de flot de données similaires, tels que la norme WebRTC.
      • Pour utiliser pleinement les fonctionnalités de la passerelle Rtcomm, il est possible d'étendre le serveur Liberty avec une fonction fournissant des API pour un connecteur de serveur multimédia basé sur la norme JSR 309. Avec cette fonction, vous pouvez créer et installer sur le serveur Liberty une application qui utilise un serveur multimédia pour le transcodage et la conversion de protocole de flot de données, en plus de nombreuses autres fonctions avancées telles que l'enregistrement, la lecture d'annonces, le mixage de flots pour les conférences A/V multi-parties et bien plus encore. Pour plus de détails, voir la spécification JSR 309.
      • Voir WASdev pour un exemple d'application utilisant JSR 289 et 309 pour la connexion à un logiciel de téléphonie SIP et le noeud final Rtcomm WebRTC utilisant un serveur multimédia comme médiateur et traducteur pour le média.
      • L'application utilise SIP Servlets (JSR 289) avec JSR 309 et sert de médiateur entre le réseau SIP et le réseau Rtcomm WebRTC. Cette application requiert uniquement la configuration du routage interne dans le fichier server.xml. Par exemple :
        <rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerhostport>"
                     <gateway sipContainer="true"></gateway>
        </rtcomm>
        Remarque : Assurez-vous que les ports SIP où sont dirigés les messages SIP entrants sont ceux du conteneur SIP Servlets et non le noeud final GW. Voir Administration du protocole SIP (Session Initiation Protocol) dans Liberty.

Exemple

Dans cet exemple, les messages WebRTC entrants sont dirigés vers un noeud final SIP externe qui peut être un proxy ou un registre, tel que 1.2.23.2:5063.
<rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerhostport>"
   <gateway sipContainer="false" externalPR="1.2.23.2:5063" allowFromSipEndpointRef="webrtc2, webrtc"></gateway>
</rtcomm>
Les messages SIP entrants peuvent être sur des noeuds finaux SIP "webrtc" et "webrtc2". Dans l'exemple suivant, "webrtc" utilise les ports par défaut, 5060 et localhost.
<sipEndpoint id="webrtc"></sipEndpoint>
<sipEndpoint id="webrtc2" sipTCPPort="5067" sipUDPPort="5067" sipTLSPort="5068" host="*"></sipEndpoint>

Icône indiquant le type de rubrique Rubrique Tâche

Nom du fichier : twlp_config_webrtc_gateway.html