Network Interface

Configure a Network Interface

Set the following parameters to configure a network interface. The network Realm identifier, VLAN ID, and network IP address cannot repeat across networks. They must be unique for each network.

Access the Network configuration object. Configuration, System Administration, Network, Network Settings.

On the Service page, click Add, and do the following on the Network Settings page:

Name

Add a name for the Network Interface. This is to enable support of multiple Network Interfaces by Communications Broker.

Sub Port ID

Enter the identification of a specific virtual interface in a physical interface (For example, VLAN tag). A value of 0 indicates that this element is not using a virtual interface. The sub-port-id field value is only required if the operation type is Media. You can add a value from o to 4095.

Realm Identifier

Enter the name of this realm for access control.

VLAN ID

Enter the identification of a specific virtual interface in a physical interface, for example, a VLAN tab. If this network interface is not channelized, leave this field blank, and the value will correctly default to 0. The sub-port-id is only required if the operation type is Media. Default: 0. Range: 0-4095.

Hostname

Enter the fully qualified domain name.

Network IP Address

Enter the IPv4 address of this network interface.

Network IP Subnet Mask

Enter the net mask of this network interface in dotted decimal notation.

Network IP Gateway Address

Enter the gateway that this network interface uses to communicate with the next hop. You can set an additional, secondary gateway with the sec-gateway parameter.

Preferred DNS Server IP Address

Enter the IP address of the targeted DNS server.

Alternate DNS Server IP Address

Enter an alternate IP address for the targeted DNS server.

Alternate DNS Server IP Address

Enter an alternate IP address for the targeted DNS server.

DNS Domain

Enter the default domain name.

Enable REFER Termination

Select to terminate and process SIP REFER messages. Default: Disabled.

Send NOTIFY for REFER Provisional Responses

Select which NOTIFY messages for provisional responses you want the system to act on. Default: None. Valid values: None | Initial | All.

Enable ToS Marking

Select to ToS mark egress packets. Default: Disabled.

ToS Value

Set the ToS value to apply to egress packets. Default: 0x00.

HIP IP List

Enter all possible local IP address(es) to which a remote system can send administrative traffic. This parameter specifies addresses that can reply to requests. You must also configure them in a service list, such as ICMP Address, to specify the service to which they can reply. This parameter can accept multiple IP addresses.

ICMP Address

Enter all possible local IP address(es) to which a remote system can ping the Communications Broker and expect replies. You must also configure these addresses to the HIP IP List parameter.

Enable Gateway Heartbeat

For High Availability, check this checkbox to allow the network interface to continually confirm that its gateway is reachable.

High Availability Settings

Use the arrow control to display the HA parameters.

Primary Utility IP Address

Enter the utility IP address for the primary peer to use.

Secondary Utility IP Address

Enter the utility IP address for the secondary peer to use.

Interface Virtual MAC

Enter the virtual MAC address of the interface. (This address moves to which ever peer is active.)

Click OK.
(Optional) Repeat steps 2 and 3 to add another network interface (up to 4 total).
Save the configuration.

Enable ICMP

To configure Internet Control Message Protocol (ICMP) functionality on a media interface, define the IPv4 address on your Oracle Enterprise Communications Broker (Communications Broker) network interface and enable ICMP in Network Settings. Enabling ICMP entries automatically opens the well-known port associated with a service. For security ICMP is disabled buy default, so the Communications Broker discards ICMP requests or responses for the address. Oracle recommends that you enable ICMP only temporarily on a network interface.

Do the following to enable ICMP functionality on a network interface.

Access the Network configuration object. Configuration, System Administration, Network, Network Settings.
Select Enable ICMP to enable ICMP traffic on this network interface, so that the Communications Broker can respond to ICMP pings. Default: Disabled.
Save the configuration.

Configure the Network Interface for High Availability Operations

The Modify Network Settings dialog also includes the High Availability (HA) setting fields, which allow you to manually specify the addressing to be used by this interface for HA operation. Oracle recommends, that you use run setup to configure HA. These fields provide you with another way to configure this addressing.

