Allow connection to camera IP address

[horga83]

Onvif-gui, please add a way to manually add a camera on a different IP address.

Thanks

[sr99622]

Hi, thank you for your suggestions. I'm not sure I understand your request however. If there is a use case scenario that would benefit from this feature, it could be added.

If you are looking for a camera on a separate sub-net you can use the network interface selection box on the settings tab to find cameras on other sub-nets.

One of the core concepts of ONVIF is that the camera can be discovered automatically, so manually adding cameras goes against that philosophy. If a camera is unable to be discovered via ONVIF, it wouldn't be much use to the program anyway. If you have a non-ONVIF camera RTSP you can use ffplay to view the output if that is what you're looking for.

[horga83]

Thank you for your response.

It seems when I click on the "Network" tab, all the UI elements are disabled, I cannot click on any of them to enter text.

While one of the core concepts of ONVIF is that a camera can be discovered, it is also a core concept to allow one to control a remote camera, this is normally achieved by directly entering the cameras data, IP address etc.   Many network admins also disapprove of network scanning. 

You do allow one to enter a host with the onvif-cli application so I'm not sure I understand why one could not  do this with onvif-gui.

Thank you George

On Thu, 2022-12-29 at 07:39 -0800, sr99622 wrote:

Hi, thank you for your suggestions. I'm not sure I understand your request however. If there is a use case scenario that would benefit from this feature, it could be added. If you are looking for a camera on a separate sub-net you can use the network interface selection box on the settings tab to find cameras on other sub-nets. One of the core concepts of ONVIF is that the camera can be discovered automatically, so manually adding cameras goes against that philosophy. If a camera is unable to be discovered via ONVIF, it wouldn't be much use to the program anyway. If you have a non-ONVIF camera RTSP you can use ffplay to view the output if that is what you're looking for. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[sr99622]

Hi George,

The network box is populated automatically based on your active network connections. If you only have one active network connection, it will appear disabled as there is only one selection available. If the computer is actively connected to multiple networks, there should be a corresponding selection for each one in the box. The connection will not show unless it is active.

The onvif-cli application is giving an illusion that the user is entering the IP address. There is a broadcast call underneath that compares what was entered by the user with what was returned by the broadcast. If the user data matches an entry in the broadcast responses, the program then uses the data returned by the broadcast to connect to the camera. The broadcast is not a network scan, it's a UDP multicast packet that the cameras respond to with their data. It's very similar to the Bonjour protocol used to find wireless printers.

[horga83]

Ok so what I gather from your response is, your application is not useful for cameras that are located at a remote site.

For example, I can run onvifviewer under Arch linux, it's in the AUR, enter an IP address, a username and password and communicate with the camera.  Your application is restricted from this type of operation.

Is that correct?

George

On Thu, 2022-12-29 at 09:35 -0800, sr99622 wrote:

Hi George, The network box is populated automatically based on your active network connections. If you only have one active network connection, it will appear disabled as there is only one selection available. If the computer is actively connected to multiple networks, there should be a corresponding selection for each one in the box. The connection will not show unless it is active. The onvif-cli application is giving an illusion that the user is entering the IP address. There is a broadcast call underneath that compares what was entered by the user with what was returned by the broadcast. If the user data matches an entry in the broadcast responses, the program then uses the data returned by the broadcast to connect to the camera. The broadcast is not a network scan, it's a UDP multicast packet that the cameras respond to with their data. It's very similar to the Bonjour protocol used to find wireless printers. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[sr99622]

Hi George,

It is very helpful to hear about your experience with the program to gain insights on how it is used on the field. I have heard about onvifviewer, but I don't have any direct experience with it. My understanding is that it is not currently under development.

I was not aware that you were asking about accessing remote cameras. If I understand correctly, this could be a situation where the camera is connected directly to the internet and a user with proper credentials would be able to access it from any location. Alternatively, I can imagine a scenario where the cameras are on a private remote network and tunneling is used to access the device.

Regarding a camera connected directly to the internet, the security implications of managing a connection like this are significant and beyond the scope of libonvif. My personal opinion is that the cameras should be isolated from all other networks, especially the internet, as a precaution against network infiltration. This is the motivation behind the networks selection box on the settings tab, as it would allow the administrator to build a separate isolated subnet exclusively for the cameras.

