It doesn't make too much sense at all to send the IV together with the key. The whole idea of an IV is that it is unique per key. But if the key changes value each time, then any IV is unique.
So you could use a static IV or even an IV that consists of all zeros. In that case you only need to worry that you don't reuse the key at other locations in the protocol. For instance for CTR mode, you should not use a Key Check Value that is generated by encrypting a block consisting of all zero's, as it would leak the initial block of the resulting key stream.
It's not a good idea to perform operations with the key to derive an IV though. If you need a separate key and IV from a given secret, please use a KBKDF such as HKDF to separately calculate the key and IV from the secret.
If your key is not changing despite the protocol given above then just prefix a unique (cryptographically safe random) IV to the ciphertext. This should also be the fail-safe default. Using an authenticated cipher like GCM or EAX should also be considered.
Sending the secret value to the other side over a secure channel is usually not a good idea. Session keys should be established beforehand, preferably by using a key agreement algorithm to provide forward security. Sending the key over a secure channel sounds easy, but if you already have a secure channel, you don't need a session key to establish a new one.