On Friday 13 August 2004 13:26, [EMAIL PROTECTED] wrote: > -Nataraj > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Nils > Ohlmeier > Sent: Friday, August 13, 2004 4:27 PM > To: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] RE: [Sip] Some "Proceeding" state > questions > > > > 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. > > > > [ABN] Why the state machine needs to be retained even after the > transaction protection timer timed out. In this case it could very well > assume like 408 received from network (but no response sent to the peer) > > > > I don't think we need to maintain the state machine until the user hangs > up the phone... (We can't retain the resources for ever)
What resources are you retaining? The memory to keep the transaction state? There is no line occupied like in the PSTN world! Both sides of the call just use some memory to keep the transaction state, and every few seconds a '180 Ringing' packet is going over the line. Where is the problem? If your user still did not hang up 32 seconds after he heard the first ring back tone he probably wants to let it ring for a longer period of time. I think your resources will only be retained forever if the user died in front of your phone. Otherwise he will hang up sooner or later. I'm pretty sure about that :-) Regards Nils Ohlmeier > > 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. > > > > [ABN] if you receive the response after you deleted the resources then > we can simply just drop those responses... > > > > 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 > > > > > > > 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
