Application vs Stack Responsibilities

From reSIProcate

[edit] 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.

[edit] Server transactions

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.

[edit] Client transactions

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.