Proxy Registrar

WARNING:

The proxy registrar feature has been deprecated in release 8.0.

The Converged Application Server Proxy Registrar implements the proxy and registrar functions described in RFC 3261. The Proxy Registrar combines the functionality of a SIP proxy server and registrar. Its main tasks include registering subscribers, looking up subscriber locations, and proxying requests onward. The Proxy Registrar is an optional component.

The Proxy Registrar's registrar function processes the REGISTER requests from user agent clients (UACs) and uses a location service to store a binding (that is, an association) between a user's address of record (AOR) and one or more contact addresses, typically the IP addresses of the UACs. The To header field of the REGISTER SIP message sent by a UA contains the address of record whose registration is to be created, queried, or modified and the CONTACT header field contains the corresponding contact addresses. The bindings between the AOR and the contact addresses are persistently stored in a database.

Figure 3-2 Registration Flow

The UAC registers its location with the Registrar, which sends the location to a location service, which stores the binding in a database.

Upon receiving requests to the AOR, the proxy function locates the mapped URIs through a Location Service lookup and then proxies the request using the location information retrieved by this lookup.

Figure 3-3 illustrates a simplified view of the interaction between UAs when a subscriber, Alice, calls another subscriber, Bob, who is located in the same domain.

Figure 3-3 Interaction of UA Elements During a Call

Bob may be registered from multiple user agents, such as personal phone, work phone, and computer. In this case, the query for Bob's location will return multiple bindings to the Proxy. The Proxy will then fork the call, either in parallel or sequentially, to the user agents that Bob is logged in to.

The Proxy is capable of proxying not only INVITE request, but other non-REGISTER requests such as MESSAGE, PUBLISH, SUBSCRIBE and so on.

When a caller and callee are in the same domain, the callee's location can be obtained by the outgoing proxy through the location service. A simplified example of the call flow for this scenario is shown in Figure 3-4. Note that this example does not include 100 Trying and 180 Ringing responses.

Figure 3-4 Call Establishment Flow Between Subscribers in a Single Domain

Alice sends an INVITE to the proxy in the example.com domain. The proxy queries Bob's location and forwards the INVITE to Bob, which responds with a 200 OK message to the proxy. The proxy forwards the 200 OK message to Alice, which sends and ACK directly to Bob, at which time Alice and Bob's UAs can communicate directly.

After the call is established, Alice and Bob's UAs can communicate directly, without using the Proxy. However, you can configure to route all subsequent traffic through the Proxy as well. This is the default and is useful if you want the ability to add additional services during the session.

If the caller and callee are in different domains, the outgoing proxy forwards the INVITE request to the callee's domain. The incoming proxy in the callee's domain performs the lookup and returns the callee's location, as illustrated in Figure 3-5.

Figure 3-5 Example of a Call Flow Between Two Domains

The Proxy can use ENUM lookup to resolve TEL URLs. The backend for the ENUM service is a DNS, which stores a mapping between TEL URLs and SIP URIs.

You configure the Proxy Registrar primarily through the Administration Console. You configure authentication for the Proxy Registrar by editing the sip.xml deployment descriptor packaged in the Proxy Registrar application. You can also edit advanced parameters by using the WebLogic Scripting Tool.