Hello, now I think I understand the problem.
Timer B is running but its expiration has only effect if the state machine has the state CALLING. Then the state machine will inform the TU that a timeout happend. But if a provisional response was received the state changed to PROCEEDING and now I have to possiblities. 1. I stop Timer A but Timer B is still running. When Timer B expires that has no effect to the state. 2. I do not stop Timer A. Timer B is still running and retransmission will be maximal seven times. If Timer B expires it has no effect to the state machine. Timer B controls transaction timeout and NOT the transaction duration how I was thinking. Now both side UAC and UAS have no timer running which controls the duration until UAS creates a final message. If no final message will send UAC can send a CANCEL if the person hang up or the proxy can send a 408 Timeout to the UAC and a CANCEL to the UAS after three minutes. Thank you, now I got it. :) Markus "Markus Hofmann" <[EMAIL PROTECTED]> schrieb am 13.08.04 14:21:13: > > 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 ____________________________________________________ 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
