Connexion ou Inscription (DFL)

FAQs DFL

Comment est défini le champ «région d’alerte» dans une alerte?

Le système ADNA utilise la  Classification géographique type de 2006 (Mise à jour mai 2010) de Statistique Canada (LIEN). Cette norme permet des champs à plusieurs niveaux pour la localisation d’une alerte et une alerte peut avoir soit un, soit une combinaison de ces niveaux de localisation:

Province / Territoire> Division de recensement > Sous-division de recensement.

 Selon cette norme une alerte émise pour le Québec aura un code CGT «24» et si elle a été émise  pour une région au Québec, cela commencera toujours par un code CGT de « 24 … ». Dépendamment de la façon dont un DFL reçoit les alertes, s’ils disposent d’un outil, celui-ci peut être utilisé pour filtrer les alertes selon le code de localisation « 24 … » ou les codes commençant par « 24 … ».

Dans le fichier de PAC de l’alerte, ce code peut être trouvé dans les champs suivants (une alerte peut avoir plusieurs champs de géocodage pour plusieurs endroits):

Que devrait faire un DFL s’il reçoit des alertes corrompues?

Si l’alerte corrompue est due à un échec du DSS, le DFL devrait nous le signaler et rejeter l’alerte corrompue. (Veuillez noter que la vérification de la signature est à la discrétion des DFL, s’ils ne vérifient aucune signature et diffusent une alerte altérée, il en va de leur propre responsabilité, mais nous leur recommandons au moins de vérifier la signature des messages de diffusion).

Plusieurs Flux sont disponibles; il est recommandé aux DFL de surveiller plus d’un flux à des fins de redondance. Cela permettra également de déterminer si l’alerte est endommagée sur un flux ou sur tous. Si un seul flux est affecté, ils peuvent utiliser l’alerte valide correspondante venant d’un autre flux.

Si l’alerte est corrompue en raison d’un problème de transmission ou d’application sur tous les flux du côté du DFL ou si le DFL ne surveille qu’un seul flux, alors il devra utiliser des mécanismes auxiliaires pour récupérer l’alerte. Les messages sont conservés dans leur forme intégrale pendant 48 heures (dans un emplacement à court terme) pour récupération automatique par un DFL.

Quel est le processus pour traiter une situation où un DFL reçoit des données corrompues dans le flux d’alerte au public?

Il pourrait y avoir 2 possibilités :

  1. Le DFL reçoit une alerte complète, mais le contenu de l’alerte est corrompu ou il pense qu’elle a été altérée.
  2. Ils ont reçu un fichier de données incomplet, une alerte sans balises XML de début ou de fin etc.

En fonction de cela :

  1. Une vérification de la signature numérique de l’alerte confirmera si l’alerte a été corrompue ou altérée ou pas. Une alerte aura 1 ou 2 signatures numériques. Le DFL peut vérifier que l’alerte a bien été envoyée par le système ADNA en validant signature numérique avec le serveur DSS du système ADNA. Cela permet de vérifier que le message n’a pas été altéré durant la transmission du système ADNA au DFL. Si cela est valide, alors le DFL peut également s’assurer que l’alerte originale n’a pas été modifiée ou altérée en aucune façon en validant la signature du diffuseur avec le DSS de l’organisation émettrice. Pour ces deux validations, les DFL devront créer des requêtes SOAP en XML par https (suivant la norme OASIS-DSS) auprès du DSS du système ADNA / de l’émetteur pour valider les signatures. Il est recommandé aux DFL de vérifier les signatures de tous les messages d’alerte destinés au public. Lorsque les deux signatures sont présentes, il est préférable de vérifier la signature de l’émetteur vu qu’elle vérifie la source d’origine. La section “Annexe 4: Signatures numériques” du guide de l’utilisateur DFL explique cela plus en détail.

Si le DFL a reçu un fichier incomplet, cela est probablement dû à un problème de transmission, par exemple une connexion internet lente, un problème avec la communication par satellite…Toutefois, cela serait du côté du DFL. Les distributeurs de fin de ligne devraient vérifier leurs systèmes et les fixer ou les améliorer au besoin. (la raison pour laquelle nous affirmons que le problème est du côté du DFL est dû au fait que nous vérifions toutes les transmissions sur les flux du système ADNA, toute donnée dont l’envoie sur un flux échoue montrera un traçage incomplet).

Pour vérifier la signature numérique du système ADNA, le document d’aide fait mention d’un ‘RequestID’ et d’un profil. Où pouvons-nous obtenir ces valeurs?

