Configuring Proxy Sets

The Proxy Sets table lets you configure up to 102 Proxy Sets. A Proxy Set defines the address (IP address or FQDN) and transport type (e.g., UDP or TCP) of a SIP server (e.g., SIP proxy and SIP registrar server). The Proxy Set represents the destination of the IP Group configuration entity.

●

You can configure each Proxy Set with up to 10 proxy servers (rows) in the Proxy Address table (a "child" of the Proxy Sets table), configured as IP addresses (in dotted-decimal notation) and/or DNS hostnames (FQDN).

●

Each Proxy Set supports up to 15 DNS-resolved IP addresses.

●

Each Proxy Set supports up to 15 IP addresses, regardless of how the IP address is obtained--DNS resolved or manually configured (dotted-decimal notation).

●

For all Proxy Sets together, the device supports up to 500 DNS-resolved IP addresses. If the DNS resolution provides more than this number, it ignores the extra addresses.

●

An SRV query sent by the device can return up to 50 hostnames. For each hostname, the subsequent DNS A-record query sent by the device can resolve into up to 50 IP addresses.

Multiple proxy servers enables you to implement proxy load balancing and redundancy. These features are supported by the device's proxy keep-alive feature, which when enabled, sends keep-alive messages (SIP OPTIONS) to all configured proxy servers to determine their connectivity status (offline or online). You can also configure the device to consider the proxy as offline if specific SIP response codes are received in response to the keep-alive messages. You can configure the number of required consecutive successful keep-alive messages before the device considers a previously offline proxy as online. This mechanism avoids the scenario in which the device falsely detects a proxy as being online when it is actually offline, resulting in call routing failure.

You can assign each Proxy Set a specific TLS Context (TLS configuration), enabling you to use different TLS settings (including certificates) per SIP entity (IP Group).

You can also enable the device to classify incoming SBC SIP dialogs to IP Groups, based on Proxy Set. If the source address of the incoming SIP dialog is the same as the address of a Proxy Set, the device classifies the SIP dialog as belonging to the IP Group that is associated with the Proxy Set.

To use a configured Proxy Set, you need to assign it to an IP Group in the IP Groups table (see Configuring IP Groups). When the device sends INVITE messages to an IP Group, it sends it to the address configured for the Proxy Set. You can assign the same Proxy Set to multiple IP Groups (belonging to the same SRD).

●

It is recommended to classify incoming SIP dialogs to IP Groups based on Classification rules (see Configuring Classification Rules) instead of based on Proxy Sets.

●

For the Gateway application, you can view the device's connectivity status with proxy servers in the Tel-to-IP Routing table for Tel-to-IP routing rules whose destination is an IP Group that is associated with a Proxy Set. The status is only displayed for Proxy Sets enabled with the Proxy Keep-Alive feature.

●

To view the connectivity status of Proxy Sets, see Viewing Proxy Set Status.

The Proxy Set is configured using two tables, one a "child" of the other:

■

Proxy Sets table: Defines the attributes of the Proxy Set such as associated SIP Interface and redundancy features - ini file parameter [ProxySet] or CLI command, configure voip > proxy-set

■

Proxy Set Address table ("child"): Defines the addresses of the Proxy Set - table ini file parameter [ProxyIP] or CLI command, configure voip > proxy-ip > proxy-set-id

➢

To configure a Proxy Set:

Open the Proxy Sets table (Setup menu > Signaling & Media tab > Core Entities folder >Proxy Sets).

Click New; the following dialog box appears (screenshot has been cropped due to page size):

Configure a Proxy Set according to the parameters described in the table below.

Click Apply.

Select the index row of the Proxy Set that you added, and then click the Proxy Address link located below the table; the Proxy Address table opens.

Click New; the following dialog box appears:

Configure the address of the Proxy Set according to the parameters described in the table below.

Click Apply.

Proxy Sets Table and Proxy Address Table Parameter Description

Parameter

Description

'SRD'

voip-network proxy-set > srd-id

[ProxySet_SRDName]

