Key article: How to set up a network camera (a.k.a. IP camera)

Chat (beta)

Mobile Apps

ONVIFTM is an international non-profit organization promoting standardization of the interface of physical IP-based security products. The word ONVIFTM is often used to refer to the standards established by the organization. Compared with other similar standardization processes, ONVIF is phenomenally successful. It gained the support of the vast majority of IP security devices in a short period of a few years after its inception in November 2008. As of April 2012, there were over 1700 ONVIF conformant devices. By early 2018, and there were well over 10,000 ONVIF devices.
The following is quoted from Wikipedia :
  • Interoperability – products from various manufacturers can be used in the same systems and “speak the same language”.
  • Flexibility – end-users and integrators are not locked within proprietary solutions based on technology choices of individual manufacturers.
  • Future-proof – standards ensure that there are interoperable products on the market, no matter what happens to individual companies.
  • Quality – when a product conforms to a standard, the market knows what to expect from that product.

In theory, our apps work with almost every network camera on the current market one way or another. However, we highly recommend ONVIF conformant cameras to protect your investment regardless of whether you use our apps. There are over 10,000 ONVIF conformant IP camera models. The challenge is determining the true ONVIF conformance of an camera as explained by the following Q/A.

It is impossible for anyone to recommend one specific model of camera even if a brand is specified. For example, Axis Communications has dozens of different models that suit different use cases. Like many other devices, the best network cameras do not have the best prices, and the network cameras with the best prices may have quality and standard conformance issues.

Here is a list of network cameras reported by a small portion (< 5%) of our app users.

ONVIF conformance is self-certification. This helps bring out a large number of ONVIF products to the market quickly with minimum burden on the manufacturers, but unfortunately also leads to poor ONVIF conformance by some manufacturers, especially some from a certain region. Many "ONVIF conformant" network cameras are not strictly ONVIF conformant. In other words, they do not support some features mandated by ONVIF. The only way to find out whether a network camera is ONVIF conformant is testing it. We highly recommend the popular free desktop tool ONVIF Device Manager . If ONVIF Device Manager can stream and retrieve medial profiles of both H.264 and JPEG video encoding from the camera, the apps should work with the camera without any problem. Unless a camera is from a well-known network camera brand such as our partners, we strongly suggest asking the vendor to provide an on-line demo for testing before purchase, or provide references from their customers showing their ONVIF products work with ONVIF client applications. The most common serious defects of claimed “ONVIF” conformant cameras are:
  1. Not supporting RTSP over HTTP. Even though our apps support RTSP over TCP and UDP now, but we strongly recommend using RTSP over HTTP for ease of traversing firewall for WAN access.
  2. Not supporting JPEG encoding. Some mobile devices usually cannot handle multiple H.264 streams, so multi-view requires JPEG encoded streams for them.
  3. Not supporting snapshot. Though snapshot is not mandated by ONVIF, it is highly desirable.
  4. Not supporting ONVIF PTZ service even though the camera is an opto-mechanical PTZ camera. Our apps rely on ONVIF PTZ service for PTZ functions.
There could be a number of reasons. When this happens, we highly recommend using a desktop client application such as ONVIF Device Manager , a great free tool, to check if the device can be discovered by a desktop client on the same network. If a desktop client also fails to discover the device, we suggest contact the technical support of the device's manufacturer to find out whether the device is discoverable. If a desktop client can discover it, please inform us via the Support page.

Some devices such as Axis cameras may need configuration change to enable ONVIF. When enabling an Axis camera for ONVIF support , it may be better to uncheck “Enable replay attack protection” which requires clock synchronization between the mobile device and the camera.

Unfortunately, some cameras have security holes. We have observed the following types:
  • Web UI and ONVIF service use different authentication systems, and the ONVIF services do not require authentication even though the web UI does.
  • Streaming not requiring authentication or providing a streaming URL including credential information.
ONVIF requires digest access authentication that is much more secure than the basic access authentication used by most cameras' web UI. Unfortunately, some manufacturers do not implement it. We suggest users contact the manufacturers of their cameras with this issue to urge them to fix it by updating the firmware. We will do our part whenever we have a chance.
When a mobile device is connected to a cellular network, it is on a wide area network (WAN), more specifically, a wireless wide area network. First, the ONVIF discovery uses Simple Service Discovery Protocol (SSDP) that is not applicable to WAN. Second, it would be impractical to send out probes to millions of devices on a WAN to discover potentially tens of thousands, or hundreds of thousands of ONVIF conformant devices. Discovery is available only for LAN connection. For current mobile devices, a LAN connection effectively means a WiFi connection most of the time.
There are many possible causes. The following are a few of them that we have observed:
  • The camera does not have the required media profile. Our apps use H.264 media profile by default for most scenarios. You could try to switch to JPEG mode in this case.
  • The camera does not support RTSP over HTTP (i.e. Tunneling RTSP and RTP through HTTP). IP CENTCOM apps use RTSP over HTTP on purpose to help users simplify port configuration and firewall traverse.
  • HTTP port misconfiguration. IP CENTCOM apps obtain video streaming URI's from ONVIF devices, and respect the port numbers if they are specified in the obtained URI's. For the external access to an ONVIF device, one usually needs only to forward the default HTTP port (80) to the device.
  • An erroneous streaming URI obtained from the ONVIF device. For example, a requested URI for H.264 video stream is actually for JPEG video streaming, or URI for RTSP over HTTP is actually for RTP over TCP
The reasons are:
  • They are created to best suit the resolution of Windows Phone to avoid wasting bandwidth of data connection. In other words, try to avoid using a lot of bandwidth to display high resolution videos on a lower resolution Windows Phone.
  • Some Windows Phone devices cannot handle HD H.264 video. This varies from device to device (see Supported media codecs for Windows Phone 8 ).
  • The apps allow editing profiles. If they share a profile with other apps, editing the profile will affect other apps, so they create profiles for their own use.
