Re: [Sip] INVITE client Transaction....

[Natesan Kannan <nkannan@huawei.com>]

Hi,

    RFC 3261 says, in section 9:
"Note that both the transaction corresponding to the original request
   and the CANCEL transaction will complete independently.  However, a
   UAC canceling a request cannot rely on receiving a 487 (Request
   Terminated) response for the original request, as an RFC 2543-
   compliant UAS will not generate such a response.  If there is no
   final response for the original request in 64*T1 seconds (T1 is
   defined in Section 17.1.1.1), the client SHOULD then consider the
   original transaction cancelled and SHOULD destroy the client
   transaction handling the original request."

    Secondly, the scenario of CANCEL not getting a 200 response because of
the server crash cannot happen, as CANCEL is hop-by-hop and a 200 OK is sent
from the next proxy in line.

    In general, the timer mentioned above could be started irrespective of
*any* response to the CANCEL, including a time-out.
-Kannan
----- Original Message -----
From: "Mukul Purohit" <mpurohit@neomagic.com>
To: "Natesan Kannan" <nkannan@huawei.com>; <sip@ietf.org>
Sent: Thursday, February 27, 2003 11:52 AM
Subject: Re: [Sip] INVITE client Transaction....


> hi,
> I Still have few doubts .... (inline)
>
> Natesan Kannan wrote:
> > 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.
>
>
> "... if the server transaction on the remote end dies." If this is due
> to the crashing of the remote machine (as depicted in scenario by
> Rajesh), then how can sending CANCEL by the application useful (in
> coming out of the proceeding state). Since remote machine is not
> contactable, it cannot send "200" to CANCEL, and "487" to INVITE. So
> INVITE transaction is still stucked waiting for "487".
> What I can think is that application (or stack's transaction layer) is
> required to ensure a mechanism to cancel the INVITE transaction through
> CANCEL transaction. Is this correct?
>
> >
> > -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)" <rkalshet@cisco.com>
> > To: <sip@ietf.org>
> > 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 sip-implementors@cs.columbia.edu for questions on current sip
> >>Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip