Login or Register as a LMD


How is the ‘alert region’ field defined in an alert?

The NAAD System uses the Statistics Canada – Standard Geographical Classification 2006 (Updated May 2010) from Statistic Canada (LINK). This standard allows multilevel fields for alert location and an alert can have a single or any combination from these location levels:

Province/Territory > Census Division > Census Subdivision.

According to this standard an alert issued for Quebec will have an SGC code “24” and if issued for a location within Quebec it will always start with an SGC code of “24…”. It depends how an LMD is receiving the alerts, if they have a tool available then it can be used to filter the alerts for location code “24” or codes starting as “24… ”.

Within the alert CAP file this code can be found in the following fields (an alert can have multiple geocode fields for multiple locations):

Are the NAAD System servers sitting in one contiguous IP space?

Yes, the servers reside on certain IP ranges, however if needed, we can only provide the DNS names, not the IP addresses.

Are the NAAD System servers always sitting in the same IP range?

Ideally, in normal case the IP doesn’t change behind the DNS. IP’s will remain the same (but please keep in mind that there is no guarantee if they would get changed or not in future; for example if we change our ISP, which would result in IP change).

Is the alert information sent over the network secure?

The NAAD System is a web based application, which uses HTTPS, SSL/TLS web secure protocols and AES-256 encryption to secure all data.

Will there be a time delay between receiving the audio feed over the radio and the beginning of the text display on the television?

Yes, since these are completely different networks. They will have a time difference. Even two TV stations may not necessarily broadcast as the exact same time.

For multilingual alerts containing the Third language, will the LMD equipment pick the third language part of the alert?

The totally depends on the configuration of the equipment at the LMDs side (which should be configured to pick content for languages other than ‘En-CA’ etc. with any valid language code).

The CAP-CP specification indicates that the polygon element is optional. Will the polygon be always contained within the given CAP-CP message or alert message can be without a polygon?

Even though the use of polygon is optional, it is strongly recommended in both CAP and CAP-CP. As such, all the alerts issued through the NAAD system or by EC are guaranteed to contain polygon data when such values are present.

Is the NAAD System data feed free of charge for LMDs?

Yes, the NAADS system is completely free, there is no charge what so ever to use it or to gather data from it.

What RSS reader or parser should be used?

Any RSS Reader tool can be used based on the need. For example a popular one is RSSOwl – http://www.rssowl.org/; it is a free download and very simple to use.

The RSS feed in a browser is not listing all the attachments included in the alert. How can I view the missing ones?

This depends on the browser being used. If someone is looking at the RSS feed using the Internet Explorer browser, then only one attachment is shown. This is something specific to the settings of IE browser but at display level only, the alert actually has all attachments but only one is displayed. If it is viewed on Firefox for example, all attachments are displayed.

The NAAD System provides alerts over Ku and C band, as well as IP. Is there a requirement to receive on all three?

The NAAD System provides 4 feeds to choose from:  Satellite KU band, Satellite C band, TCP Socket and RSS feeds. It’s totally up to the LMD whether they choose one of these or a combination of these depending on their setup.

Is it possible to get the alerts steaming through fibers (dedicated fiber connections) other than the TCP sites and satellite feeds? Is there plan to support direct connections in the future?

When the NAAD system was designed, Pelmorex consciously stayed away from designing point to point connections, the main reason being the commitment given to the CRTC and to the Pelmorex Governance Council to broadcast alerts to everyone on a public domain without restrictions and to make the alerts in fairness, available to everybody equally under the same terms and conditions.

Pelmorex does not have any plans to change the system to support customized or user specific direct connections.

Is it mandatory that the output of the Cisco receiver needs to be multicast?

The receiver we have mentioned in the LMD User Guide does not have the possibility to change (override) the destination IP address / multicast; the destination IP is decided at the equipment that is sending the feed.

Will there be packet re-ordering issues while listening to the satellite feeds via Cisco receiver setup?

In order to receive the UDP packets from the satellite receiver (regardless of whether it is from C Band or Ku Band satellite), a UDP socket application (client) should be used by the LMD (NAAD System doesn’t provide this application). This application will need to be in the same network segment as the satellite receiver, and it should register and receive packets sent to the IP multicast group:

The UDP destination port 25555 must be used to receive data. The application should receive data from this port and reassemble the packets to receive CAP-CP XML data.

