Configuring IP Groups

The IP Groups table lets you configure up to 50 IP Groups. An IP Group represents a SIP entity in the network with which the device communicates. This can be a server (e.g., IP PBX or ITSP) or a group of users (e.g., LAN IP phones). For servers, the address of the IP Group is typically defined by associating it with a Proxy Set (see Configuring Proxy Sets).

You can use IP Groups for the following:

■

(SBC Application ) Classification of incoming SIP dialog-initiating requests (e.g., INVITE messages) to IP Groups based on Proxy Set. If the source address of the incoming SIP dialog is defined for a Proxy Set, the assigns ("bonds") the SIP dialog to the IP Group associated with the Proxy Set. The feature is configured using the IP Groups table's 'Classify by Proxy Set' parameter. For more information and recommended security guidelines, see the parameter's description, later in this section.

■

(SBC Application ) Classification of incoming SIP dialog-initiating requests (e.g., INVITE messages) to IP Groups based on source tags of incoming dialog. Tag-based classification occurs only if Classification based on user registration and on Proxy Sets fail. For more information, see Configuring Classification Based on Tags.

■

(SBC Application) Representing the source and destination of the call in IP-to-IP Routing rules (see Configuring SBC IP-to-IP Routing Rules).

■

SIP dialog registration and authentication (digest user/password) of specific IP Groups (Served IP Group, e.g., corporate IP-PBX) with other IP Groups (Serving IP Group, e.g., ITSP). This is configured in the Accounts table (see Configuring Registration Accounts).

■

(Gateway Application) Call routing rules:

●

Tel-to-IP calls: The IP Group is used as the destination of the outgoing IP call and is used in Tel-to-IP call routing rules (see Configuring Tel-to-IP Routing Rules).

●

IP-to-Tel calls: The IP Group identifies the source of the IP call and is used in IP-to-Tel call routing rules (see Configuring IP-to-Tel Routing Rules).

●

Number manipulation: The IP Group can be associated with a number manipulation rule (see Configuring Number Manipulation Tables).

■

Included in routing decisions by a third-party routing server. If deemed necessary for routing, the routing server can even create an IP Group. For more information, see Centralized Third-Party Routing Server.

You can also apply the device's Quality of Experience feature to IP Groups:

■

Quality of Experience Profile: Call quality monitoring based on thresholds for voice metrics (e.g., MOS) can be applied per IP Group. For example, if MOS is considered poor, calls belonging to this IP Group can be rejected. To configure Quality of Experience Profiles, see Configuring Quality of Experience Profiles.

■

Bandwidth Profile: Bandwidth utilization thresholds can be applied per IP Group. For example, if bandwidth thresholds are crossed, the device can reject any new calls on this IP Group. To configure Bandwidth Profiles, see Configuring Bandwidth Profiles.

●

For the Gateway application, regarding table row index #0:

✔

it is recommended to not configure any IP Group in table row index #0. This index number entity is not supported by certain device functionality (e.g., not counted in performance monitoring).

✔

IP Group in row index #0 cannot be associated with Proxy Set row index #0.

✔

If no IP Group exists in the IP Groups table, the device rejects all Gateway calls. Even if you are not using IP Groups to route calls, IP Group row index #0 (default) must exist for the device to route calls.

●

If you delete an IP Group or modify the 'Type' or 'SRD' parameters, the device immediately terminates currently active calls that are associated with the IP Group. In addition, all users belonging to the IP Group are removed from the device's users database.

The following procedure describes how to configure IP Groups through the Web interface. You can also configure it through ini file [IPGroup] or CLI (configure voip > ip-group).

➢

To configure an IP Group:

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

Click New; the following dialog box appears:

Configure an IP Group according to to the parameters described in the table below.

Click Apply.

IP Groups Table Parameter Descriptions

Parameter

Description

'SRD'

srd-name

[IPGroup_SRDName]

Assigns an SRD to the IP Group.

If only one SRD is configured in the SRDs table, the SRD is assigned by default. If multiple SRDs are configured in the SRDs table, no value is assigned by default and you must assign one.

To configure SRDs, see Configuring SRDs.

Note: The parameter is mandatory.

General

'Index'

[IPGroup_Index]

Defines an index for the new table row.

Note:

■

For the Gateway application, regarding table row index #0:

✔

It is recommended to not configure any IP Group in table row index #0 (even though it is considered valid configuration). This index number is not supported by certain device functionality (e.g., not counted in performance monitoring).

✔

IP Group in row index #0 cannot be associated with Proxy Set row index #0.

■

Each row must be configured with a unique index.

'Name'

name

[IPGroup_Name]

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 (/).

'Topology Location'

topology-location

[IPGroup_TopologyLocation]

Defines the display location of the IP Group in the Topology view of the Web interface.

■

[0] Down = (Default) The IP Group element is displayed on the lower border of the view.

■

[1] Up = The IP Group element is displayed on the upper border of the view.

For more information on the Topology view, see Building and Viewing SIP Entities in Topology View.

'Type'

type

[IPGroup_Type]

Defines the type of IP Group.

■

[0] Server = Applicable when the destination address of the IP Group (e.g., ITSP, Proxy, IP-PBX, or Application server) is known. The address is configured by the Proxy Set that is associated with the IP Group.

■

[1] User = Represents a group of users such as IP phones and softphones where their location is dynamically obtained by the device when REGISTER requests and responses traverse (or are terminated) by the device. These users are considered remote (far-end).

Typically, this IP Group is configured with a Serving IP Group that represents an IP-PBX, Application or Proxy server that serves this User-type IP Group. Each SIP request sent by a user of this IP Group is proxied to the Serving IP Group. For registrations, the device updates its registration database with the AOR and contacts of the users.
Digest authentication using SIP 401/407 responses (if needed) is performed by the Serving IP Group. The device forwards these responses directly to the SIP users.

To route a call to a registered user, a rule must be configured in the Tel-to-IP Routing table or SBC IP-to-IP Routing table. The device searches the dynamic database (by using the Request-URI) for an entry that matches a registered AOR or Contact. Once an entry is found, the IP destination is obtained from this entry and a SIP request is sent to the destination.

The device also supports NAT traversal for the SIP clients located behind NAT. In this case, the device must be defined with a global IP address.

■

[2] Gateway = (Applicable only to the SBC application) In scenarios where the device receives requests to and from a gateway representing multiple users. This IP Group type is necessary for any of the following scenarios:

✔

The IP Group cannot be defined as a Server-type since its address is initially unknown and therefore, a Proxy Set cannot be configured for it.

✔

The IP Group cannot be defined as a User-type since the SIP Contact header of the incoming REGISTER does not represent a specific user. The Request-URI user part can change and therefore, the device is unable to identify an already registered user and therefore, adds an additional record to the database.

