AXIS OS Portal

AXIS OS

AXIS OS is our operating system for edge devices. It is used in more than 300 products with the broadest partner application reach in the security industry. It’s a Linux-based OS that’s built around openness, transparency and cybersecurity.

AXIS OS features different firmware tracks depending on your needs. The long-term support (LTS) tracks maximize stability and focus on keeping a well-integrated 3rd party system by providing bug fixes and security patches. The active track on the other hand provides access to the newest state-of-the-art features and functionalities as well as bug fixes and security patches, which defines the active track as the software-development-focused track.

AXIS OS support overview

The active track releases a new version every 2–3 months where only the latest version is supported. The LTS tracks are created every two years and are supported and maintained for about 5 years. As an exception, the support period for LTS 2016 has been extended one year.

Upcoming releases

In the schedule below you can find information about upcoming firmware releases on the active track and the LTS tracks. To get the latest firmware updates to your RSS feed, subscribe to the product firmware feed.

VersionTrackPreliminary release datePlanned features and updates
10.12ActiveJune 2022
  • More info to come

10.XLTS 2022Q2 2022
  • More info to come

9.80.3.12LTS 2020May/June 2022
  • OpenSSL 1.1.1o

8.40.4.6LTS 2018November 2022
  • More info to come

6.50.5.7LTS 2016August/September 2022
  • More info to come

Go to Developer information to find out more.

Current releases

In this section you can read about the highlights in the latest AXIS OS releases. For more details, visit AXIS OS Release Notes. For downloads, visit the download page.

Highlights in AXIS OS 10.11

Release date: 2022-05-09 (to be rolled out within three weeks of release date)
For more details, go to AXIS OS Release Notes.

Signed video
Support has been added for signed video. Signed video adds cryptographic signatures to H.264 videos, which can be used to validate the video authenticity and origin.

Object detection updates
Object detection has been improved and support has been added for new object classes; HumanFace, LicensePlate, Bus, Car and Truck. These classes have been added to the RTSP video analytics metadata stream. Go to AXIS OS 10.11.55 in AXIS OS Release Notes for a list of supported products.

Device events via WebSocket
Support has been added for sending device events over WebSocket connections. For more information, go to Metadata via WebSocket.

NTCIP support over SNMP
Support for NTCIP over SNMP has been added for fixed box cameras mounted on an AXIS T99A positioning unit. Go to AXIS OS 10.11.55 in AXIS OS Release Notes for a list of supported products.

OpenSSL update
OpenSSL has been updated to version 1.1.1o to increase the overall minimum cybersecurity level.

Highlights in AXIS OS 9.80.3.11 (LTS 2020)

Support phase: 2020 – 2025-12-31
Release date: 2022-05-09
For more details, go to AXIS OS Release Notes.

Apache update
Updated Apache to version 2.4.53 to increase overall cybersecurity level.

OpenSSL update
Updated OpenSSL to version 1.1.1n to increase overall cybersecurity level.

Highlights in AXIS OS 8.40.4.5 (LTS 2018)

Support phase: 2018 – 2023-12-31
Release date: 2022-05-18 (to be rolled out within 3 weeks of release date)
For more details, go to AXIS OS Release Notes.

Apache update
Updated Apache to version 2.4.53 to increase overall cybersecurity level.

OpenSSL update
Updated OpenSSL to version 1.1.1o to increase overall cyber security level.

Highlights in AXIS OS 6.50.5.6 (LTS 2016)

Support phase: 2016 – 2022-12-31 (extended from 2021-12-31)
Release date: 2022-05-11 (to be rolled out within three weeks of release date)
For more details, go to AXIS OS Release Notes.

Apache update
Updated Apache to version 2.4.53 to increase overall cybersecurity level.

OpenSSL update
Updated OpenSSL to version 1.1.1o to increase overall cyber security level.

Release notes

The detailed release notes for AXIS OS have been moved. From now on, you will find them over at AXIS OS Release Notes.

AXIS OS tracks

What is Axis firmware?
In Axis network video products, the firmware basically functions as an operating system, being the software that manages all aspects of the product’s performance. The firmware is customized for each product, to support both the imaging hardware and any product-specific features.

Firmware for new products
Firmware development for new products starts with a product firmware (PFW) being branched off from the common firmware platform (CFW). The CFW platform is a shared firmware platform that contains the combined features of all video products that have been integrated into it. The new PFW branch is built upon throughout the project lifecycle to become the initial firmware release for that product. The PFW is then merged back to the CFW platform, integrating the new product to the shared platform and enabling it to receive scheduled firmware updates.

Diagram outlining the firmware development procedure with product firmware branches from the common firmware platform.

 

Before a new product is released, the stability of the firmware is ensured through extensive testing of the product’s features. After release, firmware updates are scheduled to add features, or sometimes required to fix bugs.

Firmware releases
Firmware updates are divided into major releases and minor releases. A major release contains proactive firmware changes that incorporate both major and minor upgrades to feature and functionality. A minor release contains small, reactive firmware changes to fix reported bugs and potential security vulnerabilities.

The frequency of major and minor releases depends on which firmware management approach is used. Axis offers two separate tracks of firmware management — the active track and the LTS tracks — each with their own release intervals

The active track

The active track suits customers that want to access the newest features and functionalities. Firmware releases on this track are aligned with development on the common firmware platform. Most new Axis video products reside on the active track, which means that they get immediate access to any new features and feature updates, as soon as these are released.

The LTS tracks

The LTS track suits customers who prefer to update their products less frequently. The focus of the LTS track is to keep the products well integrated with third-party equipment or software, and lets the customer access any necessary bug fixes and security updates. The LTS tracks enable maintained cybersecurity in the products by offering firmware updates with minimized risk of negatively affecting the existing integration.

An LTS firmware track is a fixed firmware platform and is issued every two years.

Upgrade paths

It’s possible to upgrade from an LTS track to a newer LTS, but note that a newer LTS track may include new features, changes to default settings, and performance adjustments that could affect compatibility with your system. The products should be updated in a controlled and supervised manner after verification that firmware on the new LTS track works as expected in your third-party environment.

Also note that the following Axis devices require a firmware upgrade via the latest available LTS 2018 (8.40) prior to upgrading to AXIS OS 10.9 or later: AXIS D2050-VE, AXIS FA54, AXIS M3057-PLVE, AXIS M3058-PLVE, AXIS P1367/-E, AXIS P1368-E, AXIS P1445-LE, AXIS P1445-LE-3, AXIS P1447-LE, AXIS P1448-LE, AXIS P3227-LV/-LVE, AXIS P3228-LV/-LVE, AXIS P3807-PVE, AXIS Q1645/-LE, AXIS Q1647/-LE, AXIS Q1659, AXIS Q3515-LV/-LVE, AXIS Q3517-LV/-LVE/-SLVE, D101-A XF P3807, ExCam XF P1367, ExCam XF Q1645 and F101-A XF P1367.

Recommended upgrade path for switching LTS tracks when a new LTS track is available. Note that actual firmware notation and release dates may differ from those in the diagram.

Release archive

Active track releases

In this section you can find information about releases on the active track prior to AXIS OS 10.0.0. For information about later releases, please visit AXIS OS Release Notes.

Active 2020 (9.80)

Release date: 2020-05-05 (to be rolled out within three weeks of release date)

This release includes:

NTP status
It is now possible to see NTP status in the web interface.

Custom header CGI
Support has been added for custom header CGI, meaning it is now possible to customize headers to support e.g. Access-Control-Allow-Origin (CORS) and X-Frame-Options to increase minimum cybersecurity level. Go to the VAPIX library for more information.

Automatic gain control for audio input
Support for automatic gain control has been added to selected products with audio support. See full list in Automatic gain control.

Disabling SD card
It is now possible to disable the SD card slot via Plain config > Storage > Storage.S0.Enabled.

ACAP updates
AXIS Guard Suite has been updated to version 2.2.4 and AXIS Video Motion Detection has been updated to version 4.4.5.

Active 2020 (9.70)

Release date: 2020-03-10 (to be rolled out within three weeks of release date)

This release includes:

Session Initiation Protocol (SIP)
Support for SIP has been added to selected AXIS M30, AXIS M31 and AXIS M32 products. Read more and see full list in Session Initiation Protocol (SIP).

ONVIF profile T
Support for ONVIF profile T has been added to AXIS P3719-PLE. Read more in ONVIF profile T.

Active 2019 (9.60)

Release date: 2020–01–07 (to be rolled out within three weeks of release date)

This release includes:

Audio disabled per default
Audio is now disabled per default and needs to be enabled upon first usage. Applies to all products with audio support in factory defaulted state.

Copy action rules, schedules and recipients
It is now possible to copy action rules, schedules and recipients in the web interface.

Geolocation API
Geolocation API has been added to all products. Read more in the VAPIX library.

Image orientation
It is now possible to set image rotation in ONVIF media profiles.

ACAP updates
 •  AXIS Guard Suite has been updated to version 2.2.2
 •  AXIS Video Motion Detection has been updated to version 4.4.3
 •  Orientation aid PTZ has been updated to version 1.4.1
 •  Support for AXIS Live Privacy Shield has been added to AXIS M1137/-E, AXIS P1375/-E, AXIS P1377/-LE, AXIS P1378/-LE and AXIS P3245-V/-LV/-VE/-LVE

Active 2019 (9.50)

Release date: 2019–11–11 (to be rolled out within three weeks of release date)

This release includes:

Session Initiation Protocol (SIP)
Support for SIP has been added to selected AXIS M30 and AXIS Q35 products, read more and see full list in Session Initiation Protocol (SIP).

Onvif profile T
Support for ONVIF profile T has been added to selected products, read more and see full list in ONVIF profile T.

Backlit entrance scene profile
The profile has been introduced for selected products to get more visibility of face details in entrances that have strong backlight. It also reduces WDR artifacts.
Available for: AXIS Q1645/-LE, AXIS Q1647/-LE, AXIS Q1785-LE and AXIS Q1786-LE.

H.264 over HTTP
It is now possible to stream H.264 over HTTP in an mp4 or a matroska container. Examples:
  •  http://<camera-ip>/axis-cgi/media.cgi?container=mp4
  •  http://<camera-ip>/axis-cgi/media.cgi?container=matroska

Support for disabling the web interface
It is now possible to disable the web interface to increase overall minimum cybersecurity level.
The web interface can be disabled under System > Plain config > System > Sytem Web Interface Disabled. To enable the web interface after it has been disabled, the VAPIX parameter System.WebInterfaceDisabled must be set to “no”.

Web interface updates
  •  Support has been added for Image Frequency in Event Settings.
  •  It is now possible for operators to turn the IR cut filter on or off for AXIS Q6215–LE.

Apache web server update
Apache web server has been updated to version 2.4.41 to increase overall minimum cybersecurity level.

OpenSSL update
OpenSSL has been updated to version 1.1.1d to increase overall minimum cybersecurity level.

ACAP updates
AXIS Video Motion Detection has been updated to version 4.4.2, including improvements and corrections.

Active 2019 (9.40)

Release date: 2019–09–12

This release includes:

Initial device access change
For security reasons the initial device access is changed so that it requires a password to be set before any other APIs are open. For more information, go to Device access.

Average bitrate (ABR)
With this feature enabled you can set a bandwidth budget that the camera will keep over a period of time, allowing for high peaks of bandwidth and if necessary adjusting the quality setting for the entire period. See list of supported products in Average bitrate (ABR).

Session Initiation Protocol (SIP)
Support for SIP has been added to selected AXIS P32 products, see full list in Session Initiation Protocol (SIP).

Onvif profile T
Support for ONVIF profile T has been added to selected products, see full list in ONVIF profile T. Read more about profile T at https://www.onvif.org/profiles/profile-t/.

Automatic firmware rollback verification
When upgrading firmware through the web interface, the user can now select a time period to acknowledge that the upgrade was successful, otherwise it will rollback to previous version and configuration. This is especially useful when upgrading remotely. Check out the video in Configuration tips to see how it works.

Secondary NTP server
Added support for configuring a secondary NTP server in the web interface under Settings > System > Date & Time or via VAPIX Time API.

ACAP updates
AXIS Video Motion Detection and AXIS Guard Suite have been updated to new versions that include improvements and corrections. AXIS Loitering Guard is now pre-installed on AXIS P1280–E, AXIS P1290–E and all Axis Q-line cameras.

Active 2019 (9.30)

Release date: 2019–06–14

This release includes:

Source-specific multicast (SSM)
Support added via http://ip-address/axis-media/ssm/media.amp. Go to the VAPIX library for more information and documentation.

Portcast and AXIS T61 Audio and I/O Interface Series
Support for portcast and AXIS T6101/T6112 has been added to AXIS P3717–PLE. See full list of supported products in Portcast.

Web interface updates
  •  Support has been added for onscreen controls. Onscreen controls gives the user quick and easy access to commands to the camera, not only from the web interface but also from VMS software that supports this functionality. Some cameras have predefined onscreen controls, but it is also possible to add user-defined onscreen controls.
  •  The video stream is now paused per default to save bandwidth and to make the web-interface more responsive when working over slow connections.
  •  The classic web pages are now completely removed.

Apache web server update
Updated to version 2.4.39 to increase overall minimum cybersecurity level.

TLSv1.3
The camera platform now supports TLSv1.3 in Apache for improved performance and increased overall minimum cyber security level. TLS1.0 and TLS1.1 is now disabled per default.

ACAP updates
AXIS Video Motion Detection, AXIS Motion Guard, AXIS Fence Guard and AXIS Loitering Guard have been updated to new versions that include improvements and corrections.

Active 2019 (9.20)

Release date: 2019-04-17

This release includes:

Signed firmware
Firmware is now signed by Axis. Support has been added to all products. Read more in the white paper on axis.com.

LLDP allocation for max-power
Available for selected products, see full list in LLDP max-power allocation. This allows the switch to allocate less power to the camera and potentially a greater number of PoE devices can be connected to the switch. LLDP allocation for max-power can be enabled in Settings > System > Plain config > Network > LLDP POE > LLDP Send Max PoE.

Onvif profile T
Support for ONVIF profile T has been added to selected products, see full list in ONVIF profile T. Read more about profile T at https://www.onvif.org/profiles/profile-t/.

Apache web server update
Apache web server has been updated to version 2.4.38 to increase overall minimum cybersecurity level.

OpenSSL update
OpenSSL has been updated to version 1.1.1a to increase overall minimum cybersecurity level.

ACAP updates
AXIS Video Motion Detection, AXIS Motion Guard, AXIS Fence Guard and AXIS Loitering Guard have been updated to new versions that include improvements and corrections.

Active 2019 (9.10)

Relase date: 2019–02–19

This release includes:

Rollback of ACAP applications in firmware recovery
The firmware recovery/rollback feature makes it possible to undo a firmware upgrade. The feature now includes ACAP applications and their respective settings.

Apache web server update
Apache web server has been updated to version 2.4.37 to increase overall minimum cybersecurity level.

OpenSSL update
OpenSSL has been updated to version 1.0.2q to increase overall minimum cybersecurity level.

Active 2018 (8.50)

Release date: 2018–11–30

This release includes:

Onvif profile T
Support has been added to selected products, see full list in ONVIF profile T.
Read more about profile T at https://www.onvif.org/profiles/profile-t/.

CDP support for PoE negotiation
Support has been added for Power over Ethernet (PoE+ 30W, IEEE 802.3at type 2 class 4) negotiations over Cisco Discovery Protocol (CDP). If LLDP and CDP are enabled simultaneously on the switch port, the camera will take the protocol that is first advertised by the switch for PoE negotiation.

API Discovery service
API Discovery service makes it possible to retrieve information about your product’s supported APIs. Read more in the VAPIX library.

Apache web server update
Apache web server has been updated to version 2.4.35 to increase overall minimum cyber security level.

OpenSSL update
OpenSSL has been updated to version 1.0.2p to increase overall minimum cyber security level.

ACAP updates
AXIS Video Motion Detection, AXIS Motion Guard, AXIS Fence Guard and AXIS Loitering Guard have been updated to new versions that include improvements and corrections.

Active 2018 (8.40)

Release date: 2018–09-20

This release includes:

Portcast and AXIS T61 I/O and Audio Interface Series
Support for portcast and AXIS T6101/T6112 has been added to selected products, see full list in Portcast.

256–bit SD card encryption
Support has been added for AES-CBC 256–bit SD card encryption. Available for selected products, see full list in 256-bit SD card encryption.

Apache web server update
Apache web server has been updated to version 2.4.33 to increase overall minimum cyber security level.

ACAP updates
AXIS Video Motion Detection, AXIS Motion Guard, AXIS Fence Guard and AXIS Loitering Guard have been updated to new versions that include improvements and corrections.

Active 2018 (8.30)

Release date: 2018–06–25

This release includes:

Camera tampering
Tampering detection has been added to AXIS Q1941–E and AXIS Q1942–E. The tampering event will be the same as for visual cameras, except for the removal of the dark image detection setting.

ONVIF Audio Backchannel
Support has been added for ONVIF Audio Backchannel, with support for G.711 and G.726 audio codecs. Cameras are able to retrieve audio while sending an audio capable video stream with metadata in the same RTSP session.

Automatic negotiation of SMB/CIFS version
Support has been added for negotiating the preferred SMB protocol version of 2.10, 3.0 or 3.02 to increase overall minimum cybersecurity level. For more information, see https://www.axis.com/support/faq/FAQ116392.

256–bit SD card encryption
Support has been added for AES-XTS-512 256–bit SD card encryption. Available for selected products, see full list in 256-bit SD card encryption.

Google analytics
Added the possibility for the user to share anonymous usage data with Axis developers. Examples of information collected: which pages are visited, the firmware version of the product, language setting, video format, aspect ratio, browser and operating system. This is done in order to continue improving the products and user experience. The feature is disabled per default but can be enabled during installation, or under System -> Maintenance.

ACAP updates
AXIS Video Motion Detection, AXIS Motion Guard, AXIS Fence Guard and AXIS Loitering Guard have been updated to new versions that include improvements and corrections.

Active 2018 (8.20)

Release date: 2018–05–03

This release includes:

Portcast and AXIS T61 Audio and I/O Interface Series
Support for the new portcast technology has been added to selected AXIS M30 products. Portcast makes it possible to add audio and I/O ports via a new network utility box (AXIS T6101 and AXIS T6112). See full list of supported products in Portcast.

Default audio bitrate
All products with audio support now have 32 kbps bitrate per default.

Polygon privacy masks
Support for polygon privacy masks has been added for selected products, see full list in Polygon privacy masks.

Dynamic overlays
Support has been added for dynamic overlays, which will replace the older overlays. This adds capabilities like free positioning, more font sizes and colors. It is possible to migrate from existing overlays to dynamic overlays and support has been added to all products except AXIS Companion Cube L/LW, AXIS Companion Dome V/WV, AXIS M1045–LW, AXIS M1065–LV/-LW, AXIS M3044–V/-WV, AXIS M3045–V/-WV, AXIS M3046–V, AXIS M3106–L/-LVE, AXIS M3106–L/-LVE Mk II and AXIS Q6125–LE.

Hidden resolutions
Support has been added for showing hidden resolutions via API. The parameter Properties.Image.ShowSuboptimalResolutions has been added, which will, when enabled, make the parameter Properties.Image.Resolution show all of the products supported resolutions.

Exposure data provided as Exif tags
Exposure data is now provided as Exif tags in JPEG and Motion JPEG. This is intended for customers that require a richer set of sensor data to be used in advanced analytics applications.

ACAP updates
AXIS Video Motion Detection, AXIS Motion Guard and AXIS Fence Guard have been updated to new versions that include improvements and corrections.

Active 2018 (8.10)

Release date: 2018–02–16

This release includes:

Apache web server update
Apache web server has been updated to version 2.4.29 to increase overall minimum cyber security level.

ACAP updates
AXIS Video Motion Detection has been updated to version 4.2, which is compatible with ONVIF Imaging Spec 17.06, and also includes improvements and corrections.

Active 2017 (7.40)

Release date: 2017–12–11

This release includes:

Firmware rollback (previously firmware recovery)
The user can roll back to a previous firmware and its configuration.

HTTP keep-alive connections via ONVIF
PTZ products can now be controlled via HTTP keep-alive connections. This increases PTZ control accuracy, reduces overhead communication and therefore lowers the risk for security focused network infrastructure or unstable networks to block or drop PTZ control commands.

OPUS audio codec
The OPUS audio codec is supported by all audio products except Axis Companion Cube L/LW. The codec can be selected in the web-interface under Settings > Audio > Encoding, or via VAPIX API.

Browser stream statistics
Browser stream statistics is supported in live view. Stream statistics lists: resolution, stream type, encoding, frame rate, bitrate, uptime, buffer, dropped frames and refreshed.

OpenSSL update
OpenSSL has been updated to version 1.0.2p to increase overall minimum cyber security level.

Password security confirmation check
To increase the overall cybersecurity awareness, a user-configured password that is considered "weak" need to be confirmed actively twice by the user.

ACAP updates
AXIS Video Motion Detection has been updated to a new version, which includes improvements and corrections. AXIS Motion Guard and AXIS Fence Guard are now pre-installed on all Axis Q-line products.

Active 2017 (7.30)

Release date: 2017–09–22

This release includes:

SRTP
Support has been added for SRTP (Encrypted Video Streaming) according to RFC 3711. The cameras video stream can be received via secure end-to-end encrypted transportation method only by authorized clients.
SRTP is supported by all products except the following: AXIS Companion Cube L/LW, AXIS Companion Dome V/WV, AXIS M1045-LW, AXIS M1065-L/-LW, AXIS M2026-LE, AXIS M2026-LE-Mk II, AXIS M3044-V/-WV, AXIS M3045-V/-WV, AXIS M3046-V, AXIS M3106-L/-LVE, AXIS M3106-L/-LVE Mk II.

Zipstream dynamic FPS and GOP
It is now possible to further adjust and set limits for the dynamic FPS and dynamic GOP settings for Zipstream.

FTP disabled per default
The FTP server has been disabled by default to increase overall minimum security standards. The FTP server may be enabled during advanced maintenance or troubleshooting.

Brute force delay protection
With brute force delay protection, the product can block a client for a period of time if too many login attempts fails. Brute force delay protection can be configured under System > Plain config > System > System PreventDoSAttack.

Noise reduction
Support for noise reduction has been added to AXIS Q1755/-E, AXIS Q6052/-E, AXIS Q6054/-E and AXIS Q6055/-E/-C/-S.

Web interface updates
  •  Adaptive resolution is now enabled per default. When viewing live stream in the web interface, the viewing client will receive an image resolution that is adapted, or close to, the viewing clients real display resolution.
  •  Support has been added for automatic license key installation when installing an ACAP.
  •  It is now possible to choose “flash all” (i.e. factory default) when doing a firmware upgrade from the web interface.
  •  It is now possible to fast forward/backward to any time position of the selected recording within the recording list in the web interface.
  •  PTZ control in the live view has been improved for cameras with both mechanical or digital PTZ.
  •  Support has been added for entering manual SSIDs in wireless settings.
  •  The area zoom functionality has been removed from the web interface to improve the overall PTZ usability (area zoom was used to draw a rectangle in the live view to let the camera pan, tilt or zoom to this desired position).

Active 2017 (7.20)

This release includes:

AXIS SD Card health API
Support for Axis SD card health API has been added. The API allows a client to track and request the health and wear out state of cameras with AXIS Surveillance Cards.

24–bit LPCM audio
Support for 24-bit LPCM audio mode has been added. The mode is disabled by default.

Keep-alive for Axis PTZ products
PTZ products can now be controlled via HTTP 1.1 keep-alive connections. This increases PTZ control accuracy and reduces overhead communication, which in turn lowers the risk of PTZ control commands to be blocked when controlling a PTZ camera.

HTTPS enabled by default
When performing a factory default, the camera will generate a self-signed certificate at boot and can enable HTTPS. This allows clients to use encrypted access from start.
If HTTPS is to be used in daily operations, it is recommended to replace the generated self-signed certificate with a CA-signed certificate.

Open SSL update
OpenSSL has been updated to version 1.0.2k to increase overall minimum cyber security level.

Apache web server update
Apache web server has been updated to version 2.4.25 to increase overall minimum cyber security level.

Active 2017 (7.10)

This release includes:

New web interface
In this version, a new web interface with improved usability and broader support of web clients and operating systems has been introduced. It supports 12 different pre-installed languages which will be added automatically based on browser settings, meaning it is no longer required to upload individual language files.
Supported languages: English - German - French - Spanish - Italian - Portuguese - Polish - Russian -Japanese - Chinese (Mainland) - Chinese (Taiwan) - Korean.

ACAP updates
AXIS Video Motion Detection 4.1 is pre-installed in all products, and will replace AXIS Video Motion Detection 3. The new version comes with a better analytics engine and mechanical PTZ camera support.

Audio streaming capabilities API
A new audio streaming capabilities API has been implemented for better handling of the product's supported codecs, sample rates, bitrates and channels. Only supported audio combinations will be shown.

Axis On-Screen Controls
Axis On-Screen Controls make it possible for Axis Camera Station or a VMS to get information about various features of the camera. This information is available via a CGI. Read more in the VAPIX library.

Open SSL update
OpenSSL has been lifted to 1.0.2j to increase overall cybersecurity level.

LLDP
Support for LLDP neighbor announcements has been added. Products will now announce themselves in the network via the LLDP protocol.

Active 2016 (6.50)

This release includes:

ACAP updates
AXIS Video Motion Detection 4 is pre-installed in all products. The new version offers improved detection with a possibility to configure multiple detection areas.

Pre-installing the new version will not affect any current installation or configuration of previous versions of AXIS Video Motion Detection.

Active 2016 (6.40)

Release date: 2016–10–10

This release contains no major feature/capability updates.

Active 2016 (6.30)

This release includes:

ONVIF profile G
Support for ONVIF profile G has been added. More information about profile G at https://www.onvif.org/profiles/profile-g/.

Zipstream with dynamic frame rate
The latest enhancement of Axis Zipstream technology now offers even more storage and bandwidth savings in video surveillance applications without compromising important image details. It dynamically adjusts the frame rate, instantly adapting to any changes in the scene.

Active 2016 (6.20)

Release date: 2016–03–22

This release includes:

Zipstream for Axis PTZ products
Axis Zipstream improvements for PTZ products.

Active 2016 (6.10)

Release date: 2016–02–22

This release includes:

Removed predefined stream profiles
Removed predefined stream profiles "Quality", "HDTV", "Balanced", "Bandwidth" and "Mobile".
Note that if a user upgrades from a previous firmware (where the stream profiles exists), the stream profiles are kept until a factory reset has been done.

Removed parameter based event API
Users of the old event handling API need to convert the events before upgrading to firmware version 6.10 not to loose events. A convert button is available in the web interface, in the events setup section.

Active 2015 (5.90)

Release date: 2015–10–16

This release contains no major feature/capability updates.

Active 2015 (5.80)

Release date: 2015–05–22

This release includes:

Axis Zipstream technology
Optimized for video surveillance, AXIS Zipstream technology is a radically more efficient H.264 implementation, lowering bandwidth and storage requirements by an average of 50% or more. Axis Zipstream technology conforms to the H.264 standard and is compatible with third-party clients and VMS solutions that decode H.264 video. To use the Zipstream dynamic GOP mode, some clients might need to adapt their H.264 playback implementation. The fixed GOP mode works with all implementations.
Axis Zipstream is available in selected Axis products. The VAPIX library has been updated with new information and new APIs.

AXIS Video Motion Detection 3 pre-installed
AXIS Video Motion Detection 3, which includes AXIS False Alarm Filtering, is now a pre-installed ACAP application. It replaces the built-in video motion detection in the web interface in all products except Axis PTZ cameras and Axis video encoders. PTZ cameras and encoders will still use the built in motion detection.

ONVIF media profiles
Available ONVIF media profiles are now presented and configurable in the products’ web interface.

SD card encryption
With SD card encryption, it is possible to enable encryption of the SD card to protect your data. This encryption is transparent to users and VMS solutions making it possible to activate without adaptations.
The feature is presented and configurable both in the web interface and via VAPIX.

Improved time to video
The start-up of the product is now optimized and the time until the first video is delivered is reduced by an average of 20%.

Active 2015 (5.70)

This release includes:

Secure FTP (SFTP)
Systems using Secure FTP (SFTP) notifications and uploads from the product can now do this in a secure way over FTP

Matroska fixer
It is now possible to get broken recordings if the recording was ongoing during a power loss, or if a storage media was removed without proper disconnection (i.e. unmounts).
With the Matroska fixer, an attempt to fix broken recordings is performed. When a storage media is connected (mounted), any broken recording is detected and operations to fix the recording start. The recordings are fixed in a queue fashion, i.e. one recording is fixed at a time. After the recording is fixed, its stop time and duration are amended (increased).

Storage limit
Adding ability to control storage allocation quotas on edge storage devices, i.e. NAS. A storage allocation quota parameter will decide how much storage a camera is allowed to allocate.

NAS drives over 2 TB
Axis network cameras now support NAS disk drives up to 8 TB.

Automatic repair
It is now possible to configure automatic repair of ext4 file system if it has become corrupt. This increase the level of robustness of the SD edge storage feature.

Init removed
Systemd has replaced init. Init was previously deprecated and is now completely removed and replaced with systemd.

Apache web server
Changing from BOA to Apache web server due to maintenance reason.

Active 2015 (5.60)

This release includes:

ACAP updates
Firmware 5.60 extends the ACAP SDK which gives new possibilities to develop ACAP’s. It is also possible to enable multiple ACAP applications to run simultaneously. The combination of applications should however be validated by the system integrator before deployment.

AXIS Video MIB
Axis is now extending the SNMP offering with AXIS Video MIB (Management Information Base). AXIS Video MIB is targeting system integrators and end-users that are using SNMP, and enables network administrators to detect possible malfunctions in Axis products such as fan failures, temperature limits, storage disruptions, tampering, video/audio connectors disconnections, etc. via SNMP traps. Available traps are depending on the Axis product.
AXIS Video MIB is released for Axis products, see https://www.axis.com/techsup/software/index.htm for more information.
AXIS Video MIB is supported from various 5.55 firmware releases.

Edge storage auto-format SD card
Axis firmware now has the ability to auto-format an SD card to a specified file system upon insertion. This will allow an easy installation of a new SD card that automatically will be formatted to a preselected file system, mounted and recording will be resumed. Less manual intervention is needed on installation and service.
Edge storage auto-format is supported from the 5.55 firmware.

Edge storage recording indicator
With the edge storage recording indicator it is possible to indicate, e.g. in the live view, that an edge storage recording is ongoing. This allows the operator to be notified if a recording of scene is ongoing or not.
Edge storage recording indicator is supported from the 5.55 firmware.

Extended edge storage support
Supporting memory cards up to 512 GB.

Optimal live view resolution
The live view page is updated with responsive design and scales with different screen resolutions and browser window sizes. This will allow the user to always see the complete page without the need to scroll.

Quick HDTV live view demonstration
For all megapixel products, a new default viewing profile for HDTV resolution has been added. This viewing profile is visible in the live view and is beneficial for demonstration purposes, especially in full screen mode.

Export video clip
The export video clip capability enables the export of recordings directly from the camera to a PC or a smartphone.
Select the wanted portion of an edge storage recording from your camera and export them as playable video files to a client. The exported recording will be a playable Matroska file.

SSH
SSH was introduced in 5.50 and is now the only supported protocol to establish a connection. Telnet is no longer supported. SSH is not enabled by default but can be activated by an API.

Developer information: RTSP server improvement
RTSP server and video streaming are updated and improved. This is an internal architectural improvement with minor corrections in the API to comply with the standard in RFC 2326.

Developer information: ACAP management
The limitation of running only one application at a time has been removed. It’s now possible (depending on available resources) to run several applications simultaneously. The combination of applications should be validated by the system integrator before deployment. A new API has been added enabling a client to get extended information of installed applications.

Developer information: generic ACAP configuration
All applications taking advantage of the new platform can provide a URL for configuration. The intension of this is that a client, such as a VMS, can provide this link or embed it into the application in a generic way.

Developer information: ACAP upgrade
When upgrading an application, it is now possible to keep the configuration for the application. This is decided during the implementation of the ACAP.

Developer information: ACAP interfaces
A range of new APIs has been added to the platform allowing an application to directly interface with local storage, PTZ control, I/Os and audio. In addition it is now possible to interact with the event system in a more flexible way.

Developer information: device service query
An entry service has been added allowing a client to query which webservice API that is available in the product.

Developer information: system log enhancements
The system log has been improved and uses a standardized logging format. Important messages will be kept longer and repeated messages will print the actual message that was repeated.

Active 2015 (5.50)

Release date: 2015–03–05

This release includes:

Local language support
Added support for changing the language of the product's web interface from English. Supported languages are: Brazilian Portuguese, French, German, Italian, Japanese, Korean, Russian, simplified Chinese and Spanish.
The local language files are available at www.axis.com for each camera model immediately after the firmware release. The selection and installation of the files do not require any knowledge in the English language.

Extended number of privacy masks
It is now possible to configure up to 32 simultaneous privacy masks. The previous limit was 3 to 16, depending on product model. The number of available privacy masks depends on the product model.

Extended edge storage support
Supporting memory cards up to 64 GB.

Edge storage disruption detection
It is now possible to be notified when the edge storage detects disruptions. The event is used to notify administrators to quickly resolve issues, typically disk unavailable, read/write error, disk full or disk locked.

Text overlay character set extension
Ability to use non-western characters in the video text overlay. All left-to-right languages are supported.

Text overlay font size
It is now possible to select three different font sizes for the video text overlay in order to increase readability. This is especially helpful in high resolution video.

Text overlay message action
Support has been added for a product action that provides a way to display a user defined message in the text overlay upon a detected event. The message can be used to communicate information to the operator, visually mark video for later video forensics or provide an easy way for a user to validate event detectors during installation and configuration.

ONVIF profile S conformance
The ONVIF profile S replaces ONVIF Version 1.02. ONVIF has developed a profile concept to simplify identification of interoperable products. For more details see https://www.onvif.org/profiles/profile-s/.

Support for common e-mail services
Ability to connect products to common email services requiring SSL/TLS security. Predefined profiles for Gmail, Hotmail, AOL and Yahoo are included in order to simplify configuration.

HTTPS recipient
Systems using HTTP notifications and uploads from the product can now do this in a secure way over HTTPS.

Send video clip action
It is now possible to upload a video clip to an FTP server or an email recipient upon an event. A media player with support for H.264 and Matroska file format (MKV) is required to play the clip.

Live stream access detection
In some sensitive installations it may be necessary to notify people that someone is actively monitoring a camera (for example, in a conference room). The live stream access event may be used to control a nearby "alert light" connected to digital output port of the camera.

System ready event
It is now possible to get notified when the product has booted and all services are initialized. The event is typically used to notify an operator (or system) that the unit has been restarted.

