I am just curious, what is the fundamental reason to have 200 OK responses from a remote end point to be ACKed by the local end point? RFC 3261 states that it is needed for stability purposes but does not go into details. The only reason that comes to my head is the case with call forking. So, if an AOR is registered at multiple end points and these end points respond simultaneously with a 200 OK message, then an ACK will actually indicate which of the remote parties will participate in a peer-to-peer connection. Is there any other reason to end and INVITE hand shake with an ACK?
It's because SIP needs some responses (only INVITE responses in practise) to be reliably transmitted in situations where the underlying transport is unreliable, such as with UDP.
The ACK request is the way for the (UAC User Agent Client) to let the UAS (User Agent Server) know that it received the final response to an INVITE request. Without employing something like the ACK request there would always be the risk that the UAS response would not get through to the UAC and the call would be left sitting in an incorrect state.
The ACK request doesn't have any specific role in call forking. In the case you've described in a call with multiple end points BYE requests will be sent to any call legs that are not required. ACK requests still need to be sent to any UAS that responds irrespective of whether the UAC wants that call leg to proceed or not.
Related
Good day All,
I understand that when I send a SIP INVITE and do not receive a 200 OK, it will keep sending INVITES at regular duration (until sip timeout).
However, If I have received a 100 Trying for the 1st INVITE and no 200 OK (still waiting for it), then will SIP Server send INVITEs as above regular duration?
Or no matter reliable/unreliable(1xx messages), since SIP Server has got a response it will just sit and wait for the 200 OK?
RFC3261 just talks about series of INVITEs sent due to no "200 OK" received from destination.
Please help to understand.
After receiving a provisional response (1xx), retransmissions of the INVITE message will end.
The relevant part from RFC3261 is in bold:
17.1.1.1 Overview of INVITE Transaction
The INVITE transaction consists of a three-way handshake. The client
transaction sends an INVITE, the server transaction sends responses,
and the client transaction sends an ACK. For unreliable transports
(such as UDP), the client transaction retransmits requests at an
interval that starts at T1 seconds and doubles after every
retransmission. T1 is an estimate of the round-trip time (RTT), and
it defaults to 500 ms. Nearly all of the transaction timers
described here scale with T1, and changing T1 adjusts their values.
The request is not retransmitted over reliable transports. After
receiving a 1xx response, any retransmissions cease altogether, and
the client waits for further responses. The server transaction can
send additional 1xx responses, which are not transmitted reliably by
the server transaction. Eventually, the server transaction decides
to send a final response. For unreliable transports, that response
is retransmitted periodically, and for reliable transports, it is
sent once. For each final response that is received at the client
transaction, the client transaction sends an ACK, the purpose of
which is to quench retransmissions of the response.
"What will happen in SIP if both parties send INVITE to each other at same time"
What will be the behavior in the above case?
Which call will Process?
The received first INV may be proceed to establish the call by the SIP Proxy, whereas the received second INV maybe rejected by a 4xx response. But since SIP is session based it is also possible that the Proxy can establish both calls. But one call should be in hold state. Only one call will ve active.
The most likely behaviour is that the SIP user agents would display a new incoming call.
Since they would also both have an outgoing call in progress it would be up to the user as to whether they would answer the incoming call or ignore it and persist with their original outgoing call.
The crucial point is that the two INVITE requests are independent. It would be the same as if two people called each other on their mobile phones simultaneously.
RFC 3261 section 14.2 says
A UAS that receives an INVITE on a dialog while an INVITE it had sent
on that dialog is in progress MUST return a 491 (Request Pending)
response to the received INVITE.
So, I think both the parties will generate 491 response to each other. But I am still not sure as both of these INVITE will be part of different dialogs and standard mentions on the same dialog.
According to sip protocol when first invite send, sip returns proxy authentication required message (if there are any proxy server available), then client send an acknowledge message. But what happen if the acknowledge message failed to reach the sip server? Server returns forbidden after sometimes and ignore all new invite with authentication header. Also when sip gets multiple acknowledge message it's immediately send forbidden.
If your question is what would the correct behaviour be for a SIP server that has issued a 407 and not received an ACK for it, please see RFC 3261 17.2.1 for the description of the INVITE server transaction.
Sending the 407 moves the state machine into the "Completed" state, at which point the G and H timers have to be be set. When G fires, the 407 response needs to be retransmitted. And if all the ACK messages get lost, then timer H will make the server transaction give up eventually. But if the second ACK reaches the server then that's it. You will have seen two 407 responses, one with a lost ACK, the second one with a successful ACK.
The handling of the subsequent INVITE with the credentials should be entirely independent with the previously described process. The INVITE message with the credentials will constitute a separate dialogue forming transaction.
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?
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.
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.
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.
i am receiving multiple 2** responses for a call. The problem is that once the call is connected and the server receives the "ACK" packet and the call starts successsfully, server again sends the "OK" response packet back to the callee and recieves the "ACK" packet again for it. This happens multiple times before the call gets terminated automatically. Can somebody explain to me why this is happening that my server is sending the "OK" response even after the call is connected successfully and what can be the possible solution for the problem? Thanks in advance for any help.
A SIP UAS will retransmit the 2xx response multiple times until it receives the ACK request from the UAC. See the SIP RFC chapter "13.3 UAS Processing" for the gory details.
Most often this sort of problem happens when the ACK sent by the UAC is invalid and thus prevents the UAS from matching it to the INVITE transaction. ACK requests have special rules about their construction see 13.2.2.4 2xx Responses. To make things even more difficult the construction of the ACK request differs for 2xx and non-2xx final responses.