Scroll through the The Modify Network Settings dialog to locate the addressing fields shown below.
Primary utility IP address—Enter the utility IPv4 address for the primary HA peer. This address can be any unused IPv4 address within the subnet defined for the network interface. For example, given a network interface with the IPv4 address 168.0.4.15/24 (identifying the host associated with the network interface), the possible range of unused IPv4 addresses is 168.0.4.1 to 168.0.4.254. Ask your network administrator which IPv4 addresses are available for use.
Secondary utility IP address—Enter the utility IPv4 address for the secondary Oracle Enterprise Communications Broker peer. Usually, this IPv4 address is the next in the sequence up from the primary utility address. It is also generated from the range of unused IPv4 addresses within the subnet defined for the network interface.

Virtual MAC Addresses

To create an HA node, you create virtual MAC addresses for the media interfaces. You enter these addresses in virtual MAC address parameters for physical interface configurations.

This field is automatically populated with a valid virtual MAC address during run setup. It is recommended that you retain this configuration.

The HA node uses shared virtual MAC (media access control) and virtual IP addresses for the interfaces. When there is a switchover, the standby Oracle Enterprise Communications Broker sends out an ARP message using the virtual MAC address, establishing that MAC on another physical port within the Ethernet switch.

A MAC address is a hardware address that uniquely identifies Oracle Enterprise Communications Broker components. Given that, the virtual MAC address you configure allows the HA node to appear as a single system from the perspective of other network devices. To the upstream router, the MAC and IP are still alive, meaning that existing sessions continue uninterrupted through the standby Oracle Enterprise Communications Broker.

To configure a virtual MAC, enter the virtual MAC address in the Interface virtual MAC field.

Configure a Realm

You can enable and configure a variety of constraints that the Oracle Enterprise Communications Broker (Communications Broker) applies to regulate session activity with the realm.

Access the Realm Config.
Click Configuration, Network, Realm config

On the Realm Config page, click Add, and do the following:

Table 3-2 Realm Config

Fields	Description
Identifier	Enter the name of the realm. This parameter uniquely identifies the realm. You use this parameter in other configurations when asked for a realm identifier value.
Network Interfaces	Enter the physical and network interface(s) that you want this realm to reference. These are the network interfaces though which this realm can be reached by ingress traffic, and through which this traffic exits the system as egress traffic. Enter the name and port in the correct format where the name of the interface comes first and is separated by a colon (:) from the port (VLAN) number. For example, s0p0:0. The parameters you set for the network interfaces must be unique.
Media Realm List	Not Used
Teams FQDN in URI	Not Used
SDP Inactive Only	Not Used
Access Control Trust Level	Indicate the trust level for the host with the realm. The default value is none. The valid values are: none—Host is always untrusted. It is never promoted to the trusted list or demoted to the deny list. low—Host can be promoted to the trusted list or demoted to the deny list. medium—Host can be promoted to the trusted list but is only demoted to untrusted. It is never added to the deny list. high—Host is always trusted.
Invalid Signal Threshold	Enter the number of invalid signaling messages that trigger host demotion. The value you enter here is only valid when the trust level is low or medium. Available values are: Minimum—Zero (0) is disabled. Maximum—999999999 If the number of invalid messages exceeds this value based on the tolerance window parameter, configured in the media manager, the host is demoted. The tolerance window default is 30 seconds. Bear in mind, however, that the system uses the same calculation it uses for specifying "recent" statistics in show commands to determine when the number of signaling messages exceeds this threshold. This calculation specifies a consistent start time for each time period to compensate for the fact that the event time, such as a user running a show command, almost never falls on a time-period's border. This provides more consistent periods of time for measuring event counts. The result is that this invalid signal count increments for two tolerance windows, 60 seconds by default, within which the system monitors whether or not to demote the host. The signal count for the current tolerance window is always added to the signal count of the previous tolerance window and compared against your setting.
Maximum Signal Threshold	Minimum—Zero (0) is disabled. Maximum—999999999 If the number of messages received exceeds this value within the tolerance window, the host is demoted.
Untrusted Signal Threshold	Set the maximum number of untrusted messages the host can send within the tolerance window. Use to configure different values for trusted and un-trusted endpoints for valid signaling message parameters. Also configurable per realm. The default value is 0, disabling this parameter. The valid range is: Minimum—Zero (0) is disabled. Maximum—999999999
Deny Period	Indicate the time period in seconds after which the entry for this host is removed from the deny list. The default value is 30. The valid range is: Minimum—Zero (0) is disabled. Maximum—999999999
Session Max Life Limit	Enter the maximum amount of time in seconds of a session. An additional, special case value of “Unlimited”, is the highest possible value. Minimum—0 (default) Maximum—2073600 Unlimited
Refer Call Transfer	Specifies whether and how to execute a REFER Disabled—Proxy the REFER (default) Enabled—Issue a Re-INVITE to the transfer destination Dynamic—Refer to the target realm to determine whether to proxy or issue a Re-INVITE
Refer Notify Provisional	Provisional mode for sending Notify message. none: No intermediate Notify messages are to be sent. initial: Immediate 100 Trying Notify needs to be sent all: Immediate 100 Trying NOTIFY and plus a NOTIFY for each non-100 provisional received by the SD are to be sent. Default value: None.
Dyn Refer Term	Specify the behavior when a REFER is sent to this realm. Disabled—Proxy the REFER (Default) Enabled—Terminate and issue Re-INVITE
User Site	Not Used
SRVCC Trfo	Not Used

