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

From: "Rajesh Kalshetty (rkalshet)" <[email-masked]>
Date: Thu, 13 Feb 2003 17:35:25 +0530

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

---

From: Natesan Kannan <[email-masked]>
Date: Thu, 13 Feb 2003 20:56:10 +0530

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
*********

---

From: Mukul Purohit <[email-masked]>
Date: Thu, 27 Feb 2003 11:52:01 +0530

hi,
I Still have few doubts .... (inline)

> send CANCEL. We don't want to specify the maximum time a user will let

"... 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?

>>I have a question Regarding the INVITE client Transactions state m/c .
> 
> When
> 
>>suppose that client B crashes after it sends a provisional response,i
> 
> don't
>

---

From: Natesan Kannan <[email-masked]>
Date: Thu, 27 Feb 2003 12:08:11 +0530

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

---

From: Mukul Purohit <[email-masked]>
Date: Fri, 28 Feb 2003 12:32:49 +0530

hi
coments inline ....
first a request : can u provide me the link to the previuos discussion 
on the same subject, as u had mentioned. I browsed the archive but cudnt 
filter out the mails.

>    transaction handling the original request."

Doesnt it implies that transaction layer must cancel the transaction 
after this timeout (which can be timer B). If the implication is that UA 
must start this timer (called by some other name) then Timer B and this 
timer are duplicated (unnecessary overhead ).

> from the next proxy in line.
I am not sure on this. Wont the proxy reply with trying and wait for an 
OK from the remote host and then send an OK. Please clarify on this issue.

> *any* response to the CANCEL, including a time-out.

I agree to this. But this timer must be started at transaction layer 
when initial INVITE request is send (that is the reason i m calling it 
timer B) and a mention in the state diagram over the path from 
*proceeding* state to *terminated* state on the expiry of this timer.

- mukul