[reSIProcate] Open issue: Server transaction lifetime

[Byron Campen]

	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.

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

Best regards,
Byron Campen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060808/2506268e/attachment.bin>