AXIS OS Portal

AXIS OS

AXIS OS is our operating system for edge devices. It’s 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.

The LTS tracks are created every 16-24 months and are supported and maintained for about 5 years. The active track releases a new version every 2-3 months and only the latest version is supported.

 

Upcoming & current releases

This section gives an overview of the latest and upcoming firmware releases on the active and LTS tracks. To get the latest firmware updates to your RSS feed, subscribe to the product firmware feed. For downloads, please visit the download page.

Upcoming releases

VersionTrackPreliminary release datePlanned features and updates
10.7ActiveSeptember 2021
  • Apache version 2.4.48

9.80.3.5LTS 2020August/September 2021
  • Apache version 2.4.48

8.40.4.3LTS 2018September/October 2021
  • Apache version 2.4.48

6.50.5.5LTS 2016October/November 2021
  • Apache version 2.4.48

Go to Developer information to find out more.

Highlights in AXIS OS 10.6

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

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

Disabling Apache/OpenSSL version in HTTP(S) responses
A parameter for disabling Apache and OpenSSL version in HTTP(S) responses has been added in Plain Config > System.

Day/night information in overlays and server report
It is now possible to add day/night information in the overlay text by using #dn. This will show both the current value and the threshold value for the day/night change, and is also available in the server report.

ONVIF profile M - preliminary support
Preliminary support for ONVIF profile M has been added to selected products. Go to ONVIF profile M to read more.

AXIS Object Analytics classifications
Added object classifications in metadata stream for forensic search in Milestone when AXIS Object Analytics is running.

LTS 2020 - 9.80.3.3

Support phase: 2020 – 2025-12-31
Release date: 2021-06-28 (to be rolled out within three weeks of release date)

This release includes:

OpenSSH update
OpenSSH has been updated to version 8.6p to increase overall minimum cybersecurity level.

LTS 2018 - 8.40.4.2

Support phase: 2018 – 2023-12-31
Release date: 2021-04-19 (to be rolled out within 3 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 2016 - 6.50.5.4

Support phase: 2016 – 2021-12-31
Release date: 2021-05-10 (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.

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 18-24 months.

Upgrade paths

It is 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.

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.

 

Read more about Axis firmware in the Axis firmware management whitepaper.

Release archive

Active 2021

Highlights in AXIS OS 10.5

Release date: 2021-04-26 (to be rolled out within three weeks of release date)
See the release notes for AXIS OS 10.5.0 for more details.

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

Polygon privacy masks
Support for polygon privacy masks has been added to AXIS M3064-V, AXIS M3065-V, AXIS M3066-V, AXIS M3075-V, AXIS M3205-LVE and AXIS M3206-LVE.

Highlights in AXIS OS 10.4

Release date: 2021-03-08 (to be rolled out within three weeks of release date)
New products in this release: AXIS A8207-VE, AXIS A8207-VE Mk II, AXIS M3057-PLVE Mk II, AXIS M3077-PLVE, AXIS P3925-LRE, AXIS Q6075-SE
See the release notes for AXIS OS 10.4.0 for more details.

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

New action: “Publish MQTT”
Added support for new action "Publish MQTT", available in the web interface via Events > Device events > Rules setup. This new action makes it possible to publish MQTT messages with custom topic and payload.

Highlights in AXIS OS 10.3.0

Release date: 2021-01-19 (to be rolled out within three weeks of release date)
See AXIS OS 10.3.0 for more details.

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

Wear level for SD cards
It is now possible to set a wear level for the SD card which the event system can trigger on.

AXIS Object Analytics
AXIS Object Analytics (Deep Learning Processing Unit) has been externally launched and is available for compatible cameras. For more information, go to AXIS Object Analytics on axis.com.

Trigger data removed
Trigger data functionality has been removed. Support for trigger data will continue on the 9.80 LTS track.

Audio gain level behavior reverted
An issue has been corrected that caused the audio transfer over HTTPS to not work properly. The audio gain level behavior has now been reverted to the state it was known in AXIS OS releases up to AXIS OS 10.0.2. This means it is mandatory to upgrade to AXIS OS 10.3 when experiencing audio-related issues on Axis devices running on AXIS OS 10.1 and 10.2. Upon release of AXIS OS 10.3, AXIS OS 10.1 and 10.2 will be made unavailable for download from www.axis.com.

Active 2020

Highlights in AXIS OS 10.2.0

Release date: 2020-11-10 (to be rolled out within three weeks of release date)
See AXIS OS 10.2.0 for more details.

Full camera support for SRTP
All cameras in this release now support SRTP (Secure Real-time Transport Protocol).

Supervised digital audio
Support for supervised digital audio has been added to products with digital audio. Four new events for supervising the digital audio input have been added to the event system in the web interface.

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

AXIS Object Analytics
AXIS Object Analytics (Machine Learning Processing Unit) has been externally launched and is available for compatible cameras. For more information, go to AXIS Object Analytics on axis.com.

Removed support for AXIS Internet Dynamic DNS Service
Support for AXIS Internet Dynamic DNS Service (axiscam.net) has been removed. For more information, see https://www.axis.com/support/technical-notes/broadband-connection.

Removed support for NAT Traversal
Support for NAT Traversal has been removed. It is recommended to use AXIS Secure Remote Access or similar services instead. The following NAT Traversal related VAPIX parameters have been removed:
• Network.UPnP.NATTraversal.Active
• Network.UPnP.NATTraversal.Enabled
• Network.UPnP.NATTraversal.ExternalIPAddress
• Network.UPnP.NATTraversal.MaxPort
• Network.UPnP.NATTraversal.MinPort
• Network.UPnP.NATTraversal.Router

Removed support for VAPIX Record/Play CGI (previously deprecated)
Support for the previously deprecated VAPIX Record/Play CGI that allowed for playback of MJPEG recordings has been removed. It is recommended to use the RTSP protocol instead with support for all formats (H.264, H.265, MJPEG, etc.).

Active 10.1

Release date: 2020-09-23 (to be rolled out within three weeks of release date)
See AXIS OS 10.1.0 for more details.

This release includes:

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

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

MQTT
It is now possible to configure MQTT in the web interface, which can be used for sending camera events.

Remote syslog
Support for remote syslog has been added, which enables Axis devices to send log messages to a remote syslog server. Can be configured in the web interface or via VAPIX. Look at this example on how to use this.

RTSP connection speed
RTSP connection speed has been improved by 30%

HTTP2 support
VAPIX support for HTTP/2 for HTTPS connections has been added.

Factory default when downgrading
It is now mandatory to perform a factory default when downgrading the firmware. See How to downgrade for more information.

Average bitrate (ABR)
Support for average bitrate (ABR) has been added to selected products, see Average bitrate (ABR) for more information.

Automatic gain control for AXIS M3075-V
Automatic gain control has been added for AXIS M3075-V, see Automatic gain control for more information.

AXIS Object Analytics Beta
AXIS Object Analytics Beta has been pre-installed in another few selected products, e.g. AXIS Q1615/-LE Mk III which is compatible with AXIS Object Analytics using deep learning. For more information see https://www.axis-communications.com/aoa.

Other ACAP updates
AXIS License Plate Verifier has been updated to version 1.7.2
AXIS Guard Suite has been updated to version 2.2.7
AXIS Video Motion Detection has been updated to version 4.4.8

Active 10.0

Release date: 2020-06-23 (to be rolled out within three weeks of release date)
See AXIS OS 10.0.0 for more details.

This release includes:

AXIS Object Analytics
AXIS Object Analytics Beta is now pre-installed in a few selected products. For more information see https://www.axis-communications.com/aoa.

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.

On-screen controls added for the enable/disable all privacy masks feature
On-screen controls have been added for the enable/disable all privacy masks feature. The control is disabled per default and must be enabled before use.

ONVIF profile T
ONVIF profile T has been added to ExCam XF Q1785 and F101-A XF Q1785. Go to ONVIF profile T for more information.

LLDP allocation for max-power
LLDP allocation for max-power is available for AXIS M3205-LVE and AXIS M3206-LVE. Go to LLDP max-power allocation for more information.

Active 9.80.1

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 PlainConfig > 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 9.70.1

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

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 whitepaper 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 > PlainConfig > 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

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

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 addded 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 > PlainConfig > 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

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

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)

LTS 2020 - 9.80.3.2

Support phase: 2020 – 2025-12-31
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

Support phase: 2020 – 2025-12-31
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

Support phase: 2020 – 2025-12-31
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.80.2.4)

