er is a locally registered user. If not, the server resolves the handle into the SIP URL field, which is 2118.r_user@x.y.z.z in this case, as shown in Figure 10.3. 3. The server then rewrites the target URI of the message to the resolved URI. 4. From this point on, the natural SIP call flow is leveraged and the tra- ditional SIP architecture [1] is utilized for efficient call routing. Note that other proxy servers on the call path treat the request as a normal request, i.e., no handle resolution is required. Again, with our approach, correspondent users trying to communicate with the mobile user need not go through a home proxy for session setup or redi- rection. This renders the call route more efficient, eliminating unnecessary overhead and significant round-trip times. One last point worth mentioning is the ability of a user to register with multiple servers from different devices simultaneously using the same handle. In our implementation, the SIP URL field of a particular handle can contain a list of bindings (URIs) to enable this attractive property. Exploiting this property is left for future papers. § Since Internet hostnames can not contain the "/" character [13] ascii (0 X 2F) (essential character in the handle Namespace [35]), we replaced it with the " ascii (0x7E) character in the examples above for implementation purposes. We also allow the "#" ascii (0 X 23) character for compatibility with hard IP phones. © 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security 10.3.4 User-Controlled Mobility Our mobility scheme is user-controlled in the sense that the user is responsi- ble for the administration of his SIP identifier now that the latter is domain-independent. Consequently, routing the user's calls through a local server simply requires the user to add the server's persistent identifier (han- dle to her persistent identifier's admin list. This indicates that the user trusts the local server to route her calls. The other aspect of user control is the distributed servi