r, Laura clicks the button that says Call Bob. Her UA first tries Bob's public address, but the domain company.com has a SIP redirect server handling incoming invitations. Instead, Laura's UA contacts this redirect server. The re-direct server knows that Bob can be located at SIP:Bob@131.160.1.112 when he is working at his office or at SIP:Bob@uni- versity.com when he is writing his dissertation. Thus, the redirect server will recommend that Laura's UA try SIP:Bob@131.160.1.112 and SIP:Bob@university.com rather than SIP:Bob.Johnson@company.com. The redirect server also has the capacity to prioritize and can tell Laura's UA that Bob is most likely to be reached at school rather than at work. After being informed, Laura's UA tries Bob on both recommended SIP addresses. Note that a redirect server does not always return the address of the UA where the user actually is; it may just as easily return the address of another server with more knowledge about Bob's location instead (Figure 4-10). This example shows that a redirect server does not initiate any actions to locate a user, but merely returns a list of possible locations where the user might be. The UA makes all of the attempts to locate the user. In this example, it is Laura's UA trying all possible locations until it finds Bob; this is the main difference between a redirect server and a proxy server. Proxy servers make subsequent attempts for the user rather than sending new contact information to the user. Group Addresses Redirect servers can also be used to implement group addresses. To see how this works, assume that the public address for Com- pany A's support department is SIP:support@company.com. Because this department has to give support around the clock, several people are always at work. Bob works from 8:00 A.M. until 4:00 P.M., Peter works from 4:00 P.M. until midnight, and Mary works from midnight until 8:00 A.M.. The redirect server at company.com is able to return different addresses depending on the time of the day SO that if it receives a call 