Subject: [Sip] Re: [Sip-implementors] RFC3261: INVITE and non-INVITE servertransactions proceeding state has no timer

From: "vimal srivastava" <[email-masked]>
Date: Fri, 26 Aug 2005 11:01:59 -0400

Actually there is no customization. You are assuming TU at UAC and UAS both 
are not responding.
lets take the new case:
UAC sends an Invite and creates a client transaction, runs timer B
UAS receives the invite and creates a server transaction.
UAS user is not replying. so UAC side transaction is taken care because of 
time out condition.
now at UAS side, you are asking about its User is not replying and UAS 
should run timer to clean it up? right? this will happen if TU is dead, or 
its not working the way it should. why should 3261 provide anything for 
that? if TU has died, then application should clean up the hanging 
transaction. if TU is not working the way it should then again, application 
should write some cleanup on periodic timers.I think this has nothing to do 
with 3261. 3261 is between UAC-UAS, for establishing session.
but again, its more related to the way you look at it.
cheers
v.

From: Feng QIN <[email-masked]>
To: vimal srivastava <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [Sip-implementors] RFC3261: INVITE and non-INVITE 
servertransactions proceeding state has no timer
Date: Fri, 26 Aug 2005 10:49:37 -0400

Yes, I agree with you this can work under the help of TU level customized
mechanism, but it can't apply to pure transaction stuff, if there is only a
UAC => UAS (no B2BUA) with INVITE, and TU at UAS side has no response, the
UAS at proceeding state will be dead?

Besides I think it will be prefered by application developer if this problem
can be solved under stack level...

On 8/26/05, vimal srivastava <[email-masked]> wrote:
 >
 > This is how b2bua is working
 > You receive INIVTE at UAS, => a server transaction is created
 > you send out INVITE from UAC => a client transaction is created.
 > now if UAC does not receive any response from the network, then client
 > side
 > transaction will expire Timer B, and tell the application about the
 > TimeOut
 > Condition. now B2bua should respond to UAS side (response of Invite
 > received) based on policy may be 5xx etc.
 > so all the transactions are taken care of.
 > v.
 >
 >
 > From: Feng QIN <[email-masked]>
 > To: [email-masked], [email-masked],
 > [email-masked]
 > Subject: [Sip-implementors] RFC3261: INVITE and non-INVITE
 > servertransactions proceeding state has no timer
 > Date: Fri, 26 Aug 2005 00:45:39 -0400
 >
 > Hello all,
 > If we look at RFC3261 on INVITE and non-INVITE server transaction, in
 > proceeding state, transaction only wait for TU to give response to send,
 > but
 > there are no timers to check when TU can give the response.
 > Assuming in a B2BUA, if the outgoing client transaction has no response,
 > the
 > INVITE server transaction will NOT get the response from the TU ever, 
thus
 > the transaction resource will be dead here.
 >
 > Do we really miss timers there or it implies application should add timer
 > for this case by itself?
 >
 > Thanks in advance!
 >
 > --
 > Best Regards.
 >
 > QIN Feng
 > _______________________________________________
 > Sip-implementors mailing list
 > [email-masked]
 > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
 >
 >
 >

--
Best Regards.

QIN Feng

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip