In CTR mode the counter starts from $0$, therefore one doesn't need to send the initial value in the CTR mode.

$$\text{64 bits nonce}||\underbrace{\text{00000...00000}}_{64 \, zeros}$$

If you want to use the nonce ( yes it is nonce in the CTR mode) more than one file, then you need to send the start of the counter, too, and store it locally, you and the other side!. One can prepend this, too. Prepending is useful since it is at the beginning of the stream/file.

 $$\text{nonce}\|\text{counter Value}\|\text{encrypted Message}$$

Sending the start of the counter doesn't cause any insecurity problem, otherwise, we should already have with the CTR since we all know it starts from 0.

There is, however, a danger to use in this form. During a system failure, you may lose the last value, and instead, you may use the previous values of the counter. This can result in a catastrophic failure of confidentiality by the crib dragging technique. The mitigation is to use a new nonce, the best is exchanging a new key with ECDH and use a new nonce.

An interesting case of the danger is if both parties send a new message at the same time with the same counter, nonce, and key value. That is catastrophic! Therefore, if the messaging is in two directions with the same key, nonce, and counter continuation, it is not advisable to continue the counter where it is left. At least, generate a new nonce.

Remember, the CTR mode has many [disadvantages with AES][1], as the lack of integrity and authentication that AES-GCM handles. And the [AES-GCM is hard to use][2] instead use ChaCha20-poly1305 where AES is not obligatory.  


  [1]: https://crypto.stackexchange.com/a/85572/18298
  [2]: https://crypto.stackexchange.com/a/84359/18298