Q : Quel est l’un des risques de communication les plus graves dans un centre de commandement d’urgence ?

R : Il ne s’agit pas toujours d’une panne complète du réseau. Le mur d’images peut continuer à fonctionner, les commutateurs peuvent rester en ligne et les opérateurs à leur poste, alors même que la plateforme de dispatching n’est plus accessible, que les fonctions de dispatching en une touche ne répondent plus, que l’annuaire de contacts devient indisponible et que les procédures d’appel habituellement dépendantes du logiciel s’interrompent soudainement.

Cela pose immédiatement une question pratique : si un opérateur doit contacter un local de permanence sur site, diffuser une annonce d’urgence dans une zone précise, joindre des utilisateurs radio ou appeler un centre de commandement de niveau supérieur, faut-il simplement attendre le rétablissement de la plateforme principale ?

Pour un système de communication chargé de la réponse aux urgences, la réponse devrait clairement être non. La plateforme de commandement et de dispatching peut tomber en panne, mais les communications vocales locales essentielles ne doivent pas tomber avec elle.

Dans cette situation, l’intérêt d’un téléphone SIP de sonorisation n’est pas de remplacer un système complet de commandement et de dispatching. Son rôle est de conserver une interface vocale fixe, relativement indépendante et directe. Avec une architecture adaptée, les opérateurs peuvent encore effectuer des appels point à point, utiliser des lignes directes, lancer des appels de groupe ou des annonces, et accéder aux canaux radio ou aux lignes téléphoniques externes même si le logiciel de dispatching, les serveurs applicatifs ou les réseaux amont sont temporairement indisponibles.

Ces terminaux prennent généralement en charge la connectivité SIP ainsi que le mode mains libres, l’audio amplifié, les touches DSS, les fonctions de ligne directe ou les interfaces audio externes. Dans un centre de commandement d’urgence, la question essentielle n’est pas le nombre de fonctions du téléphone, mais de savoir quelles fonctions de communication restent réellement utilisables après la défaillance de la plateforme la plus complexe.

Quelles capacités de communication peuvent être perdues en cas de panne de la plateforme ?

« Panne de plateforme » n’est pas une description technique très précise. Un centre de commandement d’urgence moderne peut comprendre un logiciel de dispatching, des consoles tactiles, des téléphones SIP, un PBX IP, des serveurs de communications unifiées, des SBC, des services de sonorisation, des services d’enregistrement et des bases de données. Il peut également être relié à des systèmes radio, au PSTN, à la vidéo, aux alarmes et à plusieurs sites distants.

Deux incidents peuvent tous deux apparaître à l’opérateur comme « le système de dispatching est en panne », alors que leurs points de défaillance réels sont totalement différents.

C’est la première distinction importante à faire lors de l’évaluation de la résilience des communications d’urgence : « la plateforme de dispatching ne peut pas être utilisée » ne signifie pas « toutes les communications sont indisponibles ».

Si le dispatching logiciel, l’enregistrement SIP, le routage de numérotation, le contrôle de sonorisation et les communications externes dépendent tous d’un même nœud central, une panne unique peut affecter tous les services en même temps. En revanche, si le contrôle d’appel de base est correctement séparé des applications de niveau supérieur, la perte de fonctions avancées n’empêche pas nécessairement les opérateurs d’utiliser des téléphones fixes pour les communications critiques.

Pourquoi un terminal SIP fixe peut-il rester une interface de communication locale ?

Le principal avantage d’une console de dispatching logicielle est de réunir la téléphonie, la sonorisation, la radio, la vidéo, les conférences et les alarmes dans une même interface d’exploitation. Ce niveau d’intégration est précieux en fonctionnement normal, mais il signifie également qu’une défaillance de la couche applicative peut soudainement supprimer le point d’accès habituel de l’opérateur à plusieurs ressources de communication.

Un téléphone SIP fixe a un autre objectif. Il n’a pas besoin de gérer l’ensemble du flux de traitement d’un incident. Sa mission principale est de conserver la fonction la plus directe : établir une communication vocale entre les personnes.

En fonctionnement normal, un opérateur peut utiliser le logiciel de dispatching pour rechercher des contacts, établir des conférences ou ouvrir une vue GIS. Si le poste de dispatching tombe en panne, les touches DSS fixes du téléphone peuvent encore donner un accès direct au responsable de permanence, à la salle de contrôle incendie, au local technique ou à d’autres postes critiques.

