Why is 200 OK retransmission handled by UAS in SIP Protocol?

Question

Initially I was looking for an answer to why ACKs to 2xx responses form a separate SIP Transaction, while ACKs to non 2xx responses don't. Google gave me this:

"When the UAC receives 200 OK, the client transaction is destroyed at TL.

This is done because, the TL is unaware of the above core. The above core can be a Proxy or an UAC core.

In case of proxy, the 200 OK is forwarded whereas in case of UAC, an ACK is generated. Now this ACK has to create a new transaction (transaction created by INVITE had been destroyed)at TL for its transmission, hence the ACK for 200 OK is outside the INVITE transaction.

For other non-2xx final responses, the client transaction at TL is not destroyed and the ACK is generated by TL.

Hence in this case, the ACK is within the transaction."

http://sipforum.org/pipermail/discussion/2011-June/008499.html

Now my next question was why is the client transaction destroyed at TL upon reception of 200 Ok. Is it because ACKs are sent directly to UAS without passing intermediate proxies? (so proxies will never know if the INVITE transaction is actually completed).

Another possibly related issue I am having is that I don't understand why retransmission of 200 OK is done end-by-end. Is there a reason why retransmission is not done in hop-by-hop manner?

Answer 1

The philosophical answer as to why SIP uses different ACK mechanisms is to discreetly torture anyone foolish enough to dig into the bowels of the SIP standard.

Why is 200 OK retransmission handled by UAS?

The answer is detailed in the SIP RFC Chapter 17 Transactions (which is also referenced in the sipforum link your provided).

The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction.

Putting it another way the SIP designers were worried about the reliability of 2xx responses being delivered over UDP so they decided sending an ACK request from the client (UAC) to the server (UAS) was a good way to implement retransmissions.

I've never really understood why SIP couldn't just use the same mechanism for 2xx and non-2xx ACK's. It would make the job of implementors easier.

Now my next question was why is the client transaction destroyed at TL upon reception of 200 Ok. Is it because ACKs are sent directly to UAS without passing intermediate proxies?

If the INVITE request traversed a SIP proxy or proxies then it's likely that the ACK request will traverse the same proxies (a 2xx response can change the proxies used in subsequent requests within the same SIP dialog so in theory the ACK could traverse different proxies). So no the ACK request handling at the client (UAC) is not designed to handle requests travelling different SIP routes.

Another possibly related issue I am having is that I don't understand why retransmission of 200 OK is done end-by-end. Is there a reason why retransmission is not done in hop-by-hop manner?

Because the SIP standard mandates that the responsibility for INVITE response retransmissions is handled by the UAS. A stateless SIP proxy does not have UAS capabilities, it simply passes any requests or responses it receives through to the next SIP agent.

However just to confuse things, a stateful SIP Proxy or a B2BUA may very well implement UAS functionality and in those cases the retransmission will occur on a hop-by-hop basis although in that case each INVITE transaction is between the UAC and the UAS in the Proxy or B2BUA rather than a UAS in the destination SIP client.

Answer 2

Tried to explain the same in the following link https://abhishekchattopadhyay.wordpress.com/2010/09/21/why-ack-is-a-separate-transaction-for-invite-with-a-successful-200-ok%C2%A0response%C2%A0/

As such the question "why ack is a separate transaction in case of a 200 OK" is not a question at all. This is already explained in 3261. 200 OK (for that matter any final response) is supposed to end the transaction. And so new request would be a new transaction. no surprises!!

the real and uncomfortable question is why is ACK part of the invite transaction if the response is anything but a 200 OK. Read the above link the reason is put down there.

Thanks.

Answer 3

Why is 200 OK retransmission handled by UAS?

The answer in clear for me in RFC 3261 page 128:

"The handling of this response depends on whether the TU is a proxy core or a UAC core. A UAC core will handle generation of the ACK for this response, while a proxy core will always forward the 200 (OK) upstream. The differing treatment of 200 (OK) between proxy and UAC is the reason that handling of it does not take place in the transaction layer."

I also think this question for a while and it's clear for me when I think about proxy in the communication path. As we know, non-2xx response take place in the transaction layer. The transaction layer on proxy will response a ACK for the non-2xx response. Also the transaction layer will resend ACK when receive non-2xx again.

Let's suppose, if 200 OK take place in the transaction layer. The proxy transaction layer will response a ACK. The session will be created on UAS. This is no problem if 200 OK can reach to UAC finally. But, that's not the result we wanted as 200 OK may not reach UAC for some other reason.