 is added to record the server's real IP address for future requests. Laura's UA receives the 200 OK response and builds a Route header that will be used in subsequent requests. The Route header is built from both the Record-Route and the Contact header present in the response. Because only one proxy needs to be in the signalling path, all the subsequent requests from Laura to Bob (ACK and BYE in this example) will be sent to it and will contain a Route header with Bob's Contact address. This way, the proxy knows to send the request to the address contained in the Route header. Several Proxies The previous example shows how Record-Route works to inform Laura's UA that subsequent requests have to be sent through the proxy rather than directly to Bob. However, it does not show why the Route header is needed. A scenario with more proxies can help explain the pur- pose of the Route. Figure 5-19 contains three proxies: P1, P2, and P3. P1 and P3 have to be in the signalling path, but P2 does not. We can see how the ACK from Laura to Bob contains a Route header telling P1 to forward the request to P3. The last address in the Route header is Bob's Contact address. SIP: Protocol Operation Note that Figure 5-19 does not contain the real format of Contact, Record-Route, and Route headers as Figure 5-18 did. Instead, it uses a sym- bolic format that just indicates which addresses are contained in each header. To The To header always contains the recipient of the request. It usually contains the public address of the destination party as well. It is important to make a distinction between the To header of a request and the Request- URI. The To header, which remains the same throughout the session, is intended for the remote UA. It cannot be changed by proxies. The Request-URI contains the address of the next hop in the signalling path and is therefore changed by every proxy in the path. Figure 5-20 illus- trates the use of each. Laura calls Bob using his public address, SIP:Bob.Johnson@company com. This SIP URL will be insert