OpenSBC Logo

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
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
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
figure 1.14
Level of verbosity for SIP Logs.   Valid Range is 0-5


[PTRACE Log Level]
Figure 1.15
figure 1.15
Level of verbosity for PTRACE Logs.  Valid Range is 0-5

[Log File Prefix]
Figure 1.18
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
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
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
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
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
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
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
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
figure 1.24
The number of processors to handle the transaction event queue.  The default value is 10.

[Session Thread Count]
Figure 1.25
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
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
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]