Open Source CAP Broadcaster
Development Guide
2024 CAP Implementation Workshop
Prepared by:
Vincent Maggard
This white paper is aimed at software developers interested in integrating additional alerting system support into OBPlayer and potentially other broadcast automation systems using Common Alerting Protocol (CAP) covering the following elements:
Understanding the Common Alerting Protocol
Overview of open source alert systems using CAP
CAP code examples for implementation
The primary goal of this project is to use bare metal computers including the low cost Raspberry PI and virtual environments to automate the process of receiving and broadcasting a CAP message with open source software. This unattended alerting process for radio and TV is standardized in Canada, the United States and many other countries presently using CAP.
Common Alerting Protocol (CAP) is a worldwide open standard for alert creation and transmission via IP networks. CAP is used by many systems to ingest and distribute alerts for broadcast. Some of the common systems included IPAWS in the US managing Wireless Emergency Alert (WEA) on cell phones, sirens, and more.FEMAFEMA
Figure : Example of CAP formatted message:
Alerts can be pulled or pushed from the CAP alert server(s) to the clients. CAP alerts can be life critical, favouring to publish/subscribe (RSS and ATOM). Otherwise, a CAP alert might be missed
Pull uses HTTP(s) for alerts fetching. This fetching is normally done via an ATOM or RSS feed. Each alert is given a feed entry with a link to the full cap XML. The client polls the server every x number of seconds, with common poll rates of every 30-40 seconds. The client must keep track of alerts it’s already used in the feed, so as to not keep repeating it over and over. When a new message is found the clients logs and downloads it. At that point it can treat it much the same as Push.
Push on the other hand sends the alert or pushes it to the client. This allows for near-real time activation. With push alerts they are still logged but since messages are normally sent once so the receiving system can be sure it’s new. If an internet outage or system reboot happens when an alert is sent, the client would miss it. Some cap servers handle this with alert repeats via heartbeat messages, however if used it adds more processing and code to do so to the system.
Profiles are used with CAP to add needed requirements for special systems like the US’s EAS, or Canada’s Alert Ready system. CA-CP handles unique French language accent characters CLFGCLFG
Common profile for the United States is IPAWS. IPAWS ProfileIPAWS Profile
IPAWS ProfileAll alerts have the CAP v.1.2 elements.
There are profiles for other countries as well such as CAP-AU.
Alerts received require parsing of the XML and alert validation (simple pre-air checks).
The order of handling an alert is as follows:
Parse the XML into an object.
Run through checks listed in the example table using the object.
If the alert passes all checks, download the attached audio, or create text to speech. For video create a crawl via concatenating the description & instructions elements values.
Place audio & crawl live on air.
| Check Name | Needed Actions |
|---|---|
| Is the alert active? | Current time > Issue time but < expire time. |
| Is the alert for the broadcasting area? | Check for one or more locations is included |
| Check if event code is set for broadcast? | Run though list of allowed event codes. |
| Check for the language code for the broadcaster viewer/listener? | Use the info block’s language tag to find the right version of the message. |
Below is group of code examples using Python 3.x This code is open source and can be found on GitHub CAP ExamplesCAP Examples
To check for a given alerts status expired, or not, is quite simple. To get the difference from the sent time and expire time examine if the difference is > 0 then the alert is active.
Figure : Example using Python date objects handling it with two steps.
Example using an Open source CAP server.
Figure : Example downloading the xml file
HTTP get request (download xml) CAP feed of alerts.
Parse xml
Compare with alerts already processed while handling multiple alerts.
Validate CAP alert and pass along to the broadcast chain.*
* OBPlayer presently logs the CAP alerts including off air audio logs as required by regulators.
| Term | Definition |
| Crawl | Video overlay of scrolling alert text. |
| PR | GitHub Pull Request used for submitting code changes for review. |
| HTTP | Hyper Text Transport |
| IPAWS | Integrated Public Alert & Warning System |
Coding Skills:
Python3 Basic knowledge
Can parse and handle XML
Hands On Experience:
Text to Speech
Common A/V codecs
Web stack
Git & GitHub
CAP Pull client for player.
| Task | Predicted Timeline |
| 1 Coding CAP pull client for OBPlayer. | 50 hours |
| 2 Testing alerting playback sequence | 8 hours |
| 3 Quality Assurance (QA) | 4 hours |
| 4 Issue Pull Request | . 10 minutes |
CAP Pull client for player.
Complete Alerting playback for the broadcast location. (US, CA, IN, BD etc)
Issue Pull Request (PR) with changes into Git repo.
Download White Paper Open Source CAP Broadcaster – Development Guide
Voice Tracking Support OpenBroadcaster launched a new feature—Web-Based Voice Tracking with our intuitive Built in…
Latest Release Highlights This release delivers powerful new features and key improvements for OpenBroadcaster’s broadcast…
Innovation and Technology for Inclusive Resilience The 2025 UNDRR Sasakawa Award recognized outstanding contributions to…
RGH Hall of Innovators My 2025 nomination for Hall of Innovators is Tagish Radio Rob!…
UNESCO - Digitization and AI for Archives and collections. Results of a survey exploring how…
Hello Radio Friends, I am presently working remotely this winter in Thailand and reside in…
This website uses cookies.
Read More