idnits 2.17.00 (12 Aug 2021) /tmp/idnits52283/draft-rosen-ecrit-premature-disconnect-rqmts-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 5, 2009) is 4877 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit B. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track January 5, 2009 5 Expires: July 9, 2009 7 Requirements for handling abandoned calls and premature disconnects in 8 emergency calls on the Internet 9 draft-rosen-ecrit-premature-disconnect-rqmts-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 9, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 The -phonebcp draft currently requires endpoints to disable sending a 49 BYE on an emergency call. Insufficient justification and lack of 50 attention to the entire problem has caused comment on that section of 51 the document. This document attempts to define the problem and the 52 requirements to controlling disconnect on emergency calls. 54 Table of Contents 56 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Premature disconnect . . . . . . . . . . . . . . . . . . . 3 58 1.2. Abandoned Call . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements for Premature Disconnect . . . . . . . . . . . . . 4 60 3. Requirements for Abandoned Call . . . . . . . . . . . . . . . . 5 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Problem Statement 69 [I-D.ietf-ecrit-phonebcp] currently disallows sending of BYE by the 70 calling UA. This requirement has generated a request for additional 71 capability, and has also caused some to question why it is needed, 72 and how the mechanisms interact with current and future emergency 73 call systems. There are two aspects of handing emergency calls that 74 give rise to the discussion. 76 1.1. Premature disconnect 78 Occasionally, when on an emergency call, a caller hangs up the call 79 before the call taker is finished acquiring enough information. 80 Emergency calls are stressful, and mistakes are inevitablely made. A 81 mechanism is needed to re-establish communication between the caller 82 and the call taker when this happens. The PSTN has a feature 83 available, "Called Party Hold" (CPH) which is used in some 84 jurisdictions to meet this requirement. If the user hangs up When 85 CPH is engaged, the call is not torn down, but instead is maintained 86 despite the "on hook" condition. The call taker may also have a 87 mechanism (called "Ringback" which is different than call-back) to 88 ring the user's telephone. If the handset is picked up, since the 89 call is still active and resources maintained, the caller and the 90 call taker are readily reconnected. Called Party Hold is a feature 91 that has long been available in wireline networks, but is not 92 currently implemented in wireless networks. Some jurisdictions are 93 desirous of maintaining their current PSAP call disconnect control 94 capability, while other jurisdictions would like to regain access to 95 those capabilities. Still, in other jurisdictions, the function may 96 not be needed or desired, even in jurisdictions that want to have the 97 feature, it may not be desirable in all circumstances. For example, 98 if the call is queued due to congestion, it is undesirable to hold up 99 the call and user initiated disconnect should be permitted. 101 1.2. Abandoned Call 103 It is not uncommon for an emergency call to be cancelled before it 104 reaches a call taker. Abandoned, in this context, means that the 105 call is terminated before a call taker answers it. While it can be 106 that the user is fully aware that the call is being cancelled, and 107 considers the cancellation the most appropriate solution, abandoned 108 calls are problematic to PSAPs because they don't know why the call 109 was abandoned. Unfortunately, what looks like an abandoned call can 110 be a more serious circumstance such as a hostage situation. In some 111 jurisdictions, the PSAP dispatches a police unit to all logged 112 abandoned calls. In such jurisdictions, dispatching resources could 113 be avoided for true inadvertent calling if the call went through, and 114 the call taker was able to assess the actual situation. Other 115 jurisdictions do not have the resources and may not respond to 116 abandoned calls at all. As with premature disconnect, application of 117 the function depends on conditions. For example, in a mass calling 118 event, an Interactive Media Response unit may be used to answer 119 calls. Abandoning a call answered by a machine may be appropriate. 120 Even if jurisdictions respond to abandoned calls by dispatching 121 emergency personnel in normal situations, they may not in this 122 situation. 124 There is always a period of time after a call is initiated by a 125 caller before there is any reasonable possibility to determine that a 126 call is abandoned. Since the appication of special handling for 127 abandoned call is dependent on conditions, there is an implication 128 that some form of negotiating is needed between the UAS and the UAC 129 to invoke any kind of abandoned call processing. This in turn 130 implies that if the call is abandoned before the signaling 131 negotiation completes, no special handling should be provided. 132 Accordingly, an abandoned call is defined as a call which is 133 attempted to be disconnected prior to the UAS answering, but after 134 any signaling that would enable the feature is completed. 136 Retaining the connection is extremely important when there is no 137 callback information (e.g., uninitialized phone) or the caller has 138 call termination features active (such as call forwarding, do not 139 disturb) and the PSAP is unable to reconnect via callback. 141 2. Requirements for Premature Disconnect 143 In the following discussion the entities are the humans who take part 144 in the call. 145 PD-1 Some times, when a caller attempts to disconnect from an 146 established emergency call, s/he may find that disconnection 147 appears not to work 148 Rationale: Some callers attempt to disconnect before the call 149 taker has enough information to provide help. 150 PD-2 When a caller attempts to disconnect, the call taker gets an 151 indication of such an attempt. If the device has a mechanical 152 "hook switch" or similar mechanism that cannot be locked out, and 153 the user picks up the handset, the call taker gets an indication 154 of that action. 155 Rationale: Knowledge of the caller action gives valuable 156 information to the call taker which may influence how the call 157 will be managed going forward. 159 PD-4 When PD-1 is enforced, the call taker must be able to cause 160 alerting to the caller which has attempted to prematurely 161 disconnect from the emergency call. 162 Rationale: The caller believes they have disconnected. The 163 ability to alert is needed to encourage the caller to reconnect. 164 PD-5 When PD-1 is enforced,the caller must not be able to place 165 another call until the PSAP allows the call to be released. This 166 requirement is not intended to imply a user inteface with multiple 167 lines accessible independently is locked to the single line that 168 placed the emergency call. As mistakes can be made, an override 169 mechanism invoked by the caller must be be feasible. The 170 implementation must fail safely such that the phone cannot be 171 locked and unable to call for help. 172 Rationale: Priority must be given to the call taker until such 173 time she/he determines the call can be terminated. 174 PD-6 If the user responds to the alerting (PD-4), the caller and the 175 call taker must be able to converse roughly immediately. "Roughly 176 immediately" is in human terms: the time from when the caller 177 reacts to the alerting, initialting reconnect, and the time the 178 call taker can resume conversing, and is perhaps a second. 179 Rationale: If the user responds, caller re-answers. 180 PD-7 Control of premature disconnect is not needed in all 181 jurisdictions. It must be possible for the PSAP to not invoke the 182 function and allow premature disconnect to terminate the call as 183 if no special features were present. 184 Rationale: Whether the function is enabled is a call-by-call 185 decision and takes into account the jurisdiction practice and 186 conditions at the PSAP for the call. 188 3. Requirements for Abandoned Call 190 In the following discussion the entities are the humans who take part 191 in the call. 192 AC-1 Where enabled, an emergency call, once "dialed" by the caller, 193 completes even if the caller attempts to abandon it. Normal 194 mechanisms used by the caller to disconnect appear to be disabled. 195 Rationale: Call takers cannot distinguish between calls which are 196 appropriately abandoned and calls that need response but were cut 197 short. Controls to limit abandonment are needed for those 198 jurisdictions who would otherwise respond to all abandoned calls. 199 AC-2 The user may note that in some circumstances, a disconnect 200 request initiated very quickly after initiation does succeed. 201 Rationale: Disallowing call abandonment early minimizes the 202 chances of abandoned calls, but since the conditions at the call 203 taker have to be considered before the mechanism can be invoked. 205 AC-3 The user may note that some times, the disconnect works. This 206 may depend on where s/he is calling from, or other conditions. 207 For example, disconnect may work if the call is placed during a 208 mass calling event. 209 Rationale: Whether the function is enabled is a call-by-call 210 decision and takes into account the jurisdiction practice and 211 conditions at the PSAP for the call. . 213 4. IANA Considerations 215 There are no IANA Considerations for this document 217 5. Security Considerations 219 If these features can be enabled by entities other than PSAPs, the 220 entity may gain more control over the end device. Failures of 221 various kinds may prohibit callers from being able to disconnect. 223 6. Acknowledgments 225 Thanks to Guy Caron, Theresa Reese, John Hearty, Ric Atkins, Anand 226 Akundi and other members of the NENA i2.5 working group for their 227 comments and suggestions on this draft. 229 7. Informative References 231 [I-D.ietf-ecrit-phonebcp] 232 Rosen, B. and J. Polk, "Best Current Practice for 233 Communications Services in support of Emergency Calling", 234 draft-ietf-ecrit-phonebcp-06 (work in progress), 235 November 2008. 237 Author's Address 239 Brian Rosen 240 NeuStar 241 470 Conrad Dr. 242 Mars, PA 16046 243 US 245 Phone: +1 724 382 1051 246 Email: br@brianrosen.net