ACAP updates
Improvements in AXIS Cross Line Detection 1.x and AXIS Video Motion Detection 2.x. The applications will be less prone to false detect on very small objects.

Centralized certificate management
Certificates for HTTPS and 802.1x are now managed in one place. The firmware also includes a number of pre-installed CA certificates such as VeriSign, Thawte and GeoTrust. It is also possible to install additional CA certificates.

Improved constant bitrate control
The constant bitrate (CBR) will now adjust to target bitrate quicker and smoother.

PTZ control error notification
It is now possible to be notified if malfunction in a mechanical PTZ product is detected. The event is typically used to trigger a notification to the administrator/operator for service. The error detection is available for selected mechanical PTZ products.

Virtual inputs
Input may be used by clients to initiate action rules in the camera. Virtual inputs extend the existing “manual trigger” with 32 additional virtual inputs.

SSH (Secure Shell)
SSH is a command line interface to the products that may be used for specific support and maintenance activities. SSH extends the Telnet capabilities in order to establish a secure remote command line connection. The Telnet and SSH capabilities are not enabled by default.

LTS 2020 (9.80)

Support phase: 2020 – 2025-12-31

In this section you can find the highlights of the LTS 2020 releases prior to AXIS OS 9.80.3.3. Information about later LTS 2020 releases is available in AXIS OS Release Notes.

LTS 2020 - 9.80.3.2

Release date: 2021-05-03 (to be rolled out within three weeks of release date)

This release includes:

OpenSSL update
OpenSSL has been updated to version 1.1.1k to increase overall minimum cybersecurity level.

LTS 2020 - 9.80.3.1

Release date: 2021-03-15 (to be rolled out within three weeks of release date)

This release includes:

OpenSSL update
OpenSSL has been updated to version 1.1.1i to increase overall minimum cybersecurity level.

LTS 2020 - 9.80.3

Release date: 2021-01-19 (to be rolled out within three weeks of release date)

This release includes:

OpenSSL update
OpenSSL has been updated to version 1.1.1h to increase overall minimum cybersecurity level.

LTS 2020 - 9.8.2.4

Release date: 2020-10-28 (to be rolled out within three weeks of release date)

This release includes:

HSTS support when using HTTPS
HSTS (HTTP Strict Transport Security) is now supported when using HTTPS.

LTS 2020 - 9.80.2.3

Release date: 2020-10-07

This release includes:

Apache web server update
Apache web server has been updated to version 2.4.46 to increase overall minimum cybersecurity level.

Default custom headers
The following HTTP headers have been configured to increase overall cybersecurity level:
• X-Frame-Options: SAMEORIGIN
• X-Content-Type-Options: nosniff
• X-XSS-Protection: 1; mode=block

LTS 2020 - 9.80.2.2

Release date: 2020-07-21

This release includes general improvements and security updates.

LTS 2020 - 9.80.2

Release date: 2020-06-23

This release includes:

OpenSSL update
OpenSSL will be updated to version 1.1.1g to increase overall minimum cybersecurity level.

Apache web server update
Apache web server will be updated to version 2.4.43 to increase overall minimum cybersecurity level.

OAK VAPIX API
Support has been added for retrieving the OAK key for O3C-connections in Settings > System > O3C.

LTS 2018 (8.40)

Support phase: 2018 – 2023-12-31

In this section you can find the highlights of the LTS 2018 releases prior to AXIS OS 8.40.4.1. Information about later LTS 2018 releases is available in AXIS OS Release Notes.

LTS 2018 - 8.40.4

Release date: 2020-07-21

This release includes:

OpenSSL update
OpenSSL has been updated to version 1.1.1g to increase overall minimum cybersecurity level.

Apache web server update
Apache web server has been updated to version 2.4.43 to increase overall minimum cybersecurity level.

OAK in the web interface
It is now possible to retrieve the device Owner Authentication Key (OAK) in the web interface.

LTS 2018 - 8.40.3.3

This release includes general improvements and security updates.

LTS 2018 - 8.40.3.2

This release includes general improvements and security updates.

LTS 2018 - 8.40.3.1

This release includes:

OpenSSL update
OpenSSL has been updated to version 1.1.1d to increase overall minimum cybersecurity level.

Apache web server update
Apache web server has been updated to version 2.4.41 to increase overall minimum cybersecurity level.

See the release notes for each product for more detailed information about corrections and improvements.

LTS 2018 - 8.40.3

This release includes:

Initial device access change
For security reasons the initial device access is changed so that it requires a password to be set before any other APIs are open. For more information, go to go to Device access.

libssh2 update
Updated to version 1.9.0 to increase overall minimum cybersecurity level. Includes correction for CVE-2019-13115.

LTS 2018 - 8.40.2.2

Security vulnerabilities
Corrections to increase overall minimum cybersecurity level: CVE-2019-9494, CVE-2019-9495, CVE-2019-9496, CVE-2019-9497, CVE-2019-9498, CVE-2019-9499. CVE-2019-11477, CVE-2019-11478, CVE-2019-11479 CVE-2019-6454.

OpenSSL
Updated to version 1.1.1c to increase overall minimum cybersecurity level.

TLSv1.3
Support added for TLSv1.3 to increase overall minimum cybersecurity level.

NetApp NAS
Corrected an issue that caused SMB connection problems to NetApp NAS configured for SMBv2.

Focus improvement
Improved focus in wide and night mode for AXIS Q6155–E and AXIS Q6154–E.
Corrected an issue that caused focus not to respect set near focus limits on rare occasions for AXIS Q6052/–E, AXIS Q6054/-E and AXIS Q6054/–E Mk II.

LTS 2018 - 8.40.2.1

Apache web server
Updated to version 2.4.39 to increase overall minimum cybersecurity level.

O3C client
Updated to improve robustness.

OpenSSL
Updated to version 1.1.1b to increase overall minimum cybersecurity level.

OpenSSH
Updated to version 7.9p to increase overall minimum cybersecurity level.

LTS 2018 - 8.40.2

Security vulnerabilities
Corrections to increase overall minimum cybersecurity level: CVE-2019-3855, CVE-2019-3856, CVE-2019-3857, CVE-2019-3858, CVE-2019-3859, CVE-2019-3860, CVE-2019-3861, CVE-2019-3862, CVE-2019-3863, CVE-2018-16864, CVE-2018-16865, CVE-2018-16866, CVE-2017-16544, CVE-2019-0217.

OpenSSL
Updated to version 1.0.2r to increase overall minimum cybersecurity level.

Web interface
Correction of issue that prevented the upload of a client certificate or CA certificate using Microsoft Edge.

LTS 2016 (6.50)

Support phase: 2016 – 2022-12-31 (extended from 2021-12-31)

In this section you can find the highlights of the LTS 2016 releases prior to AXIS OS 6.50.5.3. Information about later LTS 2016 releases is available in AXIS OS Release Notes.

LTS 2016 - 6.50.5.2

Release date: 2020-08-03

This release includes:

OpenSSL update
OpenSSL has been updated to version 1.1.1g to increase overall minimum cybersecurity level.

Apache web server update
Apache web server has been updated to version 2.4.43 to increase overall minimum cybersecurity level.

TLSv1.3
Support added for TLSv1.3 to increase overall minimum cybersecurity level.

OAK in the web interface
It is now possible to retrieve the device Owner Authentication Key (OAK) in the web interface.

LTS 2016 - 6.50.5.1

This release includes general improvements and security updates.

LTS 2016 - 6.50.5

This release includes:

OpenSSL update
OpenSSL has been updated to version 1.1.1d to increase overall minimum cybersecurity level.

LTS 2016 - 6.50.4.2

6.50.4.2 includes a fix for an issue that appeared when setting the time manually in 6.50.4.1.

6.50.4.1 includes:

OpenSSL update
OpenSSL has been updated to version 1.0.2t to increase overall minimum cybersecurity level.

Apache web server update
Apache web server has been updated to version 2.4.41 to increase overall minimum cybersecurity level.

Web interface update
Time zones have been updated in the date/time settings in the web interface.

LTS 2016 - 6.50.4.1

This release includes:

OpenSSL update
OpenSSL has been updated to version 1.0.2t to increase overall minimum cybersecurity level.

Apache web server update
Apache web server has been updated to version 2.4.41 to increase overall minimum cybersecurity level.

Web interface update
Time zones have been updated in the date/time settings in the web interface.

LTS 2016 - 6.50.4

This release includes:

Initial device access change
For security reasons the initial device access is changed so that it requires a password to be set before any other APIs are open. For more information, go to Device access.

OpenSSL update
Updated to version 1.0.2s to increase overall minimum cybersecurity level.

Security vulnerability correction
Corrected security vulnerability in Systemd CVE-2019-6454 to increase overall minimum cyber security level.

Increased limit of HTTP requests
Increased the limit of concurrent HTTP requests for I/O related VAPIX commands from 4 to 10.

Triggered data in SEI messages correction
Corrected an issue that prevented the insertion of triggered data in SEI messages when streaming H.264.

LTS 2016 - 6.50.3.1

Apache web server
Updated to version 2.4.39 to increase overall minimum cybersecurity level.

O3C client
Updated to improve robustness.

OpenSSL
Updated to version 1.0.2r to increase overall minimum cybersecurity level.

Security vulnerabilities
Corrections to increase overall minimum cybersecurity level: CVE-2019-3855, CVE-2019-3856, CVE-2019-3857, CVE-2019-3858, CVE-2019-3859, CVE-2019-3860, CVE-2019-3861, CVE-2019-3862, CVE-2019-3863, CVE-2018-16865, CVE-2018-16866, CVE-2018-17182, CVE-2017-16544.

LTS 2016 - 6.50.3

Apache web server
Updated to version 2.4.33 to increase overall minimum cybersecurity level.

OpenSSL
Updated to version 1.0.2o to increase overall minimum cybersecurity level.

Handling of ACAPs
Corrected an issue with incorrect handling of ACAPs after camera boot.

Perfect forward secrecy ciphers
Added perfect forward secrecy ciphers (DHE-RSA) to the ciphers selection.

Security vulnerabilities
Correction to increase overall minimum cybersecurity level: CVE-2018-14526.

Options for disabling TLSv1.0 and TLSv1.2
Added selection boxes for disabling TLSv1.0 and TLSv1.1 in Settings > System > Plain config > HTTPS to enforce the highest possible HTTPS negotiation client handshake via TLSv1.2.

LTS 2016 - 6.50.2

Apache web server
Updated to version 2.4.27 to increase overall minimum cybersecurity level.

OpenSSL
Updated to version 1.0.2k to increase overall minimum cybersecurity level.

Triple DES cipher
The triple DES cipher is not selected as DEFAULT in the HTTPS settings to increase overall cyber security level.

Certificate handling
Improved certificate handling. Certificates were previously not usable when updating straight from firmware 5.40 to 6.50.

Critial vulnerabilities
Correction of critical vulnerabilities: ACV-120444 and ACV-116267.

Security vulnerabilities
Corrections to increase overall minimum cybersecurity level: CVE-2016-2147 and CVE-2016-2148.

System stability
Improved overall system stability.

Feature reference list

256-bit SD card encryption

Firmware versionSupported products
8.40
  • AXIS Companion Bullet LE

  • AXIS Companion Eye L/-LVE

  • AXIS M1124/-E

  • AXIS M1125/-E

  • AXIS M2025–LE

  • AXIS M3104–L/-LVE

  • AXIS M3105–L/-LVE

  • AXIS M5525–E

  • AXIS P1244 (AXIS P12 Mk II)

  • AXIS P1245 (AXIS P12 Mk II)

  • AXIS P1254 (AXIS P12 Mk II)

  • AXIS P1264 (AXIS P12 Mk II)

  • AXIS P1265 (AXIS P12 Mk II)

  • AXIS P1275 (AXIS P12 Mk II)

  • AXIS P1280-E (AXIS P12 Thermal)

  • AXIS P1290-E (AXIS P12 Thermal)

  • AXIS P1364/-E

  • AXIS P1365/-E Mk II

  • AXIS P1405–LE Mk II

  • AXIS P1425–LE Mk II

  • AXIS P1435–E/-LE

  • AXIS P3224–V/-LV/-VE/-LVE Mk II

  • AXIS P3225–V/-LV/-VE/-LVE Mk II

  • AXIS P3235–LV/-LVE

  • AXIS P3374–V/-LV

  • AXIS P3375–V/-LV/-VE/-LVE

  • AXIS P5514/-E

  • AXIS P5515/-E

  • AXIS P5624–E Mk II

  • AXIS P5635–E Mk II

  • AXIS Q1615/-E Mk II

  • AXIS Q1775/-E

  • AXIS Q1941–E

  • AXIS Q1941–E PT Mount

  • AXIS Q1942–E

  • AXIS Q1942–E PT Mount

  • AXIS Q3504–V/-VE

  • AXIS Q3505–V/-VE Mk II

  • AXIS Q3615–VE

  • AXIS Q3617–VE

  • AXIS Q6052/-E

  • AXIS Q6054/—E Mk II

  • AXIS Q6054/-E Mk II

  • AXIS Q6055/-E/-C/-S

  • AXIS Q6124–E

  • AXIS Q6155–E

  • AXIS Q8641–E

  • AXIS Q8642–E

8.30
  • AXIS M3057–PLVE

  • AXIS M3058–PLVE

  • AXIS P1367/-E

  • AXIS P1368–E

  • AXIS P1445–LE

  • AXIS P1447–LE

  • AXIS P1448–LE

  • AXIS P3227–LV/-LVE

  • AXIS P3228–LV/-LVE

  • AXIS Q1645/-LE

  • AXIS Q1647/-LE

  • AXIS Q3515–LV/-LVE

  • AXIS Q3517–LV/-LVE/-SLVE

Automatic gain control

Automatic gain control automatically adjusts the audio input gain for improved audio quality.

Firmware versionSupported products
10.1
  • AXIS M3075-V

9.80
  • AXIS M1134

  • AXIS M1135/-E

  • AXIS P1367-E

  • AXIS P1368-E

  • AXIS P1375/-E

  • AXIS P1377/-LE

  • AXIS P1378/-LE

  • AXIS P1445-LE

  • AXIS P1445-LE-3

  • AXIS P1448-LE

  • AXIS P3245-LV/-LVE

  • AXIS P5655-E

  • AXIS Q1645/-LE

  • AXIS Q1647/-LE

  • AXIS Q1659

  • AXIS Q1700-LE

  • AXIS Q1785-LE

  • AXIS Q1786-LE

  • AXIS Q1798-LE

  • AXIS Q3515-LV/-LVE

  • AXIS Q3517-LV/-LVE

  • AXIS Q3518-LVE

  • AXIS Q3527-LVE

  • AXIS Q6075

Average bitrate (ABR)

With average bitrate enabled you can set a bandwidth budget that the camera will keep over time, allowing for high peaks of bandwidth, and if necessary adjusting the quality for the entire period.

Firmware versionSupported products
10.1
  • AXIS M3064-V

  • AXIS M3065-V

  • AXIS M3066-V

  • AXIS M3075-V

  • AXIS M3205-LVE

  • AXIS M3206-LVE

  • AXIS P3719-PLE

  • AXIS Q6010-E

  • AXIS Q9216-SLVE

9.50
  • AXIS M3057-PLVE

  • AXIS M3058-PLVE

  • AXIS P1365/-E Mk II

  • AXIS P1367/-E

  • AXIS P1368-E

  • AXIS P1375/-E

  • AXIS P1445-LE

  • AXIS P1445-LE-3

  • AXIS Q1615/-E Mk II

  • AXIS Q1645/-LE

  • AXIS Q1647/-LE

  • AXIS Q1659

  • AXIS Q1785-LE

  • AXIS Q1786-LE

  • AXIS Q3515-LV/-LVE

  • AXIS Q3517-LV/-LVE/-SLVE

  • AXIS Q3518-LVE

  • AXIS Q3527-LVE

  • AXIS Q3615-VE

  • AXIS Q3617-VE

  • ExCam XF P1367

  • ExCam XF Q1645

  • ExCam XF Q1785

  • F101–A XF Q1785

9.40
  • AXIS Companion Bullet LE

  • AXIS Companion Eye L/-LVE

  • AXIS D2050-VE

  • AXIS FA54 Main Unit

  • AXIS M1124/-E

  • AXIS M1125/-E

  • AXIS M2025-LE

  • AXIS M3104-L/-LVE

  • AXIS M3105-L/-LVE

  • AXIS P1244 (AXIS P12 Mk II)

  • AXIS P1245 (AXIS P12 Mk II)

  • AXIS P1254 (AXIS P12 Mk II)

  • AXIS P1264 (AXIS P12 Mk II)

  • AXIS P1265 (AXIS P12 Mk II)

  • AXIS P1275 (AXIS P12 Mk II)

  • AXIS P1280-E (AXIS P12 Thermal)

  • AXIS P1290-E (AXIS P12 Thermal)

  • AXIS P1364/-E

  • AXIS P1435-E/-LE

  • AXIS P1447-LE

  • AXIS P1448-LE

  • AXIS P3224-V/-LV/-VE/-LVE Mk II

  • AXIS P3225-V/-LV/-VE/-LVE Mk II

  • AXIS P3227-LV/-LVE

  • AXIS P3228-LV/-LVE

  • AXIS P3235–LV/-LVE

  • AXIS P3245-V/-LV/-VE/-LVE

  • AXIS P3374-V/-LV

  • AXIS P3375-V/-LV/-VE/-LVE

  • AXIS P3717-PLE

  • AXIS P3807-PVE

  • AXIS P5655-E

  • AXIS Q1700-LE

  • AXIS Q1798-LE

  • AXIS Q1941-E

  • AXIS Q1941-E PT Mount

  • AXIS Q1942-E

  • AXIS Q1942-E PT Mount

  • AXIS Q6075/-E

  • AXIS Q6215-LE

  • AXIS Q8641-E

  • AXIS Q8642-E

  • D101-A XF P3807

LLDP max-power allocation

LLDP allocation for max-power via Link Layer Discovery Protocol (LLDP) can be used instead of the standard PoE-class based power allocation. When enabled, the Axis device will notify the PoE-switch about its max PoE consumption so that the PoE-switch can perform a better PoE-management and may allocate less PoE to the network port.

LLDP allocation for max-power can be enabled in Settings > System > Plain config > Network > LLDP POE > LLDP Send Max PoE.

Firmware versionSupported products
10.7
  • AXIS M3077-PLVE

10.4
  • AXIS M3115-LVE

  • AXIS M3116-LVE

10.3
  • AXIS M1134

  • AXIS M1135/-E

  • AXIS M3064-V

  • AXIS M3065-V

  • AXIS M3066-V

  • AXIS M3075-V

  • AXIS M3067-P

  • AXIS M3068-P

  • AXIS M3206-LVE

  • AXIS M3205-LVE

  • AXIS P3245-V/-VE/-LV/-LVE

  • AXIS P3715-PLVE

  • AXIS P3925-R

  • AXIS P3935-LR

10.2
  • AXIS S3008

10.0
  • AXIS M3205-LVE

  • AXIS M3206-LVE

9.20
  • AXIS Companion Eye L/-LVE

  • AXIS Companion Eye mini L

  • AXIS Companion Cube L/-LW

  • AXIS Companion Dome V/-WV

  • AXIS M1065–L/-LW

  • AXIS M1125/-E

  • AXIS M2025-LE

  • AXIS M2026-LE Mk II

  • AXIS M3015

  • AXIS M3016

  • AXIS M3044-V/-WV

  • AXIS M3045-V/-WV

  • AXIS M3046-V

  • AXIS M3058-PLVE

  • AXIS M3105-L/-LVE

  • AXIS M3106-L/-LVE Mk II

  • AXIS P1244

  • AXIS P1245

  • AXIS P1254

  • AXIS P1264

  • AXIS P1265

  • AXIS P1275

  • AXIS P1280-E

  • AXIS P1290-E

  • AXIS P1364/-E

  • AXIS P1365/-E Mk II

  • AXIS P1367/-E

  • AXIS P1368-E

  • AXIS P1435-LE

  • AXIS P1445-LE/-LE-3

  • AXIS P1447-LE

  • AXIS P1448-LE

  • AXIS P3225-V/-LV Mk II

  • AXIS P3228-LV/-LVE

  • AXIS P3375-VE/-LVE

  • AXIS P3807-PVE

  • AXIS Q1615/-E Mk II

  • AXIS Q1645/-LE

  • AXIS Q1647/-LE

  • AXIS Q1785-LE

  • AXIS Q1941-E

  • AXIS Q1941-E PT Mount

  • AXIS Q1942-E

  • AXIS Q1942-E PT Mount

  • AXIS Q3515-LV/-LVE

  • AXIS Q3517-LV/-LVE/-SLVE

  • AXIS Q3518-LVE

  • AXIS Q3615-VE

  • AXIS Q3617-VE

ONVIF profile M

ONVIF profile M supports analytics configuration and information query for metadata, as well as filtering and streaming of metadata. Read more at https://www.onvif.org/profiles/profile-m/

Firmware versionSupported products
10.9
  • AXIS M3057-PLVE Mk II

  • AXIS M3067-P

  • AXIS M3068-P

  • AXIS M3077-PLVE

10.8
  • AXIS FA51/-B

  • AXIS M1134

  • AXIS M1135/-E

  • AXIS M1137/-E

  • AXIS M3064-V

  • AXIS M3065-V

  • AXIS M3066-V

  • AXIS M3075-V

  • AXIS M3115-LVE

  • AXIS M3116-LVE

  • AXIS M3205-LVE

  • AXIS M3206-LVE

  • AXIS M4308-PLE

  • AXIS P1367/-E

  • AXIS P1368-E

  • AXIS P1445-LE

  • AXIS P1445-LE-3

  • AXIS P1447-LE

  • AXIS P1448-LE

  • AXIS P1455-LE-3

  • AXIS P3227-LV/-LVE

  • AXIS P3228-LV/-LVE

  • AXIS P3245-LVE-3

  • AXIS P3807-PVE

  • AXIS P3818-PVE

  • AXIS P3925-R/LRE

  • AXIS P3935-LR

  • AXIS Q1645/-LE

  • AXIS Q1647/-LE

  • AXIS Q1659

  • AXIS Q1700-LE

  • AXIS Q1785-LE

  • AXIS Q1786-LE

  • AXIS Q1951-E

  • AXIS Q1952-E

  • AXIS Q3515-LV/-LVE

  • AXIS Q3517-LV/-LVE/-SLVE

  • AXIS Q3518-LVE

  • AXIS Q3527-LVE

  • AXIS Q6215-LE

  • AXIS Q9216-SLV

  • AXIS V5925

  • AXIS V5938

  • D101-A XF P3807

  • ExCam XF P1367

  • ExCam XF Q1645

  • ExCam XF Q1785

  • F101-A XF P1367

  • F101-A XF Q1785

  • XP40-Q1785

10.6
  • AXIS P1375/-E

  • AXIS P1377/-LE

  • AXIS P1378/-LE

  • AXIS P1455-LE

  • AXIS P3245-V/-VE/-LV/-LVE

  • AXIS P3247-LV/-LVE

  • AXIS P3248-LV/-LVE

  • AXIS P3255-LVE

  • AXIS P5654-E

  • AXIS P5655-E

  • AXIS Q1615/-LE Mk III

  • AXIS Q1798-LE

  • AXIS Q3819-PVE

  • AXIS Q6074/-E

  • AXIS Q6075/-E/-S/-SE

  • AXIS Q6078-E

  • AXIS Q6135-LE

  • AXIS Q6315-LE

  • D201-S XPT Q6075

  • ExCam XPT Q6075

  • F101-A XF P1377

ONVIF profile T

ONVIF profile T supports video streaming features such as the use of H.264 and H.265 encoding formats, imaging settings, and alarm events such as motion and tampering detection. Read more at https://www.onvif.org/profiles/profile-t/.

Firmware versionSupported products
10.9
  • AXIS D2110-VE

  • AXIS FA51/-B

  • AXIS FA54

  • AXIS I8016-LVE

  • AXIS M1134

  • AXIS M1135/-E

  • AXIS M1137/-E

  • AXIS M3057-PLVE

  • AXIS M3058-PLVE

  • AXIS P3717-PLE

  • AXIS Q1700-LE

10.6
  • AXIS P3807-PVE

  • AXIS Q1659

10.2
  • AXIS Q6215-LE

10.0
  • ExCam XF Q1785

  • F101–A XF Q1785

9.70
  • AXIS P3719–PLE

9.50
  • AXIS Q6125–LE

  • AXIS Q1785–LE

  • AXIS Q1786–LE

9.40
  • AXIS P5655–E

  • AXIS M4206–LV/-LVE

9.20
  • AXIS Companion 360

  • AXIS Companion Cube L/-LW

  • AXIS Companion Dome V/-WV

  • AXIS M1045–LW

  • AXIS M1065–L/-LW

  • AXIS M2026–LE

  • AXIS M2026–LE Mk II

  • AXIS M3015

  • AXIS M3016

  • AXIS M3044–V/-WV

  • AXIS M3045–V/-WV

  • AXIS M3046–V

  • AXIS M3106–L/-LVE

  • AXIS M3106–L/-LVE Mk II

  • AXIS P9106–V

  • AXIS Q6125–LE

8.50
  • AXIS M1124/-E

  • AXIS M1125/-E

  • AXIS M2025–LE

  • AXIS M3104–L/–LVE

  • AXIS M3105–L/-LVE

  • AXIS P1364/-E

  • AXIS P1365/-E Mk II

  • AXIS P1367/-E

  • AXIS P1368–E

  • AXIS P1435–E/-LE

  • AXIS P1445–LE

  • AXIS P1447–LE

  • AXIS P1448–LE

  • AXIS P3224–V/-LV/-VE/-LVE Mk II

  • AXIS P3225–V/-LV/-VE/-LVE Mk II

  • AXIS P3227–LV/-LVE

  • AXIS P3228–LV/-LVE

  • AXIS P3235–LV/-LVE

  • AXIS P3374–V/-LV

  • AXIS P3375–V/-LV/-VE/-LVE

  • AXIS Q1615/-E Mk II

  • AXIS Q1645/-LE

  • AXIS Q1647/-LE

  • AXIS Q3515–LV/-LVE

  • AXIS Q3517–LV/-LVE/-SLVE

  • AXIS Q3615–VE

  • AXIS Q3617–VE

Polygon privacy masks

​A polygon privacy mask is a privacy mask in which you can add up to 32 anchors to make a custom shape.

Firmware versionSupported products
10.5
  • AXIS M3064-V

  • AXIS M3065-V

  • AXIS M3066-V

  • AXIS M3075-V

  • AXIS M3205-LVE

  • AXIS M3206-LVE

8.20
  • AXIS P1367/-E

  • AXIS P1368–E

  • AXIS P1447–LE

  • AXIS P1448–LE

  • AXIS P3227–LV/-LVE

  • AXIS P3228–LV/-LVE

  • AXIS Q1645/-LE

  • AXIS Q1647/-LE

  • AXIS Q3515–LV/-LVE

  • AXIS Q3517–LV/-LVE/-SLVE

Portcast

Portcast adds connectivity to Axis cameras. By placing AXIS T6101/T6112 Audio and I/O Interface between the camera and switch, it adds a communication layer on top of the network.

Firmware versionSupported products
10.4
  • AXIS Q6135-LE

9.80
  • AXIS P3245-LV/-LVE

9.30
  • AXIS P3717–PLE

8.40
  • AXIS M3057–PLVE

  • AXIS M3058–PLVE

  • AXIS P3227–LV/-LVE

  • AXIS P3228–LV/-LVE

8.20
  • AXIS M3044–V/-WV

  • AXIS M3045–V/-WV

  • AXIS M3046–V

Session Initiation Protocol (SIP)

SIP is a protocol for initiating, maintaining, and terminating multimedia sessions between different parties. Usually these sessions consist of audio, but sometimes they consist of video. SIP is the standard protocol used in voice over IP (VoIP) applications and unified communication platforms.

The most important applications of SIP are in internet telephony for voice and video calls, as well as instant messaging over IP networks.

Firmware versionSupported products
9.70
  • AXIS M3064–V

  • AXIS M3065–V

  • AXIS M3066–V

  • AXIS M3075–V

  • AXIS M3115–LVE

  • AXIS M3116–LVE

  • AXIS M3205–LVE

  • AXIS M3206–LVE

9.50
  • AXIS M3057–PLVE

  • AXIS M3058–PLVE

  • AXIS Q3515–LV/-LVE

  • AXIS Q3517–LV/-LVE/-SLVE

  • AXIS Q3518–LVE

9.40
  • AXIS P3227–LV/-LVE

  • AXIS P3228–LV/–LVE

Developer information

In this section you can read more about planned AXIS OS releases containing updates and features that can affect your software. Scroll down to Current AXIS OS version for information about the latest AXIS OS release, or visit AXIS OS Release Notes to read more about previous releases.

Scheduled AXIS OS versions

Please note that this schedule is preliminary and that both time schedule and included features are subject to change as work progresses.

AXIS OS 10.12
Scheduled for: June 2022

  • More information to come.

Current AXIS OS version

AXIS OS 10.11
Released: April 2022
Main new features:

  • Showing supported object classes from metadata producers in the product’s web interface.

  • Added support for HumanFace, LicensePlate, Bike, Bus, Car and Truck as new object detection classes in machine learning cameras.
    Applies to: AXIS F9104-B, AXIS F9114/-B, AXIS P1375/-E, AXIS P1377/-LE, AXIS P1378/-LE, AXIS P1455-LE, AXIS P3245-V/-VE/-LV/-LVE, AXIS P3247-LV/-LVE, AXIS P3248-LV/-LVE, AXIS P3727-PLE, AXIS P5654-E, AXIS P5655-E, AXIS Q1798-LE, AXIS Q6074/-E, AXIS Q6075/-E/-S/-SE, AXIS Q6078-E, AXIS Q6135-LE and AXIS Q6315-LE

  • Axis devices produce object classified data by default if the device has support for it. This is only valid for a new or defaulted device. Upgrade will keep the previous sources as it was.

    • Video analytics metadata stream will at factory default have object classifications enabled through objectanalytics/metadata-fusion.

    • Customers who want to use forensic search no longer need to manually enable objectanalytics/metadata-fusion in the web interface.

    • Customers who want the old behavior with Video motion tracker/Motion Object Tracking Engine (MOTE) can configure it in the web interface.

  • In the RTSP video analytics metadata stream, the frames produced by the metadata producer "Axis object analytics" with the Frame Source attribute "objectanalytics" now includes motion-only objects, meaning objects with bounding boxes, but without a classification. This generally result in more detected objects but with lower confidence.
    Applies to: AXIS M2035-LE, AXIS M2036-LE, AXIS M4216-V/-LV, AXIS P3255-LVE, AXIS Q1615/-LE Mk III, AXIS Q1656/-B/-BE/-BLE/-LE, AXIS Q1715, AXIS Q3536-LVE, AXIS Q3538-LVE and AXIS M4308-PLE.

  • Added support for a 10 band graphic audio equalizer which is configurable in the new web interface (Audio > Audio Mixer > Ten band graphic equalizer).
    Note: Axis products using audio via portcast over AXIS T6101 are currently not supported.

  • Added support for signed video. Signed video adds cryptographic signatures to H.264 videos, which can be used to validate the video authenticity and origin. The feature is possible to enable for RTSP streams on products with Axis Edge Vault.

  • Added support for NTP time extensions in RTP headers. This provides absolute timestamps which clients can use instead of RTP relative timestamps. An absolute timestamp can be associated with each video frame through ONVIF replay RTP header extensions, which can now be enabled on live streams.

  • Added support for sending device events over WebSocket connections. For more information, see Metadata via WebSocket.

  • Added ONVIF Profile M support for AXIS I8016-LVE.

Knowledge base

Vulnerability archive

The AXIS OS vulnerability archive transparently lists both OpenSource and Axis vulnerabilities that have been brought to our attention. The purpose of the archive is to proactively raise awareness and communicate about vulnerabilities that have been analyzed for AXIS OS capable products. AXIS OS products are either running an AXIS OS LTS or active track firmware, or 4.xx and 5.xx legacy firmware. The majority of vulnerabilities reported are the result of security scanner audits that may remark vulnerabilities on Axis products falsely. For more information about Axis work with cybersecurity, please visit https://www.axis.com/support/product-security.

OpenSource and Axis vulnerabilities are listed below with CVE IDs (CVE = Common Vulnerabilities and Exposures). Axis vulnerabilities were previously listed with ACV IDs (ACV = Axis Critical Vulnerability), which changed when Axis was approved as a CVE Numbering Authority (CNA) in April 2020.

You are welcome to contact Axis support at https://www.axis.com/support in case you have found a CVE that you believe may be present in your product’s firmware, but which is not listed in the archive below. We will be happy to assist you.

OpenSource

The OpenSource archive covers potential threats caused by 3rd part vulnerabilities of OpenSource components that are used in Axis products and their firmware.

