r. SIP: Understanding the Session Initiation Protocol SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK54532 To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=052500 From: E. Schroedinger <sip:schroed5244@aol.com>;tag=431341; Call-ID: 9@100.101.102.103 CSeq: 1 INVITE Contact: sip:werner.heisenberg@200.201.202.203 Content-Length: 0 Schroedinger acknowledges the response: ACK sip:werner.heisenberg@munich.de SIP/2.0 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK54532 Max-Forwards 70 To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=052500 From: E. Schroedinger <sip:schroed5244@aol.com>;tag=4313413 Call-ID: 19@100.101.102.103 CSeq: 1 ACK Content-Length: 0 Notice that the ACK request reuses the same branch ID as the INVITE and the 302 response. This is because an ACK to a non-2xx final response is considered to be part of the same transaction as the INVITE. Only an ACK sent in response to a 200 OK is considered a separate transaction with a unique branch ID. Also, an ACK to a non-2xx final response is a hop-by-hop response, not an end-to-end response as discussed in Section 3.6. This exchange completes this call attempt, SO a new INVITE is generated with a new Call - ID and sent directly to the location obtained from the Con- tact header field in the 302 response from the redirect server: INVITE sip:werner.heisenberg@200.201.202.201 SIP/2.0 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK92313 Max-Forwards: 70 To: Heisenberg <sip:werner.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>; Call-ID: 54-67-45-23-13 CSeq: 1 INVITE Subject: Where are you exactly? Contact: <sip:schroed5244@pc33.aol.com> Content-Type: application/sdp Content-Length: 159 o=schroed5244 2890844526 2890844526 IN IP4 100.101.102.103 s=Phone Call C=IN IP4 100.101.102.103 m=audio 49172 RTP/AVP 0 a=rtpmap: PCMU/8000 The call then proceeds in the same way as Figure 2.2, with the messages being identical. Note that in Figure 3.5, a 180 Ringing response is not sent; SIP Clients and Serv