The IP address of the Gateway-type IP Group is obtained dynamically from the host part of the Contact header in the REGISTER request received from the IP Group. Therefore, routing to this IP Group is possible only once a REGISTER request is received (i.e., IP Group is registered with the device). If a REGISTER refresh request arrives, the device updates the new location (i.e., IP address) of the IP Group. If the REGISTER fails, no update is performed. If an UN-REGISTER request arrives, the IP address associated with the IP Group is deleted and therefore, no routing to the IP Group is done.

You can view the registration status of the Gateway-type IP Group in the 'GW Group Registered Status' field, and view the IP address of the IP Group in the 'GW Group Registered IP Address' field if it is registered with the device.

'Proxy Set'

proxy-set-name

[IPGroup_ProxySetName]

Assigns a Proxy Set to the IP Group. All INVITE messages destined to the IP Group are sent to the IP address configured for the Proxy Set.

To configure Proxy Sets, see Configuring Proxy Sets.

Note:

■

For the Gateway application, IP Group ID 0 cannot be associated with Proxy Set ID 0.

■

The Proxy Set must be associated with the same SRD as that assigned to the IP Group.

■

You can assign the same Proxy Set to multiple IP Groups.

■

For the SBC application: Proxy Sets are used for Server-type IP Groups, but may in certain scenarios also be used for User-type IP Groups. For example, this is required in deployments where the device mediates between an IP PBX and a SIP Trunk, and the SIP Trunk requires SIP registration for each user that requires service. In such a scenario, the device must register all the users to the SIP Trunk on behalf of the IP PBX. This is done by using the User Information table, where each user is associated with the source IP Group (i.e., the IP PBX). To configure the User Information table, see SBC User Information for SBC User Database.

■

For the Gateway application, Proxy Sets are applicable only to Sever-type IP Groups.

'IP Profile'

ip-profile-name

[IPGroup_ProfileName]

Assigns an IP Profile to the IP Group.

By default, no value is defined.

To configure IP Profiles, see Configuring IP Profiles.

'Media Realm'

media-realm-name

[IPGroup_MediaRealm]

Assigns a Media Realm to the IP Group. The Media Realm determines the UDP port range and maximum sessions on a specific IP interface for media traffic associated with the IP Group.

By default, no value is defined.

To configure Media Realms, see Configuring Media Realms.

Note: If you delete a Media Realm in the Media Realms table that is assigned to the IP Group, the parameter value reverts to undefined.

'Internal Media Realm'

internal-media-realm-name

[IPGroup_InternalMediaRealm]

Assigns an "internal" Media Realm to the IP Group. This is applicable when the device is deployed in a Microsoft Teams environment. The device selects this Media Realm (instead of the Media Realm assigned by the 'Media Realm' parameter above) if the value of the X-MS-UserLocation header in the incoming SIP message is "Internal" and the 'Teams Local Media Optimization Handling' parameter (see below) is configured to any value other than None.

The Media Realm determines the UDP port range and maximum sessions on a specific IP interface for media traffic associated with the IP Group.

By default, no value is defined.

To configure Media Realms, see Configuring Media Realms.

Note:

■

The parameter is applicable only if you have configured the 'Teams Local Media Optimization Handling' parameter (see below) to any value other than None.

■

If you delete a Media Realm in the Media Realms table that is assigned to the IP Group, the parameter value reverts to undefined.

■

If you don't configure the parameter, the device uses the Media Realm that you assigned by the 'Media Realm' parameter.

'Contact User'

contact-user

[IPGroup_ContactUser]

Defines the user part of the From, To, and Contact headers of SIP REGISTER messages, and the user part of the Contact header of INVITE messages received from this IP Group and forwarded by the device to another IP Group.

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

Note:

■

The parameter is applicable only to Server-type IP Groups.

■

The parameter is overridden by the ‘Contact User’ parameter in the Accounts table (see Configuring Registration Accounts).

'SIP Group Name'

sip-group-name

[IPGroup_SIPGroupName]

Defines the hostname (e.g., 194.90.179.0) which the device uses to overwrite the original hostname (host part) of the URI in certain SIP headers. Therefore, the parameter allows you to implement topology hiding in SIP messages, by concealing the hostname of the communicating UAs from each another.

For the SBC application: The affected SIP headers depend on whether the IP Group is the destination or source of the call:

■

Destination IP Group: The device overwrites the host part of the following SIP headers for messages sent (outgoing) to this IP Group:

✔

