Re: [reSIProcate] CANCEL and TransactionState

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	Both proxies and user-agents end up needing to worry about this in  
exactly the same way. I think we'd be able to shed some code in both  
repro and dum if we were to do this (particularly in dum).

Best regards,
Byron Campen

> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

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