Hi all,
Please let this discussion on implementors ...
[EMAIL PROTECTED] wrote: > Ajay > > > > Timer 64*T1 is for the whole transaction. So if a final response does > not come within this time, the SIP transaction ends.....
For invite transactions: This is not mentioned in the RFC. Timer B is fired if transaction is in "Calling" state i.e. if no response (Provisional or Final) at all is received from the remote end. I think the intent for not providing a transaction time-out timer (like Timer B) when "Proceeding" state is reached, was that in general this state will be transitioned when a 180(Ringing) or 100(Trying) is received, and the callee should cancel the call (generally when he is frustrated). This involves human interaction, and no timer can predict human behaviour. Besides there may be session negotiation (using 183/Prack/Update) taking place, and it may take time before UAS indicate to the Callee about the received call, which may delay sending a final response to Initial Invite.
For non-Invite transactions, Timer F is valid in "Proceeding" state (although a 1xx for non-Invite request "Should not" be generated), as no human interaction is required at the Callee side. IMO this timer (Timer F) is not reset after receiving a Provisional Response(although not mentioned expicitly in RFC), and is continued as such.
regards mukul
> > Regards > Ranjit > > -----Original Message----- > *From:* Idnani Ajaykumar-AIDNANI1 > [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, August 11, 2004 7:04 PM > *To:* Ranjit Avasarala (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) > *Cc:* '[EMAIL PROTECTED]' > *Subject:* RE: [Sip] Some "Proceeding" state questions > > Ranjit, > > > > Thank you for your response. > > > > I think I still have a few questions. > > > > 1. Does the timer (64*T1) get reset, when you receive a 1xx > response from the UAS? > 2. Is the behavior same for an INVITE transaction, and a > non-INVITE transaction? If not, what is the difference? > > Thanks > > - Ajay > > -----Original Message----- > *From:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, August 11, 2004 12:02 AM > *To:* Ajaykumar Idnani; [EMAIL PROTECTED] > *Subject:* RE: [Sip] Some "Proceeding" state questions > > Hi Ajay > > > > On receiving provisional response the client transitions to > "Proceeding" state. It will remain in this state until it > receives a final response or until the life of the transaction > i.e 64*T1.after which the session expires. So there is no fixed > timer for "Proceeding" state. > > > > Regards > Ranjit > > -----Original Message----- > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > *On Behalf Of *Idnani Ajaykumar-AIDNANI1 > *Sent:* Tuesday, August 10, 2004 9:55 PM > *To:* '[EMAIL PROTECTED]' > *Subject:* [Sip] Some "Proceeding" state questions > > Hi, > > > > I had some basic questions on the "Proceeding" state in a > client transaction. They are as follows. > > > > 1. How long can a client stay in "Proceeding" state? Does > this vary for a INVITE client transaction and a > non-INVITE client transaction? > 2. The RFC does not seem to talk about the timers being > reset when a provisional response is received. I > thought provisional responses were meant to let the > client know that the server needs more time, and hence > the client should reset the timer on its end when it > receives a provisional response. Is this not the case? > Again is this different for an INVITE transaction and > a non-INVITE transaction? > > Appreciate your help. > > > > Thank you > > - Ajay >
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
