Active Directory-based Call Routing

A large percentage of enterprises use call servers with Active Directory (Domain Controller) such as Media Servers, Exchange Servers, and Lync Servers. For enterprises that integrate these servers in parallel to their existing communications infrastructure, or transition from their legacy Private Branch Exchange (PBX) to these types of servers, Active Directory becomes a more efficient and cost-effective way of routing the incoming calls within the core enterprise network.

Clients using Microsoft servers such as a Lync Server deploy their own URI. Therefore, a user in a network with both a desk phone and a Lync client has an IP PBX extension/URI for the desk phone, and a different URI for the Lync client. Currently, all PSTN traffic is sent by default to a legacy PBX in the core network. If the PBX does not recognize the extension/URI, the PBX forwards it to the Lync client. Sending traffic to the PBX first and then to the Lync Server can be costly in terms of compute resources and licensing fees. Routing all incoming sessions from a SIP trunk to the Lync Server first and then to a PBX can be costly.

As a solution, the Oracle® Enterprise Session Border Controller (E-SBC) initiates a query to the Active Directory to initially determine the type of incoming call. The E-SBC then stores data used to facilitate the routing decision of the call (performed by Lightweight Directory Access Protocol (LDAP)) and routes the call the first time to the applicable destination (PBX or Lync Server).

In scenarios where a user has both a Lync phone and a legacy PBX phone, calls destined for the Lync phone number can be routed to the PBX phone number, or calls destined for the PBX phone number can be routed to the Lync phone number. The destination depends on the current E-SBC configuration. The E-SBC uses the information stored in the enterprise’s Active Directory, compares it to the ESD configuration and then determines which phone number to utilize for the destined user.

Note:

The Active Directory-based call routing feature supports confidential and secure LDAP traffic support by using SSL/TLS (LDAPS).

Active Directory-based call routing is a feature of the E-SBC that facilitates the routing of incoming calls to the appropriate destinations within the Enterprise core network. The E-SBC LDAP query to the Active Directory yields whether or not the phone number is associated with a call Server or the PBX.

When the E-SBC receives an inbound SIP INVITE over a SIP Trunk (), it checks the current LDAP configuration in the E-SBC. Depending on this configuration, the E-SBC then accesses the Enterprise’s Active Directory to search for the applicable number being called via an LDAP query (). When the query has found the number to forward the call, the E-SBC routes the call directly to the call server client () or to the IP PBX phone () and ) as shown in the illustration below.

The Enterprise is responsible for migrating phone numbers from the legacy PBX to the call server by making the necessary updates in their Active Directory in order for the E-SBC to route the call properly. In the illustration above, the IP PBX extension (4392) is the primary telephone number (+1.781.328.4392); a secondary transition number (+1.781.430.7069) is assigned to Lync.

LDAP in the Oracle® Enterprise Session Border Controller

Lightweight Directory Access Protocol (LDAP) is the Protocol that the Oracle® Enterprise Session Border Controller uses to perform queries to the Enterprise’s Active Directory to determine where to route incoming calls (to the call server or the IP PBX) in the Enterprise network. Session requests and responses are sent/received based on the Oracle® Enterprise Session Border Controller’s LDAP routing configuration. LDAP determines the destination (call server user or non-call server user) and forwards the call accordingly.

The Oracle® Enterprise Session Border Controller, using LDAP, performs the following on an inbound call:

• Creates an LDAP search filter based on the dialed number and the configured LDAP attributes.
• Sends an LDAP search query to the configured LDAP Server.
• Creates a route list based on the query response received from the LDAP Server.
• Routes calls to both the call server and the IP PBX. The routing order is dependent on the LDAP attribute configuration and/or whether there was an exact match for the dialed phone number in the Enterprise’s Active Directory for the call server or the IP-PBX.

Note:

You configure LDAP Servers, filters, and local policy routing using the ACLI objects and attributes. For more information about configuring LDAP, see Configuring LDAP.

