idnits 2.17.1 draft-holmberg-ecrit-callback-00.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 28 characters in excess of 72. == There are 13 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 3, 2011) is 4742 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) == Unused Reference: 'RFC3840' is defined on line 282, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track May 3, 2011 5 Expires: November 4, 2011 7 Session Initiation Protocol (SIP) Media Feature Tag to identity a Public 8 Safety Answering Point (PSAP) Callback Call 9 draft-holmberg-ecrit-callback-00.txt 11 Abstract 13 This specification defines a new Session Initiation Protocol (SIP) 14 media feature tag, sip.psap.callback, that SIP entities can use to 15 identity Public Safety Answering Point (PSAP) callback calls, and to 16 associate them with a previously made emergency call. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 4, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Applicability and Limitation . . . . . . . . . . . . . . . . . 3 55 4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 3 56 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 3 58 4.3. Emergency call . . . . . . . . . . . . . . . . . . . . . . 4 59 4.4. PSAP callback call . . . . . . . . . . . . . . . . . . . . 4 60 5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 4 61 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Registrar behavior . . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.3. PSAP callback call . . . . . . . . . . . . . . . . . . . . 5 66 7. Message Flow Examples . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 9.1. IANA Registration of the sip.psap.callback media 71 feature tag . . . . . . . . . . . . . . . . . . . . . . . . 6 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 73 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 7 76 12.2. Informational References . . . . . . . . . . . . . . . . . 7 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 TBD 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 3. Applicability and Limitation 91 TBD 93 4. User Agent Client behavior 95 4.1. General 97 TBD 99 4.2. Registration 101 When a UAC sends a SIP REGISTER request [RFC3261], and it wants to be 102 able to receive explicit PSAP callback calls associated with that 103 registration, it MUST insert a sip.psap.callback media feature tag in 104 the Contact header field [RFC3261] of the request. 106 The value of the sip.psap.callback MUST uniqually identity the User 107 Agent (UA). If the UA supports the "sip.instance" media feature tag 108 [RFC5626], it is STRONGLY RECOMMENDED that it uses the same value for 109 the sip.psap.callback feature tag. 111 OPEN ISSUE: Need to discuss whether the usage of a "static" value 112 (e.g. the sip.instance value), that might also be known by other 113 users, causes some security issues, and whether another value (that 114 might change between emergency registrations, should be used instead. 116 If the UAC applies the SIP Outbound mechanism [RFC5626], and 117 establishes multiple registration flows associated with a 118 registration, it MUST include the sip.psap.callback media feature tag 119 in each REGISTER requests associated with every registration flow for 120 which it wants to be able to receive explicit PSAP callback calls. 121 The UAC MUST use the same media feature tag value for each 122 registration flow associated with a registration. 124 Unless the UAC wants the registrar to remove the media feature tag 125 associated with a registration/registration flow, the UAC MUST 126 include the sip.psap.callback media feature tag in every SIP REGISTER 127 request associated with the registration (or registration flow), 128 apart from when it terminates a registration (or registration flow). 130 4.3. Emergency call 132 When a UAC sends an initial SIP INVITE request [RFC3261] for an 133 emergency call, it MUST insert a sip.psap.callback media feature tag 134 in the Contact header field of the request. The UAC MUST use the 135 same media feature tag value that has been used for the registration 136 associated with the emergency call. 138 OPEN ISSUE: Should the UAC also include the media feature tag in 139 calls that are not identified as emergency calls by the UAC, but will 140 be determined as emergency calls by the network? 142 4.4. PSAP callback call 144 When a UAC, representing a PSAP, sends an initial SIP INVITE request 145 for an PSAP callback call, it SHOULD insert a sip.psap.callback media 146 feature tag in the Accept-Contact header field [RFC3841] of the 147 request. The UAC MUST use the same media feature tag value that was 148 used for the emergency call associated with the callback call. 150 If the PSAP callback call comes from a Public Switched Telephony 151 Network (PSTN), or from another interworking network, the UAC 152 representing the PSAP will normally be located in a network 153 interworking gateway controller, such as a in a Media Gateway 154 Controller (MGC). If the interworking gateway controller is able to 155 determine that the call is a PSAP callback call it MUST insert a 156 media feature tag. If the interworking gateway controller is not 157 aware of the media feature tag value associated with the called user, 158 it inserts an empty media feature tag. 160 5. User Agent Server behavior 162 5.1. General 164 TBD 166 6. Registrar behavior 167 6.1. General 169 TBD 171 6.2. Registration 173 When a registrar performs registration procedures for a user, if the 174 associated SIP REGISTER request contains a sip.psap.callback media 175 feature tag with a media feature tag value, the registrar MUST store 176 the media feature tag value together with other registration data 177 associated with the registering user. 179 OPEN ISSUE: Is there a need for the registrar to inform the UAC that 180 it supports, and has stored the value of, the sip.psap.callback media 181 feature tag? 183 6.3. PSAP callback call 185 When a registrar receives an initial SIP INVITE request for a call, 186 and the Accept-Contact header field of the request contains a 187 sip.psap.callback media feature tag, if the media feature tag value 188 matches a value registered for the called user, and if the registrar 189 trusts the originator of the request, the registrar can decide that 190 the call is a PSAP callback call. 192 If the media feature tag of the request does not contain a media 193 feature tag value (this might be the case if the requests comes from 194 an MGC that has been able the identity the call as a PSAP callback 195 call, but is not aware of the media feature tag value associated with 196 the called user), if the registrar trusts the originator of the 197 request, and a media feature tag value has been registered for the 198 called user, the registrar MAY decide that the call is a PSAP 199 callback call. 201 OPEN ISSUE: If the registrar receives a request with an empty media 202 feature tag, and decides that the call is a PSAP callback call, 203 should the registrar add the registered media feature tag value to 204 the media feature tag in the request? 206 7. Message Flow Examples 208 7.1. Example 210 TBD 212 Add example flow 213 Figure 1: Example call flow 215 8. Security Considerations 217 TBD 219 9. IANA Considerations 221 9.1. IANA Registration of the sip.psap.callback media feature tag 223 This section registers a new media feature tag, sip.psap.callback, 224 into the into the SIP media feature tag tree. The required 225 information for this registration, as specified in section 3.4 of 226 [RFC2506], is: 228 RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 229 RFC number of this specification]] 231 Media feature tag name: sip.psap.callback 233 ASN.1 identifier associated with feature tag: New assignment by IANA 235 Summary of the media feature indicated by this feature tag: This feature tag indicates 236 a unique value for a User Agent (UA), which is used to associate PSAP callback calls with 237 emergency calls placed by the user. 239 Values appropriate for use with this feature tag: String (equality relationship) 241 Examples of typical use: Associating a PSAP callback call with a previously placed 242 emergency call. 244 Related standards or documents: RFC 3840 246 Security Considerations: General security considerations for media 247 feature tags are discussed in Section 11.1 of RFC 3840. 249 10. Acknowledgements 251 The original idea of using a token based mechanism to associate PSAP 252 callback calls with emergency calls was presented by Cullen Jennings. 254 Thanks to Fredrik Lindholm, Jan Holm and Ivo Sedlacek for their 255 comments and feedbacks on the initial draft. 257 Thanks to xxx for their feedback and suggestions on the ECRIT mailing 258 list. 260 11. Change Log 262 [RFC EDITOR NOTE: Please remove this section when publishing] 264 Changes from draft-holmberg-ecrit-callback-xx 265 o Indicate changes from previous version 267 12. References 269 12.1. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, March 1997. 274 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 275 Registration Procedure", BCP 31, RFC 2506, March 1999. 277 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 278 A., Peterson, J., Sparks, R., Handley, M., and E. 279 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 280 June 2002. 282 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 283 "Indicating User Agent Capabilities in the Session 284 Initiation Protocol (SIP)", RFC 3840, August 2004. 286 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 287 Preferences for the Session Initiation Protocol (SIP)", 288 RFC 3841, August 2004. 290 12.2. Informational References 292 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 293 Initiated Connections in the Session Initiation Protocol 294 (SIP)", RFC 5626, October 2009. 296 Author's Address 298 Christer Holmberg 299 Ericsson 300 Hirsalantie 11 301 Jorvas 02420 302 Finland 304 Email: christer.holmberg@ericsson.com