IANA Registration of Enumservices for Voice and Video Messaging
updated by
- rfc-6118 — Update of Legacy IANA Registrations of Enumservices
Extracted elements (17)
Separate Enumservice types ('voicemsg', 'videomsg', 'unifmsg') were defined to allow service providers and clients to explicitly identify the nature of the messaging endpoint (voice-only, video-only, or unified). This distinction cannot be reliably inferred from SIP URIs alone without non-standards-based routing logic.
The existing SIP Enumservice type (RFC 3764) was considered but rejected because it cannot distinguish voice messaging, video messaging, or unified messaging endpoints from regular SIP endpoints. Without the vmsg type, a UAC or UAS presented with multiple SIP URIs has no standards-based way to identify which URI targets a messaging service.
VPIM (Voice Profile for Internet Mail) was considered but rejected because it supports only non-real-time, non-session-based routing of already-deposited messages between domains. The vmsg Enumservice was created specifically to enable real-time interaction with voice and video messaging systems.
Implementers are recommended to use regular expressions (backreferences) in NAPTR records to reduce individual record size and the overall database size, as shown in the backreference example in Section 7.3.
Multiple E2U+voicemsg, E2U+videomsg, or E2U+unifmsg NAPTR records may be returned for a single ENUM query. The order and preference fields in NAPTR records should be used to implement primary/backup failover and load balancing across multiple messaging servers.
When an ENUM query returns both E2U+sip and E2U+voicemsg/videomsg/unifmsg records, the network element receiving the results must contain logic to select the appropriate service type. The vmsg records are intended for routing to messaging services when a called party is unavailable, distinct from E2U+sip records for real-time end-user communication.
Although an E.164 number reveals less identity information than a SIP or email username@hostname URI, publicly available ENUM mappings still expose the association between a telephone number and messaging service endpoints, creating risk of unwanted communication targeting.
The 'unifmsg:sip' and 'unifmsg:sips' Enumservice subtypes use 'sip:' and 'sips:' URI schemes to identify a remote resource for initiating a unified communication session to a unified messaging system that handles both voice and video.
The 'videomsg:sip' and 'videomsg:sips' Enumservice subtypes use 'sip:' and 'sips:' URI schemes to identify a remote resource for initiating a video communication session to a video messaging system.
The 'voicemsg:http' and 'voicemsg:https' Enumservice subtypes use 'http:' and 'https:' URI schemes to identify a resource capable of serving information related to voice messaging, including VoiceXML files. The specific kind of content retrieved cannot be constrained further.
The 'voicemsg:sip' and 'voicemsg:sips' Enumservice types use 'sip:' and 'sips:' URI schemes respectively to identify a remote resource for initiating a voice communication session to a voice messaging system.
The 'voicemsg:tel' Enumservice subtype uses the 'tel:' URI scheme (RFC 3966) to identify a voice messaging system endpoint. This subtype is unique to 'voicemsg' and is not registered for 'videomsg' or 'unifmsg'.
Registers the 'unifmsg' Enumservice type with subtypes 'sip', 'sips', 'http', and 'https' under the IANA Enumservice registry (RFC 3761). Each subtype maps an E.164 number to a URI for routing real-time sessions to a unified messaging system handling both voice and video.
Registers the 'videomsg' Enumservice type with subtypes 'sip', 'sips', 'http', and 'https' under the IANA Enumservice registry (RFC 3761). Each subtype maps an E.164 number to a URI for routing real-time sessions to a video messaging system.
Registers the 'voicemsg' Enumservice type with subtypes 'sip', 'sips', 'tel', 'http', and 'https' under the IANA Enumservice registry (RFC 3761). Each subtype maps an E.164 number to a URI for routing real-time sessions to a voice messaging system.
DNS-based threats (including those analyzed in RFC 3833) and DNSSEC applicability (RFC 4035) are relevant to the security of ENUM deployments using these Enumservices. Implementers are referred to RFC 3761 for a full analysis of threats specific to ENUM's dependence on DNS.
Publishing vmsg Enumservice data in public ENUM trees (e.g., e164.arpa) makes E.164-to-messaging-URI mappings visible to anonymous third parties. This enables data harvesting for unsolicited communications (e.g., SPIT — SPAM over Internet Telephony), though analogous to telephone directory publication. Carriers may mitigate this by restricting ENUM data to private or trusted-network trees.