Assigns an SRD to the Proxy Set.

Note:

■

The parameter is mandatory and must be configured first before you can configure the other parameters in the table.

■

To configure SRDs, see Configuring SRDs.

General

'Index'

configure voip > voip-network proxy-set

[ProxySet_Index]

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

'Name'

proxy-name

[ProxySet_ProxyName]

Defines a descriptive name, which is used when associating the row in other tables.

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

Note:

■

Each row must be configured with a unique name.

■

The parameter value cannot contain a forward slash (/).

'Gateway IPv4 SIP Interface'

gwipv4-sip-int-name

[ProxySet_GWIPv4SIPInterfaceName]

Assigns an IPv4-based SIP Interface for Gateway calls to the Proxy Set.

Note:

■

At least one SIP Interface must be assigned to the Proxy Set.

■

The parameter appears only if you have configured a network interface with an IPv4 address.

■

To configure SIP Interfaces, see Configuring SIP Interfaces.

'SBC IPv4 SIP Interface'

sbcipv4-sip-int-name

[ProxySet_SBCIPv4SIPInterfaceName]

Assigns an IPv4-based SIP Interface for SBC calls to the Proxy Set.

Note:

■

At least one SIP Interface must be assigned to the Proxy Set.

■

The parameter appears only if you have configured a network interface with an IPv4 address.

■

To configure SIP Interfaces, see Configuring SIP Interfaces.

'Gateway IPv6 SIP Interface'

gwipv6-sip-int-name

[ProxySet_GWIPv6SIPInterfaceName]

Assigns an IPv6-based SIP Interface for Gateway calls to the Proxy Set.

Note:

■

At least one SIP Interface must be assigned to the Proxy Set.

■

The parameter appears only if you have configured a network interface with an IPv6 address.

'SBC IPv6 SIP Interface'

sbcipv6-sip-int-name

[ProxySet_SBCIPv6SIPInterfaceName]

Assigns an IPv6-based SIP Interface for SBC calls to the Proxy Set.

Note:

■

At least one SIP Interface must be assigned to the Proxy Set.

■

The parameter appears only if you have configured a network interface with an IPv6 address.

'TLS Context Name'

tls-context-name

[ProxySet_TLSContextName]

Assigns a TLS Context (TLS configuration) to the Proxy Set.

By default, no TLS Context is assigned. If you assign a TLS Context, the TLS Context is used as follows:

■

Incoming calls: If the 'Transport Type' parameter (in this table) is set to TLS and the incoming call is successfully classified to an IP Group based on the Proxy Set, this TLS Context is used. If the 'Transport Type' parameter is set to UDP or classification to this Proxy Set fails, the TLS Context is not used. Instead, the device uses the TLS Context configured for the SIP Interface (see Configuring SIP Interfaces) used for the call; otherwise, the default TLS Context (ID 0) is used.

■

Outgoing calls: If the 'Transport Type' parameter is set to TLS and the outgoing call is sent to an IP Group that is associated with this Proxy Set, this TLS Context is used. Instead, the device uses the TLS Context configured for the SIP Interface used for the call; otherwise, the default TLS Context (ID 0) is used. If the 'Transport Type' parameter is set to UDP, the device uses UDP to communicate with the proxy and no TLS Context is used.

To configure TLS Contexts, see Configuring TLS Certificates.

Keep Alive

'Proxy Keep-Alive'

proxy-enable-keep-alive

[ProxySet_EnableProxyKeepAlive]

Enables the device's Proxy Keep-Alive feature, which checks connectivity with all the proxy servers of the Proxy Set, by sending keep-alive messages.

■

[0] Disable (default).

■

[1] Using OPTIONS = Enables the Proxy Keep-Alive feature using SIP OPTIONS messages. The device sends an OPTIONS message every user-defined interval, configured by the 'Proxy Keep-Alive Time' parameter (in this table). If the device receives a SIP response code that is configured in the 'Keep-Alive Failure Responses' parameter (in this table), the device considers the proxy as offline. You can also configure if the device uses its IP address, the proxy's IP address, or the device's name in the OPTIONS message, using the [UseGatewayNameForOptions] parameter.

