IANA Registration for Enumservice Voice
updated by
- rfc-6118 — Update of Legacy IANA Registrations of Enumservices
Extracted elements (15)
The PSTN/PLMN connection implied by a voice:tel NAPTR may be indirect: an end-user device may use SIP or H.323 to a remote gateway that terminates to the PSTN, converting 'tel:' URIs to a protocol-native form. This acknowledges that not all callers have direct PSTN access.
The subtype 'tel' is defined separately from the 'voice' type because the subsystem required to initiate the call (a dialer) is distinct from the teleservice itself. This mirrors the ENUM design principle that subtypes identify the protocol/subsystem used to reach the endpoint.
An Enumservice indication operates only within the context of the 'E2U' DDDS application (ENUM). Although other DDDS applications exist (e.g., RFC 3404, RFC 3405), voice:tel NAPTRs are not intended for use in those contexts.
A 'local phone number' form SHOULD NOT be used in a voice:tel NAPTR unless the zone controller is certain it can be unambiguously distinguished by all clients that can access the record and that calls can be routed to the destination from their access points.
Before a voice call is placed via the PSTN or PLMN, the originating user SHOULD be shown the destination number so they can make an informed decision about whether to proceed.
Due to the implications of publishing data on a globally accessible database, data subjects MUST give their explicit informed consent before their data is published in ENUM.
The 'tel:' URI value carried in a voice:tel NAPTR SHOULD use the fully qualified 'global phone number' form as defined in RFC 3966.
Unlike a telephone directory entry made by explicit submission, ENUM publication makes telephone numbers machine-harvestable at scale without the data subject's knowledge. The document warns that E.164 numbers cannot easily be made 'sacrificial' like throwaway email addresses.
An Enumservice has a type and an optional subtype; the subtype is typically associated with the URI scheme used to initiate the session. Both type and subtype must be supported for the enclosing NAPTR to be usable by a correspondent.
The voice:tel Enumservice indicates that the contact in the generated URI can be used to initiate interactive voice (audio) communication involving bidirectional media streams. The subtype 'tel' implies use of the 'tel:' URI scheme and a dialer subsystem connecting to PSTN or PLMN.
IANA registers the Enumservice type 'voice' with subtype 'tel' under the framework defined in RFC 3761. The associated URI scheme is 'tel:' and the intended usage is COMMON.
All general security considerations from RFC 3761 (ENUM) apply, as well as the DNS-specific threat analysis in RFC 3833, which covers cache poisoning, denial of service, and other DNS-layer attacks.
Calls placed to PSTN/PLMN numbers via voice:tel may incur charges, including premium-rate tariffs considerably higher than standard calls. End users must be asked to confirm call placement and shown the destination number to allow informed consent.
ENUM data is publicly visible to anyone anonymously via DNS. This exposes published telephone numbers to automated harvesting by third parties, enabling unsolicited voice calls, junk faxes, and junk SMS—analogous to spam targeting of email addresses scraped from mailing lists.
Once published in ENUM, removal of an E.164 number from the zone does not remove copies harvested by third parties; any publication may effectively be permanent. Regulations in many regions require that data subjects can request removal and that consent be confirmed at regular intervals.