Dans les situations où le temps est critique, la simplicité peut elle-même devenir une forme de fiabilité.

Un terminal ne comportant que quelques touches de ligne directe clairement attribuées peut avoir davantage de valeur en urgence qu’une interface riche en fonctions dépendant de bases de données, de serveurs applicatifs et de multiples composants logiciels.

Les fonctions mains libres et d’audio amplifié d’un téléphone SIP de sonorisation peuvent également être utiles dans les salles de contrôle où travaillent plusieurs opérateurs. Lors d’un appel urgent, le personnel à proximité peut entendre les informations importantes sans obliger l’opérateur à rester au combiné. Les déploiements réels doivent néanmoins tenir compte du larsen acoustique, du bruit ambiant, de la confidentialité et des interférences entre postes voisins.

Définir les domaines de défaillance avant de concevoir le repli local

L’une des erreurs les plus courantes dans la conception du repli consiste à supposer que l’ajout d’un équipement crée automatiquement une redondance du système.

Par exemple, deux serveurs SIP peuvent sembler constituer une architecture principale et de secours. Mais si les deux machines virtuelles fonctionnent sur le même hôte physique, passent par le même commutateur cœur, utilisent la même liaison montante et dépendent du même UPS, elles partagent encore plusieurs conditions majeures de défaillance.

Un serveur de secours peut être utile lorsque le serveur principal lui-même tombe en panne, mais une défaillance du commutateur, de l’hôte de virtualisation ou de l’alimentation peut encore mettre les deux systèmes hors service simultanément.

La continuité des communications locales doit donc être conçue autour de niveaux de défaillance précis.

• Défaillance de la couche applicative : Le logiciel de dispatching est indisponible, mais les appels SIP restent opérationnels.

• Défaillance de la couche plateforme : Le nœud applicatif principal tombe en panne et le contrôle d’appel local de secours maintient les communications essentielles.

• Défaillance WAN : La plateforme de niveau supérieur devient injoignable tandis que la téléphonie locale, la sonorisation et la radio continuent de fonctionner.

• Défaillance LAN : Une commutation redondante, des liaisons montantes doubles ou une autre méthode de communication locale sont nécessaires.

• Défaillance électrique : Des systèmes UPS, une alimentation de secours et, si nécessaire, des méthodes de communication indépendantes sont requis.

Le niveau de résilience requis doit être défini dès la conception du système. Un simple local de permanence d’entreprise et un centre de commandement d’urgence destiné à la sécurité publique, à l’énergie, au transport ou à un grand site industriel n’exigent pas nécessairement le même niveau de continuité.

Un principe utile est simple : le chemin de secours ne doit pas partager exactement les mêmes points uniques de défaillance que le chemin principal.

Comment construire un système pratique de communication locale de secours ?

L’utilité d’un téléphone SIP de sonorisation après une panne de plateforme ne dépend pas d’une seule fonction. Elle repose sur le fonctionnement conjoint du contrôle d’appel local, de l’enregistrement de secours, de la numérotation, de l’accès aux ressources de sonorisation et de radio, de l’architecture réseau et de la continuité électrique.

Maintenir le contrôle d’appel de base sur le site

Si l’ensemble de l’enregistrement des extensions et du contrôle d’appel d’un centre de commandement d’urgence est hébergé dans un centre de données distant ou une plateforme cloud, une panne WAN peut empêcher deux téléphones SIP situés dans le même bâtiment de s’appeler avec leurs numéros d’extension habituels.

Pour les sites critiques, un PBX IP, un serveur SIP ou un nœud de communication doté d’une capacité de continuité locale peut être conservé sur place. En fonctionnement normal, le site peut rester administré de façon centralisée. Si la liaison amont ou la plateforme applicative principale tombe en panne, le nœud local continue d’assurer la numérotation essentielle et les fonctions de contrôle d’appel.

Le système de secours n’a pas besoin de reproduire toutes les capacités de la plateforme principale de commandement. Le GIS, la liaison vidéo, les conférences complexes, les flux de gestion d’incident et l’accès aux données historiques peuvent être temporairement dégradés tandis que la communication vocale critique entre personnes reste disponible.

Les rôles peuvent être résumés simplement : la plateforme principale fournit l’expérience opérationnelle complète, tandis que le nœud local maintient les communications essentielles.

Solution associée : Système de dispatching téléphonique IP pour centres de commandement et de contrôle

