AXIS OS Knowledge base

AXIS OS Portal | AXIS OS Release Notes | AXIS OS YouTube playlist| AXIS OS Hardening Guide | Security Advisories

Welcome to the AXIS OS Knowledge base, a comprehensive repository designed to be the go-to resource for technical information about AXIS OS. AXIS OS is the Linux-based operating system used in most of your Axis network devices. It is purpose-built to live up to the most important criteria for network devices: high standards for cybersecurity, ease of integration, quality, and long-term value.

We now have a Security Advisories page which lists all known vulnerabilities in Axis products. Please visit to stay informed.

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

Summary

Identity and Access Management comprises policies for safeguarding that individuals and applications have access to system resources in the right context. For example, individuals should only interact with applications, and only applications access devices. IAM ensures integrity over time, for example, that passwords are not leaked, and that accesses are revoked when no longer needed.

Axis recommends to use Axis' device management applications, AXIS Device Manager or AXIS Device Manager Extend, to set up and manage unique service accounts for applications accessing devices. The following sections further detail Axis' recommendations for identity and access management in video surveillance systems.

Introduction

Identity and Access Management (IAM) systems are responsible for managing identities, permissions, and access control within an organization. IAM makes sure that the right individuals and applications have the right level of access to the right system resources. This is a fundamental cybersecurity measure for preventing unauthorized access. One of the main challenges is maintaining integrity over time. This includes ensuring that passwords and other secrets have not been leaked, and that individuals and applications that should no longer have access indeed have their access revoked.

Identity and access management typically involves authentication, authorization, and privileges.

• Authentication. Verifying that an entity is who or what it states to be.

• Authorization. Controlling which entities are allowed to perform specific functions.

• Privileges. Grouping of entities based on what they are authorized to do. Axis defines privileges as roles.

Throughout the document, the terms user account and service account are used. Both are registered and governed through IAM.

• User account. A user account is an account used by a person to access applications.

• Service account. A service account is a non-human account used by an application to access devices. Service accounts are used in machine-to-machine communication or when an application needs to access devices in a trusted and automated manner.

Best practices when working with service accounts

For maintaining integrity over time the following best practices of service account management are recommended.

• Use Axis' device management applications, AXIS Device Manager or AXIS Device Manager Extend, for service account management.

• Set up unique service accounts for each application accessing devices, as recommended in the AXIS OS Hardening Guide.

• Select appropriate privilege to each service account.

• Remove service accounts that are no longer in use.

• Avoid persons accessing devices directly (if it is absolutely necessary, use a unique and temporary service account), the web-interface can be disabled as recommended in the AXIS OS Hardening Guide.

• Ensure high password complexity is given to avoid account leakage, see recommendations from the AXIS OS Hardening Guide.

The below diagrams visualize the best practices of access management in the device.

Scenario A

Person A has no direct access to the AXIS device Person A has access to the AXIS Device Manager Application Person A creates a service account for ADM in the AXIS device using ADM Person A uses ADM to create a service account for the Video Management Application

Scenario B

Person B has no direct access to the AXIS device Person B has access to the Video Management Application Person B uses the Video Management Application to perform video management tasks on the AXIS device

The device is exposed to following risks when using user accounts in the device:

• unauthorized personell accessing devices

• wrong level of authorization in different devices

• reuse of user account credentials leads to no audit traceability

• poor scalability with increasing number of devices

Different sites and organizations can have different policies, including password policies. The setup of the system should accommodate these policies. Typically, each application should have its own credentials to devices. If the password is reused in devices, Axis recommends to rotate the password frequently. 

Authorization and account privileges

Axis devices support the roles Administrator, Operator, and Viewer, with different authorization levels. Axis recommends to set up an administrator account for management application that has access to the devices. This account should be unique for each application and not shared. Ideally, the password for this account should be generated by the management application itself and remain unknown to all individuals.

If direct access to devices is needed

Some configurations may not be natively supported by the application and may need to be done through the devices web interface. Axis recommends to access the Axis device web interface through the seamless access provided by Axis' device management applications.

If there are strong reasons for allowing direct access to devices, Axis recommends to use temporary service account impersonalization with limited access. A new service account should be created on the device with the appropriate role for what needs to be done. Once the direct access is no longer needed, this service account should be deleted.

Legacy access procedure (default user with default password)

Historically, Axis devices 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. 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.

Updated access procedure (default user with no default password)

The VAPIX and ONVIF interfaces have been disabled and the "root" VAPIX user password is no longer set in factory default state. This means that it’s no longer possible for a client to access or configure the device out-of-the-box without setting a password for the VAPIX user "root". 

The new access procedure has been implemented in the following AXIS OS releases:

• Version 5.51.6

• Version 6.50.4 (2016 LTS)

• Version 8.40.3 (2018 LTS)

• Version 9.40.1 and higher

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

• 1.65.x

• 1.8x.x

• 5.75.x

• 6.53.x

• 6.55.x

• 7.15.x

Modern access procedure (no default user)

With AXIS OS 11.6 and higher, the default VAPIX user "root" has been removed from the Axis device in their factory default state and it is now possible to create a custom named VAPIX user instead during factory default state.

Anonymous interface calls

Interface calls that do not require authentication (=anonymous) are still allowed for device identification purposes. An Axis device can be identified in its factory default 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

Activate VAPIX and/or ONVIF interfaces

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

• The VAPIX interface is activated when an initial VAPIX user password is set, either via VAPIX System Settings API, as described in the VAPIX library or by using the Axis device's web interface during the installation wizard process.

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

• AXIS OS version	Web interface configuration path
  < 7.10	Setup > System Options > Security > ONVIF
  ≥ 7.10	Settings > System > ONVIF
  ≥ 10.9	System > ONVIF

•  In addition, an ONVIF user can also be created using the ONVIF Profile S specifications. 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>

Password strength indicator

Axis devices with AXIS OS 7.20 or higher support a password strength indicator which is visible when creating or modifying a user account password through the web interface. It indicates if the strength of the chosen password is considered weak, medium or strong and also provides advice on how to strengthen the password. The indicator follows the ZXCVBN algorithm developed by Dropbox. More information about setting the device password is available in the AXIS OS Hardening Guide.

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. 

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

SSH

FTP

RTSP protocol

HTTP(S) protocol

*Requires the Access Log parameter to be enabled from Plain Config > System.
**Only login attempts using the correct username will be logged. This log message is only available from AXIS OS 10.4 and onwards.

IP filtering***

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

PreventDosAttack****

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

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

AXIS OS 7.30 or higher

Axis devices running AXIS OS 7.30 and higher can be configured to automatically block HTTP/HTTPS requests coming from a client in the network (IP address). For a certain amount of time, a defined number of authentications fail. This feature can help in avoiding and to protect the Axis device from brute-force attacks, or from network clients that unintentionally imitate a similar behavior. The brute force delay protection can be configured in Plain config > System.

AXIS OS 11.5 or higher

With AXIS OS 11.5 or higher, Brute Force delay protection is enabled by default using the configuration example 1 below.

Generally the lower the allowed page/site count is, the more secure the protection. Using Brute force delay protection increases the time to guess a password tremendously. Some indications can be found below. Note that configuring a strong password is always recommend.

*Actual rate may vary and is depending on product performance.

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

Furthermore, the Axis device would log the following internally in the system log:

Parameter Description

Configuration examples

• Example 1: After 20 failed login attempts within one second, the client IP address gets blocked for 10 seconds. This configuration is the default configuration and offers flexible security where, to some extent, failed login attempts from good-known authorized clients are taken into account.

• Example 2: After 10 failed login attempts within one second, the client IP address gets blocked for 10 seconds. This configuration is recommended for very strict and high security systems where already a few failed login attempts will block a client.

About signed OS
Signed OS is a feature that was introduced to ensure that only verified and trusted software 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 selected to avoid issues. For general information about the signed OS feature, see the Cybersecurity features in Axis products white paper.

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

• Question: My device runs AXIS OS 9.10.1 and I want to downgrade to AXIS OS 8.40 LTS. Does this work?
  Answer: Yes, this will work.

• Question: 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 version will be rejected by the device and it will continue to run AXIS 9.20.1. In order to perform such a downgrade, you 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. Note that Axis does not encourage downgrades to older, unsupported AXIS OS versions in general.

Signed OS key lifecycle
Signature key pairs are generated on a dedicated offline key generation device. After generation the private key is encrypted with two different asymmetric keys. One for secure import into a cluster of Thales Luna HSMs and another key for long-term offline backup outside the HSM in at two separate secure locations.

The private key is provisioned into the HSM using an administrative role of the HSM that requires M of N authentication. At no point is the private key exposed in plain text during the import.

When Axis signs a AXIS OS image with said key, the signing request is processed by an application server that guards access to the HSM and audits use of the signing key. The application server can only be accessed from inside the Axis network and requires a signing-authorized account.

Revoking of a AXIS OS signing key entails issuing a bootloader update for all Axis devices using that key. As part of the update, the device’s anti-rollback mechanism is updated to block older bootloaders which are still accepting the revoked AXIS OS signing keys. Secure destruction of signing keys requires physical destruction of the master backup key that exist in two copies.

Troubleshooting
How can you identify that an upgrade did not work because of an unsigned OS? If a user tries to upload an unsigned version, one of the following messages is displayed in the log files of the camera when a device software upgrade fails due to signed OS:

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

Axis takes proactive steps to implement ACAP application signing, aligning with industry best practices for secure software delivery. Additionally, it anticipates potential future enforcement through legislation, including the E.U. Cybersecurity Resilience Act, E.U. Radio Equipment Directive, and Executive Order 14028. Therefore, starting from AXIS OS 12.0 customers will only be able to install signed ACAP applications on Axis devices by default. Installation of unsigned ACAP applications will be possible only and only if a device is actively configured to accept unsigned ACAP applications. Configuring a device to accept unsigned ACAP applications will lower the device’s security, but it can be useful during development or if you develop and run your own ACAP application. Running unsigned ACAP applications is not recommended.

What are the benefits for end customers?

A signed ACAP indicates that Axis has a TIP-relationship with the partner who has developed the ACAP. By inspecting the ACAP, the end customer can see who the TIP-partner is. The partner name under the vendor tag is equivalent to the company name in Axis CRM records. Therefore, the signing process ensures the validation of the partner, traceability and accountability. This process enables the end customers to validate their ACAP applications.

What are the benefits in terms of cybersecurity?

The signing process ensures that the ACAP will only require Axis-approved access-rights and privileges when running on the Axis device. An ACAP that went through the signing process, will only run with limited, approved access rights on an Axis device. Furthermore, by signing the ACAP application, it is ensured that the content of the application is not tampered with from release to installation, hence it enables the secure software delivery.

Is Axis vetting the software quality, secure development practices or performing QA-testing on Signed ACAPs?

No, Axis does not take any responsibility for whether a TIP-partner ACAP that went through the signing process is QA-tested, or has been developed according to industry best-practices secure development processes. This responsibility lies entirely on the TIP-partner that is providing an ACAP application.

Who do we allow to have their ACAPs signed?

Only TIP partners are allowed to do so. This indicates that Axis has conducted a vetting process for its partners.

Will Axis provide ACAP signing capabilities for non-TIP partners as well?

For non-TIP partners that require signing capabilities, we will also perform a vetting process. Please use this link to request access.

How does the ACAP signing technically work?

During the ACAP application signing process, a cryptographic signature is added at the end of the application package. The signature is verified by the Axis device when installing the ACAP application as part of the overall secure software delivery architecture.

When will Axis enforce mandatory ACAP signing?

In alignment with secure software delivery practices, Axis will accept only and only Signed ACAP applications without the possibility to disable this security control on its devices. Axis aims to achieve this is the next generation of the AXIS OS operating system which is planned to be AXIS OS 13.0 in H2 2026 and onwards.

A secure keystore is generally referred to as a dedicated hardware crypto computing module that offers protection of cryptographic operations, certificates, and keys. Axis products that support AXIS Edge Vault feature up to two secure keystores with corresponding security certification, either Common Criteria CC EAL6+ and/or CC EAL4+ / FIPS 140-2 level 2 certification according to the Federal Information Processing Standard, which could be a regulatory requirement for certain customers and use cases. Both secure keystores offer the same level of protection in terms of cryptographic operations, certificates, and keys. Additionally, some system-on-chips include a so-called Trusted Execution Environment (TEE). Depending on the installation requirements, the TEE might be a good choice due to lower latency for cryptographic operations.

The table below provides an overview of the cryptographic features of keystores found in Axis devices.

1. Legacy for products without any hardware protected secure keystore.

