obility in which the actual route set (set of SIP proxies that the SIP messages must traverse) must change, a re-INVITE cannot be used. For example, if a proxy is necessary for NAT/firewall traversal, then more than just the Contact URI must be changed-a new dialog must be created. The solution to this is to send a new INVITE (which creates a new dialog and a new route set including the new set of proxies) with a Replaces header (Section 6.2.23), which identifies the existing session. The call flow is shown in Figure 9.4. It is similar to that in Figure 9.3 except that a BYE is automatically generated to terminate the existing dialog when the INVITE with the Replaces is accepted. In this scenario, the existing dialog between Bowditch and Laplace includes the old visited proxy server (this proxy Record-Routed during the initial INVITE). The new dialog using the new wireless network requires the inclusion of the new visited proxy server. As a result, an INVITE with Replaces is sent by Bowditch, which creates a new dialog that includes the new visited proxy server (which Record-Routes) but not the old visited proxy server. When Laplace accepts the INVITE, a BYE is automatically sent to terminate the old dialog that routes through the old visited proxy server that is Wireless and 3GPP New visited Old visited Bowditch registrar/ registrar/ Laplace proxy proxy Media session DHCP Request DHCP ACK REGISTER 200 OK INVITE (Replaces) INVITE (Replaces) 200 OK 200 OK 200 OK 200 OK New media session Figure 9.4 Midcall mobility using INVITE with Replaces. now no longer involved in the session. The resulting media session is established using Bowditch's new IP address from the SDP in the INVITE. Services in SIP can be provided in either proxies or in user agents. If the service is resident in the user agent, then there are no service mobility problems as the user moves around. However, combining service mobility and personal mobility can be challenging unless each of the user's devices are identically con- figured with the same 