Instructions for modifying/creating a SIP Server Table entry are below. To add a SIP Server table, see Managing SIP Server Tables.

  • Multiple entries of the same server type (IP/FQDN or DNS-SRV) can be added to a SIP Server Table, but only one type of server is allowed per table. For example, if you add a SIP Server as DNS-SRV, the other entries in the same table must be specified as DNS-SRV; to add a Server Lookup as IP/FQDN, you must create another table.
  • Only one domain name and protocol are permitted in a SIP Server Table. If the domain name and protocol are used in one entry, they cannot be used in an additional entry in that same table.
  • Only one domain name per SIP Server table can be selected as the Server Host.

Creating an Entry in a SIP Server Table

  1. In the left navigation pane, go to SIP > SIP Server Tables. Click on the desired SIP Server Table.
  2. From the Create SIP Server drop down list, select IP/FQDN or DNS-SRV. The associated configuration screen is displayed.

    Note

    Federated IP addresses and FQDNs specified in a SIP Server Table are whitelisted.

  3. Configure the options. See Field Definitions.

    Click '' on the WebUI screen to configure additional items

    Configuring an Object within an Object


    1. Access a WebUI page that includes a field for a configuration resource with support for object within an object configuration. For example, the SIP Signaling Group Table includes a number of such fields.

    2. Click the field-specific () icon next to a specific object. In the example below, the Call Routing Table field supports object within object configurability:

       

      Signaling Group Table - Example

    3. At the Create window, enter a description for the newly created object.

    4. Click OK.

       

      Create Call Routing Table - Example

    5. The Call Route Table is created. The field is auto-populated with the newly-created table, and the "changed field" is highlighted (i.e., the Call Routing Table field).

       

      Populated Field


Create SIP Server: DNS SRV

Create SIP Server Entry: DNS SRV Screen

Create SIP Server: IP/FQDN

Create SIP Server Entry: IP/FQDN Screen

 

Modifying an Entry in a SIP Server Table

  1. In the left navigation pane, go to SIP > SIP Server Tables.
  2. Select the desired SIP Server Table.
  3. Click the expand ( ) icon next to the entry you wish to modify.
  4. Edit the entry properties as required. See Field Definitions.

Resequencing an Entry in a SIP Server Table

  1. Click the Resequence icon ( ) at the top of the table.
  2. Select the row(s) you want to move.
  3. Click the Move Selected Rows Up ( ) or Move Selected Rows Down ( ) icon to reposition the row(s) in the table.
  4. Click Apply.

Server Host - Field Definitions

Server Host - For IP/FQDN only

Server Lookup

This field is populated automatically when you add a SIP Server table entry and select IP/FQDN Lookup from the Create SIP Server drop down box. IP/FQDN enables the SBC to select the server containing the specified IP address or Fully Qualified Domain Name (FQDN) to which this Signaling Group sends SIP messages.

Priority

Specifies the priority of this server. The priority is used to order the server when more than one is configured. If Load Balancing is configured as Round Robin or First in the SIP Signaling group, the Priority field is not used to determine the priority of the server. See Creating and Modifying SIP Signaling Groups.

Host

Specifies an IP address or Fully Qualified Domain Name (FQDN) to which this Signaling Group sends SIP messages.

If an FQDN is configured all the associated servers are included and used according to the server selection configuration element.

Port

Specifies the port number to which SIP messages are sent.

Protocol

Specifies the protocol to use for sending SIP messages. Valid entry: UDP, TCP, or TLS. Depending upon the entry you select, different configuration options are available. These are noted where necessary.

TLS Profile

If TLS is selected from the Protocol field, this specifies the TLS profile the server will use for secure SIP messages.

Server Host - For DNS SRV only

Server Lookup

This field is populated automatically when you add a SIP Server table entry and select DNS-SRV Lookup from the SIP Server drop down box. DNS SRV enables the SBC to populate SIP server entries in the SIP Server Table based on SRV records (specified by domain, service, and protocol supported). SIP entries are updated automatically as servers change and become available/unavailable.

Host IP Version