Support phase: 2020 – 2025-12-31
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)

Support phase: 2020 – 2025-12-31
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)

Support phase: 2020 – 2025-12-31
Release date: 2020-07-21

This release includes general improvements and security updates.

LTS 2020 (9.80.2)

Support phase: 2020 – 2025-12-31
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)

LTS 2018 (8.40.4.1)

Support phase: 2018 – 2023-12-31
Release date: 2020-11-16 (to be rolled out within 3 weeks of release date)

This release includes:

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

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

RTSP connection speed
RTSP connection speed has been improved by 30%

LTS 2018 (8.40.4)

Support phase: 2018 – 2023-12-31
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)

Support phase: 2018 – 2023-12-31

This release includes general improvements and security updates.

LTS 2018 (8.40.3.2)

Support phase: 2018–2023

This release includes general improvements and security updates.

LTS 2018 (8.40.3.1)

Support phase: 2018–2023

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)

Support phase: 2018–2023

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)

LTS 2016 - 6.50.5.3

Support phase: 2016 – 2021-12-31
Release date: 2020-11-09 (to be rolled out within three weeks of release date)

This release includes:

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

LTS 2016 (6.50.5.2)

Support phase: 2016 – 2021-12-31
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)

Support phase: 2016 – 2021-12-31

This release includes general improvements and security updates.

LTS 2016 (6.50.5)

Support phase: 2016–2021

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)

Support phase: 2016–2021

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)

Support phase: 2016–2021

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)

Support phase: 2016–2021

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 > PlainConfig > 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 > PlainConfig > Network > LLDP POE > LLDP Send Max PoE.

Firmware versionSupported products
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.6 (preliminary support)
  • 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

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.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

Planned AXIS OS releases containing updates and features that can affect your software.

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.6
Scheduled for: June 2021
Main new features:

  • Removing support for stream legacy overlays
    This means that it will no longer be possible to create, remove or manipulate legacy overlays via URL options. The following URL options will be removed, more information is available in VAPIX Library.

    • clock

    • date

    • text

    • textstring

    • textcolor

    • textbackgroundcolor

    • textpos

    • overlayimage

    • overlaypos

  • It will still be possible to use the following values with the “overlays” URL option to filter overlays per stream:

    • "text" – only text overlays are shown

    • "image" – only image overlays are shown

    • "application" – only overlays rendered from ACAP applications are shown

    • "off" – no overlays are shown

  • OpenSSL is upgraded to 1.1.1k

  • Support for license key management for 3.0 ACAP applications built from manifest.json file to be managed over VAPIX

  • Support for 4K resolution for video input for AXIS P7304

  • Support for MQTT subscription, which makes it possible to use incoming MQTT messages as action triggers in the rule engine

  • Support for ONVIF Profile T for AXIS Q1659 and AXIS P3807-PVE

  • Preliminary support for ONVIF Profile M for 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 and AXIS Q6315-LE.

  • Added a parameter to enable/disable Apache & OpenSSL versions in HTTP(S) responses; root.System.HTTPServerTokens=yes

  • Added ability to select which overlay should be used in a stream profile

  • Added ability to show day/night information in the text overlay by using #dn. This shows both the current value and the threshold value for the day/night change

 

