Hello, On Friday 13 August 2004 11:42, Markus Hofmann wrote: > >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
Why is the state machine destroyed??? If there is no timer, which i suppose here, then the state machine will exist and stay and the proceeding state as long as the user did not hang up, or the the UAS send a final reply. > 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. And because there is still a state, you can easily handle any reply. Regards Nils Ohlmeier > 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 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