Click OK.
Save the configuration

Configurable TCP Timers

You can configure your Oracle Enterprise Communications Broker to detect failed TCP connections more quickly so that data can be transmitted via an alternate connection before timers expire. Across all protocols, you can now control the following for TCP:

Connection establishment
Data retransmission
Timer for idle connections

These capabilities all involve configuring an options parameter that appears in the network parameters configuration.

Configuring TCP Data Retransmission

TCP is considered reliable in part because it requires that entities receiving data must acknowledge transmitted segments. If data segments go unacknowledged, then they are retransmitted until they are finally acknowledged or until the maximum number of retries has been reached. You can control both the number of times the Oracle Enterprise Communications Broker tries to retransmit unacknowledged segments and the periodic interval (how often) at which retransmissions occur.

You set two new options in the network parameters configuration to specify how many retransmissions are allowed and for how long: atcp-rxmt-interval and atcp-rxmt-count.

To configure TCP data retransmission:

Access the Network configuration object. Configuration, System Administration, Network, Network Parameters.
Options—Set the options parameter by typing the option name atcp-rxmt-interval=x (where x is a value in seconds between 2 and 60) into the Options field. This value will be used as the interval between retransmission of TCP data segments that have not been acknowledged.
Options—Now enter a second option to set the number of times the Oracle Enterprise Communications Broker will retransmit a data segment before it declares the connection failed. Set the options parameter by typing the option name atcp-rxmt-count=x (where x is a value between 4 and 12 representing how many retransmissions you want to enable) into the Options field.
```
atcp-rxmt-interval=30
atcp-rxmt-count=6
```
Save and activate your configuration.

Timer for Idle Connections

When enabled to do so, the Oracle Enterprise Communications Broker monitors inbound TCP connections for inactivity. These are inbound connections that the remote peer initiated, meaning that the remote peer sent the first SYN message. You can configure a timer that sets the maximum amount of idle time for a connection before the system consider the connection inactive. Once the timer expires and the connection is deemed inactive, the system sends a TCP RST message to the remote peer.

To configure the timer for TCP idle connections:

Access the Network configuration object. Configuration, System Administration, Network, Network Parameters.
Options—Set the options parameter by typing option name atcp-idle-timer=x (where x is a value in seconds between 120 and 7200) into the options field. This value will be used to measure the activity of TCP connections; when the inactivity on a TCP connection reaches this value in seconds, the system declares it inactive and drops the session.
```
atcp-idle-timer=120
```
Save and activate your configuration.

Configure the Network Parameters

Set the following parameters to configure network parameters that are common to all network interfaces.

Access the Network configuration object. Configuration, System Administration, Network, Network Parameters.

On the Service page, and do the following on the Network Parameters page:

TCP Keepinit Timer