CVE Result of investigation | Actions
CVE-2022-30295Affects AXIS P7701 Video Decoder. Other Axis devices that are running the latest AXIS OS LTS or active version do not use the uClibc or uClibc-ng library. We are currently awaiting the availability of an upstream patch to be available to judge if we can provide a service release that patches this vulnerability.
CVE-2022-30115Not affected.
CVE-2022-27782Affected. The vulnerability will be patched by upgrading to cURL 7.83.1. Please monitor Upcoming releases for more information.
CVE-2022-27781Affected. The vulnerability will be patched by upgrading to cURL 7.83.1. Please monitor Upcoming releases for more information.
CVE-2022-27780Not affected.
CVE-2022-27779Not affected.
CVE-2022-27778Not affected.
CVE-2022-27776Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2022-27775Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2022-27774Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2022-22965Not affected as JDK, Spring Cloud function and/or Apache Tomcat are not used.
CVE-2022-22963Not affected as JDK, Spring Cloud function and/or Apache Tomcat are not used.
CVE-2022-23943Not affected. AXIS OS devices do not use the mod_sed module.
CVE-2022-22721Not affected. While AXIS OS devices use the core module, the command LimitXMLRequestBody is unused.
CVE-2022-22720Affected. The vulnerability will be patched by upgrading to Apache version 2.4.53. Please monitor Upcoming releases for more information.
CVE-2022-22719Not affected. AXIS OS devices do not use the mod_lua module.
CVE-2022-1292Not affected. AXIS OS devices do not use the c_rehash script.
CVE-2022-0847Not affected. The affected Linux Kernel 5.8 is not used, AXIS OS devices utilizes lower versions of Linux Kernel on Linux Long-Term releases.
CVE-2022-0778Affected. The vulnerability will be patched by upgrading to OpenSSL version 1.1.1n. Please monitor Upcoming releases for more information.
CVE-2021-44790Not affected. AXIS OS devices do not use the mod_lua module.
CVE-2021-44228  
Not affected. AXIS OS products only use the vanilla Apache webserver and not Apache Log4j, which is vulnerable. A general statement for the Axis portfolio can be found here.
CVE-2021-44224Affected. The vulnerability will be patched by upgrading to Apache version 2.4.52. Please monitor Upcoming releases for more information.
CVE-2021-43523Affects AXIS P7701 Video Decoder. Other Axis devices that are running the latest AXIS OS LTS or active version do not use the uClibc or uClibc-ng library. We are currently awaiting the availability of an upstream patch to be available to judge if we can provide a service release that patches this vulnerability.
CVE-2021-42013  Not affected
CVE-2021-41773  Not affected
CVE-2021-41617  Not affected since the AXIS OS configuration for SSH doesn't include AuthorizedKeysCommand or AuthorizedPrincipalsCommand in its default configuration.
CVE-2021-41524  Not affected
CVE-2021-40438  Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2021-40146  Not affected
CVE-2021-39275  Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2021-36260  Not affected
CVE-2021-36160  Not affected
CVE-2021-34798  Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2021-33910Affects LTS 2020. The vulnerability has been patched. Updating is recommended.
CVE-2021-33193  Affects AXIS OS 10.1 - 10.7. The vulnerability has been patched. Updating is recommended.
CVE-2021-32934  Not affected
CVE-2021-31618  Affects AXIS OS 10.1 - 10.6. Has been patched in AXIS OS 10.7.
CVE-2021-30641  Not affected
CVE-2021-29462Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2021-28372Not affected since AXIS OS doesn’t utilize the ThroughTek (TUTK) TCP/IP stack application.
CVE-2021-27219  Affected. The vulnerability has been patched on the LTS tracks.
CVE-2021-27218  Affected. The vulnerability has been patched on the LTS tracks.
CVE-2021-26691  Not affected
CVE-2021-26690  Not affected
CVE-2021-25677  Not affected
CVE-2021-23841  Not affected
CVE-2021-23840  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2021-23839  Not affected
CVE-2021-22947  Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2021-22946  Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2021-22945  Not affected
CVE-2021-22901  Not affected
CVE-2021-22898  Not affected
CVE-2021-22897  Not affected
CVE-2021-22890  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2021-22876  Not affected
CVE-2021-21727  Not affected
CVE-2021-4160Affected. The vulnerability will be patched by upgrading to OpenSSL 1.1.1m. Please monitor Upcoming releases for more information.
CVE-2021-4104  Not affected. AXIS OS products only use the vanilla Apache webserver and not Apache Log4j, which is vulnerable. A general statement for the Axis portfolio can be found here.
CVE-2021-4034Not affected since the Polkit's (PolicyKit) pkexec component is not used.
CVE-2021-4032Not affected since x86-computing architecture platform is not used in AXIS OS products. AXIS OS products utilize MIPS- and ARM-based computing architecture instead.
CVE-2021-3712  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2021-3711  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2021-3658  Affects AXIS OS 8.40 LTS and 9.80 LTS. The vulnerability will be patched in a timely manner on the AXIS OS LTS tracks. Please monitor Upcoming releases for more information.
CVE-2021-3450  Not affected
CVE-2021-3449  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2020-35452  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2020-27738  Not affected
CVE-2020-27737  Not affected
CVE-2020-27736  Not affected
CVE-2020-27009  Not affected
CVE-2020-26558  Affects Axis body worn solution and Axis wireless cameras. The vulnerability has been patched on the AXIS OS active track and the LTS tracks.
CVE-2020-25112  Not affected
CVE-2020-25111  Not affected
CVE-2020-25110  Not affected
CVE-2020-25109  Not affected
CVE-2020-25108  Not affected
CVE-2020-25107  Not affected
CVE-2020-25066  Not affected
CVE-2020-24383  Not affected
CVE-2020-24341  Not affected
CVE-2020-24340  Not affected
CVE-2020-24339  Not affected
CVE-2020-24338  Not affected
CVE-2020-24337  Not affected
CVE-2020-24336  Not affected
CVE-2020-24335  Not affected
CVE-2020-24334  Not affected
CVE-2020-17470  Not affected
CVE-2020-17469  Not affected
CVE-2020-17468  Not affected
CVE-2020-17467  Not affected
CVE-2020-17445  Not affected
CVE-2020-17444  Not affected
CVE-2020-17443  Not affected
CVE-2020-17442  Not affected
CVE-2020-17441  Not affected
CVE-2020-17440  Not affected
CVE-2020-17439  Not affected
CVE-2020-17438  Not affected
CVE-2020-17437  Not affected
CVE-2020-15795  Not affected
CVE-2020-14871  Not affected
CVE-2020-13988  Not affected
CVE-2020-13987  Not affected
CVE-2020-13986  Not affected
CVE-2020-13985  Not affected
CVE-2020-13984  Not affected
CVE-2020-13950  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2020-13938  Not affected
CVE-2020-13848  Affected. Concerned customers can temporarily disable the parameter Network.UPnP.Enabled in Plain config to mitigate this. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2020-12695  Not affected
CVE-2020-11993  Not affected
CVE-2020-11984  Not affected
CVE-2020-11899  Not affected
CVE-2020-11898  Not affected
CVE-2020-11897  Not affected
CVE-2020-11896  Not affected
CVE-2020-10713  Not affected
CVE-2020-9770  Affects Axis body worn and wireless devices and will be patched in a timely manner on the AXIS OS active track and the LTS tracks.
CVE-2020-9490  Products with AXIS OS 10.0 or lower are not affected.
For newer AXIS OS versions, the vulnerability has been patched on the AXIS OS active track. Updating is recommended.
CVE-2020-7461  Not affected
CVE-2020-3120  Not affected
CVE-2020-3119  Not affected
CVE-2020-3118  Not affected
CVE-2020-3111  Not affected
CVE-2020-3110  Not affected
CVE-2020-1971  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2020-1967  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2020-1938  Not affected
CVE-2020-1934  Not affected
CVE-2020-1927  Affected. The vulnerability has been patched on the AXIS OS active track and the LTS tracks. Updating is recommended.
CVE-2019-17567  Affects Axis door stations/intercoms. The vulnerability has been patched.. Updating is recommended.
CVE-2019-15916Affects LTS 2016. The vulnerability has been patched. Updating is recommended.
CVE-2019-12450  Affected. Has been patched on the LTS 2018 and LTS 2016 tracks.
CVE-2019-11135  Not affected
CVE-2019-11091  Not affected
CVE-2019-10744  Not affected
CVE-2019-1563Not affected
CVE-2019-1559Not affected
CVE-2019-1551  Not affected
CVE-2019-1547Not affected
CVE-2019-1125  Not affected
CVE-2018-25032Affected. The vulnerability will be patched in a timely manner on the AXIS OS active track and the LTS tracks. Please monitor Upcoming releases for more information.
CVE-2018-12207  Not affected
CVE-2018-12130  Not affected
CVE-2018-12127  Not affected
CVE-2018-12126  Not affected
CVE-2018-3646  Not affected
CVE-2018-3639  Not affected
CVE-2018-3620  Not affected
CVE-2018-3615  Not affected
CVE-2017-5754  Not affected
CVE-2017-5753  Affected. Axis has delivered patches to the affected products.
CVE-2017-5715  Affected. Axis has delivered patches to the affected products.
CVE-2016-20009  Not affected
CVE-2016-8863  Affected. Axis has delivered patches to the affected products.
CVE-2016-7409  Not affected
CVE-2016-7408  Not affected
CVE-2016-7407  Not affected
CVE-2016-7406  Not affected
CVE-2016-6255  Affected. Axis has delivered patches to the affected products.
CVE-2016-2183  Affected. The vulnerability has been patched on the active track and the LTS tracks.
CVE-2016-2147  Affected. Axis has delivered patches to the affected products.
CVE-2016-2148  Affected. Axis has delivered patches to the affected products.
CVE-2015-7547  Affected. Axis has delivered patches to the affected products.
CVE-2015-0235  Affected. Axis has delivered patches to the affected products.
CVE-2014-6271  Not affected
CVE-2014-3566  Affected. Axis has delivered patches to the affected products.
CVE-2014-0224  Affected. Axis has delivered patches to the affected products.
CVE-2014-0160  Not affected
CVE-2013-0156Not affected. AXIS OS devices do not use Ruby on Rails.
CVE-2009-1955  Not affected
CVE-2007-6750  Not affected
CVE-2007-6514  Not affected
CVE-2005-1797  Not affected
CVE-2005-0088  Not affected
CVE-2002-20001Affected. This is a known limitation of asymmetric cryptography and considered not relevant by Axis since the web server in Axis devices supports only 20 concurrent connections at a time, which renders the attack vector ineffective. It is recommended to use symmetric cryptography instead when connecting to Axis devices.
CVE-2002-0185  Not affected
CVE-1999-1412  Not affected
CVE-1999-1237  Not affected

Axis

The Axis archive covers vulnerabilities that are specific to Axis products and firmware components. Axis strongly recommends to patch affected devices and firmware.

ACV/CVEResult of investigation | Actions
CVE-2022-23410Affected. Axis has delivered a patch to the affected application. See Axis Security Advisory for more information.
CVE-2021-31989Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
CVE-2021-31988Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
CVE-2021-31987Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
CVE-2021-31986Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
CVE-2018-10664Affected. Axis has delivered patches to the affected products, see Axis Security Advisory for more information.
CVE-2018-10663Affected. Axis has delivered patches to the affected products, see Axis Security Advisory for more information.
CVE-2018-10662Affected. Axis has delivered patches to the affected products, see Axis Security Advisory for more information.
CVE-2018-10661Affected. Axis has delivered patches to the affected products, see Axis Security Advisory for more information.
CVE-2018-10660Affected. Axis has delivered patches to the affected products, see Axis Security Advisory for more information.
CVE-2018-10659Affected. Axis has delivered patches to the affected products, see Axis Security Advisory for more information.
CVE-2018-10658Affected. Axis has delivered patches to the affected products, see Axis Security Advisory for more information.
CVE-2018-9158Affected. Axis has delivered patches to the affected products.
CVE-2018-9157Disputed. This is an intended feature/functionality.
CVE-2018-9156Disputed. This is an intended feature/functionality.
CVE-2017-15885Affected. Axis has delivered patches to the affected products.
CVE-2017-12413Affected. Axis has delivered patches to the affected products.
CVE-2017-9765Affected. Axis has delivered patches to the affected products.
CVE-2016-AXIS-0812Affected. Axis has delivered patches to the affected products.
CVE-2015-8258Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
CVE-2015-8257Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
CVE-2015-8256Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
CVE-2015-8255Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
CVE-2013-3543Affected. Axis has delivered patches to affected AMC (AXIS Media Control) in AMC 6.3.8.0.
CVE-2008-5260Affected. Axis has delivered patches to the affected products.
CVE-2007-5214Affected. Axis has delivered patches to the affected products.
CVE-2007-5213Affected. Axis has delivered patches to the affected products.
CVE-2007-5212Affected. Axis has delivered patches to the affected products.
CVE-2007-4930Affected. Axis has delivered patches to the affected products.
CVE-2007-4929Affected. Axis has delivered patches to the affected products.
CVE-2007-4928Affected. Axis has delivered patches to the affected products.
CVE-2007-4927Affected. Axis has delivered patches to the affected products.
CVE-2007-4926Affected. Axis has delivered patches to the affected products.
CVE-2007-2239Affected. Axis has delivered patches to the affected products.
CVE-2004-2427Affected. Axis has delivered patches to the affected products.
CVE-2004-2426Affected. Axis has delivered patches to the affected products.
CVE-2004-2425Affected. Axis has delivered patches to the affected products.
CVE-2004-0789 Affected. Axis has delivered patches to the affected products.
CVE-2003-1386Affected. Axis has delivered patches to the affected products.
CVE-2003-0240Affected. Axis has delivered patches to the affected products.
CVE-2001-1543Affected. Axis has delivered patches to the affected products.
CVE-2000-0191Affected. Axis has delivered patches to the affected products.
CVE-2000-0144Affected. Axis has delivered patches to the affected products.
ACV-2020-100004Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
ACV-165813Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
ACV-147453Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
ACV-128401Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
ACV-120444Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.
ACV-116267Affected. Axis has delivered patches to the affected products. See Axis Security Advisory for more information.

Other

This section covers vulnerabilities that are not classified as CVEs but have been investigated by Axis.

TitleDetails
ONVIF / WS Discovery DDoS AttacksStatement for ONVIF-capable devices vulnerable for DDoS exploit.
Cross-Site Request Forgery (CSRF)Statement for Cross-Site Request Forgery in Axis products.

Common remarks from security scanner tools

Vulnerabilities and risks
All software has vulnerabilities that could potentially be exploited. Vulnerabilities will not automatically introduce risk. Risk is defined by the probability of a threat exploiting a vulnerability and the potential negative impact that a successful exploit can do. Reduce any of the two and you reduce the risk. Cybersecurity is about managing risks and risks are very hard to eliminate. The risk level depends on how a device/software is deployed, operated and managed. Reducing exposure (minimizing the opportunity) is an effective way to mitigate risks. The Axis hardening guide describes several security controls and recommendations how to minimize risks when deploying, operating and maintain an Axis device.

Some vulnerabilities may be easy to exploit, some may require a high level of sophistication, a special skillset and/or time and determination. A threat requires physical or network access to the device. Some vulnerabilities require administrator privileges to exploit. The CVSS (Common Vulnerability Scoring System) is a commonly used measure to help determine how easy a vulnerability is to exploit and potential negative impact. These scores are often based on software in critical systems or software that has high exposure to users and/or the Internet. Axis monitors the CVE (Common Vulnerabilities & Exposure) database that publish known vulnerabilities in software for the CVE entries that relate to the open-source packages used in Axis devices. Vulnerabilities that Axis identifies as limited risk will be remediated in future firmware releases. Vulnerabilities that Axis identifies as increased risk will be treated with priority resulting in an unscheduled firmware patch or the publishing of a security advisory informing about the risk and recommendations.

Scanning tools reporting false-positive
Scanning tools will typically try to identify known vulnerabilities by examining version numbers of software and packages found in a device. There is always the possibility that a scanning tool will report a false-positive remark, meaning that the device does not actually have the vulnerability. All remarks from such scanning tools need to be analyzed to validate that they in fact apply to the device. You need to make sure that the Axis device has the latest firmware version as it may include patches that address several vulnerabilities.

Boa web server

Background
Axis devices with firmware 5.65 and lower utilize the Boa web server for web interface and web-related functionality. The web server in Axis devices is being primarily used in two scenarios:

  • For general purpose machine-to-machine communication between the Axis device and the system it is connected to, usually a video management system that is accessing the Axis device via API interfaces such as ONVIF and VAPIX.

  • For configuration and maintenance tasks performed by installers, administrators and end users.

Similar to the newer Apache web server that is utilized by Axis devices with newer firmware, the Boa web server can be affected by vulnerabilities.

Motivation for false-positives
Security scanners may not recognize the web server used in older Axis devices and will therefore simply assume that those devices utilize the Apache web server. A vulnerability that applies to the Apache web server does not apply to the Boa web server by default if not stated otherwise.

Common report terms

  • "According to its banner, the version of Apache running..."

  • "The version of Apache httpd installed on the remote host is prior to 2.4.46. It is, therefore, affected by multiple vulnerabilities..."

Apache web server

Background
Axis devices base their web interface and other web-related functionality on the Apache web server. The web server in Axis devices is primarily being used in two scenarios:

  • For general purpose machine-to-machine communication between the Axis device and the system it’s connected to, usually a video management system that is accessing the Axis device via API interfaces such as ONVIF and VAPIX.

  • The installer, administrators and the end user performing (initial) configuration and maintenance tasks.

The Apache web server is a module-based open-source package. These individual modules can contain vulnerabilities. Below is a list of modules that are commonly loaded and used on Axis devices:

core_module (static)unixd_module (shared)authn_core_module (shared)proxy_fcgi_module (shared)authn_encoded_user_file_module (shared)
so_module (static)alias_module (shared)authz_core_module (shared)proxy_http_module (shared)authz_urlaccess_module (shared)
filter_module (static)rewrite_module (shared)authn_file_module (shared)proxy_wstunnel_module (shared)trax_module (shared)
brotli_module (static)cgid_module (shared)authz_user_module (shared)headers_module (shared)iptos_module (shared)
http_module (static)log_config_module (shared)authz_owner_module (shared)http2_module (shared)axsyslog_module (shared)
suexec_module (static)setenvif_module (shared)auth_digest_module (shared)systemd_module (shared)ws_module (shared)
mime_module (shared)ssl_module (shared)auth_basic_module (shared)authn_axisbasic_module (shared)
mpm_worker_module (shared)socache_shmcb_module (shared)proxy_module (shared)authz_axisgroupfile_module (shared)

Motivation for false-positives
A vulnerability that applies to a certain module in Apache needs to be loaded and used by the Axis edge device. Vulnerabilities of modules that are not loaded are not relevant.

Common report terms

  • "Apache HTTPD: mod_proxy_ftp use of uninitialized value (CVE-2020-1934)"

Risk and recommendations
Apache vulnerabilities will typically increase risk for public web services exposed to Internet targeting public users. The web server in Axis devices should only be used by installers, administrators and maintainers. It’s not recommended to expose Axis devices to be accessible over the Internet, nor should users have privileges to use a web browser to access a device during daily operations. Additional security controls such as IP Tables, only allowing approved clients to access and disabling/preventing web browsers from accessing can be applied to further reduce risks.

Apache Struts and Apache Tomcat

Background
As described in Apache web server, Axis devices base their web interface and web-related functionality on the open-source Apache web server. Other flavors of the Apache web server exist, such as Apache Struts or Tomcat, but are not utilized in Axis devices.

Motivation for false-positives
Axis utilizes the plain open-source Apache web server implementation of the Apache Software Foundation (ASF).

Common report terms

  • "A vulnerability has been discovered in Apache Tomcat..."

  • "The Jakarta multipart parser in Apache Struts..."

Web user sessions

Background
Axis devices base their web interface and other web-related functionality on the Apache web server. The web server in Axis devices is primarily being used in two scenarios:

  • For general purpose machine-to-machine communication between the Axis device and the system it is connected to, which usually is a video management system that is accessing the Axis device via API interfaces such as ONVIF and VAPIX.

  • When the installer, administrators and the end user perform (initial) configuration and maintenance tasks.

Currently, Axis devices do not support traditional web user based sessions where it's possible for the web session to e.g. logout or automatically expire after a certain amount of user-inactivity while the browser window is open. Every request through the web server on an Axis device has to be authenticated properly in order to be processed before the specific web session is open for further communication. In order to actively close a web session, the browser has to be closed.

Common report terms

  • "Concurrent User Sessions…"

  • "Insufficient Session Termination and Expiry…"

  • "Application Lacks Logout Feature…"

Risk and recommendations
Axis recommends to access the device through an application, such as a video management system (VMS), as primary video client instead of using the web browser if this would be subject of concerns. However, if the web browser is the only video client available, please have the following guidelines in mind:

  • Do not to visit untrusted websites or open e-mails from untrusted senders (this is of course a general cyber protection recommendation).

  • Use a different browser, which is not the system default, to configure the Axis device.

  • Create a viewer account on the device and use this when viewing the video stream. The viewer account has minimal privileges and no rights to change the configuration of the Axis device.

  • Do not leave the browser open unattended after configuration in order to minimize the attack window.

HTTP(S), HSTS policy

Background
Axis devices are configured by default to allow HTTP and HTTPS connections. It is recommended to make use of the first-boot generated self-signed certificate in order to perform the first initial configuration of the Axis device in HTTPS mode and to switch the configuration to only allow for HTTPS connections. HTTPS can be enforced e.g. from the web interface of the Axis device following Settings > System > Security. Furthermore, using HSTS (HTTP Strict Transport Security) to further increase device security is only automatically enabled when the Axis device is operated in HTTPS-only mode. HSTS is supported in the 2018 LTS (8.40), 2020 LTS (9.80) and the AXIS OS 10.1 ACTIVE track.

Motivation for false-positives
Security scanners may highlight that the Axis device under test is configured to allow HTTP only or HTTP & HTTPS at the same time. The detection is usually performed by validating the response from and checking the port status of the standard HTTP port 80. Axis recommends to use the device in HTTPS mode only by configuring this accordingly. Many security scanner audits are performed on Axis devices where this specific HTTPS-only configuration is not enforced by allowing the Axis device to respond to HTTP and/or HTTPS connections.

Common report terms

  • "HTTP (Port 80) insecure channel detected..."

  • "Web Portal Allows Unencrypted HTTP Connections By Default..."

  • "The remote web server is not enforcing HSTS, as defined by RFC 6797..."

  • "Insufficient Transport Layer Security…"

Cipher settings

Background
Throughout regular firmware updates, the list of available ciphers of the Axis device may receive updates. However, the actual used cipher list gets updated upon factory default only, or via manual user configuration. The reason why ciphers are not updated automatically during a firmware update is to allow the user to make a conscious decision in specifying certain ciphers for the installation and to make sure a cipher transition results in the desired outcome.

Common report terms

  • "Weak Cryptographic Key…"

  • "TLS/SSL Server Supports The Use of Static Key Ciphers…"

Risk and recommendations
It’s recommended to always use the strongest ciphers for HTTPS encryption when possible.

TLS 1.2 and lower: When using TLS 1.2 or lower you can specify the HTTPS ciphers to be used in Plain Config > HTTPS > Ciphers followed by a restart of the Axis device. Axis recommends to select all or any of the following strong-considered ciphers (updated September 2021), or to do a desired selection of your own.

ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

TLS 1.3: When using TLS 1.3, the HTTPS ciphers parameter in Plain Config has no effect as per default, only strong ciphers according to TLS 1.3 will be selected. The selection cannot be changed by the user and is updated through firmware update if needed. Currently the ciphers are (updated September 2021):

TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384

OpenSSL

Background
"Outdated OpenSSL version" is a common scanning remark on Axis devices. New vulnerabilities are discovered frequently in OpenSSL. Axis devices use OpenSSL as a common security core component in its products which provide security functionality for, e.g., HTTPS, certificate and encryption use cases. Similar to the Apache web server, OpenSSL is a modular-based platform; see below a list of modules that are not utilized by Axis products:

no-camelliano-heartbeatsno-mdc2no-srp
no-capiengno-hwno-rc5no-zlibthreads
no-dtlsno-ideano-sctp
no-dtls1no-md2no-seed

Motivation for false-positive
A vulnerability that applies to a certain module in OpenSSL needs to be loaded and used by the Axis edge device. Vulnerabilities of modules that are not loaded are not relevant but may still be flagged by the scanning tool.

Risk and recommendations
Vulnerabilities in OpenSSL do not pose any risks if the system is not using services such as HTTPS or 802.1x (TLS), SRTP (RTSPS) or SNMPv3. It is not possible to compromise the device itself as a potential attack would target the TLS connections and traffic. Exploiting OpenSSL vulnerabilities requires access to the network, a high skillset and a lot of determination.

First-boot generated self-signed certificate

Background
Axis devices come with a self-signed certificate that is generated automatically upon first-boot in order to provide the possibility to access the product via encrypted HTTPS connection and proceed with the initial setup of the product.

Motivation for false-positives
Security scanners may highlight the existence of the self-signed certificate as insecure and Axis recommends removing the self-signed certificate from the device and replacing it with a server certificate that is trusted in your organization. The self-signed certificate provides in that sense a confidential and secure mechanism for initial configuration but requires the user to still check the authenticity of the device itself.

Common report terms

  • "SSL Certificate Cannot Be Trusted..."

  • "SSL Self-Signed Certificat"

  • "X.509 Certificate Subject CN Does Not Match the Entity Name..."

Risk and recommendations
Self-signed certificates provide network encryption but do not protect from man-in-the-middle attacks (a rouge service impersonating a legitimate network service). If using services like HTTPS or 802.x it’s recommended to use Certificate Authority (CA) signed certificates. These must be supplied by the system owner using a public or private CA. If not using HTTPS or 802.1x there are no risks, and vulnerabilities in the underlying OpenSSL cannot be used to compromise the Axis device.

RSA key length

Background
As Axis devices come with a pre-loaded self-signed certificate, some devices have a shorter key length for the certificate than the 2048-bits. The certificate is also of a non-standard bit length to ensure most reputable CA’s will reject a signing request of this.

Motivation for false-positive
Security scanners may highlight this as insecure. It’s recommended to replace this certificate before production deployment as it is only intended for initial setup.

Common report terms

  • "SSL Certificate Chain Contains RSA Keys Less Than 2048 bits..."

  • "Length of RSA modulus in X.509 certificate: 1536 bits (less than 2048 bits)..."

Risk and recommendations
This vulnerability cannot be used to compromise the device. The default self-signed key length of Axis devices is set to 1536 bits in order to reduce the connection latency and time to generate the certificate and key. This key length provides enough protection for administrative tasks such as resetting device account passwords and initial setup of the Axis device. It’s recommended to replace the default certificate with a CA-signed certificate that should be provided by the system owner.

Linux distribution and built-in package manager

Background
Security scanners may support a so called "credentialed scan", using login data via web-login (HTTP) or via the maintenance access (SSH) in order to get more information about the device, its operating system and other software that might run on it. The Linux distribution is a Poky (OpenEmbedded) version with both local and upstream patches that may not match or can be recognized as such by the security scanner. Furthermore, the security scanner may expect the usage of a package manager, which is not used in Axis products.

Motivation for false-positives
Below is a comparison between a standard Linux distribution and the Axis-used distribution when it comes to the naming scheme. Please note that the latter may be recognized by the security scanner and pass while the Axis version may not pass. To illustrate this, we have the Axis-specific 4.9.206-axis and Linux-generic 54.9.206-generic version strings.

Common report terms

  • "Local security checks have NOT been enabled because the remote Linux distribution is not supported..."

Axis firmware version string

Background
Axis discloses vulnerabilities and provides updated firmware with security fixes so that customers can update and mitigate potential risks. Security scanners usually perform only a limited comparison of the firmware version the Axis product is running against older, outdated firmware that may contain vulnerabilities. A security scanner may not recognize the Axis firmware correctly, causing the scanner to flag the firmware running as vulnerable or insecure. Always consult the release notes for the firmware version of the product being tested since serious or critical vulnerability patches are listed in this document.

Motivation for false-positives
This may cause confusion in case the Axis device is running a custom firmware version or if the security scanner is not updated with the latest information of available Axis firmware. Below are some examples of Axis firmware version strings:

  • 9.70 .1

  • 9.70 .1_ beta

  • 9.70 .1. 5

Common report terms

  • "Axis Multiple Vulnerabilities (ACV-128401)..."

Architecture-dependent vulnerabilities

Background
Certain vulnerabilities may depend on the processor architecture that a device is using.

Motivation for false-positives
Axis edge devices such as cameras, encoders, wearables, audio and intercom products are based on MIPS and ARM architecture and are, e.g., not affected by x64 or x86 architecture-based vulnerabilities.

Common report terms

  • "OpenSSL rsaz_512_sqr overflow bug on x86_64 (CVE-2019-1551)..."

  • "x64_64 Montgomery squaring procedure..."

Outdated software components

Background
Security scanners highlight when a device is running an outdated version of a software component. It may even occur that the security scanner is unable to determine what version is actually running and flags it anyway. The security scanner simply compares the version of the software components running on the Axis device against the latest available version. The security scanner then outputs a list with security vulnerabilities, even without confirmation that the device under test is really affected as such. The above has been observed with the Linux kernel, OpenSSL, Apache, BusyBox, OpenSSH, Curl and others.

Motivation for false-positives
Open-source software components do receive new features, bug fixes and security patches throughout the course of their development, resulting in a high release cycle. Therefore, it is not uncommon that the Axis device being tested is not running the latest version of a software component. However, Axis is monitoring open-source software components for security vulnerabilities that could potentially be deemed critical by Axis, and will publish those accordingly in a security advisory.

Common report terms

  • "A vulnerable version of Linux was found to be utilized"

  • "According to its banner, the version of Apache running"

  • "According to its banner, the version of OpenSSL running..."

  • "Server Version Disclosure (Header)…"

Risk and recommendations
From AXIS OS 10.6 and onwards, it’s possible to disable the OpenSSL and Apache header information by disabling the parameter HTTP Server Header Comments in Plain config > System. This may result in vulnerabilities not being detected by security scanners since the package version is not easily identifiable. Axis strongly recommends to keep the device firmware up-to-date and encourages to perform security audits on your devices.

Unencrypted firmware and chip

Background
Security scanners may highlight the usage of flash chips used in the Axis device and mark them or the filesystems as such with "unencrypted".

Motivation for false-positives
Axis devices do encrypt user secrets such as passwords, certificates, keys and other files without necessarily encrypting the filesystem. Removable local storage such as SD cards are encrypted using LUKS encryption.

Common report terms

  • "The flash chip that contains the root file system of the device is not encrypted...."

  • "Information was extracted from the unencrypted firmware image, including...."

Risk and recommendations
This vulnerability cannot be used to compromise the device. The firmware does not contain any secrets by default and needs no other protection than the firmware signature to validate the integrity. Encrypted software makes it harder for security researchers to identify new (unknown) vulnerabilities and encrypted software may be used by vendors to hide deliberate flaws (security through obscurity). For Axis devices, root access is required to access the filesystem of the device to gain access to it. Sensitive information such as passwords are stored encrypted on the filesystem and require a high level of sophistication, skillset, time and determination to extract. Make sure to use a strong root password and keep it protected. Using the same password for multiple cameras simplifies management but increases the risk if one camera’s security is compromised.

Bootloader

Background
Security scanners may believe that they have identified the make and model of the bootloader implementation used in Axis devices and therefore highlight vulnerabilities related to secure boot or the bootloader itself.

Motivation for false-positives
Axis network video and network audio products utilize an in-house developed bootloader referred to as nandboot/netboot.

Common report terms

  • "A vulnerability in all versions of the GRUB2 bootloader has been detected..."

  • "An issue was discovered in Das U-Boot through 2019.07..."

UART / Serial console

Background
Physical inspection of the hardware of an Axis device may highlight the existence of a UART (Universal Asynchronous Receiver Transmitter) or serial console. Axis refers to this as a debug port. From AXIS OS 10.11 and onwards, the UART/serial console is disabled by default.

Motivation for false-positives
The debug port is used only for development and debugging purposes during engineering projects. While no sensitive information is exposed while being unauthenticated, the access to the debug port is password restricted and only the root user may login.

Common report terms

  • "Information Disclosure via UART/Serial Console..."

  • "Root Shell via UART/Serial Console..."

  • "On the PCB, the headers exposed a UART console..."

TCP/ICMP timestamp response

Background
While TCP and ICMP timestamp information is most often used as network tools to measure performance and availability of hosts, it can also be used to find time-related information about the network device itself. The ICMP timestamp information in ICMP type 13 (timestamp request) and ICMP type 14 (timestamp reply) communication provides information that could be used to calculate the actual device time in UTC. The TCP timestamp information can be used to calculate the so called round-trip time (RTT) information between two network hosts, which would make it possible to calculate the current uptime of the Axis device.

Motivation for false-positives
Security scanners may flag the existence of TCP and ICMP timestamp responses from Axis devices and recommend to disable TCP and ICMP timestamp responses whenever possible. Axis follows the recommendation of the Linux open-source community which doesn't consider the actual date/time information provided from these responses as a security risk by itself. Therefore the TCP/ICMP timestamp responses are still enabled by default. Furthermore, in newer Linux Kernel versions the actual calculation is considered unreliable as counter-measures ensure to make it unreliable to calculate the date/time information. As of today (February 2022), no known vulnerabilities or exploits have been disclosed that would justify disabling these services in Axis devices.

Common report terms

  • "TCP timestamp response found…"

  • "ICMP timestamp response found…"

System & security

Device hardening

For information on how to harden AXIS OS devices, please visit AXIS OS Hardening Guide. The hardening guide is written for, and can be applied to, all AXIS OS devices running an AXIS OS LTS or active track firmware. Legacy products running 4.xx and 5.xx firmware are also in scope.

Device access

Axis devices support a variety of ways to access the device over the network for (initial) configuration, maintenance and management purposes in order to ensure proper identity and access management and safeguarding over Axis devices.

 

Legacy access procedure (default user with default password)
Historically, Axis devices shipped from production and in their factory defaulted state have had their VAPIX and ONVIF interfaces activated for quick and easy out-of-the-box access on the network for clients connecting to them. In practice this means that a client, such as an application or video management system, can access the Axis network device via anonymous ONVIF calls as well as the default VAPIX user "root" with the default password "pass", prior to having configured anything on the Axis network device itself.

Modern access procedure (default user with no password)
With the updated access procedure in place, the VAPIX and ONVIF interfaces have been disabled and the root user’s password is no longer set in factory default state when shipped from production. This means that it is no longer possible for a client to access or configure the device out-of-the-box without activating VAPIX or ONVIF first. The new access procedure has been implemented in the following AXIS OS major platform releases:

  • Firmware 5.51.6

  • Firmware 6.50.4 (2016 LTS)

  • Firmware 8.40.3 (2018 LTS)

  • Firmware 9.40.1 and higher (ACTIVE Track)

Furthermore, the new access procedure has been rolled out in new firmwares on individual product releases that are located outside of the above major platform releases, such as:

  • Firmware 1.65.x

  • Firmware 1.8x.x

  • Firmware 5.75.x

  • Firmware 6.53.x

  • Firmware 6.55.x

  • Firmware 7.15.x

Interface calls that do not require authentication (=anonymous) are still allowed (e.g. ONVIF get capabilities, VAPIX get brand information) for device-identification purposes. An Axis device can be identified in its unconfigured state by its HTTP response header which is set to "AXIS-Setup:vapix" when an VAPIX or ONVIF API call is made, as illustrated below:

HTTP/1.1 401
Unauthorized Date: Thu, 19 Sep 2019 18:15:20 GMT
Server: Apache/2.4.39 (Unix) OpenSSL/1.1.1c
Axis-Setup: vapix