Specifies the IP version to which this Signaling Group uses to send messages. Valid entries: IPv4 or IPv6.

Domain Name/FQDN

This field specifies the domain name supported in a SIP server from which the SBC requests information (through the DNS SRV Query).  This field is used in combination with the Service and Protocol fields in the DNS SRV Query to request a list of eligible SIP servers. Valid entry: name of domain (i.e., example.com).

Service Name

This field specifies the service name (i.e., SIP) that will be used in the DNS SRV query. This field defaults to "sip" but can be overwritten with any text string (i.e., sipinernaltls). This field is used in combination with the Domain Name and Protocol fields in the DNS SRV Query to request a list of eligible SIP servers. Valid entry: name of service (i.e., SIP).

Protocol

This field specifies the protocol (i.e, UDP, TCP, or TLS) supported in a SIP Server from which the SBC requests information (through the DNS SRV query). This field is used in combination with the Domain Name and Service Name fields in the DNS SRV Query to request a list of eligible SIP servers. Valid entry: select from the drop down list.

TLS Profile

If TLS is selected in the Protocol field, this specifies the TLS profile the server will use for secure SIP messages.

Remote Authorization and Contacts - Field Definitions

For IP/FQDN entries in SIP Failover mode, when there are multiple SIP Server entries, the configuration in Remote Authorization and Contacts must match the configuration for other SIP Servers.

The Remote Authorization Table and Contact Registration Table configuration is shared between the Primary and Secondary SIP Server entries; only the one provisioned in the Primary SIP Server is used.

Remote Authorization Table

Specifies a Remote Authorization table for this SIP Server from the list of authorization tables defined in the Remote Authorization Tables.The Remote Authorization table is used by a Signaling group when a challenge (401/407) is issued by the server. The table contains a realm, user name, and password. They are used to provide credentials to the server issuing the challenge.

Contact Registrant Table

Specifies a Contact Registration Table for this SIP Server from the list of registration tables defined in the Contact Registrant Tables.

The Contact Registration is used by a Signaling Group to register one or more contacts to a registrar. The contact information contains the SIP address of record and the methods which can be used to establish sessions to this Signaling group. Valid entry: Select from the list of Contact Registrant Tables or select None. If you select a Contact Registrant from the list, the following fields are displayed: Clear Remote Registration on Startup, Contact URI Randomizer, and Stagger Registration.

If Fwd. Reg. After Local Processing is selected as the SIP Mode, the selected SIP Server Table for that same Signaling Group should not be configured with a Contact Registrant Table. The SBC does not support Fwd Reg. After Local Processing and a Contact Registrant Table in the same Signaling Group.

Clear Remote Registration on Startup

Specifies whether Remote Registration is cleared upon startup. When enabled, on power-up a Register with Expires: 0 ("Unregister") is first sent. When complete, a Register with Expires: non-0 ("Register") is sent. Valid entries: True (enables remote registration to be cleared at power-up) or False (disables remote registration from being cleared at power-up). This field is visible only when Contact Registrant Table is set to a value other than None. Default entry: False.

Contact URI Randomizer

Enables the username portion of the Contact URI in the registration for Request-URIs to contain a randomized value. When enabled, this random value is generated and put into the username portion of the Contact-URI of each outgoing Register message. The random user portion is saved and compared to the incoming Invite Request-URIs. If the Prefix of the Request-URI contains Hz1q6R, and there is a match, Hz1q6R is stripped and the remaining number is used to route. If there is not a match, but the first six digits are Hz1q6, the Invite Request-URI is ignored and no response is sent. If Hz1q6R is not contained in the Prefix, the number is sent as-is for routing. This field is visible only when the Contact Registrant Table is set to a value other than None. Valid entries: True (contact URI Randomizer is used) or False (contact URI Randomizer is not used).  Default entry: False.

Stagger Registration

Enables Registration (and Unregistration) Requests to be staggered by one second if more than one Contact Registrant entry is in the Contact table. This field is visible only when Contact Registration Table is set to a configuration other than None. Valid entry: True (registration requests are staggered) or False (registration requests are not staggered). Default entry: False. When Stagger Registration is set to True, the maximum number of contact registrant entries configured should not exceed 500. If more than 500 are entered in configuration, they will be dropped and an ERROR trace is generated.

