Configuring IP Groups

'SRD'

srd-name

[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.

'Index'

[Index]

Defines an index for the new table row.

Note:

■

Each row must be configured with a unique index.

'Name'

name

[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:

■

Configure each row with a unique name.

■

The parameter value can't contain a forward slash (/).

■

The parameter value can't be configured with the character string "any" (upper or lower case).

'Topology Location'

topology-location

[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

[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 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 = 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 doesn't 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

[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:

■

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.

■

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 SBC User Information table, where each user is associated with the source IP Group (i.e., the IP PBX). To configure the SBC User Information table, see SBC User Information for SBC User Database.

'IP Profile'

ip-profile-name

[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

[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

[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

[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

[SIPGroupName]

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

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:

■

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.

'Created By Routing Server'

[CreatedByRoutingServer]

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

■

[0] No

■

[1] Yes

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

'Used By Routing Server'

used-by-routing-server

[UsedByRoutingServer]

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

■

[0] Not Used (default)

■

[1] Used

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

'Proxy Set Connectivity'

show voip proxy sets status

[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.

'Classify By Proxy Set'

classify-by-proxy-set

[ClassifyByProxySet]

Enables the classification of incoming SIP dialog messages to a Server-type IP Group based on Proxy Set.

■

[0] Disable

■

[1] Enable = (Default) Enables classification by Proxy Set of all types of incoming SIP dialog messages (e.g., INVITE, OPTIONS, and REGISTER) to a Server-type IP Group.

By default, the device checks if the source IP address (ISO Layer 3) of the incoming SIP dialog matches an IP address in the Proxy Set that is associated with the IP Group (see the 'Proxy Set' parameter). If the Proxy Set is configured with a hostname, the device checks if the source IP address matches one of the dynamically DNS-resolved IP addresses. If such a Proxy Set exists, the device classifies the SIP dialog to the IP Group associated with this Proxy Set.

You can also configure classification by Proxy Set whereby the device checks if the IP address in the SIP Contact header of the incoming SIP dialog matches an IP address in the Proxy Set that is associated with the IP Group. If the header contains a SIP URI that has an IP address (not hostname) in the host part and it matches an IP address in the Proxy Set, the call is classified to the IP Group. This mode is useful, for example, when the source IP address is an internal address.

To specify which IP address to use (source IP address or SIP Contact header's IP address) in the incoming SIP message for classification by Proxy Set, use the global parameter 'Classify By Proxy Set Mode' (Setup menu > Signaling & Media tab > SIP Definitions folder > SIP Definitions General Settings). When configured to Both, the device first checks if the source IP address matches an IP address in the Proxy Set. Only if there is no match, does it check if the IP address in the SIP Contact header matches an IP address in the Proxy Set.

■

[2] Enable for OPTIONS = Enables classification by Proxy Set of incoming SIP OPTIONS (only) messages to a Server-type IP Group. For a detailed description of this option, see the description of the Enable value (above).

Note:

■

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

■

For security, it's recommended to classify SIP dialogs based on Proxy Set only if the IP address of the IP Group is unknown (i.e., 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's recommended to use Classification rules instead (and disable the Classify by Proxy Set feature), where the rules are 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 use Classification rules instead to classify incoming SIP dialogs to these IP Groups (see Configuring Classification Rules). 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., INVITE isn't from a registered user).

'Validate Source IP'

validate-source-ip

[ValidateSourceIP]

Enables the device to validate the source IP address of incoming SIP dialog-initiating requests (e.g., INVITE messages) by checking that it matches an IP address (or DNS-resolved IP address) in the Proxy Set that is associated with the IP Group.

The feature applies both to messages that were classified to IP Groups by Proxy Set (i.e., by configuring the IP Group's 'Classify By Proxy Set' parameter to Enable), as well as to messages classified by rules in the Classification table (see Configuring Classification Rules).

This feature is especially useful when you need to classify SIP dialogs originating from the same Proxy Set, into multiple IP Groups, where Classification table rules are necessary to produce the desired mapping to the different IP Groups.

■

[0] Disable (default)

■

[1] Enable

Note:

■

Validation is done after Classification, but before Manipulation and Routing.

■

Validation is done for the IP address only (not port, transport, or SIP Interface).

■

Upon validation failure, the device rejects the incoming SIP dialog with a 500 SIP response (Reason header value is "Source IP doesn't match Proxy Set").

■

Don't enable this parameter if the global 'Classify By Proxy Set Mode' parameter is configured to Contact Header or Both, as in most cases, the source IP address of the SIP message will not be a member of the Proxy Set.

■

This feature is typically used for Server-type IP Groups. However, you can also use it for User-type IP Groups.

'SBC Operation Mode'

sbc-operation-mode

[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.

'SBC Client Forking Mode'

sbc-client-forking-mode

[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.

'CAC Profile'

cac-profile

[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

[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' 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.

'Local Host Name'

local-host-name

[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

[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

[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.

'Source URI Input'

src-uri-input

[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 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 doesn't 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

[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 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 doesn't 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

[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

[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.

'Route Using Request URI Port'

use-requri-port

[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.

'Media TLS Context'

dtls-context

[DTLSContext]

Assigns a TLS Context (TLS configuration) to the IP Group that is used for secured media sessions (e.g., DTLS) 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 DTLS, see SRTP using DTLS Protocol.

'Keep Original Call-ID'

sbc-keep-call-id

[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:

■

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

[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, it searches 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 the source or destination tag.

To configure Dial Plans, see Configuring Dial Plans.

Note:

■

For destination tag-based routing (i.e., 'Destination Type' parameter of IP-to-IP Routing rules configured to Destination Tag):

✔

The parameter is applicable only to the source IP Group. The device searches the Dial Plan for a dial plan rule that matches the prefix of the destination number only.

✔

If a destination tag is determined during the routing stage by a Call Setup Rule (i.e., Call Setup Rule Set assigned to the IP-to-IP Routing rule's 'Pre Route Call Setup Rules Set ID' parameter), the tag overrides any other determined tag (i.e., from the Dial Plan or Call Setup Rule Set of the SIP Interface).

✔

For more information on tag-based routing, see Using Dial Plan Tags for Routing Destinations.

'Call Setup Rules Set ID'

call-setup-rules-set-id

[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).

✔

If a destination tag is determined during the routing stage by a Call Setup Rule (i.e., Call Setup Rule Set assigned to the IP-to-IP Routing rule's 'Pre Route Call Setup Rules Set ID' parameter), the tag overrides any other determined tag (i.e., from the Dial Plan or Call Setup Rule Set of the SIP Interface).

✔

For more information on tag-based routing, see Using Dial Plan Tags for Routing Destinations.

'Tags'

tags

[Tags]

Defines tags (name=value or value only), which can be implemented in one of the following ways:

■

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: If this tag is matched, the device sends the incoming SIP dialog 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 on tag-based routing, see Using Dial Plan Tags for Routing Destinations.

The valid value is:

■

A string of up to 255 characters.

■

Up to five tags, where each tag is separated by a semicolon (;).

■

Up to four tags containing a name with a value (e.g., Country=Ireland).

■

Only one tag containing a value only (e.g., Ireland).

■

You can 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: 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

[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.

'Teams Local Media Optimization Handling'

teams-local-media-optimization-handling

[TeamsLocalMediaOptimization]

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

■

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

■

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

✔

Inbound calls to Teams (PSTN-to-Teams): The device sends the initial INVITE message using the settings of the 'Teams Local Media Optimization Initial Behavior' parameter. When a SIP 200 OK is received in response, the device uses the X-MS-MediaPath header to determine if it's a direct media call. For these calls, the device never uses the Dial Plan Region Connectivity feature (see Using Dial Plans for Microsoft Local Media Optimization).

✔

Outbound calls from Teams (Teams-to-PSTN): If the parameter is configured to Teams Decides and the call is the primary (initial) route, the device uses the X-MS-MediaPath header to determine if it is a direct media call. For secondary routes (e.g., 3xx, alternative route, call forking, or transfer) or if the parameter is configured to SBC Decides, the device uses the X-MS-UserLocation and X-MS-UserSite headers together with the 'Regions Connectivity Dial Plan' parameter to determine if it's a direct media call (see Using Dial Plans for Microsoft Local Media Optimization).

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

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

'Teams Local Media Optimization Initial Behavior'

teams-local-mo-initial-behavior

[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).

■

[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 an overview of Microsoft Teams Local Media Optimization feature, see Microsoft Teams with Local Media Optimization.

'Teams Local Media Optimization Site'

teams-local-mo-site

[TeamsLocalMOSite]

Defines the name of the Teams site (e.g., "Singapore") within which the Teams client is located, when the device is deployed in a Microsoft Teams environment for its Local Media Optimization feature. The Teams site is indicated in the Microsoft proprietary SIP header, X-MS-UserSite of the incoming SIP message received from the Teams client.

The device searches the Dial Plan, specified by the 'Regions Connectivity Dial Plan' parameter, to check if this IP Group's Teams site and the Teams site of the destination IP Group share a common group number. If they do share a group number, it means that the path between them is good for high quality voice and the device considers the call as intended for direct media (bypass). For more information, see Using Dial Plans for Microsoft Local Media Optimization.

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

Note:

■

The parameter is applicable only to Teams-to-PSTN calls.

'Teams Direct Routing Mode'

teams-direct-routing-mode

[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 displayed 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.

'Metering Remote Type'

metering-remote-type

[MeteringRemoteType]

Defines if the IP Group represents the VoiceAI Connect entity.

■

[0] Regular = (Default) The IP Group represents a normal SIP proxy entity.

■

[1] VAIC = The IP Group represents VoiceAI Connect.

Note: Leave the parameter at its default setting (i.e., Regular). The parameter is used only by AudioCodes support.

'QoE Profile'

qoe-profile

[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

[BWProfile]

Assigns a Bandwidth Profile rule.

By default, no value is defined.

To configure Bandwidth Profiles, see Configuring Bandwidth Profiles.

'User Voice Quality Report'

user-voice-quality-report

[UserVoiceQualityReport]

Enables MOS calculation and reporting of calls belonging to users that are registered with the device.

■

[0] Disable (Default)

■

[1] Enable

For more information on this feature, see Configuring Voice Quality for Registered Users.

Note:

■

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

■

If you have configured a Quality of Service rule for rejecting calls or using an alternative IP Profile if MOS levels become low (see Configuring Quality of Service Rules), it's unnecessary to enable this parameter because you need to select an IP Group when configuring the rule. If you don't configure a Quality of Service rule, then you need to enable this parameter.

'Inbound Message Manipulation Set'

inbound-mesg-manipulation-set

[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 'SIP Group Name' parameter overrides inbound message manipulation rules (assigned to the 'Inbound Message Manipulation Set' 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 'Outbound Message Manipulation Set' parameter) when the IP Group is the destination of the call.

'Outbound Message Manipulation Set'

outbound-mesg-manipulation-set

[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 'SIP Group Name' parameter.

'Message Manipulation User-Defined String 1'

msg-man-user-defined-string1

[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

[MsgManUserDef2]

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.<1>.

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 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 OPTIONS messages.

■

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

✔

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

✔

The IP Group's 'Outbound Message Manipulation Set' parameter (see above) is applied to the OPTIONS 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 OPTIONS messages are filtered by IP Group. For more information on log filtering, see Configuring Logging Filter Rules.

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

'Max. Number of Registered Users'

max-num-of-reg-users

[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

[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 SBC 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.

'Dedicated Connection Mode'

dedicated-connection-mode

[DedicatedConnectionMode]

Enables the device to establish and use a dedicated TCP (TLS) connection with the SIP registrar server per user listed in the SBC User Information table.

The dedicated connection is established when the device initially registers (SIP REGISTER) the user with the server. All subsequent SIP dialogs (e.g., INVITE) originating from the user are sent to the server over this dedicated connection.

If you enable this feature and there is no valid dedicated connection when the user sends a SIP dialog-initiating request, the device rejects the SIP dialog. This also triggers the device to do a registration refresh with the server for the specific user.

■

[0] Disable = (Default) The same connection may be used for all users, depending on the [EnableTCPConnectionReuse] parameter settings.

■

[1] Per User in SBC User Information Table = The device establishes a dedicated connection per user.

Note:

■

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

■

To support this feature, you also need to do the following:

✔

Configure the 'Registration Mode' parameter (above) to SBC Initiates Registration for this User-type IP Group.

✔

Configure each relevant user in the SBC User Information table so that they are associated with this User-type IP Group (see Configuring SBC User Information Table through Web Interface).

✔

Configure the Proxy Set that is associated with the Server-type IP Group representing the registrar server, for TCP (or TLS) transport type (see Configuring Proxy Sets).

✔

Configure the associated IP-to-IP Routing rule (see Configuring SBC IP-to-IP Routing Rules) to send all SIP messages from the User-type IP Group to 'Destination Type' IP Group and the 'Destination IP Group' should be the Server-type IP Group (i.e., the registrar server).

■

The Homing redundancy mode for the Proxy Set ('Redundancy Mode' parameter) of the Server-type IP Group isn’t supported for this feature; a dedicated connection with the server is always preferable, as long as it's valid and not offline.

■

If you modify configuration relating to the user (e.g., IP-to-IP Routing rule) at any time after this feature has been configured, the device may no longer have a valid, dedicated connection until it's time to send a refresh REGISTER message for the user.

■

This feature poses the following constraints:

✔

The maximum number of users that can have a dedicated TLS connection is less than the maximum number of rows (users) that you can configure in the SBC User Information table (see Configuring SBC User Information Table through Web Interface).

✔

When the device needs to open a new TLS connection for a user (SBC User Information entry), it only establishes the connection if the number of currently established TLS connections (incoming and outgoing) is less than the maximum number of supported TLS connections by the device. If the maximum is exceeded, it doesn't open the TLS connection and doesn't send a registration request to the proxy server for the user. For the maximum number of concurrent TLS connections supported by the device, refer to 'Capacity per Feature' in the Release Notes.

'User Stickiness'

sbc-user-stickiness

[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 SBC 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.

■

This feature is also supported when the device operates in HA mode; registrar "stickiness" is retained even after an HA switchover.

'User UDP Port Assignment'

user-udp-port-assignment

[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 doesn't use this port to identify the registered user.

Note:

■

This feature doesn't 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).

■

For HA systems, the unique port assigned to a registered user is also used after an HA switchover.

■

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

[AuthenticationMode]

Defines the authentication mode.

■

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

■

[1] SBC as Client = The device authenticates as a client. When the device receives a SIP 401/407 response from the proxy requesting authentication for the outgoing SIP request, it sends the proxy its credentials (i.e., username and password), which it obtains from one of the following (listed in order of preference):

a.

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

b.

The device obtains the credentials from the SBC User Information table (see Configuring SBC User Information).

c.

The device obtains the credentials configured for this IP Group in the IP Groups table ('Username As Client' and 'Password As Client' parameters).

d.

The device obtains the credentials from the global username and password parameters (only if authenticating a Server-type IP Group).

e.

If no applicable credentials are found, the device forwards the SIP 401/407 response to the SIP UA.

■

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

✔

Authenticates SIP clients: The device challenges (authenticates) incoming SIP requests from users belonging to this IP Group. When the 'SBC Server Authentication Type' parameter (see below) is configured to Authentication is performed locally, the device authenticates the users based on the username and password configured for this IP Group ('Username As Server' and 'Password As Server' parameters). However, if a user appears in the SBC User Information table and is configured with a username and password, the device authenticates the user with the credentials in the SBC User Information table (see Configuring SBC User Information). If you have not configured a username and password, the device rejects the incoming SIP request.

✔

Authenticates SIP servers (applicable only to Server-type IP Groups).

Note: Configure the SIP request (method) types (e.g., INVITE) that the device must challenge when acting as an authentication server, using the IP Group's 'Authentication Method List' parameter.

■

[3] SBC as Both Client and Server = The device authenticates both as a client and an authentication server. For a description of each mode, see the optional values SBC as Client and SBC as Server.

'Authentication Method List'

authentication-method-list

[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 you configure the device to act as an Authentication server (i.e., 'Authentication Mode' parameter is SBC as Server or SBC as Both Client and Server).

'SBC Server Authentication Type'

sbc-server-auth-type

[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 [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 Authentication of SIP User Agents.

■

[3] Authenticate with OAuth Server = The device authenticates incoming SIP requests according to token-based authentication with an OAuth 2.0 authorization server (internal or external). The OAuth 2.0 server is configured as a Remote Web Service. The server is assigned to the IP Group using the IP Group's 'OAuth HTTP Service' parameter. For more information, see OAuth 2.0 Based SIP Message 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 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 option except Authentication is performed locally, you also need to configure the device to act as an Authentication server (i.e., 'Authentication Mode' parameter is SBC as Server or SBC as Both Client and 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.

'OAuth HTTP Service'

oauth-http-service

[OAuthHTTPService]

Assigns a Remote Web Service to the IP Group. The Remote Web Service represents the OAuth 2.0 authorization server (internal or external), which the device uses to authenticate incoming SIP requests as a server. The device sends the OAuth token received from the client to the OAuth 2.0 server for authentication.

To configure Remote Web Services, see Configuring Remote Web Services. For more information on OAuth-based authentication, see OAuth 2.0 Based SIP Message Authentication.

Note: The parameter is applicable only if the IP Group's 'SBC Server Authentication' parameter is configured to Authenticate with OAuth Server.

'Username As Client'

username-as-client

[UsernameAsClient]

Defines the username that is used when the device is challenged (SIP 401/407) by this IP Group for retrying the outgoing SIP request toward this IP Group.

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

Note: The parameter is applicable only if you configure the device to authenticate as a client (i.e., 'Authentication Mode' parameter is SBC as Client or SBC as Both Client and Server).

'Password As Client'

password-as-client

[PasswordAsClient]

Defines the password that is used when the device is challenged (SIP 401/407) by this IP Group for retrying the outgoing SIP request toward this IP Group.

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

Note:

■

The parameter is applicable only if you configure the device to authenticate as a client (i.e., 'Authentication Mode' parameter is SBC as Client or SBC as Both Client and Server).

■

The password cannot include wide characters.

'Username As Server'

username-as-server

[UsernameAsServer]

Defines the username that is used when the device challenges (authenticates) incoming SIP requests from users belonging to this IP Group (for User-type IP Groups), or challenges SIP servers (for Server-type IP Groups).

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

Note: The parameter is applicable only if you configure the device to act as an Authentication server (i.e., 'Authentication Mode' parameter is SBC as Server or SBC as Both Client and Server).

'Password As Server'

password-as-server

[PasswordAsServer]

Defines the password that is used when the device challenges (authenticates) incoming SIP requests from users belonging to this IP Group (for User-type IP Groups), or challenges SIP servers (for Server-type IP Groups).

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

Note:

■

The parameter is applicable only if you configure the device to act as an Authentication server (i.e., 'Authentication Mode' parameter is SBC as Server or SBC as Both Client and Server).

■

The password cannot include wide characters.

'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). For User-type and Server-type IP Groups, the field displays "NA".

'GW Group Registered Status'

(Read-only field) Displays if 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). For User-type and Server-type IP Groups, the field displays "NA".