Rtcomm-Gateway konfigurieren

Mit dem Rtcomm-Gateway kann eine Verbindung zwischen SIP- (Session Initiation Protocol) und Rtcomm-WebRTC-Endpunkten für den Austausch von Audio- und Videodatenströmen hergestellt werden.

Informationen zu diesem Vorgang

Das Rtcomm-Gateway (GW) ist hilfreich, wenn eine Einbindung zwischen dem Rtcomm-Netz und unterschiedlichen Anbieternetzen erforderlich ist. Das andere Netz kann ein Netz von WebRTC-Endpunkten sein, das eine andere Methode für die Signalisierung verwendet. Es kann auch ein anderes Netz von Voice-over-IP-Einheiten (VOIP) oder sogar ein öffentliches Telefonnetz (PSTN) sein. Eine solche Einbindung ist möglich, wenn das andere Netz ein Edge-Gateway-Element bereitstellt, das das weitgehend verbreitete SIP-Protokoll unterstützt.

Das Rtcomm-Gateway unterstützt Interactive Connectivity Establishment (ICE) für SIP (basierend auf RFC 5245) und trickle ICE für SIP (basierend auf dem IETF-Entwurf). Dieser Entwurf ist immer noch mit "in Arbeit" markiert, daher wird diese Implementierung in der Zukunft möglicherweise ausgehend vom Fortschritt bei der Bearbeitung dieses Entwurfs geändert.