■

[2] Using REGISTER = Enables the Proxy Keep-Alive feature using SIP REGISTER messages. The device sends a REGISTER message every user-defined interval, configured by the RegistrationTime parameter (Gateway application) or SBCProxyRegistrationTime parameter (SBC application). Any SIP response from the proxy - success (200 OK) or failure (4xx response) - is considered as if the proxy is "alive". If the proxy does not respond to INVITE messages sent by the device, the proxy is considered as down (offline). The device sends keep-alive REGISTER messages only to one proxy. Only if the proxy fails to respond to the keep-alive, does the device send the next keep-alive REGISTER message to another proxy.

■

[3] Using OPTIONS on Active Server = Enables the Proxy Keep-Alive feature using SIP OPTIONS messages (similar to the Using OPTIONS value), except that the proxy servers to which the keep-alive messages are sent depend on the settings of the Proxy Set's 'Redundancy Mode' parameter (see below):

✔

Parking: The device sends the keep-alive OPTIONS messages only to the currently active proxy server (to which it is connected and using).

✔

Homing: The device sends keep-alive OPTIONS messages to the currently active proxy server as well as to all proxy servers with higher priority (according to the 'Proxy Priority' parameter described below) than the active server. Once a higher priority server comes online, the device stops sending the keep-alive OPTIONS messages to the previously active server and connects to the higher priority server. The device now sends keep-alive messages to this newly active server and all other servers with higher priority.

✔

If the 'Redundancy Mode' parameter is not configured (empty) and the Proxy Set's 'Proxy Load Balancing Method' parameter (see below) is configured to any value other than Disable, the device sends the keep-alive OPTIONS messages to all proxy servers (same behavior as when you configure the 'Proxy Keep-Alive' parameter to Using OPTIONS).

✔

[4] Using Fake REGISTER = Enables the Proxy Keep-Alive feature using SIP REGISTER messages. The device sends a REGISTER message every user-defined interval, configured by the 'Proxy Keep-Alive Time' parameter (in this table). The name in the Contact header of the REGISTER message is a fake name. Therefore, the REGISTER request is expected to fail and the device considers the proxy server as online if it receives a SIP 404 in response. If the device receives a SIP response code that is configured in the 'Keep-Alive Failure Responses' parameter (in this table), the device considers the proxy as offline. You can also configure if the device uses its IP address, the proxy's IP address, or the device's name in the REGISTER message, using the [UseGatewayNameForOptions] parameter.

Note:

■

Proxy keep-alive using REGISTER messages (Using REGISTER) is applicable only to the Parking redundancy mode ('Redundancy Mode' parameter configured to Parking).

■

If you enable this Proxy Keep-Alive feature, the device can operate with multiple proxy servers (addresses) for redundancy and load balancing (see the 'Proxy Load Balancing Method' parameter).

■

For Survivability mode for User-type IP Groups, you must enable this Proxy Keep-Alive feature.

■

If you enable this Proxy Keep-Alive feature and the proxy uses the TCP/TLS transport type, you can enable CRLF Keep-Alive feature, using the [UsePingPongKeepAlive] parameter.

■

If you enable proxy keep-alive using SIP OPTIONS messages (Using OPTIONS or Using OPTIONS on Active Server) or fake REGISTER requests (Using Fake REGISTER), you can also enable the device to apply various settings (e.g., SIP message manipulations) of the IP Group that is associated with the Proxy Set , to these SIP messages. For more information, see the 'Proxy Keep-Alive using IP Group Settings' parameter in the IP Groups table.

■

If you enable proxy keep-alive using SIP OPTIONS messages (Using OPTIONS or Using OPTIONS on Active Server) or fake REGISTER requests (Using Fake REGISTER), you can also configure how long the device waits (in seconds) before re-sending a keep-alive message once the device considers the proxy as offline (i.e., after all retransmissions, configured by the 'Failure Detection Retransmissions' have failed). This feature is configured by the [FailedOptionsRetryTime] parameter.

