Hi: If you still want to control this ringing time, we can put an Expires: header that in the INVITE that we send out and if we dont get a final response and this timer fires, the phone automatically sends a CANCEL.
Thanks, -Badri -----Original Message----- From: Nils Ohlmeier [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 8:48 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Some doubt on timers in transaction Hello, let's see it from this perspective: We are in the 'proceeding' state, which means the destination of our call allready send us something (a provisional response, most likely 180). Only two things can happen now: - the remote side picks up the call or rejects it. - the local user looses his patient and hangs up (cancel's the call). For both things there simply should be no timeout. Why? Let the user ring the destination phone how long he ever wants! In the PSTN world there are such timeouts, because your are occupying a line just for ringing. But in the packet switched world you do not use any resources (except that both UA's have to keep the call state). I have allready seen UA's which are terminating a call after 64*T1 after receiving a 180. I really dont like it, because I want to let it ring a lot longer, because my grandmother is not that fast anymore in answering the phone ;-) Greetings Nils Ohlmeier On Thursday 29 July 2004 12:05, [EMAIL PROTECTED] wrote: > Hi Nataraju, > > Timer Ta is started for retransmission and Tb is started for Transaction. > If Client transaction is in "calling" state and Ta expires, INVITE is > retransmitted. If Client transaction is in "calling" state and Tb expires, > state is changed to ?Terminated? state. If client transaction receives > Provisional response, state is changed to ?proceeding? state and Ta is > stopped. But Tb is still running and it should run because transaction > still exists. Rfc does not talk about the expiration of Tb when client > transaction is in ?Proceeding state?. What will happen if client > transaction is in ?Proceeding ?state and no final response is sent by > Server? > > Vivek > > > > -----Original Message----- > From: [EMAIL PROTECTED] on behalf of Mukul Purohit > Sent: Thu 7/29/2004 1:59 PM > To: Nataraju Alilaghatta (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Some doubt on timers in transaction > > [EMAIL PROTECTED] wrote: > > -Natraj > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Krishna > > Kanth T > > Sent: Thursday, July 29, 2004 12:07 PM > > To: [EMAIL PROTECTED] > > Subject: [Sip-implementors] Some doubt on timers in transaction > > > > Hi, > > > > I have one basic doubt in timers in UAC transaction. When a UAC > > transaction sends an INVITE request and gets a provisional response it > > enters a "Proceeding" state. Here rfc3261 says that for a proxy it > > should restart TIMER C. But however for an endpoint, it does not say > > anything about whether a timer has to be restarted or not and also does > > not say about the value of the timer. So i am assuming that the endpoint > > can start a timer of its choice. Now when this timer times out or when > > TIMER C times out (and proxy does not want to restart this timer), > > should we change the transaction state to "TERMINATED" or should we > > still remain in "PROCEEDING" state? > > > > [ABN] when provisional response received the retrans timer will be > > stopped (Ta). When INVITE sent out the Tb (= 64*T1) also would have been > > started which will take care of transaction termination. When Tb fires > > the transaction moves to TERMINATED state... > > Tb is not for this purpose. It controls the transaction timeouts i.e. > when there is no response at all from the other side. > > When in proceeding state, the termination of transaction if no further > response is received, is signalled by TU. TU can start a timer, or it > can wait for the user( probably human) response. This is beacause a > timer should handle machine controlled responses, and not the responses > (like 200,486 etc) which are dependent on human interaction. > > > I guess the INVITE-Client Transaction section describes about this topic > > in detail... > > It is not mentioned. > > > Rgds > > Krishna > > _______________________________________________ > > 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 > > _______________________________________________ > 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 _______________________________________________ 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
