Surrogate Registration

The Oracle Communications Session Border Controller surrogate registration feature lets the Oracle Communications Session Border Controller explicitly register on behalf of a Internet Protocol Private Branch Exchange (IP-PBX). After you configure a surrogate agent, the Oracle Communications Session Border Controller periodically generates a REGISTER request and authenticates itself using a locally configured username and password, with the Oracle Communications 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.

Integrating with IMS

With surrogate registration, the Oracle Communications Session Border Controller (OCSBC) lets IP-PBXes integrate with the IP Multimedia Subsystem (IMS) architecture. The IP-PBX registers itself as if it were user equipment (UE), which triggers the implicit registration of all phone numbers associated with the IP-PBX.

Implicit registration means the explicit registration of one address of record (AoR) triggers the implicit registration of all the other AoRs associated with that UE. The implicitly registered AoRs are passed back to the UE as P-Associated-URIs in the registration’s 200 (OK).

IMS assumes that each SIP endpoint can register itself with its Serving-CSCF (S-CSCF). However, phones can be connected to SIP Integrated Access Devices (IADs) or SIP or H.323 IP-PBXes. The OCSBC performs SIP registration on behalf of the IP-PBX and IADs.

Depicts the OCSBC performing surrogate registration for an IMS core.

The OCSBC registers on behalf of the IP-PBXes and then stores the associated URIs returned by the Serving Call Session Control Function (S-CSCF). The calls from the phones behind the IP-PBX can be routed based on the cache entry the OCSBC creates after it receives each phone’s associated URI. Calls are routed using the service route, local policy or any other routing mechanism based on the associated session agent or session agent group. The OCSBC also supports multiple registrations on behalf of a IP-PBX because the IP-PBX can support thousands of phones, but the registrar might only be able to send 10 to 20 associated URIs in response to a single registration.

The OCSBC replaces the Contact URI for requests from the IP-PBX to the core to match the registered value. For calls from the IMS core to the IP-PBX, the OCSBC replaces the Request-URI username with P-Called-Party-ID/To-URI username. The IMS cores sends INVITES for the phones behind the IP-PBX with the registered Contact URI as the Request-URI instead of the AoR of the phones. The IP-PBX needs to see the phone’s AoR in the Request-URI.

Registration

The Oracle Communications 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 Communications 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 Communications 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 Communications 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 Communications Session Border Controller creates a registration cache entry for each of the AoRs for which it is sending the REGISTER requests. When the Oracle Communications Session Border Controller receives the associated URIs, it checks whether the customer host parameter is configured. If it is configured, the Oracle Communications Session Border Controller changes the host in the received Associated-URI to the customer host. If it is not configured, the Oracle Communications 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 Communications Session Border Controller receives a Service-Route in the 200 (OK) response, it stores that as well.

The Oracle Communications 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 Communications Session Border Controller can use the local policy, registrar host and the SIP configuration’s registrar port for routing.

If the Oracle Communications 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 Communications Session Border Controller uses caller, caller1, caller2 and so on as the AoR user.

Routing Calls from the IMS Core

The calls coming from the core will have the Oracle Communications Session Border Controller’s Contact-URI (which is sent in the REGISTER request) as the Request-URI. The Oracle Communications Session Border Controller looks for a registration entry that corresponds to this URI. After finding the registration entry and the corresponding surrogate agent, the Oracle Communications Session Border Controller looks for the routing mechanism it should use to route this INVITE to the IP-PBX. It uses the customer-next-hop configuration parameter to determine if it routes this call to the session agent, the session agent group, or directly to a particular IP address.

SIP

If the customer-next-hop parameter points to a SIP session agent or the SIP session agent group, the Oracle Communications Session Border Controller creates a Route header using the session agent and modifies the Request-URI. It changes the user portion of the Request-URI to either the user portion of the P-Called-Party-ID header, if present, or to the user portion of the To header. The Oracle Communications Session Border Controller also changes the host portion of the Request-URI to the hostname configured in the customer-host configuration parameter. It makes the change because the domain name on the core side can be different than the domain name on the access IP-PBX side. The Oracle Communications Session Border Controller then uses the added Route header to properly route the call.

