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

[Byron Campen]

Comment inline
>
> On Aug 8, 2006, at 2:10 PM, Jason Fischl wrote:
>
>> On 8/8/06, Byron Campen <bcampen at estacado.net> wrote:
>>>
>>> You have missed my point; sometimes the TU can't send a failure
>>> response because the request is too garbled, and there is no other
>>> interface for terminating transactions. There is nothing the TU can
>>> do in this situation.
>>>
>>
>> If the request was too garbled to generate a response, how was it  
>> able
>> to make it through the SipStack? It should be possible to construct a
>> failure response to any SipMessage that makes it to the TU. We may
>> need to make the Helper method that generates a failure response more
>> robust but I think that should be all that is required. Can you
>> provide some more concrete issues that exist in the current
>> implementation? Perhaps a test case.
>>
>> Jason
>
> The fact that we lazily parse things makes it possible for really  
> broken stuff to make it to the TU. We never check to see whether  
> mandatory headers are well-formed in the stack.
>
> Now if we can make Helper robust enough to handle any and all  
> possible cases of brokenness in the request, that should work fine,  
> but we need to keep in mind that stuff can be very broken indeed.  
> (For instance, what if the topmost via is garbage? We never check  
> its validity in the stack, we just ensure that it is there. How do  
> we respond to something with a bad topmost Via?)

Actually, this is a bad example; we end up parsing the topmost Via  
when we grab the transaction id. The point here is that really  
bizarre stuff can show up at the TU.


> Best regards,
> Byron Campen_______________________________________________
> repro-devel mailing list
> repro-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/repro-devel


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