2. Support from AXIS OS 5.50 and higher, Max size of .PFX and .P12 certificate/private key container are limited to 102400 bytes except for devices running AXIS OS 9.20 and lower where only a maximum file size of 10240 bytes is supported.

3. The support for ECC was added in AXIS OS 10.10 excluding the following products which need to receive an software update manually: HWID 79C: AXIS Q3527-LVE, HWID 7DA: AXIS Q6074, HWID 7D9: AXIS Q6074-E, HWID 7B1: AXIS Q6075, HWID 7B0: AXIS Q6075-E, HWID 7B2: AXIS Q6075-C, HWID 7B3: AXIS Q6075-S, HWID 7FA: AXIS Q6075-SE and HWID 7C7: AXIS Q9216-SLV.

4. ECC cryptography support for Axis devices without TPM module has been added from AXIS OS 10.1 and higher.

5. RSA 3072 key length is not supported.

6. Max key bit size of private key generated by the Axis device when creating a self-signed certificate (SSC) or issuing a certificate signing request (CSR). During the very first boot, the Axis device will generate a self-signed certificate automatically, which prior to AXIS OS 10.1 had a private key bit size of 1536-bit. Starting with AXIS OS 10.1 and higher, the size is 2048-bit.

7. Support from AXIS OS 11.6 or higher.

Default device certificate
Axis devices contain a certificate to allow for encrypted HTTPS and other secure connections in order to provide the possibility to access the device securely and proceed with the initial configuration of the device. Depending on the hardware capabilities of the Axis product and which AXIS OS version it is running, different default configuration applies.

Self-Signed Certificate
Axis products with support for TPM module or Software keystore only generate a self-signed certificate during first-boot up. Axis devices come with a pre-installed self-signed certificate in order to provide the possibility to access the device via encrypted HTTPS connection and proceed with the initial setup of the device. Since the first-boot certificate is self-signed by the device, it is not suitable for providing authentication or authenticity against networks and applications. Therefore, 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.

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 certificate chain. ou can download and find more information about the Axis device ID certificate chain in our Public Key Infrastructure Repository. Remember to verify the downloaded certificates against the provided sha256 hash before using the Axis device ID CA certificates as a trust anchor.

CA certificates
CA certificates are certificates used by the Axis device to validate/verify the authenticity of other servers in the network. This means that CA certificates that are going to be uploaded in the CA certificate section of the Axis device need to fulfill one of the following:

• X509v3 CA certificate with basicConstraints extension CA:TRUE*

• X509 v1 self-signed certificate

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

• Netscape Certificate Type extension saying that it is CA certificate

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

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

• The Axis device has been factory defaulted in the meantime

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

AXIS OS by default has the following most common security-related HTTP(S) headers enabled to increase overall minimum cybersecurity in factory defaulted state. The custom HTTP header VAPIX API can be used to configure further HTTP(S) headers. For more information, see the Vapix Library.

AXIS OS 10.1 and higher
With AXIS OS 10.1 or higher, the below default HTTP(S) headers have been introduced to increase overall minimum cybersecurity level:

AXIS OS 11.5 — 11.11
With AXIS OS 11.5 —11.11, a Content-Security-Policy (CSP) HTTP(S) response header is added in addition to specify a policy that tells the browser which sources of content can be trusted for the Axis device. This header can be used to protect against various types of attacks, including cross-site scripting (XSS) and data injection attacks.

When a browser receives a web page, it checks the CSP header to determine which sources of content are allowed to be loaded for that page. If any content is attempted to be loaded from a source that is not on the list, the browser will block it.

In addition to the CSP, a Referrer-Policy header is added. HTTP requests may include the optional Referrer header, which indicates the origin or web page URL the request was made from. The Referrer-Policy header defines what data is made available in the Referrer header.

AXIS OS 12.0 and higher
With AXIS OS 12.0 and higher, the default Content-Security-Policy (CSP) HTTP(S) response header has been updated.

When decommissioning an Axis device, a factory default should be performed. After the factory default, most data is erased by overwriting/sanitization. For more information, go to AXIS OS Hardening Guide.

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

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

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

Internal clients

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

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

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

• Continuous recording to SD card or network share

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

External clients

• Viewing video in web interface

• Viewing video via secure remote access

• Live view and recording to AXIS Companion

• Live view and recording to AXIS Camera Station

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

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 version 5.70 or higher in the section Snapshot of the current (caching) streams. For devices with AXIS OS version 10.7 or higher, this information is available in the section Snapshot of all running streams. The number of unique encoded streams are affected by stream properties, as will be shown in the examples below. Note that the illustrations are taken from a graphical user interface to better illustrate the use case.

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

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

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

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

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 version 9.80 and higher in the section Snapshots of the current outgoing RTP streams. This section lists the number of distributed streams in relation to their destination IP address. The distributed stream is declared as a ratio of Number of video streams:Number of physical network clients.

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

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

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

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

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.

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

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

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

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

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

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

Performance considerations
While it’s 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, you 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.