The UDP packets should be assembled in the sequence in which they are received, in order to reassemble the packets into CAP-CP XML data. There is no additional information used to indicate the sequence of the UDP packet’s data within the CAP-CP XML.

In order to minimize the UDP packets re-ordering issue (since it could happen according to protocol specifications), LMD should connect the decoding system/computer directly to the satellite receiver using an Ethernet cable.

The CAP protocol specifications has a provision for the alert not to be signed. Are all alerts signed?

The security of the NAAD System is our highest priority.

 The NAAD System supports SSL. Every alert sent through the system will always have 1 or 2 signatures:

  1. First one is a digital signature produced by the Issuer (AGA) allowing verification to Alerts as being genuine to that specific Issuer and not tempered with. This signature is optional and is at the discretion of the Issuer’s organization. So it may or may not be present.
  2. Second one is the NAAD System’s digital signature in the alert message in addition to the Issuer’s signature. It will always be present in alerts disseminated by NAAD System. It may be used by LMD’s to confirm that the Alert Messages are received from the NAAD System

When an Alert is received, the Last Mile Distributor has the option of checking either or both of the signatures to validate that the Alert did originate from NAADS system (i.e. not tampered in internet transmission after issuing) and also validate that the original Alert Message from the issuer is genuine and intact.

For more details, please refer to the LMD user guide available on our Public Alerting website.

Is there any method to validate the digital signature, using a NAAD public key for instance, without connecting to the DSS SOAP server?

No, the NAADS DSS was implemented as a DSS SOAP server. The Last Mile Distributers will have to format a DSS request and make a SOAP call to the DSS web server, whose URL is in the signature.

To verify the NAAD System’s digital signature, the help document mentions about RequestID and Profile. Where do we get these values from?

The RequestID and Profile are values that should be generated by the request issuer. Both are treated as strings. For instance an LMD can use the Alert’s ID in the RequestID or can use an automatically generated ID if their system has one. The profile is the ID of the LMD, it should be a short string that identifies the request issuer i.e. LMDs organization name.

What is the process for addressing a situation where an LMD receives corrupt data in the public alerting feed?

There could be 2 possibilities:

  1. The LMD receives a complete alert but the content within the alert is corrupt or they doubt it’s tempered with
  2. They received an incomplete data file, alert without complete start and ending XML tags etc.

Based on these:

  1. Verifying the alert’s digital signature will ensure if the alert has been corrupted or tempered with or not. An alert will have 1 or 2 digital signatures. LMD can verify the alert is sent by NAADS by validating NAADS digital signature against NAADS DSS. This verifies that Message is not tampered in transmission from NAADS to LMD. If this is valid, then LMD can further validate that original Alert is not modified or tampered in any way from the original issuing source by validating the issuer’s signature against the issuing organization DSS. For both these validations, the LMDs will need to form XML based SOAP requests on https (following the OASIS-DSS standard) to the NAADS/Issuer DSS to get the signatures validated. It is recommended that LMDs verify signatures for all Alert Messages intended to be displayed to the Public. When both signatures are present, it is preferable to check Issuer signature as it verifies the originators source. LMD User Guide’s section “Appendix 4: Digital Signatures” explains this in much detail.
  2. If LMD received an incomplete file, it could most probably be due to transmission issue, for example slow internet connection, issue with satellite communication etc. However these would be on LMDs side. They should check their systems and fix/improve as needed. (the reason we say it’s on LMD side is due to the fact that we check all the transmissions to feeds in NAADS, anything failed to go to any feed will show incomplete tracing)

What should an LMD do if they receive corrupt alerts?

If the corrupt alert is due to DSS failure LMD should report it to us and reject the corrupted alert. (Note: Verifying the signature is LMDs choice, if they don’t verify any signature and process a tempered alert, it’s their own responsibility, but we do recommend them to verify signature for at least the broadcast messages)

Multiple feeds are made available; it is recommended that LMDs listen to more than one feed for redundancy purposes. This will also determine if the alert is corrupted on one feed or all of them. If it’s only on one feed, they can use the corresponding valid alert from another feed.

If alert is corrupted due to a transmission/application issue on LMD’s end on all feeds or if LMD listens to only one feed, then they should use auxiliary mechanisms to retrieve the alert. Messages are kept in their integral form for 48 hours (in a short term repository) for automated retrieval an LMD.