[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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