Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Grundlegende Komponenten der RTC-Architektur
In der Telekommunikationsbranche bezieht sich RTC üblicherweise auf Live-Mediensitzungen zwischen zwei Endpunkten mit minimaler Latenz. Diese Sitzungen könnten sich auf Folgendes beziehen:
-
Eine Sprachsitzung zwischen zwei Parteien (z. B. eine Telefonanlage, ein Mobiltelefon oder Voice over IP (VoIP))
-
Sofortnachrichten (wie Chatten und Instant Relay Chat (IRC))
-
Live-Videositzung (wie Videokonferenzen und Telepräsenz)
Jede der oben genannten Lösungen hat einige Komponenten gemeinsam (z. B. Komponenten für Authentifizierung, Autorisierung und Zugriffskontrolle, Transcodierung, Pufferung und Relay usw.) und einige Komponenten, die für den Typ der übertragenen Medien spezifisch sind (z. B. Broadcast-Service, Messaging-Server und Warteschlangen usw.). Dieser Abschnitt konzentriert sich auf die Definition eines sprach- und videobasierten RTC-Systems und aller zugehörigen Komponenten, wie in der folgenden Abbildung dargestellt.
Wesentliche Architekturkomponenten für RTC
SoftSwitch/PBX
Ein Softswitch oder PBX ist das Gehirn eines Sprachtelefonsystems und stellt mithilfe verschiedener Komponenten Informationen für die Einrichtung, Aufrechterhaltung und Weiterleitung eines Sprachanrufs innerhalb oder außerhalb des Unternehmens bereit. Alle Teilnehmer des Unternehmens müssen sich beim Softswitch registrieren, um einen Anruf entgegennehmen oder tätigen zu können. Eine wichtige Funktion des Softswitches besteht darin, den Überblick über jeden Teilnehmer zu behalten und zu erfahren, wie er mithilfe der anderen Komponenten innerhalb des Sprachnetzwerks erreicht werden kann.
Session Border Controller (SBC)
Ein Session Border Controller (SBC) befindet sich am Rand eines Sprachnetzwerks und verfolgt den gesamten eingehenden und ausgehenden Verkehr (sowohl Kontroll- als auch Datenebene). Eine der Hauptaufgaben eines SBC besteht darin, das Sprachsystem vor böswilliger Nutzung zu schützen. Der SBC kann zur Verbindung mit SIP-Trunks (Session Initiation Protocol) für externe Konnektivität verwendet werden. Einige bieten SBCs auch Transcodierungsfunktionen für die Konvertierung CODECs
PSTN-Konnektivität
Voice over IP (VoIP) -Lösungen verwenden Public Switched Telephone Network (PSTN) -Gateways und SIP-Trunks, um eine Verbindung mit älteren PSTN-Netzwerken herzustellen.
PSTN-Gateway
Das PSTN-Gateway konvertiert die Signalisierung zwischen SIP SS7 und Medien zwischen Real Time Transport Protocol (RTP) und Time Division Multiplexing (TDM) mithilfe von CODEC-Transcodierung. PSTN-Gateways befinden sich immer am Rand in der Nähe des PSTN-Netzwerks.
SIP-Trunk
Bei einem SIP-Trunk leitet das Unternehmen seine Anrufe nicht an ein (auf TDM SS7 basierendes) Netzwerk weiter, sondern der Datenfluss zwischen dem Unternehmen und dem Telekommunikationsunternehmen erfolgt weiterhin über IP. Die meisten SIP-Trunks werden mithilfe von eingerichtet. SBCs Das Unternehmen muss sich auf die vordefinierten Sicherheitsregeln der Telekommunikationsunternehmen einigen, z. B. die Zulassung eines bestimmten Bereichs von IP-Adressen, Ports usw.
Media Gateway (Transcoder)
Benutzer kommunizieren in Echtzeit mithilfe von Audio und/oder Video sowie optionalen Daten und anderen Informationen. Für die Kommunikation müssen sich die beiden Geräte auf einen für beide Seiten verständlichen Codec für jede Medienspur einigen, damit sie erfolgreich kommunizieren und die gemeinsam genutzten Medien präsentieren können. Alle WebRTC-kompatiblen Browser müssen Online Positioning User Support (OPUS) und G711 für Audio und das H.264 Constrained Baseline-Profil für VP8
Eine typische Sprachlösung außerhalb des WebRTC-Ökosystems ermöglicht verschiedene Arten von. CODECs Einige der gebräuchlichsten CODECs sind G.711 µ-Law für Nordamerika, G.711 A-law, G.729 und G.722. Wenn zwei Geräte, die zwei unterschiedliche Geräte verwenden, CODECs miteinander kommunizieren, übersetzt das Media Gateway den CODEC-Fluss zwischen den Geräten. Mit anderen Worten, ein Media Gateway verarbeitet Medien und stellt sicher, dass die Endgeräte miteinander kommunizieren können.
Push-Benachrichtigungen in WebRTC
WebRTC-Implementierungen sind auf Mobilgeräten sehr verbreitet. Im Gegensatz zu Webbrowsern kann ein Mobilgerät eine Websocket-Konnektivität nicht lange aufrechterhalten. Daher muss es sich für alle endenden Anfragen, wie Anrufe und Nachrichten, auf Push-Benachrichtigungen vom WebRTC-Server verlassen.
Mit Amazon Simple Notification Service
Amazon SNS für Push-Benachrichtigungen
WebRTC und WebRTC-Gateway
Mit Web Real-Time Communication (WebRTC) können Sie mithilfe der API einen Anruf von einem Webbrowser aus einrichten oder Ressourcen vom Backend-Server anfordern. Die Technologie wurde unter Berücksichtigung der Cloud-Technologie entwickelt und bietet daher verschiedene Funktionen, mit APIs denen ein Anruf hergestellt werden kann. Da nicht alle Sprachlösungen (einschließlich SIP) diese unterstützen APIs, muss das WebRTC-Gateway API-Aufrufe in SIP-Nachrichten übersetzen und umgekehrt.
Die folgende Abbildung zeigt ein Entwurfsmuster für eine hochverfügbare WebRTC-Architektur. Der eingehende Datenverkehr von WebRTC-Clients wird durch einen Application Load Balancer
Eine grundlegende Topologie eines RTC-Systems für Sprache
Ein weiteres Entwurfsmuster für SIP- und RTP-Verkehr besteht darin, Paare von SBCs auf Amazon EC2 im Aktiv-Passiv-Modus über Availability Zones hinweg zu verwenden, wie in der folgenden Abbildung dargestellt. Hier kann eine Elastic IP-Adresse bei einem Ausfall dynamisch zwischen Instances verschoben werden, wobei der Domain Name Service (DNS) nicht verwendet werden kann.
RTC-Architektur mit Amazon EC2 in einer Virtual Private Cloud (VPC)
