Avaya

Message Networking Help

Home | Search  
Print | Back | Fwd | Close
  
Getting Started Admin Maintenance Reference
Home > Getting Started > Message Networking concepts and features > Enterprise Lists overview

Enterprise Lists overview

Message Networking supports the creation and administration of Enterprise Lists, which are enterprise-wide mailing lists for subscribers that reside on a Message Networking system. Each Enterprise List represents a specific group of potential recipients for enterprise distribution messages. Enterprise Lists can be used to send messages to literally hundreds of thousands of subscribers across the enterprise, and to members of the different messaging systems that Message Networking supports.

Note: Enterprise Lists are supported only for the S3400-H server.

This topic provides the following information about Enterprise Lists:

See Administering Enterprise Lists for information on list administration.

Caution: It is important that you understand list creation before using the Enterprise List feature. If an error is made, a message could be sent in error to hundreds or thousands of subscribers within your network.

How Enterprise Lists work

When an Enterprise List is created, members are added to the list by one of several different criteria that are then stored under that list ID. When a message is sent to the list, the system finds list members based on the stored membership criteria, checks appropriate permissions for using the list, and expands the list so that the message can be delivered to each recipient. Because the Enterprise List application uses a virtual subscriber as the actual list ID, anyone who is networked to the application and who has permission to use the list can access it from any remote machine. In addition, those permitted to send messages using Enterprise Lists can reference lists by:

  • Number (including network address or numeric address)
  • Alphabetic Name (ASCII name)
  • Speech Voice Name (by providing the alphabetic name)

Note: The addressing method used depends on the individual messaging system that the sender uses and the user interface of that system. User interfaces such as Web Messenger or other IMAP 4 clients might also be used to address Enterprise List messages.

If the moderator role for an Enterprise List is active, every message sent to the list is first sent to the moderator. The moderator is responsible for approving or rejecting the full delivery of each message. After the moderator approves a message, the system delivers it to all members of the list.

Note: A moderator must be an SMTP/MIME type sender.

Enterprise List members

Valid subscribers of a Message Networking system can be selected as Enterprise List members. System administrators are responsible for managing various permissions for Enterprise List members, including permission to create and update lists. However, these permissions are only available to system subscribers who use a lightweight directory access protocol (LDAP) client. Enterprise List administrators can also choose whether a list is or is not subscription-based. A subscription-based list allows LDAP clients who are not currently members to request that they be added to the list. If a list is not subscription-based, its members are determined by the list administrator.

Note: Certain Enterprise List features might not be accessible to specific sender or recipient types depending on the configuration of external software clients accessing the Enterprise List database. Most general message sending and receiving capabilities are supported for all subscriber types.

Number of supported Enterprise Lists

The number of subscribers plus the number of Enterprise Lists plus the number of Voice Name Mailboxes cannot exceed 500,000, with the following conditions:

  • The total number of voice names in the entire system cannot exceed 250,000.
  • Each individual recipient is counted only once as a subscriber, regardless of how many Enterprise Lists to which that recipient belongs.
  • Each Enterprise List counts as a subscriber.
  • Each voice name mailbox, which is required for Enterprise Lists with voice names, is counted as a subscriber with a voice name.

For example, an enterprise having 100,000 recipients could have up to 75,000 Enterprise Lists with Voice Name Mailboxes in the system, (assuming all subscribers and Enterprise Lists have voice names):

Maximum number of subscribers Message Networking supports:
250,000
Minus individual recipients in the enterprise:
100,000
Equals maximum number of Enterprise Lists and Voice Name Mailboxes in the system:
150,000

Maximim number of recipients in an Enterprise List

Based on the example above, the maximum number of recipients is simply the maximum number of subscribers in the network.

The number of total subscribers that Message Networking supports (500,000, or 250,000 with voice names) minus the number of Enterprise Lists and Voice Name Mailboxes equals the total number of possible recipients per list. An individual recipient is counted only once as a subscriber, regardless of how many Enterprise Lists to which that recipient belongs.

For example, an enterprise having 25,000 Voice Name Mailboxes and 75,000 enterprise lists could have up to 400,000 recipients per list, as shown in the following table:

