VPIM remote machine considerations

The following are considerations related to VPIM V2 remote machines:

• It is important to note that, depending on the individual vendor's implementation of VPIMv2, certain feature interactions might differ from one vendor to another. Also, when the remote VPIM system type is not one that Avaya has previously tested with, it is imperative that the customer making the verification request work with Avaya and the third party VPIM vendor in order to assist in testing.
• When the sending VPIM V2 message is larger than the receiving non-VPIM machine can handle, the message is failed with a "Large Message" failure code.
• When recipients of messages from VPIM V2 systems are notified that one or more components of a multimedia message cannot be delivered, the sender is not notified. The recipient is notified to contact the sender for missing components.
• VPIM V2 does not provide for sending adds, changes, or deletes either inbound or outbound when a given subscriber record has been updated by an Administrator.
• The maximum number of recipients per message on an inbound VPIM V2 message is 1,000. The maximum number of recipients per message on an outbound VPIM message is 250.
• VPIM V2 remote machines administered on the Message Networking system support only dynamic directory views. This means that the Message Networking system sends subscriber directory updates to a VPIM V2 remote machine as subscribers send messages to that VPIM V2 machine.
• VPIM V2 does not support the following combinations for future delivery: Aria/Octel 100/UM to AUDIX/AMIS/Serenade Digital/VPIM V2.
• Sender notification of message receipt is handled in one of the following ways:
• An originator sending a message from a VPIM V2 remote machine to a non-VPIM remote machine does not get an indication that the recipient has accessed the message.
• An originator sending a message from a non-VPIM remote machine to a VPIM V2 remote machine does not get an indication that the recipient has accessed the message. Requests for this information are ignored.
• An originator sending a message from a VPIM V2 remote machine supporting the accessed feature to a VPIM V2 remote machine also supporting the accessed feature gets an indication that the recipient has accessed the message. This response is in text format.
• Message Disposition Notification (MDN) is handled in one of the following ways:
• For messages sent from VPIM remote machines to non-VPIM remote machines, Message Networking ignores MDN requests.
• For messages sent from VPIM to VPIM remote machines, Message Networking returns whatever the receiving VPIM machine returns, for example, MDN, "Ignore," and so on.
• VPIM v2 systems do not support negative confirmation.
• Demand Remote Update and Demand Remote Push do not apply to VPIM systems.
• Disabling of Updates In or Out does not apply to VPIM v2 systems.
• VPIM V2 subscriber records can be imported using the FTP subscriber import utility.
• Message Networking follows a default transmission schedule for message delivery to VPIM remote machines. This schedule defaults to all hours (00:00-23:59). An immediate trigger for VPIM message delivery occurs when a message for a given remote VPIM machine is placed on the queue. All messages on the queue for that remote VPIM machine are sent during the same communication session for that remote machine. This schedule is not tunable.
• Message Networking provides the ability to administer up to three Domain Name Servers (DNSs) to be used (in priority order) when the VPIM module needs to locate the IP address necessary to communicate with the appropriate VPIM message server. When configuring a VPIM remote machine domain, the use of a DNS is optional. In cases where DNS is not used, the IP address for the VPIM domain being configured must be specified.
• The Message Networking system requires a uniform length dial plan (the number of digits used when addressing a message). It consists of a network address of from 3 to 10 digits. It allows for a prefix of from 1 to 21 digits for an Avaya AUDIX system. The sum of the network address and prefix cannot exceed 24 digits. A 10-digit network address dial plan is recommended.
• Delivered status indicates the message was delivered to the Message Networking system. If a message fails, the original message is returned, and two messages are returned to the sender's incoming mailbox:
  
  • An error message similar to:
    "Message to [voice name(s)] extension [extension number(s)] failed due to [reason]. A copy of this message can be found in your incoming mailbox."
    This error message might have Priority status if this option was selected through the administration pages.
• The actual message is returned to the sender so that it can be resent to the destination.
• A recipient of a message must be administered on a Message Networking system in order for that Message Networking system to accept messages for delivery.
• Notification of failure to deliver a message component because the recipient is not enabled to receive a component type (voice, fax, text, binary) is the same as on the INTUITY AUDIX Release 4 system. The component that could not be delivered is stripped, and the following statement is prefixed to the original message: "One or more components could not be delivered, please contact the sender" <pause><voice message>.
• Octel Analog Networking analog subscriber messages can optionally contain the Private/Urgent designation and voiced name of the sender as part of the actual message being sent.
• The remote subscriber name contains a suffix indicating the Message Networking system ID for the remote machine on which that subscriber resides.

  Note: This suffix can take from 2 to 8 characters at the end of the Name field.

