Application vs Stack Responsibilities
Preventing Memory Leaks
There are a few cases where the stack will hold on to a TransactionState indefinitely while waiting for the TU to take some action. If the TU fails to take this action, the memory is effectively leaked.
The TU must respond to every request that comes up from the stack (excluding ACK). The TU must never "silently" drop a request, regardless of how malformd it might be.
When the stack receives a provisional response in an INVITE client transaction, it will keep the TransactionState indefinitely until either a final response arrives, or the TU sends a CANCEL. Because a final response is not guaranteed, the TU is responsible for deciding when it has waited long enough for a final response, and send a CANCEL. For endpoints, it is sufficient to rely on the human user for deciding when to send the CANCEL (ie, when they hang up). For proxies, RFC 3261 defines the Timer C mechanism.