@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.

@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. At the same time the client broadcast a packet with command aaaa0000 on the network with destination port 2000. Note that the Client broadcasts the packet with payload aaaa0000 using destination addresses 255.255.255.255.255 and 192.168.1.255 (or your configured IP subnet). Now 255.255. 255.255 is the limited broadcast address which is only propagated within the single subnet of the interface that sent it. It is never routed to other subnets unlike the subnet directed broadcast address 192.168. 1.255 which may be routed from elsewhere, depending on router configuration. So in most cases only the cameras within the same subnet receives this packet. If there are cameras on the same network they have port 2000 opened and are listening for any broadcast with command aaaa0000. If this is received then the camera will reply to the source IP with the command aaaa0000, UID, IP, port 9000, mac and ID. So once the client receives this on port 3000 then it will start communication with the camera using TCP and port 9000. Note that at this point the communication is directly between the client and the camera which are on the same network. 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 opened with this 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.

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?

@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.

@seb_526812765704330 We have requested the scene mode to have both a scheduler and a status. Moreover to be enhanced we asked for geofencing which shall toggle (if selected) the activation/deactivation of the scene mode automatically once we arrive or leave the premises.

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.

@reolink-oskar

In order to be in line with your competitors you need to implement actual calling feature based on VOIP or XMPP. The one implemented is merely based on push message notification. And to go the extra mile, implement face recognition. And what about IFTTT, matter and webhook? Not all customers have HA for automation and I see that IFTTT is very basic. You may include the door lock too as competitors did. There are more and more features to add. It depends on one's imagination and creativity. Just read the customers requests here, at Reddit and in facebook and you will have an idea of what they are after.

@ryanoverholtzer_356153850994850 I wish to see this feature too implemented. Yeah they work pretty well on Ring and Wyze.

@thierry_835077729128592 Oui, vous avez besoin de l'IP ou de l'UID. Je formaterais la SD et vérifierais que la caméra fonctionne correctement avant de la connecter au Home Hub. Faites tous vos tests avant de l'installer. Prenez le temps de vous familiariser. Connectez-le ensuite au Home Hub et c'est le seul moyen d'accéder à la caméra. Uniquement via le hub domestique. Nous avons également demandé un accès direct mais nous n'avons reçu aucun retour.

@flashmagnum_909351053578484 I suggest you to submit your request to support on support @ reolink . com. We are customers like you assisting members wherever possible based on our skills and experience.

Note that when I see them separately, it is the same as the RLC-811WA, E1 OD Pro, Argus 3 Ultra, etc.

@chopstix Let me give some details on SIM.

Every mobile operator orders SIM cards from SIM manufacturers. Each SIM comprises an identifier ICCID, IMSI and the authentication key Ki amongst other parameters and applets. 

The Integrated Circuit Card Identifier (ICCID), an identifier of the actual SIM card chip itself. ICCIDs are also used to identify embedded SIM (eSIM) profiles. This ID can be up to 23 digits long, including a check digit calculated using the Luhn algorithm.

The International Mobile Subscriber Identity (IMSI) identifies SIM cards uniquely by their individual operator in a cellular network. The IMSI is stored as a 64-bit field and is communicated to the connected cellular network. In the core of a mobile operator network, the IMSI is used as main identification for obtaining further customer and device specific data.

All SIM cards contain cryptographic keys. The secret authentication key called Ki is unique and is stored on the ROM, a protected area of the SIM. The Ki is never exchanged between the mobile device and the network. Its purpose is to derive sub-keys that perform the necessary authentication procedures when a mobile device tries to join a carrier’s network. The Ki is also stored on the carrier’s network within a component called the Home Location Register HLR or lately with the introduction of 4G and IMS this is being referred to Home Subscriber Subsystem (HSS). The Ki is only known by the SIM manufacturer and a few persons handling the HLR programming. The IMSI and the Ki have to be inserted in each subscription.

So when you switch on the camera or smartphone, there is the IMSI attach whereby the mobile will forward the IMSI to the Radio access network (BTS for 2G, NodeB for 3G, eNodeB for 4G) and from the RAN to the MSC (for calls) and SGSN (3G data) or MME (4G data). This IMSI attach message will end up in the HLR which shall authenticate the SIM. So if the IMSI is defined on the HSS then the IMSI attach procedure will continue otherwise it will be rejected. And an IMSI can only belong to a mobile operator. Thence to connect to another mobile operator you need another SIM card which has different IMSI identifier. The MCC is the same but the MNC and SN will be different.

I hope that Reolink should start to add eSIM where there is no longer the need of any physical SIM. This innovation offers the same functionality as a regular SIM card but with an added unique capability: it is programmable, allowing for enhanced flexibility and ease of use. This programmability empowers users to seamlessly switch network operators without needing to physically swap cards. You just buy a plan and they will ask you to scan a QR code and then enter some details the details (like apn)

Now a GSM module integrated on smartphone or any device to be connected to GSM network is continuously checking the power of adjacent cells. If the calculated power is better that the one being connected to, the module shall request a location update to the mobile RAN with the new cellid it wishes to connect to. It could be a 3G cell rather than 4G depending of the module is allowed to anchor to 3G (UTRAN) networks. It could be that the mobile is on the edge of an area and it will be continuously changing LAC/RAC/TAC.

So I guess that in their previous 4G cameras, the GSM module was not able to compare the power of adjacent cells and request a LUP.

I know this area quite well :). And now there is VOLTE which requires IMS.

@user_817261050261638_817261050261638

Most probably you purchased the 3W solar panel. I have the 6W solar panel with the Reolink DUO 2, Argus 3 Pro and Ultra, Argus 4 Pro and have no issues as long as there is 2 hours of direct sunlight. On the Argus 4 Pro I get around 2 hours of battery usage per day.

But yes I agree that they should provide higher wattage solar panels esp in places with short periods of direct sun and higher capacity batteries (like the Altas PT ultra).

Nevertheless you did a good job. Well done. I don't ask any question as I know all the theory :).

@ddelrosso_61389620748490 That's it.

@chopstix Thanks. Exactly this is not the immersive view but rather the dual view or separated view. When the icon shows one dark box then you shall see both the widescreen and the telephoto views on the same screen. Conversely, when the the icon shows two boxes then the widescreen and the telephoto views are on different screens. Just wipe back and forth to get the two views.

@kimchigun Let make some calculations.

20,000mAh is 20 Ah. The battery capacity, volts times amp-hours, is about 3.6 x 20 = 72 Wh. The maximum input power is 5 x 1.2 = 6 W. Assuming a 10% power tolerance from the panel (regulator) the charge time in bright sunlight, continually facing the sun, would be 72/6/0.9 = 13.3 hours. However the charge might taper the charge current towards the end of charge so it would actually be longer than that....say 16 hours. Therefore we need a higher wattage solar panel .... at least a 12W panel which yields to 7 hours of bright sunlight.

@chopstix That means that we are reading what you write :). Joking. Sometimes I text while in a boring meeting which I don't chair and won't check my typing....

@chopstix Agree. But it would be more flexible if the camera can provide a number of monitoring positions which can be scheduled by the user. Maybe during the day positioned towards location A, afternoon towards location B and during the night towards location C. This has a pan of 355 degrees and so would be nice to add.

@chopstix eh... it is not Atlas but Altas. The objectives of this cam are being CX, having a higher battery capacity and able to provide pre event detection recording. I think this is the first on the market to provide this pre recording. WELL DONE.