The Oracle® Enterprise Session Border Controller keeps a permanent LDAP session open to all configured call servers. It sends an LDAP bind request on all established connections, to those servers. The first call server is considered the primary LDAP Server, and all others are secondary LDAP servers. If a query request sent to the primary server fails, the Oracle® Enterprise Session Border Controller sends the request to the next configured LDAP Server, until the request is successful in getting a response. If no response is received by the Oracle® Enterprise Session Border Controller and the Oracle® Enterprise Session Border Controller cannot find another route successfully, (all Oracle® Enterprise Session Border Controller configured attributes have been exhausted (local policies, policy attributes, etc.)), it sends a busy to the caller.

LDAP performs call routing based on LDAP attributes configured on the Oracle® Enterprise Session Border Controller. The route-mode attribute setting determines how LDAP handles the called number when accessing the Enterprise’s Active Directory. Routing modes can be set to any of the following:

• Exact-match-only (default)
• Attribute-order-only
• Exact-match-first

The following paragraphs describe each of these route-modes.

Exact-match-only

If the LDAP route-mode attribute is set to exact-match-only, the Oracle® Enterprise Session Border Controller performs as follows.

The Oracle® Enterprise Session Border Controller receives an incoming call to the Enterprise network. If the LDAP route-mode attribute on the Oracle® Enterprise Session Border Controller is set to exact-match-only, LDAP queries the Active Directory to find the number that matches exactly to the incoming number. If the number is found, the Oracle® Enterprise Session Border Controller forwards the call to the client’s applicable phone in the Enterprise network.

Number	Description
①	Call comes into the Enterprise network (+1.781.328.4413)
②	Using the configured route-mode of exact-match-only, LDAP queries the exact matching number in the Enterprise’s Active Directory.
③	The Active Directory finds the matching number and that number is included in the response to the LDAP query.
④	The Oracle® Enterprise Session Border Controller forwards the call to the destination phone number (same number as the number that initially called into the Enterprise in Step 1 (+1.781.328.4413)).

Attribute-order-only

If the LDAP route-mode attribute is set to attribute-order-only, the Oracle® Enterprise Session Border Controller performs as follows.

The order in which the LDAP attributes are configured on the Oracle® Enterprise Session Border Controller determines the priority of each route. If an incoming call is destined for the IP-PBX , but the attribute name for a Lync client is configured first, the Oracle® Enterprise Session Border Controller uses the corresponding next hop (Lync Server) to create the first route in the route list.

An entry in an LDAP search response must have at least one attribute that it matches in the Active Directory.

For example, the incoming phone number could be +1.781.328.4392 (which matches the IP-PBX phone number), and the attribute name msRTCSIP-Line (Lync attribute) in the response could be +1.781.430.7069 (Lync phone number). A route is created for the Lync phone number, even though the incoming phone number matches the IP-PBX phone number, since the msRTCSIP-Line attribute was configured first. Therefore, the Oracle® Enterprise Session Border Controller forwards the call to the Lync destination.

Likewise, if an Enterprise uses the same phone number for both Lync and IP-PBX phones, and the attribute-name msRTCSIP-Line is configured first (a Lync attribute), the Oracle® Enterprise Session Border Controller uses the corresponding next hop (Lync Server) to create the first route in the route list.

Number	Description
①	Call comes into the Enterprise network (+1.781.328.4392)
②	Using the configured route-mode of attribute-order-only, LDAP queries the Active Directory for the matching number.
③	The Active Directory responds with the phone number associated with the first configured LDAP attribute (+1.781.430.7069). In the illustration above, the number was associated with a Lync Client (msRTCSIP-Line) that was configured first in the LDAP configuration.
④	The Oracle® Enterprise Session Border Controller forwards the call to the applicable destination phone number from the Active Directory response. (+1.781.430.7069).

If you configure the attribute name msRTCSIP-Line first, the Oracle® Enterprise Session Border Controller uses the corresponding next hop (Lync Server) to create the second highest priority route in the route list. For example, the dialed telephone number could be +1.781.328.4392 (IP-PBX phone number), and the attribute-name msRTCSIP-Line in the response could be +1.781.430.7069 (Lync phone number). A route is created for the Lync phone number, even though the dialed telephone number is the PBX phone number.

Exact-match-first

If the LDAP route-mode attribute is set to exact-match-first, the Oracle® Enterprise Session Border Controller performs as follows.

When the LDAP query is sent to the Active Directory, the first exact match of the incoming phone number that the LDAP query finds in the Directory, is the number whose corresponding route gets the highest priority in the route list. For all other routes configured on the Oracle® Enterprise Session Border Controller, the ordering of LDAP attributes in the LDAP configuration determines the priority for each route.

