[reSIProcate] CANCEL and TransactionState

[Byron Campen]

	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 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
>>
>>

-------------- 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/fa9b6b5f/attachment.bin>