ONVIF Bugs in Axis Firmware

[lot3worx]

I am integrating various cameras, in particular the Q6135LE running firmware V10.12.199 into Windows 11 .net 6 app and have noticed bugs in the Axis ONVIF implementation (as have others in some other discussion) which is being used as the primary integration api. One bug concerns the response from a GetCapabilitesRequest using the official Onvif events WSDL derived code with Microsoft service model libraries from Nuget. The SOAP XML responses from the cameras are fine in the sense they got a successful request and they list the max pullpoints available all OK. However the SOAP action in the returned SOAP message from the cameras is GetCapabilitiesRequest when it needs to be GetCapabiltiesResponse. Simple bug, but it causes the Microsoft WCF stack to throw a fault since the response is not Onvif compliant. Great if the Axis ONVIF team can put this on the list for rectification in a future release of the firmware. Onvif.org probably needs to add another test during the certification process to pick up the correct action response for all SOAP messages returned. If a discussion on Onvif bugs is somewhere better I will switch to that category.

[github-actions[bot]]

This automatically generated reply acts as a friendly reminder.

Answers to your questions will most often come from the community, from developers like yourself. You will, from time to time, find that Axis employees answers some of the questions, but this is not a guarantee. Think of the discussion forum as a complement to other support channels, not a replacement to any of them.

If your question remains unanswered for a period of time, please revisit it to see whether it can be improved by following the guidelines listed in Axis support guidelines.

[lot3worx]

I should have been more precise with my description of the SOAP action. The precise action in the SOAP request to the Axis firmware is "http://www.onvif.org/ver10/events/wsdl/EventPortType/GetServiceCapabilitiesRequest", but the response action is simply a repeat of the request action whereas it should be "http://www.onvif.org/ver10/events/wsdl/EventPortType/GetServiceCapabilitiesResponse"

[vivekatoffice]

Hi @lot3worx ,
Thank you for making the query more precise.

I tested the same by writing a sample Python program. Please find my results below.

First test to replicate your scenario:

test.xml

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:tet="http://www.onvif.org/ver10/events/wsdl" xmlns:tt="http://www.onvif.org/ver10/schema">
  <soap:Body>
    <tet:GetServiceCapabilities />
  </soap:Body>
</soap:Envelope>

SOAP_API_CallPython_GetServiceCapabilitiesRequest.py

import requests,json
from requests.auth import HTTPDigestAuth

url = "http://10.176.12.83/onvif/device_service"
payload =""

# open the input xml file and read
# data in form of python dictionary
# using xmltodict module
with open("test.xml") as xml_file:
     
    payload = xml_file.read()
# headers
headers = {
    'Content-Type': 'text/xml; charset=utf-8'
}
# POST request
#response = requests.request("POST", url, headers=headers, data=payload)
response = requests.request('POST',url,data=payload, verify=False) 
# prints the response
print(response.text)
print(response)

Output (As you have informed response is "GetServiceCapabilitiesResponse")

Used "ONVIF Device Test Tool " to test the "GetServiceCapabilitiesRequest"

Result (Found it working 😉 and now more confusion 😃 )

Now I need to check if the payload is different here from "ONVIF Device Test Tool ". So used Wireshark to view the payload.

Difference in payload

Used new payload (test1.xml):

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<GetCapabilities xmlns="http://www.onvif.org/ver10/device/wsdl">
<Category>
All
</Category>
</GetCapabilities>
</s:Body>
</s:Envelope>

Result:

Note
I am not sure what is going wrong here. Do share your observations 😄 . I will try to forward the information to the concerned team.

[lot3worx]

Have you now got the screenshots?

[lot3worx]

As can be seen in the screenshots, the body of the SOAP messages is OK, but the SOAP header action on the response has the incorrect 'action' definition.

[vivekatoffice]

Hi @lot3worx ,
Is it possible for you to create a sample project repository and share it with me without any proprietary code?
Does the same code work with other Onvif conformant cameras? ONVIF Conformant Products
I may need to replicate the issue to explain to someone expert with Microsoft Stack and Visual Studio IDE.

Let's see if we have someone else who solved this for their project.

[lot3worx]

Dear Vivek,

I have created a sample project which has been tested and throws the fault under discussion. It can be found at

https://github.com/lot3worx/AxisDemoSample

It is just a "bare bones" project from the vs2022 winui3 app template but should do the job. You need to declare the Onvif device service Xaddr login name and password in the code for the target device in your network (sea readme.md) as well as run it on a windows 11 version 22621 or later with visual studion. Best to be in debug mode of course and set breakpoints where you need them to setep through. The poject has a getEventProperties call to prove that it ispossible to get a successful call fro the deivce and then it tries the GetServiceCapapbilities from the evetns wsdl and should then fail with the given fault. We will run a few other tests on some of our other site devices as a double check but so far the bug is repeatable when using Microsoft service Nuget packages wiht autogenreated codfe from the official Onvif.org wsdl's. Suspicions are tht the Microsoft stack is very strongly typed whereas the python methods you used are not and so is more relaxed when processing responses with the soap messages coming back. As discussed, the body of the soap message repsonse appears fine, but the action header in the response and namespaces not so.