• When the Message Networking database is full, subscribers continue to be added but voiced names are not. Therefore, no voiced name is heard when addressing a subscriber whose voiced name could not be added. Message Networking supports 120,000 subscribers with voiced names.
• Sender's name:
  • Octel Analog Networking, Aria Digital, and Serenade Digital messages to Message Networking should not be configured to include the sender's name.
  • Octel Analog Networking, Aria Digital, and AMIS recipients receive the sender's name by Message Networking prefixing.
  • AUDIX and Serenade Digital recipients receive the sender's name from the message header.
• Message Networking supports a maximum mailbox ID and network address length of ten. In addition, Message Networking supports a uniform dial plan whereby the network address length must be the same number of digits network-wide (from three to ten digits). None of the Avaya message servers that Message Networking supports can have a mailbox ID or network address greater than ten digits. Additionally, it is expected that every Message Networking system with a VPIM connection have at least one Avaya message server in its network. The VPIM specification recommends (but does not require) E.164 conformance for the format of the userid@domain address. This specification calls for a userid value length of up to 30 digits and/or characters. Therefore, the only time a mailbox length and network address length can exceed ten is if the Message Networking system is supporting only a pure VPIM environment where those networked VPIM nodes have mailbox IDs and network addresses greater than ten.
• The Message Networking VPIM module does not support network turnaround, as this is not a feature of the VPIM protocol.
• Message Networking does not support the disabling of Updates In or Out for VPIM remote machines, as this concept does not apply to VPIM.
• Message Networking does not support the ability to change a remote machine administered as AMIS type to VPIM. The remote AMIS machine must be deleted and readministered as a VPIM remote machine on the Message Networking system.
• Messages delivered to VPIM recipients from Message Networking include the sender's voiced and ASCII names in the appropriate sender's name fields. For the voiced name, the ADPCM format is used if the voiced name is stored on the Message Networking system. How the names are presented to the recipient (if at all) depends on the receiving VPIM vendor's implementation. For example, Message Networking sends a voiced name to some vendors that ignore this field and do not present it to the recipient. For inbound VPIM messages received, Message Networking extracts the sender's voiced and ASCII names from the appropriate sender's name fields and populates the Message Networking directory accordingly. It is important that VPIM customers verify the level of name support on the vendor's VPIM system that is planned to be networked to the Message Networking system. In short, Message Networking supports both the ASCII and voiced name values in its VPIM implementation, but it is the individual VPIM vendor's support of these that can affect the user experience.
• Message Networking's VPIM implementation supports voice, fax, and text components of a message. However, certain vendors have chosen not to support fax and text in their VPIM implementations. It is important that VPIM customers verify the level of component support in the vendor's VPIM system that is planned to be networked to the Message Networking system.
• Certain sending VPIM systems can generate what is known as a multistrip fax, which is not supported by Message Networking. A multistrip fax is a fax with one or more pages each stored as multiple strips of image data. An example of a system that can generate a multistrip fax is Microsoft Exchange 2000.
• When a VPIM originator sends a message to a VPIM recipient through the Message Networking system (whether one or two Message Networking systems are involved), the message component handling is always a binary-to-binary mapping (that is, the original MIME format). When a VPIM originator sends a message to a non-VPIM recipient, the voice, fax, and text components are placed into the appropriate designated components for AUDIX, AMIS, Octel Analog, Aria Digital, and Serenade Digital recipients. For each component type, its sending VPIM binary representation is removed from the MIME format and placed into the receiving machine type representation. Since these receiving machine types (AUDIX, AMIS, Octel Analog, Aria Digital, Serenade Digital systems) can only support one component of each type, similar component types (voice and text) are concatenated. For fax, subsequent faxes are added as a binary attachment on the outgoing message. For INTUITY AUDIX systems, the subsequent faxes are received as a binary attachment. Because the other system types (DEFINITY AUDIX, AUDIX R1, AMIS, Octel Analog, Aria Digital, Serenade Digital) cannot handle binary or text, these components are stripped.
• Some VPIM messaging systems support a reply-all capability upon receipt of a message. When a message originates from a non-VPIM sender through Message Networking, this reply-all feature for the VPIM recipient is not supported. Depending on the consistency of the dial plan, messages sent from a VPIM originator to a VPIM recipient through the Message Networking system may or may not be able to perform a reply-all on the message.

  Note: This consideration is not related to the reply-all feature of Message Networking's Enterprise List application, supported on the S3400-H server.

• The use of DNS on Message Networking for remote VPIM domain IP resolution is optional. However, other vendors' VPIM systems might require DNS in order to operate. The customer should verify whether the non-Avaya VPIM messaging system requires DNS and whether the facilities exist to do this before networking the system to the Message Networking system.
  

Top of page