If you are in a private network scenario, it is likely that you could get the broadcast to work with some effort. There may be router settings or such that permit UDP packets to traverse the different networks. It may be as simple as opening the broadcast port (3702). Alternatively, there may be tactics the application itself could use such as setting packet flags in some way. In any case, I lack the resources to develop and test functionality on that type of network.

[horga83]

Some very large assumptions there.  In my experience most cameras are remote.  I hope this doesn't come across in the wrong way but I get the impression you haven't been around corporate networks.  Things just don't work like a private network and convincing network admins to change something is a task at the best of times and rightly so.

At any rate thanks for the reply. 

On Thu, 2022-12-29 at 14:39 -0800, sr99622 wrote:

Hi George, It is very helpful to hear about your experience with the program to gain insights on how it is used on the field. I have heard about onvifviewer, but I don't have any direct experience with it. My understanding is that it is not currently under development. I was not aware that you were asking about accessing remote cameras. If I understand correctly, this could be a situation where the camera is connected directly to the internet and a user with proper credentials would be able to access it from any location. Alternatively, I can imagine a scenario where the cameras are on a private remote network and tunneling is used to access the device. Regarding a camera connected directly to the internet, the security implications of managing a connection like this are significant and beyond the scope of libonvif. My personal opinion is that the cameras should be isolated from all other networks, especially the internet, as a precaution against network infiltration. This is the motivation behind the networks selection box on the settings tab, as it would allow the administrator to build a separate isolated subnet exclusively for the cameras. If you are in a private network scenario, it is likely that you could get the broadcast to work with some effort. There may be router settings or such that permit UDP packets to traverse the different networks. It may be as simple as opening the broadcast port (3702). Alternatively, there may be tactics the application itself could use such as setting packet flags in some way. In any case, I lack the resources to develop and test functionality on that type of network. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[arkanoid87]

Hi, thank you for your suggestions. I'm not sure I understand your request however. If there is a use case scenario that would benefit from this feature, it could be added.

If you are looking for a camera on a separate sub-net you can use the network interface selection box on the settings tab to find cameras on other sub-nets.

One of the core concepts of ONVIF is that the camera can be discovered automatically, so manually adding cameras goes against that philosophy. If a camera is unable to be discovered via ONVIF, it wouldn't be much use to the program anyway. If you have a non-ONVIF camera RTSP you can use ffplay to view the output if that is what you're looking for.

this is so wrong in so many ways

ONVIF supports remote endpoints auto-discovery is just an option

[sr99622]

Thank you for the feedback. I do however, disagree with your assessment. Regarding discovery, I have included the relevant code segment.

    void discover()
    {
        if (interface.length() > 0) {
            memset(session->preferred_network_address, 0, 16);
            strcpy(session->preferred_network_address, interface.c_str());
        }
        int number_of_devices = broadcast(session);
        std::vector<Data> devices;

        for (int i = 0; i < number_of_devices; i++) {
            Data data;
            if (prepareOnvifData(i, session, data)) {
                if (std::find(devices.begin(), devices.end(), data) == devices.end()) {
                    devices.push_back(data);
                    bool first_pass = true;
                    while (true) {
                        data = getCredential(data);
                        if (!data.cancelled) {
                            if (fillRTSP(data) == 0) {
                                getProfile(data);
                                getDeviceInformation(data);
                                getData(data);
                                break;
                            }
                            else {
                                getTimeOffset(data);
                                time_t rawtime;
                                struct tm timeinfo;
                                time(&rawtime);
                            #ifdef _WIN32
                                localtime_s(&timeinfo, &rawtime);
                            #else
                                localtime_r(&rawtime, &timeinfo);
                            #endif
                                if (timeinfo.tm_isdst) {
                                    data.setTimeOffset(data.time_offset() - 3600);
                                    if (first_pass) {
                                        data.clearLastError();
                                        first_pass = false;
                                    }
                                }
                            }
                        } 
                        else {
                            break;
                        }
                    }
                }
            }
        }

        discovered();
    }

You can see there is a section where the program queries the camera for some data

  fillRTSP(data)
  getProfile(data);
  getDeviceInformation(data);
  getData(data);
  getTimeOffset(data);

