Improved WS-Discovery standard compliance

[altaroca]

Some small changes to WS-Discovery Probe message for #1346 . As far as I can tell the resulting messages contain all the mandatory elements.
New: dependence on perl module Data::UUID

[jburgess777]

When I run this I get complaints about the comma missing at the end of this line

[jburgess777]

I'm getting errors like this when trying this PR:

$ zmonvif-probe.pl probe
Can't locate object method "new" via package "WSDiscovery10::Elements::MessageID" (perhaps you forgot to load "WSDiscovery10::Elements::MessageID"?) at /usr/share/perl5/vendor_perl/SOAP/WSDL/XSD/Typelib/ComplexType.pm line 225.

The following fixed it for me but I don't know if this is correct or not:

diff --git a/onvif/proxy/lib/WSDiscovery10/Elements/Header.pm b/onvif/proxy/lib/WSDiscovery10/Elements/Header.pm
index df2d7f3..b68a6e2 100644
--- a/onvif/proxy/lib/WSDiscovery10/Elements/Header.pm
+++ b/onvif/proxy/lib/WSDiscovery10/Elements/Header.pm
@@ -3,6 +3,10 @@ package WSDiscovery10::Elements::Header;
 use strict;
 use warnings;

+use WSDiscovery10::Elements::MessageID;
+use WSDiscovery10::Elements::Action;
+use WSDiscovery10::Elements::ReplyTo;
+use WSDiscovery10::Elements::To;

 __PACKAGE__->_set_element_form_qualified(0);

After making these changes I see the messages going out on the wire and I get lots of responses back but none of them are decoded:

$ zmonvif-probe.pl probe
$

Adding '-v' I get the same error message for each response:

Error deserializing message. No message returned from deserializer.

[altaroca]

@jburgess777 I undid the changes to the typemap. I think those were responsible for not recognizing your cameras' responses.
I do not need the four use statements. For me it works without them. The SOAP::WSDL generated proxy classes usually do not use their sub-elements' classes.

[jburgess777]

@altaroca with your latest changes I still see the error about being unable to locate the 'new' method. I'm trying this on F23. I don't enough about the Perl object rules to know what the right answer is.

With these changes I get responses from 5 of my 6 cameras. The last camera seems to get confused by the way I quoted the namespace in the line below. Perhaps it can be rewritten to define and use an xmlns instead?

      Types => 'http://www.onvif.org/ver10/network/wsdl:NetworkVideoTransmitter http://www.onvif.org/ver10/device/wsdl:Device'

[altaroca]

I am not sure how the perl class resolver works either.
I tried using namespace aliases with this code:

$result = $svc_discover->ProbeOp(
    { # WSDiscovery::Types::ProbeType
      xmlattr => { 'xmlns:dn'  => 'http://www.onvif.org/ver10/network/wsdl',
                   'xmlns:tds' => 'http://www.onvif.org/ver10/device/wsdl', },
      Types => 'dn:NetworkVideoTransmitter tds:Device', # QNameListType
      Scopes =>  { value => '' },
    }, ...

SOAP::WSDL does not serialize the attributes, though. I have to investigate further.

[jburgess777]

I was looking into how to persuade the code to add the other namespaces but wasn't able to make it happen. For what it's worth, gsoap handles the serialization of QName fields using this code:

https://sourceforge.net/p/gsoap2/code/HEAD/tree/gsoap/stdsoap2.cpp#l14568

When parsing a QName in the form "X":Y it interprets this to mean that X is a namespace which it first tries to find in the existing namespace list and, if not found, it automatically adds it. Then the element is serialized using the appropriate namspace prefix. The equivalent SOAP::WSDL::XSD::Typelib::Builtin::QName.pm looks like it treats it like a string without any special serialization. This seems to be a missing feature in the SOAP-WSDL code.

[connortechnology]

Looks like this adds libdata-uuid-perl as another dependency

[altaroca]

The last commit enables us to use namespace aliases in the Types element. It is not beautiful - it is a workaround. The goal should be to fix SOAP::WSDL eventually.
Note: I added the namespaces to <Probe> because <Types> is not a ComplexType which makes things more difficult.

[connortechnology]

So your comments imply that this is a temporary hack. Is it? Is there a better PR coming?

[altaroca]

This PR is not a hack. The commit 5d3f5e5 is kind of a hack because it replaces SOAP::WSDL functionality. I added it to see if we get all of @jburgess777's and @knnniggett's cameras working. If we do then I propose to stick with this commit. The alternative would be updating or forking SOAP::WSDL -- which I do not have the time for.
On the other hand if the commit does not improve things then we can scrap it.

[knight-of-ni]

Hey, wait a second. We don't know if this PR makes the issue better or worse because I have not tested it yet.

[connortechnology]

This code is better. It finds my Trendnet TV-IP862-IC

[knight-of-ni]

@altaroca the onvif-probe is no working at all for the following environments:

CentOS 7 - I get the same error @siigna reported here: #1397 (comment)

Fedora 23 - I get the same error @jburgess777 reported earlier in this thread: #1411 (comment)

[siigna]

CentOS 7 - I get the same error @siigna reported here: #1346 (comment)

Sorry, deleted my comment from that issue and moved it over to #1397.

[knight-of-ni]

@siigna I've updated my previous post to reflect your move.

We previously had the ONVIF probe working much better than in our previous release, but it looks like we've had a rather serious regression as it doesn't even run anymore the systems I test from.