For example, if the incoming number is +1.405.565.1212, and the Active Directory includes a configured mobile number first (+1.201.444.5555), a home number second (+1.405.333.6666) , and a work number third(+1.405.565.1212), the LDAP query searches the mobile number first, then the home number, then finds the exact match on the work phone number. The Active Directory responds with the destination information for the work phone number and the Oracle® Enterprise Session Border Controller creates a route list with this exact phone number, and then forwards the call accordingly.

Number	Description
①	Call comes into the Enterprise network (+1.405.565.1212)
②	Using the configured route-mode of exact-match-first, LDAP queries the Active Directory for the matching number.
③	The LDAP query searches throughout the Active Directory until it finds the first exact match on the number. Active Directory responds with the exact phone number associated with the incoming number (+1.405.565.1212). In the illustration above, the number was associated with the work phone.
④	The Oracle® Enterprise Session Border Controller forwards the call to the applicable destination phone number from the Active Directory response. (+1.405.565.1212).

LDAP Messages

When you enable LDAP message logging in the Active Directory, the Oracle® Enterprise Session Border Controller (E-SBC) sends LDAP messages to the sipdldap.log. This log records all received and sent LDAP messages. Messages are in ASCII encoded binary format.

Additionally, when LDAP is invoked for routing, the LDAP messages display in the GUI under the Monitor and Trace tab. For more information about viewing LDAP messages in the GUI, see the Web GUI User Guide.

Note:

The E-SBC also supports transmitting LDAP messages using the IPFIX Protocol for the Palladion Mediation Engine.

LDAP Failure Events

If an incoming session to a primary phone number routed to Lync fails, the phone number is routed to the IP PBX. If failures occur during LDAP queries for all LDAP Servers, the Oracle® Enterprise Session Border Controller logs the failure to the sipdldap.log, and proceeds with normal configured routing policies, if available.

Note:

The Oracle® Enterprise Session Border Controller always establishes the TCP/TLS connection towards the configured LDAP server(s). If a TCP connection fails, the Oracle® Enterprise Session Border Controller continues to attempt to re-establish the connection.

An LDAP connection failure can be due to any one of the following events:

• Oracle® Enterprise Session Border Controller receives a CANCEL message (LDAP connection termination). The Oracle® Enterprise Session Border Controller detects this if it receives or issues an 'unbind' operation. The session is then closed down at TCP/TLS.
• Oracle® Enterprise Session Border Controller receives a call failure message from Lync (TCP/TLS socket termination). If either side receives a finish message (FIN) or reset message (RST), the TCP socket closes per standard behavior, which triggers the LDAP layer to detect connection failure. The Oracle® Enterprise Session Border Controller fails over to a secondary LDAP Server, if configured; otherwise it periodically attempts to reconnect to the Primary LDAP Server.
• Oracle® Enterprise Session Border Controller is unreachable and SIP session towards Lync times out. User is enabled for Lync but the Lync Server is unreachable by the Oracle® Enterprise Session Border Controller so a timeout occurs. When consecutive LDAP queries timeout, the Oracle® Enterprise Session Border Controller concludes that the LDAP session has failed, and then proceeds to terminate the TCP/TLS connection.

The number of consecutive queries that timeout before a connection is considered failed, and the number of successive query timeouts for each LDAP Server can be set via configuration.

Oracle® Enterprise Session Border Controller Limitations using LDAP

The Oracle® Enterprise Session Border Controller uses LDAP in the Active Directory when determining the destination of incoming calls. However, the Oracle® Enterprise Session Border Controller has the following limitations when using LDAP:

• Supports LDAP sessions over the Oracle® Enterprise Session Border Controller media interfaces only (i.e., not on wancom0).
• Supports LDAPv3 only.
• Establishes a session over the following connections only:

  LDAP over TCP - default

  LDAP over TLS (LDAPS)

Configuring LDAP

LDAP is the Protocol that the Active Directory uses for general interaction between and LDAP client and an LDAP server. You can configure the LDAP Server(s) in your network, and set the filters and the local policy that the LDAP Server uses when handling inbound Lync and PBX calls in the Enterprise core network.