Vorgehensweise

  1. Fügen Sie das Feature rtcommGateway-1.0 in der Datei server.xml hinzu, um die Rtcomm-Gateway-Funktion zu aktivieren.
    <featureManager> 	  <feature>rtcommGateway-1.0</feature>
    </featureManager>
    Das Rtcomm-Gateway wird im Abschnitt rtcomm konfiguriert. Bei dieser Konfiguration können Sie Folgendes definieren:
    1. Dem GW vorgeben, wohin die SIP-Nachricht übertragen werden soll, die aus einer eingehenden Rtcomm-Signalisierungsnachricht umgesetzt wurde. Es sind drei Optionen verfügbar:
      • Nichts wird konfiguriert (Standardeinstellung): Das GW versucht, das Ziel basierend auf der SIP-Adresse aufzulösen, die als Ziel im Rtcomm-WebRTC-Client angegeben wurde.
      • sipContainer=true: Das GW sendet die Nachricht an den internen Port für Liberty-SIP-Servlet-Container. Diese Nachricht wird entsprechend den Standardregeln für Anwendungsrouter an eine JSR 289-Anwendung weitergeleitet, die auf dem Liberty-Server installiert ist. Weitere Einzelheiten finden Sie unter SIP-Anwendungen in Liberty.
      • ExternalPR=host:port: Weist das GW an, die umgesetzte SIP-Nachricht an ein externes Ziel eines SIP-Proxys oder -Registrators weiterzuleiten.
    2. SIP-Endpunkt für eingehende SIP-Nachrichten definieren. Am SIP-Endpunkt eingehende Nachrichten werden in Rtcomm-Signale umgesetzt und vom GW an den WebRTC-Endpunkt übermittelt, der aus dem Header requestURI der SIP-Startnachricht aufgelöst wurde.
  2. Sehen Sie sich die folgenden zusätzlichen Überlegungen für die Implementierung des Rtcomm-Gateways an.
    1. Nachrichten über Rtcomm WebRTC an SIP senden.
      • REGISTER: Beim Senden einer Rtcomm-Registernachricht vom WebRTC-Client, der die Nachricht DOCUMENT verwendet, kann eine SIP-AOR (Address of Record) als Client-Topic verwendet werden. Wenn ein solcher SIP-URI registriert wird, konvertiert das GW ihn in einer SIP-Anforderung vom Typ REGISTER und versucht, ihn unter Berücksichtigung der von der Konfiguration definierten Regeln weiterzuleiten. Der Header "Contact" wird aus einer Rtcomm-Gateway-SIP-Endpunktadresse, die für den Liberty-Server konfiguriert ist, und dem Benutzernamen in der AOR festgelegten Benutzernamen gebildet.
      • Die Rtcomm-Nachricht START_SESSION kann ebenfalls an eine SIP-Adresse übertragen werden. In diesem Fall enthält das Feld START_SESSION toEndpointID einen URI, der mit den Schemapräfixen 'sip', 'sips' oder 'tel' anfängt. Anschließend wird die Nachricht in eine Nachricht vom Typ SIP INVITE umgesetzt und entsprechend den konfigurierten Regeln gesendet. Alle nachfolgenden Nachrichten im Dialog werden entsprechend dem definierten Signalisierungsszenario und der relevanten Request for Comments (RFC) in SIP umgesetzt. Diese Regel gilt für ICE- (Interactive Connectivity Establishment) und trickle ICE-Signalisierungsszenarien.
    2. Nachrichten über SIP an Rtcomm WebRTC senden.
      Das GW unterstützt derzeit nur INVITE-Dialoge. Eine Nachricht vom Typ SIP INVITE, die an einem der konfigurierten GW-SIP-Endpunkte eingeht, wird in eine Rtcomm-Nachricht vom Typ START_SESSION umgesetzt und an den aufgelösten WebRTC-Endpunkt gesendet. Der WebRTC-Endpunkt wird entsprechend den folgenden Regeln aufgelöst:
      • SIP-Adresse von INVITE requestURI suchen. Wenn der Endpunkt als Client-Topic von einer früheren Rtcomm-Nachricht DOCUMENT registriert wurde, ist dies das Ziel für die Übertragung der Nachricht START_SESSION. Wenn der Rtcomm-Endpunkt beispielsweise als "sip:bob@x.y.z.w" als DOCUMENT-Topic registriert wurde, wird jede Nachricht vom Typ INVITE mit "sip:bob@x.y.z.w requestURI" in START_SESSION konvertiert und an dieses MQTT-Topic übertragen.
      • Wenn der vorherige Schritt kein Ziel aufgelöst hat, suchen Sie nur nach dem Benutzerabschnitt im SIP-Anforderungs-URI (requestURI). Wenn der Endpunkt registriert wurde, wird START_SESSION an dieses Topic übertragen. Wenn der Rtcomm-Endpunkt beispielsweise als "bob", registriert wurde, dann hat jede <domain> im requestURI den Wert bob@domain.
        Anmerkung: Nicht unterstützte SIP-Anforderungen werden mit einer Fehlerantwort mit dem Code "405" zurückgegeben.
    3. Codeumsetzungs- und erweiterte Media-Server-Funktion.
      • Das Rtcomm-Gateway unterstützt keine Bearbeitung auf Medienebene und führt keine Aktionen wie die Codeumsetzung zwischen SIP-VOIP- und WebRTC-Endpunkt-Codecs aus. Das bedeutet, dass das GW bei Basisverwendung nur die Einbindung zwischen unterschiedlichen WebRTC-Endpunkten oder Endpunkten, die ähnliche Codecs und Streaming-Protokolle wie den WebRTC-Standard verwenden, zulässt.
      • Um den vollen Rtcomm-Gateway-Funktionsumfang nutzen zu können, können Sie den Liberty-Server um ein Feature erweitern, das APIs für einen Media-Server-Connector basierend auf dem Standard JSR 309 bereitstellt. Mit diesem Feature können Sie eine Anwendung auf dem Liberty-Server erstellen und installieren, die neben vielen anderen erweiterten Features, wie z. B. Aufzeichnung, Mitteilungswiedergabe, Mischen von Streams für A/V-Konferenzen mit mehreren Teilnehmern usw., einen Media-Server für die Codeumsetzung und Streaming-Protokollumsetzung verwendet. Enzeilheiten enthält die Spezifikation JSR 309.
      • Auf WASdev finden Sie eine Beispielanwendung, die JSR 289 und 309 verwendet, um ein SIP-Softphone und den Rtcomm-WebRTC-Endpunkt mit einem Media-Server als Mediator und Umsetzer für die Medien zu verbinden.
      • Die Anwendung verwendet SIP-Servlets (JSR 289) mit JSR 309 und vermittelt zwischen dem SIP- und dem Rtcomm-WebRTC-Netz. Für diese Anwendung ist nur die Konfiguration des internen Routings in der Datei server.xml erforderlich, z. B.:
        <rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerhostport>"
                     <gateway sipContainer="true"></gateway>
        </rtcomm>
        Anmerkung: Vergewissern Sie sich, dass die SIP-Ports, an die eingehende SIP-Nachrichten übertragen werden, die der SIP-Servlet-Container-Endpunkte sind und nicht die des GW-Endpunkts. Weitere Informationen finden Sie unter Session Initiation Protocol (SIP) in Liberty verwalten.

Beispiel

In diesem Beispiel werden die eingehenden WebRTC-Nachrichten an einen externen SIP-Endpunkt übertragen, bei dem es sich um einen Proxy oder einen Registrator handeln kann, wie z. B. 1.2.23.2:5063.
<rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerhostport>"
   <gateway sipContainer="false" externalPR="1.2.23.2:5063" allowFromSipEndpointRef="webrtc2, webrtc"></gateway>
</rtcomm>
Eingehende SIP-Nachrichten kann es an den SIP-Endpunkten "webrtc" und "webrtc2" geben. Im folgenden Beispiel verwendet "webrtc" die Standardports (5060 und localhost).
<sipEndpoint id="webrtc"></sipEndpoint>
<sipEndpoint id="webrtc2" sipTCPPort="5067" sipUDPPort="5067" sipTLSPort="5068" host="*"></sipEndpoint>

Symbol das den Typ des Artikels anzeigt. Taskartikel

Dateiname: twlp_config_webrtc_gateway.html