Oracle SBC Configuration and Administration 2 - 1

Oracle SBC Configuration and Administration 2 - 2

Oracle SBC Configuration and Administration 2 - 3
Oracle SBC Configuration and Administration 2 - 4
Since the early days of telephone communication to this very day, a conversation or a session is
established by exchanging some call control information. This information, verbal in the early
years, analog signals (pulses and tones) in later years and digital data nowadays, is referred to as
“signaling.” In today’s networks, signaling information consists of large amounts of data, arranged
in messages that can be binary or textual.
Establishing a call means enabling the orderly, controlled, and predictable flow of “media”
information that represents speech, video, or any other streaming information.
Signaling messages may be exchanged during the call in order to change something such as
media attributes or putting the call on hold or off hold.
Signaling is finally used to tear down the call in a graceful way. Signaling information in general is
used for other purposes too: billing, tracking, law enforcement, and more

Oracle SBC Configuration and Administration 2 - 5

The Session Initiation Protocol (SIP) emerged in 1999 documented by the IETF as RFC 2543. This
RFC is now obsolete and the current “master” document is RFC 3261. Numerous RFCs have been
written over the years in order to update RFC 3261 and extend SIP functionalities.

Oracle SBC Configuration and Administration 2 - 6

Oracle SBC Configuration and Administration 2 - 7
SIP is an application layer control protocol, often referred to as ISO layer 5 (more precisely it
combines the functions of layers 5, 6, and 7). It is used to establish, modify, and terminate
multimedia sessions such as Internet telephony calls. SIP can also be used to invite participants to
already existing sessions, such as multicast conferences. Media can be added to (and removed from)
an existing session by additional signaling messages. SIP transparently supports name mapping and
redirection services, which supports personal mobility. Users can maintain a single externally visible
identifier regardless of their current network location or the device they use.
Because the SIP is solely for controlling sessions, additional IETF protocols are used to form a
complete system. Devices that handle media negotiate the media attributes by exchanging Session
Description Protocol (SDP) information carried as a “body” within the SIP signaling messages. Real-
Time Protocol (RTP) and Real-Time Control Protocol (RTCP) packets (over UDP) are used to carry
actual media and QoS-related information, respectively.

Oracle SBC Configuration and Administration 2 - 8

Oracle SBC Configuration and Administration 2 - 9
From RFC 3261: User Agent Client (UAC): A user agent client is a logical entity that creates a new
request and then uses the client transaction state machinery to send it. The role of UAC lasts only
for the duration of that transaction. In other words, if a piece of software initiates a request, it acts
as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a
user agent server for the processing of that transaction.
UAC Core: The set of processing functions required of a UAC that reside above the transaction
and transport layers.
User Agent Server (UAS): A user agent server is a logical entity that generates a response to a
SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the
duration of that transaction. In other words, if a piece of software responds to a request, it acts as
a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a
user agent client for the processing of that transaction.
UAS Core: The set of processing functions required at a UAS that resides above the transaction
and transport layers. User Agent (UA): A logical entity that can act as both a user agent client and
user agent server.

Oracle SBC Configuration and Administration 2 - 10

The Proxy server, as the term implies, works on behalf of a SIP device by using information (for
example, routing information) that is unavailable to the device and by relaying the device’s SIP
messages. A softswitch is an example of an implementation that includes the Proxy functions and
the respective software.
In a well organized system, the system needs to know which users currently exist (or are active)
and where they are (geographically or in terms of IP addresses). To maintain this knowledge,
phones (and possibly other devices) register themselves with the system by interacting with a
Registrar.
Common in small systems (for example, office or a small campus), a calling phone will attempt to
place a call by sending its first SIP message to a server that it thinks is a proxy. This server, known
as a Redirect server, will respond with information that will enable the calling phone to connect to
the called phone directly.
Put in the simplest way, a Back-To-Back User Agent (B2BUA) receives a call as if it were the
destination. It then re-originates a call to the true destination and then “bridges” these two calls.
Being in the middle throughout the whole session the B2BUA can change everything: signaling
information, addresses, encryption, and more. This leverages many desired premium functions,
the most important of which is SIP network security.

Oracle SBC Configuration and Administration 2 - 11