For all requests: Request-URI header (if the destination of the request isn't a registered user or Trunk Group, and the URL in the Request-URI is not GRUU) and P-Called-Party-ID header.

✔

For all non-REGISTER requests (e.g., INVITE and SUBSCRIBE): To header and Remote-Party-ID header (only the first Remote-Party-ID header whose type is "called" in the message).

✔

For INVITE requests only: If the 'Destination URI Input' parameter is configured for the source IP Group, the header type configured by the 'Destination URI Input' parameter is also modified according to the 'SIP Group Name' parameter of the destination IP Group.

■

Source IP Group: The device overwrites the host part of the following SIP headers for messages received (incoming) from this IP Group.

✔

For all types of requests: From header.

✔

For REGISTER requests: To header.

✔

For all non-REGISTER requests (e.g., INVITE and SUBSCRIBE): P-Preferred-Identity (only first P-Preferred-Identity header in message), P-Asserted-Identity (only first P-Asserted-Identity header in message), Remote-Party-ID (only the first Remote-Party-ID header whose type is "calling" in the message).

✔

For INVITE requests only: If the 'Source URI Input' parameter is configured for the source IP Group, the header type configured by the 'Source URI Input' parameter is also overwritten according to the 'SIP Group Name' parameter of the source IP Group.

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

Note:

■

For the SBC application: When the IP Group is the source of the call, if you configure the destination IP Group's 'SIP Source Host Name' parameter (see below), the device ignores the 'SIP Group Name' parameter of the source IP Group. (The 'SIP Source Host Name' parameter also defines a URI host part to overwrite the original source host part, but it affects many more source-related SIP headers.)

■

When the parameter is configured for the source or destination IP Group, it overrides Inbound Message Manipulation rules (assigned by the 'Inbound Message Manipulation Set' parameter to the source IP Group) that manipulate the host part in the Request-URI, To, and From SIP headers. If you configure the parameter and you want to manipulate the host part in any of these SIP headers, assign your Message Manipulation rules to the destination IP Group using the 'Outbound Message Manipulation Set' parameter.

■

For the Gateway application: The parameter is not applicable when the IP Group is the source of the call. When the parameter is configured for the destination IP Group, the device uses the configured value to overwrite the host part in the Request-URI and To headers of INVITE requests, and the Request-URI of REGISTER requests sent (outgoing) to this IP Group.

■

For the Gateway application: If the IP Group is of User type, the parameter is used internally as a host name in the Request-URI for Tel-to-IP initiated calls. For example, if an incoming call from the device's trunk is routed to a User-type IP Group, the device first creates the Request-URI (<destination_number>@<SIP Group Name>), and then it searches the registration database for a match.

'Created By Routing Server'

[IPGroup_CreatedByRoutingServer]

(Read-only) Indicates whether the IP Group was created by a third-party routing server:

■

[0] No

■

[1] Yes

For more information on the third-party routing server feature, see Centralized Third-Party Routing Server.

'Used By Routing Server'

used-by-routing-server

[IPGroup_UsedByRoutingServer]

Enables the IP Group to be used by a third-party routing server for call routing decisions.

■

[0] Not Used (default)

■

[1] Used

For more information on the third-party routing server feature, see Centralized Third-Party Routing Server.

'Proxy Set Connectivity'

show voip proxy sets status

[IPGroup_ProxySetConnectivity]

(Read-only field) Displays the connectivity status with Server-type IP Groups. As the Proxy Set defines the address of the IP Group, the connectivity check (keep-alive) by the device is done to this address.

■

"NA": Functionality is not applicable due to one of the following:

✔

User-type IP Group.

✔

Server-type IP Group, but the keep-alive mechanism of its' associated Proxy Set is disabled.

■

"Not Connected": Keep-alive failure (i.e., no connectivity with the IP Group).

■

"Connected": Keep-alive success (i.e., connectivity with the IP Group).

The connectivity status is also displayed in the Topology View page (see Building and Viewing SIP Entities in Topology View).

Note:

■

The feature is applicable only to Server-type IP Groups.

■

To support the feature, you must enable the keep-alive mechanism of the Proxy Set that is associated with the IP Group (see Configuring Proxy Sets).

■

If the Proxy Set is configured with multiple proxies (addresses) and at least one of them is "alive", the displayed status is "Connected". To view the connected proxy server, see Viewing Proxy Set Status.

■

The "Connected" status also applies to scenarios where the device rejects calls with the IP Group due to low QoE (e.g., low MOS), despite connectivity.

SBC General

'Classify By Proxy Set'

classify-by-proxy-set

[IPGroup_ClassifyByProxySet]

Enables classification of incoming SIP dialogs (INVITEs) to Server-type IP Groups based on Proxy Set (assigned using the IPGroup_ProxySetName parameter).

■

[0] Disable

■

[1] Enable = (Default) The device searches the Proxy Sets table for a Proxy Set that is configured with the same source IP address as that of the incoming INVITE (if host name, then according to the dynamically resolved IP address list). If such a Proxy Set is found, the device classifies the INVITE as belonging to the IP Group associated with the Proxy Set.

Note:

■

The parameter is applicable only to Server-type IP Groups.

■

For security, it is recommended to classify SIP dialogs based on Proxy Set only if the IP address of the IP Group is unknown. In other words, if the Proxy Set associated with the IP Group is configured with an FQDN. In such cases, the device classifies incoming SIP dialogs to the IP Group based on the DNS-resolved IP address. If the IP address is known, it is recommended to use a Classification rule instead (and disable the Classify by Proxy Set feature), where the rule is configured with not only the IP address, but also with SIP message characteristics to increase the strictness of the classification process (see Configuring Classification Rules).

The reason for preferring classification based on Proxy Set when the IP address is unknown is that IP address forgery (commonly known as IP spoofing) is more difficult than malicious SIP message tampering and therefore, using a Classification rule without an IP address offers a weaker form of security. When classification is based on Proxy Set, the Classification table for the specific IP Group is ignored.

■

If you have assigned the same Proxy Set to multiple IP Groups, disable the parameter and instead, use Classification rules to classify incoming SIP dialogs to these IP Groups. If the parameter is enabled, the device is unable to correctly classify incoming INVITEs to their appropriate IP Groups.

■

Classification by Proxy Set occurs only if classification based on the device's registration database fails (i.e., the INVITE is not from a registered user).

■

The parameter is applicable only to the SBC application.

'SBC Operation Mode'

sbc-operation-mode

[IPGroup_SBCOperationMode]

Defines the device's operational mode for the IP Group.

■

[-1] Not Configured = (Default)

■

[0] B2BUA = Device operates as a back-to-back user agent (B2BUA), changing the call identifiers and headers between the inbound and outbound legs.

■

[1] Call Stateful Proxy = Device operates as a Stateful Proxy, passing the SIP message transparently between inbound and outbound legs. In other words, the same SIP dialog identifiers (tags, Call-Id and CSeq) occur on both legs (as long as no other configuration disrupts the CSeq compatibleness).

■

For more information on B2BUA and Stateful Proxy modes, see B2BUA and Stateful Proxy Operating Modes.

Note:

■

If configured, the parameter overrides the 'SBC Operation Mode' parameter in the SRDs table.

■

The parameter is applicable only to the SBC application.

'SBC Client Forking Mode'

sbc-client-forking-mode

[IPGroup_EnableSBCClientForking]

Defines call forking of INVITE messages to up to five separate SIP outgoing legs for User-type IP Groups. This occurs if multiple contacts are registered under the same AOR in the device's registration database.

■

[0] Sequential = (Default) Sequentially sends the INVITE to each contact. If there is no answer from the first contact, it sends the INVITE to the second contact, and so on until a contact answers. If no contact answers, the call fails or is routed to an alternative destination, if configured.

■

[1] Parallel = Sends the INVITE simultaneously to all contacts. The call is established with the first contact that answers.

■

[2] Sequential Available Only = Sequentially sends the INVITE only to available contacts (i.e., not busy). If there is no answer from the first available contact, it sends the INVITE to the second contact, and so on until a contact answers. If no contact answers, the call fails or is routed to an alternative destination, if configured.

Note:

■

The device can also fork INVITE messages received for a Request-URI of a specific contact (user) registered in the database to all other users located under the same AOR as the specific contact. This is configured by the [SBCSendInviteToAllContacts] parameter.

■

The parameter is applicable only to the SBC application.

'CAC Profile'

cac-profile

[IPGroup_AdmissionProfile]

Assigns a Call Admission Control Profile (CAC rules) to the IP Group.

By default, no value is defined.

To configure CAC Profiles, see Configuring Call Admission Control.

'SIP Source Host Name'

sip-source-host-name

[IPGroup_SIPSourceHostName]

Defines a hostname, which the device uses to overwrite the hostname of the URI in certain SIP headers. The parameter allows you to implement topology hiding for the source of SIP messages, by concealing the hostname of the source UA.

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

When the device forwards a SIP message to this IP Group, the configured hostname overwrites the host part in SIP headers (see below) that are concerned with the source of the message:

■

From, P-Asserted-Identity, P-Preferred-Identity, Referred-By, P-Charge-Info, Remote-Party-ID, P-Associated-URI, Diversion, and History-info headers.

■

If you configure the global parameter 'SIP Topology Hiding Mode' parameter to Fallback to IP Addresses and the 'Remote REFER Mode' [IpProfile_SBCRemoteReferBehavior] parameter to Regular (default), the host part in the Refer-To header is also overwritten.

■

For REGISTER requests, the host part in the To header is also overwritten.

Note:

■

The parameter is applicable only when the IP Group is the destination of the call (not source).

■

This parameter has higher priority than the 'SIP Group Name' parameter (see above) of the source IP Group. When this parameter is configured, the device ignores the value of the 'SIP Group Name' parameter that is configured for the source IP Group.

■

The parameter is applicable only to SIP dialog-initiating requests and in-dialog REFER requests.

■

The parameter is applicable only to the SBC application.

Advanced

'Local Host Name'

local-host-name

[IPGroup_ContactName]

Defines the host name (string) that the device uses in the SIP message's Via and Contact headers. This is typically used to define an FQDN as the host name. The device uses this string for Via and Contact headers in outgoing INVITE messages sent to a specific IP Group, and the Contact header in SIP 18x and 200 OK responses for incoming INVITE messages received from a specific IP Group. The IP-to-Tel Routing table can be used to identify the source IP Group from where the INVITE message was received.

If the parameter is not configured, these headers are populated with the device's dotted-decimal IP address of the network interface on which the message is sent.

By default, no value is defined.

Note: To ensure proper device handling, the parameter should be a valid FQDN.

'UUI Format'

uui-format

[IPGroup_UUIFormat]

Enables the generation of the Avaya UCID value, adding it to the outgoing INVITE sent to this IP Group.

■

[0] Disabled (default)

■

[1] Enabled

This provides support for interworking with Avaya equipment by generating Avaya's UCID value in outgoing INVITE messages sent to Avaya's network. The device adds the UCID in the User-to-User SIP header.

Avaya's UCID value has the following format (in hexadecimal): 00 + FA + 08 + node ID (2 bytes) + sequence number (2 bytes) + timestamp (4 bytes)

This is interworked in to the SIP header as follows:

User-to-User: 00FA080019001038F725B3;encoding=hex

Note: To define the Network Node Identifier of the device for Avaya UCID, use the 'Network Node ID' (NetworkNodeId) parameter.

'Always Use Src Address'

always-use-source-addr

[IPGroup_AlwaysUseSourceAddr]

Enables the device to always send SIP requests and responses, within a SIP dialog, to the source IP address received in the previous SIP message packet. This feature is especially useful in scenarios where the IP Group endpoints are located behind a NAT firewall (and the device is unable to identify this using its regular NAT mechanism).

■

[0] No = (Default) The device sends SIP requests according to the settings of the global parameter, SIPNatDetection.

■

[1] Yes = The device sends SIP requests and responses to the source IP address received in the previous SIP message packet.

For more information on NAT traversal, see Remote UA behind NAT.

SBC Advanced

'Source URI Input'

src-uri-input

[IPGroup_SourceUriInput]

Defines the SIP header in the incoming INVITE that is used for call matching characteristics based on source URIs.

■

[-1] Not Configured (default)

■

[0] From

■

[1] To

■

[2] Request-URI

■

[3] P-Asserted - First Header

■

[4] P-Asserted - Second Header

■

[5] P-Preferred

■

[6] Route

■

[7] Diversion

■

[8] P-Associated-URI

■

[9] P-Called-Party-ID

■

[10] Contact

■

[11] Referred-by

Note:

■

The parameter is applicable only to the SBC application.

■

The parameter is applicable only when classification is done according to the Classification table (see Configuring Classification Rules).

■

Once classified, the device uses the URI of the selected header for the following SIP headers in the outgoing INVITE: From, P-Asserted (if exists), P-Preferred (if exists), and Remote-Party-ID (if exists).

■

If the configured SIP header does not exist in the incoming INVITE message, the classification of the message to a source IP Group fails.

■

If the device receives an INVITE as a result of a REFER request or a 3xx response, then the incoming INVITE is routed according to the Request-URI. The device identifies such INVITEs according to a specific prefix in the Request-URI header, configured by the SBCXferPrefix parameter. Therefore, in this scenario, the device ignores the parameter setting.

'Destination URI Input'

dst-uri-input

[IPGroup_DestUriInput]

Defines the SIP header in the incoming INVITE to use as a call matching characteristic based on destination URIs. The parameter is used for classification and routing purposes. The device first uses the parameter’s settings as a matching characteristic (input) to classify the incoming INVITE to an IP Group (source IP Group) in the Classification table. Once classified, the device uses the parameter for routing the call. For example, if set to To, the URI in the To header of the incoming INVITE is used as a matching characteristic for classifying the call to an IP Group in the Classification table. Once classified, the device uses the URI in the To header as the destination.

■

[-1] Not Configured (default)

■

[0] From

■

[1] To

■

[2] Request-URI

■

[3] P-Asserted - First Header

■

[4] P-Asserted - Second Header

■

[5] P-Preferred

■

[6] Route

■

[7] Diversion

■

[8] P-Associated-URI

■

[9] P-Called-Party-ID

■

[10] Contact

■

[11] Referred-By

Note:

■

The parameter is applicable only to the SBC application.

■

The parameter can be configured for an IP Group regardless of the way in which SIP requests are classified to the IP Group (by Classification table, by Proxy Set or by the Registration database).

■

The Request-URI in the outbound side is modified according to the header selected by this parameter (if this parameter is configured), unless the Request-URI is overridden again by some other feature (e.g., Outbound Message Manipulations).

■

If the configured SIP header does not exist in the incoming INVITE message, the classification of the message to a source IP Group fails.

■

If the device receives an INVITE as a result of a REFER request or a 3xx response, the incoming INVITE is routed according to the Request-URI. The device identifies such INVITEs according to a specific prefix in the Request-URI header, configured by the SBCXferPrefix parameter. Therefore, in this scenario, the device ignores the parameter setting.

'SIP Connect'

sip-connect

[IPGroup_SIPConnect]

Defines the IP Group as representing multiple registering servers, each of which may use a single registration, yet represent multiple users. In addition, it defines how the device saves registration information for REGISTER messages received from the IP Group, in its registration database. For requests routed to the IP Group's users, the device replaces the Request-URI header with the incoming To header (which contains the remote phone number).

■

[0] No = (Default) Disables the SIP Connect feature. No extra key based on source IP address is added to the registration database and registration is done by Contact and Address of Record (AoR).

■

[1] Yes = Enables the SIP Connect feature. For initial registrations that are received from the IP Group, the device attempts to add two keys representing the user to its registration database:

✔

Key 1: The first key contains the incoming REGISTER message's source IP address, port (only if UDP), and SIP Interface ID (e.g., "10.33.3.3:5010#1").

✔

Key 2: The second key contains the incoming REGISTER message's URI (user@host) of the Contact header, source IP address, port (only if UDP), and SIP Interface ID (e.g., "user@host.com#10.33.3.3:5010#1").

The device classifies incoming non-REGISTER SIP dialog requests (e.g., INVITEs) from this IP Group, by first using the regular user search method in the registration database by Contact-AoR pair matching. If unsuccessful, the device searches the registration database for a matching Key 2 (i.e., Contact URI, source IP address, and port if the transport type is UDP). If no matching Key 2 exists, the device then searches for a matching Key 1 (i.e., source IP address only and port if the transport type is UDP). If no key is found at all, the device continues with the next Classification stage (e.g., by Proxy Set).

Note:

■

The parameter is applicable only to User-type IP Groups.

■

The parameter is applicable only to the SBC application.

'SBC PSAP Mode'

sbc-psap-mode

[IPGroup_SBCPSAPMode]

Enables E9-1-1 emergency call routing in a Microsoft Skype for Business environment.

■

[0] Disable (default)

■

[1] Enable

For more information, see E9-1-1 Support for Microsoft Skype for Business.

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

'Route Using Request URI Port'

use-requri-port

[IPGroup_SBCRouteUsingRequestURIPort]

Enables the device to use the port indicated in the Request-URI of the incoming message as the destination port when routing the message to the IP Group. The device uses the IP address (and not port) that is configured for the Proxy Set associated with the IP Group. The parameter thus allows the device to route calls to the same server (IP Group), but different port.

■

[0] Disable = (Default) The port configured for the associated Proxy Set is used as the destination port.

■

[1] Enable = The port indicated in the Request-URI of the incoming message is used as the destination port.

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

'Media TLS Context'

dtls-context

[IPGroup_DTLSContext]

Assigns a TLS Context (TLS configuration) to the IP Group that is used for secured media sessions (e.g., MSRPS) with the IP Group.

The default is the default TLS Context ("default" at Index 0).

To configure TLS Contexts, see Configuring TLS Certificates.

For more information on MSRP, see Configuring Message Session Relay Protocol.

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

'Keep Original Call-ID'

sbc-keep-call-id

[IPGroup_SBCKeepOriginalCallID]

Enables the device to use the same call identification (SIP Call-ID header value) received in incoming messages for the call identification in outgoing messages. The call identification value is contained in the SIP Call-ID header.

■

[0] No = (Default) The device creates a new Call-ID value for the outgoing message.

■

[1] Yes = The device uses the same Call-ID value received in the incoming message for the Call-ID in the outgoing message.

Note:

■

The parameter is applicable only to the SBC application.

■

When the device sends an INVITE as a result of a REFER/3xx termination, the device always creates a new Call-ID value and ignores the parameter's settings.

'Dial Plan'

sbc-dial-plan-name

[IPGroup_SBCDialPlanName]

Assigns a Dial Plan to the IP Group. The device searches the Dial Plan for a dial plan rule that matches the prefix of the source number and if not found, for a rule that matches the prefix of the destination number. If a matching Dial Plan rule is found, the rule's tag is used in the routing or manipulation processes as source or destination tags.

To configure Dial Plans, see Configuring Dial Plans.

Note:

■

The parameter is applicable only to the SBC application.

■

For IP-to-IP Routing rules that are configured for destination based on tags (i.e., 'Destination Type' parameter configured to Destination Tag), the parameter is applicable only to the source IP Group and the device searches the Dial Plan for a dial plan rule that matches the prefix of the destination number only. For more information on routing based on destination tags, see Using Dial Plan Tags for Routing Destinations.

'Call Setup Rules Set ID'

call-setup-rules-set-id

[IPGroup_CallSetupRulesSetId]

Assigns a Call Setup Rule Set ID to the IP Group. The device runs the Call Setup rule immediately before the routing stage (i.e., only after the classification and manipulation stages).

By default, no value is assigned.

To configure Call Setup Rules, see Configuring Call Setup Rules.

Note:

■

Call Setup Rules that are triggered from the IP Groups table (incoming IP Group) are done after identifying the incoming SIP Interface and after classification and manipulation for identifying the incoming IP Group, but before the routing stage (IP-to-IP Routing table). This supports all types of queries (Dial Plan, LDAP, ENUM, and HTTP).

■

The parameter is applicable only to the SBC application.

'Tags'

tags

[IPGroup_Tags]

Defines a tag, which can be implemented in one of the following manners:

■

Classification based on source tags: If the tag (name=value or value only) is the same tag as that of the incoming SIP dialog (obtained from the Call Setup Rule associated with the SIP Interface on which the dialog is received) and configured in the Classification table, then the incoming dialog is classified to this IP Group. For more information, see Configuring Classification Based on Tags.

■

Routing based on destination tags: Assigns a Dial Plan tag which determines whether the incoming SIP dialog is sent to this IP Group. The parameter is used when IP-to-IP Routing rules are configured for destinations-based on tags (i.e., 'Destination Type' parameter configured to Destination Tag). For more information, see Using Dial Plan Tags for Routing Destinations.

The valid value is a string of up to 70 characters. You can configure the parameter with up to five tags, where each tag is separated by a semicolon (;). However, you can configure only up to four tags containing a name and value (e.g., Country=Ireland), and one tag containing a value only (e.g., Ireland). You can also configure multiple tags with the same name (e.g., Country=Ireland;Country=Scotland). The following example configures the maximum number of tags (i.e., four name=value tags and one value-only tag): Country=Ireland;Country=Scotland;Country=RSA;Country=Canada;USA.

Note:

■

The parameter is applicable only to the SBC application.

■

For tag-based classification, if multiple IP Groups are configured with the same tag, the device classifies the incoming SIP dialog to the first matching IP Group.

'SBC Alternative Routing Reasons Set'

sbc-alt-route-reasons-set

[IPGroup_SBCAltRouteReasonsSetName]

Assigns an Alternative Reasons Set to the IP Group. This defines SIP response codes, which if received by the device from the IP Group, triggers alternative routing. Alternative routing could mean trying to send the SIP message to another online proxy (address) that is configured for the Proxy Set associated with the IP Group, or sending it to an alternative IP-to-IP Routing rule. For configuring Alternative Reasons Sets and for more information on how the device performs alternative routing, see Configuring SIP Response Codes for Alternative Routing Reasons.

By default, no value is defined.

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

'Teams Local Media Optimization Handling'

teams-local-media-optimization-handling

[IPGroup_TeamsLocalMediaOptimization]

Enables and defines Local Media Optimization handling when the central SBC device (proxy SBC scenario) is deployed in a Microsoft Teams environment. The handling is based on supplementary information provided by Microsoft proprietary SIP headers, X-MS-UserLocation and X-MS-MediaPath.

■

[0] None = (Default) The device ignores the Teams headers in the SIP message and uses the "regular" Media Realm assigned by the IP Group's 'Media Realm' parameter for the call.

■

[1] Teams Decides = The device's call handling depends on the Teams headers and call direction:

✔

Teams-to-SBC Call: If the call is a primary route, the device uses the Teams headers (X-MS-UserLocation and X-MS-MediaPath) in the incoming INVITE message. If the X-MS-UserLocation header value is "internal", the device uses the Media Realm assigned by the IP Group's 'Internal Media Realm' parameter. If the X-MS-UserLocation header value is "external", the device uses the Media Realm assigned by the IP Group's 'Media Realm' parameter. Based on the X-MS-MediaPath header, the device determines if it's a direct or non-direct media call. If the X-MS-UserLocation header value is "internal" and the first value of the X-MS-MediaPath header is the same value as configured for the IP Group's 'Local Host Name' parameter, the call traverses the device; otherwise, it bypasses the device (direct media).

The X-MS-UserLocation and X-MS-MediaPath headers can change upon re-INVITE messages (such as for conference calls).

If the call is a non-primary route (e.g., alternative route, 3xx, or forking), the device only uses the X-MS-UserLocation header in the incoming INVITE message, which it uses to select the appropriate Media Realm (as explained previously for primary routes). For non-primary routes, the media traverses the device (i.e., no direct media).

✔

SBC-to-Teams Call: The device forwards the INVITE message with the SDP received from the peer side to Teams according to the configuration of the IP Group's 'Teams Local Media Optimization Initial Behavior' parameter (see below). Based on the Teams headers in the 200 OK response from Teams, the device selects the appropriate Media Realm (as explained previously for Teams-to-SBC calls) and determines if it's a direct or non-direct media call (as explained previously for Teams-to-SBC calls).

■

[2] SBC Decides = The device only uses the X-MS-UserLocation header in the SIP message, which it uses to select the appropriate Media Realm (as explained previously for the Teams Decides option). When configured to the SBC Decides option, the media traverses the device (i.e., no direct media).

Note: For an outgoing INVITE message to Teams, the device sends the call as a non-direct media and uses the Media Realm assigned by the IP Group's 'Media Realm' parameter.

For an overview of Microsoft Teams Local Media Optimization feature, see Microsoft Teams with Local Media Optimization.

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

'Teams Local Media Optimization Initial Behavior'

teams-local-mo-initial-behavior

[IPGroup_TeamsLocalMOInitialBehavior]

Defines how the central SBC device (proxy SBC scenario) initially sends the received INVITE message with the SDP Offer to Teams when the device is deployed in a Microsoft Teams environment for its Local Media Optimization feature. The parameter is applicable when the device receives the SDP Offer from a remote site SBC and the 'Teams Local Media Optimization Handling' parameter is configured to Teams Decides or SBC Decides.

■

[0] Direct Media = (Default) The device sends the SDP Offer as is to Teams, indicating that the call is intended to be a direct media call (i.e., doesn't traverse the device).

Note: This option is applicable only when 'Teams Local Media Optimization Handling' parameter is configured to Teams Decides.

■

[1] Internal = The device sends the SDP Offer using the internal Media Realm (see the IP Group's 'Internal Media Realm' parameter) to Teams, indicating that the call is intended to be a non-direct media call (i.e., media traverses the central SBC device).

■

[2] External = The device sends the SDP Offer using the external (regular) Media Realm (see the IP Group's 'Media Realm' parameter) to Teams, indicating that the call is intended to be a non-direct media call (i.e., media traverses the central SBC device).

For a brief overview of Microsoft Teams Local Media Optimization feature, see Microsoft Teams with Local Media Optimization.

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

'Teams Direct Routing Mode'

teams-direct-routing-mode

[IPGroup_TeamsDirectRoutingMode]

Enables the device to include Microsoft's proprietary X-MS-SBC header in outgoing SIP INVITE and OPTIONS messages in a Microsoft Teams Direct Routing environment. The header is used by Microsoft Teams to identify vendor equipment (e.g., AudioCodes SBC).

■

[0] Disable = (Default) The device doesn't include the header in the outgoing SIP message.

■

[1] Enable = The device includes the header in the outgoing SIP message. The header's value is in the format 'AudioCodes/<model>/<firmware>', where:

✔

model is the product name of your AudioCodes device (valid values are listed by Microsoft at https://docs.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers).

✔

firmware is the software version running on the device.

Note:

■

You can't modify or remove the header using Message Manipulation.

■

The parameter is applicable only to the SBC application.

Quality of Experience

'QoE Profile'

qoe-profile

[IPGroup_QOEProfile]

Assigns a Quality of Experience Profile rule.

By default, no value is defined.

To configure Quality of Experience Profiles, see Configuring Quality of Experience Profiles.

'Bandwidth Profile'

bandwidth-profile

[IPGroup_BWProfile]

Assigns a Bandwidth Profile rule.

By default, no value is defined.

To configure Bandwidth Profiles, see Configuring Bandwidth Profiles.

Message Manipulation

'Inbound Message Manipulation Set'

inbound-mesg-manipulation-set

[IPGroup_InboundManSet]

Assigns a Message Manipulation Set (rule) to the IP Group for SIP message manipulation on the inbound leg.

By default, no value is defined.

To configure Message Manipulation rules, see Configuring SIP Message Manipulation.

Note:

■

The parameter is applicable only to the SBC application.

■

The IPGroup_SIPGroupName parameter overrides inbound message manipulation rules (assigned to the IPGroup_InboundManSet parameter) that manipulate the host name in Request-URI, To, and/or From SIP headers. If you want to manipulate the host name using message manipulation rules in any of these SIP headers, you must apply your manipulation rule (Manipulation Set ID) to the IP Group as an Outbound Message Manipulation Set (see the [IPGroup_OutboundManSet] parameter), when the IP Group is the destination of the call.

'Outbound Message Manipulation Set'

outbound-mesg-manipulation-set

[IPGroup_OutboundManSet]

Assigns a Message Manipulation Set (rule) to the IP Group for SIP message manipulation on the outbound leg.

By default, no value is defined.

To configure Message Manipulation rules, see Configuring SIP Message Manipulation.

Note: If you assign a Message Manipulation Set ID that includes rules for manipulating the host name in the Request-URI, To, and/or From SIP headers, the parameter overrides the [IPGroup_SIPGroupName] parameter.

'Message Manipulation User-Defined String 1'

msg-man-user-defined-string1

[IPGroup_MsgManUserDef1]

Defines a value for the SIP user part that can be used in Message Manipulation rules configured in the Message Manipulations table. The Message Manipulation rule obtains this value from the IP Group, by using the following syntax:

param.ipg.<src|dst>.user-defined.<0>.

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

To configure Message Manipulation rules, see Configuring SIP Message Manipulation.

'Message Manipulation User-Defined String 2'

msg-man-user-defined-string2

[IPGroup_MsgManUserDef2]

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

To configure Message Manipulation rules, see Configuring SIP Message Manipulation.

'Proxy Keep-Alive using IP Group Settings'

proxy-keepalive-use-ipg

[ProxyKeepAliveUsingIPG]

Enables the device to apply certain IP Group settings to keep-alive SIP OPTIONS messages or fake REGISTER messages that are sent by the device to the proxy server. The parameter is applicable only if you have enabled proxy keep-alive for the Proxy Set that is associated with the IP Group (see Configuring Proxy Sets).

■

[0] Disable = (Default) The IP Group's settings are not applied to the SIP messages.

■

[1] Enable = The following IP Group settings are applied (if configured) to the proxy keep-alive SIP messages:

✔

The IP Group's 'SIP Group Name' parameter (see above) value is used in the SIP messages.

✔

The IP Group's 'Outbound Message Manipulation Set' parameter (see above) is applied to the SIP messages (instead of manipulations configured by the [GWOutboundManipulationSet] parameter). You can also use the manipulation syntax "param.ipg.dst" for denoting the IP Group’s parameters.

✔

When filtering logs (configured in the Logging Filters table), the SIP messages are filtered by IP Group. For more information on log filtering, see Configuring Log Filter Rules.

Note: When multiple IP Groups are associated with the same Proxy Set, the parameter can be enabled only on one of them.

SBC Registration and Authentication

'Max. Number of Registered Users'

max-num-of-reg-users

[IPGroup_MaxNumOfRegUsers]

Defines the maximum number of users in this IP Group that can register with the device.

The default is -1, meaning that no limitation exists for registered users.

Note: The parameter is applicable only to User-type IP Groups.

'Registration Mode'

registration-mode

[IPGroup_RegistrationMode]

Defines the registration mode for the IP Group.

■

[0] User Initiates Registration (default)

■

[1] SBC Initiates Registration = Used when the device serves as a client (e.g., with an IP PBX). This functions only with the User Information table (see Configuring SBC User Information Table through Web Interface).

■

[2] Registrations not Needed = The device adds users to its database in active state.

'User Stickiness'

sbc-user-stickiness

[IPGroup_SBCUserStickiness]

Enables user "stickiness" (binding) to a specific registrar server. The registrar server is one of the IP addresses of the Proxy Set associated with this Server-type IP Group. This feature applies to users belonging to a User-type IP Group that are routed to this destination Server-type IP Group.

■

[0] Disable = After a successful initial registration of the user to a registrar, whenever the device receives a SIP request or registration refresh from the user, the device sends the request to whichever registrar (IP address of the Proxy Set) is currently active. In the case of proxy load-balancing, there is no certainty to which IP address the request is routed.

■

[1] Enable = The device always routes SIP requests (INVITEs, SUBSCRIBEs and REGISTER refreshes) received from the user to the same registrar server to which the last successful REGISTER request for that user was routed. In other words, once initial registration of the user to one of the IP addresses of the Proxy Set associated with this destination Server-type IP Group is successful (i.e., 200 OK), binding occurs to this specific address (registrar) and all future SIP requests from the user are routed (based on matched routing rule) only to this specific registrar.

Note:

■

The parameter is applicable only to Server-type IP Groups

■

The Proxy Set associated with the Server-type IP Group must be configured with multiple IP addresses (or an FQDN that resolves into multiple IP addresses).

■

This feature is also applicable to IP Group Sets (see Configuring IP Group Sets). If a user is bound to a registrar associated with this Server-type IP Group which also belongs to an IP Group Set, IP Group Set logic of choosing an IP Group is ignored and instead, the device always routes requests from this user to this specific registrar.

■

A user's "stickiness" to a specific registrar ends upon the following scenarios:

✔

If you modify the Proxy Set.

✔

If the Proxy Set is configured with an FQDN and a DNS resolution refresh removes the IP address to which the user is bound.

✔

User registration expires or the user initiates an unregister request.

■

The Proxy Set's Hot-Swap feature (for proxy redundancy) is not supported for users that are already bound to a registrar. However, you can achieve proxy "hot-swap" for failed initial (non-bounded) REGISTER requests. If the device receives a failure response for the initial REGISTER request and you have configured this response code for the Alternative Reasons Set associated (by the 'SBC Alternative Routing Reasons Set' parameter below) with the IP Group (see Configuring SIP Response Codes for Alternative Routing Reasons), "hot-swap" to the other IP addresses of the Proxy Set is done until a success response is received from one of the addresses. For failed REGISTER refresh requests from users that are already bound to a registrar, no "hot-swap" occurs for that request; only for subsequent refresh requests.

■

When using the User Information table (see SBC User Information for SBC User Database), registrar "stickiness" is supported only when the user initiates the REGISTER request. Therefore, you must configure the 'Registration Mode' parameter of the IP Group (User-type) to which the user belongs, to User Initiates Registration.

'User UDP Port Assignment'

user-udp-port-assignment

[IPGroup_UserUDPPortAssignment]

Enables the device to assign a unique, local UDP port (for SIP signaling) per registered user (User-type IP Group) on the leg interfacing with the proxy server (Server-type IP Group). The port is used for incoming (from the proxy to the user) and outgoing (from the user to the proxy) SIP messages. Therefore, the parameter must be enabled for the IP Group of the proxy server.

■

[0] Disable = (Default) The device uses the same local UDP port for all the registered users. This single port is configured for the SIP Interface ('UDP Port' parameter) associated with the Proxy Set of the proxy server.

■

[1] Enable = The device assigns each registered user a unique local port, chosen from a configured UDP port range. The port range is configured for the SIP Interface ('Additional UDP Ports' parameter) associated with the proxy server.

The device assigns a unique port upon the first REGISTER request received from the user. Subsequent SIP messages other than REGISTER messages (e.g., INVITE) from the user are sent to the proxy server on this unique local port. The device rejects the SIP request if there is no available unique port for use (due to the number of registered users exceeding the configured port range). The same unique port is also used for registration refreshes. The device de-allocates the port for registration expiry. For SIP requests from the proxy server, the local port on which they are received is irrelevant (unique port or any other port); the device does not use this port to identify the registered user.

Note:

■

This feature does not apply to SIP requests received from non-registered users. For these users, the device sends all requests to the proxy server on the single port configured for the SIP Interface ('UDP Port' parameter).

■

This feature is applicable only if the user initiates registration (i.e., user sends the REGISTER request). In other words, the 'Registration Mode' parameter of the IP Group of the user must be configured to User Initiates Registration.

'Authentication Mode'

authentication-mode

[IPGroup_AuthenticationMode]

Defines the authentication mode.

■

[0] User Authenticates = (Default) The device does not handle authentication, but simply forwards the authentication messages between the SIP user agents.

■

[1] SBC as Client = The device authenticates as a client. It receives the 401/407 response from the proxy requesting for authentication. The device sends the proxy the authorization credentials (i.e., username and password), which is obtained from one of the following (in chronological order):

If an Account exists in the Accounts table (see Configuring Registration Accounts) for the Served IP Group and the Serving IP Group (i.e., the IP Group you are now configuring), the device uses the username and password configured for the Account (only if authenticating a Server-type IP Group).

User Information file (see Configuring User Information).

The device uses the username and password configured for this IP Group in the IP Groups table ('Username' and 'Password' parameters).

Global username and password parameters (only if authenticating a Server-type IP Group).

Sends a request to users requesting credentials (only if authenticating a User-type IP Group).

■

[2] SBC as Server = The device acts as an Authentication server:

✔

Authenticates SIP clients. This is applicable only to User-type IP Groups. The device authenticates incoming SIP requests from users belonging to this IP Group. The device authenticates all the users, using the username and password configured in the IP Group's 'Username' and 'Password' parameters. However, if a user appears in the User Information table and which is configured with a username and password, then the device authenticates the user with the credentials in the User Information table (see Configuring SBC User Information). If you have not configured any username and password, and the [SBCServerAuthMode] parameter is configured to [0] (default), the device rejects the incoming SIP request.

✔

Authenticates SIP servers. This is applicable only to Server-type IP Groups.

'Authentication Method List'

authentication-method-list

[IPGroup_MethodList]

Defines SIP methods received from the IP Group that must be challenged by the device when the device acts as an Authentication server. If no methods are configured, the device doesn't challenge any methods.

By default, no value is defined. To define multiple SIP methods, use the backslash (\) to separate each method (e.g., INVITE\REGISTER). To authenticate only setup INVITE requests (and not re-INVITE requests), configure the parameter to "setup-invite" (without quotation marks).

Note: The parameter is applicable only if the 'Authentication Mode' parameter is set to SBC as Server.

'SBC Server Authentication Type'

sbc-server-auth-type

[IPGroup_TypeSBCServerAuthType]

Defines the authentication method when the device, as an Authentication server, authenticates SIP requests from the IP Group.

■

[-1] According to Global Parameter = (Default) Authentication is according to the settings of the SBCServerAuthMode parameter.

■

[0] Authentication is performed locally = The device authenticates incoming SIP requests locally. For more information, see SIP Authentication Server Functionality.

■

[2] According to draft-sterman-aaa-sip-01 = The device authenticates incoming SIP requests using a remote RADIUS server, based on Internet Draft "draft-sterman-aaa-sip-01". For more information, see RADIUS-based User Authentication.

■

[4] ARM Authentication = The device authenticates incoming SIP requests (INVITE or REGISTER) from User-type IP Groups, by first obtaining (REST-based API query) the user's password from a third-party routing server or AudioCodes ARM where the password is stored. Once the password is supplied, the device continues with the regular SIP digest authentication process (challenge) with the user. For more information on the third-party routing server or ARM, see Third-Party Routing Server or AudioCodes Routing Manager.

Note:

■

If you configure the parameter to any value other than According to Global Parameter, you need to configure the IP Group's 'Authentication Mode' parameter to SBC as Server.

■

If you configure the parameter to ARM Authentication, you also need to configure the IP Group's 'Authentication Method List' parameter to authenticate INVITE or REGISTER messages.

'Username'

username

[IPGroup_Username]

Defines the shared username for authenticating the IP Group.

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

Note: If you configure the 'Authentication Mode' parameter to SBC as Server, you need to specify the SIP request (method) types (e.g., INVITE) that must be challenged by the device, using the IP Group's 'Authentication Method List' parameter.

'Password'

password

[IPGroup_Password]

Defines the shared password for authenticating the IP Group.

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

Note:

■

If you configure the 'Authentication Mode' parameter to SBC as Server, you can specify the SIP request (method) types (e.g., INVITE) that must be challenged by the device, using the IP Group's 'Authentication Method List' parameter.

■

The password cannot be configured with wide characters.

Gateway

'SIP Re-Routing Mode'

re-routing-mode

[IPGroup_SIPReRoutingMode]

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

■

[-1] = Not Configured (Default)

■

[0] Standard = 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. This is applicable only if a Proxy server is used and the parameter [AlwaysSendtoProxy] is set to [0].

■

[2] Routing Table = Uses the Routing table to locate the destination and then sends a new INVITE to this destination.

Note:

■

When the parameter is configured to [1] and the INVITE sent to the Proxy fails, the device re-routes the call according to the Standard mode [0].

■

When the parameter is configured to [2] and the INVITE fails, the device re-routes the call according to the Standard mode [0]. 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.

■

When the parameter is set to [2], the [XferPrefix] parameter can be used to define different routing rules for redirected calls.

■

The parameter is ignored if the parameter [AlwaysSendToProxy] is set to [1].

'Always Use Route Table'

always-use-route-table

[IPGroup_AlwaysUseRouteTable]

Defines the Request-URI host name in outgoing INVITE messages.

■

[0] No (default).

■

[1] Yes = The device uses the IP address (or domain name) defined in the Tel-to-IP Routing table (see Configuring Tel-to-IP Routing Rules) as the Request-URI host name in outgoing INVITE messages, instead of the value configured in the 'SIP Group Name' field.

Note: The parameter is applicable only to Server-type IP Groups.

GW Group Status

'GW Group Registered IP Address'

(Read-only field) Displays the IP address of the IP Group entity (gateway) if registered with the device; otherwise, the field is blank.

Note: The field is applicable only to Gateway-type IP Groups (i.e., the 'Type' parameter is configured to Gateway).

'GW Group Registered Status'

(Read-only field) Displays whether the IP Group entity (gateway) is registered with the device ("Registered" or "Not Registered").

Note: The field is applicable only to Gateway-type IP Groups (i.e., the 'Type' parameter is configured to Gateway).