SIP ACK

Overview

SIP ACK request 내용 정리.

Basic

The ACK method is used to acknowledge final responses to INVITE requests. Final responses to all other requests are never acknowledged. Final responses are defined as 2xx, 3xx, 4xx, 5xx, or 6xx class responses. The CSeq number is never incremented for an ACK, but the CSeq method is changed to ACK. This is so that a UAS can match the CSeq number of the ACK with the number of the corresponding INVITE.

An ACK may contain a application/sdp message body. This is permitted if the initial INVITE did not contain a SDP message body. If the INVITE contained an SDP offer message body, the ACK may not contain an SDP message body. The ACK may not be used to modify a media description that has already been sent in the initial INVITE; a re-INVITE or UPDATE must be used for this purpose. SDP in an ACK is used in some interworking scenarios with other protocols where the media characteristics may not be known when the initial INVITE is generated and sent.

For 2xx responses, the ACK is end-to-end, but for all other final responses, it is done on a hop-by-hop basis when stateful proxies are involved. As a result, a proxy will generate an ACK for a 3xx, 4xx, 5xx, or 6xx response to an INVITE, as well as forwarding the response. The end-to-end nature of ACKs to 2xx responses allows a message body to be transported. An ACK generated in a hop-by-hop acknowledgment will contain just a single Via header with the address of the proxy server generating the ACK. The difference between hop-by-hop acknowledgments and response end-to-end acknowledgments is shown in the message.