tered URI is an internal one (private in the example in Figure 12.12), hence unusable to deliver messages to the UA. The next scenario features a single logical proxy/registrar function running on separate hosts, as shown in Figure 12.13; load balancing is ensured by the DNS alternatively resolving the proxy name to SIP proxy/registrar 1 and to SIP proxy/registrar 2. The UA establishes multiple flows with separate SIP proxy/registrars: this helps to ensure connectivity when one of the SIP proxy/registrars fails. For more details, please refer to [12]. The last scenario, depicted in Figure 12.14, encompasses edge proxies and a separate registrar. Edge proxies are between a UA and the registrar, while the latter that can access the SIP location service in order to retrieve the URI needed to forward a SIP message to the corresponding UA. In this scenario, the UA sends the REGISTER request to the registrar through an edge proxy that adds a Path field before forwarding it to the reg- istrar. By doing this, each out-of-dialog SIP request forwarded by the registrar © 2009 by Taylor & Francis Group, LLC NAT Traversal Logical proxy / registrar SIP proxy / SIP proxy / registrar 1 registrar 2 Private network FIGURE 12.13 A logical proxy/registrar function running on separate hosts. SIP proxy / registrar 2 proxy 1 proxy 2 Private network FIGURE 12.14 A scenario including edge proxies. to the UA will traverse the edge proxy1. The flow creation mechanism works between UA and the edge proxy as described before; but the edge proxy places an identifier value unique to the flow in the Path field of REGIS- TER request forwarded to the registrar. Such a value will be used by the edge proxy to map future requests to the correct flow. Keepalive messages are sent to the edge proxies. To ensure the correct delivery of mid-dialog SIP requests (e.g., messages like the BYE requests used to terminate an exist- ing session), the edge proxy will have to add a Record-Route header field to the dialog-forming request: in other words, the solutio