You can use the following objects in the ACLI to configure LDAP.

Object	XML Tag	ACLI Path	Description
ldap-config	ldapConfig	session-router->ldap-config	Configures the LDAP functionality on the Oracle® Enterprise Session Border Controller (i.e., name, state, LDAP servers, realm, authentication mode, username, password, LDAP search filters, timeout limits, request timeouts, TCP keepalive, LDAP security type, LDAP TLS profile, and LDAP transactions). Note: This is a multiple-instance object.
ldap-transaction	ldapTransaction	session-router->ldap-config-> ldap-transaction	Configures the application transaction type for LDAP, determines route priority in the route list, and configures the LDAP configuration attributes. You configure this object for LDAP search queries in call routing. Note: This is a multiple-instance object.
ldap-cfg-attributes	ldapCfgAttributes	session-router->ldap-config-> ldap-transaction->ldap-cfg-attributes	Configures the Active Directory attribute name, next hop for routing SIP requests, the realm for the next hop, a regular expression pattern, and a format for the attribute value. You configure this object for LDAP search queries in the Active Directory. Note: This is a multiple-instance object.
policy-attributes	policyAttributes	session-router->local-policy-> policy-attributes	Configures the ldap: prefix with the name of the ldap-config. This allows the Oracle® Enterprise Session Border Controller to send LDAP queries to the Active Directory server(s) configured in the ldap-config element whenever there is a match for the corresponding local-policy. Note: An ldap-config with the LDAP name specified for this parameter must be configured for the next hop. An LDAP next hop is supported only for SIP to SIP calls. This is a multiple-instance object.

Configuring ldap-config

You use the ldap-config object in the ACLI to create and enable an LDAP configuration on the ESD.

To configure ldap-config:

1. In Superuser mode, type configure terminal and press Enter.

   ACMEPACKET# configure terminal

2. Type session-router and press Enter to access the session router-related objects.

   ACMEPACKET(configure)# session-router
   ACMEPACKET(session-router)#

