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

[Byron Campen]

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

Best regards,
Byron Campen
-------------- 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/07f1eb3e/attachment.bin>