Stagger Registration does not take effect if the SIP Failover feature is enabled.

Retry Non-Stale Nonce

In 401 message, when stale = false, this field enables the SBC to either set the failed retry timer and re-attempt to send Register with same credentials at expiration (True) or not resend a Register with the same credentials (False). This field is available when a Remote Authorization is selected.

Authorization on Refresh

Enables SIP to remove the Remove an Authorization header from REGISTER requests for refresh/deletion. Valid entry:True (header stays the same) or False (SIP removes Authorization header for refresh/deletion). Default entry: True.

Session URI Validation

Enables the setting for matching the session URI when a user name is randomized as part of the Contact URI Randomizer field (in the Contact URI Randomizer, a random value is generated and put into the username portion of the Contact-URI of each outgoing Register message). The Session URI validation sets the matching requirement for this field. Valid entry: Strict or Liberal.                      

Transport - Field Definitions

Monitor

Specifies the method to monitor server.
  • None: No monitoring of this server occurs.
  • SIP options: An OPTIONS message is sent to the server. When this option is selected, additional configuration items are displayed. These are noted below.

Keep Alive Frequency

Specifies how often, in seconds, the SBC Edge queries the server with an OPTIONS message to determine the server's availability. Visible only when SIP Options is selected from the Monitor field.If the server does not respond, the SBC Edge marks the Signaling Group as down. When the server begins to respond to the OPTIONS messages again, it will be marked as up.

Recover Frequency

Specifies frequency in seconds to check server to determine whether it has become available. Default entry: Anonymous. Visible only when SIP Options is selected from the Monitor field.

Local Username

Local user name of the SBC Edge system. Default entry: Anonymous. Visible only when SIP Options is selected from the Monitor field.

Peer Username

User name of the SIP Server. Visible only when SIP Options is selected from the Monitor field.

Connection Reuse - Field Definitions

The configuration options in this section are available only when when Protocol is set as TCP or TLS.

Reuse

Specifies whether or not sockets will be reused or shared. Select from the drop down list: True (sockets are reused) or False (sockets are shared).

Sockets

Specifies number of re-usable sockets. Valid entry: 1 - 4.

Reuse Timeout

Specifies whether or not a socket will timeout. If set to Limited, the Timeout Limit field is displayed.

Timeout Limit

Specifies the number of minutes that a socket remains connected to the server. This field is displayed only if Protocol is set as TCP or TLS, and Reuse Timeout is set as Limited. Valid entry: 5 - 1440 minutes.

SRV Servers Table - Field Definitions

This table is in view-only mode and available only when the Server Lookup field is set as DNS SRV in the SIP Server Table. To view this table, go to SIP > SIP Server Tables and click on the desired SIP Server Table entry. The populated values in this table are determined by the administrator for the DNS server; ranges and possible values are detailed below.

Server ID

A number generated internally that is used to identify the SIP Server.

FQDN/Domain Name

Based on the response from the DNS SRV Query, the SBC populates this table with the configured SIP server entries (IP or FQDN). The SBC will refresh the server entries by re-trying the same DNS SRV query until the Time to Live for the SRV record expires. This table is updated automatically as servers change and become available/unavailable. 

Protocol

This field specifies the protocol (i.e, UDP, TCP, or TLS) supported in the SIP Server.

Port

Specifies the port number to which SIP messages are sent.

Time to Live

Amount of time the SRV record is able to be retried. This range is dependent on the value sent from the DNS server.

Priority

Priority determines how servers are selected. A server with a lower number priority is selected first. If that server is unavailable, the next server with the higher priority number is selected. Servers with the same priority value are selected based on weight parameter. For more information, see Weight.

Weight

The weight field specifies a relative weight for SIP server entries (range 0 - 65535), which is used to determine the selection of the server if the priority value is the same between two servers. A server with a larger weight is given a higher probability of being selected than a server with a lower weight. The weight selection algorithm is per RFC 2782.