H.323

If the session agent or the session agent group configured for the customer-next-hop parameter references an H.323 device, the Oracle Communications Session Border Controller sends the INVITE to its interworking task. If a session agent group is being used, the parameter containing the session agent group name is added to the Request-URI. The host portion of the Request-URI will point to the interworking IP address and the port is changed to 1720.

If a session agent is used, the Oracle Communications Session Border Controller uses it to route the call properly to the interworking task to take care of the H.323 call setup.

Note:

Even though the customer-next-hop field allows specification of a SAG or FQDN, the functionality will only support these values if they resolve to a single IP address. Multiple IP addresses, via SAG, NAPTR, SRV, or DNS record lookup, are not allowed.

Routing Calls from the IP-PBX

The Oracle Communications Session Border Controller (OCSBC) 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 OCSBC 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 OCSBC 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 OCSBC will not try to route the call to the registrar.

Configure Surrogate Registration

Surrogate registration allows the Oracle Communications Session Border Controller (OCSBC) 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 OCSBC 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 OCSBC to register.

Note:

To view all surrogate agent configuration parameters, enter a ? at the surrogate-agent prompt.
  1. Access the surrogate-agent configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# surrogate-agent
ORACLE(surrogate-agent)#
  2. On the Add Surrogate Agent page, do the following:
    • Register host—Enter the registrar’s hostname to be used in the Request-URI of the REGISTER request. This name is also used as the host portion of the AoR To and From headers.
    • Register user—Enter the user portion of the AoR (Address of Record).
    • Description—Optional. Enter a description of this surrogate agent.
    • Realm ID—Enter the name of realm where the surrogate agent resides (where the IP-PBX proxy resides). There is no default.
    • State—Set the state of the surrogate agent to indicate whether the surrogate agent is used by the application. The default value is enabled.
    • Customer host—Optional. Enter the domain or IP address of the IP-PBX, which is used to determine whether it is different than the one used by the registrar.
    • Customer next hop—Enter the next hop to this surrogate agent:
      • session agent group: <session agent group name>
      • session agent: <hostname> or <IPV4>
    • Register contact host—Enter the hostname to be used in the Contact-URI sent in the REGISTER request. This should always point to the OCSBC. If specifying a IP address, use the egress interface’s address. If there is a SIP NAT on the registrar’s side, use the home address in the SIP NAT.
    • Register contact user—Enter the user part of the Contact-URI that the OCSBC generates.
    • Password—If you are configuring the auth-user parameter, you need to enter the password used when the registrar sends the 401 or 407 response to the REGISTER request.
    • Register expires—Enter the expires in seconds for the REGISTER requests. The default value is 600,000 (1 week). The valid range is 0-999999999.
    • Replace contact—This specifies whether the OCSBC needs to replace the Contact in the requests coming from the surrogate agent. If this is enabled, Contact will be replaced with the Contact-URI the OCSBC sent in the REGISTER request. The default value is disabled. The valid values are enabled and disabled.
    • Options—Optional. Enter non-standard options or features.
    • Route to registrar—This indicates whether requests coming from the surrogate agent should be routed to the registrar if they are not explicitly addressed to the OCSBC. The default value is enabled. The valid values are enabled and disabled.
    • AoR count—Enter the number of registrations to do on behalf of this IP-PBX. If you enter a value greater than 1, the OCSBC increments the register-user and the register-contact-user values by that number. For example, if this count is 3 and register-user is john then users for three different register messages will be john, john1, john2. It does the same for the register-contact-user values. The default value is 1. The valid range is 0-999999999.
    • Auth user—Enter the authentication user name you want to use for the surrogate agent. This name is used when the OCSBC receives a 401or 407 response to the REGISTER request and has to send the REGISTER request again with the Authorization or Proxy-Authorization header. The name you enter here is used in the Digest username parameter. If you do not enter a name, the OCSBC uses the value of the register-user parameter.
    • Max register attempts—Enter the total number of times to attempt registration until success. Range 1-10
    • Register retry time—Enter the time to wait after an unsuccessful registration before re-attempting. Range 30-3600
    • Count start—Enter the starting value for numbering when performing multiple registrations. Range 0-9999999999
    • Register mode—Select automatic (default) or triggered (upon trigger from PBX).
    • Triggered inactivity interval—Enter the maximum time with no traffic from the corresponding PBX. (Valid only with Triggered inactivity interval.) Range 5 -300
    • Triggered OoS response—503 (Default. Send 503 response for core network failure) or drop response (Do not respond to PBX or core network failure
  3. Save and activate your configuration.
Next Steps

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

SIP Surrogate Registration Enhancements

For IMS-E networks, enhancements to the Oracle Communications Session Border Controller’s SIP surrogate registration capabilities enable it to register a series of endpoints on behalf of a set of devices that are unable to register themselves. In addition, the Oracle Communications Session Border Controller retries failed registrations, prevents authentication loops, and sends an SNMP trap for failed retransmissions. The automatic incrementing of register-user and register-contact-user values are also now more flexible.

Without Enhancements

Without the enhancements configured, the Oracle Communications Session Border Controller’s surrogate agent performs a series of registrations based on count when the system boots or when its configuration changes. It only attempts to register each user once. Although the surrogate agent uses the same retry mechanism used for SIP client transactions, it does not attempt further if it receives a failure response until the entry expires. When it receives 401, 403, or 407 responses to requests that include authentication, the surrogate agent’s automatic incrementing mechanism appends a number to the end of each registered username. Always starting at one, this number cannot appear in any other position in the username.

With Enhancements

With the enhancements configured, the Oracle Communications Session Border Controller supports:

  • Registration retry—You can configure the surrogate agent to retry registration when after a failure, timeout, or transport error. You can set how many times the Oracle Communications Session Border Controller will attempt to register each user; a setting of zero means retries are umlimited. You can also define the number of seconds to wait before initiating a retry. The Oracle Communications Session Border Controller tracks each registration retry count and timers, and sends an SNMP trap when it reaches the maximum number of retries, which signifies failed registration.
  • Authentication loop prevention—Authentication loops can occur in previous releases when the Oracle Communications Session Border Controller resends a registration request with authentication in response to 401, 403, or 407 responses (indicating, for example, that there might be a password error). Using the new enhancements, the Oracle Communications Session Border Controller only allows permits the retransmission of one request. It now considers further 401, 403, or 407 responses to be errors and initiates the retry mechanism.
  • Automatic increment enhancements—Now, the automatic increment works with the caret (^) in the register-user and register-contact-user fields. These carets define where the automatically generated incrementing number is inserted in the username. You can also use multiple carets to define leading zeroes to insert; for example, the entry user^^^^ will become user0001. You can also define the starting integer for the incrementing registrations. For example, setting the AoR count to 20, the count start to 5, and using the value user^^^^ for register-user and register-contact-user results in the incremented user registrations user0005 through user0025.

Configuring the Retry Mechanism

To set the retry mechanism:

  1. In Superuser mode, type configure terminal and press Enter. 
    ORACLE# configure terminal
ORACLE(configure)#
  2. Type session-router and press Enter. 
    ORACLE(configure)# session-router
ORACLE(session-router)#
  3. Type surrogate-agent and press Enter. 
    ORACLE(session-router)# surrogate-agent
ORACLE(surrogate-agent)#
  4. max-register-attempts—Using a value from 0 (meaning registration attempts are unlimited) to 10, enter the number of times you want to attempt registration. The default value is 3. The valid range is:

    • Minimum—0

    • Maximum—10

  5. register-retry-time—Enter the amount of time in seconds, between 30 and 3600 seconds, you want the Oracle Communications Session Border Controller to wait before reattempting registration. The default value is 300. The valid range is:

    • Minimum—10

    • Maximum—3600

  6. Save and activate your configuration.

Configuring the Count Start

To set the value where automatic incrementing will start:

  1. In Superuser mode, type configure terminal and press Enter. 
    ORACLE# configure terminal
ORACLE(configure)#
  2. Type session-router and press Enter. 
    ORACLE(configure)# session-router
  3. Type surrogate-agent and press Enter. 
    ORACLE(session-router)# surrogate-agent
ORACLE(surrogate-agent)#
  4. count-start—Change this parameter from its default of 1 if you want the automatic increment count to start at any other number when the Oracle Communications Session Border Controller performs multiple registrations. The default value is 1. The valid range is:

    • Minimum—0

    • Maximum—999999999

SIP-IMS Surrogate Registration Proxy Authorization Header for Non-Register Requests

The Oracle Communications Session Delivery Manager’s IMS functionality helps customers who use SIP IP PBX or SIP gateways that can only peer with carriers connected to IMS via a P-CSCF. As part of this function, the Oracle Communications Session Delivery Manager provides for generating a Proxy-Authorization or Authorization header for REGISTER requests that are challenged. This feature extends the Oracle Communications Session Delivery Manager’s capabilities by also allowing you to configure the generation of Proxy-Authorization and Authorization headers for non-REGISTER requests.

When you configured it to do so, the Oracle Communications Session Delivery Manager caches Proxy-Authorization or Authorization headers from the most recent (last-sent) messages in the following exchange: REGISTER--407 Proxy Authentication Required--REGISTER--200. Then the system uses these values in the subsequent requests. The following methods are supported:

  • INVITE
  • ACK
  • BYE
  • CANCEL
  • UPDATE
  • INFO
  • PRACK
  • OPTIONS

The Oracle Communications Session Delivery Manager updates the following parameters when it generates the header:

  • nonce-count—Incremented for every new request the Oracle Communications Session Delivery Manager receives
  • response—Contains the digest-request, newly generated using the cnonce, nonce, and other fields as input

In addition, the system supports the nonce text parameter in the Authentication-Info header. And for surrogate registration, it recognizes the Authentication-Info header in 200 OK responses received from the UAS and updates its cached nonce value accordingly; in this case, the system resets the nonce count to 1 for the subsequent request.

SIP-IMS Surrogate Registration Proxy Authorization Header Configuration

You configure the SIP-IMS surrogate registration proxy authorization header for non-register requests by setting the options parameter in the surrogate agent configuration. You set two types of options: auth-methods and auth-info.

Note:

If authentication of any SIP requests other than REGISTER is required, then the surrogate-agent option auth-methods MUST be configured. Supported methods are INVITE, ACK, BYE, CANCEL, UPDATE, INFO, PRACK, OPTIONS. For example: 
ORACLE(surrogate-agent)# options +auth-methods=’INVITE,OPTIONS”

To enable SIP-IMS Surrogate Registration Proxy Authorization Header for Non-Register Requests:

  1. In Superuser mode, type configure terminal and press Enter. 
    ORACLE# configure terminal
  2. Type session-router and press Enter. 
    ORACLE(configure)# session-router
ACMEPACKET(session-router)#
  3. Type surrogate-agent and press Enter. 
    ORACLE(session-router)# surrogate-agent
ORACLE(surrogate-agent)#

    If you are adding support for this feature to a pre-existing configuration, then you must select (using the ACLI select command) the configuration that you want to edit.

  4. options—Set the options parameter by typing options, a Space, and then the option name. Then type the equal sign (=), open quotation mark (“), the list of methods you want supported separated by commas, and closed quotation mark (”). Then press Enter. Valid values are INVITE, ACK, BYE, CANCEL, UPDATE, INFO, PRACK, OPTIONS. Default is blank. 
    ORACLE(surrogate-agent)# options +auth-methods=’INVITE,CANCEL,ACK,BYE”
ORACLE(surrogate-agent)# options +auth-info=refresh

    If you type the option without the plus sign, you will overwrite any previously configured options. In order to append the new options to this configuration’s options list, you must prepend the new option with a plus sign as shown in the previous example.

SIP Surrogate Agent Registration Re-initialization

Surrogate agents in the IMS network integrate IP Private Branch Exchange (PBX) that cannot register itself to the registrar. The Oracle Communications Session Border Controller supports registration retry attempts to the IMS core up to the configured maximum register attempts before failing. When the Oracle Communications Session Border Controller identifies an unregistered surrogate agent, the registration cache can cleared as a normal SIP user and the registration process re-started.

Surrogate Agents may not successfully register before the max-register-attempts, causing an unresponsive agent. Commands identify these unregistered agents and clear them from cache. New registration attempts are then available.

Command line option show registration sipd surrogate-agent <realm-id/unregistered> with no additional arguments displays all surrogate agents and their state.The system displays the last time of registration for each agent.

  • realm id—displays all surrogate agents present in the selected realm.
  • unregistered— displays all unregistered surrogate agents.

The preceding commands have the to-file option to redirect the output to a file

Possible values for the Last Registered at and State fields

User Contacts
Displays the registered SIP URI for the surrogate agent. In case of surrogate agents configured with block of numbers, one user contact (SIP NUI) for each number within the block of numbers.
Last Registered at
Displays the last time when the agent registered with the Registrar. This time will change with every renewal registry at expiration. If the surrogate user has not successfully registered, this field will say never registered
State
Displays the current state of the surrogate agent. This State field confirms the state of two timers used when a surrogate agent is being configured: 1. register-expires and 2. register-retry-time. When the register-retry-time expires, the state will be set to unregistered as it continues to try to register. When the register-expires time expires and max-register-attempts is exhausted, the state is set to failed.
Last Registered At State Description
<time> registered Surrogate agent valid and registered
<time> failed Surrogate agent registered, but failed to register refresh and is in an invalid state
<time> unregistered Surrogate agent registered, now server is not responding but continues to send REGISTER
Never registered failed Surrogate agent failed to register.

When there are no surrogate agents configured on the Oracle Communications Session Border Controller , the output for show registration sipd surrogate-agents, show registration sipd surrogate-agents by-realm <realm-id> and show registration sipd surrogate-agents unregistered shows "No matching entries found!".

When all the surrogate agents are registered and none in an unregistered state, the output for show registration sipd surrogate-agents unregistered shows "No matching entries found!".

Existing ACLI command clear-cache registration sipd restarts the registration process for the surrogate agent.

Surrogate Agent Reregistration to SAG Member Handling

In a round-robin environment sometimes requests need to go to the same server as the initial request. The Oracle Communications Session Border Controller will direct the reREGISTER request to a 401/407 response for a surrogate agent to the same Proxy Call Session Control Function(P-CSCF) as the prior REGISTER request for security purposes.

Round robin environments are commonly implemented to balance traffic on multiple Proxy Call Session Control Functions(P-CSCFs). While this strategy is effective, it does also introduce complexity to scenarios in which some consecutive requests need to be directed to the same target. When an initial reREGISTER is challenged, the Oracle Communications Session Border Controller directs the reREGISTER request for a surrogate agent to the same Proxy Call Session Control Function(P-CSCF) as the prior REGISTER request. If the reREGISTER were to go to another server, it would never be accepted. The routing decision for this reREGISTER is made independent of local policy.

No configuration is needed to enable this feature. However, the cache-challenges parameter in the SIP Config must be enabled (default).

Previous
Previous 		Next
Next
Go To Table Of Contents
Contents