@brian-nielsen_442682315796643 We have requested the support team to inform dev team that a lot of customers are asking for the doorbell to do an outbound voip call to the smartphone with possible actions as is being done by other brands. Other than this we need the full profile T support with full duplex audio.

Customers want clearer pictures and able to read text or numbers within reasonable range. They are also requesting higher fps especially at night time. And yes customers are looking also for HDR implementation. All this comes at a higher processing power and very powerful sensor. Can someone from Reolink development team update us on when these shall be made available to its customer?

@melroy UID is like your ID number which is a unique identifier pointing to a number of profiles in various institutions. If you go to the hospital they will ask you for the ID and by entering this ID they will get all your health information.

When you power up your camera, it does some DNS queries to get the IP addresses (A record) of the P2P servers (provided by Amazon and Azure) and registers with the P2P servers using its UID (we are assuming here that UID is enabled). At regular intervals the camera sends packets to the P2P servers which shall include the UID (encrypted). The application on the P2P server decrypts the packet and extracts the UID. The application extracts the private IP and Public IP (BroadBand IP:Port) of the packet and populates them in the respective record associated with UID. If the camera changes IP then the record pointed out by the UID is updated accordingly. The credentials you created are not forwarded to the P2P servers. Well if you can emulate the P2P protocol and know the encryption method/phrase then you would be able to get the private and public IP of a particular UID. But so far there have been no such breaches and still you need the credentials to get access to the camera. Therefore it is imperative to follow the policies associated with passwords such as create a strong password and change it at regular intervals. At this point we see that there is a P2P socket between the camera and the P2P server. For your perusal the camera sends the alerts to the domain pushx.reolink.com. The application server will then forward the push message request to FCM (Android) or APNS (IoS) which shall push the message to your smartphone. Token provided by FCM to your smartphone on registration is forwarded to Reolink pushx application server. This token is included in the request made by this application server to the FCM to push the alert on your smartphone.

Now let's take a look from the client side. When you run the Reolink client, it will send a DNS query to 16 P2P servers (p2p1, p2p3, etc) and the response is the A record containing the IP address of the P2P server. Any P2P server which is not yet assigned will get the A record with the loop IP (127.0.0.1). For each working P2P server, the client requests the Public IP (the Relay P2P server with which the camera is connected) and Private IPs of the camera using destination port 9999. So if we have 8 working P2P servers and 8 cameras, then the client will send 64 requests over UDP. When the client receives the replies, it will first start to open communication with each camera using the private IP over TCP. Here the credentials are included in the request. If the camera replies then communication continues with the media being sent over UDP. Note that at this point the communication is directly between the client and the camera. At the same time the client also sends the request using the public IP. This public IP is not the public IP on your BB router but rather the IP of the AWS/Azure Relay P2P server to which the camera has been registered. But if communication using the private IP fails then the client establishes connectivity with this Relay P2P server. Recall that the camera has already a p2p socket with thus server. Communication is over UDP. In my opinion, this has been adopted because a number of ISPs restrict users to connect directly to other devices. Technically this is not P2P as there is the Relay server in the middle. So in this case the encrypted packets flow from the client to the Relay server and from the Relay server to the camera and vice versa. In this case the encrypted credentials are sent to the camera through this Relay P2P server. And here comes a question....if there are 1000 12Mbps@25fps and using high def H.265 and the cameras are being accessed remotely using the public IP, then on the P2P relay servers we need a bandwidth of 17Gbps .......... which is really massive.....This explains the delay between viewing using private/local IP (cameras and client on same network) and public IP (other). And I do not think that neither Amazon nor Azure will give unlimited bandwidth.

Now the question being posed is 'Do we trust this setup?' Do you trust passing the bank information when buying over the internet? Do you trust ATM machines which are connected over BB? Do you trust your voice calls over 3G (A5/2 encryption)? etc etc.............. so you have the answer.

No matter how much security you have...there is always a way to get through. Even Alcatraz was a prison where nobody can escape...but they escaped. Nevertheless we need to do our best to protect and be secured.

Apologise for the lengthy answer...but this is high level...can go to the low level...ha ha these are rather simple protocols with the most complicated being within the Telco NEs.

@reolinkshayla They are all excellent products. I have one question though. Do the new E1 ODs have the same gear mechanism as the previous models? Thanks.

Update: support told me that they have different gearing mechanism and hopefully the problem of deviation is something of the past.

@islandman63_201848685748477 With the newest release the stretch mode has been removed. So to get the stretch mode you need to go back to the previous version. There have been a lot of requests from members to have the stretch mode back and hopefully we shall see this as an option.

Thanks for the update. Can you please let us know what bugs have been resolved by this release?