Prévoir un enregistrement SIP principal et de secours

Les terminaux disposant des capacités requises peuvent être configurés avec un serveur SIP principal et un serveur SIP de secours, ou avec un autre mécanisme de double enregistrement ou de basculement. Si le nœud principal devient injoignable, le terminal peut passer sur un service de contrôle d’appel de secours et continuer à établir de nouveaux appels.

Les fournisseurs mettent en œuvre ce comportement de différentes manières. Certains terminaux maintiennent deux comptes simultanément, d’autres utilisent des priorités de serveur principal et secondaire, tandis que d’autres s’appuient sur DNS, le fonctionnement en cluster ou des mécanismes de haute disponibilité côté serveur.

La présence de deux adresses de serveur dans une page de configuration ne prouve pas que le basculement fonctionne correctement. Les essais doivent déterminer la vitesse de détection d’une panne du nœud principal, la durée du réenregistrement, le comportement des appels en cours, le moment où les nouveaux appels redeviennent possibles et le retour éventuel du terminal vers le nœud principal après rétablissement.

Il est tout aussi important de vérifier si les serveurs principal et de secours partagent encore le même domaine de défaillance physique. S’ils dépendent tous deux d’un même commutateur cœur ou d’un même circuit électrique, leur résilience réelle reste limitée.

Conserver des numéros et des touches familiers pendant une panne

Même un système de secours techniquement complet a une valeur limitée si les opérateurs ne peuvent pas l’utiliser rapidement.

Après une panne de la plateforme principale, demander au personnel de mémoriser un nouveau préfixe de numérotation, d’utiliser d’autres extensions ou de saisir manuellement des adresses IP peut provoquer des erreurs supplémentaires précisément au plus mauvais moment.

Les destinations critiques telles que le responsable d’incident, le superviseur de permanence, la salle de contrôle incendie, le contrôle de sonorisation, la passerelle radio, le local technique et les autres postes de permanence peuvent recevoir des numéros courts fixes, des touches DSS ou des lignes directes.

Le fonctionnement normal et le mode de secours devraient conserver, dans la mesure du possible, la même numérotation et les mêmes habitudes d’utilisation. Le système en arrière-plan doit modifier le routage réel sans imposer à l’opérateur un nouveau mode opératoire.

Certains postes d’urgence peuvent également utiliser une ligne directe ou la numérotation automatique au décrochage, de sorte que le simple fait de prendre le combiné établisse immédiatement la connexion vers une destination prédéfinie. Ces fonctions doivent être configurées selon les responsabilités opérationnelles et le risque d’activation accidentelle, plutôt que d’être appliquées à tous les terminaux.

Conserver des accès alternatifs à la sonorisation, à la radio et aux lignes externes

La réponse d’urgence ne dépend pas uniquement des appels téléphoniques. Un responsable peut devoir diffuser immédiatement une annonce dans une zone précise, contacter le personnel de terrain via DMR, PDT, TETRA, PoC ou un autre système radio, puis joindre des organismes externes par le réseau téléphonique public.

Si toutes ces ressources ne sont accessibles que par l’application principale de dispatching, une défaillance logicielle peut supprimer plusieurs canaux de communication en même temps.

Un téléphone SIP de sonorisation peut utiliser des numéros prédéfinis pour accéder à ces ressources. Il peut appeler une passerelle SIP de sonorisation pour entrer dans une zone d’annonce, se connecter à un canal radio via une passerelle RoIP ou utiliser une interface FXO, un trunk SIP ou une autre passerelle vocale pour l’accès téléphonique externe.

       Téléphone SIP de sonorisation
       → Contrôle d’appel SIP local
       → Passerelle de sonorisation / Passerelle RoIP / Passerelle vocale externe
       → Haut-parleurs du site / Système radio / PSTN    

Cette architecture permet aux opérateurs d’accéder à d’autres systèmes de communication depuis un terminal vocal fixe même lorsque le poste de dispatching plus complexe n’est pas disponible.

Protéger également le réseau et l’infrastructure électrique

De nombreux systèmes de communication utilisent des serveurs redondants tout en dépendant d’un unique commutateur PoE au niveau de l’accès. Si ce commutateur perd son alimentation, tous les téléphones connectés peuvent tomber hors ligne en même temps, rendant le double enregistrement SIP sans intérêt.

