tion is abstracted through the use of globally unique and persistent identifiers called handles, which are part of the Handle System [10-13]. The Handle System is a distributed system extensively used as an indirection layer for the management of persistent Identifiers. Using the Handle System as an intermediate layer on top of multiple distributed SIP implementations allows us to implement seamless multi-domain authentication and call routing. 10.2 SIP Inter-Domain Mobility 10.2.1 Sessions and Mobility To clarify the SIP inter-domain mobility problem, we will present a simple example. Recall that SIP defines a user as an entity that associates with a C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security Home domain: hdomain SIP proxy/registrar (2118/hproxy) Handle system INTERNET REGISTER User: r_user correspondent Handle : 2118/r_user) SIP proxy/registrar (c_user) SIP proxy/registrar Foreign domain: cdomain (10.200/fproxy) Foreign domain: fdomain Traditional traffic flow Proposed traffic flow FIGURE 10.1 A reference inter-domain roaming scenario. particular domain. Figure 10.1 depicts a simple scenario of a roaming user r_user who has a valid association with his home domain hdomain but is currently present in a foreign domain fdomain. SIP signaling traffic originating from (REGISTER) or terminating at (arrows 1,2,3: arbitrary SIP user trying to INVITE the roaming user) ruuser must inefficiently pass through his home proxy server. Figure 10.1 identifies this traffic as traditional traffic flow. There are several ways in which roaming issues can be addressed, depending on whether the SIP architecture is roaming-unaware or modified to become roaming-aware. We study these issues and we present our approach by showing a typical flow for INVITE and REGISTER requests. We also compare the different approaches and illustrate the different scenarios in Figure 10.2. A more elaborate description of these scenarios is presented in Section 10.4. The first scenario shows how SIP naturally h