Hi Nils, >IMHO only two things can happen we you are in the Proceeding state: >- either the user hangs up >- the UAS sends a final reply
There are more possibilities. I have a test cases where I send a 180 Ringing to stop Timer A after an INVITE. No final response will send. After 32 sec the UAC state machine will destroy. But after 3 min the proxy sends a 408 Time out to the UAC and a CANCEL to the UAS. The UAS has no timer running and can handle the CANCEL. But the UAC state machine is destroyed, so I can't send an ACK. In my opinion there are only two possibilites to control the situation. 1. I will send a CANCEL after Timer B expires or 2. I will stop Timer B after I receive a provisional response and wait for an answer of the proxy. I didn't find anything in the RFC 3261 about this situation. Greeting Markus Hi Vivek, On Thursday 12 August 2004 14:21, [EMAIL PROTECTED] wrote: > So u r saying that this timer should be stopped on receiving first > response even it is a Provisional response. What if after receiving > first provisional response (timer has been stopped, as u said), no other > final response is sent by the UAS. Will the transaction exist > indefinitely? will the user be on the phone indefinitely? I guess not. If the user is frustrated enough he will hang up. And when that happens you can send a CANCEL, and you are not longer in Proceeding state. IMHO only two things can happen we you are in the Proceeding state: - either the user hangs up - the UAS sends a final reply (- you receive another provisional response, but then you will stay in Proceeding state) So for what do you need a timer in this state? Even if the UAS crashed while you are beeing in the Proceeding state, your user will sooner or later hang up. I can only imagine that you will stay forever in the Proceeding state if your user dies while your are in this state ;-) Greetings Nils > Vivek > > -----Original Message----- > From: Mukul Purohit [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 12, 2004 5:30 PM > To: Vivek Srivastava (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Ranjit Avasarala > (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) > Subject: Re: [Sip-implementors] RE: [Sip] Some "Proceeding" state > questions > > [EMAIL PROTECTED] wrote: > > Hi Ajay and wayne, > > Though the RFC does not talk about 64*T1 timer, it does not mean that > > it > > > should be reset. This timer, which shows the maximum life of a > > transaction, should be stopped only in "completed"state or > > "terminated" > > > state. > > Vivek. > > Nope .... IMO (and As pointed out by Nils also on sip-list) this means > that (with default setting of T1=500ms) I can ring a phone only for 32s. > > This cannot be correct. This timer should be stopped on receiving first > response (a PR or FR). The transaction is closed by the User (when the > phn is hanged up, since no one is picking at the other end). > > mukul > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Thursday, August 12, 2004 3:05 AM > > To: Idnani Ajaykumar-AIDNANI1 > > Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] > > Subject: [Sip-implementors] RE: [Sip] Some "Proceeding" state > > questions > > > Ajay, > > Questions of this nature are better sent to the SIP > > Implementors > > > Mailing List , responses to this > > thread > > and further queries should be posted there. > > > > Section 17of RFC 3261 covers this area - my understanding for > > your > > questions is: > > 1. you asked "Does the timer (64*T1) get reset, when you receive a 1xx > > response from the > > UAS?" - Good question and I searched the above section and > > other > > > parts > > of the RFC for a definitive answer and couldn't find one - alhough it > > is > > > early morning in Australia and I haven't had coffee. You can > > definately > > > have a call in the proceeding state for longer than an initial Timer B > > period (in your example 64*T1) - it seems to me that the B Timer does > > get > > reset - like the C Timer on a stateful proxy. The state machine shows > > all > > 1xx responses are passed to the TU and therefore this could reset the > > B > > > Timer - but like I said I couldn't find the reference. > > 2. you asked "Is the behavior same for an INVITE transaction, and a > > non-INVITE > > transaction? If not, what is the difference?" The state machine is > > very > > > similar, and also covered in section 17 - 3261 > > also says this for non-INVITE requests and provisional responses: > > > > 8.2.6.1 Sending a Provisional Response > > > > One largely non-method-specific guideline for the generation of > > responses is that UASs SHOULD NOT issue a provisional response for > > a > > > non-INVITE request. Rather, UASs SHOULD generate a final response > > to > > > a non-INVITE request as soon as possible. > > > > Regards, > > > > Wayne Davies > > > > > > > > > > > > Idnani Ajaykumar-AIDNANI1 > > Sent by: [EMAIL PROTECTED] > > 11/08/2004 11:33 PM > > > > > > To: "'[EMAIL PROTECTED]'" > > > > 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 > > Confidentiality Notice > > > > The information contained in this electronic message and any > > attachments > > > to this message are intended > > for the exclusive use of the addressee(s) and may contain confidential > > or > > privileged information. If > > you are not the intended recipient, please notify the sender at Wipro > > or > > > [EMAIL PROTECTED] immediately > > and destroy all copies of this message and any attachments. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > ************************************************************************ > > > ****** > > - NOTICE FROM DIMENSION DATA AUSTRALIA > > This message is confidential, and may contain proprietary or legally > > privileged information. If you have received this email in error, > > please notify the sender and delete it immediately. > > > > Internet communications are not secure. You should scan this message > > and > > > any attachments for viruses. Under no circumstances do we accept > > liability for any loss or damage which may result from your receipt of > > this message or any attachments. > > ************************************************************************ > > > ****** > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > > > > Confidentiality Notice > > > > The information contained in this electronic message and any > > attachments to this message are intended > > > for the exclusive use of the addressee(s) and may contain confidential > > or privileged information. If > > > you are not the intended recipient, please notify the sender at Wipro > > or [EMAIL PROTECTED] immediately > > > and destroy all copies of this message and any attachments. > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > Confidentiality Notice > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain confidential or privileged information. If you are not the intended > recipient, please notify the sender at Wipro or [EMAIL PROTECTED] > immediately and destroy all copies of this message and any attachments. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ____________________________________________________ Aufnehmen, abschicken, nah sein - So einfach ist WEB.DE Video-Mail: http://freemail.web.de/?mc=021200 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