'Proxy Keep-Alive Time'

proxy-keep-alive-time

[ProxySet_ProxyKeepAliveTime]

Defines the interval (in seconds) between keep-alive messages sent by the device when the Proxy Keep-Alive feature is enabled (see the 'Proxy Keep-Alive' parameter in this table).

The valid range is 5 to 2,000,000. The default is 60.

Note: The parameter is applicable only if the 'Proxy Keep-Alive' parameter is configured to Using Fake REGISTER, Using OPTIONS or Using OPTIONS on Active Server.

'Keep-Alive Failure Responses'

keepalive-fail-resp

[ProxySet_KeepAliveFailureResp]

Defines SIP response codes that if any is received in response to a keep-alive message using SIP OPTIONS ('Proxy Keep-Alive' configured to Using OPTIONS or Using OPTIONS on Active Server) or fake REGISTER requests ('Proxy Keep-Alive' configured to Using Fake REGISTER), the device considers the proxy as down.

Up to three response codes can be configured, where each code is separated by a comma (e.g., 407,404). By default, no response code is defined. If no response code is configured, or if response codes received are not those configured, the proxy is considered online.

Note: The SIP 200 response code is not supported for this feature.

'Success Detection Retries'

success-detect-retries

[ProxySet_SuccessDetectionRetries]

Defines the minimum number of consecutive, successful keep-alive messages that the device sends to an offline proxy, before the device considers the proxy as being online. The interval between the sending of each consecutive successful keep-alive is configured by the 'Success Detection Interval' parameter (see below). For an example of using this parameter, see the 'Success Detection Interval' parameter.

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

Note: The parameter is applicable only if the 'Proxy Keep-Alive' parameter is configured to Using Fake REGISTER, Using OPTIONS or Using OPTIONS on Active Server.

'Success Detection Interval'

success-detect-int

[ProxySet_SuccessDetectionInterval]

Defines the interval (in seconds) between each successful keep-alive retries (as configured by the 'Success Detection Retries' parameter) that the device performs for offline proxies.

The valid range is 1 to 200. The default is 10.

For example, assume that the ‘Success Detection Retries’ parameter is configured to 3 and the ‘Success Detection Interval’ parameter to 5 (seconds). When connectivity is lost with the proxy, the device sends keep-alive messages to the proxy. If the device receives a successful response from the proxy, it sends another (1st) keep-alive after 5 seconds, and if successful, sends another (2nd) keep-alive after 5 seconds, and if successful, sends another (3rd) keep-alive after 5 seconds, and if successful, considers connectivity with the proxy as being restored.

Note: The parameter is applicable only if the 'Proxy Keep-Alive' parameter is configured to Using Fake REGISTER, Using OPTIONS or Using OPTIONS on Active Server.

'Failure Detection Retransmissions'

fail-detect-rtx

[ProxySet_FailureDetectionRetransmissions]

Defines the maximum number of UDP retransmissions that the device sends to an offline proxy before the device considers the proxy as offline.

The valid range is -1 to 255. The default is -1, which means that the settings of the global parameter [SIPMaxRtx] is applied.

Note:

■

The parameter is applicable only if the 'Proxy Keep-Alive' parameter is configured to Using Fake REGISTER, Using OPTIONS or Using OPTIONS on Active Server.

■

If the receives an ICMP error response (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) in the Proxy Set (typically required when Proxy Hot Swap is enabled). To enable this, configure the [AbortRetriesOnICMPError] parameter to 1.

Redundancy

'Redundancy Mode'

proxy-redundancy-mode

[ProxySet_ProxyRedundancyMode]

Enables the proxy redundancy mode.

■

[-1] = Not configured (Default). Proxy redundancy method is according to the settings of the global parameter [ProxyRedundancyMode].

■

[0] Parking = If the device operates with a proxy server that has the highest priority and the proxy goes offline, the device attempts to connect and operate with a different proxy that has the highest priority of all currently online proxies. However, once the device starts operating with this new proxy, it remains operating with it even if a previously offline proxy that has higher priority becomes online again.