Enter the TCP connection timeout period if a TCP connection cannot be established. If you have upgraded the release you are running and a value outside of the acceptable range was configured in an earlier release, the default value is used and a log message is generated.

Default: 75
Values: 0-999999999

TCP Keepalive Count

Enter the number of packets the system sends to the remote peer before it terminates the TCP connection.

Default: 4
Values: 0-223-1

TCP Keepalive Idle Timer

Enter the idle time in seconds before triggering keepalive processing. If you have upgraded the release you are running and a value outside of the acceptable range was configured in an earlier release, the default value is used and a log message is generated.

Default: 400
Values: 30-7200

TCP Keepalive Interval Timer

Enter the TCP retransmission time if a TCP connection probe has been idle for some amount of time.

Default: 75
Values: 15-75

TCP Keepalive Mode

Enter the TCP keepalive mode.

Default: 0
Values:
- 0—The sequence number is sent un-incremented.
- 1—The sequence number is sent incremented.
- 2—No packets are sent.
- 3—Send RST (normal TCP operation).

Options

Enter any optional features or parameters.

Click OK.
Save the configuration.

DNS on the Communications Broker

DNS service is best known for providing resolution of internet domain names to IP addresses. Domain names are easy to remember, but connections require IP addresses. DNS deployments can also provide more comprehensive services, if required. For example, the a DNS client may need the resolution of multiple IP addresses to a single domain name, or the types of service provided by a given server. The Communications Broker uses DNS predominantly for resolving FQDNs to IP addresses so that it can support sessions.

When configured, the Communications Broker performs DNS client functions per RFC1034 and RFC1035. The user can define one primary DNS server and two backup DNS servers for the Communications Broker to query a domain for NAPTR (service/port), SRV (FQDN), AAAA (IPv6), and A (IP address) information. A common example of the Communications Broker using DNS is to locate a SIP server via server location discovery, as described in RFC 3263. An applicable context is identifying a callee so the Communications Broker can place a call.

There are multiple reasons for the Communications Broker to query a DNS server. In each case, the Communications Broker follows this high level procedure:

The system determines the egress realm.
The system identifies the egress network interface.
From the egress network interface, the system refers to the configured DNS server(s).
The system issues the DNS query to the primary server, then any configured backup servers, based on the function and the initial information it has.
The system performs recursive lookups or subsequent queries based on, for example, information provided in NAPTR resource responses, until it has one or more resolutions for the FQDN.
The system continues processing using the resolved FQDN(s) or indicates it cannot reach that FQDN.

Note:

DNS queries may require host routes.

DNS Functions on the Communications Broker

The Communications Broker Resolves session agent address when configured with FQDN. Routing to SIP Agents as static IP addresses is not scalable. Leveraging DNS-SRV allows dynamic routing and avoids routing to out of service agents. When configured, the Communications Broker can use RFC 3262 mechanism for balancing traffic to SIP servers. When the response to the DNS query for that hostname yields one or more IP addresses, the Communications Broker stores them in a cache to perform the role of the session agent. By obtaining multiple resolutions, the Communications Broker can then load balance signaling traffic.

The Communications Broker allows you to configure a session agent with an FQDN in the hostname field. When combined with an empty IP address field, the Communications Broker can initiate DNS queries that can result in multiple SRV or A records when triggered by SIP requests. For SRV requests, the Communications Broker uses the priority and weight in the DNS response to load balance. For A records, you configure the Communications Broker to use either the Hunt or Round-Robin strategy for load balancing at the applicable session agent. If there is a failure at the server, and you have enabled DNS load balancing, the Communications Broker queries the secondary server from the pool instead of recursing the request back to the Communications Broker.

The Communications Broker uses the target port number to determine what kind of query to perform, sending SRV requests if the value is 0, and A requests if it is nonzero. The Communications Broker can get this port value from either your agent configuration or from SRV responses from the DNS server.

The Communications Broker can report aggregate statistics of all IP targets that correspond to the session agent object and individual statistics per IP address (including per-method statistics) of each member that the FQDN query returns.

The Communications Broker refreshes its DNS cache when:

The DNS result TTL expires and the new results are different or changed.
The cached target associated with the UE is out of service.

