teas N. Albert Internet-Draft PhreakNet Intended status: Standards Track August 2021 Expires: 4 March 2022 Genuine In-Band Signaling in Asterisk draft-phreaknet-inband Abstract This document specifies a mechanism which allows for multiple in-band signaling protocols to be used for address information during call setup in a VoIP environment using Asterisk. Status of This Memo 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 2 February 2022. Copyright Notice 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. Albert Expires 4 March 2022 [Page 1] Internet-Draft In-Band Signaling August 2021 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. In-Band Signaling over IAX2 . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 1.1. The Problem The introduction of common channel signaling, which allows for addressing information to be sent out-of-band, increased the security of the public switched telephone network (PSTN) and greatly reduced fraud. This is accomplished by decoupling the signaling from the actual voice path. A side effect of this was also the standardization of signaling protocols, namely Signaling System 7 (SS7), which dominates on the PSTN today. In environments where it is desirable, for some reason, to utilize in-band signaling for addressing information, it is necessary to coordinate the information that must be sent an received. This can include several different pieces of information: * Signaling protocol. A common protocol must be used by both switches involved in the call. This could be multifrequency (MF) or single-frequency (SF) signaling. Other protocols, such as Panel Call Indicator (PCI) and revertive pusling (RP) are also possible, but they are DC-based signaling methods, not in-band signaling protocols, even though they may be audible to some extent. In addition to the signaling system used, both ends must be using a common standard, for instance, wink start. * Pulsing digits. If a call is being completed from A to B, A must know the correct number of digits to send to B. Because in-band signaling involves tones being sent over the voice path, it is generally desirable to send as few digits as possible (only those necessary) for call setup to proceed unambigously. This allows for call setup to complete in the quickest possible time. In VoIP environments, physical circuits may not exist between the nodes in a network, and it is thus necessary to dynamically set up trunks which facilitate the necessary in-band signaling in the Albert Expires 4 March 2022 [Page 2] Internet-Draft In-Band Signaling August 2021 correct manner and in a way that is compatible between different kinds of equipment, ideally allowing digital switches to interoperate with electromechanical ones with no particular constraints. This requires that A be informed by B when B is ready to receive digits. 2. Terminology 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. 3. Solution 3.1. In-Band Signaling over IAX2 This specification addresses the problems discussed in Section 1.1 by adding tech-agnostic applications and functions to Asterisk to facilitate in-band signaling in a compatible manner. A general procedure is discussed here. 1. First, during a route lookup request for the called number, the routing server determines what protocol should be used for the call and how many digits should be inpulsed. The calling switch can provide its supported protocol to the route lookup server or this can be stored in a database accessible to the route lookup server. The protocols supported by the called switch for a particular number should be accessible to the route lookup server. 2. The signaling protocol and inpulsing digits are then provided to the originating switch, along with other routing information needed to set up the call. The call is then placed over IAX2 to a generic extension that is used to complete all in-band calls to a particular exchange or switch. This part of call set up does not include specific addressing information for the called number, but only the information required for the signaling protocol. 3. The terminating switch communicates to the originating switch that is ready to receive digits. This is commonly done by sending a wink to the calling switch. The originating switch then sends digits to the terminating switch. 4. The terminating switch completes the call to the number called. Albert Expires 4 March 2022 [Page 3] Internet-Draft In-Band Signaling August 2021 An essential component of in-band signaling in the old North American network was the use of the 2600 Hz frequency to signal supervisory status. On an idle trunk, 2600 Hz is whistled in both directions on a trunk to indicate on-hook status. One switch can then seize the trunk by briefly removing 2600 Hz. The other switch will then wink at it to let it know that digits can be sent. After digits are sent, transmission of 2600 Hz continues from the distant end until the call has been answered. This is not clearly audible to the caller since a notch filter is used to filter the frequency from the call. However, audio artifacts may be present, especially when 2600 Hz is removed or applied and the notch filter engages or disengages, since the capacitive response is not instantaneous. In VoIP environments, the use of 2600 Hz serves no special purpose in regards to supervisory status. Because trunks are set up in a packet-switched manner, not a circuit-switched manner, trunks can be set up on demand anytime, and there is no purpose in using 2600 Hz to signal that a trunk is idle, since the trunk could simply be torn down. Likewise, the removal of 2600 Hz in the reverse direction is not needed to signal answer supervision, since answer supervision can be natively conveyed out of band. The only relevant usage of 2600 Hz would be to cause the call at the other end of a connection to terminate so that digits can be sent to it. This can be done towards the terminating end of the connection easily simply by keeping a tone detector in series with the call path. However, this is completely optional and supplementary to the other components of the in-band signaling system. 4. Security Considerations IAX2 does not encrypt call metadata, even if the call is authenticated and/or encrypted. Because transmission of the called number is performed in-band rather than in the IAX2 call setup message, the called number is encrypted since it is part of the media stream. This offers a higher level of security than calls where addressing information is sent out-of-band as part of IAX2 trunk setup. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Albert Expires 4 March 2022 [Page 4] Internet-Draft In-Band Signaling August 2021 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Naveen Albert PhreakNet United States Email: rfc@phreaknet.org Albert Expires 4 March 2022 [Page 5]