[reSIProcate] CANCEL and TransactionState

[Jason Fischl]

This isn't a bad idea. However, are there considerations that are
different for user agents from proxies? In the past, we've taken the
approach of putting nothing that is UA-specific or proxy-specific in
the transaction layer.

Doing the CANCEL processing in repro isn't too bad. The CANCEL
processing in dum is pretty involved though. I'm not sure how this
would end up refactoring.

Jason

On 7/16/07, Byron Campen <bcampen at estacado.net> wrote:
>         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
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>