Oracle SBC Advanced Configuration B - 1

Oracle SBC Advanced Configuration B - 2

Oracle SBC Advanced Configuration B - 3
Oracle SBC Advanced Configuration B - 4
Business trunking connects PBXes to the PSTN via an IP network or to other PBXes, with or
without an Integrated Access Device (IAD). The IAD is used to connect to legacy PBXes using PRI
or BRI digital interfaces, or FXO/FXS analog interfaces.
PBX to PBX configurations are more common within enterprise implementations. Local calls
inside the customer premises are routed by the PBX itself. PBX networking protocols, for example,
DPNSS, MCDN, Cornet, ABCNet, Qsig, and others are not supported.
There are four basic methods to interconnect the service provider network as shown. The role of
the SBC is to “normalize” the traffic to conform to one or more of these methods using IWF, HMR,
or the SIP-connect feature.

Oracle SBC Advanced Configuration B - 5

In straight-through trunking, the SBC is “transparent” to the traffic. Commonly, you would have
one IP address on the access side and one on the core with a direct connection between them.
Routing can take place, if required, based on location code prefixes. You can also perform digit
manipulation if required.
This is a configuration-intense method, but is very flexible in terms of meeting different needs of
individual PBXes or Trunks.
You can use this method for SIP only, H323 only, or IWF with any type of routing, associated
stack, static local-policies, SIP-NATs, and so on.

Oracle SBC Advanced Configuration B - 6

There is a one-to-one relationship in the SBC between each PBX and core network interface. This
implies that you need several peer and core network-interfaces, realms, sip-interfaces or h323-
stacks, steering pools, and so on. Nevertheless, the SBC can perform IWF or routing if required for
load-balancing purposes.
You can use any SBC routing mechanism with straight-through trunking. Local-policy is used
most often, but associated-stack and SIP-NAT configuration are also common.

Oracle SBC Advanced Configuration B - 7

Trunk Group routing principles are as follows:
The SIP protocol includes a header that can be used for routing messages via trunks. The
information is included in the Request-URI and can be set to IPTEL, trunk-group, or trunk-context.
The SBC can recognize these settings and route accordingly. No other routing configuration is
required.
The simplest SBC configuration uses a realm associated with the trunk-context and an SA
associated with the trunk group.
The use of trunking requires that other devices in the core, including the soft switch support TG-
URIs (Trunk Group). However, when implemented, it can vastly simplify provisioning.

Oracle SBC Advanced Configuration B - 8

There are many applications that you can set up on the SBC to take advantage of SIP’s trunk-
group and trunk-context headers.
Let’s consider a PBX that is originating methods using trunk-group and/or trunk-context headers.
A common application in this context is to configure the PBX as an SA on the SBC. Next, you
configure that SA to support trunk-group and/or trunk-context. Finally, you configure the SBC to
use header manipulation to pull the data from trunk-group and/or trunk-context and insert it into
the re-originated methods’ Contact headers. In this case, you are providing the service provider
with information about which PBX is originating calls that they can then use for billing and SLA
purposes.
Consider traffic flowing in the opposite direction, to the PBX. For traffic that has an application
server set to trunk-group and/or trunk-context, the SBC can use that information to select a
destination, which is typically an SA. This configuration allows you to support routing with an
extremely efficient configuration that avoids the use of a local policy for a multitude of PBXes with
different and noncontiguous numbering plans.
Even if the PBX does not support those parameters in the Request-URI, you can configure the SBC
with an egress HMR to remove them so the destination accepts the sessions.

Oracle SBC Advanced Configuration B - 9

The SBC parameter that triggers trunk group routing is the term-tgrp-mode in the ingress sip-
interface. You set the mode depending on the format received, either iptel or egress-URI. You can
also use SAs for both reading internal variables and adding them in the contact. For this purpose,
set the SA trunk-group parameter to tgrp:trunk-context.
Note that you can also set the trunk-group parameter in a SAG to apply load balancing.
You do not need the trunk-context set on the SA. This could instead be set at the realm level. Of
course, no trunk context is needed if the trunk group itself already indicates a valid next-hop,
such as an IP address.

Oracle SBC Advanced Configuration B - 10

There are two main configuration elements needed to route using trunk groups ─ sip-interface
and session-agent.
Note that SAGs allow you to load balance between trunk groups. In addition, you can use an HMR
to add or remove parameters in the Request-URI or contact for egress or ingress sessions.

Oracle SBC Advanced Configuration B - 11

In some cases, the tgrp parameter comes with a next hop defined in the form of an IP address or
FQDN. Even if this is the case, a source still must be defined.
You can use the SBC to resolve this issue by setting the trunk-context in the ingress realm. When
the SBC sees this parameter, it selects this realm as the egress. This means that the sip-interface
associated with the realm originates the session. This mechanism is very efficient and simple to
configure.
In addition, calls entering a realm with the trunk-context parameter set have the internal variable
populated. This allows us to include it in the contact of the egress session.

Oracle SBC Advanced Configuration B - 12

Oracle SBC Advanced Configuration B - 13
Oracle SBC Advanced Configuration B - 14
The SBC surrogate registration feature lets the SBC register on behalf of an Internet Protocol
Private Branch Exchange (IP-PBX). After you configure a surrogate agent, the SBC periodically
generates a REGISTER request and authenticates itself using a locally configured username and
password, with the SBC 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.
With surrogate registration, the SBC 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 registration of one address of record (AoR) triggers the automated
registration of all the other AoRs associated with that UE. The automated registered AoRs are
passed back to the UE (in this case the SBC) as P-Associated-URIs in the registration’s 200 (OK).
IMS assumes that each SIP endpoint can register itself with its Serving-CSCF (SCSCF). However
phones can be connected to SIP Integrated Access Devices (IADs), SIP, or H.323 IP-PBXes. The
SBC performs SIP registration on behalf of the IP-PBX and IADs. It can handle routing in both
directions, respecting rules from both sides.

