RFC 7462
URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
RFC 7462: URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) 🎀
okay bestie, this is RFC 7462 and it's all about making ring tones and ringback tones way more meaningful 🔔✨ it's a Standards Track doc from March 2015, published under ISSN 2070-1721 💅
- Authors: L. Liess, Ed.; R. Jesske (Deutsche Telekom AG); A. Johnston (Avaya); D. Worley (Ariadne); P. Kyzivat (Huawei) 🫶
- Category: Standards Track 🌸
- Date: March 2015 🦋
- Updates: RFC 3261 💜
- Obsoletes: nothing 🙈
this one updates RFC 3261 (the SIP base spec) normatively, so it's not just a side note, it actually changes how SIP works 👑
Abstract ✨
okay so SIP already lets you point at a specific rendering the UA (User Agent) can play as an alerting signal when the user gets alerted, like a ring tone or a ringback tone 🎶 it does this with the Alert-Info header field 💖
the problem? that reference (usually a URL) only points at one specific network resource with one specific rendering. there's no standard way to describe what the alerting situation means, or what the signal is like, without being stuck to one particular rendering 😭
so this doc defines a brand new family of URNs for use in Alert-Info header fields (and in situations with similar needs) to fix that and unlock new applications 🧚
this document normatively updates RFC 3261, which defines SIP. it changes how Alert-Info is used by letting it show up in any non-100 provisional response to INVITE 🍓 it also lets proxies add or remove an Alert-Info header field, and add or remove Alert-Info header field values 💅
Status of This Memo 🌈
this is an Internet Standards Track document, bestie 👑
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 📚
info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7462 🔗
Copyright Notice 🦋
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read these docs carefully, because they describe your rights and restrictions for this document 💖 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶
this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. the person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications of it outside the IETF Standards Process. so unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 😬 the exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍
Table of Contents 📖
1. Introduction ....................................................5
2. Requirements Language ...........................................7
3. Terminology .....................................................7
4. Updates to RFC 3261 .............................................7
4.1. Allow Alert-Info in Provisional Responses ..................7
4.2. Proxies May Alter Alert-Info Header Fields .................8
5. Requirements ....................................................8
6. Use Cases ......................................................10
6.1. PBX Ring Tones ............................................10
6.1.1. Normal .............................................10
6.1.2. External ...........................................10
6.1.3. Internal ...........................................11
6.1.4. Priority ...........................................11
6.1.5. Short ..............................................11
6.1.6. Delayed ............................................11
6.2. Service Tones .............................................11
6.2.1. Call Waiting .......................................11
6.2.2. Forward ............................................12
6.2.3. Transfer Recall ....................................12
6.2.4. Auto Callback ......................................12
6.2.5. Hold Recall ........................................12
6.3. Country-Specific Ringback Tone Indications for the
Public Switched ...........................................12
7. URN Specification for the "alert" Namespace Identifier .........12
8. "alert" URN Values .............................................18
8.1. <alert-category> Values ...................................18
8.2. <alert-indication> Values .................................18
8.2.1. <alert-indication> Values for the
<alert-category> "service" .........................19
8.2.2. <alert-indication> Values for the
<alert-category> "source" ..........................19
8.2.3. <alert-indication> Values for the
<alert-category> "priority" ........................19
8.2.4. <alert-Indication> Values for the
<alert-category> "duration" ........................20
8.2.5. <alert-indication> Values for the
<alert-category> "delay" ...........................20
8.2.6. <alert-indication> Values for the
<alert-category> "locale" ..........................20
9. IANA Considerations ............................................20
9.1. URN Namespace Identifier "alert" ..........................20
9.2. 'Alert URN Identifiers' Registry ..........................20
9.2.1. Initial IANA Registration ..........................21
9.2.1.1. The "service" <alert-category> and
<alert-identifier>s .......................22
9.2.1.2. The "source" <alert-category> and
<alert-identifier>s .......................23
9.2.1.3. The "priority" <alert-category>
and <alert-identifier>s ...................24
9.2.1.4. The "duration" <alert-category>
and <alert-identifier>s ...................24
9.2.1.5. The "delay" <alert-category> and
<alert-identifier>s .......................25
9.2.1.6. The "locale" <alert-category> and
<alert-identifier>s .......................25
9.3. 'Alert URN Providers' Registry ............................26
10. Extension Rules ...............................................26
10.1. General Extension Rules ..................................26
10.2. Private Extension Rules ..................................27
10.3. Examples .................................................28
10.3.1. Subsetting an Existing URN ........................28
10.3.2. A New Value within an <alert-category> ............29
10.3.3. A New <alert-category> ............................29
10.3.4. Subsetting a Private Extension URN ................29
11. Combinations of "alert" URNs ..................................30
11.1. Priority Rules ...........................................30
11.2. Multi-mode Signals .......................................31
12. Non-normative Algorithm for Handling Combinations of URNs .....32
12.1. Algorithm Description ....................................32
12.2. Examples of How the Algorithm Works ......................34
12.2.1. Example 1 .........................................34
12.2.2. Example 2 .........................................35
12.2.3. Example 3 .........................................37
12.2.4. Example 4 .........................................38
12.2.5. Example 5 .........................................39
13. User Agent Behaviour ..........................................40
14. Proxy Behaviour ...............................................41
15. Internationalization Considerations ...........................42
16. Security Considerations .......................................42
17. References ....................................................43
17.1. Normative References .....................................43
17.2. Informative References ...................................44
Acknowledgements ..................................................45
Authors' Addresses ................................................461. Introduction ✨
Okay so, SIP ([RFC3261]) has this really cute feature where you can suggest a ringback tone or ring tone to a User Agent (UA) while a call is getting set up 📞🎀. In [RFC3261] you do it by putting a URI in the Alert-Info header field that points to the tone. Most of the time that URI is an HTTP URL to an audio file 🎧. When the UA gets the Alert-Info header field, it may fetch the referenced ringback tone or ring tone and play it to the user 🔊.
But bestie, this is where it gets messy 😭. This setup breaks interoperability when nobody agrees on what the tone means, and that meaning can be country-specific or vendor-specific 🌍. The user can struggle to figure out what the tone is supposed to say, and the UA can't easily swap in its own tone (say, one that matches the user's preferences) or offer a different way to alert the user, like for deaf and hard-of-hearing folks 🫶. If the caller and callee are in different countries, they might hear the tones totally differently 🙈. Deaf or hard-of-hearing users may not even pick up on a tone if it's only shared as an audio file 🥺. And honestly? The tone itself is useless to machines 🤖.
Another problem with audio file URLs is that the tones get locked to one specific rendering 💅. There's no way to say what the alert means and then let the receiving UA pick the actual alert (a tone, a vibration, a visual display, whatever) to signal it 📳. There's also no way to ask for particular rendering features, like a short duration, a delay, or country-specific conventions ⏱️.
You'd think fixed URLs with set meanings would fix this, and they help, but they bring their own interoperability drama 💀. Take the Private Branch Exchange (PBX) special ring tone for a caller from outside the PBX. Different vendors do it all different ways, like:
Alert-Info: <file://ring.pcm>;alert=externalwhere ring.pcm is a dummy file name, or:
Alert-Info: <file://external.ring.pcm>Alert-Info: <sip:external-ringtone@example.com>So right now the Alert-Info header field only works when the same vendor makes both the PBX and the UA, and even then only if they're using the same made-up proprietary URI convention 🙃.
To fix all of this, this specification defines a new URN namespace "alert" for the SIP Alert-Info header field 🎉. It lets UIs adapt programmatically and lets equivalent alerting tones get converted in the Public Switched Telephone Network (PSTN) when the client is a gateway 🌉. Standardizing an "alert" URN means SIP interoperability for this header field gets a major glow-up, and all those proprietary conventions can finally retire 👑.
The "alert" namespace gives you a syntax for a bunch of different application spaces, like:
- Names for service indications, such as call waiting or automatic callback, not tied to any particular rendering.
- Names for common ring tones generated by PBX phones for cases such as an internal enterprise caller, external caller, ringback tone after a transfer failure or expiration of a hold timer, etc.
- Names for country-specific ringback tones.
- Names for things with specific renderings that aren't purely audio. They might be static icons, video sequences, text, etc.
Why a URN instead of a URL to a downloadable resource? Because it's giving advantages 🦋:
- There is no need to download it or deal with security issues associated with dereferencing.
- There are no formatting or compatibility issues.
- There is no security risk of rendering something unexpected and undesirable.
- The tone can be stored locally in whatever format and at whatever quality level is appropriate, because it is specified "by name" rather than "by value".
- It is easier to make policy decisions about whether or not to use it.
- It facilitates translation for the deaf and hard of hearing.
The one downside 😬: if the recipient doesn't understand the URN, it can only render a default ringback tone or ring tone. Still, that's a pretty chill fallback 🌸.
This document creates a new URN namespace and registry for alert indications and registers some initial values 📚.
In practice, this specification extends how the Alert-Info header field gets used. It brings in a new class of URIs and allows multiple URIs 🌈. Backward compatibility issues aren't expected, since devices that don't understand an "alert" URN should ignore it, and devices should not malfunction when they get multiple Alert-Info header field values (<alert-param>s in [RFC3261]). That was syntactically allowed before too, it just was rarely used 🤷♀️.
2. Requirements Language 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖.
3. Terminology 🧠
This specification uses a bunch of terms for the roles involved when alerting indications are used in SIP 🎭. A "specifier" sends an "alerting indication" (one or more URNs in an Alert-Info header field) to a "renderer". The renderer then "renders" a "signal" or "rendering" based on the indication for a human user 🫧. A "category" is a characteristic whose "values" can be used to classify indications 🗂️.
This specification uses the terms "ring tone" and "ringback tone" 📞. A "ring tone" or "calling signal" (terminology used in [E182]) is a signal generated by the callee's end device, letting the callee know about an incoming call 🔔. A "ringback tone" or "ringing tone" (terminology used in [E182]) is a signal that tells the caller a connection has been made and that a ring tone is being rendered to the callee 💖.
4. Updates to RFC 3261 🎀
4.1. Allow Alert-Info in Provisional Responses
This specification changes how the Alert-Info header field defined in [RFC3261] gets used, by also allowing it in any non-100 provisional response to INVITE 🦋.
Before this, the Alert-Info header field was only allowed in 180 (Ringing) responses. But in telephony, other situations that SIP provisional responses signal, like 181 (Call Is Being Forwarded) and 182 (Call Is Being Queued), are often indicated with tones 🎶. Widening where Alert-Info can show up lets SIP do what telephony already does ✨.
To support this change, the following paragraph replaces the the first paragraph of Section 20.4 of [RFC3261] 📝:
When present in an INVITE request, the Alert-Info header field
specifies an alternative ring tone to the User Agent Server (UAS).
When present in a non-100 provisional response, the Alert-Info
header field specifies an alternative ringback tone to the UAC. A
typical usage is for a proxy to insert this header field to
provide a distinctive ring feature.4.2. Proxies May Alter Alert-Info Header Fields 🔥
A SIP proxy MAY add or remove an Alert-Info header field, and it MAY add or remove Alert-Info header field values, in a SIP request or a non-100 provisional response 🧚.
5. Requirements ✨
okay so this section is basically the wishlist 💖 It talks about what the alerting indication needs to be able to do, what it's supposed to carry, and what it's supposed to avoid. Here's the full list, bestie 🎀
REQ-1: The mechanism will allow UAs and proxies to provide in the Alert-Info header field an alerting indication that describes the semantics of the signaling situation or the characteristics of the rendering, and allows the recipient to decide how to render the received information to the user. 🦋
REQ-2: The mechanism will allow the alerting indication to be specified "by name" rather than "by value," so local policy can decide whether or not to use it. 💅
REQ-3: The mechanism will enable alerting indications to represent a wide variety of signals, which have many largely orthogonal characteristics. ✨
REQ-4: The mechanism will enable the set of alerting indications to support extensibility by a wide variety of organizations that are not coordinated with each other. Extensions will be able to:
- add further values to any existing category
- add further categories that are orthogonal to existing categories
- semantically subdivide the meaning provided by any existing indication
It's giving "anyone can join the party" energy 🎉
REQ-5: The mechanism will be flexible, so new alerting indications can be defined in the future, when SIP-applications evolve. For example, "alert" URNs could identify specific media by name, such as "Beethoven's Fifth," and the end device could render some small part of it as a ring tone. 🎶 Iconic.
REQ-6: The mechanism will provide only an indication capability, not a negotiation capability. 🙅♀️
REQ-7: The mechanism will not require an alerting indication to depend on context provided by a previous alerting indication in either direction. 🌸
REQ-8: The mechanism will allow transmission in the Alert-Info header field of SIP INVITE requests and provisional 1xx responses excepting the 100 responses. 📞
REQ-9: The mechanism will be able to accommodate both renderers that are customized with a limited or uncommon set of signals that they can render, and renderers that are provided with a set of signals that have uncommon semantics. (The canonical example is a UA for the deaf and hard of hearing, customized with an alternative set of signals, video or text instead of audio. By REQ-6, the renderer has no way of transmitting this fact to the specifier.) 🫶 This one is so important, and the way it connects to REQ-6 is lowkey genius.
REQ-10: The mechanism will allow an alerting indication to reliably carry all extensions if the specifier and the renderer have designs that are properly coordinated. 🧚
REQ-11: The mechanism will allow a renderer to select a tone that approximates to that intended by the specifier if the renderer is unable to provide the precise tone indicated. 🎵
REQ-12: The mechanism will support alerting indications relating to services such as call waiting, call forwarding, transfer recall, auto callback, and hold recall. 📲
REQ-13: The mechanism will allow rendering common PBX ring tone types. ☎️
REQ-14: The mechanism will allow rendering specific country ringback tones. 🌍
REQ-15: The mechanism will allow rendering tones for emergency alerts. (Use cases and definitions of URN values for emergency calls are not a subject of this specification.) 🚨
REQ-16: The mechanism will allow rendering using other means than tones, e.g., text or images. 🖼️
REQ-17: The mechanism will allow PSTN gateways to map ring/ringback tones from legacy protocols to SIP at the edge of a network, e.g., national ring tones as defined in TIA/EIA-41-D and 3GPP2 A.S0014. (Use cases and values definition for this situation are not a subject of this specification.) 🌉
REQ-18: The mechanism will ensure that if an UA receives "alert" URNs or portions of an "alert" URN it does not understand, it can ignore them. 🙈 No drama, just ignore it and move on.
REQ-19: The mechanism will allow storage of the actual encoding of the rendering locally rather than fetching it. 💾
REQ-20: The mechanism must provide a simple way to combine two or more alerting indications to produce an alerting indication that requests a combination of the intentions of the two alerting indications, where any contradictions or conflicts between the two alerting indications are resolved in favor of the intention of the first alerting indication. 👑 The first one always wins, periodt.
6. Use Cases
This section describes some use cases for which the "alert" URN mechanism is needed today. 💜
6.1. PBX Ring Tones
This section defines some commonly encountered ring tones on PBX or business phones. They are as listed in the following subsections. 📞
6.1.1. Normal
This tone indicates that the default or normal ring tone should be rendered. It's essentially a no-operation "alert" URN, and it should be treated by the UA as if no "alert" URN is present. This is most useful when Alert-Info header field parameters are being used. For example, in [RFC7463], an Alert-Info header field needs to be present containing the "appearance" parameter, but no special ring tone needs to be specified. 😌 Basically, "do nothing, but still show up."
6.1.2. External
This tone is used to indicate that the caller is external to the enterprise or PBX system. This could be a call from the PSTN or from a SIP trunk. 🌐
6.1.3. Internal
This tone is used to indicate that the caller is internal to the enterprise or PBX system. The call could have been originated from another user on this PBX or on another PBX within the enterprise. 🏢
6.1.4. Priority
A PBX tone needs to indicate that a priority level alert should be applied for the type of alerting specified (e.g., internal alerting). 🚩
6.1.5. Short
In this case, the alerting type specified (e.g., internal alerting) should be rendered shorter than normal. In contact centers, this is sometimes referred to as "abbreviated ringing" or a "zip tone." ⚡
6.1.6. Delayed
In this case, the alerting type specified should be rendered after a short delay. In some bridged-line/shared-line-appearance implementations, this is used so that the bridged line does not ring at exactly the same time as the main line but is delayed a few seconds. ⏳ Bridged lines get a little beat of suspense, slay.
6.2. Service Tones
These tones are used to indicate specific PBX and public network telephony services. 🛎️
6.2.1. Call Waiting
The call-waiting service [TS24.615] permits a callee to be notified of an incoming call while the callee is engaged in an active or held call. Subsequently, the callee can either accept, reject, or ignore the incoming call. There is an interest on the caller side to be informed about the call-waiting situation on the callee side. Having this information, the caller can decide whether to continue waiting for the callee to pick up, or better to call some time later when it is estimated that the callee could have finished the ongoing conversation. To provide this information, a callee's UA (or proxy) that is aware of the call-waiting condition can add the call-waiting indication to the Alert-Info header field in the 180 (Ringing) response. 📵 The caller gets the tea before they even hit redial.
6.2.2. Forward
This feature is used in a 180 (Ringing) response when a call forwarding feature has been initiated on an INVITE. Many PBX systems implement a forwarding "beep" followed by normal ringing to indicate this. Note that a 181 response can be used in place of this URN. ↪️
6.2.3. Transfer Recall
This feature is used when a blind transfer [RFC5589] has been performed by a server on behalf of the transferor and fails. Instead of failing the call, the server calls back the transferor, giving them another chance to transfer or otherwise deal with the call. This service tone is used to distinguish this INVITE from a normal incoming call. 🔁
6.2.4. Auto Callback
This feature is used when a user has utilized a server to implement an automatic callback service [RFC6910]. When the user is available, the server calls back the user and utilizes this service tone to distinguish this INVITE from a normal incoming call. 🔔
6.2.5. Hold Recall
This feature is used when a server implements a call hold timer on behalf of an endpoint. After a certain period of time of being on hold, the user who placed the call on hold is alerted to either retrieve the call or otherwise dispose of the call. This service tone is used to distinguish this case from a normal incoming call. ⌛ Don't leave people on hold forever, that's just rude 💀
6.3. Country-Specific Ringback Tone Indications for the Public Switched Telephone Network
In the PSTN, different tones are used in different countries. End users are accustomed to hearing the callee's country ringback tone, and they would like to have this feature for SIP. 🇺🇳 Honestly the nostalgia is real 🥹
7. URN Specification for the "alert" Namespace Identifier ✨
This section provides the registration template for the "alert" URN namespace identifier (NID) according to [RFC2141] and [RFC3406]. 📝 Here's the official paperwork, bestie.
Namespace ID: alert
Registration Information:
Registration version: 1
Registration date: 2014-12-10
Declared registrant of the namespace:
Registering organization: Real-time Applications and
Infrastructure Area, IETF
Designated contact: RAI Area Director
Designated contact email: rai-ads@ietf.orgOkay so the NSS for "alert" URNs is called an <alert-identifier>, and it has a hierarchy. The first colon-separated part after "alert" is the <alert-category>. The parts to the right of that are <alert-ind-part>s, and together they form the <alert-indication>. The general form looks like urn:alert:<alert-category>:<alert-indication>. 🌈
The following <alert-category> identifiers are defined in this document: "service", "priority", "source", "duration", "delay", and "locale". The <alert-category> set can be extended in the future, either by standardization or by private action. The <alert-category>s describe distinct features of alerting signals. 💅
Any "alert" URN defined in this specification is syntactically valid for ring and ringback tones, and it can be used in SIP INVITE requests or in provisional 1xx responses excepting the 100 response. 📞
The ABNF [RFC5234] for the "alert" URNs is shown below:
alert-URN = "urn:alert:" alert-identifier
alert-identifier = alert-category ":" alert-indication
alert-category = alert-name
alert-indication = alert-ind-part *(":" alert-ind-part)
alert-ind-part = alert-name
alert-name = alert-label / private-name
private-name = alert-label "@" provider
provider = alert-label
alert-label = let-dig [ *let-dig-hyp let-dig ]
let-dig-hyp = let-dig / "-"
let-dig = ALPHA / DIGIT
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9<alert-label>s MUST comply with the syntax for Non-Reserved LDH labels [RFC5890]. Registered URNs and components thereof MUST be transmitted as registered (including case). 🫶 Case matters here, so don't get creative with the capitals.
Relevant ancillary documentation: RFC 7462 🎀
Namespace considerations: okay so this spec makes a URN namespace called "alert" 🔔 for URNs that stand for signals or renderings that get shown to users to tell them about events and actions. The first job is ring tones and ringback tones when dialogs get set up in SIP, but it's also fine for other call-setup protocols (like H.323), and honestly for any situation at all (web pages, endpoint device software configs) that needs to describe how a user should get signaled 💅
An "alert" URN doesn't describe a whole signal on its own. It describes one specific trait of the event it's signaling, or one feature of the signal you're gonna play. The full signal is a sequence of "alert" URNs listed in priority order, with the most important stuff up front 🥹 This is so good because the sender can build super detailed specs from a small set of URNs, and clearly show which parts matter most. Main character energy ✨
The initial use is the Alert-Info header field 📨 in initial INVITE requests (to say how the called user should be alerted about the call), and in non-100 provisional (1xx) responses to those INVITE requests (to say which ringback to use, and how the calling user should be alerted about how the call is going) 📞
Now the big deal: to get everyone to actually adopt these URNs for ring tones and ringback tones, the scheme has to let people reproduce the current variety of these tones 🌈 Right now they change between the PSTNs of different countries and between equipment from different vendors. So the scheme has to handle national variations and proprietary extensions in a way that keeps as much info as possible when systems with different national variations or different vendors talk to each other 🫶
The scheme lets you define private extension URNs that refine and extend the info from standard URNs. Private extension URNs can also refine and extend other private extension URNs 🧚 Private extensions can even define brand new categories of info about calls. Expect these to get used a LOT when existing PBX products get converted to support SIP operation 💖
The device that gets an Alert-Info header field with a sequence of "alert" URNs gives the user a rendering that represents the semantic content of those URNs. The device gets a lot of freedom in picking the rendering, but it's boxed in by rules that maximize interoperability between systems that support different sets of private extensions. Specifically, earlier URNs in the sequence win over later ones, and URNs that can't be used in full (because they have unknown extensions or clash with earlier URNs) get trimmed down, one step at a time, until you get a URN that keeps some info and can be rendered in context 🔥
Private extensions matter a ton for adoption of URNs for alerting calls, and they come with very specific rules and processing rules that make high-quality interoperation possible even with private extensions around. Because of that, the needs of the "alert" URN scheme can't be met with a fixed list of URNs and their meanings 😭 In particular, the existing namespace "urn:ietf:params" isn't enough (unless the private extension setup is applied to that namespace too).
Nothing else seems to exist that uniquely identifies the meaning of a signal or rendering feature. Unlike most other registered URN namespaces, the "alert" URN doesn't identify documents and protocol objects (like [RFC3044], [RFC3120], [RFC3187], [RFC3188], [RFC4179], [RFC4195], [RFC4198]), types of telecom equipment [RFC4152], people, or organizations [RFC3043] 🙈
The <alert-URN>s are hierarchical identifiers. An <alert-URN> asserts some fact or feature of the offered SIP dialog, or some fact or feature of how it should be presented to a user, or of how it's currently being presented to a user 🦋 Chopping an <alert-ind-part> off the end of an <alert-URN> (one that has more than one <alert-ind-part>) gives you a shorter <alert-URN> with a less specific meaning. The set of dialogs the longer <alert-URN> applies to is always a subset of the set the shorter one applies to. (If the starting <alert-URN> only has one <alert-ind-part>, so it can't be shortened, then the set of dialogs it applies to counts as a subset of all dialogs.) 🍓
The specific criteria that pick out the subset the longer <alert-URN> applies to, inside the bigger set of dialogs, is the meaning of the final <alert-ind-part>. That meaning is relative to, and depends on, the <alert-category> and <alert-ind-part>s that come before it (if there are any). Two <alert-ind-part>s that are spelled the same but come after different <alert-category>s or <alert-ind-part>s have no necessary connection at all. (An <alert-category> on its own has no meaning in this sense.) 💅
The organization that owns the <provider> in a <private-name> decides what that <private-name> means when it's used as an <alert-ind-part>. (Which organization owns a <provider> is recorded in the registry described in Section 9.3.) ✨
The organization that owns the <provider> in a <private-name> (whether that's in an <alert-category> or an <alert-ind-part>) decides the meaning of each <alert-ind-part> that's an <alert-label> following that <private-name> and coming before the next <alert-ind-part> that's a <private-name> (if there is one) 🌸
The meaning of every other <alert-ind-part> (the ones that aren't <private-name>s and don't follow a <private-name>) is defined by standardization 🎀
Community considerations: the "alert" URNs matter to a huge cross-section of internet users, namely everyone who starts and receives calls over the Session Initiation Protocol 📞 That includes both technical and non-technical people, on all kinds of devices, with all kinds of ways of perceiving things 🫶 The "alert" URNs will let users get more info about offered calls, help them decide whether to accept an offered call, and give them better feedback on how a call they placed is progressing 🔥
User interfaces that use alternative sensory modes can do a better job rendering ring and ringback tones based on "alert" URNs, because the URNs give more detailed info about what the communication is for than current SIP mechanisms do 🦋
Process of identifier assignment:
Standardized "alert" URNs get assigned by inserting them into the IANA registry described in Section 9.2. This process defines the meanings of the <alert-ind-part>s that have standardized meanings, as described in "Namespace Considerations" 📝
A new URN MUST NOT be registered if it's equal, by the comparison rules, to a URN that's already registered 🚫
Private extensions are "alert" URNs that include <alert-ind-part>s that are <private-name>s, and <alert-label>s that show up after a <private-name> (either as an <alert-category> or an <alert-indication>). If an <alert-ind-part> is a <private-name>, its meaning is defined by the organization that owns the <provider> in that <private-name>. If the <alert-ind-part> is an <alert-label>, its meaning is defined by the organization that owns the <provider> in the closest <private-name> before that <alert-label>. The organization that owns a <provider> is specified by the registry described in Section 9.3 🧚
Identifier uniqueness and persistence considerations: an "alert" URN identifies a semantic feature of a call, or a sensory feature of how the call alerting should be rendered on the caller's or callee's end device 💜
For standardized <alert-ind-part>s in URNs, uniqueness and persistence of their meanings is guaranteed by the fact that they're registered with IANA under the procedures of Section 9.2. The feature identified by a particular "alert" URN is distinct from the feature identified by any other standardized "alert" URN 👑
Making sure private extensions stay unique and persistent is delegated to the organizations that define private extension <alert-ind-part>s. The organization responsible for a particular <alert-ind-part> in a particular "alert" URN is the owner of the syntactically determined <provider> part of that URN 🌈
An organization SHOULD use only one <provider> value for all of the <private-name>s it defines. 🍓
Process for identifier resolution: this is the process where a rendering device picks a rendering to represent a sequence of "alert" URNs. The device gets a lot of leeway in making that choice, but the process MUST obey the rules of Section 11.1. The device is expected to provide renderings that users associate with the meanings assigned to the URNs within their cultural context. A non-normative example resolution algorithm is given in Section 12.1 🎀
Rules for lexical equivalence: "alert" URNs are compared using case-insensitive string equality 🔤
Conformance with URN syntax: all "alert" URNs must conform to the ABNF in the "Declaration of Syntactic Structure" in Section 7. That ABNF is a subset of the generic URN syntax [RFC2141]. <alert-label>s are constrained to be Non-Reserved LDH labels [RFC5890], meaning "ordinary ASCII labels" 🔠 Future standardization may allow <alert-label>s that are A-labels [RFC5890], so interpreters of "alert" URNs MUST operate correctly (per Section 11.1) when they're given such URNs as input 💅
Validation mechanism: an "alert" URN with no private extensions can be validated based on the IANA registry of standardized "alert" URNs. Validating an "alert" URN that does contain private extensions requires getting info about the private extensions defined by the organization that owns the <provider> in the relevant <private-name>. You can find out who that organization is from the IANA registry described in Section 9.2. However, if an "alert" URN contains at least one <alert-identifier> that comes before the first <private-name>, the part of the "alert" URN that comes before the first <private-name> must itself be a valid standardized "alert" URN, which may be validated as above 🔍
Scope: the scope for this URN is public and global 🌍
8. "alert" URN Values ✨
8.1. <alert-category> Values ✨
okay so the <alert-category> values defined in this doc are these six 💅
service
source
priority
duration
delay
locale8.2. <alert-indication> Values 🎀
this section is the lineup of "alert" URN indication values for each <alert-category> we defined 🦋
every <alert-category> has a default <alert-indication>, and it's basically a no-op "alert" URN. the UA should treat it like there's no "alert" URN for that category at all 🫶 defaults are most useful when Alert-Info header field parameters are in play. like in [RFC7463], the Alert-Info header field has to show up with the "appearance" parameter, but nobody needs to pick a special ringtone 💜
the <private-name> syntax is for extensions from independent organizations, as described in Section 10.2 🌸
8.2.1. <alert-indication> Values for the <alert-category> "service" 📞
- normal (default)
- call-waiting
- forward
- recall:callback
- recall:hold
- recall:transfer
- <private-name>
examples: <urn:alert:service:call-waiting> or <urn:alert:service:recall:transfer> 💖
8.2.2. <alert-indication> Values for the <alert-category> "source" 👀
- unclassified (default)
- internal
- external
- friend
- family
- <private-name>
(ngl these <alert-indication>s are rarely sent by the UA itself. usually a proxy adds them for the recipient UA so it knows where the call is coming from 🙈)
examples: <urn:alert:source:external> ✨
8.2.3. <alert-indication> Values for the <alert-category> "priority" 🔥
- normal (default)
- low
- high
- <private-name>
examples: <urn:alert:priority:high> 👑
8.2.4. <alert-Indication> Values for the <alert-category> "duration" ⏱️
- normal (default)
- short
- long
- <private-name>
examples: <urn:alert:duration:short> 🌈
8.2.5. <alert-indication> Values for the <alert-category> "delay" 🧚
- none (default)
- yes
- <private-name>
examples: <urn:alert:delay:yes> ⭐
8.2.6. <alert-indication> Values for the <alert-category> "locale" 🌍
- default (default)
- country:<ISO 3166-1 country code>
- <private-name>
the ISO 3166-1 country code [ISO3166-1] tells the renderer on the other end of the call to use a country-specific rendering 🍓 for example, if you want ringback tones from South Africa, you'd use this URN: <urn:alert:locale:country:za> 🇿🇦✨
9. IANA Considerations 🌸
9.1. URN Namespace Identifier "alert" 🦋
this section registers a brand new URN namespace identifier (NID), "alert", following [RFC3406] and using the registration template from Section 7 💜
9.2. 'Alert URN Identifiers' Registry 📚
standard "alert" URNs get recorded as <alert-identifier>s in a new registry called "Alert URN Identifiers". so making a new standard "alert" URN means IANA has to do something 🫶 IANA manages this registry under the 'Specification Required' policy [RFC5226], following the guidelines in Section 10.1 💅
the registry has entries in these formats:
<alert-category>/ Reference Description
<alert-identifier>
---------------------------------------------------------------
foo [RFCxyz] Description of the 'foo'
<alert-category>;
foo:bar [RFCabc] Description of the 'foo:bar'
<alert-identifier>
foo:<range> [RFCdef] Description of the
'foo:<category>' <alert-identifer>s (which will
reference the <range> value)the first value in each row is the one that gets registered 💖 it's one of three things: (1) an <alert-category> value, (2) an <alert-identifier> value, made of an <alert-category> followed by an <alert-indication>, which is made of one or more <alert-label>s, or (3) a pattern for <alert-identifier> values (like the "locale" <alert-category> in Section 9.2.1.6) 🧚
the second value in each row is the reference to the required specification for that value 📎
the third value is a short description of what the value means 🎀
a new URN MUST NOT be registered if it's equal, using the comparison rules (that's case-insensitive string comparison), to a URN that's already registered. no dupes, bestie 🙅♀️
<alert-category> and <alert-identifier> values that contain <private-name>s aren't managed by IANA 🌈 how those get assigned is described in Section 10.2 ✨
9.2.1. Initial IANA Registration 🍓
this document defines the <alert-category>s 'service', 'source', 'priority', 'duration', 'delay' and 'locale' 👑 the entries to add to the 'Alert URN Identifiers' registry table for each <alert-category> are in the sections below 💅
9.2.1.1. The "service" <alert-category> and <alert-identifier>s 📞
here's the initial IANA registration for "service" and its <alert-identifier>s. this indicator is set to something other than "normal" when the caller or callee is told that a specific telephony service has been started 🦋
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
service RFC 7462 Specific telephony
service used in this
call
service:normal RFC 7462 Normal ring/ringback
rendering (default value)
service:call-waiting RFC 7462 Call waiting was
initiated at the other side
of the call
service:forward RFC 7462 Call has been forwarded
service:recall:callback RFC 7462 Recall due to callback
service:recall:hold RFC 7462 Recall due to call hold
service:recall:transfer RFC 7462 Recall due to transfer9.2.1.2. The "source" <alert-category> and <alert-identifier>s 👀
here's the initial IANA registration for "source" and its <alert-identifier>s. this indicator tells you about the user on the other side of the call 💜
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
source RFC 7462 Classification
of the other party
to the call
source:unclassified RFC 7462 Unclassified ring/ringback
rendering (default value)
source:internal RFC 7462 User at the other side of
the call is internal to the
enterprise or PBX system
source:external RFC 7462 User at the other side of
the call is external to the
enterprise or PBX system
source:friend RFC 7462 User at the other side of
the call is a friend
source:family RFC 7462 User at the other side of
the call is a family member9.2.1.3. The "priority" <alert-category> and <alert-identifier>s 🔥
here's the initial IANA registration for "priority" and its <alert-identifier>s. this indicator tells the alerted user how much priority to give the call 👑
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
priority RFC 7462 Priority of the
call
priority:normal RFC 7462 Normal ring/ringback
rendering (default value)
priority:low RFC 7462 Low priority call
priority:high RFC 7462 High priority call9.2.1.4. The "duration" <alert-category> and <alert-identifier>s ⏱️
here's the initial IANA registration for "duration" and its <alert-identifier>s. this indicator tells you how long the alerting signals are compared to the default ones 🌈
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
duration RFC 7462 Duration of alerting signal
duration:normal RFC 7462 Normal ring/ringback
rendering (default value)
duration:short RFC 7462 Shorter than normal
duration:long RFC 7462 Longer than normal9.2.1.5. The "delay" <alert-category> and <alert-identifier>s 🧚
here's the initial IANA registration for "delay" and its <alert-identifier>s. this indicator says whether the alerting signal should be presented later than the default presentation process 🦋 for more details see Section 6.1.6 ✨
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
delay RFC 7462 Delay of rendering
of alerting signal
delay:none RFC 7462 Immediate alerting
(default value)
delay:yes RFC 7462 Delayed alerting9.2.1.6. The "locale" <alert-category> and <alert-identifier>s 🌍
here's the initial IANA registration for "locale" and its <alert-identifier>s. this indicator says whether the alerting signals that are typical for the specified location should be used 🍓
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
locale RFC 7462 Location-specific
alerting signals
locale:default RFC 7462 Alerting not location
specific
(default value)
locale:country:<ISO 3166-1 country code>
RFC 7462 Alerting according to the
conventions of the specified
country9.3. 'Alert URN Providers' Registry ✨
Okay bestie, the <provider> values (the ones used to build <private-name>s) get their own brand-new registry called "Alert URN Providers" 🎀. Private extension "alert" URNs that get defined are NOT recorded by IANA, just so you know 💅. IANA runs the registry under the 'First Come First Served' policy [RFC5226] 🌸.
Entries look like this:
<provider> Registrant Contact URI
---------------------------------------------------------------------
example IETF rai-ads@ietf.orgThe first column is the <provider> value being registered. It's case-insensitive and MUST comply with the syntax for Non-Reserved LDH labels [RFC5890] 🔥.
The second column is the registrant's name, and the third is a contact URI for that registrant 🫶.
The registry starts out with just that one example entry, which is there so you can make example private extension URNs 🧚.
10. Extension Rules 👑
10.1. General Extension Rules 🦋
The set of "alert" URNs is extensible, so it can grow! An extension "at the top level" creates a new <alert-category> (a new alerting characteristic). An extension "at the second level" creates a new <alert-indication> value for an existing <alert-category>. An extension "at the third level" makes a subdivision of an existing <alert-indication> (one that has one <alert-ind-part>), and so on. In principle, URNs allow indefinite subdivision of existing <alert-indication> values 🌈. In practice, most of the standard "alert" URNs only have one level of subdivision, and a few have two.
Extensions, standard or private, MUST conform to the following principles 📝:
- A new
<alert-category>is independent of all previously existing<alert-category>s: For any combination of one<alert-identifier>in the new<alert-category>with any one<alert-identifier>in any of the previously existing<alert-category>s, there are potential calls to which the combination can be meaningfully applied. - A new
<alert-identifier>that has more than one<alert-ind-part>is a semantic refinement of a parent<alert-identifier>, with the parent found by deleting the final<alert-ind-part>. The new<alert-identifier>has as its parent the most specific previously existing<alert-identifier>whose meaning includes all potential calls to which the new<alert-identifier>could be meaningfully applied. - A new
<alert-identifier>has no semantic overlap with any sibling<alert-identifier>(<alert-identifier>s that differ only in the final<alert-ind-part>). That is, there could be no call to which both<alert-identifier>s could be meaningfully applied.
Standard "alert" URN definitions go through the process described in Section 9.2, and all of them require registering a publicly available specification 📜. Private extensions go through the process described in Section 10.2 🔐.
10.2. Private Extension Rules 🔐
The <private-name> syntax is how you make private extensions, which are extensions that are NOT registered with IANA 🙈. A <private-name> looks like an <alert-label> followed by "@" and then a <provider> that names the organization defining the extension. Both <alert-label> and <provider> use the same syntax as an ordinary ASCII DNS label. You make a private extension URN by using a <private-name> as either an <alert-category> or an <alert-ind-part> 💖.
If a <private-name> is used as an <alert-category>, the organization defines the characteristic of the alerting signal that the <alert-category> describes. If it's used as the first <alert-ind-part>, the organization defines an alternative value for the standardized <alert-category> of the URN. If it's used as the second or a later <alert-ind-part>, the organization defines the meaning of the URN as a subset of the meaning of the shorter URN you get when that <private-name> (and any subsequent <alert-ind-part>s) is removed 🍓.
Inside a URN, all <alert-label> components that come after a <private-name> but before any following <private-name>s are additional private extensions. Their meaning is defined by the organization that defined the nearest preceding <private-name> ✨.
A URN that already contains a private extension can be subdivided further by another organization's private extension. The second organization appends an <alert-ind-part> that is a <private-name> containing a the <provider> value for the second organization 🌸.
The meaning of a <private-name> or an <alert-label> that's defined privately (because of a preceding <private-name>) is only fixed within the context given by the sequence of preceding <alert-name>s. These components have no meaning on their own. There's also no necessary relationship between the meaning of textually identical <alert-name>s that are preceded by different sequences of <alert-name>s 🤷♀️.
Creating private extension "alert" URNs is not a Standards Action, and they are not registered with IANA 💅.
The organization that defines a private extension is responsible for making sure the meaning of that extension persists 👑.
Private extensions MUST conform to the principles of Section 10.1, both with regard to previously existing standard <alert-URN>s and with regard to any previously existing private extensions using the same <provider> value, plus any other private extensions the organization is aware of. In particular, a private extension MUST NOT duplicate any standard URN or any private extension that the organization is aware of. (In either of those cases, the organization MUST use the existing URN for its purposes.) 🚫
An organization gets a <provider> value for building <private-name>s by registering that value with IANA, as described in Section 9.3 🎀.
10.3. Examples 🧁
10.3.1. Subsetting an Existing URN
The organization registering the <provider> "example" can define distinctive versions of <urn:alert:service:call-waiting>:
urn:alert:service:call-waiting:abc@example
urn:alert:service:call-waiting:def@exampleIt can also create a more specialized URN that applies to a subset of the situations the first URN above applies to:
urn:alert:service:call-waiting:abc@example:xyzBecause "xyz" follows "abc@example" (with no intervening <private-name>), its meaning is defined by the owner of the <provider> "example" 💜.
10.3.2. A New Value within an <alert-category>
The organization registering the <provider> "example" can define URNs in the "service" category to express a new service that isn't covered by any of the standardized URNs 🌈:
urn:alert:service:ghi@exampleHowever, before defining a URN like that, the organization should verify that the set of calls the URN applies to is not a subset of the set of calls for some existing URN. If it IS a subset, the extension URN should be a subdivision of the existing URN 🤓.
10.3.3. A New <alert-category>
The organization registering the <provider> "example" can define an extension <alert-category> named "jkl@example" with two <alert-indication>s, "a1" and "a2" 🦋:
urn:alert:jkl@example:a1
urn:alert:jkl@example:a210.3.4. Subsetting a Private Extension URN
The organization registering the <provider> "foo" wants to define a set of URNs that specify the different ring patterns used by a "distinctive ring" service. That service alerts for incoming calls that are directed to different directory numbers. These ring patterns are made of groups of ring sounds with particular patterns of lengths 🔔.
The company can create a private <alert-category> "distinctive@foo" and, within it, assign three 'alert' URNs that indicate the three different ring patterns its service uses 🎶:
urn:alert:distinctive@foo:long-long
urn:alert:distinctive@foo:short-long-short
urn:alert:distinctive@foo:short-short-longLater on, the company registering the <provider> "bar" wants to define an additional 'alert' URN for the ring pattern "short short". It uses that pattern to support a fourth directory number for a phone instrument 📞.
The company can create a <private-name> to be used with the "distinctive@foo" <alert-category> 💅:
urn:alert:distinctive@foo:short-short@bar11. Combinations of "alert" URNs ✨
11.1. Priority Rules 💅
Okay so this part is about what happens when every Alert-Info header field only has "alert" URNs in it 🎀 Any other mix of URIs in the same SIP message isn't defined here, so we're just not touching that 🙈
One URN is often NOT enough to fully describe a tone, so you can stack several "alert" URNs across one or more Alert-Info header fields in a request or response ✨ For example, an internal priority call could be Alert-Info: <urn:alert:source:internal>, <urn:alert:priority:high>. A priority call-waiting tone could be Alert-Info: <urn:alert:service:call-waiting>, <urn:alert:priority:high> 🦋
The sender can include an arbitrary list of "alert" URNs, even if they're redundant or contradictory 🙃 An earlier URN beats any later contradictory one. That means any element can tweak a list: stick a URN at the front to require a feature value, or at the end to suggest one 💜
The receiving UA matches the received "alert" URN combo with the signal(s) it can render 🔥
The implementation is free to ignore an "alert" URN if it doesn't recognize it, or if it can't render its effect in context 🌸 It can also chop off a final series of one or more <alert-ind-part>s to make a "more generic" URN it DOES recognize and can render in context 🧚
How a UA renders a received combo of "alert" URNs is left up to the implementation, but the implementation MUST comply with the following rules 👑
(a) Each "alert" URN has precedence over all the URNs that follow it, and its interpretation is subordinate to all the URNs that come before it 💅
(b) If the UA can't implement the effect of a URN (because it doesn't recognize it, or because preceding URNs preclude its effect), the UA keeps removing the final <alert-ind-part> of the URN until either:
- the resulting URN is recognized and can be given effect by some signal (without reducing the degree of expression of any preceding URN), or
- the resulting URN has no
<alert-ind-part>left, in which case that URN in the series can't be given effect and gets ignored 🥺
(c) If, after processing all the received URNs, the UA can generate more than one signal that are equally effective at expressing the URNs (under the rules above), ONE of those signals gets selected 🎯 When picking from that set of equally effective signals, the least specific signal in the set should be chosen: a signal shouldn't be chosen if a less-specific signal is also in the set 🫶 (Specificity is judged by the defined meanings of the signals to the user.) (For example, if each signal is considered to express certain <alert-indication>s of certain <alert-category>s, one signal is less specific than a second signal if the first signal's <alert-indication>s are a subset or are prefixes of the second signal's <alert-indication>s.) BUT a more-specific signal may be chosen if the choice is based on information from the containing SIP message 💖 For example, a signal implying <urn:alert:priority:high> may be chosen if the SIP message contains the header field Priority: urgent 🚨
In ALL situations, the set of signals that can be rendered and their significances may change based on user preferences and local policy 🌈 The chosen signal can also change based on the status of the UA. For example, if a call is active on the UA, all audible signals may become unavailable, or audible signals may only be available if <urn:alert:priority:high> is specified 📞💀
11.2. Multi-mode Signals 🎧
Sometimes a device can render two signal modes at the same time, like audio and visual, or video and text ✨
Formally, the device has to be considered as making its choice from the set of ALL combined signals it can render (pairs of one signal from the first mode and one signal from the second mode), and that choice has to conform to the rules above 😭 BUT it can be proven that if the device makes its rendering choice for each of the two modes independently, with each choice separately conforming to the rules above, the combined choice ALSO conforms to the rules above when you treat it as a choice from among all possible combinations 🧠✨
So in that situation, it may simplify implementation to make each choice separately 🍓 Whether to choose from among combined signals or to combine choices made from each signal mode is an implementation decision 💅
12. Non-normative Algorithm for Handling Combinations of URNs 🧩
This is a non-normative example of an algorithm for handling combinations of URNs that complies with the rules in Sections 10 and 11 🫶 So it shows that the rules are consistent and implementable. (Of course, a device can use any other algorithm that complies with Sections 10 and 11 🌸)
12.1. Algorithm Description 🌷
For each <alert-category> (feature) the implementation knows about, there's a "feature tree" of the known <alert-indication>s for that <alert-category>. The sequence of <alert-ind-part>s in an <alert-indication> specifies the path in the tree from the root to the node representing that <alert-indication> 🌳 For this description, we name each tree and its root node by the <alert-category> name, and name each non-root node by the <alert-identifier>. Each URN corresponds to ONE non-root node in ONE feature tree 🦋 For example, there's a tree named "source", whose root node is also named "source", and which has the children source:internal, source:external, source:friend, and source:family. The URN <urn:alert:source:external> goes at the node "source:external" in the "source" tree. If the implementation understands <urn:alert:source:foo@example>, there's a node source:foo@example that's a child of node "source". If it understands <urn:alert:source:external:bar@example>, there's a node source:external:bar@example that's a child of node source:external. (Of course, there are an infinite number of potential extra nodes in the tree for private values, but we don't have to represent those nodes explicitly unless the device has a signal representing the private value 🙈)
We give signals similar locations, but each signal has a position in every tree, describing the specific combo of meanings that it carries 💜 If a signal has a simple meaning, like "external source", its place in the "source" tree is source:external (showing it carries the "external source" meaning). But its place in every other feature tree is at the root node, meaning it has no particular meaning for those features 🌈
A signal with a complex meaning can have non-root positions in more than one feature tree 🔥 For example, an "external, high priority" signal would be placed at source:external and priority:high in those trees, and be at the root in all other feature trees 💅
To make sure the algorithm ALWAYS selects at least one signal, there needs to be a "default" signal, whose position in every feature tree is at the root 🛟 This default signal will never be excluded from the set of acceptable signals for any set of URNs, but it will be the lowest-priority signal for any set of URNs 😌
The algorithm works by considering each URN in the received Alert-Info header fields from left to right, while revising a set of signals 🏃♀️ The set starts as the entire set of signals available to the device. Each URN excludes some signals from the set, and "sorts" the signals that remain according to how well they represent the URN. (The details of these operations are described below.) The first URN is the "major sort", and has the MOST influence on where a signal lands in the set. The second URN is a "minor sort", arranging the signals that are tied within the first sort. The third URN arranges the signals tied within the first two sorts, and so on 👑
At the end, a final "most minor" sort happens, ordering the signals that are still tied under all the sorts driven by the URNs. This final sort puts the least specific signals (within their tied groups) "first". (If one signal's position in each feature tree is ancestral to, or the same as, a second signal's position in that tree, the first signal is "less specific" than the second. Other cases are left to the implementation to decide 🤷♀️)
Once all the URNs are processed and the sorting of the not-excluded signals is done, the device selects the first signal in the set 🎉
Here's how a single sort step goes, examining one URN to modify the set (by excluding some signals and further sorting the ones that remain) 💖
- The URN specifies a specific node in a specific feature tree.
- All signals in the set that are, within that feature tree, positioned at the URN's node, or at an ancestor node of the URN's node, are kept. All other signals are removed from the set (because they have meanings that are incompatible with the URN's meaning) 🙅♀️
- Each group of signals that are tied under the previous sorts is further sorted into groups based on how much of the URN's meaning they represent: those positioned at the node of the URN are tied for first position, those positioned at the parent node of the URN are tied for second position, and so on, and those positioned at the root node of the feature tree are tied for last position 📶
12.2. Examples of How the Algorithm Works 🔍
The following examples show how the algorithm from the previous section works 🦋
12.2.1. Example 1 ✨
The device has a set of four alerting signals. Here are their primary meanings, and the locations they're placed at in the feature trees 🎀
Signal 1
Meaning: external
Locations:
- source:external
- priority (that is, the root node of the priority tree)
Signal 2
Meaning: internal
Locations:
- source:internal
- priority
Signal 3
Meaning: low
Locations:
- source
- priority:low
Signal 4
Meaning: high
Locations:
- source
- priority:highTo which we add:
Signal 5
Meaning: default
Locations:
- source
- priorityIf the device receives <urn:alert:source:internal>, then the sort is:
Signals at source:internal: (this is, first place)
Signal 2: internal
Signals at source: (tied for second place)
Signal 3: low
Signal 4: high
Signal 5: defaultAnd these signals are excluded from the set:
Signal 1: externalSo in this example, the sorting algorithm properly gives first place to Signal 2 "internal" 🥳👑
12.2.2. Example 2 🦋
Okay bestie, let's add some combos to the Example 1 signals, like "internal, high priority." We're specifically excluding "internal, low priority" so we get some tricky examples 👀 Our signal set now looks like this:
Signal 1
Meaning: default
Locations:
- source
- priority
Signal 2
Meaning: external
Locations:
- source:external
- priority
Signal 3
Meaning: internal
Locations:
- source:internal
- priority
Signal 4
Meaning: low
Locations:
- source
- priority:low
Signal 5
Meaning: high
Locations:
- source
- priority:high
Signal 6
Meaning: external high
Locations:
- source:external
- priority:high
Signal 7
Meaning: external low
Locations:
- source:external
- priority:low
Signal 8
Meaning: internal high
Locations:
- source:internal
- priority:highIf the device receives <urn:alert:source:internal>, the sort goes like this 🔍
Signals at source:internal: (that is, tied for first place)
- Signal 3: internal
- Signal 8: internal high
Signals at source: (tied for second place)
- Signal 4: low
- Signal 5: high
- Signal 1: default
Signals excluded from the set:
- Signal 2: external
- Signal 7: external low
- Signal 6: external highTwo signals are tied for first place, but the final sort orders them like this:
- Signal 3: internal
- Signal 8: internal highIt does that because it puts the least-specific signal first. So Signal 3 "internal" wins 🏆
12.2.3. Example 3 💖
Same device, but now it receives <urn:alert:source:external> and <urn:alert:priority:low>. The first sort (from <urn:alert:source:external>) looks like this:
Signals at source:external:
- Signal 2: external
- Signal 7: external low
- Signal 6: external high
Signals at source:
- Signal 4: low
- Signal 5: high
- Signal 1: default
Signals excluded:
- Signal 3: internal
- Signal 8: internal highThe second sort (from <urn:alert:priority:low>) puts signals at priority:low before signals at priority, and excludes the signal at priority:high:
- Signal 7: external low
- Signal 2: external
- Signal 4: low
- Signal 1: default
Excluded:
- Signal 6: external high
- Signal 5: high
- Signal 3: internal
- Signal 8: internal highSo we choose Signal 7 "external low" 💅
12.2.4. Example 4 🙈
Now say the same device gets <urn:alert:source:internal> and <urn:alert:priority:low>. Note that there's no signal that matches this combo, so things get messy.
The first sort is based on source:internal and gives this order:
- Signal 3: internal
- Signal 8: internal high
- Signal 4: low
- Signal 5: high
- Signal 1: default
Excluded:
- Signal 2: external
- Signal 7: external low
- Signal 6: external highThe second sort is based on priority:low and gives this order:
- Signal 3: internal
- Signal 4: low
- Signal 1: default
Excluded:
- Signal 8: internal high
- Signal 5: high
- Signal 7: external low
- Signal 2: external
- Signal 6: external highSo we choose Signal 3 "internal".
Here's the plot twist 😭 <urn:alert:priority:low> couldn't actually take effect, because it came after <urn:alert:source:internal>. If the two URNs had shown up in the reverse order, Signal 2 "external" would have been chosen, because <urn:alert:priority:low> would have gotten precedence. Order matters, babe!
12.2.5. Example 5 🌸
Let's set up a simple set of signals, with three signals giving priority:
Signal 1
Meaning: default
Locations:
- priority
Signal 2
Meaning: low
Locations:
- priority:low
Signal 3
Meaning: high
Locations:
- priority:highNotice we used the "default" signal to cover "normal priority." That way it covers situations where no priority URN is present, as well as the ones with <urn:alert:priority:normal>. So we're deliberately not distinguishing "priority:normal" from the default priority. It's a choice, and it's iconic 🫶
If the device receives <urn:alert:priority:low>, the sort is:
- Signal 2: low
- Signal 1: default
Excluded:
- Signal 3: highand Signal 2 "low" is chosen.
Similarly, if the device receives <urn:alert:priority:high>, Signal 3 is chosen.
If the device receives <urn:alert:priority:normal>, the sort is:
-Signal 1 :default
Excluded:
- Signal 2: low
- Signal 3: highand Signal 1 "default" is chosen.
If no "priority" URN is received, Signal 1 "default" gets put before Signal 2 "low" and Signal 3 "high" by the final sort, so it's the one that gets chosen. Main character energy 👑
13. User Agent Behaviour 📱
So a SIP UA MAY tack a URN (or a whole bunch of them) onto the Alert-Info header field in a SIP request or a provisional 1xx response, except a 100 response. It can do this whenever it needs to share extra info about the call or the service being provided ✨
When a UA gets a SIP INVITE request or a SIP provisional response with an Alert-Info header field containing a combo of Alert-Info URNs, it tries to match that combo with a signal it can render. The process the UA uses MUST conform to the rules in Section 11. (A non-normative algorithm example for the process is described in Section 12.)
The UA must produce a reasonable rendering no matter what combo of URIs (of any schemes) shows up in the Alert-Info header field. It MUST produce a rendering based on the URIs it can understand and act on (if any), interpreted as local policy prescribes, and ignore the rest. 🙃 In particular, unless the containing message is a request and is immediately rejected, the UA SHOULD provide some alert unless it's told not to. That could be because of Alert-Info URIs it understands, the presence of a Replaces or Joins header field, local policy, or what the user wants.
Subsequent provisional responses, even within the same dialog, may contain different Alert-Info header field values. The values received in different provisional responses are treated independently. If subsequent provisional responses with different Alert-Info header field values were received within the same dialog, the UA SHOULD render, at any time, the last received Alert-Info header field value. How provisional responses with different Alert-Info values that were not received within the same dialog get handled is left as an implementation issue 🤷♀️
14. Proxy Behaviour 🔀
A SIP proxy MAY add or remove an Alert-Info header field, and MAY add or remove Alert-Info header field values, in a SIP request or a non-100 provisional response. It can do this when it needs to change the info about the call or the provided services.
A proxy has lots of reasons to do this! For example: (1) it can add indications based on what it can figure out about the call, like that it's coming from an external source or that the INVITE contains a "Priority: urgent" header field; (2) it can add an indication that a particular service is being invoked at this end of the call; (3) it can remove undesirable indications, like possibly deceptive ones from untrusted sources; and (4) it can remove indications that contain info that should be suppressed for privacy reasons 🫣
The following example is a typical 180 (Ringing) provisional response that a proxy has modified. The response the UAS sent to the proxy was very similar, but had no Alert-Info header field. The proxy added Alert-Info header field values for both a network audio resource referenced by the HTTP URI and the URN indication for the call-waiting service. That lets the UAC render the network audio resource, pick a rendering based on the URN, or do some combo of both. Due to Section 10, the UAC must produce some reasonable rendering in this situation 🎀
SIP/2.0 180 Ringing
Alert-Info: <http://www.example.com/sound/moo.wav>,
<urn:alert:service:call-waiting>
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Via: SIP/2.0/UDP server10.biloxi.example.com;
branch=z9hG4bK4b43c2ff8.1
Content-Length: 015. Internationalization Considerations 🌍
The <alert-identifier> labels are protocol elements [RFC6365] and aren't normally seen by users. That's why the character set for these elements is restricted, as described in Section 7.
There's room to internationalize <alert-identifier>s by letting them be A-labels. A processor that doesn't understand such <alert-identifier>s is required to ignore them, as specified in Sections 7 and 11.1 💖
The URNs <urn:alert:locale:country:<ISO 3166-1 country code>> select renderings that are conventional in the specified country 🇺🇳
16. Security Considerations 🔐
As an identifier, the "alert" URN doesn't seem to raise any particular security issues. The indications described by the "alert" URN are meant to be well-known.
Okay, but here's the serious part, bestie. Providing specific indications may raise privacy issues by revealing info about the source UA, such as its nature, its dialog state, or services initiated at its end of the call. Call-waiting (Section 6.2.1) and call-forwarding (Section 6.2.2) services can reveal the dialog state of the UA. Such a provision SHALL always require authorization on behalf of the user of the source UA (usually through accessing configured policy). Authorization SHALL NOT assume that there is any limitation of the potential recipients of the indications without obtaining specific information about the SIP transaction. 🚨
Based on local policy, a UA MAY choose to ignore undesirable indications (e.g., possibly deceptive indications from untrusted sources), and it MAY choose not to send indications that are otherwise valid in the context (e.g., for privacy reasons). A proxy acting on behalf of a UA MAY add or delete indications going to or from the UA for the same reasons 🙌
Since the alert indications can be sensitive, end-to-end SIP encryption mechanisms using S/MIME MAY be used to protect it. UAs that implement alert indications SHOULD also implement SIP over TLS [RFC5246] and the sips: scheme [RFC5630] 🔒
17. References 📚
17.1. Normative References 📚✨
okay so these are the must-read sources. if you're implementing this, you need these, no cap 💅
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. - [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997,
<http://www.rfc-editor.org/info/rfc2141>. - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. - [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002,
<http://www.rfc-editor.org/info/rfc3406>. - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. - [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. - [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. - [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009,
<http://www.rfc-editor.org/info/rfc5630>.
17.2. Informative References 🌸
these ones are super useful background reading, bestie. not required, but lowkey essential for the full picture 🧚
- [E182] ITU-T, "Application of tones and recorded announcements in telephone services", ITU-T Recommendation E.182, 1998,
<http://www.itu.int/rec/T-REC-E.182-199803-I/en>. - [ISO3166-1] ISO, "English country names and code elements", ISO 3166-1,
<http://www.iso.org/iso/english_country_names_and_code_elements>. - [RFC3043] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001,
<http://www.rfc-editor.org/info/rfc3043>. - [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001,
<http://www.rfc-editor.org/info/rfc3044>. - [RFC3120] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120, June 2001,
<http://www.rfc-editor.org/info/rfc3120>. - [RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001,
<http://www.rfc-editor.org/info/rfc3187>. - [RFC3188] Hakala, J., "Using National Bibliography Numbers as Uniform Resource Names", RFC 3188, October 2001,
<http://www.rfc-editor.org/info/rfc3188>. - [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code", RFC 4152, August 2005,
<http://www.rfc-editor.org/info/rfc4152>. - [RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)", RFC 4179, October 2005,
<http://www.rfc-editor.org/info/rfc4179>. - [RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005,
<http://www.rfc-editor.org/info/rfc4195>. - [RFC4198] Tessman, D., "A Uniform Resource Name (URN) Namespace for Federated Content", RFC 4198, November 2005,
<http://www.rfc-editor.org/info/rfc4198>. - [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009,
<http://www.rfc-editor.org/info/rfc5589>. - [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. - [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011,
<http://www.rfc-editor.org/info/rfc6365>. - [RFC6910] Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev, "Completion of Calls for the Session Initiation Protocol (SIP)", RFC 6910, April 2013,
<http://www.rfc-editor.org/info/rfc6910>. - [RFC7463] Johnston, A., Ed., Soroushnejad, M., Ed., and V. Venkataramanan, "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", RFC 7463, March 2015,
<http://www.rfc-editor.org/info/rfc7463>. - [TS24.615] 3GPP, "Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol Specification", 3GPP TS 24.615, September 2015.
Acknowledgements 🫶
The authors wish to thank Denis Alexeitsev, the editor of the initial version in BLISS, Anwar Siddiqui for his contributions to the document, Christer Holmberg for his careful review of the document, Adam Roach, Dean Willis, Martin Huelsemann, Shida Schubert, John Elwell, and Tom Taylor for their comments and suggestions and Alfred Hoenes for his extensive comments and proposals related to new namespace identifiers for URNs.
Authors' Addresses 💜
Laura Liess (editor)
Deutsche Telekom AG
Heinrich-Hertz Str 3-7
Darmstadt, Hessen 64295
Germany
Phone: +49 6151 5812761
EMail: laura.liess.dt@gmail.com
Roland Jesske
Deutsche Telekom AG
Heinrich-Hertz Str. 3-7
Darmstadt, Hessen 64295
Germany
Phone: +49 6151 5812766
EMail: r.jesske@telekom.de
Alan Johnston
Avaya, Inc.
St. Louis, MO
United States
EMail: alan.b.johnston@gmail.com
Dale R. Worley
Ariadne Internet Services, Inc.
738 Main St.
Waltham, MA 02451
United States
Phone: +1 781 647 9199
EMail: worley@ariadne.com
Paul Kyzivat
Huawei
United States
EMail: pkyzivat@alum.mit.edu📦 where this page comes from
- ietf: rfc7462 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms