Voice Message Routing Service
updated by
- rfc-6118 — Update of Legacy IANA Registrations of Enumservices
Extracted elements (19)
Intradomain routing mechanisms are strictly informational and internal to the recipient's domain; only the addresses created by NAPTR rewrite rules need have meaning to the advertising domain. A convention for address creation may be useful but is not mandated.
It is a goal to avoid content-processing to determine the nature of a message and its internal destination. A simple mail forwarding rule sending all inbound VPIM messages to a designated system should be sufficient, while still enabling routing of FAX, SMS, or other telephone-addressed messages to different systems.
Two routing mechanisms are defined: a complete service using ENUM to find a VPIM LDAP directory and retrieve a verified email address, and a basic 'send-and-pray' service using only ENUM NAPTR rewrite rules and DNS MX records. The basic service exists because LDAP queries may be unavailable for disconnected mobile terminals or due to firewall policies.
VPIM directory discovery and query steps must occur within PSTN user-interface timing constraints — 95% of the time within a two-second response — to support real-time call setup scenarios.
VPIMDIR servers should be deployed in redundant configuration. NAPTR weight fields allow two records for the same service and preference to have different weights, enabling load distribution or random selection between servers.
Because no recipient capabilities information is available in the basic service, messages SHOULD be sent using only the media and content types of the VPIM V2 profile.
For the complete VPIM message routing service, the sending client SHOULD query the VPIM directory for the VPIM-specific email address, and SHOULD use the ENUM service to retrieve the identity of the VPIM Directory to query.
Once the VPIM directory is discovered, the client SHOULD issue an LDAP query for the vPIMrFC822Mailbox, which SHOULD be used as the value for both the RFC 822 To: field and the SMTP RCPT command.
To facilitate intradomain routing, the indication that a message is a VPIM message SHOULD be in the domain name portion of the constructed email address.
Directory-enabled intradomain routing uses the local part of the constructed address to query a proprietary directory, substituting the result for the SMTP RCPT address. Example: +[email protected].
Interdomain routing of a constructed VPIM address is mechanically indistinguishable from standard email routing: the sending system consults DNS for an MX record and forwards the message. No infrastructure changes are required.
Service-based intradomain routing forwards all voice messages to a separate messaging system by checking for the 'VPIM' prefix in the constructed domain name. Example: +[email protected].
The 'E2U+VPIM:LDAP' service maps an E.164 telephone number to a VPIM LDAP URL, enabling discovery of the VPIM directory server. The ENUM DNS query returns NAPTR records with LDAP URLs pointing to the VPIM directory.
The 'E2U+VPIM:Mailto:' service maps an E.164 telephone number to a VPIM email address constructed via NAPTR rewrite rules, without verifying the address is valid or corresponds to the intended recipient.
VPIM directory discovery uses the ENUM protocol by querying for the VPIMDIR service associated with the recipient's telephone number. The DNS query name is constructed per RFC 3761, and the telephone number MAY contain additional sub-address digits.
This specification registers the E2U+VPIM:LDAP and E2U+VPIM:Mailto: (E2U+Voice) ENUM services with IANA according to RFC 3761, defining ENUM-to-VPIM address resolution services.
Both services rely on DNS for routing information. If DNS is compromised, an attacker can redirect messages by providing a malicious email address or rogue LDAP URL. Use of DNSSEC substantially reduces this risk; if the E.164 zone is DNSSEC-secured, the attack is precluded if the client trusts the signing key.
ENUM records expose email addresses derived from telephone numbers, enabling bulk-emailers to send unsolicited messages to large sets of recipients where only the telephone number was previously known.
Malicious NAPTR entries can redirect E.164 resolution to a wrong LDAP URL or email address, causing clients to connect to rogue servers or deliver messages to unintended recipients. DNSSEC protects the DNS layer but does not protect against an independently compromised LDAP service.