When a camera is installed inside the Ulisse's housing, it has to be fed using the 12VDC power lines provided on the dedicated clamps. PoE for the camera is not available so far.
The architecture of the system has been organized in order for the Ulisse to provide the camera with all the network services that allow a successful communication with the external peers (VMS, Web Browser, Device Manager, ...); from the camera point of view, the Ulisse is:
- a Router: being in the middle between the VMS on a Public Network (e.g. 192.168.0.100/24, as per factory default) and the Camera on a Private Network (192.0.0.0/24), the Ulisse is the Default Gateway for the camera to reach the external world.
It really has routing capabilities indeed: you can also use the Ulisse as a Gateway the communicate directly with the camera from your PC (see Tips & Tricks, Ulisse Netcam: direct access to the camera); - a DHCP Server: the Private Network's addressing is managed automatically by the Ulisse; this avoids the user to insert the camera address manually from the Ulisse web pages, and also cuts out problems due to misconfigurations of the camera. The camera must be DHCP enabled therefore.
The Ulisse will assign it with the 192.0.0.64 (always the same), having the 192.0.0.1 for itself; - a NTP Server: ONVIF authentication requires the peers to have the same time. In the Ulisse Netcam, two authentications take place: the Ulisse needs to log into the camera to get the video and the camera parameters; the VMS needs to log into the Ulisse to get the video and the Ulisse parameters.
All the peers needs to share the same time source therefore for a successful authentication. The Ulisse takes the time from an external NTP Server, and it redistributes the time to the camera.
The camera must be NTP enabled therefore; the NTP Server's address can be retrieved by the camera from DHCP, or manually configured to 192.0.0.1 (the Ulisse's internal address).
Note that, as per NTP specifications, the Ulisse won't synchronize the camera if it hasn't been able to synchronize its internal clock in advance with a valid time source. - a RTSP Proxy: for sure the most innovative feature of the Ulisse Netcam is the ability of being managed completely from the VMS with a single IP Address. The camera's IP (192.0.0.64) is never ever seen externally.
The Ulisse anyway does nothing on the video stream: what the VMS receives is what the camera sends out, the Ulisse is just a forwarder.
So how to hide that 192.0.0.64 inside the stream? With a RTSP Proxy: the Ulisse receives the video streams from the camera and re-transmit them toward the VMS.
The point is: when the camera boots up, all the services above must be up and running already; the DHCP must be available when the camera asks for a network configuration; the NTP must be ok when the clock must be distributed, the RTSP Proxy must be ready to receive and forward the video stream to the VMS.
Different cameras have different booting time. If both the Ulisse and the Camera start the boot procedures when the plug is connected, the latter can be quicker, finding unavailable services when it tries to reach them. For example, if the DHCP Server is not ready when the camera searches for it, the camera will take its factory default IP (e.g. 192.168.0.90 for the Axis), or a ZeroConf IP (e.g. 169.254.23.178); on such situation the communication would be impossible.
The only way to achieve a correct startup is giving power to the camera only when the Ulisse is ready to accept requests from it. That's why the camera can not be powered directly from the 12VCD-GND housing clamps, but through an additional switch/relay, which is activated as soon as the Ulisse finishes its startup; the D/N switch beside the power clamps is used for this aim, with the insertion of an additional jumper. Wiring diagram is reported inside the Ulisse User Manual.
To minimize the CPU load, as well as to increase the bandwidth availability for the video streams, the RTSP Proxy function has been cut.
Starting from firmware version 1.7, the Ulisse's CPU just perform a simple NAT (Network Address Translation) over the RTP video stream: the packets are managed at a lower level, changing the UDP header only, which makes the procedure quicker and less CPU-demanding.
Nothing changes on the VMS side; just a tiny detail: using the RTSP Proxy, the URI format was constant and not related with the camera model used inside the Ulisse, because the video was really transmitted by the CPU (even with no post-elaboration); with a simple NAT, the URI format depends on the camera, and therefore it changes camera-by-camera.
Not a big deal anyway, since everything is managed automatically by the VMS: when the Ulisse is connected, the software asks for the URI to require the video stream to, and the Ulisse replies with the correct one.
No drawbacks for the user, just benefits.