| Internet-Draft | Dial Pulsing | September 2021 |
| Albert | Expires 3 April 2022 | [Page] |
This document specifies a mechanism which allows for dial pulses to be sent in real time over a VoIP connection.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 March 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Two methods of customer loop signaling exist in telephone networks today. The old method, dial pulsing, dates back to the late 19th century and was the most common well into the late 20th century. The newer method, DTMF (dual tone multifrequency), commonly known as "TOUCH-TONE", has largely supplanted dial pulsing today. Most public telephone switches support both pulse dialing and tone dialing. Some VoIP terminal equipment, such as analog telephone adapters (ATAs), does not support pulse dialing.¶
As most VoIP solutions and software was developed well after dial pulsing was widely used in any capacity, dial pulsing support in most VoIP domains tends to be poorly integrated. For instance, DAHDI (Digium Asterisk Hardware Device Interface) converts pulses to tones at the kernel level and does not expose this to user level applications. This makes tasks like restricting customer loops to dial pulse only (for instance, for customers who elect not to pay an additional surcharge for TOUCH-TONE capabilities) impossible within the current constraints, though these could be overcome.¶
The major limitation associated with the inherent pulse-to-tone conversion present in DAHDI is that it converts dial pulse signaling into a store-and-forward scheme when used with multiple links. Consider an environment in which digits are dialed into A as dial pulses, sent over an IP (Internet Protocol) trunk, and then inpulsed into B, again using dial pulses. The current mechanism for doing this entails dial pulses being received by A, converted to DTMF, sending the DTMF frame(s) over the IP trunk, then converting the DTMF frame from DTMF back to dial pulses at B. This introduces a high amount of latency and delay in call setup, as the entire dialing time is now more than doubled from an already slow dial pulsing speed (typically 10 pulses per second).¶
A key consideration is that this is not how TDM and circuit-switched networks have historically operated. In cut-through modes of signaling, dial pulses are not converted to tones by the originating Class 5 switch. Instead, the dial pulses are sent over the trunk with no special meaning assigned to them - that is, they are not stored and converted to a numeric digit, but sent as they are received. Eventually, meaning is made out of them, but that is done further down the link, which is the most optimal place to do so in a trunking environment. This allows for dial pulses to be inpulsed into switching equipment at the far end of a connection as the dial returns to normal at the orignating end of a connection. Thus, there is no additional delay introduced into call setup, and the caller enjoys a more natural experience. As pulses are not being converted to tones, no DTMF decoders are even necessary for the call.¶
These capabilities do not currently exist in the VoIP domain, because the assumption is made that DTMF is the fundamental and only way of communicating digits on subscriber loops, when in fact a dial pulse on its own is a basic signaling element with its own meaning.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This specification addresses the problems discussed in Section 1.1 by adding native first-class support for dial pulsing to Asterisk.¶
Currently, no frame type exists in Asterisk for a dial pulse, even though similar frames do exist for control signals such as wink and flash. Because a dial pulse on its own is a fundamental signaling unit, it requires its own frame type to communicate signaling status. An alternate approach would be defining frames to be used for indicating on-hook and off-hook status. However, in IP environments that are subject to high latency and jitter, the erratic timing is likely to produce less reliable operation.¶
With a pulse frame type, individual pulse frames can be generated for individual dial pulses as they are detected by the channel bank (we will consider the differences with ATAs in a subsequent section). These can then be passed to a user-level application, such as Asterisk, even before it has determined to what digit the dial pulses currently being received may correspond. The IAX2 (Inter-Asterisk Exchange version 2) protocol already supports sending wink and flash over an IAX2 trunk, and thus likewise extended to support the sending of pulse over a trunk, these pulses could be sent to another Asterisk server, over an IAX2 channel, in realtime. A small technical difference is that in circuit-switched networks, dial pulses are not the fundamental units being sent over the trunk. Rather, the trunk is merely going on-hook and off-hook in conjunction with the dial pulses being sent from the subscriber premises, and equipment at the distance end may be interpreting these on-hook and off-hook changes into functional dial pulses. In a VoIP environment, we consider this to be less practical due to issues of packet loss, jitter, and latency that makes VoIP trunking inherently less predictable than a circuit-switched trunk. Sending a single pulse event is likely to result in more reliable operation. A small delay is actually being introduced, since the dial pulse detection is being down by the originating switch, not the terminating switch, but this duration is typically less than 70ms and thus not noticable to the caller. As soon as a pulse is detected, it is transmitted instantaneously over the IAX2 trunk to the terminating switch, where it can then be inpulsed into any supporting equipment, such as a foreign exchange line, and the maximum delay observed on such a connection is no greater than the duration of a dial pulse in the make (on-hook) condition.¶
The mechanism here described does not provide for Asterisk to interpret dial pulses in any way, including ascribing meaning to them by aggregating them into a digit using a DTMF frame. This is done purely by the terminating equipment that is fed dial pulses by Asterisk.¶
The framework described above applies most directly to channel banks and channel bank drivers, such as DAHDI in the case of Asterisk. On the originating side, an ATA can also be used instead of a channel bank. The constraint here is the lack of open-source ATAs on the market. It is thus necessary to rely on ATA manufacturers to add functionality to their firmware such that an event is generated and sent to the server for each individual dial pulse, similar to the pulse frames being generated by DAHDI and sent to Asterisk.¶
This specification proposes the use of the SIP INFO application/dial-pulse message be added to the standard repertoire. This will allow for a SIP message to be sent from the ATA to a server application such as Asterisk, which can then convert this message into a PULSE frame type which can then be transmitted over a trunk. Currently, no vendor has implemented this capability.¶
On the terminating side, no special hardware enhancements are needed for either channel banks or ATAs, since Asterisk could merely inpulse into it using the normal mechanism, and the hardware is not aware of any deviation from store-and-forward pulsing operation, nor will it care as long as the pulses are timed consistently. This is likely to be an issue only in the case of significant packet loss or jitter which could render the timing of the pulse control frames so inconsistent that undesired or invalid pulsing operator is effected.¶
There are no relevant security considerations for this draft.¶