For counter mode, the only condition for your IV (i.e. initial counter value) is, that it doesn't repeat over messages, and more, that it doesn't collide with any of the counter values in use for all the messages using the same key.
One way to do this would be to simply count forward from the last message, e.g. first message uses 1, 2, 3, second message uses 4, 5, 6, 7, third message uses 8, 9, and so on.
Another way would be to split the counter in two parts, one for the "in-message-counter" (which would start at zero for each message) and another one for a "message-number" (which would be incremented between messages).
Or you can use a (pseudo)random value as the IV for each message (then the non-collision property holds with high probability as long as you don't send excessively many messages with the same key). That could be a hash of the message number, but there is no real advantage to the first two versions.
If your protocol allows for reordering or dropping of the messages (i.e. message three can arrive before message two, and then is to be processed first), like UDP, you should include the starting counter in your message (it doesn't have to be encrypted). (But then you should make sure that duplicate messages either are ignored, or don't harm when processed twice.)
If the messages always arrive in the same order as sent (for example if you are sending them over a TCP-like channel), the the receiver can calculate the next counter value by the same rule as the sender (and drop the connection when the MAC fails).
The authentication (whatever it is) should include the initialization vector (or all data from which it can be derived) (whether it is sent or implicit). There is some consensus that "MAC the ciphertext" is generally better than "MAC the plaintext", as it avoids some chosen-ciphertext attacks.
"Hash plaintext and encrypt" (what was one of the proposals) is a bad idea when used with counter mode (It also needs careful examination with other modes):
If the attacker knows (or can guess or choose) the original message, she also knows the original hash. She can then chose an own message of the same length, calculate the new hash, and XOR both new and old message and hashes into the original ciphertext to get a valid original ciphertext of the new message (with the same IV).
A proper MAC (with its own key) does avoid that problem, as does an authenticated-encryption mode of operation.