Composants fondamentaux de l'architecture RTC - Communication en temps réel sur AWS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Composants fondamentaux de l'architecture RTC

Dans le secteur des télécommunications, le RTC fait généralement référence à des sessions multimédia en direct entre deux terminaux avec une latence minimale. Ces sessions peuvent être liées à :

  • Une session vocale entre deux parties (système téléphonique, mobile ou voix sur IP (VoIP))

  • Messagerie instantanée (telle que le chat et le chat par relais instantané (IRC))

  • Séance vidéo en direct (comme la visioconférence et la téléprésence)

Chacune des solutions précédentes possède certains composants en commun (tels que des composants qui fournissent l'authentification, l'autorisation et le contrôle d'accès, le transcodage, la mise en mémoire tampon et le relais, etc.) et des composants spécifiques au type de média transmis (tels que le service de diffusion, le serveur de messagerie et les files d'attente, etc.). Cette section se concentre sur la définition d'un système RTC basé sur la voix et la vidéo et de tous les composants associés, comme illustré dans la figure suivante.

Schéma illustrant les composants architecturaux essentiels du RTC.

Composants architecturaux essentiels pour RTC

Softswitch/PBX

Un commutateur logiciel ou PBX est le cerveau d'un système de téléphonie vocale et fournit des informations pour établir, maintenir et acheminer un appel vocal au sein ou en dehors de l'entreprise en utilisant différents composants. Tous les abonnés de l'entreprise doivent s'inscrire auprès du softswitch pour recevoir ou passer un appel. L'une des fonctionnalités importantes du softswitch est de suivre chaque abonné et de savoir comment le joindre en utilisant les autres composants du réseau vocal. 

Contrôleur de session en bordure (SBC)

Un contrôleur de session frontalier (SBC) se trouve à la périphérie d'un réseau vocal et assure le suivi de tout le trafic entrant et sortant (plans de contrôle et de données). L'une des principales responsabilités d'un SBC est de protéger le système vocal contre toute utilisation malveillante. Le SBC peut être utilisé pour s'interconnecter avec des troncs du protocole d'initiation de session (SIP) pour une connectivité externe. Certains offrent SBCs également des fonctionnalités de transcodage pour la conversion CODECsd'un format à un autre. La plupart offrent SBCs également des fonctionnalités de traversée de la traduction d'adresses réseau (NAT), ce qui permet de garantir que les appels sont établis, même sur des réseaux protégés par un pare-feu.

Connectivité PSTN

Les solutions de voix sur IP (VoIP) utilisent des passerelles du réseau téléphonique public commuté (PSTN) et des troncs SIP pour se connecter aux réseaux PSTN existants.

Passerelle PSTN

La passerelle PSTN convertit le signal entre le protocole SIP SS7 et le média entre le protocole de transport en temps réel (RTP) et le multiplexage par répartition dans le temps (TDM) à l'aide du transcodage CODEC. Les passerelles PSTN sont toujours situées à la périphérie, à proximité du réseau PSTN.

Tronc SIP

Dans une liaison SIP, l'entreprise n'envoie pas ses appels sur un réseau TDM (SS7 basé sur le TDM), mais les flux entre l'entreprise et l'opérateur téléphonique restent sur IP. La plupart des troncs SIP sont établis en utilisant SBCs. L'entreprise doit se mettre d'accord sur les règles de sécurité prédéfinies par les opérateurs télécoms, telles que l'autorisation d'un certain nombre d'adresses IP, de ports, etc.

Passerelle multimédia (transcodeur)

Les utilisateurs communiquent en temps réel par audio et/ou vidéo, ainsi que par le biais de données facultatives et d'autres informations. Pour communiquer, les deux appareils doivent être en mesure de s'entendre sur un codec mutuellement compris pour chaque piste multimédia, afin de pouvoir communiquer et présenter avec succès le contenu multimédia partagé. Tous les navigateurs compatibles avec WebRTC doivent prendre en charge le support utilisateur de positionnement en ligne (OPUS) et le G711 pour le son, ainsi que le profil de ligne de base contrainte VP8H.264 pour la vidéo. 

Une solution vocale typique en dehors de l'écosystème WebRTC permet différents types de. CODECs Parmi les plus courantes, citons la loi CODECs G.711 µ-law pour l'Amérique du Nord, la loi G.711 A, la G.729 et la G.722. Lorsque deux appareils utilisant deux appareils différents CODECs communiquent entre eux, la passerelle multimédia traduit le flux de CODEC entre les appareils. En d'autres termes, une passerelle multimédia traite le contenu multimédia et garantit que les appareils finaux sont en mesure de communiquer entre eux.

Notifications push dans WebRTC

Les implémentations du WebRTC sont très courantes sur les appareils mobiles. Contrairement aux navigateurs Web, un appareil mobile ne peut pas maintenir une connectivité Websocket ouverte pendant longtemps. Par conséquent, il doit s'appuyer sur les notifications push du serveur WebRTC pour toutes les demandes de fin, telles que les appels et les messages.

Amazon Simple Notification Service (Amazon SNS) vous permet d'envoyer des notifications push à des applications sur des appareils mobiles. Ces applications peuvent fonctionner sur différents systèmes d'exploitation tels qu'Apple iOS ou Android. La figure suivante présente un aperçu général du flux de notifications push, d'un serveur de notifications WebRTC aux points de terminaison mobiles WebRTC.

Schéma illustrant Amazon SNS pour les notifications push.

Amazon SNS pour les notifications push

Passerelle WebRTC et WebRTC

La communication Web en temps réel (WebRTC) vous permet d'établir un appel depuis un navigateur Web ou de demander des ressources au serveur principal à l'aide de l'API. La technologie est conçue en tenant compte de la technologie cloud et fournit donc divers APIs éléments qui pourraient être utilisés pour établir un appel. Comme toutes les solutions vocales (y compris SIP) ne les prennent pas en charge APIs, la passerelle WebRTC est requise pour traduire les appels d'API en messages SIP et vice versa.   

La figure suivante montre un modèle de conception pour une architecture WebRTC à haute disponibilité. Le trafic entrant provenant des clients WebRTC est équilibré par un Application Load Balancer (ALB), WebRTC s'exécutant sur des instances Amazon Elastic Compute Cloud (Amazon) faisant partie d'un groupe EC2 Amazon Auto Scaling. EC2

Topologie de base d'un système RTC pour la voix.

Topologie de base d'un système RTC pour la voix

Un autre modèle de conception pour le trafic SIP et RTP consiste à utiliser des paires SBCs sur Amazon EC2 en mode actif-passif entre les zones de disponibilité, comme le montre la figure suivante. Ici, une adresse IP élastique peut être déplacée dynamiquement entre les instances en cas de défaillance, lorsque le service de nom de domaine (DNS) ne peut pas être utilisé.

Schéma illustrant l'architecture RTC utilisant Amazon EC2 dans un cloud privé virtuel (VPC).

Architecture RTC utilisant Amazon EC2 dans un cloud privé virtuel (VPC)