All SIP messages are either a request from a UAC or a response from a UAS. The messages are
formatted according to RFC 822, “Standard for the format of ARPA internet text messages.”
These text-based messages are similar in look and feel to Hypertext Transfer Protocol (HTTP), an
application protocol that defines the rules for transferring information on the Web. SIP messages
are ASCII-based, similar to HTTP; the disadvantage is that ASCII-based messages consume more
bandwidth than binary formatted messages.
Each SIP message contains a start-line, followed by header fields and an optional message body.
The start-line contains different information depending on whether the message is a request or a
response.

Oracle SBC Configuration and Administration 2 - 12

The start-line in a request contains a request Uniform Resource Identifier (request-URI). The
request URI identifies the address where the request is sent to and is written in the form of
user@host. The user portion of the SIP URI identifies a particular resource at the host being
addressed. The host portion is separated from the user portion by an @ sign and frequently
refers to a domain. The user part of a URI is absent when the destination host does not have a
notion of users or when the host itself is the resource being identified.
According to the RFC 3261, the initial request-URI of the message should be set to the value of
the URI in the “To:” field. The request-URI may also include the SIP port and additional
information items separated by semicolons (not shown). The message header fields guide the SIP
device in determining the appropriate handling of the message. Several header fields are
normally found in a SIP message; here are some examples:
The “Via:” header field indicates the transport used for the transaction (transaction = request and
all its related responses) and identifies the location where the response(s) to this request should
be sent.
The “To:” header field specifies the desired “logical” recipient of the request, or the address-of-
record of the user or resource that is the target of this request. The “From:” header field indicates
the request initiator’s logical identity.
The start line in the response message contains the SIP version, a numerical code and a reason
phrase—separated by a single space.
Some of the request’s header fields may be copied into the response, some may be modified (for
example, by adding a parameter or a tag) and some header fields may be added by the UAS.
There is usually no “response to a response” but one exception does exist: This is the ACK
(acknowledge) request that is sent in order to acknowledge the receipt of a successful response
(200 OK) to an INVITE (session beginning) request.
For a complete list of SIP responses, refer to section 21 of RFC 3261.

Oracle SBC Configuration and Administration 2 - 13