_{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’s 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.

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

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

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

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

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

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

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

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

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

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

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

Example illustration

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

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

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

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

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

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

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

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

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

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

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


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

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

Troubleshooting example 3: Axis devices with newer AXIS OS versions 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

The time from an actual event happens until it's displayed on the client's screen is called latency. The latency includes processing of the image in the camera, transmission over the network, and decompression on the client. More information about latency can be found here. In some circumstances, it is desired to keep this latency as low as possible. To reduce the processing time on the camera, there are a few possibilities. Note that these settings will affect all video streams.

• Choose a capture mode with higher frame rate. In high frame rate capture modes, the processing is usually performed faster than in low frame rate capture modes.

• Enable LowLatencyMode (Settings > Plain config > Select group: ImageSource > ImageSource / I0 / Sensor > Low latency mode: on). In this mode, the amount of image processing is reduced to lower the latency. The drawback is that the images will become noisier, especially in low light conditions and around moving object. This will reduce the latency up to 30 - 200 milliseconds depending on camera model and settings. Depending on the Axis device, this feature is available on AXIS OS 9.80.1 or higher.

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.

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, see the actual network traces in Multicast in detail.

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 about 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 information about 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

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

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

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

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

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

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

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

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

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

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

v=0
o=- 1188340656180883 1 IN IP4 172.25.201.100
s=Session streamed with GStreamer
i=rtsp-server
t=0 0
a=tool:GStreamer
a=type:broadcast
a=control:*
a=range:npt=now-
m=video 50000 RTP/AVP 96
c=IN IP4 224.225.226.227/5
b=AS:50000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-sets=Z2QAKa0AxSAeAIn5ZuAgIDSDxIio,aO48sA==
a=control:stream=0
a=ts-refclk:local
a=mediaclk:sender
a=framerate:30.000000
a=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000

_{*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.}

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

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

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

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

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

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

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

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

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

Multicast in a routed network 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.

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

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

Exception: The above is not true for Axis devices with support for ImageSource.I0.SourceRotation=yes. On these devices, the image rotation parameter is set globally via VAPIX and ONVIF will adapt to it accordingly.

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

Example configurations

VAPIX configuration of image rotation from the device web interface:

ONVIF configuration of image rotation from the device web interface:

ONVIF configuration of the image rotation via script editor:

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

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

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

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

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

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

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

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

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

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

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

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

For debugging purposes we recommend using the following online converters:

• https://www.epochconverter.com/hex

• https://www.rapidtables.com/convert/number/hex-to-decimal.html

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

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

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

These sample images can be used for testing:

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

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

Analytics metadata
Analytics-related metadata is available from AXIS OS 9.50 and later. Unlike the event and PTZ metadata stream described above, analytics metadata is streamed constantly from the Axis device to receiving clients, even if nothing happens in the scene. Typical examples of analytics metadata are motion or object detection coming from Axis analytics applications (ACAPs), such as AXIS Video Motion Detection. In AXIS OS 10.10 device software, AXIS Object Analytics changes from using the Axis Object Analytics engine to AXIS Analytics Scene Description. For more information on this, click here. You can also find out more about AXIS Object Analytics here.

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

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

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

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

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

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

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

• Mechanical and/or digital PTZ

• Mechanical and/or digital I/O

• Audio in and audio out capabilities

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

• 3rd party applications

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Enabled by default

Configuration dependent

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

***IEEE 802.1X is only enabled by default on Axis Device ID capable devices.

To find out which Axis product that support Axis Device ID, please go to Axis product selector and select Axis device ID under Cybersecurity.

Network Time Protocol (NTP)

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

Axis devices use two implementations as their current platform, depending on the AXIS OS version.

Chrony is a newer implementation of the Network Time Protocol compared with OpenNTPD. It can perform well in challenging situations where the network is congested or the network connection is intermittent. Chrony can synchronize the system faster and quickly adapt to sudden clock rate changes. Additionally, Chrony supports Network Time Security (NTS) (RFC 8915) so that the time the device gets comes from a trusted source. You can find more information about Chrony here.

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

Network Time Security (NTS)

Axis devices with AXIS OS 11.1 or higher support Network Time Security. NTS allows the devices to get time from a trusted source. NTS is a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the NTP.

NTS consists of 2 protocols:

1. NTS Key Exchange (KE): Exchange the necessary keys between the NTP client and server via Transport Layer Security (TLS). Once key exchanges are done, the TLS channel will be closed. The NTP client also knows which NTP server to query.

2. NTP Authentication: The NTP client queries the time to the NTP server. Both parties authenticate NTP time synchronization packets using the results of the TLS handshake.

More public information about NTS can be found here.

OpenNTPD

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

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

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

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

Chrony

The following sections illustrate the steps taken during a complete NTP synchronization while using Chrony.

• Phase 1: Phase 1 starts with the initial time query. Chronyd will begin with a burst of 4-8 requests to make the clock’s first update sooner. Once it gets the reply from the NTP server, it calculates the time difference between the current system time against the timestamp from the NTP server. In our implementation, we set the Chrony to step the system clock if the adjustment is larger than 0.1 seconds, but only in the first clock update since chrony was started. If the time difference is less than 0.1s, the Chrony will enter slew mode. The max rate that Chrony allowed to slew the time is set to 83333.333ppm (1/12s). Once the time is synchronized, you will see “yes” on the webpage.

• Phase 2: Phase 2 is considered the usual operation mode. Once the time is synchronized, the general query polling interval to the NTP server is set to 64 seconds.Most of the Axis devices have a built-in real-time clock (RTC). The system will copy the clock from the RTC on the boot. To maintain the accuracy of the RTC, we enabled chronyd to copy the system time to the RTC every 11 minutes. Please be aware that chronyd will not track RTC drift.One of the main activities of the chronyd program is to work out the rate at which the system clock gains or loses time relative to real time. Whenever chronyd computes a new value of the gain or loss rate, it will record the value at /var/lib/chrony/drift. This can also help stabilize the initial synchronization on the next start.

NTS Sync process

To configure NTS, go to System > Date and time, and select Automatic date and time (manual NTS KE servers).
You can either input the IP address of the NTP KE servers or the hostname (make sure the DNS server is properly configured). Here is an example of successful time sync via NTS:

The behaviors of the time sync process are almost identical to those we mentioned in the above Chrony sync process. Here we mainly focus on the key exchange and secure part.

• Phase 1
  The Chrony client starts communicating with the KE server by establishing a TLS channel. That follows the key exchange. In the key exchange process, the client receives secret keys and cookies to be used later. The cookies contain secret keys only understood by the NTP server. The KE server also notifies the client which NTP server to query. Once the exchange is done, the TLS channel will be terminated.

• Phase 2
  The Chrony client directly contacts the NTP server. It encrypts the query by the key it gets from phase 1. In that query, a cookie is also included. Once the server receives the query, it knows how to read the query. The server will respond to the client with a signed query. The client validates the signature in the incoming packet and then sets the time knowing it was sent from the correct server.

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

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

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

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

(146.76.54.5 OR 146.76.54.56 OR 146.76.54.5) AND 45.32.76.99

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

With AXIS OS 11.0 or higher, when setting multiple NTP sources, Chrony tries to select the most accurate and stable sources for the synchronization of the system clock. This also applies when setting multiple NTS servers.

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

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

Netnod NTS server
Netnod’s NTP service, funded by the PTS, is available for free to anyone. Netnod currently provides the following NTS servers.

• nts.netnod.se

• sth1.nts.netnod.se

• sth2.nts.netnod.se

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

Note that Windows by default will have a lower NTP time accuracy as well as larger sync intervals, which may not be optimal for good time accuracy.
For Chrony, a common issue with Windows NTP servers is that they report a very large root dispersion (e.g., three seconds or more), which causes chronyd to ignore the server for being too inaccurate.
It's recommended to configure the Windows NTP server with more strict and accurate time accuracy and sync intervals. See the following guides for more information on this:

• Windows high accuracy time

• Windows high accuracy time configuration guide

If you use Windows as the NTP server for an offline installation, the Windows NTP server may use the local CMOS clock time. By default, it will report a root dispersion of 10 seconds. See the following guides for more information on how to change this value:

LocalClockDispersion Entry

Windows Time service tools and settings

Peer clock stratum unspecified or invalid (0)

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

Maximum time difference

Counteract clock drifting
If the system clock has a significant drift, the Axis device's clock will never achieve a close enough offset to the NTP server. However, the system clock should not drift at a rate of that magnitude.

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

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.

Further reading

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

• RFC 2475 — An Architecture for Differentiated Services

• RFC 2597 — Assured Forwarding PHB Group

• RFC 2598 — An Expedited Forwarding PHB

• RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP

• RFC 1633 — Integrated Services in the Internet Architecture: an Overview

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

• A link-local IPv6 address is automatically configured.

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

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

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

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

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

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

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

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

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

Common IPv6 addresses and ranges

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:

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

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

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

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

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

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

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

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

• The supplicant responds to the challenge by the authenticator.

• The authenticator passes the response to the challenge onto the authentication server.

• If the supplicant provides proper identity, the authentication server responds with a success message to the authenticator.

• The success message is then passed onto the supplicant by the authenticator. The authenticator now allows access of the supplicant to the LAN, possibly restricted based on attributes that came back from the authentication server. For example, the authenticator might switch the supplicant to a particular virtual LAN or install a set of firewall rules.

It should be noted that setting up and configuring IEEE 802.1X is a fairly complex procedure, and it is important that RADIUS servers, switches, and clients (such as Axis devices) are set up correctly.

Web interface

To gain access to a protected network, the Axis device must have a CA certificate, a client certificate, and a client private key. These should be created by the servers and uploaded via a web interface. When the Axis device is connected to the network switch, the device will present its certificate to the switch. If the certificate is approved, the switch allows the device access on a preconfigured port. As pointed out previously, in order to use port-based authentication, the network must be equipped with a RADIUS server and a network switch with support for IEEE 802.1X. You may also need to contact your network administrator for information on certificates, user IDs and passwords depending on the type of RADIUS server that is used.

The settings here enable the Axis device to access a network protected by IEEE 802.1X/EAPOL (Extensible Authentication Protocol over LAN). There are many EAP methods available to gain access to a network. Before AXIS OS 11.6, 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.

The client and the RADIUS server authenticate each other using digital certificates provided by a PKI (public key infrastructure) signed by a certification authority. Note that to ensure successful certificate validation, time synchronization should be performed on all clients and servers prior to configuration. Further configuration of Axis devices should be performed on a safe network to avoid MITM (man in the middle) attacks. Terms used in the web interface are described as follows:

• CA certificate - The CA certificate is created by the certification authority for the purpose of validating itself and the Axis device needs it to check the server’s identity. Select the correct certificate that was uploaded previously in the security tab under CA certificates. From AXIS OS 10.1 and onwards, selecting no CA certificate (none) means the Axis device will skip doing any validation of the server's identity.

• Client certificate - The Axis device must also authenticate itself using a client certificate. Select the correct certificate that was uploaded previously in the security tab under client certificates.

• EAPOL version - Select the EAPOL version (1 or 2) used in your network switch.

• EAP identity - Enter the user identity associated with your certificate. A maximum of 16 characters can be used.

With AXIS OS 11.6 and later, we added support for EAP-PEAP/MSCHAv2 for wired connection. With AXIS OS 11.8 and later, customers can configure EAP-PEAP/MSCHAPv2 through the web interface.

• Client certificate - This is not needed for this authentication mode.

• CA certificate - Optional. The CA certificate is created by the certification authority for the purpose of validating the server’s identity by the Axis devices. No CA certificate (none) means the Axis device will skip doing any validation of the server's identity.

• EAP identity - The username for MSCHAPv2 authentication.

• EAPOL version - Select version 2.

• Password - The password for MSCHAPv2 authentication.

• Peap version - Select PEAPv0.

• Label - Select 1.

With AXIS OS 11.8 and later, IEEE 802.1AE MACsec capabilities were added to AXIS OS-based devices.

IEEE 802.1AE MACsec (Media Access Control Security) is a well-defined network protocol that cryptographically secures point-to-point ethernet links on network layer 2 ensuring the confidentiality and integrity of data transmissions between two hosts.

* List of example network protocols used by Axis devices that are protected by IEEE 802.1AE MACsec. MACsec adds protection to network protocols without native security capabilities and adds an additional layer of protection as well to network protocols with built-in security.

Unlike protocols such as IPSec which operates at Layer 3 as an end-to-end technology, MACsec encrypts each frame that leaves the Ethernet LAN and decrypts the frames as it enters the Ethernet LAN. In order to achieve end-to-end network encryption using MACsec, all links/hops in between source and destination need to have MACsec enabled to ensure traffic traversing across a network is MACsec protected.

A single link/hop that does not support MACsec will therefore leave network traffic unencrypted from that link/hop to the next.

Not only does MACsec prevent unauthorized access to network data streams through strong encryption but also prevents man-in-the-middle attack scenarios. Because MACsec operates at the low layer 2 of the network stack, it adds an additional layer of security to network protocols that do not offer native encryption capabilities (ARP, NTP, DHCP, LLDP, CDP…) as well as ones that do offer it alike (HTTPS, TLS). The illustration below outlines the MACsec frame.

A Security Tag (SecTAG) containing MACsec parameters is inserted immediately after the source mac address in the Ethernet Header. The Integrity Check Value(ICV) is calculated via an agreed algorithm by the sender and attached to the frame. When the receiver receives the frame, it will use the same algorithm to calculate the ICV again and compare it with the one attached to the packet. The integrity is confirmed if the two ICV values are identical which means the packet is not tampered.

Terminologies

The MACsec Key Agreement (MKA)

When implementing MACsec between two devices, the MACsec Key Agreement(MKA) protocol provides and manages the session keys. The MKA protocol relies on the EAP framework to establish the communication. The two devices establish a unique connectivity association. Within the CA, there are two secure channels, one for inbound traffic, and the other one for outbound traffic. The two devices use the same cipher suite for data encryption.

MACsec Ciphers

To protect the confidentiality of the data traveling through the MACsec Secure Channel, the packets are encrypted by the industrial standard GCM-AES-128 or GCM-AES-256 cipher suites. There are another two cipher suites GCM-AES-XPN-128 and GCM-AES-XPN-256. XPN standards for Extended Packet Numbering, these two ciphers are generally used on high-speed links.

In the current implementation, AXIS OS supports GCM-AES-128 cipher suite only. Additional cipher suites can be added on demand.

MACsec modes

The IEEE 802.1AE MACsec standard describes two modes of operation, a manually configurable Pre-Shared Key (PSK)/Static CAK mode and an automatic Master Session/Dynamic CAK mode using IEEE 802.1X EAP-TLS sessions. The Pre-Shared Key mode is recommended to be used when the connecting network switch is not capable of supporting auto-negotiation through IEEE 802.1X EAP TLS.

Since IEEE 802.1X EAP-TLS is enabled by default and through that, MACsec Master Session/Dynamic CAK mode is also automatically enabled. When plugging in a factory defaulted Axis device, IEEE 802.1X network authentication will be tried and when successful, MACsec Dynamic CAK mode will be tried as well. If the connected switch does not support IEEE 802.1X EAP TLS and/or MACsec Dynamic CAK, then the Axis device will simply connect anyway without further enforced security mechanisms.

In pre-shared key(PSK) mode, also known as static CAK mode, the MACsec implementation is comprised of three phases: PSK configuration, MKA key negotiation and MACsec data encryption and decryption.

This mode requires the user to configure the to-be-used pre-shared key on both devices, the Axis device and the network switch. Every PSK consists of two fields: a connectivity association key name (CKN) and a connectivity association key (CAK). The CKN and CAK must match on both ends of the ethernet link.

Once the pre-shared key is verified, the MKA protocol is enabled to maintain the MACsec session on the link. One participant on the link will be elected as the key server and its primary responsibility is to generate, distribute and refresh the Secure Association Key(SAK). The SAK is the actual key used for encrypting the data. The MKA protocol limits the number of frames that can be protected with a single SAK. When the Packet Numbers (PNs) in an SA are exhausted, the corresponding SAK will be refreshed.

Axis device configuration

To configure the MACsec PSK in AXIS OS devices, go to System > Security > IEEE 802.1ae MACsec > Mode, select “Static CAK / Pre-Shared Key(PSK)” mode.

The CAK must be either 16 bytes (32 hexadecimal characters) or 32 bytes (64 hexadecimal characters). The CKN must be 1 to 32 bytes (2 to 64 and divisible by 2) hexadecimal characters.

At the time of writing this article, please also check the box to enable IEEE 802.1x before saving the configuration. When MACsec is secured, the status of IEEE 802.1x will show “authorized”. We are in the process of optimize this as MACsec PSK mode doesn’t work in conjunction with 802.1x.

Switch configuration

The below configuration example is outlined using the Aruba CX switch series.

1. Configure the MACsec policy

switch(config)# macsec policy axis_ms_policy
switch(config-macsec-policy)# cipher-suite gcm-aes-128
switch(config-macsec-policy)# replay-protection window-size 100
switch(config-macsec-policy)# exit
switch(config)#

2. Configure the MKA policy

switch(config)# mka policy axis_mka_policy
switch(config-mka-policy)# pre-shared-key ckn 00112233445566771111111111111111 cak plaintext 00112233445566771111111111111111
switch(config-mka-policy)# key-server-priority 5
switch(config-mka-policy)# exit
switch(config)#

3. Apply the MAC on the switch port

switch(config)# interface 1/1/28
switch(config-if)# apply macsec policy axis_ms_policy
switch(config-if)# apply mka policy axis_ms_policy
switch(config-if)# exit
switch(config)#

When implementing MACsec in conjunction with EAP-TLS, the Authenticator or the access switch performs the 802.1x authentication against the devices first. Once authentication is successful, the Radius server sends the master session key (MSK) to the switch and the device. The CAK and CKN will be derived from the MSK by both parties.

Following that, the MKA protocol is enabled on both parties on the link to start the MACsec session. Same as the PSK mode, one of the parties will be elected as the key server to manage the SAK keys. Once the SAK key is exchanged between the parties, the MACsec encryption and decryption starts.

Axis device configuration

Since AXIS OS 10.1 (September 2020), IEEE 802.1X is enabled in the factory default state using the IEEE 802.1AR-compliant Axis device ID certificate. The Axis device will automatically try to authenticate against an IEEE 802.1X-enabled network. For manual IEEE 802.1X configuration, please refer to the AXIS OS Knowledge base. To use 802.1x port-based authentication, the network must be equipped with a RADIUS server and a network switch with support for IEEE 802.1X and IEEE 802.1AE MACsec. You may also need to contact your network administrator for information on certificates and further configuration of the RADIUS server.

Once the 802.1x authentication is done, if the switch supports MACsec, the MACsec talk will happen accordingly.

Freeradius Server configuration

Once the Freeradius server is up and running, there is just one additional step needed to enable the usage of MACsec through the Freeradius server side. The FreeRADIUS server in this case needs to send the EAP-KEY-NAME attribute for the switch to derive the Session-ID used in creating the CKN and CAK for MKA.

To enable FreeRADIUS to send the EAP-Session-ID in Access-Accept frames, please uncomment the following lines inside:

/etc/freeradius/sites-enabled/default for FreeRADIUS 2.x

or

/etc/freeradius/3.0/sites-enabled/default in case of FreeRADIUS 3.x

In this document, we are using the Aruba CX switch series that requires a User-Role after the 802.1x authentication to trigger the MACsec. The “Aruba-User-Role” is a vendor-specific-value sent from the FreeRadius server to the Aruba switch based on the EAP-identity configured in the AXIS OS devices. To do that, please add below to the file /etc/freeradius/3.0/users.

Aruba ClearPass Policy Manager configuration

Please follow the instructions here to securely onboard the Axis devices into Aruba networks. The integration guide outlines example configurations in great detail using IEEE 802.1AR and 802.AE MACsec for secure zero trust network integration of Axis devices into Aruba networks. The “Aruba-user-Role” attribute must also be dispatched from the ClearPass Policy Manager to the switch.

Aruba switch configuration

1. Configure the MACsec policy

switch(config)# macsec policy macsec-eap
switch(config-macsec-policy)# cipher-suite gcm-aes-128
switch(config-macsec-policy)# replay-protection window-size 100
switch(config-macsec-policy)# exit
switch(config)#

2. Configure the port-access role

switch(config)# port-access role axiscamera
switch(config-pa-role)# associate macsec-policy macsec-eap
switch(config-pa-role)# auth-mode client-mode

3. enable MACsec on the port

switch(config-if)# aaa authentication port-access dot1x authenticator
switch(config-if-dot1x-auth)# macsec
switch(config-if-dot1x-auth)# mka cak-length 16

The cak-length should be configured to 16 bytes for the dot1x authentication mode in our current implementation.

Verify the MACsec status on the AXIS OS devices:

Below is what the MACsec frames look like when doing a packet trace from the camera directly. Go to System > Logs > Network trace.

Verify the MACsec status on the Aruba Switch:

switch# show macsec status
MACsec Protocol Status
 Interface  Port ID  Policy                    Protection           Status  State
 ---------- -------- ------------------------- -------------------- ------- --------------
 1/1/27     1        macsec-eap                IC, Conf, Offset 0   Up      Retire
 1/1/28     1        axis_ms_policy            IC, Conf, Offset 0   Up      Retire

SW23# show mka policy
MKA Policy Details
===================
  Policy Name: MKA_Auth_1/1/27_b8a44f4645f4
  ---------------------------------------------------------------------------
    Mode                     : EAP-TLS
    CKN                      : b0d80475242fbcd5c97ece50670e4dfe
    CAK (encrypted)          : AQBapQh5tkM/wWCQLE4jp0G/Iu6IfO+QutBMu8gFBKf...
    Key-server Priority      : 0
    Transmit Interval        : 2 seconds

  Policy Name: axis-mka_policy
  ---------------------------------------------------------------------------
    Mode                     : Pre-shared key
    CKN                      : 00112233445566771111111111111111
    CAK (encrypted)          : AQBapcO5rGnurI1zhrDB3JVwhbLmJhcgQkiRWgiJtfK...
    Key-server Priority      : 5
    Transmit Interval        : 2 seconds

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’s recommended to disable the WS-Discovery after usage since it is vulnerable to attacks as described in this security advisory. See instructions below on how to disable WS-Discovery.

AXIS OS > 9.70
Disable the service by disabling the parameter Enable WS-Discovery discoverable mode in Settings > System > Plain config > WebService > DiscoveryMode > Enable WS-Discovery. For multiple device configuration in AXIS Device Manager, the corresponding VAPIX parameter is called DiscoveryMode.Discoverable.

AXIS OS 5.70 — 9.60

• Enable SSH in Plain config > Network > SSH and connect to the Axis device via Putty

• Type the following commands, each followed by pressing ENTER

• • systemctl mask wsdd

  • systemctl mask wsd

  • systemctl mask wsd.socket

  • systemctl stop wsdd

• Disable SSH again from Plain Config and restart the device

AXIS OS 5.60

• Enable SSH in Plain Config > Network > SSH and connect to the Axis device via Putty

• Type the following commands, each followed by pressing ENTER

• • rm /etc/rc3.d/S92wsdd

  • /etc/init.d/wsdd stop

• Disable SSH again from Plain Config and restart the device

AXIS OS < 5.50

• Enable Telnet and connect to the Axis device via command-line tool. Go to Telnet access.

• 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

Bonjour is Apple’s implementation for zero-configuration networking. A method that helps the users to find services on a local network. By using mDNS and DNS-SD protocols, Bonjour covers three major areas:

1. Addressing
   Bonjour self-assigns a link-local address if no DHCP server is present in the network. For IPv4, randomly selected from 169.254.0.0/16. For IPv6, the address is assigned from fe80::/10.

2. Hostname to IP address translation
   Bonjour uses multicast DNS (mDNS) in the local network to resolve a hostname.

3. Service Discovery
   Bonjour discovers the available services in the local network via DNS service records.

The mDNS protocol resolves the hostname to the IP address without relying on a conventional unicast-based DNS server in a local network. The mDNS messages are sent through multicast (IPv4: 224.0.0.251 or IPv6: ff02::fb) to UDP port 5353. The Axis device will select a domain name with the prefix “.local”, which only works with mDNS within the local network. An example domain name is “AXIS P1375.local”.

To discover a service and use that service in the network by a client, several DNS records are used in the process:

Prior to AXIS OS 11.4, AXIS OS products used Bonjour to announce their presence in the network. Starting from AXIS OS 11.4, we added new service names — vapix-http and vapix-https — to simplify the discovery of Axis devices and better comply with the RFC 6763 specification. In the table below, you can see some examples of service names used on AXIS OS devices.

*VAPIX is Axis own open API (Application Programming Interface) to our products, using standard protocols that enable integration into a wide range of solutions on different platforms.
** Example: AXIS P1375 - B8A44F42B4C6
*** Example: AXIS P1375. If you add a second device of the same model, the second one will be named AXIS P1375 (2) and so on.
**** param stands for param.cgi, apidisc stands for apidiscovery, and decaf stands for device configuration framework. Decaf was added in AXIS OS 11.11 and is included in all subsequent versions.
***** This field is used by services to indicate temporary roles.

AXIS OS < 11.4
In the below example, an Axis P1375 camera is running on the AXIS OS version earlier than 11.4. We use AXIS IP Utility to discover an Axis device. AXIS IP Utility sends a query message including PTR record. Querying a service instance called “_axis-video._tcp.local”.

Once the Axis device receives the query message, it will respond with a mDNS query response containing the PTR record and additional records.

“AXIS P1375 - B8A44F42B4C6” is the service instance name. “_axis-video._tcp” is the service type that identifies what the service does and its transport protocol. In this example, the Axis device announces itself by providing the “_axis-video” service through TCP. The TXT record contains the mac address information of the Axis device.

AXIS OS ≥ 11.4
Below is another example that the same Axis P1375 camera running on version 11.4. The camera announces the service instance as “AXIS P1375._vapix-http(s)._tcp.local”. In the TXT records, additional information has been included there.

The devices are still announcing all the previous service names at the same time for the time being. So the VMSs and other clients should still be able to discover the Axis Devices, see below.

The default instance name (in the webpage, we call “Bonjour name” or “Friendly name”) can be changed when needed:

After changing the friendly name, it will apply to all services.

This section describes how to use Axis Video SNMP MIB. It’s assumed that you are familiar with the Simple Network Management Protocol (SNMP) already.

SNMP/MIBs allow network management operators to use standard SNMP tools to monitor the status of Axis products. The Axis Management Information Base (MIB) for video hardware enables monitoring of hardware-related issues that may need administrative attention. This applies to devices with AXIS OS 5.60 and higher. Note that new functionality may be added in later releases. For detailed information, read the MIB file.

Some products will not have all the hardware as specified below and there will only be one MIB defined for all hardware. In case the agent requests the status of hardware that is not included in the product, the device will return "noSuchObject". Which hardware is supported is handled at run time, meaning there is no need for product specific configuration. All Axis devices support the Axis Video MIB from AXIS OS 5.60 and higher except for AXIS Companion Line devices, however it’s recommended to update to the latest version. These MIBs are required to use Axis Video MIB:

• SNMPv2–TC

• SNMPv2–SMI

• SNMPv2–CONF

• AXIS-ROOT-MIB

• AXIS-VIDEO-MIB

To use this functionality, SNMP must be enabled in the cameras and encoders on the network. 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.

To use SNMPv3, HTTPS has to be enabled. For information about how to enable HTTPS, see the user manual for the device.

You can use AXIS Device Manager to enable SNMP on multiple devices. AXIS Device Manager is available for download from www.axis.com.

To enable SNMPv3 in Axis devices, a password must be set in the web interface for the default SNMP user initial. Once SNMPv3 is enabled, the following default privacy and authentication modes are pre-configured:

Note that it’s currently not possible for the user to change the default privacy and authentication modes in an easy way.

All Axis devices support the default SNMP MIB-II traps (Cold start, Warm start, Link up, Authentication failed). In addition, Axis devices support a number of feature and product specific traps that are included in Axis Video MIB (described in Axis Video MIB traps). Depending on your SNMP version, different configurations are required/available for using SNMP traps.

SNMPv1/v2c trap configuration
When SNMPv1 and SNMPv2c are used, all Axis Video MIB traps documented in Axis Video MIB traps will be enabled and sent when SNMP traps are enabled. The default MIB-II SNMP traps can be configured and enabled/disabled individually:

• Cold start - sent when SNMP has been started and the configuration and MIB have changed

• Warm start - sent when SNMP has been started and the configuration has changed, but not the MIB

• Link up – sent when the network link changed from down to up

• Authentication failed – sent when snmp-authentication attempt failed

SNMPv3 trap configuration
For SNMPv3, both the default MIB-II SNMP traps as well as the Axis Video MIB traps need to be configured and enabled manually. This is done using the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB modules, defined in RFC 3413. So in order to configure the Axis device to send out SNMP traps, the following tables need to be configured accordingly:

• snmpNotifyTable

• snmpTargetAddrTable

• snmpTargetParamsTable

• snmpNotifyFilterProfileTable

• snmpNotifyFilterTable

Axis Video MIB (Message Information Base) extends the way to monitor Axis devices over SNMP. The Video MIB enables network administrators to monitor status information and a number of new notifications. To make use of the Axis Video MIB, download the MIB files here and import them in your SNMP network monitoring application. The Axis Video MIB is supported by Axis network devices from AXIS OS 5.60 and higher.

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.

_{*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}

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.

The screenshots below illustrates how to import Axis Video MIB files into the iReasoning MIB Browser.

The screenshots below illustrate how to do an SNMP walk on an Axis device. Note that SNMP needs to be enabled.

SNMPv1/2

SNMPv3

The screenshots below illustrate how to receive an SNMP trap from an Axis device. Note that SNMP traps need to be enabled.

All Axis devices with AXIS OS 7.10 and higher are utilizing LLDP (Link Layer Discovery Protocol) to neighbor-announce their identity and capabilities information using the TLV-encoding scheme (Type-Length-Value) in the network. When sending out LLDP announcements, it is possible to configure certain information such as system description and name of the device. In order to configure specific LLDP settings, you can access the device via SSH, SSH is disabled per default and can be enabled in Settings > System > Plain config > Network. Once SSH access is established, type "lldpcli". See the following instructions for further commands that can be used in the LLDPCLI.

In addition to neighbor announcements, LLDP can also be used for software-based PoE negotiation. IEEE 802.3at (30 W PoE+) capable devices support software-based PoE negotiations, and IEEE 802.3af (15.4 W) capable devices running AXIS OS 9.20 and higher support the LLDP allocation of max-power towards the connected PoE-switch. When enabled, the Axis device will notify the PoE-switch about its max PoE consumption so that the PoE-switch can perform a better PoE-management and allocate less PoE to the network port. LLDP allocation for max-power can be enabled in Settings > System > Plain config > Network > LLDP POE > LLDP Send Max PoE. Both methods utilize the LLDP Dot3 PoE-MDI TLV.

When LLDP allocation for max-power is enabled in the Axis device, and the network switch is configured properly in regards to LLDP- and PoE-mode according to vendor documentation, the network switch should be able to reserve the exact amount of max PoE wattage that the Axis device would need. The example below illustrates the behavior of LLDP allocation for max-power being enabled and disabled in an Axis device.

When LLDP allocation for max-power is disabled, the network switch will reserve the full amount of 15.4 W PoE according to IEEE 802.3af with no savings gained. Compare this with having the LLDP allocation for max-power enabled, which will result in the network switch reserving in total 11.3 W PoE instead, where 9.6 W results from the needs of the Axis device and the additional 1.7 W is a margin for power loss due to cable length. This improved PoE management results in saving 4.1 W PoE that can be used on a different network port on the same network switch.

Media Endpoint Discovery (LLDP-MED)
LLDP-MED (Media Endpoint Device Extension) is an extension on top of the LLDP protocol stack that allows devices to include more information (TLVs) during LLDP exchange with network neighbors. At the time of writing (December 2020), Axis devices do not support LLDP-MED extensions and therefore do not support e.g. the LLDP-MED POE-MDI TLV for PoE power negotiation.

Fabric Attach (FA) is a technology developed by Extreme Networks. It comes with an Autonomic Edge capability which simplifies the addition of new devices to the network. Axis devices with AXIS OS 12.1 or later have the Basic Fabric Attach client capability, which reduces the time and cost to deploy them in Extreme Networks with “Zero-Touch”. For a complete list of products supporting Fabric Attach, please refer to Products on active track in AXIS OS Release notes.

Fabric Attach uses the Link Layer Discovery Protocol (LLDP) with custom organizational Type-Length-Values (TLVs) to automate the onboarding process for network devices onto different networks or services. As a Basic Fabric Attach client, Axis devices generate a Fabric Attach Element TLV which includes the following properties:

• Fabric Attach Element type

• A System ID with the device's MAC Address

The screenshot below provides a closer look at the LLDP packet structure for an Axis device.

The following applies for all Axis devices:

• Fabric Attach Element Type is always set to 11 (IP camera).

• System ID contains your device’s unique MAC address.

• LLDP is enabled by default.

• The FA Element TLV is included in every outgoing LLDP packet.

Extreme Networks has four FA client variants. Axis devices act as Basic FA clients with minimal implementation, which allows you to bypass authentication for the FA Element TLV. As a result, the HMAC-SHA digest value is always zero.

Example setup

In this scenario, the customer has a dedicated network segment, VLAN 202.

Previously, to onboard a camera, the customer would connect it to a physical switch port and then manually assign that port to VLAN 202. Fabric Attach simplifies the onboarding process.

1. By default, all ports on the Extreme Networks Fabric Engine switch are set for auto-sense.

2. The customer connects the Axis device to Port 2, which has Fabric Attach enabled. Once the device is powered on, it starts sending LLDP packets.

3. Using the FA Element TLV, the switch identifies the device as an IP Camera and automatically moves Port 2 to VLAN 202 with no manual intervention required.

To verify the Fabric Attach status on the Extreme Network switch:

SW24.14 # show fabric attach elements
Fabric Attach Mode: Standalone Proxy
                                                       Mgmt     Auto
System Id                     Port    Type             VLAN Tag Provision
----------------------------- ------- ---------------- ---- --- --------------
b8-a4-4f-28-25-d1-00-00-00-00 2       IP Camera        None Mix Disabled

SW24.15 # show fabric attach assignments
Fabric Attach Mode: Standalone Proxy
Port     VLAN  VLAN Name                         Type     ISID/NSI  Status
-------  ----  --------------------------------  -------  --------  --------
          202  VLAN_0202                         Static   N/A       Active
2         202  VLAN_0202                         ZTC      N/A       Active

The type ZTC stands for Zero Touch Client. The minimal configurations of Fabric Attach have been included below for reference.

configure fabric attach uplink 24
configure fabric attach zero-touch-client camera vlan VLAN_0202 nsi 12345
configure fabric attach zero-touch-client camera enable
configure vlan VLAN_0202 add nsi 12345

All Axis devices with AXIS OS 8.50.1 and higher are utilizing the CDP (Cisco Discovery Protocol) protocol to announce their identity and capabilities in the network. Compared to the LLDP protocol, no CDP traffic is sent out from the Axis device by default unless the network switch initiates CDP communication first.

CDP is also used for power negotiation in IEEE 802.3at (30W PoE+) capable devices. By default, the Axis device is capable of power negotiating IEEE 802.3at (30W PoE+) either using CDP or LLDP. Which one of these protocols is used depends on the network switch configuration.

In a situation where both protocols are being enabled and used by the network switch, the Axis device will respond to the protocol that arrives first (first come, first served). Note that Cisco 60W UPoE power negotiations are not supported regardless if they are hardware- or software-based.

Syslog 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. With AXIS OS 11.6 and later, we introduced our own proprietary format called “Axis” format that is mainly for our internal use. It’s the same format that we currently using in our server report logs. Please be noted that Axis may change this format without prior notice.

• Log message severity: Log messages are categorized in severities based on importance, from low to high. In newer AXIS OS versions, 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

RFC 3164

<8>Aug 23 16:32:18.000 axis-b8a44f18d105 remote-syslogd: remote-syslogd-test: This is Emergency message
<9>Aug 23 16:32:18.000 axis-b8a44f18d105 remote-syslogd: remote-syslogd-test: This is Alert message
<10>Aug 23 16:32:18.000 axis-b8a44f18d105 remote-syslogd: remote-syslogd-test: This is Critical message
<11>Aug 23 16:32:18.000 axis-b8a44f18d105 remote-syslogd: remote-syslogd-test: This is Error message
<12>Aug 23 16:32:18.000 axis-b8a44f18d105 remote-syslogd: remote-syslogd-test: This is Warning message

 RFC 5424

<8>1 2023-08-23T16:34:23.000+02:00 axis-b8a44f42b8b0 remote-syslogd - - - remote-syslogd-test: This is Emergency message
<9>1 2023-08-23T16:34:23.000+02:00 axis-b8a44f42b8b0 remote-syslogd - - - remote-syslogd-test: This is Alert message
<10>1 2023-08-23T16:34:23.000+02:00 axis-b8a44f42b8b0 remote-syslogd - - - remote-syslogd-test: This is Critical message
<11>1 2023-08-23T16:34:23.000+02:00 axis-b8a44f42b8b0 remote-syslogd - - - remote-syslogd-test: This is Error message
<12>1 2023-08-23T16:34:23.000+02:00 axis-b8a44f42b8b0 remote-syslogd - - - remote-syslogd-test: This is Warning message

Axis format

2023-08-23T16:30:14.998+02:00 axis-b8a44f4645f4 [ EMERG ] remote-syslogd[209665]: remote-syslogd-test: This is Emergency message
2023-08-23T16:30:14.998+02:00 axis-b8a44f4645f4 [ ALERT ] remote-syslogd[209665]: remote-syslogd-test: This is Alert message
2023-08-23T16:30:14.998+02:00 axis-b8a44f4645f4 [ CRIT ] remote-syslogd[209665]: remote-syslogd-test: This is Critical message
2023-08-23T16:30:14.998+02:00 axis-b8a44f4645f4 [ ERR ] remote-syslogd[209665]: remote-syslogd-test: This is Error message
2023-08-23T16:30:14.998+02:00 axis-b8a44f4645f4 [ WARNING ] remote-syslogd[209665]: remote-syslogd-test: This is Warning message

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:

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

Web interface
Devices with AXIS OS 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.

See the sample illustrations below 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)
Devices with AXIS OS 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, go to the VAPIX library.