■

[1] Homing = The device always attempts to operate with the proxy that has the highest priority of all currently online proxies. For example, if the device is currently operating with proxy server 200.10.1.1 that has priority 4, and then a previously offline proxy 200.10.1.2 that has priority 0 (i.e., a higher priority) becomes online again, the device attempts to connect and operate with proxy 200.10.1.2.

Note:

■

For proxy redundancy, you also need to enable the proxy keep-alive feature (see the 'Proxy Keep-Alive' parameter, above). The Homing redundancy mode is applicable only to proxy keep-alive using SIP OPTIONS (i.e., 'Proxy Keep-Alive' parameter is configured to Using OPTIONS or Using OPTIONS on Active Server) or fake REGISTER requests (i.e., 'Proxy Keep-Alive' parameter is configured to Using Fake REGISTER). The Parking redundancy mode is applicable to all proxy keep-alive methods.

■

From Version 7.20A.204, if you configure the parameter to Parking and the proxy keep-alive is done using REGISTER messages, when the proxy goes offline, the device arbitrarily chooses the next proxy to operate with.

■

To configure proxy priority, see the 'Proxy Priority' parameter in the Proxy Address table (below).

'Proxy Hot Swap'

is-proxy-hot-swap

[ProxySet_IsProxyHotSwap]

Enables the Proxy Hot-Swap feature, whereby if the device sends a SIP message (INVITE or REGISTER) to the proxy and the message fails, the device re-sends the same message to a redundant proxy configured for the Proxy Set. The redundant proxy is determined by your Proxy Set configuration (i.e., redundancy mode and load balancing).

■

[0] Disable = (Default) Disables the Proxy Hot-Swap feature. If the device sends a SIP message (INVITE or REGISTER) to the proxy and the proxy rejects it or no response is received from the proxy for a user-defined number of re-transmissions, configured by the [SIPMaxRtx] parameter, the device does not attempt to connect to any other proxy in the Proxy Set and the SIP message fails.

However, if you have configured an SBC Alternative Routing Reasons Set for the IP Group (see Configuring SIP Response Codes for Alternative Routing Reasons), the device tries up to four online proxies in the Proxy Set. If it successfully connects to one of the redundant proxies, it re-sends the message to this proxy. This functionality doesn’t apply to REGISTER requests initiated by the device (e.g., for Accounts).

■

[1] Enable = If the device sends a SIP message (INVITE or REGISTER) to the proxy with which it is currently operating and any of the following occurs, the device re-sends the message to a redundant online proxy:

✔

No response is received from the proxy each time the device re-sends it. The number of retransmissions is configured by the [HotSwapRtx] parameter. In such a scenario, the device issues itself the SIP response code 408 (Request Timeout).

✔

(SBC Application) The proxy rejects the message with a SIP response code that you have also configured for the Alternative Reasons Set that is assigned to the IP Group ('SBC Alternative Routing Reasons Set' parameter) associated with the Proxy Set (see Configuring SIP Response Codes for Alternative Routing Reasons).

✔

(Gateway Application) The proxy rejects the message with a SIP response code that is also configured in the Reasons for Tel-to-IP Alternative Routing table (see Alternative Routing Based on SIP Responses).

Note:For the SBC application: You can employ alternative routing with this option. If no response is received from any of the redundant (online) proxies or the proxies reject the message with a SIP response code that you have configured for the Alternative Reasons Set that is assigned to the IP Group ('SBC Alternative Routing Reasons Set' parameter) associated with the Proxy Set, the device searches the IP-to-IP Routing table for an alternative routing rule and if found, sends the message to the rule's destination. For more information on the Proxy Hot Swap feature and alternative routing based on SIP response codes, see Configuring SIP Response Codes for Alternative Routing Reasons.

'Proxy Load Balancing Method'

proxy-load-balancing-method

[ProxySet_ProxyLoadBalancingMethod]

Enables load balancing between proxy servers of the Proxy Set.

■

