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

[Byron Campen]

	To, From, CSeq, Callid, etc. The stack doesn't parse any of this  
stuff. It just ensures that these headers are present. They could be  
horribly malformed and make it all the way to the TU.

Best regards,
Byron Campen

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060808/1d70cc4b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060808/1d70cc4b/attachment.bin>