Recent changes to Home

Home modified by Stephen Rhodes

Stephen Rhodes — Sat, 23 Mar 2019 18:27:52 -0000

--- v7
+++ v8
@@ -3,3 +3,5 @@
 [Discovery](https://sourceforge.net/p/libonvif/wiki/Discovery/)

 [PTZ Functions](https://sourceforge.net/p/libonvif/wiki/PTZ%20Functions/)
+
+[Rationale](https://sourceforge.net/p/libonvif/wiki/Rationale/)

Home modified by Stephen Rhodes

Stephen Rhodes — Sat, 23 Mar 2019 17:38:04 -0000

--- v6
+++ v7
@@ -1,3 +1,5 @@
 #  libonvif - cross platform library for controlling IP cameras

 [Discovery](https://sourceforge.net/p/libonvif/wiki/Discovery/)
+
+[PTZ Functions](https://sourceforge.net/p/libonvif/wiki/PTZ%20Functions/)

Home modified by Stephen Rhodes

Stephen Rhodes — Sat, 23 Mar 2019 17:34:35 -0000

--- v5
+++ v6
@@ -1 +1,3 @@
 #  libonvif - cross platform library for controlling IP cameras
+
+[Discovery](https://sourceforge.net/p/libonvif/wiki/Discovery/)

Home modified by Stephen Rhodes

Stephen Rhodes — Sat, 23 Mar 2019 17:31:32 -0000

--- v4
+++ v5
@@ -1,11 +1 @@
 #  libonvif - cross platform library for controlling IP cameras
-**Rationale for developing libonvif**
-
-libonvif was developed as an alternative to the traditional cross platform method of connecting with Onvif compatible devices using GSOAP and OPENSSL.  This approach was tried during the early stages of this effort during which a number of problems were encountered.  Aside from the difficulty of compiling gsoap for (sometimes defunct) wsdl standard files and the shifting groundwork under openssl, the performance of the final product was weak as it failed to connect to a significant number of devices and was failing in discovery under windows in about half of the instances in which it was launched.  Attempting to fix these problems in the source file for gsoap proved untenable as the root cause of the problems was buried so deep in the mountain of code that the effort was abandoned.
-
-Gsoap failed to properly communicate with Hikvision cameras due to a lack of compliance with the Onvif standard in the html header files wrapping the xml code sent to the device.  You can observe the header with Wireshark and see that there is a section indicating the service associated with the function the xml code is invoking.  Most devices are tolerant of this parameter and will accept a generic device_service.  This is not the case for Hikvision, which will fail if the exact string is not observed.  The techincally correct method of sending this call is to query the device for its Capabilities and then use the returned service string identifiers to call functions for the respective services.  Gsoap is hard coded to use device_service for all of these calls, which Hikvision will reject when addressing services other than device_service.
-
-There is another using when using windows that arises in this configuration.  Gsoap fails to initialize the udp broadcast socket properly during preperation for the broadcast routine.  This is not an issue in linux and mac systems as the default socket obtained during setsocketopt call is the one you would expect. Windows on the other hand, will randomly return a socket without qualification, often resulting in the loopback socket, which is obviously not going to get you any traffic on the network.  This requires a bit of hunting through the IpAddrable under windows to find a socket that will actually communicate over the network.
-
-Furthermore, Gsoap will rely on the default wsdl specification for the discovery xml message syntax during the discover process.  Many cameras will not respond to this message, for whatever reason.  The message used in libonvif was developed by trial and error over a large number of different types of camera to find one that will work most often.  There is additionally a secondary message that may be invoked should the primary message fail to elicit a response from a particular device.
-

Home modified by Stephen Rhodes

Stephen Rhodes — Sat, 23 Mar 2019 17:27:07 -0000

--- v3
+++ v4
@@ -1,32 +1,4 @@
 #  libonvif - cross platform library for controlling IP cameras
-**Using libonvif to discover cameras on the network**
-
-Discovery is probably the most likely reason to use this library.  This will allow software developers to write programs that do not force the user to hard code the ip addresses of the cameras.  Any systems administrator knows that static ip addresses are a nightmare to maintain and a proper network configuration will include DHCP for devices residing on the network.  The end result of a discovery process is the RTPS string associated with a camera, which can be sent to another part of the program for decoding and display.  Other camera functions may be controlled as well with libonif, including camera resolution, frame rate, PTZ functions, etc.  These other functions are discussed later in this document.
-
-There is an example program included with libonvif that will perform discovery.  A detailed analysis of the program is provided below.
-
-The discovery program starts with the memory allocation for two data structures
-
-   struct OnvifSession *onvif_session = (struct OnvifSession*)malloc(sizeof(struct OnvifSession));
-   struct OnvifData *onvif_data = (struct OnvifData*)malloc(sizeof(struct OnvifData));
-
-If you are used to C++ programming, these might seem strange.   libonvif is a C library so it requires that you allocate the memory for data structures, whereas C++ manages the memory behind the scenes.  The structures are defined in the onvif.h header file, so you can refer to that for more detail.  The malloc call shown above will allocate memory on the computer heap so that the structure will have a place to reside.  It is important to note that when using this convention that it is incumbent on the programmer to deallocate the memory after the use of the structures to return memory to the system.  Failure to do so will result in memory leaks which may cause unusual behavior later on during program execution.  This is done with the free call as shown below, which should be called when the structure are no longer needed.
-
-   free(onvif_data);
-   free(onvif_session);
-
-In addition the allocation of memory, there are a number of initializations that must be performed before the system may begin the process of discovery.  Similar to the malloc and free calls shown above, there is an initializeSession and closeSession function calls that perform these duties.  The function pair is shown below.  As in the case of memory allocation, the initializeSession function must be called before further processing and the closeSession function is called when the routine is finished.
-
-
-
-   initializeSession(onvif_session);
-   closeSession(onvif_session);
-
-initializeSession will set a GUID identifier that us sent out with the broadcast packet.  The idea is that this will discriminate between multiple instances of the broadcast routine.  It will also set a discovery_msg_id.  The default here is 1, but there is a secondary message that my be used in the event that a camera does not respond to the first message.  This may occur in practice as the camera makers are not very strict about compliance with standards.  The secondary message has nearly the same content but a slightly different format which may elicit response from cameras not in full compliance with the standard.  Additionally, the Windows network is initialized.  The xml parser included with libxml2 is initialized as well, although it is unclear if this is completely necessary.  There was a time when libxml2 was considered to be unsafe to use with respect to memory leaks and re-entrancy problems, although these seem to have been fixed.  The closeSession call performs the complementary close functions respectively.
-
-
-
-
 **Rationale for developing libonvif**

 libonvif was developed as an alternative to the traditional cross platform method of connecting with Onvif compatible devices using GSOAP and OPENSSL.  This approach was tried during the early stages of this effort during which a number of problems were encountered.  Aside from the difficulty of compiling gsoap for (sometimes defunct) wsdl standard files and the shifting groundwork under openssl, the performance of the final product was weak as it failed to connect to a significant number of devices and was failing in discovery under windows in about half of the instances in which it was launched.  Attempting to fix these problems in the source file for gsoap proved untenable as the root cause of the problems was buried so deep in the mountain of code that the effort was abandoned.

Home modified by Stephen Rhodes

Stephen Rhodes — Sat, 23 Mar 2019 16:44:49 -0000

--- v2
+++ v3
@@ -1 +1,39 @@
 #  libonvif - cross platform library for controlling IP cameras
+**Using libonvif to discover cameras on the network**
+
+Discovery is probably the most likely reason to use this library.  This will allow software developers to write programs that do not force the user to hard code the ip addresses of the cameras.  Any systems administrator knows that static ip addresses are a nightmare to maintain and a proper network configuration will include DHCP for devices residing on the network.  The end result of a discovery process is the RTPS string associated with a camera, which can be sent to another part of the program for decoding and display.  Other camera functions may be controlled as well with libonif, including camera resolution, frame rate, PTZ functions, etc.  These other functions are discussed later in this document.
+
+There is an example program included with libonvif that will perform discovery.  A detailed analysis of the program is provided below.
+
+The discovery program starts with the memory allocation for two data structures
+
+   struct OnvifSession *onvif_session = (struct OnvifSession*)malloc(sizeof(struct OnvifSession));
+   struct OnvifData *onvif_data = (struct OnvifData*)malloc(sizeof(struct OnvifData));
+
+If you are used to C++ programming, these might seem strange.   libonvif is a C library so it requires that you allocate the memory for data structures, whereas C++ manages the memory behind the scenes.  The structures are defined in the onvif.h header file, so you can refer to that for more detail.  The malloc call shown above will allocate memory on the computer heap so that the structure will have a place to reside.  It is important to note that when using this convention that it is incumbent on the programmer to deallocate the memory after the use of the structures to return memory to the system.  Failure to do so will result in memory leaks which may cause unusual behavior later on during program execution.  This is done with the free call as shown below, which should be called when the structure are no longer needed.
+
+   free(onvif_data);
+   free(onvif_session);
+
+In addition the allocation of memory, there are a number of initializations that must be performed before the system may begin the process of discovery.  Similar to the malloc and free calls shown above, there is an initializeSession and closeSession function calls that perform these duties.  The function pair is shown below.  As in the case of memory allocation, the initializeSession function must be called before further processing and the closeSession function is called when the routine is finished.
+
+
+
+   initializeSession(onvif_session);
+   closeSession(onvif_session);
+
+initializeSession will set a GUID identifier that us sent out with the broadcast packet.  The idea is that this will discriminate between multiple instances of the broadcast routine.  It will also set a discovery_msg_id.  The default here is 1, but there is a secondary message that my be used in the event that a camera does not respond to the first message.  This may occur in practice as the camera makers are not very strict about compliance with standards.  The secondary message has nearly the same content but a slightly different format which may elicit response from cameras not in full compliance with the standard.  Additionally, the Windows network is initialized.  The xml parser included with libxml2 is initialized as well, although it is unclear if this is completely necessary.  There was a time when libxml2 was considered to be unsafe to use with respect to memory leaks and re-entrancy problems, although these seem to have been fixed.  The closeSession call performs the complementary close functions respectively.
+
+
+
+
+**Rationale for developing libonvif**
+
+libonvif was developed as an alternative to the traditional cross platform method of connecting with Onvif compatible devices using GSOAP and OPENSSL.  This approach was tried during the early stages of this effort during which a number of problems were encountered.  Aside from the difficulty of compiling gsoap for (sometimes defunct) wsdl standard files and the shifting groundwork under openssl, the performance of the final product was weak as it failed to connect to a significant number of devices and was failing in discovery under windows in about half of the instances in which it was launched.  Attempting to fix these problems in the source file for gsoap proved untenable as the root cause of the problems was buried so deep in the mountain of code that the effort was abandoned.
+
+Gsoap failed to properly communicate with Hikvision cameras due to a lack of compliance with the Onvif standard in the html header files wrapping the xml code sent to the device.  You can observe the header with Wireshark and see that there is a section indicating the service associated with the function the xml code is invoking.  Most devices are tolerant of this parameter and will accept a generic device_service.  This is not the case for Hikvision, which will fail if the exact string is not observed.  The techincally correct method of sending this call is to query the device for its Capabilities and then use the returned service string identifiers to call functions for the respective services.  Gsoap is hard coded to use device_service for all of these calls, which Hikvision will reject when addressing services other than device_service.
+
+There is another using when using windows that arises in this configuration.  Gsoap fails to initialize the udp broadcast socket properly during preperation for the broadcast routine.  This is not an issue in linux and mac systems as the default socket obtained during setsocketopt call is the one you would expect. Windows on the other hand, will randomly return a socket without qualification, often resulting in the loopback socket, which is obviously not going to get you any traffic on the network.  This requires a bit of hunting through the IpAddrable under windows to find a socket that will actually communicate over the network.
+
+Furthermore, Gsoap will rely on the default wsdl specification for the discovery xml message syntax during the discover process.  Many cameras will not respond to this message, for whatever reason.  The message used in libonvif was developed by trial and error over a large number of different types of camera to find one that will work most often.  There is additionally a secondary message that may be invoked should the primary message fail to elicit a response from a particular device.
+

Home modified by Stephen Rhodes

Stephen Rhodes — Sat, 23 Mar 2019 15:32:08 -0000

--- v1
+++ v2
@@ -1,8 +1 @@
-Welcome to your wiki!
-
-This is the default page, edit it as you see fit. To add a new page simply reference it within brackets, e.g.: [SamplePage].
-
-The wiki uses [Markdown](/p/libonvif/wiki/markdown_syntax/) syntax.
-
-[[members limit=20]]
-[[download_button]]
+#  libonvif - cross platform library for controlling IP cameras

Home modified by Stephen Rhodes

Stephen Rhodes — Wed, 21 Mar 2018 00:52:35 -0000

Welcome to your wiki!

This is the default page, edit it as you see fit. To add a new page simply reference it within brackets, e.g.: [SamplePage].

The wiki uses Markdown syntax.

Project Members:

Stephen Rhodes (admin)