[0] Disable = (Default) Disables proxy load balancing.

■

[1] Round Robin = The device sends outgoing SIP messages to the online proxy servers of the Proxy Set in a round-robin fashion. The order of the round-robin is determined by the listed order of the IP addresses in the Proxy Address table and their priority. You can configure priority of each IP address using the 'Proxy Priority' parameter (see below). For DNS-resolved IP addresses for proxy servers configured with an FQDN (including NAPTR and SRV, if configured), the priority is received from the DNS. For the Gateway application, REGISTER messages are also distributed ina round-robin fashion, unless you have configured a specific IP address of a registrar server (using the RegistrarIP parameter). The IP address list is refreshed every user-defined interval (see the ProxyIPListRefreshTime parameter). If a change in the order of the IP address entries in the list occurs, all load statistics are erased and balancing starts over again.

■

[2] Random Weights = The outgoing requests are not distributed equally among the proxy servers. The distribution is determined by the weight of the proxy servers. You can configure the weight per proxy server, using the 'Proxy Random Weight' parameter in the Proxy Address table (see below). For proxy servers configured with an FQDN, the weight of each DNS-resolved IP address is received from the DNS server (using SRV records). However, if you have configured the weight for the FQDN in the 'Proxy Random Weight' parameter, this parameter's value overrides the weight from the DNS server. The device sends the requests in such a fashion that each proxy receives a percentage of the requests according to its' weight.

'Min. Active Servers for Load Balancing'

min-active-serv-lb

[ProxySet_MinActiveServersLB]

Defines the minimum number of proxies in the Proxy Set that must be online for the device to consider the Proxy Set as online, when proxy load balancing is used.

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

Note: The parameter is applicable only if proxy load balancing is enabled (see the 'Proxy Load Balancing Method' parameter, above).

Advanced

'Classification Input'

classification-input

[ProxySet_ClassificationInput]

Defines how the device classifies incoming IP calls to the Proxy Set.

■

[0] IP Address only = (Default) Classifies calls to the Proxy Set according to IP address only.

■

[1] IP Address, Port & Transport Type = Classifies calls to the Proxy Set according to IP address, port, and transport type.

Note:

■

The parameter is applicable only to the SBC application.

■

The parameter is applicable only if the IP Groups table's parameter 'Classify by Proxy Set' is configured to Enable (see Configuring IP Groups).

■

