-
Got what appears to be an Axis firmware bug which prevents me from using standard Onvif Calls to pull event messages. My DUT is an Axis Q6135LE running 10.12.213. I am using Visual Studio 2022 with the Microsoft WCF stack NUGET packages System.ServiceModel.* V6.2.0. The scaffolding code is autogenerated from the official ONVIF wsdl and the case in point here is https://www.onvif.org/ver10/events/wsdl/event.wsdl The sample project to demo the problem can be found at https://github.com/lot3worx/AxisDemoSample I can create a pullpoint subscription for the DUT events without any problem. It provides me with a subscription address reference. I then create pullpointsubscriptionclient based on a soap message binding stack and an endpoint. However, the Axis server when it responds with the subscription address reference provides an additional reference parameter notifying me of the subscription ID as an xml element (see below) But the Onvif wsdl generated call to PullMessages evidently expects this subscriptionID to form part of the Endpoint address when the endpoint binding channel is made. There is no option to provide it to pullmessages. If you open the SOAP channel binding without the subscription ID encoded somehow in the Uri endpoint you get a "Bad Request" from the DUT. I checked some forums and stackoverflow 11 years ago a similar question was asked and the response was that you had to load the returned xml subscription ID element into the Header portion of Soap messages to PullMessages. If this is the case there appears to be noncompliance with the Onvif standard. If someone can tell me whether Axis can take the subscription ID as part of the address in the Endpoint for the SOAP channel binding and if so, the correct format that would let me do an interim workaround (I tried an obvious guess but the DUT responded "no one listening"). Even so, I have to detect the presence of Axis specific devices in an otherwise standard Onvif call, then massage the returned address reference etc to include the subscription ID. If Axis devices do not accept the subscription ID for the pullpoint to be specified in the binding endpoint Uri, i.e. it must be a header element in the SOAP message itself, then this is a bigger problem (bug) in that I now have to intercept the SOAP messages, detect the pullpointsubscription suite, then detect the presence of AXIS devices, then massage low level SOAP messages as the workaround. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 10 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
Hi @lot3worx , The only difference I noticed is the Axis OS(Firmware) here: I suggest it is worth trying the Axis OS Active track here: |
Beta Was this translation helpful? Give feedback.
-
Dear Vivek,
😃 We meet again..
Once again thank you for looking at the issue. We are fairly certain we are
looking at another Onvif non-compliance of the Axis firmware at the SOAP
message level when it responds to the createpullpointsubscription message in
that it does not correctly form the subscription reference address, or the
Axis firmware cannot accept the subscriptionID in the endpoint.
Using the active track is not easy since our deployment policies for the
sites are fairly strict for LTS formats but I will take a look at what you
suggest below and see if I can schedule a DUT with the active track to see
if the bug has been rectified there (I am sceptical since I have heard
already that the bug is still there in the active track but I do admit that
I haven't checked personally --- we have a list of Onvif and Vapix bugs in
Axis gear and thankfully I am now allowed to talk about them). Might take a
few days for me to check an updated DUT...
|
Beta Was this translation helpful? Give feedback.
Dear Vivek,
Interesting. It is quite consistent with my previous explanation and goes over quite a bit of the same ground . Axis now have to decide how to deal with what is happening with the Onvif Standard in the Events Core Specification wsdl which now prevent your subscription ID from being loaded in the Header Portion of the SOAP message without a custom workaround. Up to Axis of course but the following options might be useful as part of your internal discussions:
Option 1: As an Onvif member Axis can propose to have the V22.06 Version of the Events wsdl modified so when it is consumed by users it now places reference parameters in the HEADER portion instead of the BODY portion of th…