L’identifiant de la requête (“RequestID”) et le profil sont des valeurs qui devraient être générés par l’émetteur de la requête. Les deux sont traités comme des chaînes. Par exemple, un DFL peut utiliser l’identifiant de l’alerte dans le “RequestID” ou peut utiliser un identifiant généré automatiquement si leur système est équipé. Le profil est l’identifiant du DFL, cela devrait être une courte chaîne qui identifie l’émetteur de la requête, par exemple le nom l’organisation du DFL.

Y at-il une méthode pour valider la signature numérique, en utilisant une clé publique ADNA par exemple, sans se connecter au serveur SOAP DSS?

Non, le DSS du système ADNA a été implémenté comme un serveur SOAP DSS. Le Distributeur de fin de ligne devra formater une requête DSS et faire un appel SOAP au serveur web DSS, dont l’URL est dans la signature.

Le protocole d’alerte commun (PAC) inclue une clause stipulant que l’alerte peut ne pas être signée. Est-ce que toutes les alertes sont signées?

La sécurité du système ADNA est notre plus haute priorité.

Le système ADNA prend en charge le protocole SSL. Chaque alerte envoyée à travers le système aura toujours 1 ou 2 signatures:

  1. La première est une signature numérique produite par l’émetteur (AGA) permettant de vérifier que l’alerte est authentique et provient spécifiquement du diffuseur et qu’elle n’a pas été modifiée. Cette signature est facultative et à la discrétion de l’organisation du diffuseur. Ainsi, elle peut aussi bien être ou ne pas être présente.
  2. La deuxième est la signature numérique du système ADNA dans le message d’alerte, en plus de la signature du diffuseur. Elle sera toujours présente dans les alertes diffusées par système ADNA. Elle peut être utilisée par le DFL pour confirmer que les messages d’alerte sont reçus du système ADNA.

 Lorsqu’une alerte est reçue, le distributeur de fin de ligne a la possibilité de vérifier soit l’une, soit les deux signatures pour valider que l’alerte provient bien du système ADNA (c’est à dire qu’elle n’a pas été altérée durant la transmission par Internet, après l’envoi) et également confirmer que le message d’alerte original du diffuseur est authentique et intact.

Pour plus de détails, veuillez-vous référer au guide d’utilisation du DFL disponible sur notre site d’alerte publique.

Pourrait-il y avoir des problèmes liés au réarrangement des paquets pendant l’écoute du flux par satellite via une configuration basée sur un récepteur Cisco?

Afin de recevoir les paquets UDP du récepteur satellite (indépendamment du fait qu’ils proviennent du satellite en bande C ou en bande Ku), une application de socket UDP (client) doit être utilisé par le DFL (le système ADNA ne fournit pas cette application). Cette application devra être dans le même segment de réseau que le récepteur satellite, et elle devrait enregistrer et recevoir les paquets envoyés au l’adresse IP du groupe de multidiffusion : 224.0.10.10.

Le port de destination UDP 25555 doit être utilisé pour recevoir des données. L’application doit recevoir des données à partir de ce port et réassembler les paquets pour recevoir les données XML PAC-PC.

Les paquets UDP doivent être assemblés dans l’ordre dans lequel ils sont reçues, afin de rassembler les paquets en données XML de PAC-PC. Il n’y a aucune autre information pour indiquer la séquence des données du paquet UDP dans le XML de PAC-PC.

Afin de minimiser les problèmes de réarrangements des  paquets UDP (comme cela pourrait arriver selon les spécifications du protocole), le DFL doit directement connecter le système / ordinateur de décodage au récepteur satellite à l’aide d’un câble Ethernet.

Est-il obligatoire que la sortie du récepteur Cisco soit en multidiffusion?

Le récepteur que nous mentionnons dans le guide d’utilisation du DFL n’offre pas la possibilité de changer (remplacer) l’adresse IP de destination / multicast; l’IP de destination est définie au niveau de l’équipement qui envoie le flux.

Est-il possible d’obtenir les alertes en streaming par le biais de la fibre (connexions par fibre dédiée) autrement que par les sites de TCP et les flux de satellite? Sera-t-il possible de prendre en charge des connexions directes à l’avenir?

Lorsque le système ADNA a été conçu, Pelmorex a délibérément évité la conception de connexion point à point, la principale raison étant l’engagement pris envers le CRTC et le Conseil de gouvernance de Pelmorex  de diffuser des alertes à tout le monde sur le domaine public sans restrictions et pour mettre les alertes, en toute équité, à la disposition de tout le monde, suivant les mêmes termes et conditions.

Pelmorex n’a pas l’intention de changer le système pour supporter des connexions directes spécifiques ou personnalisées pour un utilisateur.