AXIS OS 10.5
Scheduled for: April 2021
Main new features:

  • Known issue in 10.5 – this will be corrected in 10.6:
    When an application is not found the applications/control.cgi should respond with "4 Application not found. The specified application package could not be found". Instead it gives "Error: 1".
    VAPIX reference: https://www.axis.com/vapix-library/subjects/t10102231/section/t10036126/display

  • New Mediaclip events: a state event (tnsaxis:Mediaclip/Playing) if mediaclip is playing or not, and a stateless event (tnsaxis:Mediaclip/CurrentlyPlaying) for the file currently playing.

  • RTSP and HTTP stream URL:s now allow for filtering overlays based on overlay type. This is done by setting 'overlays=<all|text|image|application|off>' in the URL (only one value).

  • Added support for polygon privacy masks for AXIS M3064-V, AXIS M3065-V, AXIS M3066-V, AXIS M3075-V, AXIS M3205-LVE and M3206-LVE

  • OpenSSL is upgraded to 1.1.1j

  • Max bitrate is increased to 100 mbit/s (check release notes for supported products)

 

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.

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 (CVE)

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

CVEResult of investigationActions | Details
CVE-2021-32934Not affectedN/A
CVE-2021-31618AffectedAffects firmwares 10.1 - 10.6. Concerned customers can temporarily disable the parameter System.HTTP2.AllowH2 (in Plain config) to mitigate this. Will be patched by upgrading to Apache version 2.4.48 on the active track during Q3.
CVE-2021-30641Not affectedN/A
CVE-2021-26691Not affectedN/A
CVE-2021-26690Not affectedN/A
CVE-2021-25677Not affectedN/A
CVE-2021-23841Not affectedN/A
CVE-2021-23840AffectedThis vulnerability will be patched by upgrading to OpenSSL 1.1.1j on the active track and OpenSSL 1.1.1k on the LTS tracks during Q2.
CVE-2021-23839Not affectedN/A
CVE-2021-22901Not affectedN/A
CVE-2021-22898Not affectedN/A
CVE-2021-22897Not affectedN/A
CVE-2021-22890AffectedMore information to follow
CVE-2021-22876Not affectedN/A
CVE-2021-21727Not affectedN/A
CVE-2021-3450Not affectedN/A
CVE-2021-3449AffectedThis vulnerability will be patched by upgrading to OpenSSL 1.1.1k on the active track and LTS tracks during Q2.
CVE-2020-35452AffectedWill be patched by upgrading to Apache version 2.4.48 on the active track and LTS tracks during Q3.
CVE-2020-27738Not affectedN/A
CVE-2020-27737Not affectedN/A
CVE-2020-27736Not affectedN/A
CVE-2020-27009Not affectedN/A
CVE-2020-25112Not affectedN/A
CVE-2020-25111Not affectedN/A
CVE-2020-25110Not affectedN/A
CVE-2020-25109Not affectedN/A
CVE-2020-25108Not affectedN/A
CVE-2020-25107Not affectedN/A
CVE-2020-25066Not affectedN/A
CVE-2020-24383Not affectedN/A
CVE-2020-24341Not affectedN/A
CVE-2020-24340Not affectedN/A
CVE-2020-24339Not affectedN/A
CVE-2020-24338Not affectedN/A
CVE-2020-24337Not affectedN/A
CVE-2020-24336Not affectedN/A
CVE-2020-24335Not affectedN/A
CVE-2020-24334Not affectedN/A
CVE-2020-17470Not affectedN/A
CVE-2020-17469Not affectedN/A
CVE-2020-17468Not affectedN/A
CVE-2020-17467Not affectedN/A
CVE-2020-17445Not affectedN/A
CVE-2020-17444Not affectedN/A
CVE-2020-17443Not affectedN/A
CVE-2020-17442Not affectedN/A
CVE-2020-17441Not affectedN/A
CVE-2020-17440Not affectedN/A
CVE-2020-17439Not affectedN/A
CVE-2020-17438Not affectedN/A
CVE-2020-17437Not affectedN/A
CVE-2020-15795Not affectedN/A
CVE-2020-14871Not affectedN/A
CVE-2020-13988Not affectedN/A
CVE-2020-13987Not affectedN/A
CVE-2020-13986Not affectedN/A
CVE-2020-13985Not affectedN/A
CVE-2020-13984Not affectedN/A
CVE-2020-13950AffectedWill be patched by upgrading to Apache version 2.4.48 on the active track and LTS tracks during Q3.
CVE-2020-13938Not affectedN/A
CVE-2020-12695Not affectedN/A
CVE-2020-11993Not affectedN/A
CVE-2020-11984Not affectedN/A
CVE-2020-11899Not affectedN/A
CVE-2020-11898Not affectedN/A
CVE-2020-11897Not affectedN/A
CVE-2020-11896Not affectedN/A
CVE-2020-10713Not affectedN/A
CVE-2020-9770Not affectedThis vulnerability is affecting Bluetooth capable client devices that are in need of patching.
Axis products with support for Bluetooth run as servers.
CVE-2020-9490AffectedProducts with AXIS OS 10.0 or lower are not affected.
Affected products has been updated to Apache 2.4.46 in AXIS OS 10.2, November 2020.
CVE-2020-7461Not affectedN/A
CVE-2020-3120Not affectedN/A
CVE-2020-3119Not affectedN/A
CVE-2020-3118Not affectedN/A
CVE-2020-3111Not affectedN/A
CVE-2020-3110Not affectedN/A
CVE-2020-1971AffectedAxis will deliver patches for this low-risk vulnerability by updating to OpenSSL 1.1.1i during Q1, 2021
CVE-2020-1967AffectedAxis has delivered patches to affected LTS and Active firmware tracks.
CVE-2020-1938Not affectedN/A
CVE-2020-1934Not affectedN/A
CVE-2020-1927AffectedAxis has delivered patches to affected LTS and Active firmware tracks.
CVE-2019-17567Affected (door stations/intercoms)Affects door stations/intercoms. Will be patched by upgrading to Apache version 2.4.48 on the active track and LTS tracks during Q3.
CVE-2019-10744Not affectedN/A
CVE-2019-1551Not affectedN/A
CVE-2018-10664AffectedAxis has delivered patches to the affected products, see Axis Security Advisory
CVE-2018-10663AffectedAxis has delivered patches to the affected products, see Axis Security Advisory
CVE-2018-10662AffectedAxis has delivered patches to the affected products, see Axis Security Advisory
CVE-2018-10661AffectedAxis has delivered patches to the affected products, see Axis Security Advisory
CVE-2018-10660AffectedAxis has delivered patches to the affected products, see Axis Security Advisory
CVE-2018-10659AffectedAxis has delivered patches to the affected products, see Axis Security Advisory
CVE-2018-10658AffectedAxis has delivered patches to the affected products, see Axis Security Advisory
CVE-2017-5754Not affectedN/A
CVE-2017-5753AffectedAxis has delivered patches to the affected products.
CVE-2017-5715AffectedAxis has delivered patches to the affected products.
CVE-2016-20009Not affectedN/A
CVE-2016-8863AffectedAxis has delivered patches to the affected products.
CVE-2016-6255AffectedAxis has delivered patches to the affected products.
CVE-2016-2183Not affectedN/A
CVE-2016-2147AffectedAxis has delivered patches to the affected products.
CVE-2016-2148AffectedAxis has delivered patches to the affected products.
CVE-2015-8258AffectedSee Axis Security Advisory
CVE-2015-8257AffectedSee Axis Security Advisory
CVE-2015-8256AffectedSee Axis Security Advisory
CVE-2015-8255AffectedSee Axis Security Advisory
CVE-2015-7547AffectedAxis has delivered patches to the affected products.
CVE-2015-0235AffectedAxis has delivered patches to the affected products.
CVE-2014-6271Not affectedN/A
CVE-2014-3566AffectedAxis has delivered patches to the affected products.
CVE-2014-0224AffectedAxis has delivered patches to the affected products.
CVE-2014-0160Not affectedN/A
CVE-2013-3543AffectedAxis has delivered patches to affected AMC (AXIS Media Control) in AMC 6.3.8.0.
CVE-2009-1955Not affectedN/A
CVE-2007-6750Not affectedN/A
CVE-2007-6514Not affectedN/A
CVE-2005-1797Not affectedN/A
CVE-2005-0088Not affectedN/A
CVE-2002-0185Not affectedN/A
CVE-1999-1412Not affectedN/A
CVE-1999-1237Not affectedN/A

