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