es from his handle handle as shown in Figure 10.3. 4. fproxy uses the Handle protocol [13] to resolve the handle 2118/r_user into the SIP_PWD field. The server then computes a message digest over the obtained credentials. 5. Authentication is granted if the two digests match. 6. After authenticating 2118/r_user, the foreign proxy fproxy proceeds to create an internal account for ruser to be able to use the SIP services © 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security on fproxy. The internal user account will have a username identical to the handle of the registering user with the " replaced by , i.e., 2118.r_user, in this case. 7. Registration of the user follows. This requires that fproxy modifies the handle 2118/r_user updating the field SIP URL to point to the internal account, 2118.r_user@x.y.z.z in this case, as shown in Figure 10.3. This means that ruser is currently associated with fproxy. Obviously, our modified authentication algorithm is domain-independent. In other words, the user's credentials are valid for all realms, provided the correct administrative privileges are set in the Handle System. This property is essen- tial, as it allows a particular authenticated SIP message to traverse multiple domains instead of requiring re-authentication for each domain on the path of the message. Since all communication between the proxy and the Handle System is secure [13], the proxy can be reasonably certain that the roaming user is indeed who he claims to be by validating his credentials against the secure handle. Internally, the proxy server monitors the user accounts created and removes an account (also updating the handle) due to unregister requests or account expiration. A sample handle for the foreign proxy is shown in Figure 10.4. Devices, whether hardphones and softphones, are treated similarly. This depends on the ability of the device owner to present the SIP proxy with a username (this could be the handle) and password for authentication. With this approach, a 