AXIS Device Manager
With the introduction of the new Remote Syslog API, it’s also possible to configure remote syslog settings for multiple Axis devices simultaneously.

Script editor
In order to configure remote syslog server, the script editor needs to be enabled. This can be done via the web interface of the Axis device, under Settings > System > Plain config > System > Enable the script editor (editcgi).

To configure syslog, open the following link in the browser, replace the IP adress placeholder ("ip_of_cam") with the real IP address of the Axis device: http://ip_of_cam/admin-bin/editcgi.cgi?file=/etc/syslog-ng.d/remote.conf

Add IP address, transport method and port as you see in the below example configuration. Click Save file once done and restart the device.

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 AXIS OS version, starting from FW 5.60.

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.

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.

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 is a machine-to-machine (M2M)/Internet of things (IoT) connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport and is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium.

MQTT is quickly becoming the standard communication protocol for implementing IoT solutions due to its lightweight and bandwidth-efficient characteristics. You can read more about benefits and usecases in the whitepaper Device integration with MQTT or keep on reading to learn more about configuring MQTT, starting with the most important components.

Client
Any publisher or subscriber that connects to a centralized server/broker over a network is a client. Both publishers and subscribers are called clients since they connect to a centralized service. Clients can be persistent or transient. Persistent clients maintain a session with the server/ broker while transient clients are not tracked by the server/ broker. Clients often connect to the server/ broker through libraries and SDKs.

