Internet-Draft | In-Band Signaling | August 2021 |
Albert | Expires 4 March 2022 | [Page] |
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.¶
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 (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.¶
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:¶
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 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.¶
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 tech-agnostic applications and functions to Asterisk to facilitate in-band signaling in a compatible manner. A general procedure is discussed here.¶
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.¶
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.¶