Hi Nils, Nils Ohlmeier <[EMAIL PROTECTED]> schrieb am 13.08.04 12:57:32: > > 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.
That's strange. I was sure that I read something which says what happens if Timer B expires in state "Proceeding" but it didn't. If I look to Figure 5 on page 126, only once Timer B expires and that's in the CALLING state. The RFC says when you have to start Timer B but it doesn't say explicit when I have to stop it after reaching state "PROCEEDING". So I was the meaning, Timer B indicates the duration of a Transaction. If Timer B expires, the state transitions to TERMINATED. The problem are this: "If the client transaction is still in the "Calling" state when timer B fires, the client transaction SHOULD inform the TU that a timeout has occured. The client transaction MUST NOT generate an ACK. The value of 64 * T1 is equal to the amount of time required to send seven requests in the case of an unreliable transport. If the client transactoin receives a provisional response while in the "Calling" state, it transitions to the "Proceeding" state. In the "Proceeding" state, the client transaction SHOULD NOT retransmit the request any longer. Furthermore, the provisional response MUST be passed to the TU. Any further provisional response MUST be passed up to the TU while in the "Proceeding" state." If I understand you answer right you are stopping or ignoring Timer B after the state "Proceeding" is reached. Then on both UAC and UAS no Timer is running. First if UAS creates a non succesful response (3xx - 6xx) a Timer H is starting and then when UAC will receive a final response Timer D will start. If no final response will send Timer C of the Proxy will finish this situation or a CANCEL of the UAC. Is this right? Did the autor of the RFC forget to mention this? > > > 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 _______________________________________________________ WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern Informationen unter: http://freemail.web.de/?mc=021199 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
