Proxy, Registration and Authentication Parameters

The proxy server, registration and authentication SIP parameters are described in the table below.

Proxy, Registration and Authentication SIP Parameters

Parameter

Description

'Use Default Proxy'

configure voip > sip-definition proxy-and-registration > enable-proxy

[IsProxyUsed]

Enables the use of Proxy Set ID 0 (for backward compatibility).

[0] No = (Default) Proxy Set 0 is not used.
[1] Yes = Proxy Set ID 0 is used.

Note:

The parameter must be used only for backward compatibility. If not required for backward compatibility, make sure that the parameter is disabled and use the Proxy Sets table for configuring all your Proxy Sets (except for Proxy Set #0).
If you are not using a proxy server, you must configure routing rules to route the call.
The parameter is applicable only to the Gateway application.

'Proxy Name'

configure voip > sip-definition proxy-and-registration > proxy-name

[ProxyName]

Defines the Home Proxy domain name. If specified, this name is used as the Request-URI in REGISTER, INVITE and other SIP messages, and as the host part of the To header in INVITE messages. If not specified, the Proxy IP address is used instead.

The valid value is a string of up to 49 characters.

Note: The parameter functions together with the [UseProxyIPasHost] parameter.

'Use Proxy IP as Host'

configure voip > sip-definition proxy-and-registration > use-proxy-ip-as-host

[UseProxyIPasHost]

Enables the use of the proxy server's IP address (in dotted-decimal notation) as the host name in SIP From and To headers in REGISTER requests.

[0] Disable (default)
[1] Enable

If the parameter is disabled and the device registers to an IP Group (i.e., proxy server), it uses the string configured by the ProxyName parameter as the host name in the REGISTER's Request-URI and uses the string configured by the IP Groups table parameter, SIPGroupName as the host name in the To and From headers. If the IP Group is configured with a Proxy Set that has multiple IP addresses, all the REGISTER messages sent to these proxies are sent with the same host name.

Note: If the parameter is disabled and the ProxyName parameter is not configured, the proxy's IP address is used as the host name in the REGISTER Request-URI.

configure voip > sip-definition proxy-and-registration > use-rand-user

[UseRandomUser]

Enables the device to assign a random string value for the user part of the SIP Contact header in the REGISTER message (generated by the device) for new user Account registrations with the device.

The string includes letters and may include numbers, but it always begins with a letter. The string is unique to each Account. An example of a randomly assigned user part is shown (in bold) below:

Contact: <sip:HRaNEmZnfX6xZl4@pc33.atlanta.com>

[0] = (Default) Disable.
[1] = Enable. The device generates one unique string for the user part per Account. Each Account registers with its unique user part string. All INVITE messages for this new Account are sent with this unique user part. This same unique user part string is also used for registration refreshes and for un-registering the Account.
[2] = Enable per registration. The device generates a new string for the user part for each REGISTER message sent for the Account, including initial registration as well as registration refreshes.

The device stops using the random user part in the following scenarios:

The user sends an unregister request.
The device sends a REGISTER request for the user, but doesn't receive a SIP 200 OK in response.
The parameter is disabled. When enabled again, new random user parts are assigned to the Accounts.

To configure Accounts, see Configuring Registration Accounts.

'Redundancy Mode'

configure voip > sip-definition proxy-and-registration > redundancy-mode

[ProxyRedundancyMode]

Determines whether the device switches back to the primary Proxy after using a redundant Proxy.

[0] Parking = (Default) The device continues working with a redundant (now active) Proxy until the next failure, after which it works with the next redundant Proxy.
[1] Homing = The device always tries to work with the primary Proxy server (i.e., switches back to the primary Proxy whenever it's available).

Note: To use this Proxy Redundancy mechanism, you need to enable the keep-alive with Proxy option, by setting the parameter EnableProxyKeepAlive to 1 or 2.

'Proxy IP List Refresh Time'

configure voip > sip-definition proxy-and-registration > proxy-ip-lst-rfrsh-time

[ProxyIPListRefreshTime]

Defines the interval (in seconds) at which the device performs DNS resolution for Proxy Sets that are configured with an FQDN (host name) to translate (resolve) it into IP addresses. The device maintains a cache of DNS resolutions, and will use cached responses as long as the TTL has not expired. If the TTL is expired, a new DNS request is sent to the DNS server.

For example, if configured to 60, the device queries the DNS server every 60 seconds. If successful, the device refreshes the Proxy Set’s list of DNS-resolved IP addresses.

The valid value is 0, or 5 to 2,000,000. The default is 60. The value 0 disables periodic DNS queries and DNS resolution is done only once - upon device restart, device power up, or new and modified configuration.

The device caches the DNS-resolved IP addresses of the last successful DNS query of a Proxy Set, which is used if the DNS server goes offline. This functionality occurs regardless of the setting of the [DNSCache] parameter.

configure network > network-settings > dns-cache

[DNSCache]

Enables the device to cache (store) DNS-resolved IP addresses of the last successful DNS query of entities (e.g., for Remote Web Services, Access List, and LDAP servers) that are configured with an FQDN. The device clears every entry in the cache 30 minutes after their DNS time-to-live (TTL) value expires.

When enabled and the DNS server doesn't respond (for whatever reason) to the device's DNS query request, instead of taking the entity offline, the device reuses the cached DNS-resolved addresses, thereby maintaining call service. In such a scenario, the device continues to query the DNS server every 10 seconds. However, if the DNS server is still not responding after the device has cleared the cached DNS-resolved IP addresses, the device considers the entity as offline.

[0] Disable
[1] Enable (default)

'Enable Fallback to Routing Table'

configure voip > sip-definition proxy-and-registration > fallback-to-routing

[IsFallbackUsed]

Enables the device to fallback to the Tel-to-IP Routing table for call routing when proxy servers are unavailable.

[0] Disable (default)
[1] Enable = When proxy servers are unavailable, the device uses the Tel-to-IP Routing table for routing the call. When the device falls back to the Tel-to-IP Routing table, it continues scanning for an online Proxy. If the device locates an online Proxy, it switches from internal routing back to Proxy routing.

Note: To enable the redundant Proxy mechanism, configure the [EnableProxyKeepAlive] parameter to 1 or 2.

'Prefer Routing Table'

configure voip > sip-definition proxy-and-registration > prefer-routing-table

[PreferRouteTable]

Enables the device to route calls according to the Tel-to-IP Routing table instead of Proxy server.

[0] No = (Default) Only a Proxy server is used to route calls.
[1] Yes = The device checks the routing rules in the Tel-to-IP Routing table for a match with the Tel-to-IP call. Only if a match is not found is a Proxy used.

'Always Use Proxy'

configure voip > sip-definition proxy-and-registration > always-use-proxy

[AlwaysSendToProxy]

Enables the device to send SIP requests and responses through a Proxy server.

[0] Disable = (Default) Uses standard SIP routing rules.
[1] Enable = Sends all SIP requests and responses to the Proxy server.

Note: The parameter is applicable only if a Proxy server is used (i.e., [IsProxyUsed] parameter is configured to 1).

'SIP ReRouting Mode'

configure voip > sip-definition proxy-and-registration > sip-rerouting-mode

[SIPReroutingMode]

Defines the routing mode after call redirection (i.e., a 3xx SIP response is received) or call transfer (i.e., a SIP REFER request is received).

[0] Standard = (Default) INVITE messages that are generated as a result of Transfer or Redirect are sent directly to the URI, according to the Refer-To header in the REFER message, or Contact header in the 3xx response.
[1] Proxy = Sends a new INVITE to the Proxy. If the INVITE sent to the Proxy fails, the device re-routes the call according to Standard.
Note: This option is applicable only if a Proxy server is used and the [AlwaysSendtoProxy] parameter is configured to 0.
[2] Routing Table = The device uses the Routing table to locate the destination and then sends a new INVITE to this destination. If the INVITE fails, the device re-routes the call according to Standard. If DNS resolution fails, the device attempts to route the call to the Proxy. If routing to the Proxy also fails, the Redirect/Transfer request is rejected.

Note:

The parameter is applicable only to the Gateway application.
If the parameter is configured to Routing Table, you can use the [XferPrefix] parameter to configure different routing rules for redirect calls.
The parameter is disregarded if the [AlwaysSendToProxy] parameter is configured to 1.

'DNS Query Type'

configure voip > sip-definition proxy-and-registration > dns-query

[DNSQueryType]

Enables the use of DNS Naming Authority Pointer (NAPTR) and Service Record (SRV) queries to resolve Proxy and Registrar servers and to resolve all domain names that appear in the SIP Contact and Record-Route headers.

[0] A-Record = (Default) No NAPTR or SRV queries are performed.
[1] SRV = If the Proxy/Registrar IP address parameter, Contact/Record-Route headers, or IP address configured in the routing tables contain a domain name, an SRV query is performed. The device uses the first host name received from the SRV query. The device then performs a DNS A-record query for the host name to locate an IP address.
[2] NAPTR = An NAPTR query is performed. If it is successful, an SRV query is sent according to the information received in the NAPTR response. If the NAPTR query fails, an SRV query is performed according to the configured transport type.

Note:

If the Proxy/Registrar IP address parameter, the domain name in the Contact/Record-Route headers, or the IP address configured in the routing tables contain a domain name with a port definition, the device performs a regular DNS A-record query.
If a specific Transport Type is configured, a NAPTR query is not performed.
To enable NAPTR/SRV queries for Proxy servers only, use the global parameter ProxyDNSQueryType, or use the Proxy Sets table.

'Proxy DNS Query Type'

configure voip > sip-definition proxy-and-registration > proxy-dns-query

[ProxyDNSQueryType]

Global parameter that defines the DNS query record type for resolving the Proxy server's configured domain name (FQDN) into an IP address.

[0] A-Record = (Default) A-record DNS query.
[1] SRV = If the Proxy IP address parameter contains a domain name without port definition (e.g., ProxyIP = domain.com), an SRV query is performed. The SRV query returns up to four Proxy host names and their weights. The device then performs DNS A-record queries for each Proxy host name (according to the received weights) to locate up to four Proxy IP addresses. Thus, if the first SRV query returns two domain names and the A-record queries return two IP addresses each, no additional searches are performed.
[2] NAPTR = NAPTR query is done. If successful, an SRV query is sent according to the information received in the NAPTR response. If the NAPTR query fails, an SRV query is done according to the configured transport type. If the Proxy IP address parameter contains a domain name with port definition (e.g., ProxyIP = domain.com:5080), the device performs a regular DNS A-record query. If a specific Transport Type is defined, a NAPTR query is not performed.

Note:

This feature can be configured per Proxy Set in the Proxy Sets table (see Configuring Proxy Sets).
When enabled, NAPTR/SRV queries are used to discover Proxy servers even if the parameter DNSQueryType is disabled.

'Use Gateway Name for OPTIONS'

configure voip > sip-definition proxy-and-registration > use-gw-name-for-opt

[UseGatewayNameForOptions]

Defines if the device's IP address, proxy's IP address, or device's name is used as the host part for the Request-URI in keep-alive SIP OPTIONS messages sent to the proxy (if enabled). The device uses the OPTIONS messages as a keep-alive with its primary and redundant SIP proxy servers. Proxy keep-alive by SIP OPTIONS is enabled per Proxy Set, by configuring the 'Proxy Keep-Alive' parameter to Using OPTIONS (see Configuring Proxy Sets).

[0] No = (Default) The device's IP address is used in the keep-alive OPTIONS messages.
[1] Yes = The device's name, configured by the [SIPGatewayName] parameter, is used in the keep-alive OPTIONS messages.
[2] Server = The proxy's IP address is used in the SIP From and To headers in the keep-alive OPTIONS messages.

configure voip > sip-definition proxy-and-registration > failed-options-retry-time

[FailedOptionsRetryTime]

Defines how long the device waits (in seconds) before re-sending a SIP OPTIONS keep-alive message to the proxy after the device considers the proxy as offline. It considers the proxy as offline after all the device's retransmissions (configured by the Proxy Set parameter 'Failure Detection Retransmissions') have failed.

The valid value range is 1 to 3600. The default is 1.

Note:

The parameter is applicable only if you enable proxy keep-alive by SIP OPTIONS messages (i.e., 'Proxy Keep-Alive' parameter configured to Using OPTIONS in the Proxy Sets table).
A failed SIP response is either no response, or a response that is specified by the Proxy Sets table parameter 'Keep-Alive Failure Responses'.

configure voip > sbc settings > abort-retries-on-icmp-error

[AbortRetriesOnICMPError]

When using UDP as the transport protocol, the device retries failed transmissions to a proxy server according to the Proxy Set parameter 'Failure Detection Retransmissions'. However, when the failed attempt receives an ICMP error (which indicates Host Unreachable or Network Unreachable) as opposed to a timeout, it may be desirable to abandon additional retries in favor of trying the next IP address (proxy server) in the Proxy Set. This is often desirable when Proxy Hot Swap is enabled.

[0] = Disable. The device retries the same proxy according to the Proxy Set parameter 'Failure Detection Retransmissions' (regardless of error response type).
[1] = (Default) Enable. Upon the receipt of an ICMP error response, the device doesn't try the proxy again (i.e., ignores the Proxy Set parameter 'Failure Detection Retransmissions'), but instead tries the next proxy in the Proxy Set.

'User Name'

configure voip > sip-definition proxy-and-registration > user-name-4-auth

[UserName]

Defines the username for registration and Basic/Digest authentication with a Proxy/Registrar server.

The valid value is a string of up to 60 characters. By default, no value is defined.

Note:

The parameter is applicable only to the Gateway application.
The parameter is applicable only if single device registration is used (i.e., 'Registration Mode' parameter is configured to Per Gateway [AuthenticationMode]).
Analog interfaces: Instead of configuring the parameter, the Authentication table can be used (see Authentication).

'Password'

configure voip > sip-definition proxy-and-registration > auth-password

[AuthPassword]

Defines the password for Basic/Digest authentication with a Proxy/Registrar server. A single password is used for all device ports.

The default is 'Default_Passwd'.

Note:

The parameter cannot be configured with wide characters.

'Cnonce'

configure voip > sip-definition proxy-and-registration > cnonce-4-auth

[Cnonce]

Defines the Cnonce string used by the SIP server and client to provide mutual authentication.

The value is free format, i.e., 'Cnonce = 0a4f113b'. The default is 'Default_Cnonce'.

'Challenge Caching Mode'

configure voip > sip-definition proxy-and-registration > challenge-caching

[SIPChallengeCachingMode]

Enables local caching of SIP message authorization challenges from Proxy servers.

The device sends the first request to the Proxy without authorization. The Proxy sends a 401/407 response with a challenge for credentials. The device saves (caches) the response for further uses. The device sends a new request with the appropriate credentials. Subsequent requests to the Proxy are automatically sent with credentials (calculated from the saved challenge). If the Proxy doesn't accept the new request and sends another challenge, the old challenge is replaced with the new one. One of the benefits of the feature is that it may reduce the number of SIP messages transmitted through the network.

[0] None = (Default) Challenges are not cached. Every new request is sent without preliminary authorization. If the request is challenged, a new request with authorization data is sent.
[1] INVITE Only = Challenges issued for INVITE requests are cached. This prevents a mixture of REGISTER and INVITE authorizations.
[2] Full = Caches all challenges from the proxies.

Note:

Challenge caching is used with all proxies and not only with the active one.
For the Gateway application: The challenge can be cached per endpoint or per Account.
For the SBC application: The challenge can be cached per Account or per user whose credentials are configured in the SBC User Information table.

Registrar Parameters

'Enable Registration'

configure voip > sip-definition proxy-and-registration > enable-registration

[IsRegisterNeeded]

Enables the device to register to a Proxy/Registrar server.

[0] Disable = (Default) The device doesn't register to Proxy/Registrar server.
[1] Enable = The device registers to Proxy/Registrar server when the device is powered up and at every user-defined interval (configured by the parameter RegistrationTime).

Note:

The parameter is applicable only to the Gateway application.
The device sends a REGISTER request for each channel or for the entire device (according to the 'Registration Mode' parameter).

'Registrar Name'

configure voip > sip-definition proxy-and-registration > registrar-name

[RegistrarName]

Defines the Registrar domain name. If specified, the name is used as the Request-URI in REGISTER messages. If it isn't specified (default), the Registrar IP address, or Proxy name or IP address is used instead.

The valid range is up to 100 characters.

Note: The parameter is applicable only to the Gateway application.

'Registrar IP Address'

configure voip > sip-definition proxy-and-registration > ip-addrr-rgstrr

[RegistrarIP]

Defines the IP address (or FQDN) and port number (optional) of the Registrar server. The IP address is in dotted-decimal notation, e.g., 201.10.8.1:<5080>.

Note:

The parameter is applicable only to the Gateway application.
If not specified, the REGISTER request is sent to the primary Proxy server.
When a port number is specified, DNS NAPTR/SRV queries aren't performed, even if the parameter DNSQueryType is set to 1 or 2.
If the parameter RegistrarIP is set to an FQDN and is resolved to multiple addresses, the device also provides real-time switching (hotswap mode) between different Registrar IP addresses (the parameter IsProxyHotSwap is set to 1). If the first Registrar doesn't respond to the REGISTER message, the same REGISTER message is sent immediately to the next Proxy. To allow this mechanism, the parameter EnableProxyKeepAlive must be set to 0.
When a specific transport type is defined using the parameter RegistrarTransportType, a DNS NAPTR query is not performed even if the parameter DNSQueryType is set to 2.

'Registrar Transport Type'

configure voip > sip-definition proxy-and-registration > registrar-transport

[RegistrarTransportType]

Determines the transport layer used for outgoing SIP dialogs initiated by the device to the Registrar.

[-1] Not Configured (default)
[0] UDP
[1] TCP
[2] TLS

Note:

The parameter is applicable only to the Gateway application.
When set to ‘Not Configured’, the value of the parameter SIPTransportType is used.

'Registration Time'

configure voip > sip-definition proxy-and-registration > registration-time

[RegistrationTime]

Defines the time interval (in seconds) for registering to a Proxy server. The value is used in the SIP Expires header. The parameter also defines the time interval between Keep-Alive messages when the parameter EnableProxyKeepAlive is set to 2 (REGISTER).
Typically, the device registers every 3,600 sec (i.e., one hour). The device resumes registration according to the parameter RegistrationTimeDivider.

The valid range is 10 to 2,000,000. The default is 180.

'Re-registration Timing [%]'

configure voip > sip-definition proxy-and-registration > re-registration-timing

[RegistrationTimeDivider]

Defines the re-registration timing (in percentage). The timing is a percentage of the re-register timing set by the Registrar server.

The valid range is 50 to 100. The default is 50.

For example: If the parameter is set to 70% and the Registration Expires time is 3600, the device re-sends its registration request after 3600 x 70% (i.e., 2520 sec).

Note: The parameter may be overridden if the parameter RegistrationTimeThreshold is greater than 0.

'Registration Retry Time'

configure voip > sip-definition proxy-and-registration > registration-retry-time

[RegistrationRetryTime]

Defines the time interval (in seconds) after which a registration request is re-sent if registration fails with a 4xx response or if there is no response from the Proxy/Registrar server.

The default is 30 seconds. The range is 10 to 3600.

Note: Registration retry time can also be configured with the MaxRegistrationBackoffTime parameter.

'Max Registration Backoff Time'

configure voip > sip-definition proxy-and-registration > max-registration-backoff-time

[MaxRegistrationBackoffTime]

Defines a dynamic time-to-wait interval before the device attempts to register the SIP entity again after a registration failure. The parameter is applicable only to registrations initiated by the device on behalf of SIP entities (for example, User Info, Accounts, Endpoints or the device itself) with a SIP proxy server (registrar).

The valid value is 0 to 3000000 (i.e., 3 million seconds). The default is 0 (i.e., disabled).

In contrast to the RegistrationRetryTime parameter, which defines a fixed time to wait between registration attempts due to registration failure, this parameter configures the device to increase the time-to-wait interval for each subsequent registration attempt (per RFC 5626, Section 4.5) for a specific registration flow. In other words, the interval changes between registration attempts.

The parameter operates together with the RegistrationRetryTime parameter. When the MaxRegistrationBackoffTime parameter is configured, the wait-time before another registration attempt increases after each failed registration (until it reaches the maximum value specified by the parameter).

The device uses the following algorithm to calculate the incremental augmented wait-time between each registration attempt:

Wait Time = min (max-time, (base-time * (2 ^ consecutive-failures)))

Where:

max-time is the value configured by MaxRegistrationBackoffTime
base-time is the value configured by RegistrationRetryTime

For example, if max-time is 1800 seconds and base-time is 30 seconds, and there were three consecutive registration failures, then the upper-bound wait time is the minimum of (1800, 30*(2^3)), which is (1800, 240) and thus, the minimum of the two values is 240 (seconds). The actual time the device waits before retrying registration is computed by a uniform random time between 50% and 100% of the upper-bound wait time (e.g., for an upper-bound wait-time of 240, the actual wait-time is between 120 and 240 seconds). As can be seen from the algorithm, the upper-bound wait time can never exceed the value of the MaxRegistrationBackoffTime parameter.

'Registration Time Threshold'

configure voip > sip-definition proxy-and-registration > registration-time-thres

[RegistrationTimeThreshold]

Defines a threshold (in seconds) for re-registration timing. If the parameter is greater than 0, but lower than the computed re-registration timing (according to the parameter RegistrationTimeDivider), the re-registration timing is set to the following: timing set by the Registration server in the SIP Expires header minus the value of the parameter RegistrationTimeThreshold.

The valid range is 0 to 2,000,000. The default is 0.

'Re-register On INVITE Failure'

configure voip > sip-definition proxy-and-registration > reg-on-invite-fail

[RegisterOnInviteFailure]

Enables immediate re-registration if no response is received for an INVITE request sent by the device.

[0] Disable (default)
[1] Enable = The device immediately expires its re-registration timer and commences re-registration to the same Proxy upon any of the following scenarios:
The response to an INVITE request is 407 (Proxy Authentication Required) without an authentication header included.
The remote SIP UA abandons a call before the device has received any provisional response (indicative of an outbound proxy server failure).
The remote SIP UA abandons a call and the only provisional response the device has received for the call is 100 Trying (indicative of a home proxy server failure, i.e., the failure of a proxy in the route after the outbound proxy).
The device terminates a call due to the expiration of RFC 3261 Timer B or due to the receipt of a 408 (Request Timeout) response and the device has not received any provisional response for the call (indicative of an outbound proxy server failure).
The device terminates a call due to the receipt of a 408 (Request Timeout) response and the only provisional response the device has received for the call is the 100 Trying provisional response (indicative of a home proxy server failure).

Note: The parameter is applicable only to the Gateway application.

'ReRegister On Connection Failure'

configure voip > sip-definition proxy-and-registration > reg-on-conn-failure

[ReRegisterOnConnectionFailure]

Enables the device to perform SIP re-registration upon TCP/TLS connection failure.

[0] Disable (default)
[1] Enable

'Gateway Registration Name'

configure voip > sip-definition proxy-and-registration > gw-registration-name

[GWRegistrationName]

Defines the user part in the From and To headers in SIP REGISTER messages. If no value is specified (default) for the parameter, the [UserName] parameter is used instead.

Note:

The parameter is applicable only to the Gateway application.
The parameter is applicable only for single registration per device (i.e., 'Registration Mode' parameter is configured to Per Gateway [AuthenticationMode]). When the device registers each channel separately (i.e., 'Registration Mode' parameter configured to Per Endpoint), the username is set to the channel's phone number.

'Registration Mode'

configure voip > sip-definition proxy-and-registration > authentication-mode

[AuthenticationMode]

Defines the device's registration and authentication method.

[0] Per Endpoint = The device registers and authenticates each
[1] Per Gateway = (Default) Single registration and authentication is done for the entire device. This is typically used for digital interfaces.

Note:

The parameter is applicable only to endpoints that are either not associated with any row configured in the Trunk Group Settings table, or are associated with a row and the row's 'Registration Mode' parameter is not configured (see Configuring Trunk Group Settings).
The parameter is applicable only to the Gateway application.

'Set Out-Of-Service On Registration Failure'

configure voip > sip-definition proxy-and-registration > set-oos-on-reg-failure

[OOSOnRegistrationFail]

Enables setting the trunk, or entire device (i.e., all endpoints) to out-of-service if registration fails.

[0] Disable (default)
[1] Enable

If registration is per endpoint (i.e., 'Registration Mode' parameter is configured to Per Endpoint) or per Account (see Configuring Trunk Group Settings) and a specific endpoint/Account registration fails (SIP 4xx or no response), then that endpoint is set to out-of-service until a success response is received in a subsequent registration request. If registration is per the entire device (i.e., 'Registration Mode' parameter is configured to Per Gateway) and registration fails, all endpoints are set to out-of-service. If all the Accounts of a specific Trunk Group fail registration and if the Trunk Group comprises a complete trunk, then the entire trunk is set to out-of-service.

Note:

The parameter is applicable only to the Gateway application.

'Register By Served Trunk Group Status'

configure voip > gateway advanced > register-by-served-tg-status

[RegisterByTrunkGroupStatus]

Defines if the device sends a registration request (SIP REGISTER) to a Serving IP Group (SIP registrar), based on the Trunk Group's status (in-service or out-of-service).

[0] Register Only if In-Service = (Default) The device sends a registration request only if the Trunk Group's status is in-service.
[1] Register Always = The device sends a registration request regardless of the Trunk Group's status (in-service or out-of-service). For example, even if the Trunk Group is configured, but its E1/T1 PSTN cable has yet to be connected to the device (i.e., out-of-service), the device still sends a registration request.

Note:

The parameter is applicable only to the Gateway application (ISDN PRI and CAS).
The parameter is applicable only if the Trunk Group's 'Registration Mode' parameter in the Trunk Group Settings table is configured to Per Account (see Configuring Trunk Group Settings).

configure voip > sip-definition proxy-and-registration > expl-un-reg

[UnregistrationMode]

Enables the device to perform explicit unregisters.

[0] Disable (default)
[1] Enable = The device sends an asterisk ("*") value in the SIP Contact header, instructing the Registrar server to remove all previous registration bindings. The device removes SIP User Agent (UA) registration bindings in a Registrar, according to RFC 3261. Registrations are soft state and expire unless refreshed, but they can also be explicitly removed. A client can attempt to influence the expiration interval selected by the Registrar. A UA requests the immediate removal of a binding by specifying an expiration interval of "0" for that contact address in a REGISTER request. UA's should support this mechanism so that bindings can be removed before their expiration interval has passed. Use of the "*" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record (AOR) without knowing their precise values.

Note: The REGISTER-specific Contact header field value of "*" applies to all registrations, but it can only be used if the Expires header field is present with a value of "0".

'Add Empty Authorization Header'

configure voip > sip-definition settings > add-empty-author-hdr

[EmptyAuthorizationHeader]

Enables the inclusion of the SIP Authorization header in initial registration (REGISTER) requests sent by the device.

[0] Disable (default)
[1] Enable

The Authorization header carries the credentials of a user agent (UA) in a request to a server. The sent REGISTER message populates the Authorization header with the following parameters:

username - set to the value of the private user identity
realm - set to the domain name of the home network
uri - set to the SIP URI of the domain name of the home network
nonce - set to an empty value
response - set to an empty value

For example:

Authorization: Digest username=alice_private@home1.net, realm=”home1.net”, nonce=””, response=”e56131d19580cd833064787ecc”

Note: This registration header is according to the IMS 3GPP TS24.229 and PKT-SP-24.220 specifications.

'Add initial Route Header'

configure voip > sip-definition proxy-and-registration > add-init-rte-hdr

[InitialRouteHeader]

Enables the inclusion of the SIP Route header in initial registration or re-registration (REGISTER) requests sent by the device.

[0] Disable (default)
[1] Enable

When the device sends a REGISTER message, the Route header includes either the Proxy's FQDN, or IP address and port according to the configured Proxy Set, for example:

Route: <sip:10.10.10.10;lr;transport=udp>

or

Route: <sip: pcscf-gm.ims.rr.com;lr;transport=udp>

configure voip > sip-definition proxy-and-registration > ping-pong-keep-alive

[UsePingPongKeepAlive]

Enables the use of the carriage-return and line-feed sequences (CRLF) Keep-Alive mechanism, according to RFC 5626 “Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)” for reliable, connection-orientated transport types such as TCP.

[0] Disable (default)
[1] Enable

The SIP user agent/client (i.e., device) uses a simple periodic message as a keep-alive mechanism to keep their flow to the proxy or registrar alive (used for example, to keep NAT bindings open). For connection-oriented transports such as TCP/TLS this is based on CRLF. This mechanism uses a client-to-server "ping" keep-alive and a corresponding server-to-client "pong" message. This ping-pong sequence allows the client, and optionally the server, to tell if its flow is still active and useful for SIP traffic. If the client doesn't receive a pong in response to its ping, it declares the flow “dead” and opens a new flow in its place. In the CRLF Keep-Alive mechanism the client periodically (defined by the PingPongKeepAliveTime parameter) sends a double-CRLF (the "ping") then waits to receive a single CRLF (the "pong"). If the client doesn't receive a "pong" within an appropriate amount of time, it considers the flow failed.

Note: The device sends a CRLF message to the Proxy Set only if the Proxy Keep-Alive feature (EnableProxyKeepAlive parameter) is enabled and its transport type is set to TCP or TLS. The device first sends a SIP OPTION message to establish the TCP/TLS connection and if it receives any SIP response, it continues sending the CRLF keep-alive sequences.

configure voip > sip-definition proxy-and-registration > ping-pong-keep-alive-time

[PingPongKeepAliveTime]

Defines the periodic interval (in seconds) after which a “ping” (double-CRLF) keep-alive is sent to a proxy/registrar, using the CRLF Keep-Alive mechanism.

The default range is 5 to 2,000,000. The default is 120.

The device uses the range of 80-100% of this user-defined value as the actual interval. For example, if the parameter value is set to 200 sec, the interval used is any random time between 160 to 200 seconds. This prevents an “avalanche” of keep-alive by multiple SIP UAs to a specific server.

'Max Generated Register Rate'

configure voip > sip-definition proxy-and-registration > max-gen-reg-rate

[MaxGeneratedRegistersRate]

Defines the maximum number of user register requests (REGISTER messages) that the device sends (to a proxy or registrar server) at a user-defined rate configured by the [GeneratedRegistersInterval] parameter. The parameter is useful in that it may be used to prevent an overload on the device's CPU caused by sending many registration requests at a given time.

The valid value is 30 to 300 register requests per second. The default is 150.

For configuration examples, see the description of the [GeneratedRegistersInterval] parameter.

'Generated Register Interval'

configure voip > sip-definition proxy-and-registration > gen-reg-int

[GeneratedRegistersInterval]

Defines the rate (in seconds) at which the device sends user register requests (REGISTER messages). The parameter is based on the maximum number of REGISTER messages that can be sent at this rate, configured by the [MaxGeneratedRegistersRate] parameter.

The valid value is 1 to 5. The default is 1.

Configuration examples:

If you configure the [MaxGeneratedRegistersRate] parameter to 100 and [GeneratedRegistersInterval] to 5, the device sends a maximum of 20 REGISTER messages per second (i.e., 100 messages divided by 5 sec; 100 per 5 seconds).
If you configure the [MaxGeneratedRegistersRate] parameter to 100 and [GeneratedRegistersInterval] to 1, the device sends a maximum of a 100 REGISTER messages per second.

configure voip > sip-definition proxy-and-registration > reg-sync-mode

[RegistrationSyncMode]

Enables the synchronization of the registration process. This prevents the device from sending multiple SIP REGISTER requests for multiple Accounts and users in the SBC User Information table registering to the same proxy server (serving IP Group) that is currently offline.

These are Accounts that are configured in the Accounts table (see Configuring Registration Accounts) and users that are configured in the SBC User Information table (see Configuring SBC User Information Table through Web Interface).

If an Account or user receives a response timeout (see note below) or a response failure (e.g., SIP 403) for a sent SIP REGISTER request, the device stops sending SIP REGISTER messages for all the other Accounts and users that are associated with the same proxy server (serving IP Group). The Account or user that first detected the no response (or failure) from the proxy is considered the lead Account or user. The device continues sending REGISTER requests to the proxy only for this lead Account or user.

When the lead Account or user receives a successful response from the proxy, the device resumes the registration process for all the other Accounts and users that are associated with this same proxy.

[0] = (Default) Disable
[1] = Enable

Note: You can configure the response timeout using the [SipT1Rtx], [SipT2Rtx], or [SIPMaxRtx] parameters.

configure voip > sip-definition settings > account-invite-failure-trigger-codes

[AccountInviteFailureTriggerCodes]

Defines SIP response codes that if received for a failed INVITE message sent for an Account, triggers the device to re-register the Account. The parameter is applicable only if the Account's 'Re-Register on Invite Failure' parameter in the Accounts table is configured to Enable (see Configuring Registration Accounts).

The valid value is a SIP response code. Multiple response codes can be configured, where each value is separated by a comma. The default is "403,408,480" (without quotation marks).

Note: SIP response code 408 also refers to an INVITE timeout (i.e., no reply from server). Therefore, if re-registration is needed for such a scenario, make sure that you configure the parameter with "408" as well.

configure voip > sip-definition settings > ignore-auth-stale

[IgnoreAuthorizationStale]

Enables the device to retry registering even if the last SIP 401\407 response included "stale=false".

When the device initiates a REGISTER request with an Authorization header (according to the relevant configured credentials), and it receives a SIP 401\407 response with the stale parameter set to "false", by default the device doesn't try to send another REGISTER message. When the parameter is enabled, the device retries registering even if the last 401\407 response had "stale=false".

[0] = (Default) If the device receives a SIP 401\407 response with "stale=true" or no stale parameter at all, it sends another REGISTER message. If "stale=false", the device doesn't send another REGISTER message.
[1] = If the device receives a SIP 401\407 response with "stale=false", it sends another REGISTER message.

Note: This parameter is applicable only to REGISTER requests which the device initiates (e.g., for an Account or for Gateway endpoints); it's not for REGISTER requests that the device forwards from the user to the registrar server.

configure voip > sip-definition proxy-and-registration > account-registrar-avoidance-time

[AccountRegistrarAvoidanceTime]

Defines a graceful time (in seconds) which is intended to prevent the device from sending REGISTER requests to a registrar server where the device previously registered, if the device also registered successfully to another server since the last successful registration to the registrar server. This can occur if the registrar server has been offline for a brief time. For more information, see the 'Registrar Search Mode' parameter in Configuring Registration Accounts.

The valid value is 0 to 15.2 million. The default is 0.

configure voip > sip-definition settings > authenticated-message-handling

[AuthenticatedMessageHandling]

Defines if a Message Manipulation Set is run again on incoming authenticated SIP messages received after the device sends a SIP 401 response for challenging initial incoming SIP REGISTER requests.

Typically, this is not required and the rules of a Message Manipulation Set that are configured to run on incoming REGISTER requests are applied only when the initial unauthenticated REGISTER request is received. However, if the Message Manipulation Set includes a Message Manipulation rule that specifies that manipulation must be done on the SIP Authorization header (i.e., 'Condition' parameter value is "Header.Authorization !exists"), which is present only in authenticated messages, then configure the parameter to [1].

[0] = (Default) Disable - The Message Manipulation Set is not run again on authenticated messages and only applied to initial unauthenticated messages. The device uses this manipulated initial REGISTER request for further processing (e.g., classification or routing).
[1] = The Message Manipulation Set is run again on authenticated messages (if it includes a rule whose condition is the Authorization header). The device uses this manipulated authenticated REGISTER request for further processing (e.g., classification or routing).