SIP ACK request re-transmission on transport error

Question

This question is regarding the ACK request in SIP (Session Initiation Protocol). Quoting RFC-3261 - 18.1.1 Sending Requests

If an element sends a request over TCP because of these message size
constraints, and that request would have otherwise been sent over
UDP, if the attempt to establish the connection generates either an
ICMP Protocol Not Supported, or results in a TCP reset, the element
SHOULD retry the request, using UDP.

This looks OK for the INVITE and other non-invite request except ACK. Below are the points why i think the above statement may not be applicable for ACK.

1. ACK is just a request and not transaction. So the SIP transaction State Machine must not be applicable for ACK request. Since State Machine is the only place which talks about the retransmission, So the 18.1.1 is not applicable for ACK request. Quoting 3261 - "17.1 Client Transaction" - in favour for above argument.

   There are two types of client transaction state machines, depending
   on the method of the request passed by the TU. One handles client
   transactions for INVITE requests. This type of machine is referred
   to as an INVITE client transaction. Another type handles client
   transactions for all requests except INVITE and ACK. This is
   referred to as a non-INVITE client transaction. There is no client
   transaction for ACK. If the TU wishes to send an ACK, it passes one
   directly to the transport layer for transmission.
   

2. ACK can be re-transmissted only if next B-party retransmits the final response.

Q:- Is my assumption correct that SIP ACK request can not be retransmitted on receiving the transport error (such as connection error, ICMP error)?

Quoting 3261 - "17.1 Client Transaction" -

If the TU wishes to send an ACK, it passes one
directly to the transport layer for transmission.

Q:- What does TU wishes mean? Does it mean that TU can send any time it wish OR it means whenever final response come then only TU sends?

Regards, Sudhansu

Answer 1

1) Let's go back to basic stuff

"If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP."

My comments :- "SHOULD retry the request" --> It says SHOULD retry not MUST retry request. So this is not mandatory at all to send ACK request.

2)

Q:- Is my assumption correct that SIP ACK request can not be retransmitted on receiving the transport error (such as connection error, ICMP error)?

Quoting 3261 - "17.1 Client Transaction" -

If the TU wishes to send an ACK, it passes one directly to the transport layer for transmission.

comments :- This clearly states if TU ( Transaction user ) wishes to {not must} pass ACK request to transport layer for tranmission.

So as per statement, it's application wish that don't do anything once you pass that to ACK to transport layer. OR if on another side if application wants if there any TCP error (ICMP) then it can retransmit same ACK request over UDP.

See RFC will never exclude ACK from this, it is application responsibility & how it is implemented. Also please can also ask question at Sip-implementors mailing list. You will get more like minded people.

Answer 2

First some clarifications. From [RFC3261 Section 6][1]:

SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction

So an ACK to a non-2xx is part of the same transaction as the INVITE, any 1xx responses and the final response. In particular it has the same CSeq and the same branch tag. ACKs to non-2xx responses are hop-by-hop.

An ACK to a 2xx is a new transaction (although this is a special ACK transaction, and there are no responses). It has the same CSeq, but a different branch tag. ACKs to 2xx responses go all the way from the client to the server.

On your specific point, section 17 is about the transaction Layer. Here ACKs are only ever re-transmitted in response to a re-transmitted final response. When the Transaction Layer decides it needs to send an ACK, it sends it to the Transport Layer, and it is the Transport Layers job to deliver it.

Section 18 is about the Transport Layer. An ICMP error or a TCP reset are Transport Layer errors, they are not covered by the SIP transaction model. If the Transport Layer needs to promote a message from UDP to TCP, or to fall-back from TCP to UDP, that is separate from the Transaction Layers model. In fact, if the TCP socket cannot be established, the ACK has not been transmitted yet. In this case the Transport Layer isn't retransmitting it, it is attempting to transmit it for the first time, by a different protocol.

In practise, this case is going to be rare. For the size of the ACK to be a problem for UDP, it has to be larger then both the INVITE and the final response - these have already succeeded via UDP. In the usual case the INVITE and final response contain an SDP body; in every success case the 2xx contains a body. The only case where the ACK is going to be larger is if there was no SDP in the INVITE and the ACK adds to the headers or body.

If you hit this case - TCP not supported and ACKs too big for UDP, you may be heading for failure anyway. [1]: https://www.rfc-editor.org/rfc/rfc3261#section-6