[reSIProcate] [repro-devel] Open issue: Server transaction lifetime

[Jason Fischl]

On 8/8/06, Byron Campen <bcampen at estacado.net> wrote:
>         When a new request is received by the stack, a new TransactionState
> is created, and the request is handed off to the TU. This
> TransactionState will wait indefinitely for the TU to get back to it.
> So the TU is expected to respond to EVERY request sent to it by the
> stack (which, incidentally, repro doesn't do). But, in the cases
> where the message is so malformed that the TU is unable to form a
> response, the TU has no way (that I can see) of letting the stack
> know to clean up the TransactionState.
>
>         What I think we need to do is create a function in SipStack that
> takes a transaction id and a bool indicating whether this is a NIT,
> and schedules the deletion of the corresponding TransactionState. We
> shouldn't just delete the transaction immediately, because we would
> end up treating any retransmissions as new requests. This function
> will create a TimerH for invite transactions, or a TimerJ for non-
> invite transactions, as if the TU had sent a failure response (Timer
> G does not need to be added, since there is no "real" response to
> retransmit), which will prompt deletion of the TransactionState after
> it has had a chance to absorb retransmissions.
>
In the case of an INVITE in a proxy, it should be the TU's
responsibility to terminate the transaction if no 1xx or final
response has been received for more than Timer C.

In the case of a NIT, it should also be the TU's responsibility to
send a final response. I don't believe this job should be done by the
transaction layer.


>         Any comments? Should we push for this to make it in the release?

This feels to me like a risky thing to try and get into this release.
Can we have some additional discussion on it before proceeding with
any implementation?