Axis (ACV)

The Axis archive covers vulnerabilities that are specific to Axis products and firmware components, classified as Axis Critical Vulnerability (ACV). Axis strongly recommends to patch affected products and firmware.

ACVDescription
ACV-2020-100004Secure boot vulnerability for AXIS S3008 and AXIS W800.
ACV-165813Secure boot vulnerability for AXIS Q3527-LVE and AXIS A8207-VE Mk II.
ACV-147453Vulnerability that allows compromising of AXIS A1001.
ACV-128401Multiple vulnerabilities combined may compromise Axis products.
ACV-120444Heap overflow in Axis SSID CGI parser.
ACV-116267SOAP WebServices stack buffer overflow.
CVE-2016-AXIS-0812Remote format string vulnerability in Axis products.

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 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. 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.. 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 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.

  • 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 modules individually 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 is 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 flavours 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…”

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...”

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 might 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 check still the authenticity of the device itself.

Common report terms

  • “SSL Certificate Cannot Be Trusted...”

  • “SSL Self-Signed Certificate”

  • “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 is 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 is 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 is 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. As an example to illustrate the matter 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 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 for the product being tested as 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, so flags it anyway. The security scanner simply compares the version of those 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 under test 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...”

Unencrypted firmware and chip

Background
Security scanners may highlight the usage of flash chips that are 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 Axis is using in their products and therefore highlight vulnerabilities with regards 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 debug port.

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...”

System & security

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 signed firmware, secure boot and security of private keys.

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'.

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.51 and lower
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

 

Certificate management

Certificate and private key support
The following section includes details about supported certificate types and private keys by Axis devices. Supported certificate formats:

  • 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, since FW 5.50)

Other certificate details:

  • Wildcard certificate support: yes

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

  • key bit size (private keys): 4096-bit, RSA only*

  • key bit size (SSC, CSR): 2048-bit**

  • size of .PFX / .P12 certificates: 102400 bytes in AXIS OS 9.30 and higher, 10240 bytes in AXIS OS 9.20 and lower

*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 had a private key bit size of 1536-bit prior to AXIS OS 10.1. Starting with AXIS OS 10.1 and higher it is 2048-bit.

Self-signed certificate
Axis devices come with a preinstalled 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.

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 is 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

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 > PlainConfig > 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 below 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”. 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 usecase.

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.

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.

