Subject: AW: [Sip] INVITE client Transaction....

From: "Jesske, R" <[email-masked]>
Date: Tue, 25 Feb 2003 11:33:32 +0100

Dear all,
From my understanding from an operator point of view this question is valid and belongs not only to the application. A operator/service provider network needs timeouts regarding the answer to a call. If I make this depended on the application I will get interoperable applications.

Also it is not defined (from my point of understanding) within RFC 3261 in which cases timer B (I think this belongs also to other SIP timers) will be cancelled/terminated. 

Or can somebody give me clarification on this issue.  

Best Regards

Roland Jesske

Deutsche Telekom AG
T Com Zentrale
Roland Jesske, T38-12
Section T38; Signalling, Gateways and Switching Systems 
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
 <mailto:[email-masked]>

> -----Ursprüngliche Nachricht-----
> Von: Natesan Kannan [mailto:[email-masked]]
> Gesendet: Donnerstag, 13. Februar 2003 16:26
> An: Rajesh Kalshetty (rkalshet); [email-masked]
> Betreff: Re: [Sip] INVITE client Transaction....
> 
> 
> Excerpt from a previous query on the same subject and Jonathan's reply
> embedded...
> -Kannan
> 
> *********
> This is an application issue. It can decide to give up at any time and
> send CANCEL. We don't want to specify the maximum time a user will let
> the phone ring.
> 
> -Jonathan R.
> 
> Vijaya Venkatachalam wrote:
> > Hi,
> >
> > I have a question regarding the INVITE transaction
> > state machine.
> >
> > It seems that in RFC 3261 - transaction state machine for
> > INVITE transactions, there is a potential for
> > the client side transaction to indefinitely be
> > in the "Proceeding" state since all timers
> > are cancelled on the reception of a 1xx response.
> >
> > Can somebody tell me how the client side transaction
> > can come out of this state, if the server transaction on
> > the remote end dies?
> >
> > Is it that the timer B is not cancelled and that only
> > timer A is cancelled when the 1xx is received or is
> > there some other means.
> >
> > Appreciate a quick response.
> >
> > Thanks,
> > Vijaya
> *********
> ----- Original Message -----
> From: "Rajesh Kalshetty (rkalshet)" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, February 13, 2003 5:35 PM
> Subject: [Sip] INVITE client Transaction....
> 
> 
> >
> > Hi all,
> >
> > I have a question Regarding the INVITE client Transactions 
> state m/c .
> When
> > a client transaction  moves to the proceeding state after  
> receiving a
> > provisional response by how much time it has to wait in 
> that state for a
> > final response.
> >
> >
> >    A     Invite        B
> >     |------------------>|
> >     |   1xx            |
> >     |<------------------|
> >     |                    |
> >     |                    x client crashes.
> >     |                    |
> >
> > suppose that client B crashes after it sends a provisional 
> response,i
> don't
> > find any way for the A's client transaction to come out of 
> the proceeding
> > state in RFC.
> >
> >
> > Regrds,
> > Rajesh k.
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Natesan Kannan <[email-masked]>
Date: Tue, 25 Feb 2003 16:21:36 +0530

Dear Roland,

This is exactly why the ringing timer is not controlled by the protocol.
This would enable you to deploy a uniform alert time across a multi-service
switching network. In this case, 'the application' could refer to the
switching entity.

-Kannan

----- Original Message -----
From: "Jesske, R" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 25, 2003 4:03 PM
Subject: AW: [Sip] INVITE client Transaction....

Dear all,
From my understanding from an operator point of view this question is valid
and belongs not only to the application. A operator/service provider network
needs timeouts regarding the answer to a call. If I make this depended on
the application I will get interoperable applications.

Also it is not defined (from my point of understanding) within RFC 3261 in
which cases timer B (I think this belongs also to other SIP timers) will be
cancelled/terminated.

Best Regards

Roland Jesske

Deutsche Telekom AG
T Com Zentrale
Roland Jesske, T38-12

---

From: "Vishal Verma" <[email-masked]>
Date: Tue, 25 Feb 2003 16:33:02 +0530

I would like to suggest minor modification here ...

1xx response from User B should not cancel timer at User A but 1xx response
should reset and increment the INVITE timer at User A .User A should start
timer of this much duration and retransmit message after timer expiry

where , initial timer and increment should be configurable values

 so after receiving 1xx response timer value should be calculated as
   final_timer_value = present_timer_value + timer_increment

where ,

present_timer_value, timer_increment are configurable values

regards, vishal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Jesske,
R
Sent: Tuesday, February 25, 2003 4:04 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: AW: [Sip] INVITE client Transaction....

Dear all,

Best Regards

Roland Jesske

Deutsche Telekom AG
T Com Zentrale
Roland Jesske, T38-12