RFC 3261 defines the six basic requests or “Methods.” The INVITE request is the one, most basic
request used to establish a session or a call. (It is the equivalent of the Initial Address Message—
IAM—used in TDM networks that use SS#7/ISUP signaling.)
Note the difference between BYE and CANCEL. BYE is a request to finish a session while CANCEL
is a request to not proceed with a session that has not been answered yet.
Subsequent RFCs introduced more methods that provide for dramatically increased network
functionality.

Oracle SBC Configuration and Administration 2 - 14

SIP responses are meticulously divided into types, as the table shows. Each type is identified by
the response code’s first digit. Some types include a large number of possible responses. The
table presents some of the most commonly occurring responses. It is important to note that a
response that begins with a 1 is provisional and that there will be a final response to the same
request. Differently put, in many cases the provisional responses are optional but final responses
must be returned (for example, a SIP phone normally does not return 100 Trying and it may not
even return 180 Ringing (if it is set to “auto-answer” mode) but it must return 200 OK or any
other non-success final response).

Oracle SBC Configuration and Administration 2 - 15

Oracle SBC Configuration and Administration 2 - 16
The requests and responses shown represent the (almost) simplest call flow. Although not
showing any specific parameters, each line shows the “spirit” of a message from the sender’s
perspective.
In this diagram, you assume that the media flow is taken care of. This is yet to be explained.

Oracle SBC Configuration and Administration 2 - 17

Like an attachment in an email message, a “body” can “take a ride” in a SIP message. The
diagram shows a Session Description Protocol (SDP) body. There is an “SDP Offer” in the INVITE,
and an “SDP Answer” in the 200 OK response. This is how the two sides negotiate media-related
parameters. The diagram shows the “spirit” of the SDP bodies, not their actual structure.
The “RTP” mentioned stands for Real-Time Protocol. This is a protocol commonly used for the
streaming of media packets that works on top of UDP.

Oracle SBC Configuration and Administration 2 - 18

RFC 4566—Session Description Protocol— defines media description–based on lines formatted
as <type>=<value>, where the value is a string that depends on the type. The type is a single
case-sensitive character. Many types are listed, some of them mandatory. The most common
types are listed here:
v= protocol version
o= originator and session identifier
s= session name
c= connection information
t= time the session is active
m= media name and transport address
a= zero or more media attribute lines
The rtpmap: attribute is used to map from an RTP payload type number to a media encoding
name that identifies the payload format.
The fmtp: (format parameter) attribute may be used to specify encoding format parameters.

Oracle SBC Configuration and Administration 2 - 19

A transaction consists of a request and all its responses. The SIP messages contain a string that
serves as the “transaction identifier.”
A call, or a session, consists of several transactions. All the transactions that belong to a session
make a “Dialog.” All the SIP messages in a dialog contain some items that jointly serve as a “dialog
identifier.”

Oracle SBC Configuration and Administration 2 - 20

Oracle SBC Configuration and Administration 2 - 21
In a traditional telephone network, a subscriber is known by the phone number the carrier has
assigned to him/her. The subscriber can unplug the phone and then plug in a different one and
still be able to make and receive calls. This is because the phone number is assigned to a user, not
to a device. In SIP networks, users are known by user names residing at hosts or in a domain. A
user name can consist of digits and resemble a “phone number.” Users can use different devices
at different times. Users are identified by the “Address Of Record,” while devices are assigned
(statically or dynamically) an IP address.

Oracle SBC Configuration and Administration 2 - 22

A user registers at the network using his/her SIP device. The SIP device, or phone, will send a
REGISTER message containing the information that provides the user’s AOR and its current IP
address and port through which the device is reachable. Although not showing any specific
parameters, each line in the event flow shows the “spirit” of a message from the sender’s
perspective.
A successful registration results in a Location Database entry, also known as a “Binding.” This
binding is exactly what makes incoming calls to a user possible. This binding has a life time after
which, unless the device re-registers, it will be deleted. Consequently, when a device is
unintentionally disconnected, the network, after some time, will “forget” about this user and reject
calls destined to him/her.
When a device gracefully leaves the network (for example, an orderly shutdown of a SIP phone) it
will send a REGISTER message with parameters that indicate the intention of unregistering.

Oracle SBC Configuration and Administration 2 - 23

Oracle SBC Configuration and Administration 2 - 24
When a caller dials a number, it is the phone’s task to make sure that the INVITE message will be
routed to the correct destination (which might be the actual destination phone, an exchange or a
gateway to a PSTN network). Theoretically, the phone can perform this “detective work” by
accessing various databases, DNS servers, and so on at the cost of time and complexity. In order
to keep the phone’s work to a minimum, it sends all its requests to a Proxy server which has all the
necessary capabilities to handle the call. A phone that works with a proxy server needs to know
very little: its own identity, its IP address, the default gateway, and the IP address and port of the
proxy it uses.
As a result, the phone assumes that the whole world is at the proxy; therefore, the phone
constructs the target URI as shown. At some place along the route, this URI will be modified (by a
proxy en-route) to reflect the correct host name or IP address where the invited user (phone
number) is.

Oracle SBC Configuration and Administration 2 - 25

Because a proxy always acts on behalf of another SIP entity, it never initiates its own requests.
It will receive request through its UAS part and relay them to another entity (the “next hop”)
through its UAC part. Some decisions must be made between receiving a message and further
relaying it. The decisions are normally based on things like: destination user, routing
requirements present in the incoming request itself, dial plans, security, and more. Proxies also
find out necessary information (that the sending SIP entity may not have) by accessing location
databases and performing DNS queries and/or ENUM queries.

Oracle SBC Configuration and Administration 2 - 26

Oracle SBC Configuration and Administration 2 - 27
This common scenario is a flow of the following events:
1. A phone registers as a UA with the AOR of 552122227777 and the current IP address port it
can be reached through.
2. A binding is created in the location database.
3. A 200 OK response is returned and it contains the binding expiry period.
4. a,b,c. An INVITE message is sent from the calling phone and is routed to the third proxy. This
proxy knows that the target phone is in its domain.
5. The proxy looks up the dialed number in the location database and obtains the phone’s IP
address and port.
6. The proxy sends the INVITE to the phone. Assume the phone rings and a person picks it up.
7. All the responses to the original INVITE flow back to the calling phone through the exact same
chain of proxies.
8. Now the two phones know each other’s IP address (from the SIP messages) and the signaling
proceeds directly. ACK request is sent and the call is thus established.
9. Media flows between the phones as the two parties speak.
10. More signaling is probable during the call for the purpose of on-hold, off-hold, DTMF codes
transmission, and more.
11. One of the parties hangs up and its phone sends a BYE, indicating a request to end the call.

Oracle SBC Configuration and Administration 2 - 28

This less-than-ideal scenario shows some transactions that do not develop into a dialog. These
are common and utilize non-2xx final responses.
403 FORBIDDEN can be returned by a proxy that is designed to forbid calls originated by end-
points that are not registered.
The CANCEL method aborts a call before the dialog has been established. When the called end-
point receives the CANCEL it sends two final responses: The first is “487 Request Terminated” for
the INVITE and the second is the normal 200 OK (success) for the CANCEL request itself. In this
case, where a dialog has not been established, all the messages from the INVITE to the 200 OK
make one transaction. In this scenario, the call is unsuccessful from the user’s perspective but the
SIP transaction is.
The 404 NOT FOUND response can have many root causes. In this scenario it might be that the
dialed number is bogus or that one of the proxies along the call path failed to find a route.

Oracle SBC Configuration and Administration 2 - 29

Oracle SBC Configuration and Administration 2 - 30
The start-line in a request contains a request uniform resource identifier (request-URI). It
identifies the address where the request is sent to and is written in the form of user@host. The
user portion of the SIP URI identifies a particular resource at the host being addressed. The host
portion is separated from the user portion by an @ sign and frequently refers to a domain. The
user part of a URI is absent when the destination host does not have a notion of users or when the
host itself is the resource being identified. According to the RFC 3261, the initial request-URI of
the message should be set to the value of the URI in the “To:" field.
Via: Provides the transport type, the IP:port of the host transmitting this request, and a branch
parameter, which is a string that serves as the transaction ID. Every proxy that this message
traverses adds its own “Via:” before the existing ones. Therefore, a message will contain a “chain”
of IP addresses and ports through which all the responses to a request will propagate. The
essence of the Via header field is to provide an IP address and port for responses.
Max-Forwards: Specifies the maximum number of proxies a request can traverse. Every proxy
will decrement this number before it forwards the request. If a proxy receives a request where this
integer is 0 it will discard the request message. This prevents a message looping indefinitely in
the universe if there are some routing errors.
Contact: Provides an IP address and port where the device directly receives requests.
To: Indicates the target resource (for example, the dialed number) in the form of user@host. The
host part, whether a fully qualified domain name or an IP address, is informational and not used
for routing decisions. In subsequent messages in the same dialog, a “tag” parameter will be added
in this header field.
From: Identifies the requestor’s AOR (for example, the calling number) in the form of user@host.
The host part, whether a fully qualified domain name or an IP address, is informational and not
used for routing decisions. A “tag” parameter is included in this header field.

Oracle SBC Configuration and Administration 2 - 31

Call-ID: A string, made as random as possible, that identifies this call. When generated correctly
by the software it will uniquely identify this call globally and at all times.
Remember: the Call-ID, the To-tag, and the From-tag together become the dialog ID
CSeq: An integer and the method itself (for example, 1 INVITE). This integer increases in each
transaction in the dialog. It serves in matching responses to requests.
Allow: Lists the methods that this device supports
Content-Type: If there is a body carried in this message, this header field specifies its type (for
example, application/SDP, application/IM, and more).
Content-Length: The body’s byte count. If zero, this message does not carry a body.

Oracle SBC Configuration and Administration 2 - 32

The responses to the INVITE message (true for other requests too) contain the status line and
most header fields that are copied from the request. Note that the responding device has added
the “To:” tag and (optionally) a display string. The 200 OK also provides the “Contact:”
information of the called device.

Oracle SBC Configuration and Administration 2 - 33

This flow shows the “accumulation” of “Via:” header fields along the route and the reverse flow of
responses through the same chain of proxies.
When the destination phone has received the INVITE, and later the calling phone has received the
200 OK, both sides know each other’s “Contact:” IP address and port as well as each other’s media
attributes. The proxies can be now considered as unnecessary.

Oracle SBC Configuration and Administration 2 - 34

In this scenario, Alice is calling Bob. Alice and Bob are user names, but so are phone numbers in
the SIP world. Each device has an IP address (generalized here for simplicity) and the layer-3 (IP)
routing infrastructure is assumed as always available.
Alice and the close proxy are said to belong to the same administrative “domain”—[Link].
Similarly, Bob and its close proxy belong to the [Link] administrative domain.
1. Bob’s phone registers itself by providing the AOR in the “To:” header field and the “location”
in the “Contact:” header field. The registrar will look at the “To:” header field. RFC 3261
requires that the “To:” and “From:” header fields contain the same AOR, in a REGISTER
message.
2. The registrar creates a binding in the location database.
3. The registrar returns a 200 OK response that indicates how long (in seconds) the binding will
be valid.
Bob’s phone is now known in its domain and a proxy in the same domain can forward calls to Bob.

Oracle SBC Configuration and Administration 2 - 35

Alice’s phone may know that bob is at [Link] (probably through a built-in phonebook). It sends
an INVITE as shown.
2. The first proxy has no idea where or what “[Link]” is. However, the request URI contains the
hint “sip:” Therefore, the proxy will initiate a set of DNS queries in order to obtain the IP
address of a SIP service in [Link].
3. Because the first proxy is not responsible for anything in [Link], it won’t change anything in
the request-URI. It will, however, add its “Via:” header field (not shown) and forward the
request to the IP address and port it has obtained in (2).
4. The [Link] proxy looks at the request-URI and identifies its own domain. It looks up
“bob@[Link]” in the location database and obtains Bob’s phone IP address and port.
5. The proxy sends an INVITE to Bob’s phone. Though it may not always be necessary, the proxy
may change the request-URI to the one shown. Bob’s phone now knows that the caller is Alice
and her “Contact:” IP address and port are as shown.
6. Responses are sent back through the same chain of proxies, and Alice’s phone now has Bob’s
“Contact:” information.
7. ACK completes the call establishment, media session exists for some time and BYE ends the
call.

Oracle SBC Configuration and Administration 2 - 36

Oracle SBC Configuration and Administration 2 - 37
Oracle SBC Configuration and Administration 2 - 38
A stateless proxy provides the normal forwarding functions but without tracking any events or
keeping any state information in its memory. For example, it does not even associate the 100
TRYING it receives to the INVITE it has sent. It forwards and forgets. Due to this simplicity it is able
to process more calls per unit of time.
Such a proxy cannot perform tasks that require transaction-related or dialog-related information
such as call logging and billing.

Oracle SBC Configuration and Administration 2 - 39

As the title implies, a proxy of this type will track and mark all state transitions of a transaction. As
shown, it will typically respond to an incoming INVITE with a 100 TRYING. After it forwards the
INVITE to the next hop, it expects a response. If the first response happens to be 100 TRYING, it
will just remember its reception without relaying it back, because it already has sent a 100 TRYING
to the initiator. Other responses will be remembered and relayed back. The proxy uses “CSeq:”
and the branch parameter (in the “Via:”) to identify the transaction it is tracking. The proxy is
done once it has relayed back the final response to the original request.
Subsequent transactions are handled the same way. If they belong to the same dialog, the proxy
will be unaware of it.

Oracle SBC Configuration and Administration 2 - 40

A dialog-stateful proxy keeps track of the whole dialog. There is an inherent problem here: When
the dialog creating transaction is complete, the devices (at the two sides of the proxy) know each
other’s “Contact:” information. If these devices choose to proceed with SIP requests and
responses exchanged directly, the proxy will never follow the dialog beyond the first transaction it
has helped to complete. It turns out that the proxy needs to somehow “convince” the two devices
to keep working through the proxy for the entire dialog. This is actually possible if you assume
that the devices are SIP compliant (as they should be). This is how it is done:
The proxy adds a “Record-Route:” header field with its own IP address and port to the request it
relays. This tells the receiving device: “Route the next transactions through me.”
This added header field is copied to the responses and propagates back to the initiating device.
Now the initiating device too knows that it needs to route its next transactions through the proxy.
The device that sends the next request will include a “Route:” header field with the proxy IP
address and port and send it out. If it is sent directly to the same proxy, this header field is not
really used, but if there is another proxy in the way, that proxy will see the “Route:” header field
and route it to our dialog-stateful proxy.

Oracle SBC Configuration and Administration 2 - 41

This example shows what happens in a scenario that involves all proxy types.
First transaction:
An INVITE message is routed; each proxy adds its own “Via:”. The first dialog-stateful proxy, P2,
adds a “Record-Route:” header field. The second dialog-stateful proxy, P3, adds another “Record-
Route:” header field in front of the one that’s already there. The target device, D3, builds an
internal “route set.” Note that all the stateful proxies respond with 100 TRYING and they “absorb”
100 TRYING received from the right hand (“downstream”) side.
180 RINGING and 200 OK flow back as explained before. As soon as the initiating device, D1,
receives the 180 RINGING (or the 200 OK if there is no 180 RINGING) it sees the two “Record-
Route:” header fields and builds a route set internally.
ACK transaction:
D1 adds to the ACK request a “Route:” header field with a list of IP addresses it has learned. The
request is sent to the stateless proxy, P2, which removes the [Link] from the “Route:” header
field and sends the ACK to P6. P6 removes the “Route:” header fields and routes the ACK to D3.
BYE transaction:
D3 adds to the BYE request a “Route:” header field with a list of IP addresses that it has learned.
The request is sent to P6 proxy. P6 removes the [Link] from the “Route:” header field and sends
the BYE to P2. P2 removes the “Route:” header fields and routes the BYE to D1. The response to
the BYE flows back, as usual. Routed by the stack of “Via:” header fields.
Because D1 and D3 acted correctly upon seeing the “Record-Route:”, all the transactions went
through P2 and P6 that are dialog-stateful. None of the “Route:” header fields mentioned [Link],
so P4, which is only transaction-stateful, has been bypassed (except, as usual, in the very first
transaction).

Oracle SBC Configuration and Administration 2 - 42

Oracle SBC Configuration and Administration 2 - 43
A proxy receives a request and relays it out. For this purpose it analyzes the request-URI and
makes some routing decisions. It will add its “Via:” header field, decrement the number in “Max-
Forwards:”, and maybe make some more changes. But the message will be basically the same.
The responses are relayed back, as usual, using the information in the next to the top-most “Via:”.
The B2BUA has, on each side, a UA (UAS-UAC pair). For the external device, this UA represents a
proxy or a target device. The UA, internally, interacts with an application. Depending on many
factors, the application may decide to initiate a call through the other UA where this call can be on
behalf of a call that came in. Comparing the incoming INVITE to the outgoing INVITE, they will be
quite different.
So in the case of a proxy we deal with “relayed” messages, while in the case of a B2BUA we deal
with “re-originated” messages.
By having a suite of application functions between the UAs in the B2BUA, and by the fact that
original and re-originated SIP messages are different, the B2BUA separates, or isolates between
SIP environments. In other words, a B2BUA can function as a “Border Element” and it is, in fact,
the main mechanism in a device called “Session Border Controller” (SBC).

Oracle SBC Configuration and Administration 2 - 44

The B2BUA, being an isolating element between SIP environments, must have at least two
interfaces. In the diagram, they are B2 and B4. The end-device D1 has no idea what a B2BUA is,
and all it cares is that it has a proxy to work with. So B2 really plays the role of D1’s proxy. You can
view this in another way: B2 is like an end-device and a call has been directly established between
D1 and B2 with no help of a proxy between them.
B4 initiates a new INVITE after the first INVITE has been received, analyzed, and processed. B4 is
like a call initiator that establishes a call to D3. This may take the common form where the first
transaction is assisted by a proxy and the subsequent transactions can proceed directly without it.
What becomes evident now is that each of B2 and B4 interfaces “holds” an entire dialog. This, in
fact, implies that a B2BUA is a dialog-stateful entity by nature.

Oracle SBC Configuration and Administration 2 - 45

One of the many important functions a B2BUA can perform is translating explicit IP addresses
that appear in the SIP message. This prevents IP addressing scheme details of one environment
from being known in another environment. The feature is also known as “Topology Hiding.”
The diagram shows how the B2BUA changes explicit IP addresses in the request-URI, Via: and
Contact:. Often a device add its own IP to the Call-ID string to improve its uniqueness. The B2BUA
hides that IP address too by generating a brand new Call-ID.
Similar translations will occur for other requests as well as for the responses.

Oracle SBC Configuration and Administration 2 - 46

Oracle SBC Configuration and Administration 2 - 47
Oracle SBC Configuration and Administration 2 - 48