@dgordon42_415060065599711 I didn't hear anything from support. They should move away from the push notification and base their design on SIP(S) + SRTP or XMPP + SRTP (used by Whatsapp) as has been implemented by other camera suppliers. Of course this design requires SIP servers which entails the client and cam to be registered. SIP is fun...........have been working on this protocol (and many many other protocols) for a long time.

In security one of the most important factor is contacting the owner. We receive lots of push notifications, messages, alerts on our mobile and we tend to ignore. But if it is a call, we do check who is calling. So they can add a feature for the cam to call in the event a particular event is triggered, say glass sound, alarm sound, etc. The ideas depend on one's immagination.

@user_623346741346376_623346741346376 I disabled any motion on the RLC511WA and have added a 1 sec delay for person and thereafter no false alarms. Since April I haven't seen any firmware update on this model.

@reolink-fiona Hi Fiona, thanks for the invitation. We will certainly assist the members as much as we can.

@terryjensen_510712816316578 I do not think there is a solution now. Previous Windows clients had an option to disable it but in the recent upgrades this feature has been removed. I have notified support to re-introduce it and its up to the customer if the camera drains the battery.

@merbine_640217202712690 How about having a 4G router and then connect to the cameras through WIFI. Then you would opt for a mains powered camera which provides 24x7 recording and a detection range of 100 feet.

@hk-devices_510046838391027 The charging circuit limits the charging current and so you have to use the rated one. Try to contact supplier on support @ reolink . com

@rpotter28_851891842711683 Yes, you can set the mode to timer during which time the spotlight will be on as illustrated below.

@user_790914341261457_790914341261457 If you use the SD cards only, then you can either record on event detection or 24x7. These are mutually exclusive. To have both then you need an NVR or an HA (using ONVIF/RTSP). For 24x7 recording on SD, ensure that it is of high endurance.

And for NTP you can set a local NTP server or just allow port 123 through a firewall. Whatever is the easiest.

Yes, if you record solely on SD then the only bandwidth used is when you view the camera.

@user_790914341261457_790914341261457 consider an average bandwidth of 8Mbps for 8MP camera then for 100 cams recording all the time you need a bandwidth of 800Mbps. So 1G network is more than adequate. You can play 4k movies too and you won't experience any delays.

If you won't use push/email notification and you don't want to access the cameras from an external network then there is no need for the camera to have access to the Internet. Just either record to the internal SD or NVR or HA or ftp server.

Consider a backup of the recordings. If camera is stolen then you have no recordings. Normal practice is to record events on SD and 24x7 on NVR.

@user_863771412115668_863771412115668 Better to opt for an NVR which will be also accessible from anywhere.

@reolink-cam_813700743893181 Most network surveillance camera streams are made up of I-frames and P-frames, I-frames are full image captures that record everything the camera is seeing and P-frames are the frames between the I-frames where only the elements of the image that are changing are refreshed.

To explain this with an example, if you had an empty corridor and someone walked down it the I-frame would capture the entire image and then the following P-frames would only capture the elements of the image that are changing, which in this case would be the person walking.

The idea behind this is that it is another way to compress the bitrate of the camera stream because instead of capturing 25 full-resolution images every second you are capturing one full image every 50 frames (e.g. 2 seconds) and then all the frames in between only capture what changes in the image and thus are much smaller files/use less bitrate.

Reducing the I-frame interval (25 frames, 10 frames, etc...) will obviously increase the bitrate/bandwidth used by the camera and is only really recommended if you are installing the camera in a very busy scene where having the full image refresh more regularly can improve image detail. Increasing the I-frame interval (75 frames, 100 frames, etc...) will decrease the bandwidth used and is only really recommended when covering scenes with little to no activity as you will see a drop in image quality and maybe even distortion to any movement that happens between the I-frames.

Now as regards the new fw, ensure you have the lady one cited in the Download center. I have the WIFI trackmix and the first fw released included ONVIF but at the expense of lower resolution at clear mode. In fact the colours appeared washed out. We have requested to restore max bit rate and fps and the definition is merely the say as the old fw. There are some issues on the new fw. Do a search on Trackmix fw and you shall find a thread on this.

@user_867198496854215_867198496854215 just search my posts on P2P relay servers and you will find everything.

@crimp-on_62210811129 The timeline scrubber is a timer with a red or different colour line that indicates a point in time in the scene where the object was first detected. You can drag the time scrubber along the timeline to jump to a specific time in the scene.

I have seen this on Trackmix with the latest firmware and on Android. Not so accurate but at least they started.

@user_692864088391837_692864088391837 You may ask support on support @ reolink . com