 <sip:info@hypotenuse.org>;tag=63104 From: <sip:pythag42@hotmail.com>;tag=9341123 Call-ID: 34283291273@port443.hotmail.com Table 4.3 Mandatory Headers in a REGISTER Request Call-ID Max-Forwards SIP Request Messages CSeq: 47 BYE Content-Length: 0 The mandatory headers in a BYE request are shown in Table 4.4. 4.1.4 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 an application/sdp message body. This is permitted if the initial INVITE did not contain a SDP message body. If the INVITE contained a message body, the ACK may not contain a 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 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. An example of this is described in Section 10.6. 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. 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 differ- ence between hop-by-hop acknowledgments to a response end-to-end acknowl- edgments is shown in the message fragments of Figure 4.2. A hop-by-hop ACK reuses the same branch ID as the INVITE since it is considered part of the same transaction. An end-to-end ACK uses a different branch ID as it is considered a new transaction. Table 4.4 Mandatory Headers in a BYE Requ