Oracle SBC Advanced Configuration B - 15

The SBC registers on behalf of the IP-PBXes and then stores the associated URIs returned by the
Call Session Control Function (CSCF). The calls from the phones behind the IP-PBX can be routed
based on the cache entry the SBC 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 SA or SAG. The SBC also supports multiple registrations on behalf of an 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 SBC 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 SBC replaces the Request-URI
username with P-Called-Party-ID/To-URI username. The IMS core 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.
The calls coming from the core will have the SBC’s Contact-URI (which is sent in the REGISTER
request) as the Request-URI. The SBC looks for a registration entry that corresponds to this URI.
After finding the registration entry and the corresponding surrogate agent, the SBC 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 SA, the SAG, or directly to a
particular IP address.

Oracle SBC Advanced Configuration B - 16

Here are detailed descriptions of the parameters in the surrogate-agent element:
• register-host: Specifies the registrar’s host name 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: Specifies the user portion of the AoR. If there will be several users because aor-
count is greater than 1, such as the example in the slide, you can configure the SBC to use
automatic increment.
• 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 aor-count to 20, count-start to
5, and user^^^^ to register-user and register-contact-user results in the incremented user
registrations user0005 through user0024.
• description: Enters a description of this surrogate agent (optional)
• realm-id: Specifies the name of realm where the surrogate agent resides (where the IP-PBX
proxy resides)
• state: Set to enabled (default) or disabled to indicate whether the surrogate agent is used by
the application
• customer-host: Specifies the domain or IP address of the IP-PBX, used to determine whether
it is different from the one used by the registrar. This parameter is optional.
• customer-next-hop: Specifies the next hop to this surrogate agent: SAG (SAG: <SAG name>),
SA (<hostname> or <IPV4>), or specific IP address (<IPV4> or <IPV4: port>)

Oracle SBC Advanced Configuration B - 17

• register-contact-host: Specifies the hostname to be used in the Contact-URI sent in the
REGISTER request. This should always point to the SBC. If specifying an IP address, use the
egress interface’s address.
• register-contact-user: Specifies the user part of the Contact-URI that the SBC generates
• password: If the auth-user parameter is configured, specify the password that will be used in
case the registrar sends the 401 or 407 response to the REGISTER request.
• register-expires: Specifies the expires in seconds to be used in the REGISTER requests.
Default value is 600,000 (1 week).
• replace-contact: Set to enabled or disabled (default). This specifies whether the SBC 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 SBC sent in the REGISTER request.
• options: Specifies nonstandard options or features
• route-to-registrar: Set to enabled (default) or disabled. This indicates whether requests
coming from the surrogate agent should be routed to the registrar if they are not explicitly
addressed to the SBC.
• auth-user: Specifies the authentication username you want to use for the surrogate agent.
This name is used when the SBC receives a 401or 407.
• aor-count: Specifies the number of registrations the SBC does on behalf of this IP-PBX. If you
enter a value greater than 1 (default), the SBC 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 register users for three different register messages will be john, john1, john2. It does the
same for the register-contact-user values.
• max-register-attempts: Specifies the number of times to attempt registration. A 0 value
means registration attempts are unlimited. Default value is 3.
• register-retry-time: Specifies the amount of time in seconds to wait after a failed registration
before reattempting registration. Default is 300 seconds.
• count-start: Specifies the starting value for automatic increment in usernames when
performing multiple registrations.
• register-mode: Specifies if the SBC sends registration automatically when the SBC boots or
when its configuration changes, or if the SBC sends registration upon trigger from PBX. Value
can be automatic (default) or triggered.
• triggered-inactivity-interval: Specifies maximum time without any traffic from the
corresponding PBX. It is valid only if register-mode is set to triggered. Default is 30.
• triggered-oos-response: Specifies out-of-service response. Value can be 503 (default),
indicating the SBC will send 503 response for core network failure, or dropresponse, indicating
the SBC does not respond to PBX for core network failure.
• options: If authentication of any SIP requests other than REGISTER is required, the auth-
methods option MUST be configured. Supported methods are INVITE, ACK, BYE, CANCEL,
UPDATE, INFO, PRACK, OPTIONS.
• For example:
• training(surrogate-agent)# options +auth-methods= “INVITE, CANCEL,ACK,BYE”
• training(surrogate-agent)# options +auth-info=refresh

Oracle SBC Advanced Configuration B - 18

More details about the advantages and disadvantages of all trunking options on the SBC:
• Straight-through: This is the easiest and traditional way to configure trunking. All the BCP
models will fit in this category. It is also flexible in terms of features but it requires a detailed
configuration effort, so it is not recommended for most of the big deployments.
• Trunk Group URI: This option is excellent for large configurations as it requires minimum
configuration load and allows a lot of flexibility. However, it requires an IMS network
supporting the parameters tgrp (trunk group) and trunk-context in the Request-URI. Additional
HMR configuration may be necessary to cover all requirements with a very high degree of
flexibility.
• Surrogate registrations: It is a very good solution for increasing the service reach of non-IMS
compliant users or H.323 devices to be able to register in a SIP environment. However, it
requires the core to support this type of operation (Send a correct URI and a P-Called-Party-ID
header). It also requires the core to handle additional registrations from the SBC. All
registrations from same surrogate-agent, if they are challenged, need to have the same
password as the configuration only allows one password field for all the range of users.

Oracle SBC Advanced Configuration B - 19

Oracle SBC Advanced Configuration B - 20