3. Type ldap-config and press Enter to access the LDAP configuration-related attributes.

   ACMEPACKET(session-router)# ldap-config
   ACMEPACKET(ldap-config)#

   • name—Enter a name to assign to this LDAP configuration. This is a unique identifier. Valid values are alpha-numeric characters. Default is blank.

     XML Tag: name

     ACMEPACKET(ldap-config)# name ldapquery

   • state—Specify whether or not to enable the operational state of the LDAP configuration. When the state is disabled, ESD does not attempt to establish any connection with the corresponding LDAP Server(s). Default is enabled. Valid values are:
     • enabled (default)
     • disabled

     XML Tag: state

     ACMEPACKET(ldap-config)# state enabled

   • ldap-servers—Enter the IP address(es) and optionally the port number(s) for each LDAP Server(s) you want to add to the LDAP configuration. When more than one server is specified, each server address should be separated by a space and the list enclosed within parentheses. The first server listed is considered the primary LDAP Server, and the remaining servers are considered the secondary LDAP Servers. The HUNT strategy is used to determine the active LDAP Server (where the ESD selects the first LDAP Server; if unreachable, it selects the second LDAP Server; it that is unreachable, it selects the third LDAP Server, etc.). Default ports used are 389 (for LDAP over TCP) and 636 (LDAP over TLS). IP Address must be entered in dotted decimal format (0.0.0.0). Default is blank.

     XML Tag: ldapServers

     ACMEPACKET(ldap-config)# ldap-servers (172.44.0.20:636 172.44.0.21:389)

   • realm—Enter the name of the realm that determines which network interface to issue an LDAP query. Valid values are alpha-numeric characters. Default is blank.

     XML Tag: realm

     ACMEPACKET(ldap-config)# realm net172

   • authentication-mode—Specify the authentication mode to use in the LDAP bind request. Default is Simple. No specific password encryption is done when sending the bind request. You can use an LDAPS connection with the LDAP Server to maintain security (see ldap-sec-type).

     XML Tag: authType

     ACMEPACKET(ldap-config)# authentication-mode Simple

   • username—Enter the username that the LDAP bind request uses for authentication before access is granted to the LDAP Server. Valid values are alpha-numeric characters. Default is blank.

     XML Tag: username

     ACMEPACKET(ldap-config)# username ENGLAB\Administrator

   • password—Enter the password to be paired with the username attribute, that the LDAP bind request uses for authentication before access is granted to the LDAP Server. Valid values are alpha-numeric characters. Default is blank.

     XML Tag: password

     ACMEPACKET(ldap-config)# password sips1234

   • ldap-search-base—Enter the base Directory Number you can use for LDAP search requests. Valid values are alpha-numeric characters. Default is blank.

     XML Tag: ldapSearchBase

     ACMEPACKET(ldap-config)# ldap-search-base CN=Users,DC=englab,DC=acmepacket,DC=com

   • timeout-limit—Enter the maximum amount of time, in seconds, for which the ESD waits for LDAP requests from the LDAP server before timing out. When an LDAP response is not received from the LDAP server within the time specified, the request is retried again based on the max-request-timeouts parameter value. Valid values are 1 to 300 seconds. Default is 15.

     XML Tag: timeLimit

     ACMEPACKET(ldap-config)# timeout-limit 0

   • max-request-timeouts—Enter the maximum number of times that the LDAP Server is sent LDAP requests before the ESD determines that the server is unreachable and terminates the TCP/TLS connection. When an LDAP response is not received within the time specified for the timeout-limit parameter value, the request is retried the number of times specified for this max-request-timeouts value. Valid values are 0 to 10. Default is 3.

     XML Tag: maxReqTimeouts

     ACMEPACKET(ldap-config)# max-request-timeouts 3

   • tcp-keepalive—Specify whether or not the ESD keeps the TCP connection to the LPAD Server alive. Default is disabled. Valid values are:
     • enabled
     • disabled (default)

     XML Tag: tcpKeepalive

     ACMEPACKET(ldap-config)# tcp-keepalive enabled

   • ldap-sec-type—Specify the LDAP security type to use when the ESD accesses the LDAP server. This parameter enables the use of LDAP over TLS (LDAPS). If you set a value for this parameter, you must also specify an ldap-tls-profile value. Default is none. Valid values are:
     • none (default) - No LDAP security type specified.
     • ldaps - Method of securing LDAP communication using an SSL tunnel. This is denoted in LDAP URLs. The default port for LDAP over SSL is 636.

     XML Tag: ldapSecType

     ACMEPACKET(ldap-config)# ldap-sec-type ldaps

   • ldap-tls-profile—Enter the name of the Transport Layer Security (TLS) profile that the ESD uses when connecting to the LPAD Server. The ldap-sec-type must be set with an ldaps value for the LDAP configuration to use this profile. Valid values are alpha-numeric characters. Default is blank.

     XML Tag: ldapTLSProfile

     ACMEPACKET(ldap-config)# ldap-tls-profile ldap-tls

   • ldap-transactions—Subelement to ldap-config. For more information on this element, see Configuring ldap-transactions.

     XML Tag: ldapTransaction

     ACMEPACKET(ldap-config)# ldap-transactions
     ACMEPACKET(ldap-transactions)#

   XML Example for ldap-config

   <ldapConfig name='ldapquery'
   		state='enabled'
   		ldapServers='172.44.0.20:636'
   		realm='net172'
   		authType='Simple'
   		username='ENGLAB\Administrator'
   		password='sips1234'
   		ldapSearchBase='CN=Users,DC=englab,DC=acmepacket,DC=com'
   		timeLimit='0'
   		maxReqTimeouts='3'
   		tcpKeepalive='enabled'
   		ldapSecType='LDAPS'
   		ldapTlsProfile='ldap-tls'
   		lastModifiedBy='admin@console'
   		lastModifiedDate='2012-06-28 20:25:13'
   		objectId='102'>
   		<key>ldapquery</key>
   </ldapConfig>

Configure ldap-transactions

Use the ldap-transactions object in the ACLI to configure the application transaction type for Lightweight Directory Access Protocol (LDAP), to determine route priority in the route list, and to configure the LDAP configuration attributes for LDAP search queries in call routing.

1. Access the ldap-config configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# session-router
   ORACLE(session-router)# ldap-config
   ORACLE(ldap-config)# 

2. Type ldap-transactions , and press Enter to access the LDAP transactions-related attributes.

   ACMEPACKET(ldap-config)# ldap-transactions
   ACMEPACKET(ldap-transactions)#