Selon le niveau de résilience requis, les terminaux critiques peuvent utiliser des chemins de commutation redondants, les équipements du cœur de réseau peuvent disposer de doubles alimentations ou être déployés en redondance, et les commutateurs PoE, serveurs SIP locaux, passerelles de sonorisation et passerelles RoIP peuvent être inclus dans la charge secourue par UPS.

Les déploiements répartis sur plusieurs salles ou bâtiments doivent également examiner les commutateurs d’agrégation, les liaisons fibre et les chemins montants afin d’identifier d’autres points uniques de défaillance.

La conception de l’UPS ne doit pas s’appuyer uniquement sur une indication telle que « deux heures d’autonomie ». La charge critique réelle doit être calculée à partir de la consommation PoE, des serveurs, des terminaux vocaux et de toutes les passerelles indispensables qui doivent rester opérationnelles pendant la coupure.

Les sites qui doivent continuer à fonctionner lors de graves défaillances d’infrastructure peuvent également avoir besoin de radio, de lignes directes analogiques, de communications par satellite ou d’autres moyens extérieurs à l’environnement IP principal, afin que l’ultime niveau d’urgence ne dépende pas des mêmes conditions de réseau et d’alimentation.

Quelles capacités faut-il préserver en priorité lorsque la plateforme est dégradée ?

La conception du repli néglige souvent un autre point important : un système en mode dégradé n’a pas besoin de conserver toutes les fonctions de la plateforme normale.

Un système de commandement peut inclure le GIS, la vidéosurveillance, les conférences, la lecture des enregistrements, la messagerie, la corrélation d’alarmes et les annuaires de contacts. Reproduire toutes ces fonctions dans un environnement de secours peut rendre la plateforme de repli de plus en plus complexe et dépendante de nombreux services identiques à ceux du système principal.

Une approche plus pratique consiste à définir la capacité minimale de communication acceptable pendant une urgence.

Les priorités les plus élevées sont généralement les appels point à point entre fonctions critiques, les lignes directes fixes, l’accès à la sonorisation d’urgence, l’accès radio et les appels externes essentiels. Le maintien de l’enregistrement, des conférences, de la vidéo ou du GIS dépend du niveau opérationnel et des exigences du projet.

Il s’agit en pratique d’une forme maîtrisée de dégradation des communications.

En fonctionnement normal, le personnel peut utiliser l’environnement complet de dispatching convergent. Si une partie de la plateforme tombe en panne, le système revient à un mode d’exploitation plus simple mais plus stable. Ce n’est qu’en cas de défaillances réseau ou électriques plus graves que les communications basculent davantage vers la radio ou d’autres chemins de secours indépendants.

Pour les communications d’urgence, la perte temporaire de fonctions avancées est gérable ; perdre la capacité de transmettre des instructions essentielles ne l’est pas.

Pourquoi « Enregistré » et « En ligne » ne prouvent-ils pas que le service fonctionne réellement ?

Lors des essais de recette des systèmes d’urgence, l’état du terminal reçoit souvent plus d’importance qu’il ne le mérite.

L’écran allumé d’un téléphone SIP de sonorisation prouve seulement que l’appareil est alimenté. Une icône réseau indique un certain niveau de connectivité. L’état « Enregistré » signifie que le terminal s’est enregistré auprès d’un serveur d’enregistrement SIP. Aucun de ces états ne prouve à lui seul qu’un appel de bout en bout peut réellement aboutir.

       L’appareil est alimenté
       ≠ Le LAN est entièrement opérationnel
       ≠ Le service SIP est entièrement opérationnel
       ≠ Le plan de numérotation est correct
       ≠ Le chemin média RTP est joignable
       ≠ Le terminal distant peut mener un appel normal à terme    

Le problème courant « enregistré mais sans audio » l’illustre clairement. La signalisation SIP peut réussir alors que RTP échoue à cause du routage, du NAT, de règles de pare-feu, de la négociation des codecs ou d’un problème de passerelle média.

Les appels faisant intervenir la sonorisation ou la radio nécessitent aussi de vérifier que la passerelle SIP, la passerelle RoIP ou le service de sonorisation lui-même restent opérationnels.

Les communications d’urgence doivent donc être validées par des services réels : passer un véritable appel et confirmer l’audio bidirectionnel ; accéder à une véritable zone de sonorisation et vérifier que les haut-parleurs de terrain diffusent l’annonce ; se connecter à un canal radio et confirmer la communication bidirectionnelle entre la salle de contrôle et les radios de terrain. « Enregistré » n’est qu’un état de signalisation. C’est le résultat opérationnel réel qui doit être validé.