Server/broker
The server/broker is the software that receives all the messages from the publishing clients and sends them to the subscribing clients. It holds the connection to persistent clients. Since the server/broker can become a bottleneck or result in a single point of failure, it is often clustered for scalability and reliability. It is up to the implementor to decide how to create a scalable server/broker infrastructure. Some of the commercial implementations of MQTT brokers include HiveMQ, Xively, AWS IoT and Loop.

Topic
A topic in MQTT is an endpoint information that a client (publisher) can share, and another client (subscriber) can connect to. Topics are simple, hierarchical strings, encoded in UTF-8, delimited by a forward slash. For example, "building1/room1/temperature" and "building1/room1/humidity" are valid topic names.

Connection
MQTT can be utilized by clients based on TCP/IP. The standard port exposed by servers/brokers is 1883, which is not a secure port. Servers/brokers that support TLS/SSL typically use port 8883. For secure communication, the clients and the server/broker rely on digital certificates.

Axis devices with AXIS OS 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.

In the following sections you can read more about configuring a device via the web interface.

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

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.

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.

To determine which topics are supported by an Axis device, you can use the following API calls in VAPIX or ONVIF. Although it's possible to run these commands within the SSH console from the camera, we recommend using a tool like CURL or POSTMAN instead. This approach doesn't require enabling SSH access to the device.

If you prefer to use SSH, go to Plain config > Network > SSH and log in directly to the AXIS device.

For more information about Postman and CURL, see VAPIX.

VAPIX interface
Make a GetEventInstances request to VAPIX web services as in the example below, but replace the username, password and IP address with the actual configured settings:

curl --noproxy "*" --user <username>:<password> --digest --request POST 
'http://<device-address>/vapix/services' \
--header 'Content-Type: application/soap+xml;
action=http://www.axis.com/vapix/ws/event1/GetEventInstances; Charset=UTF-8' \
--data-raw '<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<SOAP-ENV:Body>
		<m:GetEventInstances xmlns:m="http://www.axis.com/vapix/ws/event1"/>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>'

ONVIF interface
Make a GetEventProperties request to ONVIF event services as in the example below, but replace the username, password and IP address with the actual configured settings:

curl --noproxy "*" --user <username>:<password> --digest --request POST
'http://<device-address>/onvif/services' \
--header 'Content-Type: application/xml' \
--data-raw '<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
 xmlns:wsa="http://www.w3.org/2005/08/addressing"
 xmlns:tet="http://www.onvif.org/ver10/events/wsdl">
	<SOAP-ENV:Header>
		<wsa:Action>
http://www.onvif.org/ver10/events/wsdl/EventPortType/GetEventPropertiesRequest
 </wsa:Action>
	</SOAP-ENV:Header>
	<SOAP-ENV:Body>
		<tet:GetEventProperties>
 </tet:GetEventProperties>
	</SOAP-ENV:Body>
</SOAP-ENV:Envlope>'

Output examples

onvif:Device/axis:Status/SystemReady
onvif:Device/axis:IO//.
onvif:RuleEngine/MotionRegionDetector/Motion
axis:CameraApplicationPlatform/VMD/Camera1ProfileANY

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.

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

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.

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’s 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 about 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. For more information, see MQTT QoS settings.

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 as "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

In addition to the generic MQTT events that come with predefined topics and payloads, the Publish MQTT action rule can be triggered by any of the available device events and send a message with a custom topic and payload.

In the below example the Axis device is publishing a message to the topic "P1375/ManualTrigger/Custom/Topics/" carrying the payload "Manual Trigger is activated". The topic can include up to 1024 characters and the payload’s limit is set to 8192 characters.

This video illustrates how the action rule is set up:

Custom MQTT event subscription is available from AXIS OS 10.7 and onwards and makes it possible for the Axis device to subscribe to a topic when connecting to the MQTT broker. Once subscribed, the Axis device will listen to new incoming messages and will be able to act on it, e.g. by configuration of an action rule in the built-in event system.

See how it’s configured in this video:

With AXIS OS 11.4 and subsequent versions, you can overlay MQTT subscription data onto the video stream. In this section, we guide you through the process of implementing this feature.

First, make sure the device can successfully publish MQTT messages to the broker. In the screenshot below, we have a door monitor that can publish the door status among other information to the broker.

In the Axis device web interface, go to System > MQTT > MQTT client and fill in the necessary information for the MQTT broker based on your setup. Once finished, you should be able to see the MQTT connection status has changed to Connected.

After that, you can create MQTT overlays in the Axis device. Go to System > MQTT > MQTT overlays and click Add overlay modifier.

There are two types of modifiers:

• #XMP: The payload tag. The overlay modifier with #XMP form contains the entire payload of a published MQTT message.

• #XMD: The data tag. The overlay modifier with #XMD form contains the JSON value of a key in the payload of a published MQTT message.

Let’s take a second look at the door monitor. In the published message, there’s a section called “announce”:

Enter shellies/announce in the Topic filter. Click Save to subscribe to this topic and use it as an overlay.

This will generate a modifier called #XMP0.

On the same page, click Overlays. On the Overlays page, you can see the entire payload of the message as an overlay in the live view.