Le système ADNA distribue des alertes sur la bande Ku et la bande C, ainsi que par IP. Est-il nécessaire de recevoir tous les trois?

Le système ADNA fournit 4 flux au choix: satellite en bande KU, satellite en bande C, port TCP et flux RSS. Le DFL est entièrement libre de choisir l’un ou une combinaison de ces flux en fonction de sa configuration.

Le flux RSS dans un navigateur ne liste pas toutes les pièces jointes incluses dans l’alerte. Comment puis-je voir celles manquantes?

Cela dépend du navigateur utilisé. Si quelqu’un regarde le flux RSS en utilisant le navigateur Internet Explorer, alors une seule pièce jointe est affichée. Cela est spécifique aux paramètres du navigateur IE, mais uniquement au niveau de l’affichage : l’alerte a bien toutes les pièces jointes, mais une seule est affichée. Si elle est vue sur Firefox par exemple, toutes les pièces jointes sont affichées.

Quel lecteur de flux RSS doit être utilisé?

N’importe quel lecteur de flux RSS peut être utilisé en fonction du besoin. Par exemple, l’un des plus populaires est RSSOwl – http://www.rssowl.org/; il est en téléchargement gratuit et très simple d’utilisation.

Est-ce que le flux de données du système ADNA est gratuit pour les DFL?

Oui, le système ADNA est complètement gratuit, il n’y a aucun frais pour l’utiliser ou pour en recueillir des données.

La norme du PAC-PC indique que l’élément ‘polygone’ est facultatif. Est-ce que le polygone sera toujours contenu dans le message d’alerte ou est-ce que le message d’alerte peut être sans polygone?

Même si l’utilisation d’un polygone est facultatif, il est fortement recommandé à la fois dans le PAC et le PAC-PC. En conséquence, toutes les alertes émises à travers le système ADNA ou par EC (Environnement Canada) sont assurées de contenir les données du polygone lorsque ces valeurs sont présentes.

Est-ce qu’un diffuseur obtient le fichier .mp3 ou .wav intact (toujours au format mp3 ou fichier wav) pour le diffuser / jouer ou est-ce que l’audio est transformer et reformatée dans un format de fichier d’encapsulation différent?

Pour résumer, le radiodiffuseur obtient le fichier audio dans le format dans lequel il est envoyé.

Les distributeurs de fin de ligne ont besoin de savoir exactement quels types de types de fichiers ils peuvent s’attendre à recevoir. Le même principe s’applique aux fichiers d’image.

Veuillez-vous référer à ce document (en anglais) pour le type de pièces jointes prises en charge par le système ADNA.

La version plus longue de la réponse est que le fichier, peu importe son type, est reformaté en base64 (une norme exigée par le PAC), puis reformaté à nouveau dans son format d’origine par le DFL.

Par exemple:

  1. Le diffuseur attache un fichier mp3 à une alerte
  2. Le système ADNA le reformate en base64 et le distribue
  3. Le DFL reçoit l’alerte, extrait le fichier en base64 et le reconvertit pour le remettre en mp3.

Pour les alertes multilingues contenant une troisième langue, est-ce que l’équipement du DFL prendra la partie de l’alerte qui sera dans la troisième langue?

Tout dépend de la configuration de l’équipement du côté du DFL (qui devrait être configuré pour choisir un contenu pour d’autres langues que ‘En-CA’ etc, avec un code de langue valide).

Il y aura-t-il un délai entre la réception de la source audio sur la radio et le début de l’affichage du texte sur la télévision?

Oui, puisqu’il s’agit de réseaux complètement différents. Ils auront une différence de temps. Même deux chaînes de télévision ne diffuseront pas nécessairement en même temps.

Est-ce que les informations d’alerte envoyées sur le réseau sont sécurisées?

Le système ADNA est une application basée sur le Web, qui utilise les protocoles de sécurité HTTPS, SSL / TLS Web et le cryptage AES-256 pour sécuriser toutes les données.

Est-ce que les serveurs du système ADNA résident toujours dans la même plage d’adresses IP?

Idéalement, dans le cas normal, l’IP ne change pas derrière le DNS. Les IP resteront les même (mais veuillez garder à l’esprit qu’il n’y a aucune garantie qu’elles changeront ou non à l’avenir, par exemple si nous changeons notre FAI, cela aboutirait à un changement d’IP).

Est-ce que les serveurs du système ADNA sont dans un espace IP contigu?

Oui, les serveurs résident sur certaines plages d’adresses IP, mais si nécessaire, nous ne pouvons fournir que les noms des DNS, et non les adresses IP.