[reSIProcate] CANCEL and TransactionState

[Byron Campen]

	I have been thinking about how the stack (and TransactionState in  
particular) treat CANCEL from the TU. Right now, sending a CANCEL to  
the stack is the only way the TU can express its desire to shed  
INVITE transaction state, but the stack will only accept a CANCEL if  
the transaction has received a response. This basically means that  
the TU has to keep state around denoting whether it wants to let go  
of a given INVITE transaction, whether it is allowed to send a CANCEL  
yet, and whether it has already sent a CANCEL (replicating portions  
of the transaction-state-machine). Might it be convenient to keep  
this information down in TransactionState instead, since anything  
that sends an INVITE will ultimately be forced to keep this state if  
it wants to be protected from a deliberately non-responsive UAS?

	Thoughts?

Best regards,
Byron Campen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070716/c898173e/attachment.bin>