Comment les opérateurs doivent-ils savoir ce qui fonctionne encore après une panne ?

Les ingénieurs télécom peuvent comprendre la relation entre serveurs principaux, serveurs de secours, états d’enregistrement et routage réseau, mais la personne assise au poste de dispatching pendant une urgence n’est pas nécessairement un ingénieur télécom.

Si une panne du système principal ne fait que changer une petite icône d’état du vert au gris, l’opérateur peut ne pas se rendre compte que le terminal est passé en mode de repli.

Les pannes de plateforme sont rarement aussi simples que « tout fonctionne » ou « tout est en panne ». Certaines fonctions peuvent rester disponibles tandis que d’autres ont échoué. Sans retour clair, les opérateurs sont contraints de découvrir l’état du système par essais successifs.

Lorsque les capacités du terminal le permettent, les postes critiques peuvent afficher les états d’enregistrement principal et de secours, l’état du réseau ou la disponibilité des lignes directes essentielles. Les touches DSS doivent privilégier les destinations importantes en urgence plutôt que simplement maximiser le nombre de contacts mémorisés.

Un écran tactile comportant des dizaines de contacts dynamiques et des icônes sophistiquées peut devenir inutilisable si sa base de données en arrière-plan tombe en panne. Un petit nombre de touches fixes libellées « Superviseur de permanence », « Contrôle incendie », « Sonorisation », « Radio » et « Ligne externe » peut produire un résultat bien plus prévisible en mode dégradé.

Du point de vue opérationnel, la résilience se vérifie par un test très simple : après un changement d’état de la plateforme, les opérateurs ne devraient pas avoir à comprendre d’abord la panne avant de pouvoir passer le prochain appel critique.

Pourquoi les essais de recette doivent-ils provoquer volontairement des pannes ?

De nombreux projets effectuent des essais approfondis de fonctionnement normal avant la livraison : les appels aboutissent, la sonorisation fonctionne, les enregistrements peuvent être relus et le logiciel de dispatching est accessible. Ces essais prouvent que le système fonctionne en conditions normales, mais pas que le repli fonctionnera au moment où il sera nécessaire.

La continuité des communications locales doit être validée en provoquant volontairement des pannes.

La plateforme principale de dispatching peut être arrêtée pour vérifier si les terminaux fixes atteignent encore les postes critiques. Le WAN amont peut être déconnecté afin de confirmer que les numéros d’extension locaux restent utilisables. Le serveur SIP principal peut être arrêté pour mesurer le temps nécessaire aux terminaux pour détecter la panne et passer sur le nœud de secours. Certains chemins réseau peuvent également être coupés afin de confirmer que la redondance prend réellement le relais.

Si le projet comprend un UPS, une coupure du réseau électrique doit également être simulée afin de mesurer l’autonomie réelle des commutateurs PoE, serveurs SIP, passerelles et terminaux critiques.

Un exercice pratique de panne peut comprendre les étapes suivantes :

1. Consigner l’état normal des terminaux, serveurs et passerelles critiques.

2. Arrêter volontairement la plateforme principale ou le nœud SIP principal.

3. Confirmer que les terminaux passent dans l’état de repli attendu.

4. Appeler les postes opérateurs critiques et les lignes directes fixes.

5. Vérifier l’audio bidirectionnel réel plutôt que le seul état d’enregistrement.

6. Tester le point d’entrée de sonorisation de secours.

7. Vérifier la radio et les chemins d’appel externes requis.

8. Rétablir le système principal et observer le retour vers le fonctionnement normal.

9. Examiner les alarmes, les journaux et la chronologie de la panne.

10. Documenter toute étape nécessitant encore une intervention manuelle.

Le retour vers le système principal après son rétablissement est tout aussi important. Certains problèmes n’apparaissent pas lorsque le trafic passe vers le système de secours, mais seulement au retour du nœud principal, par exemple des enregistrements en double, un routage incorrect ou des terminaux qui ne reviennent pas au nœud principal.

Qu’est-ce qui définit des communications d’urgence fiables ?