The VAPIX and/or ONVIF interface in the Axis device can be activated using the following methods:

  1. The VAPIX interface is activated when the VAPIX "root" user password is set, either via VAPIX System Settings API, as described in the System settings in the VAPIX library (example: http://ip-address/axis-cgi/pwdgrp.cgi?action=add&user=root&pwd=pass&grp=root&sgrp=admin:operator:viewer:ptz) or by using the Axis device's web interface during the installation wizard process.

  2. The ONVIF interface can only be activated after the VAPIX interface has been activated. After that, the ONVIF interface can be activated by creating an ONVIF user via the device's web interface in Settings > System > ONVIF.

  3. In addition to that, an ONVIF user can also be created using the ONVIF Profile S specifications. The request to create an ONVIF user is channeled through the /vapix/services API which is available once the VAPIX interface is activated. An example of the API call to create an ONVIF user is described below:

POST /vapix/services HTTP/1.1
<SOAP-ENV:Envelope xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tds="http://www.onvif.org/ver10/device/wsdl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:onvif="http://www.onvif.org/ver10/schema"
xmlns:tt="http://www.onvif.org/ver10/schema"
xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope">
<SOAP-ENV:Body>
<tds:CreateUsers xmlns="http://www.onvif.org/ver10/device/wsdl">
<User>
<tt:Username>admintt:Username>admin>
<tt:Password>admintt:Password>admin>
<tt:UserLevel>Administratortt:UserLevel>Administrator>
</User>
</tds:CreateUsers>
</SOAP-ENV:Body></SOAP-ENV:Envelope>

I forgot my password, what to do?
There is no possibility to recover lost or forgotten access credentials to an Axis device. The Axis device needs to be reset to its factory default settings in order to reconfigure it with new access credentials.

Axis device ID (IEEE 802.1AR)
Axis devices equipped with Axis Edge Vault are provisioned with an Axis device ID. The Axis device ID conforms with the IEEE 802.1AR standard and can be verified using the Axis device ID Root CA certificate. Please remember to verify the download against the provided sha256 hash before using Axis device ID Root CA as a trust anchor.

CertificateIntegrity checksum SHA256
Download ECC certificate32ca2dc3230764f2d638b54d2826c050613266162932a2d7e766f81a51e3aa60
Download RSA certificatefc1a8b0d6585dc74215bcc4e87e852af9258637062d0fc4c417554a6f1b5a85e

Telnet
Telnet is supported by Axis devices with firmware version 5.50 and lower. Follow the instructions below in order to use Telnet on the device:

  1. Access http://ip-address/admin-bin/editcgi.cgi?file=/etc/inittab

  2. Remove hash from the below line in the configuration file #tnet:35:once:/usr/sbin/telnetd

  3. After removing the hash, the line should look like this: tnet:35:once:/usr/sbin/telnetd

  4. Save the file and restart the Axis device

 

FTP
Follow the instructions below in order to use FTP on Axis devices:

  1. Enable FTP from Plain Config > Network > FTP

  2. Save the settings. The Axis device is now reachable via FTP, no reboot is needed.

 

SSH in AXIS OS 5.60 and higher
Follow the instructions below in order to use SSH on devices with AXIS OS 5.60 and higher:

  1. Enable SSH from Plain Config > Network > SSH

  2. Save the settings. The Axis device is now reachable via SSH, no reboot is needed.

 

SSH in AXIS OS 5.50 - 5.55
Follow the instructions below in order to use SSH on devices with AXIS OS 5.51 and lower:

  1. Access the ssh file by using this link: http://ip-address/admin-bin/editcgi.cgi?file=/etc/conf.d/ssh

  2. Enable SSH by setting SSHD_ENABLED=“yes”

  3. Save the ssh file

  4. Restart the Axis device

 

Device access logging

In this section you can read about how successful and unsuccessful login attempts are logged in the Axis device’s log system depending on the network protocol that is used. At all times, it is recommend to configure a remote syslog server where the Axis device can send its syslogs. This will ensure that the logs can be kept and reviewed for a suitable time and not get erased after e.g. a reboot or factory default of the device itself.

SSH

Successful

[ INFO ] sshd[17583]: Accepted password for root from 10.197.252.38 port 41988 ssh2

Unsuccessful

[ INFO ] sshd[17727]: Failed password for root from 10.197.252.38 port 41994 ssh2
After 5 failed attempts[ ERR ] sshd[17727]: error: maximum authentication attempts exceeded for root from 10.197.252.38 port 41994 ssh2 [preauth]
[ INFO ] sshd[17727]: Disconnecting authenticating user root 10.197.252.38 port 41994: Too many authentication failures [preauth]

 

FTP

Successful

[ INFO ] vftpd[18263]: Accepted request from 172.27.0.3 50333
[ INFO ] vftpd[18263]: User root logged in.

Unsuccessful

[ INFO ] vftpd[18163]: Accepted request from 172.27.0.3 64936
[ INFO ] vftpd[18163]: Incorrect username/password. User access from 172.27.0.3 denied.
[ INFO ] vftpd[18163]: Client 172.27.0.3 disconnected.

 

RTSP protocol

Successful

[ NOTICE ] monolith: RTSP UNKNOWN session h4fIznyTZNy16tLt created from 172.25.155.83

Unsuccessful

[ WARNING ] monolith: Rtsp login failed from 172.25.155.83

 

HTTP(S) protocol

Successful*

[ NOTICE ] httpd[22254]: root from 10.197.240.111 /axis-cgi/admin/accesslog.cgi GET 200

Unsuccessful**

[ NOTICE ] httpd[21459]: root from 10.197.240.111 failed to access /axis-cgi/usergroup.cgi.Password mismatch

*Requires the Access Log parameter to be enabled from Plain Config > System.
**Only login attempts using the correct username will be logged.

 

IP filtering***

Unsuccessful

IP_FILTER: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:30:9c:23:e2:48:b5:08:00 SRC=172.25.201.50 DST=172.25.201.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=60428 PROTO=UDP SPT=137 DPT=137 LEN=58
IP_FILTER: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:30:9c:23:e2:48:b5:08:00 SRC=172.25.201.50 DST=172.25.201.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=60429 PROTO=UDP SPT=137 DPT=137 LEN=58

***IP filtering in Axis devices is a network layer-2 Linux Kernel functionality that blocks network packages depending on the configured rules. No authentication will be performed if an unsuited source IP-address is trying to access the Axis device since the network transmission is blocked right at the layer-2 network while authentication is performed on higher level application layers. Corresponding logs of the IP filtering can be created when the VAPIX parameter is enabled in Plain Config > Network in the IP Filtering section.

 

PreventDosAttack****

Unsuccessful

[ WARNING ] httpd[22254]: [evasive20:warn] [pid 22254:tid 1428104112] [client 172.25.201.116:42058] Blacklisting address 172.25.201.116: possible DoS attack.

****PreventDosAttack can be enabled from Plain Config > System and will only log unsuccessful login attempts and correspondingly log when a source IP-address is blocked.

 

User management configuration
From AXIS OS 10.9 and onwards, user configuration related changes are logged in the system log and can therefore be sent to a remote syslog server. In AXIS OS, VAPIX and ONVIF users are separated by having their own management interfaces and access rights. The below table illustrates what log messages to expect when certain changes to the user management configuration are done:

API interfaceUse caseLog message
VAPIXAdd userVAPIX user andre from IP-address 10.197.240.104 created VAPIX user benjamin with role Administrator
VAPIXChange access groupVAPIX user susanna from IP-address 10.197.240.104 changed VAPIX user linda role from Administrator to Operator
VAPIXChange passwordVAPIX user root from IP-address 10.197.240.104 changed VAPIX user thomas password
VAPIXDelete userVAPIX user root from IP-address 10.197.240.104 deleted VAPIX user sebastian with role Operator
ONVIFAdd userVAPIX user root from IP-address 10.197.240.104 created ONVIF user andre with role Administrator
ONVIFChange access groupONVIF user andre from IP-address 10.197.240.104 changed ONVIF user susanna role from Administrator to Operator
ONVIFChange passwordONVIF user thomas from IP-address 10.197.240.104 changed ONVIF user andre password
ONVIFDelete userONVIF user pernilla from IP-address 10.197.240.104 deleted ONVIF user sebastian with role Operator

Brute force delay protection

Axis devices running AXIS OS 7.30 and higher can be configured to automatically block HTTP/HTTPS requests coming from a client in the network (IP address). For a certain amount of time, a defined number of authentications fail. This feature can help in avoiding and to protect the Axis device from brute-force attacks, or from network clients that unintentionally imitate a similar behavior. The brute force delay protection can be configured in Plain config > System. Below you'll find two use cases and configuration examples followed by an explanation of each parameter used.

Trying to access the web interface from the network client that was previously identified as a threat would result in a HTTP 403 Forbidden response.

Furthermore, the Axis device would log the following internally in the system log:
2021-08-16T12:17:35.119+02:00 axis-accc8ed910b9 [ WARNING ] httpd[592]: [evasive20:warn] [client 172.25.201.116:41972] Blacklisting address 172.25.201.116: possible DoS attack.

Configuration example 1
After three login attempts within 30 seconds, the client IP address gets blocked for 10 seconds. Every following failed request within the 30 seconds page interval will result in the DoS Blocking Period being extended by another 10 seconds.

 

Configuration example 2
After two login attempts within 10 seconds, the client IP address gets blocked for 10 seconds. Every following failed request within the 10 seconds page interval will result in the DoS Blocking Period being extended by another 10 seconds.

 

DOSBlockingPeriod: The blocking period is the amount of time (in seconds) a client will be blocked if they are added to the blocking list. During this time, all subsequent requests from the client will result in a 403 (Forbidden), and the timer being reset (e.g. another 10 seconds). Since the timer is reset for every subsequent request, it is not necessary to have a long blocking period; in the event of a DoS attack, this timer will keep resetting.

DOSPageCount: This is the threshold for the number of requests for the same page (or URI) per page interval. Once the threshold for that interval has been exceeded, the IP address of the client will be added to the blocking list. A page is considered http://ip-address/system/plainconfig.

DOSPageInterval: The interval for the page count threshold; defaults to 1 second intervals.

DOSSiteCount: This is the threshold for the total number of requests for any object by the same client on the same listener per site interval. Once the threshold for that interval has been exceeded, the IP address of the client will be added to the blocking list. A site is considered http://ip-address/

DOSSiteInterval: The interval for the site count threshold; defaults to 1 second intervals.

Signed AXIS OS firmware

About signed firmware
Signed AXIS OS firmware is a feature that was introduced to ensure that only verified and trusted firmware is uploaded and used in Axis devices. In this section you can read about technical details that will ensure that the correct update and downgrade paths are chosen to avoid issues. For more general information, see the white paper about cybersecurity features in Axis products..

Axis started to sign its firmware from AXIS OS 8.30.1. Until the release of AXIS OS 9.20.1, devices would still accept unsigned and signed firmware for backwards compatibility, but after the release of AXIS OS 9.20.1, signed firmware was fully activated and Axis devices would then only accept firmware signed by Axis. This means it is not possible to perform a firmware rollback or downgrade below AXIS 8.30.1, which is the version where Axis initially started to sign firmware.

Common questions
Question 1: My device runs AXIS OS 9.10.1 and I want to downgrade to AXIS OS 8.40 LTS (Long Term Support Track), does this work?
Answer: Yes, this will work.

Question 2: My device runs AXIS OS 9.20.1 and I want to downgrade to AXIS OS 8.20.1 or lower as my VMS requires me this to keep backwards compatibility, does this work?
Answer: The downgrade will fail. The unsigned firmware will be rejected by the device and it will continue to run AXIS 9.20.1. In order to perform such a downgrade one would need to downgrade in two steps using AXIS OS 8.30.1 as a gateway. So first from 9.20.1 -> 8.30.1 -> 8.20.1 or further below. Please note that Axis does not encourage downgrades to older, unsupported firmware in general.

Troubleshooting
How to identify that a firmware upgrade did not work because of an unsigned firmware? In case a user tries to upload an unsigned firmware, one of the following messages is displayed in the log files of the camera when a firmware upgrade fails due to signed firmware

[ERR] fwmgr: Unknown firmware domain
[ERR] fwmgr: Image has no signature.
[ERR] fwmgr: No custom firmware certificate for camera group 'xxx'.

Certificate management

In this section you can read about supported digital signature algorithms (DSA) as well as cryptography that is supported by Axis products.

Certificate cryptography support

  • Supported cryptography: RSA, ECC NIST P-256, ECC NIST P-384, ECC NIST P-521*

  • PEM or DER formatted certificates (.PEM, .DER, .CER and .CRT file extension) with PKCS#1 formatted private keys

  • PKCS#12 formatted certificates (.PFX, .P12 file extension)**

  • Wildcard certificates support: Yes

  • Max size of .PFX and .P12 certificates: 102400 bytes***

*ECC cryptography support for Axis devices without TPM module has been added from AXIS OS 10.1 and higher.
**From AXIS OS 5.50 and higher
***Max size of .PFX and .P12 certificates except for devices running AXIS OS 9.20 and lower where a maximum file size of 10240 bytes is supported only.

 

Private key cryptography support

  • Hash algorithms supported: SHA-224/256/384/512*

  • Max RSA private key size (Uploadable): 4096-bit*

  • Max RSA private key size (self-signed certificate, certificate signing request): 2048-bit**

  • Max ECC private key size (uploadable): Defined by the supported ECC cryptographic (Example: P-256 = 256-bit)

  • Max ECC private key size (self-signed certificate, certificate signing request): Not supported

*Max key bit size of private keys possible to upload except for Axis devices supporting a TPM module, which has a maximum key bit size of 2048-bit and SHA256 hash algorithm.
**Max key bit size of private key generated by the Axis device when creating a self-signed certificate (SSC) or issuing a certificate signing request (CSR). During the very first boot, the Axis device will generate a self-signed certificate automatically, which prior to AXIS OS 10.1 had a private key bit size of 1536-bit. Starting with AXIS OS 10.1 and higher, the size is 2048-bit.

 

Self-signed certificate
Axis devices come with a pre-installed self-signed certificate in order to provide the possibility to access the device via encrypted HTTPS connection and proceed with the initial setup of the device. Security scanners might highlight the existence of any self-signed certificate that is uploaded on the device as insecure (e.g. "SSL Certificate Cannot Be Trusted" or "SSL Self-Signed Certificate"). Axis recommends removing the self-signed certificate from the device and replace it with a server certificate that is trusted in your organization when HTTPS connection is the preferred type of connection to the device.

 

CA certificates
CA certificates are certificates used by the Axis device to validate/verify the authenticity of other servers in the network. In AXIS OS, OpenSSL is the cryptography backend. This means that CA certificates that are going to be uploaded in the CA certificate section of the Axis device need to fulfil one of the following:

  • X509v3 CA certificate with basicConstraints extension CA:TRUE*

  • X509 v1 self-signed certificate

  • The keyUsage attribute extension with bit keyCertSign set but without basicConstraints

  • Netscape Certificate Type extension saying that it is CA certificate

*The CA:TRUE or CA:FALSE attribute also decides whether the CA certificate is allowed to sign other certificates.

 

Certificate signing request (CSR)
A certificate signing request (CSR) can be done with an already existing/created certificate listed in the Axis device. The certificate request in PEM format can be sent to a certificate authority (CA) for signing/verifying. After the signed certificate is returned from the CA, it needs to be uploaded on the Axis device and be compared/verified with the original certificate request. If all information is correct, the certificate upload will end successfully. However, if system changes occur between the time the CSR was issued and the certificate was uploaded, the process can be interrupted. Possible reasons why a certificate upload would fail are:

  • The Axis device has been factory defaulted in the meantime

  • The certificate used for the signing request has been removed or changed in the Axis device

  • The Common Name (CN) of the certificate does not match the Axis device IP address or hostname anymore

  • The CA rejects the used cipher with which the Axis device created the certificate request

Decommissioning

When decommissioning an Axis device, a factory default should be executed. Then all data is erased by overwriting/sanitization.

Axis devices use both volatile and non-volatile memory, and while the volatile memory is erased when removing the power, information stored in the non-volatile memory remains and is made available again at start-up. The common known concept of just removing the data pointers to make the current data invisible for the filesystem is not applied, which is why a factory default is required. The table below contains more information about data stored in the non-volatile memory.

Information and dataErased after factory default
VAPIX and ONVIF users/passwordsYes
Root user/passwordYes
Certificates and private keysYes
Self-signed certificateYes
TPM and Axis Edge Vault stored informationYes
WLAN settings and users/passwordsYes
Custom firmware certificates*No
SD card encryption keyYes
SD card data**No
Network share settings and users/passwordsYes
Network share data**No
User configuration***Yes
Uploaded applications (ACAPs)****Yes
Production data and lifetime statistics*****No
Uploaded graphics and overlaysYes
RTC clock dataYes

* Custom firmware certificates are used in the signed firmware process to allow the user to e.g. upload Axis official firmware.
** Recording and images stored on edge storage (SD card, network share) have to be deleted by the user separately.
*** All user-made configurations, from setting the initial root password to network-, O3C-, event-, image-, PTZ- and system configurations.
**** Applications that are pre-installed are kept but their configuration is erased nevertheless.
***** Production data (calibration, 802.1AR production certificates) as well as lifetime statistics include non-sensitive and non-user related information.

How to upgrade

Axis offers product firmware management according to the active track or the long-term support (LTS) tracks. Regardless of the track chosen, it’s recommended to upgrade the firmware regularly in order to get the latest security updates. The firmware can be upgraded using AXIS Device Manager, AXIS Camera Station, AXIS Companion, HTTP or FTP.

Note
  • If using AXIS A1001 in cluster mode, make sure to upgrade all controllers. Either all at a time using AXIS Device Manager or straight after each other using the web interface or FTP. The entire cluster should always be on the same firmware.
  • The following Axis devices require a firmware upgrade via the latest available LTS 2018 (8.40) prior to upgrading to AXIS OS 10.9 or later: AXIS D2050-VE, AXIS FA54, AXIS M3057-PLVE, AXIS M3058-PLVE, AXIS P1367/-E, AXIS P1368-E, AXIS P1445-LE, AXIS P1445-LE-3, AXIS P1447-LE, AXIS P1448-LE, AXIS P3227-LV/-LVE, AXIS P3228-LV/-LVE, AXIS P3807-PVE, AXIS Q1645/-LE, AXIS Q1647/-LE, AXIS Q1659, AXIS Q3515-LV/-LVE, AXIS Q3517-LV/-LVE/-SLVE, D101-A XF P3807, ExCam XF P1367, ExCam XF Q1645 and F101-A XF P1367.
AXIS Device Manager or AXIS Camera Station
  1. Go to the Device Manager Tab in Axis Device Manager or Configuration Tab > Devices - Management in AXIS Camera Station.

  2. Select all devices that should be upgraded.

  3. Right click and select Upgrade Firmware, which will open a dialog with a list of device models and the current firmware version installed in each device.

  4. In the Upgrade Firmware dialog there are two options:

    • Check for Updates which requires internet access.

    • Browse to locate firmware file e.g. on hard drive or memory stick.

  5. Check for updates:

    • Select Check for Updates to download a list of all firmware available for all device models.

  6. Browse:

    • Select browse to locate firmware files and import them. It is possible to select and import several files at the same time.

  7. Each device model will show a dropdown containing all available firmware for a model. Firmware will be sorted by “Long Term Support” (LTS) and “Active” software tracks in the dropdown.

  8. Select the firmware to install for each device model.

  9. Click OK to start upgrading the devices.

Note

By default, firmware upgrade is done for all the selected devices at the same time. The upgrade order can be changed in Configuration > Connected services > Firmware upgrade settings. Once a firmware update has been started, the devices will be unavailable until the installation and restart of the devices has completed successfully.

For more information, see the help in AXIS Device Manager/AXIS Camera Station.

HTTP
Note

The procedure to update firmware differs slightly depending on the version of the installed web interface (before and after 7.10.1). For AXIS Q1659, the new web interface was introduced in firmware version 6.55.1.

Upgrade instructions when using the old web interface

  1. Download the upgrade file to a directory that is accessible from your local computer.

  2. Open the product's start page (e.g. http://192.168.0.90) in a web browser.

  3. Click the Setup link and log in as "root" (or any other user with administrator privileges). You must be logged in as an administrator to upgrade the unit.

  4. Click System Options in the menu to the left.

  5. Click Maintenance.

  6. Click the Browse button in the Upgrade Server section.

  7. Select the upgrade file you downloaded (and maybe decompressed) from our site. This file is typically named after the product and firmware version.

  8. Click the Open button.

  9. Click the Upgrade button in the Upgrade Server section.

  10. Wait for the flash load to complete, which may take 1-10 minutes. The upgrade procedure occurs in four steps:

    • Step 1: Shut down. Running applications are shut down and active connections are terminated.

    • Step 2: Uploading firmware. The old firmware will be erased and the new firmware will be saved. During this step, the power LED will blink green/amber. After a while the progress of the upgrade will be displayed in the web browser.

    • Step 3: Reboot. The system restarts automatically.

    • Step 4: Reconfiguration. The new firmware settings are configured to match the previous settings. The color of the status LED will be amber during this step.

  11. After the upgrade has completed, the unit will automatically initiate the system, during which the status LED blinks amber. When initiation is complete and the system is ready for use, the status LED will be green.

 

Upgrade instructions when using the new web interface

  1. Download the upgrade file to a directory that is accessible from your local computer.

  2. Open the product's start page (e.g. http://192.168.0.90) in a web browser.

  3. Log in as "root" (or any other user with administrator privileges).

  4. Click Settings to the right.

  5. Click System-tab.

  6. Click Maintenance.

  7. Select the upgrade file you downloaded (and maybe decompressed) from our site. This file is typically named after the product and firmware version.

  8. Click the Open button.

  9. Click the Upgrade button in the Upgrade Server section.

  10. Wait for the flash load to complete, which may take 1-10 minutes. The upgrade procedure occurs in four steps:

    • Step 1: Shut down. Running applications are shut down and active connections are terminated.

    • Step 2: Uploading firmware. The old firmware will be erased and the new firmware will be saved. During this step, the power LED will blink green/amber. After a while the progress of the upgrade will be displayed in the web browser.

    • Step 3: Reboot. The system restarts automatically.

    • Step 4: Reconfiguration. The new firmware settings are configured to match the previous settings. The color of the status LED will be amber during this step.

  11. After the upgrade has completed, the unit will automatically initiate the system, during which the status LED blinks amber. When initiation is complete and the system is ready for use, the status LED will be green.

FTP
Note
  • Starting with firmware version 7.30.1 and onwards, the FTP server is disabled by default. In order to use the instructions below it first needs to be enabled via the web interface: Settings > System > Plain config > Network > NetworkFTP
  • This section is not applicable for AXIS Companion Line cameras.
  1. You must be at the command prompt and in the directory that contains the upgrade file.

    Example: C:\Axis\Product\Firmware

  2. From the command prompt, open an FTP connection to the unit you wish to upgrade.
    (Do not use a Windows based FTP program to do this, use command line FTP programs only.)

  3. Log in as “root”. You must be logged in as the root user to upgrade the unit.

  4. Change to binary transfer mode by typing "bin" and press enter.

  5. Type "hash" and press enter. This will allow you to see how the upgrade progresses.

  6. Type the command "put XXX.bin flash" where XXX.bin is the name of the upgrade file you downloaded (and maybe decompressed) from our site. This file is typically named after the product and firmware version.

  7. Wait for the flash load to complete, which may take 1-10 minutes. The upgrade procedure occurs in four steps:

    • Step 1: Shut down. Running applications are shut down and active connections are terminated.

    • Step 2: Uploading firmware. The old firmware will be erased and the new firmware will be saved. During this step, the power LED will blink green/amber. After a while, the progress of the upgrade will be displayed in the command prompt.

    • Step 3: Reboot. The FTP session terminates and the system starts automatically.

    • Step 4: Reconfiguration. The new firmware settings are configured to match the previous settings. The color of the status LED will be amber during this step.

  8. After the upgrade has completed, the unit will automatically initiate the system, during which the status LED blinks amber. When initiation is complete and the system is ready for use, the color of the status LED will be green.

How to downgrade

Downgrading the firmware of an Axis product might be necessary in order to establish compatibility to 3rd party systems which do not support later Axis firmware versions.
The downgrade is performed in the same way as an upgrade. Instructions are available in How to upgrade.

Note

Downgrading to a lower version could cause implications on a system’s health and stability. It is only recommended to downgrade the firmware of an Axis product using the standard upgrade process if performed in combination with a factory default of the product. The factory default can be performed simultaneously during the downgrade, or manually by the user afterwards.
As of firmware version 10.1, a factory default is mandatory when downgrading the firmware.

Known limitations
Support for a new type of NAND flash memory was added to a number of products in service releases 6.55.5.1 and 7.30.1.1. Products receiving the new type of memory also received a new hardware id (HWID). The new flash memory will not allow a firmware downgrade, meaning that products with the new HWID cannot downgrade to a firmware prior to the service release.

See list of affected products below. To find your product’s HWID, see the property “HardwareID” in the server report

Products affected in service release 7.30.1.1Old HWIDNew HWID
AXIS Companion 36080680C
AXIS Companion Cube L801809
AXIS Companion Cube LW800808
AXIS Companion Dome V80280A
AXIS Companion Dome WV80480B
AXIS M1045–LW710780
AXIS M1065–L70F781
AXIS M1065–LW70E782
AXIS M2026–LE Mk II74B784
AXIS M3044–V72D785
AXIS M3044–WV72E786
AXIS M3045–V71B787
AXIS M3045–WV72F788
AXIS M3046–V730789
AXIS M3046–V 1.8 mm75D78A
AXIS M3047–P73678B
AXIS M3048–P73778C
AXIS M3106–L/—LVE Mk II74E77D
Products affected in service release 6.55.5.1Old HWIDNew HWID
AXIS P3224–LV Mk II769.1
AXIS P3224–LVE Mk II769.2
AXIS P3225–LV Mk II769.3
AXIS P3225–LVE Mk II769.4

How to rollback

When upgrading the firmware in an Axis product, a restore point of the previous state of the product and its entire configuration is made before the upgrade. This restore point is available to go back to after the firmware upgrade has been performed in case of an unexpected issue. This feature is called firmware rollback.

The firmware rollback feature can be found in the Axis product’s web interface under Settings > System > Maintenance. A video clip with instructions can also be found in Configuration tips. The feature was introduced in firmware version 7.40, which means that the Axis product must have been upgraded to 7.40 or later in order to be able to perform a rollback.

It is recommended to use the firmware rollback function to re-establish system functionality and to contact Axis Technical Support for further instructions and troubleshooting techniques. No restore point is available when the product is in a factory defaulted state.

Media streaming

Video streaming in Axis products

The purpose of this section is to encourage and enable partners, system integrators and end users to consider their individual setup when configuring general video streaming settings in Axis devices in order to ensure optimal performance and user experience.

General considerations
Axis video capable devices deliver a video stream according to the desired requirements of the system it is used in and according to the specifications of the Axis device itself. The following information provides a foundation and understanding of how video streaming in Axis devices works and what settings to consider.

About video streaming clients
The Axis device as such recognizes several types of clients that it encodes and distributes video streams to. The clients can be categorized as internal and external, and they are served with video streams as they are requested. See examples below for each category:

Internal clients

  • Action rule for (S)FTP/HTTP(S) MJPEG image upload

  • Action rule for (S)FTP/HTTP(S) video clip upload

  • Action rule for recording videos to SD card and network share

  • Continuous recording to SD card or network share

  • (Analytics) ACAPs that request video stream or MJPEG images

External clients

  • Viewing video in web interface

  • Viewing video via secure remote access

  • Live view and recording to AXIS Companion

  • Live view and recording to AXIS Camera Station

  • Live view and recording to 3rd party video management system

Unique encoded streams

The number of unique encoded streams tells us how many different video streams an Axis device is encoding. This information can be obtained in the server report of devices with firmware version 5.70 or higher in the section Snapshot of the current (caching) streams. For devices with AXIS OS version 10.7 or higher, this information is available in the section Snapshot of all running streams. The number of unique encoded streams are affected by stream properties, as will be shown in the examples below. Note that the illustrations are taken from a graphical user interface to better illustrate the use case.

Example 1: In this example, the Axis device is encoding a total number of three unique encoded video streams. The video streams differ in one stream property - resolution - and since the resolution is different, the Axis device needs to encode each video stream separately.

 

Example 2: In this example, the Axis device is encoding a total number of two unique encoded video streams. The video streams differ in one stream property - frame rate (fps) - and since the frame rate is different, the Axis device needs to encode each video stream separately.

Conclusion: Axis devices need to encode video streams according to their stream properties. If stream properties, such as fps, compression, VideoKeyFrameInterval (GOP), etc. differ from one requested video stream to another, the Axis device is forced to encode separate video streams. This may have an impact on video streaming performance and generally it is recommended to optimize the setup towards the least amount of video streams possible.

Note: From AXIS OS 10.8 and onwards a single unique encoded video stream can be distributed to a maximum of eight physical network clients at the same time. If more physical network clients need to pull the same video stream, we suggest implementing multicast video streaming instead, or to have additional clients request another unique encoded video stream.

Distributed streams

The number of distributed video streams refers to the number of actual physical network clients in the network and the number of video streams that they are requesting. For example, it would be possible to video stream from AXIS Camera Station and from the web interface of the Axis device from the same physical network client.

This information can be obtained in the server report of devices with firmware version 9.80 and higher in the section Snapshots of the current outgoing RTP streams. This section lists the number of distributed streams in relation to their destination IP address. The distributed stream is declared as a ratio of Number of video streams:Number of physical network clients.

Example 1: In this example, the number of distributed streams is 2:2 because the Axis device streams in total two video streams to two physical network clients.

 

 

Example 2: In this example, the number of distributed streams is 3:2 because the Axis device streams in total three video streams to two physical network clients. Observe that the Physical network client 1 is requesting the Unique encoded stream 1 twice.

 

Conclusion: An Axis device can stream a single or many video streams to either the same or many physical network clients. A physical network client is defined by the number of video streams it is requesting and its destination IP address in the network.

Note: From AXIS OS 10.8 and onwards a single unique encoded video stream can be distributed to a maximum of eight physical network clients at the same time. If more physical network clients need to pull the same video stream, we suggest implementing multicast video streaming instead, or to have additional clients request another unique encoded video stream.

Unique encoded streams and distributed streams

With the information above, we can now explain the relation between the number of unique encoded streams in relation to the number of distributed streams to physical network clients.

Example 1: In this example, two physical network clients are requesting a unique encoded stream each. This results in a distributed stream to each physical network client.

 

 

 

Example 2: In this example, the Axis device is encoding two unique streams and distributes them to three physical network clients.

 

 

 

Example 3: In this example, the Axis device is encoding a single unique stream and distributes it to two physical network clients via multicast. Observe that this setup would result in a single distributed stream only as the two physical network clients will receive the stream from the multicast address. So, multicast has the advantage of consuming less network bandwidth compared to example 4 below.

 

 

 

Example 4: In this example, the Axis device is encoding a single unique stream and distributes it to two physical network clients via unicast instead. Compared to example 3, this setup would require the Axis device to consume more network bandwidth as the unique stream has to be distributed twice.

 

 

Maximum number of clients

Another important setting is the maximum number of clients (=viewers) that can receive a video stream. The number is set to 10 or 20 in all Axis devices and is depending on the configuration and performance capabilities of the device.

This means that either the Axis device is delivering a single video stream to 10 or 20 different physical clients in the network, or the Axis device is delivering 10 or 20 different video streams to one client in the network. The number of receiving video clients (physical and software instances) is the main limit. This configuration can be obtained by reading out the following VAPIX parameter: https://ip-address/axis-cgi/param.cgi?action=list&group=Image.MaxViewers

In practice, the maximum number should never be reached at any point. If an increasing number of clients need to access the video stream, it is recommended to make use of e.g. multicast.

Video, audio and metadata

In Maximum number of clients, we learned that there is a limit to how many video streams a device can deliver as a maximum, and we explained this with the number of video streams. In addition to video streams, Axis devices can also deliver audio and metadata streams. While the purpose of video and audio streams is self-explanatory, the purpose of metadata might not be. With a metadata stream, an application or VMS can listen to the Axis device’s event stream and both react on it and create its own events and actions in return.

Below is an example of an Axis device that is currently streaming one of each stream type to a single physical network client. Observe which stream type is streamed under Media.

 

To summarize, the maximum number of clients is applied to video, audio and metadata streams separately, meaning that if the parameter MaxViewers is configured to 20, the Axis device can deliver 20 x video, 20 x audio and 20 x metadata streams in total.

Performance considerations and maximum bitrate

Performance considerations
While it is possible for an Axis device to encode multiple video streams simultaneously, this will at some point have an impact on the performance if “too many” unique video streams are encoded. In the example illustration below, one can observe that the Axis device can deliver five unique video streams in full frame rate of 30 fps. In case a sixth unique video stream needs to be encoded, the performance of the product will be exceeded, causing the Axis device to deliver all of the requested video streams equally in reduced frame rate. In case of exceeding the performance of the product, the Axis device will not prioritize any of the video streams to be delivered in full fps, instead it will distribute the performance bottleneck across all video streams.

In case a sixth unique video stream needs to be encoded, the performance of the product will be exceeded, causing the Axis device to deliver all of the video streams in reduced frame rate.

Please note that the above example is an oversimplified illustration and the number of concurrent video streams an Axis device can deliver in full frame rate is heavily dependent on a lot of factors, such as requested frame rate, resolution, compression, bitrate and many more. It is recommended to test the device against the desired behavior in an environment that is exact, or close to, the environment the device is installed in.

 

Maximum video stream bitrate
A typical H.264 video stream in 1080p and 30 fps will have a bitrate of approximately 1 Mbit/s to 10 Mbit/s depending on scene, lighting conditions, movement and many other factors. In order to avoid network bottlenecks and congestion of the underlying network infrastructure which the Axis device is connected to, the maximum bitrate of a video stream is hard-capped and cannot exceed 50 Mbit/s per video stream in total.

 

Video source buffer configuration

In addition to the above information, the below listed Axis devices have additional video buffer configurations that must be considered. These devices have a limited number of statically configured so called video source buffers. The number of video source buffers depends on the device.

For single-sensor products the video source buffer can deliver at least one unique video stream, and for multi-sensor products the video source buffer can deliver at least four unique video streams. So, Axis devices containing video source buffer configurations are limited by the amount of unique video streams they can provide.

Products released before 2022
In Axis devices released before 2022, there are a maximum of four video source buffers.

  • Main source buffer: The main source buffer is statically configured to the device’s maximum default resolution and can only deliver a unique video stream in that specific resolution. This is indicated by the "fixed" term.

  • 2nd source buffer: The 2nd source buffer is a low resolution video buffer suitable for applications that rely on a lower sized resolution, such as (analytics) ACAP’s or motion jpeg image. This buffer provides variations of possible resolutions.

  • 3rd source buffer: The 3rd source buffer is a high resolution video buffer providing either the device’s maximum resolution, or a resolution close to it. In addition to that, HDMI capable devices allocate the 3rd source buffer HDMI video streaming when enabled. This buffer provides variations of possible resolutions.

  • 4th source buffer: The 4th source buffer is a high resolution buffer providing either the device’s maximum resolution or a resolution close to it. This buffer provides variations of possible resolutions.

Products released in 2022 and onwards
In Axis devices released in 2022 and onwards, there are at least four video source buffers available for encoded video such as H26X and MJPEG. HDMI will not affect the available number of source buffers for encoded video. ACAPs (typically analytics applications) that fetches YUV will not affect the available number of source buffers for encoded video.

  • Fixed source buffer (Main): The fixed source buffer is statically configured to the device’s maximum default resolution and can only deliver a unique video stream in that specific resolution. This is indicated by the "fixed" term.

  • 2nd source buffer: The 2nd source buffer is a low resolution video buffer suitable for applications that rely on a lower sized resolution motion JPEG image. This buffer provides variations of possible resolutions.

  • Nth source buffer: The Nth source buffer is a high resolution video buffer. This buffer provides variations of possible resolutions.

Example illustration

Axis deviceMain source buffer2nd source buffer3rd source buffer4th source buffer
AXIS Q6125-LEFixed 1920x1080320x240 to 720x576320x240 to 1920x1080320x240 to 1280x960

In summary, this device can deliver 2 x unique video streams in max 1920x1080 resolution — one in max 1280x960 and one in 720x576. As described in Unique encoded streams, the information in the server report can help identifying which of the video source buffers that are already used and saturated, and which are still available.

Example 1: In this example, the Axis device is delivering the following unique video streams which means the Main, 3rd and 4th video source buffers are in use. Requesting e.g. another unique video stream in 1920x1080 resolution with fps = 15 would fail because no video source buffer is available to deliver this request.

Example 2: In this example, the Axis device is delivering the following unique video streams which means the Main and 3rd video source buffer are in use. Requesting e.g. another unique video stream in 1920x1080 resolution with fps = 15 would fail because no video source buffer is available to deliver this request. Requesting a unique video stream buffer in 800x600 resolution can however be delivered by the 4th source buffer.

 

Axis device specifics
Below are all Axis devices and their video source buffer configurations listed:

Axis deviceMain source buffer2nd source buffer3rd source buffer4th source buffer
AXIS M1025
AXIS M3005-V
AXIS M3025-VE
Fixed 1920x1080320x240 to 720x576320x240 to 1920x1080320x240 to 1280x720
AXIS M1004-W
AXIS M1014
AXIS M1034-W
AXIS M3004-V
AXIS M3024-LVE
Fixed 1280x800320x240 to 720x576320x240 to 1440x900320x240 to 1280x720
AXIS M1013
AXIS M1033-W
AXIS M1143-L
Fixed 800x600320x240 to 720x576320x240 to 800x600320x240 to 800x600
AXIS M3046-V 2.4 mmFixed 2688x1520
Fixed 2560x1440
320x240 to 720x576HDMI: 1080p
320x240 to 1920x1080
320x240 to 1280x720
AXIS M1045-LW
AXIS M1065-L/-LW
AXIS M3045-V/-WV
Fixed 1920x1080320x240 to 720x576HDMI: 1080p
320x240 to 1920x1080
320x240 to 1280x720
AXIS M3044-V/-WVFixed 1280x720320x240 to 720x576No HDMI
320x240 to 1280x720
320x240 to 1280x720
AXIS M2026-LE
AXIS M2026-LE Mk II
AXIS M3106-L/-LVE
AXIS M3106-L/-LVE Mk II
Fixed 2688x1520320x240 to 720x576No HDMI
320x240 to 1920x1080
320x240 to 1280x960
AXIS M3046-V 1.8 mmFixed 2304x1296 (16:9)
Fixed 2016x1512 (4:3)
320x240 to 720x576HDMI: 1080p
320x240 to 1920x1080
320x240 to 1280x960
AXIS M4206-V/-LVFixed 2048x1536320x240 to 720x576HDMI: 1080p
320x240 to 1920x1080
320x240 to 1280x960
AXIS M4216-V/-LVFixed 2304x1728 (4:3)320x240 to 640x480*****320x240 to 1920x1080*****320x240 to 1920x1080*****
Fixed 2304x1296 (16:9)320x240 to 640x360*****320x240 to 1920x1080*****320x240 to 1920x1080*****
AXIS M3016
AXIS M3066-V
AXIS M3206-LVE
Fixed 2304x1728
Fixed 2304x1296
320x240 to 720x576HDMI: 1080p
320x240 to 1920x1080
320x240 to 1280x960
AXIS M3015
AXIS M3065-V
AXIS M3075-V
AXIS M3205-LVE
AXIS Q9216-SLVE
Fixed 1920x1080320x240 to 720x576HDMI: 1080p
320x240 to 1920x1080
320x240 to 1280x960
AXIS M3064-VFixed 1280x720320x240 to 720x576No HDMI
320x240 to 1280x720
320x240 to 1280x720
AXIS M3047-P*Fixed 2048x2048480x480 to 720x720HDMI: 720p
480x480 to 2048x2048
480x480 to 720x720
AXIS M3048-P*Fixed 2880x2880480x480 to 720x720HDMI: 720p
480x480 to 2880x2880
480x480 to 720x720
AXIS Q6125-LEFixed 1920x1080320x240 to 720x576320x240 to 1920x1080320x240 to 1280x960
AXIS P1428-E**
AXIS Q6128-E**
Fixed 3840x2160240x135 to 640x480480x270 to 1280x720240x135 to 1920x1080
AXIS Q6010-E***
AXIS Q6100-E***
Fixed 2592x1944320x240 to 1280x960320x240 to 1920x1080Not available
AXIS P3719-PLE****Fixed 2560x1440Fixed 640x360640x360 to 1920x1080Fixed 2560x1440

* The resolutions are only for fisheye overview and differ for other dewarped view modes. When pulling view area 1 & 2 with the same resolution on AXIS M3047-P and AXIS M3048-P, this will work either by using the highest resolution (1920x1440) or with lower resolutions like 640x480 and 480x360.
** Each source buffer can deliver two video streams in the corresponding resolution. Example: either 4x1080p in total with 2x1080p delivered from the main source buffer and 2x1080p delivered from the 4th source buffer, or 2x4K delivered from the main source buffer and 2x1080p delivered from the 4th source buffer.
*** The device is a multi-sensor device with 4 physical sensors, which translates to each buffer being able to deliver one video stream per physical sensor. Example: 1 x video stream in 2592x1944 resolution per sensor on AXIS Q6010-E makes it a total of 4 video streams on the main source buffer.
**** The 4th source buffer is allocated for quad-view only, so this means that the 4th source buffer cannot be utilized further even if quad-view is not used.
***** These video source buffers are capable of providing two unique video streams per buffer instead of just a single one.

 

Troubleshooting
You may refer to each device's release notes for all the supported resolutions. You will also notice the following line in the release notes for devices with hardware limitations: "5.40.5:L35026 Number of different configured video streams are limited by hardware".

A typical first hand indication that the Axis device cannot provide additional unique video streams as the video source buffers are already exceeded is the "503 Service Unavailable" error message in the web interface of the Axis device.

Other applications, like AXIS Companion or AXIS Camera Station, would show the user a "Camera error". The Server report and included log messages of Axis devices are an excellent tool to debug this kind of scenarios.

Below you can find a list of some common log messages that would appear in case the video source buffer is saturated and the Axis device is not being able to deliver a requested unique video stream

Troubleshooting example 1: In this example, requesting a unique video stream has failed due to there simply not being any video source buffer available to facilitate another unique 1024x768 video stream. The log messages indicate which source buffer is already occupied and which is still available to use at the time when the new unique video stream is requested.

<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: Unable to find available stream configuration for resolution 1024x768
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: buffer[0]: fixed 1920x1080, current 1920x1080
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: buffer[1]: max 720x576, current 0x0
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: buffer[2]: max 1920x1080, current 1280x960
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: buffer[3]: max 1280x720, current 0x0
<INFO> Jan 4 11:22:03 axis-00408cdc12b7 /usr/bin/ambad[960]: Failed to allocate a source buffer

Troubleshooting example 2: Like in the example above, requesting a unique video stream has failed due to there not being any video source buffer available to facilitate another unique 800x600 video stream.

<INFO> Jan 4 11:22:03 axis-0040 /usr/bin/ambad[960]: Unable to find available stream configuration for resolution 800x600
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: buffer[0]: fixed 800x600, current 800x600
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: buffer[1]: max 720x576, current 0x0
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: buffer[2]: max 800x600, current 800x600
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: buffer[3]: max 800x600, current 800x600
<INFO> Dec 30 21:15:36 axis408 /usr/bin/ambad[1051]: Failed to allocate a source buffer

Troubleshooting example 3: Axis devices with newer firmware print their log message in a slightly different manner, as seen in this example.

[ INFO ] /usr/bin/ambad[1035]: Failed to allocate a source buffer (1280x720, channel 1): No matching buffer available
[ INFO ] /usr/bin/ambad[1035]: stream[1]: encoding [ 1920x1080, 25/1 fps, buffer_id 2, state active, channel 1 ]
[ INFO ] /usr/bin/ambad[1035]: stream[2]: encoding [ 640x480, 25/1 fps, buffer_id 3, state active, channel 1 ]
[ INFO ] /usr/bin/ambad[1035]: stream[3]: encoding [ 320x240, 25/1 fps, buffer_id 1, state active, channel 1 ]
[ WARNING ] monolith: Failed to allocate 1280x720 H264 stream on channel 1: Failed to allocate stream resources: Failed to add stream
[ ERR ] monolith[925]: Could not set caching pipeline to playing.

Recommendations
The following general recommendations can be given to reduce complexity, configuration time and to optimize the video streaming setup of Axis devices:

  • Make use of stream profiles to package streams and their configuration in a simple way to optimize stream and configuration handling

  • Action rules that upload MJPEG images or video clips should utilize user-configured stream profiles

  • Use the same stream settings (=stream profile) for live view and recording if possible

  • Have in mind that action rules allocate a video source buffer once the action rule is activated. This means that even though the Axis device is supposed to send an image to an FTP server once a day, it will result in the video source buffer being allocated for the entire day

  • Have in mind that (Analytics) ACAPs such as AXIS Video Motion Detection or 3rd party ACAPs may consume a low resolution buffer for detection, such as 320x240

  • Have in mind that the “Adaptive Resolution/Streaming” feature enabled per default when accessing the Axis device’s web interface will request a unique video stream tailored to the actual resolution size of the physical display of the user. This might consume a video source buffer by itself

  • Avoid having anonymous viewers enabled. Besides the aspect of cybersecurity, having anonymous viewers enabled allows the uncontrolled access to an Axis device and may exceed the video source buffer configurations

  • Avoid questionable setups such as requesting two unique video streams in the same resolution, framerate but with different compression, like 30 and 35. The difference in image quality is negligible compared to the cost of consuming a video source buffer

 

Multicast video streaming

Streaming video using multicast allows different video clients located in the network to access a single video stream which the Axis device distributes to a specific multicast address and port. One of the benefits of using multicast as a transport method for video streaming is that the Axis device keeps its system and resource consumption low by only sending a single or dual video stream to a specific address in the network. It is also an efficient way of using the network infrastructure since many different video clients can retrieve the video stream from the multicast address instead of each video client pulling a separate video stream from the Axis device. The way multicast is served, distributed and received in the network can actually minimize the bandwidth consumption of the network infrastructure and all its involved clients as such. Just imagine the difference this can make in a system with more than 5.000 Axis devices in operation.

Axis devices support a variety of ways to stream video in a multicast scenario. In the following sections we will go through multicast from a streaming perspective and not take into account the general mechanics of multicast and how it is routed through the network, or the basics of the different forms of multicast.

Any-source multicast (ASM)

Independently of the desired transport method – i.e. multicast or unicast – the initial RTSP protocol communication that is required to properly initialize the video client and Axis device is very similar, except that the video client in multicast-mode specifies this instead of the unicast scenario.

We will go through the details of a typical RTSP build-up step-by-step below. For more details, please refer to the actual network traces in Multicast in detail for more research.

Step 1: video client
The video client initiates the RTSP DESCRIBE and signals to the Axis device to prepare video streaming with the specified streaming parameters given in the rtsp URL and to share its corresponding Session Description Protocol (SDP) file, which includes information on how to decode the video stream.

DESCRIBE rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30 RTSP/1.0
CSeq: 2
User-Agent: OmnicastRTSPClient/1.0
Accept: application/sdp
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="00000450Y2804646c4d9f7d3175fa496417b9c4e7aa39a2", uri="rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30", response="7a2e2dcad7618b36479ec76e252bc1c3"

Step 2: Axis device
The Axis device validates the request and shares the corresponding SDP file with the video client. Note that in any-source multicast mode, no multicast-specific network parameters are shared. In source-specific multicast mode (SSM), this is different.

RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp
Content-Base: rtsp://172.25.201.100:554/axis-media/media.amp/
Server: GStreamer RTSP server
Date: Thu, 11 Feb 2021 06:51:12 GMT
Content-Length: 1063

v=0
o=- 17136744296195211872 1 IN IP4 172.25.201.100
s=Session streamed with GStreamer
i=rtsp-server
t=0 0
a=tool:GStreamer
a=type:broadcast
a=range:npt=now-
a=control:rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:50000
a=rtpmap:96 H265/90000
a=framerate:30
a=fmtp:96 sprop-vps=QAEMAf//AUAAAAMAgAAAAwAAAwCcEJAk;sprop-sps=QgEBAUAAAAMAgAAAAwAAAwCcoAPAgBEHy55CbkSg8quTgoKC8IAAAAMAgAAAAwKE;sprop-pps=RAHANzwEbJA=
a=ts-refclk:local
a=mediaclk:sender
a=recvonly
a=control:rtsp://172.25.201.100:554/axis-media/media.amp/stream=0?videocodec=h265&adui=0&resolution=1920x1080&camera=1&compression=30&fps=30
a=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000

Step 3: video client
The video client then goes ahead and defines the appropriate transport method as multicast, the multicast IP address, streaming ports and the TTL. This is the important step in the RTSP build-up where the video client actually can specify the desired transport method. Note that in order for the Axis device to accept video client-specific multicast network parameters, the VAPIX parameter RTSP Allow Client Transport Settings in Plain Config > Network has to be enabled. If this parameter is not set, the Axis device might ignore these parameters and offer their own configuration set in Plain Config > Network > R0.

SETUP rtsp://172.25.201.100:554/axis-media/media.amp/stream=0?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30 RTSP/1.0
CSeq: 3
User-Agent: OmnicastRTSPClient/1.0
Transport: RTP/AVP;multicast;destination=224.16.17.51;port=47806-47807;ttl=64
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="00000450Y2804646c4d9f7d3175fa496417b9c4e7aa39a2", uri="rtsp://172.25.201.100:554/axis-media/media.amp/stream=0?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30", response="48cf0f723aca20f6530e79ecb966ec0a"

Step 4: Axis device
The Axis device in return validates the request and if successful, it answers with the exact same network parameters back to the video client to prepare the upcoming session.

RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;multicast;destination=224.16.17.51;ttl=64;port=47806-47807;mode="PLAY"
Server: GStreamer RTSP server
Session: f2imQtCHhuoH2FbW;timeout=60
Date: Thu, 11 Feb 2021 06:51:12 GMT

Step 5: video client
The video client then finally signals to the Axis device via RTSP PLAY to start video streaming as agreed based on the network and video streaming parameters that have been handshaked previously.

PLAY rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30 RTSP/1.0
CSeq: 4
Session: f2imQtCHhuoH2FbW
User-Agent: OmnicastRTSPClient/1.0
Range: npt=0.000-
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="00000450Y2804646c4d9f7d3175fa496417b9c4e7aa39a2", uri="rtsp://172.25.201.100:554/axis-media/media.amp?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30", response="d015b378a8a1000c964d6c48d1883d1f"

Step 6: Axis device
The Axis device acknowledges the request by sending an RTSP OK and provides the video client with info on how the video stream will be momentarily available at the defined multicast network parameters. In order to signal the start of the video stream to the video client, the Axis device specifies the sequence number of the first RTP package and the initial rtp timestamp so that the client expects and processes the correct start of the video stream.

RTSP/1.0 200 OK
CSeq: 4
RTP-Info: url=rtsp://172.25.201.100:554/axis-media/media.amp/stream=0?videocodec=h265&audio=0&resolution=1920x1080&camera=1&compression=30&fps=30;seq=24067;rtptime=417717697
Range: npt=now-
Server: GStreamer RTSP server
Session: f2imQtCHhuoH2FbW;timeout=60
Date: Thu, 11 Feb 2021 06:51:12 GMT

 

Optional client transport setting handling
In case the video client would not specify all the necessary network transport parameters accordingly, the Axis device will fallback and offer the default multicast parameter set in Plain Config > Network > R0 as illustrated in the following example. We can observe here that the video client’s request for video streaming specifies multicast as transport method and the port to be used for multicast streaming, but misses to specify the multicast IP address. The Axis device treats this as a non-complete request and offers instead its configuration set in R0, which the video client either can agree on or simply close the connection. Another reason why the Axis device would disregard the video client's desired settings is when the VAPIX parameter RTSP Allow Client Transport Settings in Plain Config > Network is unchecked.

Step 3: video client

SETUP rtsp://172.25.201.100:554/axis-media/media.amp/stream=0 RTSP/1.0
CSeq: 5
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="0003628fY51859629beb31964cb09d13947338e39266e77", uri="rtsp://172.25.201.100:554/axis-media/media.amp/", response="78be3d448c752bda36df4b82baf4ecf9"
User-Agent: LibVLC/3.0.11 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;multicast;port=55810-55811

Step 4: Axis device

RTSP/1.0 200 OK
CSeq: 5
Transport: RTP/AVP;multicast;destination=224.225.226.227;ttl=5;port=50000-50001;mode="PLAY"
Server: GStreamer RTSP server
Session: xvIhEhZ3W5QpueEZ;timeout=60
Date: Thu, 11 Feb 2021 06:28:05 GMT
Source-specific multicast (SSM)

While in any-source multicast (ASM) the multicast network parameters are handshaked after sharing the Session Description Protocol (SDP) file during the initial RTSP build-up, this is not the case in the source-specific multicast mode. In SSM, the multicast network parameters are pre-configured in the Axis device and shared with the requesting video client when the SDP file is shared. The benefit of this is that the requesting video client can join a multicast group and only filter for the multicast traffic the video client is interested in. This can be done by applying a source-specific filter when joining the multicast group.

A typical scenario where SSM would be beneficial is when multiple Axis devices would stream video to the same multicast address but would use different ports. A video client connecting via any-source multicast would receive the multicast traffic from all streaming devices, while a video client requesting source-specific multicast would be able to filter out unwanted traffic. On top of that, SSM allows for reliable planning of multicast routing/path-forwarding since it is known how multicast is switched and routed through the network.

Source-specific multicast requires pre-configuration on the Axis device to configure the desired multicast network parameters. You can find information on how to configure an Axis device for source-specific multicast in the VAPIX Library but is also illustrated below. There is no specific setting to enable or disable source-specific multicast as such, but the source-specific multicast network parameters that need to be defined in advance can be configured from Plain Config > Network for each individual video source. Below is a typical example configuration:

 

Step 1: video client
Compared to the any-source multicast mode, SSM mode requires a different streaming URL for signaling to the Axis device that source-specific multicast is wanted.

DESCRIBE rtsp://172.25.201.100:554/axis-media/ssm/media.amp?camera=1 RTSP/1.0
CSeq: 4
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="000006c7Y356087c783187c3a95be0ca315f5fa0cd57ddc", uri="rtsp://172.25.201.100:554/axis-media/ssm/media.amp?camera=1", response="3226806a8c988f0d473df291e8c7ffb8"
User-Agent: LibVLC/3.0.11 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

Step 2: Axis device
The SDP file that is shared between the Axis device and the requesting video client includes the source-specific multicast network parameters which the video client has to learn in order to join the multicast group accordingly and filter for the correct traffic.

RTSP/1.0 200 OK
CSeq: 4
Content-Type: application/sdp
Content-Base: rtsp://172.25.201.100:554/axis-media/ssm/media.amp/
Server: GStreamer RTSP server
Date: Thu, 11 Feb 2021 07:01:42 GMT
Content-Length: 749

v=0
o=- 9871677480407248934 1 IN IP4 172.25.201.100
s=Session streamed with GStreamer
i=rtsp-server
c=IN IP4 225.226.227.228/5
t=0 0
a=tool:GStreamer
a=type:broadcast
a=range:npt=now-
a=control:rtsp://172.25.201.100:554/axis-media/ssm/media.amp?camera=1
a=source-filter: incl IN IP4 225.226.227.228 172.25.201.100
m=video 60000 RTP/AVP 96
b=AS:50000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-sets=Z2QAKa0AxSAeAIn5ZuAgIDSDxIio,aO48sA==
a=ts-refclk:local
a=mediaclk:sender
a=recvonly
a=control:rtsp://172.25.201.100:554/axis-media/ssm/media.amp/stream=0?camera=1
a=framerate:30.000000
a=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000

Step 3: video client
Since the video client knows the multicast network parameters that will be used in advance, the client can include them in the RTSP SETUP request.

SETUP rtsp://172.25.201.100:554/axis-media/ssm/media.amp/stream=0?camera=1 RTSP/1.0
CSeq: 5
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="000006c7Y356087c783187c3a95be0ca315f5fa0cd57ddc", uri="rtsp://172.25.201.100:554/axis-media/ssm/media.amp/", response="89e1cf3338144d096723df0b10864cab"
User-Agent: LibVLC/3.0.11 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;multicast;port=60000-60001

Step 4: Axis device
The Axis device validates and responds with the correct multicast network parameter according to the pre-configuration done in R0.

RTSP/1.0 200 OK
CSeq: 5
Transport: RTP/AVP;multicast;destination=225.226.227.228;ttl=5;port=60000-60001;mode="PLAY"
Server: GStreamer RTSP server
Session: 06yirClN7xQCtW8q;timeout=60
Date: Thu, 11 Feb 2021 07:01:42 GMT

Step 5: video client
The requesting video client then signals to the Axis device to start video streaming to the agreed streaming and network parameters.

PLAY rtsp://172.25.201.100:554/axis-media/ssm/media.amp?camera=1 RTSP/1.0
CSeq: 6
Authorization: Digest username="root", realm="AXIS_ACCC8ED910B9", nonce="000006c7Y356087c783187c3a95be0ca315f5fa0cd57ddc", uri="rtsp://172.25.201.100:554/axis-media/ssm/media.amp/", response="c19526013f73f3db72cd4fca98ec1c40"
User-Agent: LibVLC/3.0.11 (LIVE555 Streaming Media v2016.11.28)
Session: 06yirClN7xQCtW8q
Range: npt=0.000-

Step 6: Axis device
The Axis device acknowledges the request by sending an RTSP OK and provides the video client with info on how the video stream will be momentarily available at the defined multicast network parameters. In order to signal the start of the video stream to the video client, the Axis device specifies the sequence number of the first RTP package and the initial rtp timestamp so that the client expects and processes the correct start of the video stream.

RTSP/1.0 200 OK
CSeq: 6
RTP-Info: url=rtsp://172.25.201.100:554/axis-media/ssm/media.amp/stream=0?camera=1;seq=21707;rtptime=3563678630
Range: npt=now-
Server: GStreamer RTSP server
Session: 06yirClN7xQCtW8q;timeout=60
Date: Thu, 11 Feb 2021 07:01:42 GMT
Always multicast

Always multicast is not a network multicast mode but a specific adaption to video clients that are not capable of performing a proper RTSP and/or multicast setup in either of the ways described previously (i.e. via ASM or SSM). In always multicast mode, the Axis device is statically configured to stream video to a specific multicast address and port, and also to start streaming to it directly, regardless if there are video clients in the network that are actually requesting video from that particular Axis device or not. On top of that, RTSP is not used to connect, instead the requesting video client will make a HTTP call to retrieve the Session Description Protocol (SDP) file in order to understand and make the connection to the multicast address and port where the video stream is connected. Always multicast can be configured in Axis devices in Plain Config > Network for each individual video source.

Example 1: The device will only stream video to the multicast address 224.225.226.227 and video port 50000. If video port 0 would be entered here, the Axis device would select the next possible port which has been defined in the RTP > End Port and Start Port configuration.

 

Example 2: The device will stream video to the multicast address 224.225.226.227 to port 50000, and audio to multicast address 239.216.121.37 to port 51000. Observe that it is also possible to adjust the video streaming parameters in the always multicast profile. If other streaming parameters should be used, e.g. a framerate of 15 frames per second and compression of 15, then the field can be adjusted in the following way: videocodec=h264&fps=15&compression=15. Otherwise the current configured default stream settings will be used.

 

Once the above settings are saved, the Axis device will start streaming to the configured multicast address and port immediately regardless if there are clients requesting the video stream or not. The client can access this multicast stream via the SDP file, which determines the video stream settings so that the video client learns how to play the video. The SDP file can be accessed using http://ip-address/axis-cgi/alwaysmulti.sdp?camera=1 where camera=1 is mapped to R0. An example of such an SDP file can be found via alwaysmulti.sdp. Below is a network trace example illustrating the procedure.

Step 1: video client
The video client has requested the SDP file from the Axis device. Observe that no streaming parameters or multicast network parameters are mentioned by the client, hence this configuration must be performed on the Axis device prior to making the request as described in the previous examples.

GET /axis-cgi/alwaysmulti.sdp?camera=1 HTTP/1.1
Host: 172.25.201.100
Accept: */*
Accept-Language: en_US
Authorization: Basic cm9vdDpwYXNz
User-Agent: VLC/3.0.11 LibVLC/3.0.11
Range: bytes=0-

Step 2: Axis device
The Axis device looks up the current configuration in R0 and then initializes and sends the SDP file to the requesting video client. This is done in order to pass on the required information so that the video client can access the already ongoing multicast stream at the pre-configured multicast address and port. No further unicast communication is exchanged at this point, the video client will switch over to the specified multicast network parameters in order to access the stream.

HTTP/1.1 200 OK
Date: Thu, 11 Feb 2021 06:14:25 GMT
Server: Apache/2.4.46 (Unix) OpenSSL/1.1.1g
Cache-Control: no-cache, no-store, max-age=0
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Transfer-Encoding: chunked
Content-Type: application/sdp

v=0
o=- 1188340656180883 1 IN IP4 172.25.201.100
s=Session streamed with GStreamer
i=rtsp-server
t=0 0
a=tool:GStreamer
a=type:broadcast
a=control:*
a=range:npt=now-
m=video 50000 RTP/AVP 96
c=IN IP4 224.225.226.227/5
b=AS:50000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-sets=Z2QAKa0AxSAeAIn5ZuAgIDSDxIio,aO48sA==
a=control:stream=0
a=ts-refclk:local
a=mediaclk:sender
a=framerate:30.000000
a=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000
Multicast in detail
Example network traceMulticast addressMulticast portVideo clientVideo client IP addressAxis device IP address
FFMPEG_Any_Source_Multicast.pcapng224.225.226.22750000FFMPEG172.25.201.50172.25.201.100
VLC_Any-Source_Multicast.pcapng224.225.226.22750000VLC*172.25.201.50172.25.201.100
Genetec_Any_Source_Multicast.pcapng224.16.17.5147806Genetec172.25.201.51172.25.201.100
Milestone_Any_Source_Multicast.pcapng224.16.17.5147806Milestone172.25.201.52172.25.201.100
VLC_Source_Specific_Multicast.pcapng225.226.227.22860000VLC172.25.201.50172.25.201.100
FFMPEG_Always_Multicast_Direct_SDP_File_Play.pcapng224.225.226.22750000FFMPEG**172.25.201.50172.25.201.100
VLC_Always_Multicast_Direct_SDP_File_Play.pcapng224.225.226.227 50000VLC**172.25.201.50172.25.201.100
VLC_Always_Multicast_HTTP_SDP_Play.pcapng224.225.226.22750000VLC***172.25.201.50172.25.201.100

*In VLC, you may need to enable "Force multicast RTP via RTSP" in the RTP/RTSP/SDP demuxer settings under Advanced Preferences.
**In order for FFMPEG and VLC to access and retrieve the SDP file via HTTP-authentication, the HTTP-basic authentication has to be configured in Plain Config > Network > Authentication policy.
***These examples illustrate how a video client is capable of connecting to the multicast stream just by using the file SDP alone without making any further connection to the Axis device. Assuming that no configuration change is made on the Axis device, the user is only required to download the SDP file once and then one could use the SDP to start playing the video. VLC and FFMPEG are exmaples of clients that are capable of doing so.

Multicast network overview

A typical multicast scenario consists of three parts: the source, the multicast network infrastructure, and the receivers.

The Axis device is the source which sends out the streams to the multicast address. The multicast address is agreed between the clients and the device during the negotiation. The network infrastructure must be configured by network professionals. A multicast routing protocol (like PIM) needs to be running between the routers, and the IGMP protocol needs to be running between the last-hop router and the receiving clients. Additionally, IGMP snooping needs to be enabled on the layer 2 switches to avoid multicast traffic being flooded.

Multicast in a switched network

A network where traffic is served within a certain VLAN and IP address network is called a switched network since no layer-3 IP routing is needed. Let's start with the basic setup and assume that the network switches have not been configured properly for handling multicast traffic. What you would see is similar to the illustration below, a switched network consisting of a handful of switches with client computers and Axis devices. From all of the clients, only Client 2 is interested and requests a multicast video stream from the Axis device. Since the network switches are not configured properly at this point, the multicast traffic, which is only supposed to flow from the Axis device over the traversing switches to Client 2, will be flooded to all switches and clients in the network, regardless if they are interested in receiving the traffic or not.

 

Let's look at the same network when properly configured with IGMP (Internet Group Management Protocol) enabled. IGMP is a protocol that helps the network infrastructure learn and understand who is delivering multicast traffic to which destination in order to avoid multicast flooding to non-interested clients. To configure the network to avoid multicast flooding, it is enough to configure the main switch - i.e. Layer 2 switch - for IGMP in the following example configuration:

Global configuration
ip igmp snooping querier address 172.25.201.10
ip igmp snooping querier query-interval 15
ip igmp snooping querier

By doing this, the Layer 2 switch will be sending out IGMP queries to the connected network devices in order to find out which ones are interested in receiving and sending multicast packages.

 

The network devices will respond with "join" messages in order to signal their participation in multicast-related traffic.

 

The network switches will listen and learn from this traffic in order to properly switch network packages to their appropriate destinations. In the illustration below, only Client 2 is requesting video from the Axis device via multicast.

 

With the correct configuration in place, the network switches are now capable of switching packages as well across switches. In the illustration below, we have switched the clients, so that Client 1 requests a multicast video stream from the same Axis device that previously served Client 2. The result will be proper switched network traffic across the network to the correct destination.

 

Multicast in a routed network

Multicast in a routed network does not differ essentially from a switched scenario in regards to how multicast traffic is handled. A network where clients exchange network traffic across different VLANs and IP networks is called a routed network since layer-3 IP routing techniques are needed to deliver the network traffic across. Let's re-use the same network topology as we did in the switched network scenario. The only - but important - difference is that Client 1 is placed in a different VLAN and IP address network compared to Client 2 and 3 as well as the Axis device. We assume that we have already performed the same IGMP configuration as mentioned earlier. For reference, see below:

Global configuration
ip igmp snooping querier address 172.25.201.10
ip igmp snooping querier query-interval 15
ip igmp snooping querier

 

As you can see, Client 2 is already requesting video from the Axis device using multicast and since we have applied the correct IGMP configuration to the Layer 3 switch, this setup works flawlessly. But Client 1 from the other IP network also wants to receive a video via multicast, which is not working since multicast is not routed across different IP networks by design. So in order to allow multicast traffic to be routed across layer-3 networks we have to enable IP-multicast routing and use a protocol such as Protocol Independent Multicast (PIM). The most basic and simple use case would be to make use of the passive mode of PIM, as illustrated below in the suggested configuration:

Global configuration
ip multicast-routing

Configuration VLAN 201
interface Vlan201
description LAN1 clients
ip address 172.25.201.10 255.255.255.0
ip pim passive
!

Configuration VLAN 202
interface Vlan202
description LAN2 clients
ip address 172.25.202.10 255.255.255.0
ip pim passive
!

With this configuration applied, multicast is properly routed across different networks. From the Axis device located in VLAN 201 to Client 1 that is located in VLAN 202.

 

Video streaming rotation

In this section we will take a closer look at the VAPIX and ONVIF image rotation configuration when it comes to video streaming, which is handled differently depending on AXIS OS version.

AXIS OS 8.50 and higher
After support for ONVIF Profile T was added, the handling of image rotation in Axis devices has been completely separated between VAPIX and ONVIF. This means that both protocols have dedicated parameters for image rotation configuration, and that the image rotation parameter for one protocol does not affect the other and vice-versa. For VAPIX this is configured via the image rotation parameter Image.I0.Appearance.Rotation, either in the image settings in the web interface, or directly via VAPIX HTTP request. For ONVIF it's configured in the ONVIF media stream profiles in the web interface, or directly via the script editor for legacy devices in the configuration file: /etc/ws/onvif/media/media.conf.

Exception: The above is not true for Axis devices with support for ImageSource.I0.SourceRotation=yes. On these devices, the image rotation parameter is set globally via VAPIX and ONVIF will adapt to it accordingly. SourceRotation is a feature that automatically detects the correct rotation parameter to be used depending on the way the Axis device is installed in its physical location.

AXIS OS 8.40 and lower
Configuring the image rotation parameter Image.I0.Appearance.Rotation via the image settings in the web interface or directly via VAPIX HTTP request will affect both VAPIX and ONVIF video streams. ONVIF video streams will adapt to the same image rotation configured via VAPIX, unless specified otherwise in the ONVIF stream profile settings.

Example configurations

VAPIX configuration of image rotation from the device web interface:

 

ONVIF configuration of image rotation from the device web interface:

 

ONVIF configuration of the image rotation via script editor:

 

Streaming timestamps

In this section you can read about different ways to receive timestamp information when streaming video and downloading single images from Axis devices. This metadata information can be used for processing in business applications, e.g. when receiving metadata about how many persons in a store went through a certain area. It can also be used in other use cases where time-synchronisation towards 3rd party video clients is needed

H.264/MJPEG and RTP timestamps

The following network trace can be used for testing what is described below.

RTP timestamps can be found in the payload of RTP packages and function as a monotonic timestamp that can be used to identify a specific frame of the video stream. Based on the clock rate that is computed during the video stream build-up, the RTP timestamp is expected to increase incrementally from one frame to another.

The clock rate depends on the image frequency of the video stream. In this example, the video stream consists of 30 frames per second, which means the computed clock rate will be 3000. This in turn means that the monotonic RTP timestamp will increase by 3000 upon every new I-Frame or P-Frame as you can see in the following two screenshots.

 

When the video stream starts, the Axis device will let the external video client know about the initial RTP timestamp of the first frame (I-Frame), as you can see below. This allows the receiving video client to identify e.g. missing frames and can be used for RTP timestamp drift measurement while the video stream is ongoing.

 

An I-Frame and/or P-Frame can consist of several RTP packages. As you can see, all packages that belong to the same I-Frame have the same unique timestamp, while each of the following P-Frames have their own timestamp corresponding to the clock rate. So for each unique I-Frame or P-Frame, the RTP timestamp increases incrementally.

 

RTCP NTP timestamps

The following network trace can be used for testing what is described below.

If RTCP communication takes place between an Axis device and a video client, so called RTCP sender and receiver reports are exchanged. These reports include important information about the clock-sync within an ongoing RTSP/RTP stream. The Axis device, being the sender of the video, sends the RTCP sender report where the current RTP stream time and the current NTP timestamp in UTC are included.

 

The receiving video client on the other hand exchanges the so called RTCP receiver report with the Axis device to reply to the information previously sent, and to allow for mutual time-synchronisation checks and compensation for time drift between the Axis device and the video client itself. RTCP sender and receiver reports are exchanged every couple of seconds of an ongoing video stream.

SEI timestamps

The following network trace can be used for testing what is described below.

The so called SEI frame is available when this VAPIX parameter is enabled: Image.I0.MPEG.UserDataEnabled=yes. Here Image.I0 corresponds to the default video source, and if multiple video sources are available, the parameter needs to be enabled for each video source.

SEI frames are sent from the Axis device right before every I-Frame and include useful timestamp information. As described in the VAPIX library, SEI frames include timestamp information in Linux Epoch time down to 1/100ms accuracy in HEX format.

 

For debugging purposes we recommend using the following online converters:

Image timestamps

A single image can be downloaded from the Axis device using the following VAPIX request: http://ip-address/axis-cgi/jpg/image.cgi. The received JPEG image from the Axis device provides valuable timestamp information from either the JPEG header itself or from the EXIF header data, depending on the AXIS OS version of the Axis device.

AXIS OS 8.40 and higher
From AXIS OS 8.40, the EXIF header data can be used to obtain timestamp information as you can see in the screenshot below. For debugging purposes, a simple windows application such as JPEGSnoop or EXIF in Linux OS can be used to obtain the information provided from the EXIF header. Go to the following source for more information about JPEG and EXIF timestamp header information: https://www.exif.org/Exif2-2.PDF.

 

AXIS OS 6.50 and lower
Since the EXIF header data is not available in older AXIS OS versions, the plain JPEG comment header can be used to receive timestamp information. An application such as the HxD editor can be used to obtain the timestamp information in HEX-format, which in turn can be converted to human readable time format using a Linux EPOCH time converter, e.g. https://www.epochconverter.com/hex. For the 1/100 seconds information, a simple Hex to decimal converter can be used, e.g. https://www.rapidtables.com/convert/number/hex-to-decimal.html.

 

These sample images can be used for testing:

Metadata via RTSP

Generally speaking, metadata in Axis devices consists of three different types: event, PTZ and analytics metadata. The metadata is encapsulated in an RTP/TCP stream that can be requested from the Axis device. Let's take a closer look at the different types of available metadata.

Event and PTZ metadata
For many years now (from AXIS OS 5.40 and onwards), Axis devices have been capable of sending event and PTZ metadata to a receiving 3rd party application, such as a video management system. The event and PTZ metadata is sent only when the state of the Axis device changes, meaning that no constant stream is being sent. Some common examples of event metadata are the manual trigger, virtual inputs and storage related triggers. For mechanical PTZ cameras, the metadata includes positioning data as well as information on when a PTZ preset is reached or when the Axis device is moving.

Analytics metadata
Analytics related metadata is available from AXIS OS 9.50 and onwards. Unlike the event and PTZ metadata stream described above, the analytics metadata stream is sent constantly from the Axis device to receiving clients, even if nothing happens in the scene. Typical examples of analytics metadata are motion or object detection coming from Axis analytics applications (ACAPs), such as AXIS Video Motion Detection or AXIS Object Analytics.

A sample network trace that illustrates how metadata information is transferred can be downloaded here. By using Wireshark it's possible to search and find specific metadata events within the RTP/TCP stream, as illustrated in the screenshot below.

 

In the following sections you can read more about how to get started and perform further testing.

Receiving metadata via RTSP

Metadata information can be received from an Axis device by opening an RTSP stream that uses the TCP transport protocol. The self-developed AXIS Metadata Monitor can be used as a simple test tool to request metadata from an Axis device. You can download AXIS Metadata Monitor here and install it on a computer in order to connect to an Axis device in your network. Below is a sample list of RTSP requests for receiving metadata events from the Axis device.

RTSP requestDescription
rtsp://ip-address/axis-media/media.amp?event=on&video=0Event metadata excluding video stream
rtsp://ip-address/axis-media/media.amp?event=on&analytics=polygon&video=0Event and video analytics metadata excluding video stream
rtsp://ip-address/axis-media/media.amp?event=on&analytics=polygon&ptz=all&video=0Event, video analytics and PTZ metadata excluding video stream
rtsp://ip-address/axis-media/media.amp?event=onEvent metadata including video stream
rtsp://ip-address/axis-media/media.amp?event=on&video=1&audio=1Event metadata including video and audio stream
rtsp://ip-address/axis-media/media.amp?event=on&video=0&audio=1Event metadata excluding video but including audio stream
rtsp://ip-address/axis-media/media.amp?event=on&video=0&eventtopic=axis:CameraApplicationPlatform/VMD/Camera1ProfileANYEvent metadata excluding video and filtering only for AXIS Video Motion Detection (VMD) alarms
rtsp://ip-address/axis-media/media.amp?event=on&video=0&eventtopic=onvif:Device/axis:IO/VirtualPortEvent metadata excluding video and filtering only for the manual trigger event

Additional parameters such as camera=2 to camera=9 can be added to the above requests to e.g. receive metadata events from a different video channel. This is useful when the Axis device supports more than one video source or if different view areas are configured. In the example below we use AXIS Metadata Monitor to connect to an Axis device by using one of the RTSP requests above together with the IP address of the Axis device and its access credentials.

 

As you can see, the Axis device is responding to the RTSP request with all its currently available metadata information and states. A simple way of testing incoming metadata events is to toggle the manual triggers in the web interface.

 

Another option would be to use one of the pre-installed Axis analytics applications (ACAPs), such as AXIS Video Motion Detection, to trigger a test alarm or motion in front of the Axis device in order to get motion detection/analytics based metadata events.

 

Examples of metadata events

Further down you will find a (non-complete) table of common metadata and device events available in Axis devices. The type and amount of events that are available depend on the hardware/software capabilities of the Axis device, some of which are:

  • Mechanical and/or digital PTZ

  • Mechanical and/or digital I/O

  • Audio in and audio out capabilities

  • Axis analytics applications (ACAPs) such as AXIS Video Motion Detection, AXIS Object Analytics etc.

  • 3rd party applications

 

Metadata/event categoryTopicPossible states
PTZPTZController/PTZPresets/Channel1on_preset=0/1
PTZPTZController/Move/Channel1is_moving=0/1
PTZPTZController/PTZReadyready=0/1
PTZPTZController/ControlQueuequeue_owner=userx
I/ODevice/IO/VirtualInputactve=0/1
I/ODevice/IO/Portstate=0/1
I/ODevice/Trigger/DigitalInputstate=0/1
TemperatureDevice/Status/Temperature/Abovesensorlevel=0/1
TemperatureDevice/Status/Temperature/Belowsensorlevel=0/1
TemperatureDevice/Status/Temperature/Insidesensorlevel=0/1
TemperatureDevice/Status/Temperature/Above_and_Belowsensorlevel=0/1
TemperatureDevice/Heater/Statusrunning=0/1
SystemDevice/Status/SystemReadyready=0/1
HardwareDevice/Sensor/PIRstate=0/1
AudioDevice/RingPowerLimitExceededlimit_exceeded=0/1
HardwareDevice/Network/Lostlost=0/1
HardwareDevice/Network/BlockedIPaddress = x.x.x.x
HardwareDevice/Casing/Openopen=0/1
StorageStorage/Disruptiondisruption=0/1
StorageStorage/Recordingrecording=0/1
HardwareDevice/HardwareFailure/StorageFailuredisruption=0/1
HardwareDevice/HardwareFailure/FanFailurefailure=0/1
HardwareLightControl/LightStatusChanged/Statusstate=off/on
VideoVideoSource/LiveStreamAccessedday=0/1
VideoVideoSource/DayNightVisionaccessed=0/1
VideoVideoSource/ABRabr_error=0/1
AudioAudioSource/TriggerLeveltriggered=0/1
AudioAudioControl/DigitalSignalStatussignal_status=signal/no signal
VideoVideoEncoder/Connectionsconnected=0/1
VideoVideoSource/Connectionsconnected=0/1
AnalyticsVideoAnalytics/Tamperingactive=0/1
AnalyticsVideoAnalytics/MotionDetectionmotion=0/1
AnalyticsCameraApplicationPlatform/VMDactive=0/1
AnalyticsCameraApplicationPlatform/MotionGuardactive=0/1
AnalyticsCameraApplicationPlatform/LoiteringGuardactive=0/1
AnalyticsCameraApplicationPlatform/FenceGuardactive=0/1
Axis analytics metadata configuration

From AXIS OS 10.11 and onwards, it's possible to choose dedicated analytics producers within the Axis device or to have multiple analytics metadata producers enabled simultaneously. In the backend, the Axis device can either be configured to produce analytics metadata by using the "Axis video motion tracker", which is the commonly known producer used since AXIS OS 9.50, or by using the newer "Axis object analytics" producer. The "Axis object analytics" producer offers some valuable extensions and more information with regards to analytics data, such as more detailed object classification (human faces, license plate numbers, etc.) that are useful in forensic search scenarios.

 

Metadata via WebSocket

From AXIS OS 10.11 and onwards it's possible to subscribe to the metadata stream using the (secure) WebSocket protocol. For more general information about Axis metadata streaming, see Metadata via RTSP.

In the below example we’re using the WebSocket King extension for the Google Chrome browser, however there are many other clients available supporting WebSocket communication.

Step 1: Login to your Axis device using the browser the extension has been installed to.

Step 2: In the WebSocket King extension, connect to:

  • HTTP: ws://IP/vapix/ws-data-stream?sources=events

  • HTTPS: wss://IP/vapix/ws-data-stream?sources=events

Note that if you’re using HTTPS in step 1, you will need to use the same for the connection in the WebSocket King extension.

 

Step 3: Send the following request to receive all events:

{
"apiVersion": "1.0",
"method": "events:configure",
"params": {
"eventFilterList":[
{
"topicFilter":""
}
]
}
}

 

 

It's also possible to subscribe to a specific topicFilter, for example: "topicFilter":"tns1:Device/tnsaxis:IO/VirtualInput". Go to Examples of metadata events for more topic examples. Furthermore it's possible to subscribe to a specific port. Below you can see an example of virtual input port 47.

{
"apiVersion": "1.0",
"method": "events:configure",
"params": {
"eventFilterList":[
{
"topicFilter":"tns1:Device/tnsaxis:IO/VirtualInput",
"contentFilter":"boolean(//SimpleItem[@Name=\"port\" and @Value=\"47\"])"
}
]
}
}

 

Step 4: Events will start streaming based on the set filter.

 

Step 5: Below is an example of toggling the manual trigger on the Axis device, which is reflected in the metadata stream.

 

Network protocols

Commonly used network ports

In this section you can read about commonly used network ports used by an Axis device for different services over the network.

Enabled by default

ProtocolPortTransport  Comments
HTTP80TCPGeneral HTTP traffic such as web interface access, VAPIX and ONVIF API interface or Edge-to-edge communication.
HTTPS443TCPGeneral HTTPS traffic such as web interface access, VAPIX and ONVIF API interface or Edge-to-edge communication.
RTSP554UDPUsed by the Axis device for video/audio streaming
RTPEphemeral port range*UDPUsed by the Axis device for video/audio streaming
UPnP49152TCPUsed by 3rd party applications to discover the Axis device via UPnP discovery protocol
Bonjour5353UDPUsed by 3rd party applications to discover the Axis device via mDNS discovery protocol (Bonjour)
SSDP1900UDPUsed by 3rd party applications to discover the Axis device via SSDP (UPnP)
WS-Discovery3702UDPUsed by 3rd party applications to discover the Axis device via WS-Discovery protocol (ONVIF)

Configuration dependent

ProtocolPortTransport  Comments
802.1xN/A**EAPIEEE 802.1x network authentication
ICMP/PINGN/A**ICMPGeneral OSI layer 3 communication
FTP21TCPFTP access to Axis device
SSH22TCPSSH access to Axis device
Telnet23TCPTelnet access to Axis device
DNS53UDPUsed by the Axis device to resolve IP address to hostnames
NTP123UDPUsed by the Axis device to synchronize time
SNMP161UDP/TCPUsed by the Axis device to send SNMP communication
SNMP (Traps)162UDP/TCPUsed by the Axis device to send SNMP communication
Syslog514UDPUsed by the Axis device to send log messages to a remote syslog
Syslog601TCPUsed by the Axis device to send log messages to a remote syslog
Syslog6514TCP Used by the Axis device to send log messages to a remote syslog via SSL/TLS
MQTT1883TCPUsed by the Axis device to send device events to a MQTT broker
MQTT8883TCPUsed by the Axis device to send device events to a MQTT broker via websockets
RTSPS322UDPUsed by the Axis device for encrypted video streaming (RTSPS/SRTP)
SMB445TCPUsed by the Axis device for edge recording to a remote network storage
O3C3128TCPUsed by the Axis device for O3C-related cloud communication
SOCKS1080TCPUsed by the Axis device for SOCKS-proxy network communication
SFTP22TCPUsed by the Axis device to send data via SFTP in an event rule
Action rule: emailEphemeral port range*TCPUsed by the Axis device to send images/videos via mail notification in an event rule
Action rule: TCP notificationEphemeral port range*TCPUsed by the Axis device to send notifications via TCP in an event rule
Action rule: image/video uploadEphemeral port range*TCPUsed by the Axis device to send images/videos via HTTP(S) in an event rule
SIP5060UDP/TCPUsed by the Axis device to send SIP communication
SIP5061UDP/TCPUsed by the Axis device to send SIP communication via TLS

*Allocated automatically within a predefined range of port numbers according to RFC 6056. More information can be found here.
**There is no TCP or UDP port number associated with this network traffic as these are associated with the transport layer above.

NTP (Network Time Protocol)

The NTP (Network Time Protocol) protocol is used to synchronize computer clocks on the Internet or in local networks. Version 4 (NTPv4) is the current version, and is described by RFC 5904. It's fully compatible with NTPv3 and all previous versions, and is designed to support the IPv6 protocol and dynamic server discovery. NTP is utilizing UDP as a transport protocol via port 123, which means that package delivery cannot be guaranteed. Axis devices use the OpenNTPD implementation as their current platform.

NTP uses a hierarchical structure where several NTP servers operating on different levels and accuracy (=stratum) are synced against each other to provide accurate time syncs to network devices. To do so, an NTP server in the network that provides time to local network devices should always sync to one or more NTP servers higher up in the hierarchy to avoid time-fluctuation and increased time accuracy. However, it's possible to operate an NTP server locally in a network in a standalone mode if no other NTP servers are available. More information about how the NTP protocol works can be obtained from public sources such as Wikipedia.

Sync process

The following sections illustrate the steps that are taken during a complete NTP synchronization. This network trace can be used as reference for below steps and shows a complete NTP synchronization from the first phase until the Axis device is in full NTP sync with the configured NTP server.

Phase 1
Phase 1 starts with the initial time query. The very first time-sync from an Axis device to an NTP server is a "universal sync" which means that any time provided by the NTP server will be taken by the Axis device as system time. Phase 1 is usually initiated when configuring the Axis device to sync against an NTP server (enable NTP), when the Axis device is restarted or when a firmware upgrade is initiated that also results in a restart of the Axis device.

Phase 2
After phase 1 follows a consolidation phase, where a number of time-sync requests from the Axis device against the NTP server are performed in between a 6 s – 60 s interval + 10 % randomization apart in order to align further with the NTP server to assure a close time-sync. The number of time-syncs vary depending on accuracy and trust according to the NTP protocol, but 5-15 time-syncs are usually needed.

 

Phase 3
Phase 3 is considered the usual operation mode. The query interval will stabilize after phase 2 between 30 - 1500 s + 10 % randomization apart. In case the time difference increases during normal operation mode, the camera will shorten the interval to sync more often in order to compensate for this. And if the time drift is very small, the intervals between two syncs will be larger. Please note that the sync state is changing to "Yes", which indicates that the Axis device is in good time-sync with the configured NTP server.

Common log messages

The following common log messages from Axis devices can be seen during NTP time-sync operations as well as during certain error conditions, e.g. if the NTP server is not operating correctly or cannot be reached. The log messages and their explanations provide a great detail of information on how the NTP protocol is working in practice. Plus, it's good to get an understanding of the log messages when troubleshooting NTP protocol related issues.

SituationClockNTP log messageExplanation
SyncNTPd Linux system clockntpd[21696]: reply from 192.168.255.29: offset -0.879648 delay 0.000313, next query 32s

This is a common log message indicating the offset, delay and when the next time-sync is going to be performed.

  • The delay in an NTP server describes the round-trip delay or latency of a timing message passed from client to server and back again. The delay is important so that network delays can be calculated and accounted for by the NTPd process of the Axis device.

  • The offset in ms indicates the actual time difference between the NTPd process of the Axis device and the NTP server time it's syncing to.

  • The next query is the time it takes for the Axis device's NTPd process to sync again to the NTP Server. When the "clock is in sync state" (more information below), the query interval is set to larger sync-intervals instead of shorter sync-intervalls that can be seen during the initial time-sync.

  • The jitter associated with a timing reference indicates the magnitude of variance, or dispersion, of the signal. Different timing references have different amounts of jitter. The more accurate a timing reference, the lower the jitter value.

No replyNTPd Linux system clockntpd[21696]: no reply from 192.168.255.29 received in time, next query 30sThe Axis device's NTPd process could not reach the NTP server on the network layer 2 and/or 3.
No replyNTPd Linux system clockntpd[21696]: no reply from 192.168.255.29 received in time, retransmit query 32sThe Axis device's NTPd process could not reach the NTP server on the network layer 2 and/or 3.
Negative delayNTPd Linux system clockntpd[21696]: reply from 192.168.255.29: negative delay -0.000471s, next query 3213sA state where the Axis device's NTPd process considers the NTP server in an erroneous state. Most likely the time has drifted significantly between the two network interfaces of the Axis device and the NTP server under a very short period of time and the "delay" can no longer be calculated correctly. No sync will take place for a longer period of time.
NTP server denies syncNTPd Linux system clockntpd[21696]: reply from 192.168.255.29: not synced (alarm), next query 3196sThe log message indicates that the NTP server itself denies to synchronize the NTPd process of the Axis device because it considers itself not synchronized to its (lower stratum) NTP server. It's a message that is sent from the NTP server. No sync will take place for a longer period of time.
System clock syncedNTPd Linux system clockntpd[21696]: clock is now syncedThe log message means that the NTPd process of the Axis device considers itself synced to the NTP server. This will cause the time-sync interval to be set to larger sync intervals since less syncs are needed. Directly after the sync state is reached, the RTC clock of the Axis device can be updated by the NTPd process.
System clock unsyncedNTPd Linux system clockntpd[21696]: clock is now unsyncedThe log message means that the NTPd process of the Axis device is not considering itself in sync with the NTP server. This state should not last long. When in this state, no RTC clock updates can be performed. If the logs indicate that the camera is in an unsynced state for many hours or days, it means that the NTP server is drifting faster than the Axis device’s NTPd process can account and compensate for.
NTP server reachableNTPd Linux system clockntpd[21696]: peer 172.27.0.41 now validThe log message indicates that the NTPd process of the Axis device could successfully verify the NTP server(s) integrity it's supposed to sync to.
NTPd drift fileNTPd Linux system clock1323.2313This value is in ppm (=microseconds) and indicates the amount of drift of the Linux system time that needs to be considered and compensated for by the Axis device's NTPd process. Note that this has nothing to do with the time drift that can occur on the RTC clock. Can be obtained via /var/lib/openntpd/db/ntpd.drift
RTC clock is setRTC clockntpd[21696]: set local clock to Tue May 29 08:34:21 CEST 2018 (offset 0.000168s)The log message indicates that the NTPd process of the Axis device is updating the RTC clock for the first time after it considered itself in good NTP sync towards the NTP server.
RTC clock is updatedRTC clockntpd[21696]: adjusting local clock. The current time diff is now -76.421369sWhen the NTPd process of the Axis device is in "Clock is now in sync" state, the RTC clock receives updates. The "current time diff" represents the time difference between NTPd Linux system clock and RTC clock.
Primary and secondary NTP server

With AXIS OS 9.40.1 or higher it's possible to configure a secondary NTP server in the web interface as well as up to five NTP servers via the VAPIX Time API. The device tries to synchronize with all servers that are configured. With the VAPIX Time API it's possible to configure up to 5 NTP server URLs. Additionally, one NTP server URL can resolve to many addresses, but only one "valid" server per URL is used for synchronization. So if you configure...

pool.ntp.axis.com AND 0.ntp.com where pool.ntp.axis.com resolves as three addresses [146.76.54.5, 146.76.54.56, 146.76.54.5] and 0.ntp.com resolves to 45.32.76.99

...the actual NTP servers that will be used are ONE valid and reachable address of the first URL and ONE valid and reachable address of the second URL:

(146.76.54.5 OR 146.76.54.56 OR 146.76.54.5) AND 45.32.76.99

The NTP algorithm determines which NTP server to use from the first pool.

External NTP servers

Axis public NTP server
Axis public NTP server is ntp.axis.com, to which cameras connected to the internet can sync its time.

Meinberg NTP server
Meinberg has its own standalone NTP server software that can be installed on Microsoft Windows OS with the possibility to sync against other NTP servers. It also has a standalone operation mode, ideal and simple for standalone environments without network connection to the outside.

Windows NTP server
By following these steps, it's possible to configure your local Windows system as an NTP server.

Note that Windows by default will have a lower NTP time accuracy as well as larger sync intervals, which may not be optimal for good time accuracy. It's recommended to configure the Windows NTP server with more strict and accurate time accuracy and sync intervals. See the following guides for more information on this:

Troubleshooting

Peer clock stratum unspecified or invalid (0)
The Axis device will not accept timestamps if the local NTP server is not synced with high layer NTP servers (Higher NTP hierarchy) as no reliable timestamps are provided.

What time is the Axis device sending?
While debugging NTP-related network issues, it can be observed that the Axis device is transmitting a random 64-bit time to the NTP server in order to mitigate the risk of cybersecurity attacks. This does not have any impact on the performance or quality of the NTP time sync itself since the NTP server will still respond with a valid time stamp which the Axis device will apply to its time.

Maximum time difference
Time differences between the Axis device and the NTP server that are larger than 2.145 s (35.75 min / 0.5 h) will result in there being no more time syncs. The reason is that the Axis device will assume that the time coming from the NTP server has changed too drastically and therefore considers the NTP server unreliable. It's recommended to check if the NTP server is functioning correctly and to reconfigure the Axis device to sync with the NTP server again to initiate a new time sync procedure.

Counteract clock drifting
The NTP client can adjust the system clock to 500 ppm (part per million) at most. It can e.g. counteract a clock drift of 1.8 seconds per hour. If the system clock has a larger drift than this, the Axis device's clock will never achieve a close enough offset to the NTP server. However, the system clock should not drift at a rate of that magnitude.

QoS (Quality of Service)

QoS provides the means to guarantee a certain level of a specified resource to selected traffic on a network. Quality can be defined as e.g. a maintained level of bandwidth, low latency, no packet losses, etc. The main benefits of a QoS aware network can be summarized as:

  • The ability to prioritize traffic and thus allow critical flows to be served before flows with lesser priority

  • Greater reliability in the network, thanks to the control of the amount of bandwidth an application may use, and thus control over bandwidth races between applications

To use QoS in a network with Axis video products the following requirements need to be met:

  • All network switches and routers must include support for QoS. This is important to achieve end-to-end QoS functionality

  • The Axis video products used must be QoS enabled

Imagine that the network in Figure 1 is an ordinary (non-QoS aware) network. In this example, PC1 is watching two surveillance video streams from cameras Cam1 and Cam2, with each camera streaming at 2.5 Mbps. Suddenly, PC2 starts a file transfer from PC3. In this scenario the file transfer will try to use the full 10 Mbps capacity between the routers R1 and R2, whilst the video streams will try to maintain their total of 5 Mbps. We can no longer guarantee the amount of bandwidth given to the surveillance system and the video frame rate will probably be reduced. At worst, the FTP traffic will consume all the available bandwidth.

Figure 1

 

Now, suppose the network in Figure 2 is QoS-aware and uses the DiffServ model (see below). The router R1 has been configured to devote up to 5 Mbps of the available 10 Mbps for streaming video. FTP traffic is allowed to use 2 Mbps, and HTTP and all other traffic can use a maximum of 3 Mbps. Using this division, video streams will always have the necessary bandwidth available. File transfers are considered less important and get less bandwidth, but there will still be bandwidth available for web browsing and other traffic. Note that these maximums only apply when there is congestion on the network. If there is unused bandwidth available, this can be used by any type of traffic. By using QoS we allow the network applications to co-exist on the same network, without consuming each other’s bandwidth.

Figure 2

 

Further reading

For further reading and more detailed documentation about the Quality of Service standard, see the following links:

QoS models

There are several different ways (models) of implementing QoS. Axis products use the DiffServ model, for greater scalability and flexibility. See below for more information.

The IntServ model
The IntServ model, or Integrated Services model uses a protocol called RSVP (Reservation Setup Protocol), which is used to reserve a certain traffic quality in the network. Prior to use, each application in an IntServ QoS network reserves its own resources and the router either grants or denies the request. When a reservation request is received, the routers need to find a path that can support the IntServ request and also the route that offers the best services. The major problem with this model is scalability. As the network increases in size, the connections database will grow to enormous proportions and it will be both difficult and ineffective to keep track of all reservations. Another drawback is the model’s inflexibility – the maximum amount of the resource in question that each type of traffic will ever receive is the maximum specified in the model, even if there are other unused resources available.

The DiffServ model
The Differentiated Services (DiffServ) model was introduced in 1998. It is based on two major components:

  • Packet marking

  • Router queuing disciplines

The applications in a DiffServ network mark their traffic so the router knows which service to apply to the packet. The marking is done in the IP header, by setting a field called the DSCP (Differentiated Services Codepoint). This is a 6-bit field that provides 64 different class IDs. Each DSCP value represents a QoS class, also known as a behavior aggregate. Thus, different applications can mark their own traffic with the same DSCP value. The intelligence of a DiffServ network is setup in the routers, where a particular DSCP value is mapped to a particular routing behavior. This behavior is referred to as a Per-Hop Behavior (PHB) and is implemented in the router using different queuing disciplines.

The DiffServ model abandons the concept of states as used in IntServ, and routers operate in a connectionless mode. This adds scalability to the system, since each router works independently, unaware of the network size and complexity. This model is also more flexible, as the classes of service are not strictly defined. Resources over and above the value specified as the maximum when resources are limited can be freely exploited whenever available. The main benefit of using this model in Axis products is that the products mark their own traffic, instead of letting the boundary nodes of the DiffServ domain do so. The conditioning algorithms in the boundary node cannot, for example, distinguish video over HTTP from audio over HTTP - they will only see HTTP, and probably provide a much lower level of service than actually required. To allow a node outside the DS domain to classify its own traffic:

  • The boundary router must be correctly configured

  • The camera must be set up as a trusted node

Per-Hop Behaviors (PHBs) define the router’s forwarding treatment for a certain class of traffic. Classes of traffic are also known as Behavior Aggregates (BA). Members of the BA are marked with the same DSCP value. There are four recommended PHBs defined, each mapped to one or more DSCP value.

The Default PHB: The default PHB provides the traditional best-effort service. It is represented by DSCP value 000000 (NOTE: 6-bits set to 0) and it must be available at any DiffServ router. This is the forwarding treatment applied to all non-DiffServ aware applications.

The Class-Selector PHB: To preserve backward compatibility with the old TOS field definition, the class-selector PHB defines a DSCP value of the form xxx000. The three bits represent the IP Precedence defined by a Type of Service aware network. The Class-Selector PHB ensures that DiffServ compliant nodes can coexist with IP Precedence-based nodes.

Expedited Forwarding: The Expedited Forwarding (EF) PHB provides a low loss, low latency, low jitter and guaranteed bandwidth service and can be considered the top priority behavior. Applications such as VoIP require this kind of robust service. The recommended DSCP value for EF is 101110.

Assured Forwarding: With Assured Forwarding (AF) traffic can be divided into four different classes. Each class is usually assigned a specific amount of bandwidth.

Within each class it is possible to specify three different drop precedence values. This value denotes the order in which packets will be dropped when there is congestion. A packet with a higher drop precedence will be dropped first. This gives us an AF matrix, and hence AF is often denoted AFxy, where x is the class number and y is the drop precedence. The table below shows the DSCP values recommended for the AF PHB. This gives us an AF matrix, and hence AF is often denoted AFxy, where x is the class number and y is the drop precedence. Table1.1 shows the DSCP values recommended for the AF PHB.

Table 1

 

DiffServ domain
A DiffServ domain (DS-domain) is a network that has been set up according to a particular DiffServ specification, and which has a set of DSCP values mapped to certain PHBs. As each router in a DiffServ domain forwards traffic based on DSCP value mapping, we can only guarantee that we get the correct forwarding treatment within our own DS-domain. As soon as a packet leaves the domain we can no longer guarantee how other routers will map our DSCP values. The same goes for incoming traffic - we must reclassify incoming traffic to match our rules. This means we must mark the traffic with a DSCP value valid in our domain. This is usually done by looking at the packet header and setting a new DSCP value based on the source address, port numbers, etc. The marking process is called traffic conditioning and is done at the boundary nodes of the DS domain.

VLAN 802.1P model
IEEE 802.1P defines a QoS model at OSI Layer 2 (L2, Data Link). This is called CoS, Class of Service, and adds an extra 3-bit field (called user-priority) to the VLAN MAC header. This splits traffic into 8 different classes. Priority is set up in the switches, which then use different queuing disciplines to forward the packets correctly. Although the 802.1P CoS works well, it lacks scalability and cannot provide end-to-end guarantees. We cannot assume the L2 protocol to be constant on a larger network or on the Internet. Therefore, most of today’s high-end switches implement mapping from L3 (IP DSCP) QoS to L2 CoS.

Routers

The DiffServ implementation in routers
Routers handle the forwarding of network traffic from one network to another. All packets entering from one network (see Figure 3) are queued before being processed, to determine which network they should be forwarded to. The DiffServ implementation in routers is a way of providing forwarding treatment based on the DSCP of an incoming packet. This is done by using queuing disciplines and prioritizing of packets. Note that router configuration is brand dependent and is not covered by this document.

Figure 3

 

Queue disciplines
To be able to provide the mechanism desired by DiffServ the routers implement different ways of handling its queues. These different techniques are known as queuing disciplines and are algorithms designed to provide different service guarantees.To exemplify the use of different queuing disciplines we will briefly explain FIFO queues and priority queues.

FIFO is the simplest queuing discipline and is usually the default setting in network routers. FIFO describes the simple First-In-First-Out behavior of the queue. The below image shows a FIFO queue where packets enter from the left and exit to the right. The first packet entering will be the first packet sent out on the port. Other packets will be placed at the end of the queue and must wait their turn. This discipline is too basic to provide any QoS service.

Figure 4

 

Priority queuing
Priority queuing is a relatively simple way of implementing differentiated service classes in a router. Instead of using one FIFO queue only, several are used, and each is assigned a different priority. A classifier determines which queue to put the incoming packet in, and the scheduler puts the packets out onto the network. The classifier parses the header of incoming packets and decides which priority queue to put the packetin. In a DiffServ network this decision is based on the DSCP value of the incoming packet. The scheduler ensures that the high priority queue gets served first, the medium priority queue next, and so on. This discipline allows the traffic to be prioritized.

Figure 5
AXIS OS

Axis has opted to use the DiffServ model, to provide greater scalability and flexibility. This is implemented by:

  • Marking network traffic

  • Classifying network applications in QoS classes

  • Providing a user interface

AXIS OS QoS classes
AXIS OS uses four QoS classes. The members of a class all mark their traffic with the same DSCP value and thus receive the same forwarding treatment from routers:

  • Live video - This class consists of applications that stream Motion JPEG video streams over HTTP, and MPEG-4 video streams over RTP, RTP/RTSP and RTP/RTSP/HTTP.

  • Live audio - This class consists of applications that generate audio flows, and is only present in products that supportaudio.

  • Event/Alarm - This class consists of applications that generate event and alarm traffic. The class handles FTP, HTTP, SMTP and TCP events.

  • Management - This class consists of applications that generate management traffic. The class can handle FTP, HTTP, HTTPS and SNMP management traffic.

AXIS OS QoS configuration
The image below shows an example of a screenshot of the HTTP user interface for QoS in Axis devices using AXIS OS 6.5X and lower. It shows the different QoS classes supported by the product and lets the user specify the DSCP (DiffServ Codepoint) value for each class. The default DSCP value is 0, which is the same as the default PHB and which can be interpreted as QoS disabled.

Figure 6

 

In Axis devices running AXIS OS 7.10 and higher the Plain Config in Settings > System > Plain Config > Network is used to perform QoS related configuration.

Figure 7

 

Performance improvements
The graph below illustrates a possible scenario in which performance is maintained/improved on a QoS enabled network.

  • Video is first streamed over a quiet, non-QoS network, where the frame rate can be assumed to be approximately 30 frames per second. This is illustrated by line A.

  • Network congestion is then simulated by, e.g., adding a non-responsive UDP stream. The frame rate drops sharply, to a practically unusable level, as shown by line B.

  • Video is then streamed over a DiffServ-enabled network, with the same congestion also added here. The video traffic is unaffected by the congestion and the frame rate is maintained, as shown by line C.

Figure 8

 

TCP ECN
ECN is an acronym for Explicit Congestion Notification and is an improvement of the congestion control i n T C P. The basic idea is for TCP to report that congestion is about to occur, before the queue actually overflows. The router does this by marking a field in the IP header called CE (Congestion Experienced). When the sender receives this signal the flow is slowed down. The traditional method of indicating congestion is for routers to drop packets that lead to the re-transmission of packets.

The ECN model will only be used when both communication end-points support it. This is achieved by negotiating at TCP connection initialization time. By introducing ECN support re-transmission over the network is minimized, which leads to higher throughput and less delay. TCP ECN is enabled by default in Axis video products and can be disabled in Plain Config > Network > TCP ECN.

IPv6

IPv6 (Internet Protocol version 6) was initially designed by the IETF to replace the current IP version 4 (IPv4). The most likely scenario now is that IPv4 will remain even after IPv6 enters the arena. One of the main reasons for the introduction of IPv6 is the growing shortage of IPv4 addresses. Additionally, IPv6 also adds improvements in areas such as routing and network auto-configuration. Some general information about IPv6 addresses and configuration is provided in the following sections, and the complete IPv6 specifications can be found in the RFC 2460 specifications.

IPv6 addresses
The IPv6 address is written in hexadecimal form, and consists of eight double-bytes separated by colons. To make the address representation as short as possible, a number of consecutive zeros may be abbreviated to a double colon, which is allowed once in any single IPv6 address. Instead of using a subnet mask as in IPv4, IPv6 simply uses a network prefix length. The prefix length is appended to the address.

Example: fe80::250:daff:fe4d:7592/64

The prefix length specifies how many bits of the address will be considered part of the prefix. In the example above, the first 64 bits specify the network address, while the final 64 bits specify the host address. IPv6 addresses can be assigned in different ways:

  • A link-local IPv6 address is automatically configured.

  • A DHCPv6 server can be used to assign IPv6 addresses.

  • Router advertisements can be used to assign auto-configured addresses.

Auto-configured link-local address
A device that supports IPv6 will get an auto-configured link-local address that starts with fe80. The remainder of the address is usually built on a so-called EUI64 address. The EUI64 address is constructed by taking the Ethernet MAC address of the network interface, and filling it with two specific bytes (fffe) in the middle, to get a 64-bit address (see the example address in the previous section.)

Auto-configuration using router advertisements
In an IPv6 network, network devices may be auto-configured by listening to advertisements sent by routers in the network. These advertisements will then define how the network devices should be configured in order to be able to be routable. A routable IPv6 address can be derived by using the information in the router advertisements. This auto-configured address is derived using the EUI64 address, together with the address of the router and the network prefix. The router advertisements may instruct the network device to use DHCPv6, and if so, at which level.

DHCPv6 configuration
Just as an IPv4 network may use a DHCP server to assign IP configuration, an IPv6 network may use a DHCPv6 server. DHCPv6 can be used at different levels:

  • In stateless mode the DHCPv6 server will designate the network servers to use, e.g., DNS servers and NTP servers, but it will not assign IPv6 addresses for network devices. This must be done using some other method.

  • In stateful mode, the DHCPv6 server will also assign IPv6 addresses to the network devices, as well as assigning the network servers as in stateless mode.

Accessing IPv6 devices
Most programs accept host names and will automatically look up the IPv6 address. This is the preferred way of passing addresses to programs. If the name maps to an IPv4 address, IPv4 will be used. If the name maps to an IPv6 address, IPv6 will be used. If there are both IPv4 and IPv6 mappings, the operating system will decide which to try first. To pass IPv6 literal addresses to a program, there are a few points to consider. When passing an URL, brackets must be used. To pass IPv6 literal addresses to a program, there are a few points to consider. When passing an URL, brackets must be used. For example:

ExampleComment
http://[2001:5c0:84d9:2:240:8cff:fe6b:3cb9]Accessing an Axis device using http
http://[2001:5c0:84d9:2:240:8cff:fe6b:3cb9]:8080Accessing an Axis device using http and custom httpport
https://[2001:5c0:84d9:2:240:8cff:fe6b:3cb9]Accessing an Axis device using https
http://root:pass@[2001:5c0:84d9:2:240:8cff:fe6b:3cb9]Accessing an Axis device using http and pre-entered access credentials
http://[fe80::2:240:8cff:fe6b:3cb9%eth0]Accessing an Axis device using the link-local address. Note that the network interface is specified after the IPv6 address. This is because the link-local prefix fe80::/10 has multi-path routes, i.e., one route per interface. The routing system has no way of knowing which interface the device you are trying to contact is located on.

Most programs (e.g., FTP, Telnet, etc) will accept the IPv6 address in its literal form such as ftp 2001:5c0:84d9:2:240:8cff:fe6b:3cb9 or ftp fe80::2:240:8cff:fe6b:3cb9%4. Some programs may take the interface identifier in a non-standard way. An example of this is the ping6 tool usually distributed with linux. It expects to be run like this ping6 -I eth1 fe80::2:240:8cff:fe6b:3cb9. On Windows you can see the identifier of each adapter by running ‘ipconfig’ and finding the IPv6 link-local address of that interface. It may look something like this:

Common IPv6 addresses and ranges

IPv6 addressExplanation
0:0:0:0:0:0:0:0Equals IPv4 0.0.0.0 and is the source address of a host before it receives an IP address from DHCP
0:0:0:0:0:0:0:1Equals ::1 and is the equivalent of IPv4 127.0.0.1
0:0:0:0:0:0:192.168.100.1This is how an IPv4 address would be written in a dual-stack mixed IPv4-IPv6 environment
2000:::/3The global unicast address range
FC00::/7The unique local unicast range
FE80::/10The link-local unicast range
FF00::/8The multicast range
3FFF:FFFF::/32Reserved for examples and documentation
2001:0DB8::/32Reserved for examples and documentation
2002::/16Used for IPv6 to IPv4 tunneling and used as a transition system which allows IPv6 packets to be transported over an IPv4 network without the need to configure an explicit tunnel.
IPv6: AXIS OS configuration

Web interface
The IP configuration of the Axis video product is usually made from the TCP/IP settings (see section 2.1) pages in the embedded web interface. In addition to this, you can list the parameters directly in the Plain Config page. From here you can customize the IPv6 configuration, by changing parameters that are not available from the TCP/IP settings page. On the TCP/IP settings page, it is possible to enable or disable the use of IPv4 and/or IPv6.

The user is prohibited from disabling both IPv4 and IPv6, since this will render the Axis device inaccessible. It is however, still possible to disable both IPv4 and IPv6 from the Plain Config page. If this happens, the Axis device will override the configuration and start IPv4 according to the IPv4 configuration.

Use of IPv4 is enabled by default. When IPv4 is disabled no IPv4 configuration will be made on the device. The device will then only be accessible via IPv6. Note that when IPv4 is disabled, a link-local IPv4 address will not be assigned, even if the use of a link-local IPv4 address is enabled on the Advanced TCP/IP Settings page.

Use of IPv6 is disabled by default. When IPv6 is enabled, the Axis device will assign a link-local IPv6 address. By default, the device will also listen to router advertisements and assign IPv6 addresses accordingly. It is possible to change the IPv6 configuration behavior using the plain configuration interface found in the Advanced System Options menu. For further descriptions of the advanced IPv6 settings.

Plain Config
The IPv6 configuration is by default set to accept router advertisements and to use DHCPv6 according to the router advertisements. In different environments it may be necessary to change the IPv6 configuration. To do this, go to the Plain Config page and select the Network parameter group. By altering the parameters in the Network.IPv6 parameter group, the behavior of the IPv6 configuration is changed. The group consists of five parameters:

ParameterComment
Network.IPv6.EnabledThis parameter is used to enable or disable IPv6 network configuration.
Network.IPv6.AcceptRAThe Accept router advertisements parameter is used to enable or disable the said functionality. If this parameter is set to yes, the Axis device will listen to router advertisements on the network and perform IPv6 configuration according to it.
Network.IPv6.DHCPv6This parameter is used to configure either of the four DHCPv6 client settings
  • auto – The use of DHCPv6 is determined by the router advertisements

  • stateless – DHCPv6 is used to set DNS servers and NTP servers etc, but not to set IPv6 addresses

  • stateful – DHCPv6 is used to set IPv6 addresses as well as DNS servers, etc.

  • off – DHCPv6 is disabled

Network.IPv6.IPAddressThe IP Address parameter is used to manually set an IPv6 address. This address will be used in parallel with other IPv6 addresses that may be set by DHCPv6 or by router advertisements. If a specific prefix length is requested the prefix length is defined last in the address, like this: 2001:5c0:84d9:2::1:3b/128. If no prefix length is defined, the default length 64 will be used.
Network.IPv6.DefaultRouterThe Default router parameter is used to manually set an IPv6 default router. This address will be set in parallel with other IPv6 addresses that may be set by DHCPv6 or by router advertisements.
Additional InformationThe IPv6 addresses currently in use are read from the IP address parameter In the Network.<interface>.IPv6 group, where <interface> is the name of the interface (e.g. eth0, eth1 etc..). This parameter lists all IPv6 addresses, separated by space characters.

IEEE 802.1X

There are different levels of security for a network’s infrastructure and the devices connected to it. The first level is authentication and authorization. The user or device identifies itself to the network and the remote end by a username and password, which are then verified before the device is allowed into the system. Added security can be achieved by encrypting the data to prevent others from using or reading the data. Common methods are HTTPS (also known as SSL/ TLS), VPN, and WEP or WPA in wireless networks. IEEE 802.1X is an authentication and authorization technique. Axis network video products support IEEE 802.1X as a security feature. This section presents the background of IEEE 802.1X, as well as its working principle. It also describes how IEEE 802.1X should be used in Axis devices, and how the RADIUS (remote authentication dial-in user service) servers and switches need to be configured. The intended audience of this document is technical personnel and system integrators.

IEEE 802.1X is an IEEE standard for port-based network access control (“port” means the physical connection to the LAN infrastructure). It is part of the IEEE 802.1 group of networking protocols and provides an authentication mechanism for devices to connect to a LAN, either establishing a connection or preventing the connection if authentication fails. IEEE 802.1X prevents what is called “port hi-jacking”, that is, when an unauthorized computer gets access to a network through a network jack inside or outside a building. IEEE 802.1X is useful in network video applications since their devices are often located in public spaces where a network jack can pose a security risk. In modern enterprise networks, IEEE 802.1X is becoming a basic requirement for anything that is connected to a network.

Working principle
There are three basic terms in IEEE 802.1X. The user or client that wants to be authenticated is called a supplicant. The actual server doing the authentication, typically a RADIUS server, is called the authentication server. And the device in between, such as a switch, is called the authenticator. The protocol used in IEEE 802.1X is EAPOL (Extensible authentication protocol encapsulation over LANs). There are several modes of operation, but the most common case is described here:

  • The authenticator sends an “EAP-Request/Identity” packet to the supplicant as soon as it detects that the network link is active (this could be because the supplicant, for example a specific Axis device in a network video system, is connected to the switch).

  • The supplicant sends an “EAP-Response/Identity” packet to the authenticator.

  • The “EAP-Response/Identity” packet is then passed on to the authentication (RADIUS) server by the authenticator.

  • The authentication server sends back a challenge to the authenticator, such as with a token password system.

  • The authenticator unpacks this from IP and repackages it into EAPOL and sends it to the supplicant. Different authentication methods will vary this message and the total number of messages. EAP supports client-only authentication and strong mutual authentication.

  • The supplicant responds to the challenge by the authenticator.

  • The authenticator passes the response to the challenge onto the authentication server.

  • If the supplicant provides proper identity, the authentication server responds with a success message to the authenticator.

  • The success message is then passed onto the supplicant by the authenticator. The authenticator now allows access of the supplicant to the LAN, possibly restricted based on attributes that came back from the authentication server. For example, the authenticator might switch the supplicant to a particular virtual LAN or install a set of firewall rules.

 

It should be noted that setting up and configuring IEEE 802.1X is a fairly complex procedure, and it is important that RADIUS servers, switches, and clients (such as Axis devices) are set up correctly.

IEEE 802.1X: AXIS OS configuration

Web interface
To gain access to a protected network, the Axis device must have a CA certificate, a client certificate, and a client private key. These should be created by the servers and uploaded via a web interface. When the Axis device is connected to the network switch, the device will present its certificate to the switch. If the certificate is approved, the switch allows the device access on a preconfigured port. As pointed out previously, in order to use port-based authentication, the network must be equipped with a RADIUS server and a network switch with support for IEEE 802.1X. You may also need to contact your network administrator for information on certificates, user IDs and passwords depending on the type of RADIUS server that is used.

The settings here enable the Axis device to access a network protected by IEEE 802.1X/EAPOL (Extensible Authentication Protocol over LAN). There are many EAP methods available to gain access to a network. The protocol used by Axis is EAP-TLS (EAP-Transport Layer Security) for wired and wireless IEEE 802.1X network authentication, as well as EAP-PEAP/MSCHAPv2 for wireless IEEE 802.1 network authentication.

Excerpt of the web interface of AXIS M1065-LW with wired IEEE 802.1X settings

 

Excerpt of the web interface of AXIS M1065-LW with wireless IEEE 802.1X settings (System tab > Wireless).

 

The client and the RADIUS server authenticate each other using digital certificates provided by a PKI (public key infrastructure) signed by a certification authority. Note that to ensure successful certificate validation, time synchronization should be performed on all clients and servers prior to configuration. Further configuration of Axis devices should be performed on a safe network to avoid MITM (man in the middle) attacks. Terms used in the web interface are described as follows:

  • CA certificate - The CA certificate is created by the certification authority for the purpose of validating itself and the Axis device needs it to check the server’s identity. Select the correct certificate that was uploaded previously in the security tab under CA certificates. From AXIS OS 10.1 and onwards, selecting no CA certificate (none) means the Axis device will skip doing any validation of the server's identity.

  • Client certificate - The Axis device must also authenticate itself using a client certificate. Select the correct certificate that was uploaded previously in the security tab under client certificates.

  • EAPOL version - Select the EAPOL version (1 or 2) used in your network switch.

  • EAP identity - Enter the user identity associated with your certificate. A maximum of 16 characters can be used.

WS-Discovery (Web Services Dynamic Discovery Protocol)

The Web Services Dynamic Discovery protocol utilizes UDP Port 3702 and defines itself as a multicast discovery protocol that is used to detect other devices and services on the network. ONVIF is relying on this protocol in order to detect other capable devices, so Axis devices support WS-Discovery for initial on-boarding and configuration. It is recommended to disable the WS-Discovery after usage since it is vulnerable to attacks as described in this security advisory. See instructions below on how to disable WS-Discovery.

 

AXIS OS > 9.70
Disable the service by disabling the parameter Enable WS-Discovery discoverable mode in Settings > System > Plain config > WebService > DiscoveryMode > Enable WS-Discovery. For multiple device configuration in AXIS Device Manager, the corresponding VAPIX parameter is called DiscoveryMode.Discoverable.

 

AXIS OS 5.70 — 9.60

  • Enable SSH in Plain config > Network > SSH and connect to the Axis device via Putty

  • Type the following commands, each followed by pressing ENTER

    • systemctl mask wsdd

    • systemctl mask wsd

    • systemctl mask wsd.socket

    • systemctl stop wsdd

  • Disable SSH again from Plain Config and restart the device

 

AXIS OS 5.60

  • Enable SSH in Plain Config > Network > SSH and connect to the Axis device via Putty

  • Type the following commands, each followed by pressing ENTER

    • rm /etc/rc3.d/S92wsdd

    • /etc/init.d/wsdd stop

  • Disable SSH again from Plain Config and restart the device

 

AXIS OS < 5.50

  • Enable Telnet as described here and connect to the Axis device via command-line tool.

  • Type the following commands, each followed by pressing ENTER

    • rm /etc/rc3.d/S92wsdd

    • /etc/init.d/wsdd stop

  • Disable Telnet again and restart the device

SNMP (Simple Network Management Protocol)

This section describes how to use AXIS Video SNMP MIB. It is assumed that you are already familiar with the Simple Network Management Protocol (SNMP).

SNMP/MIBs allow network management operators to use standard SNMP tools to monitor the status of Axis products. The Axis Management Information Base (MIB) for video hardware enables monitoring of hardware-related issues that may need administrative attention. This applies to devices with AXIS OS 5.60 and higher. Note that new functionality may be added in later releases. For detailed information, please read the MIB file.

Some products will not have all the hardware as specified below and there will only be one MIB defined for all hardware. In case the agent requests the status of hardware that is not included in the product, the device will return "noSuchObject". Which hardware is supported is handled at run time, meaning there is no need for product specific configuration. All Axis devices support the AXIS Video MIB from AXIS OS 5.60 and higher except for AXIS Companion Line devices, however it is recommended to update to the latest firmware. These MIBs are required to use AXIS Video MIB:

  • SNMPv2–TC

  • SNMPv2–SMI

  • SNMPv2–CONF

  • AXIS-ROOT-MIB

  • AXIS-VIDEO-MIB

Enable SNMP

To use this functionality, SNMP must be enabled in the cameras and encoders on the network. To use SNMPv3, HTTPS has to be enabled. For information about how to enable HTTPS, see the User Manual for the product. Use AXIS Device Manager to enable SNMP on multiple devices. AXIS Device Manager is available for download from www.axis.com. SNMP in Axis devices can be enabled as below

  • AXIS OS 6.5X and lower, SNMP can be enabled from the web interface using Setup > System Options > Network > SNMP.

  • AXIS OS 7.10 and higher, SNMP can be enabled from the web interface using Settings > System > SNMP.

SNMPv3 access

To enable SNMPv3 in Axis devices, a password must be set in the web interface for the default SNMP user initial. Once SNMPv3 is enabled, the following default privacy and authentication modes are pre-configured:

AXIS OSPrivacyAuthentication
10.7 and higherAES-128SHA-1
10.6 and lowerDESMD5

Note that it’s currently not possible for the user to change the default privacy and authentication modes in an easy way.

SNMP trap configuration

All Axis devices support the default SNMP MIB-II traps (Cold start, Warm start, Link up, Authentication failed). In addition, Axis devices support a number of feature and product specific traps that are included in AXIS Video MIB (described in AXIS Video MIB traps). Depending on your SNMP version, different configurations are required/available for using SNMP traps.

SNMPv1/v2c trap configuration
When SNMPv1 and SNMPv2c are used, all AXIS Video MIB traps documented in AXIS Video MIB traps will be enabled and sent when SNMP traps are enabled. The default MIB-II SNMP traps can be configured and enabled/disabled individually:

  • Cold start - sent when SNMP has been started and the configuration and MIB have changed

  • Warm start - sent when SNMP has been started and the configuration has changed, but not the MIB

  • Link up – sent when the network link changed from down to up

  • Authentication failed – sent when snmp-authentication attempt failed

SNMPv3 trap configuration
For SNMPv3, both the default MIB-II SNMP traps as well as the AXIS Video MIB traps need to be configured and enabled manually. This is done using the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB modules, defined in RFC 3413. So in order to configure the Axis device to send out SNMP traps, the following tables need to be configured accordingly:

  • snmpNotifyTable

  • snmpTargetAddrTable

  • snmpTargetParamsTable

  • snmpNotifyFilterProfileTable

  • snmpNotifyFilterTable

AXIS Video MIB

AXIS Video MIB (Message Information Base) extends the way to monitor Axis devices over SNMP. The Video MIB enables network administrators to monitor status information and a number of new notifications. To make use of the AXIS Video MIB, download the MIB files here and import them in your SNMP network monitoring application. The AXIS Video MIB is supported by Axis network devices from AXIS OS 5.60 and higher.

AXIS Video MIB traps

There are only three kinds of traps that can be generated by a video product. These three kinds are defined in the AXIS Video MIB and they should cover all the future needs of traps and thus they are defined in general terms. The trap types are described below:

  • alarmNew — This trap is sent to warn about a status change. Additional parameters include a unique trap ID (alarmID), a text string identifying the event (alarmName) and an additional string (alarmText) that specifies more detailed information about the event, for instance the unique identifier of the hardware or its status. This new state is valid until it is cleared by an alarmCleared trap. In general the state can be obtained through an SNMP get command as well.

  • alarmCleared — This trap is sent to indicate that some hardware has gone back to its normal state. The alarmID specifies the ID of a previous alarmNew trap that is cleared by this trap. Additional parameters include the same alarmName and alarmText that was sent by the alarmNew trap.

  • alarmSingle — This trap is sent to warn about a certain event. Additional parameters include a unique trap ID (alarmID), a text string identifying the event (alarmName) and an additional string (alarmText) that specifies more detailed information about the event, for instance the unique identifier of the hardware or its status. The difference from the alarmNew trap is that this trap refers to a stateless event. For this reason there is no alarmCleared and hence several traps indicating the same event might follow each other. Since this is a stateless event it is impossible to get any related information through SNMP get command.

Trap name/use caseTrap typeAlarm nameAlarm cleared event*Supported products
(Multiple) Power Supply FailurealarmNewpowerSupplyAlertAXIS Q7900 Rack and AXIS Q7920 Video Encoder Chassis
(Multiple) Fan FailurealarmNewfanAlertAXIS Q7900 Rack and AXIS Q7920 Video Encoder Chassis
(High or Low) Temperature Limit Reached AlertalarmNewtemperatureAlertAll Axis devices
(Multiple) Analog Video Signal LostalarmNewvideoSignalAlertAll Axis video encoders
(Multiple) Audio Input Signal LostalarmNewaudioSignalAlertAll Axis audio-capable devices with external audio input
Product Casing Opened AlertalarmNewopenCasingAlertAll Axis devices connected with AXIS T93F door switch / intrusion alarm
Mechanical PTZ Error AlertalarmSinglePTZAlertAll Axis mechanical PTZ devices
Edge Storage AlertalarmNewstorageMediaAlertAll Axis devices featuring SD cards and mounted network share
Camera Tampering AlertalarmSingletamperingAlertAll Axis tampering-capable devices
General TrapalarmNew or alarmSingle**Custom AlarmText All Axis devices

*The alarm cleared event is sent automatically. E.g. if the Axis device detects an issue with the storage devices, it will send out an alarm, and if the issue resolved itself, it will send another alarm notifying that the issue is resolved.
**Depending on whether the event is stateless or stateful the trap is of type alarmNew or alarmSingle

AXIS Video MIB OIDs

The status operations that are available in the AXIS SNMP MIB are listed below. All statuses are read-only objects. If a set operation is requested on the OID it will return 17, notWritable (or 2,nosSuchName, for protocol version 1). A status operation can have one or more OIDs depending on the product. As an example, .1.3.6.1.4.1.368.4.1.1.1.3.x can be .1.3.6.1.4.1.368.4.1.1.1.3.1 Temperature Sensor 1, .1.3.6.1.4.1.368.4.1.1.1.3.2 Temperature Sensor 2, .1.3.6.1.4.1.368.4.1.1.1.3.3 Temperature Sensor 3, and so on.

OID NameOIDPossible OID StatesSupported products
Get Power Supply Status .1.3.6.1.4.1.368.4.1.1.1.3.xOK;FailureAXIS Q7900 Rack and AXIS Q7920 Video Encoder Chassis
Get Fan Status.1.3.6.1.4.1.368.4.1.2.1.3.1.xOK;FailureAXIS Q7900 Rack and AXIS Q7920 Video Encoder Chassis
Get Temperature Sensor Value.1.3.6.1.4.1.368.4.1.3.1.4.1.xTemperature in degree celsiusAll Axis devices
Get Temperature Sensor Status.1.3.6.1.4.1.368.4.1.3.1.3.1.xOK;Failure;OutOfBoundaryAll Axis devices
Get Video Signal Status.1.3.6.1.4.1.368.4.1.4.1.2.xSignalOK;NoSignalAll Axis video encoders
Get Audio Signal Status.1.3.6.1.4.1.368.4.1.5.1.2.xSignalOK;NoSignalAll Axis audio-capable devices
Get Casing Status.1.3.6.1.4.1.368.4.1.6.1.3.xOpen;ClosedAll Axis devices connected with AXIS T93F door switch / intrusion alarm

Get Storage Disruption Status

.1.3.6.1.4.1.368.4.1.8.1.3.xYes;NoAll Axis devices
AXIS Video MIB Tree

Import AXIS Video MIB files using iReasoning MIB Browser

The screenshots below illustrates how to import AXIS Video MIB files into the iReasoning MIB Browser.

SNMP walk using iReasoning MIB Browser

The screenshots below illustrate how to do an SNMP walk on an Axis device. Please note that SNMP needs to be enabled before.

SNMPv1/2

 

SNMPv3

Receiving SNMP traps using iReasoning MIB Browser

The screenshots below illustrate how to receive an SNMP trap from an Axis device. Please note that SNMP traps need to be enabled before.

All Axis devices with AXIS OS 7.10 and higher are utilizing the LLDP (Link Layer Discovery Protocol) protocol to neighbor-announce their identity and capabilities information using the TLV-encoding scheme (Type-Length-Value) in the network. When sending out LLDP announcements, it is possible to configure certain information such as system description and name of the device. In order to configure specific LLDP settings, please access the device via SSH, SSH is disabled per default and can be enabled in Settings > System > Plain config > Network. Once SSH access is established, type "lldpcli". See the following instructions. for further commands that can be used in the LLDPCLI.

In addition to neighbor announcements, LLDP can also be used for software-based PoE negotiation. IEEE 802.3at (30 W PoE+) capable devices support software-based PoE negotiations and IEEE 802.3af (15.4 W) capable devices running AXIS OS 9.20 and higher support the LLDP allocation of max-power towards the connected PoE-switch. When enabled, the Axis device will notify the PoE-switch about its max PoE consumption so that the PoE-switch can perform a better PoE-management and allocate less PoE to the network port. LLDP allocation for max-power can be enabled in Settings > System > Plain config > Network > LLDP POE > LLDP Send Max PoE. Both methods utilize the LLDP Dot3 PoE-MDI TLV.

When LLDP allocation for max-power is enabled in the Axis device and the network switch is configured properly in regards to LLDP- and PoE-mode according to vendor documentation, the network switch should be able to reserve exactly the amount of max PoE wattage the Axis device would need. The example below illustrates the behavior of LLDP allocation for max-power being enabled and disabled in an Axis device.

Disabled

 

Enabled

When LLDP allocation for max-power is disabled, the network switch will reserve the full amount of 15.4 W PoE according to IEEE 802.3af with no savings gained. Compare it with having the LLDP allocation for max-power enabled, which will result in the network switch reserving in total 11.3 W PoE instead, where 9.6 W results from the needs of the Axis device and the additional 1.7 W is a margin for power loss due to cable length. This improved PoE management results in saving 4.1 W PoE that can be used on a different network port on the same network switch.

Media Endpoint Discovery (LLDP-MED)
LLDP-MED (Media Endpoint Device Extension) is an extension on top of the LLDP protocol stack that allows devices to include more information (TLVs) during LLDP exchange with network neighbors. At the time of writing (December 2020), Axis devices do not support LLDP-MED extensions and therefore do not support e.g. the LLDP-MED POE-MDI TLV for PoE power negotiation.

CDP (Cisco Discovery Protocol)

All Axis devices with AXIS OS 8.50.1 and higher are utilizing the CDP (Cisco Discovery Protocol) protocol to announce their identity and capabilities in the network. Compared to the LLDP protocol, no CDP traffic is sent out from the Axis device by default unless the network switch initiates CDP communication first.

CDP is also used for power negotiation in IEEE 802.3at (30W PoE+) capable devices. By default, the Axis device is capable of power negotiating IEEE 802.3at (30W PoE+) either using CDP or LLDP. Which one of these protocols is used depends on the network switch configuration.

In a situation where both protocols are being enabled and used by the network switch, the Axis device will respond to the protocol that arrives first (first come, first served). Note that Cisco 60W UPoE power negotiations are not supported regardless if they are hardware- or software-based.

Syslog

Syslog is a standard for message logging in IT devices. It is increasingly required in IT business applications and governance to facilitate, store, monitor and analyze audit logs from IT devices. The syslog standard is based on RFC 3164 and the newer RFC 5424. Axis devices are compliant with both standards in order to allow for an easy and simple integration towards 3rd party syslog servers such as Nagios, PRTG, Syslog-NG- or Rsyslog-based syslog servers. The common term used for edge devices sending their log messages to a syslog server is referred to as “remote logging” or “remote syslogging”. When it comes to syslog, there are two different types of devices in a network working together:

  • Edge device: An edge device with support for syslog generates log messages which are sent to a centralized server. The edge device in itself, however, may have limited amount of system resources to keep log messages long enough, or the messages may be overwritten or erased automatically upon reboot. Axis devices are examples of edge devices.

  • Syslog server: The syslog server is a centralized entity in the network that receives syslog messages from edge devices and facilitates and stores them in a manner that allows for real-time analysis and/or auditing. Different types of syslog servers are available and range from simple servers that “just” store incoming syslog messages up to fully-fledged enterprise-class syslog servers providing all means for real-time analysis as well as auditing with notification backend.

In order to send log messages to the syslog server, the edge device and server need to communicate using the same protocol/port. The edge device also needs to be configured so that it sends log messages with the desired severity.

  • Protocol/ports: The syslog standard is based on RFC 3164 and the newer RFC 5424. The default ports that are used are UDP port 514 and TCP port 601 as well as encrypted transport via SSL/TLS port 6514.

  • Log message severity: Log messages are categorized in severities based on importance, from low to high. In newer Axis firmware, it is possible to define from which severity level the Axis device will send log messages to a remote syslog sever. See log message severities for Axis devices below:
    DEBUG – INFO – NOTICE – WARNING – ERROR – CRITICAL – ALERT – EMERGENCY

     

    Examples of log messages from an Axis device

    2020-08-06T18:00:06.463+00:00 axis-accc8ebfe654 [ NOTICE ] syslog-ng[595]: Configuration reload
    2020-08-06T18:00:06.463+00:00 axis-accc8ebfe654 [ NOTICE ] syslog-ng[595]: Configuration reload request
    2020-08-06T18:00:06.493+00:00 axis-accc8ebfe654 [ INFO ] systemd[1]: logrotate.service: Succeeded.
    2020-08-06T18:00:06.494+00:00 axis-accc8ebfe654 [ INFO ] systemd[1]: Started Rotate log files.
    2020-08-06T18:00:06.494+00:00 axis-accc8ebfe654 [ ERROR ] iod[523]: Couldn’t start I/O ports

     

    Syslog in Axis devices

    Axis devices have been compliant with the syslog standard since its implementation in the 2000s. As such, Axis devices have throughout the years been supporting syslog in various ways in order to adapt, always using the newest implementation:

    ImplementationSYSKLOGDRSYSLOGSYSLOG-NG MK ISYSLOG-NG MK II
    Supported firmware

    <=5.55

    5.60 - 6.50

    7.10 - 10.0

    10.1 =>

    Script editor configuration

    Web interface configuration

    VAPIX API configuration

    SD card or network share storage*

    Transport protocol

    UDP

    TCP/UDP

    TCP/UDP

    TCP/UDP/TLS

    Primary & secondary remote syslog server**

    Send log messages test button***

    Log severity configuration****

    * Optional support for saving syslog messages to the local SD card or network share.
    ** Possibility to configure a primary and secondary remote syslog server. When both are configured, the Axis device will send its log messages simultaneously to both servers. Observe that this is not a failover-configuration.
    *** Possibility to send test messages to the remote syslog server in order to verify correct configuration.
    **** Possibility to configure the Axis device to send log messages with a specific severity and higher only.

    The coming sections will show example configurations that can be accomplished illustrated with the different syslog implementations that Axis devices have supported throughout the years.

     

    Syslog configuration in FW 10.1

    Web interface
    Devices with firmware version 10.1 and higher have a graphical user interface for syslog configuration. This can be found via the web interface of the device, under Settings > System > TCP/IP.

    Remote syslog via UDP:

    Remote syslog via TCP:

     Remote syslog via TCP/TLS*:

     Remote syslog via TCP/TLS (primary + secondary)**:

    * For the TLS mode you need to specify a CA certificate that will be used by the Axis device to verify the remote syslog server. This CA certificate is generated and provided during the configuration of the 3rd party remote syslog server.
    ** When a primary and secondary syslog server is configured, the Axis device will always send its log messages simultaneously to both servers independently regardless if the primary, secondary, or both servers are available.

     

    Two sample illustrations of an Axis device streaming its syslog messages to either a primary server only, or a primary/secondary server in parallel.

     

     

    VAPIX interface (VAPIX API)
    Products with firmware version 10.1 and higher also support the Remote Syslog API VAPIX interface that allows for mass-configuration of Axis devices e.g. using AXIS Device Manager. For more information, please go to the VAPIX library.

    AXIS Device Manager
    With the introduction of the new Remote Syslog API, it is also possible to configure remote syslog settings for multiple Axis devices simultaneously.

    Syslog configuration in FW 7.10 - 10.0

    Script editor
    In order to configure remote syslog server, the script editor needs to be enabled. This can be done via the web interface of the Axis device, under Settings > System > Plain config > System > Enable the script editor (editcgi).

    To configure syslog, open the following link in the browser, replace the IP adress placeholder ("ip_of_cam") with the real IP address of the Axis device: http://ip_of_cam/admin-bin/editcgi.cgi?file=/etc/syslog-ng.d/remote.conf

    Add IP address, transport method and port as you see in the below example configuration. Click Save file once done and restart the device.

    Note

    Make sure that no code line is out commented by a hash symbol ("#") like in the example configuration above.

     

    AXIS Support ACAP
    AXIS Support ACAP provides the possibility for a simple and fast remote syslog configuration using a graphical user interface. By default, the ACAP configures a remote syslog server with UDP transport method on port 514 and essentially configures the configuration file in the script editor, illustrated in previous section.

    Furthermore, the AXIS Support ACAP can configure a remote syslog server on an Axis device independently of its firmware version, starting from FW 5.60.

     

    Syslog configuration in FW 5.60 - 6.50

    In order to configure syslog, open the following link in the browser and replace the IP address placeholder (i.e. "ip-address") with the real IP address of the Axis device: http://ip-address/admin-bin/editcgi.cgi?file=/etc/rsyslog.d/40-remote_log.conf

    Remote syslog server
    Add *.* @ip-address at the bottom of the configuration file and specify the real IP address of the remote syslog server instead. Click Save file once done and restart the device.

     

    SD card
    Start by mounting an SD card in the Axis device. Then add *.* /var/spool/storage/SD_DISK/logs.txt at the bottom of the configuration file. Click Save file once done and restart the device.

     

    Network share
    Start by mounting a network share on the Axis device. Add *.* /var/spool/storage/NetworkShare/logs.txt at the bottom of the configuration file. Click Save file once done and restart the device.

    Syslog configuration in FW 5.55 and below

    In order to configure syslog, open the following link in the browser, replace the IP address placeholder (i.e. "ip-address") with the real IP address of the Axis device: http://ip-address/admin-bin/editcgi.cgi?file=/etc/syslog.conf

    Remote syslog server
    Start by adding *.* @ip-address at the bottom of the configuration file and specify the real IP address of the remote syslog server instead. Click Save file once done and restart the Axis device.

     

    SD card
    Start by mounting an SD card in the Axis device. Then add *.* /var/spool/storage/SD_DISK/logs.txt at the bottom of the configuration file. Click Save file once done and restart the Axis device.

     

    Network share
    Start by mounting a network share on the Axis device. Then add *.* /var/spool/storage/NetworkShare/logs.txt at the bottom of the configuration file. Click Save file once done and restart the Axis device.

    About syslog server support

    Axis devices are compliant with the syslog standard that is based on RFC 3164 and the newer RFC 5424, so the transmission of syslogs to a server should work out-of-the-box when configured correctly. Axis devices are tested regularly with different syslog servers such as syslog-ng, rsyslog as well as PRTG Paessler, Nagios, QNAP and Synology.

    Below is a sample image of an Axis device sending log messages to a Nagios syslog server.

     

    Contact
    Contact Axis Technical Services for further assistance and additional requests: https://www.axis.com/support

    MQTT

    MQTT is a machine-to-machine (M2M)/Internet of things (IoT) connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport and is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium.

    MQTT is quickly becoming the standard communication protocol for implementing IoT solutions due to its lightweight and bandwidth-efficient characteristics. You can read more about benefits and usecases in the whitepaper Device integration with MQTT or keep on reading to learn more about configuring MQTT, starting with the most important components.

    Client
    Any publisher or subscriber that connects to a centralized server/broker over a network is a client. Both publishers and subscribers are called clients since they connect to a centralized service. Clients can be persistent or transient. Persistent clients maintain a session with the server/ broker while transient clients are not tracked by the server/ broker. Clients often connect to the server/ broker through libraries and SDKs.

    Server/broker
    The server/broker is the software that receives all the messages from the publishing clients and sends them to the subscribing clients. It holds the connection to persistent clients. Since the server/broker can become a bottleneck or result in a single point of failure, it is often clustered for scalability and reliability. It is up to the implementor to decide how to create a scalable server/broker infrastructure. Some of the commercial implementations of MQTT brokers include HiveMQ, Xively, AWS IoT and Loop.

    Topic
    A topic in MQTT is an endpoint information that a client (publisher) can share, and another client (subscriber) can connect to. Topics are simple, hierarchical strings, encoded in UTF-8, delimited by a forward slash. For example, "building1/room1/temperature" and "building1/room1/humidity" are valid topic names.

    Connection
    MQTT can be utilized by clients based on TCP/IP. The standard port exposed by servers/brokers is 1883, which is not a secure port. Servers/brokers that support TLS/SSL typically use port 8883. For secure communication, the clients and the server/broker rely on digital certificates.

     

    Functionality overview

    Axis devices with firmware version 9.80 and above support the MQTT protocol to allow customers and the market to deepen the integration of their business and system applications. In the table you can see the functionality that is currently supported as well as upcoming functionality.

    FunctionalityImplementedFirmware version
    Generic MQTT event publishing

    AXIS OS 9.80.1

    Custom MQTT event publishing

    AXIS OS 10.4.0

    Custom MQTT event subscription

    10.6
    (Available in new web interface in 10.7)

    MQTT ACAP API support

    TBD

    TBD

    MQTT web interface support

    AXIS OS 10.1

    MQTT over TCP

    AXIS OS 9.80.1

    MQTT over SSL

    AXIS OS 9.80.1

    MQTT over WebSocket

    AXIS OS 9.80.1

    MQTT over WebSocket (SSL)

    AXIS OS 9.80.1

    MQTT VAPIX API

    AXIS OS 9.80.1

    MQTT ALPN support

    AXIS OS 10.9.0

    In the following sections you can read more about configuring a device via the web interface.

     

    Server

    These examples show you how to configure an Axis device to connect to an MQTT server/broker in the web interface. To connect, the user must specify the server’s/broker’s IP address or hostname, the transport protocol and port, as well as credentials (i.e. username and password). The MQTT server/broker connection configurations can be found under Settings > System > MQTT in the web interface.

    Example configuration: MQTT over TCP

     

    Example configuration: MQTT over SSL*

     

    *For the MQTT over SSL connection to be successful the CA and client certificate must be available under Settings > System > Security so that they can be selected in the MQTT configuration.

    Policies

    The connection policies help the user define general MQTT connection behavior of the Axis device towards the MQTT server/broker it connects to. Below you will find a more detailed description of the individual settings of the policies.

    • Client id: nice/nick name that is used by the Axis device to identify itself towards the MQTT server/broker.

    • Keep alive interval: defines the maximum time in seconds that can pass without communication between the Axis device and the MQTT server/broker. The Axis device will send a keep alive message within the defined interval to ensure connection. Note that this will affect the last will testament settings.

    • Timeout: defines the maximum time in seconds for a connection to complete successfully. If the connection attempt exceeds the defined value, the connection will not be accomplished.

    • Reconnect automatically: when enabled, the Axis device will try to reconnect to the MQTT server/broker upon unintentional connection loss.

    • Clean session: controls the client state persistency on the broker side and defines how a connecting client should be treated upon connection. When enabled, no state is kept on the broker. When disabled, the MQTT broker will keep the subscriptions alive and queue QoS 1/2 messages for delivery after a reconnect. This field has no impact on publishing only clients.

     

    MQTT QoS settings

    Each distinct message - i.e. the connect message, the last will testament message and the individual event filtering/topics - allows for dedicated QoS settings to be configured. Below the general QoS behavior and the level of service upon message delivery is described.

    Level 0 is the lowest service level and provides no guarantee of message delivery.

     

    Level 1 guarantees message delivery at least once to the broker with the possibility of receiving the same message multiple times before acknowledgement.

     

    Level 2 is the highest service level providing a four-way handshake to ensure that each message is delivered exactly once to the broker.

    Axis topic expressions

    In order to find out which topics are supported by an Axis device, the following API calls in VAPIX or ONVIF can be made. It is possible to run the below commands within the SSH console from the camera, but it is recommended to use a tool like CURL or POSTMAN that would not require SSH access to the device enabled.

    If you wish to use SSH to issue the requests directly, enable SSH in Plain config > Network > SSH and login directly via SSH to the AXIS device.

     

    VAPIX interface
    Make a GetEventInstances request to VAPIX web services as in the example below, but replace the username, password and IP address with the actual configured settings:

    curl --noproxy "*" --user <username>:<password> --digest --request POST 
    'http://<device-address>/vapix/services' \
    --header 'Content-Type: application/soap+xml;
    action=http://www.axis.com/vapix/ws/event1/GetEventInstances; Charset=UTF-8' \
    --data-raw '<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <SOAP-ENV:Body>
    <m:GetEventInstances xmlns:m="http://www.axis.com/vapix/ws/event1"/>
    </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>'

     

    ONVIF interface
    Make a GetEventProperties request to ONVIF event services as in the example below, but replace the username, password and IP address with the actual configured settings:

    curl --noproxy "*" --user <username>:<password> --digest --request POST
    'http://<device-address>/onvif/services' \
    --header 'Content-Type: application/xml' \
    --data-raw '<?xml version="1.0" encoding="UTF-8"?>
    <SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing"
    xmlns:tet="http://www.onvif.org/ver10/events/wsdl">
    <SOAP-ENV:Header>
    <wsa:Action>
    http://www.onvif.org/ver10/events/wsdl/EventPortType/GetEventPropertiesRequest
    </wsa:Action>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
    <tet:GetEventProperties>
    </tet:GetEventProperties>
    </SOAP-ENV:Body>
    </SOAP-ENV:Envlope>'

     

    Output examples

    onvif:Device/axis:Status/SystemReady
    onvif:Device/axis:IO//.
    onvif:RuleEngine/MotionRegionDetector/Motion
    axis:CameraApplicationPlatform/VMD/Camera1ProfileANY

     

    Last will testament

    The last will testament settings define the behavior of the Axis device towards the MQTT server/broker after ungraceful disconnection, i.e. without the Axis device sending out a disconnect message. This could happen due to bad network connection, power disconnect, etc.

    When the last will testament is enabled, the MQTT server/broker will announce the defined message in case the Axis device disconnects ungracefully. Below you will find a more detailed description of the individual settings of the last will testament and an example of a customized last will testament message.

    • Use default: use predefined default settings.

    • Topic: a customized topic that will be used by the MQTT broker for disconnection announcements, i.e. to announce to subscribed MQTT clients that the Axis device has disconnected ungracefully.

    • Message: a customized message to be used by the MQTT broker for disconnection announcements. See below example.

    • Keep: also known as retain. Defines if the broker should retain the last will testament message in the broker’s cache so that new subscribers will receive the message directly after subscribing.

    • QoS: defines the level of service upon message delivery. Go to MQTT QoS settings for more information.

     

    In the example below we have configured a customized last will testament (LWT) announcing the message “Axis device LWT message” in case the device disconnects ungracefully.

     

    Connect message

    The connect message can be used to let the Axis device announce its connection state to the MQTT broker and other subscribed MQTT clients. Below you will find a more detailed description of the individual settings of the connect message.

     

    • Use default: use predefined default settings.

    • Topic: a customized topic to be used for announcements upon connection to an MQTT broker.

    • Message: a customized message to be used for announcements upon connection to an MQTT broker.

    • Keep: also known as retain. Defines if the broker should retain the connection announcement message in the brokers cache so that new subscribers will get this message directly after subscribing.

    • QoS: defines the level of service upon message delivery. Go to MQTT QoS settings for more information

     

    Configuration example with a default connect message

    Configuration example with a customized connect message

    Generic MQTT event publishing

    After connecting to an MQTT broker, the user must specify event and event filtering related configurations, which can be found under Settings > System > Events > MQTT events.

    The below MQTT configuration shows a typical setup where the Axis device will be configured to send specific events to the MQTT broker, in this example by using manual trigger and virtual input.

    Note that the examples in this section are illustrated using an Eclipse Mosquitto broker and an MQTT client such as MQTT Explorer, which has a graphical user interface.

     

    Note that if no event is added, the Axis device will not send any events to the MQTT broker. Furthermore, it is only possible to select virtual input as an event topic. The virtual input trigger usually consists of 32–64 virtual inputs, and if virtual input is selected as an event topic, all available virtual inputs are considered.

    • Keep: also known as retain. Defines if the broker should retain the last state of this message in the brokers cache so that new MQTT subscribers will get the actual state of the event directly after subscription. This setting affects stateful and stateless events of an Axis device. Go to the Event and action services section in the VAPIX library for information on if particular events are stateful or stateless.

      • None: all events are sent as non-retained, regardless if they are stateful or stateless events.

      • Property: only stateful events are sent as non-retained, regardless if they are stateful or stateless events.

      • All: all stateful and stateless events are sent as retained messages.

    • QoS: defines the level of service upon message delivery. Please refer to MQTT QoS settings for more information.

    To exemplify we have configured the manual trigger as an event to be published to the MQTT broker. The manual trigger is a stateful event, meaning that the manual trigger at all times is in either one of two states; 0 or 1. In the two configurations below we compare two possible scenarios.

    1. We do not want the broker to keep the last known event state of the manual trigger to be available for newly subscribed MQTT clients.

    2. We do want the broker to keep the last known event state of the manual trigger to be available for newly subscribed MQTT clients.

    Scenario 1

    Scenario 2

     

    Let’s assume that the manual trigger was triggered, and that we have been connected to a broker in order to subscribe to it. As you can see below, we would see the actual MQTT message because we were connected and subscribed to the broker at the same time the manual trigger triggered.

    In case we would not have been connected to the broker with our MQTT client and would have connected at a later point in time, we would still see the last state of the manual trigger event if we had configured the event as “Retain=Property”, as can be seen below:

    If we had configured the manual trigger event with “Retain=Off”, we would not see the last message of the manual trigger and would only receive newly triggered events after we had been connected to the broker in question. Reasonably, no events would be listed:

    After successful configuration we can see that the Axis device is publishing events for the manual trigger (=VirtualPort) and the 64 virtual inputs.

    By expanding the tree structure further, we can see the status of each individual virtual input, identified by the port argument.

     

    Include condition name
    Enable include condition name to include the entire event topic name tree instead of just the raw event itself.

    Enabled

    Disabled

     

    Include condition namespaces
    Enable include condition namespaces if the ONVIF topic namespaces should be included.

    Enabled

    Disabled

     

    Include serial number in payload
    Enable include serial number in payload to include the serial number of the Axis device in the MQTT payload message. This could be used as additional information to identify the sending device.

    Enabled

    Disabled

    Custom MQTT event publishing

    In addition to the generic MQTT events that come with predefined topics and payloads, the Publish MQTT action rule can be triggered by any of the available device events and send a message with a custom topic and payload.

    In the below example the Axis device is publishing a message to the topic "P1375/ManualTrigger/Custom/Topics/" carrying the payload "Manual Trigger is activated". The topic can include up to 1024 characters and the payload’s limit is set to 8192 characters.

     

    This video illustrates how the action rule is set up:

     

    Custom MQTT event subscription

    Custom MQTT event subscription is available from AXIS OS 10.7 and onwards and makes it possible for the Axis device to subscribe to a topic when connecting to the MQTT broker. Once subscribed, the Axis device will listen to new incoming messages and will be able to act on it, e.g. by configuration of an action rule in the built-in event system.

    See how it’s configured in this video:

    Eclipse Mosquitto

    In this section you can read about the configuration steps required to connect an Axis device to an Eclipse Mosquitto MQTT broker in order to publish topics.

    Important

    The below steps illustrate basic integration and use-cases within a test lab environment. Axis strongly recommends following the provider’s guidelines for an integration that maximizes the handling of certificates, tokens, user-credentials and overall cybersecurity in a production environment.

     

    Step 1: Eclipse Mosquitto configuration
    Please see this guide for a common Mosquitto MQTT broker configuration based on Linux Ubuntu 18.04. The steps below cover the configuration in TCP and SSL/TLS mode only.

     

    Step 2: Axis device configuration

    Server configuration

    MQTT over TCP

    MQTT over SSL

    Policies configuration

    Microsoft Azure (SAS token)

    In this section you can read about the configuration steps required to connect an Axis device to an MQTT broker in order to publish topics. For further reading, go to https://docs.microsoft.com/en-us/azure/iot-hub/quickstart-send-telemetry-cli and https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-mqtt-support.

    Important

    The below steps illustrate basic integration and use-cases within a test lab environment. Axis strongly recommends following the provider’s guidelines for an integration that maximizes the handling of certificates, tokens, user-credentials and overall cybersecurity in a production environment.

     

    Step 1: Create an IoT device
    In order to get started, an IoT device must be created in Microsoft Azure. Follow the steps below in order to proceed.

     

     

     

    After creating a device, obtain the hostname of your Microsoft Azure entity. This can be looked up in the hub overview.

     

    Step 2: Generate SAS token
    The SAS token can be generated using the Cloud Shell console in Microsoft Azure. In the following example, the password is generated and valid for 3600 seconds. This SAS token is used later on to connect the Axis device to the Microsoft Azure MQTT broker.

    Cloud Shell command: az iot hub generate-sas-token -d AXISMQTT -n R2D2-IoT-Hub --du 3600

     

    Step 3: Axis device configuration
    With the information provided in Step 1 and Step 2 we can now connect the Axis device to the Microsoft Azure MQTT broker.

    Note that the custom condition prefix, disabling the condition name and the custom basepath is mandatory for the Axis device to publish messages.

    Step 4: Listen to MQTT events
    Now we’re ready to test our setup. Use the following command in Cloud Shell to listen to incoming MQTT events from the Axis device. The simplest way of testing is to use manual trigger in the Axis device.

    Cloud Shell Command: az iot hub monitor-events --hub-name R2D2-IoT-Hub

     

    Microsoft Azure (certificate authentication)

    In this section you can read about the configuration steps required to connect an Axis device to an MQTT broker in order to publish topics. For further reading, go to https://docs.microsoft.com/en-us/azure/iot-hub/quickstart-send-telemetry-cli and https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-mqtt-support.

    Important

    The below steps illustrate basic integration and use-cases within a test lab environment. Axis strongly recommends following the provider’s guidelines for an integration that maximizes the handling of certificates, tokens, user-credentials and overall cybersecurity in a production environment.

     

    Step 1: Certificate authority configuration
    In order to configure certificate-based authentication in Microsoft Azure, a trusted root certificate is required, which is used to sign and verify clients and their certificates in return. The below process describes how to add a root certificate in Azure and how to apply the proof-of-possession method in order to prove to Azure that this root certificate should be verified and trusted.

    Let’s create a root certificate of our choice by running the following commands:
    openssl genrsa -des3 -out R2D2AzureRootCA.key 2048
    openssl req -new -x509 -days 36500 -key R2D2AzureRootCA.key -out R2D2AzureRootCA.pem

     

    Download the certificate that was created in the PowerShell and upload the certificate in the certificate store as seen below.

     

     

    As you might have noticed, the status of the new root certificate is “Unverified”, meaning that we need to prove to Azure that the uploading user is in real possession of the certificate and its authority. Therefore, Azure requires us to sign a new certificate from the root certificate that was uploaded, which includes the below verification code in the CN/Subject of the new certificate.

     

    With the help of the below commands, a new certificate is created. Observe that the verification code must be used in the CN/Subject of the new certificate. Note that a challenge password during the certificate creation is not needed.

    openssl genrsa -out R2D2AzureRootCAProof.key 2048
    openssl req -new -out R2D2AzureRootCAProof.csr -key R2D2AzureRootCAProof.key
    openssl x509 -req -in R2D2AzureRootCAProof.csr -CA R2D2AzureRootCA.pem -CAkey R2D2AzureRootCA.key -CAcreateserial -out R2D2AzureRootCAProof.pem -days 36500

     

    After the certificate has been successfully created, download it in order to upload it into the certification store to confirm the proof-of-possession. Upon successful verification, the certificate status should change to “Verified”.

     

     

    Step 2: Create an IoT device
    In order to send MQTT messages from an Axis device to Microsoft Azure using certificate-based authentication, a new IoT device needs to be created with the appropriate authentication method.

     

     

    The Axis device must authenticate using a new client certificate that needs to be generated and signed from the root certificate that we uploaded in step 1. The below commands or similar are needed to do so:

    openssl genrsa -out R2D2AzureACCC8E68CB0A.key 2048
    openssl req -new -out R2D2AzureACCC8E68CB0A.csr -key R2D2AzureACCC8E68CB0A.key
    openssl x509 -req -in R2D2AzureACCC8E68CB0A.csr -CA R2D2AzureRootCA.pem -CAkey R2D2AzureRootCA.key -CAcreateserial -out R2D2AzureACCC8E68CB0A.pem -days 36500

    Observe that the device ID must match the CN/Subject of the client certificate exactly, or the authentication will fail. Note that a challenge password during certificate creation is not needed.

     

    Step 3: Axis device configuration
    In the last step, the previously created client certificate needs to be uploaded onto the Axis device, and be selected in the MQTT broker configuration. The rest of the configuration is well documented in the Microsoft Azure guidelines.

     

     

    Step 4: Listen to MQTT events
    Now we're ready to test our setup. Use the following command in the Cloud Shell to listen to incoming MQTT events from the Axis device. The simplest way of testing is to use the manual trigger in the Axis device.

    Cloud Shell command: az iot hub monitor-events --hub-name R2D2-IoT-Hub

    Go to Microsoft Azure (SAS token) and see the example in Step 4 for more information.

     

    Amazon Web Services (AWS)

    In this section you can read about the configuration steps required to connect an Axis device to an Amazon Web Services (AWS) MQTT broker in order to publish topics. For further reading, go to https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-sdk.

    Important

    The below steps illustrate basic integration and use-cases within a test lab environment. Axis strongly recommends following the provider’s guidelines for an integration that maximizes the handling of certificates, tokens, user-credentials and overall cybersecurity in a production environment.

     

    Step 1: Create a thing policy
    Before we start creating a thing device in AWS, we want to configure the thing policy first. The thing policy is basically access and connection rights given to a device upon creation. The below example illustrates a policy that lets the Axis device connect and publish messages.

     

    Step 2: Create IoT device (thing)
    After creating the thing policy, it is time to create the actual device. AWS IoT Core is providing access via certificate-based authority rather than credential-based authentication. So, a certificate and a private key are generated during the process of creating a thing as well.

     

     

     

    Observe that the certificate and private key must be uploaded to the Axis device. If the Axis device should validate the AWS MQTT broker as well, the Amazon Root CA must be uploaded on the Axis device too. Furthermore, make sure that the certificates are activated by toggling the button as illustrated in the screenshot.

     

    Here we attached the policy that we created in Step 1 to the thing device we are creating. After doing this, the thing is ready and it is time to configure the Axis device.

     

    Step 3: Axis device configuration
    With the information provided in step 1 and step 2 we can now connect the Axis device to the AWS MQTT broker.

    Note that AWS IoT Core enforces a hard limit on the length of the topic expression so we simply started with only including the condition name to keep the topic short.

     

    Step 4: Listen to MQTT events
    Now we are ready to test our setup. With the help of Amazon CloudWatch we can verify if the Axis device can send MQTT messages to the AWS cloud successfully.

    First, make sure you have logging enabled. This will then result in the AWS cloud logging connection attempts.

     

    By using the Amazon CloudWatch service, the AWSIoTlogs log group will reveal connection attempts and whether or not MQTT actions such as publishing or subscribing were successful.

    IBM Watson

    In this section you can read about the configuration steps required to connect an Axis device to an IBM Watson MQTT broker in order to publish topics. For further reading, go to https://developer.ibm.com/articles/iot-mqtt-why-good-for-iot/.

    Important

    The below steps illustrate basic integration and use-cases within a test lab environment. Axis strongly recommends following the provider’s guidelines for an integration that maximizes the handling of certificates, tokens, user-credentials and overall cybersecurity in a production environment.

     

    Step 1: Create IoT device
    Follow the steps below to create an IoT device.

     

     

     

     

     

     

    Step 2: Axis device configuration
    With the information and settings provided by the IoT device creation in Step 1, we can now connect the Axis device to the IBM MQTT broker. Again, below is a typical example.

    Note that the custom condition prefix in the MQTT events and the disabling of the condition name are mandatory for the Axis device to publish messages.

     

    Step 3: Listen to MQTT events
    IBM Watson Cloud does not possess a built-in MQTT client for subscribing to events in the cloud. We therefore use MQTT Explorer. In order for MQTT Explorer to connect to the IBM MQTT broker, it is necessary to first generate API keys to allow access. This is described in the following images.

     

     

     

     

    With the newly generated API keys we can connect to the IBM MQTT broker. See example settings below.

     

    The below subscription topic is mandatory to configure, otherwise no events will be seen. The MQTT client ID must consist of your IBM cloud entity followed by a customizable string (e.g. “mqtt”) that a user can define.

     

    Upon successful connection, events should be sent from the Axis device. The simplest way of testing this is to use the manual trigger in the Axis device.

    Google Cloud Platform (GCP)

    In this section you can read about the configuration steps required to connect an Axis device to a Google Cloud Platform (GCP) MQTT broker in order to publish topics. For further reading, go to https://cloud.google.com/iot/docs/how-tos/gateways/mqtt-bridge and https://cloud.google.com/iot/docs/how-tos/mqtt-bridge.

    Important

    The below steps illustrate basic integration and use-cases within a test lab environment. Axis strongly recommends following the provider’s guidelines for an integration that maximizes the handling of certificates, tokens, user-credentials and overall cybersecurity in a production environment.

     

    Step 1: Pub/Sub configuration
    In the first step, we will use Google’s Pub/Sub hub. Pub/Sub is used to create topics so that a device can publish its MQTT events to GCP. In addition, one can also subscribe directly to the topics.

     

     

     

     

     

     

    Step 2: GCP MQTT bridge configuration
    In this step of the configuration we add a registry point so we can add devices that later on can publish topics. We will use the IoT Core tab for the configuration.

     

     

     

     

     

    Step 3: GCP device configuration
    After creating the registry point, we can now bind devices to it. The devices will then be able to publish topics.

     

     

     

    In order to authenticate a device in GCP, a JWT token needs to be used as password for each device, and GCP also needs to bind the public key to decrypt the traffic and authenticate the device correctly.

    About the JWT token
    The JWT token is generated at a later stage using the public and private key.

    About the device public key
    In order to create a device in GCP, a public key is needed to authenticate and decrypt traffic from the device. For a test environment, public and private keypairs can be generated in the GCP console directly.

    openssl genpkey -algorithm RSA -out rsa_private.pem -pkeyopt rsa_keygen_bits:2048
    openssl rsa -in rsa_private.pem -pubout -out rsa_public.pem

    Read out the public and private key from the GCP console editor. Use the public key directly to create the device. The public key and the private key is also used later on to sign the JWT token.

     

     

     

    Step 4: JWT token claim
    Google Cloud Platform uses JWT token-based authentication. To exemplify, we have used an online tool to generate the JWT token. Note that this is not recommended in a production environment.

    The JWT token itself needs the aud (audience), iat (issued-at) and exp (expiration) fields to be available in the JWT token. The iat and exp fields are defined as unix timestamps. These can be used e.g. using this tool. The aud field is defined by the project ID in Google Cloud Platform. When you are done with aud, iat and exp, paste the public and private keypair into the JWT claim in order to export the JWT token as a password for the Axis device.

    Important: Google Cloud Platform will reject any authentication attempts with a JWT token that has a longer duration than 24 hours in total.

     

     

     

    Step 5: Axis device configuration
    Below is the actual Axis device configuration for MQTT. Observe the settings required for a successful connection. The username is ignored/not respected in GCP. The client ID uses the following naming convention format, and the parts marked in bold are individual to your configuration illustrated previously:

    projects/r2d2-iot-sandbox/locations/europe-west1/registries/axis_device_registery/devices/ACCC8E68CB0A

    The password is the JWT token that has been generated previously. The custom condition prefix for event publication uses the following convention and depends on your previously made configuration:

    /devices/ACCC8E68CB0A/events

    Step 6: listen to MQTT events
    Google Cloud Platform has its own tools to listen to incoming MQTT events from devices either using the Pub/Sub hub or the GCP console directly by using the command below. Again, the part marked in bold is depending on your previous configuration.

    gcloud pubsub subscriptions pull device_events

     

     

     

    Contact
    Contact Axis Technical Services for further assistance and additional requests: https://www.axis.com/support

    O3C (one-click cloud connection)

    O3C (one-click cloud connection) is a protocol that allows an Axis device to connect via secure connection to a cloud video management system, such as Genetec Stratocast. In order to connect an Axis device, the so called OAK (owner authentication key) is needed. See instructions for how to look up the OAK below.

    With each Axis device, you receive a piece of paper with the OAK printed on it. As mentioned, you need the OAK to verify ownership when you register the device with an O3C-based service. Please keep this document in a safe place – it’s a certificate that should not be discarded or disclosed to third parties. If you have lost your OAK, you can retrieve it by logging in to the device as an admin user. Follow one of the paths below, depending on the firmware version of your device.

    Note

    This requires that the device runs AXIS OS 5.51.7, 6.50.5.2, 8.40.4, 9.80.2, 10.0.0 or higher. Please upgrade the firmware if your device is running a lower firmware version. Axis cannot assist in retrieving the OAK for you. For the external retrieval, an outgoing HTTPS (TCP port 443) connection to "oakcgi.o3c.axis.com" needs to be available.

     

    AXIS OS 5.51 & LTS 216 (AXIS OS 6.50)
    Go to Setup > Options > Support > System Overview.

     

    LTS 2018 (AXIS OS 8.40) & LTS 2020 (AXIS OS 9.80)
    Go to System > AVHS and click on Get key.

     

    AXIS OS 10.0 or higher
    Go to System > O3C and click on Get key.

     

    AXIS OS 10.9 or higher
    Go to System > Network and click on Get key. Note that this applies to products with support for the new web interface introduced in AXIS OS 10.9. For products that don’t support the new web interface yet, please follow the above instructions for AXIS OS 10.0.

    SFTP (SSH File Transfer Protocol)

    Axis devices are capable of sending images and videos using the SFTP (SSH File Transfer Protocol) protocol to a remote server. SFTP is using the secure and encrypted SSH protocol to transfer data via FTP. This is not to be mistaken with FTPS (FTP over SSL), which is another secure method of transferring data securely, however not supported by Axis devices.

    3rd party SFTP server

    Depending on the environment and selected 3rd party SFTP server, the configuration may differ. In this tutorial we are going to have a look at the commonly used OpenSSH server for Linux operating systems.

    Important

    The below steps illustrate basic integration and use cases within a test lab environment. Axis strongly recommends following the provider's guidelines for an integration that maximizes the handling of certificates, tokens, user-credentials and overall cybersecurity in a production environment.

    OpenSSH server configuration
    The SFTP implementation of Axis devices is based on the open-source software component Curl. Out of the many authentication methods that Curl supports, Axis devices currently only support the so called CURLSSH_AUTH_PASSWORD. Therefore you need to make sure that the SFTP server being used supports this method as well.

    This guide can be used as a reference to install OpenSSH, which then allows for the Axis device to transfer data using SFTP. Once the OpenSSH server is installed, it should be possible to test that the connections work, e.g. by using Putty (SSH client). Enter the server IP address as well as the login credentials from your Linux operating system to connect.

     

     

    SFTP uses public key authentication in order to allow for secure data transfer, which is why it's recommended to create dedicated key pairs for this purpose. In AXIS OS, SSH-2 with RSA, DSA, ECDSA and ED25519 host keys are supported. By using the following commands, private/public host key pairs can be created in the OpenSSH server. The private key is exclusively used by the OpenSSH server while the public key will be used by the Axis device in form of a hashed MD5 or SHA-256 key that is generated from the public key.

    CommandDescription
    sudo ssh-keygen -t dsaCreates a private/public DSA host key pair
    sudo ssh-keygen -t rsaCreates a private/public RSA host key pair
    sudo ssh-keygen -t ed25519Creates a private/public ed25519 host key pair
    sudo ssh-keygen -t ecdsaCreates a private/public ecdsa host key pair

     

     

    Following the creation of the private/public key pair, we can use the following commands to generate the MD5 and/or SHA-256 hash keys that need to be used in the SFTP recipient configuration in the Axis device (see Axis device configuration). Note that it's possible to create both an MD5 and/or SHA-256 hash key from either of the generated public host keys above. In the below example, we generate an MD5 as well as a SHA-256 hash key from the RSA public host key.

    CommandExample outputDescription
    sudo ssh-keygen -l -E md5 -f ssh_host_rsa_key.pubb800c8958b8679a7bd66c13669051466Generates an MD5 hash from public key
    sudo ssh-keygen -l -E sha256 -f ssh_host_rsa_key.pubgUYVTq8MVXMaf/TPoJS+/5M9iPt+tGDciHPIp0HvUuAGenerates a SHA-256 hash from public key

     

    While the Axis device supports both MD5 and SHA-256 hash keys, it's recommended to use SHA-256 due to stronger security over MD5.

    Axis device configuration

    The Axis device supports SFTP servers using SSH-2 with RSA, DSA, ECDSA and ED25519 host key types. RSA is the preferred method during negotiation followed by ECDSA, ED25519 and DSA. Please make sure to enter the right MD5 or SHA256 host key that is used by your SFTP server. Based on the public/private key we created previously and the MD5 and SHA-256 hash keys we generated from the public host key (see 3rd party SFTP server), the SFTP recipient in the Axis device would look as below:

     

     

    After the SFTP recipient has been created, action rules for image and/or video clip transfer can be created.

     

    Web interface

    Browser support

    AXIS OS 7.10 and higher
    Video products with firmware 7.10 or higher include the new web interface, which comes with an overall improved and simplified graphical user interface and focuses on camera installation, configuration, and troubleshooting. The web interface is tested and optimized for Chrome™ and Firefox® browsers. It is platform-independent and works with Windows® (versions 7 through 10) as well as Linux® and OS X®. If you use other browsers, you could experience limitations in functionality and support. You can find more information about the latest firmware of your Axis product here.

    ChromeTM

    Firefox®

    EdgeTM

    Safari®

    Windows®

    recommended

    recommended

    macOS®

    recommended

    recommended

    Linux®

    recommended

    recommended

    Other operating systems

    ✓*

    *To use AXIS OS web interface with iOS 15 or iPadOS 15, go to Settings > Safari > Advanced > Experimental Features and disable NSURLSession Websocket.

    • Highlights
    • Recommended browser: Latest Chrome and Firefox

    • Supported browser: Latest Chrome, Firefox, Edge and Safari

    • Platform-independent with latest Linux, OS X and Windows 7 through Windows 10

    • Support for tablet and mobile devices

    • 12 pre-installed languages and automatic language detection

    • Known limitations
    • Edge: 1-second video delay when streaming H.264

    • Safari, Chrome, Firefox: No support for H.264 video streaming in Apple mobile (iOS) devices

    • Audio: No support for sending audio to the camera through the browser (i.e. through a computer microphone)

    • Video: Some browser plugins are known to cause problems with live streaming. Try uninstalling plugins if the video does not play as it should.

    • Video: H.265 video streaming is currently not supported in any browser

    Video streaming
    AXIS Media Control is no longer required for video streaming H.264 or RTSP. Displaying H.264 and RTSP video streams in the web interface (e.g. live view or when setting up analytics) requires that the browser can connect over WebSockets. Support for RTSP video streams over WebSockets requires an updated browser and that the network and proxy settings are configured to allow WebSockets.

    The viewing experience depends on the performance of the computer, the browser, and its encoding capabilities. If a video stream is lagging, the web interface either notifies the user or restarts the video stream automatically in case it lags a lot. If the user experiences continuous lagging, they should adapt to the computer’s performance by lowering the resolution of the video stream stepwise. When viewing video streams in higher resolutions than 1080 pixels, they should use a computer with a powerful CPU and graphics card.*

    *Tested and verified with the following configuration: Google Chrome™ (latest version) on Windows® 10 or Linux, Intel® Core™ i7-4770 Processor 3.40 Ghz with NVIDIA® GeForce® GTX™ 950 or Intel™ HD Graphics 4600.

    AXIS OS 6.5X or lower
    Video products with firmware version 6.5X or lower are tested and optimized for the latest version of Internet Explorer*, Windows, and AXIS Media Control (AMC). Although you can use other browsers, versions and operating systems, you might experience limitations in functionality and support. You can find more information about the latest firmware of your Axis product here.

    • Highlights
    • Recommended browser: Internet Explorer* with AXIS Media Control

    • Recommended for Windows operating system

    • Known limitations
    • QuickTime player introduces a 3-second video delay when streaming

    • Java applet-based clients only support one-way audio, and the audio quality, as well as the frame rate, might be reduced

    • When using video products with AXIS OS 5.50 or lower and IE10, compatibility mode is recommended

    Video streaming
    AXIS Media Control and Internet Explorer* is required for video streaming H.264 over HTTP/RTSP/RTP. MJPEG video streaming is supported by Chrome, Firefox and Safari.

    *Internet Explorer mode in Edge
    Internet Explorer was previously used to view H.264 using AXIS Media Control and to configure the legacy embedded Video Motion Detection. Since Internet Explorer is outdated and unsupported, Microsoft Edge can be used for this purpose instead if set to Internet Explorer mode.

    To set Internet Explorer mode in Edge, go to Settings > Default browser and set Allow sites to be reloaded in Internet Explorer mode to "Allow".
    Proceed by clicking "Add" next to Internet Explorer mode pages, and enter the IP address of the Axis device.

    When done, Edge will work the same way as Internet Explorer for that particular device.

    Configuration tips

    How to use HTTP POST notifications in action rules

    How to publish an MQTT message with an event rule action