broxy.munich. de to the port number listed in the Via header field: 5060, in this case. Notice that the To header field now has a tag added to it to identify this particular dialog. Only the first Via header field contains a received parameter, since the second Via header already contains the literal IP address in the URI. The Contact header field contains the device URI of Heisenberg. The proxy receives the response, checks that the first Via header field has its own address (proxy.munich.de), uses the transaction identifier in the Introduction to SIP Via header, then removes that Via header field, then forwards the response to the address in the next Via header field: IP address 100.101.102.103, port 5060. The resulting response sent by the proxy to Schroedinger is: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a To: Heisenberg <sip:werner.heisenberg@munich.de>;tag= From: E. Schroedinger<sip:schroed5244@aol.com>;tag=42 Call-ID: 10@100.101.102.103 CSeq: 1 INVITE Contact: k<sip:werner.heisenberg@200.201.202.203 Content-Length: 0 The use of Via header fields in routing and forwarding SIP messages reduces complexity in message forwarding. The request required a database lookup by the proxy to be routed. The response requires no lookup because the routing is imbedded in the message in the Via header fields. Also, this ensures that responses route back through the same set of proxies as the request. The call is accepted by Heisenberg, who sends a 200 OK response: SIP/2.0 200 OK Via: SIP/2.0/UDP roxy.munich.de:5060;branch=z9hG4bK83842.1 eived=100.101.102.105 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17a To: Heisenberg ip:werner.heisenberg@munich.de>;tag=314159 From: E. Schroedinger <sip:schroed5244@aol.com>;tag=4: Call-ID: 10@100.101.102.103 CSeq: 1 INVITE Contact: sip:werner.heisenberg@200.201.202.203> Content-Type: application/sdp Content-Length: 159 o=heisenberg 2890844526 2890844526 IN IP4 200.201.202.203 s=Phone Call C=IN IP4 200.201.202.203 m=audio 49172 RTP/AVP 0 a=rtpm