< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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



On Aug 8, 2006, at 1:49 PM, Jason Fischl wrote:

On 8/8/06, Byron Campen <bcampen@xxxxxxxxxxxx> 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?


You have missed my point; sometimes the TU can't send a failure response because the request is too garbled, and there is no other interface for terminating transactions. There is nothing the TU can do in this situation.

Best regards,
Byron Campen

Attachment: smime.p7s
Description: S/MIME cryptographic signature