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

[Jason Fischl]

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.