You can also choose to only overlay a specific part of the message, such as the IP address of the door monitor. That’s what the #XMD modifier is used for.

Go to System > MQTT > MQTT overlays and click Add overlay modifier. Enter shellies/announce in the Topic filter and ip in the Data field. Finally, click Save.

You should now see a new overlay modifier in the list:

On the same page, click Overlays. On the Overlays page, create a new text overlay with #XMD1 in the string. For example, The IP address of the door monitor is: #XMD1. In the overlay, #XMD1 will be replaced by the door monitor’s IP address.

In some scenarios, subscribed messages include a lot of information in JSON format. Objects might also be nested within other objects, as in the example below.

To overlay the number of humans, for instance, you would enter message.data.human in the overlay modifier Data field.

With AXIS OS 11.8 and later, the MQTT graph overlay feature has been added to ARTPEC- 8 products as well (except the fisheye and panoramic cameras). The steps to create the MQTT overlays are the same aside from the final step to add the overlays in the video stream. Instead of overlaying the MQTT data in text format, it’s displayed in graphs.

In the following example, we’ll use the MQTT graph overlay to display the room temperature and the battery level, drawn from the door monitor data below:

Go to System > MQTT > MQTT overlays and click Add overlay modifier . Create one for the door monitor’s room temperature and another for the door monitor’s battery level.

Once created, both overlay modifiers should be visible on the list.

On the same page, click Overlays. On the Overlays page, create a new Widget: Linegraph overlay.

Select ##XMP0 as the overlay modifier.

Create another graph overlay for the battery level of the door monitor. This time, use Widget: Meter instead. Select #XMP1 as the overlay modifier.

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.

Step 1: Eclipse Mosquitto configuration
For a common Mosquitto MQTT broker configuration based on Linux Ubuntu 18.04, see this guide. 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

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.

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

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.

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.

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.

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.

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

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.

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.

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

Using the OAuth 2.0 OpenID Connect protocol, AXIS OS devices running AXIS OS 11.6 or higher can be integrated into a IT-infrastructure controlled and centralized Identity and Access management (IAM) service allowing to use federated identities for authenticating to the Axis device. This removes the need of local device user management entirely. OpenID Connect is a standardized network protocol on top of OAuth 2.0 used for authentication and authorization of identities that can be used in various different Identity Provider or Active-Directory Federated System (ADFS) solutions such as Microsoft Active Directory, Microsoft Azure AD, Curity Identity Server and others.

For a complete list of OpenID Connect certified solutions, please go to the official OpenID Connect page. Depending on the feature set of the Identity Provider, the following security mechanism could be used to allow for further enhanced secure identity-based authentication towards the Axis device:

• Multi-Factor Authentication (MFA)

• Password Complexity Enforcement

• Password Rotation

• Time-limited authentication

• Centralized identity (user/service account) management

Benefits

• Local Axis device account (e.g. root, user-created accounts) are disabled.

• HTTP(S) digest authentication is disabled.

• No local Axis device user and password management configuration or maintenance needed.

• Increased security by avoiding local device user account information leakage.

• Axis devices integrate seamlessly into IT-infrastructure supported secure Identity and Access Management (IAM).

• HTTP(S) web-interface access and tunneled video streaming is supported.

• IT enforced IAM security policies, traceability and security audit logging.

Limitations

Please note that there are currently limitations/considerations that need to be taken into account when the Axis device is operated in OpenID connect mode:

• The Video or Device Management System that is connecting to the Axis device also needs to support OpenID Connect to interact with the Axis device. Please contact your 3^rd party Video and Device-Management System vendor for further information.

• Video Streaming through RTSP-server authentication is not supported.

• AXIS Device Management solutions (ADM5, ADMX) as well as AXIS Companion and AXIS Camera Station are currently not supported.

• Access-Token according to OAuth 2.0 are not supported.

Function Overview

• Classic Access Model

• 

• OpenID connect

• 

In this section you can read about the configuration steps required to connect an Axis device to a Curity Identity Server. Please see the Curity website for further reading about the Curity Identity Server.

Curity Identity Server setup

1. Following the getting started guide described on the Curity website should supply you with a basic setup to integrate an Axis device into Curity Identity Server. Please note you should configure trusted certificates. Please refer to the Curity Identify Server documentation on how this is done.

2. Navigate to Token Service >Client and create a new client. Enter a client id and document it.

3. Add a new capability, choose Code Flow and Introspection.

4. 

5. Define a redirect URI. This should be device unique.

6. 

7. Define a client secret and document it.

8. 

9. Define a user authentication method. During the getting started steps a default username-password page was created which we use in this example.

10. 

11. Add a scope and enter email, openid and profile.

12. 

13. The overview now should look like this:

14. 

15. In the Security tab, under Origins and Validation, please add the hostname of your device.
    

16. 

17. Under Changes in the menu, select to Commit your changes.
    

18. 
20. Axis device parameters

21. Parameter	Value
    OIDC_AuthzAdminClaim	Value of the issuer property from the ProviderMetadataURL. Example “issuer:https://curity_server/oauth/v2/oauth-anonymous”
    OIDC_AuthzOperatorClaim	Value of the issuer property from the ProviderMetadataURL. Example “issuer:https://curity_server/oauth/v2/oauth-anonymous”
    OIDC_AuthzViewerClaim	Value of the issuer property from the ProviderMetadataURL. Example “issuer:https://curity_server/oauth/v2/oauth-anonymous”
    OIDC_ClientID	The client ID obtained during step 2.
    OIDC_ClientSecret	The client secret obtained during step 10
    OIDC_OutgoingProxy	Not used in this example but if required for your setup, specify here the outgoing proxy.
    OIDC_ProviderMetadataURL	https://curity_server/oauth/v2/oauth-anonymous/.well-known/openid-configuration
    OIDC_RemoteUserClaim	This is the value used by the web interface to display the logged in user. Possible values can be found in the ProviderMetadataURL > claims_supported. Example “sub”
    OIDC_RequireClaim	Value of the issuer property from the ProviderMetadataURL. Example ““issuer:https://curity_server.com””
    OIDC_AuthzScopes	Optional list of additional OIDC scopes.

In this section you can read about the configuration steps required to connect an Axis device to the Google Cloud Platform using OpenID Connect. For further reading, please review the Google Identity documentation.

Google Cloud Platform setup

1. Setup a project in the Google API Console.

3. Click on Select project and select New project.

4. 



5. Enter a Project name and click on Create.
   

6. 



7. To setup OAuth 2.0, go to OAuth consent screen page and select user type.
   

8. 



9. Enter the required details.
   

10. 



11. Add the scopes: userinfo.email, userinfo.profile and openid.

12. 



13. Add authenticated users to the application.

14. 



15. To obtain OAuth 2.0 credentials, go to the Credentials page.

16. Select Create credentials > OAuth client ID.

17. 



18. Select application type Web application, fill in a client name and configure authorized redirect URIs. Note that this the FQDN should end with “/oidc/oauth2callback”.

19. 



20. Document the Client ID and Client secret for further usage.

21. 
22. Axis device parameters

In this section you can read about the configuration steps required to connect an Axis device to the Microsoft Identity Platform using OpenID Connect. For further reading, please review the Microsoft Identity Platform documentation.

Microsoft Identity Platform setup

1. Setup an application in the Microsoft Azure Active Directory console.

2. Go to the App registrations page and select New registration.

3. 

4. Fill in a display name and configure an authorized redirect URI. Note that this the FQDN should end with “/oidc/oauth2callback”.
   Document the Application (client) ID.

5. 

6. To obtain a client secret, go to the Certificates & secrets page and select New client secret.

7. Fill in a description and expiry date and click Add. Document the Client secret.

8. 

9. Go to the Overview page and select Endpoints and document the shown endpoints.

10. 

Axis device parameters

In this section you can read about the configuration steps required to connect an Axis device to Microsoft Windows Active Directory Federation Service (AD FS) using OpenID Connect. For further reading, please review the Windows AD FS documentation.

Windows AD FS setup

1. Install the Windows AD FS role as described here.

2. Configure the Windows AD FS role as described here.

3. Verify that Windows AD FS is working correctly be following the steps described here

4. From the Windows AD FS management console, add a new application group. Use the Server Application template.

5. 

6. Enter a Name, Client Identifier and Redirect URI. Document the Client Identifier. Note that the redirect URI is the FQDN of the Axis device and it should end with “/oidc/oauth2callback”. Click Next.

7. 

8. Select Generate a shared secret. Document the shared secret. Click Next.

9. 

10. Complete the rest of the wizard.

11. 

Axis device parameters

User roles

Axis devices know 3 different roles when using OIDC.

• Administrator

• Operator (with PTZ rights)

• Viewer (without PTZ rights)

The above identity provider setup examples result in providing all users with the administrator role. To illustrate a setup with different user roles the following security groups have been created in an Active Directory, each containing different users.

Depending on the identity provider a custom claim should be created. For the below example the claim “groups” has been configured.

In order to assign the Active Directory Groups to the Axis user roles, the following values should now be used during the Axis device parameter configuration.

This will result with the following user roles being assigned.

Configuration using the GUI

With AXIS OS 11.7 or higher, it is possible to configure OpenID in the web interface.

Configuration using the API
While the above example shows the configuration using the built-in web interface, it is also possible to use the available VAPIX API to configure the required OpenID Connect parameters on an Axis device. Using AXIS Device Manager, the required settings can be pushed to multiple devices at once.

Login on the Axis device using OpenID Connect

1. Browse to https://<hostname>/ of the Axis device. For example https://p1375.axis.com

2. The device should now redirect to the configured redirect URL of the Identity Provider. This example shows the redirect page of a Azure application.

3. 

4. After providing the user identity to the identity provider, you are redirected back to the Axis device interface.

5. 

AXIS OS 11.11 and later versions support multiple virtual host authentication interfaces. This allows for hybrid setups where Digest/OAuth 2.0 OpenID Connect authentication schemes are used for centralized Identity Access Management (IAM) in active directory federated services (ADFS) and other identity provider (IDP) solutions. 

Virtual hosts only support HTTPS.

By default, the HTTPS port configured on the Axis device supports all authentication schemes supported by the Axis device:

• Base

• Digest

• OAuth 2.0 OpenID Connect

Example 1 - Authentication schemes on different ports

The authentication scheme that the device accepts differs depending on which of the ports you attempt to access the Axis device from.

Example 2 - Authentication schemes on the same port

Because of the way virtual hosts work, the configured name will be used as the hostname to differentiate between the 2 above authentication schemes. In this example, we’ve chosen digest & oidc. The authentication scheme that the device accepts differs depending on which of the two hostnames you use to access the device.

Note that this setup might require updates in your DNS infrastructure to ensure both hostnames are correctly accessible and resolved.

Axis devices are capable of sending images and videos using the SFTP (SSH File Transfer Protocol) protocol to a remote server. SFTP is using the secure and encrypted SSH protocol to transfer data via FTP. This is not to be mistaken with FTPS (FTP over SSL), which is another secure method of transferring data securely, however not supported by Axis devices.

Depending on the environment and selected 3rd party SFTP server, the configuration may differ. In this tutorial we are going to have a look at the commonly used OpenSSH server for Linux operating systems.

OpenSSH server configuration
The SFTP implementation of Axis devices is based on the open-source software component Curl. Out of the many authentication methods that Curl supports, Axis devices currently only support the so called CURLSSH_AUTH_PASSWORD. Therefore you need to make sure that the SFTP server being used supports this method as well.

This guide can be used as a reference to install OpenSSH, which then allows for the Axis device to transfer data using SFTP. Once the OpenSSH server is installed, it should be possible to test that the connections work, e.g. by using Putty (SSH client). Enter the server IP address as well as the login credentials from your Linux operating system to connect.

SFTP uses public key authentication in order to allow for secure data transfer, which is why it's recommended to create dedicated key pairs for this purpose. In AXIS OS, SSH-2 with RSA, DSA, ECDSA and ED25519 host keys are supported. AXIS OS 11.1 or higher includes a new OpenSSH version which removes depreciated authentication methods of using RSA keys. We recommend using the SFTP server’s ECDSA or ED25519 host keys instead. By using the following commands, private/public host key pairs can be created in the OpenSSH server. The private key is exclusively used by the OpenSSH server while the public key will be used by the Axis device in form of a hashed MD5 or SHA-256 key that is generated from the public key.

Following the creation of the private/public key pair, we can use the following commands to generate the MD5 and/or SHA-256 hash keys that need to be used in the SFTP recipient configuration in the Axis device (see Axis device configuration). Note that it's possible to create both an MD5 and/or SHA-256 hash key from either of the generated public host keys above. In the below example, we generate an MD5 or a SHA-256 hash key from the different public host keys.

