ONVIF issue on DM36xIPNC V3.0

Dear all,

After the evaluation of the new camera firmware(DM36xIPNC V3.0), I have some issues which I would like to discuss and get answers. So here are the technical questions to the FW version 3.0:

1. ONVIF discover：

The camera does not appear among discovered devices in the ONVIF test tool.

(1) The boa web server dies on certain requests immediately either SIGSEGV.

=============================================================

 for example, immediate segfault triggered by POST to /onvif/services:

            <?xml version="1.0" encoding="UTF-8"?>

            <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:tev="http://www.onvif.org/ver10/events/wsdl">

            <soap:Body><tev:GetEventProperties/></soap:Body>

            </soap:Envelope>

        or glibc-detected memory corruption            http://root:twentysevencharpasswordpoof@192.168.34.205/ini.htm *** glibc detected *** ./boa: munmap_chunk(): invalid pointer: 0x004835a8 ***            *** glibc detected *** /opt/ipnc/boa: double free or corruption (out): 0x004835a8 ***

=============================================================

(2) ONVIF very frequent spurious connection teardowns by the web server without any apparent reason.

============================================================

For example, the server does not segfault and does not print anything to stdout/stderr

non-deterministic: when any request is repeated, the connection sometimes dies, sometimes it does not connection closed by the RTSP server every ~10-90 seconds

(streaming RTP over RTSP) tested with rtsp://192.168.34.205:8557/Onvif/Streaming/2?videoCodecType=H.264

"out of memory" responses to ONVIF requests non-deterministic, no apparent reason once it starts happening, almost no ONVIF request succeeds until the webserver is killed and launched again if any request is repeated, it mostly fails with OOM error, but sometimes it does not nothing is printed in the stdout/stderr of the webserver. Example (the malformed HTTP version in the response is copied verbatim from the ONVIF test tool):

=============================================================

POST /onvif/services HTTP/1.1

Host: 192.168.34.205

Content-Type: application/soap+xml; charset=utf-8 Content-Length: 289

<?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">

    <GetProfiles xmlns="http://www.onvif.org/ver10/media/wsdl" />

 </s:Body>

</s:Envelope>

HTTP/�h@ 400 Bad Request

Server: gSOAP/2.8

Content-Type: application/soap+xml; charset=utf-8

Content-Length: 2721

Connection: close

<?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

xmlns:dn="http://www.onvif.org/ver10/network/wsdl" xmlns:wsa5="http://www.w3.org/2005/08/addressing" xmlns:xmime="http://tempuri.org/xmime.xsd" 

xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:tt="http://www.onvif.org/ver10/schema"

xmlns:wsrfbf="http://docs.oasis-open.org/wsrf/bf-2" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1"

xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:ns2="http://www.onvif.org/ver10/network/wsdl/RemoteDiscoveryBinding"

xmlns:ns3="http://www.onvif.org/ver10/network/wsdl/DiscoveryLookupBinding" xmlns:ns1="http://www.onvif.org/ver10/network/wsdl"

xmlns:ns4="http://www.onvif.org/ver20/analytics/wsdl/RuleEngineBinding" xmlns:ns5="http://www.onvif.org/ver20/analytics/wsdl/AnalyticsEngineBinding"

xmlns:ns6="http://docs.oasis-open.org/wsn/b-2" xmlns:ns7="http://docs.oasis-open.org/wsn/t-1" xmlns:ns9="http://www.onvif.org/ver10/events/wsdl/EventBinding"

xmlns:tet="http://www.onvif.org/ver10/events/wsdl" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" xmlns:tad="http://www.onvif.org/ver10/analyticsdevice/wsdl"

xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tls="http://www.onvif.org/ver10/display/wsdl"

xmlns:tmd="http://www.onvif.org/ver10/deviceIO/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:trc="http://www.onvif.org/ver10/recording/wsdl"

xmlns:trp="http://www.onvif.org/ver10/replay/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:trv="http://www.onvif.org/ver10/receiver/wsdl"

xmlns:tse="http://www.onvif.org/ver10/search/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" xmlns:tns1="http://www.onvif.org/ver10/topics"

xmlns:dis="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">

 <SOAP-ENV:Body>

  <SOAP-ENV:Fault>

   <SOAP-ENV:Code>

    <SOAP-ENV:Value>SOAP-ENV:Sender</SOAP-ENV:Value>

   </SOAP-ENV:Code>

   <SOAP-ENV:Reason>

    <SOAP-ENV:Text xml:lang="en">Out of memory</SOAP-ENV:Text>

   </SOAP-ENV:Reason>

  </SOAP-ENV:Fault>

 </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

=============================================================

2. RTSP service

Currently, RTSP streams have to be obtained from services listening on different ports, the ports depending on the particular codec and setup of the stream this setup is troublesome adds a layer of weirdness and a source of possible confusion for the average users need to remember different non-standard RTSP port numbers the set of correct ports change whenever the configuration of the camera changes adds inconvenience requires users to actively find out what the correct RTSP port is and do additional configuration of their RTSP clients prevents reasonable automation of streaming different codecs are streamed from different ports but most software supports a single RTSP port per device the set of correct ports change whenever the configuration of the camera changes — clients need to update their configuration on events they don't get notification about prevents reasonable automated port forwarding the list of ports has to be obtained from the camera however, the list is typically useless in the scenarios involving the camera behind a NAT to work-around, users need to figure out what the correct ports are, tunnel them completely manually and configure their clients accordingly (as already mentioned, most software supports a single RTSP port per device) proposed alternative RTSP service listening on the standard port 554 URL-based dispatch of RTSP requests.

Can anyone give me some hints on those portions? Thanks in advance.

B.R.

OC