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

[reSIProcate] CANCEL and TransactionState


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

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