Unique encoded streams & 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 (=viewer) 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 section Maximum number of clients, we learned that there is a limit on 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
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 in total four statically configured so called video source buffers.

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 4 unique video streams. So, Axis devices containing video source buffer configurations are limited by the amount of unique video streams they can provide.

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.

Example illustration

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

So, in summary, this device can deliver 2 x unique video streams in max 1920x1080 resolution — one in max 1280x960 and one in 720x576. The previously described section “Unique encoded streams” in the server report can help in identifying which of those video source buffers 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 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 above are only for fisheye overview and they differ for other dewarped view modes. When pulling view area 1 & 2 with the same resolution on AXIS M3047-P/M3048-P, this will work either using the highest resolution (1920x1440) or 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 a 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.

 

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. 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 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 3 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 3 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 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 Client 1 request 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.

 

Network protocols

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 theRFC2460 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:

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 I nthe 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 white paper 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. They should be created by the servers and are 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 - This certificate is created by the certification authority for the purpose of validating itself, so the Axis device needs this certificate to check the server’s identity. Select the correct certificate that was uploaded previously in the security tab under CA certificates.

  • 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.

Web Services Dynamic Discovery Protocol (WS-Discovery)

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 > PlainConfig > 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

Simple Network Management Protocol (SNMP)

This section describes how to use AXIS Video SNMP MIB. It is assumed that the reader is familiar with the SNMP protocol. SNMP/MIBs allow network management operators to use standard Simple Network Management Protocol (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 firmware 5.55 and later. 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. If the agent requests the status of such hardware that is not included in the product, then the device will return noSuchObject. Which hardware is supported is handled at run time. This means that there is no need for product specific configuration. All Axis devices support the AXIS Video MIB from AXIS OS 5.55 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.

 

Enable traps
The configuration of traps, which to send and where to send them, is done differently for the different SNMP versions. For SNMPv1 and SNMPv2c, all AXIS Video MIB will be sent when traps are enabled. It will not be possible to turn on or off any specific traps.  For SNMPv3 it is possible to configure which traps are sent to which management station. This is done using the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB modules, defined in RFC3413. 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
The AXIS Video MIB (Message Information Base) extends the way to monitor AXIS devices over SNMP. The Video MIB enables network administrators to monitor a number of new notifications and status information.

To make use of the AXIS Video MIB, please download the MIB files here and import them in your SNMP network monitoring application.

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 FailurealarmNewpowerSupplyAlertxAXIS Q7900 Rack and AXIS Q7920 Video Encoder Chassis
(Multiple) Fan FailurealarmNewfanAlertxAXIS Q7900 Rack and AXIS Q7920 Video Encoder Chassis
(High or Low) Temperature Limit Reached AlertalarmNewtemperatureAlertxAll Axis devices
(Multiple) Analog Video Signal LostalarmNewvideoSignalAlertxAll Axis video encoders
(Multiple) Audio Input Signal LostalarmNewaudioSignalAlertxAll Axis audio-capable devices with external audio input
Product Casing Opened AlertalarmNewopenCasingAlertxAll Axis devices connected with AXIS T93F door switch / intrusion alarm
Mechanical PTZ Error AlertalarmSinglePTZAlertxAll Axis mechanical PTZ devices
Edge Storage AlertalarmNewstorageMediaAlertxAll 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

Cisco Discovery Protocol (CDP)

All Axis devices with AXIS OS 8.50.1 and higher are utilizing the CDP 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

    x

    x

    x

    Web interface configuration

    x

    VAPIX API configuration

    x

    SD card or network share storage*

    x

    x

    Transport protocol

    UDP

    TCP/UDP

    TCP/UDP

    TCP/UDP/TLS

    Primary & secondary remote syslog server**

    x

    Send log messages test button***

    x

    Log severity configuration****

    x

    *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 > PlainConfig > 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.

     

    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. Below are the most important components within MQTT.

    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 the 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 implementors 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 event publishing (predefined topics, payloads)

    x

    AXIS OS 9.80.1

    Custom event publishing (custom topics, payloads)
    Go to Configuration tips for a video clip.

    x

    AXIS OS 10.4.0

    Event subscription

    H1 2021 (TBD)

    TBD

    MQTT ACAP API support

    H1 2021 (TBD)

    TBD

    MQTT web interface support

    x

    AXIS OS 10.1

    MQTT over TCP

    x

    AXIS OS 9.80.1

    MQTT over SSL

    x

    AXIS OS 9.80.1

    MQTT over WebSocket

    x

    AXIS OS 9.80.1

    MQTT over WebSocket (SSL)

    x

    AXIS OS 9.80.1

    MQTT VAPIX API

    x

    AXIS OS 9.80.1

    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 PlainConfig > 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 repuest 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 events

    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 events

    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.

     

    Go to Configuration tips for a video clip of how to set up the action rule.

     

    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. Below you'll find instructions on how to look up the OAK.

    With each Axis device, you get 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 shouldn’t be discarded or disclosed to third parties. If you’ve lost your OAK, you can retrieve it by logging in to the device as an admin user. Then follow one of the paths below, depending on the firmware version of your device:

    • Firmware based on 5.51: Go to Setup > Options > Support > System Overview.

    • Firmware based on 6.50: Go to Setup > Options > Support > System Overview.

    • Firmware based on 8.40: Go to System > AVHS, and then click Retrieve OAK.

    • Firmware based on 9.80: Go to System > AVHS, and then click Retrieve OAK.

    • Firmware based on 10.0 or higher: Go to System > O3C, and then click Retrieve OAK.

    Note

    This requires that the device runs firmware version 5.51.7, 6.50.5.2, 8.40.4, 9.80.2 or 10.0.0. Please upgrade the firmware if your device is running a lower firmware version. Axis can’t assist in retrieving the OAK for you.

    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

    x

    macOS®

    recommended

    recommended

    x

    x

    Linux®

    recommended

    recommended

    x

    Other operating systems

    x

    x

    x

    x*

    *Supported in iOS and iPadOS

    • Highlights
    • Recommended browser: Latest ChromeTM and Firefox®

    • Supported browser: Latest ChromeTM, Firefox®, EdgeTM 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
    • EdgeTM: 1-second video delay when streaming H.264

    • Safari®, ChromeTM, 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 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 ChromeTM, Firefox® and Safari®.

    Configuration tips

    How to publish an MQTT message with an event rule action

     

    How to set SD card wear level

     

    Automatic firmware rollback verification

     

    How to add polygon privacy masks

     

    How to set privacy mask properties

     

    How to perform a firmware rollback (initially called firmware recovery)

     

    How to enable Opus audio codecs

     

    How to display live view stream statistics

     

    Password security confirmation check

     

    How to enable SD card encryption

    Edge storage & recording

    Edge storage support

    SD card support
    The following section includes information about supported filesystems and encryptions for SD cards.

    • Supported filesystems: ext4 (recommended), vFAT

    • Supported filesystem size: up to 2 TB for devices with SDXC slot support and AXIS OS 5.60 and higher

    • Supported encryptions:

      • AES-CBC 128-bit for all devices with AXIS OS 5.80.1 and higher

      • AES-CBC 256-bit for all devices with AXIS OS 8.40.1 and higher

      • AES-XTS-Plain64 (AES-XTS-512 256-bit) for newer devices with AXIS OS 8.30.1

     

    Network share support
    The following section includes information about supported storage network protocols and authentication modes for external storage media.

    • Supported protocols:

      • CIFS/SMB 1.0 + NTLM authentication mode for devices with AXIS OS 5.90 and lower

      • CIFS/SMB 1.0, 2.0, 2.1, 3.0 and 3.02 + NTLM authentication mode for devices with AXIS OS 6.10 and higher

    • Supported filesystem size: 8 ZB with AXIS OS 5.70 and higher, and 2 TB with AXIS OS 5.65 and lower

     

    About CIFS/SMB support
    In Axis devices with AXIS OS 8.20.1 and lower, SMB 1.0 is enabled per default while all other supported SMB versions (SMB 2.0, 2.1, 3.0, 3.02) need to be used in PlainConfig as described below.

     

    In Axis devices with AXIS OS 8.30 and higher, SMB 1.0 and SMB 2.0 are disabled per default in order to increase the overall minimum cybersecurity level of the device. In addition, it is possible for the device to auto-negotiate its SMB version with the NAS or edge storage device starting with SMB 2.1, or with higher SMB versions such as SMB 3.0 and SMB 3.02.

    In case SMB 1.0 or SMB 2.0 is required due to compatibility issues, we recommend setting the extra mount options parameter in Settings > System >  PlainConfig > Storage to a specific version, e.g. “vers=1.0” or “vers=2.0” for a network share. Please note that there are two storage groups per mounted network share (normally Storage S1 and Storage S2) and both need to have the correct version in extra mount options. If the setup also includes a network share recipient, then this recipient would be included in the S3 or S4 storage group and would also need modification. See the following example of how the configuration should look like when the NAS storage only supports SMB 1.0:

    http://ip-address/axis-cgi/admin/param.cgi?action=update&root.Storage.S1.ExtraMountOptions=vers=1.0

    http://ip-address/axis-cgi/admin/param.cgi?action=update&root.Storage.S2.ExtraMountOptions=vers=1.0

     

    Extra mount options
    Below are some configuration examples that describes how the device is handling the extra mount options parameters when configured. Note that the camera will only consider the latter of two SMB versions entered as described in the example above. Preferably only a single SMB version should be entered.

    • vers=1.0: device tries to connect via SMB 1.0

    • vers=1.0,vers=2.0: device tries to connect via SMB 2.0

    • vers=1.0,vers=2.0,sec=ntlm: device tries to connect via 2.0 SMB with NTLM only

    Timelapse recordings

    There are several ways to configure timelapse recordings in Axis products. Below you will find more information and examples of different configuration setups.

    Note

    A workaround previously described as saving images to the SD card using FTP and the IP address of the device itself is not supported by Axis. The configuration in question has been made unavailable in later firmware versions. It is recommended to use one of the following alternatives instead.

    Recording to SD card using third-party ACAP solutions
    Axis has tested and can recommend a third-party ACAP called VideoLapseMe and its successor TimelapseMe developed by Pandos Development (https://acapshare.wordpress.com/). The ACAPs work in AXIS OS 5.60 and upwards and are considered a proper solution for the timelapse use case. These ACAPs offer the following features:

    • Timelapse recordings to SD card or network share

    • Ability to download the AVI-video directly from the ACAP with user-selectable frame rate and playback rate

    • Up to five different timelapse recordings supported simultaneously

    • Alert notification in case a timelapse recording has issues

    Recording to remote host using FTP server
    Use FTP properly as it is a standard network protocol to transfer files from one host to another over the internet. Upload to a remote host, e.g., another computer or server on the network with a static path.

    Example configuration in web interface in AXIS OS 6.53 and lower

    Example configuration in web interface in AXIS OS 7.10 and higher

     

    Recording to remote host using network share

    Example configuration in web interface in AXIS OS 6.53 and lower

    Example configuration in web interface in AXIS OS 7.10 and higher

     

    Recording to remote host using mail

    Example configuration in web interface in AXIS OS 6.53 and lower

     

    Example configuration in web interface in AXIS OS 7.10 and higher

     

    Troubleshooting & maintenance

    Basic troubleshooting

    AXIS OS supports a variety of troubleshooting tools and commands that can be used to identify, analyze and solve issues that are experienced by a user. Please refer to a selected list of tools and methods as below and follow the instructions given by Axis Technical Services.

    Purpose / ActionHTTP(S) URL commandAdditional information
    Download server reporthttps://172.25.201.191/axis-cgi/serverreport.cgi?mode=zip_with_imageDownloading a server report from the Axis device.
    Download crash reporthttps://172.25.201.191/axis-cgi/debug/debug.tgzDownloading a crash report from the Axis device, this may take several minutes to complete.
    Download network tracehttps://172.25.201.191/axis-cgi/debug/debug.tgz?cmd=pcapdump&duration=30Downloading a network trace from the Axis device can also be achieved via the web-interface in newer AXIS OS versions in Settings > System > Maintenance. When the direct URL is used, a custom time in seconds can be specified in the duration= parameter..
    Ping test ip-addresshttps://172.25.201.191/axis-cgi/pingtest.cgi?ip=172.25.201.10The ping test is always issued from a source device, in this case the Axis device at 172.25.201.191 followed by the parameter that determines the target ip-address or hostname.
    Ping test hostnamehttps://172.25.201.191/axis-cgi/pingtest.cgi?ip=computer.lab.netThe ping test is always issued from a source device, in this case the Axis device at 172.25.201.191 followed by the parameter that determines the target ip-address or hostname.
    Port open testhttps://172.25.201.191/axis-cgi/tcptest.cgi?address=172.25.201.102&port=80The port test is always issued from a source device, in this case the Axis device at 172.25.201.191 followed by the parameter that determines the target ip-address and port that should be checked for availability.

    SSH access

    Note

    The below documentation should only be used according to the instructions given by Axis Technical Services in maintenance and troubleshooting situations.

    Accessing the Axis device using SSH for maintenance purposes only is recommended due to the connection being encrypted and sensitive information being transferred securely. SSH access can be achieved using the plain Linux command console or Microsoft Windows power shell. Note that administrator privileges may be required for this and/or firewall and security settings of the computer need to be adjusted in order to allow SSH connections. SSH can be enabled in the Axis device in Plain config > Network > SSH. Alternatively SSH can be enabled/disabled using the direct VAPIX API calls:

    • https://ip-address/axis-cgi/param.cgi?action=update&Network.SSH.Enabled=Yes

    • https://ip-address/axis-cgi/param.cgi?action=update&Network.SSH.Enabled=No

    Command overview
    The following main commands are available and supported when logged in via SSH to the Axis device. Please make sure you are using the commands according to the instructions given by Axis Technical Services.

    Action / PurposeWindows OS command lineLinux OS command line
    Connect & loginssh root@192.168.0.90ssh root@192.168.0.90
    Disconnect & logoutexitexit
    Restartrebootreboot
    Download crash reportssh root@192.168.0.90 /usr/sbin/dbox debugar.cgi -d > debug.tgzssh root@192.168.0.90 /usr/sbin/dbox debugar.cgi -d > debug.tgz
    Upload firmware*scp C:\Users\psadmin\Downloads\P1375_9_80_2_4.bin ssh root@172.25.201.191:/var/tmp
    Update firmwareupgrade -f /var/tmp/P1375_9_80_2_4.bincat P1375_9_80_2_4.bin | ssh root@172.25.201.191 upgrade
    Update firmware & factory defaultupgrade -d -f /var/tmp/P1375_9_80_2_4.bincat P1375_9_80_2_4.bin | ssh root@172.25.201.191 upgrade -d

    *Uploading firmware to the Axis device is only needed when the user is trying to update the device firmware using the Windows OS command line. This step is not needed when using the Linux OS command line.

     

    The commands below are illustrated using the Windows OS command lines from the table.

    Connect & login

    Disconnect & logout

     

    Download Crash Report

     

    Restart

     

    Firmware update

     

    Firmware update & factory default

    FTP access

    Note

    The below documentation should only be used according to the instructions given by Axis Technical Services in maintenance and troubleshooting situations.

    Accessing the Axis device using FTP for maintenance purposes only is not recommended due to the connection being unencrypted and sensitive information being transferred in plain text readable. Therefore, SSH access is recommended. FTP access can be achieved using the plain Linux command console or Microsoft Windows power shell. Note that administrator privileges may be required for this and/or firewall and security settings of the computer need to be adjusted in order to allow FTP connections. FTP can be enabled in the Axis device from the in Plain config > Network > FTP. Alternatively FTP can be enabled/disabled using the direct VAPIX API calls:

    • https://ip-address/axis-cgi/param.cgi?action=update&Network.FTP.Enabled=Yes

    • https://ip-address/axis-cgi/param.cgi?action=update&Network.FTP.Enabled=No

    Command overview
    The following main commands are available and supported when logged in via FTP to the Axis device. Please make sure you are using the commands according to the instructions given by Axis Technical Services.

    Action / PurposeWindows OS command line
    Connect & loginftp 192.168.0.90
    Disconnect & logoutbye
    Restartquote site reboot
    Download crash report*get debug.tgz
    Update firmware*put P1375_9_80_2_4.bin flash
    Update firmware & factory default*put P1375_9_80_2_4.bin flash_all

    *The hash command followed by the bin command can be used to enable verbose logging prior to executing the selected commands.

     

    Connect & login

     

    Disconnect & logout

     

    Download Crash Report

     

    Restart

     

    Firmware update

     

    Firmware update & factory default

     

    Network traffic shaping

    Axis devices can transmit video using the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). TCP has a control mechanism, so in the event a packet is being lost or corrupt, it will be resent. The UDP protocol doesn’t have a mechanism to ensure that all transmitted packets have been received. So, if a packet is discarded or corrupt, its retransmission is not requested. UDP is commonly used in multicast networks. The discarded packets associated with a video stream will result in unsatisfactory video performance as the associated pixels will not be displayed within the end users’ video. Packet drops are caused by different things, e.g. the incorrect specification of the network infrastructure, a network that had alterations over time (more traffic added), or a network that becomes congested at peak times. Network switches with insufficient processing power and memory capabilities will cause packet drops when faced with unexpected or inconsistent peaks of incoming data.

    Axis devices will by default transmit their data as fast as possible and due to the nature of H.264 video, we encounter peaks or bursts of network traffic that is sent out by the Axis device into the network. The bursts or peaks of data are associated with the I-frames contained within the video stream, where the whole video frame is updated. In between the I-frames are the P-frames, which are much smaller in data size. This can cause issues when there is insufficient capacity on the network hardware and when using the UDP method of transmission.

     

    Network bottlenecks and throughput
    Even though the network infrastructure through its switches and routers gets increased capabilities and become more powerful in dealing with network spikes and bursts, and even though it’s trying to overcome the temporal bottleneck by buffering the incoming data, this might eventually still fail depending on the setup.

    Below are a couple of possible scenarios where traffic shaping is a recommended technique for avoiding network related issues. The use cases illustrate how to plan and manage network related traffic by understanding possible bottleneck positions within the network. This is done by simply computing the uplink speed of the network infrastructure and potential incoming data from e.g. Axis devices or other network equipment that coexists and contributes to data traffic in the network.

     

    But it’s not only the uplink speed that is important. In some use cases the network equipment is simply not performant enough to cope with the amount of network traffic or spikes that might be generated. It’s also possible that the accumulative number of devices connected to the same network switch eventually will overwhelm it and cause it to drop network packets. Proactive planning of the expected network traffic and use case is key in avoiding potential issues.

     

    Basic traffic shaping
    There are several techniques for controlling the data output from an Axis device. The first step is to always use a suitable compression level to optimize the device’s output. H.264 compression is the industry standard method of compression due to its efficiency, but a suitable compression level must still be applied (this reduces the amount of data whilst maintaining picture quality). Axis Zipstream is an even more efficient compression algorithm, which increases the compression further whilst still maintaining picture quality when compared to H.264. H.264 and Zipstream algorithms are based on the movement or non-movement within a scene, and as such it’s quite difficult to predict the actual output of the camera. Maximum bitrate (MBR), variable bitrate (VBR) as well as average bitrate (ABR) are techniques to limit the output of a camera, and can be used to contain the transmitted data within a certain average perimeter. However this doesn’t restrict the actual peaks or bursts. Learn more about the different bit rate controls in the white paper Bitrate control for IP video.

    A completely different example of applying basic traffic shaping is the simple decision between having two video streams per Axis device, one each for live view and recording versus using the same streaming and network parameters for re-using a single video stream for both live view and recording. Using only one video stream instead of two is reducing the amount of network throughput generated by the Axis device by 50%. This may even be enough to avoid network-related bottlenecks in an aggregated scenario of, let’s say, having many Axis devices being connected to a fully utilized 48-port network PoE switch.

    Advanced traffic shaping
    In case basic traffic shaping mechanics are not suitable, more advanced techniques can be applied on the network layer of the Axis device. To control peaks or bursts of data being transmitted from an Axis device, the “bandwidth limit” parameter in Plain Config > Bandwidth can be used. The bandwidth parameter was introduced in AXIS OS 6.20 and makes use of the hierarchical token bucket (HTB) and token bucket filter (TBF). TBF controls the transmitted output by controlling the data by the use of a token. When a token is available – data can be sent. The bandwidth limit is not the capped data rate but what HTB/TBF uses to organize the data output in a controlled manner.

     

    TBF is a queuing method that acts as a timing mechanism which effectively spreads peaks of data over a longer period. More information about HTB and TBF can be found via the following links:

     

    Configuration in AXIS OS
    The bandwidth parameter can be found in Plain Config > Bandwidth. When limiting the traffic you need to set a bandwidth limit value that matches your total bandwidth needs from your Axis device. It’s recommended to gather statistics from the network switch that the Axis device is connected to in order to learn the usual bandwidth usage. As an example, an Axis device under operation is a multisensor device with four image sensors and a combined quad view that sends out two streams each per channel for recording and live view. These 10 parallel video streams generate an average network bandwidth consumption of 70-80 Mbit/s. To include some margin, the bandwidth parameter should be configured to 100mbit or 125mbit.

    Important

    The Axis device will drop packets if the bandwidth parameter is configured unreasonably, i.e. lower or very close to the actual network bandwidth consumption. Applying good margin above the actual network bandwidth consumption is always recommended. The bandwidth limit is not the capped data rate but what HTB/TBF uses to organize the data output in a controlled manner.

     

    Example 1: Default configuration, 0 means no traffic shaping is applied.

     

    Example 2: Traffic shaping is enabled, and the maximum output is capped at 100 mbit/s.

     

    Example 3: Traffic shaping is enabled, and the maximum output is capped at 10000 kbit/s (=10 mbit/s).

     

    (C) 2020 Axis Communications AB. AXIS COMMUNICATIONS, AXIS, ARTPEC and VAPIX are registered trademarks of Axis AB in various jurisdictions. All other trademarks are the property of their respective owners.