| Internet-Draft | Caller ID in SIP | November 2022 |
| Albert | Expires 3 June 2023 | [Page] |
This document defines two new headers for use with the Session Initiation Protocol (SIP). The Presentation and Call-Qualifier headers are used to extend its support for the Multiple Data Message Format (MDMF) Caller ID specification.¶
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 May 2023.¶
Copyright (c) 2022 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.¶
This document describes a SIP [RFC3261] extension header field in order to extend the precision and completeness of its support for Caller ID.¶
Caller ID is an integral component to any modern telephony environment. In general, SIP provides several standard headers that are used for relaying information about the caller, such as From, P-Asserted-Identity (PAI), Remote-Party-ID (RPID), and Privacy. However, there are several scenarios that are possible in the Caller ID standard that currently cannot be conveyed using SIP signaling, leading to ambiguity and arbitrary handling on the client side.¶
In analog telephony, Caller ID information is provided to compatible customer premises equipment (CPE) equipped with a Bell 202 modem. In North America, after the first ring has finished, the central office (CO) will, if the user subscribes to Caller ID, provide a 1200-baud FSK spill. This is a scheme known as on-hook Caller ID, since the Caller ID information is sent to the CPE while the line is still on-hook. If the user answers before the data is received, no Caller ID information is received. An alternate scheme known as Type II or Off-Hook Caller ID is used for delivering Call Waiting Caller ID. While the proposals in this document are applicable to Type II Caller ID as well, it will focus primarily on Type I (On-Hook) Caller ID.¶
There are two types of Caller ID. The original type is known as Simple Data Message Format (SDMF). This supports Caller ID Number. The newer type is known as Multiple Data Message Format (MDMF) and virtually all CPE in use today supports MDMF. MDMF supports Caller ID Name as well as many other pieces of information. MDMF-capable CPE can process a SDMF Caller ID spill, but SDMF-only CPE cannot process a MDMF Caller ID spill. This proposal focuses on MDMF since there are no limitations in SIP insofar as SMDF is concerned.¶
The analog Caller ID specification provides for a number of parameters that are used to provide various information about the calling party. In general, the parameters defined by MDMF are defined below.¶
| Parameter ID (Hex) | Parameter Purpose |
|---|---|
| 01 | Date and time |
| 02 | Caller Number |
| 03 | Redirecting Number |
| 04 | Reason for Caller Number Absence |
| 05 | Redirecting Reason |
| 06 | Call Qualifier |
| 07 | Caller Name |
| 08 | Reason for Caller Name Absence |
| 0B | Network Message Status |
The caller's number is provided in parameter 02 if available. However, the telephone network provides a mechanism for a caller to withold his number from the called party. This is commonly known as "blocking Caller ID" and often invoked using the vertical service code *67 (1167 from a rotary phone). The telephone network does not actually "block" anything when a subscriber does this: this merely sets the privacy bit in the call setup message sent using SS7 (Signaling System 7). VoIP networks provide similar mechanisms for conveying the presentation of the calling number, so that the called party's telephone system can withold it from the called party.¶
Because the Caller ID spill is sent to the subscriber equipment, parameter 02 is not sent if the Caller ID is blocked or is unavailable.¶
A large number of parameters defined in MDMF are not universally supported, but they are defined in the MDMF specification. For example, most MDMF-capable CPE do not support Redirecting parameters or the Call Qualifier parameter. One CPE that supports most parameters is the BellSouth Visual Director CI-7112, here noted for reference.¶
The Redirecting Number, also known as the RDNIS (Remote Dialed Number Information Service) provides information about the number that was originally called on a call-forwarded call. For example, if Bob has forwarded all his calls to Charlie and Alice calls Bob, then Charlie will see Alice as the Calling Number, but Bob's number as the RDNIS. This can provide crucial context to Charlie as to why he received a call from Alice, since Alice actually called Bob, not Charlie directly.¶
The Redirecting Reason parameter provides specific information about why the call was redirected. The following table provides some possible values.¶
| Redirecting Reason ID | Purpose |
|---|---|
| 01 | Call forwarded on busy |
| 02 | Call forwarded on no answer |
| 03 | Unconditional call forward |
| 04 | Deflected call (after alerting) |
| 05 | Deflected call (immediate) |
| 06 | Call forwarded on inability to reach mobile subscriber |
Most VoIP systems also have their own constructs of the redirecting reasons listed above.¶
The analog Caller ID specification remains relevant in SIP because many SIP endpoints are themselves analog devices that are connected to a SIP-aware device such as an analog telephone adapter (ATA). Thus, SIP may be used for signaling between CPE and a softswitch, even if the endpoints themselves are analog.¶
Parameters 04 and 06 do not have equivalents defined in the Session Initiation Protocol. Parameter 04 indicates the reason that a call has been blocked. The available reasons are outlined in the table below.¶
| Value | Meaning |
|---|---|
| P | Private number (blocked by caller) |
| O | Unavailable (e.g. out of area) |
The actual value is a literal character that is sent to the CPE as the value for that MDMF parameter. P remains common with "Caller ID Blocking", while "O" is less common than it was in the early days of Caller ID when such information was not always available on long distance calls.¶
While VoIP softswitches themselves, such as Asterisk, and even certain protocols like IAX2, offer support for providing this presentation information, the SIP protocol has no mechanism to provide this information to the called party. Headers like P-Asserted-Identity cannot be used since they are only to be used in trusted contexts, and a user's CPE is not trusted. The Privacy header is likewise limited to use in trusted contexts.¶
The current mechanism for indicating that a caller's number is not available is through the use of the special From contact [email protected]. However, when this is present in the From header, it is ambiguous as to the reason that the number is not available. There is no mechanism to indicate if the number is private or if the number is available.¶
Additionally, in analog telephony, it is possible to not send any Caller ID at all. The central office switch can simply not send any Caller ID spill to the CPE, and this is simply the lack of Caller ID. There is no way to indicate that no Caller ID spill should be sent to a CPE in the SIP protocol.¶
The Call Qualifier parameter (06) is solely used to indicate a Long Distance Call. This is auxillary information about the call itself, but is supported by some CPE. There is no way of conveying this information in the current SIP protocol.¶
The lack of support for conveying the information present in parameters 04 and 06 limits the current utility of the SIP protocol when using analog endpoints, in particular CPE that supports the full MDMF standard. Because SIP does not currently support the entire MDMF standard, a technology other than SIP must be employed to properly support these endpoints, such as using TDM hardware locally, even if the SIP protocol and a SIP-aware device such as an ATA would otherwise be suitable.¶
Additionally, because there is no standard for presentation information, vendors currently set these parameters in variable and non-standardized ways. For example, many ATAs often send an "O" to the CPE for parameter 04, even when it should be a "P". Likewise, there is no way in SIP currently to indicate that an ATA should not send any Caller ID spill to the CPE for a particular call; any control over this setting involves enabling or disabling Caller ID entirely on a per-line basis. In traditional telephony environments, for example, test numbers such as revertive ringback circuits will ring back a phone but not provide any Caller ID.¶
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 document proposes adding two optional headers to the SIP protocol that would allow conveying more completely information about the Caller ID that analog endpoints are capable of receiving but the SIP protocol does not currently support conveying.¶
The following headers are intended to be send to the called endpoints and are generated by the Class 5 switching component that communicates with a SIP device supporting analog endpoints.¶
The first proposed header is the Presentation header. The following values are defined as possible values for this header.¶
| Header Value | Purpose |
|---|---|
| allowed | The calling presentation is allowed. This is implicitly the default if a number is sent. |
| private | The calling presentation is blocked. This is implicitly the default if the From URI is [email protected]. The SIP deivce MUST send a "P" to the CPE for MDMF parameter 04. |
| unavailable | The calling presentation is unavailable. The SIP device MUST send an "O" to the CPE for MDMF parameter 04. |
| none | No Caller ID spill should be sent to the CPE, i.e. the SIP device MUST NOT send any FSK spill. |
The default action to take if the Presentation header is not provided MUST depend on the value of the From header; specifically if it is [email protected] or something else.¶
The second proposed header is the Call-Qualifier parameter, which is a simple binary header that may be toggled on or off. If not provided, it is assumed to be off. If the header is present with the value "L", then the SIP device MUST send the value "L" for parameter 06. Currently, "L" is the only supported value since "L" (for long distance indicator) is the only supported option for the Call Qualifier. Because the MDMF specification can be considered mature and unlikely to be extended, it is unlikely that other options will ever be supported, and we do not anticipate there being a need to ever support other values.¶
Because the additional headers are intended to be consumed by the end user's CPE, they do not expose any sensitive information about the caller and there is no added security risk associated with using these headers. This is because blocked Caller ID is never sent in the Caller ID spill, regardless of the presence or value of the presentation parameter.¶