Home

Very briefly, the protocol works this way:

workflow

1. the camera register itself on the servers communicating its LAN address, and continuously send packets to keep the connection alive (basically an UDP hole punching).
2. the client requests the location of the camera using its ID
3. the server responds with all known camera addresses (LAN + external) or with an OFFLINE message.
4. the client try to contact the camera using the addresses and sending the camera ID
5. two possibilities here: a) if the camera get the message, it responds with its ID and starts sending keepalive messages to keep the connection opened. The client must respond to the keepalive messages otherwise the session get closed by the camera. b) if the client can not contact the camera directly, it tries other ways with the help of the server (I still have to study these functionalities, I think there are 2 options: 1) the camera can try to contact directly the client, if this method fails: 2) the connection is established using relay servers)
6. once the connection is opened, the client can send GET requests very similar to HTTP requests but using a different protocol
7. the responses are divided in various packets (they have a sequence number) and have to be reassembled by the client
8. the client have to ACK the received packages otherwise the session get closed by the camera

packets format

• the packets are composed by a header (4 bytes) and an optional payload
• the header is divided in 2 parts: the first 2 bytes represent the type of the packet (i.e. the type of message/command), the other 2 bytes represent the length of the following payload.
• the format of the payload depends on the message type and can be simple or have another header itself followed by the data