Configuration and data mapping use cases

Last Updated : Aug 19, 2022 |
Prolog information
Metadata
Keywords:
Avaya Multimedia Messaging uses Avaya Aura® Device Services to validate addresses. Avaya Aura® Device Services brings the address information or handle data from Enterprise Directory and System Manager.

Enterprise Directory query

The query used is based on a URI from the Avaya Multimedia Messaging side, which should not contain a schema. Avaya Aura® Device Services uses the LDAP attribute mapping from the configuration to build the filter to query the LDAP. The filter can use the attributes mapped to EmailAddress, EmailAddress-1, IMHandle, IMHandle-1, or LyncAddress, and it is intended for the SMTP, SIP, and XMPP schema.
The following are sample default mappings:
Application Field Name
Directory Field Name
Email address
mail
EmailAddress-1
<not mapped>
IMHandle
<not mapped>
IMHandle-1
<not mapped>
LyncAddress
msrtcsip-primaryuseraddress
SMGRLoginname
userPrincipalName
If the Avaya Multimedia Messaging sends a validation request to Avaya Aura® Device Services for address j.doe@company.com, the Avaya Aura® Device Services will set the filter as follows: 
OR: 8 items

Filter: (mail=j.doe@company.com)

Filter: (mail=sip:j.doe@company.com)

Filter: (mail=xmpp:j.doe@company.com)

Filter: (mail=smtp:j.doe@company.com)

Filter: (msrtcsip-primaryuseraddress=j.doe@company.com)

Filter: (msrtcsip-primaryuseraddress=sip:j.doe@company.com)

Filter: (msrtcsip-primaryuseraddress=xmpp:j.doe@company.com)

Filter: (msrtcsip-primaryuseraddress=smtp:j.doe@company.com)
Leave the IMHandle and IMHandle-1 attributes unmapped. Avaya Multimedia Messaging uses the EmailAddress value as the internal contact. When the EmailAddress and IMHandle mapping return different attribute values, the validation might fail.

System Manager query

Avaya Multimedia Messaging sends a query to Avaya Aura® Device Services, which first queries LDAP, brings back the information, and extracts the values returned for EmailAddress and SMGRLoginname. Avaya Aura® Device Services then queries System Manager using SMGRLoginName, and if that fails, then it uses EmailAddress.
Application Field Name
System Manager Field Name
SMGRLoginName
Login Name
Email address
Login Name, OR Microsoft Exchange Communication Address, OR Other Email Communication Address
This use case is not applicable for Avaya Aura® Device Services deployments in an environment without Avaya Aura®.

The user information is available in both Enterprise Directory and System Manager

If Avaya Aura® Device Services is able to retrieve data from both Enterprise Directory and System Manager, it merges these two data sets, and sends this information back to the Avaya Multimedia Messaging server.
If Avaya Aura® Device Services queries the System Manager data, and if it does not find any related information from System Manager, it sends back the data only from Enterprise Directory.
This use case is not applicable if Avaya Aura® Device Services is deployed in an environment without Avaya Aura®. In this case, the user information is available only in Enterprise directory.

The user information is available on System Manager but not on Enterprise Directory

The Avaya Multimedia Messaging server sends a query to Avaya Aura® Device Services. If the relevant user is not available on Enterprise Directory, the query is redirected to System Manager. Avaya Aura® Device Services attempts to use the received URI from Avaya Multimedia Messaging to match the System Manager, Login Name, Microsoft Exchange Communication Address, or Other Email Communication Address.
If a match is found, then Avaya Aura® Device Services extracts the SMGRLoginName, creates a query filter with the SMGRLoginName, and then sends another query to the Enterprise Directory.
The fetched data is merged with System Manager data and sent back to Avaya Multimedia Messaging. If the second query to Enterprise Directory fails to bring back data because no relevant data exists, then only System Manager data is sent back to the Avaya Multimedia Messaging server.
This use case is not applicable if Avaya Aura® Device Services is deployed in an environment without Avaya Aura®. In this case, the user information is available only in Enterprise directory.

User in Enterprise Directory and System Manger

Avaya Multimedia Messaging server mappings
Application Field Name
Directory Field Name
Email address
mail
EmailAddress-1
<not mapped>
IMHandle
<not mapped>
IMHandle-1
<not mapped>
LyncAddress
msrtcsip-primaryuseraddress
SMGRLoginname
userPrincipalName
Enterprise Directory mappings
Enterprise Directory Field
Value
mail
j.doe@company.com
userPrincipalName
j.doe@north.company.com
System Manager mappings
System Manager Field
Value
Login Name
j.doe@north.company.com
Avaya SIP handle
2001@sip.company.com
Avaya Presence/IM handle
j.doe@pres.north.company.com
Avaya Multimedia Messaging sends a validation request for j.doe@company.com to Avaya Aura® Device Services, which then sends a query to Enterprise Directory with the filter shown in Enterprise Directory query. 
OR: 8 items

Filter: (mail=j.doe@company.com)

Filter: (mail=sip:j.doe@company.com)

Filter: (mail=xmpp:j.doe@company.com)

Filter: (mail=smtp:j.doe@company.com)

Filter: (msrtcsip-primaryuseraddress=j.doe@company.com)

Filter: (msrtcsip-primaryuseraddress=sip:j.doe@company.com)

Filter: (msrtcsip-primaryuseraddress=xmpp:j.doe@company.com)

Filter: (msrtcsip-primaryuseraddress=smtp:j.doe@company.com)
When Enterprise Directory gets a match for mail=j.doe@company.com, it returns: 
mail=j.doe@company.com

userPrincipalName=j.doe@north.company.com
Avaya Aura® Device Services sends the following query to System Manager: 
Filter: Login Name=j.doe@north.company.com
When System Manager gets a match on Login Name, it returns the Avaya SIP handle and the Avaya Presence or IM Handle.
Avaya Aura® Device Services merges the information and returns handles to Avaya Multimedia Messaging: 
Contact = j.doe@company.com

SIP Handle= 2001@sip.company.com

XMPP Handle=j.doe@pres.company.com