Resolving A and SRV Records

The Communications Broker resolves session-agent FQDNs to either A or SRV records. The type of request is dependent on the port number used in the request. Port zero generates an SRV query and any other port number generates an A query.

You configure a session-agent with port number based on the Communications Broker

Load Balancing A and SRV Records

The Communications Broker achieves A record load balancing through hunt/round-robin strategy and SRV load balancing based on priority and weights received from DNS server response.

The Communications Broker monitors the availability of the dynamically resolved IP addresses obtained from DNS using OPTIONS pings (ping-per-DNS entry). The ping-method and ping-interval for each resolved IP address is copied from the original session-agent. This can be achieved by enabling ping-all-addresses in session-agent configuration. The default of ping-all-addresses is disabled, in which case the Communications Broker only pings the first available resolved IP addresses.

Load Balancing A Records

The Communications Broker performs server resolution for a registering UE starting with a DNS SRV query for a session agent with its port set to 0 and transport method given a setting other than any or *. When it receives a UE’S initial registration message, the Communications Broker performs a DNS SRV query for the next hop target that handles the UE’s signaling. If the SRV target is an FQDN host that then resolves to multiple A RRs, the system then:

If you have configured the load-balance-dns-query parameter to hunt, the Communications Broker selects a single A RR. The Communications Broker always selects the first of several A RRs unless that system goes out of service.
If you have configured the load-balance-dns-query parameter to round-robin, the Communications Broker uses round-robin to select from multiple A RRs for a given SRV target.

By default, the system hunts for and selects a single A RR. If you have configured the dns-load-balance option, then round-robin does not work. This option distributes the requests to IP addresses that are resolved from SRV responses with the same weight and priority. Also, if you enable the session agent ping and set the load-balance-dns-query to round-robin, the Communications Broker pings all IP addresses resolved through the DNS query.

Note that when no session agent exists, the Communications Broker uses standard SRV ordering and A record hunting.

Load Balancing SRV Records

A Service record (SRV record) is a specification of data in the Domain Name System defining the location of servers for specified services as defined in RFC 2782. The SRV record includes contact information in addition to priority and weight fields.

Priority—The priority field determines the precedence of use of the record's data. Client/Customer should use the SRV records with the lowest-numbered priority value first, and fall back to records of higher priority value if the connection fails.
Weight—If a service has multiple SRV records with the same priority value, the Communications Broker load balances them in proportion to the values of their weight fields.

In the following example, both the priority and weight fields are used to provide a combination of load balancing and backup service.

_sip._tcp.provider.com. 86400 IN SRV 5 40 5060 SERVER.provider.com.
_sip._tcp.provider.com. 86400 IN SRV 5 30 5060 server1.provider.com.
_sip._tcp.provider.com. 86400 IN SRV 5 30 5060 server2.provider.com.
_sip._tcp.provider.com. 86400 IN SRV 20 0 5060 backupserver.provider.com.

The first three records share a priority of 5, so the Communications Broker uses the weight field's value to determine which server (host and port combination) to contact. The sum of all three values is 100, so server.example.com will be used 40% of the time.

The Communications Broker uses server1 and server2 for 60% of requests, with half of them sent to server1, and the other half to server2. If SERVER becomes unavailable, the Communications Broker shares the load equally between server1 and server2.

If all three servers with priority 5 are unavailable, the Communications Broker chooses the record with the next lowest priority value, which in this case is backupserver.provider.com.

Load balancing provided by SRV records is inherently limited because the information is static. A server's current load is not taken into account unless TTL values are low enough (around a minute or lower) to allow fast updates to priority or weight values.

Retransmission Logic

The retransmission of DNS queries is controlled by three timers. These timers are derived from the configured DNS timeout value and from underlying logic that the minimum allowed retransmission interval should be 250 milliseconds; and that the Oracle Enterprise Communications Broker should retransmit 3 times before timing out to give the server a chance to respond.

Init-timer is the initial retransmission interval. If a response to a query is not received within this interval, the query is retransmitted. To safeguard from performance degradation, the minimum value allowed for this timer is 250 milliseconds.
Max-timer is the maximum retransmission interval. The interval is doubled after every retransmission. If the resulting retransmission interval is greater than the value of max-timer, it is set to the max-timer value.
Expire-timer: is the query expiration timer. If a response is not received for a query and its retransmissions within this interval, the server will be considered non-responsive and the next server in the list will be tried.

The following examples show different timeout values and the corresponding timers derived from them.

timeout >= 3 seconds
Init-timer = Timeout/11
Max-Timer = 4 * Init-timer
Expire-Timer = Timeout
timeout = 1 second
Init-Timer = 250 ms
Max-Timer = 250 ms
Expire-Timer = 1 sec
timeout = 2 seconds 
Init-Timer = 250 ms
Max-Timer = 650 ms
Expire-Timer = 2sec

DNS-SRV Session Agent Recursion Error Handling

When a session request is sent from the Communications Broker to a session agent, and an error response is received (or a transport failure occurs), the Communications Broker attempts to reroute the message through the list of dynamically resolved IP addresses. The Communications Broker can be configured to resend session requests through the list of IP addresses under more failure conditions.

This feature concerns the case when a session agent is configured with an FQDN in the hostname parameter and the dns-load-balance or ping-all-addresses option is configured. This configuration sets up the load balancing / redundancy behavior for the SBC to use all addresses returned in the SRV/A-record for that session agent. In previous versions of the SBC software, only when a 503 failure from the SA was received would the SBC resend the session request to the next dynamically resolved IP address (on the SRV/A record list).

By adding the recurse-on-all-failures option to a session agent, the Communications Broker will resend a session request to the next address on the list after a 4xx or 5xx failure response has been received from a session agent.

Image shows OECBOCSBC recursing through list of IPs returned for one session agent in DNS query.

If the Communications Broker receives a failure response from the session agent, and the number of that failure is configured in the stop-recurse parameter, no further session requests will be forwarded to additional addresses from the SRV/A record list. The error message will be forwarded back to the UA.

Image shows OECBOCSBC terminating the recursion after it receives an error code listed in the stop-on-recurse parameter.

DNS Transaction Timeout

You can configure a DNS transaction timeout interval on a per network-interface basis using the dns-timeout parameter. As described, you configure the Communications Broker with a primary and two optional backup DNS servers. The Communications Broker queries the primary DNS server. If it does not receive a response within the configured number of seconds, it queries the backup1 DNS server. If that also times out, the Communications Broker contacts the backup2 DNS server.

DNS Server Status via SNMP

The Oracle Enterprise Communications Broker monitors the status of all configured DNS servers used by a SIP daemon. If a DNS server goes down, a major alarm is sent. If all DNS servers used by a SIP daemon are down, a critical alarm is sent. The apAppsDnsServerStatusChangeTrap is sent for both events.

You can poll the status of a DNS server using the apAppsDNSServerStatusTable in the ap-apps.mib.

Once the apAppsDnsServerStatusChangeTrap has been sent, a 30 second window elapses until the server status is checked again. At the 30 second timer expiration, if the server is still down, another trap and alarm are sent. If the server has been restored to service, the apAppsDnsServerStatusChangeClearTrap is sent.

Configure DNS on the Network Interface

DNS configuration includes procedures to the network-interface and session-agent elements.

To make DNS operational, configure addressing that is version compatible to the network-interface address on the network interface itself.

Access the Network configuration object. Configuration, System Administration, Network, Network Settings.

On the Service page, click Add, and do the following on the Network Settings page:

DNS IP Primary

Enter the IP address of the targeted DNS server.

DNS IP Backup1

Enter an alternate IP address for the targeted DNS server.

DNS IP Backup2

Enter an alternate IP address for the targeted DNS server.

DNS Domain

Enter the default domain name.

DNS Timeout

Enter the number of seconds to wait for a DNS response.

DNS Max TTL

Enter the maximum number of hops a query can take.

Save the configuration.

The system performs DNS query procedures with these servers every time processing encounters an FQDN for which the system needs resolution.

Review the ensuing sections and configure DNS components to refine DNS operation to your environment, including interface, realm, session agent, and ENUM operation refinement.