Please note:
  • Though the apps try to create a profile with resolutions closest to that of the running device, but it only use available resolutions. Some cameras have only 2 or 3 resolutions available. Some ONVIF devices do not allow media profile creation, and some limit the number of media profiles that can be created by the user.
  • Users do not have to use the media profiles created by the apps. They can choose whichever profile they like from the list of profiles for H.264 or JPEG video.
There are three effectively:
  • RTP unicast over UDP. This requires multiple UDP ports to be opened. Many routers do not allow this for security reasons. This also makes configuring port forwarding for a device behind a router/firewall complicated.
  • RTP over RTSP over TCP.(Standard RFC 2326 Section 10.12). This uses a single port. It is usually the RTSP default port: 554. Many routers, especially enterprise routers are configured to block the RTSP port.
  • RTP over RTSP over HTTP over TCP. This also uses a single port that is usually the default HTTP port: 80. The HTTP port is rarely blocked.
Though IP CENTCOM supports all of the above, we strongly recommend RTP over RTSP over HTTP over TCP (a.k.a RTSP over HTTP, or Tunneling RTSP and RTP through HTTP), the most robust streaming method.
RTSP over HTTP (a.k.a. RTSP and RTP over HTTP, or in ONVIF's term: RTP over RTSP over HTTP over TCP) has the following advantages compared with other video streaming protocols:
  • It is almost guaranteed NAT (network address translation) traversal. In other words, the video streaming can traverse both the transmitter's router and the receiver's router because it uses only the HTTP port that is rarely blocked. Other methods of video streaming, especially, RTSP over UDP are prone to router blocking.
  • Underneath HTTP is the lossless protocol TCP, so it is reliable.
  • It simplifies router port forwarding configuration. For using RTSP over HTTP, the user only needs to forward a router's HTTP port to that of an ONVIF NVT (e.g. a network camera or video server)
Though the benefits come with some cost - extra overhead compared with UDP, our tests have shown the effect is negligible under most circumstances.
It has been noticed that some devices return an incorrect IP address in response to the discovery probe, so please check the discovered address carefully, and make corrections if necessary. Discovery essentially helps fill out a part of the device addition form automatically.
H.264 has a large number of forms. Firstly, there are at least 9 different profiles. Secondly, there are at least 17 possible levels for each profile. Usually the profile is not an issue because most IP devices use the Base Profile(BP), and both Android and Windows Phone support BP. The required level is often the cause for mobile devices not able to display H.264 video. HD (e.g. 720p, 1080p) H.264 video usually cannot be played by mobile phones though many tablet PC's can play them.

For Windows Phone, . Please refer to the Video Support section of Supported media codecs for Windows Phone . For Android devices, please refer to the Core Media Formata section of Supported Media Formats

For H.264 video, the video stream consists of I-frames and P-frames. An I-frame of H.264 is also called IDR (instantaneous decoding refresh) frame, and a P-frame of H.264 is also called non-IDR frame. Suppose an H.264 has a GOV length of 15, its normal sequence is the following:

I P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 I P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 I P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 …

If the bandwidth does not allow sending all the frames, an NVT (i.e. a camera) needs to skip frames. In this case, it should follow the following rule:

Never include a P frame that does not have its previous frame. In other words, if frame Pi is skipped, all of its following P frames (i.e. Pi+1, Pi+2, Pi+3 …) should be skipped until the next I frame. The sequence should be like the following:
I P1 P2 P3 P4 P5 P6 I P1 P2 P3 I P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 IP1 P2 P3 P4 …

If the simple rule is followed, we will see perfect pictures even though the video may be a bit jumpy due to skipped frames, but usually it is in well acceptable range.

If the rule is not followed, the video will show abnormal images. If P frames arrive without any an I frame before them, the image will show only changing parts until the next I frame, and the image may be grayish. If a P frame is dropped without dropping its following P frames, the video image will be distorted until the next I frame.

Our Android app Onvifer started to support H.265 from V9.69 released on 2016-12-09.

We are still trying to implement the support for H.265 by working with Microsoft.

Windows Phone does not support H.265

ONVIF starts to support H.265 from Profile T. However, Profile T is yet to be released officially. It is expected to be released in the 3rd quarter of 2018. Therefore, H.265 is available officially only through generic RTSP configurations in our apps. You cannot find a media profile with H.265 video encoding. However, we have noticed that camera models disguise H.265 as H.264 for some ONVIF media profiles, so one can get H.265 video by selecting an H.264 media profile in this case.

This is usually caused by the high resolution of a video stream and the limitation of mobile devices. Some IP devices do not offer any lower resolution (e.g. VGA 640x480) media profiles. Many mobile phones cannot display HD JPEG images.
Since many mobile devices can play only one or a limited number of RTSP video streams, some H.264 videos may not play in multi-view. Our apps use JPEG encoded RTSP for multi-view for ONVIF devices. One can determine whether a camera supports JPEG encoded RTSP by switching to JPEG RTSP in single-view. Some cameras support the good old generic MJPEG though they do not support JPEG encoded RTSP. In this case, one can add the camera using its generic MJPEG URL in addition to the one set up in ONVIF mode, then use this in multi-view.
IP CENTCOM apps always try to use JPEG encoded video streams for the multi-view. In theory, an unlimited number of concurrent JPEG encoded videos can be supported.
However, many RTSP streams carry H.264 encoded video, and some ONVIF Devices, especially many made in Shenzhen, China, do not support the ONVIF mandated JPEG encoded video. The maximum number of concurrent H.264 video streams depends on the OS and hardware because all IP CENTCOM apps rely on hardware codecs to achieve the best performance.
  • Windows 8.1/10 appear to be able to support an unlimited number of H.264 video streams. At least, we have not seen any limit in our tests.
  • Windows Phone 8.1 can support only one H.264 video stream.
  • It appears that the maximum number of concurrent H.264 videos on an Android device is determined by the number of CPU cores. For example, a dual-core CPU can support 2 concurrent H.264 video streams, and a quad-core CPU can support 4 concurrent H.264 video streams. However, this is not guaranteed. In some cases, the number of allowed concurrent H.264 videos is smaller than the number of CPU cores.
Please refer to the answer of Why do the apps only use hardware codec for H.264 videos?

First, congratulate on making the camera work on your LAN.

You are taking the best approach to configure the access to your camera via WAN - ensuring it works on your LAN first.

When this happens, it is almost certain that the issue is related to port forwarding configuration. Please take a look at the answer to question: How to configure an NVT and a router to allow remote access via WAN?

The specific steps to realize this are highly NVT and router dependent.

We strongly recommend RTSP over HTTP as the video stream transport protocol. Mobile apps of IP CENTCOM use RTSP over HTTP by default. RTSP over HTTP makes port configuration the simplest and most robust - usually only one port needs to be configured. RTSP over HTTP is mandated by ONVIF, and all major network camera manufacturers support it.

Unfortunately, some NVTs do not support RTSP over HTTP. They usually support RTSP over TCP and/or RTP over UDP which is a lossy protocol and should be used as the last resort. In this case, one may need to forward multiple ports: HTTP port, ONVIF port if ONVIF uses a separate HTTP port, TCP port (sometimes called RTSP port) for streaming, and maybe more.

In the ONVIF mode, the apps use the port provided by a camera in the retrieved streaming URL, so it is important to make sure NVT's ports are forwarded to from the same ports of the gateway (i.e. the external port number must match the internal port number, e.g. 80 to 80, 8080 to 8080, 554 to 554). If no port is specified in the retrieved streaming URI, the apps use port 80 by default for RTSP over HTTP, and port 554 for RTSP over TCP and RTP over UDP.

Some organizations' networks only allow traffic through certain ports. They usually block ports such as the default UDP port 554. HTTP traffic and its default port 80 are always allowed. This is why RTSP over HTTP is the most robust way for remote video streaming.

Please refer to this Google+ post with large diagrams to help you configure port forwarding.

First, let us distinguish video encoding from video transporting. There are two primary encoding methods: JPEG and H.264. MPEG encoding is getting obsolete. Both JPEG and H.264 are supported.

As for video transporting, RTSP is used, but ONVIF specifies four specific methods to use RTSP:

  1. RTP data transfer via UDP. UDP(User Datagram Protocol) is used to transfer video data. This has the least overhead, but its traffic and its default port 554 are often blocked by many organizations. If a user uses a LAN (e.g. an institution's WiFi) which is beyond his control, he may not be able to use this mode to monitor an NVT remotely. Even a major IP camera manufacturer does not allow UDP on their corporate network.
  2. RTP/TCP. This has been deprecated.

Many wish to see the zoom scale of an IP device with the zoom capability, but the apps only allow zooming without showing the current zoom status. This is due to the following reasons: 1. ONVIFTM does not mandate a function providing specific zoom scale (i.e. magnification such as 1X, 2.3X), so the absolute zoom scale information cannot be retrieved from many devices. 2. Though ONVIFTM mandates normalized zoom scale via its generic zoom position space (http://www.onvif.org/ver10/tptz/ZoomSpaces/PositionGenericSpace), we have noticed that currently some devices do not provide the zoom status information though they allow zoom control. To accommodate all devices, we have decided not to show the zoom scale.
This depends on the following factors:
  1. Available memory of the device.
  2. Resolution of the video. The higher the resolution, the shorter the allowed recording.
  3. Frame rate. The higher the frame rate, the shorter the allowed recording.
  4. Change rate of the scene. H.264 is an extremely efficient compression for scenes with few changing parts. A rapidly changing scene diminishes the compression. The more moving objects or luminance fluctuation, the shorter the allowed recording.
The most common reason is the provided online camera does not work with the apps due to incorrect reason, credential (user name/password), or insufficient privilege of the provided credential. Please verify the camera with IP CENTCOM or Onvifer before contributing it to the demo list.
This can happen with Onvifer that uses JPEG encoded video for streaming by default and uses H.264 encoded stream for recording. Some H.264 profiles are too high for mobile devices to handle. For example, some Honeywell and Vitek cameras use H.264 High Profile that many mobile devices cannot handle. However, the recorded MP4 video files can be transferred to a desktop computer, or video sites such as YouTube to play.
They do not except JPEG encoded video in our Android app Onvifer.
There are two ways to rotate videos:
  1. Rotation at the video source (e.g. an IP camera video encoder) before it is sent out. This is by far the most efficient way to do it, and it has almost zero impact on the video streaming performance. ONVIF allows configuring a video source's rotation, but we have not implemented it primarily because we have found few ONVIF devices support this optional ONVIF feature. Fortunately, many network cameras allow such rotation via their web UI. Since a user usually needs to do this only once after a network camera is installed at a location, doing it via the camera's web UI is the best choice.
  2. Rotation by client apps such as ours after they receive them. There are many downsides and challenges for this approach. First, it can significantly reduce video performance on some mobile devices with limited computer power. It requires PTZ and stretch actions to change accordingly complicating the implementation further. For H.264 video, this is practically impossible in some cases because all of our apps try to maximize performance by utilizing hardware codec to render video. We will continue evaluating the value and cost of implementing the support for rotation.
There are two possible reasons:
  1. Different cameras have different sets of features.
  2. Many parts of ONVIF are optional. Manufacturers of ONVIF devices choose these optional features to implement quite differently.
Apple is the inventor of RTSP over HTTP (i.e. tunneling RTSP and RTP over HTTP). IP CENTCOM's apps primarily use RTSP over HTTP for good reasons. There may be times when the streaming does not work, and it may be a good idea to validate the streaming URI with Apple's QuickTime Player. To configure QuickTime Player to use RTSP over HTTP
  1. Open QuickTime Player
  2. Edit > Preferences > QuickTime Preferences...
  3. Advanced > Transport Setup: Custom...
  4. Select HTTP for Transport.
In addition to Apple's QuickTime Player, VLC Player can also be configured to use RTSP over HTTP that is the primary streaming method of IP CENTCOM's apps. To configure VLC Player to use RTSP over HTTP (i.e. HTTP tunneling of RTSP) (as of 2014-04-18):
  1. Open VLC Player
  2. Tools > Preferences.
  3. Select "All" at the left bottom corner
  4. Input/Codecs > Demuxers > RTP/RTSP
  5. Check "Tunnel RTSP and RTP over HTTP"
  6. Select the correct port for "HTTP tunnel port". This is important because VLC Player does not recognize the port specified in the streaming URL. In other words, you need to come here to change the port number whenever a streaming device uses a different port than the specified. This is a significant disadvantage of using VLC Player to play RTSP over HTTP.
Possible reasons:
  • The ONVIF device does not support the snapshot function. The snapshot function is not mandated by ONVIF.
  • Some models manufactured in a certain region give wrong port information for the snapshot URL. The apps rely on the snapshot URL retrieved via an ONVIF request. Some models do not have the correct port in the snapshot URL. For example, they may be configured to use port 81 for HTTP used by their web UI, port 1018 for ONVIF. The snapshot uses port 81 accordingly, but the device reports the snapshot URL without specifying port 81, so the apps would use the default port for HTTP: 80. The apps have no way to know the device is using port 81. Changing their HTTP port to the default HTTP port 80 is helpful for these cameras that do not comply with standards strictly.
IP CENTCOM apps' RTSP decoders rely on hardware codecs for the final rendering of videos for the following reasons:
  • Performance. The hardware codec based video rendering is drastically more efficient than software codec based video rendering. It is faster and uses less resource. This is one of the reasons that IP CENTCOM apps can have smooth HD videos at high frame rates on low end devices.
  • License issue. Using the popular open source codec as many other apps do would legally require the apps to use the same open source model. Additionally, the H.264 patent holder (i.e. MPEG LA) demands royalty from H.264 codec implementers.
This is usually caused by a malformed media profile. The most common cause is missing required elements. IP CENTCOM apps may be able to accommodate this. Please use the nice free tool ONVIF Device Manager (ODM) to confirm the ONVIF device works with ODM, then contact us with the information. We will try our best to accommodate this.
We need to talk about Onvifer's history to explain this unintended behavior.
Onvifer initially allowed PTZ gesture to be effective under all circumstances regardless of whether the control overlay is displayed. We received many requests for full-screen display - no status bar, not action bar - soon after Onvifer was released. As always, we took this user feedback seriously and implemented the full-screen display. Apparently many users love this based on the feedback. However, there is an unfortunate consequence of the full-screen - the gesture listener of the app will not be notified until after the control overlay is displayed by the first touch. This is due to an limitation or glitch of the Android OS. Many Android app developers face the same issue. We hope this will be fixed in a future version of Android or a remedy for this will be found. We will keep watching the development of this Android issue.
The apps support receiving audio from all NVTs using the audio stream in RTSP, and support outgoing audio if the its URL is known.
We support international standards (ONVIF, RTSP, etc.), and do not support proprietary protocols currently. The ONVIF way of audio output is via RTSP back channel. Unfortunately, we are yet to find a model supporting it. IP Cameras usually use proprietary protocols for output audio.
At this point of time, we have added an outgoing audio URL field to the configuration screen for users to enter it manually. Our apps fill the field automatically for some popular brands such as Axis.

Good news: ONVIF is expected to release officially Profile T for Advanced Video Streaming in late 2018. Profile T requires two-way audio support. We expect many manufacturers will support Profile T after its official release. We will support Profile T, hence two-way audio for all Profile T devices. Manufacturers may release firmware updates to support Profile T for older, but not tool old, cameras.

The perceived PTZ latency consists of two parts:
  1. True PTZ operation latency from PTZ command sending and NVT response. This is usually small. Our apps send PTZ commands as soon as the PTZ gesture or button tapping is finished. It usually takes a small fraction of a second to finish sending the command depending on the network connection quality. Most NVTs respond immediately with little latency.
  2. Video stream latency. This means the actual PTZ operation happens sometime before it is shown on the video. This is usually the most significant part. For some NVTs, it can be many seconds for H.264 RTSP streams. You can gauge this latency by watching a camera's movement to see the time lapse between the camera starting to move and the video starting to show the movement.
    We need to talk about the nature of H.264 RTSP video a little bit to explain this.
    Both RTSP and H.264 inherently contribute to the video latency. The latency is usually noticeably bigger than that of MJPEG (not JPEG encoded RTSP). We have put in a tremendous amount of effort to enhance the performance of our own RTSP decoder, hence reducing the latency as much as we can. Onvifer's H.264 RTSP performance is superior to any similar Network Video Client (NVC) apps that we have tested. Onvifer on a low end Android device has better video than some popular apps running on powerful desktop machines.
    However, there is a limit that an NVC app can do to enhance the video performance. Some latency is inherent to a Network Video Transmitter (NVT, e.g. IP camera). We often see the latency ranges from 0.5 to 3 seconds. In other words, even if PTZ commands are sent and executed immediately, it may still take 0.5 to 3 seconds to see the change normally.
With the latency in mind, we can easily explain why Onvifer does not allow continuous PTZ operation. Let's use a specific example. Suppose a video has a latency of 1 second (better than the average), and it takes 3 seconds to zoom from 1x to 30x. Suppose Onvifer allowed continuous zoom while "+" is pressed, and the user wanted to zoom from 1x to 20x. Let's assume the camera and network connection were so good that the zoom command had zero latency. The user pressed the button, it took 2 seconds to zoom to 20x, but the user would not see the 20x video until 3 seconds due to the video latency. He released the button when he saw it at 3 seconds, however the zoom would be already at 30x due to the video latency at that point of time.
One may argue that he could get used to the latency and release the button before he sees the targeted PTZ level. Unfortunately, the latency varies from camera to camera. Even worse, for the same camera it may vary under different conditions - network connection speed, image changing rate, etc.
With current technologies, it is impossible to have continuous PTZ operations with remote viewing as responsive as that of digital camera we operate by pressing physical buttons.
First, please see the above Q/A regarding why Onvifer does not allow continuous PTZ operation.
Pressing a PTZ button causes a discrete PTZ scale change. Onvifer follows the conventions of software button operations - starting the action after a button is released. This may be different from that of mechanical buttons on digital cameras. If you look at other apps, you will notice the same behavior. A user can actually cancel the action after pressing a button by moving the touch or cursor off the button before releasing it. One can use the zoom buttons of Google Map to test this behavior.
It varies. Users do not want to see the control overlay at all when they are not needed. Onvifer tries very hard to figure out when the control overlay is needed and when not. It is an evolving process. Usually it displays the overlay for 3 seconds after a touch. It will hide it immediately upon certain events (e.g. gesture), and it will lengthen the display time upon some events (e.g. overflow menu showing). We are keen to hear feedback from users to continue improving the control overlay display.
Our apps can automatically discover all ONVIF conformant devices that support discovery. All ONVIF conformant devices that we have tested support discovery. If your ONVIF device cannot be discovered, please use the nice free tool ONVIF Device Manager (ODM) to verify its ONVIF conformance.
If you believe a device is ONVIF conformant, and have entered the IP address manually, please make sure the IP address is correct, the device is on line and the port you have specified is for ONVIF services. All major brands use one HTTP port (default: 80) for everything - ONVIF services, RTSP streaming and snapshot. Some brands, especially many from certain region use multiple ports (up to three).
Usually this is caused by authentication failures. Please ensure the credential (user name/password) is correct and it has the privilege to access ONVIF services.
Some ONVIF devices (e.g. Axis models) use a set of users for ONVIF services different from that for their web UI access. In other words, ONVIF services require their own user management.
We have also heard from some users that some models made in a certain place require blank user name and password (i.e. DO NOT enter user name or password)
There are usually two ways:
  1. If a DVR/NVR is ONVIF conformant, it can be treated as one ONVIF device. It may have different media profiles corresponding to different connected network cameras, so the user can access all the cameras by using their corresponding media profiles.
  2. If a DVR/NVR is not ONVIF conformant, it usually provides an RTSP URL for each connected network camera. The user can add each camera as a generic RTSP stream. The DVR/NVR's user's manual or the manufacturer's tech support is the best source to find the URL format.
The quick answer is: most IP cameras, if not all, have built-in motion detection and other alarm features. The functions are done much more reliably and efficiently by cameras that have the raw data than client apps such as ours.
We fully understand that many users would like to have these features that are given nowadays for any video surveillance system.
A video surveillance system usually consists of three parts: video transmitters (e.g. network cameras), a video management system (VMS) and video clients (e.g. apps viewing and controlling cameras). Some apps combine VMS and video client functions. At this point of time, we consider our apps primarily as video clients. Their primary function is viewing and controlling video transmitters.
In ONVIF terms, motion detection is a part of video analytics, and alarms are a part of eventing. ONVIF supports both video analytics and eventing.
The most efficient place to do video analytics is the video source (e.g. a network camera). Almost all network cameras have video analytics including motion detection. Unfortunately, at this point of time, most ONVIF network cameras support neither ONVIF video analytics nor eventing. In other words, these cameras have the features, but client apps such as ours are unable to utilize them through ONVIF services. Our apps are focused on the support for ONVIF services instead of proprietary APIs of different manufacturers.
One option could be reinventing the wheel by doing basic video analytics within our apps. Mobile devices (e.g. phones) run our apps only on demand. The apps understandably are not allowed to run in the background to consume resources including power constantly. Relying on our apps for video analytics and alarms is impractical under most circumstances.
With more and more network cameras supporting ONVIF video analytics and eventing services, our first priority will be supporting these features through ONVIF.
For now, we suggest users utilize network cameras' web UI to configure motion detection and alarms. They are usually simple to configure and very reliable based on our experience with many models.
We plan to support ONVIF Profile G in the near future. Profile G is about the edge storage (e.g. recording on camera SD cards). If a user configures an ONVIF device to store triggered recording on SD cards, profile G will allow the viewing and management of them.

Our apps control devices primarily via ONVIF services. Features such as IR control are not a part of ONVIF currently, so they are not supported by our apps. Most, if not all, cameras with IR turn on/off IR automatically based on the light level.

ONVIF has something called auxiliary PTZ commands that we are yet to implement because most, if not all, consumer grade cameras do not support this. For now, if you know the command URLs for turning on/off IR (something like: http://address:port/something.cgi?xxx=yyy), you can add them as custom commands.

This is true of other commands such as focus, PTZ commands for generic RTSP streams. Our apps support many commands such as PTZ, focus, presets automatically for ONVIF cameras via ONVIF services. However, this is not applicable for generic RTSP/MJPEG streams. For them, custom commands are the only way to achieve these functions.

We plan to support ONVIF Profile G that governs edge storage (e.g. recording on a built-in SD card). We have noticed that only some major brands (e.g. Axis, Panasonic, etc.) support Profile G. Generic brands usually do not support Profile G currently, so implementing Profile G is not high on our priority list right now.

One useful and simple function is downloading the recordings to a user’s device, then the user can use his preferred video player to browse and play the downloaded files. The default video player and the Gallery app are quite good. One can browse hours video quickly to find interesting things. Unfortunately, Profile G does not support this. It only allows exporting from SD card to a configured NAS drive, not to the device running the app. Only proprietary protocols such as Axis' VAPIX allows downloading video to the client machine. We may consider supporting some most commonly used models with their proprietary protocols.

Some ONVIF devices have predefined media profiles corresponding to all available resolutions, but some are not. If an ONVIF devices is strictly ONVIF conformant, other resolutions can be obtained with any of the following methods:
  1. Edit the video encoder of a media profile via our apps (Pro version) or the free tool ONVIF Device Manager.
  2. Add a media profile via the free tool ONVIF Device Manager. Our apps usually create new media profiles to suit the screen resolution of the device running the app best. Please see the question of FAQ "Who are new media profiles created during setup?".
  3. Some ONVIF devices allow editing/creating media profiles with their UI. Some devices only allow changing video resolutions for predefined profiles.
We fully understand the convenience of using P2P for IP camera connection. Our apps currently do not support P2P, and we will keep examining the suitability of supporting P2P. Our current thoughts regarding P2P are the following:
  1. There are many platforms of P2P, and none of them are widely accepted as the de facto international standard. We are committed to the support of the international standard ONVIF due to the tremendous benefits that ONVIF brings to users. We continue to avoid getting into proprietary protocols.
  2. A P2P service requires an IP camera maintaining a constant connection with its server. Though the bandwidth usage by this connection is fairly small, we think this is not highly desirable. A DDNS service is advantageous in terms of reliability. It requires a router to report its public IP only occasionally. DDNS is a very mature technology and many DDNS providers have excellent track records of reliability.
  3. DDNS is also more transparent to users than P2P because their users know exactly which DDNS provider they are using while few users of P2P know which company's P2P server maintains a constant connection with their cameras. We always feel manufacturers ought to disclose these P2P providers to address any security concerns of users because these providers at least have the capability to access all registered cameras.
The official policy for app or in-app purchases does not allow refunds. However, Microsoft is kind enough to consider refunds if there is a good reason. Each case needs to be handled individually by a Microsoft representative. It can be done as following:
  1. Log into your Microsoft account.
  2. Click “Contact Us” at the bottom.
  3. Click “Windows. Office, and…”.
  4. Click “Accounts & billing”
  5. Chat online with a Microsoft Answer Tech
  6. Ask the chat rep for a refund by providing a legitimate reason.
All demo cameras are from third parties. We do not have any control of them though we check their on-line status periodically. Only demo cameras that are on-line during our checking are provided for testing purposes. However, they may be off-line for a variety of reasons. There is a limit for the number of concurrent connections for each camera, so a connection may be rejected due to the limit being reached.
Android app licenses are managed by Google, and Windows store app licenses are managed by Microsoft, Amazon store app licenses are managed by Amazon.
Per Google's policy, there is no limit on the number of devices using a purchased license.
Per Microsoft policy, up to 10 devices can actively use a purchased license.
Not at the point of time. We will update this if it has changed.
Google introduced Family Library in July 2016, and we have debated on whether making Onvifer Pro available the Google Play Family Library several times. We understand the usefulness for some users. The following points make have made us hesitate to make the move:
  • Onvifer FREE has all the basic functions. As a matter of fact, most app users use the FREE version. The non-intrusive ad of the FREE version is minimal, and displayed only at the bottom of the home screen. It never shows during video streaming that is the most important and frequent task. A FREE version user does not see any ad usually more than 95% of the app usage time. If a family has a primary user needing all the extra features, and others do simple monitoring, one Pro license that can run on unlimited devices of the same user should suffice. BTW, the ad generates minuscule revenue for us. It is more of a FREE version indicator than anything else.
  • We need to maintain some level of fairness. The Android license policy controlled solely by Google is already quite generous - it allows a Pro license used on unlimited number of devices; whereas the Pro license of our Windows version is significantly more expensive, and yet limited to 10 devices v.s. unlimited for the Android version.
  • In the case of more than one family member finding the Pro version features necessary, we feel an additional license should not be a big burden because it is only a tiny fraction of hundreds of dollars that many users spend on multiple IP cameras. We are still trying (as of early 2018) to achieve financial self-sustainability for the store app development.
No, we currently do not have a version for iOS unfortunately due to the lack of the resource to develop the iOS version though it has been our plan, and we have tried earnestly to unify all versions targeting different platforms including iOS using Xamarin, but failed. We will support iOS as soon as we have the resource. We currently support Windows (8.1/10), Windows Phone and Android.
The Pro license is managed by Microsoft server of which we have no control. A glitch to cause this has happened many times for many apps and users. We have been urging Microsoft to fix this permanently. Some users have found the following remedy working for them:
  1. Click the button or menu item(e.g. "Upgrade") for upgrading. A pop-up message box shows up. This message box is still a part of the app, not Microsoft purchase process.
  2. Click "OK". This will go to Microsoft Windows Store purchase transaction page.
  3. Click "Cancel" if the Windows Store page shows up and with “buy” button instead of the “You already own this – Install” button. If you do not see the store page, but a pop-up box thanking you for the purchase, it means the license has been retrieved successfully.
  4. Open the app again.
  5. The app should retrieve the license correctly.
  6. Out of caution, please check your Windows Store account. If Microsoft charges you again(this is extremely unlikely), please ask for refund and let us know ASAP.
Please note that the app goes back to the free version only if the Microsoft license server tells it specifically that you do not have the license. We have worked with Microsoft a few times, it took a few weeks each time, but have given up because they insist providing a way to reproduce this. This happens randomly. We are unable to reproduce it reliably. If you happen to know a way to reproduce this, please let us know.
The Android app license is completely managed by Google. This is likely related to the known Google Play cache issue. Some users have found the following remedy working for them:
  1. Click the upgrade button in the app to try purchasing the license again.
  2. Follow the instructions to reach the Google Play in-app billing page, but DO NOT complete the transaction. This should force the Google Play service running in the background to refresh the cache.
  3. Restart the app, and you should be able to enjoy the Pro version again.
Please contact us if the above method does not work. Thank you very much for supporting the app.
We rely on Google Play, Microsoft Store and Amazon to handle Pro version licenses, therefore the Android version has a license handled by Google Play or Amazon, and the Windows Phone version has a license handled by Microsoft Store.
Windows version came much later, but before Windows 10 came out to unify the OS for Windows Phone and Windows. It is a separate app, so it requires another Pro license. We wish that we could merge the licenses for Windows Phone and Windows version, but the technical burden is very significant, so two separate Pro licenses for Windows Phone and Windows respectively will remain for the foreseeable future.
Windows 10 makes this task much trickier that it should be.
The key is creating a shortcut of the Windows Store app and add it to the following folder:
C:\Users\[your user name]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Finding the shortcut is the trickiest.
Here is one way to accomplish this:
  1. Open File Browser, go to folder "C:\Users\[your user name]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup"
  2. Go to Windows Start > tap All Apps (the bottom item) to list all apps in alphabetical order > Find the app.
  3. Drag the app to the file browser opened earlier. This is easy to do if you have more than one monitors or Windows Start is not full screen. If you have only one monitor and Windows Start is full screen, you will need to drag the app to the file browser on the taskbar.
Periodically some users kindly agree to run a test version of our app for diagnosis or beta testing. In this case, the app package needs to be sideloaded. The process is simple and straightforward:
  1. Download the package which may be in a zipped file.
  2. Follow Sideload your app package.

The UWP version was released on 2017-11-06 finally.

The following is the long version:

We have been looking forward to migrating IP CENTCVOM to UWP since the release of Windows 10. Since we are unable to afford maintaining two Windows versions of IP CENTCOM - Windows 8.1 and UWP for Windows 10 - due to very limited resource, we waited till the number of Windows 8.1 users of the app dwindled to less than 10% before starting the migration. Please note that the Windows 8.1 version will always be available for downloading, but it will not be updated after the migration.

We were on track to release the UWP version by the end of January 2017 as promised to some users. We prepared the beta version to be published to Microsoft Store in late January and were ready to invite some Pro version users to try it. Completely to our surprise, the beta version generated a slew of errors related to ONVIF services while the debug version worked flawlessly. A frantic investigation ensued, and we resorted to a support ticket to Microsoft quickly.

Fortunately, Microsoft kindly responded quickly and assigned a very responsible and talented Engineer (David) to this issue on January 31, 2017. David found the culprit within 24 hours - the tool of Visual Studio for creating the release version of a UWP app not supporting a large number of APIs some of which are required for ONVIF services.

For those with inquisitive minds, here is a simple explanation of different app versions. Before UWP for Windows 10, Windows Store apps like IP CENTCOM use Just-in-time (JIT) compilation meaning they are compiled into machine code after user start running them. This is why they may be noticeably slow for the first run, and much faster for subsequent runs. JIT compilation needs to be done only once after an installation or update. To enhance apps' performance, Microsoft started using the .Net Native model. .Net Native compiles apps into machine code before users download them hence dramatically improving the app start performance. For unknown reasons, Microsoft chose to deprecate many APIs for .Net Native compilation while supporting them for app development. Since .Net Native compilation is very time consuming, it is impractical for developers to use it during app development when apps need to be restarted frequently. This is why the debug version of IP CENTCOM's UWP version works flawlessly while its release version generates many errors. Making the problem even worse, the errors cannot be detected by the .Net Native compilation, they will occur only when the app's relevant functions are performed. In other words, they are run-time errors.

David tried his best to come up with workarounds and involved other staff of Microsoft to lend their hands, but unfortunately, no viable method was found after a month-long diligent endeavor. We tried our best to find a remedy too. The burden is simply too high to overcome. Very fortunately, David managed to persuade the .Net Native tool team to fix this problem, and told us .Net Standard 2.0 to be released in Q3 2017 would include the fix. The Microsoft support ticket was closed on March 14, 2017, but we kept tracking the issue and crossing our fingers.

Microsoft finally released the new tool chain in July 2017, but only available with Visual Studio 2017 Preview version. Migrating the app project to the new Visual Studio took a few days with the extensive help from Shin, a Microsoft engineer on the tool chain team.

We were ready to publish the app to Microsoft Store for β testing in early August 2017. Unfortunately, the store did not support the new tool chain at that point of time, so we had to wait for the store to support the latest Microsoft technology.

Microsoft Store finally started to support the new tool chain in late August, but unfortunately, x-64 package of the app produced by Visual Studio kept failing though x-86 and ARM packages had no problems. With the help of Shin, we finally found the culprit - a residue from project migration causing wrong dependency - in the middle of September.

We largely completed the migration in the middle of October.


The UWP version relies on Microsoft Windows SDK. The SDK governs how ONVIF SOAP messages are sent out. The SDK prefixes each SOAP message with an HTTP/1.1 HEAD method request. The HEAD method request is legitimate though effectively useless for ONVIF services. Most network cameras can handle it without any problems, but some cameras (e.g. at least some Hikvision models) are unable to handle it.

We contacted Microsoft on 2017-12-07, and their engineers immediately agreed to remove the HEAD method request. Since this issue involves multiple teams, we were not sure when this would be fixed.

We also sough Hikvision to fix their firmware to make it accept the legitimate HTTP HEAD method requests.

One could add a Hikvisoin camera as a generic RTSP stream.

As the last resort, we could send you the old Windows 8.1 version that which can run on Windows 10.

This problem was finally solved on January 24, 2018 when a Microsoft engineer came up with a brilliant workaround.

In order to use your Tablet of Smart phone as a door-chime surveillance cam with auto-switch-on and auto-switch-off function, you need to make some changes.

You will need Onvifer (V10.69 or above ). In Onvifer, you need to uncheck “always on” so that the internal device timer for “screen-timeout” / sleep-mode-timer will be “active”.

You can also set Onvifer as a default startup-app that starts with your device automatically. Your “Door-Cam” can also be selected as default-startup-cam when Onvifer starts.

After these settings, your device is going into “sleep-mode” or “standby-mode” after the time you set in setup if you don’t “touch” the device for other use. I suggest 5 minutes.

At the device, the function similar to “wake-up after plugging-in power” or wake-up after putting into docking-station must be enabled.

Now the only problem left is how to connect the device with your doorbell.

I used a simple “trick” and installed a small relay parallel to the door-chime. This relay interrupts the device-charger ( in my case the USB power) for a short moment ( I installed the relay into the cable, between charger and my device).

You have to use this relay in “normal closed –mode”. Your device will be charged normally and only be interrupted for one second or so when someone is pressing the doorbell.

This will wake up your device and you will see the camera-stream of the cam ( in my case the door-entry cam). After 5 Minutes, the device goes into “sleep-mode” again if you have unchecked the “always on” in Onvifer.

In a nutshell, a deep link is used to show specific content of an app. For example, the Pro version of Onvifer has a deep link for the video streaming screen of each camera, so it can be used to start video streaming of the specific camera.

How to use deep links is the confusing to many users. Deep links usually are not meant to be used directly by end users. They are embedded in apps or web pages for clicking. They may look like regular web URLs, but they cannot be opened by a web browsers to our best knowledge as of this writing (2018-04-05)

Some apps, such as those for home automation, allow end users to enter deep links to open other apps. For example, an alarm/door bell app may allow a user to enter a deep link so that it can open another app automatically upon the going off the alarm

Tech savvy users familiar with Android Debug Bridge (adb) can use the following format to test a Onvifer deep link for a video:

adb shell am start -W -a android.intent.action.VIEW -d onvifer_deep_link

The following is a specific example:

adb shell am start -W -a android.intent.action.VIEW -d https://ipcent.com/onvifer/streaming/cd512fa7-d686-47f4-8e8a-158532b44fa8

Win IP Camera

Wouldn't it be nice to have Win IP Camera send out video wherever we go as long as the phone has a cellular connection. Unfortunately, as far as we know, wireless carriers do not allow this even though it is possible technically. A mobile phone connects to the Internet through one or more firewalls/NAT devices controlled by carriers. The carriers configure them to block incoming connections to phones.

This is not just the case for Windows Phone devices. It is true for all mobiles phone (Android, iPhone, etc.).

This is a common symptom of camera driver crash. Rebooting a device almost always fixes it.
More than half of the time spent on Win IP Camera development is for dealing with video drivers that require extremely tender care. The vast majority of issues after the initial release of Win IP Camera are related to camera drivers one way or another. We have tried everything we can think of to avoid disturbing camera driver.
Built-in cameras of Windows Phone devices are under better control than attached web cams. Users may see more issues with the Windows version of Win IP Camera streaming from attached web cams. There are a lot of cheap poor quality webcams on the market. It is challenging to accommodate all of them. Even the camera drivers of major brands have issues.
Win IP camera taps into true video streams, not low lag still photos or preview videos, from cameras. If a phone and the network speed are sufficient, the app can stream at 30 fps. However, for practical purpose, Win IP Camera uses an algorithm to select the optimal sampling frame rate determined by device type and video resolution ensure the best reliability and performance. For example, the sampling rate for HD video will be 8 FPS for low memory (512MB) devices, and 16 FPS for all other devices.
Win IP camera taps into true video streams, not low lag still photos or preview videos, from cameras. The app presents the image from the video stream after transcoding, but without any modification. Therefore, if there are some blank areas, they will show up because Win IP Camera has no way to know unless it analyzes each image frame. The rotation may be an exception because the blank areas are predictable.
We are fully aware of the power consumption problem, and have done everything we can to reduce the power consumption. Sending HD MJPEG streams over WiFi may be the major power hog. If we implement the support for H.264 RTSP stream, this may be alleviated due to the much smaller required data rate.
Motion detection is beyond the capability of many low end Windows Phone devices at any decent frame rate with HD video. Low end devices probably account for more than half of the market. We may consider this for the Windows version. Video recording is only practically viable after implementing the support of H.264 video.
Though it would be very easy to add the recording function in terms of coding, we are afraid that many phones would not be able to handle this.
We estimate that more than 70% of our development time for this app is spent on coping with camera drivers' vulnerability, especially for low end phones with 512MB memory. We have tried everything that we can imagine to reduce the workload to make the app have acceptable reliability.
We may try adding the recording option in the future with adequate warning of its potential detrimental effect. We will certain consider adding this function to the Windows version.

Web-based monitoring service

A user gets the ability to monitor all his cameras securely by simply using an Internet browser without installing any ActiveX controls or other add-ons that usually come with every camera.

Here is what one usually has to do when connecting to a camera directly:

  1. One needs to remember the IP address of each camera to connect it (e.g. http://MyIPCameraAddres:port/).
  2. One needs to remember the user name and password of each camera, and provide them when prompted.
  3. If it is the first time to use a particular computer to monitor the camera, one needs to go through multiple steps to install ActiveX controls or other add-ons depending on the browser.
  4. Repeat the above steps for each camera.

Anyone familiar with different IP cameras can tell how diverse the add-ons are. The installations range from being straightforward to nearly impossible. The worst under this scenario is that installation of these add-ons is usually not allowed by policy or computer configuration at workplace or public facilities.

IPCENT.COM eliminates all the above difficulties or nuances once the cameras are registered.

  • IPCENT.COM uses Hypertext Transfer Protocol Secure (HTTPS) as used by many banks. The communication between your browser and IPCENT.COM is encrypted.
  • Each camera's IP address, user name and password are all encryptped before they are stored in our database. In other words, even people with access to the database are unable to extract the information encrypted with the state-of-the-art algorithm.
  • Users' camera video streams are routed from the cameras directly to the monitoring browser. They do not pass through our server. We do not have access the streams.
  • As stated in our privacy policy, we never disseminate user information to any third-party

Yes or No. Yes, if you just want to monitor your cameras. No, if you want to configure your cameras or do sophisticated recordings.

No. The built-in applications are needed for camera configuration tasks such as wireless network settings, user management. They are usually one-time tasks. With IPCENT.COM, you do not need the built-in applications for daily monitoring.

Yes, if you want to monitor a camera outside the local network where the camera resides. No, if you only need to monitor the camera within your local network.

Yes, this is because IPCENT.COM delivers the monitoring software and log-in information to your browser, but video streams travel from IP cameras to your browser directly without getting out of the local network.

Maintaining the service and implementing support for various camera models can be costly. We plan to generate revenue to sustain and grow the service by the following avenues:

  • Ads that are very carefully selected and placed to avoid any interference with user's monitoring. We will never insert any video ads into user's video streams.
  • Premium service for some sophisticated users who would like to have more functions such as recording and broadcasting. We expect the majority of users will be content with the free service.

Our story is a typical one - we started this service because we needed such service. We are IP camera users. We have used many IP cameras from various manufacturers over the years. Our typical use is quick checking of what is going on at our homes or business locations. We have our share of frustration in installing or being unable to install web browser add-ons required by cameras. We felt there has to be a better way to monitor our cameras, and developed a Silverlight app for our own use. Then we decided to share this with the IP camera user community, and the IPCENT.COM was born.

Chat (beta)