[vivekatoffice]

Hi @lot3worx ,
Thank you for the samples. I will try to build and reproduce the issue. Let's see if any one else faced the similar problem or know how to overcome these.

[lot3worx]

Dear Vivek, Thank you so much for taking the time to look at the issue. Please find attached my screenshots to show how the Microsoft connected service model message intercepts (C# in .net 6 using Microsoft service model nuget packages) which show the SOAP message intercepts to and from the Axis Q6135LE from a connected service using the official Onvif.org event wsdl giving me the incorrect ONVIF action statement in the response (i.e. simply repeating the must understand” request”, rather than the must understand “response”) (using Visual Studio n 2022). The third attachment show the fault being generated in the VS debugger. As you can see from the response SOAP message the Axis camera processes the request and sends me the correct number of pullpoints implemented, but sends back the INCORRECT action in the SOAP header so my wcf stack throws a fault (i.e. merely repeats REQUEST action rather than the RESPONSE action). I suspect that other implementations don’t check whether the responded action statement in the SOAP header is actually the precise ONVIF compliant action response and simply proceed to process the message body whereas implementations off the strict ONVIF wsdl is strongly typed to the ONVIF standard. I used the classic message intercept in the Microsoft service model WCF stack. I also note that your test does not use the precise SOAP actions in the header (relying only on the body to make the request) and thus would not likely trigger faults utilising the body only; this is why it can “slip” past the fault detectors since there is NO action header in the request or the response --- see my attachments for strongly typed SOAP message based on the ONVIF official event wsdl. Yours Sincerely, Mark Anderson

[vivekatoffice]

Hi @lot3worx ,
As you replied to the Email, I am not able to find any snapshots. Please try to add the snapshot using a web browser or GitHub app.

I also checked the new payload with the "ONVIF Device Test Tool":

[lot3worx]

Dear Vivek, I will see if I can get a cutdown skeleton VS sample project into a github repo so you can demonstrate the problem to others. Actually, we have discovered several bugs with incomplete or malformed SOAP messages coming out of our Axis gear but that's another later story. I am not sure what I can say about the other non Axis ONVIF compliant devices at this time but can say we are not permitted to use Dahua, HikVision, or Huawei for the installations so cannot comment on those brands. I just took delivery of an Axis D2110-VE radar for integration into the testbed before eventual targeted rollout to the sites and will schedule looking at it to see if suffers from similar issues with whatever firmware version it is running. But so far on the Axis Q61 series and Axis P14 series bullets (they are all running 10.12.199) I get the fault as well as other issues hinted at above.

[vivekatoffice]

Hi @lot3worx ,
Able to get the Error on my system now:

I will try to play with it and find someone with more experience in ONVIF to look into this. Thank you for your efforts to report this.

[lot3worx]

Dear Vivek,
Unless more is needed on this bug manifestation should we now close this particular discussion as complete and let the Onvif team work out a rectification and is there any preferred way I should let Axis know about hte other bugs we have discovered (another discussion topic?).

[vivekatoffice]

Thank you @lot3worx for your response. I will suggest you to follow this
Axis support guidelines (please read before creating a new discussion)

As per my understanding, ONVIF's helpdesk Submit incident can also be used if it is related to Microsoft WCF stack support.

[lot3worx]

Dear Vivek, Good Progress. We chose this particular error due to its simplicity but we have a list of Onvif errors when dealing with Axis gear and I can load these into the test project if Axis wants to know about the other bugs we have identified. One bug has caused us to write an entire custom event broker as a workaround. I also have a list of some candidate bugs we found in the Vapix API but Onvif is our priority at the moment. But first things first let's see what is causing this error.

[vivekatoffice]

Hi @lot3worx ,
Thank you for your efforts to explain the issue. Now I can understand the problem.

ONVIF Specification: DUT would send a GetServiceCapabilitiesResponse message.

Error: Client is getting the "action http://www.onvif.org/ver10/events/wsdl/EventPortType/GetServiceCapabilitiesRequest'" in place of "GetServiceCapabilitiesResponse " for GetServiceCapabilities

Error Message:

A reply message was received for operation 'GetServiceCapabilities' with action 'http://www.onvif.org/ver10/events/wsdl/EventPortType/GetServiceCapabilitiesRequest'. However, your client code requires action 'http://www.onvif.org/ver10/events/wsdl/EventPortType/GetServiceCapabilitiesResponse'.

I will check with the concerned team to look into this. Let's start working with this issue first and later other issues can be prioritised.

Any Idea how it is not detected while Conformance Process?

[lot3worx]

Dear Vivek, Note that the command GetEventProperties does respond correctly in the provided test code. It is the GetServiceCapabilities command that fails to conform in its reply. I note below you list 5.1.1 Get Event Properties --- or does this section also include the fail component of GetServiceCapabilities?

[vivekatoffice]

Ok. Thanks @lot3worx .

I will correct the snapshot.

[vivekatoffice]

Hi @lot3worx ,
I used the following repository from here to test the same:
onvif-interface

Checkout "GetServices(DeviceClient client)" function from here:
Form1.cs

private void GetServices(DeviceClient client)
{
    // GetCapabilities is now deprecated (as of v2.1) - replaced by GetServices (Older devices may still use)
    OnvifDeviceManagementServiceReference.Capabilities capabilities = client.GetCapabilities(new CapabilityCategory[] { CapabilityCategory.All });

    if (capabilities.Analytics != null) { lbxCapabilities.Items.Add("Analytics"); }
    if (capabilities.Events != null) { lbxCapabilities.Items.Add("Events"); }
    if (capabilities.Extension != null) { lbxCapabilities.Items.Add("Extension"); }
    if (capabilities.Imaging != null) { lbxCapabilities.Items.Add("Imaging"); }
    if (capabilities.Media != null) { lbxCapabilities.Items.Add("Media"); }
    if (capabilities.PTZ != null) { lbxCapabilities.Items.Add("PTZ"); }

    lbxCapabilities.Items.Add("");
    ServiceUris.Clear();

    Service[] svc = null;
    try
    {
        svc = client.GetServices(IncludeCapability: true);
    }
    catch
    {
        // Bosch Autodome 800 response can't be deserialized if IncludeCapability enabled
        // Ignore and try with IncludeCapability disabled
    }

    // Try with IncludeCapability disabled
    if (svc == null)
    {
        svc = client.GetServices(IncludeCapability: false); // Bosch Autodome 800 response can't be deserialized if IncludeCapability enabled
    }

    foreach (Service s in svc)
    {
        Console.WriteLine(s.XAddr + " " + " " + s.Namespace);  // Not present on Axis + s.Capabilities.NamespaceURI);
        lbxCapabilities.Items.Add(string.Format("{0}", s.Namespace));
        ServiceUris.Add(s.Namespace, s.XAddr);

        if (s.Capabilities != null)
        {
            foreach (System.Xml.XmlNode x in s.Capabilities)
            {
                Console.WriteLine(string.Format("\t{0}", x.LocalName));
                lbxCapabilities.Items.Add(string.Format("    {0}", x.LocalName));
                if (x.Attributes.Count > 0)
                {
                    foreach (System.Xml.XmlNode a in x.Attributes)
                    {
                        Console.WriteLine(string.Format("\t\t{0} = {1}", a.Name, a.Value));
                        lbxCapabilities.Items.Add(string.Format("        {0} = {1}", a.Name, a.Value));
                    }
                }
            }
        }
    }

    //DeviceServiceCapabilities dsc = client.GetServiceCapabilities();
}

Do let me know if this is useful for you or you are already aware of it😉

[lot3worx]

OK, I have had another recheck of the Onvif Official site. I am convinced that the call your respondent is referring to is a deprecated call in the device management namespace wsdl. I.e. https://www.onvif.org/ver10/device/wsdl/devicemgmt.wsdl

The issue under discussion is an events handling issue and is with https://www.onvif.org/ver10/events/wsdl/event.wsdl
which of course is completely different. If you look at the attached screenshot of the GetServiceCapabilities the item under discussion there has no marker for deprecation. The events wsdl is currently at Ver 22.06. The separate core Onvif spec document as of June 2023 is at Ver 23.06 but I couldnt find a reference to any deprecation of the events namespace for GetServiceCapabilities so V22.06 should be the latest for the events namespace.

[lot3worx]

Dear Vivek, I will reprise and check from the Onvif website again but I believe that your respondent is talking about a completely DIFFERENT call. I suspect he is referring to the Onvif Device Management namespace set of calls and the call under discussion is in EVENTS namespace. And we are discussing GetServiceCapabilities, not GetCapabilities. As said, I will do a double check on the Onvif official wsdl and rematch to ensure full precision but the sample project supplied comes from https://www.onvif.org/ver10/events/wsdl/event.wsdl You can scroll down and see the GetServiceCapabilities specification at point 6. The Onvif spec we are using is Ver 22.06 (the latest) and it is not deprecated according to the Onvif website. I will send through relevant screenshots in a later post.