While the Axis device supports both MD5 and SHA-256 hash keys, it's recommended to use SHA-256 due to stronger security over MD5.

When creating a new SFTP recipient, please make sure to enter the right MD5 or SHA256 fingerprint of the host key that is used by your SFTP server. Based on the public/private key we created previously and the MD5 or SHA-256 hash keys we generated from the public host key (see 3rd party SFTP server), the SFTP recipient in the Axis device would look as below:

After the SFTP recipient has been created, action rules for image and/or video clip transfer can be created.

Since long ago, the default IP address of Axis devices has been 192.168.0.90 in case of no DHCP server being available on the network. The link-local address (169.254.0.0/16) has also always been on by default. In other words, the camera’s interface has a routable address and an IPv4 link-local address configured simultaneously. However, this is not recommended by the RFC document.

Secondly, If an Axis device is configured with a static IPv4 address, it will use it regardless of whether anyone on the same network segment uses it. However, this will cause service interruptions for the other devices.

For the aforementioned reasons, we decided to make changes to IPv4 addressing:

• To be completely RFC IPv4 compliant

• Disable link-local address when it is not used

• Better user experience for our customers, when multiple factory-defaulted Axis devices, are placed on the same network simultaneously

• Address conflict detection and resolution

With AXIS OS 11.7 and later, we add:

1. A new “Auto Link-local mode” will be triggered if there is an address conflict on the static address or, a valid DHCP offer is unavailable on the network.

2. Address conflict detection for a static address. If conflict is detected, the Axis devices will not take any IP addresses used by other devices. It will fall back to the link-local address (in auto link-local mode).

1. If you have a DHCPv4 server in your network, the factory-defaulted Axis devices will take the offer from the DHCP server. The Axis device will only have one IPv4 address configured and the link-local address will not be available.

   

2. If you don’t have a DHCPv4 server in your network, a factory default Axis device will no longer use 192.168.0.90/24 as the default IP address. Instead, a link-local address(169.254.0.0./16) will be configured.

   

3. If you manually configured static IP addresses for multiple Axis devices. However, one IP address has been misconfigured on more than one unit. Only the first unit will use that specific IP address when you connect those devices to your network. The second and later units will fall back to the link-local address.

   

4. If an Axis device is running with a static IP address, another device with the same IP address is later connected to the network. In line with RFC recommendations, the Axis device will defend the current IP address and keep the IP address under any circumstances.

   

By default, the camera will fall back to the link-local address when no DHCP server is not available in your network. To make the transition smoother, we have added a setting ( System > Network > IPv4)  allowing customers to select fallback to the static IP address or link-local address when the DHCPv4 offer is unavailable.

• ON. When DHCP fails to obtain a lease, the static address is configured.

• OFF. When DHCP fails to obtain a lease, the link-local address is configured.

Find the network interface card on your computer connecting to the same LAN where the Axis devices sit. The network interface card of the PC should also have a link-local address configured. To configure a link-local address, follow the steps of one of the following three options.

• OPTION 1: Automatically assign link-local address when the DHCP server is not available

• 1. Right-click the network interface, select Properties, select Internet Protocol Version 4 (TCP/IPv4), then click on Properties.

  

  2. Select Obtain an IP address automatically and click OK.

  

  3. The Windows PC will automatically assign a link-local address to the network interface card.

  

  4. Now the IP Utility can discover devices that fall back to link-local address.

  

• OPTION 2: Manually assign a link-local address when the DHCP server is not available

• 1. Right-click the network interface, select Properties, select Internet Protocol Version 4 (TCP/IPv4), then click on Properties.

  

  2. Manually assign a link-local address. You can use any unused IP address within the 169.254.0.0/16 range, with the exception of 169.254.0.0 and 169.254.255.255.

  

  3. Now the IP Utility can discover devices that fall back to link-local address.

  

• OPTION 3: Add link-local address to the network interface card when a routable address is configured

• 1. Right-click the network interface, select Properties, select Internet Protocol Version 4 (TCP/IPv4), then click on Properties.

  

  2. The network interface card already has an IP address 192.168.0.120/24 configured. Click Advanced to add an additional link-local address.

  

  3. Click Add under IP addresses to add the link-local address. You can use any unused IP address within the 169.254.0.0/16 range, with the exception of 169.254.0.0 and 169.254.255.255.

  

  4. The Network Interface card should now have two IP addresses configured.

  

  5. Now the IP Utility can discover devices that fall back to link-local address.

  

With AXIS OS 11.7 and later, the new IPv4 compliant mode has been implemented but it is disabled in the factory defaulted state. The current plan is to make it enabled by default in AXIS OS 12.0, which will be released in September 2024.

To try the IPv4 compliant mode, it can be enabled by changing the following parameters:

Step 1

Go to system---Network, uncheck “Fallback to static IP address if DHCP isn’t available” and save.

Step 2

Go to System—Plain config—Network—Network/ZeroConf, check “Fallback” and save.

O3C (one-click cloud connection) is a protocol that allows an Axis device to connect via secure connection to a cloud video management system, such as Genetec Stratocast. In order to connect an Axis device, the so called OAK (owner authentication key) is needed. See instructions for how to look up the OAK below.

With each Axis device, you receive a piece of paper with the OAK printed on it. As mentioned, you need the OAK to verify ownership when you register the device with an O3C-based service. Keep this document in a safe place – it’s a certificate that should not be discarded or disclosed to third parties. If you have lost your OAK, you can retrieve it by logging in to the device as an admin user. Follow one of the paths below, depending on the AXIS OS version of your device.

AXIS OS 5.51 & LTS 216 (AXIS OS 6.50)
Go to Setup > Options > Support > System Overview.

LTS 2018 (AXIS OS 8.40) & LTS 2020 (AXIS OS 9.80)
Go to System > AVHS and click on Get key.

AXIS OS 10.0 or higher
Go to System > O3C and click on Get key.

AXIS OS 10.9 or higher
Go to System > Network and click on Get key. Note that this applies to devices with support for the new web interface introduced in AXIS OS 10.9. For products that don’t support the new web interface yet, follow the above instructions for AXIS OS 10.0.

AXIS OS 7.10 and higher
Video products with AXIS OS 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 AXIS OS version of your Axis product here.

You can use the device with the following browsers:

*To use AXIS OS web interface with iOS 15 or iPadOS 15, go to Settings > Safari > Advanced > Experimental Features and disable NSURLSession Websocket.

To find out more about how to use the device, see the user manual available at axis.com.

If you need more information about recommended browsers, go to AXIS OS Portal.

• Highlights

• Recommended browser: Latest Chrome and Firefox

• Supported browser: Latest Chrome, Firefox, Edge and Safari

• Platform-independent with latest Linux, OS X and Windows 7 through Windows 10

• Support for tablet and mobile devices

• 12 pre-installed languages and automatic language detection

• Known limitations

• Edge: 1-second video delay when streaming H.264

• Safari, Chrome, Firefox: No support for H.264 video streaming in Apple mobile (iOS) devices

• Audio: No support for sending audio to the camera through the browser (i.e. through a computer microphone)

• Video: Some browser plugins are known to cause problems with live streaming. Try uninstalling plugins if the video does not play as it should.

• Video: H.265 video streaming is currently not supported in any browser

• Because the setting for NSURLSession Websocket can no longer be toggled off in iOS and IpadOS 17.0 and higher, anonymous viewers are required to be able to sign in via a web browser on iOS or IpadOS 17.0 or higher.

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 AXIS OS 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 AXIS OS version of your Axis product here.

• Highlights

• Recommended browser: Internet Explorer* with AXIS Media Control

• Recommended for Windows operating system

• Known limitations

• QuickTime player introduces a 3-second video delay when streaming

• Java applet-based clients only support one-way audio, and the audio quality, as well as the frame rate, might be reduced

• When using video products with AXIS OS 5.50 or lower and IE10, compatibility mode is recommended

Video streaming
AXIS Media Control and Internet Explorer* is required for video streaming H.264 over HTTP/RTSP/RTP. MJPEG video streaming is supported by Chrome, Firefox and Safari.

* Read more about Internet Explorer limitations in Internet Explorer mode in Edge.

Internet Explorer was previously used to view H.264 using AXIS Media Control and to configure the legacy embedded Video Motion Detection. Since Internet Explorer is outdated and unsupported, Microsoft Edge can be used for this purpose instead if set to Internet Explorer mode. Simply follow the steps below.

• Go to Settings > Default browser.

• Set Allow sites to be reloaded in Internet Explorer mode to "Allow".

• Click "Add" next to Internet Explorer mode pages and enter the IP address of the Axis device.

When done, Edge will work the same way as Internet Explorer for that particular device.

When discussing various features and problems, it can sometimes be important to clarify which version of the web user interface is used. Axis devices have had several different user interfaces throughout the years.

Axis released the first network camera, AXIS Neteye 200, in 1996. The web interface in may seem quite rudimentary by today’s standards but was very much on par with everything else on the world wide web back then. (It can be noted that NCSA Mosaic, one of the first widely available and popular web browsers was released only three years prior, so Axis was in the game very early on.)

AXIS 200:

Only a couple of years later, Axis released their first encoders, or “video servers” as they were called back then; Axis 2400/2401. The web interface in these products had graphical representations of what was connected. It was also possible to control Pan-Tilt-Zoom on connected cameras directly from this web interface.

AXIS 2400:

In 1999, Axis released the first Linux based network camera, AXIS 2100. And with that, once again a brand new web interface. Unlike the gray interface in AXIS 2400/2410 that was intended for the conservative surveillance market, this interface targeted the younger web generation and thus was brighter and shinier.

AXIS 2100:

The two separate web interfaces for encoders and cameras lived side by side for a few years, but by 2003, the time had come to introduce a web interface that worked for both cameras and encoders. This interface version lived on all the way until 2016 (in different iterations) and has become what we sometime refer to as “Classic”. We will continue to refer to it as “AXIS OS web version A (Classic)”.

The first version of AXIS OS web version A (Classic) was introduced in AXIS OS 4.0, but is now only supported in LTS 2016 (6.50). With the introduction of AXIS OS 7.10, this version was no longer the default interface, but it was still available via the URL http://camera-ip/index.shtml up until AXIS OS 9.20, after which it was completely removed.

While AXIS OS web version A (Classic ) lasted for 13 years, the rest of the world wide web moved on. In 2017, it was finally time to introduce AXIS OS web version B.

AXIS OS web version B had a more modern look than the previous version, and also supported a much wider range of browsers (including native support for H.264 streaming). Here, focus was on the video stream, and a key feature was the possibility to actually see the video while fine tuning image settings.

This interface was officially introduced with Axis OS 7.10, but a preview version could be seen already in AXIS OS 6.50 via the URL http://camera-ip/index.html. LTS 2018 (8.40) and LTS 2020 (9.80) both use this interface. Note that it is only intended to be used with video products.

Axis product portfolio has been growing over time and now includes many more product types than just video products. Since AXIS OS web version B only supported video products, it soon became important to create a user interface that would work for all types of products. So, in 2020, AXIS OS web version C was introduced.

AXIS S3008 Recorder was the first product to officially get AXIS OS web version C, which was introduced with AXIS OS 10.0.0.

Most video products had to wait some time before officially getting AXIS OS web version C, but it could be reached through http://camera-ip/preview/index.html already in 10.0 on a selected number of products (ARTPEC-7).

VAPIX® Network Video API is a set of Application Programming Interfaces (API) for configuration and management of Axis network video products. For more information, visit the VAPIX Library.

You can use tools like Postman or cURL to interact with the VAPIX API. cURL offers a command-line alternative for sending API requests and retrieving data, while Postman provides a user-friendly interface for sending HTTP requests and viewing responses, making it ideal for testing and exploring the VAPIX API. Both tools enable you to experiment with API calls, troubleshoot issues, and develop custom integrations.

For examples on how to use cURL, see the VAPIX Library. To learn more about VAPIX and Postman, click here.

AXIS has released new APIs for AXIS OS configuration. These APIs were introduced in AXIS OS 11.11, and more device configuration APIs will be added on an ongoing basis. See AXIS OS demonstration video here.

Available APIs can be seen on the device itself by typing: http://IP-adress/config/discover

The API documentation in the VAPIX library will be delayed, but it can be found on the device itself. To see API documentation on the device write: http://IP-adress /config/web-ui/cu-doc.html?md-doc-loc=/config/discover/apis/best-snapshot/v1/doc.md

Now you get the responses from the device:

