Subject: RE: [SIP] State transition diagram for INVITE

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 4 Jan 2001 02:38:41 -0500

> -----Original Message-----
> From: Piotr S. Kossowski [mailto:[email-masked]]
> Sent: Sunday, December 17, 2000 6:00 PM
> To: SIP discussion list
> Subject: [SIP] State transition diagram for INVITE
> 
> 
> Dear All,
> 
> I'm a bit confused after long studying of Figure 12 of the 2543 spec.
> There is State Machine for INVITE method there.

Actually, you are talking about rfc2543bis.

> I'm especially interested in two states: CONFIRMED and COMPLETED.
> 
> Please, correct me if I am wrong:
> Being in FAILURE or SUCCESS we can proceed to COMPLETED under one
> condition: 32 second of inactivity (no requests from UAC).
> Within 32 s. the state machine is waiting for ACK. If no ACK, 
> it probably
> means that something must have happend to UAC, and "for sure" 
> the Call is
> lost. 

Yes.

> So, COMPLETED state is common for FAILURE and SUCCESS and simply
> means "forget this call". 

The state machine is transactional; it does not relate to call state. 

Hovewer, if ACK for SUCCESS call (200 OK was
> sent)
> appears State Machine procceds to CONFIRMED state and then 
> ALWAYS after
> 32 s. to the COMPLETED (call established, transaction successfully
> finalized)
> Thus, My question is:
> 
> 1. Does COMPLETED mean realy two states: either COMPLETED_SUCCESS or
>   COMPLETED_FAILURE? 
>   If yes, Maybe lack of ACK witihin 32s in SUCCESS state 
> allows machine to 
>   procceed to COMPLETED_SUCCESS ?!

As I said, the state machine is for the INVITE *transaction*; it is not a
call state machine. The transaction is completed, for better or worse, if
either we got an ACK and everything was OK, or no ACK ever arrived.

> 
> 2. What for is CONFIRMED state in fact ? No action is 
> generated on ACK 
>    in this state, and no (?) "call specific variables" are changed on 
>    "32s" transtition to COMPLETED.

The state is to handle any additional ACKs that may be in the network. It
simply ignores them, as opposed to the case where an ACK arrives for an
unknown transaction, which might be logged as an error in a real system.

> 
> 
> And my last issue. Let's consider the following scenario:
> 
> We are currently in SUCCCESS state. So, we are waiting for 
> ACK. Sometimes, 
> we can  receive a lost INVITE - we treat it as a 
> retransmission and we 
> send, what  we have just sent - 200 OK.
> But, according to 4.2.1 (INVITE description), we must regard this 
> transaction as COMPLETED or, at least, we are not allowed to 
> response with
> "400 Bad Request" if we have just received another INVITE (re-INVITE).

If a new INVITE arrives, it is a new transaction, and thus a new state
machine. 
Again, your confusion stems from trying to interpret this diagram as a call
state machine as opposed to a transaction state machine.

> If this is true, such re-INVITE should invoke new instance of state
> machine.
> (or something else should happend, correct me)

Yes.

> For one call, we have now two state machines. Let the second machine
> work. Meanwhile, 32s timeout expired and the first machine transited
> to COMPLETED. Beacause I don't know (as mentioned above) what 
> COMPLETED
> really means, my question is: what may (should, must) happen then:
> - Behaviour the first machine is irrelevant ("the newest" machine
>   "hide" all the previous)
> - The second machine should be stopped, because the call was 
> broken down.
>   The call is being destroyed.
> - something else ?

The call state processing is separate. If I get an INVITE, and while
waiting, get and reject a re-INVITE, and then accept the initial INVITE, the
call is active.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip