Open issue: Server transaction lifetime

	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.

	Any comments? Should we push for this to make it in the
release?

Best regards,
Byron Campen

_______________________________________________
repro-devel mailing list
repro-devellist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/repro-devel

On 8/8/06, Byron Campen <bcampenestacado.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?
_______________________________________________
repro-devel mailing list
repro-devellist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/repro-devel

On Aug 8, 2006, at 1:49 PM, Jason Fischl wrote:

> On 8/8/06, Byron Campen <bcampenestacado.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?


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.

Best regards,
Byron Campen

_______________________________________________
repro-devel mailing list
repro-devellist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/repro-devel

On 8/8/06, Byron Campen <bcampenestacado.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
_______________________________________________
repro-devel mailing list
repro-devellist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/repro-devel

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 <bcampenestacado.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?

_______________________________________________
repro-devel mailing list
repro-devellist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/repro-devel

On Aug 8, 2006, at 2:10 PM, Jason Fischl wrote:

> On 8/8/06, Byron Campen <bcampenestacado.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_______________________________________________
repro-devel mailing list
repro-devellist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/repro-devel

Comment inline
>
> On Aug 8, 2006, at 2:10 PM, Jason Fischl wrote:
>
>> On 8/8/06, Byron Campen <bcampenestacado.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-devellist.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/repro-devel



_______________________________________________
repro-devel mailing list
repro-devellist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/repro-devel

On 8/8/06, Byron Campen <bcampenestacado.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.
_______________________________________________
repro-devel mailing list
repro-devellist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/repro-devel

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

> On 8/8/06, Byron Campen <bcampenestacado.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.

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

On 8/8/06, Byron Campen <bcampenestacado.net> wrote:
>
> On Aug 8, 2006, at 3:32 PM, Jason Fischl wrote:
>
> > On 8/8/06, Byron Campen <bcampenestacado.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.
_______________________________________________
repro-devel mailing list
repro-devellist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/repro-devel