Hello,
I have developed an ONVIF Client application that communicates with the Milestone ONVIF Bridge 2019 R3 component is it works well.
However, my ONVIF Client application no longer works with the OPEN NEtwork Bridge 2021 R2, my application code displays the following error in Visual Studio :
“The header ‘Security’ from the namespace ‘http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd’ was not understood by the recipient of this message, causing the message to not be processed. This error typically indicates that the sender of this message has enabled a communication protocol that the receiver cannot process. Please ensure that the configuration of the client’s binding is consistent with the service’s binding.”
I added the “SHA256Auth” registry key as shown in the article below, but with no success I still get the same error.
https://developer.milestonesys.com/s/article/changes-digest-authentication-RTSP-service-in-2021-R1-troubleshooting
Could you please tell me how to fix this ?
Thank you.
Kind Regards,
Hi Omar,
The registry key you are talking about is concerning RTSP service.
As far as I understand the problem here is in ONVIF interface, aka ONVIF service.
Meaning the registry won’t help here.
What I can advice you is to test with the ONVIF Device Manager (free open source tool) against Milestone Open Network Bridge 2021 R2.
If it works (ODM) you could make a Wireshark traces of communication and compare them with those from your application/integration.
Hi Petar,
Indeed, I started by testing with the ONVIF Device Manager which works well with the Open Network Bridge 2021 R2.
Then I compared the Wireshark traces of the ONVIF Device Manager with the Wireshark traces of my application, the result is identical, except that my application no longer works.
Hi Omar,
Sounds very strange then.
Could you attach two of those traces here, please ? One with ODM and one with your application. Let another eye look at them 
Another option could be if you are able somehow to isolate a simple method call from your app in order we to test with it locally. Like a sample (reproducing) app.
Hi Petar
Attached is a POC of my application. It connects to Onvif Network Bridge to retrieve the list of cameras (camera name and GUID) available on ONB.
The method crashes on line 72 of the DeviceViewModel.cs class (mediaClient.GetVideoSources ();).
As a reminder, this same code works perfectly with ONB version 2019R3, but crashes with ONB 2021R2
The error message is : "The header ‘Security’ from the namespace 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd’ was not understood by the recipient of this message, causing the message to not be processed. This error typically indicates that the sender of this message has enabled a communication protocol that the receiver cannot process. Please ensure that the configuration of the client’s binding is consistent with the service’s binding."
If this is not sufficient for your investigation, I will give you the Wireshark traces.
Thank you in advance for your help
Hi Omar,
My initial impression was that the Milestone Open Network Bridge server (ONVIF service) doesn’t understand the “Security” SOAP header.
However, it turned out to be the other way around. The .NET client doesn’t understand the response SOAP and in particular the “Security” header in it.
I’ve seen you redefined the “AfterReceiveReply” method of the “IClientMessageInspector” interface, but it is empty.
You could try to filter or process the received message in it - in order to overcome the missing default security implementation in the .NET.
My first try with something like:
public void AfterReceiveReply(ref Message reply, object correlationState)
{
var securityHeader = reply.Headers.First(header => header.Name.Contains("Security"));
if (null != securityHeader)
reply.Headers.RemoveAt(reply.Headers.FindHeader(securityHeader.Name, securityHeader.Namespace));
}
And it worked on my side.
There are similar solutions proposed in stack overflow like:
public void AfterReceiveReply(ref Message reply, object correlationState)
{
var security = reply.Headers.Where(w => w.Namespace == "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd").First();
reply.Headers.UnderstoodHeaders.Add(security);
}
This also worked for me.
As for the reason why this was working in 2019 R3 (although I haven’t tested against it) - most probably is because we regenerated gSOAP files for service implementation with the option “strict”. As result, returned in the SOAP response “Security” header is marked with “mustUnderstand=true”. And the .NET client tries to follow it, but actually cannot.
Long term we are planning to add support for more modern “Digest authentication” in addition to the “WS-UsernameToken”. This would make all these “gymnastics” with “CustomBinding” redundant. Especially for the .NET integrations. However I cannot commit for a particular release.
Hi Petar,
Thanks a lot for your help.
Indeed, the solution you proposed to me works, my ONVIF client application manages to communicate with the ONB 2021 R2 but the problem is the slowness, for each call you have to wait about 30 seconds, which is slow.
I tried with both suggested methods but the result is the same, same slow duration.
Know that with the ONB 2019R3 the response is instantaneous.
Could you please help me solve this slowness problem?
thanks in advance
Hi Omar,
I don’t believe this delay is somehow related to your implementation.
I would assume the same behavior is experienced also with other clients, like ONVIF Device Manager (ODM) tool. Would you test it ?
If that’s the case you could try to change one particular setting in the Open Network Bridge settings in the Management Client.
It is named “Use configuration from cameras” and please ensure it is turned off (aka unchecked). Please restart the ONB server after that.
btw. It is very strange, because exactly in 2021 R2 we introduced caching logic in the ONB server, so even if this particular option is turned on, this delay should be experienced only on the first call. All the consecutive method calls should pass pretty fast (using already cached information).
Hi Petar,
In fact, I just tested this just now. unchecking the “Use configuration from cameras” option resolved the slowness issue.
It’s perfect, once again thank you very much.
Best Regards
Omar