These queries provide data that is necessary for subsequent ONVIF commands. The xaddrs and time offset along with the user credentials go into the http header as an xml string each time an onvif command is sent. Other data is collected as well that is necessary for successful communication. For example, in order to change the video resolution, the program needs to know the profile and the available resolutions on the camera.

This is why I would say that discovery is a core concept. It might be theoretically possible to find a way to collect the necessary header information using some other method, but it would not be a very practical program. There may be some cameras out there that do not implement the full ONVIF spec and are able to use a limited subset of commands without these requirements, but that would not apply to the general population of cameras.

Regarding remote camera communication, as I mentioned in the thread, it is not a scenario that I have tested for. It should be possible to do, and would involve sending the discovery packets to the remote network. This would be similar to a Network Address Translation function that would need to accommodate UDP packets, and would most likely require opening ports on the router, which obviously should be done very carefully.

Of course, this is all just my own humble opinion, and I am open to hearing the counter argument.

[arkanoid87]

forget discovery, ask user for IP and ONVIF port (which can be remote public IP, or whatever) and query endpoint as necessary.

Auto discovery is just a process to speed things up when ONVIF devices to be managed/added are local, not a requirement.

I don't need to provide you a counter argument, just download one of the many conformant client products for profile S and check how they let you handle remote ONVIF endpoint

https://www.onvif.org/conformant-products/

some of then offer demo or free tier, and some of them are market leaders. Won't name anyone as I don't want to appear biased.

[sr99622]

What you are saying is indeed correct. With the IP address and the ONVIF port, it is possible to construct the xaddrs string which is necessary for communication with the camera. The parameters I cited above would be accessible with this minimum required data, so in the case where the user has this information, discovery would not be required.

[horga83]

I have to agree being able to add an IP address and port is a no brainer.

George

On November 11, 2023 8:41:34 a.m. PST, arkanoid87 @.***> wrote:

forget discovery, ask user for IP and ONVIF port (which can be remote public IP, or whatever) and query endpoint as necessary.

Auto discovery is just a process to speed things up when ONVIF devices to be managed/added are local, not a requirement.

I don't need to provide you a counter argument, just download one of the many conformant client products for profile S and check how they let you handle remote ONVIF endpoint

https://www.onvif.org/conformant-products/

some of then offer demo or free tier, and some of them are market leaders. Won't name anyone as I don't want to appear biased.

-- Reply to this email directly or view it on GitHub: https://github.com/sr99622/libonvif/issues/46#issuecomment-1806861598 You are receiving this because you authored the thread.

Message ID: @.***>

[abdul3909]

Hello, I also want to add remote cameras. Can the onvif username/password and IP address be added manually or not? Like any code changes we can make?

[ThomasLamprecht]

FWIW, I'd also like to add a camera manually in a routed setup. My reason for this is that I can only connect to my NVR and cameras through a WireGuard VPN and even there with an explicit IP route added as the camera IP is using a LAN IP, not one from the VPN network.

So the select network option does not work for me, and I'd think there are many other network configurations where the camera IP is actually not one of the local networks, like basically any setup with some basic routing involved.

IMO while the existing "select from configured networks on real NICs" is a nice extra convenience option, being able to pass an IP, or CIDR network, manually for such routed setups would be really great. Potentially the network selector could be made editable so that one can enter a different CIDR there, that way the interface would not gain new UI components at all, and while it might not be perfect UX-wise, this should be still clear enough.

[sr99622]

Hi Thomas,

Thank you so much for reaching out, your inquiry is greatly appreciated. The feature requested here has been developed into the next version of onvif-gui which is coming soon. There are a bunch of other features that are included in the update, which requires a re-working of much of the supporting libraries used so it's kind of a big bang situation where everything is released at once.

I am working feverishly to pull it together and the system is very close to final testing. Also included in the update are the ability to stream multiple cameras simultaneously, using camera substreams for display and detection, onvif audio controls and deeper file management capabilities, so it should be worth the wait. I should be able to release in the next couple of weeks.

The comments here are very important for me as I have learned many things I would not otherwise know from posts made by contributors, so my thanks go out to all that have provided comments.

Best Regards,

Stephen

[sr99622]

Onvif GUI version 2 has been released with the ability to add remote cameras by IP address

[ThomasLamprecht]

Thanks, I can confirm this is working. The issue here can probably just be closed then.