It is also possible to test the APIs through the Swagger GUI. To do this, go to the Swagger URL for the selected API, e.g. /config/web-ui/swagger-ui/?url=/config/discover/apis/best-snapshot/v1/openapi.json

Click on Try it out button and fill in the values. Then click on the Execute button.

Now you get the responses from the device:

Now you can copy the code and place it to your application.

The following are 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

  • Up to 64 GB for devices with SDXC slot support and AXIS OS prior to 5.60

• Supported speed classes: class 10 or 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

The following are 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

  • CIFS/SMB 3.1.1 + NTLM authentication mode with AXIS OS 10.12 or higher and Linux Kernel 4.17 or higher.

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

AXIS OS 6.40 and higher
There are two types of disk clean-up operations for deleting old recordings; one is user-controllable, and one is performed automatically by the Axis device.

The first operation removes recordings older than a certain time in days. This can be configured by the user in the storage configuration in the web interface. For instance, when the user selects one week (i.e. 7 days), the clean-up operation will remove all recordings older than 7 days. It's important to note that this operation runs once per hour (i.e. every 60 minutes).

The second operation is an automatic clean-up that is always enabled and cannot be disabled by the user. This operation runs every second and checks that the network share or SD card has enough space for recording. The clean-up level is defined as an amount of free space. For locally attached storage, like SD cards, the clean-up level is defined as 5% of the total size of the SD card unless those 5% are less than 750 MB. When that is the case, 750 MB will be the clean-up level. For network shares, the clean-up level is fixed when max 750 MB remains. So for a 64 GB SD card, the clean-up level is 3.2 GB, while for an 8 TB NAS the clean-up level is 750 MB.

If there is less free space on the disk than what's defined in the clean-up level, the automatic clean-up operation will detect this and remove the oldest recordings (actually blocks) based on the needed space. Note that at least 1 GB will be removed in order to bring the free space size above the clean-up level. For instance, if the free space is 50 MB below the clean-up level, the operation will remove at least 1 GB, thus making 950 MB free above clean-up level.

If the disk is full, i.e. if the clean-up operation was not successful in removing the data on time, another level of 75 MB free space is defined. This is called the full level. If the full level is reached, the disk is declared full and the recordings should stop. At the same time, the clean-up operation continues until the free space is above the clean-up level. Once there is space above the clean-up level, recording will start again.

AXIS OS 5.50 – AXIS 6.30
In addition to the configuration that can be performed in AXIS OS 5.40 and lower, the clean-up of old recordings will start when there is less than 750 MB of storage space available. This is an additional algorithm that has been implemented to prevent exceeding the network share or SD card storage space.

AXIS OS 5.40 and lower
In AXIS OS 5.40 and lower, there are two user-controlled clean-up parameters that defines when the Axis device should be performing a clean-up of the storage. The first parameter is used to configure number of days until recordings should be overwritten, and the second parameter is a clean-up policy in percentage. Old recordings are deleted if either one or both of the conditions in these parameters are met.

It's recommended to set the clean-up policy to 80 for AXIS OS 5.20 and 90 for AXIS OS 5.40. As an example, a clean-up value of 90 corresponds to 72% usable storage, and the Axis device would then have 72 GB writable recording space when connected to a 100 GB network share. The clean-up level can be configured from Plain Config > Storage.

For performance reasons and optimal read/write cycles to the edge storage medium, video is recorded in chunks of five minutes. This is defined in DefaultSplitDuration = "300", where "300" refers to 300 seconds, which in turn corresponds to five minutes. Note that it’s not recommended to change the value since this could affect the memory buffers. It could also affect performance since a split duration that is too short could cause a high amount of files. If the value is changed, make sure it's tested accordingly. In AXIS Companion, it’s possible to download a part of the video merged into one file in asf format, which is the recommended way to solve this issue. From AXIS OS 5.60 and onwards, the video export feature has been improved so that it's possible to export a recording from several 5 minute segments into one recording.

ONVIF and VAPIX recordings are completely separated. For example, recordings that are created via VAPIX through the web interface or VAPIX API are not visible or usable for ONVIF clients. In return, ONVIF recordings are not visible or usable for the user and are not showing in the recording section of the web interface. ONVIF clients have to create recordings through the ONVIF API separately to make use of recordings.

It's possible to listen to storage-related metadata events via the RTSP stream. Essentially there are two events available, both indicating a storage connection failure either for an SD card or a network share. These two events are called:

• Device/HardwareFailure/StorageFailure

• Storage/Disruption

If for example the network share is disconnected due to the NAS no longer being available in the network, both events would be active.

When performing an edge recording on an Axis device, the below folder structure is being used*. This folder structure can not be modified.

Example recording path: *\axis-ACCC8E9C6BE7\20211214\11\20211214_110037_AAF2_ACCC8E9C6BE7\20211214_11

* The "Send video" and "Send images" event options may use a different folder structure based on the configured recipient.
** The date and time reference is in the Axis device’s local time and refers to the date and time when the recording was created.

From AXIS OS 10.10, Axis devices support password encrypted export of edge recordings (SD card, network share). This means it is possible to export a recording that is password encrypted, adding the possibility to securely share sensitive video data without the need to manually encrypting exported recordings.

Password encrypted recordings

• Supported file format: *.zip

• Supported password length: maximum 128 bytes (128 characters). In the legacy web interface the maximum is 64 characters.

• Supported encryption: AES-256. Note that some operating systems do not have native support for this encryption. In those cases open-source tools such as 7-zip can be used to open password encrypted recordings.

Export file name
The file name of regular recording exports may contain sensitive information such as the date and time or the camera name. When doing a password encrypted export of a recording, leave the file name field empty and the file name of both the downloaded *.zip file and content names will get anonymized.

The SD card and its slot can be disabled completely. This is done from Plain Config > Storage > Storage.S0.Disabled. When the SD card slot is disabled, the Axis device will not recognize any SD card inserted.

From AXIS OS 6.20, Axis devices support health statistics for AXIS Surveillance Cards. This means it's possible to get an estimated wear out level for the SD card being used, which can help determine when to replace it.

From AXIS OS 10.3, it's possible to create an event based on the wear level of the SD card so that you can get notifications when a certain wear level is reached. More information is available in this video:

We will now take a look at how an encrypted SD card operated in an Axis device can be decrypted or re-used again.

Axis device
An SD card that was encrypted and previously used in an Axis device can be inserted and used in another Axis device again. This could e.g. happen when an Axis device gets replaced during an RMA process.

Windows
To decrypt an SD card on a Windows computer, an open-source disk encryption tool like LibreCrypt can be used.

If the SD card is formatted to VFAT, follow the screenshot guide below. If EXT4 is used, you need to install a third-party driver like Ext2Fsd first in order for the Windows computer to recognize the filesystem on the card.

Linux
In Linux operating systems, the SD card can be decrypted directly using the command line and the following commands:

sudo cryptsetup open /dev/sdf1 qqq
Enter passphrase for /dev/sdf1:
mkdir /tmp/qq ~
sudo mount /dev/mapper/qqq /tmp/qq
sudo su
cd /tmp/qq
root@mycomputer:/tmp/qq# ls
20160929 index.db lost+found
root@mycomputer:/tmp/qq# exit 
sudo umount /tmp/qq 
sudo cryptsetup close qqq

Formatting the SD card will only rewrite the parts of the SD card necessary to create the filesystem. This could be a couple of hundred MBs on a 64 GB SD card. Any of the old data, such as older recordings, will not be accessible via the new filesystem. However, a major part of the SD card data will be unmodified after formatting and may thus be accessible on a low level (i.e., it may be possible to extract the data if the card is inserted in a computer).

There are various methods to erase sensitive data on SD cards and they usually require writing the entire card with different patterns multiple times. Axis products do not have support for erasing data in such a way.

Here we'll take a closer look at the differences and negotiations in the SMB/CIFS protocol. The network traces in the table illustrate the process of negotiating a specific SMB version between an Axis device and a NAS and the corresponding session setup in order to mount a network share successfully. After the negotiating process is completed, we can observe some regular SMB protocol communication about listing, deleting and writing files to the network share.

 AXIS OS 8.30 and higher
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’s 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, SMB 3.02 and SMB 3.1.1.

AXIS OS 8.20 and lower
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 set in Plain config as described below.

Setting SMB version in Plain config
If SMB 1.0 or SMB 2.0 is required due to compatibility issues, we recommend setting the extra mount options parameter in Settings > System > Plain config > Storage to a specific version, e.g. vers=1.0 or vers=2.0 for a network share. 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 set 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 you will find three configuration examples describing how the device is handling the extra mount options parameter. As you can see, the device will only consider the latter of the two SMB versions entered. 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

In case the NAS is disconnected from the network, the Axis device will try to automatically remount a network share. A prerequisite for trying to remount a network share is that the NAS is online/available on the network, e.g. via PING. The first attempt to remount the network share will be executed after 2 seconds, and every failed attempt will double the time between new intervals:

• First try: executed after 2 seconds

• Second try: executed after 4 seconds

• Third try: executed after 8 seconds

This will continue until the last try, which will be executed after 600 seconds (10 minutes).

In the storage section in Plain Config, the complete storage configuration can be obtained from an Axis device. The storage section is splitted into S0-S2 storage groups, where S0 corresponds to the SD card configuration, and S1 and S2 are the network share configuration equivalents.

When mounting a network share on the Axis device, two storage groups - S1 and S2 - are created. S1 is the physical network share and its disk, while S2 is the network share recipient that e.g. could be used in the event system of the Axis device.

Here’s how to set up recording to cloud platforms like AWS S3 and Azure Blob Storage:

1. Set up your S3 or Azure server and create a bucket for the recordings. Then, create a destination on your device by providing the required parameters:

2. • id (the ID of the destination, which isn't part of the S3 or Azure parameters)

   • accessKeyId

   • bucket

   • secretAccessKey

   • sessionToken (optional)

   • url (the URL to the S3 or Azure server)

3. Here’s an example of what the data might look like:

{"id": "my_s3_dest", "s3": {"accessKeyId": "minioadmin", "bucket": "test-bucket", "secretAccessKey": "minioadmin", "sessionToken": "session_token", "url": "http://172.27.140.1:9000"}}

4. Create a recording group using the new recording group API. You’ll need to provide the destination ID as a required parameter. You can do this by sending a request to: http://<target_ip>/config/rest/recording-group/v2/recordingGroups

5. Start a recording using the same group.

If you need help finding the APIs, you can use the discover feature: http://<camera_IP>/config/discover.

You can also use the Swagger UI pages for the APIs to set up your destination and group quickly. You can find these at http://<camera_IP>/config/web-ui/swagger-ui/?url=/config/discover/apis/remote-object-storage/v1/openapi.json and http://<camera_IP>/config/web-ui/swagger-ui/?url=/config/discover/apis/recording-group/v2/openapi.json.

Below you'll find some guidelines for setting up edge recording on your Axis device.

• Use H.264 to reduce bandwidth and avoid MJPEG streams.

• Use only one recording at a time when recording to an SD card to avoid shortening the SD card's lifespan and minimizing its wear level.

• When configuring your recordings, add at least 30 seconds of post-buffer recording to each event triggered recording in order to avoid many small recording segments

• Configure the Axis device properly with the correct date & time prior to starting a recording. Date & time can either be configured manually or automatically via the NTP server.

• Check with the NAS-vendor if the amount of (video) data can be processed by the NAS in order to avoid performance issues.

• Keep the bitrate of the video stream below 10 Mbit/s when recording to the SD card in order to avoid missing frames/recordings.

• On Axis devices with a legacy version, set the clean-up level (i.e. the limit when older recordings are erased) to max 80% on AXIS OS 5.20 and 90% on AXIS OS 5.40.

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

Recording to SD card using third-party ACAP solutions
Axis recommends third-party solutions such as Timelapse Server and Timelapse video developed by Pandos Development (https://pandosme.github.io/). Some of the features these solutions offer include:

• 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

• Several 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 9.30 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 9.30 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 9.30 and higher

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

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:

5. • Check for Updates which requires internet access.

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

6. Check for updates:

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

8. Browse:

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

10. Each device model will show a dropdown containing all available versions for a model, sorted by “Long Term Support” (LTS) and “Active” software tracks.

11. Select the version to install for each device model.

12. Click OK to start upgrading the devices.

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

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 AXIS OS 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:

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

    • Step 2: Uploading. The old version will be erased and the new 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 versions settings are configured to match the previous settings. The color of the status LED will be amber during this step.

12. 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 AXIS OS 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:

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

    • Step 2: Uploading. The old version will be erased and the new 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 versions settings are configured to match the previous settings. The color of the status LED will be amber during this step.

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