
User
Manual
[Previous]
[Next]
[Contents]
4. HTTP Admin
The HTTP Admin pages
houses all
configurable parameters to control the behavior of OpenSBC.
OpenSBC uses an XML template (oss-application.conf.xml) file
for
the HTTP admin. This file should be present in the same
directory of OpenSBC. The idea behind the xml template is to
automate the addition of new parameters in the config pages without the
need to code anything.
The HTTP Admin automatically generates a corresponding ini file in unix
($(HOME)/.pwlib_config/opensbc.ini and a registry section
(HKEY_LOCAL_MACHINE/Software/opensipstack.org/OpenSBC) in windows based
on the items listed in oss-application.conf.xml template.
4.1
OpenSBC HTTP Admin
Figure 1.12
The HTTP Admin link allows for a user name and password to secure the
HTTP Admin pages from unauthorized access. We strongly
advice
that users set the provide login information to avoid unauthorized
access to OpenSBC configuration. In cases of forgotten
passwords,
you may reset it by deleting the corresponding entries in
($(HOME)/.pwlib_config/opensbc.ini for Unix installations an in
HKEY_LOCAL_MACHINE/Software/opensipstack.org/OpenSBC registry section
for Windows installations. If a password is set for the HTTP
Admin, you browser will prompt for the login information every time you
attempt to access the admin pages. Figure 1.13 shows a login
dialog in Internet Explorer.
Figure 1.13
4.2 OpenSBC General
Parameters
The General parameters section houses global parameters for OpenSBC.
ranging from logging, listeners, modes and signalling behavior.
4.2.1
[Logging]
All OpenSBC logs are stored in $(OPENSBCDIR)/logs directory.
Logs are created each time OpenSBC is lauched and is rotated on a daily
basis. The log filename format is
$(prefix)-YYYY-MM-DD-$(process-id).log. Eg:
b2bua-2007-07-17-3464.log. There are two types of
log
entries in OpenSBC, SIP Logs and PTRACE Logs. PTRACE is used
for
debugging purposes while SIP log displays the library and
application level activities. Configurable parameters related
to
logging are listed below:
[SIP Log Level]
Figure 1.14
Level of verbosity for
SIP Logs. Valid Range is 0-5
[PTRACE Log Level]
Figure 1.15
Level of verbosity for
PTRACE Logs. Valid Range is 0-5
[Log File Prefix]
Figure 1.18
The prefix is
configurable. This is handy during times when its
necessary to run multiple instances of opensbc and you want which log
file belongs to which OpenSBC instance.
4.2.2
[Modes]
The architecture of OpenSBC allows it to act both as a B2BUA, Registrar
and as a pure SIP Proxy. You may control which functionality
you
like by choosing the mode for OpenSBC. Each mode is explained
further below.
[SBC Mode]
Figure 1.16
This is a selection
where you can set the run mode of opensbc. This
parameter would require a restart for the change to take effect.
1.
Full Mode -
By default OpenSBC runs
in full mode exposing its capability both as a relay SIP proxy,
Registrar and as a B2B User Agent. When OpenSBC receives an
INVITE or a REGISTER request it would follow the following procedure to
make a decision how to route a request
** If the Request-URI resolves to a remote domain, the request will be
relayed. If a relay route is available, the request is sent
to
that route. If a relay route is not available, then the URI
is
resolved via DNS.
** If the Startline-URI resolves as a local address and port, the To
URI is checked if it resolves to a local domain and port. If
not,
the request would be proxied using Relay Routes or via DNS resolution.
The Request URI would be rewritten to point to the resolved
route.
** INVITE: If both Request URI and To URI resolves to a local
listener and port, the B2BUA Route is used to route the INVITE.
** REGISTER: If both Request URI and To URI resolves to a local
listener and port, the local Registrar will process the registration.
This would include Authorization of the user.
2. B2BOnly Mode-
This mode removes the relay capability but exposes the Registrar and
the B2BUA functionalities. This mode does not do the checks
performed by Full Mode. It will always process REGISTER and
INVITE as local.
** INVITE: This mode always use B2BUA Route to route calls.
If there is not corresponding route found, a DNS resolutions
is
done against the Request URI or the To URI in case the Request-URI
resolves to a local address.
** REGISTER: Registrations are always handled by the local
registrar.
3. Proxy Only Mode
- This mode removes the B2BUA functionality but exposes Registrar and
the relay SIP Proxy functionalities
** Always uses Relay Routes for all messages including REGISTER.
If a relay route is not configured, Requests will be relayed using DNS
resolution. If a registrations is resolved as local, the
registrar would handle the registration including authorization
4. B2BUpperReg Mode
- This is almost
the same as the B2BOnly mode but with the additional capability of
relaying registrations to upper registrars.
** INVITE: This mode, always uses B2BUA Route.
** REGISTER: For registrations, it performs the Request URI
and
To URI checking and relay for a remote domain or process the
registration locally for local domains.
** Upper-Registration: This mode also has the capability to
hijack-registrations towards upstream registrars
4.2.3
[Listeners]
By default, OpenSBC listens on 5060 for UDP in all available
Interfaces. OpenSBC also provides a means to configure bindings to a
specific address. To do this one must explicitly assign the address of
the interface. The ability of OpenSBC to listen on multiple
interfaces gave it the
powerful capability to bridge calls across distinct networks if
installed on a multi-homed host. Which interface to use for sending
messages is intelligently determined via the OS routing table.
Both SIP and RTP are seamlessly bridged by OpenSBC.
[Interface Address]
Figure 1.19
A list of
specific address where OpenSBC will listen for incoming connections.
By default this is set tp `sip:*:5060` where the `*` character means
`all available interfaces`. To make OpenSBC bind to a specific
interface and port, one must replace the `*` with an actual interface
address. Example: `sip:192.168.0.10:8080`. This will bind opensbc to
only the IP address 192.168.0.10 on port 8080. Take note that the
default listener in 5060 is now replaced by this specific interface
binding. Multiple listeners may be defined for a single instance of
OpenSBC.
4.2.4
[Media]
Audio NAT traversal is achieved by OpenSBC by proxying media between
the NATed UA and the internet. When OpenSBC detects that a call came
from a NATed UA based on the via address, it would automatically proxy
media for the call. OpenSBC also uses the Registration information of
UAs to determine if calls terminating to the UA needs to be media
proxied. It must be noted that proxying media is not always a guarantee
of sucessful NAT traversal for audio. It is required that User Agents
uses the same UDP socket to send and receive RTP packets.
[Always Proxy Media]
Figure 1.17
This parameter tells
OpenSBC to proxy RTP for all calls regardless of whether the the UA is
behind NAT or not.
[Static RTP Media Address]
Figure 1.20
This parameter allows a
static IP address to be sent in SDP instead of
the actual OpenSBC interface bindings. This is useful when OpenSBC
itself is behind a NAT and the router is set to provide it with a one
is to one port mapping.
4.2.5
[Call Transfer]
OpensBC supports blind transfer and attended call
transfer.
There are two types of call transfer procedure
OpenSBC
supports. The first is Pass-through REFER and the second is
Local
REFER. Attended call transfer would only work for
Pass-through
REFER.
[Pass-through REFER]
Pass-through
REFER works by relaying the REFER to the remote UA. The
Refer-To
header is rewritten to point back to OpenSBC while the original
Refer-To header is added as prefix to the User portion of the
Refer-To URI. This way, OpenSBC would always stay
in
between the call legs even if the call is transfered.
OpenSBC
just reconstructs the original Refer-To URI by extracting the prefix
from the User portion of the incoming Request-URI
[Enable Local Refer]
Figure 1.21
Local
REFER will not relay the REFER request. Instead, OpenSBC will
create a new call for the REFER. This is advisable in cases
where user agents do not support REFER directly. Local REFER
would require more processing than Pass-through.
4.2.6
[Encryption]
OpenSBC Supports two types of encryption. These are none
standard
encryption supported by some popular hardware vendors of IP Phones and
ATA's.
[Encryption Mode]
Figure 1.22
1. XOR
encryption uses an extended OR comparison to produce a new hashed
REQUEST. Both SIP messages and RTP packets are hashed when
XOR
encryption is active.
2. DiffShift
encryption uses a simple addition and subtraction to the numeric value
of each character in SIP Messages to produce the hashed request.
RTP will not be hashed if DiffShift mode is in use.
[Encryption Key]
Figure 1.23
This is the hash key
used by the encryption algorithms.
4.2.7
[Event Processors]
OpenSBC is using an event based architecture.
This means
all function calls in OpenSBC are none-blocking. Each
transaction
unit has its own independent event queue. Each
event queue
has a static pool of processors.
[Transaction Thread Count]
Figure 1.24
The number of processors
to handle the transaction event queue. The default value is
10.
[Session Thread Count]
Figure 1.25
The number of processors
to handle session events. The default value is 10
4.2.8
[Timers]
Application timers are exposed to allow custom timeouts
for
alerting and call seizure. This is used by the failover
routing
functionality.
[Alerting Timeout]
Figure 1.26

The amount of time in
seconds the
call would wait for an alerting packet. This can be any none
100
provisional response such as 180 and 183.
[Seize Timeout]
Figure 1.27

The amount of time in
seconds the call would wait for a 200 OK.
4.3 Trusted Domains
4.4 Privacy (RFC 3325)
4.5 Local Domain Accounts
4.6 B2BUA Routes
4.7 Relay Routes
4.8 Upper Registration Routes
4.9 Internal DNS Mapping
4.10 Media Server
4.11 OpenSBC Registration Status
4.12 OpenSBC Resource Counters
[Previous]
[Next]
[Contents]