Summary

  • RFC 3601 defines a dial sequence as DTMF elements plus actions. A syntactically valid phone-string may include a pause, a wait for tone, an outside-line or carrier code, a service password and post-dial menu input; it is not merely an address.
  • Governance must separate source, classification, context, authorization, device actions, signaling, connection and service outcome. No receipt at one layer proves the next.

Imagine a customer database migration that copies a value from a column called phone_number. The value starts with familiar digits. It also contains w, several p characters and more digits after them. The import accepts it, the new dialler accepts it, and a test report marks the record “valid.” Three green lights have appeared before anyone has established what the string will make a device do.

That is the operational problem RFC 3601 makes visible. Published in September 2003 on the Standards Track, the document defines a common text notation for dial sequences and for diallable GSTN/E.164 addresses. Its smallest unit is not a telephone number. A Dial Sequence is a series of Dual Tone Multi Frequency elements and human or device actions. The text form, called a phone-string, admits digits, #, *, A through D, the letter p for pause, the letter w for tonewait, and the written separators hyphen and full stop.

Those categories do different work. DTMF elements can become signals. Pause and tonewait tell an agent to change its timing or wait for an observation. Written separators exist only for human readability. RFC 3601 says separators must not cause an action and allows conformant implementations to insert or remove them. A comparison that ignores hyphens and dots can therefore be legitimate. A cleanup that also deletes p or w has crossed from typography into program editing.

Even the action symbols do not define one universal program. The RFC recommends treating one pause as one second, but says the exact interpretation depends on the device and implementation. Tonewait should last until the calling party hears dial tone or another indication that more characters may be processed; an off-hook indication may count. That flexibility was practical. It also means a database hash plus a parser version cannot reconstruct execution. The audit needs the executor, its configuration, the duration it chose and the event that released the wait.

This is the first evidence boundary: syntax is not behaviour. A parser can prove that a sequence belongs to the grammar. It cannot prove that a device emitted each DTMF element, paused for a particular interval or observed a particular tone. A dialler log saying “tonewait satisfied” proves only the condition its implementation used. It does not identify the remote party, establish that a call was answered or show that the next digits reached the intended application.

The second boundary is between a dial sequence and an address. RFC 3601 defines a GSTN phone as either global or local. Its global form begins with + and represents diallable E.164 numeric addresses. But the RFC is explicit that full abstract E.164 addresses contain further elements that cannot be dialled and cannot be completely converted into this notation. The plus sign protects a useful namespace. It does not turn every abstract addressing fact into executable digits.

The local form makes context dependence unavoidable. It may contain an exit code and a dial number. The exit code can include the digit needed for an outside line, a long-distance carrier access code or a password used to reach a service. The same characters can therefore produce different outcomes at two offices, on two PBXs or after a carrier-policy change. Copying the string without its context can preserve every byte and still change its meaning.

Later standards sharpened the distinction. RFC 3966 describes a tel URI as a globally unique identifier or name, not as the steps needed to reach it. It does not imply dialing semantics or universal reachability. It deliberately moved dial strings, pauses and post-dial sequences outside the tel URI. A local number needs a phone-context, but that context is a validity scope, not a prefix that can safely be concatenated to manufacture an E.164 number. RFC 4967 later created user=dialstring for SIP and required a context, precisely because a dial string must be distinguishable from a user part containing the same characters.

That lineage matters in migration. A team may decide that every telephone-looking value should become a tel URI. If an old value includes an outside-line instruction, pause, tonewait or post-dial secret, the transformation is not a harmless format conversion. It may discard executable behaviour, or worse, mislabel instructions as identity. The correct decision begins with classification: identifier, global phone, local phone, dial sequence, subaddress or post-dial string. Only then can the system choose a safe destination field.

Post-dial data adds another timing boundary. RFC 3601 defines it for a sequence used after the connection to the destination device has been established, such as an automated menu. A stored post-dial field does not prove that this prerequisite occurred. The execution record needs a connection or answer receipt before it can claim that menu digits were sent in the intended phase. It then needs a separate result if the business question is whether a mailbox, extension or service accepted them.

The security risk is structural, not incidental. RFC 3601's own example places a mailbox identifier and personal identification number after dialing instructions. Its security section warns that dial sequences can contain private code sequences and that transmitting them without protection can disclose access codes. A value that looks routine in an address book may therefore be both an executable program and a secret container.

Ordinary observability can become an exfiltration path. Search indexing, CRM export, call-debug logging, analytics replication and support screenshots may copy the whole sequence because the column was classified as contact data. Redacting every digit destroys useful forensic lineage; retaining every digit exposes credentials. A better design stores the public address, action plan and secret reference separately. Logs retain a stable hash, structure and execution events while replacing sensitive material with a token that can be rotated and access-controlled.

The evidence chain should be explicit. First preserve the source: supplier, original field type, raw-value hash and time. Then record classification and parser version. Attach the local context: site, PBX, numbering plan, carrier policy and configuration epoch. Record normalization character by character. Require an authorization decision before execution. During execution, log each action, the chosen pause duration and the observation that released a wait. Signaling, connection, post-dial navigation and user or business outcome each need their own receipts.

This chain prevents attractive but false compression. “Imported” does not mean classified. “Valid” does not mean authorized. “Dialled” does not mean connected. “Answered” does not prove the intended human or service. “Digits sent” does not prove the menu accepted them. One status field cannot safely represent all of those transitions.