Internet Engineering Task Force (IETF) L. Liess, Ed.
Request for Comments: 7462 R. Jesske
Updates: 3261 Deutsche Telekom AG
Category: Standards Track A. Johnston
ISSN: 2070-1721 Avaya
D. Worley
Ariadne
P. Kyzivat
Huawei
March 2015
Internet Engineering Task Force (IETF) L. Liess, Ed.
Request for Comments: 7462 R. Jesske
Updates: 3261 Deutsche Telekom AG
Category: Standards Track A. Johnston
ISSN: 2070-1721 Avaya
D. Worley
Ariadne
P. Kyzivat
Huawei
March 2015
URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
会话启动协议（SIP）的警报信息标头字段的URN
Abstract
摘要
The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the User Agent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.
会话发起协议（SIP）支持提供对特定呈现的引用的能力，该特定呈现将由用户代理（UA）在向用户发出警报时用作警报信号（例如，铃声或回铃音）。这是使用警报信息标题字段完成的。但是，引用（通常是URL）仅针对具有特定呈现属性的特定网络资源。目前不支持标准标识符来描述警报情况的语义或警报信号的特征，而不依赖于特定的呈现。为了克服这些限制并支持新的应用程序，本规范中定义了用于警报信息标题字段（以及具有类似要求的情况）的新URN系列。
This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.
本文档规范性地更新了RFC3261，RFC3261定义了会话启动协议（SIP）。它更改了RFC 3261中定义的警报信息标题字段的用法，另外允许在任何非100的INVITE临时响应中使用该字段。本文档还允许代理添加或删除警报信息标题字段，以及添加或删除警报信息标题字段值。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7462.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, 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, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
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
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 ................................................46
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 ................................................46
The Session Initiation Protocol (SIP) [RFC3261] includes a means to suggest to a User Agent (UA) a particular ringback tone or ring tone to be used during session establishment. In [RFC3261], this is done by including a URI, in the Alert-Info header field, that specifies a reference to the tone. The URI is most commonly the HTTP URL to an audio file. On the receipt of the Alert-Info header field, the UA may fetch the referenced ringback tone or ring tone and play it to the user.
会话发起协议（SIP）[rfc326]包括向用户代理（UA）建议在会话建立期间使用的特定回铃音或铃声的方法。在[RFC3261]中，这是通过在警报信息标题字段中包含一个URI来完成的，该URI指定对音调的引用。URI通常是音频文件的HTTP URL。收到警报信息报头字段后，UA可获取参考的回铃音或铃声并播放给用户。
This mechanism hinders interoperability when there is no common understanding of the meaning of the referenced tone, which might be country- or vendor-specific. It can lead to problems for the user trying to interpret the tone and for the UA wanting to substitute its own tone (e.g., in accordance with user preferences) or provide an alternative alerting mode (e.g., for deaf and hard-of-hearing users). If the caller and the callee are from different countries, their understanding of the tones may differ significantly. Deaf or hard-of-hearing users may not sense the specific tone if it is provided as an audio file. The tone, per se, is also not useful for automata.
当对所引用音调的含义（可能是特定于国家或供应商的）没有共识时，这种机制会妨碍互操作性。对于试图解释音调的用户和想要替换自己音调（例如，根据用户偏好）或提供替代警报模式（例如，对于聋哑和重听用户）的UA来说，这可能会导致问题。如果呼叫者和被呼叫者来自不同的国家，他们对音调的理解可能会有很大差异。如果作为音频文件提供，聋哑或重听用户可能感觉不到特定音调。音调本身对自动机也没有用处。
Another limitation of using URLs of audio files is that the referenced tones are tied to particular renderings. There is no method to signal the semantic intention of the alert while enabling the recipient UA to choose the specific alert indication (such as a particular tone, vibration, or visual display) to use to signal the intention. Similarly, there is no method to signal particular rendering features (such as short duration, delay, or country-specific conventions).
使用音频文件URL的另一个限制是引用的音调与特定的渲染绑定。在允许接收者UA选择特定警报指示（例如特定音调、振动或视觉显示）来表示警报意图的同时，没有方法来表示警报的语义意图。类似地，也没有方法表示特定的渲染特性（例如短持续时间、延迟或特定于国家/地区的约定）。
The issues with URLs that reference audio files can be avoided by using fixed URLs with specific meanings. However, this approach has its own interoperability issues. For example, consider the Private Branch Exchange (PBX) special ring tone for an external (to the PBX) caller. Different vendors use different approaches such as:
通过使用具有特定含义的固定URL，可以避免引用音频文件的URL的问题。然而，这种方法有其自身的互操作性问题。例如，考虑外部分支（PBX）调用者的专用分支交换（PBX）专用铃声。不同的供应商使用不同的方法，例如：
Alert-Info: <file://ring.pcm>;alert=external
Alert-Info: <file://ring.pcm>;alert=external
where ring.pcm is a dummy file name, or:
其中，ring.pcm是虚拟文件名，或：
Alert-Info: <file://external.ring.pcm>
Alert-Info: <file://external.ring.pcm>
Alert-Info: <sip:external-ringtone@example.com>
Alert-Info: <sip:external-ringtone@example.com>
As a result, the Alert-Info header field currently only works when the same vendor provides a PBX and UA, and only then if the same artificial proprietary URI convention is used.
因此，警报信息标题字段当前仅在同一供应商提供PBX和UA时有效，并且仅在使用相同的人工专有URI约定时有效。
To solve the described issues, this specification defines the new URN namespace "alert" for the SIP Alert-Info header field that allows for programmatic user interface adaptation and for conversion of equivalent alerting tones in the Public Switched Telephone Network (PSTN) when the client is a gateway. The work to standardize an "alert" URN will increase SIP interoperability for this header field by replacing proprietary conventions used today.
为解决所述问题，本规范为SIP alert Info报头字段定义了新的URN名称空间“alert”，该字段允许编程用户界面自适应，并允许在客户端为网关时转换公共交换电话网络（PSTN）中的等效警报音。标准化“警报”URN的工作将通过替换当前使用的专有约定来提高此标头字段的SIP互操作性。
The "alert" namespace provides a syntax for several different application spaces, for example:
“警报”命名空间为几个不同的应用程序空间提供了语法，例如：
o Names for service indications, such as call waiting or automatic callback, not tied to any particular rendering.
o 服务指示的名称，如呼叫等待或自动回调，与任何特定呈现无关。
o 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.
o PBX电话为内部企业呼叫方、外部呼叫方、传输失败或保持计时器过期后的回铃音等情况生成的常用铃声的名称。
o Names for country-specific ringback tones.
o 国家/地区特定铃声的名称。
o Names for things with specific renderings that aren't purely audio. They might be static icons, video sequences, text, etc.
o 具有非纯音频的特定渲染的对象的名称。它们可能是静态图标、视频序列、文本等。
Some advantages of a URN rather than a URL of a downloadable resource:
URN而不是可下载资源的URL的一些优点：
o There is no need to download it or deal with security issues associated with dereferencing.
o 不需要下载它或处理与取消引用相关的安全问题。
o There are no formatting or compatibility issues.
o 没有格式或兼容性问题。
o There is no security risk of rendering something unexpected and undesirable.
o 不存在导致意外和不希望发生的事情的安全风险。
o 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".
o 音调可以以任何适当的格式和质量级别本地存储，因为它是“按名称”而不是“按值”指定的。
o It is easier to make policy decisions about whether or not to use it.
o 决策是否使用它更容易。
o It facilitates translation for the deaf and hard of hearing.
o 它有助于聋哑人和听力障碍者的翻译。
The downside is that if the recipient does not understand the URN, then it will only be able to render a default ringback tone or ring tone.
缺点是，如果收件人不理解URN，那么它将只能呈现默认的回铃音或铃声。
This document creates a new URN namespace and registry for alert indications and registers some initial values.
本文档为警报指示创建一个新的URN命名空间和注册表，并注册一些初始值。
In practice, this specification extends the usage of the Alert-Info header field in that it will cause the use of a new class of URIs and the use of multiple URIs. Backward compatibility issues are not expected, as devices that do not understand an "alert" URN should ignore it, and devices should not malfunction upon receiving multiple Alert-Info header field values (<alert-param>s in [RFC3261]) (which was syntactically permitted before, but rarely used).
实际上，此规范扩展了警报信息头字段的用法，因为它将导致使用新的URI类和多个URI。不存在向后兼容性问题，因为不理解“警报”URN的设备应忽略该URN，并且设备在接收到多个警报信息标题字段值（[RFC3261]中的<alert param>s]）（以前在语法上允许，但很少使用）时不应出现故障。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification uses a number of terms to refer to the roles involved in the use of alerting indications in SIP. A "specifier" sends an "alerting indication" (one or more URNs in an Alert-Info header field) to a "renderer", which then "renders" a "signal" or "rendering" based on the indication to a human user. A "category" is a characteristic whose "values" can be used to classify indications.
本规范使用了许多术语来指代SIP中警报指示的使用所涉及的角色。“说明符”向“渲染器”发送“警报指示”（警报信息标题字段中的一个或多个URN），然后“渲染器”根据指示向人类用户“渲染”一个“信号”或“渲染”。“类别”是一种特征，其“值”可用于对指示进行分类。
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, advising the callee about an incoming call. A "ringback tone" or "ringing tone" (terminology used in [E182]) is a signal advising the caller that a connection has been made and that a ring tone is being rendered to the callee.
本规范使用术语“铃声”和“回铃音”。“铃声”或“呼叫信号”（在[E182]中使用的术语）是由被叫方的终端设备生成的信号，通知被叫方来电。“回铃音”或“铃声”（在[E182]中使用的术语）是一种通知呼叫者已建立连接且正在向被呼叫者提供铃声的信号。
This specification changes the usage of the Alert-Info header field defined in [RFC3261] by additionally allowing its use in any non-100 provisional response to INVITE.
本规范更改了[RFC3261]中定义的警报信息标题字段的用法，另外允许在任何非100临时INVITE响应中使用该字段。
Previously, the Alert-Info header field was only permitted in 180 (Ringing) responses. But in telephony, other situations indicated by SIP provisional responses, such as 181 (Call Is Being Forwarded) and 182 (Call Is Being Queued), are often indicated by tones. Extending the applicability of the Alert-Info header field allows the telephony practice to be implemented in SIP.
以前，警报信息标题字段仅允许在180（响铃）响应中使用。但在电话技术中，由SIP临时响应指示的其他情况，例如181（呼叫正在转发）和182（呼叫正在排队），通常由音调指示。扩展Alert Info header字段的适用性允许在SIP中实现电话实践。
To support this change, the following paragraph replaces the the first paragraph of Section 20.4 of [RFC3261]:
为了支持这一变更，以下段落取代了[RFC3261]第20.4节的第一段：
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.
当出现在INVITE请求中时，Alert Info header字段指定用户代理服务器（UAS）的备选铃声。当出现在非100临时响应中时，Alert Info header（警报信息标题）字段指定UAC的备选回铃音。典型的用法是代理插入此头字段以提供独特的环特征。
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.
SIP代理可以在SIP请求或非100临时响应中添加或删除警报信息头字段，也可以添加或删除警报信息头字段值。
This section discusses the requirements for an alerting indication to transport the semantics of the alerting situation or the characteristics of the rendering.
本节讨论警报指示的要求，以传输警报情况的语义或呈现的特征。
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-1：该机制将允许UAs和代理在警报信息报头字段中提供警报指示，描述信令情况的语义或呈现的特征，并允许接收方决定如何向用户呈现接收到的信息。
REQ-2: The mechanism will allow the alerting indication to be specified "by name" rather than "by value", to enable local policy decisions whether or not to use it.
REQ-2：该机制将允许“按名称”而不是“按值”指定警报指示，以便本地策略决定是否使用它。
REQ-3: The mechanism will enable alerting indications to represent a wide variety of signals, which have many largely orthogonal characteristics.
REQ-3：该机制将使警报指示能够表示各种各样的信号，这些信号具有许多基本上正交的特征。
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:
REQ-4：该机制将使警报指示集能够支持彼此不协调的各种组织的可扩展性。扩展将能够：
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
语义上细分任何现有指示提供的含义
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.
REQ-5：该机制将是灵活的，因此将来当SIP应用程序发展时，可以定义新的警报指示。例如，“警报”骨灰盒可以通过名称识别特定媒体，如“贝多芬的第五部”，终端设备可以将其中的一小部分呈现为铃声。
REQ-6: The mechanism will provide only an indication capability, not a negotiation capability.
REQ-6：该机制仅提供指示能力，不提供协商能力。
REQ-7: The mechanism will not require an alerting indication to depend on context provided by a previous alerting indication in either direction.
REQ-7：该机制不需要警报指示来依赖于任一方向上先前警报指示提供的上下文。
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-8：该机制将允许在警报信息报头字段中传输SIP INVITE请求和临时1x响应（100个响应除外）。
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.)
REQ-9：该机制将能够容纳使用有限或不常见信号集定制的渲染器和提供具有不常见语义的信号集的渲染器。（典型的例子是针对聋哑人和重听人的UA，使用一组替代信号、视频或文本（而不是音频）进行定制。根据REQ-6，渲染器无法将此事实传输给说明符。）
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-10：如果说明符和呈现器具有适当协调的设计，该机制将允许警报指示可靠地承载所有扩展。
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-11：如果渲染器无法提供所指示的精确音调，该机制将允许渲染器选择近似于说明符预期的音调。
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-12：该机制将支持与服务相关的警报指示，如呼叫等待、呼叫转移、转移回调、自动回调和保持回调。
REQ-13: The mechanism will allow rendering common PBX ring tone types.
REQ-13：该机制将允许呈现常见的PBX铃声类型。
REQ-14: The mechanism will allow rendering specific country ringback tones.
REQ-14：该机制将允许呈现特定国家/地区的回铃音。
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-15：该机制将允许为紧急警报呈现音调。（紧急呼叫的用例和URN值定义不属于本规范的主题。）
REQ-16: The mechanism will allow rendering using other means than tones, e.g., text or images.
REQ-16：该机制将允许使用音调以外的其他方式进行渲染，例如文本或图像。
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-17：该机制将允许PSTN网关将传统协议中的铃声/回铃音映射到网络边缘的SIP，例如TIA/EIA-41-D和3GPP2 a.S0014中定义的国家铃声。（这种情况下的用例和值定义不属于本规范的主题。）
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.
REQ-18：该机制将确保如果UA接收到“警报”URN或其不理解的“警报”URN的部分，则可以忽略它们。
REQ-19: The mechanism will allow storage of the actual encoding of the rendering locally rather than fetching it.
REQ-19：该机制将允许本地存储渲染的实际编码，而不是获取它。
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.
REQ-20：该机制必须提供一种简单的方式来组合两个或多个警报指示，以产生一个警报指示，该警报指示要求组合两个警报指示的意图，两个报警指示之间的任何矛盾或冲突得到解决，有利于第一个报警指示的意图。
This section describes some use cases for which the "alert" URN mechanism is needed today.
本节描述了一些当前需要“警报”URN机制的用例。
This section defines some commonly encountered ring tones on PBX or business phones. They are as listed in the following subsections.
本节定义了PBX或商务电话上常见的一些铃声。它们在以下小节中列出。
This tone indicates that the default or normal ring tone should be rendered. This is essentially a no-operation "alert" URN and 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.
此铃声表示应呈现默认铃声或正常铃声。这本质上是一个无操作“警报”URN，UA应将其视为不存在“警报”URN。这在使用警报信息标题字段参数时最有用。例如，在[RFC7463]中，需要存在包含“外观”参数的警报信息标题字段，但不需要指定特殊铃声。
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.
此音调用于指示呼叫者位于企业或PBX系统外部。这可能是来自PSTN或SIP中继的呼叫。
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.
此音用于指示呼叫者是企业或PBX系统的内部用户。呼叫可能来自此PBX或企业内其他PBX上的其他用户。
A PBX tone needs to indicate that a priority level alert should be applied for the type of alerting specified (e.g., internal alerting).
PBX提示音需要指示应针对指定的警报类型应用优先级警报（例如，内部警报）。
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".
在这种情况下，指定的警报类型（例如，内部警报）应比正常情况短。在呼叫中心，这有时被称为“缩写铃声”或“压缩音”。
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.
在这种情况下，指定的警报类型应在短时间延迟后呈现。在一些桥接线路/共享线路外观实现中，使用这种方式，桥接线路不会与主线在同一时间鸣响，而是会延迟几秒钟。
These tones are used to indicate specific PBX and public network telephony services.
这些音调用于指示特定的PBX和公共网络电话服务。
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 callee to pickup 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.
呼叫等待服务[TS24.615]允许被叫方在进行有效或保持呼叫时收到来电通知。随后，被叫方可以接受、拒绝或忽略传入呼叫。呼叫方有兴趣了解被叫方的呼叫等待情况。有了这些信息，呼叫者可以决定是否继续等待被呼叫者接听，或者在估计被呼叫者可能已经完成正在进行的对话时，最好稍后再打电话。为了提供此信息，被呼叫方的UA（或代理）如果知道呼叫等待条件，可以将呼叫等待指示添加到180（振铃）响应中的警报信息报头字段中。
This feature is used in a 180 (Ringing) response when a call forwarding feature has been initiated on an INVITE. Many PBX system implement a forwarding "beep" followed by normal ringing to indicate this. Note that a 181 response can be used in place of this URN.
当对邀请启动呼叫转移功能时，此功能用于180（响铃）响应。许多PBX系统都会发出转发“嘟嘟”声，然后再发出正常的响声来表示这一点。请注意，可以使用181响应来代替此URN。
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.
当服务器代表传输方执行盲传输[RFC5589]并失败时，使用此功能。服务器并没有使呼叫失败，而是回叫转发器，给他们另一个转发器或处理呼叫的机会。此服务音用于区分此邀请和正常来电。
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.
当用户利用服务器实现自动回调服务[RFC6910]时，使用此功能。当用户可用时，服务器会回拨用户，并利用此服务音调将此邀请与正常来电区分开来。
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.
当服务器代表端点实现呼叫保持计时器时，将使用此功能。在等待一段时间后，将呼叫置于等待状态的用户收到警报，要求其检索呼叫或以其他方式处理呼叫。此服务音用于区分此情况与正常来电。
6.3. Country-Specific Ringback Tone Indications for the Public Switched Telephone Network
6.3. 公共交换电话网络的特定于国家/地区的回铃音指示
In the PSTN, different tones are used in different countries. End users are accustomed to hear the callee's country ringback tone and would like to have this feature for SIP.
在PSTN中，不同的国家使用不同的音调。最终用户习惯于听到被叫人的国家/地区回铃音，并希望SIP具有此功能。
This section provides the registration template for the "alert" URN namespace identifier (NID) according to [RFC2141] and [RFC3406].
本节根据[RFC2141]和[RFC3406]提供了“警报”URN命名空间标识符（NID）的注册模板。
Namespace ID: alert
命名空间ID:警报
Registration Information: Registration version: 1 Registration date: 2014-12-10
注册信息：注册版本：1注册日期：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.org
名称空间的声明注册人：注册组织：实时应用程序和基础设施领域，IETF指定联系人：RAI领域主管指定联系人电子邮件：RAI-ads@ietf.org
Declaration of syntactic structure:
句法结构声明：
The Namespace Specific String (NSS) for the "alert" URNs is called an <alert-identifier> and has a hierarchical structure. The first colon-separated part after "alert" is called the <alert-category>; the parts to the right of that are <alert-ind-part>s, and together form the <alert-indication>. The general form is urn:alert:<alert-category>:<alert-indication>.
“警报”URN的命名空间特定字符串（NSS）称为<alert identifier>，具有层次结构。“警报”之后的第一个冒号分隔部分称为<alert category>；右侧的零件为<alert ind part>s，共同构成<alert ind indication>。一般形式为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.
本文档中定义了以下<alert category>标识符：“服务”、“优先级”、“来源”、“持续时间”、“延迟”和“区域设置”。<alert category>集合将来可以通过标准化或私人行动进行扩展。<alert category>s描述了报警信号的不同特征。
Any "alert" URN defined in this specification is syntactically valid for ring and ringback tones and can be used in SIP INVITE requests or in provisional 1xx responses excepting the 100 response.
本规范中定义的任何“警报”URN在语法上对铃声和回铃音有效，可用于SIP INVITE请求或临时1xx响应（100响应除外）。
The ABNF [RFC5234] for the "alert" URNs is shown below:
“警报”URN的ABNF[RFC5234]如下所示：
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-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).
<alert label>s必须符合非保留LDH标签的语法[RFC5890]。已注册的骨灰盒及其组件必须按注册（包括外壳）进行传输。
Relevant ancillary documentation: RFC 7462
相关辅助文件：RFC 7462
Namespace considerations: This specification defines a URN namespace "alert" for URNs representing signals or renderings that are presented to users to inform them of events and actions. The initial usage is to specify ring tones and ringback tones when dialogs are established in SIP, but they can also be used for other communication-initiation protocols (e.g., H.323), and more generally, in any situation (e.g., web pages or endpoint device software configurations) to describe how a user should be signaled.
名称空间注意事项：本规范为表示信号或呈现的URN定义了URN名称空间“警报”，这些信号或呈现用于通知用户事件和操作。最初的用途是在SIP中建立对话时指定铃声和回铃音，但它们也可用于其他通信发起协议（例如，H.323），更一般地，在任何情况下（例如，网页或终端设备软件配置），以描述应如何向用户发信号。
An "alert" URN does not describe a complete signal, but rather it describes a particular characteristic of the event it is signaling or a feature of the signal to be presented. The complete specification of the signal is a sequence of "alert" URNs specifying the desired characteristics/significance of the signal in priority order, with the most important aspects specified by the earlier URNs. This allows the sender of a sequence of URNs to compose very detailed specifications from a restricted set of URNs, and to clearly specify which aspects of the specification it considers most important.
“警报”URN并不描述一个完整的信号，而是描述它正在发送信号的事件的特定特征或要呈现的信号的特征。信号的完整规范是一系列“警报”URN，按优先级顺序指定信号的期望特性/重要性，最重要的方面由早期URN指定。这允许URN序列的发送者从一组受限的URN组成非常详细的规范，并明确指定它认为规范的哪些方面最重要。
The initial scope of usage is in the Alert-Info header field, in initial INVITE requests (to indicate how the called user should be alerted regarding the call) and non-100 provisional (1xx) responses to those INVITE requests (to indicate the ringback, how the calling user should be alerted regarding the progress of the call).
初始使用范围在Alert Info header（警报信息标题）字段中，在初始INVITE请求（指示应如何向被叫用户发出有关呼叫的警报）和对这些INVITE请求的非100临时（1xx）响应（指示回铃，指示应如何向主叫用户发出有关呼叫进度的警报）中。
In order to ensure widespread adoption of these URNs for indicating ring tones and ringback tones, the scheme must allow replication of the current diversity of these tones. Currently, these tones vary between the PSTNs of different nations and between equipment supplied by different vendors. Thus, the scheme must accommodate national variations and proprietary extensions in a way that minimizes the information that is lost during interoperation between systems that follow different national variations or that are supplied by different vendors.
为了确保广泛采用这些URN来指示铃声和回铃音，该方案必须允许复制这些铃声的当前多样性。目前，这些音调在不同国家的PSTN之间以及不同供应商提供的设备之间有所不同。因此，该方案必须适应国家变化和专有扩展，以最大限度地减少在遵循不同国家变化或由不同供应商提供的系统之间的互操作过程中丢失的信息。
The scheme allows definition of private extension URNs that refine and extend the information provided by standard URNs. Private extension URNs can also refine and extend the information provided by other private extension URNs. Private extensions can also define entirely new categories of information about calls. We expect these extensions to be used extensively when existing PBX products are converted to support SIP operation.
该方案允许定义专用扩展URN，以细化和扩展标准URN提供的信息。专用扩展URN还可以细化和扩展其他专用扩展URN提供的信息。私有扩展还可以定义有关呼叫的全新信息类别。当现有的PBX产品被转换为支持SIP操作时，我们期望这些扩展将被广泛使用。
The device that receives an Alert-Info header field containing a sequence of "alert" URNs provides to the user a rendering that represents the semantic content of the URNs. The device is given great leeway in choosing the rendering, but it is constrained by rules that maximize interoperability between systems that support different sets of private extensions. In particular, earlier URNs in the sequence have priority of expression over later URNs in the sequence, and URNs that are not usable in their entirety (because they contain unknown extensions or are incompatible with previous URNs) are successively truncated in attempt to construct a URN that retains some information and is renderable in the context.
接收包含“警报”URN序列的警报信息标题字段的设备向用户提供表示URN语义内容的呈现。设备在选择渲染时有很大的自由度，但它受到规则的限制，这些规则最大限度地提高了支持不同私有扩展集的系统之间的互操作性。特别是，序列中较早的URN的表达优先级高于序列中较晚的URN，并且URN不能全部使用（因为它们包含未知扩展或与先前的URN不兼容）连续截断，以尝试构造保留某些信息并可在上下文中呈现的URN。
Due to the practical importance of private extensions for the adoption of URNs for alerting calls and the very specific rules for private extensions and the corresponding processing rules that allow quality interoperation in the face of private extensions, the requirements of the "alert" URN scheme cannot be met by a fixed enumeration of URNs and corresponding meanings. In particular, the existing namespace "urn:ietf:params" does not suffice (unless the private extension apparatus is applied to that namespace).
由于专用分机对于采用URN进行报警呼叫的实际重要性，以及专用分机的非常具体的规则和相应的处理规则，这些规则允许在面对专用分机时进行高质量的互操作，“警报”的要求URN方案不能由URN和相应含义的固定枚举来满足。特别是，现有名称空间“urn:ietf:params”是不够的（除非专用扩展设备应用于该名称空间）。
There do not appear to be other URN namespaces that uniquely identify the semantic of a signal or rendering feature. Unlike most other currently registered URN namespaces, the "alert" URN does not identify documents and protocol objects (e.g., [RFC3044], [RFC3120], [RFC3187], [RFC3188], [RFC4179], [RFC4195], [RFC4198]), types of telecommunications equipment [RFC4152], people, or organizations [RFC3043].
似乎不存在唯一标识信号或渲染功能语义的其他URN名称空间。与大多数其他当前注册的URN名称空间不同，“警报”URN不识别文档和协议对象（例如，[RFC3044]、[RFC3120]、[RFC3187]、[RFC3188]、[RFC4179]、[RFC4195]、[RFC4198]）、电信设备类型[RFC4152]、人员或组织[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 is being presented to a user. Removing an <alert-ind-part> from the end of an <alert-URN> (which has more than one <alert-ind-part>) creates a shorter <alert-URN> with a less specific meaning; the set of dialogs to which the longer <alert-URN> applies is necessarily a subset of the set of dialogs to which the shorter <alert-URN> applies. (If the starting <alert-URN> contains only one <alert-ind-part>, and thus the <alert-ind-part> cannot be removed to make a shorter <alert-URN>, we can consider the set of dialogs to which the <alert-URN> applies to be a subset of the set of all dialogs.)
<alert URN>s是层次标识符。<alert URN>断言所提供的SIP对话框的某些事实或特征，或该对话框应如何呈现给用户或如何呈现给用户的某些事实或特征。从<alert URN>（具有多个<alert ind part>）的末尾删除<alert ind part>，将创建一个较短的<alert URN>，其含义不太具体；较长的<alert URN>应用的对话框集必须是较短的<alert URN>应用的对话框集的子集。（如果开始<警报URN >只包含一个警告的IN部分>，因此不能删除<警报Enter部分>以更短的<警报URN >，我们可以考虑<警报URN >所适用的对话框集合，作为所有对话框集合的子集。
The specific criteria defining the subset to which the longer <alert-URN> applies, within the larger set of dialogs, is considered to be the meaning of the final <alert-ind-part>. This meaning is relative to and depends upon the preceding <alert-
在较大的对话框集中，定义较长的<alert URN>适用的子集的特定标准被认为是最终<alert ind part>的含义。此含义与前面的警告相关，并取决于前面的警告-
category> and <alert-ind-part>s (if any). The meanings of two <alert-ind-part>s that are textually the same but are preceded by different <alert-category>s or <alert-ind-part>s have no necessary connection. (An <alert-category> considered alone has no meaning in this sense.)
类别>和<alert ind part>s（如有）。两个<alert ind part>s的含义在文本上相同，但前面有不同的<alert category>s或<alert ind part>s，它们之间没有必要的联系。（单独考虑的<alert category>在这个意义上没有任何意义。）
The organization owning the <provider> within a <private-name> specifies the meaning of that <private-name> when it is used as an <alert-ind-part>. (The organization owning a <provider> is specified by the registry described in Section 9.3.)
在<private name>中拥有<provider>的组织指定该<private name>用作<alert ind part>时的含义。（拥有<provider>的组织由第9.3节所述的注册中心指定。）
The organization owning the <provider> within a <private-name> (in either an <alert-category> or an <alert-ind-part>) specifies the meaning of each <alert-ind-part>, which is an <alert-label> that follows that <private-name> and that precedes the next <alert-ind-part> which is a <private-name> (if any).
拥有<private name>中<provider>的组织（在<alert category>或<alert ind part>中）指定每个<alert ind part>的含义，每个<alert ind part>是<private name>之后的<alert标签>，位于下一个<alert ind part>之前，后者是<private name>（如果有）。
The meaning of all other <alert-ind-part>s (i.e., those that are not <private-name>s and do not follow a <private-name>) is defined by standardization.
所有其他<alert ind part>的含义（即那些不是<private name>s且不遵循<private name>的部分）由标准化定义。
Community considerations: The "alert" URNs are relevant to a large cross-section of Internet users, namely those that initiate and receive communication connections via the Session Initiation Protocol. These users include both technical and non-technical users, on a variety of devices and with a variety of perception capabilities. The "alert" URNs will allow Internet users to receive more information about offered calls and enable them to better make decisions about accepting an offered call, and to get better feedback on the progress of a call they have made.
社区注意事项：“警报”URN与大量Internet用户相关，即通过会话启动协议启动和接收通信连接的用户。这些用户包括技术用户和非技术用户，使用各种设备并具有各种感知能力。“警报”URN将允许互联网用户接收更多有关提供的呼叫的信息，使他们能够更好地决定是否接受提供的呼叫，并获得关于他们所拨打的呼叫进度的更好反馈。
User interfaces that utilize alternative sensory modes can better render the ring and ringback tones based on the "alert" URNs because the URNs provide more detailed information regarding the intention of communications than is provided by current SIP mechanisms.
利用替代感官模式的用户界面可以基于“警报”URN更好地呈现铃声和回铃音，因为URN提供了比当前SIP机制提供的更详细的关于通信意图的信息。
Process of identifier assignment:
标识符分配过程：
Assignment of standardized "alert" URNs is by insertion into the IANA registry described in Section 9.2. This process defines the meanings of <alert-ind-part>s that have standardized meanings, as described in "Namespace Considerations".
标准化“警报”URN的分配是通过插入第9.2节所述的IANA注册表进行的。此过程定义了具有标准化含义的<alert ind part>s的含义，如“名称空间注意事项”中所述。
A new URN MUST NOT be registered if it is equal by the comparison rules to an already registered URN.
如果新URN与已注册的URN根据比较规则相等，则不得注册该URN。
Private extensions are "alert" URNs that include <alert-ind-part>s that are <private-name>s and <alert-label>s that appear after a <private-name> (either as an <alert-category> or an <alert-indication>). If such an <alert-ind-part> is a <private-name>, its meaning is defined by the organization that owns the <provider> that appears in the <private-name>. If the <alert-ind-part> is an <alert-label>, its meaning is defined by the organization that owns the <provider> that appears in the closest <private-name> preceding the <alert-label>. The organization owning a <provider> is specified by the registry described in Section 9.3.
专用扩展是“警报”URN，包括<alert ind part>s，它们是<Private name>s和<alert label>s，出现在<Private name>之后（作为<alert category>或<alert indication>）。如果此类<alert ind part>是<private name>，则其含义由拥有<private name>中出现的<provider>的组织定义。如果<alert ind part>是一个<alert label>，其含义由拥有<provider>的组织定义，该<provider>出现在<alert label>前面最近的<private name>中。拥有<provider>的组织由第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 a rendered at the caller's or callee's end device.
标识符唯一性和持久性注意事项：“警报”URN标识呼叫的语义特征或呼叫警报应如何在呼叫者或被呼叫者的终端设备上呈现的感官特征。
For standardized <alert-ind-part>s in URNs, uniqueness and persistence of their meanings is guaranteed by the fact that they are registered with IANA in accordance with 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.
对于URN中的标准化<alert ind part>s，其含义的唯一性和持久性由其按照第9.2节的程序在IANA注册的事实保证；特定“警报”URN标识的功能与任何其他标准化“警报”URN标识的功能不同。
Assuring uniqueness and persistence of the meanings of private extensions 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 a syntactically determined <provider> part within the URN.
确保私有扩展含义的唯一性和持久性被委托给定义私有扩展的组织。负责特定“警报”URN中特定<alert ind part>的组织是URN中按语法确定的<provider>部分的所有者。
An organization SHOULD use only one <provider> value for all of the <private-name>s it defines.
一个组织应该只为其定义的所有<private name>使用一个<provider>值。
Process for identifier resolution: The process of identifier resolution is the process by which a rendering device chooses a rendering to represent a sequence of "alert" URNs. The device is allowed great leeway in making this 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.
标识符解析过程：标识符解析过程是渲染设备选择渲染以表示“警报”URN序列的过程。设备在做出选择时有很大的余地，但过程必须遵守第11.1节的规定。该设备预计将提供与用户在其文化背景中指定给骨灰盒的含义相关联的渲染。第12.1节给出了非规范性示例解析算法。
Rules for lexical equivalence: "alert" URNs are compared according to case-insensitive string equality.
词汇等价规则：根据不区分大小写的字符串相等性比较“警报”URN。
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], that is, "ordinary ASCII labels". Future standardization may allow <alert-label>s that are A-labels [RFC5890], and so interpreters of "alert" URNs MUST operate correctly (per Section 11.1) when given such URNs as input.
符合URN语法：所有“警报”URN必须符合第7节“语法结构声明”中的ABNF。ABNF是通用URN语法[RFC2141]的子集<警报标签>被限制为非保留LDH标签[RFC5890]，即“普通ASCII标签”。未来的标准化可能允许A标签[RFC5890]的<alert label>s，因此当将“alert”URN作为输入时，“alert”URN的解释器必须正确运行（根据第11.1节）。
Validation mechanism: An "alert" URN containing no private extensions can be validated based on the IANA registry of standardized "alert" URNs. Validating an "alert" URN containing private extensions requires obtaining information regarding the private extensions defined by the organization that owns the <provider> in the relevant <private-name>. The identity of the organization can be determined from the IANA registry described in Section 9.2. However, if an "alert" URN contains at least one <alert-identifier> that precedes the first <private-name>, the portion of the "alert" URN that precedes the first <private-name> must itself be a valid standardized "alert" URN, which may be validated as above.
验证机制：不包含私有扩展的“警报”URN可以基于标准化“警报”URN的IANA注册表进行验证。要验证包含专用扩展的“警报”URN，需要获取有关拥有相关<private name>中的<provider>的组织定义的专用扩展的信息。组织的身份可以从第9.2节所述的IANA注册中心确定。但是，如果“警报”URN至少包含一个位于第一个<private name>之前的<alert identifier>，则位于第一个<private name>之前的“警报”URN部分本身必须是有效的标准化“警报”URN，可以如上所述进行验证。
Scope: The scope for this URN is public and global.
作用域：此URN的作用域是公共的和全局的。
The following <alert-category> values are defined in this document:
本文档中定义了以下<alert category>值：
- service - source - priority - duration - delay - locale
- 服务-源-优先级-持续时间-延迟-区域设置
This section describes the "alert" URN indication values for the <alert-category>s defined in this document.
本节描述了本文档中定义的<alert category>s的“alert”URN指示值。
For each <alert-category>, a default <alert-indication> is defined, which is essentially a no-operation "alert" URN and should be treated by the UA as if no "alert" URN for the respective category is present. "alert" URN default indications are most useful when Alert-Info header field parameters are being used. For example, in
对于每个<alert category>，都定义了一个默认的<alert indication>，它本质上是一个无操作“alert”URN，UA应将其视为各个类别没有“alert”URN。“警报”URN默认指示在使用警报信息标题字段参数时最有用。例如，在
[RFC7463], an Alert-Info header field needs to be present containing the "appearance" parameter, but no special ringtone need be specified.
[RFC7463]，需要存在包含“外观”参数的警报信息标题字段，但不需要指定特殊铃声。
The <private-name> syntax is used for extensions defined by independent organizations, as described in Section 10.2.
<private name>语法用于独立组织定义的扩展，如第10.2节所述。
- normal (default) - call-waiting - forward - recall:callback - recall:hold - recall:transfer - <private-name>
- 正常（默认）-呼叫等待-转发-调用：回调-调用：保留-调用：转移-<private name>
Examples: <urn:alert:service:call-waiting> or <urn:alert:service:recall:transfer>.
示例：<urn:alert:service:call waiting>或<urn:alert:service:recall:transfer>。
- unclassified (default) - internal - external - friend - family - <private-name>
- 未分类（默认）-内部-外部-朋友-家庭-<private name>
(These <alert-indication>s will rarely be provided by the sending UA; rather they will usually be inserted by a proxy acting on behalf of the recipient UA to inform the recipient UA about the origins of a call.)
（这些<alert indication>s很少由发送UA提供；相反，它们通常由代表接收方UA的代理插入，以告知接收方UA呼叫的来源。）
Examples: <urn:alert:source:external>.
示例：<urn:alert:source:external>。
- normal (default) - low - high - <private-name>
- 正常（默认）-低-高-<private name>
Examples: <urn:alert:priority:high>.
示例：<urn:alert:priority:high>。
- normal (default) - short - long - <private-name>
- 正常（默认）-短-长-<private name>
Examples: <urn:alert:duration:short>.
示例：<urn:alert:duration:short>。
- none (default) - yes - <private-name>
- 无（默认）-是-<private name>
Examples: <urn:alert:delay:yes>.
示例：<urn:alert:delay:yes>。
- default (default) - country:<ISO 3166-1 country code> - <private-name>
- 默认（默认）-国家：<ISO 3166-1国家代码>-<private name>
The ISO 3166-1 country code [ISO3166-1] is used to inform the renderer on the other side of the call that a country-specific rendering should be used. For example, to indicate ringback tones from South Africa, the following URN would be used: <urn:alert:locale:country:za>.
ISO 3166-1国家代码[ISO3166-1]用于通知调用另一端的渲染器应使用特定于国家的渲染。例如，要指示来自南非的回铃音，将使用以下URN:<URN:alert:locale:country:za>。
This section registers a new URN namespace identifier (NID), "alert", in accordance with [RFC3406] with the registration template provided in Section 7.
本节根据[RFC3406]和第7节提供的注册模板注册新的URN命名空间标识符（NID），“警报”。
Standard "alert" URNs are recorded as <alert-identifier>s in a new registry called "Alert URN Identifiers". Thus, creating a new standard "alert" URN requires IANA action. IANA manages the "Alert URN Identifiers" registry under the policy 'Specification Required' [RFC5226] following the guidelines in Section 10.1.
标准的“警报”URN在名为“警报URN标识符”的新注册表中记录为<alert identifier>s。因此，创建新的标准“警报”URN需要IANA操作。IANA按照第10.1节中的指导原则，按照“所需规范”[RFC5226]策略管理“警报URN标识符”注册表。
The registry contains entries in the following 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>
<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)
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 value that is registered, which is either: (1) an <alert-category> value, (2) an <alert-identifier> value, composed of an <alert-category> followed by an <alert-indication>, in turn composed of one or more <alert-label>s, or (3) a pattern for <alert-identifier> values (e.g., for the "locale" <alert-category> in Section 9.2.1.6).
每行中的第一个值是注册的值，它可以是：（1）一个<alert category>值，（2）一个<alert identifier>值，由一个<alert category>后接一个<alert indication>，依次由一个或多个<alert label>值组成，或者（3）一个<alert identifier>值模式（例如，用于“区域设置”）<alert category>第9.2.1.6节）。
The second value in each row is the reference to the required specification for the value.
每行中的第二个值是对该值所需规范的引用。
The third value in each row is a short description of the semantics of the value.
每行中的第三个值是该值语义的简短描述。
A new URN MUST NOT be registered if it is equal by the comparison rules (that is, case-insensitive string comparison) to an already registered URN.
如果比较规则（即不区分大小写的字符串比较）与已注册的URN相等，则不得注册新URN。
<alert-category> and <alert-identifier> values that contain <private-name>s are not managed by IANA. The process of assigning these values is described in Section 10.2.
包含<private name>s的<alert category>和<alert identifier>值不由IANA管理。第10.2节描述了分配这些值的过程。
This document defines the <alert-category>s 'service', 'source', 'priority', 'duration', 'delay' and 'locale'. The entries to be added to the 'Alert URN Identifiers' registry table for each <alert-category> are given in the respective sections below.
本文档定义了<alert category>s的“服务”、“源”、“优先级”、“持续时间”、“延迟”和“区域设置”。下面各节给出了每个<Alert category>要添加到“Alert URN Identifiers”注册表表中的条目。
The following table contains the initial IANA registration for the "service" <alert-category> and <alert-identifier>s. The value of this indicator is set to a value different from "normal" if the caller or callee is informed that a specific telephony service has been initiated.
下表包含“服务”<alert category>和<alert identifier>s的初始IANA注册。如果通知呼叫者或被呼叫者已启动特定电话服务，则此指示器的值将设置为不同于“正常”的值。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
service RFC 7462 Specific telephony
service used in this
call
<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)
服务：普通RFC 7462普通环/环回渲染（默认值）
service:call-waiting RFC 7462 Call waiting was initiated at the other side of the call
服务：呼叫等待RFC 7462呼叫等待在呼叫的另一端启动
service:forward RFC 7462 Call has been forwarded
服务：转发RFC 7462呼叫已被转发
service:recall:callback RFC 7462 Recall due to callback
服务：召回：召回RFC 7462因召回而召回
service:recall:hold RFC 7462 Recall due to call hold
服务：召回：因呼叫保持而暂停RFC 7462召回
service:recall:transfer RFC 7462 Recall due to transfer
服务：召回：转移RFC 7462因转移而召回
The following table contains the initial IANA registration for the "source" <alert-category> and <alert-identifier>. The value of this indicator provides information about the user at the other side of the call.
下表包含“源”<alert category>和<alert identifier>的初始IANA注册。此指示器的值提供有关呼叫另一端用户的信息。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
source RFC 7462 Classification
of the other party
to 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)
来源：未分类RFC 7462未分类环/环回渲染（默认值）
source:internal RFC 7462 User at the other side of the call is internal to the enterprise or PBX system
来源：呼叫另一端的内部RFC 7462用户是企业或PBX系统的内部用户
source:external RFC 7462 User at the other side of the call is external to the enterprise or PBX system
来源：呼叫另一端的外部RFC 7462用户位于企业或PBX系统外部
source:friend RFC 7462 User at the other side of the call is a friend
来源：friend RFC 7462呼叫另一端的用户是朋友
source:family RFC 7462 User at the other side of the call is a family member
来源：呼叫另一端的家庭RFC 7462用户是家庭成员
The following table contains the initial IANA registration for the "priority" <alert-category> and <alert-identifier>s. The value of this indicator provides information about the priority the alerted user should give to the call.
下表包含“优先级”<alert category>和<alert identifier>s的初始IANA注册。此指示器的值提供有关被提醒用户应给予呼叫的优先级的信息。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
priority RFC 7462 Priority of 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)
优先级：普通RFC 7462普通环/环回渲染（默认值）
priority:low RFC 7462 Low priority call
优先级：低RFC 7462低优先级呼叫
priority:high RFC 7462 High priority call
优先级：高RFC 7462高优先级呼叫
The following table contains the initial IANA registration for the "duration" <alert-category> and <alert-identifier>s. The value of this indicator provides information about the duration of the alerting signals compared to the default alerting signals.
下表包含“持续时间”<alert category>和<alert identifier>s的初始IANA注册。该指示器的值提供了与默认报警信号相比的报警信号持续时间的信息。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
duration RFC 7462 Duration of alerting signal
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
duration RFC 7462 Duration of alerting signal
duration:normal RFC 7462 Normal ring/ringback rendering (default value)
持续时间：正常RFC 7462正常环/环回渲染（默认值）
duration:short RFC 7462 Shorter than normal
持续时间：短RFC 7462比正常时间短
duration:long RFC 7462 Longer than normal
持续时间：长RFC 7462比正常时间长
The following table contains the initial IANA registration for the "delay" <alert-category> and <alert-identifier>s. The value of this indicator provides information about whether the presentation of the alerting signal should be delayed compared to the default presentation process. For more details see Section 6.1.6.
下表包含“延迟”<alert category>和<alert identifier>s的初始IANA注册。此指示器的值提供了与默认显示过程相比，报警信号的显示是否应延迟的信息。有关更多详细信息，请参见第6.1.6节。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
delay RFC 7462 Delay of rendering
of alerting signal
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
delay RFC 7462 Delay of rendering
of alerting signal
delay:none RFC 7462 Immediate alerting (default value)
延迟：无RFC 7462即时警报（默认值）
delay:yes RFC 7462 Delayed alerting
延迟：是RFC 7462延迟警报
The following table contains the initial IANA registration for the "locale" <alert-category> and <alert-identifier>s. The value of this indicator provides information about whether the alerting signals characteristic of the specified location should be used.
下表包含“区域设置”<alert category>和<alert identifier>s的初始IANA注册。该指示器的值提供有关是否应使用指定位置的报警信号特征的信息。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
locale RFC 7462 Location-specific
alerting signals
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
locale RFC 7462 Location-specific
alerting signals
locale:default RFC 7462 Alerting not location specific (default value)
区域设置：默认RFC 7462警报不特定于位置（默认值）
locale:country:<ISO 3166-1 country code> RFC 7462 Alerting according to the conventions of the specified country
地区：国家：<ISO 3166-1国家代码>RFC 7462根据指定国家的惯例发出警报
Values of <provider>, which are used to create <private-name>s, are recorded in a new registry called "Alert URN Providers". (Private extension "alert" URNs that are defined are not recorded by IANA.) The registry is managed by IANA under the policy 'First Come First Served' [RFC5226].
用于创建<private name>s的<provider>值记录在名为“警报URN提供程序”的新注册表中。（IANA不记录定义的专用扩展“警报”URN。）注册中心由IANA根据“先到先得”策略进行管理[RFC5226]。
The registry contains entries in the following format:
注册表包含以下格式的条目：
<provider> Registrant Contact URI
---------------------------------------------------------------------
example IETF rai-ads@ietf.org
<provider> Registrant Contact URI
---------------------------------------------------------------------
example IETF rai-ads@ietf.org
The first value in each row is the <provider> value that is registered. This value is case-insensitive and MUST comply with the syntax for Non-Reserved LDH labels [RFC5890].
每行中的第一个值是注册的<provider>值。此值不区分大小写，必须符合非保留LDH标签的语法[RFC5890]。
The second value in each row is the name of the registrant of the value.
每行中的第二个值是该值的注册人的名称。
The third value is a contact URI for the registrant.
第三个值是注册人的联系人URI。
The registry initially contains the one entry shown above, which can be used for constructing examples of private extension URNs.
注册表最初包含上面显示的一个条目，可用于构造私有扩展URN的示例。
The set of "alert" URNs is extensible. An extension "at the top level" creates a new <alert-category> (which represents 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" creates a subdivision of an existing <alert-indication> (that has one <alert-ind-part>), etc. URNs allow (in principle) indefinite subdivision of existing <alert-indication> values, although most of the standard "alert" URNs have only one level of subdivision and a few have two levels of subdivision.
“警报”URN集是可扩展的。“顶层”扩展创建新的<alert category>（表示新的警报特性），“第二层”扩展为现有的<alert category>创建新的<alert indication>值，“第三层”扩展为现有的<alert ind part>（具有一个<alert ind part>）创建细分，等。URN（原则上）允许对现有的<alert indication>值进行无限细分，尽管大多数标准“alert”URN只有一个细分级别，少数有两个细分级别。
Extensions, either 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.
新的<alert category>独立于所有先前存在的<alert category>s：对于新<alert category>中的一个<alert identifier>与先前存在的任何<alert category>中的任何一个<alert identifier>的任意组合，存在可有效应用该组合的潜在调用。
A new <alert-identifier> that has more than one <alert-ind-part> is a semantic refinement of a parent <alert-identifier>, the parent being obtained by deleting the final <alert-ind-part>. The new <alert-identifier> has as parent the most specific previously existing <alert-identifier> whose meaning includes all potential calls to which the new <alert-identifier> could be meaningfully applied.
具有多个<alert ind part>的新<alert identifier>是父级<alert identifier>的语义细化，父级通过删除最终的<alert ind part>获得。新的<alert identifier>具有以前存在的最具体的<alert identifier>，其含义包括新的<alert identifier>可以有效应用的所有潜在调用。
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.
新的<alert identifier>与任何同级<alert identifier>（<alert identifier>仅在最后的<alert ind part>中不同）没有语义重叠。也就是说，不可能存在对这两个<alert identifier>s都可以有效应用的调用。
The process for defining new standard "alert" URNs is described in Section 9.2; all such definitions require registering a publicly available specification. The process for defining new "alert" URNs via the private extension mechanism is described in Section 10.2.
第9.2节描述了定义新标准“警报”URN的过程；所有这些定义都需要注册一个公开的规范。第10.2节描述了通过专用扩展机制定义新“警报”URN的过程。
The <private-name> syntax is used to create private extensions, extensions that are not registered with IANA. The <private-name> has the form of an <alert-label> followed by "@" and then a <provider> that designates the organization defining the extension. Both <alert-label> and <provider> have the same syntax as an ordinary ASCII DNS label. A private extension URN is created by using a <private-name> as either an <alert-category> or an <alert-ind-part>.
<private name>语法用于创建私有扩展，即未向IANA注册的扩展。<private name>的格式为<alert label>，后跟“@”，然后是<provider>，指定定义扩展的组织。<alert label>和<provider>与普通ASCII DNS标签的语法相同。通过将<private name>用作<alert category>或<alert ind part>来创建专用扩展URN。
If the <private-name> is used as an <alert-category>, the characteristic of the alerting signal that the <alert-category> describes is defined by the organization. If the <private-name> is used as the first <alert-ind-part>, the organization defines an alternative value for the standardized <alert-category> of the URN. If the <private-name> is used as the second or later <alert-ind-part>, the organization defines the meaning of the URN as a subset of the meaning of the shorter URN resulting when the <private-name> (and any subsequent <alert-ind-part>s) are removed.
如果<private name>用作<alert category>，则<alert category>描述的报警信号的特征由组织定义。如果<private name>用作第一个<alert ind part>，则组织将为URN的标准化<alert category>定义一个备选值。如果<private name>用作第二个或更高版本的<alert ind part>，则组织将URN的含义定义为删除<private name>（以及任何后续<alert ind part>时产生的较短URN含义的子集。
Within a URN, all <alert-label> components that follow a <private-name> but are before any following <private-name>s are additional private extensions whose meaning is defined by the organization defining the nearest preceding <private-name>.
在URN中，紧跟在<private name>之后但在任何<private name>之前的所有<alert label>组件都是附加的私有扩展，其含义由定义最近的<private name>的组织定义。
A URN that contains a private extension can be further subdivided by the private extension of a different organization: the second organization appends an <alert-ind-part> that is a <private-name> containing a the <provider> value for the second organization.
包含私有扩展的URN可以由不同组织的私有扩展进一步细分：第二个组织附加一个<alert ind part>，该<alert ind part>是一个<private name>，包含第二个组织的<provider>值。
The meaning of a <private-name> or an <alert-label> that is defined privately (because of a preceding <private-name>) is only fixed within the context provided by the sequence of preceding <alert-name>s; these components have no meaning in isolation and there is no necessary relationship between the meaning of textually identical <alert-name>s that are preceded by different sequences of <alert-name>s.
私人定义的<private name>或<alert label>的含义（由于前面的<private name>）仅在前面的<alert name>序列提供的上下文中固定；这些组件没有单独的意义，并且前面有不同序列的<alert name>s的文本相同<alert name>s的意义之间没有必要的关系。
Creating private extension "alert" URNs is not a Standards Action and they are not registered with IANA.
创建专用扩展“警报”URN不是标准操作，并且它们未向IANA注册。
The organization defining a private extension is responsible for ensuring persistence of the meaning of the private extension.
定义私有扩展的组织负责确保私有扩展含义的持久性。
Private extensions MUST conform to the principles of Section 10.1, both in regard to previously existing standard <alert-URN>s and in regard to any previously existing private extensions using the same <provider> value, and any other private extensions that 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.)
私人扩展必须符合第10.1节的原则，既涉及先前存在的标准<alert URN>s，也涉及使用相同<provider>值的任何先前存在的私人扩展，以及组织知道的任何其他私人扩展。特别是，私有扩展不得复制任何标准URN或组织知道的任何私有扩展。（在上述任何一种情况下，组织必须使用现有的URN来实现其目的。）
An organization obtains a <provider> value for constructing <private-name>s by registering the value with IANA as provided in Section 9.3.
按照第9.3节的规定，组织通过向IANA注册值来获得用于构建<private name>s的<provider>值。
The organization registering the <provider> "example" can define distinctive versions of <urn:alert:service:call-waiting>:
注册<provider>“示例”的组织可以定义<urn:alert:service:call waiting>的不同版本：
urn:alert:service:call-waiting:abc@example
urn:alert:service:call-waiting:abc@example
urn:alert:service:call-waiting:def@example
urn:alert:service:call-waiting:def@example
It can create a more specialized URN that applies to a subset of the situations to which the first URN above applies:
它可以创建一个更专门的URN，该URN适用于上述第一个URN适用的情况的子集：
urn:alert:service:call-waiting:abc@example:xyz
urn:alert:service:call-waiting:abc@example:xyz
Because "xyz" follows "abc@example" (and there is no intervening <private-name>), its meaning is defined by the owner of the <provider> "example".
因为“xyz”跟在后面“abc@example“（且不存在干预性的<private name>），其含义由<provider>“示例”的所有者定义。
The organization registering the <provider> "example" can define URNs in the "service" category to express a new service that is not covered by any of the standardized URNs:
注册<provider>“示例”的组织可以在“服务”类别中定义URN，以表示任何标准化URN均未涵盖的新服务：
urn:alert:service:ghi@example
urn:alert:service:ghi@example
However, before defining such a URN, the organization should verify that the set of calls to which the URN applies 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.
但是，在定义这样一个URN之前，组织应该验证URN应用的调用集不是某些现有URN调用集的子集。如果它是一个子集，那么扩展URN应该是现有URN的一个子集。
The organization registering the <provider> "example" can define an extension <alert-category> named "jkl@example" with two <alert-indication>s "a1" and "a2":
注册<provider>“示例”的组织可以定义扩展名<alert category>jkl@example“带有两个<警报指示>s“a1”和“a2”：
urn:alert:jkl@example:a1
urn:alert:jkl@example:a1
urn:alert:jkl@example:a2
urn:alert:jkl@example:a2
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 to alert for incoming calls that are directed to different directory numbers. These ring patterns are composed of groups of ring sounds that have particular patterns of lengths.
注册<provider>“foo”的组织希望定义一组URN，这些URN指定“独特铃声”服务使用的不同铃声模式，以提醒指向不同目录号码的来电。这些环形模式由一组具有特定长度模式的环形声音组成。
The company can create a private <alert-category> "distinctive@foo", and within it assign three 'alert' URNs that indicate the three different ring patterns used by the company's service:
公司可以创建一个私有的<alert category>”distinctive@foo，并在其中指定三个“警报”骨灰盒，指示公司服务使用的三种不同的环形图案：
urn:alert:distinctive@foo:long-long
urn:alert:distinctive@foo:long-long
urn:alert:distinctive@foo:short-long-short
urn:alert:distinctive@foo:short-long-short
urn:alert:distinctive@foo:short-short-long
urn:alert:distinctive@foo:short-short-long
Later, the company registering the <provider> "bar" wants to define an additional 'alert' URN for the ring pattern "short short", which it uses to support a fourth directory number for a phone instrument.
稍后，注册<provider>的公司希望为环形模式“short-short”定义一个额外的“alert”URN，该模式用于支持电话设备的第四个目录号。
The company can create a <private-name> to be used with the "distinctive@foo" <alert-category>:
公司可以创建一个<private name>用于“distinctive@foo“<alert category>：
urn:alert:distinctive@foo:short-short@bar
urn:alert:distinctive@foo:short-short@bar
This section describes combination rules for the case when all the Alert-Info header fields only contain "alert" URNs. Other combinations of URIs in the Alert-Info header fields of the same SIP message are not defined in this specification.
本节介绍所有警报信息标题字段仅包含“警报”URN时的组合规则。本规范中未定义同一SIP消息的警报信息头字段中的其他URI组合。
In many cases, more than one URN will be needed to fully define a particular tone. This is done by including multiple "alert" URNs, in one or more Alert-Info header fields in a request or a response. For example, an internal, priority call could be indicated by Alert-Info: <urn:alert:source:internal>, <urn:alert:priority:high>. A priority call-waiting tone could be indicated by Alert-Info: <urn:alert:service:call-waiting>, <urn:alert:priority:high>.
在许多情况下，需要多个URN才能完全定义特定的音调。这是通过在请求或响应的一个或多个警报信息标题字段中包含多个“警报”URN来实现的。例如，内部优先级调用可以由警报信息指示：<urn:Alert:source:internal>，<urn:Alert:priority:high>。优先级呼叫等待音可以通过警报信息指示：<urn:Alert:service:call waiting>，<urn:Alert:priority:high>。
The sender of the Alert-Info header field may include an arbitrary list of "alert" URNs, even if they are redundant or contradictory. An earlier URN has priority over any later contradictory URN. This allows any element to modify a list of URNs to require a feature value (by adding a URN at the beginning of the list) or to suggest a feature value (by adding a URN at the end of the list).
“警报信息”标题字段的发件人可能包括任意“警报”URN列表，即使这些URN是冗余的或相互矛盾的。较早的URN优先于任何较晚的URN。这允许任何元素修改URN列表以要求特征值（通过在列表开头添加URN）或建议特征值（通过在列表末尾添加URN）。
The receiving UA matches the received "alert" URN combination with the signal(s) it is able to render.
接收UA将接收到的“警报”URN组合与其能够呈现的信号相匹配。
The implementation is free to ignore an "alert" URN if it does not recognize the URN, or if it is incapable of rendering its effect in the context. Similarly, it can remove a final series of one or more <alert-ind-part>s of an "alert" URN to create a "more generic" URN that it recognizes and whose meaning it can render in the context.
如果实现无法识别URN，或者无法在上下文中显示其效果，则可以自由忽略“警报”URN。类似地，它可以删除“警报”URN的一个或多个<alert ind part>s的最终系列，以创建一个“更通用”的URN，该URN可以识别并在上下文中呈现其含义。
The exact way in which a UA renders a received combination of "alert" URNs is left as an implementation issue. However, the implementation MUST comply to following rules:
UA呈现接收到的“警报”URN组合的确切方式留作实现问题。但是，实施必须遵守以下规则：
(a) Each "alert" URN has precedence over all URNs that follow it, and its interpretation is subordinate to all URNs that precede it.
(a) 每个“警报”URN优先于其后面的所有URN，其解释从属于其前面的所有URN。
(b) If the UA cannot implement the effect of a URN (because it does not recognize the URN or the URN's effect is precluded by preceding URNs), the UA repeatedly removes the final <alert-ind-part> of the URN until either:
(b) 如果UA无法实现URN的效果（因为它不识别URN或URN的效果被前面的URN排除），UA会重复移除URN的最终<alert ind part>，直到：
(1) the resulting URN is recognized and can be given effect by some signal (without reducing the degree of expression of any preceding URN), or
(1) 所产生的URN被识别，并可通过某些信号生效（不降低任何先前URN的表达程度），或
(2) the resulting URN is reduced to having no <alert-ind-part> in which case, that URN in the series cannot be given effect, and so is ignored.
(2) 生成的URN被简化为没有<alert ind part>，在这种情况下，该系列中的URN无法生效，因此被忽略。
(c) In case that after processing all the received URNs, the UA can generate more than one signal that are equally effective at expressing the URNs (under the preceding rules), one of those signals is selected. When selecting from the set of equally effective signals, the least specific signal in the set should be chosen: a signal should not be chosen if a less-specific signal is also in the set. (Specificity is to be judged based on 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.) However, a more-specific signal may be chosen if the choice is based on information derived 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".
(c) 如果在处理所有接收到的urn之后，UA可以生成在表示urn时同等有效的多个信号（根据前述规则），则选择这些信号中的一个。当从一组同等有效的信号中进行选择时，应选择该组中最不特定的信号：如果该组中也存在较不特定的信号，则不应选择该信号。（特异性将根据信号对用户的定义含义进行判断。）（例如，如果每个信号被视为表示某些<警报类别>的某些<警报指示>s，则如果第一个信号的<警报指示>s是第二个信号的<警报指示>s的子集或前缀，则一个信号的特异性低于第二个信号。）但是，如果选择是基于从包含SIP消息派生的信息，则可以选择更具体的信号。例如，如果SIP消息包含标题字段“优先级：紧急”，则可以选择暗示<urn:alert:priority:high>的信号。
In all situations, the set of signals that can be rendered and their significances may change based on user preferences and local policy. In addition, the chosen signal may 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 be available only if <urn:alert:priority:high> is specified.
在所有情况下，可以呈现的信号集及其意义可能会根据用户偏好和本地策略而改变。此外，所选择的信号可基于UA的状态而改变。例如，如果UA上的呼叫处于活动状态，则所有音频信号都可能不可用，或者只有在指定了<urn:alert:priority:high>时音频信号才可用。
There are cases when the device can render two signal modes (e.g., audio and visual, or video and text) at the same time.
在某些情况下，设备可以同时呈现两种信号模式（例如，音频和视频，或视频和文本）。
Formally, the device must be considered to be making its choice from the set of all combined signals that it can render (pairs of one signal from the first mode and one signal from the second mode), and that choice must conform to the above rules. However, 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 above rules, its combined choice also conforms to the above rules, when it is regarded as a choice from among all possible combinations.
两种模式相互独立，每种选择分别符合上述规则，当其组合选择被视为所有可能组合中的一种选择时，其组合选择也符合上述规则。
In such a situation, it may simplify implementation to make each choice separately. It is an implementation decision whether to chose from among combined signals or to combine choices made from each signal mode.
在这种情况下，单独做出每个选择可能会简化实现。是从组合信号中选择，还是组合从每个信号模式中做出的选择，这是一个实现决策。
The following text is a non-normative example of an algorithm for handling combinations of URNs that complies with the rules in Sections 10 and 11. Thus, it demonstrates that the rules are consistent and implementable. (Of course, a device may use any other algorithm that complies with Sections 10 and 11.)
以下文本是处理符合第10节和第11节规则的URN组合的算法的非规范性示例。因此，它表明这些规则是一致的和可实施的。（当然，设备可以使用符合第10节和第11节要求的任何其他算法。）
For each <alert-category> (feature) known by the implementation, there is a "feature tree" of the known <alert-indication>s for that <alert-category>, with the sequence of <alert-ind-part>s in an <alert-indication> specifying the path in the tree from the root to the node representing the <alert-indication>. For this description, we will name each tree and its root node by the <alert-category> name, and name each non-root node by the <alert-identifier>. Each URN thus corresponds to one non-root node in one feature tree. For example, there is 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> is placed at the node "source:external" in the "source" tree. If the implementation understands <urn:alert:source:foo@example>, there is a node source:foo@example that is a child of node "source". If the implementation understands <urn:alert:source:external:bar@example>, there is a node source:external:bar@example that is a child of node source:external. (Of course, there are an infinite number of potential additional 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.)
对于实施已知的每个<alert category>（功能），存在该<alert category>的已知<alert ind part>的“功能树”，其中<alert ind part>的序列在<alert ind ind>中指定树中从根到代表<alert indication>的节点的路径。对于此描述，我们将使用<alert category>名称命名每个树及其根节点，并使用<alert identifier>命名每个非根节点。因此，每个URN对应于一个特征树中的一个非根节点。例如，有一个名为“source”的树，其根节点也被命名为“source”，其子节点source:internal、source:external、source:friend和source:family。URN<URN:alert:source:external>位于“源”树中的节点“源：外部”。如果实现理解<urn:alert:source:foo@example>，有一个节点源：foo@example这是节点“source”的子节点。如果实现理解<urn:alert:source:external:bar@example>，有一个节点源：外部：bar@example这是节点源的子节点：外部。（当然，在私有值树中有无限多的潜在附加节点，但我们不必显式地表示这些节点，除非设备具有表示私有值的信号。）
We assign similar locations to signals, but each signal has a position in *every* tree, describing the specific combination of meanings that it carries. If a signal has a simple meaning, such as "external source", its place in the "source" tree is source:external,
我们为信号分配了相似的位置，但每个信号在*每个*树中都有一个位置，描述它所承载的特定含义组合。如果信号具有简单的含义，例如“外部源”，则其在“源”树中的位置为source:external，
showing that it carries the "external source" meaning, but its place in every other feature tree is at the root node, meaning that it has no particular meaning for those features.
表明它具有“外部源”的含义，但它在每个其他特征树中的位置都位于根节点，这意味着它对这些特征没有特殊意义。
A signal that has a complex meaning may 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, but be at the root in all other feature trees.
具有复杂含义的信号可能在多个特征树中具有非根位置。例如，“外部，高优先级”信号将放置在这些树中的source:external和priority:high处，但位于所有其他特征树的根处。
In order to assure that the algorithm always selects at least one signal, we require that there is 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 will be the lowest priority signal for any set of URNs.
为了确保算法总是选择至少一个信号，我们要求有一个“默认”信号，它在每个特征树中的位置都在根。对于任何一组URN，此默认信号将永远不会从可接受的信号集中排除，而是任何一组URN的最低优先级信号。
The algorithm proceeds by considering each URN in the received Alert-Info header fields from left to right, while revising a set of signals. The set of signals 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 in the set 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 the position of a signal in the set. The second URN is a "minor sort", in that it arranges the orders of the signals that are tied within the first sort, the third URN arranges the orders of the signals that are tied within the first two sorts, etc.
该算法从左到右考虑接收到的警报信息报头字段中的每个URN，同时修改一组信号。该信号集作为设备可用的整个信号集开始。每个URN从集合中排除一些信号，并根据它们代表URN的程度对集合中剩余的信号进行“排序”。（这些操作的细节如下所述。）第一个URN是“主要类别”，对信号在集合中的位置影响最大。第二个URN是“次要排序”，因为它排列第一个排序中绑定的信号的顺序，第三个URN排列前两个排序中绑定的信号的顺序，以此类推。
At the end of the algorithm, a final, "most minor" sort is done, which orders the signals that remain tied under all the sorts driven by the URNs. This final sort places the least specific signals (within their tied groups) "first". (If one signal's position in each feature tree is ancestral or the same as a second signal's position in that tree, the first signal is "less specific" than the second signal. Other cases are left to the implementation to decide.)
在算法结束时，完成最后的“最次要”排序，该排序将对在URN驱动的所有排序下保持绑定的信号进行排序。最后的排序将最不特定的信号（在其绑定组中）“放在第一位”。（如果一个信号在每个特征树中的位置是祖先的，或者与第二个信号在该树中的位置相同，则第一个信号比第二个信号“不太具体”。其他情况由实现决定。）
Once all the URNs are processed and the sorting of the signals that have not been excluded is done, the device selects the first signal in the set.
处理完所有URN并对未排除的信号进行排序后，设备将选择集合中的第一个信号。
Here is how a single sort step proceeds, examining a single URN to modify the set of signals (by excluding some signals and further sorting the signals that remain):
下面是单个排序步骤的过程，检查单个URN以修改信号集（通过排除一些信号并进一步对剩余的信号进行排序）：
o The URN specifies a specific node in a specific feature tree.
o URN指定特定功能树中的特定节点。
o 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).
o 在该特征树中，位于URN节点或URN节点的祖先节点上的所有信号都将被保留。所有其他信号将从集合中删除（因为它们的含义与URN的含义不兼容）。
o Each group of signals that are tied under the previous sorts are further sorted into groups based on how much of the URN's meaning they represent: those which are positioned at the node of the URN are tied for first position, those which are positioned at the parent node of the URN are tied for second position, etc., and those which are positioned at the root node of the feature tree are tied for last position.
o 根据URN所代表的含义的多少，将之前排序下绑定的每组信号进一步分类为组：位于URN节点的信号绑定到第一个位置，位于URN父节点的信号绑定到第二个位置，等等。，而那些位于特征树根节点上的特征被绑定到最后一个位置。
The following examples show how the algorithm described in the previous section works:
以下示例显示了上一节中描述的算法的工作原理：
The device has a set of four alerting signals. We list their primary meanings, and the locations that they are placed in the feature trees:
该设备有一组四个报警信号。我们列出了它们的主要含义，以及它们在要素树中的位置：
Signal 1
信号1
Meaning: external Locations: - source:external - priority (that is, the root node of the priority tree)
含义：外部位置：-来源：外部-优先级（即优先级树的根节点）
Signal 2
信号2
Meaning: internal Locations: - source:internal - priority
含义：内部位置：-来源：内部-优先级
Signal 3
信号3
Meaning: low Locations: - source - priority:low
含义：低位：-来源-优先级：低位
Signal 4
信号4
Meaning: high Locations: - source - priority:high
含义：高位：-来源-优先级：高位
To which we add:
我们在此补充：
Signal 5
信号5
Meaning: default Locations: - source - priority
含义：默认位置：-源-优先级
If the device receives <urn:alert:source:internal>, then the sort is:
如果设备接收到<urn:alert:source:internal>，则排序为：
Signals at source:internal: (this is, first place)
信号源：内部：（这是第一位）
Signal 2: internal
信号2：内部
Signals at source: (tied for second place)
信号源：（并列第二）
Signal 3: low Signal 4: high Signal 5: default
信号3：低信号4：高信号5：默认值
And these signals are excluded from the set:
这些信号被排除在集合之外：
Signal 1: external
信号1：外部
So, in this example, the sorting algorithm properly gives first place to Signal 2 "internal".
因此，在本例中，排序算法正确地将信号2“内部”放在第一位。
Let us add to the set of signals in Example 1 ones that express combinations like "internal, high priority", but let us specifically exclude the combination "internal, low priority" so as to set up some tricky examples. This enlarges our set of signals:
让我们在示例1中的信号集合中添加表示“内部，高优先级”等组合的信号，但让我们明确排除“内部，低优先级”组合，以便建立一些棘手的示例。这将扩大我们的信号集：
Signal 1
信号1
Meaning: default Locations: - source - priority
含义：默认位置：-源-优先级
Signal 2
信号2
Meaning: external Locations: - source:external - priority
含义：外部位置：-来源：外部-优先级
Signal 3
信号3
Meaning: internal Locations: - source:internal - priority
含义：内部位置：-来源：内部-优先级
Signal 4
信号4
Meaning: low Locations: - source - priority:low
含义：低位：-来源-优先级：低位
Signal 5
信号5
Meaning: high Locations: - source - priority:high
含义：高位：-来源-优先级：高位
Signal 6
信号6
Meaning: external high Locations: - source:external - priority:high
含义：外部高位：-来源：外部-优先级：高位
Signal 7
信号7
Meaning: external low Locations: - source:external - priority:low
含义：外部低位：-来源：外部-优先级：低位
Signal 8
信号8
Meaning: internal high Locations: - source:internal - priority:high
含义：内部高位：-来源：内部-优先级：高位
If the device receives <urn:alert:source:internal>, then the sort is:
如果设备接收到<urn:alert:source:internal>，则排序为：
Signals at source:internal: (that is, tied for first place)
信号源：内部：（即并列第一）
- Signal 3: internal - Signal 8: internal high
- 信号3：内部-信号8：内部高电平
Signals at source: (tied for second place)
信号源：（并列第二）
- Signal 4: low - Signal 5: high - Signal 1: default
- 信号4:低-信号5:高-信号1:默认值
Signals excluded from the set:
从集合中排除的信号：
- Signal 2: external - Signal 7: external low - Signal 6: external high
- 信号2：外部-信号7：外部低-信号6：外部高
Two signals are tied for the first place, but the final sort orders them:
两个信号在第一个位置是并列的，但最后的排序顺序是：
- Signal 3: internal - Signal 8: internal high
- 信号3：内部-信号8：内部高电平
because it puts the least-specific signal first. So, the Signal 3 "internal" is chosen.
因为它把最不特定的信号放在第一位。因此，选择信号3“内部”。
The same device receives <urn:alert:source:external>, <urn:alert:priority:low>. The first sort (due to <urn:alert:source:external>) is:
同一设备接收<urn:alert:source:external>，<urn:alert:priority:low>。第一种排序（由于<urn:alert:source:external>）是：
Signals at source:external:
信号源：外部：
- Signal 2: external - Signal 7: external low - Signal 6: external high
- 信号2：外部-信号7：外部低-信号6：外部高
Signals at source:
信号源：
- Signal 4: low - Signal 5: high - Signal 1: default
- 信号4:低-信号5:高-信号1:默认值
Signals excluded:
不包括的信号：
- Signal 3: internal - Signal 8: internal high
- 信号3：内部-信号8：内部高电平
The second sort (due to <urn:alert:priority:low>) puts signals at priority:low before signals at priority, and excludes signal at priority:high:
第二种排序（由于<urn:alert:priority:low>）将优先级为：低的信号置于优先级为信号之前，并排除优先级为：高的信号：
- Signal 7: external low - Signal 2: external - Signal 4: low - Signal 1: default
- 信号7：外部低-信号2:外部-信号4:低-信号1:默认
Excluded:
排除：
- Signal 6: external high - Signal 5: high - Signal 3: internal - Signal 8: internal high
- 信号6：外部高-信号5：高-信号3：内部-信号8：内部高
So, we choose Signal 7 "external low".
因此，我们选择信号7“外部低”。
Suppose the same device receives <urn:alert:source:internal>, <urn:alert:priority:low>. Note that there is no signal that corresponds to this combination.
假设同一设备接收到<urn:alert:source:internal>，<urn:alert:priority:low>。请注意，没有与此组合对应的信号。
The first sort is based on source:internal, and results in this order:
第一种排序基于source:internal，结果的顺序如下：
- Signal 3: internal - Signal 8: internal high - Signal 4: low - Signal 5: high - Signal 1: default
- 信号3:内部-信号8:内部高-信号4:低-信号5:高-信号1:默认
Excluded:
排除：
- Signal 2: external - Signal 7: external low - Signal 6: external high
- 信号2：外部-信号7：外部低-信号6：外部高
The second sort is based on priority:low, and results in this order:
第二种排序基于优先级：low，结果的顺序如下：
- Signal 3: internal - Signal 4: low - Signal 1: default
- 信号3：内部-信号4：低-信号1：默认值
Excluded:
排除：
- Signal 8: internal high - Signal 5: high - Signal 7: external low - Signal 2: external - Signal 6: external high
- 信号8：内部高-信号5：高-信号7：外部低-信号2：外部-信号6：外部高
So, we choose the Signal 3 "internal".
因此，我们选择信号3“内部”。
Note that <urn:alert:priority:low> could not be given effect because it followed <urn:alert:source:internal>. If the two URNs had appeared in the reverse order, the Signal 2 "external" would have been chosen, because <urn:alert:priority:low> would have been given precedence.
请注意，<urn:alert:priority:low>无法生效，因为它紧跟在<urn:alert:source:internal>之后。如果两个urn以相反的顺序出现，则会选择信号2“外部”，因为<urn:alert:priority:low>会被赋予优先权。
Let us set up a simple set of signals, with three signals giving priority:
让我们设置一组简单的信号，三个信号优先：
Signal 1
信号1
Meaning: default Locations: - priority
含义：默认位置：-优先级
Signal 2
信号2
Meaning: low Locations: - priority:low
含义：低位置：-优先级：低
Signal 3
信号3
Meaning: high Locations: - priority:high
含义：高位置：-优先级：高
Notice that we've used the "default" signal to cover "normal priority". That is so the signal will cover situations where no priority URN is present, as well as the ones with <urn:alert:priority:normal>. So, we're deliberately failing to distinguish "priority:normal" from the default priority.
请注意，我们使用了“default”信号来覆盖“normalpriority”。也就是说，该信号将覆盖不存在优先级URN的情况，以及具有<URN:alert:priority:normal>的情况。因此，我们故意不区分“优先级：正常”和默认优先级。
If the device receives <urn:alert:priority:low>, the sort is:
如果设备接收到<urn:alert:priority:low>，则排序为：
- Signal 2: low - Signal 1: default
- 信号2：低-信号1：默认值
Excluded:
排除：
- Signal 3: high
- 信号3：高
and Signal 2 "low" is chosen.
选择信号2“低”。
Similarly, if the device receives <urn:alert:priority:high>, Signal 3 is chosen.
类似地，如果设备接收到<urn:alert:priority:high>，则选择信号3。
If the device receives <urn:alert:priority:normal>, the sort is:
如果设备接收到<urn:alert:priority:normal>，则排序为：
-Signal 1 :default
-信号1：默认
Excluded:
排除：
- Signal 2: low - Signal 3: high
- 信号2：低-信号3：高
and Signal 1 "default" is chosen.
选择信号1“默认”。
If no "priority" URN is received, Signal 1 "default" will be put before Signal 2 "low" and Signal 3 "high" by the final sort, and so it will be chosen.
如果未接收到“优先级”URN，则最终排序时，信号1“默认”将置于信号2“低”和信号3“高”之前，因此将选择它。
A SIP UA MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to provide additional information about the call or about the provided service.
当SIP UA需要提供有关呼叫或所提供服务的附加信息时，可以在SIP请求或临时1xx响应（100响应除外）中的警报信息报头字段中添加一个或多个URN。
Upon receiving a SIP INVITE request or a SIP provisional response with an Alert-Info header field that contains a combination of Alert-Info URNs, the UA attempts to match the received Alert- Info URNs combination with a signal it can render. The process the UA uses MUST conform to the rules described in Section 11. (A non-normative algorithm example for the process is described in Section 12.)
收到SIP INVITE请求或SIP临时响应时，UA会尝试将收到的警报信息URN组合与它可以呈现的信号进行匹配，其中警报信息头字段包含警报信息URN的组合。UA使用的流程必须符合第11节中描述的规则。（第12节描述了该过程的非规范性算法示例。）
The UA must produce a reasonable rendering regardless of the combination of URIs (of any schemes) in the Alert-Info header field: it MUST produce a rendering based on the URIs that it can understand and act on (if any), interpreted as prescribed by local policy, and ignore the other URIs. In particular, unless the containing message is a request and is immediately rejected, the UA SHOULD provide some alert unless it is instructed not to (for example, by Alert-Info URIs that it understands, the presence of a Replaces or Joins header field, local policy, or direction of the user).
UA必须生成合理的呈现，而不考虑警报信息标题字段中的URI组合（任何方案）：它必须基于其可以理解和操作的URI（如果有）生成呈现，并按照本地策略的规定进行解释，并忽略其他URI。特别是，除非包含的消息是一个请求并且立即被拒绝，否则UA应该提供一些警报，除非指示其不提供（例如，通过其了解的警报信息URI、替换或加入标头字段、本地策略或用户指示的存在）。
Subsequent provisional responses, even within the same dialog, may contain different Alert-Info header field values. The Alert-Info header field values received within different provisional responses are treated independently. If subsequent provisional responses containing 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. The handling of provisional responses containing different Alert-Info header field values that were not received within the same dialog is left as an implementation issue.
即使在同一对话框中，后续临时响应也可能包含不同的警报信息标题字段值。在不同临时响应中接收的警报信息标题字段值将单独处理。如果在同一对话框中收到包含不同警报信息标题字段值的后续临时响应，UA应随时呈现上次收到的警报信息标题字段值。处理包含不同警报信息标题字段值的临时响应（在同一对话框中未收到这些值）将作为一个实施问题。
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 when it needs to modify the information about the call or about the provided services.
当SIP代理需要修改关于呼叫或关于所提供服务的信息时，它可以在SIP请求或非100临时响应中添加或删除警报信息报头字段，并且可以添加或删除警报信息报头字段值。
There are many reasons a proxy may choose do this, for example, (1) to add indications based on information that the proxy can determine about the call, such as that it is coming from an external source, or that the INVITE contains a "Priority: urgent" header field; (2) to add indication that a particular service is being invoked at this end of the call; (3) to remove undesirable indications, such as possibly deceptive indications from untrusted sources; and (4) to remove indications that contain information that should be suppressed for privacy reasons.
代理选择这样做的原因有很多，例如，（1）根据代理可以确定的有关调用的信息添加指示，例如，调用来自外部源，或者邀请包含“优先级：紧急”标题字段；（2） 添加特定服务在调用的这一端被调用的指示；（3） 消除不受欢迎的迹象，例如来自不可信来源的可能具有欺骗性的迹象；以及（4）删除包含出于隐私原因应禁止的信息的指示。
The following example shows a typical example of a 180 (Ringing) provisional response that has been modified by a proxy. The response sent by the UAS to the proxy was very similar, but had no Alert-Info header field. The proxy has added Alert-Info header field values specifying both a network audio resource referenced by the HTTP URI and the URN indication for the call-waiting service. This allows the UAC to render the network audio resource, to choose a rendering based on the URN, or to perform some combination of these actions. Due to Section 10, the UAC must produce some reasonable rendering in this situation.
以下示例显示了180（振铃）临时响应的典型示例，该响应已被代理修改。UAS发送给代理的响应非常相似，但没有警报信息头字段。代理添加了警报信息头字段值，指定HTTP URI引用的网络音频资源和呼叫等待服务的URN指示。这允许UAC渲染网络音频资源，根据URN选择渲染，或执行这些操作的某些组合。根据第10节，UAC必须在这种情况下提供一些合理的渲染。
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: 0
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: 0
The <alert-identifier> labels are protocol elements [RFC6365] and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 7.
<alert identifier>标签是协议元素[RFC6365]，用户通常看不到。因此，如第7节所述，这些元素的字符集受到限制。
Allowance has been made for the possibility of internationalizing <alert-identifier>s by allowing them to be A-labels: a processor that does not understand such <alert-identifier>s is required to ignore them as specified in Sections 7 and 11.1.
允许将<alert identifier>s作为A标签，从而允许其国际化：要求不理解此类<alert identifier>s的处理者按照第7节和第11.1节的规定忽略它们。
The URNs <urn:alert:locale:country:<ISO 3166-1 country code>> select renderings that are conventional in the specified country.
URNs<urn:alert:locale:country:<ISO 3166-1国家/地区代码>>选择指定国家/地区的常规渲染。
As an identifier, the "alert" URN does not appear to raise any particular security issues. The indications described by the "alert" URN are meant to be well-known.
作为标识符，“警报”URN似乎不会引起任何特定的安全问题。“警报”URN描述的指示是众所周知的。
However, the provision of specific indications may raise privacy issues by revealing information about the source UA, e.g., its nature, its dialog state, or services initiated at its end of the call. For example, 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.
然而，提供特定指示可能会通过披露有关源UA的信息（例如，其性质、对话状态或在通话结束时启动的服务）而引发隐私问题。例如，呼叫等待（第6.2.1节）和呼叫转移（第6.2.2节）服务可以显示UA的对话状态。此类规定应始终要求代表源UA的用户进行授权（通常通过访问配置的策略）。授权不得假设在未获得SIP交易的具体信息的情况下，指示的潜在接收者有任何限制。
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
根据当地政策，UA可以选择忽略不需要的指示（例如，可能来自不可信来源的欺骗性指示），也可以选择不发送不可靠的指示
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.
否则在上下文中有效（例如，出于隐私原因）。代表UA行事的代理人可出于相同原因添加或删除前往UA或从UA发出的指示。
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].
由于警报指示可能是敏感的，因此可以使用使用S/MIME的端到端SIP加密机制对其进行保护。实现警报指示的UAs还应通过TLS[RFC5246]和sips:scheme[RFC5630]实现SIP。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC2141]护城河，R.，“瓮语法”，RFC 21411997年5月<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>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月<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>.
[RFC3406]Daigle，L.，van Gulik，D.，Iannella，R.，和P.Faltstrom，“统一资源名称（URN）命名空间定义机制”，BCP 66，RFC 3406，2002年10月<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>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<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>.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<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>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月<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>.
[RFC5630]Audet，F.“会话启动协议（SIP）中SIPS URI方案的使用”，RFC 5630，2009年10月<http://www.rfc-editor.org/info/rfc5630>.
[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>.
[E182]ITU-T，“电话服务中音调和录音公告的应用”，ITU-T建议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>.
[ISO3166-1]ISO，“英语国家名称和代码元素”，ISO 3166-1<http://www.iso.org/iso/ 英语\国家\名称\和\代码\元素>。
[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>.
[RFC3043]Mealling，M.“网络解决方案个人互联网名称（PIN）：个人和组织的URN名称空间”，RFC3043，2001年1月<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>.
[RFC3044]Rozenfeld，S.，“在ISSN-URN名称空间中将ISSN（国际序列号）用作URN（统一资源名）”，RFC 3044，2001年1月<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>.
[RFC3120]贝斯特，K.和N.沃尔什，“XML.org的URN名称空间”，RFC31202001年6月<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>.
[RFC3187]Hakala，J.和H.Walravens，“使用国际标准书号作为统一资源名称”，RFC 3187，2001年10月<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>.
[RFC3188]Hakala，J.，“使用国家书目编号作为统一资源名称”，RFC 3188，2001年10月<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>.
[RFC4152]Tesink，K.和R.Fox，“公共语言设备标识符（CLEI）代码的统一资源名称（URN）命名空间”，RFC 4152，2005年8月<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>.
[RFC4179]Kang，S.“使用通用内容标识符（UCI）作为统一资源名（URN）”，RFC 4179，2005年10月<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>.
[RFC4195]Kameyama，W.，“TV Anytime论坛的统一资源名（URN）命名空间”，RFC 41952005年10月<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>.
[RFC4198]Tessman，D.，“联合内容的统一资源名（URN）命名空间”，RFC4198，2005年11月<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>.
[RFC5589]Sparks，R.，Johnston，A.，和D.Petrie，“会话启动协议（SIP）呼叫控制-传输”，BCP 149，RFC 5589，2009年6月<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>.
[RFC5890]Klensin，J.“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月<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>.
[RFC6365]Hoffman，P.和J.Klensin，“IETF国际化中使用的术语”，BCP 166，RFC 63652011年9月<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>.
[RFC6910]Worley，D.，Huelsemann，M.，Jeske，R.，和D.Alexetsev，“会话启动协议（SIP）呼叫的完成”，RFC 69102013年4月<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>.
[RFC7463]Johnston，A.，Ed.，Soroushnejad，M.，Ed.，和V.Venkataramanan，“会话启动协议（SIP）记录地址（AOR）的共享外观”，RFC 74632015年3月<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.
[TS24.615]3GPP，“使用IP多媒体（IM）核心网络（CN）子系统的通信等待（CW）；协议规范”，3GPP TS 24.615，2015年9月。
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.
作者希望感谢《布利斯》初版编辑丹尼斯·阿列克谢采夫、安瓦尔·西迪基对该文件的贡献、克里斯特·霍姆伯格对该文件的仔细审查、亚当·罗奇、迪安·威利斯、马丁·赫尔塞曼、希达·舒伯特、约翰·埃尔威尔、，汤姆·泰勒（Tom Taylor）的评论和建议，阿尔弗雷德·霍恩斯（Alfred Hoenes）对URN的新名称空间标识符提出了广泛的评论和建议。
Authors' Addresses
作者地址
Laura Liess (editor) Deutsche Telekom AG Heinrich-Hertz Str 3-7 Darmstadt, Hessen 64295 Germany
Laura Liess（编辑）德国电信公司Heinrich Hertz Str 3-7 Darmstadt，Hessen 64295德国
Phone: +49 6151 5812761
EMail: laura.liess.dt@gmail.com
Phone: +49 6151 5812761
EMail: laura.liess.dt@gmail.com
Roland Jesske Deutsche Telekom AG Heinrich-Hertz Str. 3-7 Darmstadt, Hessen 64295 Germany
德国黑森州达姆施塔特市海因里希赫兹街3-7号罗兰·杰西克德国电信公司，邮编64295
Phone: +49 6151 5812766
EMail: r.jesske@telekom.de
Phone: +49 6151 5812766
EMail: r.jesske@telekom.de
Alan Johnston Avaya, Inc. St. Louis, MO United States
美国密苏里州圣路易斯市艾伦·约翰斯顿·阿瓦亚公司
EMail: alan.b.johnston@gmail.com
EMail: alan.b.johnston@gmail.com
Dale R. Worley Ariadne Internet Services, Inc. 738 Main St. Waltham, MA 02451 United States
Dale R.Worley Ariadne互联网服务有限公司，地址：美国马萨诸塞州圣沃尔瑟姆大街738号，邮编：02451
Phone: +1 781 647 9199
EMail: worley@ariadne.com
Phone: +1 781 647 9199
EMail: worley@ariadne.com
Paul Kyzivat Huawei United States
美国保罗·基齐瓦特
EMail: pkyzivat@alum.mit.edu
EMail: pkyzivat@alum.mit.edu