Surrogate Registration
The Oracle® Enterprise Session Border Controller surrogate registration feature lets the Oracle® Enterprise Session Border Controller explicitly register on behalf of a Internet Protocol Private Branch Exchange (IP-PBX). After you configure a surrogate agent, the Oracle® Enterprise Session Border Controller periodically generates a REGISTER request and authenticates itself using a locally configured username and password, with the Oracle® Enterprise Session Border Controller as the contact address. Surrogate registration also manages the routing of class from the IP-PBX to the core and from the core to the IP-PBX.
Registration
The Oracle® Enterprise Session Border Controller uses the configuration information of the surrogate agent that corresponds to a specific IP-PBX. After the surrogate agents are loaded, the Oracle® Enterprise Session Border Controller starts sending the REGISTER requests on their behalf. (You can configure how many requests are sent.)
The SIP surrogate agent supports the ability to cache authorization or proxy-authorization header values from a REGISTER 401, 407, and 200 OK messages and reuse it in subsequent requests, such as in an INVITE. This allows the Oracle Communications Session Delivery Manager to support authorization of subsequent requests in cases such as, when a customer PBX doesn't support registration and authentication. It also supports the generation of authorization/proxy-authorization header if subsequent requests get challenged with a 401/407 response.
If the Oracle® Enterprise Session Border Controller receives 401 or 407 responses to REGISTER, requests, it will use the Message Digest algorithm 5 (MD5) digest authentication to generate the authentication information. You need to specify the password. The Oracle® Enterprise Session Border Controller also supports authentication challenge responses with the quality of protection code set to auth (qop=auth), by supporting the client nonce (cnonce) and nonce count parameters.
The Oracle® Enterprise Session Border Controller creates a registration cache entry for each of the AoRs for which it is sending the REGISTER requests. When the Oracle® Enterprise Session Border Controller receives the associated URIs, it checks whether the customer host parameter is configured. If it is configured, the Oracle® Enterprise Session Border Controller changes the host in the received Associated-URI to the customer host. If it is not configured, the Oracle® Enterprise Session Border Controller does not change the Associated-URI. It makes the registration cache entries that correspond to each of the Associated-URIs. The From header in the INVITE for calls coming from the IP-PBX should have one of the Associated-URIs (URI for a specific phone). If the Oracle® Enterprise Session Border Controller receives a Service-Route in the 200 (OK) response, it stores that as well.
The Oracle® Enterprise Session Border Controller uses the expire value configured for the REGISTER requests. When it receives a different expire value in the 200 OK response to the registration, it stores the value and continues sending the REGISTER requests once half the expiry time has elapsed.
REGISTER requests are routed to the registrar based on the configuration. The Oracle® Enterprise Session Border Controller can use the local policy, registrar host and the SIP configuration’s registrar port for routing.
If the Oracle® Enterprise Session Border Controller is generating more than one register on behalf of the IP-PBX, the user part of the AoR is incremented by 1 and the register contact-user parameter will also be incremented by 1. For example, if you configure the register-user parameter as caller, the Oracle® Enterprise Session Border Controller uses caller, caller1, caller2 and so on as the AoR user.
Routing Calls from the IP-PBX
The Oracle® Enterprise Session Border Controller (E-SBC) looks for a match in the registration cache based on the From header or the P-Preferred-Identity header. The header should contain the user portion of one of the Associated-URIs that it received from the registrar in the 200 (OK) responses to REGISTER requests. It should also have the same hostname that is configured in the customer-host parameter. If that parameter is not configured, then the hostname should be same as the one configured for the register-host parameter.
After the corresponding registration Service-Router entry is found, the E-SBC uses the Service-Route for this endpoint to route the call, if it exists. If no Service-Route exists but the SIP interface’s route-to-registrar parameter is enabled, the E-SBC tries to route this to the registrar. You can configure the surrogate agent to override the SIP interface’s route-to-register setting. If the surrogate agent’s route-to-register parameter is set to disable, it takes precedence over the SIP interface’s setting. The E-SBC will not try to route the call to the registrar.
Configure Surrogate Registration
Surrogate registration allows the Oracle® Enterprise Session Border Controller (E-SBC) to explicitly register on behalf of an Internet Protocol Private Branch Exchange (IP-PBX). Surrogate registration also manages the routing of calls from the IP-PBX and from the core to the IP-PBX. The E-SBC uses the configuration information of the surrogate agent that corresponds to a specific IP-PBX to send REGISTER requests. You can configure the number of requests to send.
Set the system to Super User mode.
Configure a surrogate agent for each IP-PBX proxy that you want the E-SBC to register.
Note:
To view all surrogate agent configuration parameters, enter a ? at the surrogate-agent prompt.You must add the surrogate agent as a session-agent under session-router.
Example
The following example shows the surrogate agent configuration.
surrogate-agent
register-host acmepacket.com
register-user 234567
state enabled
realm-id public
description
customer-host acmepacket.com
customer-next-hop 111.222.333.444
register-contact-host 111.222.5.678
register-contact-user eng
password
register-expires 600000
replace-contact disabled
route-to-registrar enabled
aor-count 1
options
auth-user
last-modified-date 2006-05-04 16:01:35