3. app-trans-type—Specify the application transaction type to use for LDAP. This value allows the E-SBC to add call routing updates to the Active Directory. Default: ad-call-routing. Valid values:
   • ad-call-routing (default)

   ACMEPACKET(ldap-transactions)# app-trans-type ad-call-routing

4. route-mode—Specify the route priority that the E-SBC uses in the route list. This parameter determines which routes are created, and the priority of those routes within the route list. Default: exact-match-only. Valid values:
   • exact-match-only (default) - When there is an exact match between the dialed telephone number and an LDAP attribute value in the search response entry, a route is created corresponding to that LDAP attribute. When there is an exact match on multiple attributes, the ordering of LDAP attributes in the LDAP configuration determines the priority for each route. For example, an enterprise that uses the same phone number for both Lync and IP-PBX phones, if the msRTCSIP-Line attribute is configured first, the corresponding next hop (Lync Server) would be used to create the first route in the route list.
   • attribute-order-only - The ordering of LDAP attributes in the LDAP configuration determines the priority for each route. So if the msRTCSIP-Line attribute is configured first, the corresponding next hop (Lync Server) would be used to create the first route in the route list. If there is a valid value present in the search response entry for a LDAP attribute, a route is created corresponding to that LDAP attribute.

     Note:

     The LDAP attribute must have a valid value in the response; a match is not necessary for that attribute. If an entry is returned in the search response, there must be a match on at least one other attribute. For example, the dialed telephone number could be [phone] (IP-PBX Phone#), and the msRTCSIP-Line in the response could be [phone] (Lync phone#). A route is created for the Lync phone#, even though the dialed telephone number is the PBX Phone#.
   • exact-match-first - If there is an exact match between the dialed telephone number and an LDAP attribute value in the search response entry, the corresponding route gets the highest priority in the route list. For the rest of the routes, the ordering of LDAP attributes in the LDAP configuration determines the priority for each route. So if the msRTCSIP-Line attribute is configured first, the corresponding next hop (Lync Server) would be used to create the second highest priority route in the route list. If there is a valid value present in the search response entry for an LDAP attribute, a route is created corresponding to that LDAP attribute.

     Note:

     The LDAP attribute must have a valid value in the response; a match is not necessary for that attribute. If an entry is returned in the search response, there must be a match on at least one other attribute. For example, the dialed telephone number could be [phone] (IP-PBX Phone#), and the msRTCSIP-Line in the response could be [phone] (Lync phone#). A route is created for the Lync phone#, even though the dialed telephone number is the PBX Phone#.

   ACMEPACKET(ldap-transactions)# route-mode exact-match-only

5. operation-type—(Optional) When configuring an LDAP query with multiple attributes, use the "and" operator or the "or" operator for more granular condition-based call routing.
6. ldap-cfg-attributes—Subelement to ldap-config. For more information on this element, see Configuring ldap-cfg-attributes.

   ACMEPACKET(ldap-transactions)# ldap-cfg-attributes
   ACMEPACKET(ldap-cfg-attributes)#

7. Save and activate the configuration.

Configuring ldap-cfg-attributes

You use the ldap-cfg-attributes object in the ACLI to configure the Active Directory attribute name, next hop for routing SIP requests, the realm for the next hop, a regular expression pattern, and a format for the attribute value. You configure this object for LDAP search queries in the Active Directory.

To configure ldap-cfg-attributes:

1. In Superuser mode, type configure terminal and press Enter.

   ACMEPACKET# configure terminal

2. Type session-router and press Enter to access the session router-related objects.

   ACMEPACKET(configure)# session-router
   ACMEPACKET(session-router)#

3. Type ldap-config and press Enter to access the LDAP configuration-related attributes.

   ACMEPACKET(session-router)# ldap-config
   ACMEPACKET(ldap-config)#

4. Type ldap-transactions and press Enter to access the LDAP transactions-related attributes.

   ACMEPACKET(ldap-config)# ldap-transactions
   ACMEPACKET(ldap-transactions)#

5. Type ldap-cfg-attributes and press Enter to access the LDAP configuration attributes.

   ACMEPACKET(ldap-transactions)# ldap-cfg-attributes
   ACMEPACKET(ldap-cfg-attributes)#

   attribute-name—Enter the Active Directory attribute name. Default is blank. Valid values are alpha-numeric characters. Some examples of Active Directory attribute names are:

   • ipPhone and msRTCSIP-Line for Lync phone number

   • telephoneNumber for IP PBX phone number

   • mobile for Mobile phone number

     XML Tag: name

     ACMEPACKET(ldap-cfg-attributes)# attribute-name msRTCSIP-Line

     next-hop—Enter the Active Directory’s next hop when routing SIP requests. Default is blank. Valid values are alpha-numeric characters. Some examples of the Active Directory’s next hop are:

   • SAG (Session Agent Group) name, specified by entering an sag: prefix

   • SA (Sesson Agent) name

   • IP Address

     XML Tag: nextHop

     ACMEPACKET(ldap-cfg-attributes)# next-hop sag:SA1

     realm—Enter the name of the realm associated with the next hop. This value determines the network interface to which to route the SIP request. Valid values are alpha-numeric characters. Default is blank.

     XML Tag: realm

     ACMEPACKET(ldap-cfg-attributes)# realm net165

     extraction-regex—Enter the regular expression pattern used to break down the string of digits in the phone number extracted from the request URI of the SIP request. The variables extracted from the phone number can be used in the attribute-value-format parameter. The default regex is "^\+?1?(\d{2})(\d{3})(\d{4})$". This value assumes that the phone number is a North American phone number specified in the E.164 format. It extracts three variables from the phone number:

   • $1 is the area code

   • $2 and $3 are the next 3 and 4 digits in the phone number

     Valid values are alpha-numeric characters.

     XML Tag: extractionRegex

     ACMEPACKET(ldap-cfg-attributes)# extraction-regex ^\+?1?(\d{2})(\d{3})(\d{4})$

     attribute-value-format—Enter the format for the attribute value. These format values are extracted from the phone number using the extraction-regex parameter. The default parameter is "tel:+1$1$2$3". This value assumes that the phone number is a North American phone number specified in the E.164 format, and it recreates the phone number in E.164 format.

     In addition to the E.164 format, Acme Packet's Active Directory uses other formats as well to store the phone numbers. You can customize the value specified for this parameter to enable successful queries for phone numbers in other formats.

     Valid values are alpha-numeric characters.

     XML Tag: valueFormat

     ACMEPACKET(ldap-cfg-attributes)# attribute-value-format tel:+1$1$2$3

   XML Example for ldap-cfg-attributes

   <ldapCfgAttributes name='ldapquery'
   		name='msRTCSIP-Line'
   		nextHop='sag:SA1'
   	realm='net1651'
   	extractionRegex='^\+?1?(\d{2})(\d{3})(\d{4})$'
   	attribute-value-format='tel:+1$1$2$3'
   </ldapCfgAttributes>

Configuring policy-attributes

You use the policy-attributes object in the ACLI to configure the ldap: prefix with the name of the ldap-config. This allows the ESD to send LDAP queries to the Active Directory server(s) configured in the ldap-config element whenever there is a match for the corresponding local-policy.

Note:

An ldap-config with the LDAP name specified for this value must be configured for the next hop. An LDAP next hop is supported only for SIP to SIP calls.

To configure policy-attributes for LDAP:

1. In Superuser mode, type configure terminal and press Enter.

   ACMEPACKET# configure terminal

2. Type session-router and press Enter to access the session router-related objects.

   ACMEPACKET(configure)# session-router
   ACMEPACKET(session-router)#

3. Type local-policy and press Enter to access the local policy configuration-related attributes.

   ACMEPACKET(session-router)# local-policy
   ACMEPACKET(local-policy)#

4. Type policy-attributes and press Enter to access the policy attributes configuration-related attributes.

   ACMEPACKET(local-policy)# policy-attributes
   ACMEPACKET(local-attributes)#

   next-hop—Enter the “ldap:” prefix along with the name of the ldap-config. An ldap-config with this name must be configured. An ldap next hop is supported only for SIP-to-SIP calls. Valid values are alpha-numeric characters. Default is blank.

   XML Tag: nextHop

   ACMEPACKET(ldap-cfg-attributes)# next-hop ldap:ldapquery

   XML Example for policy-attributes for LDAP

   <localPolicy description='' 
      activateTime=''
      deactivateTime=''
      state='enabled'
      anonymousPriority='none'
      lastModifiedBy='admin@10.1.20.147'
      lastModifiedDate='2012-07-12 20:10:30'
      objectId='85'>
      <from addr='*'
         type='Hostname'
         addrPrefix=''/>
      <to addr='*'
         type='Hostname'
         addrPrefix=''/>
      <sourceRealm name='net192'/>
      <policyAttribute nextHop='ldap:ldapquery'
         destRealm='net172'
         action='none'
         isTermRoute='disabled'
         carrierName=''
         startTime='0000'
         endTime='2400'
         dow='U-S'
         cost='0'	
         state='enabled' 
         appProtocol='SIP' 
         methods='' 
         mediaProfiles='' 
         lookup='single' 
         nextKey='' 
         eLocStrLkup='disabled' 
         eLocStrMatch=''/> 
      <key>view_realm_from_to/net192/Hostname/Hostname</key>
   </localPolicy>

LDAP Error Messages

The ESD displays errors messages if the LDAP configuration objects are not properly configured. The following error messages for LDAP may display:

For all ldap-config objects:

• if an ldap-tls-profile is specified, and a tls-profile with that name has not been configured, the following error displays:

  ERROR: ldap-config [xyz] has reference to tls-profile [abc] which does not exist.

• if a realm has not been configured for an ldap-config, the following error displays:

  ERROR: ldap-config [xyz] has reference to realm [abc] which does not exist.

For all ldap-cfg-attributes:

• if a realm has not been configured for an ldap-config, the following error displays:

  ERROR: ldap-config [xyz] has reference to realm [abc] which does not exist.

For local policy-attributes:

• if the ldap-config object is configured corresponding to every ldap-config specified in the next-hop(s) in all policy-attribute subelements, and the 
next-hop value is not recognized, the following error displays:

  ERROR: local-policy-attribute [route; ldap:ldap-config-name] from local-policy [xyz] has reference to next-hop [ldap:ldap-config-name] which does not exist

• if the ldap-config object is not enabled, the following error displays:



  ERROR: local-policy-attribute [route; ldap:ldap-config-name] from local-policy [xyz] has reference to next-hop [ldap:ldap-config-name] which is not enabled

LDAP Show Commands

The ESD rovides specific LDAP statistics you can display using the show ldap command in the ACLI. The following is an example of the show ldap command output. These statistics include LDAP status information over Period and Lifetime monitoring spans, as well as information on active LDAP sessions. LDAP search query information displays for a Lifetime monitoring span only.

ACMEPACKET# show ldap
LDAP Status                -- Period -- -------- Lifetime --------
                 Active    High   Total      Total  PerMax    High
Client Trans          0       0       0          0       0       0
Server Trans          0       0       0          0       0       0
Sockets               1       1       0          1       1       1
Connections           0       0       0          0       0       0

                           ---- Lifetime ----
                    Recent      Total  PerMax
Query                    0          0       0
Modify                   0          0       0
LDAP Requests            0          0       0
LDAP Errors              0          0       0
LDAP Rejects             0          0       0
LDAP Expires             0          0       0
LDAPD Errors             0          0       0

The following table describes each column in the above output.

Column Heading	Description
Client Trans	Total number of ESD LPAD transactions currently occurring and those that have occurred over the lifetime of the Active Directory.
Server Trans	Total number of LDAP Server transactions currently occurring and those that have occurred over the lifetime of the Active Directory.
Sockets	Total number of active and past sockets established from the Active Directory on the ESD to the LPAD Server.
Connections	Total number of active and past connections established from the Active Directory on the ESD to the LPAD Server.
Query	Total number of LDAP queries that occurred in the Active Directory on the ESD.
Modify	Total number of modified LDAP call routes in the Active Directory.
LDAP Requests	Total number of LDAP call route Requests in the Active Directory.
LDAP Errors	Total number of errors that occurred for LDAP call routes in the Active Directory.
LDAP Rejects	Total number of LDAP call routes that were rejected in the Active Directory.
LDAP Expires	Total number of times LDAP timed out or expired in the Active Directory.
LDAPD Errors	Total number of errors that occurred for the LDAP Daemon (LDAPD) in the Active Directory.