In short the purpose of ACK is not to acknowledge media exchange, rather it is majorly intended to indicate that the SIP dialog has either established or the transaction is completed. It additionally can do many other things which probably you are aware of. ACK sent for OK during dialog establishment and after that are handled similarly. For that matter, ACK sent for 3, 4, 5, 6XX response prior to dialog establishment and after it are also treated similarly.
Not doing so would require a lot of profiling and that would make the protocol more complex. Passion sip: That would be because an error response can be generated by any ua in the network and all error responses are treated hop by hop.
ACK for a OK is treated as separate transaction, Just becuase both the end point now know each other well with the contact address in OK. So ACK goes end — to — end creating a new transaction. ACK for any other final response is not treated as a separate transacation, Why?. Although 2xx, 3xx, 4xx , 5xx and 6xx all are categorized as final responses, still the 2xx responses for an Invite are special.
It is not a mandate to exchange ACK a thought of means of being doubly sure to activate media. For instance, while in early dialog in-band and out of band media is exchanged. This very operation of establishing a media session is equally prioritized at both the two ends. Like the rules at the Originating end, there could be local policies like call forward all calls, redirect, temporarily moved, permanently moved, try after some time, etc… through which alternate possible targets could be made aware and a possible dialog media exchange could be established.
Hi Abhishek, I am not sure if i got your message clearly. When failure response is traversring through a proxy chain, each proxy sends ACK back to the previous node without waiting for reception of ACK from previous node.
It does not signify that UAC has received the 4xx. In case of an error response, the Invite transaction is a true three way handshake between two endpoints, and the delivery of 4xx is promised via the same three way handshake at each hop.
Each end points know each others contact addresses so they can exchange messages directly, so the previous transaction[ OK] is destroyed and ACK is sent as seperate transaction. Refer section Upon each expiry of timer G the will be re-transmitted until timer H expires or Timer G is exhausted.
In case ACK which was lost is received before any of the two timers run out of time, the re-transmission of OK would seize and the call would go on as usual. However if ACK never gets delivered then the call would be terminated. If you find any better recommendation or explanation please share. The next logical question is if ACK is really a separate transaction then why does it not have a response? Well, for once it is not required, because if ACK is not received by the UAS it will retransmit the 2xx response, note that this is true for any transport even reliable, as it ensures that the offer answer exchange is completed end to end.
You may have worked with RFC which introduces the reliable provisional responses. Coming back to ACK to a 2xx response — This is really a special transaction unlike any other; in fact in creation and sending of this the transaction machinery is hardly involved. Remember branch parameter is required to identify a transaction. The next question to ask is - if there are no real transactions involved then why bother with a branch parameter? The reason is that even though there is no transaction involved and the ACK to 2xx passes through the transaction layer at the UAS like any other request, only when no matching transaction is found is it handed over to TU.
While at the UAC it is just a message with a new branch identifier which make it sound like a transaction but does not need to pass through the transaction layer. In fact it is directly passed to transport by TU and retransmitted when the TU gets a 2xx retransmission. You are commenting using your Google account. You are commenting using your Twitter account. You are commenting using your Facebook account. Notify me of new comments via email. Notify me of new posts via email.
This site uses Akismet to reduce spam. Learn how your comment data is processed. Proxy call flow Pic But when non-2xx response is received, its considered to be part of same transaction. Why is that? Any unauthorised distribution or copying is strictly prohibited.
0コメント