Aucune plateforme de commandement et de dispatching ne peut garantir que ses logiciels, serveurs, réseaux et son infrastructure électrique ne tomberont jamais en panne. Le véritable objectif de la conception des communications d’urgence n’est pas d’éliminer toute défaillance possible, mais de faire en sorte qu’un niveau approprié de capacité de communication reste disponible après une panne.

Un téléphone SIP de sonorisation joue un rôle simple mais important dans cette architecture : il conserve la possibilité pour une personne d’initier directement une communication vocale sans dépendre entièrement d’une interface logicielle complexe.

En fonctionnement normal, il peut servir de terminal SIP dans l’environnement unifié de dispatching. Si la plateforme principale tombe en panne, il peut continuer à joindre les postes critiques grâce au contrôle d’appel local, à l’enregistrement de secours et à des numéros fixes. Associée aux passerelles de sonorisation, passerelles RoIP et passerelles vocales externes, la même interface vocale de base peut également donner accès à la sonorisation du site, aux réseaux radio et au PSTN.

L’architecture peut ainsi prendre en charge plusieurs niveaux de fonctionnement dégradé :

       Fonctionnement normal : la plateforme unifiée assure le dispatching centralisé
       → Défaillance logicielle : les terminaux SIP fixes conservent les appels de base
       → Défaillance WAN : le contrôle d’appel local maintient les communications sur site
       → Défaillance d’un chemin vocal : la sonorisation, la radio ou les lignes externes fournissent des chemins alternatifs
       → Défaillance grave de l’infrastructure : des moyens indépendants de communication d’urgence assurent l’ultime secours    

Cette approche n’exige pas que toutes les fonctions avancées restent disponibles dans toutes les conditions de panne. Le GIS peut être temporairement indisponible, la récupération vidéo peut s’arrêter et les conférences complexes peuvent être dégradées. Ce qui doit subsister est la capacité la plus fondamentale de réponse d’urgence :

quelqu’un peut passer l’appel, quelqu’un peut l’entendre, les informations critiques peuvent être transmises et les instructions essentielles continuent d’atteindre les personnes qui en ont besoin.

Questions fréquentes

L’enregistrement doit-il continuer pendant le repli local ?

Cela dépend des exigences opérationnelles et de conformité. La sécurité publique, l’énergie, le transport et certains grands environnements industriels d’urgence peuvent exiger que les communications vocales critiques restent enregistrées. Si l’enregistrement est obligatoire, la conception doit vérifier si les médias atteignent encore un service d’enregistrement disponible pendant le repli ou si une capacité d’enregistrement locale indépendante est requise.

Chaque centre de commandement de site secondaire a-t-il besoin de son propre contrôle d’appel local ?

Pas nécessairement. La décision dépend de l’importance du site, de la fiabilité du WAN, du nombre de terminaux et de la durée d’interruption acceptable. Le contrôle d’appel local est plus utile sur les sites qui doivent continuer à fonctionner de manière autonome lorsque le réseau amont est indisponible. Les petites antennes peuvent être suffisamment couvertes par d’autres architectures centralisées à haute disponibilité.

Les serveurs SIP principal et de secours doivent-ils provenir du même fournisseur ?

Ce n’est pas une exigence absolue. Toutefois, un déploiement multifournisseur augmente les tests d’interopérabilité nécessaires pour l’enregistrement SIP, le routage de numérotation, les codes de fonction, les états de souscription et le comportement de basculement. « Les deux prennent en charge SIP » ne suffit pas à prouver qu’une redondance transparente fonctionnera avec les terminaux et services réels.

Quand faut-il conserver un moyen de communication indépendant en dehors du système IP ?

Si les exigences de continuité couvrent une panne du LAN cœur, des coupures électriques prolongées, des catastrophes majeures ou des interruptions étendues du réseau public, il convient d’envisager la radio, des lignes directes analogiques, les communications par satellite ou une autre méthode appartenant à un domaine de défaillance différent. La conception finale doit refléter le niveau de risque du site, son environnement d’exploitation et les exigences applicables du projet.

Becke Telcom fournit des téléphones SIP de sonorisation, des systèmes de dispatching téléphonique IP, l’intégration RoIP, la sonorisation IP et différentes passerelles vocales pour les centres de commandement d’urgence, les sites industriels et les infrastructures critiques. Ces composants peuvent être utilisés pour construire une architecture de communication combinant le dispatching centralisé en fonctionnement normal et le repli local, en fonction des postes critiques du site, du réseau existant, des scénarios de panne et des chemins de secours nécessaires.