Subject: [sipcore] RFC 6026: timer to use to avoid being stuck within Proceeding

From: Brett Tate <[email-masked]>
Date: Mon, 23 Jun 2014 06:55:08 -0400

Hi,

A RFC 6026 thread on sip-implementors raises a question concerning what
timer(s) were expected to be used to eventually allow the transition from
Proceeding to Terminated when stuck in Proceeding because of the RFC 6026
requirement to remain in the current state during non-recoverable
transport error situations.  Within the following paragraph, was a
proprietary timer expected to be used while within Proceeding?  If not,
what RFC defined timer was expected to be used?

"A server transaction MUST NOT discard transaction state based only on
 encountering a non-recoverable transport error when sending a
 response.  Instead, the associated INVITE server transaction state
 machine MUST remain in its current state.  (Timers will eventually
 cause it to transition to the "Terminated" state).  This allows
 retransmissions of the INVITE to be absorbed instead of being
 processed as a new request."

Thanks,
Brett

---

From: Michael Procter <[email-masked]>
Date: Mon, 23 Jun 2014 14:57:14 +0100

My recollection is that the only way for the IST to leave "Proceeding"
is to receive a final response from the Transaction User.  Once a
final response is received, the remaining transitions to "Terminated"
are guarded by timers H, I, and L.

I'm not aware of a timer guarding the final response from the TU,
except for one requested in an Expires header.  I think it is probably
reasonable to assume that the transaction layer and transaction user
are sufficiently closely coupled that they communicate reliably and so
don't need a timer.  If an implementation can't make that assumption,
then I think timer C is probably morally acceptable since it guards a
similar condition for proxies.

Regards,

Michael

On 23 June 2014 11:55, Brett Tate <[email-masked]> wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Robert Sparks <[email-masked]>
Date: Mon, 23 Jun 2014 18:04:32 -0500

Just to make sure folks aren't misreading one thing - you would
only remain in the proceeding state while the TU has only handed you
1xx responses (or no response at all). Even if there were transport
errors, if the TU hands you a 2xx, you will transition to Accepted
(and possibly spin there for a bit if trying to send the 2xx causes
a transport error), or to Completed for 300 and greater responses.
Timers in the INVITE server state machine will drain you out of Accepted
or Completed.

Nothing drains you from proceeding because Invite transactions
are designed to be able to pend forever. What will take you out of that
state is either the peer changing the state (such as with a CANCEL), or
the TU handing down a final response.

And the TU is the thing that needs to make the decision on the final
response. It's what knows enough to clean up application state if it
decides to give up on a long pending transaction.

RjS

---

From: Caixia Liu <[email-masked]>
Date: Tue, 24 Jun 2014 11:07:56 +0800

Thanks a lot for your clarification.

I got the idea. When TU hands a response to server transaction, server
transaction should transition the state according to the response
immediately no matter whether we might run into a transport error or not.

Best Regards,
Caixia

---

From: Brett Tate <[email-masked]>
Date: Tue, 24 Jun 2014 06:37:45 -0400

Thanks for the clarification.  So that I can refer to it in the future,
what supports this interpretation?

The server diagrams support remaining within proceeding state unless you
assume that the Transport Error arrow excludes the sending of anything
which might cause a state transition (or are the second phase of another
arrow).  Similarly the following paragraph requires the reader to assume
that "MUST remain in its current state" excludes the sending of anything
which might cause a state transition (or are the second phase of sending
something which may or may not have already caused a state transition).

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Robert
> Sparks
> Sent: Monday, June 23, 2014 7:05 PM
> To: [email-masked]
> Subject: Re: [sipcore] RFC 6026: timer to use to avoid being stuck
> within Proceeding
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Jun 2014 07:58:23 -0500

>   processed as a new request."
I think you've become confused about what the transition conditions
say. I think you're trying to read "send response" as "successfully sent
response". It just means that you passed  it to the transport layer,
which may come back and say it had trouble later.
(Search for "MUST be passed to the transport layer" in RFC3261.)

The thing you should point to is the second paragraph of 7.1:
"    If the SIP element's TU (Transaction User) issues a 2xx response for
    this transaction while the state machine is in the "Proceeding"
    state, the state machine MUST transition to the "Accepted" state and
    set Timer L to 64*T1, where T1 is the round-trip time estimate
    defined in Section 17.1.1.1 of [RFC3261]."

and the corresponding language for 3xx-6xx in RFC3261.