user no longer needs to register with a home proxy server as was required by pre-call mobility [5]. After registering with the for- eign server, the user's handle-to-URI mapping remains fresh, allowing corre- spondent users to reach him simply by addressing his handle, as we will show in Section 10.3.3. 10.3.3 Routing After abstracting any domain binding from users and allowing seamless authen- tication and registration with local proxy servers, the next step is to permit the user to initiate and receive calls by addressing a particular handle with Handle Field type:index Value 10.200/fproxy HS_ADMIN:100 rwr:0.NA/10.200:300 HS_ADMIN:101 wr:10.200/fproxy:300 INET_HOST:240 x.y.z.w HS_PUBKEY:300 00BE00445 FIGURE 10.4 Sample proxy handle structure. C 2009 by Taylor & Francis Group, LLC SIP Mobility Technologies and the Use of Persistent Identifiers no explicit reference to domain bindings (URIs). In this sense, a SIP user can INVITE any other SIP user provided he knows the latter's handle. From the perspective of a user, all other users seem to belong to one local domain and abstraction is complete. It is extremely important to minimize the call setup time for the time- sensitive and interactive applications enabled by SIP. To explain how this is achieved, we will go through the steps where an arbitrary SIP user c_user (caller) tries to INVITE the roaming user ruser (callee) using the latter's handle 2118/r_user as shown in Figure 10.1. The call routing process, pre- sented in Figure 10.2c, proceeds as follows: 1. Caller c_user sends an INVITE request to ruser. The invite request reaches the caller's SIP proxy/registrar containing the following header fields: INVITE sip: 2118 r_user@somedomain SIP/2.0 To: <sip: 2118 r_user@somedomain> Note: In this message, the domain somedomain is irrelevant to our approach. We are only concerned with the handle part of the request- URI. To distinguish between handle and non-handle requests, we resort to the "/" character in the host name. 2. The proxy checks if the handle 2118 r us