[reSIProcate] Fwd: [repro-devel] Open issue: Server transaction lifetime

[Robert Sparks]

So, for repro right now, what headers could someone attack that the  
stack wouldn't try to parse before it got to the application?

Proxy-Require? Contact?

What else?

RjS

On Aug 8, 2006, at 2:45 PM, Byron Campen wrote:

> 	If the request has any malformed header that it parses during  
> processing, an exception will get thrown, and we will end up  
> dropping the message on the floor. There are some other cases in  
> the main loop of Proxy where a request will get dropped, but those  
> could only be triggered if there was a bug in the stack. Also, if  
> there is a server error of some sort, we will end up dropping the  
> request.
>
> Best regards,
> Byron Campen
>
>>
>>
>> I agree that we need to have list discussion on this.
>> Whether this goes into this release is something we can hold off
>> until the end of the discussion to decide.
>>
>> The problem that we have is that if we, as a TU, do not want to send
>> any response to the request, we
>> currently have no way to do so without permanently leaking the memory
>> for that TransactionState. It's
>> cleanup is entirely dependent upon the TU saying "Here's a response".
>> Or have I missed something?
>>
>> What Byron is proposing is adding an interface that says "We're not
>> going to respond to that" that has
>> the same side-effects on transaction state that sending a response
>> has (we need the transaction to go
>> into a retransmission-draining-state the same as it would if we
>> replied, not just instantly go away). From
>> my poking at it so far, this seems to be the best approach available
>> to us.
>>
>> Byron - to make this concrete, what are the cases where repro doesn't
>> respond to a request that's passed up?
>>
>> RjS
>>
>> On Aug 8, 2006, at 1:49 PM, Jason Fischl wrote:
>>
>>> On 8/8/06, Byron Campen <bcampen at estacado.net> wrote:
>>>>         When a new request is received by the stack, a new
>>>> TransactionState
>>>> is created, and the request is handed off to the TU. This
>>>> TransactionState will wait indefinitely for the TU to get back  
>>>> to it.
>>>> So the TU is expected to respond to EVERY request sent to it by the
>>>> stack (which, incidentally, repro doesn't do). But, in the cases
>>>> where the message is so malformed that the TU is unable to form a
>>>> response, the TU has no way (that I can see) of letting the stack
>>>> know to clean up the TransactionState.
>>>>
>>>>         What I think we need to do is create a function in
>>>> SipStack that
>>>> takes a transaction id and a bool indicating whether this is a NIT,
>>>> and schedules the deletion of the corresponding  
>>>> TransactionState. We
>>>> shouldn't just delete the transaction immediately, because we would
>>>> end up treating any retransmissions as new requests. This function
>>>> will create a TimerH for invite transactions, or a TimerJ for non-
>>>> invite transactions, as if the TU had sent a failure response  
>>>> (Timer
>>>> G does not need to be added, since there is no "real" response to
>>>> retransmit), which will prompt deletion of the TransactionState  
>>>> after
>>>> it has had a chance to absorb retransmissions.
>>>>
>>> In the case of an INVITE in a proxy, it should be the TU's
>>> responsibility to terminate the transaction if no 1xx or final
>>> response has been received for more than Timer C.
>>>
>>> In the case of a NIT, it should also be the TU's responsibility to
>>> send a final response. I don't believe this job should be done by  
>>> the
>>> transaction layer.
>>>
>>>
>>>>         Any comments? Should we push for this to make it in the
>>>> release?
>>>
>>> This feels to me like a risky thing to try and get into this  
>>> release.
>>> Can we have some additional discussion on it before proceeding with
>>> any implementation?
>>
>>
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.sipfoundry.org
>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>