Subject: [Sip] RFC 3261 section 17.1.1.2 INVITE Client transaction State Machine

From: "Nayak, Subhransu S" <[email-masked]>
Date: Wed, 27 Sep 2006 10:15:13 -0400

There is an obvious flaw in the INVITE client transaction state machine. Once in "proceeding" state, State Machine is purely driven by the peer's response to the INVITE. If peer goes down, then  INVITE client transaction gets stuck in the "proceeding" state forever. From an implementation's perspective, when does the TU in an UAC release the transaction resource in this case ?   

                   |INVITE from TU
             Timer A fires     |INVITE sent
             Reset A,          V                      Timer B fires
             INVITE sent +-----------+                or Transport Err.
               +---------|           |---------------+inform TU
               |         |  Calling  |               |
               +-------->|           |-------------->|
                         +-----------+ 2xx           |
                            |  |       2xx to TU     |
                            |  |1xx                  |
    300-699 +---------------+  |1xx to TU            |
   ACK sent |                  |                     |
resp. to TU |  1xx             V                     |
            |  1xx to TU  -----------+               |
            |  +---------|           |               |
            |  |         |Proceeding |-------------->|
            |  +-------->|           | 2xx           |
            |            +-----------+ 2xx to TU     |
            |       300-699    |                     |
            |       ACK sent,  |                     |
            |       resp. to TU|                     |
            |                  |                     |      NOTE:
            |  300-699         V                     |
            |  ACK sent  +-----------+Transport Err. |  transitions
            |  +---------|           |Inform TU      |  labeled with
            |  |         | Completed |-------------->|  the event
            |  +-------->|           |               |  over the action
            |            +-----------+               |  to take
            |              ^   |                     |
            |              |   | Timer D fires       |
            +--------------+   | -                   |
                               |                     |
                               V                     |
                         +-----------+               |
                         |           |               |
                         | Terminated|<--------------+
                         |           |
                         +-----------+

                 Figure 5: INVITE client transaction

Thanks,
- Subhransu 

_______________________________________________
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: Byron Campen <[email-masked]>
Date: Thu, 28 Sep 2006 14:17:29 -0500

This depends on the TU. For an endpoint, we often rely on the human  
user. (eventually the human user will decide they have waited long  
enough for an answer, and hang up, prompting the UAC to send a  
CANCEL) For a proxy, we rely on Timer C. I do not know of any  
specific mechanism for B2BUAs, but it follows that they should be  
prepared to handle this case.

Best regards,
Byron Campen

> There is an obvious flaw in the INVITE client transaction state  
> machine. Once in "proceeding" state, State Machine is purely driven  
> by the peer's response to the INVITE. If peer goes down, then   
> INVITE client transaction gets stuck in the "proceeding" state  
> forever. From an implementation's perspective, when does the TU in  
> an UAC release the transaction resource in this case ?
>
>                    |INVITE from TU
>             |            From [email-masked] Thu Sep 28 15:20:21 2006
From: Byron Campen <[email-masked]>
Subject: Re: [Sip] RFC 3261 section 17.1.1.2 INVITE Client transaction State
	Machine
Date: Thu, 28 Sep 2006 14:17:29 -0500
To: "Nayak, Subhransu S" <[email-masked]>
Cc: [email-masked]

	This depends on the TU. For an endpoint, we often rely on the human  
user. (eventually the human user will decide they have waited long  
enough for an answer, and hang up, prompting the UAC to send a  
CANCEL) For a proxy, we rely on Timer C. I do not know of any  
specific mechanism for B2BUAs, but it follows that they should be  
prepared to handle this case.

Best regards,
Byron Campen

> There is an obvious flaw in the INVITE client transaction state  
> machine. Once in "proceeding" state, State Machine is purely driven  
> by the peer's response to the INVITE. If peer goes down, then   
> INVITE client transaction gets stuck in the "proceeding" state  
> forever. From an implementation's perspective, when does the TU in  
> an UAC release the transaction resource in this case ?
>
>                    |INVITE from TU