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

[Byron Campen]

On Aug 8, 2006, at 3:44 PM, Jason Fischl wrote:

> On 8/8/06, Byron Campen <bcampen at estacado.net> wrote:
>>
>> On Aug 8, 2006, at 3:32 PM, Jason Fischl wrote:
>>
>> > On 8/8/06, Byron Campen <bcampen at estacado.net> wrote:
>> >> 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.
>> >>
>> >
>> > We parse everything that is required in the transaction in the
>> > Transport before the TransactionState object is created. The  
>> code is
>> > all in Transport::basicCheck. The
>> >
>> > The items such as To, From, Call-ID are dialog-specific and are not
>> > required in order to produce a failure response to a request.
>>
>> No, it doesn't. basicCheck() relies on Helper::validateMessage(),
>> which just makes a bunch of calls to SipMessage::exists().
>> SipMessage::exists() doesn't parse anything.
>>
>
> I don't think anything other than the Via and Request-Line need to be
> parsed in a request in order to be able to generate a response (or at
> least this should be the case). I'm not suggesting that there isn't a
> bug but I think we need to be careful here.
>
> The fact that exists returned true, indicates that the
> scanner(preparser) was able to identify a header that loosely
> corresponds to the correct thing.
>
> We know for sure that nothing will throw as a result of a parse error
> in the Transaction. Any parse exceptions will occur in the TU and can
> be caught there and handled appropriately. I think we just need a way
> to generate a failure response from a bad SipMessage. We know where to
> send it, we just need to send something back. My initial take on this
> is that it is better to send a 400 response than to drop it on the
> floor in these cases.


	Ok, agreed. Feedback is good in these cases. So, do we want to try  
to change Helper::makeResponse() to be safe, or do we want a special- 
case function that assumes that nothing is right with the request,  
and just form as minimal a response as possible? (My initial instinct  
is to make makeResponse safe, just to keep the API clean, but this  
could make the code very ugly)

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