Maximum number of subscribers Message Networking supports:
500,000
Minus Enterprise Lists in the system:
75,000
Minus Voice Name Mailboxes in the system:
25,000
Equals maximum number of individual recipients per list:
400,000

Usage considerations

The Enterprise List feature is a powerful application that can be used to send a message to literally hundreds of thousands of subscribers across the enterprise, however it is important to note the following considerations when using Enterprise Lists.

  1. Enterprise Lists are lists and not a broadcast feature. The term broadcast implies that the sender has the option to invoke Message Waiting Indication (MWI). Examples of MWI include lighting the light on a telephone set and outcalling. Enterprise Lists invoke MWI to notify the recipient of message receipt. For some networks, the effects of MWI should be strongly considered when using these lists. Invoking MWI for a large number of subscribers on an endnode can consume significant system and/or network resources. However, in many existing networks, messages are sent to every subscriber in the Enterprise without any issues with MWI.

    Workarounds are available for the following messaging systems if MWI is not desired for a receiving system:
    • Intuity AUDIX - an Enterprise List can be built referencing one subscriber per Intuity system that has local broadcast permission on that Intuity system. Upon receiving the Enterprise List message, that person can forward the message to the local Intuity broadcast mailbox with MWI turned off.
    • Aria - an Enterprise List can be built referencing the bulletin broadcast mailbox on each Aria system. Sending messages in this fashion will not invoke MWI when sent to all of the Aria recipients. These recipients must have the bulletin broadcast class of service (COS).
    • Serenade - System Distribution Lists (SDL) on Serenade have an MWI option. An Enterprise List can be built referencing a Serenade SDL with MWI turned off.
    • Modular Messaging/Avaya - Using the Modular Messaging/Avaya Enhanced List Application (ELA) feature, a system broadcast ELA can be built without MWI. A Message Networking Enterprise List can reference this Broadcast ELA, sending a message to all Modular Messaging recipients not invoking MWI.
  2. Enterprise Lists can be a maximum of two levels. This means that only one level of embedded lists is supported. For example, if List B is embedded within List A, then List B cannot include any embedded lists.
  3. In large networks that include more than one Message Networking system, avoid defining a list with a large range on system A that includes subscribers whose home system is system B. For example, if range 5550000-5559999 is on system A and range 6660000-6669999 is on system B, then break these down into two separate lists on each respective system. One list id can be created to reference both lists so that the separate lists are transparent to the sender. This will distribute system processing and help performance.
  4. The time required to deliver messages to their entire enterprise depends on the following factors:
    • The throughput of the WAN/LAN.
    • The type and number of TCP/IP endpoints (INTUITY AUDIX, Octel 250/350, Octel 200/300 servers) as transcoding takes more time.
    • The number/type of endpoints and the distribution of the subscribers.
    • Number of any other non-TCP/IP endpoints (Octel Analog, AMIS).
    • Number of Message Networking systems (distribution).
    • Other message traffic load occurring at the same time (both on Message Networking and the endpoint).
    • Other performance-impacting activities (e.g. running of reports, etc.) both on Message Networking and the endpoint.
    • Number and type of ports configured on each system/endpoint.
  5. The following example can be used for comparison. A customer sends a message to all 40,000 subscribers in an INTUITY AUDIX (that is, there is no digital transcoding) network during non-prime time. Network Address Ranges are used in the Enterprise List feature. In this example, the entire delivery process takes 3.5 hours.

  6. Message Networking supports hybrid network configurations in which there is a mix of point-to-point and Message Networking message server connections. In configurations such as this, however, there exists the possibility for double remote name entries. When this occurs, two remote subscriber directory entries can be stored on the local message server for one system subscriber: one for the point-to-point path and another for the Message Networking path. In this case, senders using the dial-by-name feature can get back two responses for the same person (for example, "Press 1 for John Smith, Press 2 for John Smith").
    Users can prevent this double name entry by administering directory views on the Message Networking system to exclude remote machines to which they are connected point-to-point.

 

Top of page

Home | Search | Print | Back | Fwd | Close
©2006 Avaya Inc. All rights reserved.
Last modified 4 April, 2006