Subject: [Sip] transaction layer

From: 丸上 澄哉 <[email-masked]>
Date: Tue, 14 Dec 2004 18:00:03 +0900

Hi,
I need help clarifying an issue in the handling of 
transport failure for transaction layer.

RFC3261 section 17.1.4 says that

"The client transaction SHOULD inform the TU that a transport 
failure has occurred, and the client transaction SHOULD 
transition directly to the "Terminated" state.  The TU will 
handle the failover mechanisms described in [4]."

Furthermore section 17.1.1.2 says that 

"When in either the "Calling" or "Proceeding" states, reception 
of a response with status code from 300-699 MUST cause the 
client transaction to transition to "Completed".The client 
transaction MUST pass the received response up to the TU, and 
the client transaction MUST generate an ACK request, even if the 
transport is reliable (guidelines for constructing the ACK from 
the response are given in Section 17.1.1.3) and then pass the 
ACK to the transport layer for transmission."

If the ACK request failed in this case, the client transaction 
SHOULD inform the TU the transport failure.

section 8.1.3.1 says that

"In some cases, the response returned by the transaction layer 
will   not be a SIP message, but rather a transaction layer 
error.  When a   timeout error is received from the transaction 
layer, it MUST be   treated as if a 408 (Request Timeout) status 
code has been received.   If a fatal transport error is reported 
by the transport layer   (generally, due to fatal ICMP errors in 
UDP or connection failures in   TCP), the condition MUST be 
treated as a 503 (Service Unavailable)   status code."

In this case, the TU must be treated as a 503 status code that 
it is based on section 8.1.3.1. But TU has already received 
300-699 response. Then, what should the TU do?

Thank you for your consideration.

-------------------
Marugami Sumiya
Alpha Systems, Inc.
-------------------

_______________________________________________
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