idnits 2.17.1 draft-ietf-salud-alert-info-urns-14.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 1 instance 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 (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2014) is 3478 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) == Missing Reference: 'RFCXXXX' is mentioned on line 1074, but not defined == Missing Reference: 'RFCxyz' is mentioned on line 916, but not defined == Missing Reference: 'RFCabc' is mentioned on line 918, but not defined == Missing Reference: 'RFCdef' is mentioned on line 921, but not defined ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3044 (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3187 (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3188 (Obsoleted by RFC 8458) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SALUD L. Liess, Ed. 3 Internet-Draft R. Jesske 4 Updates: 3261 (if approved) Deutsche Telekom AG 5 Intended status: Standards Track A. Johnston 6 Expires: April 20, 2015 Avaya 7 D. Worley 8 Ariadne 9 P. Kyzivat 10 Huawei 11 October 17, 2014 13 URNs for the Alert-Info Header Field of the Session Initiation Protocol 14 (SIP) 15 draft-ietf-salud-alert-info-urns-14 17 Abstract 19 The Session Initiation Protocol (SIP) supports the capability to 20 provide a reference to a specific rendering to be used by the UA as 21 an alerting signal (e.g., a ring tone or ringback tone) when the user 22 is alerted. This is done using the Alert-Info header field. 23 However, the reference (typically a URL) addresses only a specific 24 network resource with specific rendering properties. There is 25 currently no support for standard identifiers for describing the 26 semantics of the alerting situation or the characteristics of the 27 alerting signal, without being tied to a particular rendering. To 28 overcome these limitations and support new applications, a new family 29 of URNs for use in Alert-Info header fields (and situations with 30 similar requirements) is defined in this specification. 32 This document normatively updates RFC3261, which defines the Session 33 Initiation Protocol (SIP): It changes the usage of the Alert-Info 34 header field defined in RFC3261 by additionally allowing its use in 35 any non-100 provisional response to INVITE.This document also permits 36 proxies to add or remove an Alert-Info header field, and to add or 37 remove Alert-Info header field values. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 20, 2015. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 86 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 87 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 4. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 6 89 4.1. Allow Alert-Info in Provisional Responses . . . . . . . . 6 90 4.2. Proxies May Alter Alert-Info Header Fields . . . . . . . 7 91 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 92 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 6.1. PBX Ring Tones . . . . . . . . . . . . . . . . . . . . . 9 94 6.1.1. Normal . . . . . . . . . . . . . . . . . . . . . . . 9 95 6.1.2. External . . . . . . . . . . . . . . . . . . . . . . 10 96 6.1.3. Internal . . . . . . . . . . . . . . . . . . . . . . 10 97 6.1.4. Priority . . . . . . . . . . . . . . . . . . . . . . 10 98 6.1.5. Short . . . . . . . . . . . . . . . . . . . . . . . . 10 99 6.1.6. Delayed . . . . . . . . . . . . . . . . . . . . . . . 10 100 6.2. Service Tones . . . . . . . . . . . . . . . . . . . . . . 10 101 6.2.1. Call-waiting . . . . . . . . . . . . . . . . . . . . 10 102 6.2.2. Forward . . . . . . . . . . . . . . . . . . . . . . . 11 103 6.2.3. Transfer-recall . . . . . . . . . . . . . . . . . . . 11 104 6.2.4. Auto-callback . . . . . . . . . . . . . . . . . . . . 11 105 6.2.5. Hold-recall . . . . . . . . . . . . . . . . . . . . . 11 106 6.3. Country-specific Ringback Tone Indications for the Public 107 Telephone Network . . . . . . . . . . . . . . . . . . . . 11 108 7. URN Specification for the "alert" Namespace Identifier . . . 12 109 8. "alert" URN Values Definitions . . . . . . . . . . . . . . . 17 110 8.1. Values Definitions . . . . . . . . . . . 17 111 8.2. Values Definitions . . . . . . . . . . 18 112 8.2.1. Values for the 113 "service" . . . . . . . . . . . . . . . . . . . . . . 18 114 8.2.2. Values for the 115 "source" . . . . . . . . . . . . . . . . . . . . . . 18 116 8.2.3. Values for the 117 "priority" . . . . . . . . . . . . . . . . . . . . . 19 118 8.2.4. Values for the 119 "duration" . . . . . . . . . . . . . . . . . . . . . 19 120 8.2.5. Values for the 121 "delay" . . . . . . . . . . . . . . . . . . . . . . . 19 122 8.2.6. Values for the 123 "locale" . . . . . . . . . . . . . . . . . . . . . . 19 124 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 125 9.1. URN namespace identifier "alert" . . . . . . . . . . . . 19 126 9.1.1. 'Alert URN Identifiers' Registry . . . . . . . . . . 20 127 9.1.2. Initial IANA Registration . . . . . . . . . . . . . . 21 128 9.2. 'Alert URN Providers' Registry . . . . . . . . . . . . . 24 129 10. Extension Rules . . . . . . . . . . . . . . . . . . . . . . . 24 130 10.1. General Extension Rules . . . . . . . . . . . . . . . . 24 131 10.2. Private Extension Rules . . . . . . . . . . . . . . . . 25 132 10.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 26 133 10.3.1. Subsetting an Existing URN . . . . . . . . . . . . . 26 134 10.3.2. A New Value within an . . . . . . . 27 135 10.3.3. A New . . . . . . . . . . . . . . . 27 136 10.3.4. Subsetting a Private Extension URN . . . . . . . . . 27 137 11. Combinations of "alert" URNs . . . . . . . . . . . . . . . . 28 138 11.1. Priority Rules . . . . . . . . . . . . . . . . . . . . . 28 139 11.2. Multi-mode Signals . . . . . . . . . . . . . . . . . . . 29 140 12. Non-normative Algorithm for Handling Combinations of URNs . . 30 141 12.1. Algorithm Description . . . . . . . . . . . . . . . . . 30 142 12.2. Examples of How the Algorithm Works . . . . . . . . . . 32 143 12.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . 32 144 12.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . 33 145 12.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . 35 146 12.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . 36 147 12.2.5. Example 5 . . . . . . . . . . . . . . . . . . . . . 37 148 13. User Agent Behaviour . . . . . . . . . . . . . . . . . . . . 38 149 14. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . . . 39 150 15. Internationalization Considerations . . . . . . . . . . . . . 40 151 16. Security Considerations . . . . . . . . . . . . . . . . . . . 40 152 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 153 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 154 18.1. Normative References . . . . . . . . . . . . . . . . . . 41 155 18.2. Informative References . . . . . . . . . . . . . . . . . 42 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 158 1. Introduction 160 The Session Initiation Protocol (SIP) [RFC3261] includes a means to 161 suggest to a user agent (UA) a particular ringback tone or ring tone 162 to be used during session establishment. In [RFC3261] this is done 163 by including a URI in the Alert-Info header field, that specifies a 164 reference to the tone. The URI is most commonly the HTTP URL to an 165 audio file. On the receipt of the Alert-Info header field the user 166 agent may fetch the referenced ringback tone or ring tone and play it 167 to the user. 169 This mechanism hinders interoperability when there is no common 170 understanding of the meaning of the referenced tone, which might be 171 country- or vendor-specific. It can lead to problems for the user 172 trying to interpret the tone and for the UA wanting to substitute its 173 own tone (e.g., in accordance with user preferences) or provide an 174 alternative alerting mode (e.g., for hearing-impaired users). If 175 caller and callee are from different countries, the understanding of 176 the tones may vary significantly. Hearing impaired users may not 177 sense the specific tone if it is provided as an audio file. The tone 178 per se is also not useful for automata. 180 Another limitation of using URLs of audio files is that the 181 referenced tones are tied to particular renderings. There is no 182 method to signal the semantic intention of the alert while enabling 183 the recipient UA to choose the specific alert indication (such as a 184 particular tone, vibration, or visual display) to use to signal the 185 intention. Similarly, there is no method to signal particular 186 rendering features (such as short duration, delay, or country- 187 specific conventions). 189 The issues with URLs that reference audio files can be avoided by 190 using fixed URLs with specific meanings. However this approach has 191 its own interoperability issues. For example, consider the PBX 192 special ring tone for an external (to the PBX) caller. Different 193 vendors use different approaches such as: 195 Alert-Info: ;alert=external 197 where ring.pcm is a dummy file name, or: 199 Alert-Info: 200 Alert-Info: 202 As a result, the Alert-Info header field currently only works when 203 the same vendor provides PBX and UA, and only then if the same 204 artificial proprietary URI convention used. 206 To solve the described issues, this specification defines the new URN 207 namespace "alert" for the Alert-Info header field that allows for 208 programmatic user interface adaptation and for conversion of 209 equivalent alerting tones in the Public Switched Telephone Network 210 (PSTN) when the client is a gateway. The work to standardize an 211 "alert" URN will increase SIP interoperability for this header field 212 by replacing proprietary conventions used today. 214 The "alert" namespace provides syntax for several different 215 application spaces, e. g.: 217 o Names for service indications, such as call waiting or automatic 218 callback, not tied to any particular rendering. 219 o Names for common ring tones generated by PBX phones for cases such 220 as an internal enterprise caller, external caller, ringback tone 221 after a transfer failure or expiration of a hold timer, etc. 222 o Names for country-specific ringback tones. 223 o Names for things with specific renderings that aren't purely 224 audio. They might be static icons, video sequences, text, etc. 226 Some advantages of a URN rather than a URL of a downloadable 227 resource: 229 o Do not need to download it or deal with security issues associated 230 with dereferencing. 231 o No formatting or compatibility issues. 232 o No security risk of rendering something unexpected and 233 undesirable. 234 o The tone can be stored locally in whatever format and at whatever 235 quality level is appropriate, because it is specified "by name" 236 rather than "by value". 237 o It is easier to make policy decisions about whether to use it or 238 not. 239 o It facilitates translation for the hearing impaired. 241 The downside is that if the recipient does not understand the URN 242 then it will only be able to render a default ringback tone or ring 243 tone. 245 This document creates a new URN namespace and registry for alert 246 indications and registers some initial values. 248 In practice, this specification extends the usage of the Alert-Info 249 header field in that it will cause the use of a new class of URIs and 250 the use of multiple URIs. Backward compatibility issues are not 251 expected, as devices that do not understand an "alert" URN should 252 ignore it, and devices should not malfunction upon receiving multiple 253 Alert-Info header field values (s in [RFC3261]) (which 254 was syntactically permitted before, but rarely used). 256 2. Requirements Language 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in [RFC2119]. 262 3. Terminology 264 This specification uses a number of terms to refer to the roles 265 involved in the use of alerting indications in SIP. A "specifier" 266 sends an "alerting indication" (one or more URNs in an Alert-Info 267 header field) to a "renderer" which then "renders" a "signal" or 268 "rendering" based on the indication to a human user. A "category" is 269 a characteristic whose "values" can be used to classify indications. 271 This specification uses the terms "ring tone" and "ringback tone". A 272 "ring tone" or "calling signal" (terminology used in [E182]) is a 273 signal generated by the callee's end device, advising the callee 274 about an incoming call. A "ringback tone" or "ringing tone" 275 (terminology used in [E182]) is a signal advising the caller that a 276 connection has been made and that a ring tone is being rendered to 277 the callee. 279 4. Updates to RFC 3261 281 4.1. Allow Alert-Info in Provisional Responses 283 This specification changes the usage of the Alert-Info header field 284 defined in [RFC3261] by additionally allowing its use in any non-100 285 provisional response to INVITE. 287 Previously, the Alert-Info header field was only permitted in 180 288 (Ringing) responses. But in telephony, other situations indicated by 289 SIP provisional responses, such as 181 (Call Is Being Forwarded) and 290 182 (Call Is Being Queued), are often indicated by tones. Extending 291 the applicability of the Alert-Info header field allows the telephony 292 practice to be implemented in SIP. 294 To support this change, the following paragraph replaces the the 295 first paragraph of section 20.4 of [RFC3261]: 297 When present in an INVITE request, the Alert-Info header field 298 specifies an alternative ring tone to the UAS. When present in a 299 non-100 provisional response, the Alert-Info header field 300 specifies an alternative ringback tone to the UAC. A typical 301 usage is for a proxy to insert this header field to provide a 302 distinctive ring feature. 304 4.2. Proxies May Alter Alert-Info Header Fields 306 A SIP proxy MAY add or remove an Alert-Info header field, and MAY add 307 or remove Alert-Info header field values, in a SIP request or a 308 non-100 provisional response. 310 5. Requirements 312 This section discusses the requirements for an alerting indication to 313 transport the semantics of the alerting situation or the 314 characteristics of the rendering. 316 REQ-1: The mechanism will allow user agents (UAs) and proxies to 317 provide in the Alert-Info header field an alerting indication which 318 describes the semantics of the signaling situation or the 319 characteristics of the rendering and allows the recipient to decide 320 how to render the received information to the user. 322 REQ-2: The mechanism will allow the alerting indication to be 323 specified "by name" rather than "by value", to enable local policy 324 decisions whether to use it or not. 326 REQ-3: The mechanism will enable alerting indications to represent a 327 wide variety of signals, which have many largely-orthogonal 328 characteristics. 330 REQ-4: The mechanism will enable the set of alerting indications to 331 be able to support extensibility by a wide variety of organizations 332 that are not coordinated with each other. Extensions will be able 333 to: 335 - add further values to any existing category 336 - add further categories that are orthogonal to existing categories 338 - semantically subdivide the meaning provided by any existing 339 indication 341 REQ-5: The mechanism will be flexible, so new alerting indications 342 can be defined in the future, when SIP-applications evolve. E. g. 343 "alert" URNs could identify specific media by name, such as 344 "Beethoven's Fifth", and the end device could render some small part 345 of it as a ring tone. 347 REQ-6: The mechanism will provide only an indication capability, not 348 a negotiation capability. 350 REQ-7: The mechanism will not require an alerting indication to 351 depend on context provided by a previous alerting indication in 352 either direction. 354 REQ-8: The mechanism will allow transmission in the Alert-Info header 355 field of SIP INVITE requests and provisional 1xx responses excepting 356 the 100 responses. 358 REQ-9: The mechanism will be able to accommodate renderers that are 359 customized with a limited or uncommon set of signals they can render 360 and renderers that are provided with a set of signals that have 361 uncommon semantics. (The canonical example is a UA for the hearing- 362 impaired, customized with an uncommon set of signals, video or text 363 instead of audio. By REQ-6, the renderer has no way of transmitting 364 this fact to the specifier.) 366 REQ-10: The mechanism will allow an alerting indication to reliably 367 carry all extensions if the specifier and the renderer have designs 368 that are properly coordinated. 370 REQ-11: The mechanism will allow a renderer to select a tone that 371 approximates to that intended by the specifier if the renderer is 372 unable to provide the precise tone indicated. 374 REQ-12: The mechanism will support alerting indications relating to 375 services such as call waiting, forward, transfer-recall, auto- 376 callback and hold-recall. 378 REQ-13: The mechanism will allow rendering common PBX ring tone 379 types. 381 REQ-14: The mechanism will allow rendering specific country ringback 382 tones. 384 REQ-15: The mechanism will allow rendering tones for emergency 385 alerts. (Use cases and values definition are not a subject of this 386 specification.) 388 REQ-16: The mechanism will allow rendering using other means than 389 tones, e.g. text or images. 391 REQ-17: The mechanism will allow TDM gateways to map ring/ringback 392 tones from legacy protocols to SIP at the edge of a network, e.g. 393 national ring tones as defined in TIA/EIA-41-D and 3GPP2 A.S0014. 394 (Use cases and values definition are not a subject of this 395 specification.) 397 REQ-18: The mechanism will ensure that if an UA receives "alert" URNs 398 or portions of an "alert" URN it does not understand, it can ignore 399 them. 401 REQ-19 The mechanism will allow storage of the actual encoding of the 402 rendering locally rather than fetching it. 404 REQ-20: The mechanism must provide a simple way to combine two or 405 more alerting indications to produce an alerting indication that 406 requests a combination of the intentions of the two alerting 407 indications, where any contradictions or conflicts between the two 408 alerting indications are resolved in favor of the intention of the 409 first alerting indication. 411 6. Use Cases 413 This section describes some use cases for which the "alert" URN 414 mechanism is needed today. 416 6.1. PBX Ring Tones 418 This section defines some commonly encountered ring tones on PBX or 419 business phones. They are as follows: 421 6.1.1. Normal 423 This tone indicates that the default or normal ring tone should be 424 rendered. This is essentially a no-operation "alert" URN and should 425 be treated by the UA as if no "alert" URN is present. This is most 426 useful when Alert-Info header field parameters are being used. For 427 example, in [I-D.ietf-bliss-shared-appearances], an Alert-Info header 428 field needs to be present containing the "appearance" parameter, but 429 no special ring tone needs to be specified. 431 [Note to RFC Editor: Please update the information for the above 432 reference and change its tag from "I-D.ietf-bliss-shared-appearances" 433 to the appropriate RFC number.] 435 6.1.2. External 437 This tone is used to indicate that the caller is external to the 438 enterprise or PBX system. This could be a call from the PSTN or from 439 a SIP trunk. 441 6.1.3. Internal 443 This tone is used to indicate that the caller is internal to the 444 enterprise or PBX system. The call could have been originated from 445 another user on this PBX or on another PBX within the enterprise. 447 6.1.4. Priority 449 A PBX tone needs to indicate that a priority level alert should be 450 applied for the type of alerting specified (e.g. internal alerting). 452 6.1.5. Short 454 In this case the alerting type specified (e.g. internal alerting) 455 should be rendered shorter than normal. In contact centers, this is 456 sometimes referred to as "abbreviated ringing" or a "zip tone". 458 6.1.6. Delayed 460 In this case the alerting type specified should be rendered after a 461 short delay. In some bridged line/shared line appearance 462 implementations, this is used so that the bridged line does not ring 463 at exactly the same time as the main line, but is delayed a few 464 seconds. 466 6.2. Service Tones 468 These tones are used to indicate specific PBX and public network 469 telephony services. 471 6.2.1. Call-waiting 473 The Call Waiting Service [TS24.615] permits a callee to be notified 474 of an incoming call while the callee is engaged in an active or held 475 call. Subsequently, the callee can either accept, reject, or ignore 476 the incoming call. There is an interest on the caller side to be 477 informed about the call waiting situation on the callee side. Having 478 this information the caller can decide whether to continue waiting 479 for callee to pickup or better to call some time later when it is 480 estimated that the callee could have finished the ongoing 481 conversation. To provide this information, the callee's UAS (or 482 proxy) aware of the call waiting condition can add the call-waiting 483 indication to the Alert-Info header field in the 180 (Ringing) 484 response. 486 6.2.2. Forward 488 This feature is used in a 180 (Ringing) response when a call 489 forwarding feature has been initiated on an INVITE. Many PBX system 490 implement a forwarding "beep" followed by normal ringing to indicate 491 this. Note that a 181 response can be used in place of this URN. 493 6.2.3. Transfer-recall 495 This feature is used when a blind transfer [RFC5589] has been 496 performed by a server on behalf of the transferor and fails. Instead 497 of failing the call, the server calls back the transferor, giving 498 them another chance to transfer or otherwise deal with the call. 499 This service tone is used to distinguish this INVITE from a normal 500 incoming call. 502 6.2.4. Auto-callback 504 This feature is used when a user has utilized a server to implement 505 an automatic callback service [RFC6910]. When the user is available, 506 the server calls back the user and utilizes this service tone to 507 distinguish this INVITE from a normal incoming call. 509 6.2.5. Hold-recall 511 This feature is used when a server implements a call hold timer on 512 behalf of an endpoint. After a certain period of time of being on 513 hold, the user who placed the call on hold is alerted to either 514 retrieve the call or otherwise dispose of the call. This service 515 tone is used to distinguish this case from a normal incoming call. 517 6.3. Country-specific Ringback Tone Indications for the Public 518 Telephone Network 520 In the PSTN, different tones are used in different countries. End 521 users are accustomed to hear the callee's country ringback tone and 522 would like to have this feature for SIP. 524 7. URN Specification for the "alert" Namespace Identifier 526 This section provides the registration template for the "alert" URN 527 namespace identifier (NID) according to [RFC2141] and [RFC3406]. 529 Namespace ID: alert 531 Registration Information: 533 Registration version: 1 534 Registration date: YYYY-MM-DD [Note to RFC Editor: Please replace 535 YYYY-MM-DD with the publication date of this RFC.] 537 Declared registrant of the namespace: 539 Registering organization: Real-time Applications and 540 Infrastructure Area, IETF 541 Designated contact: RAI Area Director 542 Designated contact email: rai-ads at tools.ietf.org 544 Declaration of syntactic structure: 545 The Namespace Specific String (NSS) for the "alert" URNs is called 546 an and has a hierarchical structure. The first 547 colon-separated part after "alert" is called the ; 548 the parts to the right of that are s, and together 549 form the . The general form is 550 urn:alert::. 552 The following identifiers are defined in 553 [RFCXXXX]: "service" , "priority" , "source" , "duration", "delay" 554 and "locale". The set can be extended in the 555 future, either by standardization or by private action. The 556 s describe distinct features of alerting signals. 558 [Note to RFC Editor: Please change XXXX in [RFCXXXX] by the new 559 RFC number, when assigned. ] 561 Any "alert" URN defined in this specification is syntactically 562 valid for ring and ringback tones and can be used in SIP INVITE 563 requests or in provisional 1xx responses excepting the 100 564 response. 566 The ABNF [RFC5234] for the "alert" URNs is shown below: 568 alert-URN = "urn:alert:" alert-identifier 569 alert-identifier = alert-category ":" alert-indication 570 alert-category = alert-name 571 alert-indication = alert-ind-part *(":" alert-ind-part) 572 alert-ind-part = alert-name 573 alert-name = alert-label / private-name 574 private-name = alert-label "@" provider 575 provider = alert-label 576 alert-label = let-dig [ *let-dig-hyp let-dig ] 577 let-dig-hyp = let-dig / "-" 578 let-dig = ALPHA / DIGIT 579 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 580 DIGIT = %x30-39 ; 0-9 581 s MUST comply with the syntax for Non Reserved LDH- 582 labels [RFC5890]. Registered URNs and components thereof MUST be 583 transmitted as registered (including case). 585 Relevant ancillary documentation: [RFCXXXX] 586 [Note to RFC Editor: Please change XXXX in [RFCXXXX] by the new 587 RFC number, when assigned.] 589 Namespace considerations: This specification defines a URN namespace 590 "alert" for URNs representing signals or renderings which are 591 presented to users to inform them of events and actions. The 592 initial usage is to specify ring tones and ringback tones when 593 dialogs are established in SIP, but they can also be used for 594 other communication-initiation protocols (e.g., H.323), and more 595 generally, in any situation (e.g., web pages or endpoint device 596 software configurations) to describe how a user should be 597 signaled. 599 An "alert" URN does not describe a complete signal, but rather 600 describes a particular characteristic of the event it is signaling 601 or a feature of the signal to be presented. The complete 602 specification of the signal is a sequence of "alert" URNs 603 specifying the desired characteristics/significance of the signal 604 in priority order, with the most important aspects specified by 605 the earlier URNs. This allows the sender of a sequence of URNs to 606 compose very detailed specifications from a restricted set of 607 URNs, and to clearly specify which aspects of the specification it 608 considers most important. 610 The initial scope of usage is in the Alert-Info header field, in 611 initial INVITE requests (to indicate how the called user should be 612 alerted regarding the call) and non-100 provisional (1xx) 613 responses to those INVITE requests (to indicate the ringback, how 614 the calling user should be alerted regarding the progress of the 615 call). 617 In order to assure widespread adoption of these URNs for 618 indicating ring tones and ringback tones, the scheme must allow 619 replication of the current diversity of these tones. Currently, 620 these tones vary between the PSTNs of different nations and 621 between equipment supplied by different vendors. Thus, the scheme 622 must accommodate national variations and proprietary extensions in 623 a way that minimizes the information that is lost during 624 interoperation between systems that follow different national 625 variations or that are supplied by different vendors. 627 The scheme allows definition of private extension URNs that refine 628 and extend the information provided by standard URNs. Private 629 extension URNs can also refine and extend the information provided 630 by other private extension URNs. Private extensions can also 631 define entirely new categories of information about calls. We 632 expect these extensions to be used extensively when existing PBX 633 products are converted to support SIP operation. 635 The device that receives an Alert-Info header field containing a 636 sequence of "alert" URNs provides to the user a rendering that 637 represents the semantic content of the URNs. The device is given 638 great leeway in choosing the rendering, but it is constrained by 639 rules that maximize interoperability between systems that support 640 different sets of private extensions. In particular, earlier URNs 641 in the sequence have priority of expression over later URNs in the 642 sequence, and URNs that are not usable in their entirety (because 643 they contain unknown extensions or are incompatible with previous 644 URNs) are successively truncated in attempt to construct a URN 645 that retains some information and is renderable in the context. 647 Due to the practical importance of private extensions for the 648 adoption of URNs for alerting calls and the very specific rules 649 for private extensions and the corresponding processing rules that 650 allow quality interoperation in the face of private extensions, 651 the requirements of the "alert" URN scheme cannot be met by a 652 fixed enumeration of URNs and corresponding meanings. In 653 particular, the existing namespace "urn:ietf:params" does not 654 suffice (unless the private extension apparatus is applied to that 655 namespace). 657 There do not appear to be other URN namespaces that uniquely 658 identify the semantic of a signal or rendering feature. Unlike 659 most other currently registered URN namespaces, the "alert" URN 660 does not identify documents and protocol objects (e.g., [RFC3044], 661 [RFC3120], [RFC3187], [RFC3188], [RFC4179], [RFC4195], [RFC4198]), 662 types of telecommunications equipment [RFC4152], people or 663 organizations [RFC3043]. 665 The s are hierarchical identifiers. An 666 asserts some fact or feature of the offered SIP dialog, or some 667 fact or feature of how it should be presented to a user, or of how 668 it is being presented to a user. Removing an 669 from the end of an (which has more than one ) creates a shorter with a less specific 671 meaning; the set of dialogs to which the longer 672 applies is necessarily a subset of the set of dialogs to which the 673 shorter applies. (If the starting 674 contains only one , and thus the 675 cannot be removed to make a shorter , we can consider 676 the set of dialogs to which the applies to be a subset 677 of the set of all dialogs.) 679 The specific criteria defining the subset to which the longer 680 applies, within the larger set of dialogs, is 681 considered to be the meaning of the final . This 682 meaning is relative to and depends upon the preceding and s (if any). The meanings of two 684 s that are textually the same but are preceded by 685 different s or s have no necessary 686 connection. (An considered alone has no meaning 687 in this sense.) 689 The organization owning the within a 690 specifies the meaning of that when it is used as an 691 . (The organization owning a is 692 specified by the registry described in Section 9.2.) 694 The organization owning the within a (in 695 either an or an ) specifies the 696 meaning of each which is an that 697 follows that and that precedes the next which is a (if any). 700 The meaning of all other s (i.e., those that are 701 not s and do not follow a ) is defined 702 by standardization. 704 Community considerations: The "alert" URNs are relevant to a large 705 cross-section of Internet users, namely those that initiate and 706 receive communication connections via the Session Initiation 707 Protocol. These users include both technical and non-technical 708 users, on a variety of devices and with a variety of perception 709 capabilities. The "alert" URNs will allow Internet users to 710 receive more information about offered calls and enable them to 711 better make decisions about accepting an offered call, and to get 712 better feedback on the progress of a call they have made. 714 User interfaces for perception-impaired users can better render 715 the ring and ringback tones based on the "alert" URNs because the 716 URNs provide more detailed information regarding the intention of 717 communications than is provided by current SIP mechanisms. 719 Process of identifier assignment: 720 Assignment of standardized "alert" URNs is by insertion into the 721 IANA registry described in Section 9.1.1. This process defines 722 the meanings of s that have standardized meanings, 723 as described in "Namespace Considerations". 725 A new URN MUST NOT be registered if it is equal by the comparison 726 rules to an already registered URN. 728 Private extensions are "alert" URNs that include s 729 that are s and s that appear after a 730 s (either as an or an ). If such an is a , 732 its meaning is defined by the organization that owns the 733 that appears in the . If the is an , its meaning is defined by the 735 organization that owns the that appears in the closest 736 preceding the . The organization 737 owning a is specified by the registry described in 738 Section 9.2. 740 Identifier uniqueness and persistence considerations: An "alert" URN 741 identifies a semantic feature of a call or a sensory feature of 742 how the call alerting should be a rendered at the caller's or 743 callee's end device. 745 For standardized s in URNs, uniqueness and 746 persistence of their meanings is guaranteed by the fact that they 747 are registered with IANA in accordance with the procedures of 748 Section 9.1.1; the feature identified by a particular "alert" URN 749 is distinct from the feature identified by any other standardized 750 "alert" URN. 752 Assuring uniqueness and persistence of the meanings of private 753 extensions is delegated to the organizations that define private 754 extension s. The organization responsible for a 755 particular in a particular "alert" URN is the 756 owner of a syntactically-determined part within the 757 URN. 759 An organization SHOULD use only one value for all of 760 the s it defines. 762 Process for identifier resolution: The process of identifier 763 resolution is the process by which a rendering device chooses a 764 rendering to represent a sequence of "alert" URNs. The device is 765 allowed great leeway in making this choice, but the process MUST 766 obey the rules of Section 11.1. The device is expected to provide 767 renderings that users associate with the meanings assigned to the 768 URNs within their cultural context. A non-normative example 769 resolution algorithm is given in Section 12.1. 771 Rules for lexical equivalence: "alert" URNs are compared according 772 to case-insensitive string equality. 774 Conformance with URN syntax: All "alert" URNs must conform to the 775 BNF in the 'Declaration of syntactic structure', which is a subset 776 of the generic URN syntax [RFC2141]. s are 777 constrained to be Non Reserved LDH-labels [RFC5890], that is, 778 "ordinary ASCII labels". Future standardization may allow s that are A-labels [RFC5890], and so interpreters of 780 "alert" URNs MUST operate correctly (per Section 11.1) when given 781 such URNs as input. 783 Validation mechanism: An "alert" URN containing no private 784 extensions can be validated based on the IANA registry of 785 standardized "alert" URNs. Validating an "alert" URN containing 786 private extensions requires obtaining information regarding the 787 private extensions defined by the organization that owns the 788 in the relevant . The identity of the 789 organization can be determined from the IANA registry described in 790 Section 9.1.1. However, if an "alert" URN contains at least one 791 that precedes the first , the 792 portion of the "alert" URN that precedes the first 793 must itself be a valid standardized "alert" URN, which may be 794 validated as above. 796 Scope: The scope for this URN is public and global. 798 8. "alert" URN Values Definitions 800 8.1. Values Definitions 802 The following values are defined in this document: 804 - service 805 - source 806 - priority 807 - duration 808 - delay 809 - locale 811 8.2. Values Definitions 813 This section describes the "alert" URN indication values for the 814 alert-categories defined in this document. 816 For each , a default is defined, 817 which is essentially a no-operation "alert" URN and should be treated 818 by the UA as if no "alert" URN for the respective category is 819 present. "alert" URN default indications are most useful when Alert- 820 Info header field parameters are being used. For example, in 821 [I-D.ietf-bliss-shared-appearances], an Alert-Info header field needs 822 to be present containing the "appearance" parameter, but no special 823 ringtone need be specified. 825 The "" syntax is used for extensions defined by 826 independent organizations, as described in Section 10.2. 828 8.2.1. Values for the "service" 830 - normal (default) 831 - call-waiting 832 - forward 833 - recall:callback 834 - recall:hold 835 - recall:transfer 836 - 838 Examples: or 839 . 841 8.2.2. Values for the "source" 843 - unclassified (default) 844 - internal 845 - external 846 - friend 847 - family 848 - 850 (These s will rarely be provided by the sending UA; 851 rather they will usually be inserted by a proxy acting on behalf of 852 the recipient UA to inform the recipient UA about the origins of a 853 call.) 855 Examples: . 857 8.2.3. Values for the "priority" 859 - normal (default) 860 - low 861 - high 862 - 864 Examples: . 866 8.2.4. Values for the "duration" 868 - normal (default) 869 - short 870 - long 871 - 873 Examples: . 875 8.2.5. Values for the "delay" 877 - none (default) 878 - yes 879 - 881 Examples: . 883 8.2.6. Values for the "locale" 885 - default (default) 886 - country: 887 - 889 The ISO 3166-1 country code [ISO3166-1] is used to inform the 890 renderer on the other side of the call that a country-specific 891 rendering should be used. For example, to indicate ringback tones 892 from South Africa, the following URN would be used: 893 . 895 9. IANA Considerations 897 9.1. URN namespace identifier "alert" 899 This section registers a new URN namespace identifier (NID), "alert", 900 in accordance with [RFC3406] with the registration template provided 901 in Section 7. 903 9.1.1. 'Alert URN Identifiers' Registry 905 Standard "alert" URNs are recorded as s in a new 906 registry called "Alert URN Identifiers". Thus, creating a new 907 standard "alert" URN requires IANA action. IANA manages the "Alert 908 URN Identifiers" registry under the policy 'Specification Required' 909 [RFC5226] following the guidelines in Section 10.1. 911 The registry contains entries in the following formats: 913 / Reference Description 914 915 --------------------------------------------------------------- 916 foo [RFCxyz] Description of the 'foo' 917 ; 918 foo:bar [RFCabc] Description of the 'foo:bar' 919 921 foo: [RFCdef] Description of the 922 'foo:' 923 s (which will 924 reference the value) 926 The first value in each row is the value that is registered, which is 927 either: (1) an value, (2) an 928 value, composed of an followed by an , in turn composed of one or more s, or (3) a 930 pattern for values (e.g., for the "locale" in Section 9.1.2.6). 933 The second value in each row is the reference to the required 934 specification for the value. 936 The third value in each row is a short description of the semantics 937 of the value. 939 A new URN MUST NOT be registered if it is equal by the comparison 940 rules (that is, case-insensitive string comparison) to an already 941 registered URN. 943 and values which contain 944 s are not managed by IANA. The process of assigning 945 these values is described in Section 10.2. 947 9.1.2. Initial IANA Registration 949 This document defines the s 'service', 'source', 950 'priority', 'duration', 'delay' and 'locale'. The entries to be 951 added to the Alert URN Identifiers 'registry table' for each are given in the respective sections below. 954 [Note to RFC Editor: In all the entries below, please replace XXXX in 955 [RFCXXXX] by the new RFC number, when assigned.] 957 9.1.2.1. The "service" and s 959 The following table contains the initial IANA registration for the 960 "service" and s. The value of 961 this indicator is set to a value different from "normal" if the 962 caller or callee is informed that a specific telephony service has 963 been initiated. 965 / Reference Description 966 967 ----------------------------------------------------------- 968 service [RFCXXXX] Specific telephony 969 service used in this 970 call 971 service:normal [RFCXXXX] Normal ring/ringback 972 rendering (default value) 973 service:call-waiting [RFCXXXX] Call waiting was 974 initiated at the other side 975 of the call 976 service:forward [RFCXXXX] Call has been forwarded 977 service:recall:callback [RFCXXXX] Recall due to callback 978 service:recall:hold [RFCXXXX] Recall due to call hold 979 service:recall:transfer [RFCXXXX] Recall due to transfer 981 9.1.2.2. The "source" and s 983 The following table contains the initial IANA registration for the 984 "source" and . The value of this 985 indicator provides information about the user at the other side of 986 the call. 988 / Reference Description 989 990 ----------------------------------------------------------- 991 source [RFCXXXX] Classification 992 of the other party 993 to the call 994 source:unclassified [RFCXXXX] Unclassified ring/ringback 995 rendering (default value) 996 source:internal [RFCXXXX] User at the other side of 997 the call is internal to the 998 enterprise or PBX system 999 source:external [RFCXXXX] User at the other side of 1000 the call is external to the 1001 enterprise or PBX system 1002 source:friend [RFCXXXX] User at the other side of 1003 the call is a friend 1004 source:family [RFCXXXX] User at the other side of 1005 the call is a family member 1007 9.1.2.3. The "priority" and s 1009 The following table contains the initial IANA registration for the 1010 "priority" and s. The value of 1011 this indicator provides information about the priority the alerted 1012 user should give to the call. 1014 / Reference Description 1015 1016 ----------------------------------------------------------- 1017 priority [RFCXXXX] Priority of the 1018 call 1019 priority:normal [RFCXXXX] Normal ring/ringback 1020 rendering (default value) 1021 priority:low [RFCXXXX] Low priority call. 1022 priority:high [RFCXXXX] High priority call 1024 9.1.2.4. The "duration" and s 1026 The following table contains the initial IANA registration for the 1027 "duration" and s. The value of 1028 this indicator provides information about the duration of the 1029 alerting signals compared to the default alerting signals. 1031 / Reference Description 1032 1033 ----------------------------------------------------------- 1034 duration [RFCXXXX] Duration of alerting signal 1035 alerting signal 1036 duration:normal [RFCXXXX] Normal ring/ringback 1037 rendering (default value) 1038 duration:short [RFCXXXX] Shorter than normal 1039 duration:long [RFCXXXX] Longer than normal 1041 9.1.2.5. The "delay" and s 1043 The following table contains the initial IANA registration for the 1044 "delay" and s. The value of this 1045 indicator provides information about about whether the presentation 1046 of the alerting signal should be delayed compared to the default 1047 presentation process. For more details see Section 6.1.6. 1049 / Reference Description 1050 1051 ----------------------------------------------------------- 1052 delay [RFCXXXX] Delay of rendering of alerting 1053 of alerting signal 1054 delay:none [RFCXXXX] Immediate alerting 1055 (default value) 1056 delay:yes [RFCXXXX] Delayed alerting 1058 9.1.2.6. The "locale" and s 1060 The following table contains the initial IANA registration for the 1061 "locale" and s. The value of this 1062 indicator provides information suggests that alerting signals 1063 characteristic of the specified location should be used. 1065 / Reference Description 1066 1067 ----------------------------------------------------------- 1068 locale [RFCXXXX] Location-specific 1069 alerting signals 1070 locale:default [RFCXXXX] Alerting not location 1071 specific 1072 (default value) 1073 locale:country: 1074 [RFCXXXX] Alerting according to the 1075 conventions of the specified 1076 country 1078 9.2. 'Alert URN Providers' Registry 1080 Values of , which are used to create s, are 1081 recorded in a new registry called "Alert URN Providers". (Private 1082 extension "alert" URNs that are defined are not recorded by IANA.) 1083 The registry is managed by IANA under the policy 'First Come First 1084 Served'.[RFC5226] 1086 The registry contains entries in the following format: 1088 Registrant Contact URI 1089 --------------------------------------------------------------------- 1090 example IETF mailto:rai-ads&tools.ietf.org 1092 The first value in each row is the value that is 1093 registered. This value is case-insensitive and MUST comply with the 1094 syntax for Non Reserved LDH-labels [RFC5890]. 1096 The second value in each row is the name of the registrant of the 1097 value. 1099 The third value is a contact URI for the registrant. 1101 The registry initially contains the one entry shown above, which can 1102 be used for constructing examples of private extension URNs. 1104 10. Extension Rules 1106 10.1. General Extension Rules 1108 The set of "alert" URNs is extensible. An extension "at the top 1109 level" creates a new (which represents a new 1110 alerting characteristic), an extension "at the second level" creates 1111 a new value for an existing , an 1112 extension "at the third level" creates a subdivision of an existing 1113 (that has one ), etc. URNs allow 1114 (in principle) indefinite subdivision of existing 1115 values, although most of the standard "alert" URNs have only one 1116 level of subdivision and a few have two levels of subdivision. 1118 Extensions, either standard or private, MUST conform to the following 1119 principles: 1121 A new is independent of all previously-existing 1122 s: For any combination of one in 1123 the new with any one in any of 1124 the previously-existing s, there are potential calls 1125 to which the combination can be meaningfully applied. 1127 A new that has more than one is a 1128 semantic refinement of a parent , the parent being 1129 obtained by deleting the final . The new has as parent the most specific previously-existing 1131 whose meaning includes all potential calls to 1132 which the new could be meaningfully applied. 1134 A new has no semantic overlap with any sibling 1135 (s that differ only in the final 1136 ). I.e., there could be no call to which both 1137 s could be meaningfully applied. 1139 The process for defining new standard "alert" URNs is described in 1140 Section 9.1.1; all such definitions require registering a publicly- 1141 available specification. The process for defining new "alert" URNs 1142 via the private extension mechanism is described in Section 10.2. 1144 10.2. Private Extension Rules 1146 The "" syntax is used to create private extensions, 1147 extensions that are not registered with IANA. The "" 1148 has the form of an "" followed by "@" and then a 1149 "" that designates the organization defining the extension. 1150 Both and have the same syntax as an ordinary 1151 ASCII DNS label. A private extension URN is created by using a 1152 as either an or an . 1154 If the is used as an , the 1155 characteristic of the alerting signal that the 1156 describes is defined by the organization. If the is 1157 used as the first , the organization defines an 1158 alternative value for the standardized of the URN. 1159 If the is used as the second or later , the organization defines the meaning of the URN as a subset of 1161 the meaning of the shorter URN resulting when the (and 1162 any subsequent s) are removed. 1164 Within a URN, all components that follow a but are before any following s are additional 1166 private extensions whose meaning is defined by the organization 1167 defining the nearest preceding . 1169 A URN that contains a private extension can be further subdivided by 1170 the private extension of a different organization: the second 1171 organization appends an that is a 1172 containing a the value for the second organization. 1174 The meaning of a or an that is defined 1175 privately (because of a preceding ) is only fixed 1176 within the context provided by the sequence of preceding s; these components have no meaning in isolation and there is no 1178 necessary relationship between the meaning of textually identical 1179 s that are preceded by different sequences of s. 1182 Creating private extension "alert" URNs is not a Standards Action and 1183 they are not registered with IANA. 1185 The organization defining a private extension is responsible for 1186 ensuring persistence of the meaning of the private extension. 1188 Private extensions MUST conform to the principles of Section 10.1, 1189 both in regard to previously-existing standard s and in 1190 regard to any previously-existing private extensions using the same 1191 value, and any other private extensions that the 1192 organization is aware of. In particular, a private extension MUST 1193 NOT duplicate any standard URN or any private extension that the 1194 organization is aware of. (In either of those cases, the 1195 organization MUST use the existing URN for its purposes.) 1197 An organization obtains a value for constructing s by registering the value with IANA as provided in Section 9.2. 1200 10.3. Examples 1202 10.3.1. Subsetting an Existing URN 1204 The organization registering the "example" can define 1205 distinctive versions of : 1207 urn:alert:service:call-waiting:abc@example 1208 urn:alert:service:call-waiting:def@example 1210 It can create a more specialized URN that applies to a subset of the 1211 situations to which the first URN above applies: 1213 urn:alert:service:call-waiting:abc@example:xyz 1215 Because "xyz" follows "abc@example" (and there is no intervening 1216 ), its meaning is defined by the owner of the 1217 "example". 1219 10.3.2. A New Value within an 1221 The organization registering the "example" can define URNs 1222 in the "service" category to express a new service that is not 1223 covered by any of the standardized URNs: 1225 urn:alert:service:ghi@example 1227 However, before defining such a URN, the organization should verify 1228 that the set of calls to which the URN applies is not a subset of the 1229 set of calls for some existing URN. If it is a subset, the extension 1230 URN should be a subdivision of the existing URN. 1232 10.3.3. A New 1234 The organization registering the "example" can define an 1235 extension named "jkl@example" with two s "a1" and "a2": 1238 urn:alert:jkl@example:a1 1239 urn:alert:jkl@example:a2 1241 10.3.4. Subsetting a Private Extension URN 1243 The organization registering the "foo" wants to define a 1244 set of URNs that specify the different ring patterns used by a 1245 "distinctive ring" service to alert for incoming calls that are 1246 directed to different directory numbers. These ring patterns are 1247 composed of groups of ring sounds that have particular patterns of 1248 lengths. 1250 The company can create a private "distinctive@foo", 1251 and within it assign three 'alert' URNs that indicate the three 1252 different ring patterns used by the company's service: 1254 urn:alert:distinctive@foo:long-long 1255 urn:alert:distinctive@foo:short-long-short 1256 urn:alert:distinctive@foo:short-short-long 1258 Later, the company registering the "bar" wants to define 1259 an additional 'alert' URN for the ring pattern "short short", which 1260 it uses to support a fourth directory number for a phone instrument. 1261 The company can create a to be used with the 1262 "distinctive@foo" : 1264 urn:alert:distinctive@foo:short-short@bar 1266 11. Combinations of "alert" URNs 1268 11.1. Priority Rules 1270 This section describes combination rules for the case when all the 1271 Alert-Info header fields only contain "alert" URNs. Other 1272 combinations of URIs in the Alert-Info header fields of the same SIP 1273 message are not defined in this specification. 1275 In many cases, more than one URN will be needed to fully define a 1276 particular tone. This is done by including multiple "alert" URNs, in 1277 one or more Alert-Info header fields in a request or a response. For 1278 example, an internal, priority call could be indicated by Alert-Info: 1279 , A priority 1280 call waiting tone could be indicated by Alert-Info: 1281 , 1283 The sender of the Alert-Info header field may include an arbitrary 1284 list of "alert" URNs, even if they are redundant or contradictory. 1285 An earlier URN has priority over any later contradictory URN. This 1286 allows any element to modify a list of URNs to require a feature 1287 value (by adding a URN at the beginning of the list) or to suggest a 1288 feature value (by adding a URN at the end of the list). 1290 The receiving UA matches the received "alert" URN combination with 1291 the signal(s) it is able to render. 1293 The implementation is free to ignore an "alert" URN if it does not 1294 recognize the URN, or if it is incapable of rendering its effect in 1295 the context. Similarly, it can remove a final series of one or more 1296 s of an "alert" URN to create a "more generic" URN 1297 which it recognizes and whose meaning it can render in the context. 1299 The exact way in which a UA renders a received combination of "alert" 1300 URNs is left as an implementation issue. However, the implementation 1301 MUST comply to following rules: 1303 a. Each "alert" URN has precedence over all URNs that follow it, 1304 and its interpretation is subordinate to all URNs that precede it. 1306 b. If the UA cannot implement the effect of a URN (because it 1307 does not recognize the URN or the URN's effect is precluded by 1308 preceding URNs), the UA repeatedly removes the final of the URN until either 1311 (i) the resulting URN is recognized and can be given effect by 1312 some signal (without reducing the degree of expression of any 1313 preceding URN), or 1315 (ii) the resulting URN is reduced to having no 1316 in which case, that URN in the series cannot be given effect, 1317 and so is ignored. 1319 c. In case that after processing all the received URNs, the UA 1320 can generate more than one signal that are equally effective at 1321 expressing the URNs (under the preceding rules), one of those 1322 signals is selected. When selecting from the set of equally 1323 effective signals, the least specific signal in the set should be 1324 chosen: a signal should not be chosen if a less-specific signal is 1325 also in the set. (Specificity is to be judged based on the 1326 defined meanings of the signals to the user.) (E.g., if each 1327 signal is considered to express certain s of 1328 certain , one signal is less-specific than a 1329 second signal if the first signal's s are a 1330 subset or are prefixes of the second signal's s.) However, a more-specific signal may be chosen if 1332 the choice is based on information derived from the containing SIP 1333 message. E.g., a signal implying may be 1334 chosen if the SIP message contains the header field "Priority: 1335 urgent". 1337 In all situations, the set of signals that can be rendered and their 1338 significances may change based on user preferences and local policy. 1340 In addition, the chosen signal may change based on the status of the 1341 UA. E.g., if a call is active on the UA, all audible signals may 1342 become unavailable, or audible signals may be available only if 1343 is specified. 1345 11.2. Multi-mode Signals 1347 There are cases when the device can render two signal modes (e.g., 1348 audio and visual, or video or text) at the same time. 1350 Formally, the device must be considered as making its choice from the 1351 set of all combined signals that it can render (pairs of one signal 1352 from the first mode and one signal from the second mode), and that 1353 choice must conform to the above rules. However, it can be proven 1354 that if the device makes its rendering choice for each of the two 1355 modes independently, with each choice separately conforming to the 1356 above rules, its combined choice conforms to the above rules, when it 1357 is regarded as a choice from among all possible combinations. 1359 In such a situation, it may simplify implementation to make each 1360 choice separately. It is an implementation decision whether to chose 1361 from among combined signals, or to combine choices made from each 1362 signal mode. 1364 12. Non-normative Algorithm for Handling Combinations of URNs 1366 The following text is a non-normative example of an algorithm for 1367 handling combinations of URNs that complies with the rules in 1368 Section 10 and Section 11. Thus, it demonstrates that the rules are 1369 consistent and implementable. (Of course, a device may use any other 1370 algorithm which complies with Section 10 and Section 11.) 1372 12.1. Algorithm Description 1374 For each (feature) known by the implementation, 1375 there is a "feature tree" of the known s for that 1376 , with the sequence of s in an 1377 specifying the path in the tree from the root to 1378 the node representing the . For this description, 1379 we will name each tree and its root node by the 1380 name, and name each non-root node by the . Each 1381 URN thus corresponds to one non-root node in one feature tree. For 1382 example, there is a tree named "source", whose root node is also 1383 named "source", and which has the children source:internal, 1384 source:external, source:friend, and source:family. The URN 1385 is placed at the node "source:external" 1386 in the "source" tree. If the implementation understands 1387 , there is a node source:foo@example 1388 that is a child of node "source". If the implementation understands 1389 , there is a node 1390 source:external:bar@example that is a child of node source:external. 1391 (Of course, there are an infinite number of potential additional 1392 nodes in the tree for private values, but we don't have to represent 1393 those nodes explicitly unless the device has a signal representing 1394 the private value.) 1396 We assign similar locations to signals, but each signal has a 1397 position in *every* tree, describing the specific combination of 1398 meanings that it carries. If a signal has a simple meaning, such as 1399 "external source", its place in the "source" tree is source:external, 1400 showing that it carries the "external source" meaning, but its place 1401 in every other feature tree is at the root node, meaning that it has 1402 no particular meaning for those features. 1404 A signal that has a complex meaning may have non-root positions in 1405 more than one feature tree. For example, an "external, high 1406 priority" signal would be placed at source:external and priority:high 1407 in those trees, but be at the root in all other feature trees. 1409 In order to assure that the algorithm always selects at least one 1410 signal, we require that there is a "default" signal, whose position 1411 in every feature tree is at the root. This default signal will never 1412 be excluded from the set of acceptable signals for any set of URNs, 1413 but will be the lowest-priority signal for any set of URNs. 1415 The algorithm proceeds by considering each URN in the received Alert- 1416 Info header fields from left to right, while revising a set of 1417 signals. The set of signals starts as the entire set of signals 1418 available to the device. Each URN excludes some signals from the 1419 set, and "sorts" the signals that remain in the set according to how 1420 well they represent the URN. (The details of these operations are 1421 described below.) The first URN is the "major sort", and has the 1422 most influence on the position of a signal in the set. The second 1423 URN is a "minor sort", in that it arranges the orders of the signals 1424 that are tied within the first sort, the third URN arranges the 1425 orders of the signals that are tied within the first two sorts, etc. 1427 At the end of the algorithm, a final, "most minor" sort is done, 1428 which orders the signals which remain tied under all the sorts driven 1429 by the URNs. This final sort places the least specific signals 1430 (within their tied groups) "first". (If one signal's position in 1431 each feature tree is ancestral or the same as a second signal's 1432 position in that tree, the first signal is "less specific" than the 1433 second signal. Other cases are left to the implementation to 1434 decide.) 1436 Once all the URNs are processed and the sorting of the signals that 1437 have not been excluded is done, the device selects the first signal 1438 in the set. 1440 Here is how a single sort step proceeds, examining a single URN to 1441 modify the set of signals (by excluding some signals and further 1442 sorting the signals that remain): 1444 o The URN specifies a specific node in a specific feature tree. 1446 o All signals in the set that are, within that feature tree, 1447 positioned at the URN's node, or at an ancestor node of the URN's 1448 node, are kept. All other signals are removed from the set 1449 (because they have meanings that are incompatible with the URN's 1450 meaning). 1451 o Each group of signals that are tied under the previous sorts are 1452 further sorted into groups based on how much of the URN's meaning 1453 they represent: those which are positioned at the node of the URN 1454 are tied for first position, those which are positioned at the 1455 parent node of the URN are tied for second position, etc., and 1456 those which are positioned at the root node of the feature tree 1457 are tied for last position. 1459 12.2. Examples of How the Algorithm Works 1461 The following examples show how the algorithm described in the 1462 previous section works: 1464 12.2.1. Example 1 1466 The device has a set of 4 alerting signals. We list their primary 1467 meanings, and the locations that they are placed in the feature 1468 trees: 1470 Signal 1 1472 Meaning: external 1473 Locations: 1474 - source:external 1475 - priority (that is, the root node of the priority tree) 1477 Signal 2 1479 Meaning: internal 1480 Locations: 1481 - source:internal 1482 - priority 1484 Signal 3 1486 Meaning: low 1487 Locations: 1488 - source 1489 - priority:low 1491 Signal 4 1493 Meaning: high 1494 Locations: 1495 - source 1496 - priority:high 1498 To which we add: 1500 Signal 5 1502 Meaning: default 1503 Locations: 1504 - source 1505 - priority 1507 If the device receives , then the sort is: 1509 Signals at source:internal: (this is, first place) 1511 Signal 2: internal 1513 Signals at source: (tied for second place) 1515 Signal 3: low 1516 Signal 4: high 1517 Signal 5: default 1519 And these signals are excluded from the set: 1521 Signal 1: external 1523 So in this example, the sorting algorithm properly gives first place 1524 to Signal 2 "internal". 1526 12.2.2. Example 2 1528 Let us add to the set of signals in Example 1 ones that express 1529 combinations like "internal, high priority", but let us specifically 1530 exclude the combination "internal, low priority" so as to set up some 1531 tricky examples. This enlarges our set of signals: 1533 Signal 1 1535 Meaning: default 1536 Locations: 1537 - source 1538 - priority 1540 Signal 2 1541 Meaning: external 1542 Locations: 1543 - source:external 1544 - priority 1546 Signal 3 1548 Meaning: internal 1549 Locations: 1550 - source:internal 1551 - priority 1553 Signal 4 1555 Meaning: low 1556 Locations: 1557 - source 1558 - priority:low 1560 Signal 5 1562 Meaning: high 1563 Locations: 1564 - source 1565 - priority:high 1567 Signal 6 1569 Meaning: external high 1570 Locations: 1571 - source:external 1572 - priority:high 1574 Signal 7 1576 Meaning: external low 1577 Locations: 1578 - source:external 1579 - priority:low 1581 Signal 8 1583 Meaning: internal high 1584 Locations: 1585 - source:internal 1586 - priority:high 1588 If the device receives , then the sort is: 1590 Signals at source:internal: (that is, tied for first place) 1592 - Signal 3: internal 1593 - Signal 8: internal high 1595 Signals at source: (tied for second place) 1597 - Signal 4: low 1598 - Signal 5: high 1599 - Signal 1: default 1601 Signals excluded from the set: 1603 - Signal 2: external 1604 - Signal 7: external low 1605 - Signal 6: external high 1607 Two signals are tied for the first place, but the final sort orders 1608 them: 1610 - Signal 3: internal 1611 - Signal 8: internal high 1613 because it puts the least-specific signal first. So the Signal 3 1614 "internal" is chosen. 1616 12.2.3. Example 3 1618 The same device receives , 1619 . The first sort (due to 1620 ) is: 1622 Signals at source:external: 1624 - Signal 2: external 1625 - Signal 7: external low 1626 - Signal 6: external high 1628 Signals at source: 1630 - Signal 4: low 1631 - Signal 5: high 1632 - Signal 1: default 1634 Signals excluded: 1636 - Signal 3: internal 1637 - Signal 8: internal high 1639 The second sort (due to ) puts signals at 1640 priority:low before signals at priority, and excludes signal at 1641 priority:high: 1643 - Signal 7: external low 1644 - Signal 2: external 1645 - Signal 4: low 1646 - Signal 1: default 1648 Excluded: 1650 - Signal 6: external high 1651 - Signal 5: high 1652 - Signal 3: internal 1653 - Signal 8: internal high 1655 So, we choose Signal 7 "external low". 1657 12.2.4. Example 4 1659 Suppose the same device receives , 1660 . Note that there is no signal that 1661 corresponds to this combination. 1663 The first sort is based on source:internal, and results in this 1664 order: 1666 - Signal 3: internal 1667 - Signal 8: internal high 1668 - Signal 4: low 1669 - Signal 5: high 1670 - Signal 1: default 1672 Excluded: 1674 - Signal 2: external 1675 - Signal 7: external low 1676 - Signal 6: external high 1678 The second sort is based on priority:low, and results in this order: 1680 - Signal 3: internal 1681 - Signal 4: low 1682 - Signal 1: default 1684 Excluded: 1686 - Signal 8: internal high 1687 - Signal 5: high 1688 - Signal 7: external low 1689 - Signal 2: external 1690 - Signal 6: external high 1692 So we choose the Signal 3 "internal". 1694 Note that could not be given effect because 1695 it followed . If the two URNs had 1696 appeared in the reverse order, the Signal 2 "external" would have 1697 been chosen, because would have been given 1698 precedence. 1700 12.2.5. Example 5 1702 Let us set up a simple set of signals, with three signals giving 1703 priority: 1705 Signal 1 1707 Meaning: default 1708 Locations: 1709 - priority 1711 Signal 2 1713 Meaning: low 1714 Locations: 1715 - priority:low 1717 Signal 3 1719 Meaning: high 1720 Locations: 1721 - priority:high 1723 Notice that we've used the "default" signal to cover "normal 1724 priority". That is so the signal will cover situations where no 1725 priority URN is present, as well as the ones with 1726 . So we're deliberately failing to 1727 distinguish "priority:normal" from the default priority. 1729 If the device receives , the sort is: 1731 - Signal 2: low 1732 - Signal 1: default 1734 Excluded: 1736 - Signal 3: high 1738 and Signal 2 "low" is chosen. 1740 Similarly, if the device receives , Signal 3 1741 is chosen. 1743 If the device receives , the sort is: 1745 -Signal 1 :default 1747 Excluded: 1749 - Signal 2: low 1750 - Signal 3: high 1752 and Signal 1 "default" is chosen. 1754 If no "priority" URN is received, Signal 1 "default"will be put 1755 before Signal 2 "low" and Signal 3 " high" by the final sort, and so 1756 it will be chosen. 1758 13. User Agent Behaviour 1760 A SIP UA MAY add a URN or multiple URNs to the Alert-Info header 1761 field in a SIP request or a provisional 1xx response (excepting a 100 1762 response) when it needs to provide additional information about the 1763 call or about the provided service. 1765 Upon receiving a SIP INVITE request or a SIP provisional response 1766 with an Alert-Info header field that contains a combination of Alert- 1767 Info URNs, the User Agent (UA) attempts to match the received Alert- 1768 Info URNs combination with a signal it can render. The process the 1769 UA uses MUST conform to the rules described in Section 11. (A non- 1770 normative algorithm example for the process is described in 1771 Section 12.) 1773 The User Agent (UA) must produce a reasonable rendering regardless of 1774 the combination of URIs (of any schemes) in the Alert-Info header 1775 field: It MUST produce a rendering based on the URIs that it can 1776 understand and act on (if any), interpreted as prescribed by local 1777 policy, and ignore the other URIs. In particular, unless the 1778 containing message is a request and is immediately rejected, the UA 1779 SHOULD provide some alert unless it is instructed not to (for 1780 example, by Alert-Info URIs that it understands, the presence of a 1781 Replaces or Joins header field, local policy, or direction of the 1782 user). 1784 Subsequent provisional responses, even within the same dialog, may 1785 contain different Alert-Info header field values. The Alert-Info 1786 header field values received within different provisional responses 1787 are treated independently. If subsequent provisional responses 1788 containing different Alert-Info header field values were received 1789 within the same dialog, the User Agent SHOULD render at anytime the 1790 last received Alert-Info header field value. The handling of 1791 provisional responses containing different Alert-Info header field 1792 values which were not received within the same dialog is left as an 1793 implementation issue. 1795 14. Proxy Behaviour 1797 A SIP proxy MAY add or remove an Alert-Info header field, and MAY add 1798 or remove Alert-Info header field values, in a SIP request or a 1799 non-100 provisional response when it needs to modify the information 1800 about the call or about the provided services. 1802 There are many reasons a proxy may choose do this. For example: (1) 1803 to add indications based on information that the proxy can determine 1804 about the call, such as that it is coming from an external source, or 1805 that the INVITE contains a "Priority: urgent" header field; (2) to 1806 add indication that a particular service is being invoked at this end 1807 of the call; (3) to remove undesirable indications, such as possibly 1808 deceptive indications from untrusted sources; and (4) to remove 1809 indications that contain information that should be suppressed for 1810 privacy reasons. 1812 The following example shows a typical example of a 180 (Ringing) 1813 provisional response that has been modified by a proxy. The response 1814 sent by the UAS to the proxy was very similar, but had no Alert-Info 1815 header field. The proxy has added Alert-Info header field values 1816 specifying both a network audio resource referenced by the HTTP URI 1817 and the URN indication for the call-waiting service. This allows the 1818 UAC to render the network audio resource, or to choose a rendering 1819 based on the URN, or to perform some combination of these actions. 1820 Due to Section 10, the UAC must produce some reasonable rendering in 1821 this situation. 1823 SIP/2.0 180 (Ringing) 1824 Alert-Info: , 1825 1826 To: Bob ;tag=a6c85cf 1827 From: Alice ;tag=1928301774 1828 Call-ID: a84b4c76e66710 1829 Contact: 1830 CSeq: 314159 INVITE 1831 Via: SIP/2.0/UDP server10.biloxi.example.com; 1832 branch=z9hG4bK4b43c2ff8.1 1833 Content-Length: 0 1835 15. Internationalization Considerations 1837 The labels are protocol elements [RFC6365] and are 1838 not normally seen by users. Thus, the character set for these 1839 elements is restricted, as described in Section 7. 1841 Allowance has been made for the possibility of internationalizing 1842 s by allowing them to be A-labels: A processor that 1843 does not understand such s is required to ignore 1844 them as specified in Section 7 and Section 11.1. 1846 The URNs > select 1847 renderings that are conventional in the specified country. 1849 16. Security Considerations 1851 As an identifier, the alert URN does not appear to raise any 1852 particular security issues. The indications described by the "alert" 1853 URN are meant to be well-known. 1855 However, the provision of specific indications may raise privacy 1856 issues by revealing information about the source UA, e.g. its nature, 1857 its dialog state, or services initiated at its end of the call. 1858 E.g., call-waiting (Section 6.2.1) and call-forwarding 1859 (Section 6.2.2) services can reveal the dialog state of the UA. Such 1860 provision SHALL always require authorization on behalf of the user of 1861 the source UA (usually through accessing configured policy). 1862 Authorization SHALL NOT assume that there is any limitation of the 1863 potential recipients of the indications without obtaining specific 1864 information about the SIP transaction. 1866 Based on local policy, a UA MAY choose to ignore undesirable 1867 indications (e.g. possibly deceptive indications from untrusted 1868 sources), and MAY choose not to send indications that are otherwise 1869 valid in the context (e.g., for privacy reasons). A proxy acting on 1870 behalf of a UA MAY add or delete indications going to or from the UA 1871 for the same reasons. 1873 Since the alert indications can be sensitive, end-to-end SIP 1874 encryption mechanisms using S/MIME MAY be used to protect it. User 1875 agents that implement alert indications SHOULD also implement SIP 1876 over TLS [RFC5246] and the sips: scheme [RFC5630]. 1878 17. Acknowledgements 1880 The authors wish to thank Denis Alexeitsev, the editor of the initial 1881 draft in BLISS, Anwar Siddiqui for his contributions to the draft, 1882 Christer Holmberg for his careful review of the draft, Adam Roach, 1883 Dean Willis, Martin Huelsemann, Shida Schubert, John Elwell and Tom 1884 Taylor for their comments and suggestions and Alfred Hoenes for his 1885 extensive comments and proposals related to new namespace identifiers 1886 for URNs. 1888 18. References 1890 18.1. Normative References 1892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1893 Requirement Levels", BCP 14, RFC 2119, March 1997. 1895 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1897 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1898 A., Peterson, J., Sparks, R., Handley, M., and E. 1899 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1900 June 2002. 1902 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 1903 "Uniform Resource Names (URN) Namespace Definition 1904 Mechanisms", BCP 66, RFC 3406, October 2002. 1906 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1907 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1908 May 2008. 1910 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1911 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1913 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1914 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1916 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 1917 Initiation Protocol (SIP)", RFC 5630, October 2009. 1919 18.2. Informative References 1921 [E182] "Application of tones and recorded announcements in 1922 telephone services", 1923 http://www.itu.int/rec/T-REC-E.182-199803-I/en , . 1925 [I-D.ietf-bliss-shared-appearances] 1926 Johnston, A., Soroushnejad, M., and V. Venkataramanan, 1927 "Shared Appearances of a Session Initiation Protocol (SIP) 1928 Address of Record (AOR)", draft-ietf-bliss-shared- 1929 appearances-15 (work in progress), January 2013. 1931 [ISO3166-1] 1932 "ISO 3166-1 English country names and code elements", 1933 http://www.iso.org/iso/ 1934 english_country_names_and_code_elements , . 1936 [RFC3043] Mealling, M., "The Network Solutions Personal Internet 1937 Name (PIN): A URN Namespace for People and Organizations", 1938 RFC 3043, January 2001. 1940 [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial 1941 Standard Number) as URN (Uniform Resource Names) within an 1942 ISSN-URN Namespace", RFC 3044, January 2001. 1944 [RFC3120] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 1945 3120, June 2001. 1947 [RFC3187] Hakala, J. and H. Walravens, "Using International Standard 1948 Book Numbers as Uniform Resource Names", RFC 3187, October 1949 2001. 1951 [RFC3188] Hakala, J., "Using National Bibliography Numbers as 1952 Uniform Resource Names", RFC 3188, October 2001. 1954 [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) 1955 Namespace for the Common Language Equipment Identifier 1956 (CLEI) Code", RFC 4152, August 2005. 1958 [RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as 1959 Uniform Resource Names (URN)", RFC 4179, October 2005. 1961 [RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for 1962 the TV-Anytime Forum", RFC 4195, October 2005. 1964 [RFC4198] Tessman, D., "A Uniform Resource Name (URN) Namespace for 1965 Federated Content", RFC 4198, November 2005. 1967 [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session 1968 Initiation Protocol (SIP) Call Control - Transfer", BCP 1969 149, RFC 5589, June 2009. 1971 [RFC5890] Klensin, J., "Internationalized Domain Names for 1972 Applications (IDNA): Definitions and Document Framework", 1973 RFC 5890, August 2010. 1975 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1976 Internationalization in the IETF", BCP 166, RFC 6365, 1977 September 2011. 1979 [RFC6910] Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev, 1980 "Completion of Calls for the Session Initiation Protocol 1981 (SIP)", RFC 6910, April 2013. 1983 [TS24.615] 1984 "3GPP TS 24.615 Communication Waiting (CW) using IP 1985 Multimedia (IM) Core Network (CN) subsystem", . 1987 Authors' Addresses 1989 Laura Liess (editor) 1990 Deutsche Telekom AG 1991 Heinrich-Hertz Str 3-7 1992 Darmstadt, Hessen 64295 1993 Germany 1995 Phone: +49 6151 5812761 1996 Email: laura.liess.dt@gmail.com 1998 Roland Jesske 1999 Deutsche Telekom AG 2000 Heinrich-Hertz Str. 3-7 2001 Darmstadt, Hessen 64295 2002 Germany 2004 Phone: +49 6151 5812766 2005 Email: r.jesske@telekom.de 2007 Alan Johnston 2008 Avaya Inc. 2009 St. Louis, MO 2010 United States 2012 Email: alan.b.johnston@gmail.com 2013 Dale R. Worley 2014 Ariadne Internet Services, Inc. 2015 738 Main St. 2016 Waltham, MA 02451 2017 US 2019 Phone: +1 781 647 9199 2020 Email: worley@ariadne.com 2022 Paul Kyzivat 2023 Huawei 2024 United States 2026 Email: pkyzivat@alum.mit.edu