If multiple Proxy Sets are configured with the same IP address and associated with the same SIP Interface, the device may classify the SIP dialog (based on Proxy Set) to an incorrect IP Group. In such a scenario, the device uses the Proxy Set with the lowest Index number (e.g., Proxy Set ID #1 over Proxy Set ID #4). A Syslog warning message is generated in such scenarios. Therefore, it is recommended to configure each Proxy Set with a unique IP address.

If multiple Proxy Sets are configured with the same IP address but associated with different SIP Interfaces, then classification based on Proxy Set can be correctly achieved.

If multiple Proxy Sets are configured with the same IP address and SIP Interface, but with different ports (e.g., 10.1.1.1:5060 and 10.1.1.1:5070) and the parameter is configured to IP Address, Port & Transport Type, classification to the correct IP Group is achieved. Therefore, when classification is by Proxy Set, pay attention to the configured IP addresses and this parameter. When multiple Proxy Sets are configured with the same IP address, the device selects the matching Proxy Set in the following order:

✔

Selects the Proxy Set whose IP address, port, and transport type match the source of the incoming SIP request (regardless of the settings of this parameter).

✔

If no match is found for above, it selects the Proxy Set whose IP address and transport type match the source of the incoming SIP request (if the parameter is configured to IP Address Only).

✔

If no match is found for above, it selects the Proxy Set whose IP address match the source of the incoming SIP request (if the parameter is configured to IP Address Only).

For example:

Index	Classification Input	Proxy Address (IP:Port;Transport Type)
1	IP Address, Port & Transport Type	10.10.10.10:5060;UDP
2	IP Address only	10.10.10.10:5060;UDP
3	IP Address only	10.10.10.10:5070;UDP
4	IP Address only	10.10.10.10:5060;TCP

✔

Incoming SIP request from 10.10.10.10:5060;UDP: Best match is #1 and #2 (same priority); second best match is #3 (due to transport type); third best match is #4.

✔

Incoming SIP request from 10.10.10.10:5080;TLS: Best match is #2, #3 and #4 (same priority).

✔

Incoming SIP request from 10.10.10.10:5070;TCP: Best match is #4 (due to transport type); second best match is #2 and #3 (same priority).

'DNS Resolve Method'

dns-resolve-method

[ProxySet_DNSResolveMethod]

Defines the DNS query record type for resolving the proxy server's host name (FQDN) into an IP address(es).

■

[-1] = Not configured. DNS resolution method is according to the settings of the global parameter [ProxyDNSQueryType].

■

[0] A-Record = (Default) DNS A-record query is used to resolve DNS to IP addresses.

■

[1] SRV = If the proxy address is configured with a domain name without a port (e.g., domain.com), an SRV query is done. The SRV query returns the host names (and their weights). The device then performs DNS A-record queries per host name (according to the received weights). If the configured proxy address contains a domain name with a port (e.g., domain.com:5080), the device performs a regular DNS A-record query.

■

[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 configured proxy address contains a domain name with a port (e.g., domain.com:5080), the device performs a regular DNS A-record query. If the transport type is configured for the proxy address, a NAPTR query is not performed.

■

[3] Microsoft Skype for Business = An SRV query is done as required by Microsoft when the device is deployed in a Microsoft Skype for Business environment. The device sends a special SRV query to the DNS server according to the transport protocol configured in the 'Transport Type' parameter (described later in this section):

✔

TLS

✔

TCP: "_sipinternal._tcp.<domain>" and "_sip_tcp.<domain>".

✔

Undefined: "_sipinternaltls_tcp.<domain>", "_sipinternal_tcp.<domain>", "_sip_tls.<domain>" and "_sip_tcp.<domain>".

The SRV query returns the host names (and their weights). The device then performs DNS A-record queries per host name (according to the received weights) to resolve into IP addresses.

Note: The device caches the DNS-resolved IP addresses of the last successful DNS query. For more information, see the description of the [ProxyIPListRefreshTime] parameter.

'Accept DHCP Proxy List'

accept-dhcp-proxy-list

[ProxySet_AcceptDHCPProxyList]

Enables the device (acting as a DHCP client) to obtain the Proxy Set's address(es) from a DHCP server.

■

[0] Disable (default)

■

[1] Enable = The device sends a DHCP request with Option 120 (SIP server address) to a DHCP server. This occurs upon a DHCP refresh (lease renewal). When the device receives the list of IP addresses (or DNS) from the server, it adds them to the Proxy Set (replacing any existing IP addresses or DNS). This is the Proxy Set that is associated with the SIP Interface that is associated with the WAN interface.

The device can also send a REGISTER request (refresh) upon the receipt of a DHCP FORCERENEW message, under certain conditions. If the device receives from the DHCP server a DHCP FORCERENEW message containing Option 125 with Enterprise Number 210, it first authenticates the message by checking that the Authentication Option (90) has key index 1. If authentication succeeds, the device sends a DHCP Request message with Option 120 to request a lease renewal of its SIP servers (i.e., Proxy Set’s IP addresses). When the device receives a DHCP ACK message with the list of IP addresses from the server, it adds them to the Proxy Set (replacing any existing IP addresses). This occurs even if there is no change in the list of IP addresses. The device then sends a SIP REGISTER message (i.e., re-registration) for the Account to the SIP registrar server (serving IP Group). For configuring Accounts, see Configuring Registration Accounts.

Note: When enabled, the device uses UDP and port 5060.

Proxy Address Table

'Index'

proxy-ip-index

[ProxyIp_ProxyIpIndex]

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

'Proxy Address'

proxy-address

[ProxyIp_IpAddress]

Defines the address of the proxy server (Proxy Set). The address can be defined as an IP address in dotted-decimal notation (e.g., 201.10.8.1) or FQDN. You can also specify the port using the following format:

■

IPv4 address: <IP address>:<port> (e.g., 201.10.8.1:5060)

■

IPv6 address: <[IPV6 address]>:<port> (e.g., [2000::1:200:200:86:14]:5060)

Note:

■

When configured with an FQDN, you can configure the periodic interval at which the device performs DNS queries to resolve the FQDN into IP addresses. For more information, see the [ProxyIPListRefreshTime] parameter.

■

When configured with an FQDN, you can configure the method (e.g., A-record) for resolving the domain name into an IP address, using the 'DNS Resolve Method' parameter in this table (see above).

■

For the SBC application: You can configure the device to use the port indicated in the Request-URI of the incoming message, instead of the port configured for the parameter. To enable this, use the [IPGroup_SBCRouteUsingRequestURIPort] parameter for the IP Group that is associated with the Proxy Set (Configuring IP Groups).

■

If you are configuring the Proxy Sets with IP addresses, it is highly recommended to configure each Proxy Set with a unique IP address. Configuring multiple Proxy Sets with the same IP address can cause problems classifying incoming SIP requests to source IP Groups based on Proxy Set. If you have configured multiple Proxy Sets with the same IP address, the device uses the Proxy Set with lowest Index number. For example, if you have configured Proxy Set ID #1 and Proxy Set ID #4 with the same IP address, the device uses Proxy Set ID #1 to classify the incoming SIP request to an IP Group.

However, configuring multiple Proxy Sets with the same IP address, but with different SIP Interfaces is acceptable for classifying incoming SIP requests to source IP Groups based on Proxy Set.

For more information on determining the Proxy Set, see the 'Classification Input' parameter (above) parameter .

'Transport Type'

transport-type

[ProxyIp_TransportType]

Defines the transport type for communicating with the proxy.

■

[-1] = (Default) Not configured. The transport type is according to the settings of the global parameter [SIPTransportType].

■

[0] UDP

■

[1] TCP

■

[2] TLS

'Proxy Priority'

priority

[ProxyIp_Priority]

Defines the priority of the proxy. When a proxy server goes offline, the device attempts to connect to an online proxy server that has the highest priority.

The valid value is 0 to 65535, where 0 is the highest priority and 65535 the lowest. The default is 0.

Note:

■

You must configure both priority and weight (or none of them). In other words, if you configure this parameter, you must also configure the 'Proxy Random Weight' parameter. If you don't configure this parameter, you must also not configure the 'Proxy Random Weight' parameter.

■

If weight and priority are not configured for any of the proxy servers of the Proxy Set, the order in which the addresses (IP addresses and FQDNs) are listed in the table determine their priority (i.e., top-listed address has the highest priority).

■

For FQDNs, weight and priority of DNS-resolved IP addresses are determined by the DNS. However, this parameter's value overrides the priority received from the DNS.

■

If you have configured at least one of the proxy servers of the Proxy Set with weight and priority, the device prioritizes all the configured proxy servers according to weight and priority. In this case, proxy servers that are not configured with priority (i.e., 0) are considered as proxy servers with the highest priority.

■

The parameter is applicable to load balancing (see the 'Proxy Load Balancing Method' parameter), and homing and parking redundancy (see the 'Redundancy Mode' parameter).

'Proxy Random Weight'

weight

[ProxyIp_Weight]

Defines the weight of the proxy.

The valid value is 0 to 65535, where 0 is the highest weight and 65535 the lowest. The default is 0.

Note:

■

The parameter is applicable only if you configure the 'Proxy Load Balancing Method' parameter to Random Weights. For more information on weights, see this parameter.

■

You must configure both priority and weight (or none of them). In other words, if you configure this parameter, you must also configure the 'Proxy Priority' parameter. If you don't configure this parameter, you must also not configure the 'Proxy Priority' parameter.

■

For proxy servers configured with FQDNs, this parameter's value overrides the weight received for DNS-resolved IP addresses from the DNS server.